I've ran into a bit of a strange problem. I am using ATMEGA328 chips as the microcontroller for a circuit board I designed. I am using the ATMEGA328P-PU version like the uno uses. I have purchased chips from both Mouser and Digikey and I've found that the ones I get from Mouser are labeled ATMEGA328P U and the ones from Digikey are labeled ATMEGA328P-PU like the ones in the uno. I verified that I did indeed buy ATMEGA328P-PU from both suppliers. I don't exactly care about the labeling, but I've noticed that the ATEMEGA328P U version doesn't function quite like it should after a little while of use until you start over by cycling the power. What is the difference between ATMEGA328P U and ATMEGA328P-PU? Why don't the two versions operate the same? Is it possible to get them to operate the same?
I've attached pictures of the two versions for your reference.
pert:
Please explain exactly what you mean by "doesn't function quite like it should".
I am using a modified version of the code on this topic. Its been modified to monitor some of the actual bits in the data stream and output them to some 74HC595's for external processing and analysis. For whatever odd reason, the code works fine at first, but then after some random length of time(at the least probably 3 minutes and at the most maybe 10), the board will stop monitoring a random bit in the stream and turn off the respective output on the 595 until power is cycled. I don't think that this anomaly occurs EVERY time, but it does happen probably 98% of the time.
Not sure if it matters, but I'm obviously writing the code in the Arduino IDE, but I am putting the code directly on the chip without the bootloader using a TL866CS.
The fuses I use are:
LOW: FF
HIGH: DE
EXTENDED: FD
LOCK: FF or FC depending on whether I want the code locked or not.
Are the chips properly decoupled? Process differences between individual chips/lots can render them more or less sensitive to improper or insufficient decoupling caps.
The P U chips are more recently produced, if I'm interpreting the date codes right. Maybe they got a die shrink or something?
DrAzzy:
Are the chips properly decoupled? Process differences between individual chips/lots can render them more or less sensitive to improper or insufficient decoupling caps.
The P U chips are more recently produced, if I'm interpreting the date codes right. Maybe they got a die shrink or something?
It seems I have forgotten a decoupling cap for the ATMEGA, but my other logic chips have them. I have an abundance of 1uf 50V electrolytics. Would those work? Could I solder one of those to the bottom side of the board to the chip's socket? If yes, which set of power pins should I use or should I use one pin from each?
You need 0.1 uF capacitor on each. You could try the 1 uF and it might work. Decoupling capacitors are a ballpark sort of thing. Your circuit board will act as a capacitor by itself. Some people even manage to get by without any at decoupling caps all but it's certainly not a good idea. Really you should just have a stock of 0.1 uF capacitors because they are always useful.
Electrolytic caps suck for decoupling. They have too much ESL and ESR. Ceramics are what you want (tants are ok too, but they cost several times as much and explode if you connect them backwards - I only use them in special situations, not run of the mill decoupling ). Buy a bag, you'll use more 0.1uF ceramic caps than any other single part.
DrAzzy:
Electrolytic caps suck for decoupling. They have too much ESL and ESR. Ceramics are what you want (tants are ok too, but they cost several times as much and explode if you connect them backwards - I only use them in special situations, not run of the mill decoupling ). Buy a bag, you'll use more 0.1uF ceramic caps than any other single part.
Ok, so I buy a bunch of .1uF ceramic caps. Then what? Until I order a new revision board, I'm going to need to connect them to the board I have. Should I solder one to the bottom of the board to one set of the Atmega's power pins? On pin from each set of power pins? Two capacitors total, one for each set of power pins?
DrAzzy:
One on each side. And make sure that AVcc and Vcc are connected (I have seen tutorials where this isn't done).
Luckily it looks like I already did that.
I finally got some 0.1 uf ceramic capacitors. Pretty soon I'll be testing the board with and without them to conclusively decide whether or not they fix the problem.
I've tried emailing Mouser, but they didn't respond. I was really wanting to email Atmel/Microchip, but I can't find a way to do that on their website. Anyone know how I might be able to do that?
Also, Digikey is now selling the ATMEGA328P U chip instead of the ATMEGA328P-PU, but it looks different from the ATMEGA328P U I received from Mouser a while back. (See photo). The text on the chip looks almost printed instead of engraved and those little impressed circle things are bigger on the ones I just got from Digikey. I haven't got a chance to test the new ones from Digikey yet, but I'm hoping they work like the ATMEGA328P-PU I used to be able to get.
I did find those already, but I was really hoping to just email someone at the company. I might just have to settle for using something on those pages.
Mouser finally emailed back. They contacted Microchip for me who said this:
As part of Part marking change due to the migration from Atmel to Microchip, the package identifier has been removed from the device marking as this can be observed visually for different packages. This will be updated in the upcoming revisions of the device datasheet. As per this new marking the ATMEGA328P U are valid devices without any process change. Please provide more details on the application and nature of failure so that we can check this further.
That answers the question about the new marking. I'll respond to the email soon and explain the issues I have.
Sketch uses 6760 bytes (20%) of program storage space. Maximum is 32256 bytes.
Global variables use 448 bytes (21%) of dynamic memory, leaving 1600 bytes for local variables. Maximum is 2048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x66
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x66
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x66
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x66
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x66
avrdude: stk500_recv(): programmer is not responding
Problem uploading to board. See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x66
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x66
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x66
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x66
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x66
Invalid library found in C:\Program Files (x86)\Arduino\libraries\AMS: no headers files (.h) found in C:\Program Files (x86)\Arduino\libraries\AMS
Invalid library found in C:\Program Files (x86)\Arduino\libraries\AMS: no headers files (.h) found in C:\Program Files (x86)\Arduino\libraries\AMS
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
I'm getting this msg after mounting the that chip.
