cancel
Showing results for 
Search instead for 
Did you mean: 

Freertos semaphore not initialised correctly by CubeMX

tizdipietro
Associate III

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.

1 ACCEPTED SOLUTION

Accepted Solutions
SofLit
ST Employee

Hello,

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

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

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

View solution in original post

1 REPLY 1
SofLit
ST Employee

Hello,

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

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

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.