Hi All, I’m using STM32F767 with CubeMX and open STM32 compiler. I have latest CubeMX is using FreeRTOS 9.0.0. I have 3 tasks (TaskA, TaskB, TaskC) every of these 3 task have same structure: ~~~ void StartTaskA(void const * argument) { uint32_t msg = 0;

for (;;)
{
    while( xQueueReceive(TaskAudioInputQueueHandle, &msg, portMAX_DELAY) != pdTRUE )
    //while( xQueueReceive(TaskAudioInputQueueHandle, &msg, 100) != pdTRUE )
        ;

    switch(msg)
    {
        // message stuff
    }

} ~~~ TaskA has Normal priority, TaskB has High priority and TaskC has Realtime priority. TaskA is sending to the queue of TaskB, TaskB is waiting on xQueueReceive(). I’m sure that I send from TaskA: ~~~ xQueueSendToBack(TaskHandle, &msg, 0); ~~~ It seems that in TaskA “xQueueSendToBack(TaskHandle, &msg, 0);” return pdTRUE for the first N times (however it isn’t handled from the other task) and faild with subsequent calls (when queue is full besause TaskB is not returns from xQueueReceive). Maybe I shall call some manual task reschedule/notify/etc procedure? TaskA sending message to TaskB not from ISR. Any Idea what can be wrong? It seems that situation is better when all task has Normal priority. Lower priority task can’t Resume Higher priority task by adding elements to it’s queue? Thx in advance for any comments and ideas to check! best regards Mik

Do you have configASSERT() defined?

Yes, I have configASSERT() by default from CubeMX. I’ve debugged xQueueSendToBack and it pass all asserts, hovewer queues is full because higher priority task does not wake to read queue filled by lower priority task…

Do you suspect that xQueueReceive() is frozen on some configASSERT()?

I was asking as adding configASSERT() may have found a problem, but if it is already defined then it could well be on an assert already. How have you defined the configASSERT() macro?

Yes, I have configASSERT() by default from CubeMX. I’ve debugged xQueueSendToBack and it pass all asserts, hovewer queues is full because higher priority task does not wake to read queue filled by lower priority task…

~~~ /* USER CODE BEGIN 1 */

define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}

/* USER CODE END 1 */ ~~~ But it doesn’t help if I change it to: ~~~

define configASSERT( x ) {}

~~~ Lower priority task can’t wake higher priority task…

Another hint… I’ve changed code to receive messages from: ~~~ while( xQueueReceive(TaskAudioInputQueueHandle, &msg, portMAX_DELAY) != pdTRUE ) ; ~~~ to: ~~~ while( xQueueReceive(TaskAudioInputQueueHandle, &msg, 0) != pdTRUE ) vTaskDelay(10); ~~~ after this change it seems that it doesn’t hang even with highter priority destination thread, however it causes 10ms unwanted delay 🙁 My configuration: ~~~

define configUSE_PREEMPTION 1

define configSUPPORTSTATICALLOCATION 1

define configSUPPORTDYNAMICALLOCATION 0

define configUSEIDLEHOOK 0

define configUSETICKHOOK 0

define configCPUCLOCKHZ ( SystemCoreClock )

define configTICKRATEHZ ((TickType_t)1000)

define configMAX_PRIORITIES ( 7 )

define configMINIMALSTACKSIZE ((uint16_t)128)

define configMAXTASKNAME_LEN ( 16 )

define configUSE16BIT_TICKS 0

define configUSE_MUTEXES 1

define configQUEUEREGISTRYSIZE 8

define configUSEPORTOPTIMISEDTASKSELECTION 1

define configUSECOROUTINES 0

define configMAXCOROUTINE_PRIORITIES ( 2 )

define INCLUDE_vTaskPrioritySet 1

define INCLUDE_uxTaskPriorityGet 1

define INCLUDE_vTaskDelete 1

define INCLUDE_vTaskCleanUpResources 0

define INCLUDE_vTaskSuspend 1

define INCLUDE_vTaskDelayUntil 0

define INCLUDE_vTaskDelay 1

define INCLUDE_xTaskGetSchedulerState 1

define configLIBRARYLOWESTINTERRUPT_PRIORITY 15

define configLIBRARYMAXSYSCALLINTERRUPTPRIORITY 5

define configKERNELINTERRUPTPRIORITY ( configLIBRARYLOWESTINTERRUPTPRIORITY << (8 – configPRIOBITS) )

define configMAXSYSCALLINTERRUPTPRIORITY ( configLIBRARYMAXSYSCALLINTERRUPTPRIORITY << (8 – configPRIOBITS) )

~~~ All ISR routines has priority od 5 (and are allowed to call “FromISR” API). Is there a possibility to dump call stac on configASSERT()? I have printf() on UART defined.

while( xQueueReceive(TaskAudioInputQueueHandle, &msg, portMAX_DELAY) != pdTRUE ) ;

