Debugging the MessageQ Application, Built in Linux EZSDK, Debugged in Windows CCS 4

Continued thread from:

http://e2e.ti.com/support/dsp/integra_dsparm/f/625/p/109185/400422.aspx#400422

MugdhaK said:

The picture of the debug window you showed is good ... it means that the DSP is up and blocked on something (in Idle task). It does show that symbols have been properly loaded, otherwise you would not have seen what you've shown here. If you want to debug something in your application after this, you may want to now open your application source file in CCS, put a breakpoint in your application (that comes after whatever you've been waiting on is unblocked), and proceed further from Linux-side -- run whatever you need to run to start communicating with the DSP.

You should see the breakpoint getting hit. If your symbols are loaded correctly, you will be able to set a breakpoint. Otherwise the breakpoint setting itself will fail.

If you want to debug before you reach the idle task, you'll have to stop somewhere ealier in your application. The way we do it is to add the following in main (say after Ipc_start) or in our application task, essentially wherever we want to debug from.

{

volatile int haltIt = 1;

while (haltIt);

}

Then when I connect to DSP and load symbols, if I've set my source lookup correctly, this file will open in CCS, and I will see that I'm spinning here. I just go ahead and change the value of 'haltIt' to 0 in watch window and then step through. At that point, I can set break-points anywhere I want, or even step through all the way if I so wish.

Making haltIt volatile ensures that if you're in release build with symbols, the compiler won't optimize out all the code after this, and also using a variable ensures that you can safely move ahead by changing the value in watch window (instead of directly using while (1)).

Regards,
Mugdha

Hi Mugdha,

I didn't set any breakpoints but I successfully set my path for the context of the debug session and clicking on any of the threads caused the appropriate source file to be automatically loaded.

Now, the problem is when I run messageqapp.exe from the command line on Linux I get (yes I did already use procmgrapp.exe to load the DSP binary):

# ./messageqapp.exe

MessageQApp sample application
MessageQApp_startup entered
Loading and starting procId [0] with [(null)]
Entered ProcMgrApp_startup
ProcMgr_attach status: [0x0]
After attach: ProcMgr_getState
    state [0x1]
Segmentation fault

To be honest, I get this whether I'm debugging or just running the program as usual. I'd like to point out that the program runs fine if I just do "/messageqapp.exe 0 messageq_ti81xx_dsp.xe674".

Any ideas what's going wrong? Is it just a fault with procmgrapp perhaps?

Thanks,

Ralph