On 1.6.2 upload to AVR64DD14 fails with prog.py: error: unrecognized arguments

[technoblogy]

On DxCore 1.6.2 uploading a small program to the AVR64DD14 (no bootloader) fails with:

An error occurred while uploading the sketch
usage: prog.py [-h] [-a ACTION] [-b BAUDRATE] [-wc WRITE_CHUNK]
               [-rc READ_CHUNK] [-d DEVICE] [--fuses FUSES [FUSES ...]]
               [--fuses_print] [-f FILENAME] [-wd WRITEDELAY] [-t TOOL]
               [-u UART] [-v]
prog.py: error: unrecognized arguments: -Ufuse5:w:0b1101101:m 6:0b00001100 7:0x00 8:0x00

All Board options at defaults. Upload via SerialUPDI.
System: DxCore 1.6.2, Arduino 1.8.19 running on a Mac Mini M4, Mac OS Sequoia.

It works on DxCore 1.5.11.

[XFer012]

Same here (Windows 10, Arduino IDE 1.8.19):

Linking everything together...
"C:\Users\Fernando\AppData\Local\Arduino15\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino8/bin/avr-gcc" -Wall -Os -g -flto -fuse-linker-plugin -mrelax -Wl,--gc-sections,--section-start=.text=0x0,--section-start=.FLMAP_SECTION1=0x8000,--section-start=.FLMAP_SECTION2=0x10000,--section-start=.FLMAP_SECTION3=0x18000 -mmcu=avr64dd14 -o "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.elf" "D:\Arduino\arduino-build-output\sketch\AVR_New_Sleep_PIT.ino.cpp.o" "D:\Arduino\arduino-build-output/core\core.a" "-LD:\Arduino\arduino-build-output" -lm
"C:\Users\Fernando\AppData\Local\Arduino15\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino8/bin/avr-objcopy" -O binary -R .eeprom "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.elf" "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.bin"
"C:\Users\Fernando\AppData\Local\Arduino15\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino8/bin/avr-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.elf" "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.eep"
"C:\Users\Fernando\AppData\Local\Arduino15\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino8/bin/avr-objcopy" -O ihex -R .eeprom "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.elf" "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.hex"
cmd /C echo. && "C:\Users\Fernando\AppData\Local\Arduino15\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino8/bin/avr-objdump" --disassemble --source --line-numbers --demangle --section=.text "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.elf" > "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.lst"

cmd /C echo. && "C:\Users\Fernando\AppData\Local\Arduino15\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino8/bin/avr-nm" --numeric-sort --line-numbers --demangle --print-size --format=s "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.elf" > "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.map"

"C:\Users\Fernando\AppData\Local\Arduino15\packages\DxCore\tools\avr-gcc\7.3.0-atmel3.6.1-azduino8/bin/avr-size" -A "D:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.elf"
Sketch uses 1054 bytes (1%) of program storage space. Maximum is 65536 bytes.
Global variables use 169 bytes (2%) of dynamic memory, leaving 8023 bytes for local variables. Maximum is 8192 bytes.
C:\Users\Fernando\AppData\Local\Arduino15\packages\megaTinyCore\tools\python3\3.7.2-post1/python3 -u C:\Users\Fernando\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.6.2/tools/prog.py -t uart -u COM6 -b 57600 -d avr64dd14 --fuses 2:0b00000000 -Ufuse5:w:0b1101101:m 6:0b00010000 7:0x00 8:0x00 -fD:\Arduino\arduino-build-output/AVR_New_Sleep_PIT.ino.hex -a write -v
usage: prog.py [-h] [-a ACTION] [-b BAUDRATE] [-wc WRITE_CHUNK]
[-rc READ_CHUNK] [-d DEVICE] [--fuses FUSES [FUSES ...]]
[--fuses_print] [-f FILENAME] [-wd WRITEDELAY] [-t TOOL]
[-u UART] [-v]
prog.py: error: unrecognized arguments: -Ufuse5:w:0b1101101:m 6:0b00010000 7:0x00 8:0x00
prog.py: error: unrecognized arguments: -Ufuse5:w:0b1101101:m 6:0b00010000 7:0x00 8:0x00

