Post History
The problem with refreshing the watchdog from an ISR is that in case the main program hangs for whatever the reason, the ISR will keep living and could keep the watchdog alive, effectively blocking...
Answer
#4: Post edited
by
Lundin
·
2024-12-17T15:20:46Z (about 15 hours ago)
- The problem with refreshing the watchdog from an ISR is that in case the main program hangs for whatever the reason, the ISR will keep living and could keep the watchdog alive, effectively blocking the product from recovering from an error state, making the watchdog useless.
- It could leave GPIO or other hardware peripherals in an active state, which in turn could cause larger system-level problems.
Similarly, memory corruption bugs could tear down the variables that the ISR relies on and maybe that's why main() got stuck in some exception handler in the first place.- Best practices is not to mix up the watchdog with any application-tier functionality or error handling. Let it be an independent peripheral with the sole purpose to check if the program is still running.
- The utopia of best practices, which isn't always possible, is to only kick the watchdog once, at the top of the main loop:
- ```c
- void main ()
- {
- for(;;)
- {
- kick_dog(); // the only point in the program where we kick the dog
- /* rest of program */
- }
- }
- ```
- But of course before you get to the `for(;;)` you need to init a bunch of stuff which might be time consuming. So you might need to refresh the wdog a couple of times during that.
- In some cases you might need to do very time-consuming things in run-time like erasing flash and then you might need to refresh the dog before and after such an operation.
- It's also common practice to refresh the dog immediately after initializing it. Watchdog initialization should happen very early on, normally in the reset interrupt vector before you even initialize system clock and run the CRT code.
- The problem with refreshing the watchdog from an ISR is that in case the main program hangs for whatever the reason, the ISR will keep living and could keep the watchdog alive, effectively blocking the product from recovering from an error state, making the watchdog useless.
- It could leave GPIO or other hardware peripherals in an active state, which in turn could cause larger system-level problems.
- Similarly, memory corruption bugs could tear down the variables that the ISR relies on and maybe that's why main() got stuck in some exception handler in the first place. What if the problem is that runaway code or memory corruption bugs is overwriting `.bss` memory where the `watchdog_fed_events` variable is stored?
- Best practices is not to mix up the watchdog with any application-tier functionality or error handling. Let it be an independent peripheral with the sole purpose to check if the program is still running.
- The utopia of best practices, which isn't always possible, is to only kick the watchdog once, at the top of the main loop:
- ```c
- void main ()
- {
- for(;;)
- {
- kick_dog(); // the only point in the program where we kick the dog
- /* rest of program */
- }
- }
- ```
- But of course before you get to the `for(;;)` you need to init a bunch of stuff which might be time consuming. So you might need to refresh the wdog a couple of times during that.
- In some cases you might need to do very time-consuming things in run-time like erasing flash and then you might need to refresh the dog before and after such an operation.
- It's also common practice to refresh the dog immediately after initializing it. Watchdog initialization should happen very early on, normally in the reset interrupt vector before you even initialize system clock and run the CRT code.
#3: Post edited
by
Lundin
·
2024-12-17T15:08:11Z (about 15 hours ago)
- The problem with refreshing the watchdog from an ISR is that in case the main program hangs for whatever the reason, the ISR will keep living and could keep the watchdog alive, effectively blocking the product from recovering from an error state, making the watchdog useless.
- It could leave GPIO or other hardware peripherals in an active state, which in turn could cause larger system-level problems.
- Similarly, memory corruption bugs could tear down the variables that the ISR relies on and maybe that's why main() got stuck in some exception handler in the first place.
- Best practices is not to mix up the watchdog with any application-tier functionality or error handling. Let it be an independent peripheral with the sole purpose to check if the program is still running.
- The utopia of best practices, which isn't always possible, is to only kick the watchdog once, at the top of the main loop:
- ```c
- void main ()
- {
- for(;;)
- {
kick_dog(); // this is the only point in the program where we kick the dog- /* rest of program */
- }
- }
- ```
- But of course before you get to the `for(;;)` you need to init a bunch of stuff which might be time consuming. So you might need to refresh the wdog a couple of times during that.
- In some cases you might need to do very time-consuming things in run-time like erasing flash and then you might need to refresh the dog before and after such an operation.
- It's also common practice to refresh the dog immediately after initializing it. Watchdog initialization should happen very early on, normally in the reset interrupt vector before you even initialize system clock and run the CRT code.
- The problem with refreshing the watchdog from an ISR is that in case the main program hangs for whatever the reason, the ISR will keep living and could keep the watchdog alive, effectively blocking the product from recovering from an error state, making the watchdog useless.
- It could leave GPIO or other hardware peripherals in an active state, which in turn could cause larger system-level problems.
- Similarly, memory corruption bugs could tear down the variables that the ISR relies on and maybe that's why main() got stuck in some exception handler in the first place.
- Best practices is not to mix up the watchdog with any application-tier functionality or error handling. Let it be an independent peripheral with the sole purpose to check if the program is still running.
- The utopia of best practices, which isn't always possible, is to only kick the watchdog once, at the top of the main loop:
- ```c
- void main ()
- {
- for(;;)
- {
- kick_dog(); // the only point in the program where we kick the dog
- /* rest of program */
- }
- }
- ```
- But of course before you get to the `for(;;)` you need to init a bunch of stuff which might be time consuming. So you might need to refresh the wdog a couple of times during that.
- In some cases you might need to do very time-consuming things in run-time like erasing flash and then you might need to refresh the dog before and after such an operation.
- It's also common practice to refresh the dog immediately after initializing it. Watchdog initialization should happen very early on, normally in the reset interrupt vector before you even initialize system clock and run the CRT code.
#2: Post edited
by
Lundin
·
2024-12-17T15:07:35Z (about 15 hours ago)
- The problem with refreshing the watchdog from an ISR is that in case the main program hangs for whatever the reason, the ISR will keep living and could keep the watchdog alive, effectively blocking the product from recovering from an error state, making the watchdog useless.
- It could leave GPIO or other hardware peripherals in an active state, which in turn could cause larger system-level problems.
Similarly, memory corruption bugs could tear down the variables that the ISR relies on and maybe that's why main() hang in some exception handler in the first place.- Best practices is not to mix up the watchdog with any application-tier functionality or error handling. Let it be an independent peripheral with the sole purpose to check if the program is still running.
- The utopia of best practices, which isn't always possible, is to only kick the watchdog once, at the top of the main loop:
- ```c
- void main ()
- {
- for(;;)
- {
- kick_dog(); // this is the only point in the program where we kick the dog
- /* rest of program */
- }
- }
- ```
- But of course before you get to the `for(;;)` you need to init a bunch of stuff which might be time consuming. So you might need to refresh the wdog a couple of times during that.
- In some cases you might need to do very time-consuming things in run-time like erasing flash and then you might need to refresh the dog before and after such an operation.
- It's also common practice to refresh the dog immediately after initializing it. Watchdog initialization should happen very early on, normally in the reset interrupt vector before you even initialize system clock and run the CRT code.
- The problem with refreshing the watchdog from an ISR is that in case the main program hangs for whatever the reason, the ISR will keep living and could keep the watchdog alive, effectively blocking the product from recovering from an error state, making the watchdog useless.
- It could leave GPIO or other hardware peripherals in an active state, which in turn could cause larger system-level problems.
- Similarly, memory corruption bugs could tear down the variables that the ISR relies on and maybe that's why main() got stuck in some exception handler in the first place.
- Best practices is not to mix up the watchdog with any application-tier functionality or error handling. Let it be an independent peripheral with the sole purpose to check if the program is still running.
- The utopia of best practices, which isn't always possible, is to only kick the watchdog once, at the top of the main loop:
- ```c
- void main ()
- {
- for(;;)
- {
- kick_dog(); // this is the only point in the program where we kick the dog
- /* rest of program */
- }
- }
- ```
- But of course before you get to the `for(;;)` you need to init a bunch of stuff which might be time consuming. So you might need to refresh the wdog a couple of times during that.
- In some cases you might need to do very time-consuming things in run-time like erasing flash and then you might need to refresh the dog before and after such an operation.
- It's also common practice to refresh the dog immediately after initializing it. Watchdog initialization should happen very early on, normally in the reset interrupt vector before you even initialize system clock and run the CRT code.
#1: Initial revision
by
Lundin
·
2024-12-17T15:05:23Z (about 15 hours ago)
The problem with refreshing the watchdog from an ISR is that in case the main program hangs for whatever the reason, the ISR will keep living and could keep the watchdog alive, effectively blocking the product from recovering from an error state, making the watchdog useless.
It could leave GPIO or other hardware peripherals in an active state, which in turn could cause larger system-level problems.
Similarly, memory corruption bugs could tear down the variables that the ISR relies on and maybe that's why main() hang in some exception handler in the first place.
Best practices is not to mix up the watchdog with any application-tier functionality or error handling. Let it be an independent peripheral with the sole purpose to check if the program is still running.
The utopia of best practices, which isn't always possible, is to only kick the watchdog once, at the top of the main loop:
```c
void main ()
{
for(;;)
{
kick_dog(); // this is the only point in the program where we kick the dog
/* rest of program */
}
}
```
But of course before you get to the `for(;;)` you need to init a bunch of stuff which might be time consuming. So you might need to refresh the wdog a couple of times during that.
In some cases you might need to do very time-consuming things in run-time like erasing flash and then you might need to refresh the dog before and after such an operation.
It's also common practice to refresh the dog immediately after initializing it. Watchdog initialization should happen very early on, normally in the reset interrupt vector before you even initialize system clock and run the CRT code.