FAQ Section Updated about Watchdog resets #2533
Conversation
FAQ section updated with an explanation why the wdt bites and how feed them and how to disable the software wdt.
Current coverage is 27.80% (diff: 100%)@@ master #2533 diff @@
==========================================
Files 20 20
Lines 3625 3625
Methods 335 335
Messages 0 0
Branches 656 656
==========================================
Hits 1008 1008
Misses 2441 2441
Partials 176 176
|
|
@krzychb thanks and will document more if needed 😄 That's fine with me, I am not a native english speaker/writer. |
|
I do not find this clear. In the example, you stop the software watchdog but continue to feed the hardware watchdog with the function named |
|
Yes, thank you! |
| ### I'm getting these Watchdog Resets "wdt reset"�How can I avoid them? | ||
| The esp8266 is equipped with two watchdog timers: A software watchdog and a hardware watchdog. If you don't understand why microcontrollers need a watchdog (timer), you may first read [here](http://www.embedded.com/electronics-blogs/beginner-s-corner/4023849/Introduction-to-Watchdog-Timers). | ||
|
|
||
| When your sketch is running�either in the `setup` or during the `loop`�you have to make sure to feed the watchdog periodically. Otherwise "it will bite" and the watchdog reset will stop your sketch. The basic operation is illustrated in the following picture: |
There was a problem hiding this comment.
@pasko-zh, I think my comment was not to the point. Sorry, and let me be more specific. I would rephrase:
Otherwise "it will bite" and the watchdog reset will stop your sketch.
to:
Otherwise "it will bite" and the watchdog will reset your sketch.
or:
Otherwise "it will bite" and the watchdog will restart your module.
I think that "stop sketch" may confuse people, while "restart" or "reset" better explains what the watchdog does if not fed.
Thank you again for contributing to FAQ 👍
Krzysztof
There was a problem hiding this comment.
Went for "restart" your sketch, which explains it better than stop your sketch
Watchdog will RESTART your sketch, is better/more precise than STOP your sketch.
| - `system_soft_wdt_feed()` | ||
| - `system_soft_wdt_restart()` | ||
|
|
||
| The name of the function `system_soft_wdt_feed()` is bit confusing: In general it will feed **both** watchdogs, i.e. the software **and** hardware watchdog. If you disable the software watchdog by calling `system_soft_wdt_stop()` and then call `system_soft_wdt_feed()` afterwards, it will still feed both watchdogs. However, since you have just disabled the software watchdog before, it will have no effect on the software watchdog (timer) and will only affect the hardware watchdog (timer). Thus, from an "End-User's" perspective, this looks like `system_soft_wdt_feed()` feeds the hardware watchdog only. |
There was a problem hiding this comment.
Personally I think is in part a bug, in part bad design. Maybe we should rather document how to feed the hardware watchdog via a register?
| system_soft_wdt_feed(); // Feed Hardware Watchdog | ||
| for (j = 1; j < 20; j++) { | ||
| a = micros(); | ||
| busy_1second(); |
There was a problem hiding this comment.
Can this be replaced with a more intuitive delayMicroseconds(1000000);?
| From the perspective of your Arduino sketch, the basic feeding is implicit: Everytime an iteration of your main loop starts again, i.e. it hits the `loop` statement both watchdogs are fed; cf. (1) in the figure above. Esp8266 Arduino libraries, especially core libraries like for instance the `ESP8266WiFi` library take care of feeding the watchdogs, too. Thus, normally you don't have to feed them explicitly. | ||
|
|
||
| **When and why should I feed the watchdog(s) explicitly?** | ||
| The software watchdog bites exactly every 3.2 seconds, the hardware watchdog every 7�8 seconds. If your sketch contains code which could exceed running for 3.2 seconds you must feed the watchdogs. I.e. you have to feed them explicitly by calling (cf. (1) in the figure above): |
There was a problem hiding this comment.
It is probably worth noting that feeding the watchdog is not the only problem if some code runs for more that a second straight. WiFi and TCP/IP stack will not work as expected after this: station mode wifi will disconnect due to beacon timeout, and TCP stack may get flooded with packets.
earlephilhower
added
merge-conflict
|
Thanks for your PR, but the core and libraries have changed enough that this PR now has a merge conflict. Could you merge it manually with the latest core, so we can consider it for future releases? |
Added a FAQ section about watchdogs: