Can't xSemaphoreGiveFromISR() during HW timer - polling task faster than FreeRTOS tick allows

Could the interrupt rate be faster than expected. If the call stack doesn’t change after running and pausing again, then that indicates that you are getting another interrupt before this one finishes.

Okay, but if I get another interrupt, with an IRQ priority > GPT2’s, wouldn’t the ISR of this new interrupt execute first, and then return to GPT2_IRQHandler()?

well, in your CAN_TX_BP_task, is it intended that you ignore the return value of the semaphore take (timeout passed in!) and do the CAN transmit regardless of the condition? ALWAYS check the return values in such cases…

Aboutr yur most recent question: The Cortex M kernel supportas something called tail chaining, so if ISR overlap, there is no return/restack. I don’t know if that has any impact on your issue as the question is a little unclear.

Please be aware that your call stacks may be mischieving. There are many optimazations that may make the call stack look different that it really is.

Hi @RAc

Thanks for yet another reply!
I would like the CAN_TX_BP_Task to execute continually, with a worst-case period of 100 ticks.
If the interrupt that gives xsemphr_TX_BP occurs, I want CAN_TX_BP_Task to execute immediately.
This way I ensure that my CAN communication buffers are updated instantly when an interrupt is received, and that they are also cleared once every 100ms (in case the CAN bus goes into an error state).
I believe that I have no use of the the returned value of pdTRUE or pdFALSE.
Am I using xSemaphoreTake() correctly for this functionality?

Thank you for your mention of tail-chaining.
I looked up an explanation and now I am better informed.

Do you believe that tail-chaining could cause the debugger’s call stack to be incorrect, in my case?

Possibly. There’s also tail recursion optimizations, code inlining and other interesting features in the Cortex world that make debugging cumbersome at times. Your best bet wuld be a deep trace, but few debugging systems support that.

Also, interrupts execute on a different stack than the current application. Some debuggers can detect that, switch SPs and thus display “the full call stack history,” but in my experience that doesn’t work reliabl.e either.

1 Like