OMAPL138 and dsplink debugging problem

Richard Bagdazian

Other Parts Discussed in Thread: OMAPL138

I am currently running the dsplink message app on an OMAPL138 based processor running the Angstrom Linux distribution.

The message app works exactly as desired when invoked from the linux command line.

I wanted to use gdbserver and eclipse to perform arm side debugging and have found a problem which I need some assistance on.

Debugging works fine and I can step through the message application code and set breakpoints inside of Eclipse until I reach the initial call to PROC_attach();

If I set a breakpoint to the statement immediately after the call to PROC_attach() as shown in the snippet below, the processor appears to stop, but Eclipse does not get control and I'm unable to issue any further debugging commands. As I said everything appears to be fine and breakpoints and single stepping work fine up until the point that the call to PROC_attach is made.

.
.
.
   if (DSP_SUCCEEDED (status)) {
        status = PROC_attach (processorId, NULL) ;
        if (DSP_FAILED (status)) {                 // <----------   breakpoint set here, never returns
            MESSAGE_1Print ("PROC_attach () failed. Status = [0x%x]\n",
                            status) ;
        }

Thanks

Rich Bagdazian

over 15 years ago

Deepali Uppal over 15 years ago

TI__Expert 4930 points

Rich,

Which DSPLink release are you on?

There was a defect in the semaphore implementation in DSPLink code. Signal handling was incorrect which led to hang seen while debugging using gdb. I have not tried debugging with eclipse.

The patch release was made over DSPLink release 1.63. this patch release is 1.63.01 and can be downloaded from http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/link/link_1_60/index.html

The changes should be easy to intregrate in the DSPLink version that you have. You will need to rebuild DSPLink, your application and re-try.

Please try this and let me know.

Deepali

Richard Bagdazian over 15 years ago in reply to Deepali Uppal

Intellectual 630 points

Hi Deepali,

I'm using DSPLINK version 1.64 with the angstrom based distribution.

-Richard

Richard Bagdazian over 15 years ago in reply to Richard Bagdazian

Intellectual 630 points

I also used a debug build of dsplink and stepped through the dsplink code to find out where my hangup was taking place and it appears that inside of Notify_init there is a call to pthread_create which is where the system hangs up when I try to step over the thread creation statement.

-Richard

Deepali Uppal over 15 years ago in reply to Richard Bagdazian

TI__Expert 4930 points

Richard,

Do you see this in a simple test case which calls pthread_create (outside of DSPLink)?

This does seem to me a problem at a more fundamental level. i.e. some feature/fix missing in gdb/threading library support.

Deepali

C. Alonso over 14 years ago in reply to Deepali Uppal

Prodigy 235 points

I've got exactly the same problem, did you finally find a solution for it?

César

Richard Bagdazian over 14 years ago in reply to C. Alonso

Intellectual 630 points

Hi César,

Unfortunately no, I had to move on to other more pressing matters.

-Richard

Deepali Uppal over 14 years ago in reply to Richard Bagdazian

TI__Expert 4930 points

Rich/Cesar,

Please look at the bug fix available in 1.63.01.

There was a defect in the semaphore implementation in DSPLink code. Signal handling was incorrect which led to hang seen while debugging using gdb.

The changes should be easy to intregrate in the DSPLink version that you have. You will need to rebuild DSPLink, your application and re-try.

Please try this and let me know.

Deepali

C. Alonso over 14 years ago in reply to Deepali Uppal

Prodigy 235 points

Finally I could solve the problem! My plattform is Davinci dm6467, and I was using dsplink 1.64, so following Deepali's suggestion I downloaded and installed the lastest version available of dsplink for my plattform (dsplink 1.65.00.03) and everything works ok now!

Whatever the problem was with dsplink 1.64, it seems to be fixed on the next version :)

Thanks Richard and Deepali for your answers,

César

Daniel Ferm over 14 years ago in reply to C. Alonso

Prodigy 100 points

We have been struggling with a similar problem for a long time with our multi-threaded application using dsplink on a custom OMAPL138 board.

When a SIGFPE signal was caused by a division by zero in one thread (not working using dsplink) while another was in a dsplink MSGQ_get function our debugger (eclipse using gdb / gdbserver) never received the signal. This caused our failing thread to silently die while the thread working with dsplink continued working like nothing happend.

Moving from dsplink 1.65.00.02 to 1.65.00.03 solved the problem! Now we receive the signal and can debug the problem properly.

Hope this information can help someone else the headache we've been having in trying to guess the problem.

Best regards,

Daniel

Deepali Uppal over 14 years ago in reply to Daniel Ferm

TI__Expert 4930 points

Daniel,

Thanks for the update.

The same bug has been fixed in 1.65.00.03 as well.

Deepali

Mushtaq Syed over 13 years ago in reply to Deepali Uppal

Expert 1140 points

Hi Deepali:

Could you please point me to documentation for DSPLINK that will help me figure out how to use DSPLINK on the OMAPL138 under CCSv5?

I have SYS/BIOS included in my project. However, I don't see DSPLINK in SYS/BIOS or in CCSv5.

How do I go about including DSPLINK for passing messages and data between the ARM and DSP.

Simple example code to accomplish the above would be very helpful.

Thanks a lot!

Cheers,

Mushtaq

Code Composer Studio™︎

Code Composer Studio forum

OMAPL138 and dsplink debugging problem