ASSERT in prvIdleTask (with tickless idle)

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… Thanks! Paul.

ASSERT in prvIdleTask (with tickless idle)

ASSERT in prvIdleTask (with tickless idle)

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.