How to debug over UPDI

[amadeuspzs]

UPDI = "Unified Programming and Debug Interface"

Is the debug interface here low-level aka checking register values, breakpoint stuff, or is there a way to use it exfiltrate debug messages like you would with UART?

Just wondering if it could replace a Serial debug workflow or if its too low-level for that?

For example, reading/debugging sensor values (int or float) when building boards?

[SpenceKonde]

It is a low level hardware debugger. They keep talking about hardware debugging support in future versions of Arduino though, so that may become usable, but right now? It's Microchip's tools only if you want to do that :-/

[SpenceKonde]

Probably overkill for what you describe - like, great for reading value of something in memory - but if you just want to see your readings printed out, I get the impression it wouldn't be well suited for that. I have never used it.

[amadeuspzs]

Ok that makes sense - thanks Spence!

[Grufbert]

Is there anything new about this topic. I want to debug UPDI via casual UART USB Bridge?

[SpenceKonde]

I am not aware of any developments.

As I've said elsewhere, since the debug part of UPDI shares the physical interface with the programming part, we can guess confidently how the protocol would look, and the path toward elucidating the details of the protocol is clear. I have no idea how the side that runs on the computer would work or how a debugger "attaches" to a piece of hardware in terms of providing an interface. That and lack of time and interest are why I haven't looked at this. the reverse engineering should be comparatively easy.

We'd expect that the basic physical layer would be the same - it would be the same autobaud-singlewire usart with 1 start bit even parity and 2 stop bits. You could spy on it trivially with a serial adapter (you wouldn't know what signal came from which end, but you know where each message from the computer starts - it will almost certainly look like updi where each message from the computer will begin with a 0x55. And if the person debugging is still confused as to what is coming from which end, a scope that decodes uart would tell you - the two devices will generate a slightly different LOW level voltage.

We expect that debug sessions are started like programming ones, except that a different KEY will be sent (this was leaked in a preliminary datasheet for one of the first modern AVRs, but has since been expunged, and I didn't record it when i spotted it ("You idiot!") but like i said, the protocol is an open book, you'll see the computer send 0x55, then 0xE4 followed by the 8 byte key - so it's not like the information is hard to get as long as you have access to a working updi debugger from microchip and the software on your computer to use it (this is also a roadblock for me. They gave me a few debuggers, and I bought a few SNAP programmers. But I couldn't get microchip studio to recognize the tools.)

