ESP32 Forum

Hi!
I have a code on an ESP32 that randomly crashes with the following reset reason: RTCWDT_RTC_RESET (rtc_get_reset_reason(0)==16).

Here I found more information about this reboot reason:
https://docs.espressif.com/projects/esp ... og-timeout

The RTC watchdog is used in the startup code to keep track of execution time and it also helps to prevent a lock-up caused by an unstable power source. [... It is] finally disabled right before the app_main() call. There is an option CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE which prevents the RTC watchdog from being disabled before app_main. [...]

As I understand this RTC watchdog, it monitors the start up of the chip and disables itself before my main code (setup() and loop()) is run. I don't use the mentioned option to enable the watchdog again. I add the following code, to verify it: Visual Studio Code shows me, the Serial.println-Command grayed out. Also there is no output of this line in serial monitor. So i don't think, my code activates this option anywhere.

So I ask myself, how could the RTC watchdog trigger a restart a few hours after the boot up, when it should be disabled for hours? Are there more errors, triggering the error code 16?

Best regards
Julian

Hello, the first thing I would say:

It is not advisable to remove the RTC

The RTC watchdog timer plays an important role in ensuring the stability and reliability of your ESP32-based system. It works by resetting the ESP32 if it is not serviced within a certain amount of time, which can help to recover from certain types of failures or issues that might otherwise cause the system to become unresponsive.

Disabling the RTC watchdog timer means that the ESP32 will no longer have this safety mechanism to recover from certain types of failures or problems, which could make the system more prone to problems. For example, if the program gets stuck in an infinite loop or encounters some other problem that prevents it from running correctly, the RTC watchdog timer can reset the ESP32 and allow it to recover, whereas if the watchdog timer is disabled, the ESP32 won't. it will be able to recover and the program will continue to run incorrectly.

Therefore, it is generally not recommended to disable the RTC watchdog timer unless you are sure it is not needed, as this can reduce the stability and reliability of your system. If you see frequent resets of the RTC watchdog timer, it's generally a good idea to try to identify and fix the root cause of the problem rather than just disabling the watchdog timer.



Secondly:
The value 16 is the numeric code for the RTCWDT_RTC_RESET reset reason, which means that the RTC watchdog timer reset the ESP32 because the RTC watchdog timer was not serviced within the specified time period. This could happen if the program gets stuck in an infinite loop or if the program is not running fast enough to service the watchdog timer regularly.

To determine the exact cause of this reset, you will need to check your code for infinite loops or other issues that might cause the program to hang, and optimize your code to ensure that it runs efficiently and that the RTC watchdog timer is being serviced regularly. It may also be helpful to enable debugging and examine the log output for error messages or other clues that can help you identify the root cause of the problem.


What's more:
There are a few possible reasons why the RTC watchdog timer might trigger a reboot on the ESP32 a few hours after boot, even if it's supposed to be disabled:

The RTC watchdog timer may not have been disabled correctly: If the rtc_wdt_disable() function was not called correctly or was called too late in the boot process, the RTC watchdog timer may still be active and can trigger a reboot. Make sure that the rtc_wdt_disable() function is called correctly and at the right time in your code.

Another part of the program might re-enable the RTC watchdog timer: If some other part of the program is enabling the RTC watchdog timer, it might trigger a reset even if it was previously disabled. Make sure that no other parts of the program are enabling the RTC watchdog timer.

There may be a problem with the RTC module itself: If there is a problem with the RTC module, it could cause the RTC watchdog timer to trigger a reset, even if it's supposed to be disabled. This could be due to a hardware problem, or it could be due to a problem with the RTC settings.

regards

Hey Franciso!
Thanks for your comprehensive reply! Nevertheless I think, we have some type of misunderstanding here.

FRANCISCO2020 wrote: ↑

Wed Jan 04, 2023 10:39 am

It is not advisable to remove the RTC

The RTC watchdog timer plays an important role in ensuring the stability and reliability of your ESP32-based system. It works by resetting the ESP32 if it is not serviced within a certain amount of time, which can help to recover from certain types of failures or issues that might otherwise cause the system to become unresponsive. [...]

You seem to talk about the Task Watchdog Timer (TWDT (Click me)). The TWDT monitors the running of the app, the RTC Watchdog only monitors the start up / boot as described here (Click me). This is the reason why it deactivates itself before starting my main code. I don't deactivate the RTC-WDT the ESP32-Boot-Code does it itself This is the reason I am surprised it seems to be still activated during normal program run.

FRANCISCO2020 wrote: ↑

Wed Jan 04, 2023 10:39 am

Secondly:
The value 16 is the numeric code for the RTCWDT_RTC_RESET reset reason, which means that the RTC watchdog timer reset the ESP32 because the RTC watchdog timer was not serviced within the specified time period. This could happen if the program gets stuck in an infinite loop or if the program is not running fast enough to service the watchdog timer regularly.

I could give it a try and manually reset the RTC WDT regularly, but I have no clue how to reset it :/ There isn't that much information in the web about the RTC WDT...

FRANCISCO2020 wrote: ↑

Wed Jan 04, 2023 10:39 am

To determine the exact cause of this reset, you will need to [...] enable debugging and examine the log output[...]

I already tried to do so, but it is hard to get the serial output, if the error raises randomly hours after program start That's why I connected a serial sniffer uploading the serial data of my problematic ESP into the Internet. But it doesn't log that much during boot. I only get one line before my code output starts:

$<�$�"$$�$8�'�#$$�$$ ��b$���';b##<�"#8��<�#<�##�<�#$;����''8.�"$8�'"�'|bp�'#�'<"$8�'"'<"��<�$�$[ 11][D][esp32-hal-cpu.c:244] setCpuFrequencyMhz(): PLL: 480 / 2 = 240 Mhz, APB: 80000000 Hz

My debug level is 5 to get as much information as possible, I think thats why I see this line. Does the ESP-Log get send with another baudrate, so my sniffer fails to record the ESP boot log? That will be hard to detect for my Sniffer

FRANCISCO2020 wrote: ↑

Wed Jan 04, 2023 10:39 am

What's more:
[...] Another part of the program might re-enable the RTC watchdog timer: [...]

This is possible. I don't reactivate it directly. Of course, it could be possible, that some of the libraries (wifi, serial, DHT22, SD, external RTC, etc.) could reactivate the Watchdog. Maybe I'll check regularly if the RTC WDT is getting activated again... I think there should be an option, to check if the WDT is active or not.

FRANCISCO2020 wrote: ↑

Wed Jan 04, 2023 10:39 am

There may be a problem with the RTC module itself: If there is a problem with the RTC module, it could cause the RTC watchdog timer to trigger a reset, even if it's supposed to be disabled. This could be due to a hardware problem, or it could be due to a problem with the RTC settings.

I never configure the RTC WTD by myself. So such a problem would be a bug in the main ESP32 code

Again: Thanks for your reply! I get some ideas, how to continue! Maybe someone knows some more reasons, why this error will be triggered?

Best regards
Julian

Really appreciate this post and its mention of "CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE".

For some reason this is enabled by default in arduinoespressif32 for ESP32S3 (via PlatformIO), I knew it would be something obvious like this but took me some time to find it!