Help me understand this debugger behavior. - Page 1
Forum section: electronics / general

author: Dan Moos
author_rank: Frequent Contributor
timestamp: September 10, 2016, 07:06:47 pm
content: I just got an AVR Dragon, and I'm messing with debugWire.I'm using Atmel Studio 7 and an atmega328. All seems to be working well, although the hassle of switching between debugwire and programming mode is a bit annoying. My understanding is that that is a common complaint, so I won't go on about that.Anyway, here is the simple code snippet in question. I put an 'X' where debugger breakpoints are.While(1){X PORTB = 0b00000001;_delay_ms(500);X PORTB = 0b00000000;_delay_ms(500):X PORTB = 0b00000001;_delay_ms(500);X PORTB = 0b00000000;_delay_ms(500):}Ok, here's what happens when I run the debugger. On the first pass through the while loop, execution stops at every breakpoint, the LED attached to the relevant pin does what I expect, and the IO port view window tells me what I expect. All is good.But on every subsequent pass through the loop, the first breakpoint is ignored, and execution stops at the second one. It is only this one breakpoint that gets skipped. I made sure it was a generic, conditionless breakpoint like the others. In my first version, the redundant second half of the routine didn't exist. I added that to see if the behaviour had something to do with the code. The second half of the routine's breakpoints work as expected.So why would a breakpoint only work on the first pass through a loop?The only parameter I'm not super comfortable with is the clock speed I set the Dragon's interface to run at. I know it's supposed to be less than 1/4 of the target's clock speed, but that leaves allot of possibilities. Is there a more specific rule of thumb here? Is this possibly relevant to my issue? I'm running on the MCU's internal 8 mghtz clock btw.Finally, is there a way in atmel studio with debugWire to execute the code one statement at a time with a keypress, regardless of breakpoints?

author: obiwanjacobi
author_rank: Super Contributor
timestamp: September 11, 2016, 06:23:58 am
content: I always look at the .lst file to see what the compiler made of my code when I see the debugger jump around. The debugger follows asm not C/C++... It may help to turn down/off optimization (-O flags)...

author: jcosper
author_rank: Contributor
timestamp: September 17, 2016, 03:12:27 am
content: It's hard to tell, but the first stop is to look at the disassembler. That should give an idea of what is actually happening. I have seen the assembly match the functionality, but not what was written in the higher language. The optimizations would also mess with this, as suggested above.

author: tatus1969
author_rank: Super Contributor
timestamp: September 17, 2016, 07:49:37 am
content: +1 to disable all optimizations.

author: newbrain
author_rank: Super Contributor
timestamp: September 17, 2016, 10:18:21 am
content: Quote from: tatus1969 on September 17, 2016, 07:49:37 amDefinitely.Look at the compiler output with -O3:Code:00000372 <main>:372:c1 e0ldir28, 0x01; 1374:c5 b9out0x05, r28; 5376:64 efldir22, 0xF4; 244378:71 e0ldir23, 0x01; 137a:80 e0ldir24, 0x00; 037c:90 e0ldir25, 0x00; 037e:0e 94 80 01call0x300; 0x300 <_delay_ms>...8< 8<....39e:15 b8out0x05, r1; 53a0:64 efldir22, 0xF4; 2443a2:71 e0ldir23, 0x01; 13a4:80 e0ldir24, 0x00; 03a6:90 e0ldir25, 0x00; 03a8:0e 94 80 01call0x300; 0x300 <_delay_ms>3ac:e3 cfrjmp.-58; 0x374 <main+0x2>and note the target of the jump in the last line: since the value of r28 is known, the compile will skip the load.The breakpoint is set to the beginning of the equivalent C line, but the loop will jump right "in the middle".With -O0 the jump is at the beginning of the C line (and note the bloat for the port operation...):Code:PORTB = 0b00000001;3a2:85 e2ldir24, 0x25; 373a4:90 e0ldir25, 0x00; 03a6:21 e0ldir18, 0x01; 13a8:fc 01movwr30, r243aa:20 83stZ, r18_delay_ms(500);3ac:64 efldir22, 0xF4; 2443ae:71 e0ldir23, 0x01; 13b0:80 e0ldir24, 0x00; 03b2:90 e0ldir25, 0x00; 03b4:0e 94 80 01call0x300; 0x300 <_delay_ms>...8< 8<...PORTB = 0b00000000;3e2:85 e2ldir24, 0x25; 373e4:90 e0ldir25, 0x00; 03e6:fc 01movwr30, r243e8:10 82stZ, r1_delay_ms(500);3ea:64 efldir22, 0xF4; 2443ec:71 e0ldir23, 0x01; 13ee:80 e0ldir24, 0x00; 03f0:90 e0ldir25, 0x00; 03f2:0e 94 80 01call0x300; 0x300 <_delay_ms>}3f6:d5 cfrjmp.-86; 0x3a2 <main+0x8>