When reverse engineering packet based communications over UART it would be handful to have an analyzer which could export the decoded UART data “packetized”.
I am thinking about the following construction:
The analyzer would have two input channels.
A “packet end” delay could be specified for each channel: if no data received after the packet end delay the bytes recieved considered a “packet” which could be exported as one packet.
Both channels could have text input for prefix and the export output would look like this way (> and < symbols used as as a prefix):
AA BB CC DD
< 12 42 67 89
I have not found any similar analyzer, however I might overlooked it.
Thanks for letting us know your requirements. This might be possible via a High Level Analyzer extension added to the Async Serial Analyzer. More information on HLAs below: https://support.saleae.com/extensions
I wanted to gather some more information from you regarding the format you would prefer to be sure if this is possible via an HLA.
Right now, the export format for a single Async Serial Analyzer is shown below as an example:
Can you provide an example csv/txt file that shows how exactly you would like it to appear? I also don’t quite understand the 2 channel requirement, so if you could go into detail on that, that would be helpful as well.
Can you provide an example csv/txt file that shows how exactly you would like it to appear? I also don’t quite understand the 2 channel requirement, so if you could go into detail on that, that would be helpful as well.
Ah, I see the problem: the code tag eat my brackets.
The HLAs and the old analyzers exports the data byte-per-byte.
However I would like to group the bytes to packets and print the packets line-by-line.
My idea for packet forming is simple: if a byte arrives within a certain amount of period to the previous one (user editable parameter) then it belongs to the same packet if not it is a new packet.
This is a basic command-response based UART communication which is quite common.
What I would like to see for this one as an output: one line for the command and one line for the response (prefixed with some user parameter). The bytes in the packets are printed with HEX separated by spaces.
In the image above this is the beginning of the R16 TX - STM command packet:
My intention to have an export capability in the following way (TX, RX is the user specified “channel prefix”):
TX AA 12 01 D0 ...
RX AA 58 01 07 ...
During reverse engineering I often create traces while applying different circumstances to the target and do diff on the created traces with standard text comparison tools.
If the output is packetised properly it is easier to edit/spot differences/etc.
I also second that this could be a nice feature. For example earlier when I was working with Dynamixel Servos by Robotis, I helped make a low level analyzer that worked with these servos, but this was on one serial line that runs in half duplex. Keep wondering about trying to convert this to HLA…
But currently, I am playing with some new servos by Lynxmotion(RobotShop), which are full duplex, with RX and TX lines running to each of the servos. So again it would be interesting to have an Analyzer that understands the TX and RX packets known by these servos. into one stream.
If I were going to hack it for my own usage, could maybe try something like, have an HLA over each Serial IO channel , that does sort of as you mentioned, that maybe tries to gather all of the information of each packet into one logical unit. Either by timeout, or knowing a little about the packet formats, like they start with XX XX and or have a length field…
Then I would maybe have an output version which dumps these out with a beginning time stamp, some form of identifier like which channel, and then the Serial data…
then if I could output both of them, I could then manually load both of them into text editor and sort by time stamp…
After thinking about this some more, modifying the Async Serial analyzer itself using our Analyzer SDK and adding support for a second channel may be your best bet.
Yupp, that was my idea as well, I just wanted to ask around to make sure that I am not replicating something which is already implemented.
I’ve compiled the library on my Ubuntu 22.04, I use AppImages. I’ve tried to use and I get following error.
When try to use with Logic 2.4.7:
When try to use with Logic 1.2.40:
I’ve tried to put AppImages and the .so file to root /, set the plugins path to root and run it from there.
The same error comes, with just root / path to the so file.
@Oleksii At first glance, I suspect the analyzer might need to be updated to meet the requirements of our new build process. Back in 2022, we sent a message out with instructions on this to the more commonly downloaded community shared analyzers.
I pulled the instructions from another community repository linked below:
You’ll likely need to update the analyzer to the new build process using the instructions above. Let me know if you run into any specific issues with that!
