• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 1044 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Code Composer Studio v3.3 Compiler error

David Zeng
Prodigy 70 points
Other Parts Discussed in Thread: TMS320F2812

I am on Code Composer Studio v3.3.38 using cl2000.exe. I am building for the TMS320F2812 Device Simulator. My current installation is the vanilla v3.3 CD install.

When I try to compile C++ code I receive:

>> INTERNAL ERROR: no match for ASG


This may be a serious problem.  Please contact customer support with a
description of this problem and a sample of the source files that caused this
INTERNAL ERROR message to appear.

Cannot continue compilation - ABORTING!


>> Compilation failure

 

I am working on trying to provide a file without proprietary or confidential code for reference.

  • 0
    TI__Guru**** 173310 points

    The C2000 compiler tools included with CCS 3.3 is pretty old. I believe it is version 4.1.3. We have released several compiler updates since then, so if it is feasible, could you try updating your compiler tools to a newer version? It is likely that this was a bug in the compiler that may be fixed in a newer version.

    As long as your CCS is not the DSK version, you should be able to update. You can download and install newer versions of codegen tools from the Update Advisor site (by going to Help->Update Advisor->Check for Updates. I would suggest trying out the latest version on the 5.1.x or 5.2.x stream. Once you install the newer version, you need to enable it within the Component Manager in CCS to tell it to build with that version. Please check this page for details: http://processors.wiki.ti.com/index.php/Compiler_Installation_and_Selection#CCStudio_3.x

    If, for some reason, you are not able to update, some immediate things to try as workarounds are different compiler options to see if the error goes away. For example, if you are using optimization, try removing the option or setting to a lower optimization level etc.

     

     

  • 0 in reply to AartiG
    Prodigy 70 points

    Unfortunately, I am qualifying CCS 3.3 so upgrading my compiler is one of the last things that i would prefer to do. I found that my error stemmed from my arrays being too massive for the stack. Thus, I had to make them global and then still shrink them so that they could fit in the RAM space when linking. Unfortunately, I had to shrink an array originally int32 0x10000 down to only 0x100.

    Edit: Is there anyway to trick the compiler that there is more RAM than the default 0x2000?

  • 0 in reply to David Zeng
    TI__Guru**** 251370 points

    David Zeng said:
    Is there anyway to trick the compiler that there is more RAM than the default 0x2000?

    The compiler does not know how much memory is in the system.  The linker does, but that's not where your problem occurred.  I don't know why making the arrays smaller avoids the problem.  I'm a bit surprised by that, myself.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 70 points

    I guess i forgot to differentiate between the linker and compiler in my post. By making the arrays global, I can then compile so that's why i suspected that the arrays were creating too large of a stack for the compiler. Once compiled though, I have a script that immediately links it. It is there where I am have to decrease my array size by several orders of hex magnitude. This is due to a limitation on RAM, specifically for memory reserved for uninitialized memory. From this context is where I am asking if there is a workaround or hack to trick the linker into thinking that there is more RAM than it allocates by default.

  • 0 in reply to David Zeng
    TI__Guru**** 251370 points

    You tell the linker how much system memory is available with the MEMORY directive in a linker command file.  See the linker chapter in the Assembly Language Tools User's Guide.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 120 points

    Hi All,

    Thank u and Sorry for delayed response as i was out of station.

    #1. Compiler version 6.0.8

    #2. Im afraid that, i dont have reproductive test case. Similar type code exists in my project(which i cannot share) where i faced the problem. As i told in the previous commnets,  we could see that memory location reads 0x80, But the condition evaluated as false. One thing I observed, that this scenario happens during cold reboot of the system. but i don think, this makes any sense and it is only observation. My intention is to understand if such behaviour can happen by any means?

    Regards

    Sudhee