Illegal call to xTaskGetTickCountFromISR from ISR

Kernel
1

I am running FreeRTOS 9.0.0 on an STM32L1. I have unit that has been returned from the field for a lockup and have hot-connected over JTAG and I see that it is stuck in xTaskGetTickCountFromISR().

I am familiar with the potential problem here with the ISR in question making the system call with too high of a priority.

However, when looking at IABR0 and IABR1, both are set to 0, indicating that no interrupt is active. I do see that there is one EXT interrupt that is configured at priority 1 (same as configMAX_SYSCALL_INTERRUPT_PRIORITY) and does make this system call, apparently illegally, but it this doesn’t make sense to me because I would expect this assert to be hit much more frequently. Being somewhat unfamiliar with the codebase, I would like to make sure that I am 100% sure of the root cause.

  1. Any idea why we would hit this fault if the NVIC reg is indicating no interrupt is active? (although several are pending)
  2. Any other way I could determine for sure who called this system call?
2

If the code runs on all devices except this one, why do you suspect a software issue (rather than a hardware issue)?

If configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 1, then that is probably your issue, as it should be shifted up into the most significant bits as described here. Setting a priority of 1 has the top byte cleared to zero, which means the interrupt priority is 0, which on an STM32 is the highest priority available. If you run FreeRTOS V10 with configASSERT() defined then it should trap any incorrect interrupt priority assignment.

Is the code in a configASSERT() handler, or in an exception handler? If its a configASSERT() then I would expect it to enter the assert every time xTaskgetTickCountFromISR() got called from that ISR. If it is an exception handler then the information here may help.