LIS3LV02DQ accelerometer, CC430/MSP430 SPI integration

Gianni Gibelli said:

   while (!(IFG2 & UCB0TXIFG));         // USCI_B0 TX buffer ready?
   UCB0TXBUF = address;
   while (!(IFG2 & UCB0TXIFG));         // Dummy write so we can read
   UCB0TXBUF = 0x00;
   while (!(IFG2 & UCB0RXIFG));         // USCI_B0 RX buffer ready?
   rbyte = UCB0RXBUF;                   // Save received byte  

Your program logic has a flaw with the double buffering mechanism.

First you write to TXBUF. Fine.
Since TXBUF is empty on the first run, the byte you wrote immediately moves to the output shift register and TXBUF is empty again. YOu sense this and write the 'dummy byte', which is correct (except that the dummy bytes are ususally written as 0xff). While doing so, the first byte is still being send and the dummy return byte is being received.
Now you wait for the RXIFG bit to be set, which finally happens. But it is set because you just received the dummy response for the address. At this point the dummy byte to read the real response has just moved into theoutput shift and the response has not been received.

Remember, you send two bytes and therefore you receive two and only the second one is of interest for you. The first is a dummy, sent by the slave while it was receiving the command.

So after writing the second byte to TXBUF, you have to wait until TXBUF is clear once more, indicating that the first byte was sent and the second has started to be sent. Then clear the RXIFG bit (or make a dummy read) and wait for the real response. But if this takes too long, you still might miss it, so you can wait for the busy bit clear (indicating that the last byte was sent and nothing is being received) which means that the first, dumym respons has been overwritten by the real answer (in this case, the overflow bit should also be set) and you can read your response.

It sounds more complex than it is. Just keep in mind that both, TX and RX, are double buffered (one byte in the buffer, one in the transfer).

Thank you so much for such a complete response. I have actually just spent another 5 hours looking at every port under an oscilloscope and deduced just that, now I wish I saw your response earlier but I still learned a lot from debugging it. The other problem was however that 4-wire mode on the MSP does not = 4-wire mode for the accelerometer. I actually want 3-wire mode (SIMO MOSI CLK) on the MSP with a manual CS, and 4-wire mode on the accelerometer (SIMO MOSI CLK CS instead of (SIMO/MOSI) CLK CS = "3 wire"). Lastly, the CS had to be delayed a couple of cycles to not cut off reception early.

Thanks again.

This is a common misunderstanding. The 4th lien i 4 wire mode is only used for controlling the clock/data output, so if this line is pulled by a different master, the port pins go inactive immediately. The program won't notice (o flag/interrupt) and it ha snothing to do with controlling a slave. Controllign a slaves CS line needs to be done manually with a normal port pin.

The reason is obvious: the might be any number of slaves on the same SPI. Actually, you can individually select as many slaves as you have free GPIO lines and access them all through the same SOMI/SIMO/CLK lines.
Also, the CS line often indicates the start of a complete transmission procedure. Releasing CS ends the current connection or acknowledges the receipt or aborts a command sequence or whatever. It's use (when and how long to keep it asserted) is different for different slaves.

The documentation properly describes the SPI hardware. It does not, however, explicitely explain the SPI bus and the interaction with different slaves (including the slave selection where necessary), and leaves room for this misinterpretation.