WDT-Problem an nodeMCU V1

[juergs]

Hallo Zusammen,

mit der Gefahr, dass ich Euch allen mit der Frage auf die Nerven gehe  :

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
vf6d232f1
~ld

Ich habe schon einiges an Threads + Foren gewälzt bin aber noch nicht wirklich weiter gekommen:

es gibt ja verschiedene Möglichkeiten, die in den Foren Erwähnung finden:

1. Boardtyp
2. Spannungsversorgung
3. WDT-Handling
4. SW-Fehler
5. Expressif-SDK-Fehler (SDK-Version?)
6. Zu lange Timeout-Schleifen .... usw. usw.

Da ich mich rel. neu mit dem ESP8266 beschäftige und das obige Problem (mal mit Reset mal mit Hang)  nervt,
wende ich mich mal an die Experten.

Gibt es Hoffnung?

Grüße,
Jürgen

[sbiermann]

It depends...

Du hast ja schon 5 mögliche Fehlerquellen erkannt, die solltest du nach und nach überprüfen ob es dann besser wird. Ich würde mit 4 und 5 anfangen, da dort meiner Erfahrung nach die meisten Probleme zu finden sind. Klassiker bei 4 wäre, eine Loop Methode ohne yield() oder delay().

[juergs]

Hallo sbiermann,
danke für die Antwort, hatte das yield() noch nicht im Blickfeld.
Werde mal versuchen erst das neueste SDK bzw. Arduino-Libraries zu installieren um auch das ausschließen zu können.
Die oben erwähnten Punkte hatte ich eigentlich auch schon geprüft.

Grüße,
Jürgen

[juergs]

Falls jemand ebenfalls mit WDT-Problemen suchen sollte: http://www.espressif.com/en/support/explore/faq

What is the watchdog timeout interval? What happens on a timeout event?

The hardware watchdog interrupt interval is 0.8*2048 ms, that is 1638.4 ms. The interrupt handling interval is 0.8*8192 ms, equal to 6553.6 ms. The interrupt handling interval is the time limit to feed the watchdog after the interrupt occurs. If the interrupt handling interval expires, it will trigger a hardware watchdog reset. As a result, in the cases where there is only hardware watchdog, if a program runs for over 6553.6 ms, then it could cause a hardware watchdog reset. If the program runs for over 8192 ms, then it will invoke a watchdog reset for sure.

The software watchdog is based on MAC timer and task arrangement. The interrupt interval is 1600 ms, so is the interrupt handling interval. As a result, in the cases where there are both software and hardware watchdogs, if a program runs for over 1600 ms, then it could cause a software watchdog reset. If the program runs for over 3200 ms, then it will invoke a watchdog reset for sure.

My application does not really need the watchdog timer, can I disable it?
The current SDK allows disabling the software watchdog only. The following methods can be taken to avoid watchdog reset when user program occupies CPU for too long:
If your routine needs a time frame of duration between software reset and hardware watchdog reset,
you may use system_soft_wdt_stop () to disable the software watchdog. After the program has been executed, you can restart the software watchdog with system_soft_wdt_restart (). You may feed the watchdog in between your code by adding system_soft_wdt_feed () such that the watchdog
is updated before it issues a reset.

What is the best way to introduce a 10-second delay in my program or poll for an input?
The watchdog timer will not allow endless loops. As mentioned above, the watchdog will overflow and cause reset if the user program is stuck polling for an event for too long or is using loops for delays. We recommend using call-back functions and timer APIs for delay.

For polling an event, if possible, always use interrupts or timer APIs to check often. Most events can be associated with call-back functions within the SDK and therefore polling can be entirely avoided in most cases.