• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 81 subscribers
  • Views 699 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.

TMS320F280045: DSP RXFFOVF set in FIFO mode

Omar Solis
Prodigy 140 points
Part Number: TMS320F280045


We are having an issue with SPI where we get an overflow error. We are using controller TMS570LS0332 to communicate using Mibspi and we configured the master as follows:

// WDELAY = 0 -> Wait Delay = (0+2)Vclk = 25 nsec
// PARPOL = even
// PARITYENA = disabled
// WAITENA = disabled
// SHIFTDIR = MSB first
// POLARITY = SPI CLK low inactive
// PHASE = no SPI CLK delay
// PRESCALE = 39 -> baud = Vclk/(39+1) = 2.0 MHz
// CHARLEN = 16 bits

In the technical reference manual of the TMS320F280045 in register SPIFFRX there is the description of RXFFOVF field (It should be set if "More than16 words have been received in to the FIFO"). Our SPI in the DSP controller uses the same configuration for the word format of Master SPI and FIFO mode active to receive 16 chars of 16 bits. If we receive the data without considering this error we see that what we send in master is correctly received in slave, we also checked with the oscilloscope and the amount of characters, clock cycles and everything seems correct. However, we are getting this RXFFOVF error flag set. Under what conditions would this error be set?

  • 0
    TI__Guru 55700 points

    Omar,

    In F280045, SPI has 16 level deep RX FIFO buffer. When SPI RX FIFO overflows, then SPIFFRX.RXFFOVF bit will be set.

    1. Do you have SPI loopback option enabled? If so, you need to disable this mode.
    2. On SPIRXFIFO interrupt, are making sure to read all the FIFO contents and making sure SPIRX FIFO is empty. If not, on your next SPIRXFF interrupt cycle, you will have new 16 words + old SPI data in FIFO buffer. This will lead to overflow condition.

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    TI__Guru 55700 points

    Is this issue resolved? Can I close this thread?

    -Manoj

  • 0 in reply to Manoj Santha Mohan
    Prodigy 140 points

    Hi Manoj,

    Sorry for taking long responding, I have not had the time to check this by now,

    We don't have loopback enabled. WE DON'T USE INTERRUPTS, I need to remark this because want to avoid being referred to interrupt examples.

    What we are doing is to fill the TX buffer once then check at a rate of 512 Hz if a master SPI message has been received. The master SPI will communicate at a rate of 256 Hz, so the slave will fill the buffer always before the master sends the message and the slave will fill the buffer again after detecting a master message has been received, seems to me there is no way of desynchronization.

    We always read the max amount of bytes we send, which is 16 half words (16 bits each, 32 bytes), if we ignore the SPIFFRX.RXFFOVF error, the data we send in master is correct is exactly what we sent, still the flag is set. Looks like there is lack of information we still don't know what else could be causing this flag being set. We even checked with the oscilloscope and the amount of bytes is exactly 32.

    Thanks,

    Omar

  • 0 in reply to Omar Solis
    TI__Guru 55700 points

    Omar,

    I don't have enough information to understand what is going wrong here. Did you try reducing the FIFO level to say 8 words and see whether you are receiving extra words?

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    Prodigy 140 points

    Manoj,

    we finally found what was the issue, it seems like having the slave buffer update at twice the master task speed is not enough, there is some sort of desynchronization that will make the master read the slave buffer before it finishes filling it, thus data gets corrupted, we solved just by increasing the slave update speed. As this issue would happen some times we would not see it just by checking the OSC or setting a BP in the place we receive data, wasn't that easy to catch.

    Thanks for your time and collaboration,

    Omar