STM32 + NetBeans =?

Wie Sie wissen, eignet sich die Kompatibilität mit GNU-Tools und die Unterstützung von GDB für nahezu jede beliebte Entwicklungsumgebung zum Debuggen einer Vielzahl eingebetteter Plattformen, meistens kostenlos und legal. In der Theorie.

Was passiert in der Praxis, wenn versucht wird, sich mit STM32 und NetBeans anzufreunden, und ist es im Prinzip möglich, ein funktionsfähiges System mit Unterstützung für die neuesten Steine ​​zu erhalten - unter dem Schnitt.

Einige Texte

Ich wollte den Mikrochip wirklich nicht verlassen. Nach dem Kauf durch Atmela vertuschten sie jedoch zunächst möglicherweise eine der vielversprechendsten Familien im Portfolio des Unternehmens - PIC32MM und dann die gesamte MIPS-Linie. Es wurde deutlich, dass der Übergang zu ARM auf absehbare Zeit unvermeidlich ist, da der Mikrochip seit zwei Jahren die Unterstützung von Atmelovsk-Controllern nicht in sein Ökosystem integriert hat und „Stay with us“ keine Vorteile brachte. Im Gegenteil, die Preispolitik nach oben und die traditionellen organisatorischen Schwierigkeiten des Zusammenschlusses machten Atmelovskiye AWPs weniger attraktiv. Gleichzeitig tauchte ein Projekt auf, über das der PIC32MZ einfach gestolpert ist. Eine kritische Masse wurde erreicht.

Warum STM: breite Marktabdeckung, Budget-Debugging, eine kostenlose Open-Source-Umgebung mit vollem Funktionsumfang auf Basis von Open-Source-SW4STM32, der politische Aspekt - ST Microelectronics wird von der französischen Regierung als strategische Ressource unterstützt, sodass ein plötzlicher Marktaustritt oder eine plötzliche Übernahme anscheinend nicht gefährdet sind.

Debugging - Erste Eindrücke

SW4STM32 wurde auf herkömmliche Weise installiert - durch wiederholtes Drücken der Schaltfläche Weiter> (* im Folgenden finden alle Experimente unter Win7 x64 statt). Ein Demo-Projekt, das zum Testen der gewünschten Funktion geeignet war, wurde aus dem STM32Cube-Firmware-Paket entfernt. Alles funktionierte mehr oder weniger sofort. Der erste Start des JTAG-Emulators hinterließ einen Eindruck: Der gesamte Zyklus des Aufrufen des Debug-Modus, beginnend mit der Verbindung und endend mit dem Stopp am Anfang von main () mit Aktualisierung des Kontexts, kann in 1-2 Sekunden passen. Im Vergleich zu Mikrochip-Debuggern (sogar REAL ICE für eine halbe Hälfte) ist der Geschwindigkeitsunterschied ein Vielfaches!
Und doch etwas unangenehm Überraschtes.

Was ist los mit Eclipse / SW4STM32

Eine Vielzahl von Einstellungen und unlogischer Organisation, versteckte Menüelemente, Perspektiven, Schnittstellenfehler und visuelle Artefakte, fehlende häufig verwendete Tasten und Funktionen in der Symbolleiste, kleine ungeschickte, unlesbare Piktogramme und Markierungen sowie das Fehlen von „Verwendungen finden“ sind teilweise subjektiv, und Sie können sie anpassen, wenn Sie dies wünschen . Aber: vergisst regelmäßig, die geänderten Dateien vor dem Zusammenbau zu speichern, obwohl alle Häkchen bei Bedarf vorhanden sind; Beim erzwungenen manuellen Speichern werden keine Änderungen angezeigt, und die inkrementelle Baugruppe erweist sich als irrelevant. Es gibt keine vollständige Neuerstellung (Clean and Build) als einzelnes Team. Nach der erzwungenen Bereinigung durch Clean Project schlägt die Assembly fehl (Dateizugriff?) und wird erst nach dem 4. Versuch erfolgreich abgeschlossen. Dies kann nicht mehr angemessen erklärt werden. Selbst die frühen MPLAB X Beta-Versionen, die auf den alten NetBeans 6.xx basieren, hatten vor 10 Jahren nicht die gleichen Probleme wie die offiziell unterstützte Entwicklungsumgebung für STM32 heute.

