Guten Tag, Ich habe folgendendes Problem und würde mich über Feedback freuen. Ich habe eine Elektronik mit einem Mikrocontroller (STM32F103xxx) und suchen nach einer Möglichkeit diesen Mikrocontroller via Bluetooth und Mobile Phone zu re-programmieren. Ich dachte an ein Bluetooth Modul welches via JTAG Interface mit dem Mikrocontroller verbunden ist. Es gibt Gründe warum ich das Ganze nicht mit dem üblichen JTAG Interface machen möchte. Hat irgendjemand damit Erfahrungen und kann etwas sagen? MfG
Warum nicht "normaler" serieller Bootloader? Ein BT-Modul das JTAG kann musst du erstmal finden. Oder bauen.
Danke aber das Produkt erlaubt keine Kabelverbindung.
Daniel D. schrieb: > Danke aber das Produkt erlaubt keine Kabelverbindung. Deshalb gibt es viele Bluetooth Chips mit serieller Anbindung an den µC. Über UART (Tx, Rx) angeschlossen. An welchen Bluetoothchip hast du denn gedacht? JTAG ist hier mMn. zu übertrieben. Der Rest ist dann nur noch Bootloader + App Programmierung.
Das Produkt wird aber nicht etwa beim Kunden heimlich "geupdadet"...!? Oder wie lädst Du das Produkt auf? Muss ja irgendwie einen USB-Anschluss haben oder dergleichen... Gruss Chregu
Sorry... lange Leitung. Verstehe.. ja ich koennte von JTAG auf UART, I2C, etc. ausweichen. Das waere kein Problem. LG Hallo Christian M. - natuerlich nicht. Muss ja schliesslich noch eine APP aufs Telefon. Wir haben keine Moeglichkeit das ein Kunde mit einem Kabel, Laptop rumfummelt. Das hoechste der Gefuehle ist eine Docking Station und eben eine App auf dem Telefon.
:
Bearbeitet durch User
Hallo Daniel, Daniel D. schrieb: > Ich habe eine Elektronik mit einem Mikrocontroller (STM32F103xxx) und > suchen nach einer Möglichkeit diesen Mikrocontroller via Bluetooth und > Mobile Phone zu re-programmieren. ich entwickel gerade einen Bluetooth LE SWD debugger (Beitrag "Gehäuse-Ideen gesucht"). > Ich dachte an ein Bluetooth Modul welches via JTAG Interface mit dem > Mikrocontroller verbunden ist. > Es gibt Gründe warum ich das Ganze nicht mit dem üblichen JTAG Interface > machen möchte. Gibt es einen Grund, dass es JTAG und nicht SWD sein soll? > Hat irgendjemand damit Erfahrungen und kann etwas sagen? Stand unserer Entwicklung ist, dass man damit einen nrf52 flashen kann. Software dafür gibt es im Moment nur für MacOS (ist meine Entwicklungsplattform). Geplannt ist bis jetzt nur Support für Windows, MacOS und Linux. Wir wollen erst einmal auf SWD setzen, JTAG könnte später dazu kommen. Ich habe im Vorfeldt der Entwicklung mal nach entsprechenden Geräten gesucht und nichts gefunden. Ich denke mal, dass unser Produkt da einmalig ist. Vielleicht magst Du mich mal anschreiben und wir gucken, ob wir irgend wie zusammen arbeiten können. mfg Torsten
Angehängte Dateien:
Daniel D. schrieb: > Ich habe eine Elektronik mit einem Mikrocontroller (STM32F103xxx) und > suchen nach einer Möglichkeit diesen Mikrocontroller via Bluetooth und > Mobile Phone zu re-programmieren. Was ich für die WordClock mit WS2812 gemacht habe: 1. ESP8266-12F mit Webinterface bietet Upload von STM32-Hex-Dateien an 2. Nach Upload flasht der ESP8266-12F den STM32 über den seriellen Bootloader Durch das Webinterface kann man den STM32 über jedes Endgerät flashen, welches einen Browser hat. Dazu gehören also auch iPhones, bei denen das mit der Bluetooth-Lizenz teuer werden kann. EDIT: Das obige erste Bild zeigt einen Download der STM32-Hex-Datei von einem Internet-Update-Server. Es geht aber auch alternativ dazu ein Upload vom eigenen Endgerät mit Browser, siehe Bild 2.
:
Bearbeitet durch Moderator
Ich schätze, dass es über den seriellen Bootloader mit einem HC-05 oder HC-06 Modul funktionieren wird. Den Bootloader muss man aber mit einem Jumper/Schalter aktivieren.
Daniel D. schrieb: > Ich dachte an ein Bluetooth Modul welches via JTAG Interface mit dem > Mikrocontroller verbunden ist. Warum JTAG? Warum SWD? Diese Schnittstellen verwendet man nicht deswegen, weil sie besonders sexy oder einfach wären, sondern weil sie auch bei leerem µC funktionieren. Wenn es um Updates geht, nimm eine Standardschnittstelle. BT Module sprechen meist (immer?) UART. Das würde sich also anbieten. Der Rest ist Software. Im Prinzip wie ein Bootloader, nur hier eben als Bestandteil eurer Firmware.
Axel S. schrieb: > Im Prinzip wie ein Bootloader, nur hier eben als Bestandteil > eurer Firmware. Dann muss man ihn auch nicht mit einem Jumper aktivieren sondern kann das so gestalten, wie man will.
Axel S. schrieb: > Daniel D. schrieb: >> Ich dachte an ein Bluetooth Modul welches via JTAG Interface mit dem >> Mikrocontroller verbunden ist. > > Warum JTAG? Warum SWD? Diese Schnittstellen verwendet man nicht > deswegen, weil sie besonders sexy oder einfach wären, sondern weil sie > auch bei leerem µC funktionieren. Na, wenn die Aufgabe darin besteht, das flash memory eines angeschlossenen µControllers zu programmieren, dann ist JTAG/SWD nicht so einfach weg zu diskutieren. Für alles andere braucht es halt entweder einen Bootloader (der geschrieben sein will und Resourcen im µController braucht) oder einen Umsetzer auf JTAG/SWD. > Wenn es um Updates geht, nimm eine Standardschnittstelle. JTAG/SWD sind "Standardschnittstellen".
Torsten R. schrieb: > Für alles andere braucht es halt entweder einen Bootloader (der > geschrieben sein will und Resourcen im µController braucht) oder einen > Umsetzer auf JTAG/SWD. Da es hier um STM32 geht, der einen oder gar mehrere hauseigene Bootloader "on-board" hat, existiert Dein geschildertes Problem nicht.
Als drahtlose Methode ist auch Infrarot immer noch im Umlauf. Wir haben einige Ladegeräte, die so programmiert werden.
Daniel D. schrieb: > Ich dachte an ein Bluetooth Modul welches via JTAG Interface mit dem > Mikrocontroller verbunden ist. Ich würde behaupten, sowas gibt es nicht :) Customized Bootloader ist das Zauberwort.
Torsten R. schrieb: > Axel S. schrieb: >> Daniel D. schrieb: >>> Ich dachte an ein Bluetooth Modul welches via JTAG Interface mit dem >>> Mikrocontroller verbunden ist. >> >> Warum JTAG? Warum SWD? Diese Schnittstellen verwendet man nicht >> deswegen, weil sie besonders sexy oder einfach wären, sondern weil sie >> auch bei leerem µC funktionieren. > > Na, wenn die Aufgabe darin besteht, das flash memory eines > angeschlossenen µControllers zu programmieren, dann ist JTAG/SWD nicht > so einfach weg zu diskutieren. Es geht nicht darum, die weg zu diskutieren. Aber sie bieten für das geschilderte Szenario keinen Vorteil, sondern sind vergleichsweise viel aufwendiger zu implementieren als einfach die Firmware direkt binär oder meinetwegen als Intel HEX vom Schlau-Fon zum Gerät zu beamen. > Für alles andere braucht es halt entweder einen Bootloader Das ist ein STM32. Die können alle das Flash aus der laufenden Anwendung heraus programmieren. Das ist auch vergleichsweise wenig aufwendig. Der eigentliche Aufwand besteht eher darin, die Integrität (mindestens Prüfsumme, besser etwas kryptografisches) des neuen Firmware-Images zu prüfen. Und eine Fallback-Strategie zu haben, falls der Stream abbricht.
Axel S. schrieb: > Das ist ein STM32. Die können alle das Flash aus der laufenden Anwendung > heraus programmieren. Das ist auch vergleichsweise wenig aufwendig. Klar, da gebe ich euch Recht! > Der > eigentliche Aufwand besteht eher darin, die Integrität (mindestens > Prüfsumme, besser etwas kryptografisches) des neuen Firmware-Images zu > prüfen. Und eine Fallback-Strategie zu haben, falls der Stream abbricht. Und mit dem Smartphone die boot pins entsprechend zu setzen ;-) Spätestens da braucht es dann doch etwas mehr, als eine wireless UART-Kabel.
Torsten R. schrieb: > Und mit dem Smartphone die boot pins entsprechend zu setzen ;-) > Spätestens da braucht es dann doch etwas mehr, als eine wireless > UART-Kabel. Falls vorhanden könnte man dazu die "Connected" Statusleitung verwenden. Ich würde physischen Zugriff zum aktivieren des Bootloaders allerdings bevorzugen. Ist sicherer.
Torsten R. schrieb: > Axel S. schrieb: >> Der >> eigentliche Aufwand besteht eher darin, die Integrität (mindestens >> Prüfsumme, besser etwas kryptografisches) des neuen Firmware-Images zu >> prüfen. Und eine Fallback-Strategie zu haben, falls der Stream abbricht. > > Und mit dem Smartphone die boot pins entsprechend zu setzen ;-) Warum das denn? > Spätestens da braucht es dann doch etwas mehr, als eine wireless > UART-Kabel. Ich weiß nicht, warum ihr euch so an den vorhandenen Bootloadern festbeißt. Ja, so ein Update-Mechanismus hat von der Funktionalität her Überschneidungen mit einem Bootloader. Deswegen ist es aber noch lange keiner. Und der eingebaute UART Bootloader ist ebenfalls keine sonderlich gute Wahl für einen Update-Mechanismus. Er hat ebenso wie SWD oder JTAG den Vorteil, auch bei leerem oder verflashtem µC noch zu funktionieren. Aber das wird doch gar nicht gebraucht. Für ein Update können wir davon ausgehen, daß sich auf dem µC eine funktionsfähige Firmware befindet. Die sollte nun vermutlich irgendeine Nutzerinteraktion verlangen, um in den Update-Modus zu gehen. Man will ja schließlich nicht, daß das Gerät aus eigenem Antrieb den Betrieb einstellt, nur weil jemand sich per Bluetooth verbunden hat. Ebenso wird das BT Modul wohl etwas Initialisierung brauchen. Und dann muß das Firmware-Update wenigstens auf Plausibilität geprüft werden (Größe, Prüfsumme, was-auch-immer). Nichts davon leistet der Werk-Bootloader.
Erstmal vielen, vielen Dank fur die Antworten. Vielleicht geh ersteinmal auf die Applikation ein. Ein elektrisches Geraet welches via Bluetooth und Mobile Phone ein Update einspielen soll. Der Benutzer muss eine bestimmte Tastenkombination druecken um eben in den Updatemodus zu kommen. Wenn ich das richting gesehen habe kann der STM32 einen Bootloader haben, der mit Hilfe einer Standardschnittstelle UART, I2C, SPI, etc. die eigentliche Applikation updated. Sollte das Ganze schief gehen waere es kein Beinbruch wenn der Kunde uns das Geraet zurueck sendet. Ich waere aber schon an einer hohen Erfolgsquote interessiert. Mein Chef hat mir gestern mitgeteilt das das Ganze doch recht preis-sensibel ist und solche eine Loesung deutlich unter US$2.00 pro Geraet liegen sollte. Ich habe dann mal nach Bluetooeth BLE Modulen geschaut und finde diese kaum unter den geforderten US$2.00. Daher muss ich meine Frage erweitern ob das ueberhaupt preislich machbar ist bevor wir uns um die Technik kuemmern?
Daniel D. schrieb: > Vielleicht geh ersteinmal auf die Applikation ein. > Ein elektrisches Geraet welches via Bluetooth und Mobile Phone ein > Update einspielen soll. Der Benutzer muss eine bestimmte > Tastenkombination druecken um eben in den Updatemodus zu kommen. OK. Das ist sinnvoll. > Wenn ich das richting gesehen habe kann der STM32 einen Bootloader > haben, der mit Hilfe einer Standardschnittstelle UART, I2C, SPI, etc. > die eigentliche Applikation updated. Jein. Jeder(?) STM32 hat ab Werk einen Bootloader im (nicht überschreibbaren) Flash. Beim Reset schaut der STM32 nach dem Pegel an den BOOT0/1 Pins und springt dann entweder in sein Flash, das RAM oder eben den Bootloader. Je nach konkretem µC kann der Bootloader wahlweise UART, SPI, I²C, CAN, USB, ... Der Zweck dieses Bootloaders besteht hauptsächlich darin, einen leeren µC zu programmieren. Natürlich kann man diesen Bootloader auch für Updates verwenden. Aber im Normalfall wird man das nicht wollen. Schon weil der keinerlei Überprüfung des Programms vornimmt. Keine Fehlerbehandlung hat (es kommen keine Daten? Egal, ich warte einfach). Er kann auch nicht mit dem Nutzer interagieren. Fortschrittsanzeige? Abbruch-Button? Nix. Aber da ist noch mehr. Der Bootloader hat seinen Namen nicht ohne Grund. Das "Boot" steht dafür, daß der Bootloader das erste ist, was der µC ausführt (vulgo: wenn er bootet). Das ist aber gerade nicht das gewünschte Verhalten für einen Updater. Schlußfolgerung: ein Bootloader, egal ob ein eingebauter oder ein selber in den Flash programmierter, ist nicht die Lösung. Das einzige was bleibt, ist eine gewisse Ähnlichkeit der Kernfunktion. Sowohl der Bootloader als auch ein Updater bestehen in ihrem tiefsten Inneren aus einer Schleife, in der sie Daten von einer Schnittstelle einlesen und diese Daten dann ins Flash schreiben. Deswegen kann es sinnvoll sein, wenn du dir mal den Quellcode eines Bootloaders für den STM32 anschaust. Aber ohne eigenen Code drum herum wird das nix. > Mein Chef hat mir gestern mitgeteilt das das Ganze doch recht > preis-sensibel ist und solche eine Loesung deutlich unter US$2.00 pro > Geraet liegen sollte. > > Ich habe dann mal nach Bluetooeth BLE Modulen geschaut und finde diese > kaum unter den geforderten US$2.00 BLE ist der neue heiße Scheiß. Nimm normales Bluetooth. Reicht doch vollkommen für eine Updatefunktion.
Daniel D. schrieb: > Ich habe dann mal nach Bluetooeth BLE Modulen geschaut und finde diese > kaum unter den geforderten US$2.00. Daher muss ich meine Frage erweitern > ob das ueberhaupt preislich machbar ist bevor wir uns um die Technik > kuemmern? Guck mal nach den etwas kleineren BLE µControllern von Nordic (zb. nrf51422) und TI, damit müsste man zumindest in die Region kommen (bei entsprechend großen Stückzahlen). Da müsst ihr dann halt noch entsprechende Firmware entwickeln.
>2$ pro Gerät ist zu teuer >hinfahren um den Kunden mit neuer Software zu versorgen ist ok Ist heute opposite day? M.M.n. ist eine Updatefunktion heutzutage Pflicht, wenn die Gerätesoftware etwas komplexer ist und/oder mit der Außenwelt kommuniziert wird. Einmal nicht hinfahren müssen bezahlt den "boot"loader bei einer ganzen Menge Geräte... Sofern RAM und eine Schnittstelle vorhanden ist, ist das "nur ein bissel Software". Evtl. lässt sich eine andere Schnittstelle verwenden? z.B. ein ESP, der einen AP aufspannt, die Website des "Routers" kann eine Datei auswählen, ein OK-Knopf, eine Statusanzeige. Das dürfte so gerade unter 2$ gehen und braucht keine App.
Jens M. schrieb: > M.M.n. ist eine Updatefunktion heutzutage Pflicht, wenn die > Gerätesoftware etwas komplexer ist und/oder mit der Außenwelt > kommuniziert wird. Ich weiß nicht. Klar, das ist gelebte Praxis. Und es wäre auch nichts dagegen einzuwenden, wenn die Hersteller es auch wirklich nur für Upgrades (nicht: Bugfixes) verwenden würden. Aber in der Realität habe ich den Eindruck, daß die einfache Update- barkeit nur zu mehr Bananenprodukten [1] führt. Nach dem Motto: "Kann schon sein, daß V1.0 unserer Firmware noch Bugs hat. Aber wenn sich zuviele Kunde beschweren, können wir ja immer noch ein Update ausrollen". Time-to-market statt Qualität. [1] reift beim Käufer
Dazu kommt, dass automatische Updates gerne mal mit voller Absicht Auswirkungen haben. Zum Beispiel, wenn der Drucker plötzlich keine nachgefüllten Patronen mehr akzeptiert, aber genau wegen dieser Möglichkeit gekauft wurde.
Daniel D. schrieb: > Wenn ich das richting gesehen habe kann der STM32 einen Bootloader > haben, der mit Hilfe einer Standardschnittstelle UART, I2C, SPI, etc. > die eigentliche Applikation updated. Nur mal rein interessehalber: Du machst das beruflich als Hauptjob? Oliver
Axel S. schrieb: > Und es wäre auch nichts > dagegen einzuwenden, wenn die Hersteller es auch wirklich nur für > Upgrades (nicht: Bugfixes) verwenden würden. Das würde implizieren, das die Software bei Auslieferung fehlerfrei ist, was per definitionem nicht möglich ist. Wenn ich wählen kann zwischen einem Gerät mit unrettbaren Fehlern und einem Gerät mit patchbaren Fehlern, wähle ich das patchbare. Upgrades hingegen sind manchmal sogar unerwünscht. Axel S. schrieb: > Aber in der Realität habe ich den Eindruck, daß die einfache Update- > barkeit nur zu mehr Bananenprodukten [1] führt. Das ist allerdings korrekt, den Eindruck hab ich auch. Hat aber nichts damit zu tun, das ein Gerät reparierbar sein sollte, und im Falle einer Software ist das eben ein Update. Dennoch sollte die Auslieferung nach bestem Wissen und Gewissen fehlerfrei sein. Aber da kommt eben immer die Realität und "$AnzahlDerBeteiligtenBWLer>1 = true" dazwischen... Stefanus F. schrieb: > Dazu kommt, dass automatische Updates gerne mal mit voller Absicht > Auswirkungen haben. Jau. Mein liebstes Beispiel: Mietkopierer mit Scanner/email von Triumph-Adler/Utax/Kyocera: alte Versionen erlauben emailsignaturen mit Umlauten und Sonderzeichen, zudem werden die Texte im Eingabefeld des Geräts nicht umgebrochen. Nach dem Update, der "kleinere Fehler behebt", werden Mails ohne Signatur verschickt... Nachdem ich z.B. aus den "Grüßen" "Gruessen" gemacht habe, gehts wieder, dafür waren die Texte dann auch noch wie das Eingabefeld umgebrochen, das in den Settings ist. Also ca. die hälfte der Breite des Eingabefelds hier. Sieht natuer lich total t oll aus, wen n die Signat ur mittendrin s o abgebroche ne Woerter u nd mittendri n unpassende Zeilenvorsch uebe hat. Sehr profess ionell, das ganze. Support sagt, das war schon immer so. Identisches Kaufgerät mit alter Firmware mit Fernwartung dem Support gezeigt, schwupp ist man im 2nd Level. Der spricht mit dem Programmiererteam, die sagen dann nur "Downgrade nicht möglich, Fehlerbehebung nicht möglich, liegt am zugrindeliegenden Linux, Feature bleibt so". Von wegen "Document Company"... Also: Never change a running system. Run a never changing system. Change a never running system.
:
Bearbeitet durch User
Wenn eine Kabelverbindung nicht geht und Zusatzchips zu teuer sind, dann macht man das anders. Mikrofon an den ADC geklemmt und 1200 bps akustisch übertragen. Dann steht der Kunde zwar ein paar Minuten mit einem rauschenden Smartphone vor der Kiste, aber dafür ist es billig.
Jens M. schrieb: > Upgrades hingegen sind manchmal sogar unerwünscht. Allerdings. Ich hatte einen DVB-Receiver, der manchmal nicht korrekt startete und in der Kanal-Liste alle Wörter beim ersten Umlaut abgeschnitten hatte. Dagegen gab es eine neue Firmware - bunter und mit runden Ecken. Jetzt zeigt er Umlaute an, schmiert aber zwischendurch beim Fernsehgucken und Umschalten der Kanäle ab -> Fall für die Mülltonne.
Danke fuer die vielen Hinweise. Nach langer Diskussion und Hin- und Her Rechnerei der Kosten werden wir doch auf eine USB (mit entsprechenden Kabel) Loesung umschwenken. Idee ist das wir eine USB Schnittstelle die wir nur fuer das Laden eines externen Geraetes (Mobile Phone, Tablet) verwenden wollten nun auch fuer die entsprechende Kommunikation und Updates benutzen. MfG...
Jens M. schrieb: > Also: > Never change a running system. > Run a never changing system. > Change a never running system. Du hast noch Never run a changing system. vergessen ;-)
Daniel D. schrieb: > Nach langer Diskussion und Hin- und Her Rechnerei der Kosten werden wir > doch auf eine USB (mit entsprechenden Kabel) Loesung umschwenken. Ich dachte, das war unmöglich?
Daniel D. schrieb: > Danke aber das Produkt erlaubt keine Kabelverbindung. Daniel D. schrieb: > Nach langer Diskussion und Hin- und Her Rechnerei der Kosten werden wir > doch auf eine USB (mit entsprechenden Kabel) Loesung umschwenken. Interessant. Immerhin wurde dies vor dem Bauen geklärt - ich habe das auch schon anders erlebt.
Daniel D. schrieb: > die wir nur fuer das Laden eines > externen Geraetes (Mobile Phone, Tablet) verwenden wollten Das heißt aber jetzt nicht, das da eine USB-A-Buchse drankommt, und zum Update braucht man ein seltenes/unübliches/verbotenes A-A-Kabel???
Hallo... Sorry fuer die spaete Antwort. Wir haben uns inzwischen auf eine andere Loesung entschieden... Das Geraet bekommt ein herausgefuehrtes Programmierinterface welches vor dem Anwender versteckt wird. Muss re-programmiert werden dann muss das Geraet eingeschickt werden und wir machen das. Wir werden uns der Sache zu einem spaeteren Zeitpunkt nochmals annehmen. Liebe Gruesse...
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.