Here is pseudo-code of the section (which is called from a task not ISR):
vTaskSuspendAll();
for (i = loop through routing table)
{
if (route exists)
{
os_err = xQueueSendToBack( queue[i], &blockToSend_p, 0 );
num_routes++;
}
}
blockToSend_p->num_references = num_routes;
xTaskResumeAll();
At xTaskResumeAll I have a situation that the highest prio task shown as READY in StateViewer is *not* the one that is scheduled next.I am aware that the FreeRTOS documentation for vTaskSuspendAll/xTaskResumeAll specifies not to use certain RTOS calls including xQueueSendToBack while suspended; however my understanding is that one may not make calls with potential to block. Using delay 0 in ‘send’ ensures the call does not block. What should I concluded from the unexpected sheduling behaviour?
A. I’ve used the wrong design.
B. It’s the right design, but a stack overflow is breaking the RTOS.
I tried placing a taskYeild() after xTaskResumeAll() but it did not fix my crashes.
Should I consider using xQueueSendToBackFromISR from task in order get queue-but-don’t-reschedule behaviour?
My setup: STM32F103, FreeRTOS 7.0.2, IAR EWARM 5.30 with StateViewer plugin. Many thanks for your suggestions. Owen