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