Firmwareupdate für Microcontroller via CANBUS

[Ben B. (benmk7)]

Hallo Community,

ich möchte mein CANBUS Netzwerk etwas vereinfachen.

Zum derzeitigen Aufbau:
Ich habe eine Steuerplatine(für Verwaltungsaufgaben und Anbindung an ein 
Display) und diese ist mit mehreren, mehr oder weniger gleichen, 
Platinen via CANBUS (2.0A) verbunden.

Grundaufbau der Platinen:
- Microcontroller ATMEGA1284p bzw. ATMEGA32A
- MCP2515 + MCP2551
- ISP Schnittstelle zum Programmieren

Nun möchte ich die Steuerplatine neu auslegen und einige Features 
ergänzen. Dazu gehören u.a. eine Ethernet Schnittstelle und die 
Möglichkeit einzelne Platinen in meinem System über den CANBUS mit einer 
neuen Firmware zu bespielen (statt per Hand über die ISP Schnittstelle).

Ich weis bereits, dass ich einen Bootloader auf jeder Platine 
installieren muss.

Ich würde gerne mit folgendem Schritt starten:

Schritt 1: Mittels eines Interfaces (z.B. USB zu CAN) soll mit Hilfe 
eines PCs eine Platine via CANBUS auf eine neue Firmware aktualisiert 
werden.


Wie gehe ich dabei am Geschicktesten vor? Wie richte ich den Bootloader 
ein? Wie nutze ich Ihn? Funktioniert mein Vorhaben mit dem bisherigen 
Aufbau übnerhaupt oder werden z.B externe Speicherbausteine auf den 
Platinen benötigt?

In dieser Thematik bin ich absuluter Neuling und würde gerne lernen, wie 
ich an sowas ran gehen muss.

Für eure Unterstützung im Voraus besten Dank. :)

Liebe Grüße,
Ben

[soso (Gast)]

Guck dich mal bei Emtas um und hau CANopen drauf. Spar dir den ganzen 
mist mit einem proprietären Protokoll und arbeite dich in CANopen ein, 
wenn du schon ein Neudesign machst.

[Dr. Sommer (Gast)]

Eine Möglichkeit: Der Bootloader startet als erstes, wartet 1 Sekunde 
auf eine Nachricht vom PC, und wenn keine kommt, startet das Programm 
normal. Wenn eine Nachricht empfangen wurde, wird das Programm-Abbild 
stückweise per CAN übertragen, empfangen und geflasht. Dabei ist es 
sinnvoll, das ganze Programm nochmal per CRC zu prüfen, für den Fall, 
dass eine Nachricht verloren gegangen ist. Außerdem braucht man Timeouts 
um Nachrichtenverlust abzufangen. Du kannst das Anwendungsprogramm so 
schreiben, dass es bei Empfang der initialen Nachricht den Controller 
resettet, sodass direkt der Bootloader startet. Solange das 
Anwendungsprogramm funktioniert, kannst du somit flashen ohne irgendwas 
neu zu starten. Sollte das Anwendungsprogramm festhängen, kannst du die 
Anlage neu starten und innerhalb von 1 Sek die erste Nachricht zum 
Flashen senden - solange der Bootloader intakt ist, kannst du dann 
flashen ohne an den ISP-Stecker dran zu kommen.

[soso (Gast)]

Du nutzt bestehende Protokolle, einheitliche Protokolle und bist auch 
offen mal etwas zugekauftes einzubringen.

Dies gilt für ein kommerzielles Produkt. Wenn du dich nur ein bischen 
mit der Thematik beschäftigen willst, guck dir mal OS zeug an, etwa das 
CANopenNode Prj.

[Bernd K. (prof7bit)]

soso schrieb:
> und hau CANopen drauf

Das bringt ihm immer noch keine Lösung für den Bootloader.

Er braucht nen Bootloader der CAN-fähig ist und Software die sein Gerät 
mir irgend nem Befehl in den Bootloadermodus versetzen und dann über CAN 
die Firmware hochladen kann.

[Nick M. (Gast)]

