Fix UPDI erase when target is locked

[MCUdude]

This PR resolved issue #1124. Now a chip erase will be performed as long as -e is specified. Note that this is still an issue with the jtag2updi programmer, and appears to either be a JTAGmkII protocol or a jtag2updi limitation.

Regarding the newly added family_id in avrdude.conf. I've been in contact with Microchip directly, and they confirmed that the AVR-DA family_id is shifted to the right (probably a mistake that's too late to fix), while for AVR-DB, AVR-DD, and AVR-EA it's shifted to the left.

Tested and works with SerialUPDI, PICkit4, SNAP, Curiosity Nano and Xplained Mini.

Please review!

[MCUdude]

I forgot to mention, the Avrdude output looks a bit funny when reading the device signature fails. Maybe @stefanrueger has any idea how we can fix this without messing up the formatting for every other progress bar?

$ ./avrdude -cserialupdi -patmega4808 -e

avrdude: UPDI link initialization OK
avrdude: Device is locked
avrdude: NVM type 0: 16-bit, page oriented write
avrdude: Entering NVM programming mode
avrdude: Timeout waiting for device to unlock
avrdude: Failed to enter NVM programming mode: device is locked
avrdude: AVR device initialized and ready to accept instructions

Reading |                                                    | 0% 0.00savrdude: error reading signature data for part "ATmega4808", rc=-3
avrdude: Received FamilyID: "megaAVR"
avrdude: erasing chip

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9650 (probably m4808)
avrdude: Leaving NVM programming mode

avrdude done.  Thank you.

[mcuee]

I forgot to mention, the Avrdude output looks a bit funny when reading the device signature fails. Maybe @stefanrueger has any idea how we can fix this without messing up the formatting for every other progress bar?

Indeed. Maybe a simple return after 0% 0.00s will fix the issue -- that is what I manually do when I post run logs. But maybe @stefanrueger has better idea to fix this.

Example output by adding a return.

$ echo "Hello World" | ./avrdude -cjtag2updi -pavr128da32 -Ueeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9709 (probably avr128da32)
avrdude: reading input file <stdin> for eeprom
avrdude: writing 12 bytes eeprom ...

Writing |                                                    | 0% 0.00s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ####                                               | 8% 0.02s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ########                                           | 16% 0.02s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #############                                      | 25% 0.03s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #################                                  | 33% 0.03s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #####################                              | 41% 0.04s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #########################                          | 50% 0.04s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #############################                      | 58% 0.05s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #################################                  | 66% 0.06s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ######################################             | 75% 0.06s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ##########################################         | 83% 0.07s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ##############################################     | 91% 0.07s
avrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ################################################## | 100% 0.08s

avrdude: 12 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>

Reading | ################################################## | 100% 0.09s

avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x48
avrdude: verification error; content mismatch

avrdude done.  Thank you.

[stefanrueger]

Mixing the progress bar with warning messages is a really hard task: I have added code elsewhere that aborts progress bars on fatal errors, but I have no easy fix for this kind of thing outlined here. Maybe that is one of those things that we need to come back to when there is more time?

[MCUdude]

Maybe that is one of those things that we need to come back to when there is more time?

Definitely. I didn't plan to "fix" the progress bar in this PR anyways, since this is a "general" problem anyways, and has little to do with this PR.

[mcuee]

Tested with snap_updi as well for the "Nano Every" ATmega4808 clone.

• AVRDUDE not erasing locked UPDI device #1124 (comment)

[ElTangas]

I've been on vacations for the last couple of weeks totally isolated from the world :P
I'll take a look and try to see if it's possible to make jtag2updi play more nicely with this patch.