Using the WDT interrupt

[joao_ribeiro]

Hi,

We are facing and issue in our code that triggers the Watch Dog. It only occurs, sometimes after an afternoon, but sometimes after a hole weekend. Therefore we must figure out a way to identify the issue and maybe the WatchDog Interrupt may be a good help here.

We have enabled the interrupt and it is being triggered, although due to the fact that it only runs for a few clock cycles, we are not able to use for instance the FLASH_Program functions as we normally use to store out config value permanently.

How can we store a variable while WD interrupt is running? What should be stored that could help us the most in figuring out where is the code issue? Maybe the stack pointer? Is there a recipe to help finding this issue as we have for the hard faults in the MCUxpresso?

We have also confirmed that the WDT is being triggered as the WDOG_GetResetCount is being incremented.

Thank you for the help.

Regards

[joao_ribeiro]

Just to add that we are using a MK64FN1M

[Miguel04]

Hi @joao_ribeiro 

Is there more information you could provide us?

I'll look into your question and more details could be usefull.

Best Regards, Miguel.

[joao_ribeiro]

Hi @Miguel04 .

thank you for the reply.

Hope this info helps.
Here are our config of the WDT

And we are reseting the WD timer each 2 s and it is working fine.

In the last code version we started to have a issue some where in the code that is being reseted by the WD as we can see the WD counter being incremented.

In an attempt to find where is the blocking code issue we want to extract more info about the position that the WD had its trigger therefore allowing to find the real issue routine. With this in mind we hoped that we could read the Stack Pointer or other value so that it could reveal a hint on were is the code being blocked. 
And here is the question for the community in how should we use the WD interrupt to record anything that could help us and how to record it.
Here is the interrupt handler 

Regards

[Miguel04]

Hi @joao_ribeiro 

Thanks for the information.

I'll look more into the WD interrupt handler, to verify if you can use it to save the stack pointer on the falsh, meanwhile I suggest another way to troubleshoot your project, you could send messages or logs with f.e. with UART, that mention you in which routine or state your project is, an the last state you recieve is where the WD interrupt is reseting.

I'll let you know what I found.

Best Regards, Miguel.

[joao_ribeiro]

Hi @Miguel04 

Thank you for the suggestion.

In fact we tried the serial print solution, but it slowed out process and therefore interfered with the rapid flow.

Actually we found the infinite loop that was triggering the WD: we disabled the WD and ran the code in debug mode while having the debugger connected to the micro controller. The hope was that the issue would appear, got the device stuck in the infinite loop and by using the debugger and the MCUxpresso we could pause the running code and see where the code was. So we let the device ran and eventually it got into the while and we figured the issue.

But it would be very helpful if we could use the WDT interrupt to store more info of a future infinite loop. Our project is always evolving and it may need this helpful tool to debug the device running.

For instance we got an IO pin toggle in the WDT interrupt just to test if the interrupt would be triggered after a WDT reset and it was, but the main question remains: what should be stored for future analyses in such a few number of clock pulses?

Looking forward to see what would be your outcome after your research .

Thank you for the support

Regards

[Miguel04]

Hi @joao_ribeiro 

I've been looking and I was not able to find an exact answer to your your question. This is something you will have to test by yourself, if the GPIO toggles you are mentioning occur without any further problem this could work but the program counter must be saved before the interrupt to know in which routine or task is failing, something like the log messages I commented before.

However, did you try the printf() functions or the UART? serial prints functions require more instructions than "one byte write" from the uart.

Regards, Miguel.