Unbrick MAX32660, der so programmiert ist, dass er den SWD-Pin ansteuert?

Ich dachte, ich wäre schlau, indem ich meinen UART-Ausgang dem SWD-Ausgangspin neu zuordnete. Ich bin kein Fan von Debuggern (sie skalieren nicht). Ich ging davon aus, dass ich meinen MAX32660 einfach neu programmieren könnte, indem ich ihn auf Reset halte, wie man es zum Beispiel mit AVRs macht.

Nun, es stellt sich heraus, dass weder OpenOCD noch PyOCD mit dem MAX32660 sprechen wollen, während er zurückgesetzt wird. Zum Beispiel sagt PyOCD "Gerätestatus ist zurückgesetzt". Ich kann das Gerät nicht einmal anhalten.

Kaum zu glauben, dass es keine Möglichkeit gibt, die SWD-Funktion wieder herzustellen. Aber in diesem Thread über einen anderen Arm, der (ähnlich wie der MAX32660) die SWD-Pins neu zuweisen kann, behaupten sie, dass das Gerät nur neu programmiert werden kann, wenn zwischen dem Start des Reset-Vektorcodes und dem Zeitpunkt der Neuzuweisung der SWD-Pins eine ausreichende Verzögerung besteht .

Ich verwende ein MAX32660 EVSYS, um das Teil zu programmieren. Kann dieser Programmierer (der nur SWD unterstützt) das Teil entpacken? Könnte ein JTAG-Programmierer das Teil entmauern?

Wenn Sie das Debugger-Setup haben, um den Hardware- Reset zu steuern, kann ein Befehl wie "reset halt" dies tun. Dann löschen Sie den störenden Blitz. Dies funktioniert bei ST, bei dem Sie sich nicht sicher sind, aber es ist wahrscheinlich, dass die Debug-Funktionalität von ARM stammt und der Flash-Teil vom Anbieter stammt. Beachten Sie, dass der Debugger den Hardware-Reset möglicherweise nicht antreibt, wenn Sie glauben, dass dies der Fall ist ... Probieren Sie zur Überprüfung ein Oszilloskop ohne angeschlossenes Ziel aus. Sehen Sie auch nach, ob das Flash-Loader-Tool des Herstellers irgendwelche speziellen Modi hat, STs hat ein "Verbinden unter Zurücksetzen" in einem Optionsmenü.
@ Chris. Brillant! Ich konnte den Blitz durch die folgende Sequenz löschen: Erden Sie den Reset-Pin mit Jumper, dann in PyOCD: set nreset 0(und lassen Sie das interaktive Fenster geöffnet), entfernen Sie den Jumper und in PyOCD: reset halt(und schließen Sie PyOCD) und schließlich in openocd: flash erase_address 0 0x40000. Ich bin mir nicht sicher, warum ich nicht alles in einem Programm machen konnte, aber hoffentlich mache ich denselben Fehler nicht zu oft. Danke schön.
Viele Konfigurationen führen standardmäßig einen Soft-Reset des Ziels durch, es kann einige echte Beharrlichkeit erfordern, um einen Hardware-Reset durchzuführen, und Testgeräte, um zu überprüfen, ob dies wirklich der Fall ist. Es gibt auch einige billige SWD-Dongles auf dem Markt, bei denen der Hardware-Reset-Header einfach nicht dort angeschlossen ist, wo die Dongle-Firmware es glaubt ...

Antworten (3)

Chris 'Lösung (erster Kommentar) hat bei mir funktioniert.

Wenn Sie das Debugger-Setup haben, um den Hardware-Reset zu steuern, kann ein Befehl wie "reset halt" dies tun. Dann löschen Sie den störenden Blitz. Dies funktioniert bei ST, bei dem Sie sich nicht sicher sind, aber es ist wahrscheinlich, dass die Debug-Funktionalität von ARM stammt und der Flash-Teil vom Anbieter stammt. Beachten Sie, dass der Debugger den Hardware-Reset möglicherweise nicht antreibt, wenn Sie glauben, dass dies der Fall ist ... Probieren Sie zur Überprüfung ein Oszilloskop ohne angeschlossenes Ziel aus. Sehen Sie auch nach, ob das Flash-Loader-Tool des Herstellers irgendwelche speziellen Modi hat, STs hat ein "Verbinden unter Zurücksetzen" in einem Optionsmenü.

Ich wollte die Lösung von Chris unterstützen und einige Folgemaßnahmen für diejenigen hinzufügen, die Keil uVision (V5.36.0.0) verwenden:

Ich habe die SWD deaktiviert, indem ich das Feld GCR_SCON.sw_dis über die folgende Schnittstelle, die von Maxims Beispielprojekt „GPIO (MAX32660_EVKIT)“ bereitgestellt wird, auf 1 gesetzt habe:

