Saleae team - we would love samples of protocol captures!

[P.Jaquiery]

Hi Mark,

I’m using the serial lines for debug consoles on two different pieces of hardware that are connecting to each other over USB-C. Most of the serial activity is status logging from the two systems with the very occasional manual debug command. But what could be more interesting is looking at the serial data and the I2C data. There is a strong correlation between the serial log data and the I2C activity. In the capture I posted the PLC device sends a logged, but unseen, device capabilities message to the FES device which results in a burst of I2C activity. A meta analyser that could work with PLC Tx traffic and either the I2C traffic, or the I2C PD (HLA) traffic would allow things like response time measurement between the two systems.

Mixing in edge detection on INT_N (the interrupt line related to the I2C) would be really useful too. That would allow interrupt response time to be measured and provide information about system performance.

For this particular system there are 6 USB-C ports on the PLC device with multiple large complicated state machines that interact with each other for each port. On top of that the power for the ports is managed by a supervisor and there is an Ethernet port running IEEE-1588 precision time sync protocol in there somewhere as well. I’m going to be interested in that sort of performance measurement fairly soon!

I’m happy to provide you with more captures of a similar sort. I could drop them in a Google Drive folder and share that, or somewhere else that works for you. I’m kinda anti Dropbox, but could use that if pressed.

Cheers,
Peter

[Jerry]

OK…You ask, I provide…!
Attached is data from a 16-channel comm format translator I’ve been working on.

It receives 1-mbit Manchester encoded HDLC data, decodes it using an HD6409 , Z85230, a dspic33EP running at 140mHz, and then processes the data. For this sample the SPI and Async serial out are the same data…

Channel map:
0 - Manchester encoded HDLC in
1 - data output from Manchester decoder
2 - /NVM (non-valid Manchester) from decoder
3 - RX data input to Z85230 comm chip
4 - RX clock input (from decoder) input to comm chip
5 - Sync pulse when opening/closing flag detected
6 - Error interrupt
7 - The decoder uses 2 identical ‘ping-pong’ buffers, This indicates which one is in use.
8 - Interrupt signal from comm chip to dspic
9 - Receive interrupt read fifo
10 - Receive ‘special condition’ interrupt (finish emptying fifo)
11 - End of Frame pulse
12 - SPI SCK
13 - SPI SDO
14 - SPI /CS
15 - Async serial , 921600-8-n-1

A couple things that I’ve notice would be nice:

1. the ability to capture a screen shot and save it within the program.
2. some way to 'minimize the right hand pane, other than starting a recording, to get a screenshot.
3. Functional Manchester and HDLC decoding…
4. When dealing with ‘framed’ data, some way to put the whole frame on one line instead of individual entries…i.e."Data, 3.598876374,0x01,0x00,0x014,0x013,0x00,0x00,0x87,0x98,{EOF}. Same with ASCII data…new line = CR or LF or both selection?

Keep up the improvements! It’s made a big difference troubleshooting this device.

Regards,
Jerry
jmusselman64@gmail.com

VL200.sal (3.6 MB)

[rei_vilo]

Please find the sample for the SPI Sharp memory display mentioned at the Logic 2.2.16 thread. The Terminal window remains empty.

Sharp128.sal (37.3 KB)

Note: the Chip Select signal is active HIGH!

[markgarrison]

Thanks @P.Jaquiery, feel free to send a google drive link here or via support - https://contact.saleae.com/hc/en-us/requests/new - just mention that it’s a sample for the software team and we’ll get it.

Python support for raw data access in analyzers is a big part of our plans, but it’s quite a ways out. There are a lot of challenges there, performance not the least of them. In the short term, it should be pretty easy to write a C++ analyzer that simply forwards edges into the new FrameV2 format, which can be consumed by python analyzers. Next week we’ll be working on the ability for a python high level analyzer (HLA) to receive data from multiple input analyzers.

Custom python measurements might be another good solution for looking at performance statistics. It won’t integrate with analyzers, and they can only be applied two a single channel at a time, but custom python measurements is an easy way to run some math on top of all the digital transitions over a span of time. We won’t be working on measurements again for a little while, since we have our work cut out for us just with analyzers though.

