I have a task that reads a protected memory and the task suppose to stop accessing the protected memory once received an interrupt.
I am deleting the task immediately after receiving the interrupt using vTaskDelete(taskAHandler) api.
I observed the memory read still continues once the execution returns from ISR.
After further reading I found that vTaskDelete() do not really delete the text or data section of the task it just deletes the TCB created for scheduler.
Is this possible that the execution is returning to the task’s text section from where it was interrupted and resume executing the memory read operation until next timer tick(timer interrupt for scheduler) kicks in and execution control taken back by scheduler ?
If above assumption is correct, then how to stop the task execution after task is deleted ?
well, since you can’t delete a task from an ISR, it must happen deferred in some other task. What priority does that task have, and does the ISR ensure that that task is being executed immediately using the portYIELD_FROM_ISR() mechanism?
Check if you are deleting task from its own function. If so, you will also need to assure that idle task is executed after calling vTaskDelete function. In Idle task, function prvCheckTasksWaitingTermination(); will actually delete task.
So, here is a time gap in which task can be executed.
No it isn’t because (as the TO correctly observed) the task to be deleted won’t be scheduled anymore after vTaskDelete(), thus also before the idle task can complete the deallocation.
As mentioned before, the only sequence I can see (aside from illegally attempting to delete it from inside the ISR) would be that the ISR signals the other task that is supposed to do the deletion but does not yield and thus allows the interrupted task to finish its time slice. Or if the task to do the deletion has a lower pri than the one that is to be deleted.
@RAc Thank you for correcting me.