Darüber hinaus sind mit SW4STM32 bereits 3 Kopien typischer IDEs im System gewählt, da außerdem MPLAB X noch fest mit NetBeans 8.0.1 verbunden und etwas eingezäunt ist (d. H. Es ist unmöglich, es für andere Sprachen / Plattformen zu verwenden). und NetBeans 8.2 für Java und C / C ++.

Es stellt sich heraus, dass durch das Einrichten von NetBeans 8.2 für STM32 die beschriebenen praktischen Probleme von Eclipse beseitigt, die Anzahl der IDE-Kopien verringert und auf eine Plattform reduziert werden, wenn auch geringfügig andere Versionen.

NetBeans 8.2 und GNU ARM Tools

NetBeans ist besser für die Verwendung von 32-Bit geeignet, da zusätzlich zum doppelten Speicherverbrauch die Unterschiede der 64-Bit-Version nicht gefunden werden konnten.

Google fand schnell eine Installationsanleitung . Der grundlegende Unterschied bestand nur im Betriebssystem (sie haben Linux gegen Win7 x64 für mich), so dass die Installation der * nix-Umgebung MSYS, die Teil des MinGW-Pakets ist, zu einem Gewinnspiel wurde. Die Toolchain-Einstellungen sollten ungefähr so ​​aussehen:


Ein wichtiger Punkt: Wählen Sie beim Hinzufügen der GNU ARM-Toolchain die Familie „GNU MinGW“ aus. In diesem Fall ruft NetBeans MSYS korrekt auf. Wenn Cygwin bereits auf dem Computer installiert ist, ist es logisch, es zu verwenden. Dementsprechend sollte die GNU ARM-Familie „GNU Cygwin“ auswählen.

Eine erfolgreiche Zusammenstellung zu erreichen war nicht einfach, aber sehr einfach. Da SW4STM32 denselben Compiler verwendet, überprüfen Sie die Befehlszeile des Compileraufrufs in SW4STM32 und kopieren Sie die fehlenden Schlüssel in Projekteigenschaften → C-Compiler → Zusätzliche Optionen


Wir erhalten genau das gleiche Ausgabeergebnis, aber mit einem wichtigen praktischen Unterschied: Alles wird beim ersten Mal gesammelt, es gibt Clean and Build und es funktioniert einwandfrei:


Dieses Ergebnis kann jedoch auch durch Hinzufügen der optionalen Post-Build-Verarbeitung verbessert werden. Öffnen Sie das Makefile und fügen Sie im Abschnitt .build-post: .build-impl Folgendes hinzu:

.build-post: .build-impl cp ${CND_DISTDIR}/${CONF}/${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}} arm-none-eabi-objcopy -O ihex ${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}}.hex arm-none-eabi-size ${CND_ARTIFACT_NAME_${CONF}} 

(wichtig - der Einzug muss ein einzelnes Tabulatorzeichen sein, keine Leerzeichen)
Zeile für Zeile: 1 - Kopiert die Objektdatei (.elf) aus dem Ausgabeordner in das Stammverzeichnis des Projekts, um den Zugriff zu erleichtern. 2 - erzeugt HEX aus Elf (kann auskommentiert werden, wenn HEX nicht benötigt wird); 3 - Zeigt die Menge des belegten Speichers nach Segmenten an.

Das Endergebnis:


So weit so gut.

OpenOCD - die ersten Schwierigkeiten

In den oben genannten Online-Handbüchern ist die Programmierung eines Chips über OpenOCD einfach und routinemäßig. Die neueste Version (0.10.0) wird installiert, die Konfigurationsdatei wird entnommen (aus dem OpenOCD-Kit oder aus dem Projektordner SW4STM32), ein Befehl des Formulars wird in Projekteigenschaften → Ausführen geschrieben:


