Why does compiler optimization flag cause function definitions other than main() to break program in AVR ATMega C code?

Question

I am using avr-gcc and avrdude to write programs onto an ATMega8515 micro-controller. I have got the blinking LED program working without a hitch. However, when I started to use interrupts and introduce functions other than main() to the code, I came across bugs. Though I could compile the program and write it onto the chip, it did not run as expected - the LEDs that should have been blinking were completely unresponsive. With tweaking I found out that the introduction of any function, not just an interrupt service routine, caused this issue.

I came across near identical issues here:

https://stackoverflow.com/questions/65427371/why-does-my-isr-declaration-break-my-program

"Now, none of the LEDs blink. Even weirder, none of them blink when I remove the sei(). The only way I've found to make the first LED blink again is to comment out the ISR declaration"

And here:

AVR ATmega32 - C - Gets stuck in function call

"it's just the same statements as before, moved to the pulse_init() function. When I upload this code the timer is set up correctly and the output pulse is OK, but the program never starts blinking the LEDs on PC0..1."

To be clear, these are the commands I am using to compile and write the code to the ATMega:

avr-gcc main.c -O2 -o main.elf
avr-objcopy main.elf -O ihex main.hex
avrdude -c usbasp -p m8515 -U flash:w:"main.hex":a

And this is a sample code snippet that does not work:

#ifndef F_CPU
#define F_CPU 1000000UL // 16 MHz clock speed
#endif

#define __AVR_ATmega8515__
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

volatile uint8_t toggle_blinking = 1;


int main()
{
    sei(); /* set global interrupt enable */
    MCUCR = 0b00000100; /* Set the INT1 to trigger on any logic change*/
    GICR = 0b10000000;
    DDRC = 0xFF; // Makes PORTC as output
    DDRD=0xe0;

    
    while(1)
    {
        if(toggle_blinking)
        {
            PORTC = 0xFF; //Turns ON All LEDs
            // _delay_ms(500); //1 second delay
            // _delay_ms(500); //1 second delay

        }
        else
        {
            PORTC= 0x00; //Turns OFF All LEDs
        }
    }
}

ISR(INT1_vect)
{
    toggle_blinking ^= 1;
}

The common denominator between all of these programs (mine, and the two linked above) is the use of the avr-gcc optimization flag (-O) which is there to ensure that the util/delay.h functions run correctly. I compiled a program which did not work with the optimization flag again, this time without the optimization flag. And sure enough, the program worked.

To clarify, I am not sure whether other function definitions are "breaking" the program, or if they are just being run instead of main(). Here is the object dump when running running avr-objdump -d main.elf on the .elf file that was generated by compiling the above program with optimization enabled:

    00000000 <__ctors_end>:
    0:   10 e0           ldi     r17, 0x00       ; 0
    2:   a0 e6           ldi     r26, 0x60       ; 96
    4:   b0 e0           ldi     r27, 0x00       ; 0
    6:   ea e6           ldi     r30, 0x6A       ; 106
    8:   f0 e0           ldi     r31, 0x00       ; 0
    a:   03 c0           rjmp    .+6             ; 0x12 <__zero_reg__+0x11>
    c:   c8 95           lpm
    e:   31 96           adiw    r30, 0x01       ; 1
    10:   0d 92           st      X+, r0
    12:   a2 36           cpi     r26, 0x62       ; 98
    14:   b1 07           cpc     r27, r17
    16:   d1 f7           brne    .-12            ; 0xc <__zero_reg__+0xb>

      00000018 <__vector_2>:
    18:   1f 92           push    r1
    1a:   0f 92           push    r0
    1c:   0f b6           in      r0, 0x3f        ; 63
    1e:   0f 92           push    r0
    20:   11 24           eor     r1, r1
    22:   8f 93           push    r24
    24:   9f 93           push    r25
    26:   80 91 60 00     lds     r24, 0x0060     ; 0x800060 <__data_start>
    2a:   91 e0           ldi     r25, 0x01       ; 1
    2c:   89 27           eor     r24, r25
    2e:   80 93 60 00     sts     0x0060, r24     ; 0x800060 <__data_start>
    32:   9f 91           pop     r25
    34:   8f 91           pop     r24
    36:   0f 90           pop     r0
    38:   0f be           out     0x3f, r0        ; 63
    3a:   0f 90           pop     r0
    3c:   1f 90           pop     r1
    3e:   18 95           reti

      00000040 <main>:
    40:   78 94           sei
    42:   84 e0           ldi     r24, 0x04       ; 4
    44:   85 bf           out     0x35, r24       ; 53
    46:   80 e8           ldi     r24, 0x80       ; 128
    48:   8b bf           out     0x3b, r24       ; 59
    4a:   8f ef           ldi     r24, 0xFF       ; 255
    4c:   84 bb           out     0x14, r24       ; 20
    4e:   80 ee           ldi     r24, 0xE0       ; 224
    50:   81 bb           out     0x11, r24       ; 17
    52:   9f ef           ldi     r25, 0xFF       ; 255
    54:   80 91 60 00     lds     r24, 0x0060     ; 0x800060 <__data_start>
    58:   88 23           and     r24, r24
    5a:   29 f0           breq    .+10            ; 0x66 <main+0x26>
    5c:   95 bb           out     0x15, r25       ; 21
    5e:   80 91 60 00     lds     r24, 0x0060     ; 0x800060 <__data_start>
    62:   81 11           cpse    r24, r1
    64:   fb cf           rjmp    .-10            ; 0x5c <main+0x1c>
    66:   15 ba           out     0x15, r1        ; 21
    68:   f5 cf           rjmp    .-22            ; 0x54 <main+0x14>

