Extends the External RAM encryption section to describe
CONFIG_SPIRAM_ENC_EXEMPT and the MALLOC_CAP_SPIRAM_NO_ENC heap
capability, including a security warning and a typical DMA-alignment
use case. Mirrors the change in zh_CN.
Adds CONFIG_SPIRAM_ENC_EXEMPT, available on chips that support per-page
PSRAM encryption configuration (esp32c5, esp32c61, esp32p4). When
enabled, esp_psram carves CONFIG_SPIRAM_ENC_EXEMPT_SIZE off the top of
PSRAM and maps it via the new mmu_hal_map_region_no_enc() helper, which
writes MMU entries without the SENSITIVE bit. The region is registered
as a separate heap pool reachable only through the new
MALLOC_CAP_SPIRAM_NO_ENC capability bit, so default SPIRAM allocations
cannot accidentally land there.
PSRAM encryption imposes alignment constraints that some DMA engines
(e.g. 2D-DMA) cannot satisfy. This option lets such workloads place
their buffers in unencrypted PSRAM while keeping the rest of PSRAM
(and flash) encrypted. Default disabled; security implications are
documented in the Kconfig help text.
Replace the eTaskGetState() polling guard in prvTaskDeleteWithCaps()
with a per-core xTaskGetCurrentTaskHandleForCore() check, so the
predicate matches vTaskDelete()'s immediate-vs-deferred decision. This
closes the taskTASK_SCHEDULED_TO_YIELD race against the IDLE-deferred
TCB cleanup on the SMP preview kernel; behaviour is unchanged on the
default IDF kernel and on single-core targets.
A typical scenario is: when XIP on PSRAM enabled, compiler optimization level is Os. Under certain binary layout, boot hangs and backtrace points to `esp_sleep_config_gpio_isolate`.
The root cause is that, during PSRAM initialization, it calls esp_gpio_reserve, which happens to place before the reported function. However, after call, there is no barrier before the clock adjustment in `mspi_timing_enter_low_speed_mode`. The clock gets changed when the cache is still fetching data, resulting in the corrupted data in the end of the cache line.
This commits add spi_flash_disable_cache as a barrier to make sure the cache transactions is finished before the clock switch.
On RISC-V chips with SPIRAM support (esp32c5, esp32c61, esp32h4, esp32p4,
esp32s31), esp_restart_noos() was disabling the cache while the current
stack pointer could still be in external RAM. Any stack access after cache
disable (function call, local variable spill) would then fault with
"Cache disabled but cached memory region accessed".
Xtensa chips (esp32, esp32s2, esp32s3) already had this guard via the
SET_STACK macro. Add the equivalent for RISC-V:
- Add rv_utils_set_sp() to riscv/rv_utils.h (plain "mv sp, %0" with a
memory clobber; no window register management needed on RISC-V)
- In each affected system_internal.c, under
CONFIG_FREERTOS_TASK_CREATE_ALLOW_EXT_MEM, check whether the current
SP is in PSRAM and if so switch it to the top of internal BSS before
any cache disable or writeback operation
- Fix xTaskCreateStaticPinnedToCore() stack size argument in the
spiram_stack test (was passing bytes instead of word count)
- Mark the null-pointer write in func_do_exception() as volatile to
prevent the compiler from optimizing it away
- Extend the [spiram_stack] tests to RISC-V by sharing fibonacci() and
the task/finish helpers across architectures, guarding only the
Xtensa-specific WINDOWBASE/WINDOWSTART prints
The test was passing without real I2C communication due to a GPIO
mismatch (slave on GPIO 6/7 vs RTC I2C master on GPIO 2/3), single-byte
zero-coincidence, unchecked ULP return values, and an insufficient
RTC I2C timeout.
Fix slave GPIOs, increase test length, check I2C return values, add
proper assertions, and set an adequate RTC I2C timeout.
Co-authored-by: Cursor <cursoragent@cursor.com>
With CONFIG_ESP_MAIN_TASK_AFFINITY_NO_AFFINITY=y the main task could
switch core between registering the idle hook and the while loop.
This would cause a deadlock were the current task was waiting for the
idle hook to run on the same core it's busy waiting.
Merge https://github.com/espressif/esp-idf/pull/16149