The above is a bit illogical: when you call xQueueReceive() with portMAX_DELAY as a time-out, the function will block for ever, or until an item has been received. and so it will always return pdTRUE.

while( xQueueReceive(TaskAudioInputQueueHandle, &msg, 0) != pdTRUE ) vTaskDelay(10);

The above loop makes more sense: a time-out of 0 ( ticks ) means: polling. The call to xQueueReceive() will poll if there is a packet, and return immediately, either success, or fail As long as there is no packet, every loop will sleep unconditionally for 10 clock-ticks. Please also realise that when it calls vTaskDelay(10), other ( lower-priority ) tasks get a chance to become active. It will also be possible for other tasks to read from TaskAudioInputQueueHandle.

But it doesn’t help if I change it to:

~~~

define configASSERT( x ) {}

~~~

The introduction of configASSERT() will not directly prevent problems, at most it may reveal some bad behaviour.

I have added loop to the: ~~~ while( xQueueReceive(TaskAudioInputQueueHandle, &msg, portMAXDELAY) != pdTRUE ) ; ~~~ because I was playing with various timeouts from 0 to portMAXDELAY and only 0 works for me. In facet for portMAX_DELAY it shoud not return nothing other than PDTRUE/pdPASS. I still have no idea why xQueueReceive(…, portMAX_DELAY) freezes and make queue overflow, especially this task has higher/realtime priority. It works only if all task has same Normal priority (which is unwanted for me).

I’ve changed configASSERT() to: ~~~

