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).
zlq
Xiao Xufeng
Mattias Schäffersmann
Chen Jichang
Marius Vikhammer
Wu Zheng Hui
morris
Chen Chen
Samuel Obuch
C.S.M
Jiang Jiang Jian
Alexey Lapshin
sibeibei
Song Ruo Jing
Mahavir Jain
Laukik Hase
Armando (Dou Yiwen)