STM32F3 Discovery + GNU ARM-Plugin + OpenOCD - kann die Binärdatei nicht auf das Board laden

Ich verwende das GNU ARM-Plugin für Eclipse mit Open OCD als Debugger. Dies ist unter Windows 10 x64. Das Problem, mit dem ich konfrontiert bin, ist der folgende Fehler, wenn ich versuche, das Beispielprogramm zu debuggen oder auszuführen:

Fehler in der abschließenden Startsequenz MI-Befehl konnte
nicht ausgeführt werden: C:\Development\stm32-test\Debug\stm32-test.elf
Fehlermeldung vom Debugger-Backend:
Laden fehlgeschlagen
MI-Befehl konnte nicht ausgeführt werden: C:\Development\stm32 laden -test\Debug\stm32-test.elf
Fehlermeldung vom Debugger-Backend:
Laden fehlgeschlagen
Laden fehlgeschlagen

Es gibt verschiedene Arten von STM32-Projektvorlagen, die das ARM-Plugin anbietet. Am bemerkenswertesten ist das "STM32Fxxx C/C++-Projekt", und es funktioniert sofort ohne Probleme. Aber es ist mit der alten Version der STM32-Bibliothek gebündelt. Ich wollte den neuesten STM32F3Cube verwenden, also habe ich die andere Vorlage verwendet – „Hello World ARM Cortex-M C/C++ project“, gemäß der Empfehlung dieses Artikels . Es wurde für die Verwendung mit dem STM32F3Cube entwickelt und kann nicht auf das Board geladen werden.

Bitte teilen Sie mir mit, welche weiteren Informationen zur Behandlung dieses Problems erforderlich sind oder wie ich detailliertere Protokolle usw. sammeln kann.

PS Ich habe die Debug-Konfigurationseinstellungen zwischen den funktionierenden und nicht funktionierenden Projekten verglichen und keinen Unterschied festgestellt. Dieselbe .cfg-Datei, zusammen mit allem anderen. Wird mein .elf abgelehnt, weil etwas damit nicht stimmt?

Vielleicht eine dumme Frage, aber sind Sie sicher, dass Ihre .elf-Datei generiert wird? Ist der Pfad korrekt?
@bitsmack: ja, dreifach geprüft. Sogar die .elf in einen anderen Pfad verschoben, Windows-Schrägstriche in Unix-Schrägstriche konvertiert usw. Immer der gleiche Fehler.
@bitsmack: Ich habe gerade Folgendes versucht: das problematische Projekt geöffnet -> Debug-Konfigurationen und anstelle der Binärdatei dieses Projekts den Elf aus dem anderen funktionierenden Projekt angegeben, das ich erwähnt habe. Also habe ich die Konfiguration dieses Projekts verwendet, um eine andere .elf-Datei zu starten, und es hat funktioniert. Anscheinend gibt es etwas damit, wie die .elf selbst kompiliert wird. Irgendeine Idee?
Die Optionen für RAM-Größe und Flash-Größe in Ihrem Projekt stimmen mit dem Zielboard überein? Außerdem gibt es einen Teil in dem Artikel, wo Sie die Flash-Startadresse im mem.ld-Skript ändern müssen. Alle diese Schritte sind in Ihrem Fall durchgeführt?
@BenceKaulics: Das war's, ich habe den Teil des Artikels zur Anpassung der Flash-Adresse verpasst! Danke, bitte poste dies als Antwort.

Antworten (1)

Aus der Fehlermeldung geht hervor, dass der Debugger nicht finden kann, wo der Flash beginnt, sodass er die Datei nicht laden kann.

In der F4-HAL-Eclipse-Vorlage ist diese Flash-Ursprungsadresse für einen STM32 korrekt eingestellt, da Sie jedoch ein allgemeines Cortex-M-Projekt verwenden, ist diese Adresse für einen STM nicht korrekt.

Dieser Schritt ist in dem von Ihnen erwähnten Artikel beschrieben. Aus dem Artikel :

Wir müssen konfigurieren, wie die Anwendung im MCU-Speicher abgebildet wird. Diese Arbeit wird vom Link-Editor (ld) ausgeführt, der die drei .ld-Dateien im Eclipse-Ordner /ldscripts verwendet. Die Datei, an der wir interessiert sind, ist mem.ld, und wir müssen die FLASH-Ursprungsadresse von 0x00000000 auf 0x08000000 ändern, wie unten gezeigt:

...
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
...

Dieser Wert kann dem Datenblatt entnommen werden. Hier der relevante Teil:

Geben Sie hier die Bildbeschreibung ein

STM32F3 Discovery + GNU ARM-Plugin + OpenOCD - kann die Binärdatei nicht auf das Board laden
AntwortenHierDatenschutz-Bestimmungen1y, 0v