ESP8266 resets via software watchdog after update 3.0->3.1

[cjbaar]

I have a home project that is using a NodeMCU ESP8266 module, which I am programming via the Arduino IDE. Recently, I started to notice frequent restarts on the device after the IDE updated some board/library files.

Testing with multiple versions of the library has confirmed that the device is running fine (no restarts) when I use v3.0.2 of the esp8266 library, but I get the software watchdog resets when using 3.1.0 or higher. The restarts are apparently random, meaning sometimes it resets after two hours of uptime, sometimes after two minutes.

I do not currently have a serial device attached, so I do not see the full stack trace. (Also, from what I can tell, the exception decoder no longer works with IDE 2.0+.) What I can see from the esp reset reason logic is that I get code (REASON_SOFT_WDT_RST / software watch dog reset). I am familiar with the hardware watchdog, but not the software-based one. I also get the last memory address as "epc1=0x40100588". When I look through the ino map file, I do no see an exact match for this address, but I think it is somewhere in this area ... ?

                0x00000000401057d0       0xc3 /.../Library/Arduino15/packages/esp8266/hardware/esp8266/3.1.0/tools/sdk/lib/NONOSDK22x_190703/libmain.a(app_main.o)
                                         0xdb (size before relaxing)
 *fill*         0x0000000040105893        0x1 
 .text.wdt_feed
                0x0000000040105894       0x63 /.../Library/Arduino15/packages/esp8266/hardware/esp8266/3.1.0/tools/sdk/lib/NONOSDK22x_190703/libmain.a(app_main.o)
                                         0x73 (size before relaxing)
                0x0000000040105894                wdt_feed
 *fill*         0x00000000401058f7        0x1 

Is this the proper place to look for the address output by the reset reason? Without a working exception decoder, even if I get the serial output from another device, how does that help me? I'm just trying to figure out how to narrow down where this is failing before I open an actual issue.

[mcspr]

Please prefer to test with latest releases, which is 3.1.2 rn
If you can, please try git installation as well (see readthedocs)

Wild guess, you just call yield() / delay() or try to 'block' CONT while actually in SYS task which is not allowed and produces random exceptions at times.

Regarding decoder, readthedocs page also mentions that exception decoder is included as a python script at tools/decoder.py. Save .elf, save exception trace as .txt and feed it to the script.

If you are aware of a method to integrate it in the IDE, please let me know :)
(or, I suppose, we would have to re-write it as javascript extension. but I am not using IDE and only have a vague idea of how it works, so it is only a guess)

Is this the proper place to look for the address output by the reset reason?

see addr2line. you can also use gdb to work with a static .elf file, which is a hefty combination of several other standalone tools

[cjbaar]

Thanks for the input. I don't call delay() anywhere, and yield() is only once in the main loop(). This code has run without issue for years, until the board library was updated beyond 3.0.2. My failures are using "3.1.0 or higher", which included 3.12. I will check out the python script to see what I can get from there.