0
\$\begingroup\$

The CPU on my embedded linux system (Armada 370) does have a hardware watchdog. It does not appear to have any way of checking at bootup time whether the bootup is a normal cold boot or a reset from a watchdog timeout (does not have a reset cause register).

Given this limitation, can anyone think of how I can determine if a hw watchdog timeout event occurred?

\$\endgroup\$
5
  • \$\begingroup\$ if it's linux, it will be in the logs somewhere. \$\endgroup\$ – KyranF Feb 15 '16 at 19:07
  • \$\begingroup\$ @KyranF I'm not sure that it's possible to log the WDT reset. It's possible to log other causes of reset, though. A WDT reset would manifest itself as an absence of log entry, because it comes without warning to a stuck system. \$\endgroup\$ – Nick Alexeev Feb 15 '16 at 19:12
  • \$\begingroup\$ @NickAlexeev I say this, because the kernel would have access to the internal registry which may have the power failure reason flag set for the WDT. Then the kernel can log (only on boot, of course) that it has suffered from a WDT related power event. That's my take on it anyway, I do not know. In simpler systems like a little 8-bit AVR you can read the system flags directly to work out if you have just suffered a brown-out or power failure and set/reset the flags yourself. Obviously a linux system is in control of that not the user \$\endgroup\$ – KyranF Feb 15 '16 at 19:15
  • \$\begingroup\$ @user411180, you are writing "It does not appear to have any way of checking at bootup time whether the bootup is a normal cold boot or a reset from a watchdog timeout." Do you mean that you weren't able to find the API for reading the cause of reset, or that the silicon doesn't have the register for cause of reset? \$\endgroup\$ – Nick Alexeev Feb 15 '16 at 19:22
  • 1
    \$\begingroup\$ Does not have a reset cause register. \$\endgroup\$ – SeanLabs Feb 15 '16 at 19:27
2
\$\begingroup\$

If the capability to detect reset type is not built into your system then you will have to modify the system design to provide that information. One way that this can be done is to design in a flip-flop into the circuitry. It needs to be configured in such way that it gets set by a power up event and then have a means for the software to read the state of the flip-flop and allow the software to clear the flip-flop. You can use this as a scheme to identify a reset as an initial startup reset. All other resets would happen and this flip-flop would not be set.

Another approach would be to disable the watch dog timer (WDT) on the processor and deploy an external watch dog timer component that has a watch dog timeout state bit that would be accessible and clearable by software.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ I agree with the idea of using an external WDT which you can interface with and know for sure. \$\endgroup\$ – KyranF Feb 15 '16 at 19:16
  • \$\begingroup\$ Good suggestion, board design is already done however (I put this requirement in the spec., the vendors claimed it was met, but it wasn't). So any solution will have to work without additional hardware. \$\endgroup\$ – SeanLabs Feb 15 '16 at 19:20
  • \$\begingroup\$ @user411180 In that case, tell us what hardware you happen to have got. Is the question about electronics design or about Linux's handling of WDT reset? \$\endgroup\$ – Nick Alexeev Feb 16 '16 at 1:36
  • \$\begingroup\$ For the watchdog the board uses the Armada's internal hardware watchdog only. \$\endgroup\$ – SeanLabs Feb 16 '16 at 2:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.