RTC fast memory usage and slow memory size

[abrakada]

Hello. For my application i need about 7-10k of ram memory. It must persist during deep sleep. So, the only way is to place variables into RTC memory. Unfortunately seems there is only 8k of RTC slow memory present in the chip and only half of it (about 4k) available according to linker script esp32.ld.

My questions are

- is it possible to extend rtc_slow_seg(RW) up to 8k, why upper 4k of RTC slow memory are reserved?
- is it possible to put some data into RTC fast memory, so define variables as RTC_IRAM_ATTR? I tried this but for some reason uart log shows me that the chip reboots and second bootloader seems doesn't even started. So, i guess esp32 thinks that my variables which stored in fast RTC memory are "wake up stubs". Is it possible to disable "wake up stubs"? Here is the log

[12:20:16:812] Guru Meditation Error: Core 1 panic'ed (LoadStoreError). Exception was unhandled.␍␊
[12:20:16:820] Core 1 register dump:␍␊
[12:20:16:823] PC : 0x400d2bd9 PS : 0x00060130 A0 : 0x800d3816 A1 : 0x3ffb7aa0 ␍␊
[12:20:16:830] A2 : 0x00000000 A3 : 0x3ffb6f28 A4 : 0x80082705 A5 : 0x3ffb5e80 ␍␊
[12:20:16:837] A6 : 0x3ffb3320 A7 : 0x3ffdfff9 A8 : 0x400c0940 A9 : 0x00000000 ␍␊
[12:20:16:846] A10 : 0x3ffb32ec A11 : 0x3ffb7ab4 A12 : 0x00000014 A13 : 0x3ffb3300 ␍␊
[12:20:16:853] A14 : 0x0000ffff A15 : 0xffffffff SAR : 0x00000020 EXCCAUSE: 0x00000003 ␍␊
[12:20:16:862] EXCVADDR: 0x400c0940 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000 ␍␊
[12:20:16:870] ␍␊
[12:20:16:870] Backtrace: 0x400d2bd9:0x3ffb7aa0 0x400d3813:0x3ffb7ae0 0x400d2c1f:0x3ffb7b00 0x400d2953:0x3ffb7b20 0x4008493a:0x3ffb7b40␍␊
[12:20:16:879] ␍␊
[12:20:16:880] Rebooting...␍␊

[ESP_igrr]

- is it possible to extend rtc_slow_seg(RW) up to 8k, why upper 4k of RTC slow memory are reserved?

The upper 4k are reserved for future use for the Wi-Fi driver. They are unused at the moment, but this may change.

- is it possible to put some data into RTC fast memory, so define variables as RTC_IRAM_ATTR? I tried this but for some reason uart log shows me that the chip reboots and second bootloader seems doesn't even started. So, i guess esp32 thinks that my variables which stored in fast RTC memory are "wake up stubs". Is it possible to disable "wake up stubs"? Here is the log

It is possible, but RTC Fast memory is accessible only by PRO CPU. In the crash dump below you see that APP CPU has attempted to read or write this memory.

[abrakada]

thanks, can i somehow fix it? So, tell app_cpu not to read from rtc fast memory, or run the app only from the PRO_CPU ? Somehow in another way? Are there any plans to encrease size of RTC slow memory in the future?

[ESP_igrr]

app_main function runs from PRO CPU. If you create other tasks, you can use xTaskCreatePinnedToCore function to pin them to PRO CPU.

Expanding the size available to apps to 8k is possible, but I can't give you a timeline, unfortunately.

[mezzynine]

is there a way to access the top 4Kb of the RTC slow memory as it isn't being used by the WiFi driver now? it'd sure be useful . or is it a hardware limitation? thanks.

[boarchuz]

Where did you see that the upper 4k is no longer reserved?

[timmbo]

Hey all,

this thread is 2 years old, but I could not find any information on how to access the upper 4KByte of RTC slow memory. Is there any update on this? I can't use the fast memory because I activated CONFIG_FREERTOS_UNICORE.

Best, Timm

[boarchuz]

That 4k is longer reserved in IDF:
https://github.com/espressif/esp-idf/co ... 99abc570af

You can use RTC_DATA_ATTR macro to place there or access memory at 0x50000000, eg.
https://github.com/espressif/esp-idf/bl ... lp.h#L1041

[timmbo]

That 4k is longer reserved in IDF:
https://github.com/espressif/esp-idf/co ... 99abc570af

You can use RTC_DATA_ATTR macro to place there or access memory at 0x50000000, eg.
https://github.com/espressif/esp-idf/bl ... lp.h#L1041

Cool, thanks for your answer! The change is not yet included in the ESP IDF 4.2, but I guess it will be in the next release -> nice! Until then I will try to implement a workaround (own memory address define).

Best, Timm