Has anyone else experienced this? After a dozen or so (don't know the exact count) flashes I can't upload new code to my Attiny3224, they seem to brick themselves with the error WARNING - UPDI init failed: Can't read CS register.
It also happens on a different board using Attiny402's. I'm using UPDI HV (via Adafruit's HV UPDI Friend) which is the common denominator. Only fix is to unsolder the chip and put a new one on - not very sustainable as it's getting expensive.
The UPDI pin (pin 10) is not being used for anything else and there is no pullup on it - straight to the attiny. I did see that the Attiny is receiving phantom power via the serial RX/TX lines since I also have a usb=>serial adapter for debugging output, but I'm not sure if this is affecting anything.
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 COM5 at 57600 baud.
Target: attiny3224
Set fuses: ['0:0b00000000', '2:0x02', '6:0x04', '7:0x00', '8:0x00']
Action: write
ymcuprog.programmer - INFO - Setting up programming session for 'attiny3224'
pymcuprog.deviceinfo.deviceinfo - INFO - Looking for device attiny3224
pymcuprog.serialupdi.physical - INFO - Opening port 'COM5' at '57600' 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.
pymcuprog.serialupdi.physical - INFO - Sending double break
pymcuprog.serialupdi.physical - INFO - Double-break sent. Retrying.
pymcuprog.serialupdi.physical - INFO - Opening port 'COM5' at '57600' 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.
It is never a good idea to connect powered circuitry to unpowered circuitry via I/O pins. Doing so is in direct violation of the manufacturer's I/O voltage level specifications, and can damage or destroy both connected components. At the very least you can expect malfunctions, and that may explain your programming failures.
Indeed, though I’m not sure what other option I have. It turns out the problem with not being able to program sometimes was due to the external display I’m using which pulled the UPDI pin low - disconnecting it during programming fixed that issue.
What I was looking to do was how to reuse the UPDI pin for GPIO - I wasn’t aware this option was disabled by default and had to be uncommented out in boards.txt. I finally figured out how to do that with some help over at megatinycore.
I have an HV programmer, though disabling the reset pin for GPIO rendered it up programmable I just haven’t figured out yet why the HV programmer isn’t getting around that.
That may be because for some later revisions of the modern Attinies a 12V pulse is not enough to reset the UPDI pin back to its UPDI function. Those chips need a powercycle short before the 12V pulse. All this to mitigate the risk that a static spike could reset the UPDI pin, which in theory could happen before that revision.
Here are my HV programmers. The top one is the CH340G based HV programmer (like you have). It works fine with older ones, like 204, 404, etc, unless Microchip decides to produce a new silicon revision of them.
The bottom one is the PC-HV programmer, that can deal with them all.
