Return to Answer

1. 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.

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.

1. 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.

1. 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.

1. 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.

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.

1. 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.