Hallo zusammen, kennt jemand einen Mikrokontroller mit CAN-Interface, der von sich aus ein Konzept für den SW-Update über den CAN-Bus mitbringt? Ich meine damit einen uc mit internem CAN-Bootloader, dessen Flashspeicher man in einem CAN-Netz mit mehreren Teilnehmern updaten kann. Gibt es sowas? Die Frage wäre dann, wie alle diese Teilnehmer zu adressieren wären, das ist schon klar. Mir ist auch klar, dass ich sowas selber programmieren könnte, aber dann besteht immer die Gefahr des "brickings"; ein nicht überschreibbarer CAN-Bootloader wäre mir da schon lieber. Kennt jemand so ein Ding?
Der wird aber keinen vorinstallierten CAN-Bootloader besitzen.
Christian H. schrieb: > Der wird aber keinen vorinstallierten CAN-Bootloader besitzen. Ja, das ist genau mein Problem: Ich brauche einen uc mit fest installiertem Bootloader bzw. Flash-programming-routine
Christian Rausch schrieb: > ein nicht > überschreibbarer CAN-Bootloader wäre mir da schon lieber. Das liegt doch an dir: wenn du einen Bootloader schreibst oder modifizierst, kannst du ja leicht dafür sorgen, dass er nicht von CAN aus überschreibbar ist. Die Frage ist bloss, wie du ihn dann überhaupt reinkriegst, z.B. JTAG. Gruss Reinhard
Christian Rausch schrieb: > Mir ist auch klar, dass ich sowas selber programmieren > könnte, aber dann besteht immer die Gefahr des "brickings"; ein nicht > überschreibbarer CAN-Bootloader wäre mir da schon lieber. Viele Microcontroller bieten die Möglichkeit, einen Teil des Flash zur Laufzeit mit einem Schreibschutz zu versehen. Also gibt es in diesem Fall kein "bricking". Auch wenn ein Bootloader ab Werk drin ist, wird dieser üblicherweise im Flash residieren und kann theoretisch gelöscht werden.
Der PIC hat die Möglichkeit den "Bootblock" vor Überschreiben zu schützen (Configurationsbit). Das wird es doch auch bei anderen Controllern mit CAN-Bus geben. Man kann im Bootloader sonst auch selber eine Funktion einbauen dass der Bootloader oder wichtige Teile nicht umzuprogrammieren sind. Das Programmieren macht ja der Bootloader selber und dann kann keiner dazwischenpfuschen. Nach einem Reset kann man erst eine Abfrage starten ob der Bootloader oder die Betriebssoftware gestartet wird. Und einen Reset durch die Stromversorgung bekommt man doch immer hin, oder? Solange man ganz sicher das Abfragekriterum zum starten des Bootloaders einhalten kann sollte es keine Probleme geben. Wenn man wirklich nur an die beiden CAN-Busleitungen des Controllers kommt könnte man ja z.B. einen Kurzschluss zwischen den beiden Eingängen machen und durch Abfrage beim Booten in den Bootloader schicken. Allerdings wäre ein fertiger Bootloader die kleinste Entwicklungsarbeit. Bastel auch gerade an einer Schaltung mit CAN-Bootloader. Den Bootloader habe ich schon erfolgreich zum laufen bekommen. Fragt sich nur wie man eine 100% sicheres Abfragekriterium beim Booten erzeugen könnte. Aber eine fertige Bootloaderlösung wäre natürlich auch interesant.
IngoF schrieb: > Bastel auch gerade an einer Schaltung mit CAN-Bootloader. Den Bootloader > habe ich schon erfolgreich zum laufen bekommen. Welcher Controller? In meinem Fall AT90CAN128. Ich bin auch gerade dabei, einen CAN-Bootloader zu bauen, der mir genehm ist. Die wenigen verfügbaren passen mir nicht. Bisher bin ich aber noch bei der Planung. Code existiert noch nicht. Ist Deiner verfügbar - so zum spicken? > Fragt sich nur wie man eine 100% sicheres Abfragekriterium beim Booten erzeugen könnte. Ich warte nach einem Reset ca 500ms auf eine bestimmte CAN-Nachricht. Erst wenn diese kommt, öffnet der Bootloader seinen kompletten Befehlssatz. Nach 500ms startet dann das Hauptprogramm. Einen Reset werde ich über CAN und dem Watchdog auslösen.
Manche STM32 haben einen CAN bootloader drin Gibt auch eine App. Note dazu http://www.stmcu.org/download/index.php?act=down&id=2954
Danke für all Eure Antworten. Den 11c24 habe ich mir schon angeschaut; der kommt meinen Vorstellungen schon ganz nahe, allerdings habe ich mit diesem uc das Problem, wie ich im Netzwerk genau diesen uc selektieren kann und von den anderen Teilnehmern, die keinen SW-update bekommen sollen, unterscheide. Das geht mit diesem uc nämlich nicht. Mit den selbergeschriebenen Lösungen gibt es das Problem, dass ich mir eben 1. die Lösung selber schreiben muss (Aufwand) und 2. den Bootloader über eine andere Methode (JTAG, UART) erst mal reinladen muss und anschließend (danke für den Tipp) mittels Jumper vor dem Überschreiben schützen muss. Aber nochmal die Frage: Gibt es denn da keine fertigen Lösungen hzw. Mikrokontroller die das von sich aus können? Das Problem müssen doch noch mehr Leute haben!?
Christian H. schrieb: > Welcher Controller? In meinem Fall AT90CAN128. Habe einen PIC18F2580 Christian H. schrieb: > Ist Deiner verfügbar - so zum spicken? Ja, ist der AN247 von Microchip. Den Code wirst Du dann wohl nicht verwenden können... Christian H. schrieb: > Ich warte nach einem Reset ca 500ms auf eine bestimmte CAN-Nachricht. Ich bin noch auf der Suche nach dem Kriterium. Der AN247 löst das dadurch dass das letzte EEPROM-Byte den Wert FF hat. Man muss also noch eine Firmware haben die Das letze Byte programmiert. ..... Das habe ich natürlich rausgeschmissen. Die Nachricht muss dann aber die "Seriennummer" enthalten. Sonst kannst Du die CAN-Knoten ja nur komplett neu flashen. Es gibt beim PIC eine 4Byte-ID die ich dann einmalig programmiere und dannach vor überschreiben schütze. Dann kann man schon mal ausschließen dass man ausversehen eine Adresse vergibt die schon existiert. Bei mir werde ich wohl den Bootloader noch so umbauen dass nur einer gleichzeitig programmiert werden kann. Kann denn noch irgendwas schief gehen dass er das CAN-Telegramm nicht empfängt? Gruß Ingo
IngoF schrieb: > Wenn man wirklich nur an die beiden CAN-Busleitungen des Controllers > kommt könnte man ja z.B. einen Kurzschluss zwischen den beiden Eingängen > machen und durch Abfrage beim Booten in den Bootloader schicken. Ich komme überhaupt nur an die CAN-Busleitungen des gesamtes CAN-Bus. Wie kann ich dem Busteilnehmer x sagen, dass ich ihn updaten will, die Busteilnehmer y,z, usw. aber nicht?
Danke für den Link, Jörn; sehr interessant, habe den Test kurz überflogen: was nicht daraus hervorgeht, ist, wie ich gezielt einen Busteilnehmer (und nur diesen) in den Bootloader-Modus bringe. Das geht doch üblicherweise nur durch Betätigung eine uc-Pins bei Reset o.ä.!?
Christian Rausch schrieb: > Das geht doch üblicherweise nur durch Betätigung eine uc-Pins bei Reset > o.ä.!? Man könnte über eine spezielle CAN-Nachricht das Hauptprogramm dazu bringen, einen Watchdog-Reset auszulösen. Danach müsste eigentlich der Bootloader ausgeführt werden. Also 1. Reset-Nachricht an einen definierten Knoten senden 2. Nachricht an den Bootloader schicken, damit dieser die Kommunikation startet. 3. Flash oder EEPROM per Bootloader schreiben/lesen 4. Reset auslösen 5. Hauptprogramm läuft wieder los Problematisch ist jedoch, wenn das Hauptprogramm keine Reset-Nachricht auswerten kann.
Renesas hat sowas für ein paar ihrer Controllerserien, genaueres für ältere hier: http://documentation.renesas.com/doc/products/mpumcu/apn/reu05b0067_mcuap.pdf Für RX600 hier: http://documentation.renesas.com/doc/products/mpumcu/apn/rx/r01an0235eu0121_rx.pdf Vielleicht auch zum Abgucken/Anregung für andere Comtroller geeignet. Beispielprojekte sollten auch irgendwo unter den Appnotes der jeweiligen µCs zu finden sein.
Christian Rausch schrieb: > Danke für den Link, Jörn; sehr interessant, habe den Test kurz > überflogen: was nicht daraus hervorgeht, ist, wie ich gezielt einen Dazu gibt es auch eine App Note :) https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/18225/AN2606.pdf Dazu benötigt man die Pin Boot0 und Boot1 in der ensprechenden Konfiguration und dar Baustein startet dann im Bootloader Modus.
Ok, die Appnote habe ich jetzt gelesen: Der STM32F105xx und der STM32F107xx wären wohl geeignet; die haben einen CAN-Bootloader. Aber wie aktiviere/deaktiviere ich das Ding? Ich muss ja , wie in Kapitel 5.2 beschrieben, den BOOT0 pin auf high (und den BOOT1 pin auf low) legen während des Resets. Damit aktiviere ich den Bootloader, der anschließend auf einen Frame mit id=0x79 an CAN_RX2 wartet und, wenn dieser kommt, in den command-modus geht. Wenn nicht, dann gibt's einen System Reset. Damit das funktionieren kann, brauche ich sowas wie einen externen 1-bit-GPIO-Baustein mit Speicherfunktion (EEPOT?): 1. Wenn meine Anwendung läuft, schicke ich Ihr ein Kommando, welches zur Folge hat, dass der BOOT0-Pin beim nächsten RESET auf "1" gesetzt wird und dadurch der CAN-Bootloader aktiviert wird. 2. Über den CAN-Bootloader läuft jetzt der SW-Update: Der Flashspeicher wird neu programmiert 3. Die Anwendungs-SW wird zuletzt über den CAN-Bootloader mit dem "go"-Kommando gestartet. Eine der ersten Aktionen der Anwendungs-SW ist das Zurücksetzen des BOOT0-Pins, damit beim nächsten RESET die Anwendung startet und nicht der Bootloader. Macht das Sinn? Könnte gehen, oder? Hört sich trotzdem etwas strange an. Was kann man sonst noch nehmen außer dem EEPOT?
Sorry, habe den Schritt 1.a) zwischen Punkt 1 und 2 vergessen: 1. Wenn meine Anwendung läuft, schicke ich Ihr ein Kommando, welches zur Folge hat, dass der BOOT0-Pin beim nächsten RESET auf "1" gesetzt wird und dadurch der CAN-Bootloader aktiviert wird. 1.a) Die Anwendungs-SW löst einen System-Reset (über den Watchdog?) aus und der Bootloader startet 2. Über den CAN-Bootloader läuft jetzt der SW-Update: Der Flashspeicher wird neu programmiert 3. Die Anwendungs-SW wird zuletzt über den CAN-Bootloader mit dem "go"-Kommando gestartet. Eine der ersten Aktionen der Anwendungs-SW ist das Zurücksetzen des BOOT0-Pins, damit beim nächsten RESET die Anwendung startet und nicht der Bootloader.
Du suchst das Dual bank boot feature. Ich mach es etwas anders. Mein bootloader kann kein CAN, der schreibt nur die Firmware an die richtige Stelle (ich benutze ein externes EEProm für den Zwischenspeicher). Die Firmware kann dann im laufenden Betrieb die neue Firmware empfangen und wenn der DL fertig ist (dauert so 10-15min) wird neu gestartet und der BL tut den Rest. Vorteil hier, CAN ist nicht sehr performant und man kann den BUS relativ schnell mit Daten dicht machen. Andere Geräte wären dann natürlich im Nachteil und die Funktionalität beeinträchtigt. Hat alles sein für und wider. -..-
Auch interessant! SW-Update im laufenden System, sozusagen? Das wäre auch für mich ein interessantes Feature. Danke für den Tipp!
Christian Rausch schrieb: > SW-Update im laufenden System, sozusagen? Das wäre > auch für mich ein interessantes Feature. Da musst du dir aber schon sorgfältig überlegen, was in dem Moment passiert - ich möchte z.B. nicht in einem Auto sitzen, bei dem bei 200 km/h auf der Autobahn gerade neue Firmware in das Bremssystem geladen wird ("update läuft - versuchen sie später nochmal zu bremsen"). Gruss Reinhard
Christian Rausch schrieb: > Den 11c24 habe ich mir schon angeschaut; der kommt meinen Vorstellungen > schon ganz nahe, allerdings habe ich mit diesem uc das Problem, wie ich > im Netzwerk genau diesen uc selektieren kann und von den anderen > Teilnehmern, die keinen SW-update bekommen sollen, unterscheide. Das > geht mit diesem uc nämlich nicht. Natürlich kann man das mit den LPC11Cxx machen. Wäre ja sonst auch der Hammer. Schau dir im UM10398 mal die Sections 26.6 und 26.7 an. Die Zauberworte heißen u.a. IAP, SDO und UID.
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.