Forums » Software Development »
dsplink debugging issue
Added by Rich Bagdazian over 13 years ago
I am currently running the dsplink message app on the mityOmap processor (OMAPL138)
The message app works exactly as desired when invoked from the linux command line.
When using gdbserver and eclipse to perform arm side debugging I have run into some peculiar behavior which I was wondering if anyone has run into.
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)) { // <----------- breakpoint set here, works fine
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
Replies (10)
RE: dsplink debugging issue - Added by Michael Williamson over 13 years ago
If you let the application run in the absence of using the debugger, does PROC_attach return a value, or does it hang on the attach?
I thought that with DSP link, there is a handshake that must happen between the DSP and the ARM before the PROC_attach cycle completes... but I might be wrong...
-Mike
RE: dsplink debugging issue - Added by Rich Bagdazian over 13 years ago
Hi Mike,
The app is the "message" sample app provided by TI in their dsplink release. It runs to completion normally when executed outside of the debugger and communication between the ARM and DSP appears to be working correctly based on the program output:
root@mityomapl138:~# ./DspMessage message.out 100 0 ========== Sample Application : MESSAGE ========== Entered MESSAGE_Create () Leaving MESSAGE_Create () Entered MESSAGE_Execute () Transferring 100 iterations took 0 seconds 41706 microseconds. RoundTrip Time for 1 message is 417 microseconds. Leaving MESSAGE_Execute () Entered MESSAGE_Delete () Leaving MESSAGE_Delete () ==================================================== root@mityomapl138:~#
I can start up gdbserver on the target with the app I want to debug and then enter debug mode in Eclipse. At that point Eclipse connects up to the remote app running on the target mityOmap and highlights the first line of code in the program. If I tell Eclipse to resume execution with no breakpoints set, the program runs to completion normally, except that at the end of the program, control doesn't return back to Eclipse and the program seems to be hung up somewhere. In this case the output looks like:
root@mityomapl138:~# gdbserver :1000 ./DspMessage message.out 100 0 ========== Sample Application : MESSAGE ========== Entered MESSAGE_Create () Leaving MESSAGE_Create () Entered MESSAGE_Execute () Transferring 100 iterations took 0 seconds 41706 microseconds. RoundTrip Time for 1 message is 417 microseconds. Leaving MESSAGE_Execute () Entered MESSAGE_Delete () Leaving MESSAGE_Delete ()
Note that it doesn't return to the system prompt and Eclipse is unable to gain control also.
If I put in a breakpoint as I mentioned above, right past the call to PROC_attach, the system seems to stop at the breakoint, but control isn't returned to eclipse. The output then looks like:
root@mityomapl138:~# gdbserver :1000 ./DspMessage message.out 100 0 ========== Sample Application : MESSAGE ========== Entered MESSAGE_Create ()
Thanks!
-Rich Bagdazian
RE: dsplink debugging issue - Added by Michael Williamson over 13 years ago
You might try to compile the dsplink libraries in debug mode and then step into the PROC_attach and see what's going on. If I get a chance I'll try it here as well.
-Mike
RE: dsplink debugging issue - Added by Rich Bagdazian over 13 years ago
Good idea. I'll see what I can find out.
-rb
RE: dsplink debugging issue - Added by Rich Bagdazian over 13 years ago
Hi Mike
I think I have a handle on what's going on.
The system seems to go into limbo immediately after a call to pthread_create() inside a function called _NOTIFY_Init in _notify.c module, which is part of the dsplink library. It seems that with another thread running (after the call to pthread_create) gdb loses track of what's going on. I'm not enough of an internals expert to know what to do about this.
-Rich
RE: dsplink debugging issue - Added by Michael Williamson over 13 years ago
Rich,
Are you using the gdbserver that you built or the one from opkg? You should be able to do thread level debugging. I'll see if I can reproduce. Keep in mind on the eclipse context that multiple threads can be running, and if you break/pause, you have to make sure that you select the correct thread context to debug....
-Mike
RE: dsplink debugging issue - Added by Rich Bagdazian over 13 years ago
Hi Mike,
I'm using the gdbserver that I built since my company has me behind a firewall and won't recognize the mityOmap as an authorized machine. :-(
Anyway, I didn't see anything related to multiple threads in Eclipse and how to switch execution threads, but could be the problem. Everything seems to work ok until a new thread is started up.
Thanks,
Rich
RE: dsplink debugging issue - Added by Rich Bagdazian over 13 years ago
Hi Mike,
Just before I hit the call to pthread_create, I added a breakpoint at the entry point of the new thread and also a break point right after the call to pthread_create. Then, when I hit resume, the breakpoint inside the new thread triggered and then when I hit resume again, the breakpoint in the mainline code was hit. Then hitting resume one more time allowed the system to run to completion. I'm curious if the opkg dbgserver exhibits the same behavior. Can you email me the appropriate gdbserver for the target and gdb for the host as a tar file since I can't use opkg at the current time?
Thanks!
Rich
RE: dsplink debugging issue - Added by Susan Begley about 13 years ago
Was this issue ever resolved? I am running into the same problem.
Thanks,
Susan
RE: dsplink debugging issue - Added by Michael Williamson about 13 years ago
Hi Susan,
It looks like Richard raised this issue on the TI E2E site, here:
http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/57359.aspx
The solution appears to be to upgrade to DSPLINK 1.65. We're working on building/testing the latest version of DSPLINK and will post any lessons learned about that in the dsplink page on our wiki, but I don't expect there to be anything outside what the TI build instructions require you to do. You just need to build the kernel module against the version of the kernel you are working with. If you need an immediate fix, you might try to download the latest version and build/use it and see if the problem clears up.
-Mike
