Sniffing SPI data with Bus Pirate

Posted on Sunday, February 12th, 2012 in Bus Pirate, how-to, MSP430 by the machinegeek

Greg Whitmore at Four-Three-Oh forum has written a quick how-to post on using the Bus Pirate to sniff SPI data on the MSP430. We’re reproducing the post here in its entirety with Greg’s permission.

Bus Pirate, SUMP and the MSP430

To start off, this is not a tutorial but more of a quick how-to. The 1st post will be about using your Bus Pirate to “sniff” SPI data on your MSP430. Mostly, I’m posting this because I’ve never found clear instructions or examples on doing this but it’s been important in solving a lot of programming issues. The Bus Pirate is the handiest tool on my bench -it’s tiny and has a lot of functionality.

Hardware Connections
Bus Pirate -> MSP430
CS -> UCBxSTE (or your CS pin)
CLK ->UCBxCLK ( or your SPI clock pin)
MISO -> UCBxSOMI (or your SPI input pin)
MOSI -> UCBxSIMO (or your SPI output pin)
AUX -> SPI D/C or other Trigger source.

Alternative Sump Logic Analyzer Client

Labeled Client Project for MSP430

It’s a pretty simple process. Once you’ve downloaded the files, run either run.bat or for windows or linux. Open the Labeled Client Project, which will be MSP430_SPI_Scanner.olp

Once opened, you’ll see this:

Then, what I like to do, is create a logic trigger in my program. This is done, so I can determine exactly when I want to trigger the analyzer instead of relying on a clock source.

This code can be placed in your main.c:

Code: Select all
// manual logic trigger for analyzer
#define LOGIC_BIT BIT7

Here I used P1.7 on the MSP430F2274. Change the port and bit configuration to suit your hardware. This will be the pin we connect to the AUX pin of the Bus Pirate. Then you can place TRIGGER; anywhere you’d like to start analyzing your data.

To being a capture, click on the ‘Start Capturing’ button. You’ll be presented with a configuration window. Select the configuration for your hardware; Analyzer Port is the com port for the Bus Pirate. Leave the speed at 115200bps and for Device Type, select “Bus Pirate OLS mode”. In the Acquisition tab, leave the default settings. Move to the Triggers tab; check the box to enable the trigger. For mode, select “Serial” and Channel to 0. The last step is select the Trigger Mask. We’re using Channel 4 (AUX on the Bus Pirate), so put a check in the 5th box from the right.

It should look like this:

Before pressing the capture button, prepare your MSP430 by making all the hardware connections and adding the TRIGGER macro. I like to use the CCS debugger together with SUMP. The capture button can be pressed and it will wait until you press Run in the debugger.

If all goes well, you’ll have a nice signal captured that looks similar to:

From here, select “Tools -> SPI Analyzer”. The proper channel and mode settings were saved as part of the Labeled Client Project, so just press “Analyze”. You will see all of the data that was transfer and at what times. Press close when you’re done reading.

The resulting window after Analyzing:

Here you can see that our Trigger was pulled high, CS was pulled low, no serial data was incoming, the clock is function properly and our outgoing datastream is “0xAE, 0x00, 0x10, 0x40, 0x00, 0x81, 0x8F…..” (BTW, that’s the init sequence for the OLED Booster Pack)

To scan again, just press the “Repeat Capture” button. This also works for I2C, UART and other protocols (with different settings, of course).”

Via the contact form.

This entry was posted on Sunday, February 12th, 2012 at 12:41 am and is filed under Bus Pirate, how-to, MSP430. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

3 Responses to “Sniffing SPI data with Bus Pirate”

  1. Jay Wilkinson says:

    That will be real handy soon!

  2. Jim Narem says:

    I think it’s pretty important to identifiy the limitations of this use of SUMP and BP when
    applied to SPI data. It seems that the BP is sampling each of the input lines simultaneously at 1 MHz then dumping that 4K buffer down to SUMP. Unlike a hardware logic analyzer, this has no clock line to trigger the samples; instead the dissection of the SPI data is done using the sampled SCK line.

    This implies that sampled clock rate must be slow enough that your sampling clock (1MHz)
    can reconstruct it good enough to identify the sampled clock transition points where
    the data lines are valid. This may depend on the SPI transmission mode.

    My ballpark guess would be a max 200 KHz SPI clock, assuming that the SPI data
    lines are sampled at the last sampled clock tick before the transition. A 5X oversampling
    rate probably isn’t fast enough to see any SPI clock “issues”; for instance when you
    use a faster logic analyzer you can see (in the SCK line) the execution delay in AVR code between bytes being sent by the AVR SPI interface as you loop through the data.

    If you use this, it’s pretty important to get a handle on it’s limitations; just as with a digital sampling scope, once you start to get close to the samping rate the data loses information fast and you have to identify the lies because sometimes the machine
    will not.

    The BP hardware SPI sniffer is completely different method and may be a better bet once you’re sure that the SPI data transfer is working at the hardware level.

  3. Todd Carney says:

    Hey, I’ve looked all over YouTube for your Bus Pirate Week Day 4 video. Was a day 4 episode ever made?

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Recent Comments

  • readybrek: They're tasty tasty very very tasty... they're very tasty.
  • hli: Sunday++
  • Chamod: Check on your buddy. Make sure they don't forget their lunchbox.
  • Kurt: But February made me shiver With every paper I'd deliver Bad news on the doorstep I couldn't take one more step
  • Craig Hollabaugh: Excellent tip, please keep these coming. Thanks!