STM32 & ST-LINK - Nach erfolgreicher Programmierung kann keine Verbindung zur MCU hergestellt werden

Ich habe mein eigenes Board mit STM32F7-45VGT6 gebaut. Ich habe es erfolgreich mit ST-LINK v2 programmiert (allerdings nicht das Original) und jetzt kann ich mich nicht einmal mit der MCU verbinden.

Ich verwende das ST-Link-Dienstprogramm von der ST- und SWD-Schnittstelle. Es kann sein, dass ich SWD-Pins als Ausgang verwende und diese in meinem Code als GPIO-Ausgang setze. Kann es sein?

Trotzdem verbinde ich meinen Reset-Pin mit GND und setze die Option "Connect under reset" im ST-Link Utility, aber es funktioniert nicht ... Was kann ich tun?

Im Internet habe ich etwas über die Verwendung von BOOT0 Pin gefunden, aber ich weiß es nicht genau ...

"Es kann sein, dass ich SWD-Pins als Ausgang verwende", das ist möglich, aber der einzige, der es wissen würde, sind Sie, es sei denn, Sie meinen eine beschädigte Ladung einer Firmware, die dies nicht absichtlich tut, aber möglicherweise als Folge davon der Fehler, der tatsächlich passiert. Im Allgemeinen kann dies behoben werden, indem die anfängliche SWD-Verbindung mit aktiviertem Hardware-Reset durchgeführt wird, entweder manuell oder automatisch. Wenn Sie die SWD-Pins als I/Os verwenden möchten, kann eine Verzögerung von ein paar Sekunden vor dieser Einstellung die Entwicklung vereinfachen, aber Sie müssen feststellen, dass Sie den Debugger trotzdem nicht verwenden können.

Antworten (8)

Ich habe es geschafft, dieses Problem zu lösen. Falls jemand auf ein ähnliches Problem stößt, hier ist, was ich getan habe:

Ich habe ST-Link v2 und das ST-Link-Dienstprogramm verwendet. In den Einstellungen habe ich "Connect under reset" und die SWD-Schnittstelle eingestellt (bei der Frequenz bin ich mir nicht sicher).
Dann drücke ich die Reset-Taste auf meinem Board und klicke auf „Ziel“ -> „Chip löschen“ und gleich nach dem Klicken ließ ich die Taste los – der Chip wurde gelöscht, sodass ich jetzt meine MCU neu programmieren kann.


Wie auch immer, wenn Sie SWD-Pins als Ausgang verwenden müssen, fügen Sie am Anfang des Programms eine Verzögerung hinzu oder verwenden Sie einen Jumper, um die Einstellung dieser Pins als Ausgänge zu deaktivieren / aktivieren.

Ja, das ist ziemlich zu erwarten, wenn Sie die SWD-Stifte für einen anderen Zweck verwenden. Die Erfahrung zeigt, dass selbst STM32-Designs, die dies nicht absichtlich tun, gelegentlich in einem Modus "stecken bleiben", in dem die SWD-Pins nicht reagieren (beschädigtes Programm?) und eine solche Behandlung zur Wiederherstellung erfordern.
Unter Linux habe ich diesen Bash-Befehl verwendet, um den Chip zu löschen: st-flash erase
Der Erase-Chip hat bei mir nicht funktioniert. Ich ging zu Ziel -> Sektoren löschen -> Alle auswählen -> Anwenden. Danach habe ich wieder Zugriff auf mein Board. Ich bin mir nicht sicher, warum das Chip-Löschen nicht geantwortet hat

Damit die Verbindung unter Reset funktioniert, muss der ST-Link die Kontrolle über den Reset-Pin haben, wenn Sie ihn an Masse binden, hat der ST-Link keine Chance, das Ziel zum Laufen zu bringen und Zugriff darauf zu erhalten.

Wenn Sie den BOOT0-Pin während des Einschaltens hochziehen, startet die MCU mit dem internen Bootloader und Sie können über mehrere serielle Protokolle darauf zugreifen (weitere Einzelheiten finden Sie im Referenzhandbuch).

Innerhalb des Bootloaders sollten die SWD-Pins verfügbar sein, um Zugriff zu erhalten, aber ich bin mir nicht 100% sicher.

Der ST Flash Loader Demonstrator ist ein Tool, mit dem Sie das Mikro über die UART-Schnittstelle löschen / programmieren können. Wenn Sie auf keinen der UARTs Ihres Mikros zugreifen können, funktioniert diese Lösung nicht für Sie.

Ich kann auf USART3 zugreifen, das vom Bootloader unterstützt wird, also werde ich das später versuchen - es wird schwierig, weil BOOT0 auf der Platine mit GND verbunden ist ... Aber ich möchte wissen, was falsch ist. Was habe ich falsch gemacht? Ich setze SWD/JTAG-Pins als Ausgänge in meiner Funktion main(). Aber im Handbuch steht, dass beim Reset alle Pins ihre Default-Funktion haben und sofort verwendet werden können. Warum kann ich den Flash beim Zurücksetzen nicht löschen? Ich habe auch U-LINK 2 Programmer und uVision 5 getestet. Ich hoffe, dass keine Schutzstufe - irgendwie versehentlich - eingestellt wurde. Ich habe keine solchen Bits gesetzt, aber gibt es eine Möglichkeit zu testen, ob die Schutzbits in Ordnung sind?
@zupazt3 Ich möchte nicht unhöflich klingen, aber bitte lies meinen ersten Satz noch einmal. Es enthält eine Antwort auf das Problem mit der Verbindung unter Zurücksetzen. Wenn Sie es nicht verstehen, schreiben Sie einen spezifischeren Kommentar.
Aber ich binde es nicht die ganze Zeit :) In meinem ersten Post meinte ich, dass ich es SOGAR direkt an GND gebunden habe, um zu prüfen, ob das helfen würde. Aber normalerweise binde ich NRST nicht an GND, sondern an einen Programmierer, damit er die Kontrolle über das Zurücksetzen hat. Und es verbindet sich immer noch nicht. Ich habe auch versucht, U-Link 2 und Keil uVision 5 zu verwenden, aber mit dem gleichen Ergebnis. Was kann der Grund sein?
@zupazt3 das ging aus deiner Frage nicht ganz hervor. Möglicherweise hilft es, den SWD-Takt zu erhöhen, da die Verbindung möglicherweise hergestellt wird, bevor das Ziel auf Ausgabe umschaltet. Aber ich habe die SWD-Pins versehentlich auf Ausgang gesetzt und konnte keine Verbindung zu meinem Ziel herstellen, und nur mit dem BOOT0 konnte ich sie wiederherstellen, wenn Sie sie direkt (ohne Widerstand) mit Masse verbinden, wird dies et hart.
Ich habe es endlich geschafft, den Chip zu löschen! Mit dem ST-Link-Dienstprogramm - ich habe die Reset-Taste gedrückt, auf "vollständig löschen" und die Freigabe-Taste geklickt und es hat sich irgendwie selbst gelöscht und jetzt funktioniert es. Das hatte ich schon mal probiert aber erst jetzt hat es geklappt.
@zupazt3 na gut für dich, vielleicht kannst du das als Antwort posten, damit andere Leute es leichter als Lösung finden können.
Wie die Erfahrung des OP gezeigt hat, ist es nicht unbedingt richtig, dass der SWD-Pod die Kontrolle über das Zurücksetzen haben muss - Sie können die Wiederherstellung durchführen, während Sie das Zurücksetzen manuell manipulieren. Es hilft, wenn Sie Software haben, die zwischen der Verbindung und dem Versuch, den Flash zu löschen, pausieren kann. Das Standard-Windows-Tool macht das, und irgendwo habe ich eine gehackte Version des Open-Source-Tools, das das tut, aber sonst nichts (ich wechsle dann zur normalen Version)

Wenn Sie stmcubemx verwenden, müssen Sie die serielle Leitung auf der Registerkarte stmcube Pinout konfigurieren. Klicken Sie auf der Registerkarte Pinbelegung auf SYS und ändern Sie die Debug-Option in Serial Wire. Es löst mein Problem und vielleicht auch dein Problem.

Dies könnte zwar ein Problem darstellen, aber wenn es nicht die Standardeinstellung dieser Software-Suite ist, SWD-Pins in der Einschalt-Standardeinstellung des SWD-Modus zu belassen, ist dies wohl ein ziemlich schwerwiegender Usability-Defekt, der einen Fehlerbericht und eine Korrektur erfordert. Sind Sie sicher, dass Sie die Einstellungen nicht von ihren ursprünglichen Werten geändert haben oder mit einem bestimmten Projekt begonnen haben, das die Verwendung dieser Pins auf eine nicht standardmäßige Weise erforderte?
Ich habe zuerst nur meine Pins als SYS_SW gesetzt .... aber sie sind orange gefärbt. Hatte auch Probleme beim Verbinden mit dem Chip nach dem Hochladen des Codes. Wenn ich den Debug-Modus in SYS-Serial Wire ausgewählt habe, verbindet sich der Chip nach dem Flashen normal.

Ich habe einen Code auf mein eigenes STM32F427-Board heruntergeladen. Dann kann ich mit dem ST-LINK Utility keine Verbindung mehr zu meinem Board herstellen. Ich denke, mein Code bringt die Debug-Port-Pin-Konfigurationen durcheinander (? kann ich nicht bestätigen). Was ich getan habe, ist Folgendes, um die Verbindung herzustellen und mein Board neu zu programmieren:

  1. Öffnen Sie das ST-LINK-Dienstprogramm und bereiten Sie sich auf „Verbinden“ im Zielmenü vor.
  2. Schalten Sie Ihr Board ein (in meinem Fall verwende ich ein USB-Kabel) und klicken Sie GLEICHZEITIG im ST-LINK-Dienstprogramm auf "Verbinden".

Ich habe 2 Boards mit diesem Trick restauriert. Hoffe das hilft. --Bob

Wie Dili schon sagte:

Wenn Sie stmcubemx verwenden, müssen Sie die serielle Leitung auf der Registerkarte stmcube Pinout konfigurieren. Klicken Sie auf der Registerkarte Pinbelegung auf SYS und ändern Sie die Debug-Option in Serial Wire. Es löst mein Problem und vielleicht auch dein Problem.

STM32CubeMx konfiguriert den Debug-Port nicht standardmäßig, daher wird ST-Link nicht mehr funktionieren, sobald Sie Ihren Code flashen. Sie müssen den Chip beispielsweise mit dem ST-Link-Dienstprogramm löschen. Um eine Verbindung mit der MCU herzustellen, musste ich den BOOT0-Pin während des Einschaltens hochziehen, um den Bootloader zu aktivieren. Gehen Sie dann zum Tarjet-Menü und Chip löschen .

Um die Debug-Pins automatisch in der STM32Cube IDE zu konfigurieren, gehen Sie zur Registerkarte Pinbelegung & Konfiguration > Kategorie Systemkern > SYS > Wählen Sie „Serial Wire“ für Debug. Flashen und Debuggen hat danach bei mir funktioniert.

Beim STM32F1xx ist das gleiche Problem aufgetreten. Insbesondere konnte ich über die SWD-Schnittstelle auf meinem benutzerdefinierten Board keine Verbindung zum STM32-Chip herstellen, während auf dem STM32F7xx mit derselben Firmware auf einem NUCLEO-Board alles einwandfrei funktionierte. In meinem Fall gab es dafür 2 Gründe:

  1. Der Startcode (generiert vom SDK und CubeIDE) deaktiviert die SWD-Schnittstelle fast unmittelbar nach dem Einschalten, ES SEI DENN, Sie geben an, dass Sie SWD in der .ioc-Datei verwenden (die Pinbelegung und Konfigurationsansicht in STM32CubeIDE).
  2. es hätte keine Rolle gespielt, wenn die nRST-Leitung auf die SWD-Schnittstelle auf meinem Board geführt worden wäre. Leider habe ich vergessen, es dorthin zu bringen.

Kurzfristige Lösung: Das nRST-Signal vom Programmierer über das externe Kabel auf die Reset-Leitung gebracht (in meinem Fall war es einfach, da ich einen physischen Reset-Knopf auf meiner Platine hatte). Dann geflasht mit der FW-Version hatte SWD in der Pinbelegungsansicht angegeben. Danach musste das nRST nicht mehr angeschlossen werden.

Langfristige Lösung: In der nächsten Revision der Karte die nRST-Leitung auf die SWD-Schnittstelle verlegen. Mit dieser Änderung konnte ich SWD während des Starts sicher deaktivieren und die Pins neu verwenden

Diese Punkte wurden alle vor einigen Jahren von anderen gemacht, daher ist nicht wirklich klar, was dieser Beitrag der Seite hinzufügt.

Um die MCU neu zu programmieren, halten Sie die Reset-Taste gedrückt und wählen Sie im ST-Link-Dienstprogramm „Mit Gerät verbinden“ oder drücken Sie in Ihrer IDE (z. B. Keil) auf „Download“ und lassen Sie dann die Reset-Taste los.

Die Boot-Pins (Bits in einigen Versionen) können den Start des Debuggers verhindern. Stellen Sie sicher, dass Sie das Boot-Muster beim Start nicht implementieren (bestimmtes Binärmuster auf den Pins boot0 und boot1), da Ihre MCU sonst in den Boot-Zustand gerät.

Ich habe den Boot0-Pin an GND gebunden ... Ich bin mir nicht sicher, was Sie geschrieben haben, weil ich es - wie gesagt - geschafft habe, meinen Flash erfolgreich zu programmieren, und das Programm sich immer noch auf der MCU ausführt - ich kann einfach keine Verbindung zur MCU mit ST herstellen -Link über SWD-Schnittstelle. Beim Zurücksetzen sollte das Booten nicht ausgeführt werden und die Pins sollten sich im Standardzustand befinden, sodass ich nicht verstehe, warum keine Verbindung hergestellt wird.
Bist du dir da sicher? Welche Kombination würde Ihrer Meinung nach das SWD so deaktivieren, dass eine Manipulation des Resets nicht außer Kraft gesetzt werden kann?
STM32 & ST-LINK - Nach erfolgreicher Programmierung kann keine Verbindung zur MCU hergestellt werden
AntwortenHierDatenschutz-Bestimmungen1y, 0v