AnsweredAssumed Answered

Dangerous bug in cmsis_os Message implementation?

Question asked by Laureg on Mar 23, 2017
Latest reply on Feb 21, 2018 by STM32Cube-T

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.

Outcomes