esp_hw_support: Fix invalid system time if s_esp_rtc_time_us & s_rtc_last_ticks were moved around
Closes IDFGH-7930
See merge request espressif/esp-idf!23030
The commit fixes the case:
If variables in RTC RAM have been moved around by the linker,
they will be filled with garbage data. Any reset other than OTA would work fine
because the variables would still be initialized from the initial bootup.
So now system time will be valid even after OTA.
Closes https://github.com/espressif/esp-idf/issues/9448
- Remove the size limit for the hash_map array from the CONFIG_HEAP_TRACE_HASH_MAP_SIZE
- Add test case for heap tracing using hashmap
- Update heap_debug.rst to document the newly added configurations in the heap component
Closes https://github.com/espressif/esp-idf/issues/11172
Add test configuration to run all tests with heap component in the flash.
Add reference to this new configuration in performance section of the documentation.
- and place all added functions and vairables related to the hashmap in RAM
when the config is enabled only.
- add number of hash map entry as a Kconfig value and remove the hash map init function.
This prevents the user from allocating the hash map in flash and pass the pointer to the
init function (as the heap trace manipulate the hash map from functions placed in IRAM).
- add max linear value to the KConfig to make it configurable by the users.
- protect access to static variable "tracing"
- remove unecessary field in heap_trace_hashmap_entry_t
- Fix "test get allocated size"
- Add tests for the free / alloc hooks
- Call alloc function hook on malloc/realloc/calloc base functions
- Add caps parameter to the allocation hook function
After heap_idf.c has been added (where the FreeRTOS heap is a subset of the
ESP-IDF heap), xPortGetFreeHeapSize() was updated to only returns the free
size of the FreeRTOS heap and not the entire ESP-IDF heap.
This commit replaces calls of xPortGetFreeHeapSize() with
esp_get_free_heap_size() in places outside of FreeRTOS.
- Call TAILQ_INSERT_TAIL in linked_list_setup to add unused records from the tail of the list
- Fix test "heap trace leak check" to expect that after a free, the record is zeroed instead of checking that
the whole list of records is moved by one index in the array.
- Use esp_rom_printf() under lock instead of printf() since it does not rely on interrupts.
When light (or comprehensive) poisoning is enabled, the size requested by the user for allocation
is extended by a few bytes to store the canary header and footer. heap_caps_get_allocated_size() should
return the original size asked by the user (without the additional canary bytes).
test_malloc.c extended with a new test assuring that heap_caps_get_allocated_size() returns the proper size
regardless of the degree of poisoning.
If memory protection is enabled on esp32c3 and esp32s3, we don't want to the heap component to see
the startup stack memory as D/IRAM but as DRAM only. Introduce a new type to make this possible in
the same fashion the regular D/IRAM regions are handled.
Check that when trying to allocate in IRAM with the system memory protection enabled,
null pointer is returned, or that an address in IRAM is returned if the memory protection
is disabled.
Since DRAM and IRAM are superposed on esp32c6 it is not necessary to convert a freshly allocated
DRAM addr to its IRAM equivalent when MALLOC_CAP_EXEC is passed to heap_caps_malloc(). Instead,
proceed with a default allocation since the address returned by multi_heap_malloc() already belongs
to the IRAM region.
Applies for esp32c6 and every boards with superposed DRAM and IRAM addresses.
Added statistics and wear simulation functions to support migration of
remaining storage related host tests from fixture to linux implementation
of esp_partition.
when CONFIG_ESP_SYSTEM_PMP_IDRAM_SPLIT is not set, the PMP rule for esp32c2 shoud allow write access.
Fix esp_cpu_configure_region_protection() in cpu.c accordingly.
Note: the checks for the tests marked as [test-dump] are done in the pytest function
test_heap_trace_dump() since they are relying on the content of the heap_trace_dump_caps()
output.
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
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.
- When PSRAM is enabled, the heap integrity check APIs
(`heap_caps_check_integrity` and `heap_caps_check_integrity_all`)
take more time to execute and keep the interrupts disabled for a
longer time.
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
- update the target and host tests to consider the new TLSF api and the metadata size
only when the target is not using the rom implementation of the TLSF
Previously, condition_4 was making impossible the valid scenario
start > heap_start && end == heap_end.
Now, the end == heap_end and start == heap_start case is handled
separately allowing the case start > heap_start && ned == heap_end
to be considered a valid scenario
