I recently put out a question about the RAM in the ESP8266. In a typical compile, for me I might see…
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000894 3ffe8000 3ffe8000 000000e0 2**4
CONTENTS, ALLOC, LOAD, DATA
1 .rodata 0000275c 3ffe88a0 3ffe88a0 00000980 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .bss 00009a80 3ffeb008 3ffeb008 000030e8 2**4
ALLOC
4 .text 00007786 40100000 40100000 000030e8 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .irom0.text 0003ce04 40202010 40202010 0000a870 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
All very confusing. So .irom0.text is FLASH – why they can’t just call it FLASH I’ll never understand. The rest are various kinds of RAM.
.data is used for “initialised” data, i.e. that which needs copying from FLASH on powerup. I’ve used 0x894 in the above example.
.rodata is used read only data – this is in ram (again I don’t understand, if it is read only why it’s not in flash – most likely for speed). I’ve used 0x275c.
.bss is used for variables which are not initiased. I’ve used 0x9a80.
.text is used for CODE that is not in FLASH – i.e. it is in FLASH on powerup – but gets copied to RAM for speed. Sadly due to lack of RAM we usually end up using a directive to put code into FLASH to save space – but REALLY time critical code should be left in RAM. Of course it does get copied into RAM (cacheing) but that could mean execution times which are different first time around – not good for RGB LED lighting etc.
A fellow by the name of Don Kinzer replied and here’s what he had to say.. very useful.
“There are no individual limits for the sizes of .data, .rodata and .bss (but see caveat below). The ESP8266 has 80K of User Ram which is occupied by .data, .rodata, .bss, the stack and the heap. Basically, the space represented by (80K – sizeof(.data) – sizeof(.rodata) – sizeof(.bss)) is used by the heap growing from one end and the stack growing from the other end. If the heap and stack collide bad things will happen (probably an exception, eventually, and a reboot).
The caveat that I mentioned is that the .data and .rodata sections, along with the .text section (itself limited to 32K) must fit in the first 64K of Flash. The sizes of each of these sections is rounded up to an integral multiple of 4 bytes and an additional 8 bytes of overhead are added for each section plus an additional 8 bytes of overhead. Finally, space for the checksum is added (between 1 and 16 bytes) so that the overall size is an integral multiple of 16 bytes. The total of all that must be 64K or less. The image containing all of this data is often called app.v6.flash.bin but the name itself is not important.
As for the limit on the size of .irom0.text, that depends on 1) the size of your Flash chip (commonly 512K but can be 16MB or more), and 2) where you load it into Flash and 3) if you want OTA upgrade or not. For non-OTA upgrade, it is common to load the .irom0.text at 0x40000 but it can be loaded as low as 0x10000. Since the system parameter area exists at 16K from the end of the Flash chip, the size of .irom0.text is limited to sizeof(Flash) – 16K – loadAddress.
If you want to load the (non-OTA) .irom0.text at an address other than 0x40000 you’ll need to modify the linker script accordingly.”