2025-04-21 10:17 AM
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){
Solved! Go to Solution.
2025-04-22 7:06 AM
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
2025-04-21 11:39 AM
> 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
2025-04-22 3:28 AM
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.
2025-04-22 3:40 AM
this was my guess. Probably out of heap space.
2025-04-22 7:06 AM
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