Persistent Code upload failure with updi

Hi, I have started to have an intermittent problem which has now become persistent, and I can’t upload code to my AVR4809. There are two separate 4809s in a project box with separate FTDIs. Each is on its own breadboard. The one uploads fine, the one with the fault now will not upload code and I get this pymcuprog error:

PS C:\Users\Paul\Documents\PlatformIO\Projects\Live\Stepper> pymcuprog write -d atmega4809 -t uart -u COM17 -c 250k -f .pio\build\ATmega4809\firmware.hex - WARNING - Check failed - WARNING - Check failed
Traceback (most recent call last):
  File "c:\users\paul\appdata\local\programs\python\python39\lib\", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "c:\users\paul\appdata\local\programs\python\python39\lib\", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\Paul\AppData\Local\Programs\Python\Python39\Scripts\pymcuprog.exe\", line 7, in <module>
  File "c:\users\paul\appdata\local\programs\python\python39\lib\site-packages\pymcuprog\", line 285, in main
    return pymcuprog_main.pymcuprog(arguments)
  File "c:\users\paul\appdata\local\programs\python\python39\lib\site-packages\pymcuprog\", line 80, in pymcuprog
    status = _start_session(backend, device_selected, args)
  File "c:\users\paul\appdata\local\programs\python\python39\lib\site-packages\pymcuprog\", line 549, in _start_session
  File "c:\users\paul\appdata\local\programs\python\python39\lib\site-packages\pymcuprog\", line 363, in start_session
  File "c:\users\paul\appdata\local\programs\python\python39\lib\site-packages\pymcuprog\", line 78, in setup_device
    self.device_model = get_nvm_access_provider(self.transport,
  File "c:\users\paul\appdata\local\programs\python\python39\lib\site-packages\pymcuprog\", line 44, in get_nvm_access_provider
    accessprovider = NvmAccessProviderSerial(transport, device_info, baud=frequency, options=options)
  File "c:\users\paul\appdata\local\programs\python\python39\lib\site-packages\pymcuprog\", line 51, in __init__
    self.avr = UpdiApplication(port, baud, self.dut)
  File "c:\users\paul\appdata\local\programs\python\python39\lib\site-packages\pymcuprog\serialupdi\", line 81, in __init__
  File "c:\users\paul\appdata\local\programs\python\python39\lib\site-packages\pymcuprog\serialupdi\", line 60, in init_datalink
    raise PymcuprogError("UPDI initialisation failed")
pymcuprog.pymcuprog_errors.PymcuprogError: UPDI initialisation failed

the pymcuprog command i use for code uploads on the two AVRs is identical:

pymcuprog write -d atmega4809 -t uart -u COM17 -c 250k -f .pio\build\ATmega4809\firmware.hex

So I am hoping someone might have an idea what the problem is. Here’s the things I’ve tried

Checked all the connections on the breadboard
rechecked particularly the UPDI wiring several times
Reseated the 4809 in its zif connector
Reseated the zif in the breadboard (it’s back in EXACTLY the same place btw :slight_smile: )
Checked VCC at the avr4809 VCC pin which is 5.5V (power is derived from the FTDI chip)
Replaced the 1k resistor between the Tx and Rx lnes as per PyUPDI
changed the -c parameter in the pymcuprog command to -c 115200

Restarted the USB hub
Changed the USB cable
Changed the FTDI chip

Is there any thing else I could do before swapping out the AVR4809?

any ideas much appreciated.

I guess it’s worth adding that I know the connections are correct because every now and again, the code will upload - I get a success message, but the code doesn’t seem to run, I have no serial comms for instance via the serial monitor (the code has been tested extensively). I was hoping to upload a blinkled program, but can’t upload at all now.

I just changed the 4809 chip for a new one and things are working again. My knowledge of AVR is a bit limited, do they fail often?

Just to make sure, I’ll replace the working chip with the previous one. Breadboards are a joy in terms of prototyping but can be a pain due to poor connections.

I’ve confirmed that swapping back the original ‘failed’ chip causes the updi failure again. I’m a bit concerned going back to this link that configuring the reset pin as reset rather than as gpio may have caused the problem. If this is the case, is there any way back for the chip?
I can’t use updi to check /set the fuses as the initialisation fails every time. It’s no big deal if it’s dead, but if I can resurrect it, so much the better.