Ich habe mir letztens zwei weitere STM32 BluePill Development Board gekauft. Wie es bereits bekannt ist, muss hier zunächst der Bootloader gebrannt werden. Also die Jumper gesetzt und über UART und z.B dem „Flash Loader Demonstrator“ das generic_boot20_pc13.bin auf den Controller gebrannt. Bei mir ist die LED an PC13 angeschlossen.
Jumper zurücksetzen und über den USB vom STM diesen an den PC anschließen. Im Geräte-Manager meldet sich der STM als „Mapple 003“ an [Bild 1] und nach kurzen automatischen Updates der Treiber wird dieser unter „libusb-win32 device“ als „Maple DFU“ angezeigt [Bild 2].
So weit so gut…. Leider fehlt hier jedoch die Zuweisung eines COM-Ports…!
Eine weitere Möglichkeit ist, die in der Arduino DIE zugefügten Treiber vom STM zu installieren. Dafür als Admin die „install_drivers.bat“ und zum Teil auch die „install_STM_COM_drivers.bat“ ausführen um die Verknüpfung in Windows herzustellen… ebenfalls ohne Erfolg…
Selbst hab ich bereits zwei funktionierende STM32-Boards hier liegen. Angemeldet werden diese immer mit einem COM-Port [Bild 3] in Windows und funktionieren trotz der andauernden Neuinstallationen von den Treiber tadellos.
Da ich langsam dachte, dass die STM32 bei den neuen Board einen defekt haben, hab ich kurzerhand mir einen STM32F106-IC bei einem anderen Hersteller gekauft und den Chip auf dem PCB getauscht. Auch hier das gleiche.. somit müsste es eigentlich nur an der Software liegen... nur wo ?
Mein letzter Versuch war es jetzt noch die Maple-Treiber manuell zu installieren. Dafür hab ich vorsichtshalber den PC im angesicherten Modus gestartet um automatische Treiberinstallationen zu umgehen und den maple-serial-Treiber manuell beim STM installiert. Ein kleiner Teilerfolg war da und Windows hat diesen unter Anschlüsse als „Maple Serial“ mit einem COM-Port angezeigt. Dennoch fehlte es Windows an einem Treiber und direkt nach dem Anschließen mit dem Maple DFU überspielt.
Wäre super wenn jemand noch eine weiter Idee hat, damit der STM noch Programmiert werden kann.
Ich habe mir letztens zwei weitere STM32 BluePill Development Board
gekauft. Wie es bereits bekannt ist, muss hier zunächst der Bootloader
gebrannt werden.
Nein, muß er nicht. Man kann auch weiterhin (wie es für das Brennen des Bootloaders ja nötig war) mit dem im ROM stehenden Bootloader arbeiten, bei dem man dann entweder einen echten COM-Port oder eine USB-UART-Bridge benutzt, deren Windowstreiber man hat.
Außerdem kann man noch den ST-Link benutzen.
Gruß Klaus (der soundsovielte)
P.S. Wenn man meint, man müsse unbedingt mit einem zusätzlichen Bootloader arbeiten, sollte man sich einen aussuchen, dessen Windowstreiber dabei ist (oder mit Linux arbeiten, wo meist nicht der Treiber, sondern die Rechteverwaltung der Knackpunkt ist).
Ich suche halt eine Möglichkeit direkt den D+ und D- Pin vom STM zu nutzen und dieses hierüber zu Programmieren. Ich wollte eigentlich ungerne wieder ein zusätzliches Gerät mit einbringen.
Ich arbeit im Moment ebenfalls an einer Platine die aus diesesm Grund einen STM vorsieht. Da ich hier nur begrenztzen Platz habe wäre diese Direktlösung am Besten geeignet. Die STM Controller sind sowieso beutlich besser als so mach anderer Controller. Ich weiß das es auch so funktioniert nur sehr schade das der Windostreiber jetzt so große Probleme macht
nach kurzen automatischen Updates der Treiber wird dieser
unter „libusb-win32 device“ als „Maple DFU“ angezeigt [Bild 2].
So weit so gut…
Genau, bis dahin ist alles richtig
Leider fehlt hier jedoch die Zuweisung eines COM-Ports…!
Deine Erwartungshaltung ist falsch. Das DFU Protokoll emuliert keine serielle Schnittstelle. Es ist völlig richtig, dass da kein virtueller COM Port erscheint. Die zugehörige Software spricht den Mikrocontroller über die libusb-win32 Bibliothek an, nicht über einen COM Port.
Der virtuelle COM Port ist Bestandteil des Anwendungsprogramms, das nach dem Bootloader startet (wenn es installiert ist). Soweit ich mich erinnere, enthält generic_boot20_pc13.bin einen LED-Blinker als Anwendungsprogramm. Ob dieses auch einen virtuellen COM Port auf macht, weiß ich nicht.
Ich hoffe, du hast keine schlechte Fälschung bekommen. Bluepill Boards mit originalem Chip sind ja seit ein paar Jahren offenbar nicht mehr im Handel.
Wenn man meint, man müsse unbedingt mit einem zusätzlichen
Bootloader arbeiten, sollte man sich einen aussuchen, dessen
Windowstreiber dabei ist
Ich suche halt eine Möglichkeit direkt den D+ und D- Pin vom STM zu
nutzen und dieses hierüber zu Programmieren. Ich wollte eigentlich
ungerne wieder ein zusätzliches Gerät mit einbringen.
Ja, dann kommt auch nur ein zusätzlicher Bootloader in Frage, da die Bluepill von sich aus noch kein USB-Boot unterstützt. Ganz offensichtlich haben Deine bereits vorhandenen Bluepills einen Bootloader, der auf der PC-Seite von einem Treiber bedient wird, der einen virtuellen Com-Port (VCP) emuliert. Wenn Du jetzt nicht irgendeinen, sondern genau den Bootloader findest, der bereits in Deinen vorigen Bluepills steckt, bist Du fertig. Ganz offensichtlich ist aber der von Dir auf die neuen Bluepills aufgespielte Bootloader eine Anderer. Für den existiert ein Treiber, der eben nicht einen VCP emuliert, sondern die alternative Methode, eine Library verwendet (ob als DLL oder statisch). Das hat dann den Nachteil, daß Du unterschiedliche Methoden zum Brennen benutzen müsstest. Insofern wäre es aus meiner Sicht praktischer, genau den Bootloader zu finden, der bereits auf Deinen vorherigen Boards drauf ist. Aber das ist allein Deine Wahl. Wenn der neuere Bootloader dank Steves Unterstützung (ich kenne mich nur mit den VCPs aus) funktionieren sollte, kannst Du sie natürlich auch auf die alten Boards aufspielen und hast dann wieder ein einheitliches Interface.
@Steve van de Grens
Du scheinst Dich mit den Bootloadern auszukennen, die libusb verwenden. Könntest Du das ein wenig ausführlicher darlegen? Ich würde gerne mehr darüber lernen.
Der virtuelle COM Port ist Bestandteil des Anwendungsprogramms, das nach
dem Bootloader startet (wenn es installiert ist).
Das scheint mir nicht ganz richtig zu sein. Über USB laufen die Daten auf der unteren Ebene nach der USB-Spezifikation und obendrauf nach dem Protokoll, das der Programmierer auswählt. Und auf der Gegenseite, dam PC, reicht trennt der USB-Treiber von Windows die untere Protokollschicht ab und reicht die Nutzdaten an das PC-Programm weiter und nutzt dabei dieselben Betriebssystemaufrufe wie die für die echten Comports. Das ist dann erst der VCP. Der läuft also auf dem PC und nicht auf dem uC. Sehe ich das falsch?
Ja. Einen "VCP" gibt es nur, wenn das USB-Gerät selbst ein passendes Protokoll spricht, das ist entweder CDC oder aber ein proprietäres Protokoll, zu dem ein passender Devicetreiber gehört (wie z.B. bei FT232, CP2102 etc.).
Wenn das USB-Gerät aber ein anderes Protokoll spricht (wie z.B. HID), dann gibt es keinen "VCP". Das ist keine Entscheidung einer Anwendungssoftware oder eines Devicetreibers auf dem PC.
Verstehe ich das richtig, daß damit die "Communication Device Class" gemeint ist und ein Virtueller ComPort vom Betriebssystem auch ohne separaten Treiber eingerichtet wird, wenn auf dem USB-layer dieses CDC signalisiert wird?
Gruß Klaus (der soundsovielte)
P.S. Ich kenne USB bisher nur aus Anwendersicht, arbeite aber viel mit VCPs und habe inzwischen soviele verschieden USB-Geräte an meinem Entwicklungs-PC, daß ich ständig nicht mehr benötigte Treiber deinstallieren muß, damit ich nicht bei COM45 lande. Manche Programme, die ich gern nutze, sind nach oben begrenzt und erlauben nur bis COM6 oder COM20 etc.pp. Da könnte mir etwas mehr Wissen um die USB-Eigenheiten weiterhelfen. Danke im voraus.
die libusb verwenden.
Könntest Du das ein wenig ausführlicher darlegen? Ich würde gerne mehr
darüber lernen.
winusb nicht libusb. ist aber in der Praxis ziemlich ähnlich. Beides sind Treiber die APIs bereitstellen um mit USB Devices zu reden. Das ist eigentlich dafür gedacht für Devices die keiner USB Klasse entsprechen einen Satz Funktionen bereitzustellen um vom Usermode die UsbDevices anzusprechen. Libusb kommt aus der Linuxecke WinUsb stammt von MS und wurde erstmals unter XP SP2 unterstützt.
Da man seit W10 keine keine Treiber mehr ohne Zertifikat fürs binary und inf installiert bekommt, ist die Anwendung etwas tricky weshalb oft das mächtige aber auch gefährliche zadig für die Zuordnung verwendet wird. (*)
Es gibt auch automatische Wege die dann aber in der USB FW eingebaut werden müssen. -> Beitrag "Usb BOS descriptor"
Zusammengefasst kann man sagen:
libusb oder winusb kommen immer dann zum Einsatz wenn man usb direkt von einer App steuern will. Was genau passiert ist in der usb FW und der App festgelegt.
(*) zadig kann auch für Classdevices verwendet werden um z.B. aus einem Memory Stick ein libusb device zu machen. Ich hab das z.B, schonmal gemacht um die USB Kommunikation eines Memory Sticks für Testzwecke zu emulieren.
Danke, das ist mal handfeste Information. Habe bisher immer um USB den größten Bogen gemacht, den ich hinbekommen habe. Es rückt aber immer näher an mich ran, da kann etwas solides Wissen nicht schaden.
Beispiel (etwas vereinfacht):
usbmidi, VCP, MSD verwenden alle ein ein Bulk EP Paar für die Datenübertragung. (Die zusätzlichen formalen Sachen in den Deskriptoren mal ignoriert). in allen 3 Fällen wird im den Deskriptoren beschrieben dass die einer entsprechenden Klasse angehören.
Das Datenformat der Bulk Eps ist dabei klassenspezifisch. USB legt nur fest, dass max 64B (Fullspeed) oder 512B (HighSpeed) über den EP laufen. Darüber liegen dann Funktionen die die Datenpakete filtern und an die entsprechenden Systemtreiber weiterleiten. MS hat dafür früher den Begriff minidriver geprägt. Entsprechende Beispiele sind in alten DDKs zu finden.
Im Falle eines Speichergeräts:
Der Systemtreiber hat dann keine Ahnung mehr ob z.B die Daten von einem Memorystick, von einer SATA Schnittstelle, vom Netzwerk... usw kommen.
nochwas:
libusb ist so beliebt weil man unter WIN,LINUX,OSX und Android im wesentlichen die gleichen API Funktionen hat. Das vereinfacht die App Programmierung wenn man mehrere OS unterstützen will.
Verstehe ich das richtig, daß damit die "Communication Device Class"
gemeint ist und ein Virtueller ComPort vom Betriebssystem auch ohne
separaten Treiber eingerichtet wird, wenn auf dem USB-layer dieses CDC
signalisiert wird?
Du scheinst Dich mit den Bootloadern auszukennen, die libusb verwenden.
Könntest Du das ein wenig ausführlicher darlegen? Ich würde gerne mehr
darüber lernen.
Das ist dann erst der VCP. Der läuft also auf dem PC und nicht
auf dem uC. Sehe ich das falsch?
Jein.
Der Bootloader startet eine DFU Schnittstelle und wartet 1s auf Kontaktaufnahme durch den PC. Danach beendet sich der Bootloader und startet das Anwendungsprogramm (falls vorhanden). Dieses enthält üblicherweise einen virtuellen COM Port (also ein CDC Device).
Auf dem PC sieht das so aus: Beim Anstecken des USB Kabels sieht man für 1s den DFU Bootloader als winusb oder libusb Device. Eine Sekunde später verschwindet er, stattdessen taucht dann im Gerätemenager der virtuelle COM Port auf.
Beispiel (etwas vereinfacht):
usbmidi, VCP, MSD verwenden alle ein ein Bulk EP Paar
Ist für mich schon schwer verständlich, weil ich bis auf VCP alle Akronyme raten muß, wobei ich bei usbmidi vermutl. richtig rate, bei EP=EndPoint aber schon unsicher bin und bei MSD passen muß. Googles Akronymfinder sind bei solch speziellen Sachen i.d.R. ahnungslos.
Hättest Du einen Tipp für mich, wo USB für einen Menschen mit solider Halbbildung erklärt wird? Ich baue ja einfache Elektronik selber und programmiere beruflich Sondermaschinen, bin also ziemlich breit aufgestellt und starte nicht auf dem Anfängerlevel. Ein Level, auf dem ich Deinen USB-Stack f. den CH552 verstehen könnte, würde mich schon reizen zu erreichen
Entsprechende Beispiele sind in alten DDKs zu finden.
Könnte es sich um SDKs handeln? Sowas fliegt bei mir noch rum.
Hättest Du einen Tipp für mich, wo USB für einen Menschen mit solider
Halbbildung erklärt wird?
Es gibt diverse Bücher zum Thema, u.a. von Jan Axelson. Die können einem helfen, einen gewissen Überblick zu finden. Aber auch nicht unbedingt schlecht sind die /englischsprachigen/ Wikipediaseiten.
sorry für die Abkürzungen :-)
usbmidi ist Teil des usbaudio.sys Klassentreiber (ab WinME mit Midi)
MSD ist der Treiber für Memory Sticks (ab WinME)
VCP ist der Treiber usbserial.sys (ab XP) war aber schon für W98 als usbpos.sys im W98 DDK (Driver Development Kit) im Sourcecode verfügbar genau wie eine frühe Version des MSD Treibers.
EP steht für Endpoint das ist im wesentlichen einfach ein Datenkanal in eine Richtung. BULK ist ein USB lowlevel Transferformat mit Error Korrektur und automatischer Wiederholung. (ISOCHRON bzw INTERRUPT wären die anderen Formate)
usb.org für die Specs und Tools.
USB Complete von Jan Axelson
USB Mass Storage von Jan Axelson
Serial Complete von Jan Axelson
USB Design by Example von Jon Hyde
Programming the Microsoft Windows.Driver Model von Walter Oney
alle in Englisch und auch in Online Biblioteken zu finden (ZLib ist ja down)
usbmidi ist Teil des usbaudio.sys Klassentreiber (ab WinME mit Midi)
MSD ist der Treiber für Memory Sticks (ab WinME)
Das ist sehr grob vereinfacht.
Tatsächlich ist es so, daß es USB-Geräteklassen gibt (HID, CDC, Audio, Midi, MSD und noch ein paar andere), und daß Betriebssysteme üblicherweise mit universellen Devicetreibern für diese Geräteklassen daherkommen.
Du vermischst die Geräteklassen mit den Namen der Gerätetreiber unter Windows.
Die beliebten USB-Seriell-Bridges von FTDI, SiLabs, Prolific oder auch WCH sind /keine/ CDC-Geräte, sondern nutzen ein proprietäres Protokoll und benötigen daher prinzipiell ihre eigenen Gerätetreiber; bei manchen Betriebssystemen ist dieser Treiber aber auch im Lieferumfang enthalten (Linux & Co.).
Windows weigerte sich lange, ohne zusätzliche Informationen mit CDC-Geräten zu kommunizieren, /obwohl/ der nötige Treiber praktisch schon immer in Windows enthalten war, dieser Designfehler wurde erst mit Windows 10 behoben. Vorher brauchte man mindestens eine *.inf-Datei und, dank Treibersignierung, auch noch eine passende *.cat-Datei.
Der Bootloader startet eine DFU Schnittstelle und wartet 1s auf
Kontaktaufnahme durch den PC. Danach beendet sich der Bootloader und
startet das Anwendungsprogramm (falls vorhanden). Dieses enthält
üblicherweise einen virtuellen COM Port (also ein CDC Device).
Für mich ist ein "virtueller Com-Port" eben etwas Anderes als ein CDC-Device,
kann aber auch mit einer völlig anderen Definition leben.
Ich denke, daß wir da einach ein Problem mit unterschiedlicher Bedeutung von Wörtern haben. So wie das "Rad" im Deutschen mal die generische Bedeutung eines runden Teils mit Mittelachse hat, im Speziellen aber auch das Zweirad/Fahrrad meint.
So hat auch der COM-Port zwei Bedeutungen, er ist einmal der generische "Communication Port", der vieles Verschiedenes bedeuten kann, im Speziellen aber auch der 7/8/9-bit UART, der im PC sitzt. Und der ist nur dann "virtuell", wenn eben nicht ein UART dahintersitzt, sondern eine andere serielle Technik wie USB eingesetzt wird. Alles Andere ist eben "reell" und nicht virtuell, insofern verorte ich das Ende des "Virtuellen" schon im PC. Dann geht es mit etwas Anderem weiter, was nur der generischen, aber reellen Bedeutung von COM-Port entspricht, das ist dann wohl die "CDC". Da findet dann eine schleichende Umdeutung statt, es heißt noch "virtuell", ist aber längst "reell".
Das ist aber im Deutschen nicht ungewöhnlich, man denke nur an den "Geburtstag", der heutzutage auch nicht mehr den Tag der Geburt, sondern nur noch dessen Jahrestage meint.
natürlich ist es das. 25 Jahre USB kann man nicht in ein paar Zeilen erklären.
Ich rede übrigens immer von Windows, weil ich von OSX fast keine Ahnung und von Linux nur wenig Ahnung habe.
Was ich sagen wollte UAC1 (UsbAudioClass 1.0) wurde seit W98 unterstützt. Der Midi Teil kam aber erst mit WinME. W98 hing bei Midi Descriptoren W200 produzierte einen Blue Screen. Solange beschäftige ich mich schon mit USB zeitweise auch mit USB Treiberprogrammierung unter Win.
Soweit ich mich
erinnere, enthält generic_boot20_pc13.bin einen LED-Blinker als
Anwendungsprogramm.
Ja, genau so ist es. Da ich an der Sache ja interessiert bin, habe ich mir spaßeshalber die Datei generic_boot_pc13.bin hergeholt mit dem von mir üblicherweise verwendeten "stm32flash" aus der Arduinoinstallation per UART-Boot auf das Board übertragen. Es blinkte wild vor sich hin und erschien wie beim TO als Maple003 im Gerätemanager von Windows. Gemäß Anleitung habe ich dann den Mini-USBtreiber f.Maple hergeholt, entpackt und das install_driver.bat aufgerufen. Damit ließ sich aber noch kein geändertes Programm in der Arduino-IDE auf das Bluepillboard laden. Ich mußte direkt nach dem Erscheinen des weißen Erfogstextes der Compilierung kurz auf die Resettaste der blauen Pille drücken, dann wurde das Board gefunden und das Programm erfolgreich übertragen. Es ist also genau so, wie Du beschrieben hast, für eine Sekunde nach Reset ist der Bootloader aktiv, danach springt er ins (Blink-)Programm und die Verbindung per USB ist tot.
Wahrscheinlich fehlt auf dem Board die Mimik, um per USB einen Reset auszulösen, wie es bei den AVRs Usus ist. Man muß also von Hand nachhelfen.
Immerhin funktioniert es schonmal. wenn auch noch nicht komfortabel.
Gruß Klaus (der soundsovielte)
P.S. Es muß aber natürlich noch einen anderen Bootloader geben, der sich so verhält, wie vom TO bei seinen älteren Boards beschrieben.
Wenn der TO erfindix diese Boards per "stm32flash" auslesen würde, könnte darin ein Hinweis auf die Quelle enthalten sein. Bisher hat er sich ja nicht wiedergemeldet.
P.S.2: Dank an alle Hinweisgeber, ich habe jetzt ein USB-Lern-Wochenende vor mir! Ein Fischkopp wie ich, der im Süden lebt, verzieht sich bei diesen Temperaturen am liebsten in den Keller.
Ja, so ist das. Alles ziemlich unhandlich, da nehme ich lieber direkt
einen ST-Link Adapter (ohne Bootloader).
Wenn ich für ST-Controller entwickeln würde, tät ichs auch.
Ich hab aber nur externe Geräte (aktuell 6) von anderen Herstellern über USB an der Maschine und muß eine reibungsfreie USB-Kommunikation hinkriegen.
So ist die Bluepill mit ihrem USB-Anschluß nur spielerisches Lehrmaterial, die "Unhandlichkeit" ist der Zweck der Übung :-)
Für meine eigenen Basteleien habe ich noch keinen Verwendungszweck f. die Bluepill gefunden.
Ja, genau so ist es. Da ich an der Sache ja interessiert bin, habe ich
mir spaßeshalber die Datei generic_boot_pc13.bin hergeholt mit dem von
mir üblicherweise verwendeten "stm32flash" aus der Arduinoinstallation
per UART-Boot auf das Board übertragen. Es blinkte wild vor sich hin und
erschien wie beim TO als Maple003 im Gerätemanager von Windows. Gemäß
Anleitung habe ich dann den Mini-USBtreiber f.Maple hergeholt, entpackt
und das install_driver.bat aufgerufen. Damit ließ sich aber noch kein
geändertes Programm in der Arduino-IDE auf das Bluepillboard laden. Ich
mußte direkt nach dem Erscheinen des weißen Erfogstextes der
Compilierung kurz auf die Resettaste der blauen Pille drücken, dann
wurde das Board gefunden und das Programm erfolgreich übertragen. Es ist
also genau so, wie Du beschrieben hast, für eine Sekunde nach Reset ist
der Bootloader aktiv, danach springt er ins (Blink-)Programm und die
Verbindung per USB ist tot.
Wahrscheinlich fehlt auf dem Board die Mimik, um per USB einen Reset
auszulösen, wie es bei den AVRs Usus ist. Man muß also von Hand
nachhelfen.
Immerhin funktioniert es schonmal. wenn auch noch nicht komfortabel.
Moin Klaus,
das klingt nach einer möglichen, wenn auch nicht einer zu praktikablen Lösung. Ich habe es jetzt auch mal so versucht. Problem ist bei mir, dass ich bei der Arduino-IDE ja einen USB-Port wählen muss. Da ich keinen Port wählen kann habe ich dieses jetzt ignoriert…dürfte also nicht klappen. Nach dem Reset beim Kompilieren meint die IDE einen "USB Device 0x1eaf:0x0003" gefunden zu haben. Der Upload bricht aber wegen des Com-Ports ab
Was noch auffällig ist, dass die LED nur blinkt, wenn BOOT1 auf 1 (HIGH) steht. Wenn der Jumper auf 0 steht gehts nicht. Der BOOT0 bleibt auf 0 (LOW).
Ich habe mir jetzt nochmal den STLink zusätzlich bestellt um hierüber auch nochmal ein wenig auszuprobieren
Der Log in der IDE ist wie folgt:
gewählt: STM32duino bootloader
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=256
Starting download: [##################################################] finished!
error resetting after download: usb_reset: could not reset device, win error: Ein nicht vorhandenes Ger�t wurde angegeben.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
timeout waiting for COM9 serial
P.S. Es muß aber natürlich noch einen anderen Bootloader geben, der sich
so verhält, wie vom TO bei seinen älteren Boards beschrieben.
Wenn der TO erfindix diese Boards per "stm32flash" auslesen würde,
könnte darin ein Hinweis auf die Quelle enthalten sein. Bisher hat er
sich ja nicht wiedergemeldet.
Gibt es eine Fehlermeldung? Was exakt hast Du versucht? Hast Du das
Binary runtergeladen, oder versuchst Du die Sourcen selbst zu
übersetzen?
ich habe mir die
stm32flash-0.7-binaries.zip
heruntergeladen und versucht, diese über die .exe zu starten. Hier öffnet und schließt sich das Fester sofort, ohne etwas erkennen zu können.
Bei der
stm32flash-0.7.tar.gz
habe ich versucht die Sourcen selbst über die Eingabeaufforderung zu starten. Hier gehts leider auch im Moment nicht so ganz weiter
Ah mist.. mein Fehler. War auf die exe zu sehr fixier und hab das übersehen.
Zum Auslesen führe ich den Befehl aus
...binaries/stm32flash.exe /dev/ttyS0
wobei ttyS0 durch meine Schnitstelle vom STM ersetz wird. Nur weche ist das.. Bei Windows ist das mal wieder so versteckt zu finden
Leider bekomme ich dieses nichr auf meinen Win-pc zum laufen
Das ist kein Bootloader, das ist mein "Brot- und Butterprommer" für die Bluepill. Der bedient den im ROM befindlichen UART-Bootloader, muß dementsprechend einen Dateinamen und den COMportnamen mitbekommen, der mit A9/A10 auf der blauen Pille verbunden ist.
ich habe mir die
stm32flash-0.7-binaries.zip
heruntergeladen und versucht, diese über die .exe zu starten. Hier
öffnet und schließt sich das Fester sofort, ohne etwas erkennen zu
können.
Typisch klickibunti User.
Das Programm muss mit Parametern aufgerufen werden, also in der cmd Shell (Eingabeaufforderung)
Das braucht eine serielle Schnittstelle. Hat Dein "Maple DFU" eine?
DFU geht über USB, nicht seriell. DFU hat nichts mit COM Ports zu tun. Stm32flash ist für den seriellen Bootloader, nicht für DFU.
Der Maple Bootloader spricht ein anderes DFU Protokoll als die festen per Boot0 aktivierbaren Bootloader von ST. Der feste Bootloader vom STM32F103 kann jedoch kein DFU, sondern nur seriell an PA9 und PA10. Der STM32F105 kann DFU.
Offenbar verwirren hier zu viele Optionen. Deswegen lies meine Homepage.
Im Geräte-Manager meldet sich der STM als „Mapple 003“ an
[Bild 1] und nach kurzen automatischen Updates der Treiber wird dieser
unter „libusb-win32 device“ als „Maple DFU“ angezeigt [Bild 2]
da wird kein Com zugewiesen. sonst wäre ja alles geklärt und ich könne den STM in der z.B. Arduino-IDE programmieren.
Bild "B1" zeigt die EInstellungen von dem dann Maple DFU an
DFU geht über USB, nicht seriell. DFU hat nichts mit COM Ports zu tun.
Stm32flash ist für den seriellen Bootloader, nicht für DFU.
Der Maple Bootloader spricht ein anderes DFU Protokoll als die festen
per Boot0 aktivierbaren Bootloader von ST. Der feste Bootloader vom
STM32F103 kann jedoch kein DFU, sondern nur seriell an PA9 und PA10. Der
STM32F105 kann DFU.
Offenbar verwirren hier zu viele Optionen. Deswegen lies meine Homepage.
Top, das klingt ja nach dem Problem, warum Windof so viel Probleme bereitet. Kannst du nicht sonst kurz erklären wie ich den STM-Flashen muss bzw was ich in Windows ändern muss damit es läuft.
Nutze wie erklärt den STM32F103C6T6
Danke
Das ist mein USB-Tree, es hängen nur mein Wirelessadapter und die blaue Pille dran. Es wird im Gerätemanager immer noch "Maple 003" unter "Andere Geräte" angezeigt. Eigentlich warte ich drauf, daß sich das ändert und "libusb-win32" angezeigt wird. Das ist aber noch nicht der Fall, Keine Ahnung, wann, wie und Warum das passiert.
Das ist mein USB-Tree, es hängen nur mein Wirelessadapter und die blaue
Pille dran. Es wird im Gerätemanager immer noch "Maple 003" unter
"Andere Geräte" angezeigt. Eigentlich warte ich drauf, daß sich das
ändert und "libusb-win32" angezeigt wird. Das ist aber noch nicht der
Fall, Keine Ahnung, wann, wie und Warum das passiert.
Das hatte ich auch teilweise. Wenn du jetzt einfach mal die "install_drivers.bat" ausführst wird diese auf alle Fälle hier umgeschrieben. (BluePill am PC lassen)
Mein Tree sieht wie folgt aus. Den Log habe ich mal als Textdokument angehängt. Ich hoffe darauf kann vielleicht wer was erkennen :)
Das ist mein USB-Tree, es hängen nur mein Wirelessadapter und die blaue
Pille dran.
nicht ganz du hast an Port7 vermutlich den Maple hängen der nicht funktioniert
weil kein Treiber zugeordnet ist und an Port 15 noch was anderes.
Benutze jetzt mal den UsbTreeView von Sieber der ist wesentlich gesprächiger...
nö passt das hatte ich übersehen sorry. Also aus diesem MAple Dingsbum kann nie ein VCP (CDC) werden da nur DFU Deskriptoren da sind. Mich würde ja mal interessieren was du an der Install_drivers,bat umgeschrieben hast.
Ich hatte die "install_drivers.bat" vergessen. Sinnigerweise ist auf meinem Rechner mit 64-bit-Windows jetzt der COM-Port erschienen.
Auf meinem Laptop mit 32-bit-Windows erschien nur das libusb-win32-Gerät.
Auf dem 64-bit-Windows kann ich jetzt neue Programme aufspielen, ohne den Resetknopf zu betätigen, also so, wie es sein soll.
Upload method: STM32duino Bootloader!
Gruß Klaus (der soundsovielte)
P.S. Muß mich jetzt verabschieden, bin für 18 Uhr zu Essen eingeladen :-)))
Habe jetzt nochmal den USB-TRee aufgenommen. Der Text zum Maple-Treiber ist so lang, daß er auf meinen 1600x1200 Bildschirm nicht ganz draufpaßt. Steht dann in der Textdatei.
vorläufiges Fazit:
64-bit-Win10 (Haswell CPU mit 12GB RAM): Treiber funktioniert
Ich kann fehlerfrei beliebige Blinkmuster mit dem Beispielprogramm erzeugen.
Situation im 32-bit-Win10 ändert sich noch langsam, ich berichte wenn stabile Situation eintritt.
Auch im 32-bit-Win10 ist die Lage jetzt stabil. Nach Ausführen von install_drivers.bat verschwand die Meldung "Maple 003" bei "andere Geräte" und es tauchte zunächst wie beim TO "Seine Majestät (erfindix)" in Bild 2.JPG
unter "libusb-win32 devices" das Gerät "Maple DFU" auf und verschwand nach eineigem An- uns Abstecken (zum Test am 64-bit-OS) wieder, um als VCP "Maple Serial (COM 7) "wieder aufzutauchen.
Ein Aufspielen neuer Programme ist aber nach wie vor nicht möglich. Es verschwindet aber das am 64-bit-OS aufgespielte Programm und das originale nervöse Blinken, das direkt nach dem Aufspielen des Bootloaders auftritt, ist wieder da. Es steht vermutlich direkt im Bootloaderteil. Es wurde also ein Anwenderprogramm stillgelegt, auch wenn der maple_loader behauptet, kein DFU-Programm finden zu können (siehe den Mitschnitt Arduino32.txt).
Gruß Klaus (der soundsovielte)
P.S. Ich versuche jetzt mal, aus den Texten von usbview schlauer zu werden.
In der Ereignisanzeige stehen vielleicht hilfreiche Fehlermeldungen.
Das Bluepill Board hält sich nicht richtig an die USB Spec. Eigentlich müsste es eine Datenleitung mit 1,5 jOhm auf 3,3 Volt ziehen. Stattdessen zieht es den Pin mit 10k Ohm auf 5 Volt.
nö passt das hatte ich übersehen sorry. Also aus diesem MAple Dingsbum
kann nie ein VCP (CDC) werden da nur DFU Deskriptoren da sind. Mich
würde ja mal interessieren was du an der Install_drivers,bat
umgeschrieben hast.
Leider gar nichts. So heruntergeladen und ausgeführt (admin) :-)))
Das Bluepill Board hält sich nicht richtig an die USB Spec. Eigentlich
müsste es eine Datenleitung mit 1,5 jOhm auf 3,3 Volt ziehen.
Stattdessen zieht es den Pin mit 10k Ohm auf 5 Volt.
Das ist ja auch zum Teil bekannt, dass ein falscher Widerstand bestückt wurde. Ich werde jetzt nochmal ein weiteres Board kaufen und ansonsten das eine Laufende Board nehmen und hier die Controller tauschen. Dann weiß ich auf jeden Fall, dass es am uC liegt und nicht am Board selbst
müsste es eine Datenleitung mit 1,5 jOhm auf 3,3 Volt ziehen.
Stattdessen zieht es den Pin mit 10k Ohm auf 5 Volt.
Es sollten 1.5K .. 1.8k von D+ nach VBus sein. Das ist hier aber sicher nicht das Problem weil die Enum ja funktioniert.
Der Usb Anschluss der BP Boards war vermutlich ursprünglich nur zur Stromversorgung gedacht. Dann wären auch 10k ok und beim Anstecken eines leeren BP erscheint kein unbekanntes Gerät. Für USB Funktionalität muss bei solchen boards dann etwa 2.7k von D+ nach VBus parallel geschaltet werden.
Wenn es so ist dass das Problem nur bei W10 32Bit auftritt sind die die Driver Installer das Problem. Ich hab mir die Sachen von Roger Clark jetzt mal näher angesehen. Sein Bootloader meldet sich mit 2 verschiedenen IDs an.
Das ist zum einen der DFU mode der lt Stefan nach einiger Zeit verschwindet und durch den Comport ersetzt wird. Man sollte also 2 DingDongs hören.
Roger benutzt dieses libwdi zum installieren was ähnlich wie zadig keine infs für die Treiber braucht.
Aus dem log von Klaus geht hervor das die upload.bat versucht via DTR Pulse das BP Board in den DFU Mode zu setzen (Reset?) was wohl nicht gelingt. Das könnte man mal mit HTerm versuchen zu simulieren.
sagt, meine Boards verhalten sich wie Original STM-Teile. Sowas ist ja leicht im Voraus zu testen, wenn man Blindflug nicht mag. Es scheint also nicht nur Fälschungen zu geben.
Meine Neugier hat mir keine Ruhe gelassen und ich habe die neuere Boardverwalterdatei in der Arduino-IDE ausprobiert und noch ein paar Experimente gemacht.
Damit scheint die Sachlage für mich geklärt zu sein: Das Problem liegt aus meiner Sicht darin, daß die Dateien für den HID-Bootloader immer gleich heißen und die Versionsnummer daraus nicht ersichtlich ist, man muß also genau schauen, aus welchem Unterverzeichnis man die Dateien holt. Die älteren Versionen laufen nur mit der Boardverwalterdatei von Dan Drown und brauchen einen Windowstreiber (der wohl nur im 64-bit-Windows richtig arbeitet), so wie ich es bisher gemacht habe.
Die neueren Versionen 2.2.1 und 2.2.2 brauchen dagegen zwingend die Boardverwalterdatei von github und arbeiten mit dem im Windows vorhandenen generischen Treiber. Wenn man in den Werkzeug-Einstellungen den UART über USB aktiviert, muß man nach dem ersten Flashen den zusätzlich auftauchenden COMport in den Einstellungen auch noch anwählen, dann läufts wie geschmiert.
Wenn man in den Werkzeug-Einstellungen
den UART über USB aktiviert, muß man nach dem ersten Flashen den
zusätzlich auftauchenden COMport in den Einstellungen auch noch
anwählen, dann läufts wie geschmiert.
Nice das klingt super. Bei mir finde ich das noch nicht so ganz. Kannst du mir hier ggf noch ein paar Bilder zeigen wie das bei dir aussieht
Danke
Ich habe mittlerweile auch Einiges probiert. Es scheint auf jedem Fall nicht am PC zu liegen sondern, wenn einmal der STM nicht läuft, an jedem Rechner das Problem zu sein. Mein Funktionierender STM geht jetzt überall.
Ein ST-Link den ich mit jetzt nochmal besorgt habe geht jedenfalls, war aber nicht meine Hoffnung, sondern die USB-Schnittstelle vom STM selbst.
Als PC-System hab ich Win64. Hoffe also ich finde ebenfalls die Einstellung wie sie Klaus S. beschrieben hat :)
Nice das klingt super. Bei mir finde ich das noch nicht so ganz. Kannst
du mir hier ggf noch ein paar Bilder zeigen wie das bei dir aussieht
Danke
Könnte ich machen, es muß mir aber einleuchten, wozu das gut sein sollte.
Ich bin nicht so der Bilder-Typ, ich kriegs zwar hin, es macht mir aber Mühe.
Der Schlüssel zur Lösung des Problems scheint mir aber nicht weiteres Rumprobieren zu sein, sondern ein genauer Ablauf Schritt für Schritt, bei dem man bei jedenm Schritt auch versteht, warum er funktionieren sollte.
Als PC-System hab ich Win64.
Könntest Du dazu noch angeben, mit welcher Software Du die blauen Pillen programmierst? Also beispielsweise welche Arduinoversion und welche Boardverwalterdatei Du verwendest?
Könntest Du dazu noch angeben, mit welcher Software Du die blauen Pillen
programmierst? Also beispielsweise welche Arduinoversion und welche
Boardverwalterdatei Du verwendest?
STM: STM32F103C6T6A STM32F103C8T6
Program Memory Size: 32 kB 64 kB
Data RAM Size: 10 kB 20 kB
Interface Type: I2C, SPI, USART CAN, I2C, SPI, USART, USB
Einmal ist der Ram / Memory größer. Zum Anderen, hat aber der C6T6 kein USB Interface. Somit sind die zu kaufenden Controller auf dem Dev-Board zwar identisch und auch beide mit USB ausgestattet, nur das der eine nicht USB kompatibel ist. Das würde auch erklären, warum dieser nur als Mappel-USB angezeigt wird.Ich habe jetzt mal fix den c8T6 bestellt und probiers hiermit mal.
Hi, check carefully your uC, it might be CBT6, not C8T6. Check memory with CubeProgrammer, if it show you 128k, then it will be CBT6! I face the same problem.
Hi, check carefully your uC, it might be CBT6, not C8T6. Check memory
with CubeProgrammer, if it show you 128k, then it will be CBT6! I face
the same problem.
That cannot be the problem cause. Both a binary and pin compatible. If the firmware fits into the flash memory, then it will work. The cube programmer displays an error message if the memory is too small.
Hi, I check my fake bluepill (CBT6, instead C8T6) with simple Arduino program to print on COM something and I get nothing. Then I try with working program in Atollic but debugger was stuck. Changing the type of uC solved the problem (almost). When I said to check memory, was to verify that is a genuine C8T6 and not an fake (CBT6). One hour i test the fake bluepill to figure out that is core of CBT6 in body of C8T6.
You have to change the model of uC in CubeIDE. Cube programmer show you what model of uC is connected via stlink,on the lower right corner. Sorry, i cannot show you how to do, i am on vacation.
