STM32 DFU上传失败GCC优化

Question

编辑：通过生成一个Makefile项目来解决问题，但是我仍然想知道发生了什么。

这个问题呼应了我这里提到的未解决的问题(STM32 app not running sometimes, remains in DFU)。

我有一个基于STM32L486的定制板，我使用内置的DFU模式在Linux上使用dfu-util在USB上上传新固件。

有时，由于未知的原因，应用程序将不会启动后，离开DFU模式。代码的微小变化可以使其工作或破坏它。(详见上文链接)。

可以逆转问题的更改示例：

• 添加/删除HAL_Delay或LED闪烁
• 数组大小为+1或-1
• 添加/删除sprintf格式

看起来可行的是使用Og优化构建二进制文件(或者使用STLink工具和调试模式)。

我尝试过增加堆和堆栈(默认为20倍)，它不会改变任何东西。在Atollic中检查准备死代码/数据删除选项似乎会使构建失败的次数比其他时候更多。

是什么原因导致应用程序没有启动，甚至是初始步骤？我怎样才能找到可能导致这种情况的罪魁祸首呢？

这能与内存对齐问题联系起来吗？

欢迎任何关于如何检查的想法/见解/评论。

我已经能够复制相同的问题(从这里和我的另一个链接)在一个核心板。

我试图从CubeMX生成一个Makefile项目，但问题没有发生。我想这是Atollic生成的二进制文件中的一个bug，或者IDE生成的编译器/链接器设置中的错误。

请注意，我的Makefile使用与Atollic完全相同的工具链，所以这不能是工具链问题。

这个问题在此被回避了，但我仍然想了解可能发生的事情。

Answer 1

据我所知，这个DFU问题和应用程序没有重新启动是在从Atollic (TrueStudio)构建时引起的。

从生成一个Makefile项目解决了这个问题，但我仍然无法解释原因。