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.
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
bugfix: Fixed the crash of LoadProhibited caused by invalid operation on list node in handling hci_hardware_error event (v4.3)
See merge request espressif/esp-idf!23119
1. wifi_mesh: fix the heap corrupt issue in MTXON task
2. Update tx rate when phymode change from LR to 11N
3. wifi_mesh: Fix several bugs on mesh network
1. Disable SA query timers when station disconnect and other SA query related improvements
2. Send appropriate reason code in 4 way handshake failure
3. Send deauth while going from assoc state to init, if reason is assoc timeout
* Update submodule: git log --oneline a7abf28e02282b32479f4bbaf2d90f09d2a60f4c..6bb132e3797d5449a923804c75c57d458920f8ac
Detailed description of the changes:
- tcp_in/ooseq: Fix incorrect segment trim when FIN moved (esp-lwip@6bb132e3)
- api_msg: fix tcp_abort thread safety (esp-lwip@53a6e019)
When the virt efuse mode is on and psram is on as well
then efuse buffer is not filled by efuses (it is filled by 0).
So the psram init func gets wrong pkg_ver = 0.
Closes https://github.com/espressif/esp-idf/issues/10925
Close IDFGH-9576
When release sdkconfig is set, substract_poison_overhead() is not inlined
and called from IRAM in multi_heap_get_allocated_size(). By wlways inlining
substract_poison_overhead(), we assure that this problem will not happen.
heap: Fix erroneous value returned by heap_caps_get_allocated_size() when poisoning is enabled (backport v4.3)
See merge request espressif/esp-idf!22190
This commit adds a workaround for the TWAI listen only mode errata which is
present on the ESP32, ESP32-S2, ESP32-S3, and ESP32-C3. twai_get_status_info()
has also been updated to account for the fact that TEC/REC are frozen in
listen only mode.
Errata Description:
When the TWAI controller is put into listen only mode, it should not influence
the TWAI bus in any way (i.e., should never send a dominant bit). However,
on the targets listed above, the TWAI controller will send dominant bits in an
error frame (i.e., active error frame), even if the controller is set to listen
only mode.
Workaround:
We can force the TWAI controller into the error passive state on startup (by
setting the REC to >= 128). Since the TEC/REC are frozen in listen only mode,
the TWAI controller will remain error passive and only send recessive bits
(i.e., passive error frames), thus will not influence the TWAI bus.
Closes https://github.com/espressif/esp-idf/issues/9157
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.
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.
The calculation of fl index max is changed to always be the smallest
number that includes the size of the registered memory.
The control_construct() function now checks for minimum size as the control structure
parameters are calculated.
There is no longer a minimum configuration for fl index max so the tlsf_config
enum is striped down to remove unecessary compile time values.
the tlsf_size() function will fail if no tlsf pointer is passed as parameter since there
is no way to calculate a default tlsf size anymore.
bitfields are now used in control_t when possible which reduces the size of the structure
from 56 bytes to 36 bytes.
When SECURE BOOT V2 is enabled and CONFIG_SECURE_BOOT_SIGNED_BINARIES
is not set, sector-pad the bootloader image, which is required for an
external PKCS#11 interface to generate a signature.
esptool_py: Update submodule to release/v3 (4bc311767b7c6df41def6f95a50f87b1c9406cbd)
Before this fix, when we call esp_pm_configure after gpio_wakeup_enable,
the configuration of GPIO in sleep state in gpio_wakeup_enable will be
overwritten by esp_pm_configure.
mktime function uses tm_isdst member as an indicator whether the time
stamp is expected to be in daylight saving time (1) or not (0).
FAT filesystem uses local time as mtime, so no information about DST
is available from the filesystem.
According to mktime documentation, tm_isdst can be set to -1, in which
case the C library will try to determine if DST was or wasn't in
effect at that time, and will set UTC time accordingly.
Note that the conversion from UTC to local time and then back to UTC
(time_t -> localtime_r -> FAT timestamp -> mktime -> time_t) does not
always recover the same UTC time. In particular, the local time in the
hour before DST comes into effect can be interpreted as "before DST"
or "after DST", which would correspond to different UTC values. In
this case which option the C library chooses is undefined.
Closes https://github.com/espressif/esp-idf/issues/9039
Originally reported in https://github.com/espressif/arduino-esp32/issues/6786
1. fix ftm timer macro issue
2. send null data when state change from association to run
3. bugfix for optimize abnormal beacon log
4. bugfix RSNXE related changes
5. send ftm frames immediately
6. fix ftm procedure with peer failed status 4 issue
For Secure Boot v2 case, unsigned image is first padded to next 64K
aligned boundary and then a signature block of 4K gets appended. Thus
an app partition whose size is 4K aligned should be allowed here.
For Secure Boot v1 case, app partition size must be 64K aligned as the
signature block lies at the very end of 64K boundary.
Relevant:
57b601ab7f
- If internet connectivity weakened or disappeared suddenly while we were
in the TLS handshake stage, the app got stuck at that point indefinitely.
- This was because when timeout was not explicitly specified in esp_tls_cfg_t,
the default timeout was set at the wrong place. This causes the sockets to be
setup with zero timeout, hence the indefinite wait.
