Hi Jeremy,
I appreciate that you and others are looking into putting the watchdog to good use, but most use cases break horribly when you would need the watchdog timer most. See below.
On 16.04.2008 17:55, Jeremy Jackson wrote:
On Wed, 2008-04-16 at 17:33 +0200, Carl-Daniel Hailfinger wrote:
Please avoid any POST code toggling. There are POST boards out there which display the last n POST codes and make it a lot easier to follow the code path. Once you add POST code toggling, that history is flushed away really fast.
Perhaps a config option? The same function/inline/macro could be put in the code, but de-toothed as far as toggling, for those with a fancier POST card.
We have some places where we output POST codes in a tight loop in a die() function (or whatever it is called). Coupling watchdog timer reset with outputting POST codes makes sure that the machine will NEVER reboot on serious errors and we might as well disable the watchdog altogether.
Toggling aside, the original idea was, to point out there is one thing which pokes "keepalive" info already, and perhaps it's just a matter of directing that poke to include the TCO timer.
What is the longest amount of time between any two POST code updates? The only think I can think of is ECC ram clearing.
One hour, probably longer. A payload is not guaranteed to poke the TCO timer, so as long as the payload is running, the TCO timer could fire in theory.
To be honest, I care mostly about v3, so if there is no strong opposition to this in v2, I won't authoritatively veto it although I think even risking an interrupt before we can handle it is bad design.
However, once that code comes anywhere near v3, expect it to explode badly, especially when the machine is already unable to boot and loads recovery code over serial. Do not expect us to sprinkle watchdog pokes all over the codebase in v3.
Regards, Carl-Daniel