MSP430FR5962: Compiler optimizing out random functions?

Brett Koenig

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%.

over 2 years ago

0 Eason Zhou over 2 years ago

TI__Mastermind 32920 points

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:

0 Brett Koenig over 2 years ago in reply to Eason Zhou

Prodigy 60 points

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.

-opt0

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

+1 Chester Gillon over 2 years ago in reply to Brett Koenig

Guru 92251 points

Brett Koenig said:
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.

0 Eason Zhou over 2 years ago in reply to Brett Koenig

TI__Mastermind 32920 points

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.

0 Brett Koenig over 2 years ago

Prodigy 60 points

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.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430FR5962: Compiler optimizing out random functions?