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

[PGump.1]

---

@Andrew Neil wrote:

Note that 'volatile' has nothing to do with atomic access.

'volatile' just prevents the compiler from optimising-out accesses - it does nothing to control whether those accesses are atomic.

---

I had not made any connection between volatile and atomic. The connection was about synchronous functions, and your comment about a "race condition".

Kind regards
Pedro

[Andrew Neil]

---

@PGump.1 wrote:

---

---

I had not made any connection between volatile and atomic.

---

OK - was in reply to:

---

@PGump.1 wrote:

 If a compiler makes a boolean anything other than an atomic variable,

---

Sorry if I misinterpreted that.

[MM..1]

Go back to start. Your debug and release problems. I never on ARM use release, because result bin code is equal to debug when options is same. And i always debug with opti parameter set as for end app. Yes some debug parts then is harder , but code tested is same as code released. And i pref -O3 .

And about volatile, better is use __IO yes is alias, but mark variables updated in IRQs or shared threads...

When your issue isnt solved show code...

[PGump.1 · Accepted solution]

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

[Andrew Neil]

---

@PGump.1 wrote:

@MM..1  using Debug as Release is a waste of resources,

---

I think you missed that @MM..1 suggested using the same optimisation level - whether for "debgug" or "release"?

[Andrew Neil]

---

@MM..1 wrote:

Your debug and release problems. I never on ARM use release, ...

---

Even if you do have the same compiler settings for both "debug" and "release", I still see value in having the two configurations; eg,

• Debug might add diagnostic outputs;
• Release might disable the SWD interface altogether (eg, for low-power and/or security)
• etc, ...

[MM..1]

Yes and no. For designs with nano second precisions any different timing code is contra productive.

And i write only for user without knowledge, that switch same code from debug to release is waste of power and space on PC. For equal setup hex files equal for both.

[Andrew Neil]

Well, yes - you obviously wouldn't be putting debug traces into places in the code where nanosecond precision was required!

[PGump.1]

Hi all,

My original code had the declaration of my boolean variable in main.c as :-

bool x = false;

and in stm32c0xx_it.c as

extern bool x;

Swapping the declarations around is another solution.

This is because c compilers don't retain/share meta-data on variables between individual c files. In my case, x doesn't get written to in main(), the compiler wouldn't know that the declaration of x is going to be exported so, it is quite understandable that it is assumed to be non-volatile in main.c.

Swapping the declarations around stops the compiler from making that incorrect assumption...

The moral of this story is - this was a very simple project that I took far too simplistic approach too...

I hope this helps someone.

Kind regards
Pedro

[Andrew Neil]

---

@PGump.1 wrote:

My original code had the declaration of my boolean variable in main.c as :-

bool x = false;

---

That's the definition.

---

@PGump.1 wrote:

and in stm32c0xx_it.c as

extern bool x;

---

That's a declaration.

They need to be both qualified as 'volatile'.

Also, rather than manually transcribing the declaration into each source file that needs it, it would be better to have it in a header file; eg, in main.h:

extern volatile bool x;

Then both main.c and any/all other .c files which need it can #include "main.h"

Apart from the saving of duplication, this has the advantage that, when compiling main.c, the compiler will see both the declaration and the definition - thus will be able to detect any discrepancy.

See:

https://community.st.com/t5/stm32cubeide-mcus/adding-new-c-source-files-to-my-project-and-navigating-through/m-p/657455/highlight/true#M25847

And:

https://community.st.com/t5/stm32cubeide-mcus/adding-new-c-source-files-to-my-project-and-navigating-through/m-p/658310/highlight/true#M25925