search

STMicroelectronics / STM32CubeL4

STM32Cube MCU Full Package for the STM32L4 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
262 stars 153 forks source link

CMSIS-RTOS V2 bug: incorrect implementation of osFlagsWaitAll option for osEventFlagsWait() #7

Closed fronders closed 3 years ago

fronders commented 4 years ago

The set-up

Description of the bug Incorrect implementation of osFlagsWaitAll option for osEventFlagsWait() is causing incorrect code functioning. When using osEventFlagsWait() function with osFlagsWaitAll I expect that the thread calling gets unblocked when all of the specified flags are set. However if any other flags (additional to specified) are also set - osEventFlagsWait() returns with osErrorTimeout. This happens even with osWaitForever timeout, which is nonsense.

Problem lies in the ST's wrapper around FreeRTOS function xEventGroupWaitBits(). If more flags then specified are set - the function will report error, which shouldn't happen.

Specifically this check on cmsis_os2.c line 1179 is causing the bug. Here is the piece of code around those lines:

    rflags = xEventGroupWaitBits (hEventGroup, (EventBits_t)flags, exit_clr, wait_all, (TickType_t)timeout);
    if (options & osFlagsWaitAll) {
      if (flags != rflags) {    // <--------- THIS IS A BUG
        if (timeout > 0U) {
          rflags = (uint32_t)osErrorTimeout;
        } else {
          rflags = (uint32_t)osErrorResource;
        }
      }
    }
    else {
      if ((flags & rflags) == 0U) {
        if (timeout > 0U) {
          rflags = (uint32_t)osErrorTimeout;
        } else {
          rflags = (uint32_t)osErrorResource;
        }
      }
    }

Proposed solution Replace the buggy condition check:

if (flags != rflags) {    // <--------- THIS IS A BUG
    // ...
}

with a correct one:

if ((flags & rflags) != flags) {    // <--------- THIS IS CORRECT IMPLEMENTATION
    // ...
}

-- Same problem is observed with STM32CubeF4 v1.25.0 pack and many others since they contain CMSIS-RTOS v2.00 Middleware implementation as well.

RKOUSTM commented 4 years ago

Hi @fronders,

Thank you for this report. It will be forwarded to our development teams for analysis. We will be back to you as soon as we get an answer.

Thank you for your patience and thank you again for your contribution.

With regards,

rahmanih commented 4 years ago

Hi @fronders,

this is indeed a bug! and will be fixed in the next release.

regards Haithem.

rahmanih commented 4 years ago

Hi @fronders

It seems that the bug was fixed in the official CMSIS-FreeRTOS repo. (check here)

We are planning to update the STM32CubeFW with the latest CMSIS-FreeRTOS release to integrate the fix.

regards Haithem.

rahmanih commented 4 years ago

I think we can close this issue now.

regards Haithem.

ALABSTM commented 3 years ago

Reopened till a new STM32CubeL4 firmware version supporting FreeRTOS v10.3.1 is published.

RKOUSTM commented 3 years ago

Hi @fronders,

The fix you requested has been implemented and is now available in the frame of the STM32CubeL4 FW V1.17.0 package where we have upgraded to use FreeRTOS V10.3.1 version.

This issue can be closed now. Thank you again for your contribution.

With regards,