# Task hangs on xQueueReceive **URL:** \ **Category:** Kernel\ **Created:** [November 14, 2017, 12:01am UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827 "2017-11-14T00:01:37Z")\ **Posts on this page:** 11\ **Page:** 2
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 15, 2017, 4:15pm UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/21 "2017-11-15T16:15:46Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Wednesday, November 15, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#bc20/b062/f169): > BTW: I have preemption enabled so I believe FreeRTOS shall switch task > as soon as new item is send to the queue… That is true for when the queue is written to from a task, so the yield is not needed there, but it is not true when the queue is written to from an interrupt. Sometimes more control is needed in interrupts - for example if you get an interrupt each time a character is received on a UART you might not want to switch immediately to the handling task unless you know the last character received was the end of the message. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 15, 2017, 7:36pm UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/22 "2017-11-15T19:36:10Z")
**[nixz](https://sourceforge.net/u/nixz/)** wrote on [Wednesday, November 15, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#bc20/4dd2): Adding: ```auto portYIELD_FROM_ISR(xHigherPriorityTaskWoken); ``` or ```auto portYIELD_FROM_ISR(pdTRUE); ``` and from the not ISR calls: ```auto portYIELD(); ``` does not change situation… higher prioryty taks are frozen after short while :-/ ---
**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\ **Post date:** [November 17, 2017, 9:17am UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/23 "2017-11-17T09:17:09Z")
**[heinbali01](https://sourceforge.net/u/heinbali01/)** wrote on [Friday, November 17, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#3edf): Hi, I’m afraid that we’ve come to a point here where there is not enough information to find the root cause. I noticed that the FreeRTOS functions and objects are wrapped into a library. I assume that is not introducing a problem? If you can send me a simple but complete project that shows the failure, I can test it on my STM32F. You can use this email address: “h [point] tibosch [at] freertos [point] org” to send me code directly. But I can not give support on the libraries ( HAL / OS-layer ) that you are using, only direct calls ( API’s ) to the FreeRTOS kernel. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 20, 2017, 12:28pm UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/24 "2017-11-20T12:28:27Z")
**[nixz](https://sourceforge.net/u/nixz/)** wrote on [Monday, November 20, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#3edf/5fcd): OK, I will prepare extra simplified project you can run on your STM. My project is strictly based on template generated from CubeMX (FreeRTOS 9.0.0 is modified by STM and some functions are wrapped by CMISIS). ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 20, 2017, 2:27pm UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/25 "2017-11-20T14:27:28Z")
**[nixz](https://sourceforge.net/u/nixz/)** wrote on [Monday, November 20, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#bc20/b93c): No change after extra call to the portYIELD\_FROM\_ISR(). ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 23, 2017, 2:45pm UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/26 "2017-11-23T14:45:56Z")
**[nixz](https://sourceforge.net/u/nixz/)** wrote on [Thursday, November 23, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#7d52): I ve prepared simplified project to demonstrate problem. Project template was generated with STM32CubeMX, it contains 3 tasks (main A and two higher priority B and C). B and C are blinking LEDs on the board.Queue of A is feed from ISR, queue of B is feed from A and queue of C is feed from ISR. Task A (normal priority is working as expected), B and C are freezing on xQueueReceive(…, portMAX\_DELAY). ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 23, 2017, 5:44pm UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/27 "2017-11-23T17:44:28Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Thursday, November 23, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#7d52/1996): Before trying to work out what the code is doing: - I’m not familiar with the abstraction layer used, so would have to look at the documentation to see if it was used correctly, and the implementation to see if it was implemented correctly (neither of which I have time to do ;o) That limits the support that can be provided as its not easy to support other people’s code. - I note the assert function is implemented to do nothing but return. If that assert function is called in response to assert failures within FreeRTOS then it needs to be implemented to halt operation as assert failures within FreeRTOS are unrecoverable. - Is STM32Cube generating C++ code, or is that your code? I see calls such as: SendToMainTask(msg\_t(MUserBtn), true); that, inside the function, use the address of the msg\_t object. - Lines such as: SendToAudioInputTask( ((++counter) & 1) ? BUFFER\_READY\_LOW : BUFFER\_READY\_HIGH); appear to use only a single parameter, but when I look at the prototype of SendToAudtioInputTask(): BaseType\_t SendToAudioInputTask(uint32\_t msg, bool from\_isr); It needs two parameters, yet no compiler warning is generated. That makes me think I don’t really understand the function call. Regards, Richard. - [http://www.FreeRTOS.org](http://www.FreeRTOS.org) The de facto standard, downloaded every 3 minutes during 2016. - [FreeRTOS+ Feature libraries designed to work with FreeRTOS](http://www.FreeRTOS.org/plus) IoT, Trace, Certification, TCP/IP, FAT FS, Training, and more… On 11/23/2017 6:45 AM, nixz wrote: > I ve prepared simplified project to demonstrate problem. Project > template was generated with STM32CubeMX, it contains 3 tasks (main A and > two higher priority B and C). B and C are blinking LEDs on the > board.Queue of A is feed from ISR, queue of B is feed from A and queue > of C is feed from ISR. > Task A (normal priority is working as expected), B and C are freezing on > xQueueReceive(…, portMAX\_DELAY). > > Attachments: > > - QueueTest.zip > [https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/7d52/attachment/QueueTest.zip](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/7d52/attachment/QueueTest.zip) > (769.3 kB; application/x-zip-compressed) > > * * * > > Task hangs on xQueueReceive > [https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/?limit=25#7d52](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/?limit=25#7d52) > > * * * > > Sent from [sourceforge.net](http://sourceforge.net) because you indicated interest in > [SourceForge.net: Log In to SourceForge.net](https://sourceforge.net/p/freertos/discussion/382005/) > > To unsubscribe from further messages, please visit > [SourceForge.net: Log In to SourceForge.net](https://sourceforge.net/auth/subscriptions/) ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 24, 2017, 8:19am UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/28 "2017-11-24T08:19:04Z")
**[nixz](https://sourceforge.net/u/nixz/)** wrote on [Friday, November 24, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#7d52/1996/468c): 1. I’m not aware of CubeMX-\>FreeRTOS abstraction layer documentation. It seems that most of the calls are simply defines osXXXXXX to FreeRTOS native. 2. I’ve also played with assertion reporting - it changed nothig as no assertion were triggered. 3. Yes, this is my code. It is using some C++ features. Object msg\_t is simply union with constructor. 4. SendToXXXTask() functions have two parameters, however second one “bool from\_isr” is defaulted to false in header file. best regards Mikoaj Tutak ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 27, 2017, 2:36pm UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/29 "2017-11-27T14:36:45Z")
**[nixz](https://sourceforge.net/u/nixz/)** wrote on [Monday, November 27, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#7d52/1996/468c/08c5): I’ve removed xQueueReceive()/xQueueSend() and changed IPC mechanism to xTaskNotify()/xTaskNotifyWait() and it seems to solve freezing issues. However “queue” has only 1 element of uint32\_t, so it is easy to lose send information… I believe there is some bug in reschedule of higher priority tasks waiting on xQueueReceive()… ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 27, 2017, 5:52pm UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/30 "2017-11-27T17:52:33Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, November 27, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#7d52/1996/468c/08c5/26ca): > I believe there is some bug in reschedule of higher > priority tasks waiting on xQueueReceive()… That is unlikely (although of course not impossible) as the reschedule mechanism is the same in both cases, and that code is mature plus tested by ourselves. I think there is something else going on that we haven’t discovered yet. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 27, 2017, 6:03pm UTC](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827/31 "2017-11-27T18:03:20Z")
**[nixz](https://sourceforge.net/u/nixz/)** wrote on [Monday, November 27, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/#7d52/1996/468c/08c5/26ca/75a8): I mean that xQueueSend() do not wake higher priority task wating opposite to xTaskNotify() which works as expected… I’m quite happy with xTaskNotify() however it is intresting why queue version doesn’t work im my case… Maybe problem with ST port within MxCube? PS: is it possible to clear notification bits one by one (when processed) not in one call? [Previous page](https://forums.freertos.org/t/task-hangs-on-xqueuereceive/6827.md?page=1)