2014-12-23 18 views
8

Ich habe eine Anwendung, die ich von der Kieler IDE portiere, um mit der GNU-Toolkette aufgrund von Lizenzproblemen zu bauen. Ich bin erfolgreich in der Lage, die Anwendung auf dem Gerät einzurichten, zu erstellen, zu flashen und auszuführen.STM32 WWDG Interrupt feuern, wenn nicht konfiguriert

Die Anwendung auf der GNU-Seite ist aus irgendeinem Grund in der schwachen verknüpften IRQ-Handler für die WWDG stecken, die eine Endlosschleife ist. Die Anwendung aktiviert die WWDG nicht, und sie ist beim Zurücksetzen standardmäßig deaktiviert. Ich habe auch überprüft, dass die Konfigurationsregister ihre Standardstartwerte haben.

Der einzige Unterschied, außer Compiler, sind die Linker und Startup-Dateien. Sowohl die Startdateien als auch die Linkerdateien, die von beiden Toolketten verwendet werden, sind jedoch Standardwerte, die von STM generiert werden.

Irgendeine Idee, was das verursachen könnte? Ich bin hier ungefähr am Ende.

Mit dem stm32f103XX, lassen Sie mich wissen, wenn andere Informationen hilfreich wären.

EDIT: Mit den Kommentaren unten konnte ich feststellen, dass es tatsächlich der HardFault_Handler ist, der ausgelöst wird. habe ich die Backtrace Ausgangs unten umfassen, wenn diese Hilfe sein kann

GDB BT:

0 HardFault_Handler()

1 (Signal-Handler genannt)

2 0x720a3de in ??()

3 0x80005534 in foo()

Backtrace gestoppt: vorherigen Frame identisch mit diesem Rahmen

2 Dinge stehen, um mich, obwohl im nicht GDB-Experten (korrupter Stack?). 1) foo ist keine Funktion, es ist ein const Array von Zeichen und 2) 0x0720a3de ist keine gültige Speicheradresse der Flash-Adressbereich beginnt bei 0x08000000

+1

Sind Sie sicher, dass es wirklich die WWDG ist? Ein anderes 'while (1);' kann diesen Code aufgrund der Optimierung teilen. Zeigt die Kartendatei nur die WWDG an dieser Adresse an? –

+0

Sie sind vielleicht auf etwas. Es scheint, dass in der .elf-Datei alle Standard-IRQ-Symbole auf die gleiche Adresse zeigen, was bedeutet, dass es nur ein Zufall ist, dass der WWDG_IRQ-Name im Debugger ist. Ich werde stong Link-Funktionen für die IRQ hinzufügen, damit ich herausfinden kann, welcher genau der Schuldige ist. – gettingSmarter

Antwort

7

Also danke an den Tritt in die Hose von D Krüger. Ich konnte feststellen, dass HardFault_Handler das war, was tatsächlich aufgerufen wurde. Wer also in diesem Post stolpert, verifiziert, welcher IRQ wirklich aufgerufen wird, indem er temporäre Funktionen schreibt, um die wahrscheinlichen Täter, d. H. HardFault, abzudecken. Das eigentliche Problem für den IRQ-Aufruf ist ein schlechter Speicherzugriff von memcpy, auf dem ich als nächstes auf dem Weg bin zu lösen.

+0

Ich bin mir ziemlich sicher, dass Sie feststellen werden, dass der schlechte Speicherzugriff nicht "* von memcpy *" ist, sondern * Ihr Anruf * zu memcpy. – Clifford

+2

Der letzte Schuldige stellte sich heraus, dass ich nicht mit den richtigen Optionen verlinkt war, mit denen ich mich zusammenarbeitete. Ich habe vergessen, mit den Optionen -mthumb und -mcpu = cortex-m3 zu verknüpfen. Also habe ich mit den falschen C-Bibliotheken verlinkt. – gettingSmarter

4

Ich hatte genau den gleichen Fehler wie OP (scheinbarer WWDG-Interrupt, aber eigentlich HardFault_Handler feuern), wenn ein Beispiel für die STM32F3-Discovery-Platine in CooCoX CoIDE 1.7.7 mit STM32Cube F3-Bibliotheken (v1.1.0) kompiliert wird. Der Code lief einwandfrei, solange ich keine Interrupts verwendete, aber sobald ich den SysTick-Timer-Interrupt einschaltete, stoppte die HardFault-Ausnahme.

Das Problem war, dass ich die Dateien stm32f3xx_it.h und stm32f3xx_it.c im Projekt vernachlässigt hatte. Ihre Abwesenheit verursachte keine Compiler-Warnungen/Fehler. Sobald sie & verknüpft wurden, lief der Code mit Unterbrechungen gut.

0

Ich hatte ein sehr ähnliches Problem beim Zusammenführen von zwei Projekten, die separat von STM32CubeMX für einen STM32F2XX-Prozessor generiert wurden. Ein Projekt verwendete das Ethernet-Peripheriegerät, das andere nicht. Abgesehen von diesem einen Unterschied verwendeten die beiden Projekte den gleichen Satz Peripheriegeräte.

Nach der Integration der beiden Projekte durch manuelles Kopieren von Dateien, würde die Anwendung nach dem Start der ersten Aufgabe (wenn Interrupts zum ersten Mal aktiviert werden) in der WWDG_IRQHandler enden. Ich habe zuerst bestätigt, dass das WDGA-Bit des WWDG-Registers tatsächlich nicht gesetzt war und daher das WWDG-Peripheriegerät deaktiviert wurde. Als nächstes verifizierte ich, dass die Interrupt-Vektortabelle korrekt initialisiert wurde. Schließlich, nach mehreren Stunden des Grabens, erkannte ich, dass ich die ETH_IRQHandler-Funktion in stm32f2xx_it.c nicht definiert hatte, was dazu führte, dass der Ethernet-Interrupt vom Standard-Handler behandelt wurde und sich als WWDG_IRQHandler maskierte - wahrscheinlich aufgrund der Optimierung.

0

Ich hatte dieses Problem aufgrund der gleichen Ursache wie awilhite. Ich verwende Atollic TrueStudio 8.0.0. Ich habe es verwendet, um ein Projekt für STM32F030 und (wahrscheinlich manuell) hinzugefügt Bibliotheken Ordner mit stm32f0xx.h, die ADC1_IRQn definiert (IRQ Kanalnummer in NVIC-Setup verwendet).

Und ich implementiert ADC1_IRQHandler (void) in meinem main.c (wie ich es gewohnt bin und es funktionierte immer so weit - x_IRQn -> x_IRQHandler)

Aber nach 2 Tagen Frustration, fand ich heraus, Das startup_stm32f0xx.s in meinem Projekt definiert ADC1_COMP_IRQHandler.

Also, mein ADC-Interrupt-Handler war undefiniert und als der ADC den Interrupt erzeugte, stürzte das Programm ab (WWDG-Interrupt).

Ich hoffe, dies hilft Leuten wie mir, die denken, dass sie ihren Handler implementiert haben, aber tatsächlich taten sie es nicht.