I keep hitting a virtual watchdog timeout in my code, and I have no idea where it is timing out. The watchdog is set for quite long (about 2 or 3 seconds), and I hit the watchdog fairly often.
Is there any way of knowing at what point the system timed out? I have tried putting printf’s at the start and end of each routine, but then my software doesn’t work at all as it is very heavily comms based and by calling all these printf’s the comms timing gets messed up.
Any help would be really appreciated.
The thing I would try is to create a global (and therefore static) variable which you don’t initialize. Set up your code to print it’s value on startup of the code. Then insert assignments of different values to this variable in different routines in your code. Possibly even more than one in a long function. Then after the watchdog reset occurs, the print statement you added at startup will tell you which of these assignments was the last one executed. You should see if this value is coming out consistently on repeated lockups, and if so, you’re on the right track. You now have an area of code to look at and see if there are any loops or delays that could be getting locked up. Perhaps if you have a lot of communications, your code could be waiting for something it expected and getting hung up there.
This technique has minimal impact on operational timing, but can help narrow down were to look in this type of situation. Most likely, your code is getting locked up somewhere and although you may normally be servicing the watchdog regularly, once locked that may no longer be the case. One other thing that may cause a symptom like this is having interrupts get disabled, or getting lost within an ISR (which effectively does the same thing). Keep this in mind when looking over your code. If you still can’t find it you can add more to assignments to narrow it down further since you now have an idea of the area with the problem. Hope this helps.
Thanks alot, that’s a good idea. will give it a try.