STM32(L4) über SWD ohne ST-Link programmieren?

Auch bei SWD/JTAG wird ueber Registerzugriffe programmiert. Der 
Registerzugriff ist in dem Arm Debug Interface (Adiv5) definiert. Z.B. 
OpenOCD und Blackmagic Debug Probe fuehren dann beide Sachen zusammen.

Ralf schrieb:
> kann mir jemand sagen, ob ST die SWD-Programmieralgorithmen (nicht
> Debug) offengelegt hat?

Ja haben sie. OpenOCD kann STM32 µCs programmieren und es ist 
vollständig Open Source.

Es gibt dort auch die Möglichkeit einem FTDI-basierten JTAG Adapter via 
Bustreiber oder Widerstand das SWD Protokoll beizubringen.

Interessant ist beim Programmieren von ARM Cortex-M µCs übrigens nur der 
eigentliche Flash Speicherzugriff, der Rest ist komplett von ARM 
dokumentiert (siehe infocenter.arm.com).

Was du suchst ist das Dokument "AN3155 • USART protocol used in the 
STM32 bootloader". Das ist genau das Protokoll, an welches sich auch der 
ST Flash Loader hält. Das ist alles was du brauchst, um deinen STM32 mit 
einem anderen Controller über den UART zu flashen.

Gruß

Ralf schrieb:
> Es geht darum, dass der STM32 an eine CPU angeschlossen ist, und im
> Falle dass der Bootloader versagt der Controller über "harte"
> Programmierung durch die CPU(!) wieder belebt werden kann.

Wieso sollte der Bootloader versagen? Der ist fest in jedem STM drin, da 
kann niemand dran rütteln. Wenn der interne Bootloader versagt, hat der 
ganze Controller versagt und bedarf keiner weiteren Programmierung. Was 
willst du da noch retten?

Code Mitleser schrieb:
> Themaverfehlung! Setzen, sechs.
>
> Er will was anderes. Hier nochmal zum besseren Verständnis
> wiedergegeben, damit es nicht zu schwer wird:
>
> Ralf schrieb:
>> über SWD ohne ST-Link programmieren?

Du scheinst mir ein sehr großkotziger Zeitgenosse zu sein, der nur 
gelernt hat sofort draufzuhauen :) Dann erklär du mir doch bitte, was 
für einen Fall es gibt, wo der Bootloader versagt und man dann noch 
ernsthaft versuchen darf, über SWD direkt an die Innereien ranzukommen. 
Versagen kann der Bootloader doch nur, wenn er irgendeinen internen 
Schaden hat. Oder arbeitet der Bootloader nur von 9-17 Uhr?

A.. P. schrieb:

>> Ralf schrieb:
>>> über SWD ohne ST-Link programmieren?
>
> Du scheinst mir ein sehr großkotziger Zeitgenosse zu sein, der nur
> gelernt hat sofort draufzuhauen :) Dann erklär du mir doch bitte, was
> für einen Fall es gibt, wo der Bootloader versagt und man dann noch
> ernsthaft versuchen darf, über SWD direkt an die Innereien ranzukommen.
> Versagen kann der Bootloader doch nur, wenn er irgendeinen internen
> Schaden hat. Oder arbeitet der Bootloader nur von 9-17 Uhr?

Was spielt das für eine Rolle? Er will das SWD Protokoll wissen. Man 
KANN hier kurz den Hinweis auf den USART Bootloader geben, falls er 
diese Möglichkeit nicht kennt. Aber das wars dann auch. Deine sonstigen 
Überlegungen zu der Notwendigkeit einer direkten SWD Verbindung sind 
irrelevant.

Cyblord -. schrieb:
> Deine sonstigen
> Überlegungen zu der Notwendigkeit einer direkten SWD Verbindung sind
> irrelevant.

Falsch. Der TO scheint die Möglichkeit des USART-Bootloaders sehr wohl 
zu kennen (sonst hätte er ihn ja nicht explizit erwähnt). Un da er davon 
sprach, dass dieser versagen kann und er deshalb den Controller direkt 
über SWD programmieren können will, stellt sich mir die Frage, wie das 
sein kann. Genauso gut kann man fragen, wie man eine Hälfte des 
Controllers noch benutzen kann, falls die andere schon abgeraucht ist.

Ich versuche nunmal alle Informationen einzubeziehen, die der TO gegeben 
hat und nicht nur die allererste und spärlichste. Sonst läuft er heute 
los und implementiert sein SWD-Protokoll und öffnet in 2 Wochen einen 
neuen Thread, in dem er nach einer anderen Lösung sucht, weil es so 
nicht klappt.

Du magst das vielleicht so einfach handhaben und nicht unbedingt 
weiterdenken, als nötig, aber ich hinterfrage nun mal gerne etwas mehr. 
Im übrigen scheint mir ja niemand meine Frage, ob es so eine Situation 
geben kann, beantworten zu wollen, um sich stattdessen daran 
aufzuhängen, dass ich Dinge frage und ein anderer eben nicht. Dafür gibt 
es ein Forum.

