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?
Und Dein Testboard erzeugt einen definierten Power-On-Reset? Mal von Hand an der Reset-Leitung "gewackelt"?
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.