Bug at decoded message

[bauergeorg]

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

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]

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

[bauergeorg]

I am looking forward to get a hotfix release version.

[bauergeorg]

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

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

[timreyes]

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]

Tied to ticket (#77245)

[Marcus10110]

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:

jtag-analyzer/src/JtagTypes.cpp

Line 160 in 50faedc

std::vector<U8> subset( bits.end() - 256, bits.end() );

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:

Here is the non-truncated version.

[Marcus10110]

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]

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...