ESP8266 FLASH SIZES and SDK issues

27 thoughts on “ESP8266 FLASH SIZES and SDK issues”

1. hi pete,

   i have chosen ESP8266 chip for my Engineering Project. I want to use RTOS SDK so that i can make use of multithreading in the program. i’m Having a lot of problems compiling the Program using the latest RTOS SDK V1.4.x in windows. I have tried numerous tutorials from other site and failed. Can you please guide me in compiling RTOS SDK from scratch in either linux or windows(whichever you prefer). And also i wanted to know the maximum number of threads we could run in ESP8266_RTOS_SDK.

2. Dear Pete,
   I know you from some other ESP8266 site. Happy to see you here. I have a problem with ESP8266 12E and 12F series about write commands. When I need to write data to the ROM in ESP8266 it only allows to around 6800 times with (w+) command. I am using both integer and float and lastest and previous firmwares but nothing changes. An example simple code is below. W,th ESPlorer I run the codes and when both test1 lua and test2 lua reaches to 3400 file system starts to reset the module. I only activate module by formatting it. If I use just one file it reaches around 6800 cycle of writing. With (a+) command and 2 files I only managed to write up to total 13600 number somehow. Then again a format is needed.
   Any help would be appriciated.

   test=0
   tmr.alarm(6, 100, 1, function()
   node.restore()
   file.open(“test1.lua”,”w+”)
   file.writeline(test)
   file.close()
   file.open(“test2.lua”,”w+”)
   file.writeline(test)
   file.close()

   test=test+1
   end)

   1. hi there Ugur

      Sorry I gave up on Lua a long time ago – not enough RAM and it was crashing often – I went to programming the chips in C and have had no problems since. So afraid I can’t help you – someone else may have something to say..

      1. Thanks for your quick response

3. Hello Everyone,
   I try to compiling the code of mesh.But it show below error what will be the issue
   c:/Espressif/ESP8266_SDK/lib\libmain.a(app_main.o): In function `user_uart_wait_tx_fifo_empty’:
   (.irom0.text+0x5c4): undefined reference to `user_init’
   c:/Espressif/ESP8266_SDK/lib\libmain.a(app_main.o): In function `user_rf_pre_init’:
   (.irom0.text+0x85a): undefined reference to `user_init’
   collect2.exe: error: ld returned 1 exit status
   C:/Users/abc/worksorg/meshnetwork/Makefile:187: recipe for target ‘build/app.out’ failed
   mingw32-make.exe: *** [build/app.out] Error 1

4. You have it the other way around, irom0text.bin stays on flash and flash.bin is loaded into memory. This is just an example (default) layout, you can change the split with the linker file. The reason it is split is just a poor design decision by espressif, when you use a boot loader (rBoot or the sdk one) you can combine them into a single file that is written in one chunk to the flash. The reason for two “user data” areas is just to fill in the gap that that poor decision leaves, if you use a loader then you just have a single larger user data area.

   1. Thanks a lot for this clear explanation.

5. So I have been using Lua Scripts for some time and now moving to SDK.
   I am using the Unofficial SDK and read the documentation that comes with it in the doc directory.

   I have some doubts:

   What is the difference between: flash.bin and irom0.text.bin??
   Why is there two different sections in the ESP Flash Mapping?
   In the FOTA section, they showed two user firmwares user1.bin and user2.bin, why two firmwares??

   I might be posting this off topic, but I am not getting reply from the esp community and would like to know more about SDK. Thank you.

   1. The file names are arbitrary, but a standard sdk app has two files, one contains the elf sections that go in memory and the other (the larger one) contains the sections that stay on flash and are accessed through memory mapped flash.
      When using a boot loader (sdk or rBoot) all sections are contained in a single file.
      The only really safe way to do OTA is have two copies of the rom on the device, one that is running and one that is to be updated and switched to. If these are both in the same 1mb chunk of flash they need to be linked differently. So user1 and user2 are the same rom, just linked differently depending on where they will sit within that 1mb chunk. If they are to be in different 1mb chunks of flash (but the same relative position within each) you only need to link a single file which can be used in either 1mb chunk.

      1. Thanks a lot Burton, that cleared most of my doubts.

         I am still unclear about the Flash partitions though.

         In the section “Flash Map” of IOT SDK Manual document, it demonstrates a 512KB flash map for none boot:

         |
         Flash.bin| User Data| User Parameter |irom0text.bin| User Data| System Parameter

         What is the need to partition two 256KB segments?
         Why is there two User Data segments?
         Ans as per your explanation, flash.bin will contain data that remains on flash and iromtext.bin contains the elf data that goes into memory. Am I right? Or is it the other way around?

         *Ignore my poor drawing skills 🙂

