# Assert failed: prvProcessReceivedCommands timers.c:862 (xResult)

**URL:** <https://forums.freertos.org/t/assert-failed-prvprocessreceivedcommands-timers-c-862-xresult/17445>\
**Category:** Kernel\
**Created:** [May 18, 2023, 10:33am UTC](https://forums.freertos.org/t/assert-failed-prvprocessreceivedcommands-timers-c-862-xresult/17445 "2023-05-18T10:33:29Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![DrMickeyLauer](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/drmickeylauer/32/3490_2.png) [@DrMickeyLauer](https://forums.freertos.org/u/DrMickeyLauer)\
**Post date:** [May 18, 2023, 10:33am UTC](https://forums.freertos.org/t/assert-failed-prvprocessreceivedcommands-timers-c-862-xresult/17445/1 "2023-05-18T10:33:30Z")

</div>

I’m getting an `assert` in the following kernel code:

```c
if( ( pxTimer->ucStatus & tmrSTATUS_IS_AUTORELOAD ) != 0 )
{
    xResult = xTimerGenericCommand( pxTimer, tmrCOMMAND_START_DONT_TRACE, xMessage.u.xTimerParameters.xMessageValue + pxTimer->xTimerPeriodInTicks, NULL, tmrNO_DELAY );
    configASSERT( xResult );
    ( void ) xResult;
}

```

As this only happens sporadically, I’m not sure what I can do about it. Can you think of a scenario where `xTimerGenericCommand` would fail?

CPU load is about 30%, free memory about 100K, number of tasks is 9.

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [May 18, 2023, 1:40pm UTC](https://forums.freertos.org/t/assert-failed-prvprocessreceivedcommands-timers-c-862-xresult/17445/2 "2023-05-18T13:40:02Z")

</div>

Is it possible that timer command queue is not large enough? Can you try increasing the value of `configTIMER_QUEUE_LENGTH`?

---

<div class="post-metadata">

**Author:** ![joshzarr](https://avatars.discourse-cdn.com/v4/letter/j/6de8d8/32.png) [@joshzarr](https://forums.freertos.org/u/joshzarr)\
**Post date:** [May 24, 2023, 6:23pm UTC](https://forums.freertos.org/t/assert-failed-prvprocessreceivedcommands-timers-c-862-xresult/17445/3 "2023-05-24T18:23:02Z")

</div>

Greetings!

I just wanted to follow up and see if you had a chance to try out Gaurav’s suggestion to try and increase the value of configTIMER\_QUEUE\_LENGTH ?

Was that suggestion helpful or do you require any further assistance?

Thanks,  
Josh

---

<div class="post-metadata">

**Author:** ![DrMickeyLauer](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/drmickeylauer/32/3490_2.png) [@DrMickeyLauer](https://forums.freertos.org/u/DrMickeyLauer)\
**Post date:** [February 2, 2024, 2:28pm UTC](https://forums.freertos.org/t/assert-failed-prvprocessreceivedcommands-timers-c-862-xresult/17445/4 "2024-02-02T14:28:31Z")

</div>

Sorry for not getting back earlier. In my tests, increasing the `configTIMER_QUEUE_LENGTH` did not help. I’m afraid it has to do with concurrency, since I did use the timer API to blink LEDs, which involves a lot of (possibly concurrent) calls to reset the timer, if blinking should keep on.

Before investigating deeper though I wanted to try another way to handle blinking LEDs (PWM, low-power coprocessor) and settled on the latter one. When I have some time, I will try to create an artificial minimal example that resembles my use case ­– perhaps I can reproduce it again and we can continue taking a look.

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [February 5, 2024, 5:48am UTC](https://forums.freertos.org/t/assert-failed-prvprocessreceivedcommands-timers-c-862-xresult/17445/5 "2024-02-05T05:48:08Z")

</div>

Thank you for reporting back!