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.

Compiler/TMS320C6713B: How to re-build the CSL library

Part Number: TMS320C6713B


Tool/software: TI C/C++ Compiler

dsk6713bsl_test.zipTMS320C6713
Spectrum Digital DSK6713

I am building a simple app that reads a MEM Mic from McBSP0.

I want to use APIs MCBSP_open(), MCBSP_read(), MCBSP_write(), MCBSP_close().

I included libraries:

libc.a
"E:\ti\C6xCSL\lib_3x\csl6713.lib" TMS320C6000 Chip Support Library (CSL), v2.31.00.16 April 5, 2006.
"E:\ti\dsk6713\lib\dsk6713bsl.lib" Spectrum Digital DSK6713 library

In CCS Version: 7.2.0.00013, I Rebuild the project.
I got warnings about the csl6713.lib and dsk6713bsl.lib libraries.

'Building target: mems_mics.out'
'Invoking: C6000 Linker'
"E:/ti/ccsv7/tools/compiler/c6000_7.4.22/bin/cl6x" -mv6700 --abi=coffabi -g --define=CHIP_6713 --define=c6713 --diag_wrap=off --diag_warning=225 --display_error_number -z -m"mems_mics.map" --stack_size=0x800 --heap_size=0x800 -i"E:/ti/ccsv7/tools/compiler/c6000_7.4.22/lib" -i"E:/ti/ccsv7/tools/compiler/c6000_7.4.22/include" --reread_libs --diag_wrap=off --warn_sections --display_error_number --xml_link_info="mems_mics_linkInfo.xml" --rom_model -o "mems_mics.out" "./board_config.obj" "./main.obj" "../C6713.cmd" -llibc.a -l"E:/ti/C6xCSL/lib_3x/csl6713.lib" -l"E:/ti/dsk6713/lib/dsk6713bsl.lib"
<Linking>
warning #16002-D: build attribute vendor section TI missing in "E:/ti/C6xCSL/lib_3x/csl6713.lib<csl_emif.obj>": compatibility cannot be determined
warning #16002-D: build attribute vendor section TI missing in "E:/ti/C6xCSL/lib_3x/csl6713.lib<csl_mcbsp.obj>": compatibility cannot be determined
warning #16002-D: build attribute vendor section TI missing in "E:/ti/C6xCSL/lib_3x/csl6713.lib<csl_pll.obj>": compatibility cannot be determined
warning #16002-D: build attribute vendor section TI missing in "E:/ti/C6xCSL/lib_3x/csl6713.lib<csl_irq.obj>": compatibility cannot be determined
warning #16002-D: build attribute vendor section TI missing in "E:/ti/dsk6713/lib/dsk6713bsl.lib<dsk6713_dip.obj>": compatibility cannot be determined
warning #16002-D: build attribute vendor section TI missing in "E:/ti/dsk6713/lib/dsk6713bsl.lib<dsk6713_led.obj>": compatibility cannot be determined
warning #16002-D: build attribute vendor section TI missing in "E:/ti/dsk6713/lib/dsk6713bsl.lib<dsk6713.obj>": compatibility cannot be determined
'Finished building target: mems_mics.out'

My customer requires a project that has no suppressed warnings, so I can't use --diag_suppress=16002


I created a dsk6713bsl project from the dsk6713bsl source.
The C6000 Compiler flags were added: -mc6713
The new dsk6713bsl.lib links without the warnings.
The dsk6713bsl functions appear to be working as expected.


I created a CCS project from the CSL source.
The C6000 Compiler flags were added: -mc6713 and --define==CHIP_6713
The new csl6713.lib links without the warnings.


But now the program dies a call to puts().
It looks like puts() comes from liba.lib which is built from:
ti\ccsv7\tools\compiler\c6000_7.4.22\lib\src\fputs.c


It appears that linking to the newly compiled CSL library is causing functions in liba.lib to die.

I attached

the CSL library project: csl6713.zip

the DSK6713 library project: dsk6713bsl.zip

the test app: dsk6713bsl_test.zip

Any suggestions about how to re-build the CSL library so that it does not break liba.lib?

Thanks,
Bruce Graham

Senior Software Engineer

