When stack check is enabled, certain functions (sometimes placed in RAM)
are being decorated with stack guards and a call to __stask_chk_fail() in
case ofr stack corruption. For this reason, __stack_chk_fail() must be
placed in RAM too.
Add stack check config in heap tests on all targets to find eventual flash to RAM
calls due to stack checks when running callgraph_check.py
The tlsf now checks for size validity when creating a new heap.
The check previously done in multi_heap_register_impl() is no longer
valid since the tlsf_size() is not known at this time (as the metadata
size is linked ot the size of the memory region passed as parameter
when calling tlsf_create_with_pool())
The tlsf_create_with_pool() will return a null pointer if the size
of the memory is not big enough to hold the metadata overhead and
at least a small block.
Update the test according to the changes in TLSF API
On xtensa architecture, the call to __assert_func uses a reference to __func__ that can
sometimes be placed in flash. Since the __asert_func can be called from functions in IRAM
the check_callgraph script can report an error when checking for invalid calls from IRAM
to flash sections. However, the __asert_func prevents this scenario at runtime so the
check_callgraph script reports a 'flas positive' situation. For this reasson, all references
to __func__$x found prior to a call to __assert_func are droped in the parsing of the rtl files.
this commits:
- adds build-time test to check that no call to flash regions are done from IRAM functions
- resolves problems related to IRAM function using content in flash memory
- update heap_caps_alloc_failed to use a default function name in DRAM
when necessary instead of creating a function name variable in DRAM for
each call of heap_caps_alloc_failed. This allows to save some extra bytes
in RAM.
This commits adds a internal.md file in the heap directory to clarify the idea behind
which functions is placed in IRAM or in flash.
A section in mem_alloc.rst documentation is added to specify which functions from the
heap component API can be used in interrupt handlers.
This commit aims to place in the IRAM section only the functions that
are relevent for performance instead of placing the entire content of
multi_heap.c, mullti_heap_poisoning.c and tlsf.c in the IRAM.
The existing tests detect errors in the internal interface (eg. parttool read-write functions) and did not check for any possible breakages in the args parsing of the parttool commands.
Importing esptool in wrappers could cause importing the wrapper itself.
Updating the PATH is not reliable. For example, os.path.realpath()
changes the Windows driver letter to uppercase therefore, misses the
right path for users with small device letters in their PATH. Removing
paths without considering cases could also lead to errors.
This fix invokes esptool scripts as modules without the need to
importing them.
Closes https://github.com/espressif/esp-idf/issues/9861
Closes https://github.com/espressif/vscode-esp-idf-extension/issues/791
All the partition handling API functions and data-types were moved from the 'spi_flash' component to the new one named 'esp_partition'. See Storage 5.x migration guide for more details
Previous the console doc is moved from api-guide to api-reference, which
broken the URL as well, this commit added a redirect link to ensure the
old URL can still work.
