Freertos semaphore not initialised correctly by CubeMX

[tizdipietro]

By setting up a new project in STM32CubeMX 6.10.0, when adding a Semaphore in FREERTOS, the generated code is not correct, and the binary semaphores are initialised in a Taken state ( initial_count=0 of osSemaphoreNew() )  - resulting in the fact that the application will never be able to take the semaphore - see code snippet below. 

/**
 * @brief  FreeRTOS initialization
 *   None
 * @retval None
 */
void MX_FREERTOS_Init(void) {
	/* USER CODE BEGIN Init */

	/* USER CODE END Init */

	/* USER CODE BEGIN RTOS_MUTEX */
	/* add mutexes, ... */
	/* USER CODE END RTOS_MUTEX */

	/* Create the semaphores(s) */
	/* creation of i2sHalfCpltReadySem */
	i2sHalfCpltReadySemHandle = osSemaphoreNew(1, 0, &i2sHalfCpltReadySem_attributes);

 The correct function call should be with initial_count=1 as here below and how it was in older MX versions

foo = osSemaphoreNew(1,1, &bar);

For users having the same issue: quick fix is to add these line after initialisation

/* USER CODE BEGIN RTOS_SEMAPHORES */
osSemaphoreRelease(i2sHalfCpltReadySemHandle);

For ST Employees: please fix Cube MX to properly initialise.

[mƎALLEm]

Hello,

Thank you for raising this issue. Will raise this internally to be fixed.

Internal Ticket 174972 (not accessible by ST community members).

[mƎALLEm · Accepted solution]

Issue fixed in the latest version of CubeMx 6.12.0

[seajeep]

Hi: 

The bug is still there, ver is CubeMx6.13/6.14, the initial state of Semaphore is always 1, would you check it?

[mƎALLEm]

Hello @seajeep ,

According to the internal team, the issue has been fixed in the MCU part numbers supporting native FREERTOS such as H7RS, F1 etc .. However, it still exist in other MCU part numbers that are not supporting natively X-Cube-FREERTOS pack and it will be fixed in the coming revisions of X-Cube-FREERTOS.