ESP8266 Community Forum

I see that as per the link https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map, in SPI flash ROM layout table (without OTA) there are 5 bin files that are flashed to esp8266. Though there are instructions found online in other resources that mention how to merge all bin file to one,

- What is the primary reason behind creating 5 different bin files for ESP MCUs unlinke a single bin file in other MCUs like STM32? (What is the distinct purpose of each bin file and what is the architechture or working principle of ESP due to which we need to generate different bin files?)
- I would be thankful if someone can add the detail of explaining the bin files with respect to memory layout. The starting addresses of the bin files do not reflect in the memory layout table given in page in same URL mentioned above.
- Finally, Why do we need to use esptool command utility to flash bin files to ESP MCU unlike using load command in other MCUs like STM32. Is there any difference in memory layout functioning that ESP MCU differs architecturally or at BFD level from other MCUs?

Probably it seems to club multiple questions at a single go, but fundamentally all questions point to the same concept of memory layout in ESP MCUs and its reflection in build process/ flashing.

Thanks

first of all the flash is external and can be large. it is possible to create and flash one bin, but it could be large.

most of the flashed bin files are blank.bin to clear settings stored in flash.

Espressif choose to not implement a hardware programmer (inside the chip and a additional peripheral). Instead they choose to create a simple software-based programmer (in the ROM code) using UART/serial instead of the usual SPI interface.

This may sound lame (and is a bit too), but it also means you don't need an expensive programmer. Any serial port (or USB to serial converter) will do. Add two additional signal lines (DTR, RTS -> reset, gpio0) and you have fully functioning programmer. The esptool's main function is to send your image over the serial line in a way the ESP "programmer" code understands it. It will normally upload some stub programmer code, too, but the idea remains the same and it can work without the sub too.

The programmer works like this, you point out a sector of flash (4k) to program and send it. The ESP then erases that sector and programs it.

Besides the software (image) areas, there are also areas where the Espressif SDK code (which you can't omit, unfortunately) keeps some state, for example some system settings you requested and wlan phy settings. The areas have been at fixed areas for years, but are now user configurable. I think most images still keep them where they have always been, though.

This creates a situation where areas to be programmed are not consecutive. Creating an image with megabytes of null/filling sectors would be senseless. So that is why you have multiple files to be flashed.

Also the "normal" image layout requires the "iram" and "flash" segments of the image to be handed separately. This also adds an extra file (which you cannot omit, the others you can mostly omit).

If you're using an alternative esptool + boot loader (like rboot), you can have these segments in one file (and have proper OTA programming as well...)

The reason your addresses "don't add up" is because flash is mapped into the lineair address space of the ESP8266 (with caching added). The ESP does never execute code directly from flash and instead fetches it, caches it in IRAM and executes it there. This last process is transparent, but the fact that the flash memory is mapped into lineair memory space, is something you need to take care of when writing code (although most of it is handled by the compiler and linker, have a look at the loader config file for that).

This mapping has an enormous advantage (which is used by almost nobody). At boot you can select one of four 1 Mbytes area's to be mapped (into the same address range). So it's possible to create four images (versions), using the same addresses and select one of them to be booted at will. This is much simpler than the usual Espressif OTA approach where you need to create separate (and different) images for the same code for different "slots". The only limitation here is that you need at least a 2 Mbytes flash for it to work, so the ESP-01 won't work (or replace the flash chip...). Most other versions come with a 4 Mbytes flash chip anyway.