Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

RE: Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

Simonr — Wed, 04 Jun 2025 13:50:53 GMT

This ticket is more than 4 years old at this point. Please create a new ticket where you explain your issue in detail and possibly link to this one if you find it relevant.

Best regards,

Simon

RE: Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

jthmp — Tue, 03 Jun 2025 19:21:57 GMT

Any update on a fix for this? we are having the same problem and it's preventing us from using the low power features of nrf52840 with freertos.

RE: Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

Susheel Nuguru — Mon, 07 Jun 2021 12:51:39 GMT

Ray,

You found a bug in the FreeRTOS tickless sleep handler. Thank you for very clear info. But I do not think there is a clear way to fix this completely without masking all interrupts for very small time (which we have been trying our best not to do when using softdevice)

The issue here is that any higher priority (sodtdevice specific) context preempting the vPortSuppressTicksAndSleep function just after wakeup (from __WFE/sd_app_evt_wait) and calculating the diff and if that higher context has not yielded control back to this vPortSuppressTicksAndSleep before the compare register gets incremented, then the FreeRTOS kernel is not happy about it because of the way it increments ticks vTaskStepTick in one go.

Try increasing configEXPECTED_IDLE_TIME_BEFORE_SLEEP to 3 which reduces the chances of this happening (not a fix, just a workaround)
To have this fix properly, we need to disable all interrupts (Even softdevice) so that nothing preempts the clocks correction mechanism after tickless wakeup inside vPortSuppressTicksAndSleep. right now we use sd_nvic_critical_region_enter when using softdevice which only disables application specific interrupts. So softdevice activity can still preempt the tickless update after wakeup

RE: Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

Ray Ma — Fri, 04 Jun 2021 22:12:32 GMT

Hey Simonr,

I want to bring up this issue again, it doesn't happen all the time but now I found a way to repro it reliably. So I tried the patch you suggested above and still have this issue. By atttaching GDB I have some better understanding now:

Here we expect it sleeps for 2 tick but coming back from WFE we are seeing 3 tick difference on the RTC counter, so it assert in task.c 2505

#if ( configUSE_TICKLESS_IDLE != 0 )

	void vTaskStepTick( const TickType_t xTicksToJump )
	{
		/* Correct the tick count value after a period during which the tick
		was suppressed.  Note this does *not* call the tick hook function for
		each stepped tick. */
		configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime );
		xTickCount += xTicksToJump;
		traceINCREASE_TICK_COUNT( xTicksToJump );
	}

#endif /* configUSE_TICKLESS_IDLE */

#1  0x0004287a in vTaskStepTick (xTicksToJump=3) at FreeRTOS/Source/tasks.c:2505

#2  0x00044bb4 in vPortSuppressTicksAndSleep (xExpectedIdleTime=2) at nrf_sdk/nRF5_SDK_16.0.0_98a08e2/external/freertos/portable/CMSIS/nrf52/port_cmsis_systick.c:281

#3  0x00042b62 in prvIdleTask (pvParameters=<optimized out>) at

I tried to disable the software device and the same repro steps doesn't cause the issue any more. I am wondering if it's the SD event handing causing the delay.

Thanks,

-Ray

RE: Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

Simonr — Wed, 28 Oct 2020 09:07:44 GMT

sd_app_evt_wait() is a function intended to let the SoftDevice disable the necessary peripherals, etc. before going to sleep if the SoftDevice is used in an application.

Best regards,

Simon

RE: Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

Ray Ma — Tue, 27 Oct 2020 23:27:34 GMT

Hey Simon, I'll give that a try. What's the difference between sd_app_evt_wait() and WFE()?

Thanks,

-Ray

RE: Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

Simonr — Thu, 22 Oct 2020 08:47:34 GMT

Hi Ray

What SDK version are you using for development? Can you try replacing the #ifdef statement (line 238-254) in port_cmsis_systick.c with the following snippet? I'm not sure if it's related but it's been the fix for surprisingly many FreeRTOS projects having issues with the tickless mode.

#if 0  // With FreeRTOS sd_app_evt_wait increases power consumption with FreeRTOS compared to _WFE (NRFFOSDK-11174)
#ifdef SOFTDEVICE_PRESENT
            if (nrf_sdh_is_enabled())
            {
                uint32_t err_code = sd_app_evt_wait();
                APP_ERROR_CHECK(err_code);
            }
            else
#endif
#endif // (NRFFOSDK-11174)
            {
                /* No SD -  we would just block interrupts globally.
                * BASEPRI cannot be used for that because it would prevent WFE from wake up.
                */
                do{
                    __WFE();
                } while (0 == (NVIC->ISPR[0] | NVIC->ISPR[1]));
            }
        }

Best regards,

SImon

RE: Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

Ray Ma — Wed, 21 Oct 2020 18:09:34 GMT

Hey Simon,

Thanks for replying!

As I understand the diff here should always be equal or less than the xExpectedIdleTime, because before entering WFE() we set the RTC to generate interrupt at xExpectedIdleTime, if there are other interrupts wakes up the CPU early than the RTC it would have a diff less than xExpectedIdleTime which is fine. However the assert shows it end up with a diff larger than xExpectedIdleTime which makes me suspect either the RTC is a bit off or the RTC interrupt was preempted by other high priority interrupt.

-Ray

RE: Assert in FreeRTOS task.c: configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime )

Simonr — Wed, 21 Oct 2020 12:23:02 GMT

Hi Ray

The configASSERT is a sanity check. When tickless mode is entered, an expected maximum idle time is provided. The actual idle time may be shorter than the expected maximum (for example an interrupt), but it should never be greater than the expected maximum. If the assert is hit it means that the code is asking to step over the tick past the time at which a task would otherwise have left the blocked state due to a timeout, which means it is being stepped past what was otherwise the expected maximum idle time. The code should be called before the scheduler is resumed, so that shouldn't happen. Please see this link for more information.

Please note that this reply is derived from an earlier reply by a FreeRTOS user here on the DevZone. I have not seen an issue like this before. Our FreeRTOS expert is out of office until Monday I'm afraid, but I'll try to assist you to the best of my abilities until then.

Best regards,

Simon