Go Down

Topic: Watchdog in Arduino Library - or at least support by bootloader (Read 33266 times) previous topic - next topic

gerrievanzyl

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

Nick Gammon

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.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

bperrybap


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.


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

Nick Gammon

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.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

drjiohnsmith

is it just me

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



bperrybap


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

Nick Gammon


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.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

bperrybap



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

westfw

Quote
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.)


Kralj5


I tried testing my simple sketch on page 1 of this thread. It works up to a point, but I must have the "bad" bootloader. Does anyone have a link to one that definitely fixes the watchdog issue? (For the Mega 2560).


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?

Nick Gammon

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.

http://www.gammon.com.au/forum/?id=11635
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

westfw

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. :-(
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.

bilica


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

Thanks!

Go Up