Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a ATmega328-PU chip which is setup to use the internal oscillator without dividing clock speed by 8. The first thing I did was to use a really simple program I uploaded; a program which turned on and off all pins on PORTB. Like so:

#define F_CPU 8000000UL
#include <avr/io.h>
#include <avr/delay.h>

int main(void) {
    DDRB = 0xFF;
        PORTB = 0xFF;

    while(1) {
            PORTB = 0x00;
            PORTB = 0xFF;

    return 0;
  • Update: I have tried what Jon L suggested. Still the same result.
  • Update 2: I have tried what Kevin Vermeer suggested. The chip seems to freeze when it enter the first loop. Using the timer with a value < 65000 makes the LED turn on directly, using a value > 65000 results in the LED never turn on.
  • Update 3: I have tried following with a new identical chip with the same results
  • Update 4: I plugged in simulavr and avr-gdb to see whether I found something, this was the output:

    memory.c:267: WARNING: * * Attempt to write invalid io reg: ADCL at 0x0024 memory.c:267: WARNING: * * Attempt to write invalid io reg: ADCH at 0x0025 memory.c:267: WARNING: * * Attempt to write invalid io reg: ADCH at 0x0025 decoder.h:59: WARNING: Unknown opcode: 0xffff

Then unknown opcode loops forever.

However, when I have uploaded the program it reaches the second instruction in main and then freezes. Leaving all PORTB pins in HIGH. So far I have tried:

  • Different ms between 10 - 1000 to see whether there are some values that can't be used
  • Changed F_CPU to 1000000UL in case it would use CKDIV8.
  • Looping _delay_ms(1) in a separate function until it iterates to the given amount
  • Re-compiled and re-uploaded multiple times
  • Tried resetting multiple times
  • Used different PORTB pins
  • Defined F_CPU from the compiler arguments -DF_CPU=8000000

Why I'm asking here and not stackoverflow.com is because I think I should start to eliminate errors on the lowest level of abstraction, that is; hardware.

So what could be the problem?

Here are some information about my setup:

  • Operating system: OS X 10.7.3
  • Programmer: AVRisp MKII
  • Uploader: avrdude
  • Compiler: avr-gcc
  • Bin 2 hex: avr-objcopy

Fuse settings:

avrdude: safemode: lfuse reads as E2
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7

Input into AVR fuse calculator:

Fuse settings in AVR fuse calculator


        avr-gcc -g -Os -Wall -mmcu=atmega328 -c ../src/example.c

        avr-objcopy -j .text -j .data -O ihex example.o example.hex

        avr-objdump -h -S example.o > example.lst

        avrdude -p m328 -c avrispmkII -P usb -U flash:w:example.hex

        rm -f *.o
        rm -f *.hex
        rm -f *.lst

Pins used on chip:

  • Pin 7 (VCC): 5 volts supply
  • Pin 8 (GND): ground
  • Pin 14 (PB0): resistor and LED
share|improve this question
...you also have to make sure you have size optimizations enabled for util/delay.h functions to work correctly. – vicatcu Feb 23 '12 at 18:05
Yes, that's enabled. Look at the makefile under main:, where you can see that the -Os is used. – rzetterberg Feb 23 '12 at 18:52
up vote 3 down vote accepted

I suspect the problem is not with your C code but with your Makefile.

The following lines in your Makefile produce an example.o object file.

    avr-gcc -g -Os -Wall -mmcu=atmega328 -c ../src/example.c

The created .o file only contains the symbols and code from example.c, not the additional source required to actually make it run on a target system such as interrupt vector jump tables and code to initialise the BSS RAM segment to zeros, and load your initialised data sections.

You'll need to add an additional line something like this to run the linker and produce an output object suitable for download to the AVR part. Alternatively, use avr-ld, but you'll have to work out all the required linker options.

main.elf: example.o
    avr-gcc example.o -o main.elf

You can use avr-objdump --disassemble-all <filename> on both example.o and main.elf yourself to verify the different content of each file.

It's always a good idea to try to reduce your problem in steps to the most simple example possible. In this case, it would probably mean dropping into the AVR Studio software and creating a project running on the simulator using their managed build process. From there, you could them export the Makefile in use by their build process by using the 'Export Makefile' menu option. The generated makefile could then be compared with your version.

Actually, it's probably a good idea to use a Makefile similar to the one generated by AVR Studio because it has the correct rules already defined, you just have to set up some variables with regard to which objects need to be generated and the final target file name.

share|improve this answer
This sounds really reasonable! I haven't even begin to think of this. It's the one part I have totally over-looked. I will read up on using the linker and try this out. Thank you for the different approach! :) – rzetterberg Feb 25 '12 at 12:05
You, sir, has made my day. It works like expected! I added the elf creation to my make file and ran compilation, elf creation, hex creation and finally upload. – rzetterberg Feb 27 '12 at 7:52

For your CPU speed:

#define F_CPU 80000000UL

Do you have an extra 0 on there? That reads 80 MHz. I think you want 8 MHz.

EDIT: after checking the datasheet, your lfuse value looks to be OK if you're wanting to use the internal oscillator with CKDIV8 disabled.

share|improve this answer
Well spotted! Although, if you're right, wouldn't the delay loop take 5s, so you'd see some activity... – Toby Jaffey Feb 23 '12 at 17:26
@JobyTaffey, yeah... I'm looking elsewhere for any issues as well. – Jon L Feb 23 '12 at 17:28
Thanks for spotting that! Other than that, is there anything I should think of and improve? :) I wanted to try out the chip, but I don't have an external oscillator and caps I can connect to it, that's why I used the internal oscillator. – rzetterberg Feb 23 '12 at 17:44
@rzetterberg, this is probably redundant, but I noticed in one of my old Makefiles that I had this flag after avr-gcc: "-DF_CPU=8000000" - again, since you have this defined in code I think this is redundant, but I'm trying to remember why I had this in here in the first place... might be worth tacking on. – Jon L Feb 23 '12 at 18:00
@Jon L: Alright, I will correct the value and try to supply the frequency both ways and see whether that makes a difference. – rzetterberg Feb 23 '12 at 18:03

