DS-5 debugger does not show uC-OS info

Hi lmorsephilips

have moved your question to Software Development Tools where i hope you will get the answers you seek.

Hi lmorsephilips,

There shouldn't be any extra steps needed for the OS Support to work - you simply need to enable it from the "OS Awareness" tab in the Debug Configuration window and load an image with the uC-OSIII debug symbols (either via the Debug Configuration file tab or at some point after connection using the commands view or "Load..." option in the Debug Control view). Once you have the image loaded the OS Support should automatically enable itself once it detects the OS is running.

Once you have hit your breakpoint if you could do the following it will help a lot in working out what's gone wrong:

• Run the command "show os enabled" in the Commands view and let me know what the result is
• Run the command "print OSRunning" in the Commands view and let me know what the result is

The first command will print the state of the OS Support (i.e. whether or not it's correctly loaded) and the second will print a symbol which we expect in uC-OSIII images.

Best regards,

Jon

The response that I get from the debugger is:

show os enabled

Operating system hooks set to "deferred" and operating system support currently disabled

print OSRunning

$11 = 1 '\1'

I see a note in Debug Control that the device is connected, but uC/OS-III: Waiting for the OS to be initialized.  Yet the breakpoint is in the startup task ???

Thanks for your help,  Lee

Hi Lee,

Thanks for that - something definitely looks wrong here, the symbols appear to have been correctly loaded and the OS appears to have finished initialization, but the debugger thinks it hasn't.

I have a number of follow up questions:

• Do you see any errors in the Commands view? Do any errors come up in the Error Log (it probably isn't open by default, "Window | Show View | Error Log" will open it)?
• What version of uCOS-III are you running? The command "print OSDbg_VersionNbr" will give the version number if you don't know (I see 30401 for our images, corresponding to v3.04.1).
• Could you try printing some task information, e.g. "print OSTCBCurPtr->NamePtr" (or just "print OSTCBCurPtr" if that doesn't work)?
• When is the startup task being run? Is this a normal OS task, or is this being run before/during the OS initialisation? It shouldn't really matter as long as 'OSRunning' is set to 1 (which occurs after the call to 'OSStart(...)'), but it will help me reproduce the issue.

Thanks - best regards,

Jon

Very quick and, I hope, redundant question: did you build uCOS with OS_CFG_DBG_EN defined to something other than 0 in os_cfg.h or elsewhere in the build?

Most of the tables in the OS Data view rely on information which is only present if that flag is set in the build. While the OS Awareness will initialize, it hasn't got access to the lists it needs to access without it, because uCOS doesn't keep track of that data unless you're running a build generated with that flag.

Ta,

Matt

Yes, the debug configuration is enabled.

After fiddling around, I am now seeing the following …

show os enabled

Operating system hooks set to "deferred" and operating system support currently enabled

print OSRunning

$9 = 1 '\1'

If I look at the Kernel Configuration pull-down in the OS Data tab, I see:

OSDbg_VersionNbr is N/A

All the OSDbg_*En are also N/A

OSMutexQty is 3 

Under the Tasks pull-down it says:

“Could not find the symbol OSDbg_StatTaskStkChkEn”

In os_dbg.c, this variable is set to OS_CFG_STAT_STK_CHK_EN, which is enabled.

Thoughs?

Thanks in advance,  Lee

Hi Lee,

I'm glad you were able to get the OS support into the enabled state. This now looks like the debugger constants in os_dbg.c are not making it out correctly.

As you've said that OS_CFG_DBG_EN is set to 1, the other common cause for this is the compiler optimising the values out when it recognises they are not read from. In the version of the source code I'm looking at (v3.04.01) there is a function at the bottom of the file, OS_Dbg_Init(void), which is intended to prevent this. A quick test suggests this function is required for my compiler (ARM Compiler 5.06 at -O0) - i.e. the symbols are optimised out without the function.

If that function is there it could point to a build issue - you could check that by using one of the constants in your application source code and see if it links correctly and the symbol is then printable from the debugger.

Hope this helps,

Jon