嵌入式newlib-nano printf會導致硬件故障

我在兩個目標（一個飛思卡爾，一個STM32和皮質M4）上編譯「相同」代碼。我使用--specs=nano.specs，並且我已經實現了_write函數作爲空函數，並且這導致整個printf被GCC的-Wno-unused-function優化，即使STM32目標上的-O0（參見地圖）。這很好，我想重現一下飛思卡爾的目標。嵌入式newlib-nano printf會導致硬件故障

但是，在飛思卡爾目標（具有相同的編譯標誌）printf會導致硬故障。但是如果我一步一步地使用調試器（程序集步進），printf會在沒有硬性錯誤的情況下通過庫。簡單斷點斷點有時不能在printf中的任何位置命中和運行，也會導致硬錯誤（因此它不太可能是外設問題）。

到目前爲止，我檢查堆棧和堆不重疊和其他一些牽強拆卸。

爲什麼printf優化不在freescale目標上？什麼可以導致庫代碼hardfault？爲什麼在進行組裝一步一步的調試時可以嗎？

編輯：

採用ARM-無 - EABI - 海合會兩個MCU具有相同的庫5.4.1。
我不想刪除printf，這只是第一步能夠使用他們與否。
矢量表有默認弱向量所有ISR所以應該OK
使用register dump似乎出現故障的指令是在地址4（復位向量），所以現在新的問題是：爲什麼芯片復位？

來源

2017-09-25 Julien

問題在其他地方是100％。 –

@ PeterJ_01這正是我需要解決這個問題的原因，因爲我不知道其他地方會發生什麼。您的評論可以更有用嗎？ – Julien

不幸的是，如果沒有實際的軟件和硬件，DH很難進行診斷。我擔心這是不可能的。使用我的水晶球 - 我賭矢量表的問題 - 沒有正確初始化或某些向量拖欠DH。當你使用調試器中斷時沒有觸發。當你運行程序「正常」的方式觸發。也許定時器，也許systick，也許別的東西。你有兩個不同的初創公司 - 需要自己看看。我知道我寫了什麼。如果是100％在別的地方。 –

當ARM應用程序似乎正常工作，直到使用printf時，最常見的問題是堆棧未對齊。在調用printf的函數的入口點放置一個斷點並檢查堆棧指針。如果指針不是雙字對齊的，那麼你已經發現了你的問題。

來源

2017-09-26 21:10:21

堆棧指針對齊：在printf之前的0x1fff18e0和在hardfault中的0x1fff1830。鏈接器腳本是正確的'。 = ALIGN（4）;' – Julien

@Julien那不是你的問題，但它通常是'ALIGN（8）;'以確保堆棧位於雙字邊界上。 –

@D克魯格，只是爲了我的理解，爲什麼對齊（8）？是不是一個DWORD 4字節？ – Julien

嵌入式newlib-nano printf會導致硬件故障

回答

相關問題