SPI Sniffer misses clock signal changes

[JYouren]

I am sniffing a SPI device using the 'official' SPI sniffer exe and can see that the SPI data read has missing CS transitions, as confirmed by a logic analyser. For example, this snippet:

5B [5C 00 0x00(41 0x41)5C 0A 0x0A(00 0x00)5C 00 0x00(41 0x41)5C 8A 0x8A(00 0x00)5C C1 0xC1(41 0x41)5C 0A 0x0A(00 0x00)5D ]
5B [5C 00 0x00(01 0x01)5C 0A 0x0A(00 0x00)5C 00 0x00(01 0x01)5C 0A 0x0A(00 0x00)5D ]
5B [5C 00 0x00(41 0x41)5C D7 0xD7(00 0x00)5D ]

I would expect them to be structured similarly to

5B [5C 28 0x28(00 0x00)5C 00 0x00(00 0x00)5D ]

which some are.

The logic analyser shows clear CS transitions for every 2 MOSI bytes, where first byte is command/register, second byte is data. CS high lasts for about 1.148us, where low lasts around 19.103us. MOSI and MISO data otherwise seems ok.

Serial speed: 2000000

Bus Pirate v3.5
Community Firmware v7.1 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v4.4

[USBEprom]

Hi JYouren.
Good catch, thanks!
You wrote

Bus Pirate v3.5
Community Firmware v7.1 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v4.4

Could you please write a link to the firmware you are using?
Thanks.
Some of the firmwares released have problems of various kinds, could be what you wrote attributable to one of these below?

http://dangerousprototypes.com/forum/index.php?topic=8498.msg67164#msg67164
http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=45#p66033
http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=60#p66038
http://dangerousprototypes.com/forum/index.php?topic=8498.msg67167#msg67167
#74
#54 (comment)
#45

Be seeing you.

U.Sb

[JYouren]

I was using the latest firmware you had posted which sets the bus pirate to the higher usb com speed by default 115200 from the bus pirate forums. From beginning of this year I think.

[USBEprom]

Hi JYouren.
Do you mean S-2M-1.hex (http://dangerousprototypes.com/forum/index.php?topic=1776.msg67352#msg67352)?
If so, as far as I know it should have no problems with the SPI protocol, because I know that all the firmwares released later version S_1-28102018.hex and U_1-28102018.hex (http://dangerousprototypes.com/forum/index.php?topic=8498.msg67796#msg67796) until before S_1-29092019.hex and U_1-29092019.hex (http://dangerousprototypes.com/forum/index.php?topic=8498.msg70165#msg70165) do not work properly with SPI protocol, probably due to some incompatibility introduced with the patch used to correct timing in the protocols 2-WIRE, 3-WIRE and 1-WIRE, as the culprit seems to be due to the management of delays (#23 (comment)).
S_1-29092019.hex and U_1-29092019.hex (http://dangerousprototypes.com/forum/index.php?topic=8498.msg70165#msg70165) are exactly the same S_1-28102018.hex and U_1-28102018.hex as before but rebuilt with the agatti fix for AVRDUDE in spi.c (#122), so by using them AVRDUDE too it is functioning, while S_1-28102018.hex and U_1-28102018.hex have problem with it.

Be seeing you.

U.Sb

[JYouren]

I believe it was one early this year.

It looks to me potentially to be a limitation with the hardware? The SPI communication was very quick - and looking at the source code for the SPI sniffer, I couldn't see any scenarios where it would not work correctly.

[USBEprom]

Hi JYouren.
The date you wrote does not tell me anything.
Just out of curiosity would it be possible to have that firmware?
Thanks.
You wrote "Serial speed: 2000000", do you mean setted as described here?:

http://dangerousprototypes.com/forum/index.php?topic=6765.0

I do not know if it is a limitation of the hardware or not, I remember using 'official' SPI sniffer exe in order to acquire the data exchanged by an SD card and having obtained congruent data to what was captured with a logic analyzer.
I seem to remember that at that time I was using stock firmware v5.10 on my Bus Pirate v3.6.