Task hangs on xQueueReceive

Kernel
21

rtel wrote on Wednesday, November 15, 2017:

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.

22

nixz wrote on Wednesday, November 15, 2017:

Adding:

portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

or

portYIELD_FROM_ISR(pdTRUE);

and from the not ISR calls:

portYIELD();

does not change situation… higher prioryty taks are frozen after short while :-/

23

heinbali01 wrote on Friday, November 17, 2017:

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.

24

nixz wrote on Monday, November 20, 2017:

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).

25

nixz wrote on Monday, November 20, 2017:

No change after extra call to the portYIELD_FROM_ISR().

26

nixz wrote on Thursday, November 23, 2017:

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).

27

rtel wrote on Thursday, November 23, 2017:

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.

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:

Task hangs on xQueueReceive
https://sourceforge.net/p/freertos/discussion/382005/thread/e37ed619/?limit=25#7d52

Sent from sourceforge.net because you indicated interest in
SourceForge.net: Log In to SourceForge.net

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

28

nixz wrote on Friday, November 24, 2017:

  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

29

nixz wrote on Monday, November 27, 2017:

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()…

30

rtel wrote on Monday, November 27, 2017:

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.

31

nixz wrote on Monday, November 27, 2017:

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?