Watchdog in Arduino Library - or at least support by bootloader

Nick,
re: Regarding "
Tested on the Mega2560 board once I replaced the bootloader with this working one:

https://raw.github.com/arduino/Arduino-stk500v2-bootloader/master/goodHexFiles/stk500boot_v2_mega2560.hex"

Do you know if this is the bootloader in the Arduino 1.04 IDE release?

I've been battling dropped ethernet connection on my webserver application for weeks. It occurs anywhere from hours to days. The application continues to run, but over time, a client will not be able to connect. I have a Mega2560 and want to implement watchdog timer based on your example. The code verifies, but I haven't uploaded it yet to test based on the comments on this post (the need to replace the bootloader)

Is your recommendation of the bootloader you specified still valid? Any help is appreciated.

Thanks,
Rich

There seem to be two booloader files shipping with 1.04 namely:

// File =  Mega2560-prod-firmware-2011-06-29.hex
// Loader start: 3E000, length: 8192
// MD5 sum = 1E 35 14 08 1F 65 7F 8C 96 50 69 9F 19 1E 3D F0 

// File =  stk500boot_v2_mega2560.hex
// Loader start: 3E000, length: 8192
// MD5 sum = D9 E6 6B 4E D1 A6 11 2C 61 8F 9B D5 5D 24 E2 13

However neither has the MD5 sum of the one that I found to work namely:

// File =  stk500boot_v2_mega2560_fixes_watchdog_problem.hex
// Loader start: 3E000, length: 8192
// MD5 sum = 8A F4 7A 29 43 A0 D8 7C DB ED 09 A3 8F 40 24 1E

I would still recommend the "fixed" one from:

https://raw.github.com/arduino/Arduino-stk500v2-bootloader/master/goodHexFiles/stk500boot_v2_mega2560.hex

Nick, thanks for your reply. Ummmm... how do I actually load this? Using the Arduino IDE under tools->Burn Bootloader ? Obviously from my question I've never done this and would appreciate pointing me in the right direction. Is there documentation you could site? All I could find in http://arduino.cc/en/Guide/Environment using IDE tools->Burn Bootloader is:
"Ensure that you've selected the correct board from the Boards menu before burning the bootloader."

Thanks in advance.
Rich

You need an external device. A board can't burn its own bootloader. If you have a second Arduino one option is the sketch described here:

Using the IDE you also need another device, such as another Arduino with the "Arduino as ISP" sketch on it, or a programmer like USBtinyISP or similar. These are available from places like Adafruit, Sparkfun, eBay, etc.

Nick, thanks for your reply. I do have another Arduino ( Uno, rev 3). I reviewed the sketch you specified in your reply. To other readers... Nick's reply is more then just a sketch, it's a tutorial on how to burn a new bootloader using a second arduino.
Question: before doing this, is there any harm in testing the sketch you listed on page 1 with my existing bootloader? If my bootloader (by chance) were correct, I would get the results listed on page 2 ,your Reply #22 . If not, what will occur? It won't brick my Mega will it? What happened when you ran with the "bad" bootloader, Reply #20?
I'm asking because of FernandoGarcia 's reply #25 "I uploaded these examples in my arduino mega 2560 and was a fight to get remove them." as well as RetroLefty's post #29 example code comment: "Note that current arduino mega boards will fail this test and brick". Yikes!
To restate my environment: Mega2560, Arduino IDE 1.0.4

thanks
Rich

richsp51:
Question: before doing this, is there any harm in testing the sketch you listed on page 1 with my existing bootloader? If my bootloader (by chance) were correct, I would get the results listed on page 2 ,your Reply #22 . If not, what will occur? It won't brick my Mega will it? What happened when you ran with the "bad" bootloader, Reply #20?

First, there are ways around a "bricked" processor, particularly this type of bricking. The problem is that the sketch runs, sets up the watchdog timer, and the watchdog then interrupts the bootloader.

The trick is to not let the sketch run. You power the board off completely, hold down reset, keep holding down reset you apply power (plug the USB cable in). At this stage the sketch hasn't run (you have reset held down). Now with a free hand (this can be the tricky bit) you start uploading a fresh sketch. As it starts to upload you release reset (and not before), and the bootloader kicks in, without having the watchdog timer enabled.

Or, you simply use things like my bootloader uploader to simply replace the bootloader which has the side-effect of erasing program memory, and thus erasing the problem sketch. So you have two ways around it.

pls check this:

Arduino Mini 328
no delay() befero wdt_enable(), and one wdt_reset() just after wdt_enable() and another wdt_reset() in first line in loop();

like this:
void setup()
{
wdt_enable(WDTO_4S);
wdt_reset();
}
void loop()
{
wdt_reset ();
while(1)
{
//user loop
}
}

