Hallo,
Eins vorweg: ich bin ARM-Anfänger, deshalb entschuldigt meine vielleicht
dummen Fragen :-)
Also, ich habe hier ein Board mit einem LPC2478 drauf. Nun möchte ich
ein kleines Testprogramm da drauf ausführen. Ich verwende eine
Testversion von Rowley Crossworks, und ich habe einen J-Link von Segger.
So, nun. Wenn ich das Programm ausführen will, dann läuft es, so lange
der J-Link eingesteckt ist. Sprich - egal ob ich es ins Flash lade oder
ins RAM, wenn der J-Link angeschlossen ist geht es.
Nun möchte ich aber, dass das Programm auch läuft, wenn ich den J-Link
NICHT anschliesse. Dazu muss ich das Programm ja im Flash ablegen. Okay,
das habe ich gemacht, im Memory-Editor kann ich auch sehen, dass im
Flash irgendwelche Daten gespeichert sind. Wenn ich jetzt den J-Link
ausstecke, und einfach den Strom aus- und wieder einschalte, dann müsste
doch mein Programm starten?!
Das tut es aber nicht, wie ich bereits messen konnte.
Was das Programm mache: es toggelt einen GPIO-Pin in einer
endlosschleife. Mit dem Oszi messe ich aber nur einen H-Pegel.
Nun, im Handbuch des Controllers liest man verschiedentlich etwas von
Memory Remapping.
Kann es sein, dass ich damit noch ein Problem habe? Oder muss ich noch
bestimmte Register initialisieren, damit es aus dem Flash läuft?
Crossworks baut in den Startup-Code eine Totschleife direkt nach dem
Reset ein. Der Debugger überspringt die wenn er die Kontrolle hat. Sowas
in der Art ist nötig, um den Prozessor nach einem Reset per Debugger
wieder einzufangen bevor er Unfug stiftet. Andere Zeitgenossen nehmen
eine hinreichend lange Zählschleife, die stört nicht so.
Für Produktionscode muss die natürlich raus. -DSTARTUP_FROM_RESET oder
so. Siehe Kommentar im Startup-Code (in System Files vom Projekt).
So ist das jedenfalls beim STM32.
Einfach STARTUP_FROM_RESET in den Preprocessor Settings unter
Preprocessor Definitions definieren.
STARTUP_FROM_RESET
If defined, the program will startup from power-on/reset. If not defined
the program will just loop endlessly from power-on/reset.
This definition is not defined by default on this target because the
debugger is unable to reset this target and maintain control of it over
the
JTAG interface. The advantage of doing this is that it allows the
debugger
to reset the CPU and run programs from a known reset CPU state on each
run.
It also acts as a safety net if you accidently download a program in
FLASH
that crashes and prevents the debugger from taking control over JTAG
rendering the target unusable over JTAG. The obvious disadvantage of
doing
this is that your application will not startup without the debugger.
We advise that on this target you keep STARTUP_FROM_RESET undefined
whilst
you are developing and only define STARTUP_FROM_RESET when development
is
complete.
@A.K.:
ich verstehe diesen Startup-Code sowieso noch nicht ganz.
Was hat es mit diesem remapping der Interrupt-Vektoren auf sich? Warum
muss man die remappen? es gibt doch den Interrupt Controller, der die
Interrupts handhaben sollte.
Frager schrieb:
> Was hat es mit diesem remapping der Interrupt-Vektoren auf sich? Warum> muss man die remappen? es gibt doch den Interrupt Controller, der die> Interrupts handhaben sollte.
Sind zwei paar Stiefel. Die Sprungleiste ab Adresse 0 mit
Reset,Abort,Interrupt,... ist eine Sache, die Interrupt-Vektoren des VIC
eine andere. Der Interrupt-Controller wird bei ARM7 vom Prozessor
überhaupt nicht angesprochen, das macht der Interrupt-Code selbst - oft
ein "LDR PC,..." Befehl direkt in der Sprungleiste.
Remapped wird diese Sprungleiste.
Wozu ist denn die Sprungliste da? jetzt bin ich ein bisschen verwirrt.
Was passiert denn z.B., wenn der UART0 einen Receive Interrupt
generiert? wird jetzt der VIC aktiv oder wird in der Sprungtabelle
nachgeschaut?
Hardware-Interrupt => Sprungleiste => LDR PC,vektorregister => Handler.
Vektorisierte priorisierte Interrupts sind im ARM Design eigentlich
nicht vorgesehen, vom FIQ mal abgesehen. Und wurden nachträglich
drangestrickt. Das merkt man gelegentlich.
Aha. Vielen Dank erstmal.
Kannst du mir denn mal kurz erklären, was genau vor sich geht, wenn ein
Interrupt auftritt? Um jetzt z.B. bei diesem UART-Interrupt zu bleiben,
als Beispiel. Was passiert da?
Ich weiss nur, dass der VIC da irgendwie ins Spiel kommt, aber ich habe
noch nicht so ganz verstanden, was der genau macht.
Kurzfassung:
Hardware-Interrupt => Sprungleiste => LDR PC,vektorregister => Handler.
Langfassung: Der Interrupt landet im IRQ Eintrag der Sprungleiste. Dort
steht ein LDR-Befehl, der den Program Counter mit dem Inhalt des
Vektorregisters des VIC füttert.
Kennst du das Hitex-Buch über die LPC2000er? Hilft vielleicht: "The
Insider's Guide To The Philips ARM7-Based Microcontrollers"
@ Frager
"LPC2478 will Programm nicht ausführen", das ist eine echte
Unterstellung, der will absolut :-) Der ist so willig, das glaubst Du
gar nicht.
Konnte mir das einfach nicht verkneifen, nicht boes gemeint.
Robert
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
