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.
- Add config to set duplicate scan list refresh period
- overwrite the oldest device infor if the list is full
- Fixed duplicate scan period is not accurate
- Add config to set duplicate scan list refresh period
- overwrite the oldest device infor if the list is full
- Fixed duplicate scan period is not accurate
- Fixed some memory was not released after bluetooth controller initialization failed
- Fixed privacy errorr for directed advertising
- Fixed multiple periodic advertising sync failed in air
- Fixed lld_con.c line 3048 assert
- Fixed crash sometimes when connected as a slave by the 8th device
1 change default TX power to 9 dBm
2 fixed disconnect reason 0x1f (unspecified error)
3 fixed connection timeout due to terminate ind has not been acknowledged
