Hi Mattias,
Good to have these features. I didn't realize they weren't always there. For comments below, this is CubeIDE v1.7.0, HAL F7 v1.16.1, and CubeMX v6.3.0, running on a NUCLEO-F756 with either the stock ST-LinkV2 firmware or the "JLink-on-ST" firmware.
(1) Showing all kernel objects only shows objects that have names. There is an oversight/bug with showing queues, mutexes and semaphores. For example, in Middlewares/Third_Party/FreeRTOS/Source/queues.c, the list of queues (which also stores mutexes and semaphores) is stored in an array of structures. The structure stores a handle and a "const char *" pointer to the name. vQueueAddToRegistry() uses "name == NULL" as an indicator that the array entry is empty.
LwIP creates its mutexes and mailboxes without names. For example, in Middlewares/Third_Party/LwIP/system/OS/sys_arch.c the 3rd param to MessageQueueNew() is NULL, meaning no "attributes" structure (and thus no name). So calling vQueueAddToRegistry() multiple times with the name as NULL will overwrite the same array entry each time. And, since "name == NULL" indicates an empty entry, even the last call to vQueueAddToRegistry() with name == NULL will be ignored and not displayed in the IDE. As a result, none of the LwIP mutexes/semaphores/queues show up in the debugger RTOS window.
I had to modify the LwIP sys_arch.c to add names to each mutex/mailbox/semaphore so they would show up. And even this was a kludge that named them all the same name, since the vQueueAddToRegistry() only stores a POINTER to the name, it doesn't copy the name into local storage. So unlike task names, queue and mutex names must be "const" (static in RAM or stored in FLASH). This is OK for queues/mutexes created by CubeMX that have a global (and thus static) attributes structure. But not for objects created "on the fly".
(2) I have some instances where the "per task" callback stack lists in the left-side debug window only shows the current task (without the task name displayed). I haven't been able to narrow down why or when this happens. Some times this behavior continues after exiting debug mode and re-entering (i.e. re-starting a debug session). For a while I thought it might be due to some memory corruption related to a bug in my code, but having this issue persist across debug sessions kind of rules that out. Start a debugging session, program loads and runs to main(). Callback stack shows single stack trace as expected. Run code for a short while (long enough for FreeRTOS to init and Ethernet to start running), then pause (or hit a breakpoint). Most of the time I see all the tasks and their stacks. But sometimes only the single un-named task. And sometimes the system has to run for a longer time before I see only the single un-named task. And sometimes it always works. There is no pattern that I can discern, yet. If I can narrow this down, I will post details.