und alles funktioniert sofort. Dies ist zwar bei jüngeren Familien wie STM32F103 und F407 der Fall, aber ich interessiere mich für F7 und H7. Mit der ersten Version stürzt die offizielle Version von OpenOCD 0.10.0 mit den Fehlern "auto_probe failed" und "undefined debug reason 7" ab. Letztere werden überhaupt nicht unterstützt. Wir haben alle verfügbaren offiziellen Baugruppen 0.10.0 von Januar 2017 bis Januar 2018 ausprobiert - das Ergebnis ist identisch. Eine Stichwortsuche bestätigt die Existenz des Problems, obwohl Sie es nicht als massiv bezeichnen können. Es gibt keine Analyse und Lösung.

Es gibt jedoch eine Version, die garantiert funktioniert - aus dem SW4STM32-Kit. Natürlich stellt sich heraus, dass es durch neue Skripte und Unterstützung für die H7-Familie verbessert und ergänzt wird. Außerdem wurde die Dateistruktur darin geändert, und im Plug-In werden die Ressourcen in einem separaten Modul gespeichert. Damit das in einem einzelnen Ordner konsolidierte Dienstprogramm seine Skripte sehen kann, war der Schalter -s erforderlich.

Board.cfg für NUCLEO-F767ZI, ohne Kommentare und komprimiert:

 set CHIPNAME STM32F767ZITx source [find interface/stlink-v2-1.cfg] transport select hla_swd source [find target/stm32f7x.cfg] set WORKAREASIZE 0x10000 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 reset_config srst_only srst_nogate connect_assert_srst set CONNECT_UNDER_RESET 1 

Starten Sie schließlich über Run Main Project:


Die Firmware ist erfolgreich, der Code wird ausgeführt.

Debuggen

Es wird angenommen, dass das Schema das traditionellste ist: NetBeans, ein lokaler GDB-Server unter OpenOCD, stellt über localhost eine Verbindung her: 3333 über TCP. Dementsprechend benötigt NetBeans das Gdbserver-Plugin.

Es ist möglich, den Start von OpenOCD über ein Bat-Skript zu vereinfachen. Da die Sitzung nach Abschluss der Sitzung an die Konsole gesendet wird, ist es sinnvoll, den Neustart endlos zu wiederholen:

 :start openocd -f debug.cfg -sd:/Prog/openocd/scripts goto start 

Start:


Die Version von SW4STM32 ist nicht explizit geschrieben, aber der Server wartet auf eine TCP-Verbindung zu Port 3333. Wählen Sie in NetBeans Debug → Debugger anhängen ... und installieren Sie:


Die Sitzung ist aktiv. OpenOCD-Terminal:


Im Aussehen sieht alles gut aus - die Debugging-Sitzung ist aktiv, der Code wird ausgeführt. Das Problem besteht jedoch weiterhin.

Das Problem

Im Freilaufmodus kann die Ausführung nicht gestoppt werden.

Wenn Sie vor dem Starten der Sitzung einen Haltepunkt festlegen, wird beim Aufrufen des Debuggens die Aktualisierung des Kontexts beendet, die schrittweise Ausführung und das Anzeigen / Ändern von Variablen funktionieren, dh im Prinzip alle grundlegenden Funktionen, die für das vollständige Debuggen erforderlich sind:


Aber nur bis zum nächsten freien Start, danach bleibt nur noch die Sitzung zu schließen und neu zu starten.

Eine weitere unangenehme Kleinigkeit ist mit Software-Haltepunkten verbunden: Die Funktion SYSTEM_Halt () ist als __asm__ ("bkpt") definiert, und ihre Operation führt zur Anzeige eines unnötigen Dialogs:


