Problem with unhandled UPDI response

[replaysMike]

I've encountered an issue that I'm not sure if it is a new bug or an unhandled hardware response.

I am using an Adafruit HV UPDI Friend to program an ATTINY3224 after changing the UPDI pin to GPIO as I need the extra input pin. I had no issues burning the fuses the first time and went through all the suggested configuration thankfully posted in a previous issue.

Using the HV programmer to upload new code to the 3224 (or burning new bootloader), this is the exception response output during upload, it seems its getting some unexpected output Unexpected number of bytes in response: 0 byte(s) expected 1 byte(s):

"C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\tools\python3\3.7.2-post1/python3" -u "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10/tools/prog.py"  -t uart -u COM8 -b 230400 -d attiny3224 --fuses 0:0b00000000 2:0x02 6:0x04 7:0x00 8:0x00 "-fC:\Users\mikeb\AppData\Local\arduino\sketches\DCC7B13FF25B122DB8CDF5C481CD5652/CabinetAssembly_AdafruitGFX.ino.hex" -a write -v
SerialUPDI
UPDI programming for Arduino using a serial adapter
Based on pymcuprog, with significant modifications
By Quentin Bolsee and Spence Konde
Version 1.2.3 - Jan 2022
Using serial port COM8 at 230400 baud.
Target: attiny3224
Set fuses: ['0:0b00000000', '2:0x02', '6:0x04', '7:0x00', '8:0x00']
Action: write
File: C:\Users\mikeb\AppData\Local\arduino\sketches\DCC7B13FF25B122DB8CDF5C481CD5652/CabinetAssembly_AdafruitGFX.ino.hex
pymcuprog.programmer - INFO - Setting up programming session for 'attiny3224'
pymcuprog.deviceinfo.deviceinfo - INFO - Looking for device attiny3224
pymcuprog.serialupdi.physical - INFO - Opening port 'COM8' 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 - INFO - UPDI init OK
pymcuprog.serialupdi.link - INFO - STCS 06 to 0x02
pymcuprog.serialupdi.link - INFO - Setting UPDI clock to 8 MHz
pymcuprog.serialupdi.link - INFO - STCS 02 to 0x09
pymcuprog.serialupdi.physical - INFO - Switching to '230400' baud
pymcuprog.serialupdi.application - INFO - SIB: 'tinyAVR P:0D:1-3M2 (00.59B0E.0)'
pymcuprog.serialupdi.application - INFO - Device family ID: 'tinyAVR'
pymcuprog.serialupdi.application - INFO - NVM interface: 'P:0'
pymcuprog.serialupdi.application - INFO - Debug interface: 'D:1'
pymcuprog.serialupdi.application - INFO - PDI oscillator: '3M2'
pymcuprog.serialupdi.application - INFO - Extra info: '(00.59B0E.0)'
pymcuprog.serialupdi.application - INFO - Using 16-bit UPDI
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
Traceback (most recent call last):
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10/tools/prog.py", line 286, in <module>
pymcuprog.serialupdi.physical - INFO - Closing port 'COM8'
    main()
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10/tools/prog.py", line 128, in main
    return_code = pymcuprog_basic(args, fuses_dict)
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10/tools/prog.py", line 201, in pymcuprog_basic
    args_start)
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\pymcuprog_main.py", line 545, in _start_session
    backend.start_session(sessionconfig)
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\backend.py", line 362, in start_session
    sessionconfig.interface_speed)
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\programmer.py", line 83, in setup_device
    options=self.options)
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\nvm.py", line 42, in get_nvm_access_provider
    accessprovider = NvmAccessProviderSerial(transport, device_info, baud=frequency, options=options)
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\nvmserialupdi.py", line 57, in __init__
    self.avr.read_device_info()
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\serialupdi\application.py", line 125, in read_device_info
    self.logger.info("PDI revision = 0x%02X", self.readwrite.read_cs(constants.UPDI_CS_STATUSA) >> 4)
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\serialupdi\readwrite.py", line 25, in read_cs
    return self.datalink.ldcs(address)
  File "C:\Users\mikeb\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\serialupdi\link.py", line 88, in ldcs
    "{} byte(s) expected {} byte(s)".format(numbytes_received, self.LDCS_RESPONSE_BYTES))
pymcuprog.pymcuprog_errors.PymcuprogError: Unexpected number of bytes in response: 0 byte(s) expected 1 byte(s)
Failed programming: uploading error: exit status 1

I'm looking through the megatinycore code now to see if I can find the culprit, though I'm unfamiliar with the code base. Cross-posted at Adafruit Forums as I am unsure if this is a hardware problem with the HV UPDI Friend - it is only sending the initial 12V signal after a power reset.

[replaysMike]

It seems to be a combination of issues, though the log above still applies. The HV UPDI Friend only sends the 12V pulse on the first upload. Subsequent uploads don't send it for some reason so I get the usual WARNING - UPDI init failed: Can't read CS register. With that identified, at least the error above is consistent.

12V spike appears if I unplug the HV UPDI Friend and plug it back in

Subsequent uploads don't send the 12V spike

[hmeijdam]

When I take my 1626 (I have no 3224) and disable the UPDI pin by turning UPDI into RST or GPIO, I cannot upload anything via UPDI anymore with a HV serial CH340G based programmer like you have. I get the exact same error. When I take my Powercycle-HV JTAG programmer I can reprogram and/or change the pin back to UPDI.

My HV serial CH340G based programmer has no problems changing a 204's UPDI pin back and forth between UPDI and GPIO/RST. It always gives a 12V spike, no need to replug. So that's odd of yours as both are based on the same design by Wagminator

[replaysMike]

agreed it is strange. I feel like I might have something else going on here that I haven't been able to find yet. I wonder if there is something wrong with this programmer, I just now tried swapping to another new 3224 and I am unable to program it even without touching the fuse settings. Going to have to narrow it down and maybe get my hands on another HV programmer or build one.

[replaysMike]

actually now it's uploading fine again (no change to reset pin, burned default bootloader). Hrm.