Release build won't run

[PGump.1]

Hi all,

I have a simple project using a STM32C011J4. Using STM32CubeIDE V1.15. I compile it for both Debug & Release.

I program it via STM32Programmer V2.10.

The Debug elf file works okay, however, the Release elf does NOT run…

Yes! I have checked that the Debug & Release files are up to date (and time)...

Yes! The NRST pin is correct level…

What else should I check?

Kind regards
Pedro

[Andrew Neil]

Look at what's different between your Release and Debug versions

[PGump.1]

Thank you for your reply.

There is no difference in the c code for the Release and Debug versions.

STM32CubeProgrammer reports Debug elf contains approx 2900 bytes, and 1050 bytes for the Release elf.

The only difference is the compiler options set by STM32CudeIDE.

Kind regards
Pedro

[Andrew Neil]

---

@PGump.1 wrote:

There is no difference in the c code for the Release and Debug versions.

---

No conditional compilation; including things like ASSERT - which will behave differently between release & debug ?

---

@PGump.1 wrote:

The only difference is the compiler options set by STM32CudeIDE.

---

So what is/are the difference(s) there?

[PGump.1]

Thanks again for your reply.

The compiler instructions are within the attached file...

I hope this helps.

Kind regards
Pedro

[PGump.1]

PS: HAL functions are only called during initialization, as per STM32CubeMX code generator.

I'm not calling any HAL functions in my portion of the code.

Other than Systick(), there are no interrupts.

Watchdogs are not enabled (yet).

Kind regards
Pedro

[Andrew Neil]

So here's the differences:

-g3 enables debug info in the ELF file:

https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#:~:text=Level%203%20includes%20extra%20information%2C%20such%20as%20all%20the%20macro%20definitions%20present%20in%20the%20program.%20Some%20debuggers%20support%20macro%20expansion%20when%20you%20use%20%2Dg3.

You could start by enabling that in the Release config, and then use the debugger to investigate what's going on.

-Os enables optimisation for size:

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#:~:text=Optimize%20for%20size.%20%2DOs%20enables%20all%20%2DO2%20optimizations%20except%20those%20that%20often%20increase%20code%20size%3A 

When changing (especially increasing) the optimisation level breaks your code, it usually indicates that there are latent bugs; eg, volatile missing where it should have been used.

[Andrew Neil]

---

@Andrew Neil wrote:

---

---

No conditional compilation; including things like ASSERT - which will behave differently between release & debug ?

---

You didn't address that question.

One way to check that would be to just define the DEDUG symbol in the Release build - change nothing else.

If that changes the behaviour, then you do have conditional code somewhere ...

[PGump.1]

Thank you for that informative reply.

This is stock solution using STM32CubeMX. I haven't made any changes to the compile options.

You could start by enabling that in the Release config, and then use the debugger to investigate what's going on.

---

I would like to do that, however, there's an issue with STM32CubeIDE V1.15, see

https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-v1-15-st-link-upgrade-problem/m-p/652172#M25268

---

When changing (especially increasing) the optimisation level breaks your code, it usually indicates that there are latent bugs; eg, volatile missing where it should have been used.

---

"volatile" maybe an issue... I'll try that tomorrow...

Kind regards
Pedro

[PGump.1]

PS: I have not added any conditional compiling. Any conditional compiling is due to STM32CubeMX code generator.

As far as I'm aware, in this application, only HAL functions use ASSERT. Apart from the initialization code (generated by STM32CubeMX) I'm not calling any HAL functions...

Kind regards
Pedro