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]

You still haven't addressed the question about conditional code.

As suggested in the other thread, you really need to get a working debugger!

[Andrew Neil]

---

@PGump.1 wrote:

As far as I'm aware, ...

---

So why not give it a go - and remove all doubt?

[PGump.1]

---

@Andrew Neil wrote:

You still haven't addressed the question about conditional code.

---

I don't know what more I can tell you about this...

---

@Andrew Neil wrote:

As suggested in the other thread, you really need to get a working debugger!

---

As I said on the other tread, several times, the debugger is embedded in this system - I cannot change it.

I have rolled STM32CubeIDE back to V1.14 - V1.15 is far too problematic...

Kind regards
Pedro

[PGump.1]

I think 'volatile' is the key - I'm passing a boolean from Systick() to main() via a global variable. I can see how a compiler may think this is a static value...

The machine this fitted to is busy today. I'll try it Monday...

Kind regards
Pedro

[Andrew Neil]

---

@PGump.1 wrote:

As I said on the other tread, several times, the debugger is embedded in this system - I cannot change it.

---

Surely you can change it just for the purpose of solving this issue?

[Andrew Neil]

Another common one is race conditions in the code. And other marginal timing.

You might get away with these in the unoptimised (slower) Debug build, but they bite you in the optimised (faster) Release build.

[PGump.1]

Thanks for the input. An interesting point given that Systick() and main() are asynchronous. However, I should point out that I'm using C (not C++), and the interconnection between the two functions is a boolean variable. If a compiler makes a boolean anything other than an atomic variable, particularly for an ARM processor, then it is a rubbish compiler...

Even if the compiler handled this boolean variable in a non-thread-safe manor, it can only be interpreted as True or False. Only a rubbish compiler could do something different...

Kind regards
Pedro

[Andrew Neil]

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.

[Tesla DeLorean]

So the likely scenario here is that's you're looping on a variable that the compile thinks is invariant and it's optimized out of the loop. If a variable is changing outside of normal code flow it needs to be volatile so that the content is re-read at each iteration.

[PGump.1]

---

@Andrew Neil wrote:

---

@PGump.1 wrote:

---

Surely you can change it just for the purpose of solving this issue?

---

Yes, I can. I've rolled STM32CubeIDE back to V1.14. V1.15 is far too problematic...

Kind regards

Pedro