- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the following interrupt handler, I hit the halt in Line 43 because I'm getting the not-empty interrupt yet the FIFO is empty. Anybody know what's going on here? (This is usually after I've received one byte, and as you can see in the code, I do clear the interrupt)
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
As it is mentioned in the Architecture TRM (SCB Interrupts):
Note that certain interrupt sources are triggered again as long as the condition is met even if the interrupt source was cleared. For example, the TX_FIFO_EMPTY is set as long as the transmit FIFO is empty even if the interrupt source is cleared.
This seems to be true for your code, I can't tell for certain, as it is blackened.
- You clear the interrupt.
- The condition is still present.
- I can only assume there is a delay in the blackened part, so the interrupt is set again and the interrupt is triggered again.
- You clear the FIFO by reading it.
- You leave the ISR.
- But because the Interrupt is already set again, you will enter the ISR a second time.
- This time with an empty FIFO, so you enter the fault condition.
The example is working, because there is a 2 cycle synchronisation (https://www.cypress.com/documentation/application-notes/an217666-psoc-6-mcu-interrupts Ch 5.2) delay between the SCB and NVIC, what is enough to clear the interrupt condition by reading the FIFO.
I don't think this is ideal and the interrupt condition should be resolved before clearing the interrupt flag.
regards,
Achim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I think the problem is, that you clear the interrupt while there is still data in the FIFO. This should cause the interrupt to trigger again right after it was cleared. So after you exit the interrupt Handler it will be called a second time and the error condition should be in this second pass, as the FIFO was cleared before.
Try to clear the flag after you have red the data in the RxFifo.
regards,
Achim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So you're saying that the Cypress example code in CE219656 is wrong?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, for me that is at least a possibility.
It might work in the example, because the instructions are put there directly after each other.
In your code there might be a delay (blackened) and this difference is enough, so the interrupt flag is set again in your case and not in the example.
That is something I have seen on other MCUs in the past.
Achim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, from your profile picture I thought you were a Cypress representative. I'll wait to see what Cypress has to say about it. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am working for Cypress, but I am not going to say it is bugged unless I have double checked it
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Then it would be good to have a definitive answer instead of guessing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I have made modifications to the existing code example by adding your code for RxInterrupt and the code seems to be working for me. It is a simple loopback program.
If possible, please share your code or atleast a minimal version of the code where the issue exists so that we can debug the issue faster.
Also, are there any higher priority interrupts or any other function that reads the UART FIFO data? Are you facing the issue always after the first byte or is it happening randomly?
Regards
Harigovind
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't understand the experimenting and guessing. Is there nobody at Cypress who understands how the silicon works and can address this definitively?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
As it is mentioned in the Architecture TRM (SCB Interrupts):
Note that certain interrupt sources are triggered again as long as the condition is met even if the interrupt source was cleared. For example, the TX_FIFO_EMPTY is set as long as the transmit FIFO is empty even if the interrupt source is cleared.
This seems to be true for your code, I can't tell for certain, as it is blackened.
- You clear the interrupt.
- The condition is still present.
- I can only assume there is a delay in the blackened part, so the interrupt is set again and the interrupt is triggered again.
- You clear the FIFO by reading it.
- You leave the ISR.
- But because the Interrupt is already set again, you will enter the ISR a second time.
- This time with an empty FIFO, so you enter the fault condition.
The example is working, because there is a 2 cycle synchronisation (https://www.cypress.com/documentation/application-notes/an217666-psoc-6-mcu-interrupts Ch 5.2) delay between the SCB and NVIC, what is enough to clear the interrupt condition by reading the FIFO.
I don't think this is ideal and the interrupt condition should be resolved before clearing the interrupt flag.
regards,
Achim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh, I had already marked that last response as the correct answer but somehow it became unmarked. All good now, thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My apologies. Someone escalated this to me internally, so I wasn't sure if it was supposed to be marked correct (thought our team might have done so).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No problem. I had sought additional help when the only responses were guesses, before that last response was added. Thanks for looking into it.