UPDI init failed: Can't read CS register

[second-string]

I'm having issues using SerialUPDI to connect to an ATtiny414 on a very simple board. I'm powering the ATtiny from 5V coming through out of an LDO, and have a 0.1uF cap rated for 50V from Vcc to ground.

I've created a couple programmers with cheap CH340s and the recommended BAT54C schottky with the cathode towards TX soldered between the RX and TX pins on the bottom of the usb to serial board.

These are the settings in the arduino tools menu:

I've set the board, chip, port, and programmer, and I'm not sure if the others matter. These ATtinys are straight from a supplier, no bootloader burned onto them that I know of (so I'm assuming the reset pin is in UPDI mode although I might try the 12V battery hack tomorrow).

These are some scope shots of the UPDI attempted programming process (full output at bottom). The first is a wide view of the full initial sequence with channel 1 (yellow) on the UPDI pin and channel 2 (blue) on the Vcc pin of the ATtiny.

Here's a zoom in to see the initial UPDI init low, then a chunk of data:

And here's a closer zoom on that chunk of data to see that the transitions look nice and clean:

If you look at the cursor measurement on that last image, one large thing that jumps out at me is that the UPDI line is only transitioning between a high of 3.6V and a low of 1.4V. Is this expected? Should a high be 5V or is 3.6V logic acceptable? Is 1.4V low enough to register an actual low on the ATtiny within the UPID pin?

Any thoughts?

Here's the full output from the Arduino upload log. Don't think it'll tell much, just that it tries to start the process and can't get a response from the board

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 /dev/cu.usbserial-1130 at 57600 baud.
Target: attiny414
Set fuses: ['2:0x02', '6:0x04', '8:0x00']
Action: write
File: /var/folders/sr/3ms7sks57hq80w8qt37pvqnh0000gn/T/arduino_build_208512/sketch_may18b.ino.hex
pymcuprog.programmer - INFO - Setting up programming session for 'attiny414'
pymcuprog.deviceinfo.deviceinfo - INFO - Looking for device attiny414
pymcuprog.serialupdi.physical - INFO - Opening port '/dev/cu.usbserial-1130' 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 '/dev/cu.usbserial-1130' 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.
Traceback (most recent call last):
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/prog.py", line 285, in <module>
    main()
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/prog.py", line 128, in main
    return_code = pymcuprog_basic(args, fuses_dict)
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/prog.py", line 199, in pymcuprog_basic
    status = pymcu._start_session(backend,
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/libs/pymcuprog/pymcuprog_main.py", line 545, in _start_session
    backend.start_session(sessionconfig)
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/libs/pymcuprog/backend.py", line 359, in start_session
    self.programmer.setup_device(
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/libs/pymcuprog/programmer.py", line 78, in setup_device
    self.device_model = get_nvm_access_provider(self.transport,
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/libs/pymcuprog/nvm.py", line 42, in get_nvm_access_provider
    accessprovider = NvmAccessProviderSerial(transport, device_info, baud=frequency)
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/libs/pymcuprog/nvmserialupdi.py", line 53, in __init__
    self.avr = UpdiApplication(port, baud, self.dut)
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/libs/pymcuprog/serialupdi/application.py", line 79, in __init__
    datalink.init_datalink()
  File "/Users/dot4qu/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.5.10/tools/libs/pymcuprog/serialupdi/link.py", line 44, in init_datalink
    raise PymcuprogError("UPDI initialisation failed")
pymcuprog.pymcuprog_errors.PymcuprogError: UPDI initialisation failed
pymcuprog.serialupdi.physical - INFO - Closing port '/dev/cu.usbserial-1130'
the selected serial port pymcuprog.serialupdi.physical - INFO - Closing port '/dev/cu.usbserial-1130'
 does not exist or your board is not connected

[second-string]

Don't you love spending an hour debugging an issue just to figure out that the one single cold solder joint just happens to be the one most important pin on your micro 🙄🙄🙄. I'm all good with slow up to fast w/ no write delay for both boards I built up.

Thanks for the effort you put into this tool

[mosqu-ito]

I remember reading this a few weeks back when I was getting the same error. My issue turned out to be very similar, not a cold joint, I had simply counted from the wrong end of the chip and attached UPDI to PA2 instead of PA0. Like you, I always jump to the most esoteric possibilities before contemplating the simple ones. Maybe it's human nature.

[SpenceKonde]

Yeah, I wish I could do better error reporting. That error is the "stk500 sync error" of updi, the kind of error you get whether it's a loose wire, or you sawed the board in half and discarded the partnership the mcu

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Thu, May 19, 2022, 01:36 Brian Team ***@***.***> wrote: Don't you love spending an hour debugging an issue just to figure out that the one single cold solder joint just happens to be the one most important pin on your micro 🙄🙄🙄. I'm all good with slow up to fast w/ no write delay for both boards I built up. Thanks for the effort you put into this tool — Reply to this email directly, view it on GitHub <#713 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW2DLQDJP5RQVBYFM3DVKXHMZANCNFSM5WK53SAQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** .com>

[SpenceKonde]

The reason the error reporting blows is the same reason the stk500 sync error can mean almost anythjing.- there's no addtional channel for the adapter to get any sort of information from. All it knows is that it was expecting to get a response to it's first action... and it didn't get one..

[SpenceKonde]

When I have a chance I'll try to make it give a different message if it doesn't get an answer the first time it's supposed to,

[second-string]

Yeah it was pretty clear there was no talking going on, my original question was just a sanity check on what the scope output should look like. I know there's not really much you can do with a stack trace when you get zero info back

[MATTERealise]

I too have been having issues bringing up a custom UPDI programmer designed for serialupdi. Strange. I'm on Win10, Can paste an error log here but its essentially the same as Brian's, above. I confirmed it wasn't bad cables by using a diode soldered between the pins of a fake FTDI module and that worked fine. With my custom CH340 board, I was initially only able to flash successfully once or twice out of tens of attempts on the slowest mode, targeting a bad signature tiny402. I soldered up a 1614 on a DIP breakout PCB, so as to be sure the bad signature was nothing to do with it and I couldn't get a single successful load, even on slow mode. Then I found this discussion when I searched for the error about not being able to read CS register.

I went and checked/resoldered all the joints and have seen an improvement, in that I can load using slow mode. But normal speed on all configs is highly intermittent. Schematic of relevant area, for sanity and perhaps reference for others.

I used a normal switching diode initially and then swapped to an SBR130S3 when I realised (and wasn't getting successful comms at anything but the lowest speeds). Any suggestions on how to get normal speed working on Windows would be appreciated but I can live with the slow setting if I have to.

Additionally, I can't get any speed working at 5V. Only success at 3.3V. Again, thoughts would be very welcome on this.

[makeriot2020]

Interesting... I am going down a similar road at the moment, just done with a UPDI programmer, based on CH340G, on a prototype board ( before I spend the time and money to actually get a board made). I have not dared to test it on a processor yet, thought to get some online scope traces yet, to verify that the circuit I got online actually makes sense.

I am happy to say that is at least looks like it is doing what it has to, in the case of not having a processor connected... so , now I can wait to get the ATTiny chips from AVNET, and then do a real test :) Thanks for taking the time to actually post scope traces here...

[SpenceKonde]

You don't need to particularly worry about connecting a UPDI programmer to the UPDI/reset pin. There are only two potential ways that something connected to the UPDI pin can make the chip hard to reprogram:

1. If the device connected to the UPDI pin sends a valid UPDI command which improperly sets the SYSCFG1 fuse to disable the UPDI function (HV programmer required to unbrick)

or

2. If it causes physical damage to the pin by either

a) exposing it to a voltage of 13v or more and allowing more than a miniscule amount of current to flow. (but why the fuck would your programmer even have 13V or more anywhere on the PCB?)

b) exposing it to a voltage of -0.5 or less (ie, below ground) and allowing significant current (there's even less reason for this voltage to be present anywhere - though if ground of target was tied to Vcc of programmer instead of Gnd, that would do it - though in this case, you likely also connected Vcc of the target to ground of the programmer - reverse polarity instantly destroys almost all ICs.).

c) "fighting" with the pin by attempting to drive the pin LOW while the target tries to drive it high, without any current limiting, hence why it is common to include a small resistor in series with the UPDI pin.

Cause 1) indicates that you have a working programmer - and you've always been able to brick chips by writing garbage to the fuses which requires difficult measures to recover from. Do look at your selected options before doing burn bootloader, like always.

2a) would require that a voltage which has no business being on a UPDI programmer at all is somehow present. There is no plausible way for this to happen accidentally.

