2014-12-23 124 views
8

由於許可問題,我有一個應用程序從基爾IDE移植到GNU工具鏈。我已成功地在設備上設置,構建,閃存和運行應用程序。未配置STM32 WWDG中斷觸發

由於某種原因,GNU端的應用程序陷入了無限循環的WWDG的弱鏈接IRQ處理程序中。該應用程序不啓用WWDG,並且在默認情況下在重置時禁用。我還驗證了配置寄存器處於其默認啓動值。

編譯器以外的唯一區別是鏈接器和啓動文件。但是,兩個工具鏈使用的啓動文件和鏈接程序文件都是STM生成的默認文件。

任何想法可能會導致此?我在我的智慧在這裏結束。

使用stm32f103XX,讓我知道是否有任何其他信息會有所幫助。

編輯: 使用下面的評論我能夠斷言它實際上是被觸發的HardFault_Handler。 我有包括回溯輸出低於如果可能的幫助

GDB BT:

0 HardFault_Handler()

1(信號處理程序調用)

2 0x720a3de在?? ()

3 FOO 0x80005534()

回溯停止:前幀等同於該框架

兩件事情中脫穎而出對我來說,雖然IM沒有GDB專家(堆棧損壞?)。 1)foo不是一個函數,它是一個字符的常量數組,2)0x0720a3de不是有效的內存地址,flash地址範圍從0x08000000開始

+1

你確定它真的是WWDG嗎?另一個'while(1);'可能由於優化而共享該代碼。地圖文件是否只顯示該地址處的WWDG? –

+0

你可能正在做某事。看起來,在.elf文件中,所有默認的irq符號都指向相同的地址,我想這意味着WWDG_IRQ的名稱是調試器中的ues。我將爲irq添加stong鏈接函數,以便我可以找出究竟哪一個是罪魁禍首。 – gettingSmarter

回答

7

所以感謝D Krueger的褲子踢。我能夠弄清楚HardFault_Handler是實際被調用的內容。所以,凡是在這篇文章中絆腳石的人,通過編寫臨時函數來覆蓋可能的肇事者,即HardFault,來驗證哪個IRQ確實被調用。 IRQ調用的真正問題是memcpy對內存的訪問不正確,我正在接下來要解決的問題。

+0

我很肯定你會發現不好的內存訪問不是「* by memcpy *」,而是*你的調用*到memcpy。 – Clifford

+2

最後的罪魁禍首竟然是我沒有把我正在編譯的正確選項聯繫起來。我忘了鏈接-mthumb和-mcpu = cortex-m3選項。所以我連接了不正確的c庫。 – gettingSmarter

4

當使用STM32Cube F3庫(v1.1.0)在CooCox CoIDE 1.7.7中編譯STM32F3查找板時,我與OP(明顯的WWDG中斷,但實際上是HardFault_Handler觸發)完全相同的錯誤。只要我沒有嘗試使用任何中斷,代碼就會正常運行,但只要打開SysTick計時器中斷,HardFault異常就會被觸發。

問題是我忽略了在項目中包含stm32f3xx_it.h和stm32f3xx_it.c文件。他們的缺席並沒有導致任何編譯器警告/錯誤。一旦編譯鏈接&,帶有中斷的代碼運行良好。

0

當STM32F2XX處理器合併兩個由STM32CubeMX單獨生成的項目時,我遇到了一個非常類似的問題。一個項目使用以太網外設,而另一個則不是。除了這一點之外,這兩個項目使用了相同的外設。

通過手動複製文件將兩個項目集成在一起之後,應用程序將在啓動第一個任務(第一次啓用中斷)後結束於WWDG_IRQHandler。我首先確認了WWDG寄存器的WDGA位確實未設置,因此WWDG外設被禁用。接下來,我驗證了中斷向量表已正確初始化。最後,經過幾個小時的挖掘之後,我意識到我沒有在stm32f2xx_it.c中定義ETH_IRQHandler函數,這引發了以太網中斷被默認處理程序處理,將其本身掩蓋爲WWDG_IRQHandler - 可能是由於優化。

0

我有這個問題,原因與awilhite相同。我正在使用Atollic TrueStudio 8.0.0。我用它來啓動STM32F030的項目,並且(可能是手動)添加stm32f0xx.h庫文件夾,該文件夾定義了ADC1_IRQn(在NVIC設置中使用的IRQ通道編號)。

而且我在main.c中實施ADC1_IRQHandler(無效)(因爲我已經習慣了,它總是迄今的工作 - x_IRQn - > x_IRQHandler)

但後2天的挫折,我發現,我項目中的startup_stm32f0xx.s定義了ADC1_COMP_IRQHandler。因此,最終,我的ADC中斷處理程序未定義,當ADC生成中斷時,程序崩潰(WWDG中斷)。

我希望這對像我這樣的人有幫助,他們認爲他們確實實施了他們的處理程序,但實際上他們沒有。