Wrong values in avrdude.conf

[stefanrueger]

Some wrong entries in the avrdude.conf file

ATmega165: signature bytes are 0x1E, 0x94, 0x05 (not ... 0x07)

see datasheet

ATmega64M1's flash size, page size and eeprom size need to be double each (copy/paste error from ATmege32M1?)
see datasheet

ATxmega128D4's page size should be 256, not 512, see datasheet page 16

[MCUdude]

ATmega165: signature bytes are 0x1E, 0x94, 0x05 (not ... 0x07)

The weird thing is that 0x1E9405 is the signature for ATmega169P (see datasheet). What the real device signature for ATmega165 is for me a mystery...

ATmega64M1's flash size, page size and eeprom size need to be double each (copy/paste error from ATmege32M1?)

Good catch! This should be correct:

#------------------------------------------------------------
# ATmega64m1
#------------------------------------------------------------

part parent "m328"
    id              = "m64m1";
    desc            = "ATmega64M1";
    # stk500_devcode	= 0x;
    # avr910_devcode	= 0x;
    signature       = 0x1e 0x96 0x84;
    bs2             = 0xe2;

    memory "eeprom"
        size            = 2048;
        page_size       = 8;
    ;

    memory "flash"
        paged           = yes;
        size            = 65536;
        page_size       = 256;
        num_pages       = 256;
    ;

    memory "efuse"
        size            = 1;
        min_write_delay = 4500;
        max_write_delay = 4500;
        read            = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0",
                          "x x x x x x x x o o o o o o o o";
        
        write           = "1 0 1 0 1 1 0 0 1 0 1 0 0 1 0 0",
                          "x x x x x x x x x x i i i i i i";
    ;
;

ATxmega128D4's page size should be 256, not 512, see datasheet page 16

Will this be the case for other Xmegas as well?

[dl8dtl]

ATmega165: signature bytes are 0x1E, 0x94, 0x05 (not ... 0x07)

see datasheet

File a bug report with Microchip then … somewhere on the way, the have kaputified their datasheet.
I've got the B revision of the manual here, and it declared the signature as 0x07.
I've also got that one:

(The Dymo label on it is not mine – it came that way from Atmel.)
And it gives us:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9407 (probably m165)

Finally, I fetched their ATmega device packs, and extracted the ATDF files:

% fgrep SIGNATURE2 atdf/ATmega165*
atdf/ATmega165A.atdf:          <property name="SIGNATURE2" value="0x10"/>
atdf/ATmega165P.atdf:          <property name="SIGNATURE2" value="0x07"/>
atdf/ATmega165PA.atdf:          <property name="SIGNATURE2" value="0x07"/>

Note that there's no non-P version even mentioned in the device packs … (which is probably also the reason why they've labelled that Dymo label on mine).

[dl8dtl]

However, thanks for triggering me to dig out that old M165P ;-) I just noticed the signature read instruction in avrdude.conf for that device has a one-bit error, preventing it from reading the signature correctly. I'll fix that immediately.

[MCUdude]

Note that there's no non-P version even mentioned in the device packs … (which is probably also the reason why they've labelled that Dymo label on mine).

Does this mean that the Atmega165 doesn't even exist, and should instead use the ATmega165A signature instead like we do on ATmega32/32A?

However, thanks for triggering me to dig out that old M165P ;-) I just noticed the signature read instruction in avrdude.conf for that device has a one-bit error, preventing it from reading the signature correctly. I'll fix that immediately.

Good catch! It's probably my fault, sorry. I found the ATmega165 definitions on someone's Github page and assumed that it would work. I do have a lot of various AVRs at my disposal, but unfortunately, not the ATmegaXX5 family.

[dl8dtl]

Note that there's no non-P version even mentioned in the device packs … (which is probably also the reason why they've labelled that Dymo label on mine).

Does this mean that the Atmega165 doesn't even exist

Probably, yes. Microchip has a datasheet for it but no ATDF files. That means their Studio does not support them at all (Studio needs the ATDF files).

and should instead use the ATmega165A signature instead like we do on ATmega32/32A?

No: the P and PA variants do exist, and use the old signature. Only the A variant got a new one.

I do have a lot of various AVRs at my disposal, but unfortunately, not the ATmegaXX5 family.

I think they are pretty meaningless these days. I never really understand their purpose: they are cut-down versions of the "9" LCD controller line, where the LCD block has been left out. That gives lots of GPIOs, but then, the "0/1" line (ATmega640 … ATmega2560/2561) offers lots of GPIOs as well.

[stefanrueger]

Yes, makes sense that the 165 doesn't exist (if no ATDF file). Maybe consider removing from avr-libc and avrdude?

[stefanrueger]

I have been comparing what avr-gcc (11.2.0)/avr-libc sees against avrdude. Also noticed a few names that feel wrong

[stefanrueger]

suggest

• ATmega406 instead of ATMEGA406
• ATtiny43U instead of ATtiny43u
• ATmega329A instead of ATmega329a

Seems trivial, but one might as well make the capitalisation consistent

[MCUdude]

and should instead use the ATmega165A signature instead like we do on ATmega32/32A?

No: the P and PA variants do exist, and use the old signature. Only the A variant got a new one.

What I meant was to change the avrdude.conf file to this (table below), since the ATmega165(non-A) probably doesn't exist. At least it can't be bought anymore:

From this:

Chip	Signature	Is parent in avrdude.conf
ATmega165	0x1e9407	Yes
ATmega165A	0x1e9410	No
ATmega165P	0x1e9407	No
ATmega165PA	0x1e9407	No

To this:

Chip	Signature	Is parent in avrdude.conf
ATmega165	0x1e9410	Yes
ATmega165A	0x1e9410	No
ATmega165P	0x1e9407	No
ATmega165PA	0x1e9407	No

The argument for doing this change is that virtually any other "non-A, non-P, and non-PA" shares the same signature as the *A-part. If someone wants to program an ATmega165A chip, but are used to not adding *A to the part number (Avrdude support for *A names was recently added), it should IMO work with the non-A target instead, like with other chips (ATmega32/A, ATmega64/A, ATmega128/A etc.).

I can submit a PR with this if along with the other minor things @stefanrueger pointed out.

[stefanrueger]

Fun history fact: Avr-libc today thinks that ATmega165's SIGNATURE_2 byte is 0x05 (wrong according to this discussion), and has done so for a while. Going back in history, it's as long ago as the avr-libc version that came with avr-gcc 4.8.1 when ATmega165's SIGNATURE_2 byte last was 0x07 (right according to this discussion).

I had a program look at inconsistencies in terms of signature bytes, flash size and page size on the intersection between avrdude and avr-libc of supported parts. I reported discrepancies either in avr-libc or avrdude depending on the data sheets (which may or may not be right, particularly when the part in question is not known to actually exist).