I am working with an SPI bus that is going through multiple layers of bus isolators, which creates significant round-trip latency between the CLK going out and any changes to MISO coming back in:
D0 and D3 are measured at the master end, D4 and D7 at the slave.
As you can see at the center of the picture, the MISO level change on the master end happens after the sampling clock edge on D0.
This of course confuses Logic’s SPI analyser.
The thing is… the actual system is working fine! I suspect the master MCU itself samples the MOSI line a lot later than its own sampling clock edge, as I am able to crank up the baud rate by quite a bit further without communications failing.
My feature request is thus:
Please add an adjustable delay for the SPI analyser between the clock edge and it actually sampling the bit.
This would let me debug the bus without modifications like reducing the baud rate that can create issues elsewhere.
This is a common issue. We’ve had the same problem here driving ADCs over an isolation barrier. However I think the fix is to think about the two sides of the barrier as two different busses. In our case we bring the clock from the isolated side back to the unisolated side. Because it suffers the same latency as the data signals both returned clock and data are aligned correctly. This fixes the hardware problem.
The same mindset offers a solution to the measurement problem: point two analysers at the bus, one looking at what the master sees and the other at what is seen on the far side of the barrier.
Yes, that is how I would normally approach this problem too. I only recently joined the project, and was very surprised when I saw the above signals and found that the bus was still working fine. If this was a greenfield project, I would absolutely recommend your two-bus approach.
As it is, I think we are either looking at some genius design that takes into account absolutely undocumented features of the master MCU - or a happy little accident.
You could check the analog data, and confirm your logic voltage levels:
… if you have a pro model, consider if a different threshold helps to reduce the latency. If you are confident that the hardware latencies aren’t affecting the decoding, then you could just use the SCLK and MISO from the slave side in your analyzer decoder vs. looking on the master side.
Note: the new Logic MSO lets you select a custom digital voltage level, so you could ‘tune’ to levels that work better for your hardware, assuming that the signal starts to move quickly enough and still get over any noise.
It would also help to confirm the behavior in the datasheet – does the hardware actually sample on the clock edge, or at some internally clocked/delayed offset? This analysis can help you determine how robust the actual hardware design is. Does it always work with the round trip latency, or just ~99% of the time?