[jenschr]

I can also confirm this error. Using a breakout with a NanoUPDI serial programmer.

Incorrect output:
/Users/jensa/Library/Arduino15/packages/megaTinyCore/tools/python3/3.7.2-post1/python3 -u /Users/jensa/Library/Arduino15/packages/DxCore/hardware/megaavr/1.6.2/tools/prog.py -t uart -u /dev/cu.usbserial-1430 -b 230400 -d avr64dd14 --fuses 2:0b00000000 -Ufuse5:w:0b1101101:m 6:0b00001100 7:0x00 8:0x00 -f/var/folders/t2/6m0f3ybs5rsbsdbfl_gg77fw0000gp/T/arduino_build_349409/test.ino.hex -a write -v

It looks like some parsing error occurs that is outputting the following incorrect statement: "-Ufuse5:w:0b1101101:m"

Manually corrected output:
/Users/x/Library/Arduino15/packages/megaTinyCore/tools/python3/3.7.2-post1/python3 -u /Users/x/Library/Arduino15/packages/DxCore/hardware/megaavr/1.6.2/tools/prog.py -t uart -u /dev/cu.usbserial-1430 -b 230400 -d avr64dd14 --fuses 2:0b00000000 5:0b1101101 6:0b00001100 7:0x00 8:0x00 -f/var/folders/t2/6m0f3ybs5rsbsdbfl_gg77fw0000gp/T/arduino_build_349409/test.ino.hex -a write -v

Upload via SerialUPDI.
System: DxCore 1.6.2, Arduino 1.8.13 running on a MacbookPro i9/2.9Ghz, Mac OS Ventura 13.1.

Board options:

[k-takata]

Same here.

It seems that boards.txt has mistakes:

--- a/megaavr/boards.txt
+++ b/megaavr/boards.txt
@@ -1221,8 +1221,8 @@ avrdd.upload.maximum_size=0
 avrdd.upload.maximum_data_size=0
 # The maximum size and data size attributes are overridden by the selected chip. If you are avoiding specifying that somehow, there is no hope of anything working, so don't do that.
 # Each top-level entry supports at least a dozen parts with varying memory constraints.
-avrdd.program.serupdifuse5="-Ufuse5:w:{bootloader.SYSCFG0}:m"
-avrdd.program.avrdudefuse5=5:{bootloader.SYSCFG0}
+avrdd.program.avrdudefuse5="-Ufuse5:w:{bootloader.SYSCFG0}:m"
+avrdd.program.serupdifuse5=5:{bootloader.SYSCFG0}
 
 
 #----------------------------------------#

[k-takata]

After updating boards.txt, I can upload a program to AVR64DD28 once.
But it doesn't work.

Then I cannot upload the program anymore:

pymcuprog.programmer - INFO - Setting up programming session for 'avr64dd28'
pymcuprog.deviceinfo.deviceinfo - INFO - Looking for device avr64dd28
pymcuprog.serialupdi.physical - INFO - Opening port 'COM6' at '115200' baud
pymcuprog.serialupdi.link - INFO - STCS 08 to 0x03
pymcuprog.serialupdi.link - INFO - STCS 06 to 0x02
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.link - WARNING - UPDI init failed: Can't read CS register. likely wiring error.
pymcuprog.serialupdi.physical - INFO - extra-long break requested. Close serial port, reopen @ 300, send 0x00, receive the 0x00, and then proceed. 
pymcuprog.serialupdi.physical - INFO - Double-break sent. Re-initializeing USART to retry.
pymcuprog.serialupdi.physical - INFO - Opening port 'COM6' at '115200' baud
pymcuprog.serialupdi.link - INFO - STCS 08 to 0x03
pymcuprog.serialupdi.link - INFO - STCS 06 to 0x02
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.link - WARNING - UPDI init failed: Can't read CS register. likely wiring error.

[k-takata]

Then I cannot upload the program anymore:

Does this fix it?
#638

[flowernert]

AVR64DD32 on custom board
Same issue here, same resolving process and same bricking after programming it one time by editing the generated command line to input fuse 5 in the expected format and running it in a CLI