And here is the dump from the compiled program without optimization enabled:

  00000000 <__ctors_end>:
    0:   10 e0           ldi     r17, 0x00       ; 0
    2:   a0 e6           ldi     r26, 0x60       ; 96
    4:   b0 e0           ldi     r27, 0x00       ; 0
    6:   ea ea           ldi     r30, 0xAA       ; 170
    8:   f0 e0           ldi     r31, 0x00       ; 0
    a:   03 c0           rjmp    .+6             ; 0x12 <__zero_reg__+0x11>
    c:   c8 95           lpm
    e:   31 96           adiw    r30, 0x01       ; 1
    10:   0d 92           st      X+, r0
    12:   a2 36           cpi     r26, 0x62       ; 98
    14:   b1 07           cpc     r27, r17
    16:   d1 f7           brne    .-12            ; 0xc <__zero_reg__+0xb>

  00000018 <main>:
    18:   cf 93           push    r28
    1a:   df 93           push    r29
    1c:   cd b7           in      r28, 0x3d       ; 61
    1e:   de b7           in      r29, 0x3e       ; 62
    20:   78 94           sei
    22:   85 e5           ldi     r24, 0x55       ; 85
    24:   90 e0           ldi     r25, 0x00       ; 0
    26:   24 e0           ldi     r18, 0x04       ; 4
    28:   e8 2f           mov     r30, r24
    2a:   f9 2f           mov     r31, r25
    2c:   20 83           st      Z, r18
    2e:   8b e5           ldi     r24, 0x5B       ; 91
    30:   90 e0           ldi     r25, 0x00       ; 0
    32:   20 e8           ldi     r18, 0x80       ; 128
    34:   e8 2f           mov     r30, r24
    36:   f9 2f           mov     r31, r25
    38:   20 83           st      Z, r18
    3a:   84 e3           ldi     r24, 0x34       ; 52
    3c:   90 e0           ldi     r25, 0x00       ; 0
    3e:   2f ef           ldi     r18, 0xFF       ; 255
    40:   e8 2f           mov     r30, r24
    42:   f9 2f           mov     r31, r25
    44:   20 83           st      Z, r18
    46:   81 e3           ldi     r24, 0x31       ; 49
    48:   90 e0           ldi     r25, 0x00       ; 0
    4a:   20 ee           ldi     r18, 0xE0       ; 224
    4c:   e8 2f           mov     r30, r24
    4e:   f9 2f           mov     r31, r25
    50:   20 83           st      Z, r18
    52:   80 91 60 00     lds     r24, 0x0060     ; 0x800060 <__data_start>
    56:   88 23           and     r24, r24
    58:   39 f0           breq    .+14            ; 0x68 <__SREG__+0x29>
    5a:   85 e3           ldi     r24, 0x35       ; 53
    5c:   90 e0           ldi     r25, 0x00       ; 0
    5e:   2f ef           ldi     r18, 0xFF       ; 255
    60:   e8 2f           mov     r30, r24
    62:   f9 2f           mov     r31, r25
    64:   20 83           st      Z, r18
    66:   f5 cf           rjmp    .-22            ; 0x52 <__SREG__+0x13>
    68:   85 e3           ldi     r24, 0x35       ; 53
    6a:   90 e0           ldi     r25, 0x00       ; 0
    6c:   e8 2f           mov     r30, r24
    6e:   f9 2f           mov     r31, r25
    70:   10 82           st      Z, r1
    72:   ef cf           rjmp    .-34            ; 0x52 <__SREG__+0x13>

  00000074 <__vector_2>:
    74:   1f 92           push    r1
    76:   0f 92           push    r0
    78:   0f b6           in      r0, 0x3f        ; 63
    7a:   0f 92           push    r0
    7c:   11 24           eor     r1, r1
    7e:   8f 93           push    r24
    80:   9f 93           push    r25
    82:   cf 93           push    r28
    84:   df 93           push    r29
    86:   cd b7           in      r28, 0x3d       ; 61
    88:   de b7           in      r29, 0x3e       ; 62
    8a:   90 91 60 00     lds     r25, 0x0060     ; 0x800060 <__data_start>
    8e:   81 e0           ldi     r24, 0x01       ; 1
    90:   89 27           eor     r24, r25
    92:   80 93 60 00     sts     0x0060, r24     ; 0x800060 <__data_start>
    96:   00 00           nop
    98:   df 91           pop     r29
    9a:   cf 91           pop     r28
    9c:   9f 91           pop     r25
    9e:   8f 91           pop     r24
    a0:   0f 90           pop     r0
    a2:   0f be           out     0x3f, r0        ; 63
    a4:   0f 90           pop     r0
    a6:   1f 90           pop     r1
    a8:   18 95           reti

It seems as though the memory address location of main() is being affected by compiler optimizations which is causing the issues. Does anyone have a proper explanation for this and/or a fix that would allow me to use compiler optimizations with interrupt routines?

Answer 1

These are not bugs that you are encountering. The problem goes deeper than just compiler optimization flags. It is a pure coincidence it happens to work at all.

The code isn't compiled properly according to instructions and examples of avr-libc/avr-gcc. Reading the manual will solve the issue.

The command used to compile the code will not work and generates something you can't use, at least not on a Mega8515.

You haven't told to the compiler and the linker which MCU you are using, so that the compiler could pick the right architecture, right startup code, and right libraries to use when compiling and linking code, as there are about 15-20 possible variants of things called AVR.

By default the compiler generates code for "avr2" architecture and Mega8515 is an "avr4" architecture chip.

Also the way you are defining the IC you use in the code for the io header is not the intended way of defining the MCU.

All this is explained on avr-libc website and there are also example projects and more importantly, examples how to compile them properly.

Answer 2

