I’m having an issue resolving a problem with an ISR using FreeRTOS 10.2.1 on an STM32F7 chip. The ISR is a straightforward process to take an incoming CAN message and put it onto a Queue using
xQueueSendFromISR(). The problem I’m having is that making any change (both adding or commenting out application code) to a number of RTOS tasks in the system, even if they are unrelated to this ISR (this also includes some tasks that are suspended at the point I expect the interrupt to fire) causes the ISR to stop running entirely. I have another ISR that continues to work correctly throughout testing this issue (EXTI interrupts which also send data to a different queue). Here’s the list of things I’ve tested so far:
- I have verified the bus integrity using both an external CAN-sniffer on the testing code and by reverting the changes to the last stable release.
- I verified that the ISR does not run at all with both a debug breakpoint and using an onboard debug LED toggle
- I ran a quick timing check with Tracealyzer to see if there were any events on the queue or something else pre-empting the ISR somehow
- I checked the
uxTaskGetHighWaterMark()using method 2 on each of the relevant tasks (each task had at least 80 bytes of the default 256 free), as well as the overall available heap memory
- I verified the interrupt priority was not higher than the
configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY- both are set to equal at 5, and additionally I tried decreasing the ISR priority (by raising the NVIC priority to 6)
- I also tried changing the NVIC priority of the other working interrupt to 6 (both together with the broken ISR and separately)
Now the one part I have suspicion about with this ISR compared to the other is the way we enable it. In the current working code, we use a call to a
startCAN() function which is called at the end of
FreeRTOS_Init(). This function activates the various Notifications provided in the CAN HAL, sets up the CAN filter and calls the actual
HAL_CAN_Start() function. I found that moving this to before the RTOS scheduler starts (but after the peripheral details are configured), also causes the same issue as described above. This includes adding a
taskENTER_CRITICAL() section around this function to avoid issues with changing the enabled ISRs. This might just be a red herring, but it stuck out to me as something unique about the specific problem ISR.
At this point I’m both out of my depth as a junior engineer and out of ideas on what to try next - does anyone have any thoughts on what else could be causing this and/or tests for me to try?