Edit : Problem circuvented by generating a Makefile project but I'd still like to know what is going on.
This question echoes my unresolved problem mentioned here (STM32 app not running sometimes, remains in DFU).
I have a custom board STM32L486 based and I am using the built-in DFU mode to upload new firmware over USB using dfu-util on Linux.
Sometimes, for unknown reasons, the app won't start after leaving the DFU mode.
A slight change in code can make it work or break it. (see link above for details).
Examples of changes that can reverse the problem :
HAL_Delay or a LED Blinksprintf formatWhat seems to work is building the binary with Og optimisation (or using the STLink tool and debug mode).
I have tried to increase the heap and stack (up to 20x the default), it doesn't change anything. Checking the prepare dead code/data removal options in Atollic seem make build fail more than other times.
What could be causing the issue of the app not starting, not even the init steps ?
How can I track down the culprit flags that may cause this ?
Can this be linked to a memory alignment problem ?
Any ideas / insights / comments on how to check is welcome.
I have been able to reproduce the same issues (from here and my other link) on a Nucleo board.
I tried to generate a Makefile project from CubeMX and the problem does not happen. I guess this is a bug in either the binary generated by Atollic or the compiler/linker settings that the IDE.
Note that my Makefile uses the exact same toolchain as Atollic so this cannot be a toolchain issue.
This issue is hereby circumvented by this, but I'd still like to understand what may happen.
As far as I've tried, this DFU issue and app not rebooting is caused when building from Atollic (TrueStudio).
Generating a Makefile project from CubeMX solved this issue though I still cannot explain why.