TI Linux DSP toolchain

Developers
2008-02-02
2012-09-14
  • Hi,

    Has anyone tried to use the DSP toolchain from TI under linux?
    It can be found here:

    Linux hosted 54xx Code Generation Tools v4.1.1
    https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/download.html
    (you need to register -it is free-).

    Juan

    PD: The TMS320C55x is also inside the Nokia N770 :-) (actually, in the same chip as the ARM processor).

     
    • Percy Zahl
      Percy Zahl
      2008-02-29

      Thanks. I am not registered, and once I pressed "register" the window disappeared. I tried it now in a new browser window with address cut'n pasted, then it worked - strange. ?!?!?!?

      I'll test that thing out. Did you made any Makefile etc. for it?

       
    • Percy Zahl
      Percy Zahl
      2008-02-28

      Hmmm, where do I find this, the link is dead after clicking in sign in/register?

       
  • Stefan Egger
    Stefan Egger
    2010-09-20

    Hi,

    I want to adapt some things in the DSP code for my experiments. As a first
    step, I tried to compile the DSP code with the TI Linux tools. After some
    problems, I could load the generated "FB_spmcontrol.out" on my SR2-A810. Now,
    it seems to be fine. So far I didn't notice any problems when controlling the
    dsp with the gxsm2 program.

    Here a description of the procedure, which I applied:

    • Installing Ti Linux tools version 4.1.2 (free available on the Ti website)
    • Copying "rts55.lib" from ".../MK2-A810_FB_spmcontrol/" to "/opt/TI/cgtools-c5500/lib/"
    • Running "make" (and fixing a problem with the file "spm_log.asm"; but why that?)
    • Loading the new "FB_spmcontrol.out" with a Windows system using the softDB software
    • Trying with gxsm2 from a Linux system

    Nevertheless I'm wondering how you are doing this. Which version of the Ti
    tools are you using? (Does the "rts55.lib" fit to all versions of the TI
    tools?) What is the best procedure?

    Thanks in advance for comments on this.

    Stefan

     
  • Percy Zahl
    Percy Zahl
    2010-09-20

    Sounds about right.

    Just curious -- what is the issue with spm_log.asm?

    must be cg-tools version issue -- I have since first install still version
    2.56-01 -- according to the number I found in the readme file here:

    -rwxrwxr-x 1 767 470 107485 2003-01-08 12:53 README.TXT
    percy@mimas:/opt/TI/cgtools-c5500$ pwd

    /opt/TI/cgtools-c5500


    • TMS320C55x Code Generation Tools Release Version 2.56 *
    • Release Notes *

    ==============================================================================

    Table of Contents

    ==============================================================================

    2.56-01. Bug Fixes in this Release

    ==============================================================================

    2.56-01. Bug Fixes in this Release

    ==============================================================================

    Linker

    SDSsq27823 lnk55 may crash PC when writing allocation failure diagnostic msg

    SDSsq27857 Nesting linker cmd files may corrupt processing of linker inputs


    • TMS320C55x Code Generation Tools Release Version 2.55 *
    • Release Notes *

     
  • Stefan Egger
    Stefan Egger
    2010-09-20

    Thanks.

    About the problem with "spm_log.asm":

    The precise error messages are:


    "spm_log.asm", ERROR! at line 34: Substitution symbol operand expected

    .asg *sp(0), Exp

    "spm_log.asm", ERROR! at line 35: Substitution symbol operand expected

    .asg *sp(1), Mant

    2 Assembly Errors, No Assembly Warnings


    It seems the compiler doesn't like the names "Exp" and "Mant": When changing
    them to "Exp1" and "Mant1" everything is fine.

     
  • Percy Zahl
    Percy Zahl
    2010-09-20

    Thanks for the info -- interesting, must be new keywords for the assembler.

    I'll change it in CVS so no issues in future with this.

    This log code incl. the names is actually Ti math examples...

     
  • The version of the DSP CC is crucial. I had a lot problems to run it with the
    newer own officially availible from TI. You may try this version
    http://open.neurostechnology.com/files/TI-C54x-
    CGT-v4.1.1.2.tar.bz2.
    That should be the one working with the sourcecode
    available on sranger.sf.net.

    Thorsten :-)

     
  • Stefan Egger
    Stefan Egger
    2010-09-20

    Thorsten, I'm surprised that it works with the c54 tools for the SR2-A810. (I
    thought it has to be C55.) But it seems that it needs modifications in the
    makefile. (A quick trial wasn't successful.)

    With Percy's modification the C5500CGT4.1.2 compiles the code nicely. (But I
    still didn't try all functions of gxsm2.)

    Stefan

     
  • Hi Stefan.

    Of course you are right! That version was just for the SRanger STD/SP2. Sorry,
    I did not pay attention to the filename. I was just happy to find again that
    link so one can download it without registration at TI.

    To compile for the SR-MK2 you have to download another package. I found a file
    TI-C55x-CGT-v4.2.2-eval.bin on one of my computers. Actually, after
    installation the compilation of the DSP code is no problem. I just had to link
    the folder /opt/TI/cg55x_4_2_2 to /opt/TI/cgtools-c5500 as Percy uses this
    path in his makefile.

    To get this file you have to register at TI - that's what I wanted to avoid. I
    also tried the latest version of their compiler
    ti_cgt_c5500_4.3.7_setup_linux_x86.bin and it is okay (=compiling without any
    error or warning). Besides the link I had to change permission for this
    folder.

    Haven't tried the compiled code on the Open Source controller yet - need to
    reboot :-(

    Thorsten :-)

     
  • Pham Van
    Pham Van
    2011-12-20

    Hello everybody,

    we have recently acquired a SR-MK2 NG, that we could successfully run with
    GXSM2 (ubuntu 10.04) after flashing the original FB_spmcontrol.out using SR3
    mini debugger (Win XP).

    As we were interested in modifying the DSP code, we have downloaded and
    installed (after registration on TI web site) the CCStudio v5.1 IDE. We could
    build the .out file for the DSP two ways : wether using the build command of
    the IDE (that call gmake) after setting up some variables (memory model) , or
    using the conventional make command on the terminal (that call cl55, v4.4.0).

    However, none of the files once loaded in the flash memory allowed the SPM
    Controller to be interfaced with GXSM2. I noticed after flashing the DSP that
    the entry point adress has changed: the original version indicates 4B12,
    whereas the newer 3920 (using cl55 linker), so there might be differences in
    the linker implementation. Indeed I thought that the .cmd file was explicit
    enough to to meet the SR MK2 requirement...

    Should I revert to an older version of the linker, or did I miss something in
    the linker command file?

    Thx for your suggestions,

    Laurent.

     
  • Does your posting mean that you use the code composer studio under windows?
    Just asking because the compilation is different for the linux and the windows
    tools. In earlier times (SR-STD/SP2) we used the CCS with the Visual linker to
    compile the DSP code. This was just an eval version so you had to apply some
    tricks to use it for a longer period of time. Some years ago, TI decided to
    offer the linux tools for free and Percy adapted the code to compile with the
    command line tools with the convential linker. So if possible use the command
    line tools and not the full code composer studio. If installed a make in the
    source directory should do the job.

    Just another stupid question: You are working in the folder
    MK2-A810_FB_spmcontrol or MK2_FB_spmcontrol? The first one is intended to work
    with the open source spm controller. The second is an earlier repositry
    related to the A16-addon board. So which exact hardware are you using?

    Thorsten :-)

     
  • Just forget to mention: Right at the moment there seems to be a version
    missmatch between the DSP code and GXSM - at least I have some trouble on my
    system. The FB_spmdataexchange.h is different in the two repositries! So
    please make sure that you use a DSP source which is more than a week old. That
    should work with GXSM.

    Thorsten :-)

     
  • Pham Van
    Pham Van
    2011-12-20

    Hello Thorsten,

    I am using the CCS eval under linux and I copied the project file from
    MK2-A810_FB_spmcontrol.

    I 've been working on the subject for 3 weeks time (the source was downloaded
    on the 29th of November), so I guess there won't be any trouble with
    dataexchange header file.

    Indeed, even the "direct" make doesn't work for me.

    I noticed that it produces an .out file of 68.8 kB, whereas the original FB-
    spmcontrol.out is only 31 kB. Therefore i must assume there is a difference in
    the compilation process.

    I'd be glad to test former tools if available...

    Thx for the answer.

    Laurent.

     
  • Percy Zahl
    Percy Zahl
    2011-12-20

    I apologize -- some thing went wrong with the latest CVS commit -- just
    looking into this to fix ASAP, will post. Sorry again.

     
  • Pham Van
    Pham Van
    2011-12-21

    Hello Thorstein and Percy,

    I have compiled the DSP sources using an older available version by Ti website
    (CGT C5500 3.3.6, Linux, using make), and the FB_spmcontrol.out produced
    weights 72.6kB.

    After flashing in the SR-MK2 memory, the hardware is still not recognized by
    GSXM2.

    That suggests that the problem arises more likely from the DSP sources than
    from the compiler (?)

    Thx for your help.

    Laurent.

     
  • Percy Zahl
    Percy Zahl
    2011-12-21

    Not sure why, but this is way to large. It should be around 32kB. Can you send
    me or 1st compare the generated .map files? (memory layout)

     
  • Percy Zahl
    Percy Zahl
    2011-12-27

    I am getting the latest C5500 compiler and will have a look next days!

     
  • Percy Zahl
    Percy Zahl
    2011-12-28

    FYI: I have now the c5000 CC V4.2.3 install and can reproduce the problem.

    Also I think we found the issue, I am working with Alex from Softdb to resolve
    it.

    It seams the new compiler generates a (false) additional .vectors section from
    the rts.lib -- what I should not do here. This definitively screws it all up
    and the DSP crashed at boot with the 1st ISR issued.

    Thin you can find in the map files:

    OK -- CC V 2.4.6:

    output attributes/

    section page orgn(bytes) orgn(words) len(bytes) len(words) input sections


    .ioport 0 00000000 * 0000000b UNINITIALIZED

    00000000 * 0000000b FB_spm_probe.obj (.ioport)

    .vectors 0 00000080 * 00000000 UNINITIALIZED

    vectors 0 00000100 000000f8 *

    00000100 000000f8 * vectors.obj (vectors)

    .stack 0 00000208 * 000001f4 UNINITIALIZED

    new/broken -- CC V4.2.3:

    output attributes/

    section page orgn(bytes) orgn(words) len(bytes) len(words) input sections


    .pinit 0 00000400 * 00000000 UNINITIALIZED

    vectors 0 00000000 00000100 *

    00000000 00000100 * rts55.lib : vectors.obj (vectors)

    .vectors 0 00000100 000000f8 *

    00000100 000000f8 * vectors.obj (.vectors)

    .ioport 0 00000100 * 0000000b UNINITIALIZED

    00000100 * 0000000b FB_spm_probe.obj (.ioport)

    .stack 0 00000208 * 000001f4 UNINITIALIZED

    00000208 * 000001f4 --HOLE--

     
  • Percy Zahl
    Percy Zahl
    2011-12-28

    here is the diff/patch for vectors.asm -- will test tomorrow, looking good.
    When OK I will do a CVS update and add one more note here.

    Big thanks to Alex from SoftdB from the quick help!

    patch for vectors.asm:

    2d1

    < .global _Reset

    35c34

    < .sect .vectors


    .sect "vectors"

    39c38

    < _Reset .ivec _RESET_K,USE_RETA ; 0: RESET (Software 0: SINT0) ; Reset
    (hardware and software)


    ResetVect .ivec _RESET_K,USE_RETA ; 0: RESET (Software 0: SINT0) ; Reset
    (hardware and software)

     
  • Percy Zahl
    Percy Zahl
    2011-12-28

    All in CSV now:

    DSP code fix and CC related patch -- should work now with latest and old DSP-
    CC tools and GXSM HwI update to match up versions.

     
  • Pham Van
    Pham Van
    2012-01-05

    Thanks Percy.

    Everything works fine with your modifications, even using TI Code Composer
    Studio v5.

    I just confirm that the .out file size generated by CGT 3.3 and 4.4 has nearly
    doubled compared to the previous version generated by older TI tools (2.x).

    Happy New Year !

    Laurent.

     
  • Percy Zahl
    Percy Zahl
    2012-01-05

    Great! Was a good incentive and about time to look at the latest compiler... a
    minor but by far not obvious adjustment in vectors.asm. Do not worry about the
    .out file size -- this is NOT the code size finally loaded onto the DSP --
    what is pretty much unchanged -- there may be a newer revision of the COFF
    file format (.out file is COFF) including more or extra meta data related to
    symbolic debugging, etc.

    -P