• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 670 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.

Unexpected delay of the SPI TXFFST value

Markus Schroeder
Prodigy 180 points
Other Parts Discussed in Thread: TMS320F28069

Hello together,

I am using the SPI module of the TMS320F28069 to communicate with an FRAM device. I don't use the interrupt functionality.

Into that FRAM I can send long data streams without any break, so I want to send one message after the other without the chip-select going high again.

I use the 4 stage buffer mechanism and additionally I write only transmit data into that buffer when there is space, see the follwing code:

  const uint16_t maximumFifoSize = 4U;

  while(maximumFifoSize == SpiaRegs.SPIFFTX.bit.TXFFST)
  {
    // wait until there is place in the transmit FIFO
    // TODO: timeout check
  }

  SpiaRegs.SPITXBUF = dataToTransmit;

This seems to work as expected until several bytes are sent. The first 5 bytes get into the buffer directly without any waiting time. The next 4 Bytes get a bit delayed into the buffer,
since each of them has to wait until a byte gets completely transmitted on the bus.

But now comes the unexpected behaviour, the next byte gets written into the buffer much later then the others, it will get written when the complete data is sent on the bus and even some time later.
All interrupts are turned off. I set a GPIO to high directly before the above described while loop and set it to low afterwards in order to see the timing on the scope. So it seems, that the TXFFST bits are not
changing, even the transmit buffer gets more and more empty.

On the following scope-screenshot you can see all the described behavior.

D3 you can ignore, it would be the received data

D4 is the pin-toggle before and after the while loop, in the zoomed part below you can see clearly, that the first 5 data values get written into the buffer instantly and the next 4 are waiting, the long one afterward is unexpected to me.

D2 is the sent data to the FRAM on the SPI MOSI.

D1 is the CLK signal of the SPI.

D0 is the chip-select. This also causes an issue in my application, since the FRAM interpretes everything within a chip-select cycle as a complete instruction.

The transmit FIFO delay bits in the SPIFFCT register are all set to 0 as well.

I hope somebody can help me and tell me why there is this delay in the TXFFST value and how I can avoid it, or if there is another way to write continuous data on the SPI bus.

Best regards,
Markus

  • 0
    Expert 1725 points

    Hi,

    Well that's strange. I've never seen this. And your CS goes high which would indicate your SPI has "completed" your transmission and starts a new one. Could you try this by using the SpiaRegs.SPISTS.bit.BUFFULL_FLAG instead of the compare and add a NOP(); or something within your while loop.

    Or something like:

    int i,MaxData;

i=0;

MaxData=8;

do{

while( SpiaRegs.SPISTS.bit.BUFFULL_FLAG)
  {      NOP();
  }
SpiaRegs.SPITXBUF = dataToTransmit[ i++ ];

}while(i<MaxData);

    I assume you've configured your SPI properly with FIFO options enabled AND used the EALLOW; EDIS; permissions?

  • 0 in reply to Tjarco Boerkoel
    Prodigy 180 points

    Hi Tjarco,

    thank you for your quick reply.

    I double checked my project again, so I figured out, there was still an interrupt source running (I remembered I disabled it, but unfortunately I turned it on again later, since I needed it as a trigger).

    I am sorry for the confusion. After changing the interrupt timing it is now working.

    The BUFFULL_FLAG I tried as well in the meantime, but that seemed it would read 0 even the buffer has no place, so I lost data. Anyway I know now what my problem was and can use my former approach.