STM32CubeMX 4.7.0 FreeRTOS osMessageCreate bug

[lqdjdy]

Posted on April 30, 2015 at 01:58

osMessageQId osMessageCreate (const osMessageQDef_t *queue_def, osThreadId thread_id)

{  (void) thread_id;  return xQueueCreate(queue_def->queue_sz, queue_def->item_sz);  //return xQueueCreate(queue_def->queue_sz, (uint32_t) sizeof(queue_def->item_sz));   //-------------->Bug}if you want use a queue and the size larger than 4 bytes, osMessageCreate always give you a 4bytes queue. because sizeof(queue_def->item_sz) always return 4.

[2dimka]

Posted on May 19, 2015 at 03:01

I have the same problem.

I try this: return xQueueCreate(queue_def->queue_sz, queue_def->item_sz); But osMessageGet() can return only (osEvent) type. Therefore I was compelled to return to xQueueCreate() and other basic FreeRTOS calls.

[james2399]

Posted on June 20, 2015 at 03:24

This bug is also present in STM32CubeMX 4.8.0 / STMCubeF4 1.6.0

So frustrating because the bugfix gets overwritten by CubeMX when you regenerate project code.

[james2399]

Posted on July 17, 2015 at 05:00

Bug is still present in STM32CubeMX 4.9.0 / STM32CubeF4 1.7.0

[Nesrine M_O]

Posted on July 23, 2015 at 15:24

Hi,

I will report the issue to our development team.Thank you for the information and sorry for the inconvenience that it may bring.-Syrine-

[DD]

Posted on September 16, 2015 at 10:28

Hi, it seems that the bugfix on the STM32CubeF4 1.8.0 has highlighted another problem.

The functions osMessageGet and osMessageKeep will call the xQueueReceive(queue_id, &event.value.v, ticks) passing to it the address of the value.v element of a (osStatus) event variable; t

hen the &event.value.v is passed to the xQueueGenericReceive as the buffer (void * const pvBuffer) where to write the queue item you need to analyze.

Since the value.v is a single uint32_t, it is not correct to use it as a buffer where to store the queue item.

Moreover, if the queue item size is long enough, it will overwrite other stack elements and may lead the code to crash.

[vapostolov]

Posted on August 16, 2016 at 07:44

I hit the same issue. The problem is in the library template of the cmsis_os.h header file.

In my case I was running the current STM32CubeF4 release 1.13.0.I worked around the issue by editing the template header file cmsis_os.h.Change from:const osMessageQDef_t os_messageQ_def_##name = \{ (queue_sz), 

sizeof 

(type)  }to:const osMessageQDef_t os_messageQ_def_##name = \{ (queue_sz), (type)  }The location of the template header file cmsis_os.h on my computer is:

C:\Users\Vlad\STM32Cube\Repository\STM32Cube_FW_F4_V1.13.0\Drivers\CMSIS\RTOS\Template\cmsis_os.h

[Ivan Kucherov]

Posted on April 05, 2017 at 12:50

I confirm this in:

* @file cmsis_os.c

* @author MCD Application Team * @date 22-January-2016 * @brief CMSIS-RTOS API implementation for FreeRTOS V8.2.3

looks like there should be a check on queue item size inside osMessageGet()

To avoid this bug is to not use queue with item size > 4 bytes