6. Hello i am a beginner to ESP8266 , i got acouple of ESP-01 from Aliexpress
   and i want to use it as wifi shield to send and receive data connected it to Arduino Uno , Nano etc. using Blynk app on android.

   my problem is to use it with Blynk it must be loaded with AT firmware (the official one) , and the SDK 1.0 AT command v 22
   mine has FW 0.95.

   any easy way to do that and where can i find the required uploader and FW files

   1. Blynk looks very near – a shame you have to use the AT firmware.. however… if that’s the direction you want to go (see the article I just did on websockets – though that means your own “cloud”) – the ESP-01 boards are not the easiest to program – as you’ll need an FTDI board (usb-serial convertor) and some interfacing unless your FTDI can output 3v3 volts. a simpler bet would be something like the nodemcu or other variation that has a micro-usb connector – then it is just a matter of getting the right software. You will need the facility to FLASH the chip – and the code can be had from the ESPRESSIF forum. On a PC, I personally found it easiest to get hold of the ALTERNATIVE ESP8266 environment which has just about everything you need (assuming you’re using Windows) – on Linux, you’ll need to seek advice from others. Just Google “ESP8266 flashing AT software” – someone will already have done this and that will save you some learning curve. In the end it is all very easy, just a bit of a learning curve. This advice seems pretty good at first glance. https://developer.mbed.org/users/sschocke/code/WiFiLamp/wiki/Updating-ESP8266-Firmware

      1. Hello,
         when ever i try to complie code the following errors occurs.Can you tell me what will be the issue

         ets Jan 8 2013,rst cause:1, boot mode:(3,7)

         load 0x40100000, len 27468, room 16
         tail 12
         chksum 0x75
         ho 0 tail 12 room 4
         load 0x3ffe8000, len 1376, room 12
         tail 4
         chksum 0xfb
         load 0x3ffe8560, len 5048, room 4
         tail 4
         chksum 0xf3
         csum 0xf3

         1. When you are COMPILING the code!!???!!! That’s a reboot are you sure it is when you are compiling – don’t you mean AFTER you’ve flashed the code?

            1. Sorry not in compiling.After upload the code in esp, the following error shown in output window i.e in putty terminal.

      2. i know that AT FW is sucks , but as Blynk use ITEADLIB_Arduino_WeeESP8266 library that communicate with ESP8266 loaded with AT FW ver 1.0 even not the latest.

         i tried to use OpenHAP but i found it very complicated especially designing the sitemap and
         also add the bindings, so Blynk is the shortcut for now.

         i am waiting the USB To Serial to arrive , to start playing with Blynk

         https://github.com/vshymanskyy/ITEADLIB_Arduino_WeeESP8266
         http://www.blynk.cc/

         1. I too found OpenHab to be a little heiroglyphic – and that started me down the road of using MQTT and Node-Red – and I’ve never looked back 🙂

7. The erase function is buggy, I don’t know if it’s esptool.py or the esp8266 itself. On my ESP-12 I’ve found many times that writing the bootloader at 0x00000 has also erased the second sector, despite the bootloader only being about 2k and so it should fit comfortably within the first sector.

   And yes, the ESP-12 does have a larger eeprom, it’s 32Mbit. You can make sure you’re rom will fit at link time by setting the section sizes and addresses correctly in the linker script, if you then try to exceed them it will complain when you link the rom.

   You can change the 0x40000 position of the .irom0.text section, but be sure to update the linker script and where you flash too. Better than that if you use the bootloader it supports a newer rom type that puts the .irom0.text section first and your iram section follow straight after, meaning you don’t need to specify an arbitrary split up front.

   I recently wrote a bit about the boot process, the sdk bootloader and even wrote a new open source bootloader myself. See http://richard.burtons.org/2015/05/17/esp8266-boot-process/ and the couple of articles that follow for more info.

   Richard.

