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.

RTOS/TMS320C6412: Latest BIOS SW supported by TMS320C6412 - Looking to upgrade from BIOS v5.31.02

Part Number: TMS320C6412
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

I am maintaining a set of code that is used by a TMS320C6412 and is currently running the following SW:

  • CCS v3.3 (not actively using CCS, only the libraries)
  • C6000 packages: CSL, RTDX, CGTOOLS, C6400DSPLIB
  • BIOS v5.31.02

The latest load that supports this DSP appears to be DSP/BIOS v5.42.02.10. Would this be the most stable release to upgrade to? Can I anticipate any issues from jumping over so many releases?

Rebuilding the code is no issue and I'm not looking to use any new features. Does Code Composer need to be installed, or can I install the libraries as stand-alone packages?

  • Hello Amanda,

    I am looping in the SYSBIOS experts. They will be able to better answer your questions.
  • Hi Amanda,

    I took a brief look at the release notes between those releases. Nothing major jumped out (other than dropping Solaris host and RTDX support ). While the newer version (5.42.02) is compatible with your version (5.31.02), the compilers are different. That would probably be the biggest risk.

    If you moved to 5.42.02, I would use the recommended CCS. This guarantees you are using the proper compiler and other tools.

    Before deciding, you might want to look at the release notes for the versions between the lastest and yours in case something pops up that might impact you. A good place to look is here:

  • Thanks for having a look Todd. The lack of RTDX support should be fine. That was likely used during emulation for initial development. If we require emulation use in the future, it wouldn't make sense to use such an old tool. I have looked through most of the release notes, but there have been so many versions that I'm not confident that I haven't missed anything critical.

    I've been looking into the details of CCSv5.3.0 and I would like to avoid installing that, if at all possible, especially since in our usage, we don't use the application itself, only the libraries. Our code repository is already huge and I don't want to bring in any unnecessary bloat. There have also been updates to the libraries included in CCS v5.3.0. Without opening the CCS application (if I go down the install CCS route), is it possible to get package updates installed?

    For testing purposes I can install CCS on my machine, but for the final solution, these libraries need to be installed on a server.

  • Hi Amanda,

    I had a quick look at this too. Just to understand your build environment, are you saying that you're using your own makefiles to build all of your code? You're not using the CCS project manager, right? If that is the case, I think it should be reasonably straight-forward to migrate. As Todd mentioned, the compiler change is probably a bigger risk than the DSP/BIOS change. What compiler version are you using now?

    The newest DSP/BIOS 5.42.02 was validated using compiler 7.3.1. My recommendation (for starters) would be to use the same 7.3.x code branch. However, I do not advise using 7.3.1 specifically. While that was likely the latest and greatest compiler when DSP/BIOS 5.42 was released, there have been many years of bug fixes that went into that compiler branch. It looks like the latest in that branch is 7.3.23. In my opinion, that would be the best place to start. That's especially true if you have a huge code base, i.e. you're likely to hit a lot of the compiler bugs if you're using one of the initial versions. You can download the compiler without downloading CCS:

    I suggest you download DSP/BIOS 5.42.02 plus C6000 Compiler 7.3.23 and give it a shot. Depending on what sort of issues you hit, you could either respond on this thread or start a brand new thread.

    Best regards,
  • Thanks for the follow-up Brad. I thought it would go with CGT v7.4.23 since the 7.4.1 version was what was shipped with CCSv5.3.0. I haven't gotten to the point where I tried a compile with it, as I came up with another related question. I thought that the CSL package would be installed as part of the CGT package and that wasn't the case.

    On the site for the TMS320C6412, the link for the CSL brings you to:

    But this library is v2.31.00.16 from April 2006 and I can't seem to find any reference to a more recent version. Is there a more recent version?

  • CSL is independent of the compiler. That was the final CSL release.
  • One slight clarification. That was the final "CSL2" release. For 64x+ devices and newer we moved to "CSL3" which was a completely different software architecture.
  • A quick search brought me to document spraa10 (Migrating from CSL2.x to CSL3.x), where Table 1: CSL Support Matrix shows the C6412 is only supported by CSL2.

    In the end, I've installed the following on my Linux machine:

    •    bios_5_42_02_10
    •    ti_cgt_c6000_7.4.23
    •    ccs3.3/c6000/csl (not upgrading this)

    I've updated all the paths in my makefile (note: I'm not using CCS), but when I try to compile, I get this error:

    js: "/home/bios_5_42_02_10/xdctools/include/", line 976: Error: Can't find[ip] file for 'ti.platforms.generic'

    make[1]: *** [/BIOS/UppDspcfg.h] Error 1


    I've done a compare between the new and old XDC Tool versions in /home/bios_5_42_02_10/xdctools/packages/ti/catalog/c6000 for and Content wise, they are equal. The path using bios_5_31_02 is of similar structure. I think my tcf file follows the guidelines:

    environment["ti.bios.oldMemoryNames"] = true;

    /* loading the generic platform */

    var params = {};

    params.clockRate = 720.000000;

    params.deviceName = "6412";

    params.catalogName = "ti.catalog.c6000";

    params.regs = {};

    params.regs.l2Mode = "4-way cache (0k)";

    utils.loadPlatform("ti.platforms.generic", params);


    Alternatively, I tried copying the '' and '' files from their location in the old XDC Tools path, to a local directory and importing the file:

    tconf -Dconfig.importPath="/home/BiosUpgrade"



    This didn't bring any success either:

    js: "./UppDsp.tcf", line 23: Invalid assignment left-hand side.

    js: utils.importFile("C6412");

    js: .....^

    js: "./UppDsp.tcf", line 23: syntax error

    js: utils.importFile("C6412");

    js: ......^

    js: "./UppDsp.tcf", line 1: Compilation produced 2 syntax errors.


    Do you have any suggestions on why I wouldn't be able to locate ti.platforms.generic?

  • Sounds like a path issue. The big change in DSP/BIOS 5.42 was to remove on the dependency on having a separate xdctools installation. I imagine this impacted some of the paths, etc. Make sure your tconf include paths contains both C:\TI\bios_5_42_02_10\packages and C:\TI\bios_5_42_02_10\xdctools\packages.
  • Hi All,

    Can I go ahead and mark this as TI Thinks Resolved, or is there something else to add to this?

  • Hi Todd,
    I'm still having path issues, however, I do have one further question:

    Brad, when you said, "Make sure your tconf include path contains...", what specifically do you mean? I want to make sure I'm not misinterpreting your advice.
  • The tconf utility has a search path, e.g. analogous to the C compiler having a search path. It is discussed in the Tconf User's Guide that is inside the docs/ directory of BIOS. There's a -p option where you pass it a path, plus there's also the config.importPath environment array variable (see Section 2.2.1). Here's an example that adds a couple paths:

    tconf -Dconfig.importPath="c:/include;d:/platforms" hello.tcf

    If the tconf tool is not finding files, you likely have a path missing here.
  • Thanks Brad. I was misinterpreting your advice and I put the 'tconf -Dconfig' usage in the wrong place. To get the file found I did a search for the directory name:
    [a] $ find -type d | grep "generic"
    ./packages/ti/platforms/generic <-- this is the path I wanted. It was a directory above the tconf path.

    Then I updated my rules file, where tconf was run, with the correct path:
    cd ${<D} && /home/bios_5_42_02_10/xdctools/tconf -Dconfig.importPath="/home/bios_5_42_02_10/packages/ti/platforms/generic" ${<F}

    That did the trick! Now, I'm chasing down other compile errors.
  • Amanda,

    Great! Glad to hear you're making progress again. Hopefully the compiler errors are reasonably straight-forward to correct. I hope everything comes up smoothly once you get to the run-time testing and debugging!

    Best regards,