Different versions of the ATMega328P-PU??

I made a standalone Uno with a pair of 22 pF caps and a 16MHz crystal. It works great. I program the 328P-PU by inserting it back in the Uno board and uploading from my desktop computer.

All is good so far.

I purchased a bunch of extra ATMega328P-PU chips and they hang when uploading to the chip (when they are in the Uno board. I swapped out the new chips for the old ones and everything seems to work again (the upload of the sketch).

I noticed the original 328P-PU that came with the Uno has "1644" directly above where "328P-PU" is stamped on the chip. The new chips (that do not upload) have "1633" in the same place.

Is it possible "not all 328P-PU chips are the same"?

My problem goes away and I am able to upload with no problems when I use the 1644 chip that came with the Uno board.

Thank you for the help in advance.

Also: is there a workaround for this problem? Thank you again.

Brand new ATmega328P-PU chips do not come with the same fuses programmed as an Arduino-programmed chip, and of course they do NOT have any bootloader programmed, so they're not ready to be used with the Arduino IDE unless you also have a programmer. (Unless you specifically bought chips WITH a bootloader already programmed.)

westfw: OK, thank you... may i ask a stupid question (I am new, sorry), how does one do a "bootload" to these chips?

Bootloading:

LarryD:

Thanks for the link.

  • I wired up the 2 Unos as he shows

  • I put my USB cable in the "good board" now BOTH boards are running the same "blink" program

  • I loaded the .ino and all the .h files as he shows in github but when i go to compile his bootloader program I get "readfuse()" compile errors... :frowning:

I know I am close... but no cigar :frowning:

OK, thank you all! I managed to get one Uno to be a programmer for another 328P chip... the other ship appears to burn and i can program that chip... but I get this error. What does it mean? (Sorry, I am still a beginner).

Thank you

The efuse (extended fuse byte) only uses the 3 lower bits, the upper 5 do not exist.
Programming in 0x05, or 00000101, is the same as programming in 11111101, or 0xfd.
So the warning is telling you to use 0xfd instead of 0x05 so when the check is done to see if the byte was programmed correctly, the unused bits that read back as 1s match the bits being written.

Operationally, it is just a warning and has no impact.

CrossRoads: Thank you... I am still getting a handle on all of this. Thanks for the help.