MXC_GCR->scon |= MXC_S_GCR_SCON_SWD_DIS_DISABLE;

Dies führt zu folgendem Fehler „SWD/JTAG-Kommunikationsfehler“:SWD/JTAG-Kommunikationsfehler

Um die SWD wieder online zu bringen, habe ich unter den MAX32660_EVKIT CMSIS-DAP Debugger-Einstellungen die Debug => Connect & Reset Options => Connect: "Normal" auf "under Reset" geändert.

Screenshots der relevanten Einstellungen unten:CMSIS-DAP_Cortex-M_Driver_Setup_Debug_under-Reset

CMSIS-DAP_Cortex-M_Driver_Setup_Flash-Download

Ich ging davon aus, dass ich meinen MAX32660 einfach neu programmieren könnte, indem ich ihn auf Reset halte, wie man es zum Beispiel mit AVRs macht.

Yeah Nein. Was der Reset-Pin bedeutet und was ein Programmiermodus ist, hängt davon ab, wie der Hersteller ihn gestaltet!

Da moderne ARM-MCUs in der Regel viel, viel schöner sind als AVRs, haben viele von ihnen einen Boot-Pin, mit dem Sie einen zu startenden Bootloader auswählen und auf Befehle auf zB UART und USB (!) warten können. Dieser Bootloader kann dann nur vom Techniker deaktiviert werden, indem er an eine bestimmte Adresse im Flash schreibt.

Dies ist eine sehr verbreitete Methode zum Programmieren in der Produktion. Eine andere sehr verbreitete Methode ist in der Tat die Verwendung von SWD und das Laden von Firmware, die, wie Ihre, SWD einfach deaktiviert, wenn Sie nicht möchten, dass die Benutzer eine Debug-Schnittstelle haben. (Ich denke nicht, dass "Debugger nicht skalieren" eine wahre Aussage ist, daher ist SWD eine ziemlich nette Sache und ermöglicht eine Menge systeminterner Programmierbarkeit, z. B. wenn Sie die Firmware Ihres aktualisieren möchten Leistungsregler auf Ihrem PC/Laptop-Mainboard. Dies skaliert auf ein paar Millionen Einheiten ...)

Wie auch immer, Ihr IC hat definitiv einen solchen Bootloader; Sie sollten damit in der Lage sein, neue Firmware auf Ihr Gerät zu laden. Lesen Sie das MAX32660 Bootloader-Benutzerhandbuch (UG6471).

Das Gerät kann nur neu programmiert werden, wenn zwischen dem Start des Reset-Vektorcodes und dem Zeitpunkt, zu dem es die SWD-Pins neu zuweist, eine ausreichende Verzögerung besteht.

Exakt. Der Trick, den sie tun, ist: Richten Sie einen Debugger ein, der kontinuierlich versucht, Fehler zu beheben, und geben Sie dann das Zurücksetzen frei. Es gibt keine Garantie dafür, dass dies beim ersten Versuch funktioniert, daher müssen Sie es möglicherweise mehrmals versuchen.

Sie könnten versuchen, den Reset-Pin loszulassen und sofort die SWD-Uhr zu takten.

Wenn das beim ersten Versuch nicht funktioniert, variieren Sie das Timing zwischen diesen beiden.

Tun Sie das so oft, bis es funktioniert. Könnte ein paar tausend Versuche dauern, bis zufällige Variationen das zum Laufen bringen.

Oder Sie könnten eine externe Uhr anstelle eines Quarzoszillators verwenden, um den Kern zu takten, und einfach aufhören, ihn zu takten, nachdem Sie einen Taktzyklus nach dem Auslösen des Zurücksetzens getaktet haben, und dann versuchen, SWD auszuführen. Wenn das nicht funktioniert, versuchen Sie es mit zwei Taktzyklen und so weiter.

Beides ist nichts, was ein Bewertungsgremium standardmäßig tut. Sie möchten so etwas wie ein FPGA-Board und müssen umfangreiche Gateware schreiben oder zB das vorhandene Glitching-Framework von Scanlime verwenden.

Dies könnte funktionieren, aber die Lösung von Chris (eine Form des haltBefehls zu verwenden, die funktioniert, während reset bestätigt wird) war viel einfacher. SWD skaliert auf Millionen von Einheiten, ja. Aber wenn ich bereits eine andere Form der Konnektivität habe, kann ich diese für Firmware-Updates verwenden. Meine Aussage war, dass Debugger nicht skalieren, was wahr ist (versuchen Sie, alles zu debuggen, was Netzwerkprotokolle ohne tcpdumpoder eine andere Form von Protokollierung mit hohem Durchsatz betrifft).
@personal_cloud das stimmt immer noch nicht.