Hallo allerseits! Ich hab hier folgende Problematik, mit der ich gedanklich noch nicht weiterkomme. Ich möchte/muß einen proprietären Bootloader für ARM7 schreiben der es mir ermöglicht, den Controller in-system z.B. über UART, CAN, etc. zu flashen. Nur hat der ARM7, bzw seien wir mal genauer, der LPC23xx ja keinen dedizierten Bootloader-Bereich, wie ich es vom AVR bzw. anderen Controllern her kenne (oder?). Wo liegt eigentlich der eingebaute Bootloader? Kann man den durch einen eigenen ersetzen? Was passiert mit den Interrupts (Mapping)? Es wird ja sicher möglich sein, einen eigenen Bootloader zu schreiben. Nur fehlt mir im Moment so ein bisschen der Startpunkt oder das richtige Schlagwort. Danke schonmal fürs Lesen. Grüße, Frank
Danke A.K. ! Auf die Seite war ich auch schonmal gestoßen. Jedoch hat sie mich mehr verwirrt, als weitergeholfen. Ich glaube, das ist für den Moment noch ne Nummer zu tief angesetzt. Vielleicht nochmal anders formuliert. Ich hätte gerne folgendes: Ein Stück Programm (mein Bootloader), der sich im LPC z.B. im Adressbereich 0x0000 - 0x1FFF befindet. Nach dem Reset wird dieses ausgeführt und prüft, ob an Adresse 0x2000 und aufwärts eine gültige Applikation zu finden ist. Wenn ja, wird diese gestartet. Wenn nicht, dann verweilt er und wartet auf Kommandos und Daten zum Flashen von einer der Schnittstellen (CAN, USB UART, etc.). Das Übertragungs-Protokoll wäre ein eigenes. Darüber WIE man den Flash beschreibt, sei jetzt noch gar nicht bedacht. Ist das prinzipiell so denkbar? Was compiliere/linke ich meine eigentliche Applikation? Reicht es, dem Linker zu sagen, dass sie an Adresse 0x2000 anfangen soll und fertig? Was ist mit den Interruptvektoren, Stack, Heap, etc.? Wie wechselt/springt man von Bootloader zu Applikation und zurück? Muß man da vorher noch Dinge verbiegen? Ich hoffe, es ist etwas klarer geworden, was ich vorhab.
Prinzipiell ist das natürlich möglich. Den eingebauten Bootloader würde ich aber immer beibehalten für den Fall , dass beim eigenen mal was schief läuft. Da du eh den Bereich 0-1fff dafür reservieren willst. OK. Die Vektoren müssen dann natürlich entsprechend verbogen werden. Beim Bootloader würde ich eine feste Einsprungadresse für den Rücksprung vorsehen. Für dein eigenes Programm ist dann der Startup Code entsprechend zu modifizieren (wenn nicht schon beim Bootloader verwendet + initialisiert) Gruß Thomas
hallo arm-fan, falls du bereit bist für die lösung auch geld zu investieren dann würde ich dir den bootloader von hcc-embedded (http://www.hcc-embedded.com/site.php?mid=230) ans herz legen. gruss gerhard
> Ist das prinzipiell so denkbar? Ja. Wenn dein Bootloader keine Aborts/Syscalls/Fast-IRQs benötigt. Die Interrupts selber sind harmlos, jedenfalls wenn man in der Anwendung den gängigen Weg mit LDR PC,vic_vektor verwendet, der ja für die Anwendung genauso funktioniert wie für den Bootloader selbst. Wenn man freilich einen zentralen Interrupt-Dispatcher verwendet und der Bootloader auch Interrupts braucht, dann ist ein Interrupt-Rerouter im RAM fällig. > Ich glaube, das ist für den Moment noch ne Nummer zu tief angesetzt. Genau da landest du aber. Nicht unbedingt auf der Ebene der Flash-Programmierung per undokumentierter Register. Aber Angst vor einem angepassten Startup-Code und Anpassung von Linker-Scripten solltest du nicht haben. > Stack, Heap, etc.? Unverändert, nur fängt der Code weiter oben an (=> Linker Script). > Wie wechselt/springt man von Bootloader zu Applikation Alle Hardware wieder in den Ursprungszustand versetzen und ab nach 0x2000. > und zurück? Watchdog einschalten, Interrupts abschalten, Schleife. > Darüber WIE man den Flash beschreibt, sei jetzt noch gar nicht bedacht. Dafür gibt's dann den IAP-API in NXPs Bootloader. Ja, das ist genau der, der laut Jayasooriah in älteren Versionen des Bootloaders den Chip versemmelt. Ind neueren hoffentlich nicht.
> Wo liegt eigentlich der eingebaute Bootloader? Hängt ein bischen stark von der verwendeten Familie ab, denn das macht jeder Hersteller völlig anders. LPC2000 != SAM7 != STR7 != ...
Vielen Dank A.K. Denke mal, dass der Bootloader mit Std-IRQs (VIC) auskommen sollte. Ich glaube, ich hab mittlerweile hier (http://www.tnkernel.com/usb_fw_upgrader.htm) auch noch die ein oder andere Anregung gefunden. Mir gehts nur prinzipiell darum, ob das mit dem ARM funktioniert was ich mir so gedacht habe. Aber irgendwie muß es ja. Bin sicherlich nicht der einzige auf der Welt, der nen eigenen Bootloader für seinen Controller schreiben muß, damit er sich mit dem Rest des Systems und der Software auch versteht. Interessant wirds dann, wenn ich mit der Implementierung beginnge. Im Moment sammele ich noch ein bisschen Infos. Wo ist eigentlich die IAP API dokumentiert? Habe mir gestern bei NXP relativ erfolglos nen Wolf gesucht und bin nur bei einer Mini-AppNote gelandet. Oder gibt NXP die nur unter NDA raus? Wär ja auch nicht so das Problem.
Auch solltest du vor falscher Doku keine Angst haben. Der Autor des von ST selbst zur Verfügung gestellten seriellen Bootloaders für STR9 hat sich nämlich genau an die Doku gehalten. Was ein ziemlicher Fehler war, wie sich mittlerweile herausstellte. ;-)
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.