STM32 DFU上传失败及GCC优化

Question

Edit : 通过生成 Makefile 项目规避了问题，但我仍然想知道发生了什么。

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

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

有时，由于未知原因，应用程序在退出 DFU 模式后无法启动。 代码中的轻微更改可以使其正常工作或破坏它。 （有关详细信息，请参阅上面的 link）。
可以扭转问题的变化示例：

• 添加/移除一个 HAL_Delay 或一个 LED Blink
• +1 或 -1 数组大小
• 添加/删除 sprintf 格式

似乎可行的是使用 Og 优化（或使用 STLink 工具和调试模式）构建二进制文件。

我已经尝试增加堆和堆栈（默认值高达 20 倍），但没有任何改变。 检查 Atollic 中的 prepare dead code/data removal 选项似乎比其他时候更容易导致构建失败。

什么可能导致应用程序无法启动，甚至初始化步骤也无法启动？ 我怎样才能找到可能导致这种情况的罪魁祸首？
这可以 link 解决内存对齐问题吗？

欢迎就如何检查提出任何想法/见解/意见。

---

我已经能够在 Nucleo 板上重现相同的问题（从这里和我的另一个 link）。
我尝试从 CubeMX 生成一个 Makefile 项目，但问题没有发生。我想这是 Atollic 生成的二进制文件或 IDE.
的 compiler/linker 设置中的错误 请注意，我的 Makefile 使用与 Atollic 完全相同的工具链，因此这不是工具链问题。
这个问题特此规避，但我还是想了解可能会发生什么。

Answer 1

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

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