AS6 + JTAGICE3 weird breakpoint crashes

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

Hi All,

I've had a few problems debugging an XMEGA256A3B this morning using a JTAGICE3 in AS6. First up, I've found a few places through my code where I can insert breakpoints on C statements that are never hit, but moving the breakpoint a little in the disassembly makes it work. For example, I've got a code snippet like

	if ((int16_t)s->v > max_v)
		max_v = s->v;

and setting a breakpoint on the 'if' statement never gets hit. Looking at the ASM, I've got

00006BFA  CPI R18,0xC5		Compare with immediate 
00006BFB  LDS R19,0x3C26		Load direct from data space 
00006BFD  CP R18,R24		Compare 
00006BFE  CPC R19,R25		Compare with carry 
00006BFF  BRGE PC+0x05		Branch if greater or equal, signed 
00006C00  STS 0x3C25,R24		Store direct to data space 
00006C02  STS 0x3C26,R25		Store direct to data space 

and AS6 puts the breakpoint at 6BFA. If I move the breakpoint to 6BFB or later, works no worries.

This I could see as being an odd but harmless(ish) effect of optimisation or something, I've learned before not to completely trust debugging optimised code.

It gets worse though.

The next code snippet looks like

	double acc_mag = (double)(s->acc.x_a);

which partially disassembles to

000069B6  PUSH R29		Push register on stack 
	double acc_mag = (double)(s->acc.x_a); /*) +
000069B7  MOVW R30,R24		Copy register pair 
000069B8  LDD R22,Z+1		Load indirect with displacement 
000069B9  LDD R23,Z+2		Load indirect with displacement 

If I put a breakpoint before the MOVW it works fine. If I put a breakpoint on or after that instruction, or try and single-step over it, AS6 times out waiting for CallStack->getChild. After this event, I have to re-open AS6 and power cycle both my JTAGICE3 and the target board.

These are far from the only points in my code that do one of these things, it's turned debugging in to a hell of a minefield. Anyone seen this before? Any ideas what the deal is (apart from "don't debug with optimisation" :) )?

I'm using AS6.0.1863 under Win7 if it makes a difference.

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

I faced similar issue once, when I had selected wrong device for building the project.

:)

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

mailtosarathy wrote:
I faced similar issue once, when I had selected wrong device for building the project.

:)

Wouldn't the JTAG flash load error out in this case - chip signature disagrees that the selected chip in the project IDE?

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

Heh, would that it be so simple, everything here points correctly to the XMEGA256A3B :)

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

Quote:

This I could see as being an odd but harmless(ish) effect of optimisation or something, I've learned before not to completely trust debugging optimised code.

I agree wit the first one that it's almost certainly an optimisation effect as I explained in:

Optimisation and the importance of volatile in GCC

That CPI R18,0xC5 is probably part of some other statement (actually I wonder about the code generation - isn't any setting of flags it makes going to be immediately over-ridden by the next CP/CPC sequence?!?)

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

clawson wrote:
Quote:

This I could see as being an odd but harmless(ish) effect of optimisation or something, I've learned before not to completely trust debugging optimised code.

I agree wit the first one that it's almost certainly an optimisation effect as I explained in:

Optimisation and the importance of volatile in GCC

Nice link, thanks :)
Quote:
That CPI R18,0xC5 is probably part of some other statement (actually I wonder about the code generation - isn't any setting of flags it makes going to be immediately over-ridden by the next CP/CPC sequence?!?)
Yeah I thought it odd too.. Actually I just noticed that the byte immediately previous to that CPI isn't able to be decoded as an instruction and the one before that is a JMP - perhaps it's just two bytes of data mixed in to the instruction stream? Anyway, easy enough to set the breakpoints in the ASM if there's any doubt.

I'm guessing my other problem is to do with the execution of the

 PUSH R29 

instruction somehow changing the stack in such a way as to confuse AS6's relatively new call stack recovery, but I'll have to look closer to see what's going on there. It's a shallow call-path and there's virtually no on-stack allocations, so I wouldn't imagine it's a simple overrun..

-S.

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

mailtosarathy wrote:

Quote:
Quote:
I faced similar issue once, when I had selected wrong device for building the project.

Wouldn't the JTAG flash load error out in this case - chip signature disagrees that the selected chip in the project IDE?

I think I had created the project in ImageCraft for some 8 bit device and in Atmel Studio I used Open Object file for debugging there I had selected wrong device by mistake, If I remember right I used simulator so I did not get the signature error.

As the side effect the break points where not properly set when I set the breakpoint in assembly it worked.
(My mistake).

:)

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

I've seen (and reported) an occasion where the debug info generated by the compiler placed a source code line in the middle of a 4 byte instruction, resulting in bp never being reached. This could also confuse the JtagIce3.

In these cases it's probably best to place the breakpoint in the disassembly view on a known good address.