I used the xSemaphoreGiveFromISR function within software timer, while another task used xSemaphoreTake to acquire this semaphore. As a result, the system crashed after running for a period of time. Although FreeRTOS clearly states that the xSemaphoreGiveFromISR function needs to be used in an interrupt context, why does using xSemaphoreGiveFromISR within a task lead to system crashed ?
Can you step through the xSemaphoreGiveFromISR code with a debugger to see where it crashes ?
xSemaphoreGiveFromISR is specifically designed to be used from interrupt service routines (ISRs) where context switching is not permitted. When called from an ISR, it performs the necessary operations to give the semaphore without triggering a context switch.
When xSemaphoreGiveFromISR is called from a task, it attempts to give the semaphore without considering the possibility of a context switch. This can potentially lead to a situation where a higher-priority task is made ready to run, but the context switch is not performed, violating the scheduling rules.
The FreeRTOS kernel maintains internal data structures and state information to manage tasks, semaphores, and other kernel objects. When xSemaphoreGiveFromISR is called from a task context, it may not properly handle these data structures, leading to potential corruption or inconsistencies.
Hope this clarifies your question 
3 Likes
As has been said, the FromISR routines are designed to be called only from an ISR. There is also a mention that they can be called from within a critical section (as that has a similar enough environment to an ISR, as it can’t be interrupted). One important thing to be considered is which port you are using, my guess is this is a Xylinx port with an Arm Cortex A series processor. Many of these (not sure about the Xylinx one) by default don’t support interrupt nesting as that depends on the particulars of the interrupt controller. Without interrupt nesting, the FromISR routines need no critical sections within them, and they “know” they will run undisturbed, which is not the case of code at the task level outside a critical section, so using them can easily lead to race conditions that break them.
1 Like