search

saleae / jtag-analyzer

Saleae JTAG Analyzer
MIT License
17 stars 4 forks source link

Bug at decoded message #4

Open bauergeorg opened 1 year ago

bauergeorg commented 1 year ago

Saleae Logic display wrong decoded message for message size larger than 256 bits: image

Version (2.4.2) {"Environment":"production","Branch":"master","Commit":"7279335064ab01578c4ea5fa100df9f3f1c37353","Version":"2.4.2","AutomationVersion":"1.0.0","MachineID":"43070b86-d9b2-497d-9078-a3818dba19b4","PID":22824,"LaunchId":"bae99020-1c2e-491b-93e4-099590b75b57"}

In Detail: I try to send via JTAG SVF files like this:

TRST ABSENT;
ENDIR IDLE;
FREQUENCY 15E6 HZ;
SIR 160 TDI (0000000100000002000000030000000400000005);

The Logic Analyzer display a valid result! If I increase the SIR bits to a number larger than 256 bits (e.g.)

SIR 288 TDI (000000010000000200000003000000040000000500000006000000070000000800000009);

A wrong decodes message will be displayed.

Here is the sal file bug_jtag_decode.zip

bauergeorg commented 1 year ago

I think this bug is not in the last release software before 2.4.2!

bauergeorg commented 1 year ago

I am looking forward to get a hotfix release version.

bauergeorg commented 1 year ago

Ah I realize: In the old software you will display the first bits... now you display the last (256) bits image

But I this case you should write "0x...ABCDEF (512)" and not "0xABCDEF... (512)".

timreyes commented 1 year ago

Oh wow, that's a pretty embarrasing oversight by us, and I'm glad you noticed the subtle difference. You're right, we should have displayed it as "0x...ABCDEF (512)". I'll bring this up with the team here. Thanks for reporting this, and sorry for the trouble with that.

timreyes commented 1 year ago

Tied to ticket (#77245)

Marcus10110 commented 1 year ago

Ok, I think I found the bug. It actually has been in the JTAG analyzer the whole time, I did test an older version of the SW to make sure it was not a regression:

https://github.com/saleae/jtag-analyzer/blob/50faedcecbabd8be7568db2bad1c7bf94adc559a/src/JtagTypes.cpp#L160

The problem is that we take the trailing end for the subset, but then add the "..." to the start of the data.

Note, there are actually 2 different trimming systems in play here. GetTDIString, which calls GetStringFromBitStates, takes the trailing bits.

Then, GenerateBubbleText will take that string and will truncate the ending characters and add a trailing ....

The simplest solution will be to move the ... in the GetStringFromBitStates function to the start, but when these two systems overlap, the results will be ugly.

The truncation system in GenerateBubbleText only kicks in when the bubbles are too small to fit the full string in the application. That's a bit tricky to do in the sample provided here, but if you shrink the software window horizontally, you can see it kick in:

image image image image Here is the non-truncated version. image

Marcus10110 commented 1 year ago

I just tossed in a quick fix to at least make this correct. I need to fix CI on all of our LLA repos before this ships though.

Marcus10110 commented 1 year ago

I've merged the fix to the master branch here, but it won't ship until we've fixed our build on Linux, which right now is pulling in the latest libstdc++ version, which no one has...