xplainedmini_dw upload not working

[maxgerhardt]

Hardware

ATMega328P XPlainedMini (mEDBG probe on-board)

Software:

Latest avrdude 7.1 release for Windows x64

Problem description

When debugWire mode has been enabled through Microchip Studio, and avrdude is instructed to program a .hex file onto the chip in debugWire mode, programming fails.

Output

C:\Users\Max\Downloads\avrdude-v7.1-windows-x64\avrdude.exe -C C:\Users\Max\Downloads\avrdude-v7.1-windows-x64\avrdude.conf -p m328p -P usb -c xplainedmini_dw -e -U flash:w:.pio\build\ATmega328P\firmware.hex:i
         Vtarget         : 5.00 V

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude error: chip erase not supported in debugWire mode
avrdude: reading input file .pio\build\ATmega328P\firmware.hex for flash
         with 2456 bytes in 1 section within [0, 0x997]
         using 20 pages and 104 pad bytes
avrdude: writing 2456 bytes flash ...

Writing | #####--------------------------------------------- | 10% 1.52s

 ***failed;
[...]
avrdude error: JTAGICE3_DW programmer uses avr_write_page() but does not
        provide a cmd() method
 *** page 0 (addresses 0x0000 - 0x007f) failed to write
[...]
avrdude error: JTAGICE3_DW programmer uses avr_write_page() but does not
        provide a cmd() method
 *** page 19 (addresses 0x0918 - 0x0997) failed to write

avrdude: 2456 bytes of flash written
avrdude: verifying flash memory against .pio\build\ATmega328P\firmware.hex

Reading | ##------------------------------------------------ | 5% 0.03s

avrdude error: unable to read byte at address 0x0000
avrdude error: read operation not supported for memory flash
avrdude error: unable to read all of flash memory, rc=-2

avrdude done.  Thank you.

Microchip Studio can write the firmware image to chip just fine when it starts debugging

Or does it do a magical sequence to connect to the debugger, disable debugWire mode and flash it via ISP? But then why is xplainedmini_dw if you can't program it via this protocol?

Also I don't get how avrdude says reading flash memory isn't supported in debugWire mode when Microchip Studio can do it fine

[mcuee]

Just a question, have you enable the DW fuse inside Microchip Studio permanently? If not, Microchip Studio enables DW mode only during debug sessions and then disable it after the debug session.

As of now, avrdude 7.1 is not able to write the fuses with Xplained Mini.

• https://github.com/avrdudes/avrdude/issues/1235

@MCUdude has the PR #1286 to enable that feature. You may want to give it a try.

• 1286

[maxgerhardt]

Just a question, have you enable the DW fuse inside Microchip Studio permanently? If not, Microchip Studio enables DW mode only during debug sessions and then disable it after the debug session.

When debugWire is not enabled, Microchip studio will ask for the fuse to programmed when a debug sesion is started

Click "yes" makes the debug session start. Now there are two options:

Clicking Debug -> Stop Debugging does not seem to disable the DWEN fuse again, as it doesn't ask for the fuse to be enabled again.

Clicking Debug -> "Disable debugWire and Close" resets the DWEN fuse and Microchip studio will ask again to reenable it.

If use "Stop Debugging", avrdude is able to read the chip signature via debugWire.

>C:\Users\Max\Downloads\avrdude-v7.1-windows-x64\avrdude.exe  -p m328p -c xplainedmini_dw

         Vtarget         : 5.00 V

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)

avrdude done.  Thank you.

If I use "Disable debugWire and Close" then avrdude fails completely.

C:\Users\Max>C:\Users\Max\Downloads\avrdude-v7.1-windows-x64\avrdude.exe  -p m328p -c xplainedmini_dw

         Vtarget         : 5.00 V

avrdude error: device is locked; chip erase required to unlock
avrdude error: device is locked; chip erase required to unlock
avrdude error: initialization failed, rc=-1
        - double check the connections and try again
        - use -B to set lower ISP clock frequency, e.g. -B 125kHz
        - use -F to override this check

avrdude done.  Thank you.

From that I conclude that in the above example where a flash write was attempted to be executed, debugWire was properly enabled.

[mcuee]

@maxgerhardt I see. In that case, DebugWire is properly enabled.

@MCUdude I have misplaced my ATmega328PB Xplained Mini so that I can not test this issue. Please help to confirm if this is a bug or not. Thanks.

[mcuee]

@maxgerhardt

I have found my ATmega328PB Xplained Mini board. Could you please provide the Micrcohip Studio project file in zip format so that I can try it as well? Thanks.

[maxgerhardt]

