Hello,
I'd like my isr to get the line of code which had been Interrupted. This should help get the reason why the watchdog sometimes kicks in
Thank!
That's BASIC while Arduino uses C++.
Having others take a look at the source code may help you. Usually the watchdog barks if there are long running loops and stuff.
@DrDiettrich - thanks. ide numbers lines (if nicely requested)
@Danois90 thanks. Code is lengthy, practically impractical:)
Of course i can add, in the suspected sections (mostly involving the enet chip), to each instruction,
Trace=__LINE__;
and store trace to eeprom in the wd isr. but id rather find a way to do it in with due "elegance"
Have you disabled all compiler optimizations?
Have you enabled full stack frames?
@Coding_Badly -
No to both
In the preferences i only set to
compiler warnings: all
Should I? Why? Can you please send links explaining these two switches.
Also, i use Ethernet 2 libs because it's compatible with the ping I'm using.
You should allow to build up a full stack trace, showing all subroutines which are active when the interrupt occurs.
Interrupts have a priority. Higher priority interrupt may interrupt code for a lower priority interrupt's code. How will you keep track of that?
@Paul_KD7HB it may be that the watchdog interrupts an isr and not the faulty long loop or whatever slow code. The probability is low because my isrs are pretty short.
@DrDiettrich assume i know how to read the stacked program counter, how do i map it to the source code line?
Look up the function in the linker map. I don't know how line numbers are stored in which (debugger?) map.
That is the first step to reliably determining what was interrupted. Without those changes the problem can be insoluble.
Those two combined incur a significant performance hit.
The second step is address translation. You need a mapping from function address to function name. In the crudest form that will be a MAP file. In the finest form that will be debug information (often in the form of a binary file). The compiler and linker work together to create such files.
The third step is a stack dump. You need code that "walks the stack" outputting return addresses as it goes. Often times such things are included with a debug version of the runtime libraries.
The fourth step is to offload that data (the output from walking the stack). That could be output sent to Serial or an in-circuit debugger.
Finally, the data is used to determine the nearest function entry points.
But that's just the tip of the ice burg.
@Danois90 has offered sound advice and a much better use of your time.
Not usually possible with AVR Arduinos, and very improbable in other cases.
Keep in mind that with optimization, there is no requirement that the compiler produce code that executes "lines" in the order that you write them, and it may eliminate some "lines" entirely.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.