RTOS debugging with CubeIDE

[franticspider787]

Hi everyone

I've got a few questions about the views that show FreeRTOS Semaphores and Queues:

1.  My application creates a lot of Mutex and Queues, and only the first 63 (or 64 -- I may have lost count) of each type are visible.  Is this a feature or a bug?  And if I want to see the remainder... any thoughts on how to go about that?

2.  Here's a screenshot of the Semaphore view:

2A:  MutexSPI2 is created by CubeMX as a dynamically allocated Mutex using the CMSIS OS wrapper.

2B:  PS-Global Lock is created with 

mutex_init(&lock,"PS-Global Lock");

where

int mutex_init(mutex_t *_m, const char* mutex_name) {
	SemaphoreHandle_t *m = (SemaphoreHandle_t *) _m;
	*m = xSemaphoreCreateMutex();
	vQueueAddToRegistry((QueueHandle_t) m,mutex_name);
	return 0;
}

I'm guessing that since the 'mutex' is being defined as a Semaphore is why it's not showing up on the list as a MUTEX, but I don't understand why the "Size" and "Free" values are.

2C: The remainder of the Semaphores are created by

	ps_queue_t *q = calloc(1, sizeof(ps_queue_t));
	mutex_init(&q->mux, mutex_name);
	semaphore_init(&q->not_empty, 0, sem_name);

 where

int semaphore_init(semaphore_t *_s, unsigned int value, const char* sem_name) {
	SemaphoreHandle_t *s = (SemaphoreHandle_t *) _s;
	*s = xSemaphoreCreateCounting(INT32_MAX, value);
	vQueueAddToRegistry((QueueHandle_t) s,sem_name);
	return 0;
}

I don't understand why the Free and # Blocked Tasks values are so large (other than they look like

pointers to code addresses).

The code does work (I'm using the pubsub-c library from here

https://github.com/jaracil/pubsub-c and modified it so each mutex / semaphore gets assigned

a name so I could tell them apart.

I'm trying to understand what the values mean and if they're important for what I'm using.

Yes, I should probably spend some time reading through the library but was hoping someone could

tell me if it's a feature or a bug...

I suppose the biggest question is how this view gets the info it's looking for, and if I'm

mis-interpreting the lists because it's a mutex being viewed as a semaphore, or vice versa.

Hope this makes sense to someone other than me, and thank you for your time

[Khaled_DHIF]

Hello @franticspider787 ,

Thank you for raising these points. 

1. Why only ~63–64 mutexes/queues are shown?

That’s a limit of STM32CubeIDE’s FreeRTOS awareness plugin, not FreeRTOS itself. The plugin only displays the first N kernel objects (around 64) for performance reasons. Objects beyond that still exist and work; they’re just not listed.

To inspect objects beyond that:

- Register them with vQueueAddToRegistry().
- Use the Expressions / Memory views to inspect the handle directly.

There’s no public setting in CubeIDE to increase this limit.

• Why `Type`, `Size`, `Free`, `#Blocked` look wrong?

The issue is how you add objects to the queue registry. vQueueAddToRegistry() needs the handle, NOT the address of the variable. Passing m/s makes the registry point at the wrong memory, so CubeIDE tries to decode random data as a Queue_t, and by consequence you see huge or strange values for Size, Free, and Blocked tasks.

Correct code should be:

vQueueAddToRegistry((QueueHandle_t)*m, mutex_name);
vQueueAddToRegistry((QueueHandle_t)*s, sem_name);

• Are those values important?

They’re debug info only:

- For a mutex/binary semaphore: Size = 1, Free = 0/1.
- For counting semaphores: Size = max count, Free = current count.
- # Blocked tasks helps diagnose contention.

They don’t affect runtime behavior; wrong values just mean the debugger looked at the wrong memory because of the registry bug, not that your synchronization is broken.

Kind regards, 

DHIF Khaled