• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 527 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Building DSP-side Syslink applications with CCS

Günter
Intellectual 460 points
Other Parts Discussed in Thread: SYSBIOS

Is it possible to create a Syslink DSP-side application as a CCS project, without the need of a) defining a package and b) calling XDC for build? I do not (yet) want to create XDC packages when I create my own application. Reading through the RTSC primers, XDC build shouldn't be necessary for a 'package consumer'. I've successfully tried to re-create the shared region sample under CCS v5, but the message queue sample reports unresolved symbols, see build log at the end of the article. The generated C file from configuration is exactly the same as the one of the original sample when built with XDC, except for one line that specifies the assembly directory, which is obviously not the problem. Changing the RTSC Build-profile from the default 'whole_program' to debug makes compilation run, but generates the following remark: remark: the selected profile (debug) does not generate optimized code. 'debug' and 'release' profiles should only be used for source-level debugging of BIOS code. While these profiles build faster, the code runs slower and requires extra stack space. 'whole_program' profile is recommended for optimized code. Changing RTSC Build-profile again by manually entering whole_program_debug (which fits the original XDC build) again results in the unresolved externals. I guess it has to do with tool options and probably optimizing out too much. I'm using EZSDK 5.0.0.56 under Ubuintu 10.04. Project may be attached or not; not sure whether upload worked. Here's the build log: **** Build of configuration Debug for project test_message_queue **** /usr/local/CCSv5/ccsv5/utils/gmake/gmake -k all Building file: ../main.cfg Invoking: XDCtools "/home/guenter/xdctools_3_20_07_86/xs" --xdcpath="/home/guenter/ti-ezsdk_c6a816x-evm_5_00_00_56/syslink_02_00_00_56;/home/guenter/ti-ezsdk_c6a816x-evm_5_00_00_56/sysbios_6_31_00_06_eng/packages;/home/guenter/ti-ezsdk_c6a816x-evm_5_00_00_56/ipc_1_22_00_10_eng/packages;" xdc.tools.configuro -o configPkg -t ti.targets.elf.C674 -p ti.syslink.samples.rtos.platforms.ti816x.dsp -r whole_program -c "/home/guenter/ti-ezsdk_c6a816x-evm_5_00_00_56/cgt6x_7_2_0" "../main.cfg" making package.mak (because of package.bld) ... generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ... configuring main.pe674 from package/cfg/main_pe674.cfg ... cle674 package/cfg/main_pe674.c ... lnke674 main.pe674 ... "package/cfg/main.pe674.se674", WARNING! at line 36749: [W9999] Placing data in a code section (.text) is discouraged. The data may be interpreted as code. This section will not be compressed. b _c_int00 No Assembly Errors, 1 Assembly Warning Finished building: ../main.cfg Building file: ../main.c Invoking: C6000 Compiler "/home/guenter/ti-ezsdk_c6a816x-evm_5_00_00_56/cgt6x_7_2_0/bin/cl6x" -mv6740 -g --include_path="/home/guenter/ti-ezsdk_c6a816x-evm_5_00_00_56/cgt6x_7_2_0/include" --diag_warning=225 --abi=eabi --preproc_with_compile --preproc_dependency="main.pp" --cmd_file="./configPkg/compiler.opt" "../main.c" Finished building: ../main.c Building target: test_message_queue.out Invoking: C6000 Linker "/home/guenter/ti-ezsdk_c6a816x-evm_5_00_00_56/cgt6x_7_2_0/bin/cl6x" -mv6740 -g --diag_warning=225 --abi=eabi -z -m"test_message_queue.map" --warn_sections -i"/home/guenter/ti-ezsdk_c6a816x-evm_5_00_00_56/cgt6x_7_2_0/lib" -i"/home/guenter/ti-ezsdk_c6a816x-evm_5_00_00_56/cgt6x_7_2_0/include" --reread_libs --rom_model -o "test_message_queue.out" -l"./configPkg/linker.cmd" "./main.obj" -l"libc.a" warning: creating output section ".plt" without a SECTIONS specification undefined first referenced symbol in file --------- ---------------- ti_sysbios_knl_Semaphore_Params__init__S ./main.obj ti_sysbios_knl_Semaphore_post__E ./main.obj xdc_runtime_Error_init__E ./main.obj error: unresolved symbols remain warning: entry-point symbol other than "_c_int00" specified: "ti_sysbios_family_c64p_Hwi0" error: errors encountered during linking; "test_message_queue.out" not built >> Compilation failure make: *** [test_message_queue.out] Error 1 make: Target `all' not remade because of errors.
  • 0
    TI__Genius 17205 points

    Based on these errors...

    Günter said:
    undefined first referenced symbol in file --------- ---------------- ti_sysbios_knl_Semaphore_Params__init__S ./main.obj ti_sysbios_knl_Semaphore_post__E ./main.obj xdc_runtime_Error_init__E ./main.obj

    Try adding the following to your .cfg script:

    xdc.useModule('ti.sysbios.knl.Semaphore');
    xdc.useModule('xdc.runtime.Error');

    It's probably stated in the BIOS Users Guide, but the rule of thumb to follow is...

    If your c file does this:              #include <some/package/Module.h>

    Your cfg script must do this:          xdc.useModule('some.package.Module');

    Chris

  • 0 in reply to Chris Ring
    Intellectual 460 points
    Adding these statements does indeed remove the errors. I did not check such issues, as I was using existing sample code, assuming it was written correctly. So it seems that there is a problem in the original sample code. Maybe someone of the EZSDK/syslink people can have a look at it. The original sample is in ti-ezsdk_c6a816x-evm_5_00_00_56/syslink_02_00_00_56/ti/syslink/samples/rtos/messageQ. However: building the sample code under XDC works, so the missing packages seem to be included from somewhere else. I've tried again as follows: - copy ti-ezsdk_c6a816x-evm_5_00_00_56/syslink_02_00_00_56/ti/syslink/samples/rtos/messageQ to some local folder - remove other platforms from package.bld and remove their specific folders - merge common and platform-specific configuration into one single file and update package.bld accordingly - build using XDC Result is that the build works without problems. So there is definitley a difference whether building the package from a producer's side (using XDC) or from a consumer's side (CCS-based build using xdctool's configuro as first step). thanks so far Guenter P.S. Sorry for the bad formatting (at least in first post); my browser seems to have problems with this page.