I'm trying to get sensible bits out of a Bus Pirate hooked up to a Launchpad board (Using the Sparkfun cable: Orange goes to P1.6, Yellow to P1.5. This should be correct, unless I have MOSI and MISO confused...). I don't have CS hooked up, since I'm just using the bus pirate to monitor anything.

The bus pirate is set up for SPI, 125KHz, Clock polarity Idle low, output clock edge Active to idle, input sample phase middle, /CS, output is normal.

On the Launchpad, I have a MSP430G2231 with no external crystal. Using Code Composer Studio, I have the following:

#include  "msp430g2231.h"
volatile unsigned char value=0;

#pragma vector=USI_VECTOR
__interrupt void universal_serial_interface(void)
void main(void){

    BCSCTL1 = CALBC1_1MHZ;                    // Set range
    BCSCTL2 &= ~(DIVS_3);

    USICNT = 8;

    __bis_SR_register(LPM0_bits+ GIE);  

Most of this is cobbled together from the various samples. After much reading of the data sheet, it does seem that the USI clock is set to run at 125KHz (SMCLK of 1MHz, divided by 8), although I do not have a scope to measure this.

When running, I get what is essentially garbage out of the bus pirate. P put a breakpoint on the first line of the USI interrupt vector, and had it go through three times, so I should have gotten 0, 1, 2 from the bus pirate


And letting it free run, I just get stuff like this:


Which still looks nothing like what I'm expecting.

I've spent most of the evening going through the users guide for the chip, and I'm still stumped.

While writing this, I discovered that I can use the Bus Pirate as a logic analyzer (using LogicSniffer), and set it up to do so. And modified the program to write 0x55 to USISRL, and change the USIDIV to USIDIV_4 to slow things down a bit more, and here's the results: enter image description here

The clock signal looks good, LogicSniffer reports that it's about 285KHz... and MOSI is... special. I would expect a nice alternating pattern, since I'm writing out 0x55, and that's anything but.

Any one have any thoughts on what I might be doing wrong? Defective chip? Something else?

EDIT: Ok, minor amount of idiocy on my part. I didn't change the value that gets written to SPI in the interrupt. Doing this results in the expected pattern:

enter image description here

However, going back to attempting to write out an incrementing byte gets me garbage: enter image description here

So, I still have a problem, just not as big of a one as I thought...

EDIT 2: Thanks to the comments below, I tied the ground wire off the Bus Pirate cable, which was previously unconnected, to the ground off my power supply (Sparkfun's breadboard power supply). Previously, the closest ground they shared was back in the USB hub I'm hanging all this equipment off of.

This removed the glitching on MOSI when running the counter program, and LogicSniffer can now decode the bytes correctly on its own: enter image description here

The bus pirate in monitor mode still reports odd results:


It does seem better able to detect the ends of the writes (I'm assuming that's what the square brackets delimit), but the data is decodes is still off. I'm not quite as concerned now that the waveform looks better, but it would still be nice to know why the Bus Pirate is getting confused.

  • 3
    \$\begingroup\$ That last diagram looks like it has glitches on the MOSI line, could be crosstalk from the clk. Do you an oscilloscope? What's you wiring like - do you have good solid short ground between the BusPirate and the MSP430? \$\endgroup\$ Commented Jul 13, 2012 at 10:47
  • 2
    \$\begingroup\$ I agree with @MartinThompson. The MOSI line is glitching and the Bus Pirate is getting confused. If you squint a little at the second picture and ignore what Bus Pirate thinks it sees (I just typed the binary I see into Windows calculator and converted to hex) you get 6B-6C-6D, incrementing like you want. You need to clean up the wiring between the Bus Pirate and the MSP. \$\endgroup\$ Commented Jul 13, 2012 at 13:32
  • \$\begingroup\$ I don't see a while(1); or equivalent at the end of main() to stop it exiting and doing random stuff. \$\endgroup\$
    – Oli Glaser
    Commented Jul 13, 2012 at 17:29
  • 2
    \$\begingroup\$ @OliGlaser, if I'm reading the sheet right, going into LPM0 actually halts CPU execution until an interrupt occurs. Most, if not all of TI's samples use this. It makes sense, since they tout the MSP430s as low power parts, and a busy loop isn't very power friendly. \$\endgroup\$ Commented Jul 13, 2012 at 17:32
  • 1
    \$\begingroup\$ Oh my, I just noticed this is > 1 year old. \$\endgroup\$ Commented Nov 16, 2013 at 9:26

2 Answers 2


MSP430 is a MCU example tha invert the CPHA naming convention, thus diverging from the standard SPI description: TI MSP430 uses the name UCCKPL instead of CPOL, and its UCCKPH is the inverse of CPHA. When connecting two chips together, carefully examine the clock phase initialization values to be sure of using the right settings.


MSP430 USCI SPI timing diagram

(Image source: Texas Instruments MSP430x5xx and MSP430x6xx Family User's Guide, SLAU208, Chapter 37)

As @Dirceu has said, the normal convention states that the receive operations must be handled in the leading edge of the pulse, if CPHA = 0. However, MSP430 somehow define CKPH instead of CPHA in such a way that CKPH is inverse of CPHA.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.