cancel
Showing results for 
Search instead for 
Did you mean: 

Release build won't run

PGump.1
Senior

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

1 ACCEPTED SOLUTION

Accepted Solutions
PGump.1
Senior

Hi all,

I'm happy to report that 'volatile' has fixed it! @Andrew Neil  thank you for planting that seed.

@MM..1  using Debug as Release is a waste of resources, particularly in parts with very limited resources.

Anyway, if I hadn't been so lazy, I would have coded it up in assembler, and saved myself a week... 😂

Kind regards
Pedro

View solution in original post

29 REPLIES 29
Andrew Neil
Evangelist III

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

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

 


@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?

 

Thanks again for your reply.

The compiler instructions are within the attached file...

I hope this helps.

Kind regards
Pedro

PGump.1
Senior

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

So here's the differences:

AndrewNeil_0-1712845176269.png

 

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

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

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