getting UpdiException with ATtiny402

[dmosberger]

This looks like an interesting project. Unfortunately, when I try to use it with an ATtiny402 chip, I get this error:

$ avr-absurd -P /dev/ttyS0 -p attiny402 -r 4242
UPDI instruction `ldcs` failed
Traceback (most recent call last):
  File "/home/davidm/tmp/avr-absurd/src/absurd/__main__.py", line 43, in main
    updiver: int = uc.connect()
                   ^^^^^^^^^^^^
  File "/home/davidm/tmp/avr-absurd/src/absurd/updi/updirev3.py", line 53, in connect
    self.store_csr(0x03, 0x08)
  File "/home/davidm/tmp/avr-absurd/src/absurd/updi/updirev3.py", line 158, in store_csr
    raise UpdiException("stcs")
absurd.updi.updirev3.UpdiException

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/davidm/tmp/avr-absurd/src/absurd/__main__.py", line 45, in main
    uc.resynchronize()
  File "/home/davidm/tmp/avr-absurd/src/absurd/updi/updirev3.py", line 98, in resynchronize
    raise UpdiException("ldcs", "`ldcs STATUSB` following a BREAK character failed")
absurd.updi.updirev3.UpdiException: `ldcs STATUSB` following a BREAK character failed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/davidm/.local/bin/avr-absurd", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/davidm/tmp/avr-absurd/src/absurd/__main__.py", line 78, in main
    uc.resynchronize()
  File "/home/davidm/tmp/avr-absurd/src/absurd/updi/updirev3.py", line 98, in resynchronize
    raise UpdiException("ldcs", "`ldcs STATUSB` following a BREAK character failed")
absurd.updi.updirev3.UpdiException: `ldcs STATUSB` following a BREAK character failed

I can program the chip just fine with avrdude and pymcuprog so I think at least hardware-wise, things should be OK.

[feline-felicity]

Thank you for your interest, and I'm terribly sorry I have overlooked your post for months.

The traceback suggests that the very first UPDI instruction (stcs CTRLB, 0x08) failed. This instruction expects no reply from AVR, so theoretically it should succeed even if no target device is connected, and can only fail if we don't receive our own transmission on the UPDI line. Normally, this would mean the serial port is not properly wired as SerialUPDI, but we can rule this out if well maintained tools like avrdude works.

So, I suspect the current handling of serial ports is somehow not working well with your hardware. What is your /dev/ttyS0 and SerialUPDI adapter like?

I usually experiment with FT234X or CH340N with a Schottky diode on a Windows machine. I also did a quick check with an Ubuntu one. However, I haven't been able to reproduce the problem with any combination of these hosts and adapters, using ATtiny202 and ATtiny412 as targets. I haven't tried "real" serial ports yet, though.

[thamosi]

Thanks for your reply! I finished the software I was working on, but I'm still interested in getting this working since we'll for sure have this come up again and it would be nice to have a debugger for the ATtiny402. I'll try again in the next couple of days or so.

[thamosi]

Oh, boy, just slightly embarrassing: I used the wrong serial device in my test! No idea where that came from. It should have been /dev/ttyUSB0. It's working much better now:

$ avr-absurd -P /dev/ttyUSB0 -p attiny402 -r 4242 -v
UPDI rev.2
SIB: tinyAVR P:0D:0-3M2 (02.59B14.0)
Signature: 1E-92-27 (revision B)
NVM: v0 / OCD: v0
2026-04-06 22:13:59,777 [DEBUG] Starting server; attaching to MCU and halting CPU

GDB seems to be pretty happy too:

$ avr-gdb ./ac-nfc.avr 
GNU gdb (GDB) 15.0.50.20240320-git
  ...
(gdb) target remote localhost:4242
Remote debugging using localhost:4242
0x000002ec in i2c_read_byte ()
(gdb) bt
#0  0x000002ec in i2c_read_byte ()
#1  0x000002ba in i2c_read ()
#2  0x00000220 in retry ()
#3  0x00000000 in ?? ()

Neat! Thanks for the help and writing this code!

[feline-felicity]

Good to know that! You are not alone in being puzzled by serial port names; my favorite USB adapter used to be COM5 but it's suddenly COM14 somehow. Anyway, thanks again for giving it a try.

By the way, I'm working on a branch to add gdb load command and optional software breakpoint support. During this process, I found many things I had got wrong and details I had overlooked, which I hope I've fixed. I'll merge the branch after a little more testing.

[thamosi]

Oh, that sounds interesting! I'd be happy to test the improvements.

Also, have you considered uploading the package to pypi? That'd make installation quite a bit easier.

[feline-felicity]

I felt shy about kinda officially releasing something but this may be the good time to do so...

I'll try it once I'm done with final checks.

[dmosberger]

On Fri, Apr 10, 2026 at 11:02 PM feline-felicity ***@***.***> wrote: *feline-felicity* left a comment (feline-felicity/avr-absurd#1) <#1 (comment)> I felt shy about kinda officially releasing something but this may be the good time to do so... I'll try it once I'm done with final checks.

Great! They make that very easy. I think it will increase the audience for this project significantly!

…

--david

Message ID: ***@***.***>