CODECOMPOSER: BUG: Optimizer incorrectly changing compiler behavior

Hi Jeremy,

Thanks for the video. Please note that the higher the optimization, the greater the negative impact on source level debug. Optimization level 3 is high.

See: https://dev.ti.com/tirex/explore/node?node=A__AEm7LJjS34iFPa5fpT7ttQ__ccs_devtools__FUz-xrs__LATEST

Jeremy Trafas said:

ultimately ruin the code since it is very dependent on timing

Now, without looking at source line stepping, does the code actually run as expected? This is the bigger question.

Thanks

ki

The code did not run as expected with the optimizer on. This function is the waking process for an eval board and the board did not wake. Yes level 3 is high but it is also what CCS had as default.

Jeremy Trafas said:

The code did not run as expected with the optimizer on.

Ok, thanks for clarifying. I will bring this thread to the attention of the compiler experts.

From C code, you can control the order in which things occur.  But you cannot control the timing.  So, are things happening in the wrong order?  Or, are they happening in the correct order, but the timing is incorrect?  

Thanks and regards,

-George

Things are happening in the wrong order. As you can see in the video with optimizing, the debugger jumps back a line and then just quits entirely.

This ...

Jeremy Trafas said:

the debugger jumps back a line

... is not rare when debugging optimized code.  That alone does not mean the code executes in the wrong order.  

Jeremy Trafas said:

then just quits entirely

What does that mean?  Maybe the function should return, and that never happens.  Is that what you mean?

Generally speaking, if something executes in a different order between the optimized and not optimized builds, you need to clearly identify that difference in order.

Thanks and regards,

-George

Ok so the function should operate like this. I click next line and it goes to the next line. With the optimizer. I click next line and it goes back up a line. I click next line and it goes to next line. When I try to click next line one more time it next lines greys out. I think this is easy to see in the video. Maybe its unclear. The video on the left has the optimizer and the video on the right does not have the optimizer. 

The two videos are the same exact function, the difference in order is quite clear! I am clicking the same button and a different thing is happening.

When I'm saying it quits entirely, the debugger just... stops? I'm not a coding expert and this is code from Texas Instruments and the author is Vince Toledo. 

Jeremy Trafas said:

With the optimizer. I click next line and it goes back up a line. I click next line and it goes to next line. When I try to click next line one more time it next lines greys out. I think this is easy to see in the video.

Again, please see the link I referenced earlier:

https://dev.ti.com/tirex/explore/node?node=A__AEm7LJjS34iFPa5fpT7ttQ__ccs_devtools__FUz-xrs__LATEST

Specifically this line: "Does single stepping proceed through the code exactly as written? Or, does it skip around in seemingly random order?"

What you are showing in the video for the optimized case is an example of the issues of trying to do source line debug of heavily optimized code. Basically the debugger will have issues with this due to the nature of optimized code. 

The more the code is optimized, the less the debugger will be able to accurately show source line debug information. This is a known and expected tradeoff.

Another quote from the article in the link above: The essential problem is that things the compiler does to make the code run faster (optimization) may, at the same time, make the code harder to debug

When optimization is disabled, source line debug works great as you proved in your video. When you turn on optimization, it looks a screwy because the optimized code will confuse the debugger in regards to source line debug. But it doesn't mean that the code is not running correctly.

Basically when the code is optimized to that degree, you can NOT rely on source line debug. So ignore it. Do not bother with source stepping. Hence ignore your first video. The behavior in the video is actually expected.

Focus on if your program is running correctly - without source stepping or viewing variables. 

Ok cool. Glad there isn't a bug. 

Jeremy Trafas said:

Ok cool. Glad there isn't a bug. 

I can't say definitively that there is no bug. But I can say that what you showed in video 1 is not necessarily a bug for optimized code.

Ok I am just using the BQ79616 Sample Code if you want to further explore 

Jeremy Trafas said:

Ok I am just using the BQ79616 Sample Code if you want to further explore 

I don't know enough about this code to comment on this. 

Ignoring source level debug for optimized code (since it cannot be reliably debugged as expected), how else did you determine your code is running incorrectly?

High level, the code makes the BQ79616 eval board work. It is a chip that measures cell voltages. I knew the code did not work because the eval board would not wake/turn on. Without optimizer, the board woke and read cell voltages as designed.

Thank you for clarifying. This is beyond my area of expertise. I will defer to the device experts here.

Hi Jeremy,

It seems like this is an SCI issue. Depending on the optimization settings, the SCI transmitter behaves differently. Let me know if this is incorrect.

Are you able to observe the SCI messages coming from the C2000 device when optimization is enabled and disabled on an oscilloscope? Do you notice any differences? If the SCI pins are not probable, there is a way to mimick the behavior of the pins on other pins of the F28 device that you may be able to probe.

Thank you,

Luke

Sorry Luke, I cannot allocate time to this issue anymore.