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.

Symbol CLK_F_itime (CCS migration to 5.1, BIOS 5.41)

My issue is similar to the following post: http://e2e.ti.com/support/embedded/bios/f/355/t/184383.aspx

I recently upgraded a project from CCS 3.3 to CCS 5.1 and used the CDB2TCF conversion tool to update the configuration file. I encounter no errors during compilation, but when linking in the BIOS files I get the following error:

>> Compilation failure
 undefined   first referenced                                            
  symbol         in file                                                 
 ---------   ----------------                                            
 CLK_F_itime C:/ti/bios_5_41_13_42/packages/ti/bios/lib/bios.a62<swi.o62>

error #10234-D: unresolved symbols remain

The CLK_F_itime symbol is defined in an assembly header among the BIOS package files, but the linker doesn't seem to find it. Based on a bit of research, my current guess is that the tcf file is missing some line that would point the linker in the right direction, but am too unfamiliar  with tcf files to know what this might be.

Any ideas?

  • Christopher,
    what's the device and the platform you are building for? These settings are usually defined by the line in the TCF script that often looks like this:
    utils.loadPlatform("ti.platforms.evmDM6437");
    or it could be
    utils.loadPlatform("ti.platforms.generic", params);
    where 'params' are defined in the preceding lines.
    Depending on these settings, a library that contains the function CLK_F_itime is linked in.

    If you post here these lines from your TCF script, I should be able to reproduce the problem.

  • Sasha,

    Sorry for the slow response - apparently my company's e-mail server decided forum notification e-mails were spam :(

    I'm building for a TMS320C6713, and the related lines from the tcf file are:

    /* loading the generic platform */
    var params = {};
    params.clockRate = 200;
    params.deviceName = "6713";
    params.catalogName = "ti.catalog.c6000";
    params.regs = {};
    params.regs.l2Mode = "SRAM";
    utils.loadPlatform("ti.platforms.generic", params);

    Let me know if there's any other information that you need.

    Thanks,

    -Chris

  • Chris,
    in your project in the directory Debug (or Release), there is a file with the extension .cmd. Open that file and search for "priority". You should be able to find a piece of the file that looks like this:
    -priority
    --trampolines
    -llnkrtdx.a67
    -ldrivers.a67         /* device drivers support */
    -lsioboth.a67         /* supports both SIO models */
    -lbiosC6000.a67       /* BIOS clock specific library */
    -lbios6x1x.a67        /* BIOS c6x1x specific library */
    -lbios.a67            /* DSP/BIOS support */
    -lrtdxsim.lib         /* RTDX support */
    -lrts6700.lib         /* C and C++ run-time library support */

    I built an app for 6713, and that's what I have in my .cmd file. The symbol that the linker cannot find comes from biosC6000 library. Can you post the same part of your .cmd file, so I can check which libraries are referenced?

    Also, your error message indicates that you are using bios.a62 library instead of bios.a67. I am using the same version of DSP/BIOS as you are, but I can't replicate that problem. Is there any reference in your TCF script to a property "DSPTYPE" or "DSPSUBTYPE"?  

    Finally, in the same directory where you found .cmd file there is another file with the extension .cdb. Can you open it in a text editor and check the second line that looks like this:
    //# c6x1x.cdb 5.25.36

    What's the content of that line in your file?

  • Sasha,

    While going through the items you've requested, I've noticed that a lot of references to DSP part numbers are inter-mixed between the 6200 series and the 6700 series... The original code was (for some reason - I was not involved with the original development) built this way, and seems to work fine. Do you have any concerns with the inter-mixing of libraries like this?

    Anyways, the priority section of my command file is as follows:

    -priority
    -llnkrtdx.a62
    -ldrivers.a67          /* device drivers support */
    -lsioboth.a62          /* supports both SIO models */
    -lbios.a62             /* DSP/BIOS support */
    -lrtdx.lib             /* RTDX support */
    -lcsl6713.lib
    -lrts6700.lib          /* C and C++ run-time library support */

    Adding a line for the biosC6000.a67 (or biosC6000.a62) resolves the error. Were the references to clocks split into a new library file between the days of CDBs and now? I was unaware that there was another library there! Regardless of this (relatively simple) fix, I'll copy in the rest of the information requested for reference.

    There isn't anything on DSPTYPE or DSPSUBTYPE in the TCF file, but in the original CDB file there was the following:

        global DSPTYPE :: 62 {
            prop Type :: "{21455EA2-B96A-11cf-9BFE-0000C0AC14C7}"
            prop Label :: "DSP Major Type"
            prop JSName :: "DSPTYPE"
            prop Visible :: 0
            prop Writable :: 0
            prop NoGen :: 1
        }
        global DSPSUBTYPE :: 6711 {
            prop Type :: "{A11FE980-C07A-11cf-9BFE-0000C0AC14C7}"
            prop Enum :: "6211,6711"
            prop Label :: "DSP Type"
            prop Visible :: 1
            prop Writable :: self.CHIPTYPE == "other" || self.CHIPTYPE == "custom"
            prop Set :: (self.DSPSUBTYPE = $1, self.L2Check(), "ok")
            prop NoGen :: 1
        }
        global CHIPTYPE :: "6713" {
            prop Type :: "{21455EA1-B96A-11cf-9BFE-0000C0AC14C7}"
            prop Enum :: "6211,6711,6712,6713,DA610,custom,other"
            prop Label :: "Chip Support Library (CSL)"
            prop JSName :: "CHIPTYPE"
            prop NoGen :: 1
            prop Visible :: 1
            prop Writable :: 1
            prop Set :: (if ($1 == "6201" || $1 == "6202" || $1 == "6203" || $1 == "6204" || $1 == "6205") {self.DSPSUBTYPE = 6200} else {if ($1 == "6701") {self.DSPSUBTYPE = 6700} else {if ($1 == "6211") {self.DSPSUBTYPE = 6211} else {if ($1 == "6711" || $1 == "6712" || $1 == "6713" || $1 == "DA610") {self.DSPSUBTYPE = 6711} else {if ($1 == "DM642" || $1 == "6412" || $1 == "6414" || $1 == "6415" || $1 == "6416") {self.DSPSUBTYPE = 6400} }}}}, self.CHIPTYPE = $1, self.CSLNAME = self.setCSLNAME(), if (self.CHIPTYPE == "other" || self.CHIPTYPE == "custom") {self.C621XL2CONFIGURE = 0, self.C641XL2CONFIGURE = 0, self.L2CONFIGURE = 0} , self.L2Check(), $e = "ok", if (GBL.CHIPCHAIN != nil) {$e = GBL.CHIPCHAIN.chipcall()} , $e)
        }

    This seems very interesting... These property settings seem like a bit of a mess. I'm guessing, but DSPTYPE should probably be 67 and DSPSUBTYPE should be 6713. Might this conflict be the source of the hodgepodge of DSP part numbers in linked libraries?

    Finally, the CDB I'm using seems to have been  edited by hand by the original developer of the code, so the version number might not tell the whole tale. In either case, the line in question is:

    //# c6x1x.cdb 4.90.270

    Let me know if you have any other advice (with regards to the library mixing) or general tips on the matter.

    Thanks,

    -Chris

  • Chris,
    it's good that you can build finally but you should not have to add biosC6000.a67 manually. Many of the problems you posted indicate that you are not really using DSP/BIOS 5.41.13.42. The CDB file under Debug should be created automatically by DSP/BIOS and should have today's (or recent) modification date, and should have version 5.xx. In DSP/BIOS 5, your only configuration source is the TCF script, the CDB file is created automatically and only reflects the content of the TCF script.

    I think your problems are caused by the mix of files from different DSP/BIOS versions and we need to figure out that first. Even though your build succeeded, a mix of files form various DSP/BIOS versions could cause problems that are difficult to debug.

    Can you build again and post the complete content of the Console Window? Can you also check the modification date on the generated CDB file? But before all that, if you have any other DSP/BIOS installation on your PC can you rename them by adding .hide to their names, for example? Don't remove them before you get a valid build using only DSP/BIOS 5.41.13.42.

    I am mostly interested in the command line that displays your config.importPath and the source of the tconf executable:
    'Invoking: TConf'
    "C:/ccsproducts/xdctools_3_23_04_60/tconf" -b -Dconfig.importPath="C:/ccsproducts/bios_5_41_13_42/packages;" "../hello.tcf"
    'Finished building: ../hello.tcf'

     

  • Sasha,

    Well, I'm using a custom linker script inherited from the original project - not the generated one. So, any library changes such as this would require me to update the library link list manually. With regards to the CDB file, the project started out with -only- a CDB file, and I generated the TCF from this using the updater tool in {TI_ROOT}\bios_5_41_13_42\packages\ti\bios\config\update ...

    I've gone through the link search directories for the project and made sure that only the 5.41.13.42 BIOS libraries are used, so I don't think there's any way for other BIOS versions to be involved... My main concern is whether using the C6200 and C6700 libraries intermixed for a C6713 will cause any issues, as this is how the custom linker script was written when I received it.

    Either way, the command line for invoking TConf is as follows (path/name of TCF file redacted):

    'Building file: [REDACTED].tcf'
    'Invoking: TConf'
    "C:/ti/xdctools_3_23_03_53/tconf" -b -Dconfig.importPath="C:/ti/bios_5_41_13_42/packages;" "[REDACTED].tcf"
    'Finished building: [REDACTED].tcf'

    Thanks,

    -Chris

  • Ok, that makes more sense now. The custom linker script was probably created before we had a separate clock library, so that's why that library was missing.
    C62 and C67 are very similar, and a C67 CPU can run C62 code. However, DSP/BIOS 5.41.13.42 contains C67 versions of all C62 libraries that you are using. I think you should switch to C67 libraries because you'll get more efficient code, but as I said C62 libraries should work fine too