That nobody has posted any details is just due to nobody having looked (I think the number of people who are interested in this, and who would know how to take the raw information and make it useful from a debugging tool on a computer (gdb? I don't even know), but who do not just use microchip's tooling, but who have access to a working official debugger, so that they can spy on a working updi session is very small indeed. (and you would need that working UPDI session recording to analyze to get the key if nothing else. Otherwise, well, there are 2^64 possible keys, 16 quadrillion. Assuming you could test one per second, if you tested a full reel of 3k chips at a time, testing every key would take about 200 million years, and finding a specific(*) random key would take on average half that time. But the key is the same for all parts, and every copy of microchip studio has to know it, and the protocol can be easily snooped on).

The updi interface and ASI registers shown in the datasheet are presumably a subset of the actual ones, with a few more being used for debug.
One imagines that the ASI Key Status register has at least one bit for the debug key being enabled, and so on. They advertise two hardware breakpoints, so presumably there are registers that take the breakpoints,

* the keys aren't random though - not even a little bit. They appear to be ASCII strings. chip erase key spells NVMErase program mode key is NVMProg (with the space at the end), and userrow write on locked chip is NVMUs&te. I suspect the debugging ones start with "OCD" (On-Chip-Debugger), and further that there's at least one that has never leaked that lets you write the sigrow which is used in factory cal (but I would be surprised if it had no mechanism by which, once written, it could not be erased or modified). They need to write a full 128 bytes of signature during cal minimum, because there's a checksum at the end of the sigrow. We know that they use the same die in multiple parts so we already know they have to write the chip ID. The mystery constants in the sigrow (see https://github.com/SpenceKonde/AVR-Research ). The fact that you can guess that all of the key bytes are made up of ascii characters reduces the keyspace by 2^8 just from restricting it to the lower half of the ascii character set. You probably won't see any values below 0x20 either. So these speed up the exhaustive search from our 200 million years with a reel of chips in parallel down to just 228 years with a single chip.

[leonerd]

We expect that debug sessions are started like programming ones, except that a different KEY will be sent (this was leaked in a preliminary datasheet for one of the first modern AVRs, but has since been expunged, and I didn't record it when i spotted it ("You idiot!")

I have a copy of the data sheet here. The OCD key is 0x4F43442020202020; or "OCD " (the trailing spaces are important).

The sheet goes on to explain the UPDI registers 0x04 and 0x05. 0x06 is still "reserved". The key status register at 0x07 does indeed have an OCD bit in it:

The various bits seem to interract with onchip debug message register at 0x0D, but the data sheet doesn't further explain the content or meaning of those messages.

That nobody has posted any details is just due to nobody having looked (I think the number of people who are interested in this, and who would know how to take the raw information and make it useful from a debugging tool on a computer (gdb? I don't even know), but who do not just use microchip's tooling, but who have access to a working official debugger, so that they can spy on a working updi session is very small indeed. (and you would need that working UPDI session recording to analyze to get the key if nothing else.

I do have an mEDBG board with an ATtiny814 on it, that I keep meaning to fiddle with. Probably to start with I'd work through Sigrok and write a UPDI decoder for this.

[stellar-aria]

Yeah, I just don't have a PICkit or a "real" AVR programmer at the moment, so no way to actually get the signal data to analyze.

[leonerd]

I have the kit I just have absolutely no idea on what to do or how to get the motivation to think of things. If someone can tell me what to apt-get install and then commands to run to generate what I presume might be sigrok .sr files that people can analyse themselves without having the hardware, please do.

Or maybe someone can write a sigrok UPDI decoder, if I provide some .sr files with known UPDI transactions in them and that can serve as a base to decoding the unknown portions from my real debugger.

I.e. please use me as dumb remote hardware.

[SpenceKonde]

Just put it on a digital scope and take a screencap and use a ruler to determine the width of the bits, from that you calculate the baud, Then just connect Rx of a serial adapter to that pin (and tie the grounds together, except they already are if it's on the same computer) open at that baud rate in another serial console program (hTerm set up in hexadecimal would be my choice) set up to log, and then debug.

they probably use a standard baud rate so you could even just step through the normal baud rates until you found it if you don't have a scope. The way the protocol works is all laid out inf the UPDI chapter of the datasheet - it's 0x55 then a command and 0 or more data bytes, and then the target may respond (a few commands give no response), repeated for every command.

And uh, like, you know I don't know how to do thje next step of making it usable to attach things to a debugger. I'm just trying to give the people with that knowledge the knowledge I have that they'd need...

[leonerd]

I do appear to have some success writing a Sigrok decoder for UPDI. I can at least decode a bunch of fairly basic messages.
I also appear to have found a key ;)

[leonerd]

Ugh, I had a small rounding error in my baud rate calculations. This is just the wellknown "NVMProg " key. Sorry for the false alarm.

[leonerd]

I found my really cheap $10 Saleae-clone didn't even need that opamp; it can see the UPDI line from both sides just fine. I made some captures like that already. I still want to write a proper Sigrok decoder for it, so it can capture the baud rate from the sync pulses, decode the instruction opcodes, etc.. and generally give a more human-readable output that's better for researching this.

I now have this working pretty reliably, at least for any of the UPDI captures I can actually perform currently with my own PC-side tooling. For example, here's the output of a READSIB command:

I'm now in search of ways to get more interesting captures from more interesting scenarios. I have an ATtiny817 Xplained board of somesort I think, so maybe if we can provoke that into talking interesting debugging from its own internal debug bridge onto the chip and spy on it, that might reveal some new clues.

Ideas welcome.

[streef]

FYI: I've created a Python script that lets you establish a serial connection over a UPDI link. It uses a virtual UART on the AVR that is accessed via the UPDI interface, so you can flash the device and have a serial communication channel via the single UPDI pin. I noticed that you can access the I/O registers in the 0x00..0x3F range via UPDI without switching to OCD mode, so it uses the GPIORx registers in that range to implement the virtual UART. You can find the script and a demo program in this repository:
https://github.com/streef/upditerm

[streef]

I've made the header files C++ compatible, so you can add the .c and .h files to an Arduino sketch and include the header files in your .ino file. But you should keep the .c suffix so that the files are compiled as C files. Tested with Arduino 1.8.13 and 2.3.2 + megaTinyCore 2.6.10.
I've also made some other improvements in the meantime. I now use OCD messaging for transmitting data, which is much faster, than polling a GPIORx register and I switch the UPDI interface to OCD mode to be able to detect a reset of the CPU.

[hmeijdam]

I could get it to work now on my Windows11 PC. Able to dim the led and it took me a while to find that "E e" terminates the interactive mode.
Pressing "s" gave me signature : 00 00 00 (not sure what that is)
Pressing "d" gave me the SRAM content, which is cool!
Pressing "r" displays RESET

Looking at your breathing led example I start to understand how to use it, but need to play with it some more first.

Groeten, Hans

[FL0WL0W]

This is pretty awesome reverse engineering work. Great job!

It would be awesome if you figured out how the hardware breakpoints are setup. I'm working on a project in assembly for some fast SPI communication. Some hardware breakpoints along with being able to read out all the registers and ram states would be better for troubleshooting. Then maybe someone can build on that to connect it with OpenOCD?

-Daniel

[MX682X]

I did some research on debugging, this is what I was able to find out:

0xF80 - Unknown [4 bytes, 2 writable]
0xF84 - HW "RUN" breakpoint [4 bytes, 2 writable]
0xF88 - Halt Status? [1 byte, 0x07 Mask]
0xF89 - Unknown. 0x20 on reset [1 byte, 0xF0 Mask]
0xF8C - 0x84 on reset, otherwise 0x04, unwritable [1 byte] ( bitmask Haltstate?)
0xF8D - Halt Source? (0x02 - Run BP hit, 0x01 - step BP hit)

0xF90 - Unknown, unwritable [4 bytes]
0xF94 - HW "STEP" Breakpoint [4 bytes, 2 writable]
0xF98 - Shadow SP [4 bytes, 2 writable]
0xF9C - Shadow SREG [4 bytes, 1 writable]
0xFA0 - CPU Shadow Register [32 bytes]

Run and step were chosen according to how they were used by Microchip studio. I've only checked it with Attiny1614 though.

I also have some semi-finished python script that creates a GDB server that can be controlled through the Arduino IDE, but needs more work.

[ulion]

This is great, I'm working 1614 and now out of pins to do extra TX for debugging, this really saved me from everything which could be worse.
I do have a question, no matter board runs in 1MHz or 20MHz, dump() seems runs quite for a while (maybe one minute?), default baud rate, is it expected?

[streef]

The 's' key should show the chip device id from the signature row, which for instance is 1e 92 23 for the ATtiny412. The program uses the following declaration to access it:

uint8_t sig[3] __attribute__((address(0x1100)));

Perhaps that doesn't work with your compiler version.

[hmeijdam]

No worries I changed it to:

        case 's': // show chip signature

          printf("Device ID: ");
          printf(" %02x", SIGROW_DEVICEID0);
          printf(" %02x", SIGROW_DEVICEID1);
          printf(" %02x\n", SIGROW_DEVICEID2);

          printf("S/N: ");
          printf(" %02x", SIGROW_SERNUM0);
          printf(" %02x", SIGROW_SERNUM1);
          printf(" %02x", SIGROW_SERNUM2);
          printf(" %02x", SIGROW_SERNUM3);
          printf(" %02x", SIGROW_SERNUM4);
          printf(" %02x", SIGROW_SERNUM5);
          printf(" %02x", SIGROW_SERNUM6);
          printf(" %02x", SIGROW_SERNUM7);
          printf(" %02x", SIGROW_SERNUM8);
          printf(" %02x\n", SIGROW_SERNUM9);

          break;