(As you read this post, please be sure to read my further replies that clarify and effectively answer my own question.)
Our design uses two MSP430F5359 microprocessors. One MSP430 acts as a SPI Bus Master device and interfaces to multiple SPI Bus Slave devices including the other MSP430. This post is about the MSP430 that is using one of its USCI_B peripherals as a SPI Bus Slave device.
Normally, our system works fine. At power-up time, both devices initialize their respective USCI_B interfaces into the correct modes (Master, 3-wire SPI and Slave, 4-wire SPI, respectively) and all is well. When the Master device MSP430 is addressing the Slave device MSP430, the Master clocks the SPI Bus at about 31,500 Hz. When the Master device is addressing other devices on that same SPI Bus, it clocks at 1 MHz. All is fine.
But it is possible for either MSP430 to fail and restart. In that situation, we've found the following apparent MSP430F5359 hardware failure:
- If the incoming SPI Bus clock is running when the SPI Bus peripheral
is initialized as a SPI Bus slave device, then the state machine in the
SPI Bus slave peripheral is improperly initialized. The result is that
FOREVER MORE1, the SPI Bus slave peripheral improperly frames
the SPI Bus bytes. For both transmission and reception, it frames
the bytes “a few clock cycles” off from where they should be framed
based on SPI Bus STE (“Chip Select”). See the ‘scope shot below.
The number of bits slipped is arbitrary/random. In the ‘scope shot, the number of bits slipped is 2. I've highlighted where we write Slave device's SPI Bus TXBUF and where those bytes are then sent on MISO. You can see how the correct bytes are transmitted but slipped by two bits relative to the way the SPI Bus bytes ought to be framed.
And while you’d think that the SPI Bus Slave state machine would re-initialize with every new assertion of SPI Bus STE (“Chip Select”), this isn’t the case. The exact same value of bit-slippage persists from one SPI Bus transaction to the next meaning that our system, as currently coded, never recovers from the onset of “bit-slippage”.
This can occur if the SPI Bus Slave MSP430 fails and restarts while the SPI Bus Master MSP430 is addressing and transmitting to the Slave MSP430 (or maybe any SPI Bus slave device; I haven't checked).
We're going to change our code to do another SPI Bus Slave device reset each time we detect a failure from the Slave device side of the interface. This works-around the problem although it may take several tries because the Slave has no say-so about when the Master device attempts a SPI Bus transmission. But it's pretty clear that there's a hardware problem with the implementation of the USCI_B SPI Bus Slave state machine hardware2.
1 Well, until you reset again without the incoming SPI Bus clock running.
2 We're aware of Errata USCI40; this is different.