Tintin does not have a hardware-based reset mechanism like Time-series devices do, and so it can end up as a brick if one turns off all the power-consuming apparatus and walks away. As such, we need to implement an absolutely bombproof one of our own. I suggest the following:
Configure the WDT for about a two to four second timeout.
Have the watchdog timer thread feed the watchdog about every 500ms or so. Ensure that the watchdog is running when we enter the watchdog timer thread; if the watchdog timer has ticked an unexpected amount, or is not enabled, turn on the watchdog and reset immediately.
The watchdog timer thread should do a buttons check that ultimately filters down to a special HAL interface (still needs mutual exclusion from the OS). The buttons check in the HAL should do two things:
One, it should do an "integrity check" on the buttons GPIO. That is to say, it should write some pull-up or pull-down registers on the buttons, ensure that they change on a readback, and then write them back to their original value (and for good measure, read them back, and see if the rest of the button GPIO is configured appropriately). If this fails, the check fails safe -- i.e., indicates that a vulcan nerve pinch is happening.
Two, it should check to see if a vulcan nerve pinch is being pressed.
If a vulcan nerve pinch is underway, the watchdog timer thread should simply refuse to feed the watchdog on that cycle.
This should result in a Tintin that can always be rebooted, no matter how wedged the OS is -- and, as a result, a Tintin that should be more brick-resistant.
Tintin does not have a hardware-based reset mechanism like Time-series devices do, and so it can end up as a brick if one turns off all the power-consuming apparatus and walks away. As such, we need to implement an absolutely bombproof one of our own. I suggest the following:
This should result in a Tintin that can always be rebooted, no matter how wedged the OS is -- and, as a result, a Tintin that should be more brick-resistant.