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.

Help with thread deadlock debugging session on DSP.

 

Serge
  Limondin posted How
  to display DSP/BIOS threads state in a debugging session with Code Composer
  Studio
in Code Composer Forum.

Hello,

I have
  been chasing a thread deadlock on the DSP core of a DaVinci DM6446 ARM/DSP
  device.

The
  following make it extremelly hard to debug and fix these situations.
  Something that would take a few hours with a Debugging environment such as
  Visual Studio 2010 is taking multiple days of frustration with Code Composer
  Studio.

Hurdle:

1) When
  breaking on the Target, only the main init DSP thread is shown, no mehcanism
  to enumerate all the threads in the system and show their stack traces at the
  point the break/pause was issued.

My
  environment is as follows:

1) Code
  COmposer Studio v4.2.4.00033

2) DSP/BIOS
  v5.41.6.21

3) Code
  Gen Tools: 6.1.20

4)
  BlackHawk Emulator: USB560 JTAG Emulator v4.2.1.009

Is
  there a mechanism or project settings to setup a Debugging session such
  that ALL threads running are displayed in the debugging session and all their
  stack traces can be shown so it is easier in a deadlock situation to figure
  out what the state of each thread is ?

Regards,

Serge
  Limondin

  • Hi Serge,

    Have you seen the ROV tool?  It provides some information about the application when the target is halted.

    Also, you should see the current stack trace within the CCS debug window:

    Steve

  • Some details about ROV here:

    http://rtsc.eclipse.org/docs-tip/Runtime_Object_Viewer

    Certainly worth setting up, lots of good data buried in there.

    Chris

  • Thank You Chris for suggesting the ROV, I can now enumerate all the tasks in the system but still cannot see their individual strack traces.

    Please note that we do not use any of the XDC features, our Dsp App is using a custom communication interprocess scheme that we developed and on the Dsp is a regular main() type exe.

    What do i need to do to enable "in the build" the ability to allow stack traces of all running threads to be displayed.

    When I halt the system in the debugger, eventhough the ROV panel shows all the thread, there are no options or no additional Tabs when the TSK object is selected, just the list of threads and their state.

    What i need to do is set the focus of one of these thread in the Debug Session pane that always wants to show:

    "Thread[main] (Suspended)"

        = 0 FXN_F_run()

    And not any of my threads...

    Thank you for your help.

    Serge

  • So I can display their stack traces and now can start debugging the application lockup by looking at what the chain of routine(s) did that lead to the deadlock...

    Kind regards,

    Serge

  • On a related subject I would like to use the RTS tools to do Thread load analysis of our running System on the Dsp.

    Again we use none of the XDC, etc...tools for our DSP application and image.

    Our Dsp.out is a C/C++ application that is only using the DSP BIOS services and as I had mentioned we developed out own shared memory based IPC mechanism between the ARM and the DSP relying again only on DSP BIOS services.

    How do i set this up in our project(s) to be able to see CPU and Thread loads at runtime in Realtime.

    Kind Regards,

    Serge

  • There is a tool called THRLOAD (for "Thread Load") that was developed for BIOS 5 which will give you CPU load on a per task basis.

    However, it was built for a slightly older version of BIOS (5.33x).

    You can have a look at that tool here:

    https://www-a.ti.com/downloads/sds_support/applications_packages/rf_modules/index.htm

    Steve

  • Hi Steve,

    I am using DSP/BIOS 5.20 and would like to know where the PC was for a given task.

    But the following structure does not have program counter.

    struct KNL_Obj

    {    

    QUE_Elem    ready;          /* ready/semaphore queue elem */     
    QUE_Elem    alarm;          /* alarm queue elem */     
    QUE_Elem    setpri;         /* set priority queue elem */     
    QUE_Handle  queue;          /* task's ready queue */     
    Int         priority;       /* task priority */     
    Uns         mask;           /* 1 << priority */     
    Ptr         sp;             /* current stack pointer */     
    Uns         timeout;        /* timeout value */     
    Int         mode;           /* KNL_BLOCKED, KNL_READY,... */     
    /*      *  This STS Object is used to measure the time from when the task is      
    *  made ready, until the function TSK_deltatime() is called.  When the      
    *  task is made ready, the STS object is "set" to the current time.      */      
    STS_Obj     *sts;     Bool        signalled;      /* pending task waken up by sem or timeout */ 
    }; 
     
    Thank you for the help.
     
    Regards,
    Steve Qu