The target CPU is STM32F103ZE.
I installed Ride7 7.36.11 and Rkit-ARM for Ride7 1.36.11.

Actually,the real code segment is:
if(TotalCPSPerSecond > Threshold)
OutOfRangeFlag = 1;
else
OutOfRangeFlag = 0;
Since TotalCPSPerSecond is already greater than 300, but OutOfRangeFlag is still 0. That is why I put CPS there to see if the value of Threshold has changed.

BTW, TotalCPSPerSecond is used everywhere. It is not optimized out.

Hi,

Thanks for the information.

First, note that you are using old software, which included some bugs. I suggest you download and install the latest versions from our Extranet website.

Then, please note that the fact that "TotalCPSPerSecond is used everywhere" does NOT guarantee that accesses to it are not optimized. For this it should be volatile.

Finally, keep in mind that the optimization can make debugging very tricky. Among other things, most C lines will be split in two or more pieces of code, and often only the second/last part really modifies the target of the statement. It's easy to get confused when debugging optimized code.

So I suggest you disable optimization and tell us if it makes a difference. Then we'll know better where to search.

Best Regards,

Vincent

When I checked the value of "TotalCPSPerSecond ", it shows the correct value. That is why when I declare it as volatile,it doesn't help.

Also extro info for this: this code segment worked before. After I adding some other codes(not related to this segment), it stopped working.

Hi,

Please first confirm that you upgraded your software. Some problems that have been corrected after the versions you mentioned earlier could cause what you observe.

When the behavior changes after modifications in "other codes (not related...", this is almost always related to optimization.

From what I know, it could be the accesses to OutOfRangeFlag that are optimized.

How do you observe that OutOfRangeFlag is not written as expected? If you check it using the debugger and if optimization is ON, as I said before it is possible that what the debugger observes might not correspond to what really happens.

Very rarely it can be related to interrupts, stack overflow or other, more complex things. But really optimization must be fully ruled out first, before inquired other areas.

Could you please try to completely disable optimization on the whole project and tell us if it changes anything?

To tell you more I would need a complete project that demonstrates the problem.

Best Regards,

Vincent

I changed the "Optimization Level" to "No optimize", the result is still the same.

The next thing I'm going to try is updating the software.

Forgot to mention one thing. I added one line of code(CPS=Threshold ) before the comparison.let's say TotalCPSPerSecond =400 and Threshold=300,then OutOfRangeFlag=1,which has the correct value. Now, if I changed Threshold from 300 to 5000 and TotalCPSPerSecond =400, then OutOfRangeFlag should be 0,but actually it is still 1. And the value of CPS still shows 300, instead of 5000.

If I removed that line of code(CPS=Threshold ), then recompile, the result will be correct.OutOfRangeFlag=0 and CPS shows 5000. Now if I change Threshold from 5000 to 300, it stopped working again.

Looks like it always remember the last woking value of Threshold.

I unchecked the debug switch in the tool.Then compiled it and it worked. Haven't figured out the reason yet.