Hallo, kann mir jemand sagen, ob ST die SWD-Programmieralgorithmen (nicht Debug) offengelegt hat? Ich finde leider auf der Website unter "InCircuit Programming" nichts, nur "InApplication Programming" per Bootloader gibt's zuhauf. Ralf
Beitrag #5330287 wurde von einem Moderator gelöscht.
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).
Hallo, danke für eure Antworten. D.h. die entsprechenden Infos finde ich im STM32 Reference Manual und auf der ARM Homepage? 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. Ralf
Hi, ich denke was du meinst ist der integrierte Bootloader via UART / CAN o.Ä. Das nennt sich DFU. AN3156 ist evtl. ein Einstieg.
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ß
A.. P. schrieb: > Was du suchst ist das Dokument "AN3155 • USART protocol used in the > STM32 bootloader". Test schrieb: > ich denke was du meinst ist der integrierte Bootloader via UART / CAN > o.Ä. Das nennt sich DFU. AN3156 ist evtl. ein Einstieg. Der ralf hat doch eindeutig gesagt, dass er das SWD Protokoll haben möchte - und nicht das vom UART/CAN Bootloader.
A.. P. schrieb: > Das ist alles was du brauchst, um deinen STM32 mit > einem anderen Controller über den UART zu flashen. 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?
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.
A.. P. schrieb: > 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. Er will SWD und nicht den Bootloader. Was du für besser hälst oder du machen würdest kannst ihm vorschlagen - ist aber zweitrangig. Auch ein Synonym für dieses Forum: Lösungsansätze, die total am Thema vorbei sind a la "so würde ich es machen, ist doch viel besser so".
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.
:
Bearbeitet durch User
Wenn ich Ralf richtig verstehe will er den ST-Link loswerden, aber seinen STM32 weiterhin über das SWD-Protokoll programmieren. OpenOCD kann genau das auf einem Raspberry Pi machen, anstelle des ST-Links werden die GPIOs genutzt. http://openocd.org/doc-release/doxygen/bcm2835gpio_8c_source.html Auch wenn vermutlich keine Broadcom Chip verwendet wird zeigt dies eine Möglichkeit auf und sollte sich mehr oder weniger leicht adaptieren lassen.
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
Hallo zusammen, bitte entschuldigt die späte Rückmeldung. Vielen Dank an alle für die zahlreichen Antworten. Kurze Erläuterung: der STM32 soll als Slave-Controller eingesetzt werden und im Feld durch den Master updatefähig sein. Das würde prinzipiell auch über den Bootloader gehen. Soweit ich die ST-Doku zum Bootloader verstehe, geht das Starten vom BL per Boot0-Pin nicht mehr, wenn die Readout-Protection gesetzt ist. In dem Fall muss die Applikation den Bootloader aufrufen. So, und wenn nun die Applikation abschmiert, dann wäre das im WorstCase eben ein toter Controller. Deswegen die Frage nach einer sicheren Wiederherstellungsmöglichkeit, und das ist m.E. eben SWD, weil das über Hardware geht. Außerdem ist mir momentan für den ST-Bootloader nicht ganz klar, was auf den Schnittstellen gemacht wird: laut dem Flussdiagramm werden die unterstützten Schnittstellen konfiguriert und dann "gelauscht". Nur steht nicht dran, ob nur die Empfangspins (bspw. UART Rx) konfiguriert werden oder auch gleich die Tx-Pins. Im zweiten Fall müsste man dann nämlich auch aufpassen, was man wo anschließt. Das gilt evtl. sogar für den Fall, dass "nur" der Empfangspin eines UARTs scharf ist, dort aber ggf. etwas angeschlossen ist, was beim Einschalten auf low liegt. Ich werde mir die OpenOCD-Sache mal anschauen, besten Dank hierfür. Ralf
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!
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
@Harry: Es geht hier nicht um den Bootloader. @Dieter: Das Nachbauen ist genau die Aufgabe. Danke, ich komme alleine weiter.
:
Bearbeitet durch User
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.
Knut B. schrieb: > Was soll ich mit dem Raspberry und dem STLink anstellen? OpenOCD oder eins der Programme von ST benutzen.
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.