define configASSERT( x ) if((x)==0) printf( “##########nASSERT FAILED in %s, line %inn”, FILE, LINE )

~~~ However it wasn’t executed and task waiting on queue have freezed and queue overflows…

If you want, can you attach some more complete code that I can actually run? I’d like to see : ● the three tasks functions ● the calls to Send and Receive ● the way in which you create all queues and you can leave-out other details ~~~ int msg; xQueueSendToBack(TaskHandle, &msg, 0); ~~~ Isn’t TaskHandle a strange name for a handle to a queue? Aren’t you mistaken here?

Sure, some code is created by STM32 CubeMX: Tasks: ~~~ osThreadId TaskMainHandle; uint32t TaskMainBuffer[ 2048 ]; osStaticThreadDeft TaskMainControlBlock; osThreadId TaskAudioInputHandle; uint32t TaskAudioInputBuffer[ 1024 ]; osStaticThreadDeft TaskAudioInputControlBlock; osThreadId TaskAudioOutputHandle; uint32t TaskAudioOutputBuffer[ 1024 ]; osStaticThreadDeft TaskAudioOutputControlBlock; … osThreadStaticDef(TaskMain, StartTaskMain, osPriorityNormal, 0, 2048, TaskMainBuffer, &TaskMainControlBlock); TaskMainHandle = osThreadCreate(osThread(TaskMain), NULL); osThreadStaticDef(TaskAudioInput, StartTaskAudioInput, osPriorityNormal, 0, 1024, TaskAudioInputBuffer, &TaskAudioInputControlBlock); TaskAudioInputHandle = osThreadCreate(osThread(TaskAudioInput), NULL); osThreadStaticDef(TaskAudioOutput, StartTaskAudioOutput, osPriorityNormal, 0, 1024, TaskAudioOutputBuffer, &TaskAudioOutputControlBlock); TaskAudioOutputHandle = osThreadCreate(osThread(TaskAudioOutput), NULL); ~~~ Queues: ~~~ osMessageQId CmdTxRxQueueHandle; uint8t CmdTxRxQueueBuffer[32 * sizeof(struct msgt)]; osStaticMessageQDef_t CmdTxRxQueueControlBlock; osMessageQId TaskAudioInputQueueHandle; uint8t TaskAudioInputQueueBuffer[16 * sizeof(uint32t)]; osStaticMessageQDef_t TaskAudioInputQueueControlBlock; osMessageQId TaskAudioOutputQueueHandle; uint8t TaskAudioOutputQueueBuffer[16 * sizeof(uint32t)]; osStaticMessageQDef_t TaskAudioOutputQueueControlBlock;

osMessageQStaticDef(CmdTxRxQueue, 32, msg_t, CmdTxRxQueueBuffer, &CmdTxRxQueueControlBlock);
CmdTxRxQueueHandle = osMessageCreate(osMessageQ(CmdTxRxQueue), NULL);

osMessageQStaticDef(TaskAudioInputQueue, 16, uint32_t, TaskAudioInputQueueBuffer, &TaskAudioInputQueueControlBlock);
TaskAudioInputQueueHandle = osMessageCreate(osMessageQ(TaskAudioInputQueue), NULL);

osMessageQStaticDef(TaskAudioOutputQueue, 16, uint32_t, TaskAudioOutputQueueBuffer, &TaskAudioOutputQueueControlBlock);
TaskAudioOutputQueueHandle = osMessageCreate(osMessageQ(TaskAudioOutputQueue), NULL);

~~~ Task structure (~same for all three tasks): ~~~ for (;;) { while( xQueueReceive(CmdTxRxQueueHandle, &msg, portMAX_DELAY) != pdTRUE ) ;

    switch(msg.id)
    {
    case MNone:
    {
        break;
    }
...
}

~~~ Send functions (all three looks the same): ~~~ BaseTypet SendToMainTask(msgt msg, bool fromisr) { if (!fromisr) return xQueueSendToBack(CmdTxRxQueueHandle, &msg, 0);

BaseType_t xHigherPriorityTaskWoken = pdFALSE;
return xQueueSendToBackFromISR(CmdTxRxQueueHandle, &msg, &xHigherPriorityTaskWoken);

} ~~~ It works if all three tasks have Normal priority, if I change priority of TaskB AboveNormal it would freeze xQueueReceive(CmdTxRxQueueHandle, &msg, portMAX_DELAY) and makes queue overflow. Which is visible from TaskA which is still running and responding…

~~~ BaseType_t xHigherPriorityTaskWoken = pdFALSE; return xQueueSendToBackFromISR(CmdTxRxQueueHandle, &msg, &xHigherPriorityTaskWoken); ~~~ The above code is called if from_isr = 1, that is good. But what I miss is a yield, By default the ISR will return without switching, i.e. to the task ( or interrupt ) that was active. Could you this : ~~~ BaseTypet SendToMainTask(msgt msg, bool fromisr) { BaseTypet xResult; if (!fromisr) { xResult = xQueueSendToBack(CmdTxRxQueueHandle, &msg, 0); } else { BaseTypet xHigherPriorityTaskWoken = pdFALSE; xResult = xQueueSendToBackFromISR(CmdTxRxQueueHandle, &msg, &xHigherPriorityTaskWoken); portYIELDFROMISR(xHigherPriorityTaskWoken); } return xResult; } ~~~

~~~ Task structure (~same for all three tasks):

for (;;)
{
    while( xQueueReceive(CmdTxRxQueueHandle, &msg, portMAX_DELAY) != pdTRUE )
        ;

~~~ Just another question: do the three tasks all wait for the same queue name CmdTxRxQueueHandle ?

No, all three tasks has three separate queues: ~~~ osMessageQId CmdTxRxQueueHandle; osMessageQId TaskAudioInputQueueHandle; osMessageQId TaskAudioOutputQueueHandle; ~~~ I’ve attached definitions before (see above).

And what is the effect of calling portYIELD_FROM_ISR() in case SendToMainTask() is called from an interrupt?

Thank you for the idea to check. I will check it when I will get access to the code again. However task B and C are feeded also from main loop od task A not only from ISR. Those “non ISR” messages also do not wake taks B and C. Do yoy think I shall try adding portYIELD() to the non ISR portion of this function? ~~~ BaseTypet SendToMainTask(msgt msg, bool fromisr) { BaseTypet xResult; if (!fromisr) { xResult = xQueueSendToBack(CmdTxRxQueueHandle, &msg, 0); portYIELD(); } else { BaseTypet xHigherPriorityTaskWoken = pdFALSE; xResult = xQueueSendToBackFromISR(CmdTxRxQueueHandle, &msg, &xHigherPriorityTaskWoken); portYIELDFROMISR(xHigherPriorityTaskWoken); } return xResult; } ~~~ BTW: I have preemption enabled so I believe FreeRTOS shall switch task as soon as new item is send to the queue…

BTW: I have preemption enabled so I believe FreeRTOS shall switch task as soon as new item is send to the queue…

I think that is correct. ~~~ xResult = xQueueSendToBack(CmdTxRxQueueHandle, &msg, 0); portYIELD(); ~~~ and so there is no need to call portYIELD() explicitly. In case of an interrupt, a yield must be scheduled explicitly.

But when I disable all messaged sent from ISRs and leave only those sent from TaskA (Normal) main loop, TaskB also hangs on reading item from queue so thats the idea behing adding “portYIELD()” from non ISR calls.

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.

Adding: ~~~ portYIELDFROMISR(xHigherPriorityTaskWoken); ~~~ or ~~~ portYIELDFROMISR(pdTRUE); ~~~ and from the not ISR calls: ~~~ portYIELD(); ~~~ does not change situation… higher prioryty taks are frozen after short while :-/

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.

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

No change after extra call to the portYIELDFROMISR().

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

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(msgt(MUserBtn), true); that, inside the function, use the address of the msgt object.
• Lines such as:

SendToAudioInputTask( ((++counter) & 1) ? BUFFERREADYLOW : BUFFERREADYHIGH); appear to use only a single parameter, but when I look at the prototype of SendToAudtioInputTask(): BaseTypet SendToAudioInputTask(uint32t 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 The de facto standard, downloaded every 3 minutes during 2016.
• 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 (769.3 kB; application/x-zip-compressed)

---

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 https://sourceforge.net/p/freertos/discussion/382005/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

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

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

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.

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?