# SerialUPDI
SerialUPDI is a UPDI upload tool which uses a normal USB serial adapter with the most trivial of modifications directly as a UPDI programmer
It was written in 2020-2021 By Spence Konde and Quentin Bolsee based on the pymcuprog tool from Microchip, which is much, much, slower.
## jtag2updi? Never heard of him
This page was formerly dedicated to discussing jtag2updi. jtag2updi was a program written in some of the most inscrutable C++ it has been my misfortune to work with, and it could be loaded onto a wide variety of AVR microcontrollers, and they could then be used as a UPDI programmer. The code was buggy, and very few people could make sense out of it. It's performance was passable, though, for example, Optiboot performed better at uploads, and both Optiboot and jtag2updi were stuck with baud rates 1/4th to 1/3rd of what the chip could be written at.. In late 2020, the first versions of SerialUPDI were created from pymcuprog, but the performance was very disappointing. In mid 2021, a push was undertaken to make it perform better than jtag2updi. The progress and the short time it took to make it exceeded all expectations. Since the 2021 performance sprint, SerialUPDI - which had write speeds as poor as 600b/s at the time this effort was started, advanced very rapidly. Within just a few days, speeds over 10k were achieved and within weeks it was faster than everything else.
Since then some further performance enhancements, as well as ways to throttle it's performance to make sure it didn't overflow the part's receive buffer while it was writing
SerialUPDI is not perfect, but it's imperfections are small compared to those of jtag2updi, and less-initiated individuals are better able to improve it as compared jtag2updi - particularly as most of SerialUPDI's foibles are almost entirely due simply to it having not gotten enough attention from people who know how to write python - so things that should retry on failure or print error messages instead print stack traces, because something's throwing an exception and I don't know how to catch it. But the low level core that writes to the chip is largely fine. As of 11/21, we are no longer offering support for jtag2updi. The cores still support it, but it is not recommended. I will fix no bugs. If someone else wants to leap into this dumpster fire, by all means go ahead. I choose not to.. The only way that thing could be salvaged involves essentially rewriting it de novo so it wasn't a posterchild for how incomprehensible C++ can get.
## Brief orientation: What is UPDI
UPDI is the interface used for programming all AVR parts released since 2016 (the "modern AVRs") (and debugging, but that's locked behind a proprietary interface that nobody has bothered to reverse engineer, even though you can snoop on the protocol with just a serial adapter and even though the large scale structure of the protocol is known too - c'mon guys, this is gonna be a walk in the park compared to debugwire). Unlike the old ISP interface, which was very SPI like (in fact, It seemed to be SPI with the reset pin used like SS, and a somewhat odd pattern of communication). This time, we have a somewhat more sophistcated interface that we're connecting to (they call it the Asynchronous System Interface (ASI)), and the communication method is via what looks suspiciously like they put another copy of the UART in, hardwired to always be in LBME (half-duplex single wire), 2 stop bits, even parity, and autobaud enabled and WFB (wait for break) as soon as it initializes. This talks to the ASI, which initially only lets you reset the chip and read the device ID and SIB (system information block).
To enable the programming or debug modes, a "key" is sent - there are three in the datasheet (programing mode, chip erase which as usual is how you unlock and erase a locked chip, and program USERROW which can be written even while the chip is locked). There is also a debug key, I don't know what it is, but if I had a working debug setup with microchip studio, it should be trivial to recover by snooping on the communications during debugging. I'd also wager that this is the way they configure what pincount a part is (since most of the AVR dies these days get put into 2-3 adjacent
Because it's basically a UART, and it looks like they simply copied the UART, only pointed it at the ASI. UARTs have 2 bytes of buffer on receive. Since halting for flash halts the CPU - but not the peripherals like the UPDI physical layer - it will buffer two bytes and lose dataon the third; this results in, at the end of the page being written, the programmer having written more bytes than the target received, causing the programming to fail at that point, because the the part is still treating the next command as data to write, and doesn't respond.
## Wiring the hardware
Briefly, you connect Rx and Tx with either a 4.7k resistor or a small (signal) Schottky diode (band towards Tx). The RX like becomes the UPDI
This file has been truncated. show original
.
…