ST-Link/V2 vs. ST-Link/V2-1

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.

Artikel von obigem Herrn Bonnes:

http://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe

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.)

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?

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.

>Board kaeme dann ein zusaetzlicher F103CB.
oder ein ST-Link V3