Firmware per CAN-Bus auf den Controller in einen Zwischenspeicher 
(EEPROM) ablegen. Mit CRC usw. überprüfen.
Flag im Controller setzen, dass er neu flashen soll.
Controller booten lassen, der sieht das Flag und der Bootloader holt 
sich die Daten aus dem Zwischenspeicher (EEPROM lässt sich einfacher 
lesen als CAN-Bus).
Flag löschen wenn der CRC passt, neu booten (vom Bootloader ausgelöst).
Mit der Methode kannst du sogar das flashen unterbrechen 
(Spannungsausfall) ohne dass was daneben geht.

Feddisch. Braucht wenig code im Bootloader.

[Dr. Sommer (Gast)]

Nick M. schrieb:
> Firmware per CAN-Bus auf den Controller in einen Zwischenspeicher
> (EEPROM) ablegen.

Wenn der interne Flash groß genug ist, um zwei Firmware-Versionen 
aufzunehmen, brauchts das EEPROM nicht. EEPROM eigentlich sowieso nicht, 
NAND-Flash tut's auch und dürfte billiger sein.
Man kann auch einfach das Programm direkt überschreiben, und beim Booten 
die Prüfsumme testen, und im Fehlerfall den Bootloader in Endlosschleife 
laufen lassen.

[Michael R. (Gast)]

> Wie gehe ich dabei am Geschicktesten vor? Wie richte ich den Bootloader
> ein? Wie nutze ich Ihn?

Es gibt auch Controller, die werksseitig einen CAN-Bootloader intus 
haben. Da kenne ich z.B. die LPC11C2x, wofür es eine fertige und offene 
Host-Lösung gibt: https://www.fischl.de/can/bootloader/canflasherutnl/

[Gerd E. (robberknight)]

Nick M. schrieb:
> Firmware per CAN-Bus auf den Controller in einen Zwischenspeicher
> (EEPROM) ablegen. Mit CRC usw. überprüfen.
> Flag im Controller setzen, dass er neu flashen soll.
> Controller booten lassen, der sieht das Flag und der Bootloader holt
> sich die Daten aus dem Zwischenspeicher

genau so.

Allerdings würde ich auch kein EEPROM nehmen, sondern ein kleinen 
SPI-NOR-Flash. Gibt es für vielleicht 25 Cent in kleinen Stückzahlen. 
Die haben dann schon mehrere MByte Kapazität, also ein Mehrfaches Deines 
µC. Dadurch kannst Du auf dem Flashbaustein 2x (oder noch öfters) die 
gesamte Firmware ablegen.

Ich mache das bei mir so daß auf dem Flash immer zusätzlich noch eine 
alte, aber auf jedenfall bekannt gute Firmware abgelegt ist. Sollte eine 
neue Firmware einen Bug haben und ich damit nicht mehr in der Lage sein 
eine neue ins SPI-Flash zu übertragen, kann man an dem Gerät einen 
kleinen Taster drücken. Der resettet den µc und weist den Bootloader an 
diese Rettungsfirmware zu flashen. Von da aus kann man dann wieder über 
den normalen Weg eine gefixte Version einspielen.

Die Lösung über den Taster ist ein Weg, Reedschalter+Magnet oder Jumper 
auf der Platine wären andere Varianten. Hängt vom Gerät und Einsatzzweck 
ab was besser passt.

[Sebastian S. (amateur)]

Ich würde mir das 1000-fach dokumentierte Verfahren des Boot Step 
Loaders mal zu Gemüte führen.

Prinzipiell gilt nämlich:

Dem CAN-Bus ist es egal, was die zu transportierenden Daten bedeuten.

Da aber plötzlich eine sehr hohe Last im Bus erzeugt wird, kann es 
sinnvoll sein, die Anlage vorübergehend anzuhalten. Es sei denn, 
plötzliche, zeitliche Verzögerungen stören nicht.

Das wiederum kann entweder eine Fahrt in eine definierte Position 
bedingen, oder die komplette Speicherung des gerade aktuellen Status.

Ein einfacher Stopp ist in den seltensten Fällen empfehlenswert.