6507.dsk6713bsl_test.zipcsl6713.zipdsk6713bsl.zip

  • Hi,

    I've notified the sw team. Their feedback will be posted here.

    Best Regards,
    Yordan
  • Bruce,

    Unfortunately, this is a fairly old CSL code and more than 10 year old DSP so I am not sure if the CSL library build supports build using newer compiler tools. I see that you are building the application in COFF binary using Compiler CGT 7.4.x but are the libraries also built using this version of the compiler ?

    I am moving this to the compiler forum to see if more trained eyes can find something more in your build log that needs to be fixed.

    Regards,
    Rahul
  • I built the libraries and app as coff and elf output formats.

    I sould note that the CSL source comes from C6xCSL\lib_3x\csl6000.src.
    > cd E:\ti\C6xCSL\lib_3x
    > E:\ti\ccsv7\tools\compiler\ti-cgt-c6000_8.2.1\bin\ar6x x csl6000.src

    =============================
    COFF LIBRARIES AND APP
    =============================
    I built the 2 libraries and the application using an output format of legacy COFF.
    The application crashes somewhere in the C run-time, and does not get to main().

    =============================
    ELF LIBRARIES AND APP
    =============================
    I re-compiled the 2 libraries and the application using an output format of (eabi) ELF.

    I got the linking error:
    undefined first referenced
    symbol in file
    --------- ----------------
    _IRQ_hookFetchPacket E:/Workspace/invictus/Invictus_v1.0.0/csl6713/Debug/csl6713.lib<csl_irq.obj>

    I looked in the csl_irq.c source and found the missing function in some in-line assembly:
    extern far void _IRQ_hookFetchPacket();
    asm(" .global __IRQ_hookFetchPacket");
    asm("__IRQ_hookFetchPacket:");
    asm(" STW B0, *--B15");
    asm(" MVKL 0x00000000, B0");
    asm(" MVKH 0x00000000, B0");
    asm(" B B0");
    asm(" LDW *B15++, B0");
    asm(" NOP 4");
    asm(" NOP");
    asm(" NOP");

    The reference the missing function is in:
    void IRQ_hook(int intNum, void *func) {

    int gie;
    Uint32 vector;
    Uint32 *work,*fetchPacket;

    gie = IRQ_globalDisable();

    #if (C11_SUPPORT || C64_SUPPORT)
    work = (Uint32*)_EDMA_RSVD_PARAM;
    fetchPacket = (Uint32*)_IRQ_hookFetchPacket;

    I used ofd6x to verify the elf csl6713.lib has a symbol named _IRQ_hookFetchPacket instead of __IRQ_hookFetchPacket.
    > ti\ccsv7\tools\compiler\c6000_7.4.22\bin\ofd6x -x csl6713.lib > csl6713.xml

    So, I copied the in-line source, and renamed the function so that the linker can find it.
    Note that I renamed __IRQ_hookFetchPacket() to _IRQ_hookFetchPacket(). This linked and runs.
    See below.

    extern far void _IRQ_hookFetchPacket();
    asm(" .global _IRQ_hookFetchPacket");
    asm("_IRQ_hookFetchPacket:");
    asm(" STW B0, *--B15");
    asm(" MVKL 0x00000000, B0");
    asm(" MVKH 0x00000000, B0");
    asm(" B B0");
    asm(" LDW *B15++, B0");
    asm(" NOP 4");
    asm(" NOP");
    asm(" NOP");

    It appears that the elf linker and compiler are handling the naming of in-line functions inconsistently.

    Since the COFF output format is not working, should I use the ELF output format,
    with my re-named function?

    Thanks,
    Bruce Graham

    Senior Software Engineer

  • Firstly, although I know it's distasteful to the customer, the best option here is to continue to use the old COFF library despite the warnings. For the most part, the warning "compatibility cannot be determined" usually just means that an old version of the compiler was used to compile it. If there have been no bugs detected in that library, it's probably safe to continue to use. It is almost surely compatible, it's just that the linker cannot prove it.

    If you really want to convert to EABI, please read this document:

    processors.wiki.ti.com/.../C6000_EABI_Migration

    The compiler does not provide a liba.lib; perhaps you mean libc.a?

    The call to puts may be due to a known performance issue. Certain functions in the library by default print an error message when certain bad things occur, such as a failed "operator new". Later versions of the compiler remove these calls to puts, as they are typically undesired in embedded systems. Try upgrading to the very latest compiler version. Your customer may not want to upgrade to that version, but it will tell us something of the nature of the puts problem.
  • Correct, libc.a.

    My customer is using code that was written specifically for the TMS320C6713. The old TMS320C6713 project was built with CCS V3.3.

    I will have to talk to me customer about moving to a newer, and supported DSP, and moving to CCS V7 and Windows 10.

    What DSP would you recommend as a replacement for the TMS320C6713?

    Thanks,

    Bruce Graham

  • I'm sorry, that's beyond my area of expertise. I would assume you would want to look at the C6740 family, but that's just a guess. However, I don't see why this customer needs to update at all. Is the customer trying to use a newer version of some library? Is the user upgrading from an older version of the compiler, even older than 7.4.x?
  • I  summarize the situation this way.  When the customer builds, they see this ...

    Bruce Graham6 said:
    <Linking>
    warning #16002-D: build attribute vendor section TI missing in "E:/ti/C6xCSL/lib_3x/csl6713.lib<csl_emif.obj>": compatibility cannot be determined
    warning #16002-D: build attribute vendor section TI missing in "E:/ti/C6xCSL/lib_3x/csl6713.lib<csl_mcbsp.obj>": compatibility cannot be determined
    warning #16002-D: build attribute vendor section TI missing in "E:/ti/C6xCSL/lib_3x/csl6713.lib<csl_pll.obj>": compatibility cannot be determined
    warning #16002-D: build attribute vendor section TI missing in "E:/ti/C6xCSL/lib_3x/csl6713.lib<csl_irq.obj>": compatibility cannot be determined
    warning #16002-D: build attribute vendor section TI missing in "E:/ti/dsk6713/lib/dsk6713bsl.lib<dsk6713_dip.obj>": compatibility cannot be determined
    warning #16002-D: build attribute vendor section TI missing in "E:/ti/dsk6713/lib/dsk6713bsl.lib<dsk6713_led.obj>": compatibility cannot be determined
    warning #16002-D: build attribute vendor section TI missing in "E:/ti/dsk6713/lib/dsk6713bsl.lib<dsk6713.obj>": compatibility cannot be determined
    'Finished building target: mems_mics.out'

    And they also see this ...

    Bruce Graham6 said:
    The dsk6713bsl functions appear to be working as expected.

    But the customer also has this constraint ...

    Bruce Graham6 said:
    My customer requires a project that has no suppressed warnings, so I can't use --diag_suppress=16002

    In my opinion, the work the customer has to do just to avoid those linker warnings is not worth it.  Not even close.  Just live with them.  As you've seen, trying to address this problem by updating tools causes yet more problems to appear.  This is typical when you combine old libraries and new tools, especially when they are so far apart in time.  

    All that said, the customer is the one who is responsible for their system, so we will help them toward whatever goal they say is most important.

    Thanks and regards,

    -George

  • OK. I will live with using --diag_suppress=16002.
  • Please post your questions regarding part number recommendations on the Single core DSP forums. We are closing this post here.

    Regards,
    Rahul