• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 3394 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F5418A: MSP430 SPI Slave Receive Issue

Paul Terricciano
Intellectual 270 points
Part Number: MSP430F5418A

  Our application is implementing a synchronous interface as a SPI Slave. The communication protocol is half duplex so the driver is either receiving or transmitting. The clock phase and polarity are defined by a standard and we cannot change them. It can run for days, months and forever but occasionally the UCB0 will issue the Receive Interrupt after the 7th clock edge on every receive byte. The data in the receive buffer is either shifted by one bit or sometimes the contents of the transmit buffer shifted by a byte. Before every receive transaction the UCI is reset and configured. It sometimes requires several POR to clear the condition and it will not reoccur for weeks. It only 1 component of a system and it is very inconvenient to power cycle the entire device and the unit has to be physically opened to reset the MSP430. It has started to show up in the field and is becoming very troublesome. I have attached captures of good and bad reception sequences. The Receive interrupt sets an clears an IO pin which lets us know when it occurs.

Spi receive initialization

{
	volatile uint8_t	dummy;
	// SPI communication
	StopFlashWrite = true;
	UCB0CTL1  			  =  UCSWRST;
	RcvState              = R_DEVT_1;
	RcvCount              = 0;
	XmtCount              = 0;
	checkSum			  = false;
	errorCode			  = 0;
	UCB0TXBUF 			  = 0xDE;
	P3SEL		          = CEAMoSi | CEAClock;
	P3DIR				 &= ~(CEAMiSo | CEAMoSi | CEAClock);
	UCB0CTL0  			  =  UCMSB + UCSYNC + UCCKPH;
	UCB0CTL1  			 &= ~UCSWRST; // Release reset
	dummy				  = UCB0RXBUF;
	EnableRxInterrupt();
}

Correct Receive Timing

Incorrect Timing show entire handshake. On receive of 4 byte, the message is determined to be corrupted and receive aborted.

Same capture, at a higher resolution.

Regards,

Paul Terricciano

  • 0
    TI__Mastermind 49692 points

    Hello Paul,

    Thank you very much for your detailed post - the description and screenshots are extremely helpful!

    The issue that you're observing seems to be caused by the USCI40 errata. For your reference, I've included a snippet from the MSP430F5418A's erratasheet.

    Also, here are some threads that talk about this errata and also how the workaround works.

    Please try this workaround and let me know if that resolves this issue.

    Regards,

    James

    MSP Customer Applications

  • 0 in reply to James Evans
    Intellectual 270 points
    James,
    We have read USCI40 errata, though it seems to refer exclusively to transmit problems which we have not seen. We have tried writing to the transmit buffer, per the workaround, in our receive interrupt handler but that has not made a difference. We have tried to hold the peripheral in reset, UCB0CTL1 = UCSWRST;, for an arbitrarily long period of time, greater than a second, which does seem to help but is very detrimental the product performance. We have not had an opportunity to tune this reset hold time. Is there a detailed explanation of what is happening so that me may try to reason what we may doing in the rest of the system to trigger the condition?

    Best Regards,
    Paul Terricciano
  • 0 in reply to Paul Terricciano
    TI__Mastermind 49692 points

    Hello Paul,

    Thank you for your reply and for trying the workaround.

    Based on your description of how the issue may take days, months, or even longer to occur, I'm suspecting that noise from the operating environment, nearby noisy traces on the PCB, another device on the PCB, etc. is occurring on the SPI clock signal. If a glitch happens, perhaps this could be perceived by the MSP430F5418A as a SPI clock edge, which would cause the received data to be shifted. I see that you shared logic analyzer data, which is very helpful. However, you may need to use a scope to capture a glitch if one exists.

    What's the master SPI device? Are there any other slave SPI devices besides the MSP430F5418A? If so, could any other slave SPI device (besides the MSP430F5418A) cause a glitch on the SPI clock signal?

    With regards to holding the USCI module in reset or power cycling the MSP430F5418A, the master SPI device needs to know when the slave SPI device gets reset to stay synchronized with each other. If the MSP430F5418A comes out of reset, there's a strong chance that it won't be synchronized with the master SPI device. I think this is why it works sometimes but not always.

    Regards,

    James

    MSP Customer Applications

  • 0 in reply to Paul Terricciano
    TI__Mastermind 49692 points
    Hello Paul,

    I'm just checking to see if you've been able to resolve this issue.

    Regards,

    James

    MSP Customer Applications

**Attention** This is a public forum