• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 1673 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

F28069: SPI FIFO - RX FIFO is not updated when RX ISR is called

Vishwanatha Manevarthe
Expert 1080 points


Hello,
I have configured [TXFFIL = 0], [RXFFIL = 1]. I copy 4 words every time TX ISR is called.
I have also enabled the RX interrupt to capture this, as shown here:
interrupt void SPI_Rx_SPIA(void)
{
    Uint16 LoopCount;
    Uint16 RxFifoCount;
    
    RxFifoCount = SpiaRegs.SPIFFRX.bit.RXFFST;
    
    for(LoopCount=0; LoopCount < RxFifoCount; LoopCount++)
    {
        DestBuff[RxDataCount++] = SpiaRegs.SPIRXBUF;
    }
    
    SpiaRegs.SPIFFRX.bit.RXFFOVFCLR=1;  
    SpiaRegs.SPIFFRX.bit.RXFFINTCLR=1;  
    PieCtrlRegs.PIEACK.all |= 0x20;       
}

The problem I am facing is this:
when I step into the code by having breakpoint at "RxFifoCount = SpiaRegs.SPIFFRX.bit.RXFFST;", reception works
properly. But if I keep breakpoint at any other line after this, RxFifoCount is different what is in RXFFST
(in fact, it is always 1). i.e., RXFFST shows 4 (as I transmit 4 words) but RxFifoCount gets 1.
In otherwords, I always loose 3 bytes when the entire reception is over.
If I add delay code before reading RXFFST, RxFifoCount is updated with correct value of RXFFST;
but by that time, first 4 words are lost (at the end of reception, a difference of 4 words exists between the
expected receive words and actual received words).

Is this a common behaviour due to FIFO design? Or have I missed any configuration?

thank you,

Vishwanatha

  • 0
    Expert 1080 points

    Hello,

    any help?

    thank you,

    Vishwanatha

  • 0 in reply to Vishwanatha Manevarthe
    TI__Genius 15260 points

    Vishwanatha,

    I believe this is due to the way the pipeline operates with respect to a breakpoint.  When you set the breakpoint at the line where you read the status register, the rest of the incoming data has time to propagate into the FIFO while the emulation is halted.  If you looked at the status register in the watch window prior to stepping into this instruction when you reach the breakpoint, I wouldn't be surprised if it showed a '1' there and then a '4' after you refreshed.  Not entirely sure about this.

    The '1' is expected because this is what you are setting your interrupt level to.  So in other words, this ISR fires after your FIFO has 1 word in it.  Depending on what the CPU is doing when this level is reached, it could be more than 1, but it will most commonly read 1.  So I would expect you are not losing data, but it will be read again in the next ISR.

    Kris

  • 0 in reply to Kris Parrent
    Expert 1080 points

    Kris,

    thank you for the insight.

    I'll check this again and update.

    Vishwanatha

  • 0 in reply to Vishwanatha Manevarthe
    TI__Genius 15260 points

    Another possible source of the discrepancy is the configuration of the FREE / SOFT bits which control what the SPI does on an emulation halt.  If you have both SPIs setup to continue operation during emulation halt, this would also explain the behavior.

    Kris