Dangerous bug in cmsis_os Message implementation?

[Gustavo.Laureano]

Posted on March 23, 2017 at 14:12

I think that there is dangerous a bug in the cmsis_os implementation, because when you create a queue (thru osMessageCreate), it creates a queue in FreeRTOS with the item size based in the item size configured by the user in the osMessageQDef_t variable, this way if I create a queue to hold 10 items of a structure of 100 bytes of size each FreeRTOS will allocate 1000 bytes to this queue, but when I send a message thru osMessagePut it will send only the pointer to the 'info' variable, whitch is uint32, this will cause a copy of 100 bytes to the FreeRTOS queue item (4 bytes containing the uint32 'info' data and 96 bytes of garbage), in the reception, the osMessageGet will create a osEvent item and pass the address of event.value.v (whitch is uint32) to the FreeRTOS's xQueueReceive function, whitch will copy 100 bytes from its queue in the address of the event.value.v > CAUSING A HUGE MEMORY CORRUPTION < in your application.

In short: if you create a queue thru cmsis_os with a item size bigger than 4 bytes, you probabily will end with memory corruption when you call osMessageGet, even if you passed the address of you item in the osMessagePut, correct me if I am wrong please!

And also I would like to ask STM32 to put an option in the CubeMX to generate code using the FreeRTOS API instead of the cmsis API, I don't want to use the cmsis API in my code, but I don't like the mixture of APIs caused when I generate the base of my code with CubeMX and then program thru the FreeRTOS API.

[Rob.Riggs]

Posted on March 24, 2017 at 01:52

I think there may be a slight disconnect between CMSIS-OS and FreeRTOS since STM32CubeMX 4.20 upgraded to the newer version of FreeRTOS.  CMSIS-OS has the concept of a message queue, which passes only pointers or data that can fit in sizeof(void*), and a mail queue, which can pass objects by value.  FreeRTOS only has the equivalent of a mail queue and calls it a message queue. CMSIS-OS maps both message queues and mail queues onto FreeRTOS message queues.

I could be misreading what's going on.  There were some significant changes in the FreeRTOS UI components in 4.20 CubeMX.  

There may also be some misunderstanding of what features are available in CMSIS-OS.  It does not help that CubeMX conflates both CMSIS-OS and FreeRTOS in its user interface without a clear delineation of the two.  This may help clear up features offered by CMSIS-OS: 

https://developer.mbed.org/handbook/CMSIS-RTOS

   -- specifically see the sections entitled Message Queue and Mail Queue.

[Gustavo.Laureano]

Posted on March 24, 2017 at 15:28

Well, right

Even with this differentiation between message & mail in CMSIS and FreeRTOS the bug still present if the user define a item_sz bigger than 4 bytes in the osMessageQDef_t used to create the message queue thru osMessageCreate(), because this size will be used to create the FreeRTOS queue, which later will use as parameter to copy the data to/from its queue.. copying (item_sz) bytes of data into the event.value.v (which is uint32)

ATM I still using previous version of CubeMX (I will wait they correct the latest reported bugs to update) so I don't know if/what they changed..]

CMSIS_OS wrapper using FreeRTOS message queue to only pass pointers (in both their message and mail features) is not an issue (as long as they fix this bug), but I think that the way CMSIS do it (dynamically allocating memory for every mail) difficults its use and increase chance of failures (like mem frag), not justifying the implicated memory saving

[Gustavo.Laureano]

Posted on March 27, 2017 at 13:46

No comments from ST team? 

I am using Cube F1 V1.4.0 and seems to be the latest one...

(only my cubeMX is in the previous version, but this have nothing to do with lib version)

[Amel NASRI]

Posted on April 25, 2017 at 13:10

Hello

Laureano_Carneiro_Ca

‌,

Please note that your description will be the base for a deeper investigation of the issue as well as the evaluation of your proposal.

As you already noted, there is no update in STM32CubeF1 version used with last STM32CubeMX version (4.1).

However, for STM32F4, we switched to support last FreeRTOS version (9.0.0).

Will come back to you soon...

-Amel

[stm32cube-t]

Posted on February 21, 2018 at 12:18

Hello,

We confirm that the issue occurs for queue item size larger than 4 bytes: this is a limitation in the CMSIS-RTOS V1 API architecture.

Also, we recommend to use 4 bytes as maximum item size in a message queue until we implement a workaround or we switch to the CMSIS-RTOS V2 API which solves the issue.

You can also use the Mail API osMailPut() and osMailGet() to send receive data size bigger than 4 bytes, for more information please refer to the FreeRTOS/FreeRTOS_Mail application in the STM32Cube embedded software packages (Projects folder).

[SBoes]

Hello, I ran into this issue as well. So there are 3 options for messages larger than 4 bytes:

1) Use the Message Q for pointers to messages in a defined local buffer. The issue here is that you have to write code to pop/push the buffer, which defeats the whole point of using FreeRTOS queues.

2) Use memory pool allocation for the buffer of messages, and the message queue for pointers to the memory pool blocks allocated for the messages.

3) Use Mail queues, as stated by the most recent posting.

The problem with both 2 and 3, for me, is that I'm developing for a medical device and using dynamic allocation is prohibited on my project. The real fix for all this, in my opinion, is allow the option in 2 or 3 to allocate memory blocks FROM A LOCALLY DEFINED BUFFER, vs heap. In this case, I would use the Mail queues. Or better yet, change the CMSIS standard to allow defined message sizes and use that for static memory and mail queues for applications that can use dynamic memory allocation.

[Piranha]

4) Drop CMSIS-RTOS wrapper and use FreeRTOS API directly.

https://www.freertos.org/xQueueCreateStatic.html

[SBoes]

Yep but then you are also bypassing the cubeMX code generation capabilities for RTOS related things.