TMS320F28375S: C2000 microcontrollers forum

It's difficult to tell from this limited information. Have you used CCS to debug the problem? I would suggest taking a look at the SPI status registers for signs of activity.

I know it is difficult to find the SPI interrupt stopped issue. We had checked the SPI registers at CCS when the SPI RX interrupt stopped.

The registers are the same as we set.

Is there possible that other SCI interrupt will stop the SPI RX interrupt? We can see the hardware signal is inputed into CPU. The SPI RX ISR is NOT triggered.

Eddie

SPI interrupts have higher priority than SCI interrupts. However, this only applies in the case both interrupts are pending at the same time. By default, there is no interrupt nesting on C2000 devices. Could it be possible that the CPU is stuck in your SCI ISR and not servicing the SPI interrupts? You can do a simple test: set and clear a GPIO in your SCI ISR and verify with a scope if that ISR is taking up all CPU bandwidth. 

We trigger the SCI communiction manually. So, it should NOT occupy all bandwidth. When the SPI interrupt stops, we still can trigger the SCI communication. We will investage  how much time the SCI communication costs. 

Is it possilbe that costs too much time in SCI then the SPI RX interrupt stops?

Eddie 

Eddie,

What is the content of the SPI status registers? Specifically the SPISTS and SPIFFRX register when the issue happens? You can also check the PIEIER6 and PIEIFR6 to see if the SPI interrupts are enabled and pending to the CPU. 

I review the code and found there is SCI TX function in  SCI RX ISR. I remove the TX function from SCI RX ISR. Then, the SPI RX ISR works well.

Is it the root casue?

Eddie 

Is the SCI RX ISR provided by TI or is it a custom code? What does this SCI TX function do, exactly?

We write the SCI RX ISR and it sends some message out. Now, we move the "send out message" code to main loop.

Now, we are testing this new program. 

Eddie

Understood.