alex/esp-idf
alex/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf.git synced 2024-10-05 20:47:46 -04:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

MR things

Browse Source
This commit is contained in:
Jeroen Domburg 2017-03-09 19:59:09 +08:00
parent ab5bbfa74b
commit 17a4a2527d
2 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
components/esp32/heap_alloc_caps.c
View File

@ -206,15 +206,15 @@ void heap_alloc_caps_init() {
after the scheduler has started, the ROM stack is not used anymore by anything. We handle it instead by not allowing after the scheduler has started, the ROM stack is not used anymore by anything. We handle it instead by not allowing
any mallocs from tag 1 (the IRAM/DRAM region) until the scheduler has started. any mallocs from tag 1 (the IRAM/DRAM region) until the scheduler has started.
The 0x3ffe0000 region also contains static RAM for various ROM functions. The following lines knocks The 0x3ffe0000 region also contains static RAM for various ROM functions. The following lines
out the regions for UART and ETSC, so these functions are usable. Libraries like xtos, which are reserve the regions for UART and ETSC, so these functions are usable. Libraries like xtos, which are
not usable in FreeRTOS anyway, are commented out in the linker script so they cannot be used; we not usable in FreeRTOS anyway, are commented out in the linker script so they cannot be used; we
do not disable their memory regions here and they will be used as general purpose heap memory. do not disable their memory regions here and they will be used as general purpose heap memory.
Enabling the heap allocator for this region but disabling allocation here until FreeRTOS is started up Enabling the heap allocator for this region but disabling allocation here until FreeRTOS is started up
is a somewhat risky action in theory, because on initializing the allocator, it will go and write linked is a somewhat risky action in theory, because on initializing the allocator, vPortDefineHeapRegionsTagged
list entries at the start and end of all regions. For the ESP32, these linked list entries happen to end will go and write linked list entries at the start and end of all regions. For the ESP32, these linked
up in a region that is not touched by the stack; they can be placed safely there.*/ list entries happen to end up in a region that is not touched by the stack; they can be placed safely there.*/
disable_mem_region((void*)0x3ffe0000, (void*)0x3ffe0440); //Reserve ROM PRO data region disable_mem_region((void*)0x3ffe0000, (void*)0x3ffe0440); //Reserve ROM PRO data region
disable_mem_region((void*)0x3ffe4000, (void*)0x3ffe4350); //Reserve ROM APP data region disable_mem_region((void*)0x3ffe4000, (void*)0x3ffe4350); //Reserve ROM APP data region

7
components/esp32/include/esp_heap_alloc_caps.h
View File

@ -41,9 +41,10 @@ void heap_alloc_caps_init();
/** /**
* @brief Enable the memory region where the startup stacks are located for allocation * @brief Enable the memory region where the startup stacks are located for allocation
* *
* On startup, the pro/app CPUs have a certain stack frame, so we cannot do allocations * On startup, the pro/app CPUs have a certain memory region they use as stack, so we
* in the regions these stack frames are. When FreeRTOS is completely started, they do * cannot do allocations in the regions these stack frames are. When FreeRTOS is
* not use that memory anymore and allocation there can be re-enabled. * completely started, they do not use that memory anymore and allocation there can
* be re-enabled.
*/ */
void heap_alloc_enable_nonos_stack_tag(); void heap_alloc_enable_nonos_stack_tag();