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

F28035 SPI RX Interrupt problem

mosin
Expert 1160 points

Hi,

I have a F28035 configured as a slave on SPI B with RX interrupts enabled. Most of the time, everyting is going well but sometimes, I'm able to freeze it. By freeze, I mean that RX interrupt isn't serviced anymore. Here's the SPIFFRX register value :

SPIFFRX.RXFFIL = 2
SPIFFRX.RXFFIENA = 1
SPIFFRX.RXFFINTCLR = 0
SPIFFRX.RXFFINT = 1
SPIFFRX.RXFFST = 4
SPIFFRX.RXFIFORESET = 1
SPIFFRX.RXFFOVFCLR = 0
SPIFFRX.RXFFOVF = 1

At the end of the interrupt handler, I call this :

SPIFFRX.bit.RXFFOVFCLR = 1;
SPIFFRX.bit.RXFFINTCLR = 1;
PieCtrlRegs.PIEACK.all |= PIEACK_GROUP6;

Beside this interrupt, I have some external interrupts that aren't flagged. I don't understand why the ISR isn't getting called. Also, I can see I'm still receiving what the SPI master is sending in SPIRXBUF. 

Is there something I could check to figure out what my code is missing to handle this case?

Best regards,

  • 0
    Guru 192875 points

    Hi Mosin,

    mosin said:
    I'm able to freeze it. By freeze, I mean that RX interrupt isn't serviced anymore.

    Is this behavior random or happens at a particular interval / frequency?

    Regards,

    Gautam

  • 0 in reply to Gautam Iyer
    Expert 1160 points

    Hi,

    I can't reproduce it easily so I'd say it's quite random. One of the thing I think it's related to is when I change the CLA task dynamically. The main thread gets "stuck" copying in RAM the new CLA task. This shouldn't block the interrupt to be serviced. The interrupt fills a FIFO that is emptied in the main thread so I get overflow in my FIFO when this happens. Other than losing data, it's not much of a problem. That's the only thing that comes to mind when I think about what could cause this. 

  • 0 in reply to mosin
    Expert 1160 points

    I've tested masking the SPI RX interrupt at run time to see if I could reproduce the problem. When the interrupt is masked, the SPI FIFO fills up and it overflows. As soon as I set the interrupt back, everything goes back to normal. Still no luck reproducing it for now...

  • 0 in reply to mosin
    Expert 1160 points

    Hi,

    I'm bumping my question again since I've encountered it once again and I can easily reproduce it. Let me explain the problem once again...

    I have two F28035.

    Master is transmitting 4 words each 25us at 7MBits/s.

    Slave uses the RXFIFO and interrupts are enabled for : RXFFIL = 2 and for RX overrun. 

    At some point, I never go in the RX interrupt again but I can see data coming in in SPIRXBUF. I know I'm not processing data coming in fast enough but I don't understand why the interrupt isn't triggered anymore. If I set the bit RXFFIENA to 0 and then to 1 again, SPI peripheral gets back on its feet even though it had overflowed considerably. So Here's the SPI interrupt:

    Slave SPI Interrupt

    const Uint16 data = g_sSpiMgr.spiRegs->SPIRXBUF;

spicommProcessReceivedData(data);
spicommUpdateTransmitFIFO();

g_sSpiMgr.spiRegs->SPISTS.bit.OVERRUN_FLAG = 1;
g_sSpiMgr.spiRegs->SPIFFRX.bit.RXFFOVFCLR = 1;
g_sSpiMgr.spiRegs->SPIFFRX.bit.RXFFINTCLR = 1;

PieCtrlRegs.PIEACK.all |= PIEACK_GROUP6;

    When the freeze happens, here are some SPI register values :

    SPIFFRX.bit.RXFFIENA = 1
SPIFFRX.bit.RXFFINTCLR = 0
SPIFFRX.bit.RXFFINT = 1
SPIFFRX.bit.RXFFST = 4
SPIFFRX.bit.RXFIFORESET = 1
SPIFFRX.bit.RXFFOVFCLR = 0
SPIFFRX.bit.RXFFOVF = 1

SPISTS.bit.BUFFULL_FLAG = 0
SPISTS.bit.INT_FLAG = 0
SPISTS.bit.OVERRUN_FLAG = 0

PIEIER6.bit.INTx3 = 1
PIEIFR6.bit.INTx3 = 0

    To succesfully get the SPI on track, I found out that a couple of things can do it :

    Set PIEIFR6.bit.INTx3 to 1   ---> SPI interrupt will run for a while and handle between 400 to 3000 words

    Toggling SPIFFRX.bit.RXFFIENA to 0 and then to 1    --> Same, it will go for a couple of words

    Toggling SPIFFRX.bit.RXFIFORESET to 0 and then to 1    ----> Same

    If I initialize the SPIFFRX.bit.RXFFIL to 1 instead of 2, my communication is running smoothly. I know at 2 it means I can't process everything but my concern is really to understand why it stops being interrupted.

    Any help will be appreciated.