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.