ESP8266 Community Forum

- Tue Jul 21, 2015 11:50 am #23840 It's even more confusing if you look at the linker script.

Code: Select all[code]MEMORY
{
  dport0_0_seg :                        org = 0x3FF00000, len = 0x10
  dram0_0_seg :                         org = 0x3FFE8000, len = 0x14000
  iram1_0_seg :                         org = 0x40100000, len = 0x8000
  irom0_0_seg :                         org = 0x40240000, len = 0x3C000
}[/code]

iram1_0_seg is at 0x40100000, irom0_0_seg is at 0x40240000, which means the iram1_0_seg size = 0x140000. I am trying to figure out where the 0x40000 comes from...

esptool.py calculates it as the start address of the irom segment (= 0x40240000) minus 0x40200000 which indeed yields 0x40000. But the logic behind it??? 0x40200000 would be the start of the flash mapping within the esp8266, according to the memory layout map from the wiki.

The only rationale I can think of is that the irom_text is actually always programmed into the second half (> 256k) of the flash. Which would contradict everything I read about it (using the "eagle.app.v6.ld" script).

- Tue Jul 21, 2015 12:04 pm #23843

You say mapping is linear, but can you explain then, why the first file is written to 0x00000.bin and the second one to 0x40000.bin, while the room (at that point still in flash) available for iram is only 32k (= 0x8000). It would be logical that the second file would be flashed to 0x8000, but it's not, it's flashed to 0x40000, leaving an unused gap of 224 k.

If you use the default linker script, yes. But, for example, nodeMCU build produces binaries that go to FLASH at offsets 0x00000 and 0x10000. AFAIK the FLASH space between 0x8000 and 0x40000 is not used by the SDK, still I'm not sure why it's done that way by default. Maybe for the compatibility with OTA layout (https://github.com/esp8266/esp8266-wiki ... a-upgrades).

Also, it's not only the IRAM image that goes to FLASH at 0, DRAM segments also go there. And also there's 64K of IRAM, of which we usually see only 32K.

- Tue Jul 21, 2015 12:10 pm #23845 I was just examining the (default) linker scripts, one more time. It's indeed very interesting.

eagle.app.v6.ld org = 0x40240000
eagle.app.v6.old.512.app1.ld org = 0x40211000
eagle.app.v6.old.512.app2.ld org = 0x40251000

So apparently you CAN go lower than 0x40000. I am going to try this, looks promising.

- Tue Jul 21, 2015 12:17 pm #23846

But, for example, nodeMCU build produces binaries that go to FLASH at offsets 0x00000 and 0x10000.

BTW, ArduinoIDE also is producing binaries at offsets 0x00000 and 0x10000.