UART interrupt issue

cancel
Showing results for 
Search instead for 
Did you mean: 

UART interrupt issue

Jump to solution
238 Views
Contributor II

I am facing a UART interrupt issue with my current setup which occurs not deterministically after a variable period of time.

My setup in detail:

  • LPC1768
  • FreeRTOS
  • 2 UARTs:
    • 1 UART incoming data with 200 Hz is copied within the ISR into a ringbuffer and processed within a task
    •  1 UART as console
  • Output over CAN

What happens (error description):
After an undefined period of time (between 30 minutes and several hours) the UART callback related to receiving data is not called anymore. As a result, it seems that no new data is avaiable as the ringbuffer head is not moved anymore. What I can see from the debugger is, that the program is still running. For data incoming with 100 Hz over UART, this issue seems not to occur.

Some things I already tried:

  • checked that the interrupt flag for receiving new data is still set
  • increased task stack sizes and ringbuffer size
  • compiled with -fstack-check to check for stack overflows
  • protected the ringbuffer with CRITICAL statements against reading and writing from the ISR and the task
  • checked the receiving data buffer: there is new data available (but the interrupt won't hit)

I am running out of ideas how to further deal with this. Any suggestions are appreciated.

Labels (1)
1 Solution
11 Views
NXP TechSupport
NXP TechSupport

Hi volkerweber‌,

If one of your interruptions happens to often, the lower priority interruption will never happen, I think that's why the UART lost in some point.

Have in count that the UART doesn't have recovery mechanism, like CAN that will repeat the transmission until some node sends an acknowledge. If you're receiving CAN transmission continuously the other interruptions will not trigger or will be pending until the higher priority interrupts are attended.

Best Regards,
Alexis Andalon

View solution in original post

7 Replies
11 Views
NXP TechSupport
NXP TechSupport

Hi volkerweber‌,

I've checked your implementation in general looks good. Since in the project it seems you use some custom drivers I can say its due to an error configuration.

But with the information you provide about the NVIC, I think it could be and error with sincronization from the two UARTs.

Could you check the ISPR bit from the UART1 interruption? If this is set, it means something happens that the interruption wasn't attended.

Let me know your findings.

Best Regards,

Alexis Andalon

11 Views
Contributor II

Hi nxf46116‌,

thanks for your input and I think I managed to get it to work. The application is now running over a day twice, which will not be a use case at all and as a result, I can mark it fixed "for me".

Besides the interrupts of the two UARTs (1) + (2) I have furthermore an interrupt for an input GPIO (3), an interrupt for a PWM (4) and the CAN interrupt which I mentioned above (5). What solved the issue here was changing the interrupt priorities via

NVIC_SetPriority(..., n).

In Detail:

Interruptpriority (erroneous case)priority (working case)
UART0_IRQn( 0x01<<3 ) | 0x01 = 914
UART1_IRQn514
EINT2_IRQn514
CAN_IRQn214
PWM1_IRQn( 0x01<<3 ) | 0x01 = 914

I do not use any priority grouping (pre-empting), however, I cannot explain why this (obviously) fixed my faulty application. Any idea?

0 Kudos
12 Views
NXP TechSupport
NXP TechSupport

Hi volkerweber‌,

If one of your interruptions happens to often, the lower priority interruption will never happen, I think that's why the UART lost in some point.

Have in count that the UART doesn't have recovery mechanism, like CAN that will repeat the transmission until some node sends an acknowledge. If you're receiving CAN transmission continuously the other interruptions will not trigger or will be pending until the higher priority interrupts are attended.

Best Regards,
Alexis Andalon

View solution in original post

11 Views
Contributor II

Hi nxf46116‌,

your explanation sounds reasonable and could be the root cause of my problem. Anyway, the changes in the priority levels have solved the issue for me. I will now keep in mind that choosing the priority levels of my interrupts is a crucial thing and that the UARTs need more attention towards this.

Thanks for your support Alexis, it was really appreciated.

Best regards,

Volker

0 Kudos
11 Views
Contributor II

Update: if I remove the terminal task from the application, the program apparently does not crash after a day of running. That seems weird as there is no action on this UART for the whole time. I keep investigating...

0 Kudos
11 Views
NXP TechSupport
NXP TechSupport

Dear volkerweber‌,

Can you let me know which UART (console or the ringbuffer) is the one that is not transmiting after sometime?

Also, as a suggestion, is important to use mutex to exclude the usage of the peripherals. Maybe you have a problem with this.

Best Regards,

Alexis Andalon

11 Views
Contributor II

Hi nxf46116,

thanks for your reply. Unfortunately, both UARTs stop working at the same time and both won't receive any interrupts anymore. Furthermore, I use a GPIO interrupt which also quits. 

Further investigation results:

  • if I remove the console task, the program seems not to crash (as mentioned above)
  • if I remove the preemption bits from any NVIC_SetPriority argument, only the console task and the GPIO interrupt stop working. UART1 (the serial interface for data communication) still works.

I attached my UART1 (data communication) implementation, could you please quick-check my UART initialization function (UART1_create)? Many thanks! 

0 Kudos