freertos: call tick hooks on CPU1 even if CPU0 scheduler is suspended

The block which dispatches ticks on CPU1 was a copy of the code block
for the normal path (CPU0). It used to check uxPendedTicks, with the
logic that uxPendedTicks can be 0 iff the scheduler is not suspended.

On CPU1 however, uxPendedTicks is not related to the state of the
scheduler (as uxPendedTicks is updated on CPU0). Due to this, if CPU0
scheduler was suspended, and uxPendedTicks happened to be nonzero,
tick hooks on CPU1 didn’t run, even though CPU1 scheduler was working.

This change removes the check for uxPendedTicks in CPU1 code path,
so that the tick hooks on CPU1 always get called (as for the CPU0 code
path).
This commit is contained in:
Ivan Grokhotkov 2017-01-18 23:14:29 +08:00
parent f7e2e456e4
commit 31ec0a7c44

View File

@ -2381,26 +2381,15 @@ BaseType_t xSwitchRequired = pdFALSE;
switch, even when this routine (running on core 0) unblocks a bunch of high-priority
tasks... this is less than optimal -- JD. */
if ( xPortGetCoreID()!=0 ) {
#if ( configUSE_TICK_HOOK == 1 )
vApplicationTickHook();
#endif /* configUSE_TICK_HOOK */
esp_vApplicationTickHook();
/*
We can't really calculate what we need, that's done on core 0... just assume we need a switch.
ToDo: Make this more intelligent? -- JD
*/
{
/* Guard against the tick hook being called when the pended tick
count is being unwound (when the scheduler is being unlocked). */
if( ( uxSchedulerSuspended[ xPortGetCoreID() ] != ( UBaseType_t ) pdFALSE ) || uxPendedTicks == ( UBaseType_t ) 0U )
{
#if ( configUSE_TICK_HOOK == 1 )
vApplicationTickHook();
#endif /* configUSE_TICK_HOOK */
esp_vApplicationTickHook();
}
else
{
mtCOVERAGE_TEST_MARKER();
}
}
return pdTRUE;
}