gccstm32dfu

STM32 DFU upload fails and GCC optimisations


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 :

What 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.


Solution

  • 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.