Can not set breakpoint

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

Setup:

Atmel-ICE debugger

AtmelStudio 7.0.1417

ATmega328P, customer board 8MHz, NO Clock DIV / 8

debugWire interface

 

I can't set breakpoints.  I've tried everything I know to do:

1) Started a new project.

2) Reset power to the board.

3) Set the clock DIV /8 to slow the processor to 1MHZ

4) Clean build ("Rebuild" or "Clean" + "Build Solution")

 

I know my code is being loaded into the target because I can make my LED's blink at different rates.  It's like the debugger can't see my source code and doesn't have the debug database in order to step to the lines.  I don't understand what's going on.

 

Error Screen Shot

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

From the looks of your screenshot you are running the session.  You must set breakpoints before you start a debug session, or when paused.

 

Stop the debug session, and try setting the breakpoint, THEN start the session and see what happens.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Jim thanks for your reply,

The breakpoint was set before I started debugging.  Further, it doesn't matter if I "Start Debugging" or "Start Debugging and Break".  Neither will allow me to hit breakpoints or step through code.  Start&Break stops at the "board_init()" function and I can't step past that.  It's like the debugger gets confused at that point and can no longer find my code.

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

Apparently there is no code generated for this line. Show us your code.

Last Edited: Thu. Oct 12, 2017 - 11:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MarekJ71 wrote:

Apparently there is no code generated for this line. Show us your code.

 

I'm pretty sure that it's not optimized out.  I've tried every line in the code and none of them will hit.  This particular line, shown in the screen shot, is a function call which looks at the int provided and sets one of my LED's either on or off according to the "on" bool.  I'm fairly certain that's not being optimized out.  

 

However, I'll zip up my code and upload it later today.

 

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

What happens in the simulator?

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

clawson wrote:

What happens in the simulator?

 

That's a great question...I've never used the simulator so I don't actually know!  I'm assuming you mean I should select the "simulator" tool as my debug tool.  I'll give that a shot and report back.

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

I would look at the disassembly view and see if/where a breakpoint was (can be) set.

  • Debug / Start Debugging and Break (Alt+F5)
  • Debug / Windows / Disassembly  (Alt+8)

 

 

Edit: typo

 

 

David (aka frog_jr)

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

Yup, the reason for suggesting simulator is to split the issue. At the moment it could be hardware or the ICE or something. Or it could be optimisation or a fault in the debug info. For the latter things the same would be seen with simulator. For the former the simulator will work. So it helps to isolate the issue.

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

jgmdesign wrote:
From the looks of your screenshot you are running the session.  You must set breakpoints before you start a debug session, or when paused.

I don't know if the same applies to AVR, but with SAM I found that trying to set a breakpoint while running would mess up the whole breakpoint system - you would have to exit & restart the whole debug session to get it back "in sync"

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

lonpalmer wrote:
I'm pretty sure that it's not optimized out.

How did you come to this "pretty sure" conclusion? Are you guessing, or have you actually inspected the generated code?

 

lonpalmer wrote:
stops at the "board_init()" function and I can't step past that. 

Can you step into it? (For sure, if there inside that function is e.g. a loop that won't terminate then you won't get any further.)

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:

lonpalmer wrote:
I'm pretty sure that it's not optimized out.

How did you come to this "pretty sure" conclusion? Are you guessing, or have you actually inspected the generated code?

 

lonpalmer wrote:
stops at the "board_init()" function and I can't step past that. 

Can you step into it? (For sure, if there inside that function is e.g. a loop that won't terminate then you won't get any further.)

 

I'm pretty sure because I'm unable to set a break point at any line of code, as was stated earlier.  That's not the issue.

 

I can step into "board_init()" which was added by AVR when I imported libraries.  That function is completely blank, it doesn't do anything.  It does import some headers which may set some defines but I think that's about it.  When I step out of the code it can't step to my next statement which sets the IO pin direction.  

 

