Forum: Mikrocontroller und Digitale Elektronik Keil uVision3 Linker Problem


von Nik Bamert (Gast)


Lesenswert?

Hallo,

ich programmiere gerade einen Bootloader für den LPC2368. Dazu verwende 
ich Keil uVision3 (V3.53).
Ich möchte den Bootloader ans Ende des Flashs platzieren, also direkt 
vor NXPs Standard-Bootloader. Nur wenn ich bei den Target Options als 
Startadresse für IROM1 etwas anderes als 0x0 angebe, dann kümmert das 
den Linker rein gar nichts. Wenn ich mir das ausgegebene Hex-File 
anschaue,
dann beginnt der Code immer noch bei 0x00000000 und nicht (wie 
gewünscht) bei 0x0007C000.

Mit einem Linker Script habe ich es auch schon versucht, wobei ich 
allerdings
noch nicht herausgefunden habe, wo ich dem uVision denn sagen kann, dass 
er dieses verwenden soll. Bei den Linker Optionen habe ich jedenfalls 
keine entsprechende Zeile,
wo ich einen Pfad für das File angeben könnte...

Any ideas?

mfg Nik

von ARM-Fan (Gast)


Lesenswert?

Habe auf dem LPC2368 auch einen Bootloader programmiert.
Nur gehört der nach meinem Verständnis an die Stelle, die
nach dem Start des Controllers angesprungen wird. Und das ist
nunmal am Anfang des Flashs. Der Bootloader entscheidet dann,
ob eine Applikation in einem höher gelegenen Speicherbereich
vorhanden ist und startet diese ggfs. Wenn nicht, verbleibt
der Controller im Bootloader.

Gelöst habe ich das ganze über ein Linkerskript.
Dieses zu benutzen verklickert man der µVision im Projektoptions-
dialog auf dem Reiter "Linker". Und dort wählt man das gewünschte
"Scatterfile" aus.

von Nik Bamert (Gast)


Angehängte Dateien:

Lesenswert?

Danke für die schneller Antwort ARM-Fan!

Musst du dann nicht für jede Applikation die Interrupt Vektoren 
anpassen, da ja dein Bootloader nun am Anfang des Flashs steht?

Ich wollte das mit dem Scatterfile gerade auch ausprobieren, nur scheint 
da das uVision nicht mitmachen zu wollen. Die Zeile in der man das 
Scatterfile auswählen können müsste, ist nämlich einfach grau hinterlegt 
und disabled. Genauso übrigens die Checkbox "Use memory layout from 
target dialog"
(siehe Anhang)

Nik

von ARM-Fan (Gast)


Lesenswert?

Das mit deinem Dialog sieht komisch aus.

Die Zeile wo man das Scatterfile auswählen kann, wird bei mir
nur ausgegraut, wenn ich "Use Memory Layout from Target Dialog"
ankreuze. Aber da kommst du ja gar nicht dran im Moment.

Was benutzt du denn als Compiler?
GCC oder den Realview Compiler?
Arbeitest du mit einer Demo- oder Vollversion vom Keil?

Ich kann hier für mich nur von Vollversion mit Realview sprechen.

Was den Bootloader an sich angeht:

Der wird bei mir an Adresse 0x00000000 gelinkt.
Und die Applikation steht dann ab Adresse 0x00008000 (bedingt
durch die Größe meines Loaders).

Die Interruptvektoren müssen sich beide teilen.
Es gibt ja (leider) keinen dedizierten Bootloader-Bereich mit
eigenen Vektoren wie z.B. beim AVR.

Wie man das ganz geschickt anstellen kann, kann man sich beim
"tnkernel usb firmware upgrader" abgucken. (so wie ich...) ;-)

von Nik Bamert (Gast)


Lesenswert?

Ich benutze ebenfalls Realview, allerdings die Eval. Version.

>Die Interruptvektoren müssen sich beide teilen.
>Es gibt ja (leider) keinen dedizierten Bootloader-Bereich mit
>eigenen Vektoren wie z.B. beim AVR.

Ich steh da irgendwie im Moment total auf dem Schlauch - macht es 
bezüglich den Interruptvektoren nun also keinen Unterschied ob ich die 
Applikation zuerst habe und dann den Bootloader oder umgekehrt, da die 
beiden sich die Vektoren sowiso 'teilen' müssen ?

von ARM-Fan (Gast)


Lesenswert?

Nein, egal ist es nicht.

Der Bootloader muß nach dem Reset als erstes angesprungen werden,
denn er entscheidet ja, ob er ein FW-Update machen soll oder eine
vorhandene Applikation starten soll.

Nach einem fehlgeschlagenen Updateversuch, muß der Bootloader
ja ebenfalls noch funktionabel sein. Und das geht nur,
wenn dieser direkt "unten" hiner dem Reset-Verktor liegt.

von Nik Bamert (Gast)


Lesenswert?

Achso ja das ist einleuchtend ;-) - Nur muss man dann jede Applikation 
die man laden möchte speziell behandeln und kann sie nicht einfach 
compilieren und @ 0x00000000 gelinkt lassen.

Aber eigentlich könnte man doch den NXP Bootloader auch überschreiben, 
dann hätte man dank P2.10 einen zweiten Reset Vektor...nur werden mir 
die 8kb warscheinlich zu knapp. :-(

Bitte 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
Noch kein Account? Hier anmelden.