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.

Statically link and configure SYSLINK in a library

Other Parts Discussed in Thread: OMAP-L137, SYSBIOS

Hello,

i am trying to build a static DSP library for the DSP of an OMAP-L137 with CCS. The library uses SYSLINK for communication to the ARM processor. This library shall be used in a DSP application, which is build on a PC without a SYSLINK installation. Only the basic CCS installation (with e.g. BIOS and IPC) is present on this build PC.

Now my question: Is it possible to build this library in a way, so that SYSLINK is not required on the build platform, which builds the DSP application? And is it required to add the SYSLINK specific configuration to the *.cfg file when building the DSP application, or is it sufficient to have that *.cfg file during build of the library?

Best regards,

Dom

  • Dom,

    You may be able to do this if you are not using SysLink's RingIO or FrameQ.  Also, in the DSP side's .cfg file, you would normally have the line:

    xdc.useModule('ti.syslink.ipc.rtos.Syslink');

    This causes the causes the SysLink_attach() function to get called (code from ti/syslink/ipc/rtos/Syslink.xs):

    function module$use()
    {
        var Ipc;
        Ipc = xdc.useModule ('ti.sdo.ipc.Ipc');

        var fxn = new Ipc.UserFxn;
        fxn.attach = '&ti_syslink_ipc_rtos_Syslink_attach';
        fxn.detach = null;
        Ipc.addUserFxn(fxn, null);
    }

    In addition, these options are given to the linker (from ti/syslink/ipc/rtos/linkcmd.xdt):

        --dynamic
        --retain=_Ipc_ResetVector

    So you would need to set these yourself.  We haven't tried out this build scenario, as this is not a typical use case.  Is there any particular reason for not installing SysLink on the build platform?

    Best regards,

        Janet

  • Janet,

    thanks for your reply. First of all, the scenario is used to buil a kind of communication library and to deliver it to e.g. a customer. So the customer does not have to deal with SYSLINK and can focus on other things on the DSP. So it shall ease the install and build process of the customer.

    I tried to use your suggestions above and i think on the application build it seems to work. But i think i have to ensure that the afforded sysmbols are linked to the library now, because they cannot be linked duting the application link process. I get a linking error when building the application:

    <Linking>

     undefined                          first referenced                                                                                           
      symbol                                in file                                                                                                
     ---------                          ----------------                                                                                           
     ti_syslink_ipc_rtos_Syslink_attach /home/charlie/workspace_v5_2/TestCcmComWithoutSyslink/Release/configPkg/package/cfg/CCM-221_DSP_pe674.oe674

    error #10234-D: unresolved symbols remain

    In my opinion this is a result of missing linking syslink components to the library, am i right? So which component do i need to additionally link to my labrary to have this symbol defined?

    Best regards,

    Dom

  • Dom,

    That symbol is in ti.syslink.ipc.rtos.ae674 (located in ti/syslink/ipc/rtos/lib).

    Best regards,

        Janet

  • Thanks Janet.

    I tried the following steps:

    - get the ti.syslink.ipc.rtos.a674 and copy it to my application build project in CCS

    - rename ti.syslink.ipc.rtos.a674 to ti.syslink.ipc.rtos.a

    - build the application, all symbols can be resolved now, so the linking error of my previous post is fixed

    Everything is fine until this step. But when i try to load this application from the ARM, the ARM hangs during Ipc_control(remoteProcId, Ipc_CONTROLCMD_STARTCALLBACK, NULL). When i go some steps backwards and allow the appliaction to link against SYSLINK itself by removing the steps you mentioned above, the appliaction runs fine.

    I do not know if my steps to link the application against ti.syslink.ipc.rtos.a674 are correct or do i have a different problem here?

    Best regards,

    Dom

  • Dom,

    Maybe you can turn on SysLink trace to find the problem.  You can do this by:

        insmod syslink.ko TRACE=1 TRACEFAILURE=1 TRACECLASS=3

    Best regards,

        Janet

  • Hello Janet,

    when the ARM hangs during DSP start process of "Ipc_CONTROLCMD_STARTCALLBACK" the trace prints "Ipc_attach: Ipc_procSyncStart failed!". I dont know whether this information is helpful. I reduced my ARM and DSP applications to simply load, start and stop the DSP but i have the same result. When using the standard way by adding SYSLINK to the application build the program works. When i use the way described above, the program hangs. Is there anything that we may have forgotten? I do not really know how to debug this problem at this point.

    Best regards,

    Dom

  • Dom,

    Could you try adding:

    -eti_sysbios_family_c64p_Hwi0

    to your LDFLAGS?  I found this one in ti/syslink/ipc/rtos/linkcmd.xdt and I think that may be causing Ipc_attach() to fail.

    Best regards,

        Janet

  • Janet,

    yes thats it. With a minor correction, i have used "-e_ti_sysbios_family_c64p_Hwi0" to define the etnry point. then my appliction links with the warning:

    <Linking>
    warning #10063-D: entry-point symbol other than "_c_int00" specified:
       "_ti_sysbios_family_c64p_Hwi0"
    Finished building target: CcmComExample.out

    which is OK (see http://processors.wiki.ti.com/index.php/Troubleshooting_SysLink_Build_Issues). Then the DSP application can successfully be loaded, started and stopped from the ARM processor.

    Thank you very much for your help!

    Best regards,

    Dom