• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 101 subscribers
  • Views 434 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Syslink debug problem

Alexander Zhu
Prodigy 70 points

I have a syslink program on DM8168.

When I run it, it works well. But when I debug it (gdbserver to debug arm, emulator to debug dsp), it gets something wrong.  The Ipc_start function keeps returning Ipc_E_NOTREADY on dsp side, and arm side get stuck on Ipc_control(remoteProcId, Ipc_CONTROLCMD_STARTCALLBACK, NULL )

My Debug steps:

1. use salverloader to startup dsp

2. launch target configuration

3. connect C674X

4. load dsp program

5. run gdbserver on arm

I found if I turn dsp program optimization level from O3 to NULL, it gets work.

But I still don't know what's wrong with it.

Can anyone help?

-------------------------------------------------------------------------------------

Here is my platform information:

CCS5.5  linux

xdctools 3.25.05.94

syslink 2.21.03.11

ipc 1.25.03.15

bios 6.35.04.50

workspace_v5_5.tar.gz
  • 0
    TI__Genius 12865 points

    Hi Alexander,

    In general, it is difficult to step through code that has been highly optimized with -o3, as the order in which the code is executed may not directly match the source lines, and some code might have been optimized out entirely. I think you said the code runs correctly when built with -o3 and when you do not hook it up to the debugger. Is that correct? Have you tried linking in the debug version of the Ipc libraries (while building the application with -o3) so that you can step through the Ipc_start() function and see if you can find out which condition triggered the Ipc_E_NOTREADY return code?

    Make sure in step 4 you are simply loading the *symbols* of the DSP program and not reloading the entire binary using CCS, Slaveloader should have already loaded and started the DSP at that point.

    In case you haven't seen this already, here's a good link that describes how to debug the slave cores using CCS:

    http://processors.wiki.ti.com/index.php/CCS_Debugging_of_Linux_Applications_with_GDB#Debugging_slave_cores_running_SysBios

    Best regards,

    Vincent