rtc_get_reset_reason() doesn't work on C3 chipset (ESP32-C3)

[bwjohns4]

Board

ESP32-C3

Device Description

It's a one-off board using a ESP32-C3 module. It's called NiceMCU-C3F_V1.0

Hardware Configuration

No

Version

v2.0.7

IDE Name

PlatformIO

Operating System

MacOS

Flash frequency

40MHz

PSRAM enabled

yes

Upload speed

115200

Description

rtc_get_reset_reason() returns the same reason and does not differentiate between ESP.restart(), null ptr reference (crash), or WDT timeout. It does recognize POWER_ON type startups, but the crashes and software restarts are all lumped together under value "3" of the RESET_REASON enum which I interpret as software reset. Maybe that's because the crashes are directed to the panic handler which actually just issues a software reset? Not sure...

Sketch

RESET_REASON reason0 = rtc_get_reset_reason(0);
    switch ( reason0)
    {
      case 1 : BWJ_DEBUG_PRINTLN(F("POWERON_RESET"));break;          /**<1, Vbat power on reset*/
      case 3 : BWJ_DEBUG_PRINTLN(F("SW_RESET"));break;               /**<3, Software reset digital core*/
      case 4 : BWJ_DEBUG_PRINTLN(F("OWDT_RESET"));break;             /**<4, Legacy watch dog reset digital core*/
      case 5 : BWJ_DEBUG_PRINTLN(F("DEEPSLEEP_RESET"));break;        /**<5, Deep Sleep reset digital core*/
      case 6 : BWJ_DEBUG_PRINTLN(F("SDIO_RESET"));break;             /**<6, Reset by SLC module, reset digital core*/
      case 7 : BWJ_DEBUG_PRINTLN(F("TG0WDT_SYS_RESET"));break;       /**<7, Timer Group0 Watch dog reset digital core*/
      case 8 : BWJ_DEBUG_PRINTLN(F("TG1WDT_SYS_RESET"));break;       /**<8, Timer Group1 Watch dog reset digital core*/
      case 9 : BWJ_DEBUG_PRINTLN(F("RTCWDT_SYS_RESET"));break;       /**<9, RTC Watch dog Reset digital core*/
      case 10 : BWJ_DEBUG_PRINTLN(F("INTRUSION_RESET"));break;       /**<10, Instrusion tested to reset CPU*/
      case 11 : BWJ_DEBUG_PRINTLN(F("TGWDT_CPU_RESET"));break;       /**<11, Time Group reset CPU*/
      case 12 : BWJ_DEBUG_PRINTLN(F("SW_CPU_RESET"));break;          /**<12, Software reset CPU*/
      case 13 : BWJ_DEBUG_PRINTLN(F("RTCWDT_CPU_RESET"));break;      /**<13, RTC Watch dog Reset CPU*/
      case 14 : BWJ_DEBUG_PRINTLN(F("EXT_CPU_RESET"));break;         /**<14, for APP CPU, reseted by PRO CPU*/
      case 15 : BWJ_DEBUG_PRINTLN(F("RTCWDT_BROWN_OUT_RESET"));break;/**<15, Reset when the vdd voltage is not stable*/
      case 16 : BWJ_DEBUG_PRINTLN(F("RTCWDT_RTC_RESET"));break;      /**<16, RTC Watch dog reset digital core and rtc module*/
      default : BWJ_DEBUG_PRINTLN(F("NO_MEAN"));
    }

### Debug Message

```plain
Core0: SW_RESET

Other Steps to Reproduce

N/A

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[mrengineer7777]

I've noticed SW_RESET on ESP32 as well. Not sure this is just a ESP32-C3 issue.

[igrr]

Maybe that's because the crashes are directed to the panic handler which actually just issues a software reset? Not sure...

Yes, that's correct. All these kinds of resets are software resets (from HW perspective).
You can use esp_reset_reason API to distinguish between them.

[mrengineer7777]

You can use esp_reset_reason API to distinguish between them.

Great info! I'm updating my code to use this.

Should we update the example to use this?
https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/ResetReason

[bwjohns4]

So use esp_reset_reason() in place of rtc_get_reset_reason()?

[mrengineer7777]

esp_reset_reason_t r = esp_reset_reason();
if(r == ESP_RST_POWERON) { }
else { }

[bwjohns4]

@igrr How does the dual core nature of the regular ESP32 play into this? esp_reset_reason() doesn't take an argument for which core. If one core crashes and restarts, would the panic handler then reboot the other core so effectively there's no notion of which core experience the issue?

[mrengineer7777]

@bwjohns4 esp_reset_reason calls esp_rom_get_reset_reason(PRO_CPU_NUM) (CPU 0) internally. I believe if CPU0 hardware reboots then CPU1 is also rebooted.

[Jason2866]

Closing, a solution is provided.