Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

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

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 ()

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

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

Good idea. I'll see what I can find out.
-rb

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

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

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

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

Was this issue ever resolved? I am running into the same problem.

Thanks,
Susan

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