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 ? Anleitungen habe ich viele probiert, aber bei allen ist es eigentlich immer Gleich, nach dem Brennen des Bootloaders meldet sich der STM automatisch als Com-Port an… https://www.electrosoftcloud.com/en/stm32f103-bootloader-and-programming/ 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.
:
Bearbeitet durch User
S. M. schrieb: > 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). Das sind jetzt 4 verschiedene Möglichkeiten.
Das klingt super, Danke Klaus. 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
:
Bearbeitet durch User
S. M. schrieb: > 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 Dort downloadbar: https://github.com/rogerclarkmelbourne/Arduino_STM32/archive/master.zip
S. M. schrieb: > 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. Steve van de Grens schrieb: > 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? Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > 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.
Harald K. schrieb: > das ist entweder CDC 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.
Klaus S. schrieb: > 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.
Thomas Z. schrieb: > winusb nicht libusb. ist aber in der Praxis .... 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. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Sehe ich das falsch? im wesentlichen richtig. 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.
Klaus S. schrieb: > das ist mal handfeste Information 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.
Klaus S. schrieb: > 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? Unter neuerem Windows: Genau so ist es. Klaus S. schrieb: > daß ich ständig nicht mehr benötigte Treiber > deinstallieren muß, damit ich nicht bei COM45 lande. Hier ist https://www.uwe-sieber.de/misc_tools.html#arbiter sehr hilfreich. Klaus S. schrieb: > Manche Programme, > die ich gern nutze, sind nach oben begrenzt und erlauben nur bis COM6 > oder COM20 Dann sind die sehr, sehr schlecht programmiert. Daß serielle Schnittstellen unter Windows bis \\.\COM256 heißen können, ist seit 1993 bekannt.
Klaus S. schrieb: > 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. Ich habe das nur mal kurz ausprobiert, war aber insgesamt nicht begeistert. Mehr als auf http://stefanfrings.de/stm32/stm32f1.html#arduino weis ich dazu auch nicht.
Klaus S. schrieb: > 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.
Thomas Z. schrieb: > 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. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > und bei MSD passen muß Mass Storage Device, wie USB-Stick oder -Festplatte. Klaus S. schrieb: > Könnte es sich um SDKs handeln? Als "DDK" wird das Driver Development Kit von Microsoft bezeichnet, das man benötigt, wenn man für Windows Devicetreiber programmieren will. Glaub' mir: Das willst Du nicht. Ganz sicher nicht. Klaus S. schrieb: > 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.
Klaus S. schrieb: > Ist für mich schon schwer verständlich 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)
Thomas Z. schrieb: > 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. Eine ausführlichere Auflistung gibts hier: https://en.wikipedia.org/wiki/USB#Device_classes 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.
Steve van de Grens schrieb: > 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. Gruß Klaus (der soundsovielte)
Harald K. schrieb: > Das ist sehr grob vereinfacht. 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.
Steve van de Grens schrieb: > 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.
Klaus S. schrieb: > Hättest Du einen Tipp für mich, wo USB für einen Menschen mit solider > Halbbildung erklärt wird? https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32
Klaus S. schrieb: > 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. Ja, so ist das. Alles ziemlich unhandlich, da nehme ich lieber direkt einen ST-Link Adapter (ohne Bootloader).
Stefan F. schrieb: > https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32 Danke, der paßt gut. > 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. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Für meine eigenen Basteleien habe ich noch keinen Verwendungszweck f. > die Bluepill gefunden. Falls doch: Der Pin-kompatible STM32F303 hat einen fest installierten USB Bootloader.
Klaus S. schrieb: > 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
Klaus S. schrieb: > 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. Ich hoffe es war der hier gemeint https://sourceforge.net/p/stm32flash/wiki/Home/ Leider bekomme ich dieses nichr auf meinen Win-pc zum laufen
S. M. schrieb: > Leider bekomme ich dieses nichr auf meinen Win-pc zum laufen Gibt es eine Fehlermeldung? Was exakt hast Du versucht? Hast Du das Binary runtergeladen, oder versuchst Du die Sourcen selbst zu übersetzen?
Harald K. schrieb: > 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
:
Bearbeitet durch User
S. M. schrieb: > Hier öffnet und schließt sich das Fester sofort, ohne etwas erkennen zu > können. Das ist ein Kommandozeilenprogramm.
Angehängte Dateien:
-
B1.JPG
44 KB
Harald K. schrieb: > Das ist ein Kommandozeilenprogramm. 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
S. M. schrieb: > ttyS0 durch meine Schnitstelle vom STM ersetz wird. Das braucht eine serielle Schnittstelle. Hat Dein "Maple DFU" eine?
Harald K. schrieb: > Das braucht eine serielle Schnittstelle. Hat Dein "Maple DFU" eine? Es wird keine in Windws angezeigt
S. M. schrieb: > Ich hoffe es war der hier gemeint > https://sourceforge.net/p/stm32flash/wiki/Home/ > > 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. Gruß Klaus (der soundsovielte)
jetzt zeige halt mal den kompletten Deskriptor Baum für deine beiden Devices --> Ausgabe von UsbTreeView https://www.uwe-sieber.de/usbtreeview_e.html dann sehen wir weiter
S. M. schrieb: > 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)
S. M. schrieb: > wobei ttyS0 durch meine Schnitstelle vom STM ersetz wird. Nur weche ist > das.. Bei Windows ist das mal wieder so versteckt zu finden Stecke das Gerät an, während du im Gerätemanager beobachtest, welcher COM Port bein Anstecken des USB Kabels dazu kommt. Der serielle Bootloader erforder die Verwendung eines USB-UART Adapters. Ich habe das alles auf meiner Homepage dokumentiert. http://stefanfrings.de/stm32
Harald K. schrieb: > 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.
Stefan F. schrieb: > Typisch klickibunti User. > > Das Programm muss mit Parametern aufgerufen werden, also in der cmd > Shell (Eingabeaufforderung) Hab das übersehen und korrigiert ! S. M. schrieb: > Ah mist.. mein Fehler. War auf die exe zu sehr fixier und hab das > übersehen. Stefan F. schrieb: > Stecke das Gerät an, während du im Gerätemanager beobachtest, welcher > COM Port bein Anstecken des USB Kabels dazu kommt. Bereits ganz oben erläuter was passiert wenn ich den STM anschließe. siehe hier: S. M. schrieb: > 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 Stefan F. schrieb: > 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
:
Bearbeitet durch User
Thomas Z. schrieb: > jetzt zeige halt mal den kompletten Deskriptor Baum für deine beiden > Devices --> Ausgabe von UsbTreeView Harald und Stefan scheinen den Thread nur teilweise gelesen zu haben und müssen erstmal auf den momentanen Stand des Wissens kommen, das kann dauern. Ich mach das Ganze bei mir parallel und probier Deinen Vorchlag aus. Gruß Klaus (der soundsovielte)
Angehängte Dateien:
-
Tree1.PNG
21 KB
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. Gruß Klaus (der soundsovielte)
Angehängte Dateien:
-
C1.JPG
180 KB
Klaus S. schrieb: > 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 :)
:
Bearbeitet durch User
Klaus S. schrieb: > 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...
Thomas Z. schrieb: > UsbTreeView von Sieber https://www.uwe-sieber.de/usbtreeview.html den hab ich genommen
S. M. schrieb: > Leider nicht Port 7 & 15 sind NC das war auch nicht für dich gedacht sondern für Klaus. Du hast ein vollkommen Spec konformes DFU Device du hast leider im PNG die DriverInfo verdeckt. Du solltest jetzt noch den Tree für dein Comport Blupill Device zeigen dann kann man googlen.
Thomas Z. schrieb: > U Device du hast leider im PNG die > DriverInfo verdeckt. Sind im Textdokument oder war da noch mehr
S. M. schrieb: > Sind im Textdokument oder war da noch mehr 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.
S. M. schrieb: > Kannst du nicht sonst kurz erklären wie ich den STM-Flashen muss bzw was > ich in Windows ändern muss damit es läuft. Lies einfach meine Homepage. Ich werde hier nicht für dich persönlich einen extra Aufsatz schreiben.
Angehängte Dateien:
-
GM1.PNG
26 KB
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 :-)))
Angehängte Dateien:
-
Tree4.PNG
61 KB
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. Gruß Klaus (der soundsovielte)
Angehängte Dateien:
-
USBtree32.PNG
56 KB
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.
Thomas Z. schrieb: > 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) :-)))
Ich überlege langsam, ob nicht einfach das Board einen Fehler hat und der Controller so läuft wie es sein sollte. Stefan F. schrieb: > 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
Stefan F. schrieb: > 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. gerade gefunden: 2) It allows the host PC to issue a system reset into the DFU bootloader with the DTR + RTS + "1EAF" sequence (see leaflabs.com/docs/bootloader.html for more information on this). mit dieser Sequenz schaltet Clark von COM-> DFU um. https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/STM32F1/cores/maple/libmaple/usb im Readme
:
Bearbeitet durch User
Stefan F. schrieb: > Stattdessen zieht es den Pin mit 10k Ohm auf 5 Volt. Meine Boards von "Komputer.de" haben 1K5 korrekt drauf. Und die Bluepill-Diagnostic von https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diags-v1.640.html 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. Gruß Klaus (der soundsovielte) P.S. Alle meine Tests in der Arduino-IDE wurden mit der Boardverwalterdatei http://dan.drown.org/stm32duino/package_STM32duino_index.json gemacht. Es gibt noch die konkurrierende Variante https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json die aber nur zum Up/Download mit dem CubeProgrammer von STM arbeitet. Den muß ich mir jetzt aber nicht auch noch antun, ich bekomme schon so mehr Spam von STM, als mir lieb ist. Für unerschrockene STM-Fans wäre das aber noch eine zusätzliche Testmöglichkeit-
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. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > 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 :)
:
Bearbeitet durch User
S. M. schrieb: > 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? Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Könntest Du dazu noch angeben, mit welcher Software Du die blauen Pillen > programmierst? Also beispielsweise welche Arduinoversion und welche > Boardverwalterdatei Du verwendest? Moin selbe Boardverwalterdatei wie bei dir > http://dan.drown.org/stm32duino/package_STM32duino_index.json Als Softwarenutze ich ebenfalls Arduino: Version 1.8.19
Ich glaube ich habe das USB Problem gefunden 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.
:
Bearbeitet durch User
Wo hast du diese Info gefunden? Laut Datenblatt hat der STM32F103x6 ein USB 2.0 Interface. Ohne dieses würde der Maple Bootloader nicht funktionieren. https://www.st.com/resource/en/datasheet/stm32f103c4.pdf
Beitrag #7446492 wurde vom Autor gelöscht.
Stefan F. schrieb: > Wo hast du diese Info gefunden? wenn ich bei Mouser den STM bestellen wollte und die Chips vergleiche. Hier mal der Vergleich als Anhang bei Mouser
S. M. schrieb: > Hier mal der Vergleich als Anhang bei Mouser Was spricht dagegen, sich die Beschreibung beim Hersteller anzusehen? Der müsste das deutlich besser wissen.
Naja, ich hätte auch der Beschreibung von Mouser vertraut, wenn ich es nicht vorher anders im DB gelesen hätte.
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.
Cristi P. schrieb: > 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.
:
Bearbeitet durch User
Cristi P. schrieb: > Changing the type of uC solved the problem Good to know. One detail question: Where did you change set setting (STM32F103C8T6 -> STM32F103CBT6), only in the Cube Programmer or also in the Cube IDE to compile it differently?
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.
:
Bearbeitet durch User
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.