-->
Page 1 of 2

How to locate the cause of HardwareWDT reset on 8266 module?

PostPosted: Mon Jan 06, 2020 11:15 am
by esp8266_abc
Not So frequently, 8266 module would reset with below info:

ets Jan 8 2013,rst cause:4, boot mode: (3,7)
wdt reset

Further dig into reset info to get
reset reason : 1, wdt reset
epc1=0x40000f68, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

Espressif documents says "Please do NOT disable the hardware interrupt for a long time, it should NOT be longer than 50us" or it migt bring about a hardware wdt reset.

Howver, there is no interrupt disable operation and even burn standard AT firmware from expressif to some esp8266 module also might encountered this issue just a short period after booup.

How to locate the cause?

Re: How to locate the cause of HardwareWDT reset on 8266 mod

PostPosted: Mon Jan 06, 2020 5:22 pm
by davydnorris
you can use the value of epc1 and a compile dump to find out which function is causing the problem. That may help you work out what the ultimate cause is.

If it's happening on the standard AT flash then that would suggest the problem may be external hardware interrupt related - how are you communicating with the ESP? Serial line? Any other external connections?

Re: How to locate the cause of HardwareWDT reset on 8266 mod

PostPosted: Wed Jan 08, 2020 7:35 am
by esp8266_abc
Thanks!

But, if the epc1 address range (i.e. 0x4000f68) has been checked, it may be found that it is an address of on-chip rom code! And a fallen-in dead-loop address inside the on-chip rom code(which will bring about a HardwareWDT reset definitely). Meanleass for further locating.

Do NOTHING Just after bootup, the module would reboot due to Hardware WDT reset according to the bootup message.

Any further suggestion? Thanks

Re: How to locate the cause of HardwareWDT reset on 8266 mod

PostPosted: Wed Jan 08, 2020 5:03 pm
by davydnorris
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