ESP8266 Community Forum

- Sun Feb 02, 2020 5:09 am #85527

The next step is to trace back from the ROM function to find out where it's being called from user land.

Using GDB can help here but it's problematic because the crash is random so you never know when it will happen, and adding the GDB stubs also changes timing but typically these sort of crashes can be timing sensitive

So, if norally deug method introduce a hard work, experiences might be more helpful. e.g. if someone else did some work before and then encountered this issue, it would be helful to summarry the possible causes.

- Sun Apr 12, 2020 5:35 am #86456 A watchdog timer reset can be caused by disabled interrupts but really doesn't need to be. I can also be triggered by a loop in your code that never yields back to the SDK code. The loop can be by intention or a bug. In both cases it won't work.

If the exception occurs at different locations, randomly there can be either two causes:
- bad power supply so the whole chip starts to work erraticly
- severe bug in your code that trashes either the user stack or the SDK stack. At some point the code will do a return and it will jump to a random location instead of what is intended.

The use stack (talking about NONOS SDK here) is quite big, about 5k. If you manage to put all kinds of arrays on it, it will overflow though and then you will get these kinds of crashes. Similary if you have stray pointers in your program and manage to overwrite SDK memory space (including stack) you will see the same.

I have ESP's here with my own code using NONOS SDK happily run for years, so it's not something inherently to ESP8266.