• State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 19 subscribers
  • Views 4111 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Program does not run with optimization disabled, except if debugging

Enzo Redivo

Hello.

I've been having issues with a program of mine that works perfectly fine while running with optimizations enabled but if I disable it, it doesn't seem to get to main, the only exception being running in debug mode.  I have set up the pins using MCUXpresso Config Tools v7, and did not modify any of the generated code except for changing the #pragma push and #pragma pop for #pragma clang diagnostic push and #pragma clang diagnostic pop in the MK22FA12.h header file generated by Keil, as the ARM6 compiler seems not to accept the former.

I have also changed the first line in the scatter file for #!armclang -E --target=arm-arm-none-eabi -mcpu=cortex-m4 -xc (was #! armcc -E) and disabled the "Use Memory Layout from Target Dialog" option in the Linker.


Using debug mode every optimization setting seems to work fine.

Compiler: ARM V6.13.1

Board: MK22FX512AVLL12

SDK: MCUXpresso 2

IDE: Keil uVision5

I've included a simple project that makes one of the leds blink when it gets to main that reproduces the presented problem. I have tested with all optimization levels and the only one that does not work when I run is -O0*.

*It does run, in debug mode only.

If anyone could help me, I'd be really glad.

Blink.zip

Parents
  • 0 in reply to Dario
    Dario said:
    What could the optimization "optimize out" to make the program work?

    One reason could be the "distance" between accesses for example to the watch dog.

    Does it also stop working if you have the debugger attached? If so, reset your board and then attach the debugger and check where it sits.

    Last resort: Add endless-loops and do the above to see where it stops working.

    Dario said:
    the policy at our company is to avoid optimization.

    I often see this (strange) policy. Esp. the lower levels (like common sub-expression removal) aren't very aggressive.

    The better policy IMHO is: Options for Release version must be the same as for the tested version.

Reply
  • 0 in reply to Dario
    Dario said:
    What could the optimization "optimize out" to make the program work?

    One reason could be the "distance" between accesses for example to the watch dog.

    Does it also stop working if you have the debugger attached? If so, reset your board and then attach the debugger and check where it sits.

    Last resort: Add endless-loops and do the above to see where it stops working.

    Dario said:
    the policy at our company is to avoid optimization.

    I often see this (strange) policy. Esp. the lower levels (like common sub-expression removal) aren't very aggressive.

    The better policy IMHO is: Options for Release version must be the same as for the tested version.

Children
No data