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.

How to debug SYSBIOS + IPC DSP program with CCSV5.1?

Other Parts Discussed in Thread: SYSBIOS, CCSTUDIO

Hi,

I have a C6A8168 EVM board, ti-ezsdk_dm816x-evm_5_03_01_15 software package on CentOS 5.8 and CCSV5.1 on Windows XP.

I have built the MessageQ example program for the ARM on Linux and for DSP on Windows. Linux part was built on Linux with makefiles and it included use of Linux and SYSLINK (ProgMgr and SlaveLoader and IPC). DSP part of the messageQ program was built with CCSV5.1 on Windows.  My goal is to be able to debug my DSP program with CCSV5.1 on Windows. After I run the Linux program which loads and runs the DSP program, I put the Linux program into idle so that I can connect to DSP from the Windows side with CCSV5.1. I was able to load the DSP image into memory and the program counter reached main() of my DSP program. But single step will not get over the Ipc_start() routine because the ARM has been put in idle and won't respond to the Ipc_start() from DSP side (I guess). So my question is how can I debug my DSP program that requires the DSP to run a Receive Task and a Transmit Task if it can not pass the Ipc_start() routine in the main()?

The main program is attached below:

/*

* ======== main ========

*/

Int main(Int argc, Char* argv[])

{

Int status = Ipc_S_SUCCESS;

do {

/* Call Ipc_start() */

status = Ipc_start();

}

while (status != Ipc_S_SUCCESS);

BIOS_start();

return (0);

}

 

Thanks,

Zhao

  • I've heard that the usual debug practice is to:

    1) add a "while(1) ;" loop to main() in the DSP program.

    2) Then allow the ARM to bring up the DSP.

    3) Then attach to the DSP (while leaving the ARM running).

    4) Then force the program counter past the while(1) loop, and continue on.

    Alan

  • Zhao,

    On the host side (Linux program), I use the getchar() function to pause the execution flow to give me time to attach CCS to the DSP.

    printf("Press Enter to continue");
    getchar();

    Adding these two statements is usually sufficient but if you want to pause the DSP executable as well, add a spin loop like this (as suggested by Alan).

    { volatile int spin = 1; while(spin); }

    The volatile keyword is important, it will prevent the optimizer from removing it. The  braces let you add this code multiple times without conflicts. When you enter the loop, simply pause the DSP and use the variable window in CCS to set spin=0. When you run the DSP it will exit the loop and continue.

    ~Ramsey

  • Ramsey, Alan,

    Thanks for your suggestions! I will give them a try. I bet they would work.

    I got two warnings during the compilation (as below) of the DSP program. How can I get rid of the first warning? Where is .plt section used?

    As to the second warning, why does the program use "ti_sysbios_family_c64p_Hwi0" instead of usual "_c_int00" entry point? What is the "ti_sysbios_family_c64p_Hwi0"?

    Thanks,

    Zhao

    **** Build of configuration Debug for project DSP_MSGQ_Reply ****

    C:\CCStudio_v5.1.1.00028\ccsv5\utils\bin\gmake -k all

    'Building file: ../MessageQ_ti81xx_dsp.cfg'

    'Invoking: XDCtools'

    "C:/CCStudio_v5.1.1.00028/xdctools_3_22_04_46/xs" --xdcpath="C:/CCStudio_v5.1.1.00028/ipc_1_23_05_40/packages;C:/CCStudio_v5.1.1.00028/bios_6_32_05_54/packages;C:/CCStudio_v5.1.1.00028/syslink_2_00_05_85_2/packages;C:/Documents and Settings/ZhaoLi/myRepository/packages;" xdc.tools.configuro -o configPkg -t ti.targets.elf.C674 -p ION_E_DSP2 -r debug -c "C:/CCStudio_v5.1.1.00028/ccsv5/tools/compiler/c6000" "../MessageQ_ti81xx_dsp.cfg"

    making package.mak (because of package.bld) ...

    generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...

    configuring MessageQ_ti81xx_dsp.xe674 from package/cfg/MessageQ_ti81xx_dsp_pe674.cfg ...

    cle674 package/cfg/MessageQ_ti81xx_dsp_pe674.c ...

    'Finished building: ../MessageQ_ti81xx_dsp.cfg'

    ' '

    'Building file: ../DspAppMsg.c'

    'Invoking: C6000 Compiler'

    "C:/CCStudio_v5.1.1.00028/ccsv5/tools/compiler/c6000/bin/cl6x" -mv6740 -g --include_path="C:/CCStudio_v5.1.1.00028/ccsv5/tools/compiler/c6000/include" --display_error_number --diag_warning=225 --abi=eabi --preproc_with_compile --preproc_dependency="DspAppMsg.pp" --cmd_file="./configPkg/compiler.opt" "../DspAppMsg.c"

    'Finished building: ../DspAppMsg.c'

    ' '

    'Building file: ../MessageQApp.c'

    'Invoking: C6000 Compiler'

    "C:/CCStudio_v5.1.1.00028/ccsv5/tools/compiler/c6000/bin/cl6x" -mv6740 -g --include_path="C:/CCStudio_v5.1.1.00028/ccsv5/tools/compiler/c6000/include" --display_error_number --diag_warning=225 --abi=eabi --preproc_with_compile --preproc_dependency="MessageQApp.pp" --cmd_file="./configPkg/compiler.opt" "../MessageQApp.c"

    'Finished building: ../MessageQApp.c'

    ' '

    'Building target: DSP_MSGQ_Reply.out'

    'Invoking: C6000 Linker'

    "C:/CCStudio_v5.1.1.00028/ccsv5/tools/compiler/c6000/bin/cl6x" -mv6740 -g --display_error_number --diag_warning=225 --abi=eabi -z -m"DSP_MSGQ_Reply.map" --warn_sections -i"C:/CCStudio_v5.1.1.00028/ccsv5/tools/compiler/c6000/lib" -i"C:/CCStudio_v5.1.1.00028/ccsv5/tools/compiler/c6000/include" --reread_libs --rom_model -o "DSP_MSGQ_Reply.out" -l"./configPkg/linker.cmd" "./MessageQApp.obj" "./DspAppMsg.obj" -l"libc.a"

    <Linking>

    warning #10247-D: creating output section ".plt" without a SECTIONS

    specification

    warning #10063-D: entry-point symbol other than "_c_int00" specified:

    "ti_sysbios_family_c64p_Hwi0"

    'Finished building target: DSP_MSGQ_Reply.out'

    ' '

    **** Build Finished ****

  • Zhao,

    These two linker warnings are safe to ignore. The 'warning #10247' results from some code explicitly being placed in a section called ".plt", but at link time the linker was not told where to place that section. The linker will by default create an output section by the same name. The 'warning #10063' comes from SysLink linker command directive. It was decided to use the reset vector as the program entry point. We are working to eliminate these warnings in future releases.

    ~Ramsey