cancel
Showing results for 
Search instead for 
Did you mean: 

WWDG early wake interrupt to prevent reset

StefanR
Associate II

Hi,

I have a question regarding the possibilities and best practises of the early wake interrupt generated by the window watchdog.

Is it possible to use the EWI to refresh the watchdog? And if so, is it actually a good idea and reliable?

To describe the reason why I am asking briefly:

I receive data over UART in fixed intervals, which refreshes the watchdog under normal conditions. If no data is received after a certain time I assume the connection is faulty, set a failsafe/timeout flag and refresh the watchdog. This would be triggered by the EWI and should not happen under normal operating conditions, it is purely a failsafe measure.

Technically no reset is necessary or even wanted in this case. I know that this should be realised with a normal timer interrupt, but I am using all of the timers for something else. I could probably make this work with the RTC or a capture compare interrupt from timer 1, but ideally I do not want to use the same timer for two different functionalities as the prescaler and counter period are dictated by the other function and might change. So I basically am trying to get one more "independent" timer interrupt out of limited hardware.

It strikes me as something that is probably not best practise and THIS post has me concerned about reliability, which is why I am asking. Thanks for your answers in advance!

 

Cheers,

Stefan

1 ACCEPTED SOLUTION

Accepted Solutions
STM_Thirty2
ST Employee

While it does deviates from typical usage patterns for watchdog timers, which are traditionally used to recover from software faults that lead to infinite loops or other issues preventing the watchdog from being refreshed, if it works out for you and you do not have any instances where there may actually be an early watchdog refresh event or you were not using it anyways then i dont see why not. 

Have you considered perhaps sharing Systick with Hal Tick and implementing a software timer of sorts, albeit somewhat low resolution. As long as you keep things light in the the isr its not a terrible idea top share timers.

If you feel a post has answered your question, please click "Accept as Solution"

View solution in original post

3 REPLIES 3
StefanR
Associate II

After getting back to my hardware I tested this. It is is certainly possible to refresh the watchdog in the EWI, but the question if it is a good idea still remains.

The priority of EWI is the highest of course and can most likely stay that way in my case.

STM_Thirty2
ST Employee

While it does deviates from typical usage patterns for watchdog timers, which are traditionally used to recover from software faults that lead to infinite loops or other issues preventing the watchdog from being refreshed, if it works out for you and you do not have any instances where there may actually be an early watchdog refresh event or you were not using it anyways then i dont see why not. 

Have you considered perhaps sharing Systick with Hal Tick and implementing a software timer of sorts, albeit somewhat low resolution. As long as you keep things light in the the isr its not a terrible idea top share timers.

If you feel a post has answered your question, please click "Accept as Solution"
StefanR
Associate II

Thanks Eddie!

I did not think about implementing a software timer, even thought that should be more than good enough for what I am doing here. I will keep that in mind for next time!

I have set the window to be the same length as the watchdog itself, so an early refresh should not be a problem. Under normal circumstances the watchdog gets refreshed every time a valid packet is received over the UART.