mbedtls 4.x is PSA-first: CONFIG_MBEDTLS_SHA256_C now maps to
PSA_WANT_ALG_SHA_256, and on ESP targets the hardware SHA accelerator
serves SHA-256 through PSA, leaving the legacy MBEDTLS_SHA256_C builtin
macro undefined. The inner guard on pbkdf2_sha256 was gating on bare
MBEDTLS_SHA256_C, so the function was compiled out and NAN ND-PMK
derivation (nan_derive_nd_pmk_from_passphrase) failed to link.
Guard on (MBEDTLS_SHA256_C || PSA_WANT_ALG_SHA_256) to match the idiom
already used elsewhere in the supplicant mbedtls port (tls_mbedtls.c),
covering both the legacy builtin and PSA-provided SHA-256.
Add a Unity test case that arms only ANA_CMPR_CROSS_POS (resp. only
ANA_CMPR_CROSS_NEG) on a unit and asserts that a real transition of
the matching direction fires the callback exactly once, while a
transition of the opposite (never-armed) direction does not fire at
all.
This closes a gap in the existing test_apps: none of the current
cases isolate cross direction, so a swapped POS/NEG interrupt mask in
the LL layer (fixed in the previous commit) previously went
undetected.
On the scan-based comparator IP (ESP32-H4/S31), a crossing is only
sampled/latched when a scan is explicitly triggered, so the new test
case also triggers a scan after each level change on that IP, plus
one extra priming scan right after enabling the unit so the internal
compare state starts in sync with the already-set initial GPIO level.
Signed-off-by: Tiago Medicci <tiago.medicci@espressif.com>
In components/soc/esp32c5/register/soc/gpio_ext_struct.h (ESP32-C5),
components/soc/esp32c61/register/soc/gpio_ext_struct.h (ESP32-C61),
and components/soc/esp32p4/register/hw_ver3/soc/gpio_struct.h
(ESP32-P4), the analog comparator raw/status/enable/clear register
fields are named comp_neg_0_*/comp0_neg_* for bit 0 and
comp_pos_0_*/comp0_pos_* for bit 1, but each field's own comment says
the opposite: bit 0 is documented as "analog comparator pos edge
interrupt raw/status/enable/clear" and bit 1 as the "neg" counterpart.
The LL masks were defined from the field names rather than from this
documented behavior, so ANALOG_CMPR_LL_POS_CROSS_INTR_MASK() ended up
selecting bit 1 and ANALOG_CMPR_LL_NEG_CROSS_INTR_MASK() bit 0.
A new test case, added in the following commit, arms only one cross
direction at a time and checks that a matching transition fires the
callback while the opposite, never-armed direction does not; without
this fix it reproducibly fails on ESP32-C5, ESP32-P4, and ESP32-C61.
Signed-off-by: Tiago Medicci <tiago.medicci@espressif.com>
Use the full rodata page range when converting flash physical addresses back to cache addresses for XIP PSRAM. RISC-V extram stack coredump tests are temporarily skipped in CI until coredump supports PSRAM task stacks (IDF-15623).
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
Restore the use_secure_element field in esp_tls_cfg_t, esp_tls_cfg_server_t
and httpd_ssl_config_t, and esp_transport_ssl_use_secure_element(), as
deprecated no-ops so that existing code keeps compiling. Setting them now
fails at runtime with ESP_ERR_NOT_SUPPORTED, as the feature is accessed
via the esp_key_config_t interface. To be removed in the next major release.
No compile-time deprecation attribute on this release branch; the field and
function stay warning-free here and carry only documentation notes.
- fixed identification of blob parts to be cleaned by using right starting chunk index
- improved localisation of blobs for cases where some of pages get reclaimed
- created host test cases covering the edge cases above
WL_Flash::write() and WL_Flash::read() computed:
uint32_t count = (size - 1) / this->cfg.wl_page_size;
`size` is `size_t` (unsigned). Neither the public wl_write()/wl_read() API
(wear_levelling.cpp), nor the newer wl_bdl_write()/wl_bdl_read() block-device
path (wl_blockdev.cpp), reject size == 0 before calling into WL_Flash, and
wear_levelling.h does not document size == 0 as invalid (a 0-byte
write/read is a reasonable no-op, mirroring POSIX write()/read() with
count == 0).
When size == 0, `size - 1` wraps around to SIZE_MAX, so `count` becomes an
enormous page count instead of 0. The functions then loop that many times,
reading (write()) or writing (read()) `wl_page_size` bytes per iteration
through the flash partition, immediately walking past the caller-supplied
buffer on the very first iteration:
- write(): out-of-bounds *read* from the caller's `src` buffer.
- read(): out-of-bounds *write* into the caller's `dest` buffer -- the
more severe case, since it corrupts caller memory with flash
content instead of merely over-reading.
Verified with a standalone reproduction that compiles the unmodified
WL_Flash.cpp against a mock Flash_Access partition: calling
`wl.write(0, an_8_byte_buffer, 0)` with no other change immediately
segfaults (confirmed count == 0xFFFFFFFF for wl_page_size == 4096); with
this fix applied the same call returns ESP_OK without touching memory
outside the buffer, and normal non-zero-size read/write is unaffected.
Add an early `size == 0` return (mirroring the existing `!initialized`
guard) to both functions, and a host_test regression case exercising
wl_write()/wl_read() with size == 0 through the public API.
Disclosure: this fix was prepared with AI assistance (Claude) and reviewed
by me before submission.
Signed-off-by: yi chen <94xhn1@gmail.com>