PlatformIO throwing avrdude errors with CuriosityNano AVR128DA48

[Ragnar2022]

I've been developing in PlatformIO on a Nano AVR128DA48 on one Windows 10 machine just fine. Now, I'm trying to get it up and running on another machine (Windows 11) and avrdude is bitching like it's not even connected. I've successfully flashed it through the Arudino IDE 1.8.18 on the Windows 11 machine.

This is what I get in PlatformIO when I try to flash it.

avrdude: bad response to AVR sign-on command: 0xa0
avrdude: retrying with external reset applied
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: retrying with external reset applied
avrdude: JTAGEN fuse disabled?
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

This does not happen on the other machine. I'm using the same PlatformIO Core 6.1.6 on both machines. Thoughts? Prayers?

[Ragnar2022]

UPDATE:
I did some more testing and just tried the avrdude command myself with some verbose-ness. It seems that the device signature is all over the place and not what's expected.

Running command:
avrdude -c pkobn_updi -P usb -F -p avr128da48 -b 115200 -U flash:w:firmware.hex -v

First run:

avrdude.exe: bad response to AVR sign-on command: 0xa0
avrdude.exe: retrying with external reset applied
avrdude.exe: bad response to AVR sign-on command: 0xa0
avrdude.exe: retrying with external reset applied
avrdude.exe: JTAGEN fuse disabled?
avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0x666c61
avrdude.exe: Expected signature for AVR128DA48 is 1E 97 08
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.

Second run:

avrdude.exe: bad response to AVR sign-on command: 0xa0
avrdude.exe: retrying with external reset applied
avrdude.exe: bad response to AVR sign-on command: 0xa0
avrdude.exe: retrying with external reset applied
avrdude.exe: JTAGEN fuse disabled?
avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0x656570
avrdude.exe: Expected signature for AVR128DA48 is 1E 97 08
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.

[SpenceKonde]

Are you uploading via SerialUPDI? That functionality is not supported by the 6.3 version of AVRdude. Some new ones have it, but the core does not make use of those versions,

…

On Wed, Feb 8, 2023 at 10:25 AM Ragnar2022 ***@***.***> wrote: I've been developing in PlatformIO on a Nano AVR128DA48 on one Windows 10 machine just fine. Now, I'm trying to get it up and running on another machine (Windows 11) and avrdude is bitching like it's not even connected. I've successfully flashed it through the Arudino IDE 1.8.18 on the Windows 11 machine. This is what I get in PlatformIO when I try to flash it. avrdude: bad response to AVR sign-on command: 0xa0 avrdude: retrying with external reset applied avrdude: bad response to AVR sign-on command: 0xa0 avrdude: retrying with external reset applied avrdude: JTAGEN fuse disabled? avrdude: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check. This does not happen on the other machine. I'm using the same PlatformIO Core 6.1.6 on both machines. Thoughts? Prayers? — Reply to this email directly, view it on GitHub <#394>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEWYQOTOCV6R2K66D6LDWWO3FVANCNFSM6AAAAAAUVMXDTE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

--

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support for all post-2016 tinyAVR parts! DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: ***@***.***

[SpenceKonde]

Also if it's the onboard USB debugger, you are specifying the wrong programmer. I've never seen that before, but it's not the nano programmer. That looks like maybe jtag2updi or some jtag2updi-like "fake" jtag programmer - but in the former case, it's not working, and in the latter case, it's something I haven't even heard of...

[Ragnar2022]

It's whatever programmer is on the CuriosityNano board, this guy, http://ww1.microchip.com/downloads/en/DeviceDoc/AVR128DA48-Curiosity-Nano-UG-DS50002971A.pdf

Board machines (Win 10 and Win 11) have the same version of AVRdude too. When I run it on the machine that works (Win 10) it shows it's using pkobn_updi which is obviously part of the avrdude.conf file.

[SpenceKonde]

This is what the core uses on Arduino for programmer options. I have no idea what pkobn_updi is or who created it or why but suddenly people are trying to use it. And reporting the fact that it doesn't work to me, as if I am supposed to be able to do anything about it. This issue should be directed to the author of the program that is invoking avrdude with the wrong programmer.

