ADDITIONAL_MAKE_CLEAN_FILES is deprecated and only worked with make.
Replaced with the new ADDITIONAL_CLEAN_FILES (CMake 3.15) which also works with ninja.
1. Fixed crash after controller disable and re-enable
2. Fixed the crash caused by processing the HCI_Read_Remote_Extented_Features command in the non-connected state
3. Fixed disconnection due to not handling lmp_unsniff_req in LC_WAIT_SNIFF_SUB_RSP state
4. Fixed crash caused by supervision timeout greater than sniff interval
Closes https://github.com/espressif/esp-idf/issues/11164
Closes https://github.com/espressif/esp-idf/issues/10835
- As per the memory block diagram for ESP32-S3, the
internal memory address ranges as follows:
DRAM: 0x3FC88000 (== SOC_MEM_INTERNAL_LOW) <-> 0x3FCF0000
IRAM: 0x40378000 <-> 0x403E0000 (== SOC_MEM_INTERNAL_HIGH)
- to acknowledge the unused DCACHE added to DRAM for ESP32-S3
- For ESP32-S3, when the DCACHE size is set to 16 kB, the unused 48 kB is added to
the heap in 2 blocks of 32 kB (from 0x3FCF0000) and 16 kB (from 0x3C000000).
- But, if we try allocating memory from the 16 kB block and run an `esp_ptr_internal`
check on that memory pointer, it fails as the address block from 0x3C000000
corresponds to the external memory symbols SOC_DROM_LOW and SOC_EXTRAM_DATA_LOW.
(E.g. freertos - If the IDLE task stack buffer gets allocated from this region,
the firmware will abort due to this failure).
- Thus, the checks `esp_ptr_internal`, `esp_ptr_in_drom` and `esp_ptr_byte_accessible`
have been updated to acknowledge this memory as a part of the DRAM.
Co-authored-by: Mahavir Jain <mahavir@espressif.com>
Inadequate locking in the esp_timer component allowed corruption
of the s_timers linked list:
1. timer_armed(timer) returns false
2. another task arms the timer and adds it to s_timers
3. the list is locked
4. the timer is inserted into s_timers again
The last step results in a loop in the s_timers list, which causes
an infinite loop when iterated. This change always locks the
list before checking if the timer is already armed avoiding
the data race.
eFuse module has a hardware bug.
It is related to ESP32-C3, C6, S3, H2 chips:
- BLOCK9 (BLOCK_KEY5) can not be used by XTS_AES keys.
For H2 chips, the BLOCK9 (BLOCK_KEY5) can not be used by ECDSA keys.
S2 does not have such a hardware bug.
- While updating to mbedtls release/v3.4.0, building mbedtls/library/psa_crypto.c,
clang produced an unreachable-code warning, so added `-Wno-unreachable-code` compile option for clang.
- In `mbedtls/v3.4.0`, the ECDSA restartable sign and verify functions (`ecdsa.c`) were made public.
- But the `mbedtls_ecdsa_sign_det_restartable` function prototype was declared in the file `ecdsa.h`,
only when `MBEDTLS_ECDSA_SIGN_ALT` was not defined.
- added a patch in mbedtls library to fix it.
