Reading from the flash while it is being reconfigured leads to data
corruption and a crash when the reconfiguration code is located in flash.
This is only an issue if a device has a bootloader that runs with 40 MHz
flash and an application flashed via OTA that runs with 80 MHz flash.
If bootloader and application run with the same flash speed, the
reconfiguration is basically a no-op and no data corruption occurs.
Fix reconfiguration by placing the code back into IRAM.
Issue introduced in: 7549d08
Closes: https://github.com/espressif/esp-idf/pull/17905
This commit implements a workaround that allows ESP32-C5 to run at 240MHz CPU frequency
normally, while automatically reducing CPU frequency during encrypted flash writes to
ensure correct operation. The frequency limit is chip revision dependent:
- v1.2 and above: limited to 160MHz during encrypted writes
- v1.0 and below: limited to 80MHz during encrypted writes
Key implementation details:
- Frequency limiting is triggered automatically when esp_flash_write_encrypted() is called
- Uses start() flags (ESP_FLASH_START_FLAG_LIMIT_CPU_FREQ) to integrate with OS layer
- Works with both PM enabled and disabled configurations
- Frequency is automatically restored after encrypted write completes
- For ESP32-C5 with 120MHz flash, Flash clock and timing registers are adjusted when
CPU frequency is reduced to 80MHz
- SPI1 timing registers are configured during frequency switching since encrypted writes
use SPI1 and must work correctly at reduced CPU frequencies
Code improvements:
- Use SOC_MSPI_FREQ_AXI_CONSTRAINED capability macro instead of hardcoded chip checks
- Control workaround via Kconfig (CONFIG_PM_WORKAROUND_FREQ_LIMIT_ENABLED) instead of
hardcoded macros
- Add comprehensive test cases covering various PM configurations and edge cases
This workaround enables ESP32-C5 applications to benefit from 240MHz CPU performance
while maintaining reliable encrypted flash write functionality.
Interrupt wdt would get triggered on uart_driver_install if uart driver was deleted before
Closes https://github.com/espressif/esp-idf/issues/17779
RTC wdt would get triggered on esp_restart if uart driver was deleted before
Encrypted flash write operation sometimes result in random corruption in
certain bytes. Root cause points to sudden current surge due to involvement of
encryption block overwhelming LDO supply. More details will be provided
in the ESP32-C5 SoC Errata document.
This fix limits the CPU clock to 160MHz for flash encryption enabled
case. Failing encrypted flash write tests could successfully pass in
this configuration. Going ahead, a dynamic clock adjustment in flash
driver will be considered to mitigate this issue.
When DMA keep writing the memory, some data may be corrupted after reset. For example, the stack of bootloader may be overwritten and failed to boot until a higher scope of reset (Core).
Also removed the DPORT_PERIP_RST_EN_REG alias on ESP32S2. Now it's the same as some following chips (EN0).
Added one more pair of 2DDMA channels
Priority bit width increased corespondingly
Added three new CSC modes for RX channel 0
Also cleaned up DMA2D capability definitions in soc_caps.h
- Remove GPTIMER and TIMG related definitions from soc_caps_full.h files
- Move timer peripheral definitions to appropriate HAL layer files
- Update references across components to use proper HAL abstractions
- Consolidate timer group and GPTIMER capabilities organization
- Ensure consistent timer configuration across all ESP32 variants
This refactoring improves the separation of concerns between SOC
capabilities and HAL implementations for timer-related functionality.
yanzihan@espressif.com
morris
Mahavir Jain
Aditya Patwardhan
Jiang Jiang Jian
Laukik Hase
Xiao Xufeng
Mattias Schäffersmann
zlq
Chen Chen
Samuel Obuch
wuzhenghui
Alexey Gerenkov
Song Ruo Jing
Alexey Lapshin
sibeibei
Chen Jichang