CUBE MX CMSIS-RTOS Incompatibilities

[gmontero1959]

Posted on August 21, 2015 at 18:01

I'm just starting with cube MX and free KEIL toolchain for STM32M0, wich includes free ARM CMSIS RTOS, and I have to say that I'm a little disappointed so far with RTOS implementation in MX.

The only OS support is for FreeRTOS with a CMSIS wrapper, which, at a first glace, looked great, because I thought that I could code as if using actual CMSIS RTOS with the hope of moving to actual CMSIS in the future, on a future version of MX with CMSIS RTOS support. I decided to go on this direction after trying to use Keil CMSIS RTOS with MX generated project. I made it work, but with some patches to MX generated code, and with some conflicts with clocks and tick configuration, so I preferred to keep MX code unchanged and use It's supported RTOS. But soon I found out that Cube RTOS wrapper is quite incomplete and incompatible with CMSIS. So far I've found that osThreadDef macro is not compatible (not exactly the samearguments), osMailAlloc does not block waiting for allocation, osSignalWait does not block waiting for the specified signals (allways returns on any signal), and don't know yet how many other incompatibilities I will find. I am writing a module with patched versions of this functions, but I don't know what to do, if to go on with this or abandon Cube and MX and write my oun code with Keil CMSIS-RTOS. I wonder if in the near future versions of Cube, MX, and Keil packages will come out with better integration of both toolchains.

[gmontero1959]

Posted on August 26, 2015 at 13:08

Hi !! Anybody there that has something to comment on this subject ?

Thanks and Regards, Gustavo

[swinemaker]

Posted on August 22, 2016 at 03:35

Hello from 2016 🙂

I've just encountered similar weird issue - osSignalWait from ''cmsis_os.c'' wrapper works strongly not as described - it returns on any received signal. For now, ended up with ugly workaround as this:

osEvent WaitOsSignal (int32_t signals, uint32_t time_to_wait){

uint32_t entry_time = osKernelSysTick();

uint32_t elapsed_time = 0;

uint32_t ticks_left = time_to_wait;

osEvent oe;


do
{

oe = osSignalWait(signals, ticks_left);

if
(oe.status != osEventSignal && oe.status != osOK){ 
// osSignalWait() returns osOK if timeout=0

return
oe; 
// timeout or other s**t

}

if
(oe.value.signals & signals){ 
// got one of requested signals 

return
oe;

} 
else
{ 
// got other signal than requested

osThreadYield(); 
// let other tasks to work for some time

elapsed_time = osKernelSysTick() - entry_time;

if
(elapsed_time>time_to_wait){

ticks_left = 0; 
// prevent overflow

} 
else
{

ticks_left = time_to_wait-elapsed_time;

}

}

} 
while
(ticks_left>0);


oe = osSignalWait(signals, 0); 
// just to be sure

if
((oe.status != osEventSignal && oe.status != osOK) || oe.value.signals & signals){ 
// check for: 

return
oe; 
// 1) other error - pass; 

} 
else
{ 
// 2) required signal - pass; others - falcificate

oe.status = osEventTimeout; 
// falcificate (:

return
oe;

}

}

Please note that this code will consume ticks when task is waiting for specific signal, and that is definitely not what are events for. For now I have to include ''cmsis_os.h'' and ''cmsis_os_workaround.h'' arrrgh. P.S. I use CubeMX for STM32F7.

[rchrdlyon1]

Posted on August 23, 2016 at 09:43

Hi,

CMSIS-RTOS signal events are badly broken. For example, if you want to wait for the first available signal event you normally would set the first parameter to zero when your code calls osSignalWait. The problem is that when you do this, the signal is never cleared when osSignalWait returns. It should be! So subsequent calls to osSignalWait with the first parameter set to zero immediately return. There is no recovery from this as osSignalClear is not implemented by ST. If you set the first parameter to 0xFF, osSignalWait will always return when a signal event becomes available and the signal event is cleared. This is not correct as osSignalWait should then wait for all 16 signal events before clearing and returning. (I have assume timeout is set to osWaitForever). ST have tried to implement CMSIS-RTOS signal events with the FreeRTOS task 32-bit notifications (xTaskNotify and xTaskNotifyWait). They should have used FreeRTOS event groups instead. It is likely other things are broken in the CMSIS-RTOS wrapper. FreeRTOS looks pretty good. Regards ....

[Vito Marolda]

Posted on March 20, 2017 at 18:46

Hello, I am facing the same issue. Did you find any good workaround?

Regards,

--Vito.

[Davide Dalfra]

Posted on June 08, 2017 at 04:18

Hello Vito and Richard

Of course I'm having the same issue there . Before start working deeply on CMSIS-OS wrapper files, did you found any solution or work around ?

Thanks 

Davide

[Vito Marolda]

Posted on June 08, 2017 at 10:12

Hello,

I am porting a project from Keil RTX to STM32 MX.

My experience with osSignalWait:

1. it works as explained here:

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

(wait on 1 signal at a time, with auto-clear: do not rely on osSignalClear, which would also be unsafe in my opinion).

2. see my answers in this thread:

https://community.st.com/0D50X00009XkYcfSAF

Then, there are other small incompatibilities:

1. osThreadDef: stacksize=0 does not mean default stack size: it fails with a null-pointer malloc (easily found if you enable malloc failure callback).
2. Keil RTX ignoresuninitialized semaphores, ST CMSIS-FreeRTOS blocks on assertion failure.

Anyway, it did not require so much effort.

Regards,

--Vito.

[mn]

Posted on June 11, 2017 at 10:38

hi,

I have same problem.

my project was made with STM32CubeMX Library 1.5.1(stm32f746) , when migrate to library 1.7.0(stm32f746) i got many Hard faults. i am using freeRTOS and IAR compiler. I using uart 1, 2, 4 and uart6, with DMA and sending signals when UART send or receive complete,code was OK and worked well , when migrated from Library 1.5.1 to Library 1.7.0, randomly  hard fault occurred , some time in UART1 some time in UART6 and so on. Hard faults is in DMA receive or send and because DMA Handler registers c

ontent

was

unreasonably

changed.

some things i am

suspicious, D-cache is enable ; OS signaling mechanism in new version of cmsis-os changed. 

[Vito Marolda]

Posted on June 11, 2017 at 12:36

 ,

 ,

Hi, I don't use DMA, but if you suspect variables are getting dirty it is

advisable to enable stack overflow and malloc fault hooks.

2017-06-11 10:39 GMT+02:00 nahvi.mohamad <,st-microelectronics@jiveon.com>,:

STMicroelectronics Community

<,https://community.st.com/?et=watches.email.thread>,

Re: CUBE MX CMSIS-RTOS Incompatibilities

reply from nahvi.mohamad

<,

in STM32 MCUs Forum - View the full discussion

<,https://community.st.com/0D70X000006SkPjSAK