If the problem is repeatable it will help a tremendous amount. The debug process can be addressed if you have a couple of key embedded development tools available. These tools would include a digital oscilloscope and two spare GPIO pins on your processor. In the absence of two spare pins it is often possible to temporarily re-deploy two in-use pins for the purpose of the debug exercise.
The method of debug is one of divide and conquer to discover what section(s) of your code are in use when the errant reset happens. The first step involves adding code in your startup routine that sets one of the spare pins as an output and to a logic level that will then get changed back to default when the MCU goes back into reset. This GPIO will be used as a trigger for your digital scope such that the "end trigger mode" will be used. It is possible that you may already have an I/O in your system that can serve as this trigger event. In some cases the WDT reset may also appear directly visible on the MCU reset pin. If either of these latter cases applies then you can use that instead of having to add use of this first GPIO pin.
The next step is to set the other spare GPIO pin as an output and then set it to its non default level followed by setting it back to to the other state within a specific branch of your program code. The common method for most MCUs is that GPIO pins default to inputs after reset so a external pullup is installed to keep the pin high whilst it is still an input. Your test code would then set the pin as an output to low and then after a time later in the code branch set the output to a high level.
Re-compile, link and load the test version of the code. Now you put the scope to "end trigger" on the occurrence of first mentioned GPIO which will signal that the errant WDT reset has happened. Have the other GPIO on a second channel of the oscilloscope. Then start up your system and wait till the errant reset happens. If you notice that this second GPIO sets low and back high before the trigger event then you will know that the WDT event did not happen within the branch of code where you added the handshake signal. On the other hand if this second GPIO returns to its default state in conjunction with the WDT reset then you know that the guilty code is somewhere between the two places in the code where you set and cleared the handshake signal. (Note that if you do not see the second GPIO handshake at all on the scope then you know that particular branch of code was never even entered and thus probably not the guilty region of the code).
When evaluating the scope traces do take note that the WDT reset will happen some time before the scope trigger happens due to the fact that you setup the scope trigger GPIO in the code execution just after the code has re-started. You will need to evaluate how much delay there is here on your MCU and in your system so that you can accurately judge whether the second signalling GPIO happens to clear at WDT reset time or earlier in time. Practice runs can help to fine tune the technique.
The investigation process now involves moving the setting and clearing of the second GPIO handshake around in various parts of your code execution path to try to isolate the specific parts of the code that are involved with the problem. If you find a branch that is suspect you can then narrow down the area of focus....i.e. "divide and conquer".
One very nice thing about this technique is that the setting and clearing of the signalling GPIO takes very little execution time on the processor and so does not have a serious impact on the real time performance of time critical code. There are other debugging techniques available but they all generally involve much greater execution overhead than the described technique.
