TL;DR: If your're having problems with AVRDUDE not supporting the ATMega328 (non-"picoPower" variant of the ATMega328P), get the latest version from the SVN repository and build it.
In just over a month, I've seen 3 threads here all seeming to have at least something to do with issues related to trying to program the non-"picoPower" ATMega328 MCUs using AVRDUDE:
When I first encountered this myself back in early Dec 2011, the latest version of AVRDUDE (5.11.1) supported the ATMega328P ("picoPower" variant, with signature 0x1e950f) but not the non-P variant (with signature 0x1e9514). It seems that more people (like myself) are starting to encounter this non-P chip.Back then, I did an Internet search and found that most people were doing one of 2 things:
- using the '-p m328p -F' options on AVRDUDE to force it to treat their ATMega328 like an ATMega328P and ignore the resultant signature error (with the inherent danger therein)
- hacking their 'avrdude.conf' file to simply copy the "ATmega328P" section and editing the 3 lines required to make it into an ATMega328 (non-P) section
As I stated in one of those 3 threads referred to above, if I knew for certain that those 3 simple changes were the only changes (in that voluminous 'avrdude.conf' entry) needed to support the non-P ATMega328, I'd have submitted a patch to the AVRDUDE project back then.
Well, tonight I was determined to ask about this issue on the AVRDUDE mailing list. But I first thought to check the SVN repository and ...eureka!... found that less than a month after I first encountered and worked around the issue, support for the non-P ATMega328 was added in the repository! Just my luck! :D Here's the slightly condensed/edited entry from the 'ChangeLog-2011' file:
2011-12-29 Rene Liebscherbug #34302: Feature request : device configuration with parent classes * config_gram.y: Added part parent rule and allow overwriting existing data at several places * avrdude.conf.in: Added description comment and m328/m328p as example
You can grab the latest AVRDUDE code from the SVN repository with a command like this:
svn co svn://svn.savannah.nongnu.org/avrdude/trunk
Simple build instructions are provided in the 'BUILD-FROM-SVN' file. Being a GNU/Linux-only guy for AVR stuff, I don't know how the Windows (and Mac?) users of AVRDUDE build their hot-off-the-presses SVN repository code (maybe MinGW?), but maybe one of the advanced AVR/Windows users can chime in here with suggestions and/or comments.
Here's what the new 'avrdude.conf' will look like if you build AVRDUDE from the SVN sources:
#------------------------------------------------------------
# ATmega328
#------------------------------------------------------------
part
id = "m328";
desc = "ATmega328";
has_debugwire = yes;
flash_instr = 0xB6, 0x01, 0x11;
eeprom_instr = 0xBD, 0xF2, 0xBD, 0xE1, 0xBB, 0xCF, 0xB4, 0x00,
0xBE, 0x01, 0xB6, 0x01, 0xBC, 0x00, 0xBB, 0xBF,
0x99, 0xF9, 0xBB, 0xAF;
stk500_devcode = 0x86;
# avr910_devcode = 0x;
signature = 0x1e 0x95 0x14;
.
.
.
memory "signature"
size = 3;
read = "0 0 1 1 0 0 0 0 0 0 0 x x x x x",
"x x x x x x a1 a0 o o o o o o o o";
;
;
part parent "m328"
id = "m328p";
desc = "ATmega328P";
signature = 0x1e 0x95 0x0F;
;
A big chunk was intentionally omitted in the middle but note how the ATMega328P is now defined as a "child" of the "parent" ATMega328. Very nice and very clean!
My thanks to Rene Liebscher for the patch and to Jörg Wunsch and all the other great folks who provide and support AVRDUDE -- a great app indeed! My hat is off to you all!
I guess my caution about copying the "m328p" section and just changing the obvious lines was unfounded, but I'm a cautious guy by nature. :)
Anyway, I just wanted to report this here so that anyone encountering this issue will know about it, even if they're too inexperienced to actually build from SVN. Hopefully they'll find this post if they're searching or someone can point them to this if they aren't.
Good luck to all you ATMega328 users! Hope this information proves helpful....
Regards,
Bill
