F29H850TU: CCS RTOS Object View (ROV) not displaying Queues/Semaphores/Mutexes/Timers

Hello,

Thanks for the comprehensive post. 

One more thing to check would be that the projects SDK version matches the one in which you have the updated ROV file. Also that configCHECK_FOR_STACK_OVERFLOW is set to 2

To verify the ROV file itself, can you check the control+rtos_demo example to see if the semaphore shows up in the ROV. If yes, there may be some problem in the way your registry is set up, and we can debug from there.

One stopgap solution I can suggest in case you see no improvements is replacing the CCS installations ROV file directly with the one from the SDK. This file can be found at ccs2100\ccs\ccs_base\yarov\rov_freertos.js (maintain a backup of this as well). For instance, I see the following view for Mutexes when running the freertos_port_validation_tests validation project

(There do seem to be mismatches when interpreting mutexes vs semaphores vs queues, but we should at least be able to view all of them)

Regards,

Arnav 

Thank you for your fast response Arnav. Following your suggestions, here's what we did and found:

1. configCHECK_FOR_STACK_OVERFLOW — already set to 2, confirmed via SysConfig. Not the cause.

2. Tested control+rtos_demo example — imported fresh from the same SDK (f29h85x-sdk_1_02_01_00) into our workspace, built and debugged it standalone. Its registered binary semaphore does show up correctly under Mutexes/Semaphores in ROV. This confirms the ROV mechanism and toolchain work in general.

3. Replaced CCS's installed ROV script — backed up ccs2100/ccs/ccs_base/yarov/rov_freertos.js (the built-in 4-view script: Heap/Stack/TaskModule/TaskInstances — no Queues/Semaphores/Mutexes/Timers at all) and replaced it directly with the SDK's FreeRTOS.rov.js (7-view version). This removes any ambiguity about which script CCS is actually using. No change — our project's Queues/Semaphores/Mutexes tabs are still empty.

4. Compared our object registration against the working demo line-by-line:

• Demo: vQueueAddToRegistry(handle, name); vQueueSetQueueNumber(handle, uniqueValue); — we were missing the vQueueSetQueueNumber() call. We added it (unique non-zero value per object). No change.
• Timing: we initially assumed our registrations happened after the scheduler started (from task context). We traced our main() and found this is not the case — like the demo, all our registrations happen in main(), before FreeRTOS_init() (which creates tasks and starts the scheduler). So registration timing is equivalent between our project and the demo.
• Struct layout: verified byte-for-byte via the debugger that our compiled Queue_t layout matches what the ROV script's manual offset parser expects (configUSE_QUEUE_SETS=0 in both, no unexpected extra fields).
• Confirmed via direct memory/register reads that our xQueueRegistry is fully and correctly populated (10/10 valid entries, correct names, ucQueueType=1 for Mutex, non-zero unique uxQueueNumber after our fix).

Remaining known difference: the demo registers exactly 1 semaphore; our project registers 4 mutexes. We haven't been able to test whether object count is the actual trigger, since even a single mutex isn't showing yet in our project.

And our project SDK versions:





Best regarding,
Jan

Hi Jan,

Apologies for the delay, is there any change on issue?

It would be hard to debug this further without inspecting the code, if you are able to send over the FreeRTOS skeleton code where the issue is recreated, we can check it out.

Regards,

Arnav