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: Compilation and Optimisation level problem



Tool/software: Code Composer Studio

Hai,

My Source code developed on CCS 5 and optimisation level is 2

I faced one issue that my application getting restart (not working)because some part of the code gets neglected i think so. 

when i changed the optimisation level to 4, It's working fine.

Then i create the project in CCS 7 and optimisation level 2

It's working fine.

I don't know what is the issue? 

Please help me to find out the problem

Thanks in advance

  • hello Embedded Developer,

    Optimization level 4 might be like turning it up to 11 on a scale of 10, but indeed you have my full support if you can indeed set an O4 optimizer level. Cut/paste build output or snippet from the build output?

    The failure mode you mentioned is an unintentional restart. Restarting can be cool sometimes. Maybe you can leverage the unintentional restart into a feature controllable by a knob. Check out _c_int00() function. It is somehow being re-invoked? Maybe set a breakpoint on it.

    Maybe the issue a bug in your code which is tickled differently by different compiler-revs/optimization-levels/debug-symbols-or-not. When you change compiler rev or optimization level, you change text segment size, which can significantly change the link map if you haven't locked all your vars down via linker.cmd and DATA_SECTION pragmas. Platform dependently it can change which globals are in which segment/memory, resulting in vast logic differences being exposed at runtime.

    An example possible bug might be memory stomping such as by array-bounds-exceeded. To workaround/hack around that enough to debug it, you can put memory-wasting "protection stripes" (long long wastememorythatmightgetstomped[42000] = {0}). Put vars like that inbetween your globals and/or functions to move them around so they don't get stomped by whatever bug you are hunting - then when the code stops misbehaving due to lucky link map, you can maybe instrument it further to find where it went wrong.
    Also inbetween each function call you can sum all the memory-protection-stripes to see if any of them got stomped by an errant write, and exit if that happens - then you can see where in the code its happening via 'trail of breadcrumb's.

    With old compilers, if you use opt level 2 or above, different assembly code may be generated if you also use "-g" (such as symdebug:full) .
    Also it seems likely that different compiler rev is used when you build with CCS5 compared to CCS7, so that is a big change too.

    Maybe vary all the optimization levels with whatever CCS and see if there are different behaviors and instrument as you see fit? Also if using compiler less than v7, you can also vary the "-g" vs "no -g" Debug symbols. Does code behave same for all those conditions? If so, maybe you can declare victory/mission-accomplished and never look back to the ancient CCSv5 runes. Instead move forward to CCSv8.

    best regards,

    Senior Embedded Developer
    (recently learning & enjoying C66 & CCS after extensive previous TI experience with the TI-58c/TI-59.)
  • Embedded Developer said:

    My Source code developed on CCS 5 and optimisation level is 2

    I faced one issue that my application getting restart (not working)because some part of the code gets neglected i think so. 

    Unfortunately, this is too vague to act on.  I can only give a few general bits of advice.  Be sure you allocate enough stack and heap.  Any variables which may change value due to something other than ordinary C code (interrupts, peripherals, and so on) should be marked volatile.

    Thanks and regards,

    -George