You know that something goes really wrong when at address 0 there is no vector table, which would be an array of RJMPs or JMPs, but there is ordinary code:

    00000000 <...>:`
    0:   10 e0           ldi     r17, 0x00       ; 0
    2:   a0 e6           ldi     r26, 0x60       ; 96

Vectab is device specific, thus something with device selection is wrong, and indeed:

Missing -mmcu=atmega8515 when Compiling and Linking

avr-gcc main.c -O2 -o main.elf

Always (like in ALWAYS) specify the MCU for which you are generating code! Both for compiling and linking. You are performing both steps by means of one command, so -mmcu= is missing in both build steps.

The outcome of missing -mmcu= will be:

• The compiler is using the wrong command line options (as per wrong specs file). With -mmcu=atmega8515 the compiler will use specs-atmega8515 which provides options for many sub-processes like compiler proper (cc1 for C or cc1plus for C++), assembler (as) and linker (ld).

• One outcome of missing specs-atmega8515 is that built-in macro __AVR_ATmega8515__ is not defined which is required so AVR-LibC can pick the right sub-header in #include <avr/io.h>. You hacked around that by hand-defining __AVR_ATmega8515__. Don't to that! The macro is defined in specs-atmega8515 which will be used with -mmcu=atmega8515. Without that option, the default is -mmcu=avr2, and the specs file specs-avr2 does not provide any device-specific options and defines.

• Linking without -mmcu=atmega8515 will have the effect that the compiler driver (avr-gcc) will call the linker without providing AVR-LibC's startup-code and vector table for ATmega8515 in crtatmega8515.o. The startup-code will initialize SP, set R1 aka. __zero_reg__ to zero, etc. When your code is missing all these relevant bits, it will malfunction.

• Linking without -mmcu=atmega8515 will have the effect that the compiler driver (avr-gcc) will not link against libatmega8515.a. Functions like EEPROM routines eeprom_read_byte from avr/eeprom.h are missing.

• Wrong or sub-optimal code: Not all AVR devices share the same instruction set. For example, ATmega8515 supports the MUL instruction, but you are compiling for device family avr2 (the default) which doest support MUL. Similar for MOVW instruction.

To get an overview what commands avr-gcc is issuing, add -v to the command line options and compare the output with[out] -mmcu=atmega8515.

Answer 3

Thank you for providing the dump output! You've captured the smoking gun:

See ATmega8515 Datasheet | Microchip page 54:

The first instruction must be rjmp .init (or equivalent label), and the instruction at 0x04 must be rjmp __vector_2 (and so on; usually, unused vectors are rjmp __reset or something like that). Instead, it has completely stomped over the whole interrupt vector region and just placed regular code there.

When you change the pin state, you've essentially done a program reset, minus the two instructions at the top that is. Which, in these cases, r17 and r26 are not used after initialization, so it will indeed act "normal" (not that "normal" does anything from reset, heh), rather than corrupt itself or crash. Cute!

Normally, vectors are allocated with an object containing a list of jump targets; it's forced to base address 0, and tagged used, meaning the linker will not omit it from the output, even if no reference is made to it by other objects, and even if -lto is used. Other objects (vectors, init, main(), etc.) are then placed after it.

These are missing because the compiler needs to know what exact MCU core is being used. This will also obviate the #define __AVR_ATmega8515__ declaration, which is generated automatically by the specs file.

When -mmcu=atmega8515 is added to the command line, GCC will read from a "specs" file, which provides a variety of parameters: which libraries to use, important addresses if different from linked symbols, compile target (CPU), etc. Defines, and other command-line options, can also be included. For example, on my path, %GCC_root%\lib\gcc\avr\8.1.0\device-specs\specs-atmega8515 contains these lines towards the end:

*cpp:
    -D__AVR_ATmega8515__ -D__AVR_DEVICE_NAME__=atmega8515

the define is handled automatically by these command line options.

---

Alternative smoking gun: you should never have to touch double-underscore defines in program code. io.h reads such a platform define, and presumably you patched that in to make it work; but this won't affect the linker, or anything else in the compiler back-end. This is kind of your clue that -mmcu is missing; though it can be hard to tell what exact invocation you happen to be missing.

The recommended start, here, I suppose, is to look at an existing project, or build tool, and see how they do it. For my part, I use Code::Blocks, which provides built-in scripts / invocations for avr-gcc, which I've mutated slightly to suit my own purposes. For a more shell-oriented environment, you'd probably want to look at makefiles.