The Xtensa load/store handler did not properly handle 8/16-bit
memory access to IRAM regions configured with MALLOC_CAP_IRAM_8BIT
(and CONFIG_ESP32_IRAM_AS_8BIT_ACCESSIBLE_MEMORY=y) from a loop
(LBEG/LEND/LCOUNT) context. This caused the loop to exit after
the first access, instead of continuing to iterate as intended.
Closes https://github.com/espressif/esp-idf/issues/14127
If Task WDT is initialised but not start, the call to esp_timer_stop() in
the reconfigure path returns ESP_ERR_INVALID_STATE and reconfiguring the
Task WDT fails. This isn't the case when the Timer Group is used for Task
WDT.
(This failure cascades into the failure due to disabled interrupts, fixed
in the parent commit.)
Signed-off-by: Angus Gratton <angus@redyak.com.au>
- Failures were being masked as function always returned ESP_OK
- In the failure path the spinlock was not unlocked, so interrupts
became permanently disabled.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
The ULP sources include sdkconfig.h for compile-time configuration
values. The sdkconfig directory was previously available to the ULP
target indirectly through the COMPONENT_INCLUDES variable, which is
populated from the parent component's INTERFACE_INCLUDE_DIRECTORIES.
In cmake v1, idf_component_register() adds the config_dir as PUBLIC
include directory to every component (component.cmake:498), so it
ends up in INTERFACE_INCLUDE_DIRECTORIES and gets passed to the ULP
subproject via COMPONENT_INCLUDES.
In cmakev2, the config_dir is added as a build-level property and
applied to components as PRIVATE (component.cmake:1053), so it no
longer appears in INTERFACE_INCLUDE_DIRECTORIES. As a result, the
sdkconfig directory is missing from the ULP target's include paths.
Add the sdkconfig directory explicitly to the ULP target's include
directories. Note that SDKCONFIG_HEADER is already passed to the ULP
subproject and its directory is already extracted into sdkconfig_dir
for linker script preprocessing (IDFULPProject.cmake:40).
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
CMakev2's DEFERRED mode for idf_component_optional_requires only links
optional components already present in the dependency graph. This caused
esp_coex headers to be unavailable when building minimal examples on
targets with both WiFi and IEEE802154 (e.g. esp32c5, esp32c6).
Moving init_coexist to esp_coex removes the cross-component dependency
and ensures the init function is only compiled when esp_coex itself is
part of the build. A linker hook is added to guarantee the object file
is not silently discarded by the linker.
Made-with: Cursor
This commit updates the dependencies list for the esp_wifi component
when compiled for non-WiFi targets. The reason for this change is
because cmakev2 explicitly includes the esp_wifi component even on
non-WiFi targets leading to compilation errors due to missing
dependencies.
In cmakev2, a component can be evaluated within the context of another
component, so it's important to properly initialize each variable used
by the component.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
For Build System v2 on linux target, esp_timer dependency must be
conditional on CONFIG_LWIP_IPV4 rather than checking BUILD_COMPONENTS.
v2 uses configuration-driven dependencies.
For Build System v2 on linux target, lwip dependency and ESP_TLS_WITH_LWIP
definition must be conditional on CONFIG_LWIP_ENABLE rather than checking
BUILD_COMPONENTS. v2 uses configuration-driven dependencies.
When CONFIG_APP_BUILD_TYPE_RAM is set (loadable ELF app build),
bootloader_support was adding micro-ecc to priv_requires. The micro-ecc
component lives in the bootloader subproject and is not available in
normal app builds with cmakev2, causing component resolution to fail
when built for a build system v2 project.
micro-ecc is only needed for secure boot sources built under
BOOTLOADER_BUILD (secure_boot_signatures_bootloader.c). For app builds
with CONFIG_APP_BUILD_TYPE_RAM we do not build those sources, so
only add micro-ecc to priv_requires when BOOTLOADER_BUILD is set.
In cmakev1, the initial order of components linked to the executable is
determined by the `__build_expand_requirements` function and stored as a
list in the `BUILD_COMPONENT_ALIASES` build property. Later, the
components from `BUILD_COMPONENT_ALIASES` are linked to the executable
using `target_link_libraries`. The issue is that
`BUILD_COMPONENT_ALIASES` contains components in a "reversed" order
compared to how they would typically appear on the link command line. In
other words, components (archives) deeper in the dependency chain are
placed first. As a result, cmake has to repeat the archives in the link
command more times than is actually necessary. This has the beneficial
side effect of placing libfreertos.a before libmain.a, allowing the
`app_main` symbol to be resolved.
In cmakev2, there is no predefined order because it does not perform
early evaluation. Instead, the entire link command is created based on
actual component dependencies using `target_link_libraries`.
Consequently, freertos must set the `app_main` symbols as undefined.
This is already done for non-Linux targets, but it must also be done for
the Linux target.
Another issue arises with macOS, which mangles C symbols by prepending
an underscore. We cannot use the same method as in
`components/linux/assert_func.c` for `__assert_func`, so for macOS,
`_app_main` is used. In the future, if more undefined symbols need to be
added for the Linux target, we should consider introducing a helper.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
In cmakev2, the configuration for all components is included because the
complete configuration is generated very early, before any component is
actually evaluated. This poses a problem for the Linux target, which
does not have a controller Kconfig.in file, causing kconfgen to fail due
to the missing include. To address this, let's use the osource command,
which does not include the referenced Kconfig file if it does not exist.
Closes https://github.com/espressif/esp-idf/issues/18142
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The `srcs` list variable is used without initialization when building
for linux target. Initialize it explicitly.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The `srcs` list variable is used without initialization when building
for linux target. Initialize it explicitly.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
PONG frames (opcode 0xA) were never dispatched to the user's WebSocket
handler despite an existing comment stating they should be. The dispatch
condition `ra->ws_type < HTTPD_WS_TYPE_CLOSE` excluded PONG (0xA)
since CLOSE is 0x8.
This caused a critical secondary bug: when the server sends PING frames
and the client responds with PONG, httpd_ws_recv_frame() is never
called for the PONG, leaving the remaining frame bytes (second_byte
plus 4-byte mask_key) unconsumed in the TCP buffer. On the next
WebSocket read, these orphaned bytes are misinterpreted as a new frame
header, causing either "WS frame is not properly masked" errors or
EAGAIN timeouts with garbage length values, effectively destroying
the connection.
Add `ra->ws_type == HTTPD_WS_TYPE_PONG` to the dispatch condition so
PONG frames reach the user handler, which calls httpd_ws_recv_frame()
to properly consume the frame bytes from the socket.
Closes https://github.com/espressif/esp-idf/issues/18227
In auth_sae_queue(), when wpa3_hostap_post_evt() fails, the queued
entry was left on the list and never freed. This leaks memory under
SAE commit floods or when the event queue is full.
Free the entry and remove it from the list on post failure.
The existing spinlock mechanism possibly has an overlap of memory
operations during multi core execution, as visible in CI testing. When
running the example inter_cpu_critical_section, shared count increment
stops at 299999 instead of reaching 300000, but this only happens
randomly 1 out of 10 times. It is suspected that a memory operation
happens simultaneously from both core, even though spinlock protection
is in place.
To handle this problem, a memory barrier (fence instruction) is added
at critical places during spinlock acquire and release, to ensure that
all memory operations upto that point are completed and synchronised
before proceeding further.
Jin Cheng
muhaidong
Song Ruo Jing
Konstantin Kondrashov
tarun.kumar
Jiang Jiang Jian
Angus Gratton
igor.udot
Sumeet Singh
C.S.M
Frantisek Hrbata
Marius Vikhammer
Sudeep Mohanty
Peter Backeris
Li Shuai
Ashish Sharma
Laukik Hase
Chen Yudong
Sarvesh Bodakhe
yanzihan@espressif.com
yangfeng
Meet Patel
armando
Alexey Lapshin
cjin
Chen Jichang
Liu Linyan
luoxu
morris