Ralf schrieb:
> Es geht darum, dass der STM32 an eine CPU angeschlossen ist, und im
> Falle dass der Bootloader versagt der Controller über "harte"
> Programmierung durch die CPU(!) wieder belebt werden kann.

Mir scheint der Weg das dann über SWD zu machen aufwendiger als nötig. 
Denn SWD ist zwar von ARM definiert, aber anders als z.B. UART ist das 
Protokoll  nicht schon in Hardware und mit fertigen Treibern in CPUs 
vorhanden.

Mit "Bootloader versagt" meinst Du einen eigenen, von Dir 
programmierten, Bootloader?

Dann kannst Du immer noch den von ST fest einprogrammierten und über das 
BOOT0-Pin aktivierbaren Bootloader verwenden und mit dem danach z.B. per 
UART den ganzen STM32 wieder neu programmieren.

Du bräuchtest dafür also UART-RX, UART-TX, Reset und Boot0 die von 
Deiner CPU aus angesprochen werden müssen.

Wenn die Pins dafür zu knapp sind, kann man Reset und Boot0 aber auch 
über kleine Hex-Inverter (74LVC2G14) und RC-Glieder aus dem UART 
erzeugen: wenn das UART für 1 Sekunde low ist, wird Reset aktiviert, 
wenn das dann auch ne Sekunde aktiv ist, wird Boot0 aktiviert.

Gerd E. schrieb:
> Dann kannst Du immer noch den von ST fest einprogrammierten und über das
> BOOT0-Pin aktivierbaren Bootloader verwenden und mit dem danach z.B. per
> UART den ganzen STM32 wieder neu programmieren.

Oh oh, lass das bloß nicht die anderen sehen XD

Guten Tag an alle Mitleser, an dieser Stelle muss ich das Thema noch mal aufwärmen, da ich vor der gleichen Herausforderung stehe. Ich habe eine komplett eigenständige Programmier- und Testeinheit zu entwickeln, welche fertige Platinen mit STM32L431 programmieren soll, die keinen Zugriff auf den Boot-Pin haben und auch für einfache, externe Zugriffe gesperrt sein sollen. Ich habe begonnen, das SWD-Protokoll zu analysieren (originaler Mitschnitt eines STLINK V2 mit STM32CubeProgrammer) und kann, nachdem ich die ganzen umfangreichen Anfragen nachempfunden habe, erfolgreich das Flash des Targetcontrollers lesen. Beim Flash-Schreiben hakt es noch. Nachdem ich mich durch die ganze Initialisierung und das Hochladen des Flash Loaders in das SRAM gewühlt habe, stolpere ich über die Eigenart, dass immer 0xB78 (2936) Bytes der elf-Datei in das SRAM kopiert werden und dann eine wilde Registerschreib- und Pollorgie stattfindet, bis die nächsten 2936 Bytes in das SRAM kopiert werden, und zwar an die genau nächste Adresse, wo vor dem Registerzugriff das Kopieren unterbrochen wurde. So wie es aussieht, wird zwischen den Kopiervorgängen etwas gelöscht, vielleicht das Flash?? Die zu flashende elf-Datei ist 5864 Bytes groß, was ziemlich das Doppelte des zerhackstückelten Kopierblocks ist. Ich stehe im Moment auf dem Schlauch und würde einfach das Protokoll weiter kopieren, aber ich würde eben gern auch verstehen, was da vor sich geht. Vielleicht kann mich jemand erleuchten, der das schon mal gemacht hat?

Vielen Dank!

Schau doch einfach mal an, wie das bei openocd gemacht wurde.

https://sourceforge.net/p/openocd/code/ci/master/tree/src/flash/nor/stm32l4x.c

fchk

Schau Dir halt an was die ST-Link Loader (die .STLDR Dateien machen), mit den Debug Symbolen in den ELF Dateien und den Loader Beispielen als Source Code ist das fast schon trivial.

Und wenn man verstehen will was genau passiert kann man sich das Ganze in OpenOCD ansehen und/oder die ARM Doku zu SWD und der ARM Debug Unit lesen.

OK, vielen Dank für die Hinweise, ich lese mich mal ein. Ist alles Neuland für mich :-/.

Mit der umfangreichen C-Code-Bibliothek von Open OCD kann ich leider so gar nichts anfangen. Ich komme aus der Assembler-Ecke und bin auf der Protokoll-Ebene unterwegs und will/soll den STM32 programmieren, nicht verstehen, wie der Loader funktioniert. Der soll einfach nur transparent seinen Dienst tun. Ich würde den Flash von dem Stein auch manuell programmieren, wenn ich wüsste, wie ich vorgehen soll. Ein paar Anregungen habe ich im Netz schon gefunden, aber keinen, der von Anfang bis Ende beschreibt, was beim Flash-Laden genau passiert.

Knut B. schrieb:

Mit der umfangreichen C-Code-Bibliothek von Open OCD kann ich leider so gar nichts anfangen. Ich komme aus der Assembler-Ecke [...]

