Hallo, momentan flashe ich mein Board über den eingebauten Bootloader per RS232 mit FlashMagic. Nun möchte ich den Controller gerne über die Ethernetschnittstelle flashen. Die Schnittstelle funktioniert und stellt über einen kleinen Webserver eine Testseite dar. Also vermutlich brauche ich dann einen anderen Bootloader und ein Programm, dass den Code über Ethernet rüberschiebt. Das Thema Bootloader ist noch neu für mich. Ist meine Vorstellung mit Bootloader + Programmiertool vollständig, oder brauche ich da noch mehr? Ist das überhaupt möglich? Wie geht man da prinzipiell dran? Gruß Felix
Felix schrieb: > Ist das überhaupt möglich? Ja. > Wie geht man da prinzipiell dran? Eine geeignete Software einfallen lassen. Ich war mal an so einem Ding dran, einen LPC2xxx über Schnittstelle zu fernupdaten. Ist aber nicht weiter gereift, da ich dann in der Krise gefeuert wurde. Hab mich dann um die Dinge auch nicht mehr weiter gekümmert. Die Überlegungen zur groben Funktionsweise hatte ich aber schon. Wichtig ist auf jeden Fall, daß das nicht vor Ort greifbare Gerät beim fehlerhaften Flashen unter allen Umständen weiter läuft, als wäre nichts passiert. Man schreibt das Update in einen freien Speicherbereich, der µC sollte da was reichlich frei haben. Am Ende setzt man die Vektoren für Programmstart und Interrupts neu. Das ist ein ganz kleiner kritischer Augenblick, wo gerade der Strom nicht ausfallen sollte. Ein spezieller Bootloader ist nötig, der das alles managt.
Hallo Wilhelm, danke für die Antwort. Kannst du mir sagen, ob ich den originalen Bootloader unangetastet lassen kann und einen eigenen BL zusätzlich aufspielen kann? Dann hätte man an der Stelle eine Redundanz als Backup. Also so kritisch wie bei deiner Anwendung ist das bei mir nicht, da das Gerät nicht unerreichbar sein wird. Es geht dabei eher um Komfort bzw. Unterstützung. Es wäre immer jemand in der Nähe des Gerätes Verfügbar während des Updates. Gibt es schon freie Tools, die das Update über Netzwerk rüberschieben? Dann bräuchte ich nur eine Seite selber schreiben. Hast du vielleicht noch einen Tipp, wo man sich gut zum Thema BL einlesen kann? Gruß Felix
Hallo Felix, einen gesonderten Bootloader brauchst du nicht, da der interne BL unveränderlich ist. Im Zweifelsfalle geht dann immernoch ISP via UART0. Den IAP-Vorgang musst du aber wohl per Hand implementieren, der interne BL kennt nur ISP, kein IAP.
Es gibt auch direkt von NXP einen Ethernet-Bootloader http://www.nxp.com/documents/application_note/AN10744.pdf
Der originale Bootloader ist FEST im Controller drin. Da ksnnst du überhaupt nichts ändern. FlashMagic bietet ja schon Programmierung per LAN an. Ich nehme an das man bei denen die entsprechende Software bzw. Dokumentation dafür bekommt. Diese Software musst du dann in deine eigene Software einfügen. Stichwort: IAP (in application programming).
Danke für die Antworten. IAP ist doch ein nützliches Stichwort. Den Ethernet-BL von NXP habe ich auch eben gefunden, den werde ich mir mal anschauen. Bei Flashmagic habe ich nur CAN/CANOPEN BL gesehen und der ist recht teuer. Programmieren per LAN mit Flashmagic wäre natürlich interessant. Gruß Felix
Also der Ethernet BL von NXP hört sich so an, als könnte er meine Aufgabe lösen. Da ist sogar ein PC-Tool bei. Ich muss nur die Boardinitialisierung (Peripherie) anpassen und den Entry Point für das eigentliche Programm nach hinten legen. Der Rest könnte schon so funktionieren. Leider kenn ich mich mit den StartUp Sachen bei den ARMs nicht aus. Ich vermute die Entry Point Einstellung irgendwo im Umfeld der startup.s, aber finden konnte ich dort nichts. Da ich kein Keil benutze, sondern mit der Yagarto Toolchain arbeite, muss ich das irgendwo in den Dateien selber einstellen. Das Grundgerüst habe ich aber nicht selber erstellt. Hat jemand einen Hinweis für mich, wie ich den Entry Point ändere bzw. wo der zu finden ist? Gruß Felix
Kann mich keiner auf die richtige Spur bringen? Ich finde dazu einfach nichts...
Da es keinen Standard gibt, kann man ohne das "Grundgerüst" gesehen zu haben nicht viel schreiben. Im Prinzip für die Anwendung: - Die Startaddresse des Speicherbereichs der Anwendung wird im Linker-Script (Dateiendung oft .ld) festgelegt, dort im mit MEMORY startenden Bereich schauen nach ROM oder FLASH und in der entsprechenden Zeile den Wert hinter ORIGIN anspassen. - Im Linker-Script im Bereich der Output-Section für Code (Meist beginnend mit .text) sicherstellen, dass dort die Input-Section des Reset-Handler zuerst steht (oft mit .init bezeichnet). Evtl. steht dort schon die Input-Section des Exceptions-Vectors (.vecotors oder ähnlich), ist auch ok, da die erste Anweisung darin zum Reset-Handler springt. - Im Linker-Script im Bereich der Output-Section für initialisierte Daten (.data) Platz für den Vector im RAM freimachen. (a) Man kann dazu die im MEMORY-Bereich ORIGIN von RAM erhöhen oder gibt (b) einfach die Input-Section, in der die Tablelle abgelegt ist als erstes bei .DATA an - ist praktischer (s.u.) - Falls oben Methode (a) gewählt wurde: vor Aktivierung bzw. Verwendung von IRQ, FIQ, SWI die Vektortabelle aus der Vorlage im Flash kopieren. Bei Methode (b) wird die Vektortabelle ohnehin schon mit dem normalen .data-Init kopiert. - Dem Kern mitteilen, wo der die Vektortabelle findet (siehe Manual REMAP). Anpassung der Adresse, zu der der Bootloader zum Start der Anwendung springen soll, ist wenn richtig erinnert in der pdf-Datei von NXP beschrieben.
Felix schrieb: > Hallo Wilhelm, > danke für die Antwort. > Kannst du mir sagen, ob ich den originalen Bootloader unangetastet > lassen kann und einen eigenen BL zusätzlich aufspielen kann? Entschuldige, ich habe da mit den Begriffen was durcheinander gebracht. Und daß ich nicht wieder früher in den Thread schaute. Bei ARM schaue ich so gut wie nie, und hier bei µC und Elektronik verschwindet der Thread auch mal schnell aus dem Fokus. Der originale Bootloader im LPC bleibt selbstverständlich unangetastet. Für den gibt es zwar auch Updates, aber das muß man nicht. Unter Umständen kann man den originalen Bootloader im Extremfall auch kaputt flashen, dann ist der Baustein (und die ganze Baugruppe/Platine) für die Mülltonne. Denn irgend eines der seriellen Tools über RS232 konnte auch ein Bootloder-Update. Das Stichwort IAP wurde aber schon genannt. Du mußt dir wirklich eigene Software ausdenken, wie man das lösen kann. Irgend was kleines an Software muß ja während des Updates auf jeden Fall weiter laufen. Du brauchst da für deine Anwendung eher doch keine 2 Speicherbereiche, wenn ich das richtig verstehe. Statt Bootloader brauchte man eher sowas wie einen eigenen kleinen Bootmanager im Flash. Vielleicht kann man dort einen spartanischen Ethernet-Treiber drin lassen, der nie neu geflasht wird. Wie schon gesagt, meine eigene Lösung war damals noch nicht völlig gereift. Daher kann ich jetzt auch nichts zum garantierten Erfolg beitragen. Jedenfalls ist es nicht ganz so trivial, wie eine Blink-LED zu programmieren. Das ist sicher. Auf jeden Fall muß man sich vorher mal genau das Verhalten definieren, was das Gerät beim Update können bzw. nicht können muß, das ist fast wichtiger als die Software selbst. Am besten schriftlich festhalten. Und dann abchecken, ob dies dann so machbar ist. Sonst dreht man sich auch schnell im Kreis.
Das hat schon mal geholfen. Vielen Dank! Die Linkerdatei lag in einem anderen Ordner als die startup. Es handelt sich sogar um ein von Martin Thomas angepasstes ;-) Soweit ich das nachvollziehen konnte, ist dort schon alles passend eingestellt (siehe Anhang). Kann da bitte noch mal jemand drüber schauen? Ich muss dann vermutlich nur noch die Startadresse für ROM ändern, damit Platz für den secondary Bootloader entsteht. Die Datei ist übrigens laut Kommentar von 2007, muss ich mich da mal um was aktuelleres kümmern? Was mich ein bisschen wundert ist, dass im MEMORY Bereich keine Werte für ramstack usbram ethram sdram eingetragen sind. Werden dann Standardwerte verwendet? Gruß Felix
Mir stellt sich da gerade noch eine Frage, mal angenommen der secondary Bootloader funktioniert. Dann kann ich den ja so aufspielen, wie ich bisher das Programm aufgespielt habe (über Flashmagic und den internen Bootloader). Gibt es denn auch eine Möglichkeit den secondary Bootloader und das eigentliche Programm in einem Rutsch aufzuspielen. Das würde die Erstprogrammierung vermutlich sehr beschleunigen. Der secondary Bootloader soll dann ja eigentlich erst für Updates über Ethernet benutzt werden. Gruß Felix
Hi, hier gibt es zumindest einen USB-Bootloader für den 2148 (Olimex-Board): Beitrag "LPC2148 IAP USB Bootloader" Ich kenne den 2378 nicht, wird sich von der Vorgehensweise aber wohl nicht so stark unterscheiden... Gruß Andreas
Danke Andreas, aber es gab weiter oben schon einen Hinweis auf einen Ethernet Bootloader, der sehr vielversprechend aussieht. Hat denn jemand noch Antworten zu meinen Fragen vom 27.?
Felix schrieb: > Das hat schon mal geholfen. Vielen Dank! > Die Linkerdatei lag in einem anderen Ordner als die startup. > Es handelt sich sogar um ein von Martin Thomas angepasstes ;-) Lange her, düfte von den ersten Spielereien mit LPC23xx sein. > Soweit ich das nachvollziehen konnte, ist dort schon alles passend > eingestellt (siehe Anhang). Kann da bitte noch mal jemand drüber > schauen? Ich muss dann vermutlich nur noch die Startadresse für ROM > ändern, damit Platz für den secondary Bootloader entsteht. Das auf jeden Fall. Damit die Größenkontrolle des Linkers auch funktioniert den Wert, der zu ORIGIN dazuaddiert wird von LENGTH abziehen. Mit "KEEP(*(.vectmapped))" wird Platz für die Vectortabelle reserviert. Falls der Startup-Code allerdings die von mir seinerzeit angepasste Version aus dem NXP/Keil Beispielcode ist, dann fehlt noch einiges im Starup-Code damit Remapping funktioniert (section fuer Vectors, Remapping, vgl. Aufzählung oben). Das Linker-Script hatte ich seinerzeit schnell mal aus einem anderen Beispiel zusammengebastelt. > Die Datei ist übrigens laut Kommentar von 2007, muss ich mich da mal um > was aktuelleres kümmern? Falls kein C++ verwendet werden soll (bei CTORS der statischen Objekte hat sich etwas geändert) und den Speicherbereich für USB und Ethernet RAM nicht explizit mit C-sections ansprechen will sollte das alte Skript reichen. Aktuelleres findet sich sicher irgendwo auch noch, z.B. hat ChaN ein Beispiel mit LPC23xx für sein FatFs mit GNU Cross-Toolchain veröffentlicht. > Was mich ein bisschen wundert ist, dass im MEMORY Bereich keine Werte > für ramstack Section für Stack ist schon drin. Ob diese auch verwendet wird, kann ohne den Startup-Code gesehen zu haben nicht gesagt werden. > usbram > ethram Diese sind z.B. in ChaNs Linker-Script zumindest als MEMORY-Eintrag enthalten. Speicherbereiche werden aber, wenn richtig erinnert, in seinem Beispiel auch nicht verwendet. > sdram Im Sinne von externem RAM? Dann RAM ensprechenden Speicherbereichen zuweisen und im Startup-Code vor erstmaliger Verwendung des externen Speichers (typische .data-Intialwerte kopieren und .bss löschen) das Speicherinterface aktivieren. > eingetragen sind. Werden dann Standardwerte verwendet? Der Linker kennt die Adressebreiche des Controllers nicht. Falls Daten oder Funktionen im Speicherbereich für USB und/oder Ethernet (da gibt es w.r.e. Einschränkungen) verwalten will, kann man diesen per Attribut Section (vgl. gcc Dokumentation) eine Input-Section zuweisen und im Linker-Script ergänzen, dass diese in Output-Sections enthalten sind, die man im entsprechendenen Memory-Bereich ablegt.
Danke für die Antwort. Das sieht noch nach ein bisschen Arbeit für mich aus. Gibt es irgendwo eine gute Einführung zum Aufbau der Startup Datei und des Linkerskripts? Wie kommt man in das Thema gut rein? Anbei mein Startup Skript. Momentan funktioniert das ja soweit, aber wie gesagt, von dem Startup Kram und dem Linkerskript habe ich keine Ahnung. Ich kann auch (noch) nicht beurteilen, ob der Ethernet Bootloader zB den Ethernet RAM braucht und benutzt. Gruß Felix
Hallo Felix, ich sitze gerade an der gleichen Aufgabe und finde keine weiteren guten Hilfen mehr im Netz. Dahet die Frage, bist du zu einer Lösung gekommen und klappt es nun mit eigenen Applicationen? Gruß David
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.