IRAM0 segment data does not fit

[ESP_Angus]

The libbtdm_app.a code in IRAM is because the BT controller needs real-time response, including when the flash cache is disabled (which may happen temporarily when writing to flash, etc.)

Heap code is in IRAM for similar reasons. There are some instances where an allocation may need to occur when flash cache is disabled, by code running in IRAM. I'll see if it's viable for us to make this configurable, but I suspect not. However, 6.5KB seems high - if you've enabled any heap debugging functions (tracing, poisoning) then disabling these will reduce the libheap size (at the expense of not having these functions).

Switching to Release mode is, as you've found, a good option. The main difference is that code may be harder to debug/disassemble in gdb (because the compiler's optimiser has reorganised some of the compiler output in ways which no longer resemble the source code.)

You can also set the assertion level to "Silent". This mostly shrinks the overall binary size, but it should shrink the IRAM usage a little as well. It means that any assertion failure will need decoding using "idf_monitor" or addr2line, as the assertion failure output won't contain any human-readable details, just a code (PC) address.

If you're not using PSRAM, disabling PSRAM support in menuconfig will reduce the IRAM footprint as well (as it allows some ROM functions to be used which otherwise need to be put into IRAM), and reduces the compiled code size as well.

[PeterR]

Thanks for your full answer. I suspected the BLE RT point.

I figure that most people would rather have the IRAM than being able to malloc() when cache is switched off though.
I would at least.
Plus a lot of coding standards won't allow dynamic malloc() so its a well trodden path to allocate at startup only.
FLASH write is in itself quite tricky for the reasons you explain i.e. code must be in IRAM.
But if there is no IRAM left then the user cannot have his FLASH write routine & so heap may as well be configurable as outside IRAM.

Unfortunately I am using PSRAM as well. I will turn poisoning off.

Is there scope for reducing libfreertos.a ? Does the linker strip out unused functions? If not maybe finer grained packaging would help?
If it does strip then maybe I should reduce what I use?
Regards

[ESP_Angus]

I figure that most people would rather have the IRAM than being able to malloc() when cache is switched off though.
I would at least. Will confirm.

The last time we looked into this there was at least one instance where WiFi code may need to malloc() while cache is disabled. Maybe this is no longer the case, but that was the case then.

Is there scope for reducing libfreertos.a ? Does the linker strip out unused functions? If not maybe finer grained packaging would help?
If it does strip then maybe I should reduce what I use?

The linker does strip unused functions (and symbols in general), so if you can remove code from being used then it will link the file size.

There may be some parts of libfreertos which could be moved out of IRAM, however a lot of it is called from contexts where cache is disabled. Also, a lot of FreeRTOS functions are called very frequently - I guess having a program with terrible performance (because all the core OS constructs are constantly cache thrashing) may be better having no program at all, but maybe not.

[PeterR]

Thanks.

The last time we looked into this there was at least one instance where WiFi code may need to malloc() while cache is disabled. Maybe this is no longer the case, but that was the case then.

Would be helpful to understand when & option.
I do not write to IROM which I understand to be the only time Cache would be disabled?
User configurable and guarded with an ASSERT (as often the IDF helpfully does) would be really neat.

I guess having a program with terrible performance (because all the core OS constructs are constantly cache thrashing)

Only if you are scheduling loads and that comes down to your application type.

Plenty of what I do is - package input streams, crunch and forward to another stream. DMA, crunch, DMA.
Scheduling frequency comes down to throughput but plenty of DRAM left so for me is not high.
I do more 'reactive' systems from time to time, so I see your point there.

I don't have the IRAM for either approach & so optioning which behavior goes in IRAM would be cool & especially if all this IRAM use is only to help those who write to FLASH (fit a WINBOND!).

I suppose that the IRAM issue is not a disaster but it would be great to have the better IRAM optioning. IMHO lets forget about those who write to FLASH. Dual boot or something. The ESP FLASH options are really affordable after all.

[ESP_Angus]

Some news you'll be happy with, the WiFi team are currently adding some configuration options to move some "hot" WiFi code paths out of IRAM. If this config selected it will probably lower WiFi performance but it will free some IRAM.

Also, it seems like a configuration option to move heap out of IRAM is possible without any loss of functionality, just a potential loss of allocation performance.

It may be a few weeks before these two changes land on the master branch, though.

I don't have the IRAM for either approach & so optioning which behavior goes in IRAM would be cool & especially if all this IRAM use is only to help those who write to FLASH (fit a WINBOND!).

I suppose that the IRAM issue is not a disaster but it would be great to have the better IRAM optioning. IMHO lets forget about those who write to FLASH. Dual boot or something. The ESP FLASH options are really affordable after all.

It's rare to find an application that doesn't need some kind of persistent storage (NVS, a filesystem, etc), although I'm sure there are some - and you seem to have one.

Supporting writing to a second flash chip (so the first chip can always be mapped to the flash cache) is something we've discussed internally. A lot of customers are sensitive to the additional BoM cost (and additional board space requirement), though. It's still something I hope we can look into sooner or later.

[PeterR]

Thanks. Sound good additions. We are not production until Q2/3 2019 so no hurry.
Heap would be fine, As many, I try to avoid dynamic allocation especially on small footprints.

I agree many/most will have persistent storage, Wifi credentials, BLE pairing etc.
Mostly configuration use cases I think, rare & outside normal operation & therefore some loss of function may be acceptable.

Wonder if suspending user IRAM functions whilst configuring, swapping out the user function from IRAM and replacing with the FLASH writer would be a worth some effort.

Thanks again.

[PeterR]

Been diverted for a few weeks but:

It would be worth trying the following GCC compile/link flags either to the whole project or to selected module:
Compile:

Code: Select all

-fdata-section -ffunction-sections

Link:

Code: Select all

-gc-sections

Enabling sections will allow the linker to remove unused functions. I think that the default is to have sections but worth a try.

[ESP_Angus]

Hi Peter,

The ESP-IDF build system should enable these flags by default, so as long as your project doesn't replace CFLAGS/CXXFLAGS/LDFLAGS then it should be doing this already.

Angus

[jumjum123]

Is there a typo ?
Should it be -fdata-sections
(see s at the end)

[PeterR]

Darn & thanks. I saw that GCC sets by default but thought best to double check.
Scratch that idea then.