My SPI transactions come in groups of 4 bytes. After successfully decoding a long series of these 32-bit sets, the last byte (on only the last set) is never decoded. The clock looks good (8 falling pulses), but the analyzer just decides to quit a little early. I’m pretty sure this is a bug that is probably worth looking at.
I encountered this same issue with SPI and HLA. In the HLA I could see that the disable was not generated (or at least no passed to the HLA). This could be the same issue.
https://saleae.upvoty.com/b/logic-2-bugs/last-spi-disable-frame-not-generated/
Thanks for this additional information @kamiel. I can see how these issues might be related. I’m not using an HLA here but it would seem likely that a bug in the SPI analyzer would create issues for an HLA. I might expect the result frame to be affected but I don’t know much about HLAs. I have attached a capture with this issue in case anyone wants to see it: session_11.sal (571.9 KB)
I don’t think it is the case here, but I also see this at times if the CS pin comes up HIGH before the last clock finishes or at the exact same time.
Again visually I don’t think this is the case, but I would probably verify that.
Thanks for the ideas @KurtE. Yes, the packet shown is the same as all the other packets that are decoded properly. Only happens on the last packet and enable does not come up early. I posted the capture file above if you would like to take a look. Thanks!
Does anyone know if this project is open to the community? If so, I would happily fix this and submit a pull request.