Compiler/MSP430F5419A: Abnormal behaviors moving from CCSv4 to CCSv8 with newer compilers

Thanks for the reply George, but it didn't help much since I am already aware of most of what you said. The issue here is that the same exact code compiled in CCSv4 with TI v3.3.3 compiler has no problem. Only when I import the same project over to CCSv8 with newer compiler(s) do I see the anomalies. In both cases I tried my best to turn off optimizations. What do you mean by "most optimizations" when setting --opt_level to off? What other optimizations I might have missed?

Appreciate your help!

Compilers have *always* performed some optimizations. I don't know specifically for the TI compiler, but for example, if you have:

omega = f * 2 * m_pi;

the compiler will compute 2 * m_pi at compile time.

Also, if you create a loop like this:

int i;

for (i=0; i<1000; i++) ;

to waste time, the compiler might just remove it since it has no effect.

Also, for the << operator, what were the actual operands, what did you get, and what did you expect?

Thanks for the clarifications Keith. I meant something more obvious that could be turned on/off in the settings. Again my question is more like why compiler 3.3.3 does not show any of the optimization anomalies; only with the new CCS and compilers.

Regarding the shift operator, I just took an educated guess that was the case. I have something like:

if (Para > 0)

{

while (Para < 0x80000)

{

Para <<= 0x01;

}

}

and once in a blue moon Para in the while loop just mysteriously becomes 0 which gets the code stuck in the while loop and causes a WD reset.

I literally have to put a guard if (Para == 0) { break;} in the while loop to prevent the WD reset.

It could be from the shifter << or it could be related to hidden optimization settings that I am not aware of. Just very very bizarre. This does not happen in CCSv4 with 3.3.3 compiler (we've been using it for years without issues).

snuk said:

once in a blue moon Para in the while loop just mysteriously becomes 0

If this happens on an intermittent basis, then that sounds like a problem in the hardware.

Thanks and regards,

-George

Definitely not a hardware problem since it never happens in CCSv4 with 3.3.3 compiler. Plus this is only one of the anomalies. The other one having to do with a GPIO pin that never seems to "turn on" as coded, is all the time, not intermittent. 

We do not want to go back to CCSv4 since we need to support uint64_t data type in the near future but if this problem persists we don't seem to have a choice.

Try the gcc compiler.

Tried that also! After manually and painstakingly converting the setup to the GNU environment for the project, I still run into a bunch of warnings and errors. Our project was set up to use TI compilers and it would be a load of work to switch to GNU (i.e. pragmas are not supported etc.). The pitfalls that come with such an endeavor would make it not worthwhile.

Unless I am missing something of course.

Regarding this situation ...

snuk said:

I have something like:

if (Para > 0)

{

while (Para < 0x80000)

{

Para <<= 0x01;

}

}

and once in a blue moon Para in the while loop just mysteriously becomes 0

For the source file that contains this code, please follow the directions in the article How to Submit a Compiler Test Case. I'll generate the assembly code and see if I can spot the problem.

Thanks and regards,

-George

Thanks again George, I will try that when time permits. I know TI does not support field engineers recently like it used to years ago but is it possible to get some kind of on site help because our code is very hardware specific?

It is easier to demonstrate the anomalies at the bench level.

snuk said:

I will try that when time permits.

It only takes 5-10 minutes.

snuk said:

is it possible to get some kind of on site help

I don't know.  That's not something I have ever arranged.  Get me that test case first.  Every situation is different.  But you might be surprised at how far we get with just that.

Thanks and regards,

-George