Announcement: there is an English version of this forum on Hallo Leute, ich habe ein STM32-basiertes Gerät, mit dem ich es nicht schaffe, eine serielle Verbindung per FTDI aufzubauen. Kurzversion: > Ich habe einen (FTDI-Adapter FT232RL), der laut Prüfschleifen-Test (TX zu RX, siehe z.B. https://www.youtube.com/watch?v=4rYHHLNufb0) funktioniert. > Dann verbinde ich den FTDI-Adapter mit dem seriellen Gerät: RX an TX, TX an RX und GND an GND. > Das serielle Gerät sollte eigentlich per spezieller Software (ST Flash Bootloader Demonstrator) geflasht werden, die Software zeigt aber nur eine unspezifische Fehlermeldung (siehe unten). > Daher habe ich die Verbindung mit Putty versucht. Der "AT"-Befehl liefert kein "OK" zurück. Ich bin neu in dem Thema serielle Kommunikation. Wie läuft Fehlersuche bei seriellen Schnittstellen? Wo würdet Ihr anfangen? Langversion: Das DSO138 ist ein "Spielzeug-Oszi", das auf dem STM32 basiert. Ich habe einen Clon davon (ich denke die originalen gibt es nicht mehr): https://www.amazon.de/ARCELI-Digitaloszilloskop-Kit-Taschenformat-4-Zoll-TFT-zusammengebaute/dp/B07V67LYXF/ref=cm_cr_arp_d_product_top?ie=UTF8 Auf dem ist nicht die Standardsoftware installiert, und die installierte SW nervt mich. Ich will also die Originalsoftware flashen. Zum Flashen gehe ich nach der Anleitung des Herstellers vor: https://jyetech.com/wp-content/uploads/2018/07/dso138-firmware-upgrade.pdf Die beiden Jumper sind zugelötet, 9V-Block ist verbunden, der Bildschirm bleibt weiß wie es sein soll, RX&TX sind über Kreuz verbunden und GND gerade. Windows zeigt den FTDI-Adapter als "USB Serial Port (COM4)", wie es sein soll. Wenn ich den ST Flash Bootloader Demonstrator starten will mit den Parametern: > Port Name COM4 (wie im Gerägemanager) > Baud Rate 115200 > Parity Even > Echo Disabled > Timeout 5 kommt nach ein paar Sekunden die Fehlermeldung No response from the target, the Boot loader can not be started. Please, verify the boot mode configuration and the flash protection status, Reset your device then try again... Ich habe es auch mit dem neueren STM32 CubeProgrammer versucht, da ist die Ausgabe des Logs: > 11:03:07 : Serial Port COM4 is successfully opened. > 11:03:07 : Port configuration: parity = even, baudrate = 115200, data-bit = 8, stop-bit = 1.0, flow-control = off > 11:03:09 : Timeout error occured while waiting for acknowledgement. > 11:03:09 : Timeout error occured while waiting for acknowledgement. > 11:03:09 : Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again... Was sind meine Optionen? Nur aufgeben, oder kann man was anderes schlaues machen? Vielen Dank im Voraus!
Infos zum seriellen Bootloader: http://www.st.com/resource/en/application_note/cd00167594.pdf http://www.st.com/resource/en/application_note/cd00264342.pdf Du musst dazu schon die Software von ST benutzen. "AT" Befehle bringen dir dort gar nichts, das ist schließlich kein Modem. Du könntest mal eine niedrigere Baudrate versuchen. Oder andere Software: STM32 Cube Programmer. Damit der Bootloader funktioniert, sind nur wenige Voraussetzungen nötig: - Stromversorgung muss anliegen - Der Boot0 Pin muss auf HIGH liegen - Der Boot1 Pin muss auf LOW liegen Das war's schon. Der Chip braucht nicht einmal ein externes Reset Signal oder Takt. Ich fürchte, dass deine 9V Block Batterie zu schwach ist. Für mehr als 100mA eignen sich diese Batterien selten. Bedenke dabei, dass die Platine in Aktion zeitweise mehr Strom aufnimmt, als in Ruhelage. Vielleicht sind Rx/Tx vertauscht beschriftet. Das kannst du ja leicht im getrennten Zustand testen. Der Tx Ausgang beider Seiten liefert in Ruhelage einen High Pegel. Eine LED mit Vorwiderstand sollte daran leuchten. Die seriellen Leitungen müssen über Kreuz verbunden werden: Tx Ausgang -----> Rx Eingang Rx Eingang <----- Tx Ausgang GND -------------------- GND
:
Bearbeitet durch User
Danke. Zitat aus Deinem Link: > Um den Bootloader zu aktivieren, setzt man den Pin Boot0=High, Boot1=Low und dann drückt man den Reset Knopf. Also hier ist der Schaltplan: https://www.jyetech.com/Products/LcdScope/Schematic_Shell.pdf > Jumper 1 ist zugelötet, das setzt Boot0 auf 3,3V > Boot1 ist im Schaltplan nicht verbunden, ich hoffe, dass er dann 0 ist? > Außerden soll Jumper 2 zugelötet werden, das setzt DB2/PB2 auf Ground. Ist der zufällig intern mit Boot1 verbunden? > Einen Reset-Knopf gibt es rausgeführt, auf der Platine markiert mit SW8, den finde ich im Schaltplan aber nicht. Vielleicht ist der Plan nicht vollständig, oder ich bin blind.
Stefan ⛄ F. schrieb: > Du könntest mal eine niedrigere Baudrate versuchen. Oder andere > Software: STM32 Cube Programmer. Niedrigere Baudrate hatte ich schon versucht. Die Ausgabe vom STM32 Cube Programmer ist im Originalpost ganz unten angehängt, hatte ich also auch schon versucht. > Ich fürchte, dass deine 9V Block Batterie zu schwach ist. Oh, ich hab sie gerade mal nachgemessen, 7,7V... Okay, ich organisier ein Netzteil. Danke für den Tipp!
Stefan ⛄ F. schrieb: > Ich fürchte, dass deine 9V Block Batterie zu schwach ist. Für > mehr als 100mA eignen sich diese Batterien selten. Bedenke dabei, dass > die Platine in Aktion zeitweise mehr Strom aufnimmt, als in Ruhelage. Also das war es leider auch nicht. Mit Netzteil ist das gleiche Verhalten wie vorher mit Batterie. > Vielleicht sind Rx/Tx vertauscht beschriftet. Das kannst du ja leicht im > getrennten Zustand testen. Der Tx Ausgang beider Seiten liefert in > Ruhelage einen High Pegel. Also TX ist bei 3,3V und RX ist bei GND. > Die seriellen Leitungen müssen über Kreuz verbunden werden: > > Tx Ausgang -----> Rx Eingang > Rx Eingang <----- Tx Ausgang > GND -------------------- GND Ist geschehen. Ich hatte auch schon mehrmals versucht, zu überkreuzen, einfach nur um zu sehen...
Daniel B. schrieb: > Zitat aus Deinem Link: > >> Um den Bootloader zu aktivieren, setzt man den Pin Boot0=High, >> Boot1=Low und dann drückt man den Reset Knopf. Eigentlich wollte ich nicht auf meine Homepage verweisen, sondern den Link auf die Application Note von dort kopieren. Habe ich inzwischen korrigiert. > Ist der zufällig intern mit Boot1 verbunden? Ja richtig. Ich habe mir die Anleitung angeschaut, sieht alles stimmig aus. Es geht auch ohne Reset-Knopf, dann muss man halt die Batterie nach dem Löten der Brücken anklemmen. Hast du sicher auch so gemacht, denke ich mal. Habe deine weiteren Antworten gelesen. Nun weiß ich auch nicht mehr weiter.
Stefan ⛄ F. schrieb: > Habe deine weiteren Antworten gelesen. Nun weiß ich auch nicht mehr > weiter. Okay, dann heißt das für mich, dass ich zumindest nicht irgendeinen ganz dummen Anfängerfehler mache. Danke!
Daniel B. schrieb: > Okay, dann heißt das für mich, dass ich zumindest nicht irgendeinen ganz > dummen Anfängerfehler mache. Ja denke ich schon. Aber es nicht, dass der Fall hoffnungslos ist. Hier gibt es andere, die sich damit viel besser auskennen. Warte einfach mal eine Weile ab.
Bei der derzeitigen Knappheit würde es mich nicht überraschen, wenn da gar kein STM32F103 drin ist, sondern irgendein "Klon". Der hat wiederum vielleicht gar keinen Booloader oder zumindest einen, der anders arbeitet ... Foto vom uC?
Angehängte Dateien:
-
20220527_091156_1_.jpg
240 KB
Naja, das ganze Ding ist ein chinesisches Design; es würde mich nicht wundern, wenn das originale DSO138 schon einen falschen Chip draufgehabt hätte. Deine Vermutung ist korrekt. Ich lese auf dem Chip: CH32F103 C8T6 401539B19 Gibts da irgendwo eine Info über den Bootloader von speziell diesem Chip? Ich hab ehrlich gesagt gedacht, dass STM32-Chips normalerweise gar keinen Bootloader haben, weswegen man ja sonst immer den ST-Link benutzt. Beim DSO138 soll man aber nach Anleitung explizit den UART benutzen. Ich hatte trotzdem schon mal den ST-Link versucht, aber damit auch keinen Erfolg gehabt (hab aber auch nicht ewig probiert).
Daniel B. schrieb: > CH32F103 :-) - https://hackaday.com/2020/10/22/stm32-clones-the-good-the-bad-and-the-ugly/
Daniel B. schrieb: > Ich bin neu in dem Thema serielle Kommunikation. Wie läuft Fehlersuche > bei seriellen Schnittstellen? Wo würdet Ihr anfangen? Tja, bei dem Zeugs von ST kriegt man nach einer gewissen Denkpause eben immer nur "es geht nicht". Ich hab vor geraumer Zeit hier mal ein Programmierprogramm für die STM32 gepostet, das hat Testroutinen drin für Reset und Boot und sollte eigentlich geeignet sein, dir weiterzuhelfen. Suche einfach mal nach STM32Prog oder Bootlader Programmer. W.S.
Hast du es inzwischen geschafft, eine neue Software aufzuspielen? Ich stehe aktuell vor dem gleichen Problem
Daniel B. schrieb: > kann man was anderes schlaues machen? Verwende am Zeilenanfang keine '>', denn damit werden hier im Forum Zitate aus anderen Posts gekennzeichnet. Nimm irgend ein anderes Aufzählungszeichen.
:
Bearbeitet durch Moderator
Marco schrieb: > Ich stehe aktuell vor dem gleichen Problem Da der Thread schon etwas älter ist, wird nicht unbedingt eine Antwort vom TO kommen. Mich interessiert der Thread insofern, als ich UART-Bootloader für die einfachste Methode halte, einem uC ein Programm zu verpassen. Ich staune aber immer wieder, warum Menschen daran scheitern. Ich führe sozusagen eine Liste der häufigsten Fehler dabei. Gruß Klaus (der soundsovielte)
Es könnte auch dies sein: A. B, schrieb: > Bei der derzeitigen Knappheit würde es mich nicht überraschen, > wenn da gar kein STM32F103 drin ist, sondern irgendein "Klon". > Der hat wiederum vielleicht gar keinen Booloader Ich habe vor 2 Jahren schon ein paar Berichte über gefälschte STM32F103 ohne UART Bootloader gelesen.
Marco schrieb: > Hast du es inzwischen geschafft, eine neue Software aufzuspielen? Nö, ich habe es aufgegeben. In diesem Post hier Beitrag "[PlatformIO] Stm32 lässt sich nicht flashen" wird gesagt, dass im stm32f1xx.cfg-File die ID auf "set CPUTAPID 0x2ba01477" gesetzt werden soll, aber in der Anleitung zum Firmware-Update von jyetech https://jyetech.com/wp-content/uploads/2018/07/dso138-firmware-upgrade.pdf wird diese Datei gar nicht verwendet; da gibt es nur ein hex-File. Der Tipp bezieht sich wohl ausschließlich auf die Programmierung mit Aruino IDE oder Platformio.
Klaus S. schrieb: > Marco schrieb: >> Ich stehe aktuell vor dem gleichen Problem > > Da der Thread schon etwas älter ist, wird nicht unbedingt eine Antwort > vom TO kommen. Mich interessiert der Thread insofern, als ich > UART-Bootloader für die einfachste Methode halte, einem uC ein Programm > zu verpassen. Ich staune aber immer wieder, warum Menschen daran > scheitern. Ich führe sozusagen eine Liste der häufigsten Fehler dabei. > > Gruß Klaus (der soundsovielte) Wolltest Du jetzt mit irgendwas helfen, oder nur zum Besten geben, dass Du denkst Du seist schlauer als andere? Wenn Du glaubst Du weißt wie es geht, dann mach doch mal einen Vorschlag, was wir noch probieren könnten.
Daniel B. schrieb: > Wolltest Du jetzt mit irgendwas helfen, oder nur zum Besten geben, dass > Du denkst Du seist schlauer als andere? Wenn Du glaubst Du weißt wie es > geht, dann mach doch mal einen Vorschlag, was wir noch probieren > könnten. Danke für die freundliche Begrüßung. Da Du Dich seit Mai nicht mehr weiter gemeldet hast, wollte ich eigentlich nur Marco helfen. Ich bin im Übrigen nicht schlauer als Andere, nur oft hartnäckiger. Und das ist für den UART-Betrieb eine wichtige Eigenschaft. Rumprobieren bringt da eben nur selten was. Da habe ich auch nichts vorzuschlagen. Fürs Fummeln sind Andere zuständig. Mein Vorgehen ist eher technisch begründet. Wenn man nach und nach alles der Reihe nach abklappert und nachprüft, findet man irgendwann den Fehler. Ob man ihn dann beheben kann, ist eine andere Frage. Mich interessiert einfach, ob der betreffende STM-Kompatible nun einen UART-Bootloader hat oder nicht. Und da ist die aus meiner Sicht empfehlenswerte Methode, den uC in den Bootloadermodus zu versetzen und mit dem STM32Flasher von Roger Clarke oder dem Delphiprogramm von W.S. Kontakt aufzunehmen, da das Tool von ST selber keinen guten Ruf hat. Ich habe das Programm von W.S. ausprobiert, aber den STM32F103 nicht darin gefunden. Deshalb habe ich das Programm von Roger Clarke benutzt und das funktionierte. Ich hatte die alte Version 4.0 benutzt, die in der Arduinoversion für die BluePill enthalten ist (Version von Dan Drown). Man kann das Programm aber auch separat herunterladen. Gruß Klaus (der soundsovielte)
Okay, das kann ich als konstruktiven Vorschlag sehen. Leider ist das Programm STM32duino, auf das du dich denke ich beziehst https://github.com/rogerclarkmelbourne/STM32duino-bootloader für die Verbindung über ST-Link gedacht. Das Design des DSO138 ist aber so, dass die Verbindung über ST-Link nicht funktioniert, das habe ich schon probiert. Ich habe auch online niemanden gefunden, der das beim DSO138 geschafft hätte. Ich behaupte sogar, wenn es gehen würde, hätte der Hersteller nicht diesen komischen Weg über den uralten Flash Bootloader Demonstrator gewählt; Programmierung über Arduino IDE wäre für das Ding eigentlich perfekt gewesen. Aber vielleicht kriegt es ja jemand mit mehr Ahnung als ich doch hin?
Daniel B. schrieb: > Aber vielleicht kriegt es ja jemand mit mehr Ahnung als ich doch hin? Nicht verzagen, uC-Net fragen! Für STM32 gibt es mehrere Arduino-Konfigurationen. Den Zugang zum UART-Bootloader enthält nach meinem Wissensstand nur die JSON-Datei von Dan Drown, alle Anderen nicht.Mein Hinweis darauf war wohl nicht dick genug geschrieben. Hier der Link: http://dan.drown.org/stm32duino/package_STM32duino_index.json Hinweis zu den darin enthaltenen und manchmal auftretenden Fehler (Race condition) unter Beitrag "Arduino IDE überholt sich selbst" Gruß Klaus (der soundsovielte)
Der STM32duino Bootloader ist ein Stück Firmware dass man in den Flash des Mikrocontrollers laden kann, um ihn danach über USB zu flashen. Ich denke, der hat mit dieser Diskussion hier nichts zu tun. Hier geht es um den seriellen Bootloader, mit dem der Chip ausgeliefert wird, den man weder ändern noch löschen kann. Dann gibt es noch die Programmierung über SWD, welche nach meinem Kenntnisstand eine Funktion des ARM Kerns ist und ebenfalls weder geändert noch gelöscht werden kann. Die SWD Schnittstelle kann jedoch durch das laufende Programm auf dem µC deaktiviert werden, was sowohl Arduino als auch Cube MX standardmäßig tun. Die SWD Schnittstelle ist allerdings während des Reset ansprechbar. Der Flash Loader Demonstrator ist ein altes Programm von ST zum Flashen anderer STM32 Modelle, deren fest installierter Bootloader auch USB unterstützt. Das Protokoll dazu nennt ST "DFU". Der STM32F103 hat diese Funktion nicht, wohl aber die STM32F105 und F107. Was man dazu vielleicht noch wissen sollte: Ursprünglich gab es das "Maple" Projekt, zusätzlich zum fest installierten Bootloader einen zweiten Bootloader in den Flash Speicher packte, damit man die STM32F103 doch per USB programmieren konnte. Dieser Bootloader spricht ein anderes Protokoll, das nur so ähnlich wie DFU funktioniert. Es sind allerdings Kommandozeilentools im Umlauf, die sowohl das originale DFU Protokoll als auch das Maple Protokoll unterstützen. Roger Clark hat darauf aufgebaut und diesen Bootloader im Rahmen seines "STM32duino" Projektes weiter verwendet. Um das zugehörige PC Programm hat er sich nicht gekümmert, so dass man bei STM32duino die PC Software vom Maple Projekt nutzen musste. Dann hat ST das STM32duino Projekt übernommen und auf Cube HAL umgebaut. Das was wir heute unter dem Namen STM32duino kennen ist Welten von Roger Clarks Projekt entfernt. ST setzt auch nicht mehr auf diesen alternativen Maple Bootloader, sondern auf das was die Chips ab Werk mit sich bringen. Im Fall des STM32F103 ist das der serielle Bootloader und SWD (kein USB). Die aktuelle Software zum Ansprechen sämtlicher Bootloader von ST heißt "STM32 Cube Programmer". Dessen Installationspaket enthält auch ein Kommandozeilentool. Die älteren Programme von ST wurden ein paar Jahre parallel dazu gepflegt, sind inzwischen aber deprecated. Seid also bitte vorsichtig, wenn ihr Infos zu STM32duino oder dem Bootloader sucht. Da gibt unterschiedliche Produkte mit gleichen und ähnlichen Namen, die aber nicht gleich funktionieren.
:
Bearbeitet durch User
Stefan F. schrieb: > ST setzt auch nicht mehr auf diesen > alternativen Maple Bootloader, sondern auf das was die Chips ab Werk mit > sich bringen. Im Fall des STM32F103 ist das der serielle Bootloader und > SWD (kein USB). Danke für die ausführliche Übersicht und das Update meines Wissensstandes. Ich hatte die mögliche Benutzung des Cube-MX völlig vergessen, da sie mir zu umständlich war ("lazyness rules" bei Minimalisten wie mir). Es wäre also auch noch eine Option für den TO, Cube-MX zusätzlich zu installieren und die von ST unterstützte Version der JSON-Datei zu benutzen. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Es wäre also auch noch eine Option für den TO, Cube-MX zusätzlich zu > installieren und die von ST unterstützte Version der JSON-Datei zu > benutzen. Mit Cube MX kann man keine Firmware flashen. Cube MX generiert Quelltext. Zum Flashen braucht man (wenn schon) den STM32 Cube Programmer. Ich benutze dieses Programm mit dem seriellen Bootloader: https://sourceforge.net/projects/stm32flash/files/ Es hat ein paar nette Kommandozeilenparameter mit denen man die Chip ID und die Speichergröße ignorieren kann. Damit kann man die vollen 128 kB der STM32F103C8 nutzen (offiziell haben sie nur 64 kB).
:
Bearbeitet durch User
Stefan F. schrieb: > Mit Cube MX kann man keine Firmware flashen. Cube MX generiert > Quelltext. Zum Flashen braucht man (wenn schon) den STM32 Cube > Programmer. Ich habe gerade keinen Zugriff auf meine Arduino-Installationen, muß deswegen auf meine Erinnerung zurückgreifen. Als wir beide vor einiger Zeit in einem anderen Thread zu helfen versuchten, habe ich zwei verschiedene Arduinoinstallationen ausprobiert, einmal die Version von Dan Drown (die ich auch für mich benutze) und die von ST unterstützte Version. Und in der konnte man das Programm nur dann über den UART-ROMloader transferieren, wenn man noch ein zusätzliches Tool von ST installierte. In meiner Erinnerung war das Cube-MX, aber das ist dann wohl grottenfalsch. Weißt Du, ob das der von Dir genannte STM32 Cube Programmer ist? Ich fände es einfach gut, wenn man dem TO die 2 Links dazu auch auf dem Tablett servieren könnte, da er die Arduino-IDE ideal fand und nach eigener Aussage in der seriellen Kommunikation nicht so bewandert ist. Er hätte damit das, was er sich wünschte: einen Vorschlag zum Ausprobieren. Ich komme aber frühestens in 24 Sunden an die Unterlagen von damals. Gruß Klaus (der soundsovielte(
STM32CubeProg STM32CubeProgrammer software for all STM32 https://www.st.com/en/development-tools/stm32cubeprog.html
Ich hatte mich damals ja erkundigt und auch festgestellt, dass der STM32 Cube Programmer die neuere Version/Nachfolger vom Flash Bootloader Demonstrator ist, der in der Anleitung des DSO138-Herstellers benutzt wird. Deshalb hatte ich ihn auch ausprobiert, steht schon im allerersten Post. Ich konnte aber mit keinem der beiden Tools eine Verbindung zum Chip herstellen. Will heißen, ob ich den Stecker an die Platine gesteckt hatte oder nicht, die Ausgabe des Tools war immer gleich. Ich fürchte, wir kommen nicht weiter mit dem Thread, wenn nicht vielleicht noch irgendein Crack selbst ein DSO138 hat und es mal selber probiert, oder schon probiert hat.
Klaus S. schrieb: > Als wir beide vor einiger Zeit in einem anderen Thread zu helfen > versuchten, habe ich zwei verschiedene Arduinoinstallationen > ausprobiert, einmal die Version von Dan Drown (die ich auch für mich > benutze) und die von ST unterstützte Version. Dan Drown hat die Software von Roger Clarks so verpackt, dass man sie über Boardmanager der Arduino IDE installieren kann. Als Roger noch an seinem Projekt arbeitete, gab es diesen Boardmanager noch nicht, man musste die Software manuell durch Kopieren von Dateien installieren. Wenn du also von der "Version von Dan Drown" schreibst, dann ist das genau genommen die Software von Roger Clark. > Und in der (Version von ST) konnte man das Programm nur dann über > den UART-ROMloader transferieren, wenn man noch ein zusätzliches > Tool von ST installierte. Möglicherweise, so genau kann ich mich nicht erinnern. Ich habe Software von ST nur relativ kurz verwendet und dabei stets via SWD mit meinem ST-Link Adapter. > In meiner Erinnerung war das Cube-MX Wie gesagt: Du verwechselst das mit dem "STM32 Cube Programmer". Zu der Zeit als Roger Clark an diesem Projekt aktiv war, gab es noch keine Cube Programme. Klaus S. schrieb: > Ich fände es einfach gut, wenn man dem TO die 2 Links dazu auch auf dem > Tablett servieren könnte, da er die Arduino-IDE ideal fand und nach > eigener Aussage in der seriellen Kommunikation nicht so bewandert ist. Meinen kleinen historischen Exkurs fand ich noch sinnvoll um die Verwirrung bezüglich diverser STM32duino Projekte aufzuklären. Aber warum sollte er eine ganze IDE benutzen, bloß um ein Firmware File in den Mikrocontroller zu laden? Die Arduino IDE ist ebenso wie die "STM32 Cube IDE" alles andere als Ideal, um einfach nur eine Firmware im HEX Format auf den Chip zu laden. Das Programm, das ich für seriellen Transfer benutze, habe ich gerade empfohlen. Den Link zum "STM32 Cube Programmer" präsentiere ich hier absichtlich nicht, weil das Programm für den aktuellen Fall eher kontraproduktiv ist. Es verweigert die Kommunikation mit vielen gefakten STM32. Naja, jetzt hat Harry den Link gepostet. Viel Glück damit.
:
Bearbeitet durch User
Stefan F. schrieb: > Die Arduino IDE ist ebenso wie die "STM32 > Cube IDE" alles andere als Ideal, um einfach nur eine Firmware im HEX > Format auf den Chip zu laden. Es geht ja zunächst nur darum zu testen, ob der verwendete Chip überhaupt einen UART-Bootloader im ROM hat. Da ist aus meiner Sicht am günstigten, ein Tool zu benutzen, das dem TO vertraut ist und deshalb einen geringen Fehlerquerschnitt hat. Arduino-IDE hat er selbst als ideal bezeichnet. Ich benutze ebenfalls Arduino für BluePill mit dem JSON-File von Dan Drown und weiß, das es funktioniert, wenn der Bootloader im ROM vorhanden ist. Wenn das funktioniert, kann man jeden anderen STM32-Flasher nutzen. Es geht einfach darum, einen Schritt nach dem anderen zu machen und nicht zwei Schritte auf einmal Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Es geht ja zunächst nur darum zu testen, ob der verwendete Chip > überhaupt einen UART-Bootloader im ROM hat. Da ist aus meiner Sicht am > günstigten, ein Tool zu benutzen, das dem TO vertraut ist. Die Arduino IDE hat keinen Menüpunkt, mit dem man eine fertige *.hex Datei hochladen kann. Auch die STM32 Cube IDE hat keine Funktion, um *.hex Dateien hoch zu laden. Zudem frage ich mich, warum du davon ausgehst, dass dieses Gerät ausgerechnet den Arduino Bootloader enthalten soll, wo doch der Hersteller in seinem PDF schreibt, dass man den "Flash Loader Demonstrator" von ST verwenden soll. Der Arduino Bootloader spricht ein ganz anderes Protokoll! Darauf habe ich schon vor einem halben Jahr hingewiesen. Es mag ja sein, dass das Programm von ST alt ist, aber es funktioniert. Den Vorschlag, es durch ein anderes zu ersetzen, dass weder den Dateityp noch das benötigte Protokoll unterstützt, finde ich ziemlich irreführend.
Stefan F. schrieb: > Zudem frage ich mich, warum du davon ausgehst, dass dieses Gerät > ausgerechnet den Arduino Bootloader enthalten soll, wo doch der > Hersteller in seinem PDF schreibt, dass man den "Flash Loader > Demonstrator" von ST verwenden soll. Der Arduino Bootloader spricht ein > ganz anderes Protokoll! Darauf habe ich schon vor einem halben Jahr > hingewiesen. Ich habe nicht die geringste Ahnung, wie Du auf solche Einfälle kommst. Ich kann mich nicht erinnern, je den Arduino-Bootloader erwähnt zu haben, der (noch viel deplazierter als der Maple-Bootloader weil AVR) hier überhaupt nichts zu suchen hat. Du hast mir bestimmt 5 Jahre Erfahrung mit der STM32-Fmilie voraus und ich habe das Meiste über den STM32F103 von Deiner Webseite gelernt. Ich habe aber im Verlauf des letzten Jahres die Bluepill über Arduino-IDE und den ST-UART-Bootloader mit Programmen versorgt und rede deshalb nicht aus 2.Hand, sondern aus eigener Expertise. Während Du auf Deiner Webseite davor gewarnt hast, der UART-Boot sei dem Hörensagen nach unzuverlässig und stattdessen den ST-Link propagierst, habe ich mich auf die Kehrseite gesetzt, einen Fehler gesucht und gefunden und in diesem Forum auf die Ursachen hingewiesen, damit Menschen wie Du das auf ihrer Webseite verbreiten können. Meine Arbeitsmethode habe ich ganz oben als Antwort auf die pampige Anmache des TO beschrieben: Nicht Fummeln, sondern Schritt für Schritt den Fehler einkreisen. Das ist die mühsame, aber sichere Methode (If You want to have it done right, You have to do it Yourself). Im Gegensatz dazu ist das Ausprobieren von Tipps der "Cracks" erheblich ökonomischer, allerdings nur, wenn die Tipps auch zum Erfolg führen. Und da von Mai bis jetzt kein "Crack" aufgetaucht ist, war mein Vorschlag, es mit der mühsamen Methode zu versuchen. Da ist der erste Schritt eben, festzustellen, ob der eingebaute Chip überhaupt einen funktionsfähigen UART-Bootloader im ROM hat oder eine Fälschung ohne diese Eigenschaft ist. Das kann ich fachmännisch begleiten, wenn ich das benutzte Tool kenne, sonst ist es wieder Hörensagen aus 2.Hand. Optimal ist es, wenn ich das Tool auch noch im Sourcecode habe und in der Lage bin, es zu modifizieren. Genau das habe bereits mit dem STM32flash.exe von Roger Clarke erfolgreich gemacht. Und da auch noch der TO die Arduino-IDE ideal fand, wüßte ich nicht, welches Tool besser geeignet sein sollte, bin aber für Vorschläge sehr offen. Die zweite Methode mit dem von Dir angeführten "STM32 Cube Programmer" habe ich noch einmal ausprobiert, sie war schon auf meinem Rechner und funktioniert einwandfrei. Da hat mein Gedächtnis ziemlich viel entsorgt gehabt, ich konnte mich zunächst ja überhaupt nicht mehr daran erinnern, daß es sie überhaupt gab. Sie ist aber natürlich "Closed Source" nach meinem Wissensstand und deswegen eher sub-optimal, aber durchaus geeignet. Es gibt auch noch eine dritte Möglichkeit. Das Datenblatt von WCH ist verfügbar. Es ist aber nur in Chinesisch erhältlich. Da es nicht mein Chip ist, habe ich wenig Lust, es für den TO zu übersetzen. Stefan F. schrieb: > Die Arduino IDE hat keinen Menüpunkt, mit dem man eine fertige *.hex > Datei hochladen kann. Das ist zwar richtig, aber jeder der eine Tastatur bedienen kann. kann die Datei SERIALUPLOAD.BAT von Hand ändern und statt des Übergabeparameters einen Dateinamen einsetzen. KlickiBunti-Jünger haben es da natürlich schwer, ich erkläre mich aber bereit, ihnen im Falle des Falles die Feder führen zu können und haarklein zu erklären, was dafür nötig ist. Wer Kinder hatte, weiß, daß man ab und an mal einen Po abwischen muß, das gehört zum Leben dazu. Der Vorteil dabei ist, daß man wirklich nur den Dateinamen einsetzen muß, alles Andere ist maulfertig durch die Bauteilewahl in der Arduino-IDE erledigt. Aber natürlich darf man auch jedes andere Tool benutzen. Ich kann aber nur da Unterstützung geben, wo ich mich auskenne, ansonsten komme ich ins Schwafeln. Insofern habe ich nicht das geringste Problem damit, wenn Du dem TO etwas Besseres vorschlägst, statt zu monieren, daß mein Vorschlag nichts taugt. Aber auch Deine Kritikpunkte beantworte ich gern. Ich hab soviel von Dir gelernt, so kann ich mich mal revanchieren :-) Gruß Klaus (der soundsovielte) P.S. Der TO hat schon nach einem Tag die Lust auf Fehlersuche verloren, der wartet lieber weiter auf die "Cracks". Verstehen kann ich ihn ja. Wenn man keine Lust zu etwas hat, sollte man es auch tunlichst lassen, es kommt nicht viel dabei heraus.
Noch ein Nachtrag: Stefan F. schrieb: > Es mag ja sein, dass das Programm von ST alt ist, aber es funktioniert. Jetzt geht es mir so, wie Dir mit dem UART-Boot. Vom Hörensagen (Aussage von W.S) taugt dieses Programm nicht viel, weshalb er extra ein Besseres geschrieben hat. In dem habe ich leider den F103 nicht gefunden und zum Erweitern der config-Datei reicht mein Wissen (noch?) nicht aus. Deshalb meine Bevorzugung des Tools, das ich unter Kontrolle habe. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Während Du auf Deiner Webseite davor gewarnt hast, der UART-Boot sei dem > Hörensagen nach unzuverlässig und stattdessen den ST-Link propagierst Bitte bleibe bei den Tatsachen. Auf meiner Homepage werte ich den seriellen bBootloader nicht ab. Das Wort "unzuverlässig" existiert dort nicht, auch kein anderes abwertendes Wort. In der 2. Auflage meines Tutorials im PDF Format nutze ich sogar ausschließlich den seriellen Bootloader.
Klaus S. schrieb: > In dem habe ich leider den F103 nicht gefunden Sowohl der Flash Loader Demonstrator als auch der STM32 Cube Programmer unterstützen alle STM32F103 Modelle ohne besondere Tricks.
Stefan F. schrieb: > Bitte bleibe bei den Tatsachen. Da habe ich Dich wohl mit jemand Anderen verwechselt, bitte um Entschuldigung. Gruß Klaus (der soundsovielte)
Stefan F. schrieb: > Auch die STM32 Cube IDE hat keine Funktion, um *.hex Dateien hoch zu > laden. Braucht sie auch nicht, da die CubeIDE kein Programmer ist. Mit dem CubeProgrammer kann man dagegen sehr wohl *.hex programmieren, sowohl mit der GUI, als auch mit dem CLI. PdG
Stefan F. schrieb: > Es mag ja sein, dass das Programm von ST alt ist, aber es funktioniert. Naja, cum grano salis. Wenn alles funktioniert, dann funktioniert auch dieses Flashloader-Programm von ST. Aber wenn es irgendwie irgendwo ein bissel hakt, dann kaut das Programm eine halbe Ewigkeit drauf herum und meldet dann lapidar "geht nicht". Nicht sehr hilfreich. Ich hatte mir deshalb mein eigenes Programm geschrieben (hatte ich hier auch mal gepostet) und das benutze ich noch heute. Nach meiner Erfahrung damit funktioniert das mit dem Bootlader zumindest genauso zuverlässig wie andere Programmierarten. Allerdings sehe ich da Unterschiede zwischen Seggers JLink (der ist immer noch der Beste - aber auch der Teuerste) und den anderen Basteleien. W.S.
Hallo, den Fehler weiß ich auch nicht, Aber ich habe es "hingebrungen". ;-) Link: Beitrag "Re: stm32flash "Failed to init device"" Warum es so geht weiß ich auch nicht. :-)) LG Jörg
Jörg H. S. schrieb: > Warum es so geht weiß ich auch nicht. Offenbar, weil da ein gefälschter STM32F103 verbaut wurde, der keinen seriellen Bootloader hat. Von solchen Fakes wurde hier und auf anderen Webseiten schon öfters berichtet.
Ganz so einfach, sei die Sachlage nicht. Wie man sieht wird da noch mehr gefaked oder raubkopiert als man annimmt, auch mit voller Funktion.! Fakt ist, man kann die Dinger programmieren, wenn man weiß wie. Die DSOs funzten ja mal bei Auslieferung auch mit den nicht originalen Chips. Was fehlt ist eine allgemeingültige Anleitung, mit der auch ein Laie, wie ich, klarkommt. Das ist umso wichtiger, weil Originale im Moment gar nicht lieferbar sind. Mit der seriellen Schnittstelle geht es wohl nur selten, mit dem ST-LINK schon viel besser, weil man den Boot-Loader nicht braucht. Dafür gab es aber schon wieder keine Anleitung für DAUs. So wird aus dem kleinsten Bastelproblem ein Hexenwerk. Die Komplexität meines Tuns war mir Überhaupt nicht. Ich dachte 3x "copy und paste" und schon geht das, Pustekuchen.!!
Jörg H. S. schrieb: > Ganz so einfach, sei die Sachlage nicht. > Wie man sieht wird da noch mehr gefaked oder raubkopiert als man > annimmt, auch mit voller Funktion.! Naja, dass es zahlreiche unterschiedliche Fakes gibt, ist seit Jahren bekannt. Mir sind folgende Probleme bekannt: - Flashen geht nur über SWD, nur UART oder nur mit 115200 Baud - Debuggen geht nicht - Der Blink Sketch (Arduino) blinkt nicht - DMA Controller löst falsche Interrupts aus und hängt sich auf - OCN-Ausgänge der Timer funktionieren nicht - USB funktioniert nicht - Die Chip-ID lässt sich per Firmware auslesen (beim Original geht das nicht) Jeder schlecht gefälschte STM32F103 hat einen oder mehrere dieser Mängel. Ob es fehlerfreie Fälschungen gibt, weiß ich nicht.
:
Bearbeitet durch User
In der Zeit als Eisen noch aus Holz war, hab ich meine Brötchen mal mit Full-Custom Designen verdient... Schon damals wurde abgekupfert was das Zeug hielt. Mit der heutigen Technik kann ich überhaupt nichts anfangen. Das Konzept der ARM-Chips waren damals gerade noch nicht angewendet worden. Das war damals revolutionär, so zu denken. Ein Quantensprung in der Signalverarbeitung. Nur Silizium war noch zu langsam, das sollte sich schnell ändern.! Die Gehäuse enthielten häufig nicht mal so ähnliche Dies, auch wenn hoch und heilig versprochen wurde nichts zu ändern, sogar beim Original. Wer konnte das schon prüfen. Es ist ja auch egal, wenn es funzt. Aber wehe "in field" geht nix.! Bei MC ist das einfacher, man kann sie auslesen.
:
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.