UART "RX FIFO not empty" IRQ when the FIFO is empty

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

cross mob
euggersh
Level 5
Level 5
5 sign-ins First solution authored 50 replies posted

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)

pastedImage_0.png

0 Likes
1 Solution

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

View solution in original post

13 Replies
AchimE_41
Employee
Employee
10 sign-ins 5 sign-ins First comment on KBA

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

0 Likes

So you're saying that the Cypress example code in CE219656 is wrong?

pastedImage_0.png

0 Likes

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

0 Likes

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.

0 Likes

I am working for Cypress, but I am not going to say it is bugged unless I have double checked it

0 Likes

Then it would be good to have a definitive answer instead of guessing.

0 Likes
lock attach
Attachments are accessible only for community members.
Hari
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

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

0 Likes
euggersh
Level 5
Level 5
5 sign-ins First solution authored 50 replies posted

I don't understand the experimenting and guessing.  Is there nobody at Cypress who understands how the silicon works and can address this definitively?

0 Likes

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

user_362267832

Does this help?  Do you need further clarification?

0 Likes

Oh, I had already marked that last response as the correct answer but somehow it became unmarked.  All good now, thanks.

0 Likes
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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).

No problem.  I had sought additional help when the only responses were guesses, before that last response was added.  Thanks for looking into it.

0 Likes