Vorab - ich habe noch nie mit Bootlader gearbeitet. Es geht um Mega8 und
Mega16/32, ein Gerät wird auch einen Mega128 erhalten. Dazu jeweils
einen MCP2515, es werden verschiedene Geräte am Bus hängen. Bin gerade
am CAN-Bus planen und überlege, ob ich eine Software-Updatemöglichkeit
überhaupt einplanen soll. Schön wäre es, wenn es ginge...
Also kurze Frage: ist es überhaupt möglich? Ich müsste also auf eine
bestimmte Botschaft hin dass normale Programm verlassen können, in den
Bootladersektor springen, dort CAN-Nachrichten empfangen, in welchem
Format auch immer das dann übertragen wird, und dieses in den "normalen"
Flash schreiben.
Also keine Einzelheiten, nur ob es prinzipiell möglich ist.
Hallo crazy horse,
klar geht das, und je mehr Microcontroller im System sind, desto
sinnvoller wird es auch.
Hast Du ein Schnittstellenmodul, um auf den CAN vom PC aus zuzugreifen?
Welches? Ggf. an dessen Protokoll anlehnen.
Ich baue mir auch gerade einen Bootloader - für meinen Hausbus. Ich
benutze den MCP2515 und Mega16 bzw. Mega32. Wenn Du willst, können wir
uns gerne mal zusammenmailen.
Viele Grüße, Stefan
na, das klingt ja schon mal beruhigend.
Es wird ungefähr 8 verschiedene Gerätearten im System geben, von einigen
nur ein einziges, von anderen bis zu 32.
Chef des Ganzen wird ein Beck-IPC, der würde dann über Ethernet
angebunden, darüber würde dann auch ein Software-update der Peripherie
laufen, prinzipiell aber auch über Modem/GSM, wenn das Ding in der Pampa
hängt.
Wird recht umfangreich das Ganze, umso sorgfältiger muss die Planung
sein.
Z.B. muss dann auch Hard- und Software-Revision auslesbar sein, jede
Menge Datentransfers, Parametrierungen, Alarmwerte, Schnittstellen zu
anderen Feldbussen und und und. Wahrscheinlich werde ich gleich auf
CAN2.0B gehen, die 11bit gehen schneller aus als man denkt, wenn man
sinnvolle Gruppen bilden will. Und überall ein bisschen Reserve hat noch
nie geschadet :-)
Wenn Du es einfach haben willst mit dem Bootloader, dann ist es
sinnvoll, dem Bootloader die gesamte NRWW-Sektion - also die maximal
mögliche Bootsektor-Grösse - zu gönnen. Nur dann kann nämlich der
Bootloader das gesamte Applikations-Flash beschreiben, ohne auf das
Flash warten zu müssen.
Das hat den Vorteil, dass Du den Bootloader wie ein ganz normales
Programm schreiben kannst - mit Interrupts, die die Daten vom CAN holen
und in ein FIFO füllen, und mit einer main-Schleife, die das Parsen der
CAN-Daten und das Flash-Programmieren übernimmt.
(Im anderen Fall bleibt Dein AVR während dem Flash-Programmieren stehen
-> Essig mit IRs. Der Bootloader muss dem Host also vor jedem
Programmiervorgang (alle 128 bzw. 256 Bytes) mitteilen, dass er eine
Weile abwesend ist bzw. der Host nichts schicken darf,).
Wichtig ist auch die Geschwindigkeit des CAN-Bus: ist der CAN schneller
mit der Übertragung der Flash-Daten oder der ATmega mit dem
Programmieren einer Page? Im letzteren Fall kannst Du ev. auf ein
Handshake verzichten und nur am Schluss der Flash-Programmierung eine
Kontrolle des Applikations-Flash z.B. per CRC machen.
Für den CAN brauchst Du ja eine eindeutige ID. Die muss schon im
Bootloader stehen, damit Du jeden einzelnen adressieren kannst.
Kleiner Insider-gg-Tip für die avr-libc:
Wenn Du IRs aktiviert hast, solltest Du während den Programmierbefehlen
unbedingt die IRS kurzzeitig sperren. Die Befehle zum
Flash-Programmieren müssen nämlich aus Sicherheitsgründen direkt
nacheinander kommen, sonst sind sie ungültig (siehe AVR-Manual dazu).
Kommt Dir ein IR dazwischen, wird der Flash-Schreibbefehl dann nicht
ausgeführt.
So gehts richtig:
1
cli();
2
boot_page_write(page_open_adr);// dito bei erase-befehl, etc.!
3
sei();
boot_page_write startet nur den Flashvorgang und kommt dann sofort
zurück, die IRs sind also nur kurz gesperrt.
Viele Grüße, Stefan
so, gerade mal die betreffende Seiten im Datenblatt angeschaut, da komme
ich selbst beim Mega8 noch zurecht, 64Byte/page schreiben in max. 5ms.
CAN soll mit 125kBit laufen, macht also selbst bei 11bit-ID und ohne
stuff-Bits mindestens 7ms für 64Byte, passt also in jedem Fall.
Wie ich das genau machen werde, steht noch in den Sternen, soweit bin
ich noch lange nicht...
Was passiert denn eigentlich, wenn ich ein paar pages geschrieben habe
(das eigentliche Programm also zerstört ist), und dann wird die
Übertragung unterbrochen? Sei es Stromausfall, ein Kabelausfall wie auch
immer oder sonst was anderes? Dann ist das Teil über CAN ja erst mal
nicht mehr erreichbar? Oder aus Versehen eine fehlerhafte Version
aufgespielt, die hängenbleibt? Gibt es da noch einen Noteingang?
Aber Danke erst mal für die nützlichen Infos, wie gesagt, habe mich
damit bis jetzt überhaupt noch nicht beschäftigt.
>Was passiert denn eigentlich, wenn ich ein paar pages geschrieben habe>(das eigentliche Programm also zerstört ist), und dann wird die>Übertragung unterbrochen? Sei es Stromausfall, ein Kabelausfall wie auch>immer oder sonst was anderes? Dann ist das Teil über CAN ja erst mal>nicht mehr erreichbar? Oder aus Versehen eine fehlerhafte Version>aufgespielt, die hängenbleibt? Gibt es da noch einen Noteingang?
Normalerweise schreibst Du den Bootloader als total eigenständiges
Programm. Beim ATmega kannst Du per Fuse die Bootvektoren einschalten,
dann startet der AVR nach einem Reset nicht bei 0000h, sondern eben im
Bootbereich.
Dort steht der Bootloader. Und bleibt auch da. D.h. Du machst immer nur
ein Update der Applikation, nie des Bootloaders. Dann kann es nie
passieren, dass Dir der Kram komplett abstürzt (theoretisch wenigstens
nicht ...)
Im Bootloader-Programm hast Du natürlich alle Möglichkeiten:
Sinnvoll ist, erstmal zu testen, ob die Applikation geladen werden soll.
Ich warte dazu 3s auf einen Boot-Befehl zum Host. (Dieses Delay will man
sicher nicht in jeder Anwendung haben, dann muss man sich eben was
anderes ausdenken). Danach wird getestet, ob die Anwendung, die im Flash
steht, auch gültig ist, z.B. per CRC *. Eine abgebrochene oder sonstwie
gestörte Übertragung fällt also auch raus. Wenn die Anwendung gültig
ist, wird sie gestartet, der Bootloader hat seinen Teil getan. Wenn die
Applikation korrupt ist, wartet der Bootloader endlos auf Boot-Daten vom
Host.
*:
Dazu muss im Applikations-File eine Prüfsumme mit integriert werden.
Die einfachste Art, den Bootvorgang zu starten, ist ein Reset: danach
ist der Bootloader erstmal aktiv. Hat den Vorteil, dass alles im AVR
definiert ist, und nicht durch die Applikation irgendwelche Register
umgedreht wurden, die den Bootloader an der korrekten Arbeit hindern.
Wenn es ohne Reset gehen muss, dann sollte der Bootloader sicherstellen,
dass wirklich alle Register initialisiert werden, und sich nicht auf
Reset-Defaults verlassen.
Viele Grüße, Stefan
Hallo
Hab gerade gesehen das du dich mit einem Bootloader schon mal
beschäftigt hast.
Ich nehme an das er bei dir schon funktioniert.
Ich habe nun die gleiche Aufgabe, ich habe 1 bis 64 Module mit einem
ATmega16m1. Die Dinger sind so schön verbaut das ich da nicht mehr
rankomme -> Lösung: Bootloader
Kannst du mir Infos zu deiner Lösung schicken?
Ich verwende einen PEAK CAN-USB Adapter für die PC-CAN kommunikation.
Vorab schon mal Danke
MfG
Rainer
www.atmel.com/Images/doc8247.pdf vielleicht?
Wobei ich "4k" und "slim" für ein wenig seltsam halte, alles braucht man
davon wahrscheinlich auch nicht.
Was mich bisher vor allem auch von einem Bootloader abgehalten hat ist
das man auf dem PC noch die Gegenseite dafür benötigt.
Hallo,
ich benutze den Bootloader von dieser
http://www.kreatives-chaos.com/artikel/can-bootloader Seite. Bis auf das
UI und ein paar Timing Probleme, Funktioniert das eigentlich sehr Gut.
Ich habe mir ein kleine Programm in VC++ geschrieben, welche das Phyton
Programm aufruft. Das tut auch einigermassen. Zu mehr reichen meine VC++
Kentnisse nicht aus.
Gruss
Frank
Hallo zusammen.
Hab an einem ATmega16M1 den Bootloader von Atmel eingebaut. Flashen über
FLIP-PC Software mit einem PEAK-CAN USB Adapter.
Achtung die Application Note von ATMEL AVR076 mit dem ISR Compiler
enthält Fehler!!
Das Linker File wurde vom Mega32 kopiert und nur der Text aut Mega16
geändert, sämtliche Speicherbereiche sind hier falsch!!
Falls das jemand testen will kann ich die aktuellen Linker Files
zusenden.
Zum Compilieren braucht man den IAR Compiler
(siehe Compiling Notes AVR076),
den gibts als eval.Version:
Time Limited -> 30 Tage voller Umfang
Size Limited -> zeitlich unbegrenzt, auf 4k limitiert -> hört sich
verführerisch an für den 4k Bootloader -> FALSCH, da im Projekt
ASM-Befehle drin sind geht es trotzdem nicht.
Ich habs mit der Time Limited Version gemacht.
MfG
Den Fehler habe ich bei ATMEL gemeldet und wurde bereits bestätigt.
Vielleicht gibts dann mal eine neue Version.
Super wär natürlich wenns für den AVRGCC verfügbar wäre (wie für den
AT90CAN128/64/32, der hat aber 5,4k)
Schöne grüße aus Österreich
Häng das doch mal bitte hier an, das interessiert mich durchaus, nur
testen kann ich das gerade nicht.
Wobei noch interessant wäre, ob man den mit den Vector-CAN Tools
benutzen kann.
