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/TMS320C5504: Unable to produce working a00 file for TMS320C55x on Code Composer 10.

Part Number: TMS320C5504
Other Parts Discussed in Thread: OMAP5912

Tool/software: TI C/C++ Compiler

We are trying to migrate a project, which was previously built on Code Composer v3.3, over to being built on Code Composer v10.0. The project generates an a00 ASCII hex file that is placed into the TMS320C55x DSP located on an OMAP5912. The project does successfully compile using Code Composer v10.0, using C5500 Code Generation Tools 3.3.2 provided from TI, but the project generates a binary that differs from the one generated on Code Composer v3.3. In addition, and most importantly, this newly generated binary fails to run on the DSP.

We copied the C5500 compiler tools from the Code Composer v3.3 install, and produced the same results, on Code Composer v10.0, when using the C5500 Code Generation Tools 3.3.2. Thus, we feel this rules out the compiler tools as the source of the issue.

Currently, the Code Composer v.10.0 project uses XDAIS v6.24.1.6, and the Code Composer v3.3 project uses XDAIS v2.24.x (I don't recall minor version, though I can get it if useful). Could the XDAIS version disparity be the source of the binary generation issues we are having? What other tools, if any, play a part in generating the a00 binary file in Code Composer v10.0?

  • I'm unclear on the difference between this which fails ...

    Levi Amen said:
    The project does successfully compile using Code Composer v10.0, using C5500 Code Generation Tools 3.3.2 provided from TI, but the project generates a binary that differs from the one generated on Code Composer v3.3.

    and this which works ...

    Levi Amen said:
    We copied the C5500 compiler tools from the Code Composer v3.3 install, and produced the same results, on Code Composer v10.0, when using the C5500 Code Generation Tools 3.3.2.

    In both cases, you use CCSv10.0 and compiler tools version 3.3.2.  But you get different results.  What else is different?

    Thanks and regards,

    -George

  • George Mock said:

    In both cases, you use CCSv10.0 and compiler tools version 3.3.2.  But you get different results.  What else is different?

    Thanks and regards,

    Perhaps poor wording on my part. In both cases CCSv10.0 produces the exact same result (binary), not different, which is why we felt the compiler tools were not the issue. However, the resulting binary produced from CCSv10.0 differs from the one produced by CCSv3.3. The binary produced by CCSv3.3 works, and the binary produced by CCSv10.0 does not.

    As stated in my post, one difference we've identified between our setups is CCSv10.0 is using XDAIS v6.24.1.6 and CCSv3.3 is using XDAIS v2.24.x. Though, we are unsure if this difference in XDAIS versions is a contributing factor or not.

  • Hi Levi,

    Are you using DSP/BIOS? If so, which version?

    Todd

  • ToddMullanix said:

    Are you using DSP/BIOS? If so, which version?

    No, we are not.

  • As a test, we completely removed XDAIS from the project and CCSv10.0. Interestingly enough, the project still built fine with no additional error or warnings, thus XDAIS was neither a dependency or the problem.

    I dug into the .map files, that were being generated, and I noticed something interesting...

    The left half is the .map file generated from the CCSv10.0 build, the right generated from CCSv3.3.

    The placement of the rts55x library objects, specifically boot.obj, and the corresponding difference in _c_init00 symbol was of interest to me. So, I changed the linker configuration adding --library=rts55x.lib before the ${inputs} pattern and rebuilt the project in CCSv10.0. The resulting map file matched the one generated from CCSv3.3, and the resulting .a00 file successfully ran on the TMS320C55x.
    I will admit that I'm not quite sure why changing the link order so boot.obj from rts55x.lib was set at memory address 0x00010000 fixed our issue.
    My next steps are going to try using the newer compiler version, v4.4.1, and see if the binary still runs on the DSP. Will report back results.