Habe jetzt dieses STM32-407 DIY eval board (7,83€ inkl. Versand) bekommen. Natürlich ohne jegliche Doku, außer dem schlecht lesbaren Silkscreen auf der Unterseite.
Angehängte Dateien:
-
IMG_6932.jpg
210 KB
Es ist mehr ein MCU-Breakout-Board als ein Eval-Board. Im Anhang meine Notizen zu dem Teil. Die bunten Markierungen sind zusammengehörige Peripherie-Pins.
:
Bearbeitet durch User
Walter T. schrieb: > Es ist mehr ein MCU-Breakout-Board als ein Eval-Board. Im Anhang > meine > Notizen zu dem Teil. Die bunten Markierungen sind zusammengehörige > Peripherie-Pins. Walter, noch eine Frage zu Deiner Doku: Du schreibst, die bunten Markierungen seien zusammengehörige Peripherie-Pins. Ich vermisse da die gleiche Markierung an den Pins PA10/PA9. Das sind doch USART1_Tx resp. USART1_Rx. Oder welche Kriterien liegen Deiner Farbmarkierung zu Grunde?
Angehängte Dateien:
Christoph K. schrieb: > Oder welche Kriterien liegen Deiner Farbmarkierung zu Grunde? Ich hatte das Board bestellt, um etwas auszuprobieren, und brauchte I2C, SPI und viele Timer. USART nicht. Entsprechend habe ich das Bildchen gemalt. Es gibt also keinen tieferen Sinn. Man sieht ja an der Seitenzahl, dass das Bild ein Nebenprodukt eines ganz anderen Projekts ist.
OMG schrieb: > Oh wie wahr! > > Ich würde mir so etwas nie antun. Macht man auch nicht. Wenn man schon ein schickes Gehäuse hat und eine einigermaßen taugliche Hardware will, dann muss man eben eine ordentliche PCB dafür machen. Eval Boards und Dupont-Stecker sind nun mal was für den Labortisch und nicht für fertige Geräte.
Angehängte Dateien:
Versuche gerade, dieses Board (seriell) zu flashen. Geht irgendwie nicht. Habe meine Mimik gerade noch mal am STM32F407-DISC1 verifiziert: PA09 (USART1_TX) an FTDI-24, PA10 an FTDI-25. GND-GND. Versorgung über USB-C Kabel. Zum Flashen muß Jumper BOOT0-GND gesteckt. sein (?) RESET gedrückt (ist doch die Taste neben dem USB-Sockel?) PWR-LED ist an. User LED blinkt.
OMG schrieb: > Ich würde mir so etwas nie antun. Machst Du nie Testaufbauten, die wie der nackte Wahnsinn aussehen, bedeutet dass, das Deine Projekte zu einfach sind.
Walter T. schrieb: > Machst Du nie Testaufbauten, die wie der nackte Wahnsinn aussehen, > bedeutet dass, das Deine Projekte zu einfach sind. Du weisst es, denn du kennst mich ja nur zu gut.
Christoph K. schrieb: > Zum Flashen muß Jumper BOOT0-GND gesteckt. für den UART Bootloader auf 1, direkt an +3,3 V setzen.
Cyblord -. schrieb: > Wenn man schon ein schickes Gehäuse hat Naja, ein schickes Gehäuse sieht bei mir anders aus. Das war einfach ein Testaufbau. Die Testumgebung (Werkstatt) erforderte es, dass da ein Deckel drauf ist.
:
Bearbeitet durch User
Walter T. schrieb: > Christoph K. schrieb: >> Oder welche Kriterien liegen Deiner Farbmarkierung zu Grunde? > > Ich hatte das Board bestellt, um etwas auszuprobieren, und brauchte I2C, > SPI und viele Timer. USART nicht. Entsprechend habe ich das Bildchen > gemalt. Es gibt also keinen tieferen Sinn. Man sieht ja an der > Seitenzahl, dass das Bild ein Nebenprodukt eines ganz anderen Projekts > ist. OK, verstehe. Flashen klappt jetzt. BOOT1 auf GND zum Flashen :)
Was für ein Quarz ist eigentlich auf diesem STM32-407 DIY-MORE Board? Das ist doch die HSE-Clock, gell? Lt. https://stm32-base.org/boards/STM32F407VGT6-diymore wäre das ein 8MHz Quarz.
:
Bearbeitet durch User
Johannes S. schrieb: > Jepp, 8 MHz Quarz für HSE. Danke. Und ich kann mittels PLL eine 168MHz Clock daraus herstellen? Kann man sich das irgendwo anlesen? Irgendeines dieser Tools (STM32CubeProgrammer?) erlaubt doch die Einstellung der Clocks in einer übersichtlichen Form. Was war das noch mal?
:
Bearbeitet durch User
CubeMX heißt das Zaubertool aus der Würfelreihe. Hat eine lange Doku, ist aber doch recht intuitiv zu bedienen. MCU oder Board auswählen, dann in der Config unter RCC HSE extern aktivieren und dann in die Clock Ansicht. Da kann man auf PLL stellen und die Parameter werden berechnet (bzw. brute force durchprobiert). Man kann Code generieren lassen und übernimmt ihn oder nicht. Und ja, aus 8 MHz bekommt die PLL 168 MHz hin.
Christoph K. schrieb: > Irgendeines dieser Tools (STM32CubeProgrammer?) erlaubt doch die > Einstellung der Clocks in einer übersichtlichen Form eventuell: https://www.st.com/en/development-tools/stm32cubemx.html
Angehängte Dateien:
-
IMG_6936.jpg
230 KB
Beim Suchen im Internet stieß ich auf folgende Seite: https://jeelabs.org/2018/getting-started-f407/ und ich wurde auf PlatformIO aufmerksam. Habe das mal installiert (VSCode unter macOS). Der Autor bezieht sich da auf das Black Magic Probe Modul. Jetzt habe ich schon mehrere Programmiermodule und will nicht noch ein drittes und viertes kaufen. Was ich immer umständlich finde, ist, den BOOT1-Jumper zu setzen und dann wieder zu ziehen und den Resetknopf drücken zu müssen. Ich nehme doch an, das kann man vereinfachen, indem ich das RST Signal z.B. vom ST-LINKV2 (XTW, USB Modul) benutze, oder wie wäre dann die Verdrahtung z.B. beim STM32-407-DIY-MORE? Bisher hatte ich meinen aufgeprokelten FTDI-serial-Adapter benutzt. Grüße, Christoph
Christoph K. schrieb: > Was ich immer umständlich finde, ist, den BOOT1-Jumper zu setzen und > dann wieder zu ziehen und den Resetknopf drücken zu müssen. Man kann auch bei diesem Modul einfach 4 Leitungen setzen und mittels SWD Schnittstelle einen ST-Link V2 benutzen. Aber erst mal umständlich mit Bootloader herumstopseln ....
Wenn man eh einen ST-Link benutzt, kann man den doch auch direkt anschließen. PA13/PA14. Habe ich oben im PDF ja schon aufgeschrieben. Reset ist leider nicht herausgeführt. Braucht man aber eigentlich auch fast nie. Dafür ist PB2 auf zwei Pins. Ich gehe davon aus, dass der Designer dieses Boards am Nachmittag schon etwas Anderes vor hatte.
:
Bearbeitet durch User
Walter T. schrieb: > Ich gehe davon aus, dass der Designer dieses Boards am Nachmittag schon > etwas Anderes vor hatte. Was man, angesichts der maximal 4 Euro die der Entwickler pauschal für das Board eingestrichen hat, durchaus verstehen kann.
Angehängte Dateien:
-
IMG_6947.jpg
230 KB
Walter T. schrieb: > Wenn man eh einen ST-Link benutzt, kann man den doch auch direkt > anschließen. PA13/PA14. Habe ich oben im PDF ja schon aufgeschrieben. > Reset ist leider nicht herausgeführt. Braucht man aber eigentlich auch > fast nie. > > Dafür ist PB2 auf zwei Pins. > > Ich gehe davon aus, dass der Designer dieses Boards am Nachmittag schon > etwas Anderes vor hatte. Also PA13 an SWDIO PA14 an SWCLK Was schließe ich denn an BOOT0/BOOT1 an? Was mache ich mit RST ? Was schließe ich an PB2 an?
Christoph K. schrieb: > Was schließe ich denn an BOOT0/BOOT1 an? Üblicherweise ist der Jumper BOOT0/GND gesesetzt, um aus dem Flash zu booten. RST ist eh nicht herausgeführt, wird aber auch nicht benötigt. PB2 kann anderweitig verwendet werden.
Christoph K. schrieb: > Was schließe ich denn an BOOT0/BOOT1 an? > Was mache ich mit RST ? > Was schließe ich an PB2 an? OMG! Bist du irgendwann schon mal auf die Idee gekommen ein Datenblatt zu lesen? Nein, nicht das Datenblatt deines China-Boards sondern das des Controllers der da draufgepappt ist. Die Bedeutung der Boot Jumper hast du doch schon längst bei deinem Discovery-Board herausgefunden. Warum fragst du dann hier nochmal dermassen blöd? OMG!
Mit der Setzung von PA13/PA14 (SWDIO/SWCLK) wird das STLINK-V2 z.B. vom STM32 ST-LINK Utility nicht erkannt. STM32CubeProgrammer sagt mir "OLD ST-LINK firmware version. Upgrade ST-LINK firmware." Wenn ich im ST-LINK Programm auf ST-LINK->Firmware Upgrade gehe, sagt das Programm, ST-LINK sei nicht im DFU-Mode, "please restart it".
:
Bearbeitet durch User
Christoph K. schrieb: > Mit der Setzung von PA13/PA14 (SWDIO/SWCLK) wird das STLINK-V2 z.B. vom > STM32 ST-LINK Utility nicht erkannt. Was ist eine "Setzung" in Zusammenhang mit einem Mikrocontroller? Kannst du mal klar dokumentieren was du überhaut machst bevor du dumme Fragen stellst? Dein ST-Link Vxyz braucht genau vier Leitungen zum Arbeiten: SWCLK, SWDIO, 3.3V und GND. Wenn du meinst dass das nicht stimmt hast du schon verloren.
Christoph K. schrieb: > STM32CubeProgrammer sagt mir "OLD ST-LINK firmware version. Upgrade > ST-LINK firmware." Das Ding sieht auch nicht wie ein originaler STLink aus. Auf diese Clones lässt sich aber BMP flashen. Dem Reset braucht man wenn SWD keine Verbindung bekommt. Das passiert z.B. wenn man die CPU im deep sleep schlummern lässt. Das kann man im debug build anders machen um nicht immer reset drücken zu müssen oder die reset Leitung anschliessen und von BMP/STLink bedienen lassen.
Noch mal - ich hatte ein Foto hochgeladen, auf dem der XTW ST-LINK V2
USB adapter abgebildet ist. Den habe ich mit
ST-LINKV2 STM32407VGT6 (auf China Board gepappt)
-----------------------
SWCLK - PA14
SWDIO - PA13
GND - GND
+5V - +5V
angeschlossen. ("Setzung" war vielleicht falsch verwendet, Belegung war
gemeint). Die 3.3V werden auf dem Board gemacht. Den BOOT0 pin habe ich
auf GND gejumpert.
Das ist die Ausgangssituation.
Christoph K. schrieb: > Den BOOT0 pin habe ich auf GND gejumpert. Und den BOOT1 gibt's plötzlich nicht mehr? Hat sich in Luft aufgelöst?
Boot0 hat sicher auch einen Pull Down und braucht keinen Jumper, Boot1 dann auch nicht. SWD kommuniziert mit dem Coresight core von ARM, das ist in Hardware gegossen und braucht die Klimmzüge mit dem Bootloader nicht. SWD kommt unabhängig vom laufenden Programm an die CPU, mit Ausnamahe wenn die im Tiefschlaf ist.
Christoph K. schrieb: > STM32CubeProgrammer sagt mir "OLD ST-LINK firmware version. Upgrade > ST-LINK firmware." Wenn der STM32CubeProgrammer sich störrisch zeigt weil man evtl keinen Original ST-Link hat empfiehlt es sich das ältere Progammier-Programm st-link utility zu verwenden. google: st-link utility download Aber auch dort muss man evtl upgraden.
In den Bootloader booten kann Anfangs noch wichtig sein wenn man sich den Clock verkonfiguriert hat.
BOOT1 ist offen. +5V kommen vom ST-LINK USB Modul und liefern die Versorgung für das Board. +3,3V liegen am Pin des ST-LINK USB Modules als Quelle an.
:
Bearbeitet durch User
OMG schrieb: > Christoph K. schrieb: >> STM32CubeProgrammer sagt mir "OLD ST-LINK firmware version. Upgrade >> ST-LINK firmware." > > Wenn der STM32CubeProgrammer sich störrisch zeigt weil man evtl > keinen Original ST-Link hat empfiehlt es sich das ältere > Progammier-Programm st-link utility zu verwenden. > > google: st-link utility download > > Aber auch dort muss man evtl upgraden. Ich habe st-link auch unter macOS laufen. Da liefert es Folgendes: $ st-flash read file.bin 0x08000000 65536 st-flash 1.6.1 2020-11-28T11:14:50 WARN: Invalid flash type, please check device declaration Failed to connect to target (ich hatte eigentlich noch nie eine device declaration eingestellt für das st-link utility) $ port list | grep stlink stlink @1.6.1 cross/stlink Habe gerade mal das blackmagic (git clone) kompiliert und installiert unter macOS. Ist das jetzt eine Firmware? Wenn ich kein funktionierendes Flashprogramm habe, kann ich auch nichts neues flashen (Henne-Ei-Problem) :)
:
Bearbeitet durch User
es ist das Gleiche wie beim F407. Entweder per Bootloader oder SWD flashen. Es gibt STLink Clones die haben Testpunkte auf der Platine für SWD oder die serielle. Da muss man einmal was anlöten zum erstmaligen Programmieren von BMP-DFU und BMP. Danach kann man per DFU updates über USB machen, wenn es denn mal nötig ist.
Angehängte Dateien:
-
IMG_6950.jpg
240 KB -
IMG_6951.jpg
240 KB -
IMG_6954.jpg
240 KB
Johannes S. schrieb: > es ist das Gleiche wie beim F407. Entweder per Bootloader oder SWD > flashen. Es gibt STLink Clones die haben Testpunkte auf der Platine für > SWD oder die serielle. Da muss man einmal was anlöten zum erstmaligen > Programmieren von BMP-DFU und BMP. Danach kann man per DFU updates über > USB machen, wenn es denn mal nötig ist. Dann müßte ich diesen ST-LINK V2 Klone aber wahrscheinlich aufsägen :-( Dann werd' ich mir vielleicht doch noch einen in Reserve bestellen oder gleich was Vernünftiges kaufen? Kommando zurück, das Ding läßt sich ganz einfach aufziehen. Ziemlich "schwarze" Schaltung. Ob das evtl. ein STM32F411 ist?
:
Bearbeitet durch User
DIYMROE.pdf -> damit kann man dann per piggyback z.B. ein AtariUno2600 Modul basteln.
Nehmen wir an, es wäre ein STM32F411. Könnte man den ST-LINK des Nucleo-Boards (NUCLEO-F411RE) nehmen zum Programmieren?
Angehängte Dateien:
-
swo_nachruesten.jpg
230 KB
Christoph K. schrieb: > ST-LINK V2 Klon > Ziemlich "schwarze" Schaltung. > Ob das evtl. ein STM32F411 ist? In meinen (vermutlich ST-Link V1 Klonen) Steckt ein STM32F101, der eigentlich gar kein USB hat. Die Firmware ist für den STM32F103 vorgesehen - läuft trotzdem. Die zusätzliche Leitung, die ich da dran gemogelt habe ist SWO, für den Serial Wire Viewer. Christoph K. schrieb: > Könnte man den ST-LINK des > Nucleo-Boards (NUCLEO-F411RE) nehmen zum Programmieren? Soweit ich weiß kann man mit jedem ST-Link jeden STM32 Controller programmieren. Man muss nur an die nötigen Pins heran kommen.
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> ST-LINK V2 Klon >> Ziemlich "schwarze" Schaltung. >> Ob das evtl. ein STM32F411 ist? ... > Soweit ich weiß kann man mit jedem ST-Link jeden STM32 Controller > programmieren. Man muss nur an die nötigen Pins heran kommen. Thema ist jetzt, das abgebildete XTW St-Link V2 mit dem BMP zu flashen. Wie gesagt, ich weiß nicht genau, was für ein Chip da drauf ist. Es ist ein LQFP64 Gehäuse. Mal angenommen, es wäre ein STM32F411 und ich versuchte es mal mit dem ST-LINK auf dem Nucleo Board, dann würde ich T_JTCK (2) und T_SWO (6) von CN4 (SWD) anzapfen und an die Programmierpins der "schwarzen Schaltung" legen. GND verbinden und 3,3V noch vom JP1 nehmen. Oder sollte ich das XTW extern (USB) mit 5V versorgen? Die 3,3V in den Ausgang hineinzufüttern ist vielleicht nicht so gut, denn die hängen ja auf dem XTW am Ausgang eines Reglers, den ich dann rückwärts beaufschlagen würde. (Eingang wäre ja blind). Und was sind die Programmierpins am STM32F411 (angenommen es ist einer)?
Walter T. schrieb: > Machst Du nie Testaufbauten, die wie der nackte Wahnsinn aussehen, > bedeutet dass, das Deine Projekte zu einfach sind. Also mein Testaufbau ist in der Regel eine gefertigte PCB und in der Regel funktioniert da auch immer alles auf Anhieb. Manchmal muss eine zweite Version her, das sind dann aber oftmals Dinge die man nicht durch so einen Testaufbau testen kann - z.B. abhängige Position von empfindlichen Bauteilen etc.
Angehängte Dateien:
-
IMG_6976_2.jpg
230 KB -
IMG_6975.jpg
240 KB
Christoph K. schrieb: >> Christoph K. schrieb: >>> ST-LINK V2 Klon >>> Ziemlich "schwarze" Schaltung. >>> Ob das evtl. ein STM32F411 ist? > Und was sind die Programmierpins am STM32F411 (angenommen es ist einer)? Man korrigiere mich ggfs.: Selbstbeantwortung: PA14 SWCLK, PA13 SWO GND und Vcc fehlen noch...
Eh's jemand anderes merkt: die Anzapfung am Chip ist falsch. Eine Ecke weiter.. Programmierung klappt allerdings noch nicht. ST-LINK findet kein Target.
:
Bearbeitet durch User
Christoph K. schrieb: > Oder sollte ich das XTW extern (USB) mit 5V versorgen? Die 3,3V in den > Ausgang hineinzufüttern ist vielleicht nicht so gut, denn die hängen ja > auf dem XTW am Ausgang eines Reglers, den ich dann rückwärts > beaufschlagen würde. (Eingang wäre ja blind). Den meisten Spannungsreglern (bis 5V Ausgangsspannung) macht das nichts aus. Aber da die Datenblätter dazu nichts aussagen, und ich auch nicht weiß, um welchen Spannungsregler es konkret geht, würde meine Hand nicht dafür ins Feuer legen. Ich würde es einfach mutig ausprobieren, da gibt es ja nicht viel zu verlieren.
Angehängte Dateien:
Habe jetzt doch das XTW ST-LINKV2 Modul von USB gespiesen. SCLK und SWO an 49 (PA14) resp. 46 (PA13) mit kleinen Drähtchen angeschlossen und mit der ST-LINK V2 Sektion auf dem Nucleo-Board verbunden. Und zwar an CN4-2 und CN4-6 (die Jumper CN-2 gezogen). Ist da was falsch? Das Target wird vom Windows ST-LINK Utility jedenfalls nicht erkannt.
:
Bearbeitet durch User
Christoph K. schrieb: > Das Target wird vom Windows ST-LINK Utility > jedenfalls nicht erkannt. Eventuell deaktiviert die laufende Firmware den SWD Port. Gebe ihm mal beim Verbindungsaufbau einen Reset-Impuls.
Christoph K. schrieb: > Ist da was falsch? Das Target wird vom Windows ST-LINK Utility > jedenfalls nicht erkannt. Dein Target musst aber schon versorgen! (?) Nicht vom ST-Link sondern gesondert, separat!
jo mei schrieb: > Dein Target musst aber schon versorgen! (?) Merke: Der Pin 3.3V vom ST-Link ist keine Versorgungsspannung sondern ein Monitor-Punkt der nachschaut ob eine Spannung am Target vorhanden sind. Das ist die Original-Intention des Herstellers STM. ST-Link Clones und andere Nachbauten nehmen sich die Freiheit und definieren diesen Anschlusspunkt um als Versorgungsanschluss (nicht einheitlich geregelt). STMs Software aber sucht diese Spannung als "vorhanden" und wird im Fehlerfall dein Target schon aus diesem Grund nicht finden.
jo mei schrieb: > Christoph K. schrieb: >> Ist da was falsch? Das Target wird vom Windows ST-LINK Utility >> jedenfalls nicht erkannt. > > Dein Target musst aber schon versorgen! (?) > Nicht vom ST-Link sondern gesondert, separat! jo mei, ich schrob doch: "Habe jetzt doch das XTW ST-LINKV2 Modul von USB gespiesen."
Christoph K. schrieb: > jo mei, ich schrob doch: Wenn man Prosa-Schaltpläne liefert und liest ist oft nicht so ganz klar was was ist.
jo mei schrieb: > jo mei schrieb: >> Dein Target musst aber schon versorgen! (?) > > Merke: Der Pin 3.3V vom ST-Link ist _keine Versorgungsspannung_ > sondern ein Monitor-Punkt der nachschaut ob eine Spannung am > Target vorhanden sind. Das ist die Original-Intention des > Herstellers STM. ST-Link Clones und andere Nachbauten nehmen > sich die Freiheit und definieren diesen Anschlusspunkt um als > Versorgungsanschluss (nicht einheitlich geregelt). STMs > Software aber sucht diese Spannung als "vorhanden" und wird > im Fehlerfall dein Target schon aus diesem Grund nicht finden. Um es noch mal klarzustellen: Zwischen der ST-Link-Sektion vom Nucleo Board und dem Target befinden sich eine GND-Verbindung und die zwei Signale SCLK und SWO. Das Target selbst (XTW ST-Link V2 USB Stick) wird über USB (+5V) versorgt und macht sich seine +3,3V selber. Wenn ich es mit Windows verbinde, werfe ich es aber aus. @stefanus: Du meinst nicht das Target (Reset), sondern das Nucleo ST-LINK-V2, richtig? Ich kann SB11 kurzschließen bei laufendem ST-Link Utility. Da passieren dann undefinierte Dinge. Ich weiß im Moment nicht, wo ich definiert dann zu welchem Zeitunkt ein Reset auslösen soll (NRST am STM32F103CBT6?).
:
Bearbeitet durch User
Christoph K. schrieb: > @stefanus: Du meinst nicht das Target (Reset), sondern das Nucleo > ST-LINK-V2, richtig? Ich kann SB11 kurzschließen bei laufendem ST-Link > Utility. Da passieren dann undefinierte Dinge. Nein, du sollst das Target resetten, damit sich der Debugger während des Reset connecten kann. SO verhinderst du, dass die Firmware auf dem Target startet und die SWD Schnittstelle deaktiviert.
Christoph K. schrieb: > befinden sich > eine GND-Verbindung und die zwei Signale SCLK und SWO. Ob du es wirklich schon verstanden hast? Ich glaube es - nach diesem deinem Prosa-Schaltplan zu urteilen - noch nicht so ganz. OMG schrieb: > Dein ST-Link Vxyz braucht genau vier Leitungen zum Arbeiten:
jo mei schrieb: > jo mei schrieb: >> Dein Target musst aber schon versorgen! (?) > > Merke: Der Pin 3.3V vom ST-Link ist _keine Versorgungsspannung_ Welchen ST-Link meinst Du jetzt? Das Target nenne ich hier mal XTW. Das hat +5V und +3,3V - ich nenne es mal "Pins" - im Anschlußstecker. Die ST-LINK V2 Sektion auf dem Nucleo hat - wenn ich nichts übersehe - nur einen Signalnamen +3V3_ST_LINK, der an alle Vdd pins geht. > sondern ein Monitor-Punkt der nachschaut ob eine Spannung am > Target vorhanden sind. Das ist die Original-Intention des Welches sollte dieser "Monitorpunkt" in der Schaltung des ST-LINK V2 des Nucleo denn Deiner Meinung nach sein? Zeig mir den bitte mal in der Schaltung, um mal statt Prosa Klartext zu reden. Ich bin ja lernwillig. > Herstellers STM. ST-Link Clones und andere Nachbauten nehmen > sich die Freiheit und definieren diesen Anschlusspunkt um als > Versorgungsanschluss (nicht einheitlich geregelt). STMs > Software aber sucht diese Spannung als "vorhanden" und wird > im Fehlerfall dein Target schon aus diesem Grund nicht finden.
:
Bearbeitet durch User
Christoph K. schrieb: > Welchen ST-Link meinst Du jetzt? Du siehst schon an diesem deinen kleinen Beispiel dass Prosa- Schaltpläne grundsätzlich einfach scheisse sind. Was ist was und welche Leitung geht wohin .... Chaos ... ... da hat man wirklich keine Lust alles selbst herauszuklamüsieren ....
Angehängte Dateien:
-
IMG_6977.jpg
170 KB
Stefan ⛄ F. schrieb: > Ich habe schon lange aufgegeben, mit ein Bild im Kopf davon zu machen. Um es noch mal klar zu machen, habe ich ein weiteres Bild hinzugefügt. Ich schrieb auch, daß ich den XTW mittels des ST-LINK V" auf dem Nucleo flashen wollte. Die roten Verbindungen auf der Skizze sind SCLK und SWO.
:
Bearbeitet durch User
Die Reset Leitung fehlt. Bei dem Programmieradapter von Nucleo Board muss man die 3,3V Leitung nicht anschließen.
Angehängte Dateien:
-
IMG_6978.jpg
220 KB
Stefan ⛄ F. schrieb: > Die Reset Leitung fehlt. Guter Punkt. NRST am SWD pin 5 an den Target Chip pin 7 ? Mache ich nachher gleich. > > Bei dem Programmieradapter von Nucleo Board muss man die 3,3V Leitung > nicht anschließen. Habe ich auch nicht (3,3V Leitung) und da ist ja auch keine, die man anschließen könnte. So, NRST auch verbunden von SWD Connector pin. Leider kein Programmiererfolg. Target wird nicht gefunden.
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG_6979.jpg
240 KB
Nachtrag, s. Bild. Wie man auch sieht, ist die Oberfläche des Chips weggelasert. Richtig versunken. Sollte meine Annahme falsch sein, daß es sich um einen STMF32 handelt? Könnte die Funktion der Schaltung, da sie sich nach im Betrieb befindet, den Programmiervorgang behindern oder beeinflussen? Würde es etwas ändern, wenn ich den BOOT pins verändere?
:
Bearbeitet durch User
Es könnte ein Fake sein. Hier poppen immer wieder Leute mit Blue-Pill Boards auf, die sich nur seriell per Bootloader flashen lassen. > Könnte die Funktion der Schaltung, da sie sich nach im Betrieb > befindet, den Programmiervorgang behindern oder beeinflussen? Ohne Schaltplan schwer zu raten. > Würde es etwas ändern, wenn ich den BOOT pins verändere? Wenn du BOOT0=High setzt, startet der Bootloader statt der Firmware. Der Bootloader deaktiviert die SWD Schnittstelle nicht. Es könnte Fummelei mit dem Reset ersetzen.
Angehängte Dateien:
-
IMG_6980.jpg
240 KB
BOOT0=1 (auf Vdd gesetzt, Pin 60 via Schalter mit 64 verbunden). SWD und Versuch, seriell zu programmieren klappt auch nicht. Schließe das Kapitel hier. Nochmal zusammengefaßt: o Mit diesem Klötzchen konnte ich das China Board STM32-DIYMORE via SWD programmieren (ST-LINK Utility Windows V 4.5.0.0) o STM32 Cube Programmer erkennt es nicht. Sagt: Error Old ST-LINK Firmware version. o Der Versuch, die BMP Firmware hineinzuflashen schlug fehl. Danke für die Unterstützung.
:
Bearbeitet durch User
Christoph K. schrieb: > Der Versuch, die BMP Firmware hineinzuflashen schlug fehl. vermutlich weil du SWO und SWDIO durcheinander wirtst. Erst noch korrekt SWDIO, dann redest du von SWO und wenn es wie in https://www.mikrocontroller.net/attachment/482586/IMG_6976_2.jpg am Disco angeschlossen ist, dann ist es falsch. Das UM https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjwrsjIoa_tAhWF_KQKHeW-ALcQFjAAegQIBBAC&url=https%3A%2F%2Fwww.st.com%2Fresource%2Fen%2Fuser_manual%2Fdm00039084-discovery-kit-with-stm32f407vg-mcu-stmicroelectronics.pdf&usg=AOvVaw02VAbwreRYjTEyDgPwXYck müsstest du doch schon auswendig kenn, Kapitel 6.1.5 beschreibt doch alles. SWCLK an Pin 2, SWDIO an Pin 4. Und das wird kein F411 sein, die STLinks haben F103RB und die Clone hatten anfangs noch orginole F103C8 und dann später undokumentiert kompatible. Mit etwas Glück ist in diesem XTW sogar ein F103RB mit 128 kB Flash nominell drin, aber das wird das der Progammer melden wenn die Verbindung funktioniert. Sowohl orginol STLink als auch BMP sind für F103 gebaut, das würde auch gar nicht auf einen F411 passen.
Angehängte Dateien:
@jojos: danke für die Klarstellung. Werde also noch mal einen Versuch starten. Allerdings benutze ich kein DISCO, sondern ein Nucleo F411RE. Aber da steht es in Kap. 6.2.4. Entsprechend habe ich jetzt das XTW mal an den SWD port des Nucleo angeschlossen. Wird leider noch nicht gefunden vom ST-Link Utility. Die blaue LED auf dem Klötzchen blinkt übrigens im Sek. Takt, was sie im Normalbetrieb nicht tut. Erster Erfolg! (siehe Bild) Disable RDP. Wie jetzt? Oder ist hier Schicht im Schacht? Vermute mal, daß der einzige Weg wäre, mutig zu sein und das Flash zu löschen. Und dann (daumendrück), das BMP.bin zu flashen.
:
Bearbeitet durch User
Thema erledigt. Klappe zu, Affe tot. Konnte über Option Bytes die RDP disablen. Danach das blackmagic.bin geflasht. Stick ist tot. Ich Blödmann habe in der Aufregung vergessen, das ausgelesene Programm zu retten. Jetzt wäre es nur noch eine akademische Aufgabe und eine schöne Übung, den Stick noch mal zu ordern und auszulesen, um das Teil zu repaieren. Warum blackmagic.bin darin nicht läuft, wäre dann eine andere Sache.
:
Bearbeitet durch User
Auch blackmagic_dfu.bin geflasht? Und wie wolltest du die alte SW ‚retten‘ wenn der Ausleseschutz aktiviert wurde?
Angehängte Dateien:
Johannes S. schrieb: > Auch blackmagic_dfu.bin geflasht? Nö, aber jetzt :) Und siehe da, BMP ist eingerichtet. Zumindest wurde das Device erkannt und von Windows 10 eingerichtet. Es ist auch im Gerätemanager zu sehen, aber leider ist ein gelbes Ausrufezeichen dran und STM32CubeProgrammer findet das Device auch nicht. > > Und wie wolltest du die alte SW ‚retten‘ wenn der Ausleseschutz > aktiviert wurde? Ich dachte, wenn der RDP deaktiviert ist, geht das?
:
Bearbeitet durch User
Christoph K. schrieb: > Ich dachte, wenn der RDP deaktiviert ist, geht das? ja, aber damit wird der Flash gelöscht. Sonst macht ein Ausleseschutz ja keinen Sinn wenn man den einfach abschalten kann... BMP ist nicht STLink kompatibel, die ST Software brauchst du nicht mehr. In BMP ist der GDB Server drin, das ist ja der Clou. Erstmal https://github.com/blacksphere/blackmagic 'Sample Session' lesen. Und das https://github.com/blacksphere/blackmagic/wiki mit Getting Started. Durch den eingebauten GDB Server ist das OS unabhängig und kann gut mit beliebigen Entwicklungsumgebungen kombiniert werden.
Angehängte Dateien:
Johannes S. schrieb: > Christoph K. schrieb: ... > BMP ist nicht STLink kompatibel, die ST Software brauchst du nicht mehr. > In BMP ist der GDB Server drin, das ist ja der Clou. > Erstmal https://github.com/blacksphere/blackmagic 'Sample Session' > lesen. Und das https://github.com/blacksphere/blackmagic/wiki mit > Getting Started. > Durch den eingebauten GDB Server ist das OS unabhängig und kann gut mit > beliebigen Entwicklungsumgebungen kombiniert werden. Ja, das ist mir schon klar, daß da mehr drin steckt, aber ich hatte aus Deiner Bemerkung weiter oben, als ich sagte, daß STM32CubeProgrammer das Ding als zu altes ST-Link erkannte/ablehnte, man könne es mit BMP flashen, abgeleitet, daß man es dann verwenden könne. Also, der fehlende Treiber unter Windows ist "normal"? Und BMP hat dann auch keine virtuelle COM Port? Den Text auf github hatte ich mir eben schon mal flüchtig reingezogen. EDIT: ich muß wohl noch den libusbK-Treiber unter Windows installieren. Mach ich gerade.... Bringt nichts. (s. Bild)
:
Bearbeitet durch User
das ist jetzt nur der dfu teil, flashe jetzt nochmal das blackmagic.bin. Es müssen zwei virtuelle serielle angezeigt werden im BMP Gerät. Der libUSB Treiber muss nur eingestellt werden wenn man das dfu Update machen will.
Johannes S. schrieb: > das ist jetzt nur der dfu teil, flashe jetzt nochmal das blackmagic.bin. > Es müssen zwei virtuelle serielle angezeigt werden im BMP Gerät. > > Der libUSB Treiber muss nur eingestellt werden wenn man das dfu Update > machen will. Habe jetzt den blackmagic.bin drübergeflasht und das Device ist tot. Habe das ganze noch mal wiederholt: Full Chip Erase blackmagic.bin geflasht blackmagic_dfu.bin (mit Skip Flash erase X) Dann gibt's dieses:
1 | 11:26:38 : ST-LINK SN : 0679FF525056805087052236 |
2 | 11:26:38 : V2J34M25 |
3 | 11:26:38 : Connected via SWD. |
4 | 11:26:38 : SWD Frequency = 4,0 MHz. |
5 | 11:26:38 : Connection mode : Normal. |
6 | 11:26:38 : Device ID:0x410 |
7 | 11:26:38 : Device flash Size : 64KBytes |
8 | 11:26:38 : Device family :STM32F10xx Medium-density |
9 | 11:26:50 : Flash memory erased. |
10 | 11:27:08 : [blackmagic.bin] opened successfully. |
11 | 11:27:08 : [blackmagic.bin] checksum : 0x00872258 |
12 | 11:27:36 : Memory programmed in 20s and 860ms. |
13 | 11:27:36 : Verification...OK |
14 | 11:27:36 : Programmed memory Checksum: 0x00872258 |
15 | 11:27:54 : [blackmagic_dfu.bin] opened successfully. |
16 | 11:27:54 : [blackmagic_dfu.bin] checksum : 0x0009D879 |
17 | 11:28:02 : The elf loader Program function fails. |
18 | 11:28:03 : The elf loader Program function fails. |
19 | 11:28:03 : Memory-Loader error |
20 | 11:28:03 : Error occured during program operation! |
21 | 11:28:03 : Programming error @ 0x08000004! |
22 | 11:28:08 : Programmed memory Checksum: 0x000AB501 |
:
Bearbeitet durch User
beim blackmagic.bin flashen auch die richtige Adresse angegeben? -> 0x08002000 als startadressse.
Angehängte Dateien:
Johannes S. schrieb: > beim blackmagic.bin flashen auch die richtige Adresse angegeben? 0x08000000 ? In welcher Reihenfolge muß man die Binaries flashen? Wo steht die Doku dazu? OK, 0x08002000. Woher weiß man das? Das sieht jetzt schon besser aus. Trotzdem immer noch diese gelben Ausrufezeichen bei den Devices.
:
Bearbeitet durch User
Die fehlenden Treiber für dieses Devices stören erstmal nicht. Aber das die VCOM fehlen ist schlecht. BMP versucht die HW zu erkennen, das scheint bei der (neuen?) XTW Hardware fehlzuschlagen. Man muss wissen auf welchen Ports die SWD liegt und kann dann die Quellen anpassen. Wenn du die SW sowieso schon selber kompiliert hast, dann ist das nicht schwierig. hier sind einige Clones aufgeführt, aber alle noch mit 48 Pin Chips. https://wiki.cuvoodoo.info/doku.php?id=jtag
oops, ja, wenn die von dem BMP sind ist alles gut. Eine davon ist für den GDB, ausprobieren.
1 | (gdb) |
2 | (gdb) target extended-remote /dev/cu.usbmodem7AAF76931 |
3 | Remote debugging using /dev/cu.usbmodem7AAF76931 |
4 | (gdb) monitor jtag_scan |
5 | Target voltage: 2.6V |
6 | JTAG device scan failed! |
7 | (gdb) |
'mon scan swd' wenn etwas per swd angeschlossen ist, aber BMP Firmware ist schon ok.
Johannes S. schrieb: > 'mon scan swd' wenn etwas per swd angeschlossen ist, aber BMP Firmware > ist schon ok.
1 | (gdb) mon version |
2 | Black Magic Probe (Firmware v1.7.1-69-gbf548e9) (Hardware Version 4) |
3 | Copyright (C) 2015 Black Sphere Technologies Ltd. |
4 | License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> |
5 | |
6 | (gdb) mon help |
7 | General commands: |
8 | version -- Display firmware version info |
9 | help -- Display help for monitor commands |
10 | jtag_scan -- Scan JTAG chain for devices |
11 | swdp_scan -- Scan SW-DP for devices |
12 | targets -- Display list of available targets |
13 | morse -- Display morse error message |
14 | halt_timeout -- Timeout (ms) to wait until Cortex-M is halted: (Default 2000) |
15 | connect_srst -- Configure connect under SRST: (enable|disable) |
16 | hard_srst -- Force a pulse on the hard SRST line - disconnects target |
17 | tpwr -- Supplies power to the target: (enable|disable) |
18 | traceswo -- Start trace capture, Manchester mode: (decode channel ...) |
19 | heapinfo -- Set semihosting heapinfo |
20 | (gdb) mon swdp_scan |
21 | Target voltage: 2.6V |
22 | SW-DP scan failed! |
23 | (gdb) |
Und das STM32F407-DIMORE ist über SWD-Interface angeschlossen. XTW DIYMORE --------------- SWCLK - PA14 SWDIO - PA13 GND - GND 5V - +5V Was ist mit den Leitungen RST und SWIM am ST-LINK (XTW)?
:
Bearbeitet durch User
da ist dann die Frage ob beim XTW die SWDIO auch auf PB14 und SWCLK auf PA5 liegen. https://github.com/blacksphere/blackmagic/blob/master/src/platforms/stlink/platform.h
Johannes S. schrieb: > da ist dann die Frage ob beim XTW die SWDIO auch auf PB14 und SWCLK auf > PA5 liegen. > https://github.com/blacksphere/blackmagic/blob/master/src/platforms/stlink/platform.h Puh. Durchpiepsen zum Pin geht leider nicht, da die Signale gepuffert sind und Leiterbahn verfolgen unterm Quarz durch ist auch nicht so toll. Gibt's von dem XTW irgendwo eine Schaltung? Könnte ich in der Source durch Trial and Error die Pins durchprobieren?
:
Bearbeitet durch User
hatte ich auch schon vergeblich gesucht. Vielleicht mal im blackmagic Discord channel fragen. Aber auch die Treiber könnten https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiwhcPzjrLtAhULJhoKHZ2dAWQQFjADegQIBBAC&url=https%3A%2F%2Fwww.ti.com%2Flit%2Fgpn%2Fsn74lvc1t45&usg=AOvVaw1ou20xFk8G9ep42WnBZJQn sein, das lässt sich auch verfolgen. Wobei der SWDIO noch die Richtungsumschaltung hat, da passt die STLINK platform von BMP nicht ganz. Da hast du schon eine Luxusvariante erwischt...
Konnte zumindest schon mal verifizieren, daß SWCLK auf PA5 geht (über einen 100 Ohm). Den Link, den Du da zitierst (mit dem bidirektionalen Treiber), auf welchen Baustein in meinem XTW ST-LINK V2 soll der sich beziehen?
:
Bearbeitet durch User
Wenn die Treiber aus meinem Link verbaut wären, dann müssten da mehrere sein, 3 Stück. Auf deinem Bild war jetzt nur einer zu sehen, wie sieht es unter dem Schaumstoff aus? SMD Markierung könnte aber auch ein Diodenarray als Schutz sein, der Treiber hat eine andere Markierung als V05. Wenn der SWCLK aber doch direkt raus geht, dann wird es einfacher und PA5 wäre ja schon richtig. Ist dann nicht auch PB14 SWDIO?
Erfolgsmeldung!
1 | $ arm-none-eabi-gdb |
2 | GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.50.20181213-git |
3 | Copyright (C) 2018 Free Software Foundation, Inc. |
4 | License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> |
5 | This is free software: you are free to change and redistribute it. |
6 | There is NO WARRANTY, to the extent permitted by law. |
7 | Type "show copying" and "show warranty" for details. |
8 | This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi". |
9 | Type "show configuration" for configuration details. |
10 | For bug reporting instructions, please see: |
11 | <http://www.gnu.org/software/gdb/bugs/>. |
12 | Find the GDB manual and other documentation resources online at: |
13 | <http://www.gnu.org/software/gdb/documentation/>. |
14 | |
15 | For help, type "help". |
16 | Type "apropos word" to search for commands related to "word". |
17 | (gdb) target extended-remote /dev/cu.usbmodem7AAF76931 |
18 | Remote debugging using /dev/cu.usbmodem7AAF76931 |
19 | (gdb) mon jtag_scan |
20 | Target voltage: 3.27V |
21 | JTAG device scan failed! |
22 | (gdb) target extended-remote /dev/cu.usbmodem7AAF76931 |
23 | Already connected to a remote target. Disconnect? (y or n) y |
24 | Remote debugging using /dev/cu.usbmodem7AAF76931 |
25 | (gdb) mon jtag_scan |
26 | Target voltage: 3.27V |
27 | JTAG device scan failed! |
28 | (gdb) mon swdp_scan |
29 | Target voltage: 3.28V |
30 | Available Targets: |
31 | No. Att Driver |
32 | 1 STM32F40x M4 |
33 | (gdb) |
34 | (gdb) |
Was hatte ich falsch gemacht? Nun, auf dieser Seite https://www.mjoldfield.com/atelier/2018/08/nucleo-bmp.html fand ich:
1 | $ git clone git@github.com:blacksphere/blackmagic.git |
2 | $ cd blackmagic |
3 | $ git submodule init |
4 | $ git submodule update |
5 | $ make |
6 | $ cd src |
7 | $ make clean |
8 | $ make PROBE_HOST=stlink |
Ich hatte das cd src und make PROBE_HOST=stlink vergessen bzw. wußte davon nichts. Im Moment hängt das STM32F407-DIYMORE Board dran.
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG_6995.jpg
240 KB
Johannes S. schrieb: > Wenn die Treiber aus meinem Link verbaut wären, dann müssten da mehrere > sein, 3 Stück. Auf deinem Bild war jetzt nur einer zu sehen, wie sieht > es unter dem Schaumstoff aus? SMD Markierung könnte aber auch ein > Diodenarray als Schutz sein, der Treiber hat eine andere Markierung als > V05. > Wenn der SWCLK aber doch direkt raus geht, dann wird es einfacher und > PA5 wäre ja schon richtig. Ist dann nicht auch PB14 SWDIO? Auf der Unterseite sind auch noch ein solcher V05 und ein S2SL (5-pol).
Glückwunsch :) Dann sind die V05 doch eher Schutzdioden. Ich sag ja, Luxusteil, das ist schon einer der besseren. Der Controller ist vermutlich zwar eher ein GD oder CK, aber egal wenn BMP läuft. Das Bluepill hast du ja jetzt auch noch als mögliche BMP HW, das hat den Vorteil das man noch eine VCOM für einen UART und damit für Debugausgaben oder Bedienung frei hat.
Johannes S. schrieb: > Glückwunsch :) Dann sind die V05 doch eher Schutzdioden. Ich sag ja, > Luxusteil, das ist schon einer der besseren. Der Controller ist > vermutlich zwar eher ein GD oder CK, aber egal wenn BMP läuft. > Das Bluepill hast du ja jetzt auch noch als mögliche BMP HW, das hat den > Vorteil das man noch eine VCOM für einen UART und damit für > Debugausgaben oder Bedienung frei hat. Blue Pill ist ja erst mal wieder zurückgegeben. Wieder gelernt. Selbst wo STM32F103CGBT drauf steht (auf der Verpackung) ist nicht zwangläufig auch STM32 drin. Suche jetzt gerade noch einen mit einem günstigen Preis-Lieferzeit-Produkt.
Angehängte Dateien:
-
DIY-More-STM32F407VGT6.png
650 KB
Wollte noch nachtragen zum eigentlichen Thema des Threads. Beste Doku (Schaltplan), die ich bis jetzt gefunden habe, befindet sich hier: https://github.com/BLavery/STM32F407VG-Arduino/blob/master/images/DIY-More-STM32F407VGT6.png Gutes Neues Jahr, Christoph
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.