STM32 DFU上載失敗並進行GCC優化

Question

編輯 ：通過生成Makefile項目來解決問題，但我仍然想知道發生了什么。

這個問題與我在這里提到的未解決的問題相呼應（ STM32 app有時不運行，仍然在DFU中 ）。

我有一個基於STM32L486的定制板，我使用內置的DFU模式在Linux上使用dfu-util通過USB上傳新固件。

有時，由於未知原因，應用程序將在離開DFU模式后無法啟動。 代碼的細微變化可以使其工作或破壞它。 （詳見上文鏈接）。
可以解決問題的更改示例：

• 添加/刪除HAL_Delay或LED閃爍
• 數組大小為+1或-1
• 添加/刪除sprintf格式

似乎有用的是使用Og優化（或使用STLink工具和調試模式）構建二進制文件。

我試圖增加堆和堆棧（默認值高達20倍），它不會改變任何東西。 檢查Atollic中的准備死代碼/數據刪除選項似乎使構建失敗比其他時間更多。

什么可能導致應用程序無法啟動的問題，甚至是初始步驟？ 如何追蹤可能導致此問題的罪魁禍首？
這可能與內存對齊問題有關嗎？

歡迎任何關於如何檢查的想法/見解/評論。

---

我能夠在Nucleo板上重現相同的問題（從這里和我的其他鏈接）。
我試圖從CubeMX生成一個Makefile項目 ，但問題不會發生。 我想這是由Atollic生成的二進制文件或IDE的編譯器/鏈接器設置中的錯誤。
請注意，我的Makefile使用與Atollic完全相同的工具鏈，因此這不是工具鏈問題。
特此繞過這個問題，但我仍然想了解可能發生的事情。

Answer 1

據我所知，當使用Atollic（TrueStudio）構建時，會導致此DFU問題和應用程序無法重新啟動。

從CubeMX生成一個Makefile項目解決了這個問題，雖然我還是無法解釋原因。