Hi, We're using the hardware watchdog on /dev/watchdog to ensure that the board reboots in case there is an issue with our board / software. The idea is that we poll the watchdog every 30 seconds, and if for some reason the software fails to do that we expect the board to reboot. We've verified this by stopping our software and ensuring that the board reboots. Now, on some occasions (and we're not able to reproduce this), we've notice that the boards somehow gets stuck and doesn't respond anymore (no network connectivity, no response via the serial console, no response from keyboard / screen). What we also see is that during the time the board is down (or crashed), nothing gets written to any logfiles (no dmesg / syslog / other logfiles get written to). It's as if the thing is completely frozen. The board remains powered throughout this period. The only way to get out of this situation is to perform a reset or power down / power up. We assume that the /dev/watchdog is a hardware watchdog and should always be able to recover. However this doesn't seem to be the case. So , I have 2 questions : What is the way to solve this issue What would be a good way to reproduce such a scenario ? (to ensure that a potential fix works). Thx.
I assume it is enabled because when we stop writing to /dev/watchdog the board reboots. Or am I missing something ?
I'm also seeing this : Code: dmesg | grep -i watch [ 2.466486] imx2-wdt imx2-wdt.0: IMX2+ Watchdog Timer enabled. timeout=60s (nowayout=1) Does this mean that the hardware watchdog is enabled ? Ot is it possible that this refers to a software watchdog ?
hehe ... would be great if you could get in touch with something who knows a little bit about these internals. We assume we're running with the hardware watchdog now but we have boards that get stuck. Would be great if we would be able to reproduce this somehow and find a solution for it.
I've been told it's hardware-enabled. Page 2 UDOO QUAD Schematics: U117 and U4 implement the watchdog function
Any idea under what circumstances the UDOO could hang despite having the hardware watchdog in place ? What we see is the board is powered but isn't doing anything (no logging takes place, and no connectivity can be established (through network / serial / screen). Our SW writes to /dev/watchdog every 30 seconds (and logs that operation in a logfile as well). We assume our SW at this point hangs as well (as we see no logging after we reboot the device for the whole period the system hangs). Despite the HW watchdog, no reboot is taking place.
Sorry to hijack a thread. There isn't much information about how the APX watchdog is implemented and this seems like a good place continue a request for watchdog information. I am using u-boot to load standalone programs and cannot disable the watchdog. It's a bit annoying to deal with the watchdog while I am debugging. Attached is my modified uboot-imx/examples/standalone/hello_world.c program that illustrates my problem. When I use the enable_watchdog() and reset_watchdog() functions, the program works. I added the blinking LED on GPIO40 just to make sure the timer loop is actually executing. It blinks as expected. When I comment out the enable and reset functions and use the disable_watchdog() the program will execute for about a second (~3 blinks) followed by a UDOO reboot. I'm assuming that my code is not disabling the APX watchdog. So my question is: How do I disable the watchdog timer for standalone programs? Apparently the watchdog is disabled when a linux kernel is loaded but I cannot find where that happens. Thanks.