Nick,

Is there a source that documents which Arduinos have what bootloader?

Specfically, I would like to know whether a standard Leonardo will work with a watchdog timer?

Thanks so much
Gerrie

The bootloader in use doesn't really affect whether or not you can use the watchdog timer.

The only problem is some bootloaders (particularly the Mega earlier ones) don't work too well if the watchdog fires while it is booting.

The Leonardo has a watchdog timer.

I believe this is misleading.
The issue I've seen on the older bootloaders is that if the watchdog actually "fires" (causing a watchdog reset),
the bootloader didn't properly clear the watchdog reset state which
ended up causing an infinite watchdog reset loop.
It did not matter when/where the the initial watchdog fired.
This was definitely true in the m168/m328 bootloader..
It was a simple 1 line fix to the bootloader code but the Arduino team never fixed it.
(I patched all my bootloaders)
The optiboot bootloader, which is now used, does not have this issue.

If the bootloader has this issue, it is not possible to use the watchdog timer
beause if the watchdog ever actually occured (causing a watchdog reset),
the sketch would never restart because of the watchdog reset error in the bootloader.

--- bill

That's what I was trying to say. The watchdog works, but the way the bootloader interacts with it doesn't. This particularly applies to a "reset" watchdog, not an "interrupt" watchdog.

is it just me

or is it sad that the arduino team did not implement the one line fix

drjiohnsmith:
is it just me

or is it sad that the arduino team did not implement the one line fix

Kind of,
But the newer optiboot bootloader which is now being used is better since not
only does it not have the issue, but it is smaller so there is now more
room for application code.

--- bill

drjiohnsmith:
is it just me

or is it sad that the arduino team did not implement the one line fix

No software is perfect when it is released. As far as I know recent versions fix known bugs. Known at the time, that is. There is always going to be some lag between when a bug is discovered and when it is fixed. First the bug needs to be confirmed. Then a fix devised. Then the fix tested to make sure it doesn't introduce other, unexpected, side-effects. Then the fixed software is rolled out to the production line that is making the gadgets in the first place.

Well, at least let's be a little more open/honest here.
There were many bugs/issues (some even self inflicted by the team itself) that the team simply
refused to fix even when it was clearly pointed out and a drop in solution was offered.
More recently things are getting better, but for a few years, things were pretty bad
and got very heated at times.

The best example of a total screw up was when the team consciously and intentionally decided
to break 100% of the existing 3rd party libraries between the final 1.0 release candidate
and the final official 1.0 release.
In normal s/w development practices, you just don't do something like that.
(have years of working code, and then break it all between a release candidate and the final release)
This broke years of compability and stability. The team knew this was going to be an issue
and against many pleas from 3rd party developers proceeded anyway
even though there were some very simple alternatives that offer backward comptibilty to
to the vast majority of existing 3rd party.

Think about that again for a moment. This was not a bug, it was not an "oops" or
an untended consequence. The team knowingly and consciously decided
that it was a good idea to break 100% of all the 3rd party libraries in existence.
They thought that breaking all the libraries was a way to force the 3rd party developers
to all update their code for the new way of doing things.

Even after a couple of years since the 1.0 release, we are still fighting issues with this decision
and yet they still refuse to include some backward compability header files to allow
most of the pre 1.x libraries to work on 1.x

--- bill

Specfically, I would like to know whether a standard Leonardo will work with a watchdog timer?

The leonardo bootloader DOES include a "wdt_disable()" call, and DOES terminate early (running the user sketch) in the case of a WDT-caused reset, so you should be able to use the WDT however you want in a sketch, without any problems (except that the sketch will not be able to notice that it was restarted by the WDT.)

I am having mega 2560 board with "bad" bootloader. I am asking myself, if I can solve the problem with non-disabled watchdog by bootloader with this trick?
Can I add "wdt_disable();" before a "wdt_enable (WDTO_8S);" in a void setup (WDT will be set to 4 or 8s to ensure that bootloader will load completely)?. Will this trick do the job?

I doubt it. My tests showed that with the bad bootloader even a long watchdog time didn't help much. I think it might change the watchdog time-out to something short, the watchdog then immediately fires, it reboots, and it does the whole thing again.

I recommend upgrading the bootloader, it can be done simply enough.

Theory (and the datasheet) says that the watchdog control register is reset to the default value of zero (except for the Enable bit) on a reset, which would mean that a freshly reset chip is always operating with the minimum timeout. :frowning:
I think that's silly; if you're going to remember that the WDT is running, you should remember other things about it as well; but it does make sense from a HW perspective, and seem to match observed behavior.

Does anybody know if the Arduino Yun has a "good" bootloader ? The Yun supposedly has a Leonardo inside...

Thanks!