Hi Mark,
Could you share your analyzer source code, so we could use it to reproduce the first issue over here for debugging? If not, we can just modify our SPI analyzer to mimic the behavior.
The link I provided in the previous post has details on this but here are the links for convenience:
The plugin supports simulation but I think that feature is still missing in V2, so if you need a capture the link here has a file which can be used:
The plugin is quite complex and not the easiest to understand what is going on; so here are some additional details that might help:
The actual SPI packet structure is as follow (taken from the ABCC40 Software Design Guide):
NOTE: What is shown in the image above is one SPI packet (one instance where chipselect may assert low and then deassert). What I show within the red box is what my previous images correlate with. In the same timespan as MISO’s “NETTIME” field, the MOSI has “APP STAT”, “INT MASK”, and 2 bytes of the message data field which in this case I implement each byte of the message field as its own V1 frame.
Effectively my plugin is creating the following V1 frames:
MOSI (CH1): [ Frame #1 ][ Frame #2 ][ Frame #3 ][ Frame #4 ]
MISO (CH2): [ Frame #5 ]
TIME: --------------------------------------------------------------->
Over this time span there are a total of 5 frames added. 1 for MISO, and 4 for MOSI. I use the flags field of the V1 Frame to indicate whether the frame is for MOSI or MISO (if looking at the source code this is “SPI_MOSI_FLAG”).
The logic implemented in GenerateBubbleText() is separated into a few parts. The main two sections consist of:
- Logic that ONLY concerns MOSI
- Logic that ONLY concerns MISO.
Effectively, when a MOSI-indicated frame (i.e. the special SPI_MOSI_FLAG is asserted in the V1 Frame’s flags field) is passed into GenerateBubbleText() with the “channel” parameter set to MISO, this frame (in most cases) will be skipped (no call to AddResultString is made). This is how this separation of MOSI/MISO frame structure is supported.
- The exceptions to this is for common/shared events that both channels exhibit at the same time. This for instance is for things like an SPI fragment where the SPI chipselect deasserts before the end of the packet is reached. Such an event may be handled for both MOSI and MISO. In these cases the frame time span is identical (and the same exact V1 frame).
Comparatively, the Saleae SPI plugin does this (where the frame size is specified by user settings):
MOSI (CH1): [ Frame #1 ][ Frame #2 ][ Frame #3 ][ Frame #4 ]
MISO (CH2): [ Frame #1 ][ Frame #2 ][ Frame #3 ][ Frame #4 ]
TIME: --------------------------------------------------------------->
In other words, a V1 frame that is committed contains data for both MISO and MOSI. This means the SPI packet framing structure must be identical for both MISO/MOSI. The previous example avoids this by committing frames for MOSI independent of MISO.
During initial development of the plugin I considered the alternate approach where the plugin would always use a frame size of 16-bits this would make both MOSI and MISO have the same frame size.
Current framing structure:
MOSI (CH1): [ APP STAT ][ INT MASK ][ MSG DATA ][ MSG DATA ]
MISO (CH2): [ NETTIME ]
TIME: --------------------------------------------------------------->
Alternate framing structure (16-bit frames):
MOSI (CH1): [ APP STAT + INT MASK ][ MSG DATA0 + MSG DATA1 ]
MISO (CH2): [ NETTIME LO-WORD ][ NETTIME HI-WORD ]
TIME: --------------------------------------------------------------->
I opt’d against it since using a field’s actual data size as the frame size is more intuitive than splitting up a 32-bit value into two 16-bit frames. And certain features like the CRC32 field where computation is performed and the bubble text will indicate to the user if the CRC32 is invalid would not be as clean of an implementation.
- NOTE: You might wonder why did I not consider 32-bit framing structure instead of 16-bit frames? Well the SPI packet structure does not have this guarantee. The protocol defined here only guarantees the number of bytes transmitted will always be evenly divisible by 2.