Dangerous Prototypes Open Source Hardware

SPI sniffing with the Bus Pirate

January 11, 2010, 03:45:55 am

Hi,

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 author="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.[/quote]

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 author="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.[/quote]

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.

The Bus Pirate is well-designed, so it is entirely possible I'm just misunderstanding the docs. Any answers are appreciated. Thanks!

Disclaimer: I haven't tried SPI sniffing with the Bus Pirate yet, and I wish to apologize if any of my questions have an obvious answer once we test on hardware.

Re: SPI sniffing with the Bus Pirate

Reply #1 – January 11, 2010, 08:35:03 am

It will sniff any speed, the speed setting is ignored by the PIC SPI slave mode, as far as I can tell. You can refer to the PIC24FJ family reference manual though:
http://www.microchip.com/stellent/idcpl ... odeId=2575

You are correct. After the buffer is full it drops randomly. Finding the boundary is impossible and data shouldn't be trusted if the MODE LED is off. It might be better to send a control sequence so you know exactly when the buffer is full, but the current code base for the ring buffer wouldn't support that without a rewrite.

The Bus Pirate sniffer probably won't be useful in your situation because the speed is so limited by the UART connection, and the buffer is limited by the PIC memory. The sniffer is a little bonus feature supported by the PIC, but the Bus Pirate hardware was never designed to support high-speed bulk transfers like that. There are some (rather expensive) purpose-built sniffers (I can't think of the name, but I think it's pro tools or something), or you could try a logic analyzer with decent sample depth and speed (@10MHz you might try the Saleae Logic, it has continuous/unlimited samples).

Re: SPI sniffing with the Bus Pirate

Reply #2 – January 11, 2010, 11:16:42 pm

Thanks for clarifying! I don't know the exact encoding of the ring buffer, but given that it has to encode both CS# and actual data in two directions, I'm assuming that the first transaction (guaranteed to be smaller or equal than 516 bytes per direction) will not fill up the buffer completely and thus at least that first transaction should pass through safely. That will be good enough for a start.

Having the logging stop if the ring buffer is full would also help. Hm. We'll try to analyze the first transaction, maybe it already is enough.

Re: SPI sniffing with the Bus Pirate

Reply #3 – January 12, 2010, 08:04:02 am

Having the capture stop is a more sensible solution that fits better with the existing code. I'll try to implement that in the next update.

Re: SPI sniffing with the Bus Pirate

Reply #4 – January 12, 2010, 04:14:53 pm

Thanks, that would be awesome. Will the stopped capture be detectable from the outside (that is, show up in the log)?

Another question: If I start logging in the middle of a transaction (CS# active) will the Bus Pirate start logging immediately or will it wait until a CS# inactive->active transition?

Re: SPI sniffing with the Bus Pirate

Reply #5 – January 12, 2010, 04:47:02 pm

Unfortunately there's no way to push that extra info without a rewrite of the ring buffer.

Capture starts right away.

Re: SPI sniffing with the Bus Pirate

Reply #6 – January 13, 2010, 12:40:27 am

Well, as long as the logging stops if the ring buffer is full, I can start logging anytime the ring buffer is sufficiently empty, and then I'll just use the CS# transition in the log to find the start of the next transaction. Should work fine.