Pages: 1 2 3 [4]   Go Down
Author Topic: Watchdog in Arduino Library - or at least support by bootloader  (Read 30173 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Global Moderator
Offline Offline
Brattain Member
*****
Karma: 485
Posts: 18771
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged


Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 67
Posts: 2702
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Global Moderator
Offline Offline
Brattain Member
*****
Karma: 485
Posts: 18771
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged


Offline Offline
Sr. Member
****
Karma: 4
Posts: 327
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

is it just me

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


Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 67
Posts: 2702
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Global Moderator
Offline Offline
Brattain Member
*****
Karma: 485
Posts: 18771
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged


Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 67
Posts: 2702
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 133
Posts: 6752
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?
Logged

Global Moderator
Offline Offline
Brattain Member
*****
Karma: 485
Posts: 18771
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged


SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 133
Posts: 6752
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Offline Offline
Jr. Member
**
Karma: 1
Posts: 68
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


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

Thanks!
Logged

Pages: 1 2 3 [4]   Go Up
Jump to: