ATmega328P Woes - Page 1
Forum section: electronics / general

author: Kalcifer
author_rank: Regular Contributor
timestamp: May 08, 2021, 03:17:30 am
content: 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)Code:$ makeavr-gcc -c -mmcu=atmega328p main.c# Compile, but don't linkavr-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 instructionsReading | ################################################## | 100% 0.00savrdude: Device signature = 0x1e950f (probably m328p)avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performedTo disable this feature, specify the -D option.avrdude: erasing chipavrdude: reading input file "a.hex"avrdude: input file a.hex auto detected as Intel Hexavrdude: writing flash (178 bytes):Writing | ################################################## | 100% 0.05savrdude: 178 bytes of flash writtenavrdude: 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 Hexavrdude: input file a.hex contains 178 bytesavrdude: reading on-chip flash data:Reading | ################################################## | 100% 0.07savrdude: verifying ...avrdude: 178 bytes of flash verifiedavrdude: 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 portCode:#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...

author: Kalcifer
author_rank: Regular Contributor
timestamp: May 08, 2021, 03:46:24 am
content: ALRIGHT never mind. Turns out I did fry the chip at some point. Strange that everything else works except the code ;P

author: Peabody
author_rank: Super Contributor
timestamp: May 08, 2021, 04:43:00 am
content: 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=0xFFuno.bootloader.high_fuses=0xDEuno.bootloader.extended_fuses=0xFD

author: westfw
author_rank: Super Contributor
timestamp: May 08, 2021, 09:26:46 am
content: QuoteUno 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...)Quoteyou should probably useavr-objcopyI'm not SURE that objcopy isn't "generic", but ... who knows for sure! (What doesavr-objdump -D -mavr a.hexshow?)

author: hugo
author_rank: Regular Contributor
timestamp: May 09, 2021, 08:52:51 pm
content: You never know, this code might work ...Code:#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);}}

author: Buriedcode
author_rank: Super Contributor
timestamp: May 09, 2021, 10:19:41 pm
content: Quote from: hugo on May 09, 2021, 08:52:51 pmI'm surprised you're the first to pick up on that!Quote from: Kalcifer on May 08, 2021, 03:17:30 amAsk yourself, what the above code is actually doing.

author: newbrain
author_rank: Super Contributor
timestamp: May 10, 2021, 10:43:05 am
content: Quote from: Buriedcode on May 09, 2021, 10:19:41 pmWhat the OP expected? Output a 1 on a pin:Quote from: Kalcifer on May 08, 2021, 03:17:30 amIt was not meant to be a blinky.

author: hugo
author_rank: Regular Contributor
timestamp: May 11, 2021, 06:39:02 pm
content: QuoteLet's say that it was not meant to be a blinky, the code still doesn't work: DDD6, PORTD6 etc.

author: westfw
author_rank: Super Contributor
timestamp: May 12, 2021, 05:12:14 am
content: QuoteLooks OK to me...(from iom328p.h)Code:#define DDD6 6:#define PORTD6 6