I saw an option in sdkconfig about IRAM reservation with a warning disclaimer.
So what is the safest way to reserve a block of RAM (for some global variables I want to store there) and be sure, such a RAM block is "invisible" to C compiler in a sense, that either heap, either stack, either anything dynamically created at runtime, either possibly any of integrated peripheral which needs RAM for proper operation, either bootloader, will never overlap that block?
If I turn that option in sdkconfig how do I obtain a pointer to the start of that block?
What are the advantages/disadvantages of making it in IRAM/RTC_FAST_RAM/RTC_SLOW_RAM ? I didn't find any documentation describing clocking operations on read/writes cycles with timings. How big is that difference in speed among those different rams?
Can all of those memories be accessed with word (2 byte) alignment or only (4 byte) aligned reads/writes?
I saw that ULP writes in RTC ram are always 4 byte aligned and two upper bytes are used to store address of instruction which accessed that location. But if I do not use ULP, are those 2 upper bytes accessible as 16 bits read/writes (avoiding masking on 32 bits read/writes) from PRO/APP CPUs?
What is the safest way of reserving, let's say 1KB of RAM in internal RAM
-
- Posts: 1708
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: What is the safest way of reserving, let's say 1KB of RAM in internal RAM
That's easy (except for the bootloader part).that either heap, either stack, either anything dynamically created at runtime, either possibly any of integrated peripheral which needs RAM for proper operation, either bootloader, will never overlap that block?
All global variables are statically allocated and won't overlap any other memory/variables.
The bootloader is a bit different because it is a separate program from the main application. You may be able to move the RAM used by the bootloader via the linker, but if you want data to survive a reboot RTC RAM is the proper area for that data.
Re: What is the safest way of reserving, let's say 1KB of RAM in internal RAM
Thank you for the answer. So any global variable will be safe from lets say stack flooding etc.
Is there a way to allow, for example, one block of such global data (in IRAM) is available only to PRO core and not accessible for APP core and vice verse or I have to target RTC_FAST_RAM for that? How do you declare some variable telling to C compiler to allocate space for it in lets say RTC_FAST_RAM?
Is there a way to allow, for example, one block of such global data (in IRAM) is available only to PRO core and not accessible for APP core and vice verse or I have to target RTC_FAST_RAM for that? How do you declare some variable telling to C compiler to allocate space for it in lets say RTC_FAST_RAM?
-
- Posts: 1708
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: What is the safest way of reserving, let's say 1KB of RAM in internal RAM
Unfortunately, no.
However on (some?) ESPs hardware support for stack overflow protection can be enabled (via software-set debug watchpoints).
In theory, this should be possible via the Memory Protection Unit (MPU) and hardware-based process IDs, but AFAIK this is not implemented in FreeRTOS/ESP-IDF.Is there a way to allow, for example, one block of such global data (in IRAM) is available only to PRO core and not accessible for APP core and vice verse or I have to target RTC_FAST_RAM for that?
-> https://docs.espressif.com/projects/esp ... low-memoryHow do you declare some variable telling to C compiler to allocate space for it in lets say RTC_FAST_RAM?
Re: What is the safest way of reserving, let's say 1KB of RAM in internal RAM
Thx for that info.
It looks the RTC_FAST_RAM is the best place for those permanently allocated global variables (with the assumptions that sleep modes are not required, ULP (if required) is forced to use RTC_SLOW_MEM, CONFIG_ESP_SYSTEM_ALLOW_RTC_FAST_MEM_AS_HEAP is disabled ). If I understood well, DMA and APP CPU can not access that memory (by design) and stack will never be allocated there.
It looks the RTC_FAST_RAM is the best place for those permanently allocated global variables (with the assumptions that sleep modes are not required, ULP (if required) is forced to use RTC_SLOW_MEM, CONFIG_ESP_SYSTEM_ALLOW_RTC_FAST_MEM_AS_HEAP is disabled ). If I understood well, DMA and APP CPU can not access that memory (by design) and stack will never be allocated there.
Who is online
Users browsing this forum: Google [Bot] and 123 guests