AVR-Chat

> From: wagnerj@proaxis.com
> ....
> I think this is an inherent limit due to JTAG debugging. You don't get
> history information out of JTAG. ....

Hi Jim, 

As I think someone pointed out, I'm not interested in an 'execution history' (i.e.:
what I would call 'tracing') but rather a display showing the current function call
chain that resulted in reaching the current code location.  I use this all the time
in MS Visual C# for my Windows code.  You can even set your context in any of the
callers to examine variables, etc.

I have very limited (aka: about zip) knowledge of how WinAVR constructs the frame
markers so I don't know if the data is even available without help from the symbols
or somehow adding to the code emitted by the compiler for call/return.

I was very familiar with these issues on the machine that I spent most of my carrier
on (Tandem Computers, Non-Stop I, Non-Stop II, and TXP) including writing debuggers,
etc. (even found a bug in one of the machine's hardware instructions) but, to my
discredit, I have let WinAVR shield me from this and other processor specifics on
the AVRs - hanging my head in shame ... :-)


> From: Don Kinzer
> ....
> Breakpoints aren't particularly useful for debugging some types of realtime
> systems ....

The problem I seem to run into a lot is when (in AVRStudio) when I do a 'step out'
of a function, I find myself in an interrupt handler.  I would have expected the
debugger to set a breakpoint at the return code location contained in the stack
frame and run but apparently it's doing something else (single-stepping out?).
Oddly enough, it doesn't seem to happen if I single-step (F10) out of the function.


> From: wagnerj@proaxis.com
> ....
> I have handled this (trace) by implementing a "real time trace buffer". I write
> certain information into the buffer (a constant indicating the function
> identity, and perhaps a key variable), and maybe a key variable on exit.
> It has been crucial to debugging protocol state machines for me.

Depending on the situation I'll just do 'wait loop' writes to the UART or, if timing
is more sensitive, do the writes via a circular buffer to an interrupt-driven UART
send function.  I haven't dealt with anything yet whose timing couldn't stand the
addition of the later - but I know such cases exist ...

As I mentioned in my other email, I'm evaluating Code::Blocks and CodeLite.  If
anyone has had experience with extensions available for either of these that
supports dealing with the FreeRTOS data structures in the debugger (Task lists,
TCBs, etc.) I'd appreciate hearing about them - even ugly, home grown, unsupported
stuff :-)
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844 http://www.whitetrout.net/Chuck