cancel
Showing results for 
Search instead for 
Did you mean: 

Occasionally Missing Interrupts

alanrouse9
Associate II
Posted on September 07, 2015 at 13:44

I have an STM32 system that works correctly most of the time but occasionally fails to service interrupts. I wonder if there is something I am missing in my understanding of the NVIC:

The system is built around FreeRTOS and uses, among other things, three USART’s and a real time clock. The RTC produces a one second tick on GPIO input E1 which is configured to generate the EXTI1 interrupt. I have proved that the system sometimes misses this interrupt, and I suspect that it sometimes also misses USART interrupts:

The EXTI1 interrupt service routine simply gives an RTOS semaphore:

xSemaphoreGiveFromISR(System.Semaphore.SecondTick, &xHigherPriorityTaskWoken)

One of the FreeRTOS tasks waits for this semaphore, but times out if it is not received within 1.02 seconds:

if (xSemaphoreTake(System.Semaphore.SecondTick, 1020) == pdFAIL){
.
.
} else {
.
.
}

This should obviously never fail, but occasionally it does.

If I run the system through a debugger (OpenOCD) and pause it at random times I often see that the EXTIPR and the NVIC ISPR registers both indicate that the EXTI1 interrupt is pending. I would expect any pending interrupt to be handled immediately and cleared by the ISR. The only reason I can imagine why this is not happening is if the interrupt is disabled.

As far as I can see the only mechanism for disabling interrupts is to set BASEPRI to a value numerically lower than the priority of the interrupt. SCB AIRCR PRIGROUP is set to 3 (i.e. 16 group priority levels, no sub-priorities) and the NVIC IPR for EXTI is set to 0x In FreeRTOSconfig.h the value for

configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 0x

According to my understanding FreeRTOS sets BASEPRI to configMAX_SYSCALL_INTERRUPT_PRIORITY when it is executing a task that can’t be interrupted and 0 at all other times

. I don’t believe that I can monitor BASEPRI directly. However, I think FreeRTOS copies it to pxCurrentTCB->uxBasePriority, and whenever I pause the debugger this reads 0.

Can anyone give any suggestions why the interrupts are failing?

#interrupts
1 REPLY 1
jpeacock
Associate II
Posted on September 08, 2015 at 19:57

You might try one interrupt at a time to see if there are bugs in your logic.  Do you nest interrupts and do you have enough stack space (look at MSP) for it?  Do any of your interrupt routines have spinlocks (loop polling a flag) or other types of loops (that's a very, very bad practice leading to precisely what you describe)?  Do you have enough CPU time to handle all interrupts?

  Jack Peacock