The example is the standard blink LED example for the board that comes up in the "New ASF example project" dialog.

MEGA_LED_EXAMPLE1.zip

I have gotten further with AVR-GDB + AVaRICE, and that software can write the firmware to it over debugWire, so now I'm even more convinced that this is a bug in avrdude.

avr-gdb.exe -batch -ex "target extended-remote :3232" -ex "load" firmware.elf

makes AVaRICE say

>avarice.exe --edbg --debugwire --debug :3232
[...]
committing to flash
jtagWrite
command "write memory" [0x12, 0x23]
0E 00 0E 00 12 23 00 B0 00 00 00 00 80 00 00 00 00 0C 94 66 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 D6 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 0C 94 83 00 00 00 00 00 24 00 27 00 2A 00 00 00 00 00 25 00 28 00 2B 00 00 00 00 00 00
Received 0x81 0x11 0x00 0x06 0x0e 0x0e
read:  0e 0e 00 12 80 00

[mcuee]

@maxgerhardt

I found my ATmega328PB-xmini, however, I can not get the debugging working under Microchip Studio. Sorry but I am not familiar with Microchip Studio myself. Somehow I can not select the mDBG tool.

I want to get this working first before trying avrdude so that I know how to recover.

Using Tools -- Device Programming and then I am able to program the chip properly and it is working (push the button and then the LED will turn on).

[mcuee]

@MCUdude

Just wondering if you can give this a try to confirm the issue. Thanks.

[mcuee]

@maxgerhardt It turns out I need to change the device in order to select mDBG as the debugging tool, since I have the ATmega328PB-xmini.

[mcuee]

@maxgerhardt

I can reproduce the issue.

Note to myself: if I stop debugging, DW will still be enabled. Once I close Microchip Studio, DW fuse will be disabled again. So this is pretty safe.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c xplainedmini_dw -p m328pb

         Vtarget         : 5.00 V

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9516 (probably m328pb)

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c xplainedmini_dw -p m328pb -U .\MEGA_LED_EXAMPLE1.hex

         Vtarget         : 5.00 V

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9516 (probably m328pb)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude error: chip erase not supported in debugWire mode
avrdude: reading input file .\MEGA_LED_EXAMPLE1.hex for flash
         with 1424 bytes in 1 section within [0, 0x58f]
         using 12 pages and 112 pad bytes
avrdude: writing 1424 bytes flash ...

Writing | #################--------------------------------- | 33% 3.23 s

 ***failed;
 ***failed;
...
...
 ***failed;
avrdude error: JTAGICE3_DW programmer uses avr_write_page() but does not
        provide a cmd() method
 *** page 0 (addresses 0x0000 - 0x007f) failed to write

 ***failed;
 ***failed;
...
...

 ***failed;
 ***failed;
avrdude error: JTAGICE3_DW programmer uses avr_write_page() but does not
        provide a cmd() method
 *** page 11 (addresses 0x0510 - 0x058f) failed to write

avrdude: 1424 bytes of flash written
avrdude: verifying flash memory against .\MEGA_LED_EXAMPLE1.hex

Reading | ####---------------------------------------------- | 8% 0.03 s

avrdude error: unable to read byte at address 0x0000
avrdude error: read operation not supported for memory flash
avrdude error: unable to read all of flash memory, rc=-2

avrdude done.  Thank you.

[maxgerhardt]

And that is with the version that already has https://github.com/avrdudes/avrdude/pull/1286 merged?

[mcuee]

And that is with the version that already has #1286 merged?

