Weird AVR family warning on locked AVR-Dx

[LinuxJedi]

I'm flashing a locked AVR-Dx with the following command, which works great, but the messages are a bit weird:

avrdude -c atmelice_updi -p avr64da64 -e -U flash:w:flash.hex -U lock:w:0xA33A3AA3:m

This is the initial message before the flash executes:

Error: device is locked; chip erase required to unlock
Error: device is locked; chip erase required to unlock
Error: unable to read byte at address 0x0000
Error: read operation failed for memory signature
Error: unable to read signature data for part AVR64DA64 (rc = -3)
Warning: received FamilyID: "AVR    "
expected FamilyID: "    AVR"

Whilst really minor, I find it odd for two reasons:

1. It says "Error", but these are more warnings, they are non-fatal and I have provided -e anyway.
2. The FamilyID appears to have different whitespace to the expected response.

I don't know enough about avrdude's code or the protocol to understand why, and it isn't really a problem, but it was just a little unexpected :)

[stefanrueger]

Thanks for reaching out @LinuxJedi.

Yes, I can relate to your observation. It is a side effect of the way that AVRDUDE is written as an application from our big AVR library libavrdude that there are a couple of independent abstraction levels that engage with hardware: lower levels don't necessarily know whether upper levels have an alternative plan should things go wrong and upper levels don't necessarily know how many error messages and warnings the lower levels have issued. So, yes, AVRDUDE tends to overcomplain, and sometimes doesn't get the error/warning level right. We won't be able to fix that but have done a lot of work to smoothen out communication in standard cases.

The FamilyID is a thing, albeit one that Microchip botched. This is a situation where AVRDUDE cannot read the signature and thus cannot really verify that it's the chip the user said it is. Early on, AVRDUDE tried to evaluate the FamilyID, but Microchip subsequently has failed to put a reasonable string into the space foreseen for the FamilyID in their SIB for the series of chips they developed later on. Rather than AVR DA, AVR Ex, or similar they actually "encode" different one with "AVR " and " AVR", believe it or not. To make things worse, AVRDUDE's config file seems to have mistakenly put the wrong expected FamilyID into 64da64's entry in this case. I have long doubted the utility of this FamilyID check, so am tempted to just drop FamilyID from the code and config file. @MCUdude? @dl8dtl? @mcuee?

[MCUdude]

I don't have an AVR64DA64, but I do have an AVR128DA64. And this has the AVR family ID. I just gave it a try. So I don't know how the AVR64DA64 ever got that AVR family ID.

The story I've been told is that they messed up when they released the DA series with AVR, and corrected new chips (ABR DB, DD etc.) with AVR instead. so again, I have no idea how or why the 64DA64 is different than the rest of the DAs (I've currently tested the 128DA64, 128DA48 and 128DA28). So yes, I'd vote for dropping the family ID.

But the other lock "errors" should perhaps be turned into warnings.

But it doesn't serve any purpose for Avrdude anymore. Is we really want that we can just read the SIB, something that wasn't possible a few Avrdude versions ago.

[stefanrueger]

the other lock "errors" should perhaps be turned into warnings

It's as fatal as it can get, leading straight to being unable to read the signature. And the only remedy is CE. So, that's way more than just a mere warning from almost any vantage point except when you know a CE is the master plan all along... but that's nothing that the low-level routine can or should know. I hope users can live with this situation being communicated as error.

[mcuee]

I have long doubted the utility of this FamilyID check, so am tempted to just drop FamilyID from the code and config file. @MCUdude? @dl8dtl? @mcuee?

Looks like a good move to me.