Go Down

Topic: How to use the Watchdog properly (Read 7789 times) previous topic - next topic

AlexanderB

Hi,

I am new to Arduino and spent hours of reading now.

For my RC project (controlling the four motors of a radio controlled plane) I have to make sure that the system is most reliable. The software will be somewhat complex so I want to make sure that the systems keeps working if I failed in the s/w design and it hangs.

That's where a watchdog jumps in.

I now read that under certain conditions the watchdog can lock up the system entirely since it may jump in during the bootloader on and on again thus preventing the system from starting at all.

I didn't get now if this is an issue where one shouldn't use the watchdog at all?

What is the way to safely use the watchdog?

Cheers and thank you very much
Alexander

retrolefty

You just need to use a bootloader that is compatible with watch dog operation. I think the standard Arduino bootloader is still not compatable. However there are bootloaders that are compatable, the ADAfruit bootloader works nice. http://wulfden.org/TheShoppe/freeduino/ADABOOT.shtml

AlexanderB

Thank you very much.

So does that mean that I connot / should not use the watchdog with the original bootloader?

I also read that it would be possible to programm the bootloader with another Arduiono. Is that true do you (or anyone else) have instructions on that. I do have an Duemilenove and a Nano (both 328).

Thank you very much.

retrolefty

So does that mean that I connot / should not use the watchdog with the original bootloader?

That is true. If the bootloader doesn't handle watchdog generated resets correctly it's possible to get the bootloader trapped into a tight loop that it can't escape from, causing continuous resets.

I also read that it would be possible to program the bootloader with another Arduino. Is that true do you (or anyone else) have instructions on that. I do have an Duemilenove and a Nano (both 328).

Yes there is a sketch available that turns a standard Arduino board into a ICSP programmer. However it just burns the standard bootloader into the target chip. There would have to be further modifications done in the IDE files to utilize a different bootloader to be burned into the target. I use a standalone hardware programmer to burn HEX files into target chips.

Lefty



AlexanderB

Thank you Lefty,

sorry (and almost embarassing) to ask: but what do I have to by and to to programm a new bootloader to the Duemilenove or the Nano?

Is there a cheap solution?

Thank you!

retrolefty

Quote
Is there a cheap solution?


It's not that there aren't cheap solutions avalible (includeing buy a processor chip with a WDT compatable bootloader installed for $6), but more about the detail steps needed depending on the specific chip and files and procedures required.

There is lots of information on bootloaders and programmers on the arduino site ( http://www.arduino.cc/playground/) . I'm just not confident enough to give you a step by step guide. The nano being a soldered in chip would not be a good candidate for learning the steps require, in case you 'brick' the bootloader. While I have burned my own bootloaders into mega8, 168 and 328 chips, I have never used the watchdog timer in any of my programs so would rather you get advice and recommendations from someone here who has direct experiance with using the WDT.

Lefty

Marco_Benini

Hi all,
late post, but could be usefull for others.
Take a look at optiboot bootloader http://code.google.com/p/optiboot/ , it includes also the modifications introduced by Adafruit.

There are also files to copy in Arduino IDE subfolders, so You'll find the "new" Optiboot boards in the list of the boards when uploading the sketches.

It can be uploaded using another Arduino as bridge.

Ciao. Marco.

udoklein

@Alexander: if maximum reliability is the goal you might want to consider this: http://www.eetimes.com/discussion/break-point/4024509/Li-l-Bow-Wow.

It implies the use of a dedicated watchdog. This could be done with an ATiny or similar cheap chip. I would not try to implement the watchdog in the software of the main processor for exactly the reasons stated in the article. A dedicated watchdog also allows for much simpler implementation of the dog.

Udo
Check out my experiments http://blog.blinkenlight.net

retrolefty

#8
Aug 23, 2010, 08:44 pm Last Edit: Aug 23, 2010, 08:48 pm by retrolefty Reason: 1
Quote
What is the way to safely use the watchdog?


It really comes down to the risk/consequences of failure. I worked in the process control industry (oil refinery) and critical systems almost always used external hardware WDT circuits to shutdown plants or at least place them into a safe condition. Relying on the system to be monitored to generate/react/initiate a safety action is a pretty fundamental design error in my opinion. But again it comes down to the risk threat and consequence of failure, and only you can make that determination. That eetimes article link gave a good example of a what happens if the crystal clock source fails (vibration or bad solder joint, etc) on a microprocessor, the WDT function would also fail to function.

Lefty

udoklein

#9
Aug 23, 2010, 08:53 pm Last Edit: Aug 23, 2010, 09:04 pm by udoklein Reason: 1
One more link that goes a little bit deeper into details http://www.ganssle.com/watchdogs.pdf. And of course I second the opinion of Lefty the referred authors. Unless there are some very tight budget constraints the watchdog should be an external self contained device and not a software function.

By the way: this is why I spend an additional controller for the power button in my current design. If the main controller hangs I want to be 100% sure to be able to shut the whole circuit down by means of the power button. Of course I could make a mistake in the code of the power button controller but chances are pretty small. It contains not to many lines. The main controller on the other hand contains >10klocs hence it has good chances to contain some bugs that might make it run astray.

Udo
Check out my experiments http://blog.blinkenlight.net

mpeuser

#10
Aug 23, 2010, 10:20 pm Last Edit: Aug 23, 2010, 10:28 pm by mpeuser Reason: 1
To build anything "more stable" is fine!

Professional safety analysis first tries to analyse the hazards involved, i.e.
- What is the exact kind of issue you expect?
- How high is the likelihood of its occurance?
- What are the consequences if it occurs?
Without a good answer to all three questions all well meant counter actions are vague..

A watch dog timer can identify the failure of a specific function, which can be caused by hardware OR by software issues.

Now, what to do in both of that cases? A simple reset is fine if you  assume the problem has occured by a coincidence of rare events, hardly to be expected again in near future.

But what, if the cause is a fatal hardware issue? So a reset will help little, and there is not much difference with or without reset.

You have a quite different situation, when you need to enter a fail safe state in case of a no longer controllable situation. In that case - and only in that case - is external hardware mandatory. This hardware CAN try to reset the original function but in addition has to provide alternative means if this function cannot be revived.

A second microcontroller is adaquate for this. Of course it has to contain a little bit more intelligence than just resetting the master :-)

The advantage of an external microcontroller which does nothing (!) but try to reset the master is somewhat dubious.

I understand well that you are discussing the failure of the internal watch dog function. This is called "double error" and - if rare - is often not considered, except if the cost of a potential demage multiplied with its likelihood will justify the additional effort.

In this special Arduino case the failure of the internal watchdog however is assumed to be deterministic rather than probabilistic. You just have to look to find out!!

To say: I doubt that the internal watchdog works reliable, so I design an external watchdog, is fine and understandable, however not very rational.

udoklein

@Alexander: AVR132 http://www.atmel.com/dyn/products/app_notes.asp?family_id=607 gives details on watchdogs.

@deSilva: I do not get you point. Do you argue for or against external watchdogs in the situation of the OP? IMHO the OP should use an external watchdog. Of course not because he does not know how to setup the internal watchdog but because the cost vs. risk assessment tells that the small cost of the external watchdog justifies it. The risk is an out of control model plane that might go full throttle out of control and crash in a spectacular way. The cost is a cheap piece of hardware plus some ad hoc board design. On the other side the software part becomes simpler and thus cheaper.

Udo
Check out my experiments http://blog.blinkenlight.net

Go Up