Thanks everyone for the details.
This looks like a bug in the SMBus analyzer.
I was able to modify the simulated data generator temporarily to reproduce what seems like the same issue, and then implement a fix: Fix invalid results when running in real-time. by Marcus10110 · Pull Request #3 · saleae/smbus-analyzer · GitHub
However, I don’t have a really good way to test this here. Ideally, if @smarty8 or @wgoebel happens to still be working on SMBus recordings, it would be great if you could test the fix.
To test, you just need a github account to download the analyzer. Once you are signed into github.com, go to this page: Fix invalid results when running in real-time. · saleae/smbus-analyzer@72b0c8e · GitHub
Scroll to the bottom, you will find a section called “Artifacts”. You can click the name of your platform to download the correct file, e.g. “windows”. Note if you are not signed into github.com, the artifacts won’t be downloadable.
Once you extract the zip file you have downloaded, you will want to back-up the smbus analyzer you already have, and then copy & paste the new SMBus analyzer into your analyzers directory. Note - you cannot have both the old and new SMBus analyzer loaded at the same time. This is because our software can’t handle multiple analyzers loaded that have exactly the same name.
Analyzers can be found here on Windows:
C:\Program Files\Logic\resources\windows-x64\Analyzers
Make sure that Logic 2 is not running.
move the old smbus_analyzer.dll out of that directory, then copy in the new one. Note, simply re-naming the old smbus_analyzer.dll might not work, because the analyzer name is imbedded in the DLL. If you change the file extension to something other than *.dll, that will prevent it from getting loaded.
Copy the new smbus_analyzer.dll into the same directory, then launch the software.
Notes on testing:
- The bug only occurs while the SMbus analyzer is running in real-time. If you add the SMBus analyzer after the recording is complete, or edit any of the settings of the SMBus analyzer after recording, this will cause the SMBus analyzer to run on the already recorded capture, which was already working properly.
- The best thing to do is to export the CSV right after recording, before doing anything else.
- You can easily restart the analyzer by right-clicking it and selecting “restart”. This should be faster than saving and re-loading the *.sal file, and have the same effect.
We’re looking for 2 things:
- The SMBus results are decoded correctly
- The SMBus analyzer produces the same results for both the real time case and the already-recorded case.
Background:
Our analyzers run in what we consider 2 different “modes”. First, the real time mode. This is when the analyzer is running at the same time the data is being recorded from the device. In this mode, the analyzer processes one bock of data at a time. Analyzers may spend a lot of time blocked while waiting for more data.
The second mode is when the analyzer is run on a complete recording. This happens when you add an analyzer to an existing capture, edit the settings on an analyzer on a completed recording, or load a file that contains analyzers. In this mode, 100% of the data in the recording is available when the analyzer starts.
Our analyzers are designed to work properly in both cases. However, after taking a quick glance at the SMBus analyzer source, I was able to find a bug that could cause it to produce invalid results in the ream time case. There is more detail of the problem in the Github PR link posted above, but basically the analyzer wasn’t written with the real-time case in mind, and was likely mainly tested on SMBus analyzer saves.