I am running version 2.4.8 and I am seeing two issues with the PMBUS decode. The biggest issue is the PEC calculation is intermittently wrong and says the PEC value that we send is invalid. This mainly seems to occur on a Read where the PEC includes the entire transaction. In the attached trace, the very last transaction is doing Read from Address 0xD6 which returns a byte return value of 0x00, so the PEC calculation should use the values
0x78 0xD6 0x79 0x00
PEC value should be 0xCF but the tool says “Bad PEC 0xCF should be 0x1F”
Other times it reports it correctly. It could be noise on the bus that is corrupting the bus or that I may not have the sampling correct or the repeated starts or the clock stretching. Other times though it works and I do see it work on packets over 200 bytes long so I know the base operation is correct. There is something in this trace provoking this issue.
The second more benign issue is that the PMBUS module does not decode the first transaction on the bus. This can also be seen in the attached trace. This is just a nit but I thought I would point it out.
Finally the third issue is a request to support decoding the most recent updates to the specs M-CRPS spec which added more defined commands to registers 0xD0-0xDF as well as others.
bad_pmbus2.sal (18.2 KB)
Another thing to try is turning on glitch removal, especially on any line that acts like a clock.
I just went back to look at doing something like you said and ran into one of the other issues I have had with the PMBUS module that I forgot about.
After I get these invalid PEC decode errors, if I save the trace and then re-open the trace, the decoding now gives a different decoded value which is now correct. Its also decoding and displaying the PMBUS data of the the first packet.
It really feels like the tool is taking one path through the SW on a live capture and a slightly different path through the decoding SW when the trace is loaded from a file(which would be the normal SW development path).
@kenjustken42 Sorry about this! This looks like a known bug with our SMBus analyzer, and we’re planning on implementing a fix in the next official release of our software.
Having said that, you can implement the fix in the current version of the software by following the steps we’ve highlighted below.
Hopefully that works out for you in the short term, at least until we officially implement the fix.
To address the 2nd issue - the first transaction seems to be getting decoded. Could this be an artifact of the above mentioned bug? (i.e. issue appears after real-time decoding, but saving/re-opening the capture file causes the first transaction to be decoded properly).
Thanks for the the heads up on your 3rd point as well. Feel free to get that posted in the Issues section of our SMBus GitHub repository below, and/or our feature requests site so that we can properly log your feedback. I can do so as well on your behalf if you prefer!