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
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
Hi Deepali,
I'm using DSPLINK version 1.64 with the angstrom based distribution.
-Richard
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,
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.
I've got exactly the same problem, did you finally find a solution for it?
César
Hi César,
Unfortunately no, I had to move on to other more pressing matters.
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.
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,
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
Daniel,
Thanks for the update.
The same bug has been fixed in 1.65.00.03 as well.
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