A. xSemaphoreGive() is not safe to call from an ISR
B. The semaphore is given twice accidentally
C. The ISR does not clear the interrupt flag
D. The task will never unblock
Solution
Step 1: Check function usage in ISR
xSemaphoreGive() is a task-level function and is not safe to call inside an ISR.
Step 2: Correct function to use
Inside ISR, xSemaphoreGiveFromISR() must be used to safely notify the task.
Final Answer:
xSemaphoreGive() is not safe to call from an ISR -> Option A
Quick Check:
Use FromISR functions in ISRs [OK]
Hint: Never call task functions inside ISR, use FromISR versions [OK]
Common Mistakes:
Calling task functions inside ISR
Forgetting to clear interrupt flags
Assuming semaphore gives always unblock tasks
5. You want to implement deferred interrupt processing where an ISR signals a task to process sensor data. Which sequence correctly follows FreeRTOS best practices?
hard
A. Task polls sensor data continuously, ISR disables interrupts
B. ISR processes sensor data directly, then calls vTaskDelay()
C. ISR sends data via xQueueSend(), task never blocks
D. ISR calls xSemaphoreGiveFromISR(), then task waits on semaphore and processes data
Solution
Step 1: ISR role in deferred processing
ISR should be short and only notify the task using xSemaphoreGiveFromISR().
Step 2: Task role in processing
The task waits on the semaphore and processes sensor data when notified.
Final Answer:
ISR calls xSemaphoreGiveFromISR(), then task waits on semaphore and processes data -> Option D
Quick Check:
ISR signals, task processes data [OK]
Hint: ISR signals; task does heavy work [OK]
Common Mistakes:
Doing heavy work inside ISR
Using blocking calls inside ISR
Not synchronizing task and ISR properly
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.