2b) would require a voltage that has no business being on a UPDI programmer to be present, or a fatal wiring error which would often (but not necessarily) be accompanied by a complementary fatal wiring error; those in combination would destroy the part before you even tried to talk to it. But that's a wiring mistake that will trash anything and which can be made whenever power is connected to anything. Don't reverse power and ground.

2c) is the interesting one. While it is unarguably a legitimate concern on AVR Dx-series and megaAVR 0-series parts, it's unclear whether there is any risk at all here on the tinyAVR. The datasheet does not spec an "absolute maximum" reset pin current, which implies it's no different from any other pin. However, the pin drivers on the HV tolerant pin (PA0 in the modern tinies) are incredibly weak (a consequence of their HV tolerance), being closer in strength to a pullup/pulldown than an output pin, and as a result, even if the tiny is trying as hard as it can to drive the pin low, while the programmer tries to drive it high, and there's no current limiting whatsoever, the programmer will be able to drive it nearly all the way to the positive rail, and the current flowing will still be well below the absolute maximum per pin current!

In fact, they're so weak, and the pin is so worthless as an output, that on the AVR-Dx-series and mega0-series they don't even bother; the reset pin (which is or would be the HV tolerant pin there - "would" since the mega0 and DA/DB can't disable UPDI, I don't think there's any HV programming mode implemented it was added to the DD, which also had the fuse for disabling UPDI) doesn't have output drivers at all and is input only: It can be set as a general purpose input pin instead of reset, but it can never be an output).

