Skip to main content
Associate
April 21, 2025
Solved

CMSIS RTOS v1 Semaphore Problems

  • April 21, 2025
  • 2 replies
  • 741 views

Hi, I have a problem with CMSIS RTOS v1 using STM32F103RET6. I have about 6 - 7 tasks. The first task is the StartDefaultTask, after finishing initializing, when running to osSemaphoreRelease, it gets to configAssert(pxQueue) and loop forever. The semaphore is reference to another task, which the task combines at least two semaphores to work. Can anyone meet this before? Also the task which combines two semaphores work like this, where the callback_timeout is released from the StartDefaultTask

if(osSemaphoreWait(save_data, osWaitForever) == osOK){
			if(osSemaphoreWait(callback_timeout,osWaitForever)==osOK){

 

Best answer by bl1ndf0ld

Thanks, I have fixed it. Turn out, cmsis-rtos v1 was the problem. When I change to FreeRTOS command, it works perfectly. This only happens to semaphore, while the other thing like mail or mutex doesn't

 

2 replies

KnarfB
Super User
April 21, 2025

 it gets to configAssert(pxQueue)

i.e. pxQueue is not a valid queue handle. This may happen if the queue creation failed and you don't check that. Typically with default (small!) heap settings and dynamic queue creation.

Use the debugger to further investigate the issue.

hth

KnarfB

bl1ndf0ldAuthor
Associate
April 22, 2025

I also check again and the problem is the semaphore isn't created correctly. I set the semaphore like this:

osSemaphoreId save_data;
osSemaphoreDef(save_dataId);
osSemaphoreId save_data = osSemaphoreCreate(osSemaphore(save_dataId), 0);

But it returns NULL. I want to set the semaphore initial state 0, if I set 1 it will go to other task.  

KnarfB
Super User
April 22, 2025

this was my guess. Probably out of heap space.

bl1ndf0ldAuthorAnswer
Associate
April 22, 2025

Thanks, I have fixed it. Turn out, cmsis-rtos v1 was the problem. When I change to FreeRTOS command, it works perfectly. This only happens to semaphore, while the other thing like mail or mutex doesn't