This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5962: Compiler optimizing out random functions?

Part Number: MSP430FR5962

So far I've tried optimization levels 0 and 1 and played around with --opt_for_speed with no success.  Currently optimization level 2 seems to work for some reason, but so did -o1 until I eventually had the same issue.  What happens is the compiler seems to pick a function at random (it seems to be a new one every time there's any code changes) to optimize out.  Disabling optimization completely solves the issue.

A call to the optimized out function leads me to an address containing all BRA @PC instructions, which of course sets my PC to 0 and the program remains halted.

I should also note that my FRAM2 is 100% full, with FRAM at 82% and RAM at 81%.

  • It is really hard to find the reason. You need to disassembly the code to know what the complier do to the code.

    I think you can change the optimization of different files expect the whole project:

  • Here's a good example.  Today I did a clean & rebuild at the following optimization levels

    This function has never had this issue before until just now.  It's in the stdlib.h's atoll function.  Here's the function call.

    All good so far.  Until we hit the following line of code

    Which in assembly is...

    Function gets called fine (pointer in tact).  But the assembly of the function looks like it is missing/optimized out.

    The rest is halted @PC 0

    Repeating this at -opt1 produced the same results.

    At -opt0, the function is in tact and runs successfully.


    And just to clarify - the behavior is the same whether I'm stepping or free running the code.  Both end up @PC 0

  • Function gets called fine (pointer in tact).  But the assembly of the function looks like it is missing/optimized out.

    Since the disassembly is showing the function name from the symbol table, it means the linker hasn't removed the function.

    Rather, suspect something in the running program is overwriting the FRAM containing the function.

  • Can you try my way to work around this issue.

    1. Put the function in a dedicated C file

    2. Make the optimization of the C file to be 0.

  • Looks like it was a run time bug due to a large array not being initialized properly, zeroing past its own memory.  That explains why different functions would 'break' when changing optimization since it forces the compiler to rebuild.

    Thanks for the help.