Release build won't run
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-11 1:15 AM
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
Solved! Go to Solution.
- Labels:
-
STM32CubeIDE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-13 9:04 PM
@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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-14 1:43 AM
@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.
A complex system designed from scratch never works and cannot be patched up to make it work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-14 1:58 AM
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-14 8:58 PM
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... :face_with_tears_of_joy:
Kind regards
Pedro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-15 1:11 AM
@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"?
A complex system designed from scratch never works and cannot be patched up to make it work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-15 1:14 AM
@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, ...
A complex system designed from scratch never works and cannot be patched up to make it work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-15 6:37 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-15 6:40 AM
Well, yes - you obviously wouldn't be putting debug traces into places in the code where nanosecond precision was required!
A complex system designed from scratch never works and cannot be patched up to make it work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-15 5:53 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-16 1:01 AM
@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:
And:
A complex system designed from scratch never works and cannot be patched up to make it work.

- « Previous
- Next »