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