8. while playing this afternoon, I watched the eclipse console as I flashed an ESP-01 with a sming example. It looked like so:

   [first bin]
   Writing at 0x00000000… (3 %)
   Writing at 0x00000400… (7 %)
   …(etc)
   Writing at 0x00006800… (96 %)
   Writing at 0x00006c00… (100 %)

   [second bin]
   Writing at 0x00009000… (0 %)
   …(etc)
   Writing at 0x0003c000… (99 %)
   Writing at 0x0003c400… (100 %)

   As you can see it’s reporting the start and end addresses of each of the two flash operations. So if you examine the flash console output from when you flash the problem set, it should be obvious if the first binary is writing into the address range of the second.

   As we’ve discussed, the fix could be as simple as simply assigning a higher or different start address for the second bin. Though of course it would help to know what’s more bloated in v1.01 vs v0.96.

9. It may be due to this bug?

   https://github.com/themadinventor/esptool/issues/33

   1. There’s a good chance you are right – I’m now reversing the flashing order (400000 first) and having no issues at all. I’ve not been able to do the fixes suggested in that link in my Windows Makefile however.. but reversing the flashing order does seem to solve it.

10. Interesting issue.

    Some (random) thoughts:
    – have you tried arbitrarily commenting out code sections to see if the resulting compile now fits?
    – have you tried thinning out debugging or similar code?
    – have you flagged enough of your functions with ICACHE_FLASH_ATTR to move it in memory? Maybe flagged too many?

    There’s some old notes about memory at http://www.esp8266.com/viewtopic.php?f=5&t=9&start=40

    In the main make file, there’s a set of profilers that produce something like this after a compile:
    ——————————————————–
    Section info:

    out/build/app.out: file format elf32-xtensa-le

    Sections:
    Idx Name Size VMA LMA File off Algn
    0 .data 000005b8 3ffe8000 3ffe8000 000000e0 2**4
    CONTENTS, ALLOC, LOAD, DATA
    1 .rodata 00001a10 3ffe85c0 3ffe85c0 000006a0 2**4
    CONTENTS, ALLOC, LOAD, DATA
    2 .bss 00009390 3ffe9fd0 3ffe9fd0 000020b0 2**4
    ALLOC
    3 .irom0.text 0002f4e8 40209000 40209000 00007020 2**4
    CONTENTS, ALLOC, LOAD, READONLY, CODE
    4 .text 00004f69 40100000 40100000 000020b0 2**2
    CONTENTS, ALLOC, LOAD, READONLY, CODE
    ——————————————————————————
    Memory Usage:
    Section| Description| Start (hex)| End (hex)|Used space
    ——————————————————————————
    data| Initialized Data (RAM)| 3FFE8000| 3FFE85B8| 1464
    rodata| ReadOnly Data (RAM)| 3FFE85C0| 3FFE9FD0| 6672
    bss| Uninitialized Data (RAM)| 3FFE9FD0| 3FFF3360| 37776
    text| Cached Code (IRAM)| 40100000| 40104F69| 20329
    irom0_text| Uncached Code (SPI)| 40209000| 402384E8| 193768
    Total Used RAM : 45912
    Free RAM : 36008
    Free IRam : 12457

    … perhaps these might give a clue about whether the files ‘fit’.

    I suspect there’s some setting in the makefile that determines where the two bin files get placed and linked. The 0x40000 might just be arbitrary and can be changed to reallocate memory a bit.

    1. I’m trying to avoid that – I intend to make the program bigger not smaller and it works on the .96 SDK…

       1. But I WILL go through the notes – thanks for the links.

11. Which seems to suggest that the code being written at 0x00000 is too big and is being clobbered by the subsequent write at 0x40000, doesn’t it. Sounds like an off-by-one type bug.

    1. Hmmm….

12. Here’s the funny thing… somewhere I found a directive for ESPTOOL called -bz 512K – but it doesn’t work. Elsewhere I found the suggestion to reverse the flashing order.. and that DOES. It is certainly not a solution, more a CLUGE but it does work and I can now blow the code to both ESP-01 and ESP-07 and it works. Need a better way though..

    flash: firmware/0x00000.bin firmware/0x40000.bin
    $(PYTHON) $(ESPTOOL) -p $(ESPPORT) write_flash 0x3C000 $(BLANKER) 0x40000 firmware/0x40000.bin 0x00000 firmware/0x00000.bin

    ## $(PYTHON) $(ESPTOOL) -p $(ESPPORT) write_flash 0x00000 firmware/0x00000.bin 0x3C000 $(BLANKER) 0x40000 firmware/0x40000.bin

Comments are closed.