CMSIS RTOS feature osSignal incorrectly implemented on FreeRTOS

[Oskar Weigl]

Posted on December 06, 2016 at 15:04

Hi,

I was checking through the implementation of osSignal in the file installed by STM32CubeMX to 'Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS/cmsis_os.c'

The

http://www.keil.com/pack/doc/CMSIS/RTOS/html/group__CMSIS__RTOS__SignalMgmt.html

specifies that the call to osSignalWait will '

Suspend the execution of the current

runningthread until ALL specified signal flags with the parametersignalsare set.'

This is exactly the behavior of the FreeRTOS function 

http://www.freertos.org/xEventGroupWaitBits.html

. However, in the osSignal implementation, the FreeRTOS primitive 'TaskNotify' is used. As noted on

http://www.freertos.org/RTOS_Task_Notification_As_Event_Group.html

, 'Unlike when using an event group the receiving task cannot specify that it only wants to leave the Blocked state when a combination of bits are active at the same time. Instead the task is unblocked when any bit becomes active, and must test for bit combinations itself.'

This means that the osSignal functionality does not behave as specified.

Please let me know if I have misunderstood the situation, or please let me know how this can be fixed?

Cheers,

Oskar

#cmsis-rtos #freertos

[zamek42]

Posted on December 21, 2016 at 11:10

Hi Oskar,

Unfortunately the osSignalClear is not implemented in stm32Cubemx. Only he declaration is exists on cmsis_os.c

by

Zamek

[Imen.D]

Posted on December 21, 2016 at 14:34

Hello,

osSignal functionality is not supported by STM

32CubeMx

.

In fact, the osSignalClear

function is specified in the generic cmsis_os wrapper for RTOS, but it is not supported by FreeRtos. 

Maybe you can review the example in the Cube package firmware to

 get more details on how to use and apply

osSignal functionality.

Best Regards

Imen

[Oskar Weigl]

Posted on January 17, 2017 at 19:29

Hello,

I do believe that you specify in your user manual

http://www.st.com/content/ccc/resource/technical/document/user_manual/2d/60/ff/15/8c/c9/43/77/DM00105262.pdf/files/DM00105262.pdf/jcr:content/translations/en.DM00105262.pdf

on page 14 that the osSignal functionality is available and supported.

I do see that osSignalClear is not implemented, but it is the behaviour of osSignalWait (and by extension osSignalSet) that I am using, and which is incorrect. The specification says that ALL required bits have to be set for the control to be released, but the implementation by the ST MCD Application Team releases the control as soon as ANY signal is received.

Cheers,

Oskar

[Richard Lowe]

Posted on January 20, 2017 at 20:19

Signals are supported but yes, the behavior is not what is to be expected. osSignalClear is there in prototype, but not implemented. What happens is the signal is clear and therefore runs the first time, then it behaves as expected.

[Gustavo.Laureano]

Posted on February 01, 2017 at 17:44

I'm also suffering with issues regarding osSignal management in the cmsis_os abstraction layer (poorly) provided by ST, is there a way to remove the abstraction layer from the code generation in CubeMX? So the code will be generated with FreeRTOS calls instead of 

cmsis_os calls?

In this way, I can standardize the use of the FreeRTOS in my application, without mixing cmsis_os calls with direct FreeRTOS calls

I can deal with the portability loss in order to keep my API calls standardized all over my application source.

[Richard Lowe]

Posted on March 15, 2017 at 09:59

As of the most recent HAL version. osSignal functions (except clear) seem to be working as expected.

Using signals is by far the fastest inter-thread communication scheme. Best when used to schedule high priority ISR callbacks:

void HAL_CAN_RxCpltCallback(CAN_HandleTypeDef* hcan)
{
if( hcan->Instance == CAN1 )
{
osSignalSet(can_rx_taskHandle, CAN_RX_ISR_FLAG);
}
}�?�?�?�?�?�?�?

[Vito Marolda]

Posted on March 20, 2017 at 18:42

Which version of cmsis_os.c do you have? I have 'CMSIS-RTOS API implementation for FreeRTOS V8.2.3' and I still see the inconsistent implementation of osSignalWait, which will wake-up on ANY signal (regardless of the specified signals, which are only a clear mask but not a filter) instead of waiting for all specified signals to be set.

[Richard Lowe]

Posted on March 20, 2017 at 23:09

FreeRTOS v9.0.0

CMSIS v1.02

I can't comment on multiple signals since in the last application I wrote I was only using single flags with all signals. But, looking through the function that sets and waits for the flag looks to be functional:

Found in tasks.c / FunctionxTaskGenericNotifyFromISR approx line 4888

switch( eAction )
{
case eSetBits:
pxTCB->ulNotifiedValue |= ulValue;
break;
case eIncrement:
( pxTCB->ulNotifiedValue )++;
break;
case eSetValueWithOverwrite:
pxTCB->ulNotifiedValue = ulValue;
break;
�?�?�?�?�?�?�?�?�?�?�?�?�?

Appears correct.

Compare that with the version you have.

[Richard Lowe]

Posted on April 04, 2017 at 22:47

I've been using the signal flags extensively these past weeks and can proclaim they are working as desired.

But...

You have to use them like the

http://www.disca.upv.es/aperles/arm_cortex_m3/curset/CMSIS/Documentation/RTOS/html/group___c_m_s_i_s___r_t_o_s___signal_mgmt.html

states.

Once you set a signal:

osSignalSet(my_super_thread, MY_GO_FLAG);�?�?

You need to check for it in the thread like so:

osEvent evt;
for(;;)
{
 evt = osSignalWait(MY_GO_FLAG, osWaitForever);
 if( evt.value.signals & MY_GO_FLAG)
 {
 ...magic goes here.
 }
 
 if( evt.value.signals & MY_EXTRA_FLAG )
 {
 ... more magic happens.
 }
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

I have a few threads with at least 4 signals on it and all works as advertised.