Replies: 2 comments
-
|
Please prefer to test with latest releases, which is 3.1.2 rn 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 :)
see addr2line. you can also use gdb to work with a static .elf file, which is a hefty combination of several other standalone tools |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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 ... ?
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.
Beta Was this translation helpful? Give feedback.
All reactions