CCS/TMS320F28374S: TMS320F28374s Compiler optimize level issue and TMS320F28066 different compiler version issue

Benjamin Zhou said:

1) different optimization level caused different code execution which make DCDC control algorithm not stable.

I'm not sure what causes this problem.  Please make sure any variables modified by interrupts are marked volatile.  That is often a cause of situations like this.

Benjamin Zhou said:

 2) different compiler version caused different result with same source code.

In the document which details this problem, it states the problem is somehow related to memcpy.  And the fix was to change from using the memcpy routine supplied in the compiler RTS library to a custom implementation of memcpy.  Do I summarize that correctly?  I doubt that this change directly fixes the problem.  It is more likely that this change only masks the problem.  While I am not certain, this seems like a problem of timing.  And timing problems are often caused by failing to use the volatile keyword where needed.

Thanks and regards,

-George

During the use of memcpy() did the regions overlap? I could easily believe that memcpy() could break with overlapping regions during optimization since that is the whole point of memcpy(). Try memmove() instead - it is much safer.

George,
For 1) issue, the variables fist is defined in the structure, also the issue still exist. for "volatile" declaim, do you mean each variables used in ISR should be used the volatile?
for 2), customer also have the same concern, on-site debug located to this function. the prototype is used not in ISR but also in other places. what's your suggestion for volatile usage？ should it used for every variables in prototype?

Best Regards
Benjamin

Any variable that can be changed unexpectedly should be marked volatile. "Unexpectedly" here means that the value may change due to an ISR. So all global variables that are changed in ISR's need to be marked volatile.

For example, say you have a while loop condition that uses a global flag to signal the end of the loop. If it is not marked volatile, the compiler will assume that this variable can never change and never bother to check it at the top of the loop. If it is marked "volatile" the compiler knows to reload and check the value at each iteration of the loop.

Keith,
For "Volatile", do you mean only the variable used or defined in ISR must use the volatile?
also, could you kindly give comments on other typical consideration for prototype definition/Variable definition/Prototype calling?

This response has been modified from the original, in order to correct an error.

Benjamin Zhou said:

For "Volatile", do you mean only the variable used or defined in ISR must use the volatile?

Any variable that is read or written by an ISR.

Thanks and regards,

-George

Any variable read or written by an ISR, DMA, co-processor, etc.

For "Volatile", It seems that variables defined in different location are required the "volatile", but in C/C++ compiler user guide, it only mentioned a little, and also it will link to the optimization level according to the user guide. what's your comments for the "volatile" usage while the optimizer level is configured to ”off“？ is it still required for the "volatile" while using the variable in ISR/DMA or others?

Failure to use volatile correctly can cause problems at any level of optimization, even "off".  That said, such problems are more likely at higher levels of optimization.

Thanks and regards,

-George