MSPM0L1117: Optimization options for examples that don't need them

Part Number: MSPM0L1117


Hello,

I'm running the flashctl_dynamic_memory_protection example, and one of the key variables failType is optimized out because we by default set our optimization level to 2 in all our examples.

While the example may be functionally "correct" this example is supposed to be one where you step through and observe the values of the function return codes to understand how dynamic write protection works and having optimization on isn't helpful for this since some of the variables like failType get optimized out and there is some out of order execution that happens.

Can we please make sure in places where optimization is not essential to actually leave it off? Or there's a debug configuration for all these projects and they should actually be "debug" code where optimization is off and then release turns optimization back on.

Munan

  • Hi Munan,

    The failType is a local variable and if user want to observe it or make it non-optimized, they can change it to global and or add volatile for the variable, just like the gCmdStatus.

    B.R.

    Sal

  • Hey Sal,

    I'm aware of how to make the variable appear again, but I think the bigger point is that we shouldn't needlessly enable optimizations because it reduces understanding of how the code works when stepping through examples.

    This sdk example just happened to be what I'm looking at right now, but I think every SDK example has a default debug build configuration with optimization set to -o2.

    What is the benefit of doing this? Should we be?

    Munan

  • Hi Munan,

    Non-optimization will significantly increase the code size and reduce execution efficiency.

    That is the reason we set O2 for all SDK example.

    B.R.

    Sal

  • Make the "release" configuration the one optimized for size and speed!

    It's not like we're struggling to fit these examples on the devices.

    Maybe this is my personal opinion but I just don't see how we can't do both.