Your program should be able to use _delay_ms(), but there are other ways to do a delay.

_delay_ms() just calls _delay_us(), which calls _delay_loop_1() in delay_basic.h. _delay_loop_1(), as the name implies, simply loops. It uses 3 instructions per loop (for comparisons, increments, and jumps), and the time taken for each instruction is constant and known, so it can delay for a given time simply by running in a loop.

To remove any confusion about your program structure and F_CPU search path, you could re-create the function (in a very rough way) in the main function like this:

#include <stdint.h>  // Typedefs `unsigned long` or something to `uint16_t`,
                     // a 16-bit unsigned number
#include <avr/io.h>
int main(void) {
    uint16_t counter1, counter2;

    DDRB = 0xFF;
    PORTB = 0xFF;

    while(1) {
            PORTB ^= 0; // Use XOR to toggle
            for (counter1 = 0; counter1 < 10; counter1++) { 
                for (counter2 = 0; counter2 < 50000; counter2++) { /* Do nothing */ }

    return 0;

The other method is to use the onboard timer peripherals, instead of implementing a timer with a loop. You can use these peripherals in many ways, but I'll describe the two simplest ways below. First, you can poll the timer from a loop, and do something when the value reaches a certain point. Second, you can have the timer issue an interrupt when it reaches a certain point, and have your code do nothing.

To poll from a loop, you'd do something like this:

#include <avr/io.h> 

int main (void) 
   DDRB = 0xFF; // Set port as output 
   TCCR1B |= _BV(CS10); // Set up timer 

   while(1)    { 
      // Check timer value in if statement, true when count matches 1/20th of a second 
      if (TCNT1 >= 49999) 
         PORTB ^= 0xFF; // Toggle the port 

         TCNT1 = 0; // Reset timer value 

To issue an interrupt:

#include <avr/io.h> 
#include <avr/interrupt.h> 

int main (void) 
   DDRB = 0xFF; // Set LED as output 
   TCCR1B |= (1 << WGM12); // Configure timer 1 for CTC mode 
   TIMSK |= (1 << OCIE1A); // Enable CTC interrupt 
   sei(); //  Enable global interrupts 
   OCR1A   = 10000; // Set CTC compare value, about 50ms.
   TCCR1B |= ((1 << CS10) | (1 << CS11)); // Start timer at Fcpu/64 

   while(1) { 
       // Do nothing, the interrupt is taking care of it.

   PORTB ^= 0xFF; // Toggle the LED 

The above code samples were adapted from the excellent timer tutorial on AVR Freaks, also available from Dean's website here in PDF format.

Furthermore, your code (and each of the above samples) toggles the entire port. Your LED is on PB0; you can toggle just this pin by replacing every assignment to PORTB with

PORTB ^= _BV(PB0);

which compares PORTB with only 0x0000 0001.

share|improve this answer
Thanks for the write up and the alternatives. I will try the different methods tomorrow :) – rzetterberg Feb 23 '12 at 19:25
+1 for trying to rule out the include path – Jon L Feb 23 '12 at 19:25
@Jon - Admittedly, I still included stuff, so all I did was eliminate the CPU speed definition. – Kevin Vermeer Feb 23 '12 at 19:53
@Kevin Vermeer: I have tried what you suggested, see my edit of the question. About why I turned on all ports at the same time is because I wanted to eliminate the possibility that I had put the LED on the wrong pin. – rzetterberg Feb 24 '12 at 10:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.