cancel
Showing results for 
Search instead for 
Did you mean: 

CMSIS RTOS v1 Semaphore Problems

bl1ndf0ld
Associate II

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){

 

1 ACCEPTED SOLUTION

Accepted Solutions
bl1ndf0ld
Associate II

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

 

View solution in original post

4 REPLIES 4
KnarfB
Principal III

 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

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.  

this was my guess. Probably out of heap space.

bl1ndf0ld
Associate II

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