The more captures we can get the better! Especially if they contain complete transactions, for instance starting the recording before any initialization communication occurs.

Also any description of what we’re looking at would help.

[markgarrison]

Thanks @Jerry!

I’d like to try to get the manchester HDLC data decoding in our software.

Could you send any links to the protocol documentation?

I wrote our Manchester decoder, and it seems to be working properly at 1mbit/sec. However, I don’t know the rest of the details required to understand what’s there.

Also thanks for the feedback:

the ability to capture a screenshot and save it within the program.

Yup, we need to get to that. In the meantime, if you’re on windows 10, you can press Windows Key + Shift + S. Then drag to select a region of the screen to capture. You can then click the notification that appears to save the image, or just paste it into a document.

MacOS I think is command-shift-5, and has a nice easy to use UI.

some way to 'minimize the right hand pane, other than starting a recording, to get a screenshot.

press ‘n’ then ‘q’. Or, just click the icon for the panel that’s currently open to collapse it. All navigation shortcuts can be found in the shortcut help, on the main menu, or by pressing ‘?’ (shift+/) on your keyboard.

Functional Manchester and HDLC decoding…

I’d like to work on that next week. The main known flaw with the manchester analyzer is that it ignores long strings of all zeros or all ones, if the bit state never changes. This is because it’s not possible to differentiate between all zeros or all ones until a bit changes. However, adding a setting to the UI to treat unknown bits as zeros or ones should easily solve that.

I won’t be able to simply merge our Mancester analyzer with our HDLC analyzer, but I would like to try implementing basic HDLC decoding in python, on top of the Manchester analyzer.

When dealing with ‘framed’ data, some way to put the whole frame on one line instead of individual entries…i.e."Data, 3.598876374,0x01,0x00,0x014,0x013,0x00,0x00,0x87,0x98,{EOF}. Same with ASCII data…new line = CR or LF or both selection?

Are you talking about the terminal view or the search results table?

This is the sort of thing that will be very easy to reformat with a little bit of python. One of our example python high level analyzers, called “Text Messages” only does one thing - allows the user to configure the rules by which frames are combined into longer frames. A delimiter can be selected, and a timeout can also be selected to be used as a delimiter. It’s meant to be an example and could quickly be modified to suit one particular application.
That said, this is the sort of thing our software should be able to do out of the box, without custom code.

[Jerry]

Thanks, Mark…fast feedback!

I think I spoke to soon regarding the Manchester decoding. It does appear that is working in the current release, but I can’t use it because the data is also HDLC encoded.
The HDLC analyzer I need is bit synchronous…which is there, but there also needs to be an external clock selection…which the current analyzer doen’t have.

In the data I sent, the HDLC data is line D3 and the clock is line D4.
As you may know, HDLC has an opening and closing flag of 0x7E, and does 0-bit stuffing anytime there’s more than 5 1’s in a row. More than 7 ones is an abort.

Thanks for the screenshot info. I should have known that…I just don’t use it that much.
Also the ‘close sidebar’…I swear I looked through the keyboard commands and didn’t see it…

Jerry

[siddacious]

Here’s a directory with some captures from me debugging a driver for an ICM-20948:
https://drive.google.com/drive/folders/1rgd999NZfxXMLMr5YTBXSi-oQhFGflux

Datasheets for the ICM-20948 and the integrated magnetometer:

DS-000189-ICM-20948-v1.3.pdf

SMDSW.020-2OZ.pdf

and here’s a spreadsheet with the register map. I’m planning to turn this into a json file that I can load into the HLA I’m working on at the moment:

ICM-20948 Register Map

I worked on the CAN project over the weekend, but I got lost down a rabbit hole researching the higher level protocols so I don’t have any captures for now. I’ll share them when I do.

[Collin]

Here’s a little capture of the comm between a Tesla Model S battery module and the master board. As you might imagine, Tesla did not exactly provide a handy protocol specification document for this. So, the only references are open source projects. Luckily, I did write one of those: https://github.com/collin80/TeslaBMS

