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.

CCS/TMS320F28379D: Bytes in the SPI buffer are randomly shifted

Part Number: TMS320F28379D

Tool/software: Code Composer Studio

I used TMS320F28379D processor as a slave in an SPI communication. I would like to transfer 6*16 bits from the master (it is an ARM controller) at high clock speed (minimum 8-10 MHz, the LSPCLK is set to 200 MHz)

At certain times the ARM controller initialize the communication by the CS and send the 6*16 bits data. In the DSP I use a RX FIFO interrupt based on RXFFIL match (greater than or equal to).

My problem is that, the order of the bytes data becomes shifted as following:

The data to be send is (byte-by-byte) = 1 2 3 4 5 6 7 8 9 10 11 12

The data that is put on the MISO is =    1 2 3 4 5 6 7 8 5   4  11 10 or sometimes: = 1 2 3 4 5 6 7 8 7   6   9  8

So if I send only 4*16 bits it works, but if I increase the length of the data the order of the bytes are randomly shifted. 

Could you suggest the reason for this one and give some advice how to solve it? (Of course I can send the data in two packages, but I would like to do it in one shot to reduce the time and theoretically the DSP supports it)

Here is my init function:

void spi_initSlave()
{
SpibRegs.SPICCR.bit.SPISWRESET = 0; //reset SPI before initialization
SpibRegs.SPICCR.bit.SPICHAR = 0xF; //16-bit word
SpibRegs.SPICTL.bit.MASTER_SLAVE =0; //Enable slave mode, normal phase,
SpibRegs.SPICTL.bit.TALK =1; //transmit enable
SpibRegs.SPICTL.bit.SPIINTENA = 1; //SPI interrupt enable
SpibRegs.SPIPRI.bit.STEINV = 1; //SPISTE is active high (inverted)
EALLOW;
CpuSysRegs.PCLKCR8.bit.SPI_B = 1;
EDIS;

SpibRegs.SPIBRR.bit.SPI_BIT_RATE = 0x3;

//The SPI is a slave, the module receives a clock on the SPICLK pin from the master.

//Therefore, these bits have no effect on the SPICLK signal. The frequency of the input

//clock from the master should not exceed the slave SPI's LSPCLK signal divided by 4.


SpibRegs.SPICTL.bit.CLK_PHASE=0; //Rising edge without delay
SpibRegs.SPICCR.bit.CLKPOLARITY = 0;
SpibRegs.SPIFFTX.bit.SPIFFENA = 1; //SPI FIFO enhancements are enabled
SpibRegs.SPICCR.bit.HS_MODE = 1; //enable High Speed Mode (the high speed mode pins should be used)

SpibRegs.SPIPRI.bit.FREE = 1; // Set so breakpoints don't disturb xmission
SpibRegs.SPIFFRX.bit.RXFFIENA = 1; //RX FIFO interrupt based on RXFFIL match (greater than or equal to) will be enabled.
SpibRegs.SPIFFRX.bit.RXFFIL = 6; //6*16bit
SpibRegs.SPIFFCT.bit.TXDLY = 0;
SpibRegs.SPIFFRX.bit.RXFIFORESET =1; //RX fifo reset
SpibRegs.SPIFFRX.bit.RXFFINTCLR=1; // Clear Interrupt flag
SpibRegs.SPIFFTX.bit.TXFIFO = 1; //Reset transmit fifo
SpibRegs.SPIFFCT.bit.TXDLY = 0;
SpibRegs.SPICCR.bit.SPISWRESET = 1;
}

  • Are you observing the data on the MISO line using a logic analyzer or oscilloscope? I just want to confirm that it's definitely the send that's going wrong and not the way it's being received on the ARM.

    Can you tell me more about the transmit scheme and the timing of when you're filling the TXFIFO? Since the F2837xD is the slave device, I want to make sure that the master isn't kicking off a transmission before the TXFIFO is ready for it.

    Whitney
  • Dear Whitney!

    Thank you for your answer. The issue was that,  it is crucial to read back all the data from the SPIRXBUF. Otherwise we will have data shift. Now everything works as it should.