Atmel Studio 7 while(1) loop does not repeat

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
int main(void) {

  // -------- Inits --------- //
  DDRB |= 0b00000011;
  //cli();
    int8_t i = 0;




        while (1)
{
    PORTB = 0b00000001;          /* Turn on first LED bit/pin in PORTB */
                    //_delay_ms(50);                                           /* wait */
                
     PORTB = 0b00000010;          /* Turn off all B pins, including LED */
                    //_delay_ms(50);  
}
    

  return 0;                            /* This line is never reached */
}

I don't understand why in the debugger mode, it stops at the end of the while loop and never repeats. If I place a breakpoint at the start of the while loop, then it repeats, otherwise it hangs. In assembly everything works just fine.

This topic has a solution.
Last Edited: Fri. Jun 26, 2020 - 01:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Right click, "goto disassembly" then continue stepping. You will see:

 

 

alternating with:

 

 

and then

 

 

and this will keep repeating. So it definitely is doing the two OUTs (and then an RJMP) each time.

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

But, while stepping in the C code, it still hangs on the last line in the while loop, and never jumps back. Actually it repeats once, and then remains on the last line in the while loop, repeating the same instruction.

Last Edited: Fri. Jun 26, 2020 - 12:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try:

Debug / Start Debugging and Break

Debug / Windows / Disassembly

 

Now use F11 to step through the code shown in the disassembly window...

 

 

Edit: Apparently I was late to the party...blush

 

David

Last Edited: Fri. Jun 26, 2020 - 12:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it works normally in assembly. I can't understand why it's not doing the same in the C file?

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

Please try to do it in the C file. You will see, it will hang in that loop, and never jumps back at the beginning.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

What optimization level are you using, -Og should be used for debugging! 

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

ki0bk wrote:

What optimization level are you using, -Og should be used for debugging! 

 

Jim

Yup, I confirm the C steps as expected in -Og optimization.

 

(does kind of make you wonder why Atmel default "Debug" to -O1 not -Og in fact?)

 

PS in -Og build the code is:

	while (1)
	{
		PORTB = 0b00000001;          /* Turn on first LED bit/pin in PORTB */
  80:	81 e0       	ldi	r24, 0x01	; 1
  82:	85 b9       	out	0x05, r24	; 5
		//_delay_ms(50);                                           /* wait */
		
		PORTB = 0b00000010;          /* Turn off all B pins, including LED */
  84:	82 e0       	ldi	r24, 0x02	; 2
  86:	85 b9       	out	0x05, r24	; 5
  88:	fb cf       	rjmp	.-10     	; 0x80 <main+0x6>

so it keeps doing LDIs inside the loop. With -O1 (and above) it is:

	while (1)
	{
		PORTB = 0b00000001;          /* Turn on first LED bit/pin in PORTB */
  80:	91 e0       	ldi	r25, 0x01	; 1
		//_delay_ms(50);                                           /* wait */
		
		PORTB = 0b00000010;          /* Turn off all B pins, including LED */
  82:	82 e0       	ldi	r24, 0x02	; 2



	while (1)
	{
		PORTB = 0b00000001;          /* Turn on first LED bit/pin in PORTB */
  84:	95 b9       	out	0x05, r25	; 5
		//_delay_ms(50);                                           /* wait */
		
		PORTB = 0b00000010;          /* Turn off all B pins, including LED */
  86:	85 b9       	out	0x05, r24	; 5
  88:	fd cf       	rjmp	.-6      	; 0x84 <main+0xa>

so the LDIs are now optimised out of the loop.

 

So to peek at what's going on inside costs a bit of performance. Schroedinger unfortunately lost a cat this way once !

Last Edited: Fri. Jun 26, 2020 - 01:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you so much Jim and to all!

Last Edited: Fri. Jun 26, 2020 - 01:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Do note the penalty you pay for buying the ability to get the debugger to step it so you probably want a "better" optimization setting for the final code you plan to use.

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

(does kind of make you wonder why Atmel default "Debug" to -O1 not -Og in fact?)

Simply because Og came long after the other O levels, and ... well, never been a huge impetus for change (i.e it is difficult to guarantee that (wrong) code today wont break if we default from 01 to Og, if they rely on timing requirements that O1 keeps at the moment, but Og does not...)

:: Morten

 

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

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

I don't use -Og because of the problem already written.
I have been using nop for a long time.

 

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

Probably  ali6e7 should spend some time reading-up on compiler optimisation,  and the things that need to be borne in mind both when writing code and when debugging - as these are very common issues, not specific to AVR or GCC.

 

Here's a starter for ten:  

 

https://www.avrfreaks.net/forum/tutcoptimization-and-importance-volatile-gcc

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...