ModelS_BMS.sal (9.7 KB)

I haven’t taken the time to built a python HLA for this yet. If I remember correctly the various commands and responses are more or less static in length so it should be possible to write some sort of state machine that interprets the data into a higher level output.

The BMS uses an extremely odd bit rate so it’s kind of interesting from that perspective. The async serial decoder seems to be working well and results fill out the table properly.

[siddacious]

@markgarrison these captures(above) also have the terminal formatting quirk someone else mentioned where reads and writes sometimes don’t have newlines. It seems like there are only newlines after read transactions

[chrisbennet]

This is a RS485 protocol capture from this USB to Serial device [1].
capture0.sal (135.2 KB)

[1] https://www.serialcomm.com/datasheets/USB-485C.pdf

[rei_vilo]

Another decoded protocol with an empty terminal.

Here, I²C INA219 Current/Power Monitor and SSD1306 OLED Driver.

I²C with no terminal.sal (969.2 KB)

Since I²C worked for the previous example, is there a limit on the size of the trace?

I checked that Stream to Terminal was duly activated.

[KurtE]

Not sure how much this helps, I captured a Robotis Example sketch for one of their servo libraries, doing a scan through all of the possible Servo IDS, using both Dynamixel Protocol 1 and Protocol 2. I had it setup with some XL430-W… servos.

I setup using the Serial Analyzer at 1MBS. Also I show the results using my old Dynamixel protocol Analyzer (C++…) https://github.com/KurtE/SaleaeDynamixelAnalyzer

Dynamixel_scan.sal (20.5 KB)

[dstahlke]

Can’t wait for the high level analyzers! These would be especially useful for EEPROM, since it can be hard to see what’s going on with the low level decode. It’d be nice if these would allow easily extracting a firmware dump.

24LC32A serial (I2C) eeprom:
24LC32A.sal (36.2 KB)

ATSHA204A crypto chip, MCP4261 I2C digital potentiometer, MCP6S91 I2C programmable gain amplifier:
Multi-SPI.sal (78.4 KB)

[KurtE]

Again not sure how useful this will be.
But with the Teensy processors, I do spend a reasonable amount of time getting display libraries to work on the different boards, especially when a new Teensy is in beta and/or just shipped. Recently been doing a bunch with different displays for the newly released Teensy 4.1 https://www.pjrc.com/store/teensy41.html

Sorry for a plug of their products, but I do the same for these analyzers up on their forums

Any way here is a capture from a T4.1 (beta board) to an ILI9488 display, where I am testing out using a frame buffer that was created in the optional RAM (in this case this board has additional 8mb).

With some (many/most) displays, with SPI, there is another IO pin that is often used on the display DC (Data/Command), that would be interesting to have the SPI analyzer or an HLA capture.

Also note with the T4.x, when I am doing SPI operations, some outputs are a byte at a time, other times, it is a word and in this case others are 24 bits.

The example sketch is doing a continuous DMA screen update of the display, so once it does the initial stuff of telling the screen the area to update and that the last command of 2c (data)… it just continues to output lots of data to the screen 24 bits per pixel, when it gets to bottom of the screen it will start over at the start…

Note: I trimmed the capture down a lot to fit… Probably could reduce farther.

T41_ILI9488.zip (3.6 MB)

[P.Jaquiery]

Sample capture for the software team:

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.

Cheers,
Peter

[KurtE]

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:

https://www.robotshop.com/info/wiki/lynxmotion/view/lynxmotion-smart-servo/

Their servos run using a Full duplex Serial (+5v signals). My Teensy board has TTL level shifters to convert to 5v…

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)

[rani]

Can’t wait for the high level analyzers!

The high-level analyzers are live for quite a while
You can check out our docs here. Please let us know if you need some help with getting started

p.s.
We’ll update the API and improve the docs next week.

[markgarrison]

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.

[markgarrison]

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.

[rei_vilo]

@markgarrison Congratulations for identifying the bug, and good luck with fixing it now!