ESP32-C3 freezes when setting CPU clock to internal RC oscillator (IDFGH-11852)

[Pavelovec]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3

Espressif SoC revision.

ESP32-C3 rev v0.3

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32-C3 rev v0.3 on custom board

Power Supply used.

External 3.3V

What is the expected behavior?

The ESP32-C3 should switch to the internal RC oscillator (17.5MHz) as the CPU clock source and continue to operate normally, as indicated in the ESP32-C3 datasheet.

What is the actual behavior?

When setting the CPU clock source to the internal RC oscillator in the ESP32-C3, the system consistently freezes, making any further code execution impossible. This problem has been observed on several ESP32-C3 boards. Notably, an equivalent code functions correctly on ESP32-C6 boards, suggesting a model-specific issue with the ESP32-C3.

Steps to reproduce.

1. Connect any ESP32-C3 board
2. Build and flash this code:

#include <stdio.h>
#include <inttypes.h>
#include "sdkconfig.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_chip_info.h"
#include "esp_flash.h"
#include "esp_system.h"
#include "soc/rtc.h"

void app_main(void) {
    printf("Hello world!\n");
    fflush(stdout);
    vTaskDelay(1000 / portTICK_PERIOD_MS);
    rtc_clk_8m_enable(true, false);
    vTaskDelay(2000 / portTICK_PERIOD_MS);
    rtc_cpu_freq_config_t config;
    rtc_clk_cpu_freq_get_config(&config);
    config.source = SOC_CPU_CLK_SRC_RC_FAST;
    config.freq_mhz = 20;
    config.div = 1;
    rtc_clk_cpu_freq_set_config(&config);
    esp_restart();
}

Debug Logs.

ESP-ROM:esp32c3-api1-202�I (26) boot: ESP-IDF v5.3-dev-1196-gece73357ca-dirty 2nd stage bootloader
I (26) boot: compile time Jan  6 2024 18:10:01
I (27) boot: chip revision: v0.3
I (31) boot.esp32c3: SPI Speed      : 80MHz
I (36) boot.esp32c3: SPI Mode       : DIO
I (40) boot.esp32c3: SPI Flash Size : 2MB
I (45) boot: Enabling RNG early entropy source...
I (51) boot: Partition Table:
I (54) boot: ## Label            Usage          Type ST Offset   Length
I (61) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (69) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (76) boot:  2 factory          factory app      00 00 00010000 00100000
I (84) boot: End of partition table
I (88) esp_image: segment 0: paddr=00010020 vaddr=3c020020 size=09d50h ( 40272) map
I (103) esp_image: segment 1: paddr=00019d78 vaddr=3fc8ae00 size=01294h (  4756) load
I (106) esp_image: segment 2: paddr=0001b014 vaddr=40380000 size=05004h ( 20484) load
I (117) esp_image: segment 3: paddr=00020020 vaddr=42000020 size=16ed8h ( 93912) map
I (137) esp_image: segment 4: paddr=00036f00 vaddr=40385004 size=05dc8h ( 24008) load
I (145) boot: Loaded app from partition at offset 0x10000
I (145) boot: Disabling RNG early entropy source...
I (157) cpu_start: Unicore app
I (166) cpu_start: Pro cpu start user code
I (166) cpu_start: cpu freq: 160000000 Hz
I (166) cpu_start: Application information:
I (169) cpu_start: Project name:     hello_world
I (174) cpu_start: App version:      1
I (179) cpu_start: Compile time:     Jan  6 2024 18:09:57
I (185) cpu_start: ELF file SHA256:  3ef25d90c...
I (190) cpu_start: ESP-IDF:          v5.3-dev-1196-gece73357ca-dirty
I (197) cpu_start: Min chip rev:     v0.3
I (202) cpu_start: Max chip rev:     v1.99 
I (207) cpu_start: Chip rev:         v0.3
I (211) heap_init: Initializing. RAM available for dynamic allocation:
I (219) heap_init: At 3FC8D030 len 00032FD0 (203 KiB): RAM
I (225) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (232) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (239) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM
I (246) spi_flash: detected chip: generic
I (250) spi_flash: flash io: dio
W (253) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (267) sleep: Configure to isolate all GPIO pins in sleep state
I (273) sleep: Enable automatic switching of GPIO sleep configuration
I (281) main_task: Started on CPU0
I (291) main_task: Calling app_main()
Hello world!

More Information.

An image from the ESP32-C3 datasheet, specifying CLK sources, will be attached for reference. The ESP32-C3 datasheet indicates the internal RC oscillator as a viable CPU clock source, yet implementing this in code results in system freeze. It's important to note that my ESP-IDF version is marked as "dirty." This is because I attempted several modifications in the SDK to resolve the issue. However, it's crucial to mention that the system freeze occurred with both the modified ("dirty") and the original, unmodified versions of the SDK, indicating that the problem persists regardless of these changes. I would greatly appreciate any insights or confirmation on whether it is indeed feasible to use the internal RC oscillator as a CPU clock source on the ESP32-C3. This information is critical for my project, and I am under a significant time constraint. Prompt assistance or guidance from the community or Espressif representatives would be highly valued.

[songruo]

Hi @Pavelovec, we didn't really support to use RC_FAST_CLK as CPU clock source in ESP-IDF. We didn't even try this option internally. Can you explain why you may want to do this? If we think it is reasonable, this could be a feature request.

[Pavelovec]

Hi @songruo ,

Thank you for your response. We are exploring the use of the internal RC oscillator as a CPU clock source on the ESP32-C3 as a workaround for a specific issue. Our ESP32-based devices are experiencing restarts when a relay, controlling a contactor, is activated. We suspect that the relay's electromagnetic interference might be causing glitches in the 40MHz crystal oscillator, leading to system instability and resets by the watchdog timer after a few seconds.

As a potential solution, we are considering switching the CPU clock source from the 40MHz crystal to the internal 17.5MHz RC oscillator during relay activation and then switching back post-operation. We acknowledge that this approach is unconventional, but we aim to address the problem through software modifications without substantial hardware changes.

Thank you for your consideration and support in addressing this issue.