GCC Optimizations result in application not running
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-07-24 08:41 AM
Any time I set any optimization level for GCC my application will not longer start. I can set G++ optimization to anything and it still works fine as long as GCC optimization is set to -O0. This project uses TouchGFX and FreeRTOS.
While in debugger I can step through to where the osKernelStart() and then let it go and it runs fine. If just run out of the gate in the debugger the trace below show failure in touchgfx InitializeView, maybe I need some delay before starting TouchGFX?
Any suggestions as to what I should look at to resolve this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-07-24 12:09 PM
Debug your hard fault and find out exactly what is failing. CubeIDE has a fault analyzer, and there are several (many?) posts here about coding your own. Could be an interrupt race condition, or do you have any delays that are simple "for" loops that might get optimized out of the compiled code?
Since the stack trace shows the last function as calculating the bounding area, you probably have a divide-by-zero issue where some data structure is getting used before it is getting (fully) initialized.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-07-24 12:37 PM
Optimization tends to worsen any latent failings in the code.
Trace the hardfault backward, understand the underlying cause and paths too it. Instrument code. Sanity check parameters. Perhaps enable assert()s where available, or add your own.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-07-24 03:32 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-06 09:33 PM
I have had the same problem at times. As I recall not qualifying a variable as volatile can do this as the compiler optimisation can change the execution order of instructions. Any variables that can be modified in different threads or interrupt handlers will cause these problems. :smiling_face_with_smiling_eyes: volatile is your friend.
Another problem I had was I forgot to intialise a counter in a thread and ended up trying to change an address protected by the Memory Control unit. You can see these types of faults in the fault analyzer.