System startup capture file with two I2C channels on different systems each with a HLA analyser decoding TUSB422 traffic and traffic to a MCP23017 I/O expander. There are also two active async serial 912600 baud serial streams giving system status information for the two systems.
One system is a data acquisition system using USB 2 full speed over USB-C with Power Delivery to negotiate 5V at 10W. The other system is in essence a four port 100W per port USB-C hub with a little extra proprietary magic.
The capture shows the cable connect through to completion of power and proprietary alternate mode negotiation over USB-C PD.
Note that the CC2 line actually shows the Manchester encoded PD communication between the devices.
Again not sure how interesting this one is. It is a simple capture of communications from Teensy4.1 to a set of Lynxmotion Smart Servos (LSS). In this case working on translating the code from other servos (Dynamixels) to their smart servos. More information on their servos are up at:
The channel 1 is the TX pin and commands start with # and end with \r
If the command is a query, like is shown in screen show asking Servo 8 for it’s Angular Range: #8QAR0\r
and In this case Servo 8 responds on Line 0 with the: *8QAR1800\r
which says range is 180 degrees in 10ths of a degree.
I already mentioned in another posting would be nice if terminal mode would handle just have \r as line ending. Not sure if a HAL would work with combining data from both Serial lines.
Edit: Oops forgot to upload the SAL file LSS_Servos.sal (21.0 KB)
Thanks @rei_vilo, I’ve been able to reproduce this with your capture on MacOS but not Windows. Quite an odd problem, we should be able to get it fixed soon, should be on our next bug fixing day.
Ok, Finally figured out the bug where for some captures, some protocol analyzers would not produce terminal output.
The problem affects MacOS (and probably Linux, will test soon). Basically the front end does not get any terminal data if the back end writes too many bytes to the terminal’s named pipe at once. Not sure why, but it appears to be a problem with the front end named pipe support, because reading works fine from the terminal.
Looks like we have a working fix and it should be in the next release.
Thanks again everyone for submitting sample captures!
8 people submitted captures, and we ended up with samples of I2C, Serial, SPI, and manchester data, with over 15 different devices / protocols.
We’ve been working on 4 different specific extensions to start with - the AK09916 and HDC2080 I2C sensors, the TUSB422 I2C USB Type-C Power Control IC, and the USB PD (BMC) signal.
I’ve been working on the USB PD HLA (Biphase Mark Code), and just published to the marketplace. You can find the source here too: https://github.com/saleae/hla-usb-pd.
In addition to missing most vendor data object decoding and all extended header & data block decoding, it does support quite a lot - all the basics, plus it decodes data objects for all other data types. (source capabilities, sink capabilities, etc).
But there is a big caveat. To use it, you need to find a way to reliably record the USB Type-C CC pin using a digital input. The analog recording I got from @P.Jaquiery would have required a threshold of 0.4 volts to decode properly, which our device does not support. This would likely require the user to record using a digital comparator first. Eventually, we’ll want to add analog to digital conversion in our application to support this. In the meantime, I exported the analog channel, and modified our software’s digital simulation code to read a modified version of the export, to get the data back into the SW as digital.
The github post includes a digital clipping of @P.Jaquiery’s sample capture to demonstration purposes.
When I was first working with the TUSB422 and USB-C PD I found that I could get pretty reliable detection of the data across the CC line using the 1.2V detector (I guess that’s about 0.6V threshold). Using that technique and the Manchester decoding I hand decoded a few packets as a sanity check of what I was seeing on a USB-C PD analyser and because the analyser we are using doesn’t decode some of the cable VDM VDOs. It’s not something I’d want to do a lot of!
A software analyzer that can accept analog data as input could be a solution to the detection problem using a fairly simple threshold detector with a little hysteresis. That would be a cool tool because it could be used for all sorts of non-standard logic levels and simple event detection.
You have a more complete TUSB422 HLA, but we’ve been spending more time building HLAs internally so I took a shot at building one for TUSB422 as well. It doesn’t do any bitfield decoding, but does decode the individual i2c subadresses. You can see it here:
Of particular note we were trying different methods of implementing the decoding - this implementation uses a generator function that consumes individual frames and maintains state using local variables. Overall it was a worthwhile exercise, but I think the approach itself was not as straightforward as hoped, and the result is not easy to read (IMO).
I’m sure I’ll circle back at some point and look at the bitfields, but just wanted to share! Thanks for sharing your capture!
nice to see I’ve stirred some interest with my HLA and captures.
I’m sorry to say, but I agree that the generator approach doesn’t seem to lead to an elegant solution in this case. That may be I’m not really a Python user and not familiar with yield, but deeply nested code is generally regarded as a code smell. I’d have thought at least the outermost loop could go away if you used “continue” instead of “break” in the first inner loop. 8 yealds scattered through the code doesn’t bode well for understanding either.
My own HLA is a pretty mixed bag tailored very much for the hardware I’m working on at the moment. In particular, it ignores any TUSB422 registers that I’m not interested in, and decodes non-TUSB422 traffic for I/O expanders that are very project specific. I don’t think there would be any harm in it being in the public domain, but it may not be very useful to anyone else either.
Ha, in hindsight I’m not sure why I didn’t use continue, I can’t see a constraint requiring the nested while. Some of the nesting could have been alleviated by breaking out into other generators, but I hadn’t gotten to that point. In any case, I think it was a worthwhile exercise.
I still need to dig into yours soon! It’s definitely helpful to see HLAs and how other people are writing them.
My own coding style tends to state machines and dispatch tables. My HLA uses dispatch tables heavily, but the state machine component is rather subtle and mainly concerned with register read decoding.
My HLA deals with a lot of special cases to try and show “interesting” information, like which alert flags are newly set or reset, so there is a lot of code there. I’m still adding to it and altering stuff without too much pain so it seems to meet my maintenance goals. Not sure how that would hold for anyone else though!
Ideally with the generator case you would have one generator per state, which I believe Mark’s did. There’s a benefit there to keeping the relevant data for the current state within the current scope, but the awkwardness of using yield to both send and receive frames made it a bust in our opinion.
Looking forward to seeing how you setup all the flags! Are there any features that you think would have been helpful? For instance, we don’t have native support for bitfields, and if you break them out into separate data.* fields, it can create quite a few columns in the data table.
For now I’m most interested in the “bubble” text and I haven’t really explored the data table at all. I’m often comparing logging from the DUT as async serial data with the TUSB422 traffic. The logging tells me about the internal state of the system and something about timing, and the I2C traffic tells me what’s actually happening. There are a whole bunch of interacting state machines that are pretty much direct implementations of the state diagrams given in the “Universal Serial Bus Power Delivery Specification” so gaining insight into how those machines are interacting is fundamental to figuring out what the system is doing. I’m using the logic analyzer as a firmware debugging tool much more than I’m using it to debug the hardware at present.
