2

We know watchdog timer if enabled RESETs when Arduino is locked up somewhere inside the code. As the title suggests has anyone experienced this unless they put deliberately a while(1) loop inside the code? Of course, buffer overflow or memory related issues are excluded.

I mean is it worth in Arduino to use watchdog and RESET rather than to fix the code to not get locked up. Are there still some behavior which are not predictable here?

Improve this question
4
  • Your code might communicate with an external sensor. If the sensor doesn't respond (correctly) your could could get stuck. Or there could be noise on the signal wires resulting in a response that you wouldn't get ordinarily. You could do a lot of checks in software, but you might just miss that edge case that only occurs once in a blue moon.
    – Gerben
    Commented Apr 15, 2017 at 15:56
  • @Gerben the case is I have made a Mega based device with GSM to send certain sensor data to my server. It works fine everywhere, but at a specific place I have seen the device stops communicating with GSM; it simply gets struck. What I believe it could be a power issue, or ground mismatch with the sensor device which communicates with RS-232. So I consider implementing watchdog here and see the result.
    – goddland_16
    Commented Apr 16, 2017 at 4:40
  • The watchdog doesn't necessarily reset the processor. It can call a watchdog ISR. Also it's worth noting that sometimes the issue is external hardware, like an SD card interface or an RFID card reader. Resetting the processor in these cases doesn't fix the underlying problem that the attached hardware is locked up. A totally independent watchdog might be useful, which completely powers down, and back up, the entire device (including peripherals).
    – Nick Gammon ♦
    Commented Apr 17, 2017 at 7:33
  • Agreed, the watchdog ISR has the option to RESET or raise an interrupt, whichever is necessary. Yes, the above case is equivalent to disconnect and reconnect power to the device and periperials again.
    – goddland_16
    Commented Apr 17, 2017 at 10:54

1 Answer 1

Reset to default
1

Most Arduino projects involve sensing the physical world or controlling the physical world (hopefully with some feed back). When sensing the physical world, it is best to add extra code to protect the project from locking up. And then, even more code concerned with what to do when the unlikely happens. Unfortunately, many projects leave out this extra code. Reasons vary:

  • The project is a prototype and the effort is thought necessary.
  • There is no time in the schedule to create this "extra code".
  • The unexpected event is thought to be an impossible situation.
  • There is no room left to add code that is not expected to run.

As an example:

A bicycle is outfitted with an Arduio base digital speedometer. Speed is calculated based on the period of a wheel mounted magnet passing a frame mounted Hall Effect switch. It works as long as the bicycle is moving at a reasonable speed. However, the program does not take into account what happens if the bicycle is not moving. If the magnet does not pass the Hall Effect switch. The program's period counter continues to count up. Eventually the watch dog timer reset the program. Over and over again.

Approaches to avoid lockup or to avoid using the watch dog timer:

  1. Place all "non-blocking" polling in an infinite loop which also check the elapsed time. Consider the amount of time allowed to make a successful reading. If that time expires consider a good course for the program to follow. For instance a warning to the user or a default value when the measured value is unavailable.
  2. Use interrupts. That is, use the above method, but relay on external signal changes to generate interrupts to set values and / or flags. This is a good (however more complex) alternative if the external signal occurs too fast for "non-blocking" polling.
Improve this answer
6
  • If you want a heavily studied heavily reviewed real world example of watch-dog-timers simply search the Internet using a term similar to: "toyota watchdog timer".
    – st2000
    Commented Apr 15, 2017 at 16:02
  • That seems a good explanation. Well any idea on how to implement in real code which are complex and don't return within 8 seconds timebound set by watchdog timers.
    – goddland_16
    Commented Apr 16, 2017 at 5:53
  • One approach, place all non-blocking polling in an infinite loop which also checks the elapsed time.... I'll add this to the answer.
    – st2000
    Commented Apr 16, 2017 at 13:37
  • Yes, these are the alternatives to using watchdog timer and a good understanding of code flow is mandatory for prevention of lockup.
    – goddland_16
    Commented Apr 17, 2017 at 4:43
  • Thanks to @st2000 it was a good understanding of what watchdog does. What I gather is when dealing with a time-critical situation, where a mistake would cost you a lot, it is a must to use watchdog as a failsafe. Most importantly the code should be deterministic in time, where the system or the programmer is aware of how much time every action takes to complete. Unlike in GSM, where a majority of the tasks are dependent on network quality, it will hard to make a deterministic call on time. Here is a good [ckecklist](criticaluncertainties.com/2013/11/13/…
    – goddland_16
    Commented Apr 17, 2017 at 4:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.