Yes, this is with latest git main (https://github.com/avrdudes/avrdude/commit/7a8d257676ca858f4c00e61c09885234c64a880f).

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude
Usage: avrdude [options]
Options:
  -p <partno>                Specify AVR device
  -p <wildcard>/<flags>      Run developer options for matched AVR devices
  -b <baudrate>              Override RS-232 baud rate
  -B <bitclock>              Specify bit clock period (us)
  -C <config-file>           Specify location of configuration file
  -c <programmer>            Specify programmer type
  -c <wildcard>/<flags>      Run developer options for matched programmers
  -A                         Disable trailing-0xff removal from file and AVR read
  -D                         Disable auto erase for flash memory; implies -A
  -i <delay>                 ISP Clock Delay [in microseconds]
  -P <port>                  Specify connection port
  -F                         Override invalid signature or initialisation check
  -e                         Perform a chip erase
  -O                         Perform RC oscillator calibration (see AVR053)
  -U <memtype>:r|w|v:<filename>[:format]
                             Memory operation specification
                             Multiple -U options are allowed, each request
                             is performed in the order specified
  -n                         Do not write anything to the device
  -V                         Do not verify
  -t                         Enter terminal mode
  -E <exitspec>[,<exitspec>] List programmer exit specifications
  -x <extended_param>        Pass <extended_param> to programmer
  -v                         Verbose output; -v -v for more
  -q                         Quell progress output; -q -q for less
  -l logfile                 Use logfile rather than stderr for diagnostics
  -?                         Display this usage

avrdude version 7.1-20230322 (7a8d257), URL: <https://github.com/avrdudes/avrdude>

[mcuee]

And that is with the version that already has #1286 merged?

@maxgerhardt

BTW, if you want to try latest git main, you can always get from the links here, if you do not want to build the binary from source. https://github.com/avrdudes/avrdude/wiki/Getting-Nightly-Builds-for-AVRDUDE

[mcuee]

@MCUdude

Just wondering if you have a chance to see if you can reproduce the issue. Thanks.

[MCUdude]

Well, I'm sure I could confirm that this is in fact an issue, but I'm not sure how to fix the root cause. Even Microchip themselves tells us that the mEDBG programmers/debuggers have serious limitations and may be unstable in comparison to the nEDBG.

One quirk with the mEDBG debugWire is that it (the ATmega32U4) has to provide the 8/16MHz clock (CKOUT) to the target in order to be able to communicate with it.

[MCUdude]

When briefly looking at the jtag3.c source code, it seems like the Xplained Mini debugWire gets the same "treatment" as all the other debugWire compatible programmers. So Avrdude is probably trying to do/send a command that the xplainedmini_dw doesn't support. The question is, are you available to communicate with the mEDBG chip after a failed flashing attempt, or do you have to power-cycle the board?

[MCUdude]

Somehow, Avrdude ends up calling avr_write_page(), which relies on pgm->cmd, which none of the EDBG programmers have. I'm not sure where this happens, and I also think it's strange that this doesn't happen to other JTAG3 dW programmers as well.

[MCUdude]

I can't reproduce the issue on my mac:

$ ./avrdude -cxplainedmini_dw -patmega328pb -Uflash:w:/var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_24845/BlinkWithoutDelay.ino.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9516 (probably m328pb)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude error: chip erase not supported in debugWire mode

avrdude: processing -U flash:w:/var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_24845/BlinkWithoutDelay.ino.hex:i
avrdude: reading input file /var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_24845/BlinkWithoutDelay.ino.hex for flash
         with 1170 bytes in 1 section within [0, 0x491]
         using 10 pages and 110 pad bytes
avrdude: writing 1170 bytes flash ...
Writing | ################################################## | 100% 3.37 s 
avrdude: 1170 bytes of flash written
avrdude: verifying flash memory against /var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_24845/BlinkWithoutDelay.ino.hex
Reading | ################################################## | 100% 0.41 s 
avrdude: 1170 bytes of flash verified

avrdude done.  Thank you.

[maxgerhardt]

With which commit of avrdude is that?

[MCUdude]

Compiled from the latest git main

[MCUdude]

I just tried to write a 32768 bytes large file, and this was flashed without any errors:

$./avrdude -cxplainedmini_dw -patmega328pb -Uflash:w:the_quick_32k.hex 
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9516 (probably m328pb)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude error: chip erase not supported in debugWire mode

avrdude: processing -U flash:w:the_quick_32k.hex:i
avrdude: reading input file the_quick_32k.hex for flash
         with 32768 bytes in 1 section within [0, 0x7fff]
         using 256 pages and 0 pad bytes
avrdude: writing 32768 bytes flash ...
Writing | ################################################## | 100% 85.44 s 
avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against the_quick_32k.hex
Reading | ################################################## | 100% 11.19 s 
avrdude: 32768 bytes of flash verified

avrdude done.  Thank you.

[maxgerhardt]

Let me cross-verify this on my computer..

[MCUdude]

I just tried uploading using the xplainedmini_dw programmer using Avrdude 7.1, and it failed. However, when using git main the exact same procedure worked perfectly fine.

It would be interesting to know which commit solved this issue!

Waiting to hear back from @maxgerhardt

Avrdude 7.1 using the xplainedmini_dw programmer

``` $ /Users/hans/Library/Arduino15/packages/MiniCore/tools/avrdude/7.1-arduino.1/bin/avrdude -C/Users/hans/Library/Arduino15/packages/MiniCore/hardware/avr/2.2.1/avrdude.conf -patmega328pb -cxplainedmini_dw -Uflash:w:blink-m16.hex Vtarget : 5.00 V avrdude: AVR device initialized and ready to accept instructions avrdude: device signature = 0x1e9516 (probably m328pb) avrdude: Note: flash memory has been specified, an erase cycle will be performed. To disable this feature, specify the -D option. avrdude: erasing chip avrdude error: chip erase not supported in debugWire mode avrdude: reading input file blink-m16.hex for flash with 988 bytes in 1 section within [0, 0x3db] using 8 pages and 36 pad bytes avrdude: writing 988 bytes flash ... Writing | #############------------------------------------- | 25% 1.52 s ***failed; ***failed; ***failed; ***failed; avrdude error: JTAGICE3_DW programmer uses avr_write_page() but does not provide a cmd() method *** page 0 (addresses 0x0000 - 0x007f) failed to write [...] ***failed; ***failed; ***failed; ***failed; avrdude error: JTAGICE3_DW programmer uses avr_write_page() but does not provide a cmd() method *** page 7 (addresses 0x035c - 0x03db) failed to write avrdude: 988 bytes of flash written avrdude: verifying flash memory against blink-m16.hex Reading | ######-------------------------------------------- | 12% 0.03 s avrdude error: unable to read byte at address 0x0000 avrdude error: read operation not supported for memory flash avrdude error: unable to read all of flash memory, rc=-2 avrdude done. Thank you. ``` (I know that a blink program compiled for an "m16" will never work on a 328pb. It was just a random test file I happened to use this time)

"Git main" Avrdude using the xplainedmini_dw programmer

``` $ ./avrdude -patmega328pb -cxplainedmini_dw -Uflash:w:blink-m16.hex avrdude: AVR device initialized and ready to accept instructions avrdude: device signature = 0x1e9516 (probably m328pb) avrdude: Note: flash memory has been specified, an erase cycle will be performed. To disable this feature, specify the -D option. avrdude: erasing chip avrdude error: chip erase not supported in debugWire mode avrdude: reading input file blink-m16.hex for flash with 988 bytes in 1 section within [0, 0x3db] using 8 pages and 36 pad bytes avrdude: writing 988 bytes flash ... Writing | ################################################## | 100% 2.70 s avrdude: 988 bytes of flash written avrdude: verifying flash memory against blink-m16.hex Reading | ################################################## | 100% 0.33 s avrdude: 988 bytes of flash verified avrdude done. Thank you. ```

[MCUdude]

I can trace the fix down to @stefanrueger's PR #1343. This PR is pretty large, but it has some debugWire fixes in it that may have resolved this issue, which is pretty awesome!

[maxgerhardt]

It successfully worked for me with the git master version.

avrdude.exe  -cxplainedmini -patmega328p -Uflash:w:C:\Users\Max\temp\xplained\.pio\build\nanoatmega328\firmware.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip

avrdude: processing -U flash:w:C:\Users\Max\temp\xplained\.pio\build\nanoatmega328\firmware.hex:i
avrdude: reading input file C:\Users\Max\temp\xplained\.pio\build\nanoatmega328\firmware.hex for flash
         with 924 bytes in 1 section within [0, 0x39b]
         using 8 pages and 100 pad bytes
avrdude: writing 924 bytes flash ...
Writing | ################################################## | 100% 1.01 s
avrdude: 924 bytes of flash written
avrdude: verifying flash memory against C:\Users\Max\temp\xplained\.pio\build\nanoatmega328\firmware.hex
Reading | ################################################## | 100% 0.95 s
avrdude: 924 bytes of flash verified

avrdude done.  Thank you.

same with _dw, works now

\avrdude.exe  -cxplainedmini_dw -patmega328p -Uflash:w:C:\Users\Max\temp\xplained\.pio\build\nanoatmega328\firmware.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude error: chip erase not supported in debugWire mode

avrdude: processing -U flash:w:C:\Users\Max\temp\xplained\.pio\build\nanoatmega328\firmware.hex:i
avrdude: reading input file C:\Users\Max\temp\xplained\.pio\build\nanoatmega328\firmware.hex for flash
         with 924 bytes in 1 section within [0, 0x39b]
         using 8 pages and 100 pad bytes
avrdude: writing 924 bytes flash ...
Writing | ################################################## | 100% 2.70 s
avrdude: 924 bytes of flash written
avrdude: verifying flash memory against C:\Users\Max\temp\xplained\.pio\build\nanoatmega328\firmware.hex
Reading | ################################################## | 100% 0.33 s
avrdude: 924 bytes of flash verified

avrdude done.  Thank you.

so, this issue is obsolete now.

[mcuee]

I can trace the fix down to @stefanrueger's PR #1343. This PR is pretty large, but it has some debugWire fixes in it that may have resolved this issue, which is pretty awesome!

Great job to close this issue and identify the PR which fixed the issue!