# Blink LED example does not work

I'm trying to run standard Blink LED example on Atmega8A, but my LED doesn't blink. Here is my circuit:

And here is my code:

#ifndef F_CPU
#define 16000000UL
#endif // F_CPU

#include <avr/io.h>
#include <util/delay.h>

#define set_bit(target, num)    (   target |=   _BV(num))
#define clear_bit(target, num)  (   target &=   ~ _BV(num))
#define toggle_bit(target, num) (   target ^=   _BV(num))

#define DELAY_IN_MS 1000 /* 1 sec */

int main()
{
set_bit(DDRD, PD7);
set_bit(PORTD, PD7);
while(1)
{
toggle_bit(PORTD, PD7);
_delay_ms(DELAY_IN_MS);
}

return 0;
}


What's wrong?

• Make sure to add a resistor in series with the LED, about 220-270 Ohm. Also try to place the crystal and capacitors as close as possible to the mcu pins. Try to place the crystal as shown here – alexan_e Aug 14 '14 at 10:56
• With the LED reversed originally and the lack of a current limit resistor the next thing I'd try is a new LED (with the series resistor) and moving it to a different I/O pin, maybe something like PB0 that is pin 14. Also let it run a while, if the clock fuses are at the default it will be running at 1 MHz and take 16 seconds to blink (although it would be on at the start). – PeterJ Aug 14 '14 at 12:26

It looks to me like you've got the Cathode of the LED wired to Vdd. That's the wrong way round, so you should turn around the LED. Or alternatively, wire the Cathode to GND instead of VDD. Also, it's poor practice not to include a resistor in the LED current path; 220 Ohms or so should be fine.

UPDATE:

It looks like you've got more problems than just that. Going by the pin-out posted by 'TMa', your Vcc,GND (p7,p8) look reversed. Also the GND on pin22 is unconnected. Usually all GNDs on an IC should be connected because they are internally connected via the substrate.

• Changed circuit, now LED is connected to the GND. But still Led is not blinking... – Edward Aug 14 '14 at 10:57
• You should add the resistor too. – akellyirl Aug 14 '14 at 12:31
• @Edward you should check the update I posted regarding Vcc, GND. That could help. – akellyirl Aug 14 '14 at 12:39
• I followed your update, but problem still occurs. – Edward Aug 14 '14 at 16:58
• Mis-Powering a CMOS IC by reversing the polarity can cause latch-up, which can partially or completely impair the ICs functionality. You may want to try a new one if this has happened to you. – akellyirl Aug 15 '14 at 8:40

I fixed the problem. Thank you guys, for your attention and help:

The problem was in compilation. Here how I was compiling(Blink example does not work, verification fails):

avr-gcc -Wall blink.c -mmcu=atmega8 -DF_CPU=16000000UL -o blink.o


Here is how I'm compiling now:

avr-gcc -Wall blink.c -mmcu=atmega8 -DF_CPU=16000000UL -o blink.elf


BTW:

Code is working fine even if there is nothing connected to the second GND, AREF and AVCC.


First off, welcome to EE stack exchange!

Now, if your schematic is right, you're missing a pull-up reistor on RESET pin. Here's what usually is added:

simulate this circuit – Schematic created using CircuitLab

Capacitor C1 is there to get somewhat rid of the bouncing effect when button is pressed/released.

Add a current limiting resistor for the LED (220 Ohm). LED is a Ligh-Emmiting DIODE, so without a resistor there to limit the current, the LED acts like a short circuit to GND.

Furthermore, connect both grounds(pin 8 and 22) and connect Vcc to Avcc(pin 7 and 20). Also, add a 0.1 uF capacitor from AREF to GND if it is not used for ADC reference. Beware of positive and negative terminals on the capacitor, positive should go to AREF and negative to GND.

About the code, get rid of return 0; its not wrong to have it, but embedded system dont usually return from main(). And without compiler optimization if it would return, it could cause unidentified behaviour.

• The circuit I've posted is very simple. That's why there is nothing connected to the Reset and AREF pins. And as I know connections to the RESET, AREF and other additional pins is not required for Blink LED example. – Edward Aug 14 '14 at 11:58
• @Edward - Have you used circuits which reliably work without the RESET pull-up? Do you set a fuse? I trust the Shrimping It blog. They have worked carefully for several years to make a minimal cost, minimal component design suitable for DIY in a breadboard. They show a pull-up resistor on RESET. IMHO it's there for a reason. It won't cost much time and effort to add it, and, once you have the circuit working, you can easily remove it, to discover if it is needed. – gbulmer Aug 14 '14 at 12:16
• Of course its needed, unless the pin is set as a I/O pin. – Golaž Aug 14 '14 at 12:24
• The ATmega8A does have an internal pull-up on the reset pin. Only a weak one so I wouldn't rely on it for production but probably OK here. Having said that no harm trying in case it is in a noisy environment. – PeterJ Aug 14 '14 at 12:30

I don't think LED is properly connected to PD7.

• You was right. I've updated circuit image. But LED still doesn't blink. on PD7 pin now is about ~1.5V. – Edward Aug 14 '14 at 11:54
• What is Vcc, 3V3 or 5V ? If it is 3V3 then 1V5 might signalize that _delay_ms(1sec) does not work (but probably the LED shoud dim). Seems the code is not running. Add some pin change to hi level (e.g.PB0) in main to see if it's really running. If not double check FUSEs. You can also test running internal crystal (if supported by ATMEGA8). Also test is LED is OK - if you ran without resistor it might be broken. – TMa Aug 14 '14 at 12:21
• VCC is 5V(using USB as power supply). I've just changed fuses back to 0xE1 0xC9(default value): sudo avrdude -Vvv -c usbasp -p atmega8 -U lfuse:w:0xE1:m -U hfuse:w:0xC9:m. But LED still doesn't blink. – Edward Aug 14 '14 at 16:55
• I suspect it is compilation problem (e.g. is really main() compiled as intended "main" function). I'd check disassembled hex file, download code and compare with hex to prove that correct code is running. Also try set and toggle more pins to avoid broken PD7 pin problem. – TMa Aug 14 '14 at 20:28
• Same problem with PORTB, PORTC... I can upload compiled hex file, if it'll help... – Edward Aug 14 '14 at 20:35