ASSERT in prvIdleTask (with tickless idle)

pvmellor wrote on Friday, December 21, 2018:

I’m running FreeRTOS 9.0.0 on a 32-bit cortex L4 (STM32L433). No time slicing, but pre-emption is enabled and so is tickless idle. There are 5 tasks running, and it all generally works very well.

Sporadically i get an assert failure in prvIdleTask because xNextTaskUnblockTime < xTickCount. Happens maybe once every few hours, and is difficult to pin down. Looks like all tasks were blocked and an int came in and the ISR was about to give to a semaphone to wake a task to do the actual servicing. The task i suspect is about to be woken is still on the DelayedTaskList.

I do run my own vPortSuppressTicksAndSleep(). This function will do a light sleep if things are still busy and i expect more processing soon. Also it will do a deep STOP2 sleep if we are expecting a long period of inactivity (days for example). During the deep sleep the systick (for free RTOS) and TIM7 tick (for CMSIS, HAL etc) are all disabled. Everything is stopped. The MCU sits in a WFI inside a PRIMASK on/off protection area. We’ve no need to keep the tick count relating to real time.

Anyone able to help? All ideas gratefully received! I’m new to freeRTOS. It looks great, but this is hard to resolve without some in-depth knowledge…


pvmellor wrote on Friday, December 21, 2018:

rtel wrote on Friday, December 21, 2018:

I do run my own vPortSuppressTicksAndSleep().

These things can get very intricate. The key is to see what happens
when the system comes out of sleep mode, specifically, if an interrupt
brings the system out of sleep mode, when does the interrupt run? If it
runs too early, before you have recalculated anything to set the clock
back to normal operation, then the time taken to execute the interrupt
can lead to some errors as it is the time consumed is not taken into
account in the calculations. There were some changes in the default
tickless interrupt implementation to account for this but it doesn’t
sound like you are using that.