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.
System Notes
Timekeeping
The following are the timekeeping mechanisms available and their differences:
- System time (
esp_system_get_time)
Time with the origin at g_startup_time. The implementation is not handled by esp_system,
but it does provide a default implementation using RTC timer. Currently, esp_timer
provides system time, since the hardware timers are under the control of that
component. However, no matter the underlying timer, the system time provider
should maintain the definition of having the origin point at g_startup_time.
esp_timertime (esp_timer_get_time)
This is the time read from an underlying hardware timer, controlled through config. Origin is at the point where the underlying timer starts counting.
newlibtime (gettimeofday)
Timekeeping function in standard library. Can be set (settimeofday) or moved forward/backward (adjtime);
with the possibility of the changes being made persistent through config.
Currently implemented in terms of system time, as the point of origin is fixed.
If persistence is enabled, RTC time is also used in conjuction with system time.
- RTC time (
esp_rtc_get_time_us)
Time read from RTC timer.
Brownout
on some boards, we name BOD1 as ana_bod, to unify the usage, using BOD1 in following passage.
BOD1 will be a little faster then BOD0, but BOD0 can be widely used(can reset rf, flash, or using interrupt, etc.) So, in IDF code, we use BOD1 in bootloader and BOD0 in the app.