Quick Edit:  I can step into board_init() only if I "Start Debugging and Break", not if I just "Start Debugging".

 

 

 

Last Edited: Thu. Oct 12, 2017 - 06:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you attach the .lss file from the build to a post here? (It will reveal at least parts of your source code, so if that is proprietary and not for public eyes then don't post it).

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

lonpalmer wrote:
I'm pretty sure because I'm unable to set a break point at any line of code, as was stated earlier. That's not the issue.

???  How does that tell you it wasn't optimized away?!?

 

(the optimizing compiler might also re-order chunks, which may make breakpoint setting hard)

 

JohanEkdahl wrote:
Can you attach the .lss file from the build to a post here?
+1.  At least from enough around the problem area to give context.

 

As mentioned, can you set a breakpoint earlier and step through the problem area?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

JohanEkdahl wrote:

Can you attach the .lss file from the build to a post here? (It will reveal at least parts of your source code, so if that is proprietary and not for public eyes then don't post it).

 

Sure.  It will be later this evening when I get home but I'll be glad to.

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

theusch wrote:

lonpalmer wrote:
I'm pretty sure because I'm unable to set a break point at any line of code, as was stated earlier. That's not the issue.

???  How does that tell you it wasn't optimized away?!?

 

(the optimizing compiler might also re-order chunks, which may make breakpoint setting hard)

 

JohanEkdahl wrote:
Can you attach the .lss file from the build to a post here?
+1.  At least from enough around the problem area to give context.

 

As mentioned, can you set a breakpoint earlier and step through the problem area?

 

As I mentioned earlier, I can "Start Debugging and Break" and step only in to the first function which was placed by AVR Studio "board_init()" which is a blank function (nothing in the fuction).  I can not step to the next line, or any line.

 

If the compiler can optimize the entire code base away such that you can't step through it at all and can't break on any line then I'd call that not very useful.  I don't know if you're correct, it sounds very suspect.  As I stated, not a single line of mine can be broken on in any code file (there are about 6).

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

lonpalmer wrote:
It's like the debugger can't see my source code and doesn't have the debug database in order to step to the lines.

I'm not a GCC+Studio guru.  I guess that might be possible with certain combination(s) of toolchain options?

 

Start Debugging and Break.  Then switch to Disassembly View?

 

With a simple test program, I guess also that the optimizer no longer "needs" the source code?  "on" in a register; setLED() inlined; ...

 

the LSS, and then maybe the makefile and the build log, will tell more.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

So I tried the simulator and the exact same thing happened.  I was unable to hit my breakpoint.  However, this time it didn't complain that I COULDN'T hit my break point.  It just never landed on any break point that I set.

 

I've uploaded the entire project folder.  Thanks everyone, for their help.

Attachment(s): 

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

Take away -Wl,-mrelax from the linker arguments and check the 'Relax Branches' checkbox under Common/General and all is dandy... (also, why have you added -fdata-sections under 'Other optimizations' when that's checked just below?)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

meolsen wrote:

Take away -Wl,-mrelax from the linker arguments and check the 'Relax Branches' checkbox under Common/General and all is dandy... (also, why have you added -fdata-sections under 'Other optimizations' when that's checked just below?)

 

Thank's for your advice!  I'm afraid I'm a bit new at this so I'm not sure, exactly, where to "take away..." from the linker arguments.  As far as "other optimizations" I have no idea how that might have gotten checked.  AFAIK That's how the project was set up from the start.

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

In the project settings => Toolchain, find AVR/GNU Linker ?> Miscellaneous and remove everything in the box. 

 

I'm attaching the project (with the changes and optimization set to O0). Once you are comfortable, change the optimization level to O1 and see that all the function calls in your main function is inlined (Look at the code and the lss file side by side).

Attachment(s): 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

OK I found it and tried it and it didn't work.  Same problem as before...

 

However, I did find something that DID work but I'm perplexed as to why.

 

If I comment out board_init() I can step through the code with out any problems!  board_init() is a completely blank function placed into my project by ASF project wizard.  That function is declared "extern" in another header file and implemented in "init.c" as blank.  I'm really shocked that it's causing the debugger not to be able to step debug the project.  Did I do something wrong?

 

 

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

BTW you don't need to study the LSS to find out where you can/can't set breakpoints.

 

While viewing the C in the debugger right click it and select "Goto Disassembly" (which is a misnomer because it really means "Goto mixed C and disassembly view"). You now see the lines of C and around them the AVR opcodes they have generated. This does two things:

 

1) you can see which lines are not generating any code because of optimisation - without code you clearly can't set breakpoints on them

 

2) you can actually position your breakpoints to be "opcode accurate". So if one line of C generated 300 opcodes (could happen!) then you can pick the exact place in the sequence to position the breakpoint. If doing it at the C (statement) level you only get to choose to put breaks on the opening of the sequence

 

Personally (even x86 Windows programs sometimes!) I tend to debug in the mixed C+Aseembly view a lot of the time so I have a clearer view of what's going on.

 

Also if you switch to a new micro architecture it's one of the fastest ways I've found to learn a new assembly language. Watch the C doing some stuff - which opcodes does it pick and if you step them individually (with opcode manual alongside) to see what they do.

 

BTW, when in the mixed view "step" does indeed mean "one opcode" not "one whole C statement" at a time.

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

meolsen wrote:
(also, why have you added -fdata-sections under 'Other optimizations' when that's checked just below?)

Well, go back to the first post -- OP [in all probability] didn't "add" anything -- he let Studio make a new project for him.

 

meolsen wrote:
Take away -Wl,-mrelax from the linker arguments ...

I'm not a GCC guru, but remember a thread from a couple/few years ago where to poster was told to "relax" more.

 

clawson wrote:
While viewing the C in the debugger right click it and select "Goto Disassembly" (which is a misnomer because it really means "Goto mixed C and disassembly view"). You now see the lines of C and around them the AVR opcodes they have generated. This does two things:

...which I mentioned earlier.  From the first screenshot, OP tried that but couldn't do it when running.  Thus, I suggested doing it at the initial break.

 

Now to satisfy curiosity, gotta dig into that .ZIP ...

 

No source lines in the .LSS for main() ?  Dunno what that means.  I can't tell -O level from the generated code.

int main (void)
{
  92:	f3 df       	rcall	.-26     	; 0x7a <board_init>
  94:	21 9a       	sbi	0x04, 1	; 4
  96:	c0 e0       	ldi	r28, 0x00	; 0
  98:	d1 e0       	ldi	r29, 0x01	; 1
  9a:	cc 23       	and	r28, r28
  9c:	11 f0       	breq	.+4      	; 0xa2 <main+0x10>
  9e:	29 9a       	sbi	0x05, 1	; 5
  a0:	01 c0       	rjmp	.+2      	; 0xa4 <main+0x12>
  a2:	29 98       	cbi	0x05, 1	; 5
  a4:	cd 27       	eor	r28, r29
  a6:	66 e5       	ldi	r22, 0x56	; 86
  a8:	78 e5       	ldi	r23, 0x58	; 88
  aa:	84 e1       	ldi	r24, 0x14	; 20
  ac:	90 e0       	ldi	r25, 0x00	; 0
  ae:	e6 df       	rcall	.-52     	; 0x7c <__portable_avr_delay_cycles>
  b0:	f4 cf       	rjmp	.-24     	; 0x9a <main+0x8>
	bool on = false;
	while(true)
	{
		ioport_set_pin_level(IOPORT_CREATE_PIN(PORTB, 1), on);
		on = !on;
		delay_ms(1000);

	}

It isn't real obvious to me where "on" is toggled.  Are "bool" operations 16-bit?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Fri. Oct 13, 2017 - 02:10 PM