This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCSv5 Linux Aware Debugging

Other Parts Discussed in Thread: OMAP3530

Have a question about Linux Aware Debugging in CCSv5.

I'm debugging in Linux 2.6.32 on the OMAP3530 with an XDS510USB.  I can connect to my target, halt the execution, and I can step through the kernel execution.

However, when I select "Enable OS Debugging", the list of user processes does not appear.  I cannot figure out how to get to the list of processes and threads.

This seems to be different than CCSv4.  In CCSv4, when I halt the execution and select "Enable OS Debugging", I get a list of processes and threads immediately.

Is there some hidden option in CCSv5 to turn this on?

Thanks!
Chris Norris

  • Looking for the same?

    When i tried to enable OS Debugging, it gives the following error

    CortexA8: Can't initialize TLD Device Driver: per_cpu__runqueues.curr - not found

    Also where the list of processes/threads can be viewed in CCSv5?

     

    with regards

    Mugunthan V N

  • @Chris,


    The process and thread list part of Linux Aware debug has not yet been ported ton v5.x. The way this worked in the version of Eclipse that was used in v4 could not easily be moved to the new Eclipse version in v5. Enabling OS aware debug in v5 will still enable the module relocation part of this feature.

    I'm curious what your use case is for using the process/thread list in CCS. We had found v4 was primarily being used for kernel debug and this part of the feature was not much used. As CCS v5 does support simultaneous run-mode (gdb) and JTAG debug sessions and Gdb debug is more suitable for process debugging, this may be a better bet if you are trying to look at both the a user process and kernel space.

    @Mugunthan,

    From the description of the error message, it sounds like the version of the kernel you are using has changed key symbols that CCS is looking for to support module relocation. We will need to update the OS driver to add support for the latest kernel changes.  You can still debug kernel code without enabling OS debugging though, you just won’t be able to enable the module relocation feature until we can make that update. What kernel version and target are you using?

  • Hi Andy,

    I'm currently debugging a CPU stall where the console and the network become unresponsive, so I was hoping if I have the JTAG debugger running that I could halt and learn what tasks are blocking.  Having the ability to debug in source code be extremely useful in this case, but for the moment I have shifted to other methods to get information about my blocked tasks.  I have shifted my focus from JTAG & CCS to use Ftrace and SysRq in Linux instead.  I just learned that I can send SysRq-T, SysRq-W, etc. through the serial console when I'm in the stall, so I'm getting information about my hung tasks that way.

    I have not narrowed down the specific problem that's hanging my system yet, so I am definitely still interested in whether CCS & JTAG can accelerate my debugging process.  Maybe the kernel-only source debugging combined with information I learn from SysRq could lead me to the answer.

    I have both a CCSv5.x and CCSv4.x installed on my PC, so let me ask another question about CCSv4.  I figured out how to debug kernel source code using the TI Wiki's.  I can enable the OS debug and get my list of processes and threads.  At that point, I cannot not figure out how to load symbols for my user processes.  Is it possible to do this?

    I have a DSP/BIOS application running in my SoC as well.  If I could debug DSP, Linux kernel on ARM, and user processes on ARM, all with one JTAG debugger and CCS, that would be such a killer tool to have for these ARM+DSP SoC's!!  :)

    Regards,
    Chris Norris

  • Hi Chris,

    Here are the steps to debug a process in CCSv4:

    1. You need to build your application with debug info (-g).
    2. Run the application on the target.
    3. Enable OS debug
    4. From the CCS debug view, select the process you want to debug, expand it to see the callstack.
    5. Select Add symbols and specify the debug build of the application.
    6. You should be able to set thead level breakpoints using the symbols from the application.

    You can add other user symbols to the process by repeating the step 5.

    CCS unwinds the call stack of a process using the kernel symbol (vmlinux) and additional symbols you added to the process.

    If your process halts at the kernel code, CCS will unwind the callstack in the kernel code using vmlinux

    On the other hand, if the process halts at the user code, CCS will unwind the callstack using the application symbol file.

    In order to see the full call stack from the user space to the kernel space, you need to load the dynamic library symbols as well.

    Currently, CCS does not figure out where the dynamic symbols are relocated. You have to do that manually and load the symbols manually.

    I can provide further details if you want to do that.

    Regards,

    Raymond

     

  • Hi Andy,

    I am using the following Linux version on my board

    Linux ti8168-evm 2.6.37 #3 Mon Mar 28 15:08:18 IST 2011 armv7l GNU/Linux

    Target - Centaurus Board (ti8168-evm)

     

    regards

    Mugunth

  • Mugunth,

    I have filed a bug report (SDSCM00039726) to track getting the Linux driver updated to support this kernel.

  • Hi Raymond,

    Thank you for this information.  I will try these steps.

    Cheers!
    Chris