SPI Slave Interrupt not clearing properly.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I am attempting to set up an SPI slave with an interrupt triggered at rx FIFO greater than 2. I am using StartEx to create my own ISR in main. I configured the interrupt source through TopDesign. When the ISR is entered I have verified that there are indeed 3 bytes in the rx buffer. I go into this loop to read in the data.

   

 

   

while (0u != SPIS_SpiUartGetRxBufferSize())
    {
        rx_buffer[rx_location] = SPIS_SpiUartReadRxData();
        rx_location++;
    }

   

Then I use SPIS_SpiUartClearRxBuffer to ensure that the interrupt source is cleared as detailed in the interrupt documentation. I then set a flag to indicate back to the main function new data is available. Finally, before leaving the ISR I call SPI_ISR_ClearPending to be sure that everything is cleared. 

   

 

   

As I understand it between the SPIS_SpiUartClearRxBuffer and SPI_ISR_ClearPending I should have cleared all the sources for the interrupt and allowed myself to exit. However I never do exit the ISR.

   

 

   

What could be holding me there?

0 Likes
1 Solution
Anonymous
Not applicable

@ e.pratt_1639216

   

You are correct. The hardware trigger must be cleared by reading the data or clearing the buffer. Otherwise the interrupt will continue to trigger.

View solution in original post

0 Likes
6 Replies
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

How do you determine that you never exit the ISR? Or is it just that it re-enters again (e.g. because there is new data)?

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Do you call SPIS_ClearRxInterruptSource()?

0 Likes
Anonymous
Not applicable

I have another microcontroller operating as the master. On startup it sends a known data packet. The ISR triggers and I have verified that it properly receives the packet. The intended function is for the ISR to put the data into a buffer and then set a flag. The flag is checked in a while 1 in main. If the flag is true it parses the packet and signals the master that it successfully received the packet. The signaling is done by pulling a pin low which the master is monitoring. When the master detects the pin is low it starts a new transaction. Thus in correct operation this should be an endless cycle. I have verified that all of these things work except the interrupt for the cypress RX ISR. I checked all other functionality by running the cypress spi in a polled mode where I manually checked the RXFIFO level. In this setup all systems worked as intended and the data continuously cycled. I say all this to show that the transaction only occurs once. No new data is being shifted into the rx buffer after the first entrance into the isr because it never signals for a new transaction. I have verified all this with a logic analyzer as well. I have also verified that it does leave the ISR and then immediately returns. It never executes anything outside the ISR again. 

   

 

   

No. I was not aware of that #define. Maybe in reading through the documentation I missed something, but I've never seen that referenced anywhere else. It was just buried in a sea of #defines. However, that was the key to fixing the ISR. I'll remember that from now on when using the SCBs.

   

 

   

Thanks hli.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Its mentioned in the _common_ API definition for the SCB component (but not in the SPI section). Its easy to overlook.

0 Likes
Anonymous
Not applicable

I'm not sure if you are still working on the issue, but I believe in order to clear the FIFO above x bytes, you have to actively read the byes to clear the interrupt; Just clearing the flag and leaving the ISR will immediately set the flag again, as the FIFO is still technically above x bytes. The flag is hardware/peripheral set, and thus asynchronously sets the interrupt flag whenever the FIFO contains x number of bytes regardless of whether the ISR or the corresponding flags have been set/cleared.

0 Likes
Anonymous
Not applicable

@ e.pratt_1639216

   

You are correct. The hardware trigger must be cleared by reading the data or clearing the buffer. Otherwise the interrupt will continue to trigger.

0 Likes