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.

CCS: CCS6.1 output file issue

Tool/software: Code Composer Studio

Hi,

Generated application software ( release bin)  using CCS3.1 and loaded into DSP5509A. DSP5509A transmits McBSP data at the rate of 20MHz  to OMAP L138 . DSP 6748 (OMAP L138 DSP6478)  receives data successfully without any frame missing issues.  The same application  software generated CCS6.1 ( release bin) and loaded into DSP5509A but the data frames are missing  in the OMAP DSP6478 side.

We did observe that release bin generated from CCS3.3  file size is 127KB and CCS 6.1 file size is 124KB. We did compare all the memory model, compiler, linker settings and looks like all are identical between CCS 3.3 and CCS 6.1.

Please  note that the same behavior ( missing data frames) occurs on CCS6.2, 8.2 as well.

Question is why CCS 6.1 generated release bin missing data frames but not in the CCS 3.3 generated bin file. Please help us to solve the problem.

Thanks,

Ramesh G.

  • ramesh ganesamoorthy said:
    We did observe that release bin generated from CCS3.3  file size is 127KB and CCS 6.1 file size is 124KB.

    Rather than comparing file sizes I would suggest using the objdiff utility to check whether two binaries are the same. See this related thread

  • Hi,

    Thanks for the response. While trying to run objdiff got the below error: Please help me to resolve the below error.

    "cannot be object or executables files, but must be XML files. Either add the
    the OFD command, or separately use OFD to convert them to XML."

    I ran the ofd55.exe output3_3.out and ofd55.exe output6_2.out the output files are completely different. I couldn't able to find the objdiff utility procedure document. If you please provide the steps to run the objdiff utility it will be really helpful.

    Thanks,

    Ramesh G.

  • Details about each of the utilities in the cg_xml package are documented in files included in the package. Start with the index.htm in the main installation folder. 

    The objdiff command would look like this (assuming the paths to each of these are already in your system PATH, otherwise you would need to provide full paths):

    objdiff output3_3.out output6_2.out ofd55


    If the objdiff utility shows differences between the two executables then you would need to take a closer look at the reason for the differences. Compare the compiler version, settings, etc between the two versions. Also compare the linker map file generated with both versions to understand differences.

    If the executables are different due to intentional use of different tools versions and/or settings, then there can be no expectation that the software will execute in the same manner, so that is something you would need to debug from an application stand-point.

  • Thanks for the reply. I did generate the diff files but the files are showing completely different. For sure compiler will be different because CCS3.3 uses 3.3.1 compiler and CCS6.1 uses 4.4.1. We did generate assembly files and compared and observed lot of function calls are introduced in CCS6.2 which we didnt expect to be in the output files ex: memset. We didnt have memset function call or header file anywhere in the software.

    The basic question is we have similar settings in CCS3.3 and CCS6.1 like optimization, release, memory model etc. and same application software running on both CCS versions but we see CCS6.1 generated bin file size is 3KB less than CCS3.3. We believe CCS6.1 compiler optimized (Parallel instruction). 

     The executables are different due to different compilers 3.3.1 vs 4.4.1. Is there way to include compiler 3.3.1 in CCS6.1?.. Please help.

    Thanks,

  • ramesh ganesamoorthy said:
    For sure compiler will be different because CCS3.3 uses 3.3.1 compiler and CCS6.1 uses 4.4.1.

    If the compiler versions are different then the generated code will be different, regardless of the compiler options remaining the same. So if the new code does not work as expected that would take some debugging to figure out why. 

    ramesh ganesamoorthy said:
    Is there way to include compiler 3.3.1 in CCS6.1?

    Yes you can set up CCS 6.1 to use a specific version of the compiler. The general procedure is described in this page. Give that a try and hopefully that will produce a functionally same executable as the one you built with CCS 3.1.
    http://software-dl.ti.com/ccs/esd/documents/ccs_compiler-installation-selection.html 

  • Ok. We were unable to include the ccs3.3.1 compiler version 3.3.1 in ccs6.1. Sure we will try as per the above link and see.

    So if the new code does not work as expected that would take some debugging to figure out why.

    It’s not new code. It’s same old code which is running ok with ccs3.3 but not ccs 6.1. Again this is identical old application code.

    Thanks

  • ramesh ganesamoorthy said:
    It’s not new code. It’s same old code which is running ok with ccs3.3 but not ccs 6.1. Again this is identical old application code.

    I understand. What I meant by "new code" was code generated by another/newer version of compiler. It is not surprising for different compiler versions to generate different mode. In majority of case the functionality should not be impacted, however when there is optimization or other details involved, there could be other subtle details that should be more closely analyzed. 

    A move from CCS 3.3 to CCS 6 is pretty significant, and the compiler tools would've also gone through a few iterations in that time frame. Also these are all very old versions, so the support we can provide is quite limited.

    One quick test you could do is to take the .out file generated from the CCS 3.3 build and simply load and run it using CCS 6.1. You can do this by launching the debugger manually (http://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html#manual-launch) and then loading the program. If this works as expected, then the next step would be "install" the older compiler into CCS 6.1, and build and run using 6.1. 

  • .Hi, I work along with Ramesh, who created this Thread.

    Installed the Compiler Version TI v3.2.3 and Configured the IDE  6.2.0.00050  to Compiler Version v3.2.3 in the Build Properties . Please find the attached snapshot for the settings (Settings.PNG).  With these settings(CCS 6.2.0.00050  -> Compiler Version TI v3.2.3) , when i am trying to Build the Software , the CCS is throwing an error " Can't find Input File ,libc.a'" ,and for the error , please find the attached snapshot (Error.png).

    I didn't find any 'libc.a' File that got downloaded, as part of the Installation of Compiler Version TI v3.2.3 . Please let us know, how to resolve this Error.

    Thanks in Advance.

  • MALLIKARJUNA PALAGANI said:
    I didn't find any 'libc.a' File that got downloaded, as part of the Installation of Compiler Version TI v3.2.3 .

    libc.a is an "index" library.  If you link against it instead of rts<whatever>.lib, the linker will automatically figure out the most appropriate version of the RTS library to use. This has been around in the compiler tools for many years now and we recommend that everyone use "libc.a" for the Runtime Support library name, unless there are special circumstances. I assume support for it came after v3.2.3 compiler (I don't have that version installed to verify), so in this case just replace that field with the exact runtime library (rts55.lib or rts55x.lib) that was used with CCS 3.3.

  • Hi,

    Thank you for the quick responses. One more clarification as follows, please suggest.

    Currently with CCS IDE Version: 6.2.0.00050 -> Compiler Version TI v4.4.1 (or TI v3.2.3). the output Format is getting set as "legacy COFF as default" and the same i can see in the CCS generated Assembly Files as below

    ".compiler_opts --hll_source=on --mem_model:code=flat --mem_model:data=large --object_format=coff --silicon_core_1_0 --silicon_core_1_1 --silicon_core_2_0 --silicon_core_2_1 --silicon_core_2_2 --symdebug:skeletal "

    please Refer the attached snaphsot for the setings.

    Clarification : Is there any way , the output Format  can be changed in settings from Legacy Coff. In another words, i would like to see the Compiler Options in assemble files as below (No object_format Field) :

    ".compiler_opts --hll_source=on --mem_model:code=flat --mem_model:data=large --silicon_core_1_0 --silicon_core_1_1 --silicon_core_2_0 --silicon_core_2_1 --silicon_core_2_2 --symdebug:skeletal "

  • MALLIKARJUNA PALAGANI said:
    Clarification : Is there any way , the output Format  can be changed in settings from Legacy Coff. In another words, i would like to see the Compiler Options in assemble files as below (No object_format Field) :

    COFF is the only Output format supported for C55x so the output will be the same whether the option is explicitly specified or not. The CCSv6 build interface might be passing the --object_format=coff option to the compiler under the hood by default. But it really shouldn't impact the output as it is implicitly always generating COFF anyway. 

  • We would like to try compiler version 3.3.2 in CCS6.2 but unable to find out in the ti website. Please let us know the "C5500 Code Generation Tools v3.3.2" version links.

    Thanks,

    Ramesh G

  • Ramesh,

    I'll have to check with some other people about this and will get back to you when I have more information next week.

  • Sure Thanks for the response. Mean while we loaded Compiler 3.3.3 generated Release bin file and it appears that the device core was hung. We were unable to reset the device. Please help us to reset the device for further investigation. Thanks.

  • We could able to generate .out file in CCS6.2 using compiler 3.2.3 and debug mode works good similar to CCS 3.3 but the .bin (release mode) generated file in CCS6.2 using compiler 3.2.3 not working and having Device core was hung issue. We are unable to recover from this error. 

    We cross checked all the JTAG connections, emulator setup , hardware everything looks good and we could able to run the software CCS 3.3 generated bin file as well. We followed the below link and confirmed connections are good.

    http://software-dl.ti.com/ccs/esd/documents/ccsv7_debugging_jtag_connectivity_issues.html

    The problem is CCS6.2 compiler 3.2.3 generated .bin file makes Device core hung issue not in debug mode. Please help us to run the CCS6.2 (Compiler 3.2.3) generated .bin file in flash mode without having Device core hung issue.

  • ramesh ganesamoorthy said:
    We could able to generate .out file in CCS6.2 using compiler 3.2.3 and debug mode works good similar to CCS 3.3

    This confirms that the CCS side of things are working fine. 

    ramesh ganesamoorthy said:
    but the .bin (release mode) generated file in CCS6.2 using compiler 3.2.3 not working and having Device core was hung issue.

    This points to either a hardware issue or maybe a device boot loading issue. Did you already confirm that the procedure and settings for generating the .bin file with CCS 6.2 is exactly the same as what was done with CCS 3.3? If you have already checked that  and also performed hardware troubleshooting as per the JTAG Troubleshooting page, then as a next step I would suggest posting this specific issue to the Processors forum for the device experts there to comment further.

    This thread has evolved from a output file build and compiler version question to a hardware, perhaps connection issue. So to keep things concise and separate I would request you to open a new thread for the core hung error, and I will close out this thread. 

  • I believe this may not be hardware issue because the same software with compiler 4.4.1 works fine and CCS 6.2 debug build with compiler 3.2.3 also works fine with the same hardware. As soon as we put the release mode generated .bin file from the CCS 6.2 compiler 3.2.3 its not working. The processor/hw, compiler version are same but CCS version is different. Please let us know if you have any solution. Thanks

  • ramesh ganesamoorthy said:
    As soon as we put the release mode generated .bin file from the CCS 6.2 compiler 3.2.3 its not working.

    What exactly is the "release mode generated .bin file"? How is it generated and loaded? 

    ramesh ganesamoorthy said:
    The processor/hw, compiler version are same but CCS version is different.

    If the versions of all tools involved in the build (like compiler tools, RTOS tools like BIOS) as well as build settings are the same, then the version of CCS  alone should not impact the build output. 

    Please understand that migrating a project to newer versions of tools is not always a straight-forward process. The better your understanding of the tools and application software, the smoother the process will be. From our end, the best we can do is provide direction on how/where to troubleshoot. 

    It sounds like you already have a few versions of working software. Are you not able to move forward with that? What is your rationale in getting just that one specific combination working?

  • I'll post processor reset issue in the processor forum. We have tried using compiler 3.3.2 in CCS6.2 and generated the output files. We are kind of getting similar .asm files of CCS3.3 compiler version 3.3.2 except the file name path. 

    1. How to turn off the file name path in the IDE while generating the .asm file. Left CCS 3.3 (Compiler 3.3.2) and Right CCS6.2 (Compiler 3.3.2). CCS6.2 brings whole file name path in the .asm file.

    2. Other than the file name path both CCS version having the same .sam file but the output files Object file (.out) and Release file (.bin) files are different. Though assembly files are kind of similar why the final object and release bin files are different. Please advise.

    Thanks,

    Ramesh G.

  • Ramesh,

    1. If there is no other difference in the .asm files other than the file path, I would expect the code to be same and functionality to not be affected. 

    Does your code use __FILE__ macro? If so that might be the reason for the difference in the path that is passed to the compiler.

    2. Did you compare the object files (.obj and .out) using objdiff? If objdiff reports differences between object files, then please send us examples of such differences and we could try to help identify their source. 

    For eg, if an intermediate object file file1_v33.obj generated by CCS 3.3 is different from object file file1_v62.obj generated by CCS 6.2 (with the same compiler version and build settings) , please send us file1_v33.obj and file1_v62.obj.

    In summary if you could please attach the following, it will be helpful:

    - For a couple of object files (.obj) that show differences with objdiff, provide the corresponding C source file, .asm file generated and .obj generated
    - .out files that show differences with objdiff
    - complete build logs from both versions
    - linker map files from both versions

    If you do not wish to post your files here to the public forum you can share them with me privately. Just hover over my ID and you should be able to send me a private message.

  • Discussion on this topic has been going on offline. We will post relevant details or conclusions as they become available.

  • Hi Aarti,

    First of all, Thanks a lot for the Quick Responses and the great support that you are providing.

    As discussed in webex meeting, we updated the Linker Order and Linker Commands and ensured the Linking Options are same between CCS 3.3-> Compiler 3.3.2 and CCS6.2->Compiler 3.3.2 and still we see the difference in Object Files. For Reference, the Linking Output of the CCS3.3 and CCS6.2 are attached to this Message.

  • MALLIKARJUNA PALAGANI said:
    As discussed in webex meeting, we updated the Linker Order and Linker Commands and ensured the Linking Options are same between CCS 3.3-> Compiler 3.3.2 and CCS6.2->Compiler 3.3.2 and still we see the difference in Object Files.

    During the webex I had mentioned comparing the .obj files between the two builds, not just the .out files. Are there differences reported by the objdiff utility when comparing the .obj files? Or is it only when comparing the .out files?

    If there are differences reported that you would like us to look into further, please see if you can share the files requested in my private message per the amended NDA. That will help move things along a bit faster.