Author Topic: ATmega328P Woes  (Read 726 times)

0 Members and 1 Guest are viewing this topic.

Offline Kalcifer

  • Regular Contributor
  • *
  • Posts: 65
  • Country: ca
ATmega328P Woes
« on: May 08, 2021, 03:17:30 am »
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: [Select]
$ 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

Code: [Select]
#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...
« Last Edit: May 08, 2021, 03:34:54 am by Kalcifer »
 

Offline Kalcifer

  • Regular Contributor
  • *
  • Posts: 65
  • Country: ca
Re: ATmega328P Woes
« Reply #1 on: May 08, 2021, 03:46:24 am »
ALRIGHT never mind. Turns out I did fry the chip at some point. Strange that everything else works except the code ;P
 

Online Peabody

  • Super Contributor
  • ***
  • Posts: 1100
  • Country: us
Re: ATmega328P Woes
« Reply #2 on: May 08, 2021, 04:43:00 am »
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
« Last Edit: May 08, 2021, 04:49:48 am by Peabody »
 
The following users thanked this post: wraper

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3462
  • Country: us
Re: ATmega328P Woes
« Reply #3 on: May 08, 2021, 09:26:46 am »
Quote
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...)

Quote
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?)
 

Offline hugo

  • Regular Contributor
  • *
  • Posts: 161
  • Country: ca
Re: ATmega328P Woes
« Reply #4 on: May 09, 2021, 08:52:51 pm »
You never know, this code might work ...   ;)

Code: [Select]
#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);
    }
}


« Last Edit: May 10, 2021, 05:15:57 am by hugo »
 

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1367
  • Country: gb
Re: ATmega328P Woes
« Reply #5 on: May 09, 2021, 10:19:41 pm »
You never know, this code might work ...   ;)

Code: [Select]
#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!

Code: [Select]
#include <avr/io.h>

void main(void)
{
    DDRD |= (1 << DDD6);
    PORTD |= (1 << PORTD6);
 
    while(1)
    {
    }
}


Ask yourself, what the above code is actually doing.
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1145
  • Country: se
Re: ATmega328P Woes
« Reply #6 on: May 10, 2021, 10:43:05 am »
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.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline hugo

  • Regular Contributor
  • *
  • Posts: 161
  • Country: ca
Re: ATmega328P Woes
« Reply #7 on: May 11, 2021, 06:39:02 pm »
Quote
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.

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3462
  • Country: us
Re: ATmega328P Woes
« Reply #8 on: May 12, 2021, 05:12:14 am »
Quote
the code still doesn't work: DDD6, PORTD6 etc.
Looks OK to me...
(from iom328p.h)
Code: [Select]
#define DDD6 6
   :
#define PORTD6 6

 
The following users thanked this post: newbrain


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf