Move 7 trace-related examples (app_trace_basic, app_trace_to_plot,
esp_trace_custom_library, function_tracing, gcov, sysview_tracing,
sysview_tracing_heap_log) from examples/system/ into a dedicated
examples/system/tracing/ subdirectory for better organization.
Update all path references across documentation (en + zh_CN),
build-test-rules, CI configs, Kconfig, and component READMEs.
Keep legacy ULP apps on the CMake v1 build path while buildv2 coverage
is limited to full_subproject ULP apps.
Also add the missing esp_driver_gpio dependency to the esp_pm test app
so buildv2 dependency checks see driver/rtc_io.h explicitly.
Add examples/system/ulp/lp_core/build_system_v2/ demonstrating the
cmakev2 ULP build with native IDF component support, Kconfig
integration, component manager usage, linker scripts (static and
ldgen-processed), and per-project menuconfig.
The example shows a custom ULP project (via ulp_add_project) structured
as a proper IDF-like project with a main component and
idf_build_executable(). The ULP sub-project runs its own kconfgen with
the parent's sdkconfig as SDKCONFIG_DEFAULTS, inheriting the parent's
IDF configuration while adding ULP-specific Kconfig options from its
own components.
Three components demonstrate different integration mechanisms:
- ulp_sum and ulp_math: pure cmakev2 components in the components/
subdirectory, using add_library(${COMPONENT_TARGET}) directly.
Each provides a Kconfig file with configurable options.
- ulp_clamp: an external component in the extra/ subdirectory,
declared as a local path dependency in ulp_sum/idf_component.yml.
The component manager resolves this dependency automatically.
ulp_clamp also provides a Kconfig file with a configurable
maximum clamp value (CONFIG_ULP_CLAMP_MAX_VALUE).
Linker script support is demonstrated in two ways:
- Static linker script: ulp_math registers ulp_math_sections.ld via
idf_component_set_property(LINKER_SCRIPTS), defining a custom
linker symbol (ulp_math_version).
- ldgen-processed template: ulp_math provides a linker fragment file
(ulp_math.lf) that describes a custom .ulp_math_fast section
placement. The main component registers ulp_sections.ld.in via
target_linker_script(PROCESS), which ldgen processes using the
fragment to generate the final linker script. The
ulp_math_multiply() function is placed in .ulp_math_fast using
__attribute__((section)). Both static and ldgen linker scripts
are handled by the standard idf_build_library() flow without any
ULP-specific linker script functions.
The ULP project has its own sdkconfig.defaults that overrides the
ulp_clamp default (100 instead of 255), demonstrating per-project
configuration layering. Users can append to SDKCONFIG_DEFAULTS
before include(idf.cmake) to add project-specific defaults.
A menuconfig-<app_name> target is registered in the parent build,
allowing ULP-specific configuration via:
idf.py --no-hints menuconfig-ulp_build_system_example
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
pytest_gcov hardcoded `__idf_<component>.dir/` as the per-component CMake
intermediate directory where each .gcda is expected to land. The directory
name is build-system specific (Build system v1 uses `__idf_<component>.dir`,
Build system v2 uses `_idf_<component>.dir`). Asserting on a single literal
made every test_gcov_uart run fail under Build system v2 even though the
chip was streaming valid coverage data and the host-side UartGcovCapture
was writing the files to the build's actual layout.
Probe `CMakeFiles/*_<component>.dir/` and prefer the candidate whose .gcno
files were emitted by the active build, so the assertion follows the build
output rather than dictating it.
ESP32-C2 and ESP32-C61 have no RSA based Secure Boot V2 support, so the
CI configs that pin the RSA signing scheme and key fail the app signing
scheme/key check on these targets.
- flash_enc_wifi_2.data_partition_verification: add C2/C61 sdkconfig
overlays that switch to the ECDSA P-256 signing scheme and key (no
force-enable needed as Secure Boot V2 itself is not enabled here).
- on_update_no_sb_rsa: disable the build on targets without
SOC_SECURE_BOOT_V2_RSA, mirroring simple_ota_example, since this
config specifically exercises the RSA scheme.
fix(mmap): fixed mmap read data wrong when flash being erased/written and cache not disabled
Closes IDFGH-14084
See merge request espressif/esp-idf!29804
Address these:
lock_example.c:162:60: error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
162 | xTaskCreatePinnedToCore(inc_num_mutex, NULL, 4096, (void *)thread_id, TASK_PRIO_3, NULL, tskNO_AFFINITY);
| ^
create_task_example.c:30:19: error: cast from pointer to integer of different size
[-Werror=pointer-to-int-cast]
30 | int task_id = (int)arg;
ESP_FAULT_ASSERT(C) was silently deleted by the optimizer when C is a cached
flag/status already proven by a preceding `if (!C) return/goto`: the compiler
folds C to a constant and drops all three checks, removing the fault-injection
protection with no warning.
Before:
The cache won't be disabled when XIP on psram. But during flash
erasing/programming, read data will be courrupt.
When XIP in psram is enabled, the image is not mapped to the cache so
usually there will be no flash access. The only way to read from flash
is via the driver or use mmap. The driver has protection during erasing,
while th mmap region not.
Now:
Mmap APIs provide a flag to make mmap->unmap region mutually exclusive
to flash erase/programming when XIP from psram. SPI Flash write APIs
will benefit from this. When the flag is used, no concurrent access to
mapped region will happen while writing; otherwise the cache will be
disable to avoid data corruption.
Most ESP-IDF APIs calls mmap with this flag. As for users calling
mmap-like APIs directly, they can choose whether to enable this by a
flag.
Closes https://github.com/espressif/esp-idf/issues/14897
ESP32-C2 and ESP32-C61 have no RSA based Secure Boot V2 support
so the virt_sb_v2_and_fe configs cannot use the default RSA signing key.
Add target-specific sdkconfig overlays that switch to the ECDSA P-256 key;
on ESP32-C61 the ECDSA scheme must additionally be force-enabled
SECURE_BOOT_V2_ECDSA_INSECURE).
ECDSA based Secure Boot V2 is not functional for certain input vectors on
ESP32-C5/C61/H2/P4 and on the preview targets ESP32-H4/H21. RSA based Secure
Boot V2 is the recommended scheme where the SoC supports it. This issue will be
fixed in a future hardware ECO revision; more details will be shared through the
hardware errata document.
A new hidden Kconfig option SECURE_BOOT_V2_ECDSA_INSECURE marks the affected
mass-production SoCs (ESP32-C5/C61/H2/P4). On these SoCs, when hardware Secure
Boot V2 is enabled, the ECDSA (V2) signing scheme is no longer offered by
default; it must be turned on explicitly via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
under "Allow potentially insecure options" (CONFIG_SECURE_BOOT_INSECURE). App
signing without hardware Secure Boot is not affected. Note that ESP32-C61 has no
RSA based Secure Boot V2, so it has no Secure Boot scheme enabled by default.
The preview targets ESP32-H4 and ESP32-H21 mark ECDSA Secure Boot V2 as not
supported in their SoC capabilities instead of using the option above. As
ESP32-H4 has no other Secure Boot V2 scheme, Secure Boot is disabled entirely on
it; ESP32-H21 retains RSA based Secure Boot V2.
The security documentation keeps the ECDSA Secure Boot V2 content visible and
adds a warning describing the limitation (including that ECDSA Secure Boot V2 on
ESP32-C61 is not recommended for production). CI apps that exercise ECDSA Secure
Boot V2 on the affected SoCs set CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
accordingly.
