Hallo zusammen, ich nutze einen ST-Link/V2-ISOL, der - genau wie die STM32-Discovery-Boards - als ST-Link/V2 erkannt wird. Auf den Nucleo-Boards ist ein SWD-Adapter, der mit "ST-Link/V2-1" bezeichnet wird und der mit dem anderen Treiber im ST-Link-Utility nicht erkannt wird. Die USB-PIDs bei beiden Devices sind unterschiedlich: Nucleo: 374B St-Link/V2-ISOL, Discovery: 3748 (komisch, sieht nach einen Flüchtigkeits-Tippfehler aus). Deswegen die Frage an die Gemeinde: Kennt jemand eine Übersicht, bei der die Unterschiede und Gemeinsamkeiten zwischen ST-Link/V2 vs. ST-Link/V2-1 erklärt werden? Viele Grüße W.T.
OpenOCD hat ebenfalls die 0x374B als ST-Link V2-1 PID hinterlegt. Das ist also völlig korrekt so. Schau mal nach, ob Dein ST-Link Tool noch aktuell ist.
ST-Link/V2: - Hat UART Verbindung zum Target als Viruial Com Device abgebildet - Hat ein Virtual Disk Device. Wenn man ein bin File auf diese Disk kopiert, wird das Bin File in das Target geflasht. Das ist fuer die MBED Kompatibilitaet wichtig und auch sonst neckisch.
Uwe Bonnes schrieb: > ST-Link/V2: > - Hat UART Verbindung zum Target als Viruial Com Device abgebildet > - Hat ein Virtual Disk Device. Zumindest diese Sachen treffen auf das ST-Link/V2-1 auch zu, wie ich beim bisherigen Probieren schon herausfinden konnte. Es schein nur (bedingt durch die andere PID) einen eigenen Treiber unter Windows zu benötigen. Und es kann kein JTAG.
Argh! Ich meinte natuerlich V2-1. V2 hat weder VCP noch "Virtual Disk"
Ah, OK, so herum ergibt das einen Sinn. Läuft über den virtuellen Com-Port das Gleiche, was ich am V2 mit dem ST-Link-Ultility im "SWO-Viewer" sehen kann?
:
Bearbeitet durch User
Nein, der VCP ist eine Verbindung zum UART des Targets. SWO sind Daten die aus der Debug Eingheit kommen. SWO sollte natuerlich auch mit V2-1 gehen, ich habe aber beides noch nicht getestet.
Kann man eigentlich die Firmware für den V2-1 irgendwie in einen "normalen" V2 reinbekommen? Mich interessiert z.B. die Funktion mit dem zusätzlichen UART. Beim STM32F3DISCOVERY ist ja auch eine UART-Verbinding zwischen µC-UART und dem ST-Link-Modul vorgesehen und kann per Lötbrücke hergestellt werden.
. ST-Link/ schrieb: > http://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe damit habe ich aber hinterher eine Black Magic Probe und keinen ST-Link/V2-1.
Gerd E. schrieb: > Kann man eigentlich die Firmware für den V2-1 irgendwie in einen > "normalen" V2 reinbekommen? Nicht dass ich wuesste. Ich habe schon auf ein Discovery Board mit STLINK-V2 einen neuen STM32F103CB statt des STM32F103C8 aufgeloetet und die ST-Link Firmware neu aufgespielt und dann den ST-Link Update gefahren. Es wurde und blieb aber ein V2. Auf der Blackmagic Seite gibt es ja Hinweise auf die Firmware zum Aufspielen von V2 auf ein blankes Device Vermutlich wird V2-1 mit einem anderen Bootloader bespielt. Ich verstehe auch nicht, warum ST nicht das V2-1 Bin-File veroeffentlicht. Wenn man Hardware mit dem STM32 baut, waere ein kombinierter VCP/Debug USB Anschluss auf dem Board hilfreich. Auf das Board kaeme dann ein zusaetzlicher F103CB. PS: Der VCP Uart auf dem Blackmagic verliert unter Last Zeichen...
Vieleicht sorgen allein schon die unterschiedlichen USB-PIDs dafür dass kein VCP-Treiber geladen wird stlink_VCP.inf [Standard.NTamd64] %DeviceNameVCP% =USB_InstallVCP, USB\VID_0483&PID_374A&MI_02 %DeviceNameVCP% =USB_InstallVCP, USB\VID_0483&PID_374B&MI_02 %DeviceNameVCP% =USB_InstallVCP, USB\VID_0483&PID_374C&MI_01 stlink_dbg_winusb.inf [Standard.NTamd64] %DeviceName% =USB_Install, USB\VID_0483&PID_3748 %DeviceName% =USB_Install, USB\VID_0483&PID_374A&MI_00 %DeviceName% =USB_Install, USB\VID_0483&PID_374B&MI_00 %DeviceNameRW% =USB_InstallRW, USB\VID_0483&PID_374A&MI_01 Für PID_3748 ist wohl kein VCP vorgesehen. Ob die PID jedoch in der Firmware enthalten ist? Am einfachsten wäre es wohl sich für etwa 13 Euro ein Nucleo-64 Board zuzulegen und sich ein V2-1 aus dem "cuttable PCB" rauszuschneiden. (Wenn man auch noch einen weiteren ST-Link hat könnte man theoretisch das Bin-File auch aus dem Flasch V2-1 rauslesen/rekonstruieren.)
rothy schrieb: > (Wenn man auch noch einen weiteren ST-Link hat könnte man theoretisch > das Bin-File auch aus dem Flasch V2-1 rauslesen/rekonstruieren.) Wenn der Code nicht Lesegeschuetzt ist ...
Könnte natürlich sein, wenn Sie bewusst aus dem Bin-File ein Geheimnis machen. Rein interessehalber Hast du folgende Version von ST-Link Update verwendet? http://www.st.com/web/catalog/tools/FM147/SC1887/PF260217 (stsw-link007.zip, STSW-LINK007, ST-LINK/V2-1 firmware upgrade )
Achtung blöde Idee Eine modifizierte stlink_VCP.inf wäre wohl unverschämtes Glück stlink_VCP.inf ;... [Standard.NTamd64] ;folgende Zeile hinzufügen %DeviceNameVCP% =USB_InstallVCP, USB\VID_0483&PID_3748&MI_02 %DeviceNameVCP% =USB_InstallVCP, USB\VID_0483&PID_374A&MI_02 %DeviceNameVCP% =USB_InstallVCP, USB\VID_0483&PID_374B&MI_02 %DeviceNameVCP% =USB_InstallVCP, USB\VID_0483&PID_374C&MI_01
Jim M. schrieb: > OpenOCD hat ebenfalls die 0x374B als ST-Link V2-1 PID hinterlegt. Das > ist also völlig korrekt so. Ich frage mich, wie die PIDs generell verwaltet werden. Bei USB.ORG kann man soweit ich weiß nut VIDs kaufen und der Hersteller verwaltet. Wie kann OpenOCD dann z.B. zur PID 0x0483 die 0x374B als PID hinterlegen wo die 0x0483 doch STMicroelectronics gehört. Gehören OpenOCD und STMicroelectronics irgendwie zusammen?
PIDs sind immer im Zusammenhang mit der VID zu betrachten.
Angehängte Dateien:
-
STlinkPreConnect.jpg
67 KB -
STlinkPostconnect.jpg
41 KB
Eine interessante Beobachtung zu ST-LinkUpgrade.exe aus stsw-link007.zip mit einem STlink/V2-1. Gerätemanager vor dem "Device Connect" s. STlinkPreconnect.jpg Gerätemanager nach dem "Device Connect" s. STlinkPostconnect.jpg Mit "Device Connect" wird eine Neuenumeration ausgelöst und es erscheint nur noch ein Gerät nämlich "STMicroelctronics STLink dongle" in der Gruppe "Universal Serial Bus devices". Dieses Gerät hat anders als vor dem "Device Connect" nicht die PID 374B sondern 3748. Heisst das jetzt: nicht ST-Link/V2-1 sondern STLink/V2? Wie auch immer: Verlässt man jetzt ST-LinkUpgrade.exe und versuch z.B. mit Keil eine Debug-Session zu starten kommt die Meldung "ST-Link in DFU mode. Restart or upgrade it." Soweit so gut. Wenn ich jetzt den eigenen Deutungen meiner bisherigen Recherchen z.B https://www.youtube.com/watch?v=Kx7yWVi8kbU trauen kann ist der DFU mode auch dafür geignet noch nicht programmmierte bzw. gelöschte Chips zu programmieren. Rein vom Spieltrieb her würde mich schon interresieren ob man ein Discovery Board mit STLINK-V2 und gelöschtem Flash irgendwie in den DFU mode bringen kann und was dann im Gerätemager ggf. erscheint. Ob allerdings ST-LinkUpgrade.exe eine Art Notfallplan für mislungene Updates bzw. korruptes oder leeres Flash hat? Zumindest enthält ST-LinkUpgrade.exe laut der readme.txt FIRMWAREen für 3 Zweige (V1, V2, V2-1). Rufus Τ. F. schrieb: > PIDs sind immer im Zusammenhang mit der VID zu betrachten. Das ist mir im Bezug auf die Treiberauswahl bei der Enumerierung schon klar. Mir gings nur darum worauf man sich verlassen kann. Mein (erschütterliches) Weltbild bisher: 1.) USB.ORG vergibt/verkauft VIDs an Hersteller. (nicht jede VID ist jedoch öffentlich) 2.) Der Hersteller verwendet (u.a. ?) die PID um seine eigene Produktpalette von unterschiedlichen Produkten abzubilden. 3.) Ob er sein PID-Schema öffentlich bekannt gibt oder irgendwo registrieren lässt (Windos-Treiberdatenbank, http://www.linux-usb.org/usb.ids) oder ob andere (ungefragt) dies für ihn tun, ist ein anderes Thema.
. ST-Link/ schrieb: > Artikel von obigem Herrn Bonnes: > > http://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe Lieber Uwe, könntest Du den Artikel bitte wieder zur Verfügung stellen? Der Link ist leider tot. Danke!
Eigentlich geht es wie im Titel des Threads versprochen darum, die Unterschiede zwischen den Programmierern herauszufinden und damit einfach Mal zu experimentieren. Wie positioniert sich die Black Magic Probe im Vergleich zu den beiden ST-Link Versionen? Einen chinesischen ST-Link/V2 kann man eventuell in einen V2-1 upgraden, wenn eine chinesische Klon-MCU mit 128KB verbaut wurde? Hier gibt es zumindest einen Artikel dazu: https://www.eevblog.com/forum/microcontrollers/dumping-and-reverse-engineering-st-link-v22-1-firmware/msg3525898/#msg3525898
Hier gibt es noch eine weitere Umbauanleitung: https://sudonull.com/post/32259-Making-ST-Link-V21-from-Chinese-ST-Link-V2 Den Anschluss umzubauen ist jedoch nicht wirklich motivierend, da kann man besser direkt ein passendes Board mit allen herausgeführten Anschlüssen nehmen. Außerdem https://github.com/User420t/V2_1/issues/1
:
Bearbeitet durch User
Karsten W. schrieb: > Hier gibt es noch eine weitere Umbauanleitung: > https://sudonull.com/post/32259-Making-ST-Link-V21-from-Chinese-ST-Link-V2 Das ergibt aber keinen vollwertigen ST-Link/V2.1. Insbesondere kann das Umbauergebnis kein SWIM, und funktioniert daher nicht mit STM8.
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.