Ich denke, jeder, der in dieser Branche beruflich tätig ist, sollte C-Kenntnisse haben. Zumindest so viele, um existierenden Code verstehen zu können. Da musst Du dann eben durch. ST hat sonst keine anfängergeeignete Doku, wie das per SWD oder JTAG geht.

Alternative: Raspberry Pi plus STLINK plus OpenOCD. Damit bist Du dann wirklich nur noch User und musst nur den OpenOCD bedienen können. Und dafür gibts dann auch genug Anfänger-Doku.

fchk

Was soll ich mit dem Raspberry und dem STLink anstellen? Ich habe einen funktionierenden PC mit STLink. Wie beschrieben, habe ich einen kompletten Protokollmitschnitt vom Schreiben der elf-Datei und baue diesen gerade nach. Was ich eigentlich wissen möchte ist, warum die Abläufe so sind, wie sie sind und ob ich da noch optimieren kann, wie zum Beispiel direkt und ohne den Loader auf das Flash zu schreiben oder ob das dann eher nicht empfohlen werden kann. Im Endeffekt muss ich 5kByte an die richtige Stelle transferieren - mehr nicht.

Aber egal, ich werde schon klar kommen, dauert nur etwas und ich habe vermutet, dass ich nicht der Einzige bin, der das mal zu Fuß programmieren muss. Ein Programmablaufplan wäre schon super. Ich kenne die STM32-Serie und andere Cortexe halt nicht. Ich muss sie nur füttern und testen.

Frank K. schrieb:

Ich denke, jeder, der in dieser Branche beruflich tätig ist, sollte C-Kenntnisse haben.

Steht in meiner Stellenbeschreibung nicht drin, das ist auch nicht mein Kerngeschäf, aber gut. Anderes Thema.

Knut B. schrieb:

Was ich eigentlich wissen möchte ist, warum die Abläufe so sind, wie sie sind und ob ich da noch optimieren kann, wie zum Beispiel direkt und ohne den Loader auf das Flash zu schreiben oder ob das dann eher nicht empfohlen werden kann.

Für Optimierungen könntest Du Dir ansehen was z.B. J-Flash macht (das kann auch eine Log-Datei der Zugriffe schreiben).

Bezüglich nachbauen: Das wird man in der Praxis vermutlich eher selten tun müssen weil z.B. OpenOCD eine große Menge unterschiedlicher Interfaces unterstützt, da sollte für die allermeisten Fälle etwas dabei sein. Das ist Open Source und wirklich nicht sonderlich schwer zu Lesen wenn man sehen möchte wie bestimmte Dinge funktionieren (zum Lesen muss man eine Hochsprache nicht zwingend auch Programmieren können).

Und OpenOCD läßt sich bei Bedarf in die eigenen Abläufe einbinden, egal ob unter Windows oder Linux.

Bitte sehr:

https://www.st.com/resource/en/application_note/an3155-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

@Harry: Es geht hier nicht um den Bootloader.

@Dieter: Das Nachbauen ist genau die Aufgabe.

Danke, ich komme alleine weiter.

Knut B. schrieb:

Was ich eigentlich wissen möchte ist, warum die Abläufe so sind, wie sie sind und ob ich da noch optimieren kann, wie zum Beispiel direkt und ohne den Loader auf das Flash zu schreiben oder ob das dann eher nicht empfohlen werden kann. Im Endeffekt muss ich 5kByte an die richtige Stelle transferieren - mehr nicht.

Da ist aber SWD auch keine so sehr gute Idee.

Denn da steckt ein überraschend langer (und komplexer) Rattenschwanz an Abhängikeiten dran, die man bei Arm.com (IIRC gegen Email) als PDF lesen kann. Und das ist nur die Hälfte - dazu kommt dann noch der eigentliche Flash Schreibzugriff.

Denn die übertragenen Bits sind bei 2 verschiedenen Flash Aktionen nicht notwendigerweise identisch - selbst wenn dieselben Daten an die gleiche Adresse geschrieben werden. Man muss da auf Status Bits in den Antworten achten.

Zumindest für die Arduino µC Klasse ist das eine verdammt unangenehm große Menge an Code. Assembler kannste da knicken - völlig ungeeignet IMHO.

Knut B. schrieb:

@Dieter: Das Nachbauen ist genau die Aufgabe.

Rein interessehalber (ohne es zu bewerten): Warum reicht eine der vielen bereits vorhandenen Lösungen nicht aus bzw. kann nicht angepasst werden? Einen STM32 in der Produktion zu programmieren ist ja eigentlich nichts ungewöhnliches.

Danke, hat sich erledigt. Ich bin dann ´raus hier.

Danke für die Negativbewertung. Warum bin ich 'raus? Weil ich eine klar definierte Frage mit der Bitte um Unterstützung gestellt habe und bis auf wenige Ausnahmen nur Vorschläge gemacht wurden, die von meiner Aufgabenstellung abweichen. Dann finde ich lieber selber eine Lösung. Das Internet ist groß. Und der Wille, das genau so umzusetzen, auch.