- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you call SPIS_ClearRxInterruptSource()?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Its mentioned in the _common_ API definition for the SCB component (but not in the SPI section). Its easy to overlook.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ 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.