# Any reason for xQueueReceive not unblocking? **URL:** \ **Category:** Kernel\ **Created:** [February 7, 2024, 4:11pm UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137 "2024-02-07T16:11:13Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![AlbertoGe](https://avatars.discourse-cdn.com/v4/letter/a/74df32/32.png) [@AlbertoGe](https://forums.freertos.org/u/AlbertoGe)\ **Post date:** [February 7, 2024, 4:11pm UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/1 "2024-02-07T16:11:13Z")
Hello everybody just asking if someone knows any subtle reason that could prevents an xQueueReceive with infinite blocking time (portMAX\_DELAY) to not return when the queue is filled with an xQueueSendToBackFromISR. Short description: - a task (with a quite high prio) is blocking on an xQueueReceive; - an ISR triggered by an external signal wakes up the previous task with an xQueueSendToBackFromISR; - there is only one ISR that fills the queue and one task that consumes it (for the purpose to defer to the task a long computation); - the system (which has many other tasks) basically works, it can run for days (and the queue is filled each 1 ms), then without any reason, other evidences or ciclicity the xQueueReceive on the task stops to proceed when the ISR fills the queue; - I’ve verified (when the problem happens): - the interrupt is still executing (each 1 ms); - inside the ISR the call to xQueueSendToBackFromISR exit with retval != pdPASS; - I imagine that the queue is now full; - but the task waiting on the xQueueReceive is still present and in BLOCKED state; - i’m convinced that there are no other points where that task could be blocked, but of course bugs could be anywhere. Already verified: - the queue has been created with success (and I don’t check with xQueueReceive if the queue pointer is void for any reason); - configASSERT is defined and working (when called…); - any other task (also at lower priority) is running and the FreeRTOS, in general, is healty; - rules for interrupt priorities are respected; thank you for any suggestion Alberto ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [February 7, 2024, 5:13pm UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/2 "2024-02-07T17:13:54Z")
Maybe the variable that holds the queue in the receiving task is being overwritten with something that is close enough to a real queue object not to generate a fault, or the queue structure itself is being “benevolently” overtrampled. ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [February 7, 2024, 5:43pm UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/3 "2024-02-07T17:43:41Z")
On thing you don’t mention is the ISR using the wasWoken flag to wake the task, but failing to do that should just delay the task till the next tick (assuming you have preemption enabled, which is by default). The other issue sounds like corruption of system memory some how. One question, what version of FreeRTOS are you using, older versions, even with configASSERT defined might let some errors sneek past. A typical issue that can cause this sort of issue is using FreeRTOS API inside an ISR with too high of a priority, or other similar configuration errors. ---
**Author:** ![AlbertoGe](https://avatars.discourse-cdn.com/v4/letter/a/74df32/32.png) [@AlbertoGe](https://forums.freertos.org/u/AlbertoGe)\ **Post date:** [February 8, 2024, 7:11am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/4 "2024-02-08T07:11:34Z")
Hello Richard > [@richard-damon](#): > > On thing you don’t mention is the ISR using the wasWoken flag to wake the task, but failing to do that should just delay the task till the next tick (assuming you have preemption enabled, which is by default). yes, handled the yield stuff inside ISR. > [@richard-damon](#): > > One question, what version of FreeRTOS are you using, older versions, even with configASSERT defined might let some errors sneek past. A typical issue that can cause this sort of issue is using FreeRTOS API inside an ISR with too high of a priority, or other similar configuration errors. should be 10.1.1. The target is Zynq7000. Regarding the isr prio issue, i’ve checked that deliberately putting the prio at the wrong level correctly raises the assert inside FreeRTOS’s API. Hello RAc > [@RAc](#): > > Maybe the variable that holds the queue in the receiving task is being overwritten with something that is close enough to a real queue object not to generate a fault, or the queue structure itself is being “benevolently” overtrampled. this is a good point. Now i’ve added a task that monitors the queue when there is the failure (printing " uxQueueMessagesWaiting" and the likes). Of course there is EMI noise around (is a motor control application) and staying connected with the jtag is not so practical. thank you Alberto ---
**Author:** ![funky23](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/funky23/32/5640_2.png) [@funky23](https://forums.freertos.org/u/funky23)\ **Post date:** [February 8, 2024, 10:16am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/5 "2024-02-08T10:16:14Z")
i cannot help but i basicly have the same problem on a renesas rx631 a basic system is running. i can run multiple tasks, the scheduler is working, semaphores aswell. I have one queue which is filled by an RXIRQwith xQueueSendToBackFromISR() and portYIELD\_FROM\_ISR(). xQueueSendToBackFromISR returns true. my irq has prio 4 #define configKERNEL\_INTERRUPT\_PRIORITY 1 #define configMAX\_SYSCALL\_INTERRUPT\_PRIORITY 4 if i raise the prio of my irq above configMAX\_SYSCALL\_INTERRUPT\_PRIORITY i also get the assert that my prio is wrong configured the Task waits forever with xQueueReceive() After leaving the irq handler the scheduler stops working and it seems like it always hangs at if( listCURRENT\_LIST\_LENGTH( &( pxReadyTasksLists[tskIDLE\_PRIORITY] ) ) \> ( UBaseType\_t ) 1 ) no other task is executed anymore(my blinky tasks stop working) and i don’t get into the irq handler again if i send other chars to the controller i’m a little bit lost here. Used Freertos on stm32 before and never had such problems 😕 ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [February 8, 2024, 11:35am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/6 "2024-02-08T11:35:45Z")
how does your port implement the critical section? ---
**Author:** ![funky23](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/funky23/32/5640_2.png) [@funky23](https://forums.freertos.org/u/funky23)\ **Post date:** [February 8, 2024, 11:51am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/7 "2024-02-08T11:51:46Z")
on the rx631 ```auto void vTaskEnterCritical( void ) { portDISABLE_INTERRUPTS(); if( xSchedulerRunning != pdFALSE ) { ( pxCurrentTCB->uxCriticalNesting )++; /* This is not the interrupt safe version of the enter critical * function so assert() if it is being called from an interrupt * context. Only API functions that end in "FromISR" can be used in an * interrupt. Only assert if the critical nesting count is 1 to * protect against recursive calls if the assert function also uses a * critical section. */ if( pxCurrentTCB->uxCriticalNesting == 1 ) { portASSERT_IF_IN_ISR(); } } else { mtCOVERAGE_TEST_MARKER(); } } ``` ---
**Author:** ![AlbertoGe](https://avatars.discourse-cdn.com/v4/letter/a/74df32/32.png) [@AlbertoGe](https://forums.freertos.org/u/AlbertoGe)\ **Post date:** [February 9, 2024, 8:57am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/8 "2024-02-09T08:57:42Z")
> [@RAc](#): > > how does your port implement the critical section? Hello everybody Sorry for my late reply. If you refers to “taskENTER\_CRITICAL()”, the Zynq7000 port (FreeRTOS Kernel V10.5.1) ends up here: ```auto *void vPortEnterCritical( void )* { /* Mask interrupts up to the max syscall interrupt priority. */ *ulPortSetInterruptMask();* /* Now interrupts are disabled ulCriticalNesting can be accessed directly. Increment ulCriticalNesting to keep a count of how many times portENTER_CRITICAL() has been called. */ ulCriticalNesting++; /* This is not the interrupt safe version of the enter critical function so assert() if it is being called from an interrupt context. Only API functions that end in "FromISR" can be used in an interrupt. Only assert if the critical nesting count is 1 to protect against recursive calls if the assert function also uses a critical section. */ if( ulCriticalNesting == 1 ) { configASSERT( ulPortInterruptNesting == 0 ); } } ``` while “taskEXIT\_CRITICAL” is after the #defines of the port: ```auto *void vPortExitCritical( void )* { *if( ulCriticalNesting > portNO_CRITICAL_NESTING )* { /* Decrement the nesting count as the critical section is being exited. */ *ulCriticalNesting--;* /* If the nesting level has reached zero then all interrupt priorities must be re-enabled. */ if( ulCriticalNesting == portNO_CRITICAL_NESTING ) { /* Critical nesting has reached zero so all interrupt priorities should be unmasked. */ portCLEAR_INTERRUPT_MASK(); } } } ``` Then “portCLEAR\_INTERRUPT\_MASK” is: ```auto /* Macro to unmask all interrupt priorities. */ *#define portCLEAR_INTERRUPT_MASK()* \ { \ *portCPU_IRQ_DISABLE();* \ *portICCPMR_PRIORITY_MASK_REGISTER = portUNMASK_VALUE;* \ *__asm volatile ( "DSB \n"* \ *"ISB \n" );* \ *portCPU_IRQ_ENABLE();* \ } ``` and: ```auto /* The critical section macros only mask interrupts up to an application determined priority level. Sometimes it is necessary to turn interrupt off in the CPU itself before modifying certain hardware registers. */ #define portCPU_IRQ_DISABLE() \ dmb(); \ __asm__ __volatile__ ( "cpsid i" ::: "memory" ); \ dsb(); \ isb(); #define portCPU_IRQ_ENABLE() \ dmb(); \ __asm__ __volatile__ ( "cpsie i" ::: "memory" ); \ dsb(); \ isb(); ``` thanks ---
**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 10, 2024, 9:39am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/9 "2024-02-10T09:39:35Z")
> [@funky23](#): > > if( listCURRENT\_LIST\_LENGTH( &( pxReadyTasksLists[tskIDLE\_PRIORITY] ) ) \> ( UBaseType\_t ) 1 ) Can you examine pxReadyTasksLists for your task priority and see if the task is on ready list? Also, are you interrupts getting disabled somehow? Can you check the value of `uxCriticalNesting ` in your task’s TCB? > [@AlbertoGe](#): > > Now i’ve added a task that monitors the queue when there is the failure (printing " uxQueueMessagesWaiting" and the likes). Did you find anything from this? ---
**Author:** ![AlbertoGe](https://avatars.discourse-cdn.com/v4/letter/a/74df32/32.png) [@AlbertoGe](https://forums.freertos.org/u/AlbertoGe)\ **Post date:** [February 10, 2024, 6:19pm UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/10 "2024-02-10T18:19:02Z")
> [@aggarg](#): > > Did you find anything from this? hi @aggarg , no, for the moment the system is running and my counters don’t show anything strange. As I’ve told before, it’s a very rare occurrence - but still to catch. ---
**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 11, 2024, 5:55am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/11 "2024-02-11T05:55:30Z")
Let us know whatever you find. ---
**Author:** ![funky23](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/funky23/32/5640_2.png) [@funky23](https://forums.freertos.org/u/funky23)\ **Post date:** [February 12, 2024, 11:42am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/12 "2024-02-12T11:42:45Z")
unfortunately as usual the error sat in front of the pc ☹ i switched from RX to GCC compiler and somehow the interrupt declaration of my pheripheral interrupt(where i access the queue) was wrong/missing and i think i missed a warning for a missing declaration. everything compiled, the program seemed to be ok. multiple tasks where working fine. as soon as i jumped to my irq handler i could write to the queue but after i returned from it everything was garbage and i jumped elsewhere(sometimes the scheduler was quit, sometimes i hang at the described line in the scheduler. so i think the compiler did not IRET and RET instead. sorry for the hassle. this was absolutley my fault(but the description of the error felt the same to what i observed) Regards ---
**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 12, 2024, 11:49am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/13 "2024-02-12T11:49:12Z")
Glad that you figured. Thank you for reporting back! ---
**Author:** ![AlbertoGe](https://avatars.discourse-cdn.com/v4/letter/a/74df32/32.png) [@AlbertoGe](https://forums.freertos.org/u/AlbertoGe)\ **Post date:** [March 22, 2024, 11:16am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/14 "2024-03-22T11:16:59Z")
Hi everybody, finally I had the chance to see the problem again (the occurrence is very rare). I have added some debug counters to have a picture. I can read the counters from a console terminal, to stay connected with the jtag is quite impossible for EMI noise; The question could be described in this way: 1. a counter in FPGA (Zynq 7000) raises an isr when it expires; 2. that ISR awakes a task with “xQueueSendToBackFromISR”; 3. the queue has been created with deep = 2 (really only uses 1); 4. the queue is empted by a task that does the processing; the queue is really used as a signal; 5. the cpu load is absolutely quiet and there isn’t the possibility that the “eating” task is not running; 6. the counter overflows each 1 ms, and the failure happens in days (= basically it works); 7. when the failure happens, the “_xQueueSendToBackFromISR_” can’t push to the queue any longer (returning != pdPASS) and then the waiting task keeps waiting forever. Still, the surrounding is working, and a monitoring task says me that the queue is full with 2 elements (=the maximum); let’s say _uxQueueMessagesWaiting(xQ\_P50\_trigger) = 2_; any debug idea is appreciated. thanks Alberto ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [March 22, 2024, 8:45pm UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/15 "2024-03-22T20:45:36Z")
So your system timer is still working in the erratic scenario? Are you absolutely sure that your receiving task is suspended on the queue wait and not in some other code location? Is the task stack not overflown? If you have terminal output, can you guarantee that your printf/sprintf logic is not part of the problem? ---
**Author:** ![AlbertoGe](https://avatars.discourse-cdn.com/v4/letter/a/74df32/32.png) [@AlbertoGe](https://forums.freertos.org/u/AlbertoGe)\ **Post date:** [March 25, 2024, 10:53am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/16 "2024-03-25T10:53:39Z")
Hi RAc, > [@RAc](#): > > So your system timer is still working in the erratic scenario? yes, not only the timer of the scheduler, but the whole FreeRTOS system and tasks, which is quite complex. > [@RAc](#): > > Are you absolutely sure that your receiving task is suspended on the queue wait and not in some other code location? Is the task stack not overflown? To debug (no jtag, remember) I’ve assigned different values to a debug variable, which I then can examine on the console. This variable has exactly the same value assigned before the (blocking) call to xQueueReceive. Regarding the stack overflow, I’ve put: #define configCHECK\_FOR\_STACK\_OVERFLOW 2 and I do not see anything suspect. But I will investigate further. > [@RAc](#): > > If you have terminal output, can you guarantee that your printf/sprintf logic is not part of the problem? Of course anything could be. I’ve tried to avoid problems, I execute sprintf in protected areas, and then I send the string to be emitted (using a queue) to a lo-prio task that write to the uart when there is free space. thank you for any debug idea. Alberto ---
**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:** [March 25, 2024, 4:45pm UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/17 "2024-03-25T16:45:56Z")
> [@AlbertoGe](#): > > which I then can examine on the console. Can you examine the task’s TCB and Queue control block? We want to see if the task’s [xEventListItem](https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/tasks.c#L371) is on the queue’s [xTasksWaitingToReceive](https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/queue.c#L115) list. If we can get, the call stack of the task may also provide some useful information - not sure of you can get that though. ---
**Author:** ![AlbertoGe](https://avatars.discourse-cdn.com/v4/letter/a/74df32/32.png) [@AlbertoGe](https://forums.freertos.org/u/AlbertoGe)\ **Post date:** [May 20, 2024, 3:01pm UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/18 "2024-05-20T15:01:58Z")
Hi @aggarg @RAc @richard-damon, I understand that my reply to Your question has come very late. Indeed, I’ve tried to reproduce the problem many times (while solving other bugs in between), but I’ve not seen it any longer. So my current suspect is that it was a consequence of something else that has been fixed meanwhile. Thank you for all the suggestions ---
**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 21, 2024, 4:23am UTC](https://forums.freertos.org/t/any-reason-for-xqueuereceive-not-unblocking/19137/19 "2024-05-21T04:23:54Z")
Thank you for reporting back!