Mikrocontroller programmieren via Bluetooth

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.

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.

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

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.

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:
> 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:
> 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

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.

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.

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

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