STM32 DFU upload fails and GCC optimisations

0
votes

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 :

  • Adding / removing a HAL_Delay or a LED Blink
  • +1 or -1 on an array size
  • Adding / removing a sprintf format

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.

1
gccstm32dfu
How do you prepare your firmware image for DFU? Have you tested your procedures on some ST eval. board? - ddbug
Hi @ddbug, I have been indeed been able to reproduce this with a Nucleo board and still have the problem. I have edited my answer with my advancements - d6bels
What is the stack and heap size now, after you increased it? Can you give more info on how the build fails with Atollic? Try to disable optimization or at least remove dangerous optimization options. If it won't help, I'd suggest to ask on the ST forum -- it is ugly, but helpful. - ddbug
@ddbug I tried to increase them up to 8000B but it didn't change anything. Just to be clear, the build does not fail, only the DFU update with the binary generated by Atollic does (and works fine using a Makefile project). Tried all optimizations from O0 to O3 with Os and Og as well. I may post one day on ST yes, but kinda in a rush now with the time lost with that bad joke! - d6bels

1 Answers

0
votes

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.