[k-takata]

I've created a device to restore the bricked AVR DD device by applying a 7.5V HV pulse:
https://github.com/k-takata/PCB_avr_dx_unbricker

I've also confirmed that 1.6.2 works when the above change and #638 are both applied.

[giusmos]

I've created a device to restore the bricked AVR DD device by applying a 7.5V HV pulse: https://github.com/k-takata/PCB_avr_dx_unbricker

I've also confirmed that 1.6.2 works when the above change and #638 are both applied.

It's not clear to me what exactly should I apply from #638. Before finding this thread I got from claude the suggestion to swap lines 1230 and 1231, thus replacing:

avrdd.program.serupdifuse5="-Ufuse5:w:{bootloader.SYSCFG0}:m"
avrdd.program.avrdudefuse5=5:{bootloader.SYSCFG0}

with:

avrdd.program.serupdifuse5=5:{bootloader.SYSCFG0}
avrdd.program.avrdudefuse5="-Ufuse5:w:{bootloader.SYSCFG0}:m"

Is this wrong? Can you help me understand the right procedure to avoid bricking my AVR64DD28 ?

[k-takata]

@giusmos

It is not sufficient, and it bricks the device.
You must also change the avrdd.bootloader.SYSCFG0 line as written in #638.

This is the complete patch to fix the issue:

--- boards.txt.orig
+++ boards.txt
@@ -1209,7 +1209,7 @@
 avrdd.bootloader.wdttimeotbits=0000
 avrdd.bootloader.BODCFG=0b{bootloader.bodlevbits}{bootloader.bodmodebits}
 avrdd.bootloader.updipinbit=1
-avrdd.bootloader.SYSCFG0=0b110{bootloader.updipinbit}{bootloader.resetpinbit}0{bootloader.eesavebit}
+avrdd.bootloader.SYSCFG0=0b110{bootloader.updipinbit}{bootloader.resetpinbit}00{bootloader.eesavebit}
 avrdd.bootloader.SYSCFG1=0b000{bootloader.mviobits}{bootloader.sutbits}
 avrdd.bootloader.CODESIZE=0x00
 avrdd.bootloader.BOOTSIZE=0x01
@@ -1227,8 +1227,8 @@
 avrdd.upload.maximum_data_size=0
 # The maximum size and data size attributes are overridden by the selected chip. If you are avoiding specifying that somehow, there is no hope of anything working, so don't do that.
 # Each top-level entry supports at least a dozen parts with varying memory constraints.
-avrdd.program.serupdifuse5="-Ufuse5:w:{bootloader.SYSCFG0}:m"
-avrdd.program.avrdudefuse5=5:{bootloader.SYSCFG0}
+avrdd.program.avrdudefuse5="-Ufuse5:w:{bootloader.SYSCFG0}:m"
+avrdd.program.serupdifuse5=5:{bootloader.SYSCFG0}
 
 
 #----------------------------------------#

[giusmos]

@giusmos

It is not sufficient, and it bricks the device. You must also change the avrdd.bootloader.SYSCFG0 line as written in #638.

This is the complete patch to fix the issue:

--- boards.txt.orig
+++ boards.txt
@@ -1209,7 +1209,7 @@
avrdd.bootloader.wdttimeotbits=0000
avrdd.bootloader.BODCFG=0b{bootloader.bodlevbits}{bootloader.bodmodebits}
avrdd.bootloader.updipinbit=1
-avrdd.bootloader.SYSCFG0=0b110{bootloader.updipinbit}{bootloader.resetpinbit}0{bootloader.eesavebit}
+avrdd.bootloader.SYSCFG0=0b110{bootloader.updipinbit}{bootloader.resetpinbit}00{bootloader.eesavebit}
avrdd.bootloader.SYSCFG1=0b000{bootloader.mviobits}{bootloader.sutbits}
avrdd.bootloader.CODESIZE=0x00
avrdd.bootloader.BOOTSIZE=0x01
@@ -1227,8 +1227,8 @@
avrdd.upload.maximum_data_size=0
The maximum size and data size attributes are overridden by the selected chip. If you are avoiding specifying that somehow, there is no hope of anything working, so don't do that.
Each top-level entry supports at least a dozen parts with varying memory constraints.
-avrdd.program.serupdifuse5="-Ufuse5:w:{bootloader.SYSCFG0}:m"
-avrdd.program.avrdudefuse5=5:{bootloader.SYSCFG0}
+avrdd.program.avrdudefuse5="-Ufuse5:w:{bootloader.SYSCFG0}:m"
+avrdd.program.serupdifuse5=5:{bootloader.SYSCFG0}

