2022-01-29 08:29 AM
I am beginner with STM32CubeIDE 1.8.0 and am having trouble delivering release mode firmware to the attached target (STM32F0Discovery module, which is otherwise working well.)
I am now experimenting with switching from Debug (the default configuration of the project when it was first generated, beginning with STM32CubeMX) and Release (my goal) using the small hammer-like icon near the left end of the icon ribbon just below the main menu of STM32CubeIDE.
When I switch from debug to release this way, I can go to Project > Properties and see in the main pane C/C++ Build that Configuration has switched from Debug to Release [Active]. It is clear from the compiler/linker console messages that the text size of the resulting binary (elf) file is changing as expected between release (smaller) and debug (larger) configuration.
To download firmware to the target, I am always using Run > Run (I suspect this is my problem, but I'm not certain, hence my question.)
I think the previously generated debug binary is being sent to the target, rather than the more-recently built release binary (I've gone back and forth a couple of times changing something in the source code to see if the change propagates to the target.)
Is there a different method to push the built project's binary to the target when using release configuration?
Thank you for any advice, referrals to documentation, or requests for clarification.
Solved! Go to Solution.
2022-01-29 01:00 PM
Well, looks like your source code is sensitive to compiler optimization. This is a bad sign. Could be a timing issue or a missing use of volatile, __IO or other hints to the complier. Hard to tell.
You may increase the optimization level in debug mode or decrease it in release mode and see what happens. You may also strip down your code to find the sensitive parts.
hth
KnarfB
2022-01-29 09:22 AM
When you debug (bug icon) or run (green button) for the very first time, a debug configuration (.launch file) for your project is created. If you switch the configuration later to release, the same old debug configuration is still used. You can create a new one by pressing the small down arrow near the debug/run icon. A drop down menu appears, select Debug/Run configurations... and you can edit your settings, create a duplicate etc..
hth
KnarfB
2022-01-29 12:07 PM
Thank you, KnarfB. I have now been able to build (hammer icon), and run (green icon) build and release configurations created for my (very small test) project. I am now confident that the correct binary is being sent to the target.
This progress has uncovered a different problem, which is that my test application does not run properly (USART peripheral begin accessed in polled mode with interrupts disabled) when in Release configuration. I do not believe this is related to build/debug configuration management (the debugger is not active when the target is running), so I now need to learn what differences to application 'text' (executable code) exist between release and debug configuration.
Thank you again for your help!
2022-01-29 01:00 PM
Well, looks like your source code is sensitive to compiler optimization. This is a bad sign. Could be a timing issue or a missing use of volatile, __IO or other hints to the complier. Hard to tell.
You may increase the optimization level in debug mode or decrease it in release mode and see what happens. You may also strip down your code to find the sensitive parts.
hth
KnarfB
2022-01-29 02:29 PM
Fortunately it is very small code; I am experimenting with avoiding any dependency on HAL or LL functions. I have been preparing to reduce the code to minimum example that will duplicate problem.
Thank you again for your help, at least now I can manage debug/release successfully, and also now I can expose this problem of dependency on debug mode (which I did not realize before.)
Dave
2022-01-29 03:42 PM
KnarfB --- Brilliant!
The cause was exactly what you suggested - I lacked a "volatile" declaration involved in reading the USART status register. I made very tiny change for this, and now the code is identical function in Debug or Release configuration. In my prior life, I was only using assembly language for MCU programming, but that is not so practical for STM32 so I am migrating to C --- sometimes these details are still new for me...
THANK YOU -- you have taught me many very useful things today as I learn STM32CubeIDE and STM32 with GCC.
Dave
2022-01-31 09:44 AM
@wb0gaz, with respect to you original post:
--------------
I think the previously generated debug binary is being sent to the target, rather than the more-recently built release binary (I've gone back and forth a couple of times changing something in the source code to see if the change propagates to the target.)
Is there a different method to push the built project's binary to the target when using release configuration?
--------------
Maybe you are already aware, if so, I will still clarify one point to make sure other community members reading this thread does not get confused. :)
As you state there are CubeIDE by default (most often) provides two build configurations, Debug and Release.
Build configurations are separate from launch configurations.
The launch configurations can be used to:
What we have to take care about is that by default ONE launch configuration is explicitly set to point at the build output from ONE build configuration.
So, when building the second build configuration (Release in your case), we should create a second launch configuration pointing at this "optimized" elf-file...
You can change the default behavior and rely on just one launch configuration which then can follow and point to at the elf-file being built by the Active build configuration.
Have a look at this drop-down menu:
Not sure if it brings anything to this discussion or just raises questions..
Anyway, welcome to the C / STM32 world! :)
2022-01-31 09:48 AM
Thank you, Mattias, I appreciate the good detail.
I am having much better result now that I have learned more about STM32CubeMX and STM32CubeIDE. I am successfully delivering debug and build configurations and it is working well. C/STM32 is favorite environment now.
---> I have a small new feature request I wish to submit to the STM32CubeIDE team. Can you tell me where I could submit this feature request? <---
Dave
2022-02-02 03:49 AM
Well, we try to read most things on the forum/PM/etc.
I would recommend that you submit your request in the Idea Zone.
In the idea zone other STM32 users will eb able to up-vote good ideas. It helps us make priorities...
https://community.st.com/s/ideazone
We review new ideas that are filed towards STM32CubeIDE once per week.