Notice that nothing uses pkobn_updi here. This is one of the infuriating things about third party IDEs. I make a board manager json file that points to a known workinig version of avrdude, includes a known working, compatible version of avrdude.conf, a programers.txt that references programmers and settings known to work, and boards.txt that provides tools submenus and that and platform.txt that ensure that there will be a combination of those settings used which works with the core (that is, the C/C++ source for all the API functions). I build a toolchain package that includes support for all the parts every time Microchip releases some new part to incorperate the latest packs.

jtag2updi.name=jtag2updi
jtag2updi.communication=serial
jtag2updi.protocol=jtag2updi
jtag2updi.program.protocol=jtag2updi
jtag2updi.program.tool=avrdude
jtag2updi.program.extra_params=-P{serial.port} -b{program.speed}
jtag2updi.program.speed=115200


nedbg.name=Curiosity Nano (nEDBG, debug chip: ATSAMD21E18)
nedbg.communication=usb
nedbg.protocol=curiosity_updi
nedbg.program.protocol=curiosity_updi
nedbg.program.tool=avrdude
nedbg.program.extra_params=-Pusb

edbg.name=Xplained Pro (EDBG, debug chip: AT32UC3A4256)
edbg.communication=usb
edbg.protocol=xplainedpro_updi
edbg.program.protocol=xplainedpro_updi
edbg.program.tool=avrdude
edbg.program.extra_params=-Pusb

medbg.name=Xplained Mini (mEDBG, debug chip: ATmega32u4)
medbg.communication=usb
medbg.protocol=xplainedmini_updi
medbg.program.protocol=xplainedmini_updi
medbg.program.tool=avrdude
medbg.program.extra_params=-Pusb

atmelice_updi.name=Atmel-ICE
atmelice_updi.communication=usb
atmelice_updi.protocol=atmelice_updi
atmelice_updi.program.protocol=jtagice3_updi
atmelice_updi.program.tool=avrdude
atmelice_updi.program.extra_params=-Pusb

pickit4_updi.name=PICkit4 (UPDI mode)
pickit4_updi.communication=usb
pickit4_updi.protocol=pickit4_updi
pickit4_updi.program.protocol=jtagice3_updi
pickit4_updi.program.tool=avrdude
pickit4_updi.program.extra_params=-Pusb

snap_updi.name=MPLAB SNAP (UPDI mode)
snap_updi.communication=usb
snap_updi.protocol=snap_updi
snap_updi.program.protocol=jtagice3_updi
snap_updi.program.tool=avrdude
snap_updi.program.extra_params=-Pusb

Arduino, on a board manager install, will always use precisely the same version of AVRdude (and of SerialUPDI): the one I specify. The one that I tested and that I know works. Or it will use serialUPDI (the version I supply as part of the core) and either system python version or the package i specify is installed by board manager on windows where we can't assume that there's python. It will always use the version of the toolchain that was specified by the board manager json and which is hence known to work.

Third party IDE's pick and choose whatever the fuck they want, as if you can arbitrarily mix different pieces. "Oh we'll compile this core, with that toolchain and expect to be able to use some other version of avrdude with some other version of avrdude.conf" - and no matter what part is wrong, they report it to me like I'm supposed to know how to fix it. It's like some used car lot had a bunch of toyota bodys and frames, but no other appropriate parts, so they hacked them together using bicycle wheels, the engine from a lawn mower and the steering wheel and rudder of a motorboat and chairs they found by the side of the road for the seats.... and then, when the ungodly contraption doesn't work because the rudder is digging into the dirt, the rear wheels are in the air, the front wheels are crushed under the weight, the engine doesn't start, and/or the seat collapses under them because it was stored outdoors and rotted out, what does the user do? They call toyota's support line....

[SpenceKonde]

At this point I have no reason to believe that this problem has anything to do with my core as it's using a programmer that we never specify nor supply in our avrdude.conf. As far as I'm concerned, the system that doesn't work is working correctly and the one that does work is the surprising one.

Edit: Oh it's a discussion not an issue. Okay, so marking it not our bug.