[ilFuria]

I'm using a genuine FTDI chip on a serial programmer (bought at least 5years ago and used for arduino pro mini programming) with the usual schottky and 470R resistor. Well I had mixed results:

• I was able to program one chip once.
• From then on I always get the error message. Wiring is ok, I buzzed everything, and I'm on my 3rd attiny804 but now I always get this message.
  I'm really at a loss and I don't know what to do anymore, do I have to buy a pickit?
  Cheers

[SpenceKonde]

Do you have a scope trace of the failed attempt to program, taken from the UPDI pin of the part? That's the most useful diagnostic point. That, and the RX pin at the point that it enters the serial adapter IC.
Generally one of two things is happening:
UPDI is not driven low enough by the programmer to be recognized by the target (because people ignore the "schottky" part of the circuit described here, as if I looked up how to spell the fucking thing and specified that just for fun. I spec'ed a schottky diode (specifically a small signal schottky diode), cause it don't work with other kinds of diodes!
UPDI is not driven low enough by the target to be heard by the programmer (common on tinyAVR setups, because tinyAVR has limp noodles for pin drivers on PA0 because it's also the HV programming pin)

[ilFuria]

oh well… this is embarrassing… while trying to scope idk what happened (perhaps one oof my 12397 attempts) the thing started working again. now I'll read about optiboot not working but this magically solved itself.idk, thanks, I guess

[SpenceKonde]

I've got 3 respins of new series of Serial Adapters on the way in any event (same error mirrored on all designs, only assembled 1 device of 1 out of 3 designs 2 of which will have a builtin UPDI functionality that will be going up for sale in Tindie, and we'll see if anyone is willing to pay for a serial adapter that isn't utter shit.

[ilFuria]

let me know too please I'd definitely want a good one

[makeriot2020]

Sounds like a plan, please send me the links when you have posted it... could use another reliable UPDI programmer, they are seeing a lot of use these days :)

…

On Thu, Jul 6, 2023 at 6:39 AM Spence Konde (aka Dr. Azzy) < ***@***.***> wrote: I've got 3 respins of new series of Serial Adapters on the way in any event (same error mirrored on all designs, only assembled 1 device of 1 out of 3 designs 2 of which will have a builtin UPDI functionality that will be going up for sale in Tindie, and we'll see if anyone is willing to pay for a serial adapter that isn't utter shit. — Reply to this email directly, view it on GitHub <#713 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQLJU5EZ3MRAZISJPXBPIMTXOX3KVANCNFSM5WK53SAQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

-- โจฮันเนส เฮอร์มานัส รีดลลิงไฮนสื / Jean Redelinghuys โทร (+66) (0) 0829130280 E-mail: ***@***.***

[Andrei-Pozolotin]

A report from the trenches:

A board similar to this: https://www.amazon.com/dp/B00LZV1G6K

Problem: same error: UPDI init failed: Can't read CS register:

Solution: unsolder / remove both TX led D4 and RX led D4 from the board:

http://nicecircuits.com/ch340g-usb-to-rs232-ttl-module-schematic-d-sun-v3-0/

[SpenceKonde]

Oh, yeah for serial updi, I'm pretty sure we mention in the docs, there much be **no** load on rx whatsoever, because it has to be driven low by PA0. Unlike a normal i/o pin, where youll get 20 mA with under a volt of drop, when the reset pin is doing output stuff - since thats the same pin that the HV pulse is applied to - you get wet noodles for pin drivers, which (see datasheet) are only speced for under 1v of drop with half of a milliamp. It's kind of like having a aprx 2k resistor in series with the output pin (not exactly, as it's a pullup much like the avr's own ones. SO - you have an active low bidirectional data line, with the the updi protocol having been designed so that, implemented correctly, no collision happens. What are the key things that need to work? 1. The programmer must be able to overcome the 35k-ish pullup resistance, and all loads on that line, the diode or resistor between TX and the updi line close enough to ground to read as zero. As it happens, the CH340G is beefy as far as pin driving goes, so as long as you accounted for the resistor on the board when sizing your additional resistor, if doing 4.7k resistor. Using a diode, it *must* be a schottky, it fails to drive the pin low enough to be seen - or worse, gets there but is flaky. A few weeks ago someone posted upload log that eventually ended with a failure... and I scroll up. It had experienced like half a dozen "errors" and managed to pick itself back up. I never found out what was going on there, but I strongly suspected either poor contact between pin and receptacle or one side was occasionally missing pulses because ut was almost unable to see the transition in time. 2. The target must meet a similar critera. And on tinyAVR this is where the problems happen. Instead of nice beefy 20mA pins you get a scrawny runt of a pin driver. It's so weak, that at 5v, driving to ground, just half an mA of current will cause it to be unable to pull the pin down below 1v. Any capacitance will slow the transitions. And, of course, an LED on RX is guaranteed not to work on any tinyAVR. Dx/Ex are probably better behaved than that. 3. Programmer must implement a protocol consistent with UPDI for that family of chips (still a problem for some upload meathods. Those are the main things. The tinyAVR reset pin is very weak (the pin that takes the HV pulse is *always* very very weak as an output, so much so that on Dx and Ex they declared the pin input only when used for GPIO (or rather GPI).And stupid manufacturers just love putting onto USB-serial bridges which don't have a separate pin to control the LEDs, bidirectional activity LEDs, which the UPDI/Reset pin would be hard presed to illuminate.

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Tue, Nov 7, 2023, 13:29 Andrei Pozolotin ***@***.***> wrote: A report from the trenches: A board similar to this: https://www.amazon.com/dp/B00LZV1G6K Problem: same error: UPDI init failed: Can't read CS register: Solution: unsolder / remove both TX led D4 and RX led D4 from the board: http://nicecircuits.com/ch340g-usb-to-rs232-ttl-module-schematic-d-sun-v3-0/ [image: image] <https://user-images.githubusercontent.com/1622151/281140382-87d2b71e-9716-4591-a6cd-16f364f798d9.png> [image: image] <https://user-images.githubusercontent.com/1622151/281140471-51d0f70c-cc68-461d-b772-004cb0955905.png> — Reply to this email directly, view it on GitHub <#713 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW52REHCAQJIP2AZYETYDJ4Z3AVCNFSM5WK53SA2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TONJQGIZDCNA> . You are receiving this because you commented.Message ID: ***@***.*** com>

[Andrei-Pozolotin]

@SpenceKonde :

• thank you for the extensive write-up above
• yes, you do mention removing leds/diodes in the docs, as I found later, but I ended up here first via error
• perhaps it would help to future newbies if the error message would direct straight to some check-list http page :-)

by the way, I am using your great breakout boards (thanks again):
https://www.tindie.com/products/drazzy/attiny412similar-breakout-board-bare-board/

and I discovered that the CH340G adapter above, with leds removed, works just fine on linux via SerilaUPDI@230400,
for ATtiny402 with the venerable 1N60 and even 1N5822 :-)
https://www.google.com/search?q=1N60+datasheet
https://www.google.com/search?q=1N5822+datasheet

[Leo-Ka]

I encountered a similar problem and spent a couple of days on it. If you use a board similar to this: https://www.amazon.com/dp/B00LZV1G6K, it turns out that a Schottky diode and a 1.5 k resistor (R4) are connected in series. As a result, the CH340 cannot lower the voltage to less than 1.4 volts on RX, or even 1.6. I did not remove the LED, I simply replaced R4 with 330 ohms, which was enough to reduce the lower level to 900 mV.This solved the problem, but probably this board should now only be used as a UPDI programmer.Here is the situation before replacing the resistor: