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
extern_ram_seg segment was marked as RWX in the linker script
even though we cannot run code from PSRAM on ESP32.
This is a link-time check, and actual CPU RWX permissions are
controlled seperately so this has no practical implications,
but it could mistakenly be remarked upon during security scans
or checks by customers.
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.
Michael (XIAO Xufeng)