#----------------------------------------#

Thanks, I have now understood how to fix the boards.txt file and could program correctly two brand new AVR64DD28 ICs (one in DIP package on a breadboard and one in SSOP package in my own PCB). However, the MCU in the initial board (my custom PCB) that I have been using in the beginning (before being aware of the bug in boards.txt) refuses to program. I use the MPLAB pickit 5 as programmer and Arduino IDE. When I try to run the command below in a terminal:

avrdude -C/home/user/.arduino15/packages/DxCore/tools/avrdude/avrdude_v8.1-released/etc/avrdude.conf -pavr64dd28 -cpickit5_updi -Pusb -B 125kHz -F -v

I get the error below, and the device signature is "00 00 00" instead of the expected "1E 96 1B". Do you think this means that the MCU is bricked?

Using port            : usb
Using programmer      : pickit5_updi
Setting bit clk period: 8.0 us
Usbdev_open(): found MPLAB? PICkit 5, serno: ........
(config 1) Device or resource busy
AVR part              : AVR64DD28
Programming modes     : SPM, UPDI
Programmer type       : pickit5
Description           : MPLAB(R) PICkit 5 in UPDI mode
Application version   : 02.04.54
Serial number         : ........
Target Vdd: 5.04 V, target current: 0 mA
External voltage detected: will not supply power
Error: script error returned: 0x51
Error: reading script response failed
Error: initialization failed  (rc = -1)
 - double check the connections and try again
 - use -B to set lower the bit clock frequency, e.g. -B 125kHz
 - reset the programmer by unplugging it
AVR device initialized and ready to accept instructions
Error: script error returned: 0xE19
Error: reading script response failed
Error: script error returned: 0xE19
Error: reading script response failed
Error: script error returned: 0xE19
Error: reading script response failed
Error: script error returned: 0xE19
Error: reading script response failed
Device signature = 00 00 00 (retrying)
Error: script error returned: 0xE19
Error: reading script response failed
Error: script error returned: 0xE19
Error: reading script response failed
Error: script error returned: 0xE19
Error: reading script response failed
Error: script error returned: 0xE19
Error: reading script response failed
Device signature = 00 00 00 (retrying)
Error: script error returned: 0xE19
Error: reading script response failed
Error: script error returned: 0xE19
Error: reading script response failed
Error: script error returned: 0xE19
Error: reading script response failed
Error: script error returned: 0xE19
Error: reading script response failed
Device signature = 00 00 00
Error: invalid device signature
Warning: expected signature for AVR64DD28 is 1E 96 1B

Avrdude done.  Thank you.

[k-takata]

Do you think this means that the MCU is bricked?

I haven't used PICkit 5, but I think so.
Of course, PICkit 5 supports HV programming; you should be able to unbrick it. (I don't know if AVRDUDE supports HV programming via PICkit 5.)

[giusmos]

Do you think this means that the MCU is bricked?

I haven't used PICkit 5, but I think so. Of course, PICkit 5 supports HV programming; you should be able to unbrick it. (I don't know if AVRDUDE supports HV programming via PICkit 5.)

Yes, the reason why I bought the PICkit 5 is that I was convinced I did brick my MCU after having read about the bug in the boards.txt file. However, I have found out that the real issue was that some of the IC pins where not properly soldered and did not have good electrical contact with the PCB. Among these, it was the UPDI pin. This saved me from bricking the MCU but made me rush to buy this programmer. But the PICKit 5 programmer is really nice, so I do not regret much about having bought it, and if in the future new bugs happen, I have the possibility to unbrick the MCU.