-->
Page 1 of 2

wdt, Finding in Code

PostPosted: Wed Feb 16, 2022 9:04 am
by Inq720
Is there any information in the error output for Watch Dog errors that can lead me to some place in my code? Even if it's a ball-park. Say... something like the ESP Exception Decoder does.

The usual suspects...

* There are no delay() statements in my library of about 25k lines of code.
* The same program on the same ESP, linked on the same USB computer port can run for five minutes one time and multiple days another before getting the wdt. In the multi-day instance, the WiFi had sent/received over 2GB of data.
* The ADC_MODE(ADC_VCC) voltage reading is showing a solid 3.37 V.
* There are no memory leaks as monitored by system_get_free_heap_size.

Thank you for your help.

Code: Select all ets Jan  8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v00061a00
~ld

Re: wdt, Finding in Code

PostPosted: Wed Feb 16, 2022 5:02 pm
by davydnorris
Unfortunately the WTD is hardware and is triggered at low level, so you lose your place in the program.

I had to chase this down once and I ended up writing a small debug file that stored and retrieved debug info from the RTC RAM. I put the retrieve function in the start up code and printed the info to the console, and then I added the store function at the top of functions until I was able to gradually narrow down the problem - tedious but I eventually found the place where I was doing stuff for too long.

You didn't mention what SDK or environment you're using, but look for code that does stuff inside potentially long loops.

Re: wdt, Finding in Code

PostPosted: Thu Feb 17, 2022 8:44 am
by Inq720
Thanks for your reply. Although hopeful, just knowing something wasn't staring me in the face on that screen is a good consolation prize.

davydnorris wrote:Unfortunately the WTD is hardware and is triggered at low level, so you lose your place in the program.

I had to chase this down once and I ended up writing a small debug file that stored and retrieved debug info from the RTC RAM. I put the retrieve function in the start up code and printed the info to the console, and then I added the store function at the top of functions until I was able to gradually narrow down the problem - tedious but I eventually found the place where I was doing stuff for too long.

You didn't mention what SDK or environment you're using, but look for code that does stuff inside potentially long loops.


That sounds next-level! Makes this printf style look lightning fast. I have not done anything with RTC yet, but do have it bookmarked for future study.

BTW - I'm back using the Arduino IDE flavor of development on the ESP's.

Re: wdt, Finding in Code

PostPosted: Thu Feb 17, 2022 7:55 pm
by davydnorris
It's not really next level, it's a couple of calls. If you are using Arduino then these should help you get organised:

https://hutscape.com/tutorials/rtc-memory
https://forum.arduino.cc/t/how-to-store-data-in-rtc-internal-memory-of-esp8266-thing-dev-board/531738

Simply define a structure that contains whatever you like, but make it compact - I just use a string with the debug point name in it. At the top of each function or code block you write the string to RTC, and in the setup you read and print the RTC contents

Whenever you restart for any reason, it'll print the string and show you the last debug point reached before reboot