Wenn Sie auf Verwerfen und Anhalten klicken, funktioniert dies wie erforderlich (dh es wird die Ausführung gestoppt). Es ist jedoch nicht möglich, diese Option standardmäßig festzulegen und die Fensteranzeige standardmäßig auszuschalten.

Vor dem Heap möchte ich den Start von OpenOCD automatisieren und den Debugger direkt über NetBeans verbinden.

Objektiv gesehen ist die einzige Funktion, die für ein mehr oder weniger vollständiges Debuggen nicht ausreicht, das Stoppen der Ausführung (es ist auch erforderlich, einen Haltepunkt im laufenden Betrieb festzulegen).

Debuggen Debuggen

Eine Google-Suche ergab, dass ähnliche Probleme mit NetBeans, die GDB stoppen, gestoppt wurden, aber vor einigen Jahren behoben wurden. Mangels einer besseren Idee wurden NetBeans-Quellen heruntergeladen, in der Hoffnung, den Debugger live zu durchlaufen. Überraschenderweise gelang es uns, das Problem schnell zu lokalisieren, bevor wir das externe Dienstprogramm GdbKillProc.exe aufriefen, das im Wesentlichen ein Wrapper für DebugBreakProcess (pid) von WinAPI ist. Das Prinzip des Dienstprogramms reduziert sich auf eine nicht störende Unterbrechung des Prozesses (analog zu "kill -SIGINT [pid]" unter * nix oder Strg + C in der Konsole).

Aber sie arbeitet nicht.

Was wird getestet

Im Konsolenmodus reagiert der GDB-Client (arm-none-eabi-gdb.exe) korrekt auf Strg + C, dh er stoppt die Codeausführung, ohne die Sitzung zu schließen, und wartet auf weitere Anweisungen.

ps -W und Windows Process Explorer zeigen den Prozess korrekt an und die PID stimmt mit der internen Variablen in NetBeans überein.

Der manuelle Aufruf von "kill -SIGINT [pid]" aus dem MSYS-Paket löst den Fehler "Kein solcher Prozess" aus.

Das Durchchecken von "taskkill / pid [pid]" ergibt "Der Prozess ... konnte nicht beendet werden ... Dieser Prozess kann nur mit Gewalt beendet werden ...", was auf eine Systemsperre hinweist. Mit dem Schalter / f wird der Prozess vollständig geschlossen, was auch nicht gut ist.

Dabei stellte sich heraus, dass unter Windows die Situation bei der Erzeugung von Interrupt-Signalen keine Rolle spielt oder vielmehr in keiner Weise: Standardmäßig wird nur das SIGTERM-Analogon unterstützt, was einer groben Verkürzung des Prozesses entspricht, und es gibt keine allgemein akzeptierte Lösung.

Im Internet wurde ein Windows-Kill-Dienstprogramm gefunden, das Strg + C und Strg + Brk emuliert. Der Prozess findet, dass der Interrupt fehlerfrei sendet, aber der GDB-Client antwortet immer noch nicht.

Die Experimente wurden mit allen 32-Bit-Versionen (NetBeans, ARM Tools, MSYS 1.0) durchgeführt, mit Ausnahme von Windows-Kill, das sich weigerte, 32-Bit zu starten ("... nicht richtig zu starten ..."). Vielleicht liegt das Problem genau darin, denn nach fragmentarischen Daten aus Foren und Bugtrackern sollten die Bittiefe des Dienstprogramms und des Prozesses zusammenfallen. Die Schwierigkeit hierbei ist, dass ARM die x64-Version der Toolchain für Windows nicht anbietet. Die einzige Möglichkeit, die Heterogenität zu beseitigen, besteht darin, die x32-Version von Windows-Kill zum Laufen zu bringen, was auch nicht klar ist, ob dies unter Win x64 im Prinzip möglich ist.

In der Mitte des Prozesses wurde das Betriebssystem von Grund auf neu installiert, und es wurden keine Änderungen im Verhalten der Versuchspersonen festgestellt, auch wenn mit großer Sicherheit die Merkmale eines bestimmten Systems beseitigt werden können.

