I was running into some problems trying to decode a quad-SPI flash memory device.
Specifically, I was trying to configure a ‘one shot’ capture of the entire power-up transaction, but running into two problems:
- The digital data packet loss on derived digital signals (even though all analog data was captured successfully)
- The ‘one shot’ trigger failed to actually STOP the capture properly
Background: Initial serial communications is ~ 5 MHz SPI, but switches to ~20 MHz QSPI mode. The SPI is not contiguous (idle/bursts between chip select transactions). The particular challenge with monitoring this, is that the SCLK signal itself is rather ‘shark-fin’ vs. ‘square-wave’ and not providing a clean digital signal that classic Logic/LogicPro can ‘see’ properly (as the clock isn’t transitioning well on normal digital thresholds).
Details on Issue #1: Digital Data Packet Loss
I am able to see a ‘clean enough’ signal from the Logic MSO, but was running into Logic dropping edges due to ‘too many’ … even though the actual communications should only be ~20 MHz Quad SPI.
Also, I connected SCLK onto one of the analog channels, expecting (hoping) that the Logic MSO would be able to track & derive everything that fits within the analog snapshot window – but it appears that the digital output is done separately from the analog, and ‘streamed’ the same way that the pure digital probes are handled? Are the 4 analog channels treated like an additional/virtual 4 channel digital probe and digital data streamed over USB, subjected to USB streaming bandwidth constraints?
If possible, could the software patch/fill any digital data streaming ‘holes’ that occur within the analog snapshot window(s), by using the analog data it successfully captured? (i.e., automatically insert the missing digital edge(s) lost from USB streaming overruns?) On a traditional MSO that can do ‘digital decoding’ from analog data, it uses the captured analog data (saved in the capture buffer) to derive the digital waveforms – so you always get 100% of the digital data that exists within the analog capture. It’s rather frustrating to have ‘missing’ digital data for the waveform, when the analog data is obviously right there in front of me 
.
The other question is what may be going wrong with the USB bandwidth that would cause data to be lost in the first place? My math says the worst-case edges should be 2 x 20 MHz x 4 channels, or only 160M per second (only if continuously streamed, which it is not). This edge rate should be well below the 300M capacity? I confirmed the Logic MSO was connected to a USB 3.2 Gen 1 port (running USB 3.0 at 5 GS/s), and no other device connected on this hub (the internal hub of the PC, no external hub between Logic MSO and the PC’s USB port). I tried both a USB-C (with provided USB-A to C adapter) and USB-A port, with similar results. All USB cables are those supplied by Saleae.
Note: I don’t have any issues with USB data streaming on the same USB port when using a LogicPro16 capturing at 500 MS/s or 250 MS/s (depending on channel count).
Is there any USB bandwidth / data integrity test mode to test my connection? I haven’t done much to debug this, as the LogicPro16 ‘just works’ and this is the first more demanding stress test on the Logic MSO that I’ve attempted.
Details on Issue #2: One Shot Trigger Problems
The second problem is that a ‘one shot’ capture actually appears to continuously trigger, rather than halting after the first trigger is detected. I think it might be due to a large capture window having to transfer a lot of data to the PC vs. how the ‘stop triggering’ might be handled?
Setup: 250 MS/s sample rate (>10X the 20 MHz SCLK frequency) for 3 seconds (1.4 s offset), so 100 ms pre-trigger, 2.9 s post-trigger and 750 MS capture buffer. The software estimates that this will take ~15 s to transfer from Logic to PC. However, the triggering goes from “searching” to triggered, and then back to “searching” and fails to ‘stop’ after the 3 seconds of data are captured.
I tried to increase the trigger hold-off, but the maximum value was 10 s (and it takes ~15+ seconds to transfer everything). So, it seems like adding the extra hold-off period only inserts an “arming” delay, but it will still go back to “searching” rather than stopping immediately after “one shot” like I expected. Does the PC side halt the capturing in one shot mode vs. being handled/halted directly on the Logic MSO? If so, would large post-trigger memory transfers interfere with one shot halting?
Meanwhile, a ‘quick fix’ might be allowing a larger trigger hold-off than 10 seconds?
Any feedback or suggestions welcome – as I’d much rather have Saleae’s analyzer library to decode a ‘full’ snapshot buffer than try to use something else.
Edit:
For reference, here’s a screenshot of a capture, where CH3 (blue, SCLK) is losing data on digital channel 3D while analog channel 3 is captured just fine:
