Skip to main content
Topic: SPI sniffing with the Bus Pirate ?. (Read 662 times) previous topic - next topic

SPI sniffing with the Bus Pirate ?.

Hello,

I'm currently investigating whether it is possible to do some reverse engineering with the help of the Bus Pirate. Basically, we need to correlate an USB data stream (PC to undocumented device) with a SPI data stream (undocumented device to documented SPI flash chip). I'm not sure whether the undocumented device is just a stupid SPI master which receives SPI commands over USB and passes them through or whether it actually has builtin "intelligence". Dumping the USB data stream is already taken care of, so only the SPI data stream remains, and for that we'd like to use the Bus Pirate.

Some things about the Bus Pirate SPI sniffer mode remain unclear, though:
Quote from: http://dangerousprototypes.com/2009/11/05/bus-pirate-i2c-spi-sniffer-updates/
The SPI sniffer is implemented in hardware and should work up to 10MHz. It follows the configuration settings you entered for SPI mode.

Does this mean the SPI clock must be set in the SPI mode before sniffing, or will the sniffer work at any frequency below 10 MHz regardless of SPI mode speed settings?

Quote from: http://dangerousprototypes.com/2009/11/05/bus-pirate-i2c-spi-sniffer-updates/
The I2C and SPI sniffers now use a 4096byte output ring buffer. Sniffer output goes into the ring buffer and gets pushed to the PC when the UART is free. This should eliminate problems with dropped bytes, regardless of UART speed or display mode. A long enough stream of data will eventually overtake the buffer, after which new bytes will be dropped until space is available.[...]

Both sniffers use the user input buffer as a ring buffer. Any commands entered after the sniffer macro will be lost.
If the ring buffer is full, bytes are simply dropped until there’s free space. The MODE LED turns off if this happens.

Since I want to correlate logs, dropped data is a problem, made more severe by the fact that there will be an almost sustained (that is, there will be a delay in the order of microseconds after each 260-byte communication chunk) data rate of 10 Mbit/s in each direction (MISO+MOSI) with a total length of ~2 MByte per direction. That means I will overrun the 4096 byte ring buffer easily.

After that, will the Bus Pirate empty and fill the ring buffer bytewise and thus end up with a random selection of bytes from the stream being filled in to the freed byte(s) in the ring buffer each time one byte becomes free in the ring buffer? Such a random selection would mean anything past the first 4096 bytes is unusable as trace. OTOH, if the ring buffer is emptied in n-byte chunks (preferably larger than 260) the chunks are still useful.

It seems the MODE LED is the only indicator of a buffer overrun and there is no way to detect such a condition from the Bus Pirate output on the virtual serial port. That makes finding the chunk boundary impossible AFAICS.


thanks
jackyjoy