I just started working with an ATmega328P for the first time using avrdude after using an ATtiny84A for a while using the same programming method, and I've run into some strange issue. The microcontroller is being successfully programmed, but it doesn't seem to be "working" for lack of a better word. The chip is brand new, so I don't think it's fried. Plus if it was fried, I doubt it would program successfully.
Here is the output of programming the controller for proof of the successful programming (you can also see the fuse bits at the end for verification)
$ make
avr-gcc -c -mmcu=atmega328p main.c # Compile, but don't link
avr-gcc -mmcu=atmega328p main.o -o a.out # Link all of the object files together.
objcopy -O ihex a.out a.hex # Convert the compiled program into hex.
avrdude -c atmelice_isp -p m328p -U flash:w:a.hex # Program the flash of the microcontroller with the data in the hex file.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "a.hex"
avrdude: input file a.hex auto detected as Intel Hex
avrdude: writing flash (178 bytes):
Writing | ################################################## | 100% 0.05s
avrdude: 178 bytes of flash written
avrdude: verifying flash memory against a.hex:
avrdude: load data flash data from input file a.hex:
avrdude: input file a.hex auto detected as Intel Hex
avrdude: input file a.hex contains 178 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.07s
avrdude: verifying ...
avrdude: 178 bytes of flash verified
avrdude: safemode: Fuses OK (E:FD, H:D6, L:E0)
avrdude done. Thank you.
I created a simple test program to see if I was even able to toggle a port
#include <avr/io.h>
void main(void)
{
DDRD |= (1 << DDD6);
PORTD |= (1 << PORTD6);
while(1)
{
}
}
and then probed pin 12, and nada. No output. It should be outputting high but it is not. I tried a number of other pins, and same problem.
I have absolutely no idea what is going on. I'm using the exact same method that successfully programmed the ATtiny84A. Any help would be greatly appreciated. I eager to find out what the boneheaded oversight I made is.
All obvious things have been checked: triple checked wiring, good source, good clock... I highly doubt that it's instrument related as I've measured with two separate instruments, and still nada. A possibility is that its being held in reset for some reason, but the reset pin is pulled up to vcc with a pull up resistor, the watch dog isn't enabled, and there is no BOD enabled, and again the supply is good, so its not in low power reset...
ALRIGHT never mind. Turns out I did fry the chip at some point. Strange that everything else works except the code ;P
Well, just make sure you're checking the right pin, and that you haven't done something with the fuses that makes it impossible for the code to run properly - clock source, or something like that.
Just to check the 328P, you could install the portable version of the Arduino IDE, flash a bootloader to the chip, which would also set the fuses, then try to upload and run the Blink example sketch. You would need a USB-to-uart adapter of some kind.
It's unlikley you've fried the chip.
Edit: The fuses Arduino uses for that chip on the Uno are shown below. They are for a 16MHz external crystal and a bootloader of 2K (I think).
uno.bootloader.low_fuses=0xFF
uno.bootloader.high_fuses=0xDE
uno.bootloader.extended_fuses=0xFD
The fuses Arduino uses for that chip on the Uno are shown below. They are for a 16MHz external crystal and a bootloader of 2K (I think).
Uno uses a 512-byte bootloader.
You have the fuses set for a bootloader; is there one on the chip ? (actually, this shouldn't stop your program from working; it'll run the nop-ish non-existent bootloader and loop around to your actual code.
You also have the fuses set for an "external clock" which is NOT the same as an external crystal. Do you have a clock source connected? (although, if this was wrong, you should have had trouble uploading code...)
objcopy -O ihex a.out a.hex # Convert the compiled program into hex.
you should probably use
avr-objcopyI'm not SURE that objcopy isn't "generic", but ... who knows for sure! (What does
avr-objdump -D -mavr a.hex show?)
You never know, this code might work ...
#define F_CPU 1000000UL // (internal RC OSC frequency Hz)
#include <avr/io.h>
#include <util/delay.h>
void main(void)
{
DDRD |= (1<<6);
while(1)
{
PORTD |= (1<<6);
_delay_ms (1000);
PORTD &= ~(1<<6);
_delay_ms (1000);
}
}
You never know, this code might work ...
#include <avr/io.h>
#include <util/delay.h>
void main(void)
{
DDRD |= (1<<6);
while(1)
{
PORTD |= (1<<6);
_delay_ms (1000):
PORTD &= ~(1<<6);
_delay_ms (1000):
}
}
I'm surprised you're the first to pick up on that!
#include <avr/io.h>
void main(void)
{
DDRD |= (1 << DDD6);
PORTD |= (1 << PORTD6);
while(1)
{
}
}
Ask yourself, what the above code is actually doing.
I'm surprised you're the first to pick up on that!
[...]
Ask yourself, what the above code is actually doing.
What the OP expected? Output a 1 on a pin:
and then probed pin 12, and nada. No output. It should be outputting high but it is not. I tried a number of other pins, and same problem.
It was not meant to be a blinky.
I created a simple test program to see if I was even able to toggle a port
Let's say that it was not meant to be a blinky, the code still doesn't work: DDD6, PORTD6 etc.