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.
Move the OpenCode companion guide into the ble_uart_service example.
Add English and Chinese Markdown guides with image assets.
Keep ESP-BLE-UART naming consistent across the example and bridge tooling.
(cherry picked from commit 926111e721)
Co-authored-by: Zhou Xiao <zhouxiao@espressif.com>
The WebSocket echo server tests connect immediately after seeing
'Starting server on port:' in the device log, but URI handlers
(/ws, /auth) are registered asynchronously after the server starts,
taking 40-660ms depending on config and CI load.
This causes two failures:
1. WebSocket handshake returns 404 Not Found because the URI
handler is not registered yet when the client connects.
2. WebSocket echo returns wrong data because the server is in a
partially initialized state.
Wait for 'Returned from app_main()' before connecting, which
guarantees all URI handlers are registered. Add connection retry
with WebSocketBadStatusException handling to WsClient.
Extract _wait_for_server_ready() helper to deduplicate the WiFi
credential input and server readiness logic.
(cherry picked from commit 7a50e3ab04)
fix(examples): make https_request rom_impl CI test resilient to transient external server failures (backport v5.5)
See merge request espressif/esp-idf!48417
The binary size (0x100110) slightly exceeds the default 1MB factory
partition, causing a build failure with 0x110 bytes overflow.
Use CONFIG_PARTITION_TABLE_SINGLE_APP_LARGE to provide sufficient
space, consistent with other TLS-based mqtt examples.
The esptool version bundled with the release/v5.5 IDF environment only
accepts the underscore subcommand name 'write_flash'. The hyphenated
alias 'write-flash' is rejected by argparse on this esptool version.
Use the canonical 'write_flash' name accepted by all esptool versions.
The write_time_to_nvs helper is introduced by parent MR !47528's sibling on master
(!47201). On release/v5.5 the parent hasn't merged yet, so this MR's rom_impl test
resilience patch references an undefined name. Include the helper inline here so
pre-commit (ruff F821 + mypy) passes; if the parent's backport (!48415/!48416)
lands first, the merge will need a trivial dedup of this helper.
The test_examples_protocol_https_request_rom_impl test on ESP32-C2 with
the ROM mbedTLS implementation hits a public TLS endpoint
(tls13.browserleaks.com / www.howsmyssl.com) for five sequential
sub-tests. CI runs frequently fail mid-test with one of:
* mbedtls_ssl_handshake returned -0x7780
(MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE - server-side fatal alert)
* esp-tls: [sock=NN] select() timeout
* esp-tls: Failed to open new connection in specified timeout
In a representative log the first three sub-tests succeed and only the
fourth/fifth fail, which is consistent with rate-limiting or transient
server unavailability rather than a device bug. Mark the test as
flaky with up to two reruns (10 s delay) so a single transient remote
failure does not fail the CI job.
Also align this test with the rest of the file by injecting the host
timestamp via NVS (write_time_to_nvs) so the device clock no longer
depends on a previous boot's persisted SNTP result, removing one more
source of CI flakiness on first-boot or after NVS erase.
The test_examples_protocol_https_request_rom_impl test on ESP32-C2 with
the ROM mbedTLS implementation hits a public TLS endpoint
(tls13.browserleaks.com / www.howsmyssl.com) for five sequential
sub-tests. CI runs frequently fail mid-test with one of:
* mbedtls_ssl_handshake returned -0x7780
(MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE - server-side fatal alert)
* esp-tls: [sock=NN] select() timeout
* esp-tls: Failed to open new connection in specified timeout
In a representative log the first three sub-tests succeed and only the
fourth/fifth fail, which is consistent with rate-limiting or transient
server unavailability rather than a device bug. Mark the test as
flaky with up to two reruns (10 s delay) so a single transient remote
failure does not fail the CI job.
Also align this test with the rest of the file by injecting the host
timestamp via NVS (write_time_to_nvs) so the device clock no longer
depends on a previous boot's persisted SNTP result, removing one more
source of CI flakiness on first-boot or after NVS erase.
The esptool version bundled with the release/v5.5 IDF environment only
accepts the underscore subcommand name 'write_flash'. The hyphenated
alias 'write-flash' was added in later esptool releases, so the CI
target test failed with 'argparse.ArgumentError: invalid choice:
write-flash'. Use the canonical 'write_flash' name, which is accepted
by all esptool versions.
