ESP8266 Community Forum

You can free up about 15K of iram0_1 used by the espressif libraries by making a few simple changed to your linker script.
Example: I am using eagle.app.v6.new.2048.ld in my projects
This file is located in the SDK, ld directory

Find these next two lines in your linker script
(they are before two iram1_0_seg sections at the end of the file
} >dram0_0_seg :dram0_0_bss_phdr
/* __stack = 0x3ffc8000; */

Move the one .irom0.text section (at the very end of the file)
to just after the /* __stack = 0x3ffc8000; */ comment above
In my modified version I added libpp. which moved it into irom instead of iram0_1, this saves about 15K of iram - more then all other other libraries combined - the impact to overall speed is still to be determined but it is working for me.

.irom0.text : ALIGN(4)
{
_irom0_text_start = ABSOLUTE(.);
*(.irom0.literal .irom.literal .irom.text.literal .irom0.text .irom.text)
/* you can relocate libraries from ram cache by including them here */
/* gcc hal phy pp net80211 lwip wpa main m */
/* Mike Gore */
*libpp.a:(.literal .text .literal.* .text.*)
_irom0_text_end = ABSOLUTE(.);
} >irom0_0_seg :irom0_0_phdr

Moin,

you are moving code from iram to flash here.
Interrupt called code and flash access code must reside in iram.
How do you know that the code in libpp is neither?

Cal

Hi Mike,

This is super interesting, thanks for posting. I thought I was pretty handy with gcc but I never saw these per-archive linker script options before! There are some dirty tricks in esp-open-rtos that can probably be replaced with this - super handy. Probably time for me to sit down and read the ld manual properly, see what else I've missed.

Like Cal I have some reservations about moving large blocks of code out of iram. As Cal says, if an interrupt handler calls into irom code while SPI flash (irom) mapping is disabled then it will crash.

I'm curious also - what are you doing with the iram that is made available via this technique? Iram can't (easily) be used as data ram (dram), because unlike dram it needs to be accessed via 4 byte aligned word reads.

If the different code that you're placing into iram is called less often than the code you're moving out of iram, you'll have a net performance loss. libpp has code to handle the low levels of the WiFi PHY layer, so some of those code paths are likely to be hit every time the 802.11 radio does something. If the code you're replacing in IRAM is called less often than the WiFi frame handling code, it's a net performance loss.

Nevertheless it's an interesting development - thanks again for posting it. It may be possible to move files out of iram on a more granular level - per-object-file, perhaps. You could even do some profiling of "hot" code paths via the JTAG interface, or via cpu interrupts similar to how the gdb stubs work.

Mike, this seems to be exactly what I'm looking for! I was just abouting asking a question that would accomplish this and I couldn't get my head around.

My problem is this, almost all of my code has the ICACHE_FLASH attribute and comes in the irom0_text segment. There is almost no code in the .text (iram0) segment. Most code is non-timing-critical, so that's good.

Still at some point adding code I run out of the irom_text segment size. When comparing the sizes and symbols of code that does link sucessfully and code that doesn't (the difference is only line...) I see two library symbols included additionally, that have to do with int<->float conversion, so I assume they're from -lm or -lgcc. They're placed in .text AHA! So this is how my .text segment becomes filled.

All kinds of things with conversion are really not timing critical for me (that code is integer only), so I will go and try to get these libs into .irom0_text, just one 1k of extra space would probably suffice.