Programatically cause a break while debugging?

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With other debuggers I have always used debug break statements in the source code to good advantage, e.g.

if (i<0) Debugger("i<0 you idiot!")

which halts the program and breaks into the debugger to display the message. I have been expecting to find something similar in AVR studio but now I am beginning to think it isn't there. If not, how would you get a similar effect without manually marking all the breakpoints? Calling a single subroutine would allow just one breakpoint but requires tedious display of the calling string in memory and then stepping back to the caller to get the context.

Also, using JTAG-ICE on hardware isn't the program flash rewritten every time you toggle a breakpoint? I wouldn't worry so much about hardware debugging if I could write all the breakpoints in an initial flash (the simulator RS232 output to hapsim can be painfully slow).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well most C compilers support assert() and in the assert handler you could put an:

asm("BRK");

which hard codes a debugger break.

The only thing is what comms channel were you hoping the "i<0 you idiot!" would be transported over? There certainly isn't a comms channel from the AVR direct to the debugger unless you count the OCDR->IDR mechanism that no one ever seems to have been able to make work on any AVR (but that just transports a numeric code from 0x00 to 0x7F)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
The only thing is what comms channel were you hoping the "i<0 you idiot!" would be transported over? There certainly isn't a comms channel from the AVR direct to the debugger unless you count the OCDR->IDR mechanism that no one ever seems to have been able to make work on any AVR (but that just transports a numeric code from 0x00 to 0x7F)

You could have a pointer to the debug string pushed on the stack, and the debugger could pop it and read memory to display the message. That is similar to how the old Macintosh debugger worked. No UART would be required, much faster in the simulator, and no hapsim window taking up monitor real estate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well it doesn't have such functionality but clearly yo ucan follow a stack backtrace and find the location of the failing assert() so the use of an explanatory message is moot anyway as you can see it in context. Alternatively you could just have assert() output a message over something like an LCD or UART channel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What I used to do was zip through a series of debug breaks showing various parameters, and then stop at the final break where the code (i.e. my logic) was screwing up. I could refer to the scrollback for all the parameters and not have to remember everything. With RS232 in the simulator that would take forever, and my battery chargers don't have RS232 anyway. Too bad Studio doesn't have a window for this kind of debug message protocol, I think it would be a great addition.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dak664 wrote:
Too bad Studio doesn't have a window for this kind of debug message protocol, I think it would be a great addition.
There are several things that the debugger is missing that would be incredibly useful. What you gave is one. I would dearly love to get a symbolic stack trace. I understand that register naming (useful for assembly folks) is showing up in Studio 4.17.

In some cases, the issue is not the debugger, per se, but the JTAG protocol set up by Atmel. If you want a message to come up from a debug break, it would need to be supplied by the debugger based on the break address, not supplied by the JTAG link itself.

I suspect that the real answer here is to get a dedicated set of folks together and to start building the Debugger Of Our Dreams ("DOOD"). Unfortunately there is already an avr-dude, so that acronym is for naught. Still, I am beginning to think that leveraging Eclipse or some such other open-source effort may be the right answer.

*sigh* I guess we are getting what we are paying for here. We've already chosen cheap - see my signature. :lol:

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!