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.

MSP430FR2476:SPI communication issue between MSP430

Part Number: MSP430FR2476

Prepare two MPS430FR2476, each as master/slave
SPI communication (communication with eUSCI_A0) function is under development.


Among them, like [phenomenon], it is a situation where [what you want to do] cannot be realized due to unintended behavior.
Sorry to trouble you, but please answer the following [questions].


【phenomenon】
Immediately after writing data to UCAxTXBUF on the master side, it turn ON not only UCTXIFG but also the "UCRXIFG" bit.
 UCRXIFG turns ON even when the communication cable between slaves is disconnected.


[What you want to do]
 I want to detect a timeout error when there is no received data for a certain period of time on the master side.
  ⇒Currently, the received signal arrives immediately after transmission, so it cannot be detected.


【question】
1. Is the above [phenomenon] normal behavior? If there is an error, is there a workaround?
2. Is it possible to realize [what you want to do]? If so, do you have any sample code?


【detail】
The master/slave performs the following processing.


 Master: Executes the following processes at 1ms intervals.
         ① Data transmission     EUSCI_A_SPI_transmitData(EUSCI_A0_BASE, tx_data);
         ② Wait for BUSY OFF while(EUSCI_A_SPI_isBusy(EUSCI_A0_BASE));
         ③ Check the reception flag while(!EUSCI_A_SPI_getInterruptStatus(EUSCI_A0_BASE, EUSCI_A_SPI_RECEIVE_INTERRUPT));
          ④ Data reception      *rx_data = EUSCI_A_SPI_receiveData(EUSCI_A0_BASE);


 Slave:  Perform the following processing at the UCRXIFG interrupt.
         ① Data transmission     EUSCI_A_SPI_transmitData(EUSCI_A0_BASE, tx_data);
         ② Wait for BUSY OFF     while(EUSCI_A_SPI_isBusy(EUSCI_A0_BASE));
         ③ Reception flag check    while(!EUSCI_A_SPI_getInterruptStatus(EUSCI_A0_BASE, EUSCI_A_SPI_RECEIVE_INTERRUPT));
         ④ Data reception          *rx_data = EUSCI_A_SPI_receiveData(EUSCI_A0_BASE);


[Register setting]

Offset Acronym Master Slave
00h UCAxCTLW0 0x6B82 0x6302
00h UCAxCTL1 0x03 0x03
01h UCAxCTL0 0x00 0x00
06h UCAxBRW 0x02 0x00
06h UCAxBR0 0x02 0x00
07h UCAxBR1 0x00 0x00
0Ah UCAxSTATW 0x0000 0x0000
0Ch UCAxRXBUF 0x**** 0x****
0Eh UCAxTXBUF 0x**** 0x****
1Ah UCAxIE 0x0000 0x0001
1Ch UCAxIFG 0x000x 0x000x
1Eh UCAxIV 0x0000

0x0002

Best regards.

  • That is normal for SPI. As it transmits it also receives and there is no way to decouple that behaviour. It has to be that way since the master runs the clock.

  • 1) Yes, this is how SPI works. The master side simply samples MISO according to its clock, and has no idea whether the slave is sending anything.

    2) In general, No. If you have some expectations about what the slave should be sending, you can check the data. In particular, if you know that it won't send 0x00 [0xFF], you can put a pulldown [pullup] on MISO to detect whether it is connected.

    SPI receives a byte implicitly (simultaneously) for each transmitted byte. It is unusual (though possible) for the first receive byte from the slave to have any meaning at all, since it doesn't know yet what the master is asking.

**Attention** This is a public forum