Hallenhilfe erforderlich

Tatsächlich kann alles oben Genannte als Einführung in diesen Absatz betrachtet werden.
Der letzte Schritt besteht darin, das STM32-Debugging unter NetBeans real zu machen:

erfordert einen funktionierenden Softwaremechanismus zum Senden des SIGINT-Interrupt-Signals (Strg + C) an den Windows GDB-Client-Prozess

Im Folgenden finden Sie eine Empfehlung zum Festlegen der Mindestkonfiguration, die ausreicht, um das oben genannte Problem zu überprüfen / zu debuggen. Wenn / wann es behoben werden kann, wird der Artikel in einer einfachen Schritt-für-Schritt-Anleitung zum Konfigurieren von NetBeans + OpenOCD für mehrere verschiedene Familien und Debug-Boards wiederholt. Weitere Funktionen können nach Belieben ausgeführt werden, da bereits eine funktionsfähige Basislösung vorhanden ist.

Testaufbau

Es wird vorgeschlagen, das Blue Pill Board basierend auf dem STM32F103C8T6 und dem Klon ST-Link V2 als Hardwareplattform zu verwenden.


Es ist notwendig:

1. Installieren Sie die GNU Arm Embedded Toolchain

2. Installieren Sie OpenOCD 0.10.0 ( Build unter Win )

3. Registrieren Sie die Bin-Ordner beider Pakete in PATH (Systemsteuerung → System → Erweiterte Systemeinstellungen → Umgebungsvariablen ... → Pfad).

4. Kopieren Sie den Inhalt an einem geeigneten Ort zum Erstellen der Datei board.cfg:

 source [find interface/stlink-v2.cfg] source [find target/stm32f1x.cfg] transport select "hla_swd" reset_config none separate set WORKAREASIZE 0x5000 set CHIPNAME STM32F103C8T6 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 set CLOCK_FREQ 4000 set CONNECT_UNDER_RESET 1 

5. Wählen Sie die entsprechende Test-Firmware (test.elf). Das Hauptkriterium ist, dass Ausführung und Stopp klar voneinander zu unterscheiden sind. Kopieren Sie an einen geeigneten Ort.

6. Von einem geeigneten Ort aus, um die Platine zu flashen:

openocd -f board.cfg -c "program test.elf verify reset exit"

Die Firmware sollte starten. Beispielausgabe von OpenOCD an die Konsole:


7. Starten Sie den OpenOCD GDB-Server von einem geeigneten Ort aus:

openocd -f board.cfg

Der Code wird noch ausgeführt. Beispielausgabe (Konsole bleibt von OpenOCD gesperrt):


8. Führen Sie in einer anderen Konsole oder direkt arm-none-eabi-gdb.exe aus dem GNU ARM Embedded Toolchain-Paket aus und führen Sie die folgenden Befehle aus:

target extended-remote localhost:3333 (Code wird noch ausgeführt)
continue (Code läuft, die Konsole ist gesperrt)
Ctrl+C (Code gestoppt, Konsole aktiv)
continue (läuft wieder, die Konsole ist gesperrt)


Die Aufgabe besteht darin, den GDB-Client programmgesteuert aus dem Ausführungsstatus zu entfernen (d. H. Im Wesentlichen Strg + C zu emulieren).

Verwenden Sie zum Ermitteln der Prozess-ID "ps-W" aus der * nix-Umgebung oder den Windows-Prozess-Explorer (optional installiert).

Möglicherweise wird jemand direkt nach der Ersteinrichtung von NetBeans korrekt debuggen - solche Informationen sind auch nützlich, insbesondere mit einer detaillierten Beschreibung des Systems und möglicher Funktionen.

Bitte teilen Sie Ideen in den Kommentaren mit, und ich hoffe, dass wir durch die Zusammenarbeit ein mutiges Experiment in einen nützlichen Leitfaden für die Einrichtung eines noch nützlicheren Tools verwandeln können.