Was jetzt kommt ist praktisch reine Software. Es empfiehlt sich den 
eigentlichen Loader vom Programm getrennt zu halten. Das ist insofern 
auch recht einfach, weil dieser Teil fast nie ausgetauscht werden muss. 
Getrennt halten sollte auch die prozessorspezifischen Eigenheiten beim 
Beschreiben des Flash im Auge behalten. Auch ist es nicht ganz einfach 
den Stuhl unter dem Hintern zu tauschen, während man darauf sitzt.

[Nick M. (Gast)]

> Allerdings würde ich auch kein EEPROM nehmen, sondern ein kleinen
> SPI-NOR-Flash.

Kein Problem damit. Ich meinte damit eher "irgendein Speicher". Der kann 
natürlich auch im µC sein. Aber da ist ja nie genug Platz.
Aber natürlich, im µC geht es etwas eleganter, weil man dann auch ohne 
Zwischenschritt die neue Firmware starten kann.
Aaaaber ... Wie lange hält das an, dass intern noch genug Speicher ist? 
Wenn man langfristig denkt, kommt man um einen externen Speicher in der 
Größe des internen Speichers nicht drum rum.
Und ja, mehrere Images extern halten zu können ist alles andere als 
schädlich, die Kosten sind minimal.


Nick

[Sebastian W. (wangnick)]

Ben B. schrieb:
> Zum derzeitigen Aufbau:
> Ich habe eine Steuerplatine(für Verwaltungsaufgaben und Anbindung an ein
> Display) und diese ist mit mehreren, mehr oder weniger gleichen,
> Platinen via CANBUS (2.0A) verbunden.
>
> Grundaufbau der Platinen:
> - Microcontroller ATMEGA1284p bzw. ATMEGA32A
> - MCP2515 + MCP2551
> - ISP Schnittstelle zum Programmieren
>
> Nun möchte ich die Steuerplatine neu auslegen und einige Features
> ergänzen. Dazu gehören u.a. eine Ethernet Schnittstelle und die
> Möglichkeit einzelne Platinen in meinem System über den CANBUS mit einer
> neuen Firmware zu bespielen (statt per Hand über die ISP Schnittstelle).
>
> Ich weis bereits, dass ich einen Bootloader auf jeder Platine
> installieren muss.
>
> Ich würde gerne mit folgendem Schritt starten:
>
> Schritt 1: Mittels eines Interfaces (z.B. USB zu CAN) soll mit Hilfe
> eines PCs eine Platine via CANBUS auf eine neue Firmware aktualisiert
> werden.
>
> Wie gehe ich dabei am Geschicktesten vor? Wie richte ich den Bootloader
> ein? Wie nutze ich Ihn? Funktioniert mein Vorhaben mit dem bisherigen
> Aufbau übnerhaupt oder werden z.B externe Speicherbausteine auf den
> Platinen benötigt?
>
> In dieser Thematik bin ich absuluter Neuling und würde gerne lernen, wie
> ich an sowas ran gehen muss.

Hallo Ben,

ich sitze gerade mit meiner Gartenbewässerung an einem ähnlichen 
Prototyp.

Mein Ethernet-CAN-Gateway ist Atmega1284P/W5500-basiert, die Satelliten 
sind zur Zeit Arduino Nanos (Atmega32P), und ich verwende zur Zeit die 
NiRen MCP2515/TJA1050 CAN-Module. Dazu benutze ich jedoch noch einen 
RasPi mit Mosquitto und node-red.

Auf dem Gateway läuft eine Software die a) über CAN Daten und 
Neustartevents von den Satelliten empfängt und via MQTT and den RasPi 
schickt, und b) über MQTT nach Neustartevents gegebenenfalls neue 
Firmware oder Software im HEX-Format vom RasPi empfängt und über ein 
eigenes Protokoll über CAN an die Satelliten weiterreicht.

Der CAN-Bootloader auf den Satelliten ist dabei in der Lage sich 
nötigenfalls selbst zu überschreiben.

Insofern denke ich ja, dein Vorhaben sollte auch funktionieren.

Ansonsten ist mein Prototyp noch sehr ... prototypisch (siehe Foto) :)

LG, Sebastian

[mukel (Gast)]

Schau dir mal openblt an.

Für Atmegas müsstest du zwar eine Menge änderen, aber die Hostseite wäre 
fertig verfügbar.