|
Anzeige
|
Ozone Debugger CPU Init File?
Gast
#4921267
Hallo, arbeitet jemand mit dem Debugger von Segger Ozone mit einem ARM9 oder ARM7? Ich suche nach einer Möglichkeit die CPU zu initialisieren, damit das SDRAM arbeitet und ich meinen Code zum debuggen einspielen kann. Übrigens finde ich den Debugger als Standalone Programm echt klasse. Man kann sich mal von den IDEs etwas befreien. Auch scheint mir die Funktionalität bis jetzt recht gut zu sein. Bis jetzt aber nur mit einem CM0 getestet. Gruß Sascha
Gast
#4921277
Interessantes Problem. Hat der keinen internen Flash/SRAM welcher direkt funktioniert? Könntest du da nicht ein einfaches Initialisierungs-Programm einspielen, welches den SDRAM initialisiert und danach einen Breakpoint aufruft (Instruktion "BKPT") sodass du dann dein Programm in den SDRAM laden kannst?
Gast
#4921362
Nein SRAM geht nicht, sind max. nur 10K und mein Programm hat mindestens 4MB. Deshalb habe ich mir auch einen flotten JLink zugelegt. Gruß Sascha
Gast
#4921592
Sascha schrieb: > Nein SRAM geht nicht, sind max. nur 10K und mein Programm hat mindestens > 4MB. Ein Programm welches den SDRAM aktiviert sollte wohl in 10KB passen. Das lädst du in den SRAM, startest es, und lädst dann das Hauptprogramm in den SDRAM.
Gast
#4921806
Ja das ist einfach gesagt, aber wie weise ich das dem Ozone Debugger an. Bei anderen Debugger Systemen setze ich die CPU auf Halt und schreibe über den JTAG einfach mittels script in die Hardware-Register. Nach einem System Reset ist ja alles wieder weg ! Man muss also auch noch unterscheiden zwischen System- und CPU-Reset. Gruß Sascha Du kannst die Ozone Projekt-Datei (*.jdebug) mit einem Texteditor bearbeiten. Darin sind mehrere Funktionen in einer C-ähnlichen Scriptsprache enthalten, mit denen das Verhalten des Debuggers gesteuert werden kann. Im Manual des Debuggers (https://www.segger.com/downloads/jlink/UM08025_Ozone.pdf) ist dieses Scripting-Interface im Kapitel 6 beschrieben. So lassen sich z.B. Event-Handler implementieren, welche vor dem Download des Programmes ausgeführt werden sollen. Gruss, Christian
Gast
#4922343
Hallo Christian, ja Danke das werde ich mir sofort mal ansehen, ich hoffe man bekommt auf den JLink zugriff oder kann sogar Initialisierungs Plugins einspielen (also ins SRAM). Habe mir gerade die Befehle schon angesehen, es fehlt noch ein Wait xxx ms Befehl, weil man oft keine Hardware Register pullen kann ist es besser beim Schreiben auf eine PLL einfach xxx ms abzuwarten, bevor man das nächste Register beschreibt. Ich muss die PLL initialisieren (Taktung) und das SDRAM, damit ich auf den Chip komme. Wenn ich ein Initialisierungs File ins SRAM einspiele kann ich das ja über eine Memoryzelle (Status) als quasi Handshake pullen, wann es fertig ist. Also in etwa gleich wie bei einem Flash-Loader. Mein Source-Code also das ELF-File belegt das SRAM und das SDRAM zugleich. Das dürfte hoffentlich beim Download kein Problem sein? Es wird ja auch kein Flash-Loader verwendet. Ich darf nur keinen System-Reset machen, sonst ist alles wieder weg! Gruß Sascha An die Arbeit. Hallo Sascha Ich denke, beide Varianten sollten möglich sein: - entweder ein File ins RAM einspielen (Target.LoadMemory) und ausführen - oder die Initialisierung mittels Debugger Script ausführen. Bisher habe ich eigentlich immer die zweite Variante verwendet (allerdings mit einem anderen Debugger und Prozessor). Mittels Target.ReadU8/16/32 sollte es meiner Meinung nach möglich sein, auch auf die Peripherie-Register zuzugreifen und somit PLL und SDRAM zu initialisieren. Es gibt übrigens einen Util.Sleep Befehl (im pdf Kapitel 7.7.6). Das Flow-Chart im Kapitel 7.5 könnte für deine Anwendung auch noch interessant sein. Darin ist ersichtlich, wie man sich in die Startup-Sequenz des Debuggers einhängen kann. Gruss, Christian Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
