Zum debuggen diverser Cortex-M benutze ich mittlerweile am liebsten VSCode und die Cortex-debug Extension. Das funktioniert einigermassen gut, aber es gibt einige Unschärfen und Unterschiede bei den verschiedenen möglichen Interfaces. BMP: funktioniert schnell und gut, wenig Konfigaufwand weil die debug probe smart ist. Manchmal klemmt der gdb, will viel Speicher haben und startet dann nicht. Passiert recht selten, manchmal hilft mehrmals starten probieren, VScode neustart oder target ins Boot-ROM starten. BMP benutze ich als Alternative Firmware auf einem billig STLink Clone, bei Boards mit integrierten STLink müsste man die Firmware umprogrammieren. Stutil: Habe den gleichen Code jetzt auf einem ST DISCO board getestet und wollte da den integrierten STLink V2 benutzen (Disco STM32F769NI). Dafür gibt es das texane/stutil. Code flashen geht sehr fix, aber steppen nicht richtig. Wenn ich auf einen BP laufe und dann mit step over über eine Funktion springen möchte passiert nix. Mit setp into lande ich in einem Interrupt Handler, da kann ich dann weiter steppen. Wenn ich Run ausführe lande ich wieder auf meinem BP. Ich muss den BP löschen und eine Zeile weiter setzen, dann kann ich da hinlaufen. Das stutil das als Installversion vorliegt hat die Version 1.3.0, ich habe mühselig die 1.5.1 kompiliert aber das Verhalten bleibt gleich. Kann das irgendeine gdb Einstellung sein die anders ist? Ganz habe ich das stutil noch nicht durchschaut, hat das auch ein Stück gdb mit drin? pyOCD: funktioniert auch, aber seeehr lahm. Flashen langsam (wird 32 Bit Operation nicht unterstützt oder muss man das aktivieren?) und auch steppen ist sehr langsam. Für den F7 gibt es ein Problm das MCU .pack zu laden, ich hatte das aber schon vorher mal geladen und dann mit manuellen Eingriffen installiert bekommen. Auch pyOCD hat manchmal Startprobleme, ist auf der Github Seite auch dokumentiert. Dann ist erst ein flash erase nötig, ist bei 2 MB auch lästig. openOCD: hatte auch funktioniert, möchte ich aber wegen der MCU abhängigen Konfig in launch.json vermeiden. jlink: müsste auch funktionieren, aber man muss den integrierten STLink umprogrammieren. Und der jlink Treiber erinnert täglich daran das er gerne gekauft werden möchte, auch lästig. Wie sind eure Erfahrungen, gibt es zu den genannten Problemen Lösungen?
Johannes S. schrieb: > jlink: > müsste auch funktionieren, aber man muss den integrierten STLink > umprogrammieren. Und der jlink Treiber erinnert täglich daran das er > gerne gekauft werden möchte, auch lästig. Benutz ich unter Unix und funktioniert relativ problemlos. Wenn mal was nicht geht dann weil Segger die Treiber schießt... Glücklicherweise hats die Kauf-Erinnerung nicht in den Unix-Build vom JLink geschafft.
ja, habe deinen Blog Beitrag auch schon gelesen: https://higaski.at/vscode-arm-cortex-m-debugging/ Da habe ich noch die preRestartCommands entdeckt, die habe ich in der Configbeschreibung nicht gesehen: https://marcelball.ca/projects/cortex-debug/cortex-debug-launch-configurations/ Das STutil wäre sonst auch sehr einfach weil es wenig Konfiguration braucht. Zum pyOCD ist mir noch aufgefallen das die Extension pyocd-gdbserver benutzt was als deprecated marktiert ist. Aber die Entwicklung von Cortex-debug läuft langsam, der Autor hat da wohl nicht viel Zeit für.
Ich nutze aktuell auch VSCode mit OpenOCD und einem ST-Link Clone. Ich habe auch sporadisch BP's von denen ich nicht mehr weg komme. Das zeigt sich so, dass das Programm am BP stoppt und bei Continue das GUI und VSCode nicht umschaltet auf und damit der Stop Button nicht sichtbar ist, der qC läuft dann, aber lässt sich nicht mehr steuern. Nach neuem verbinden mit dem qC per Launch, geht alles wieder.
Ich hol das Thema mal wieder hoch, da es einige Updates gab, z.B. PyOCD in Version 0.30: https://github.com/pyocd/pyOCD/releases/tag/v0.30.0 Wie sind also jetzt in 2021 eure Erfahrungen? Ich suche nämlich gerade nach offenen Möglichkeiten, die BMP sowie ST-Link V2 und V3 via Python zu scripten.
da die Konfiguration der debug probe in VSCode mit wenigen Zeilen JSON Config erfolgt, bin ich da flexibel geblieben. Für ST gibt es eine neue Variante in Cortex-Debug die mit dem neuen CubeProgrammer zusammenspielt. Ist schnell und unkompliziert. Ausser beim F7, da hat ST irgendwas beim CoreSight von ARM gespart und beim Steppen landet man immer im Interrupt, wie bei der STutil Variante. Das Problem hat nur Segger mit dem JLink im Griff, daher benutze ich den gerade mit einem Nucleo Board. pyOCD brauche ich aber auch weil die automatisierten Tests in Mbed in Python geschrieben sind, dafür muss ich dann wieder ein Board mit STLink Firmware benutzen... Und für China Boards ohne eingebauten STLink nehme ich dann wieder BMP.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.