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.

TMS320F28379D: SPI corrupted receiving Data.

Part Number: TMS320F28379D

Hello,

I have a curious behavior using SPI peripheral in TMS320F28379D.

I am using RX interrupt with 16 FIFO and 16 bytes.

The RX ISR trigger  is triggered, in this interrupt, I read the 16 words FIFO, and I send it back,

The first word of the writing back data set to '0', even the first 16 words sent are all 0x00FE

Could you please explain to me why the first word is 0?

I am using SPI A and SPI B with an external connection.

Thank you in advance,

S.Tarik,

  • Hello again S.Tarik,

    It looks like the master SPI is generating back-to-back transfers and slave SPI TX FIFO is not loaded in time. In this case, the slave SPI will just end up shifting out whatever is in the SPIDAT register. 

    I would suggest maybe using a FIFO level of 8. This way, the slave SPI generates an RX interrupt after 8 characters, and the CPU on the slave side has 8 character times to copy that data to the slave TX FIFO. Note that here there is still a good chance the slave SPI will send a 0x00 for the first character followed by the 8 real characters since we don't really solve that race condition at the beginning, but subsequent character transfers should be ok. 

    EDIT: Clarified my response a bit more.

  • Hello Gus, 

    Thank you for your answer,

    Gus Martinez said:
    It looks like the master SPI is generating back-to-back transfers and slave SPI TX FIFO is not loaded in time

    I couldn't understand this, could clarify please back-to-back transfers.

    Effectively, this is what happens, the first character is wrong and the others are okay,

    Gus Martinez said:
    Note that here there is still a good chance the slave SPI will send a 0x00 for the first character followed by the 8 real characters since we don't really solve that race condition at the beginning, but subsequent character transfers should be ok. 

    Do you have any errata documents for this, are you saying it is a common issue?
    No problem with editing, I take time to read your answers, 

    S.Tarik,

  • UserHomeInit said:
    I couldn't understand this, could clarify please back-to-back transfers.

    Back-to-back transfers means the master immediately starts the next transfer. 

    UserHomeInit said:
    Do you have any errata documents for this, are you saying it is a common issue?

    This is not a bug. It's just a fact of life with embedded systems. There are always deadlines to meet. 

    I have marked up your image. Maybe it'll help you understand my point a little clearer. 

    Note that when you set the RX FIFO level to 16, the SPI must fully receive 16 characters before it generates the RX interrupt. If you have the TX FIFO set to 16 as well, by then the TX FIFO is also empty. The CPU must then write at least one character to the TX FIFO *before* the master starts the next transfer. Otherwise the SPI will just shift out whatever it has in its buffer at that time. 

  • Some suggestions on how to deal with the race-condition below. I don't have the full details of what you are trying to accomplish, therefore I am not sure what works for you.

    - Add more time between SPI master transfers.

    - Optimize your slave SPI ISR. You want to make sure you write the next character to the slave SPI TX FIFO as soon as possible.

    - Slow down the SPI clock