Hallo, ich habe heute die Yagarto Tool Chain installiert. Leider ist kein Beispiel Projekt für einen AT91SAM7 dabei. Deswegen hab ich leichte Startschwierigkeiten. Mir fehlen nun die Startup- und die Linker-Datei. Hat jemand vielleicht sowas für mich? Ich arbeite mit einem AT91SAM7A3, aber die genaue Bezeichnung ist glaub ich nicht so wichtig, sondern nur AT91SAM7xxx. Ich habs mit den LPC2142-Datein probiert, jedoch funktioniert da etwas nicht, obwohl ich die RAM und Flash Adressen im Linker File umgeschrieben habe. Auch das Startup-File hab ich etwas geändert, aber leider weiß ich nicht so recht, was ich da eigentlich mache. Wenn ich ein RAM-Build mache, und den Debugger starte, dann kommt folgendes in der Eclipse Konsole: *************************************************** No source file named test.elf. target remote localhost:3333 0x00100a28 in ?? () monitor reset monitor sleep 500 monitor poll target state: running monitor soft_reset_halt requesting target halt and executing a soft reset monitor arm7_9 sw_bkpts enable software breakpoints enabled break main Breakpoint 1 at 0x50c: file src/main.c, line 71. load Loading section .text, size 0x56c lma 0x0 Start address 0x3c, load size 1388 Transfer rate: 5 KB/sec, 1388 bytes/write. continue ************************************************** Und die Progress Anzeige für "Launching SAM7A3_Test_Eclipse Default" bleibt bei 27% hängen. Halte ich den Prozessor über eine externe Telnetverbindung mit "halt" an, so muss ich feststellen, dass das der Programm-Counter im Flash-Speicher herumschwirrt, wo er ja garnicht sein sollte, sondern im RAM. D.h., es kommt nie zu dem Software Breakpoint im RAM. Die Interrupt Vektoren auf den Adressen 0x0000 0000, 0x0010 0000 (Flash) und 0x0020 0000 (RAM) sehen verdächtig falsch programmiert aus. Wo finde ich eigentlich die genauen Adressen für zB den Reset-Interrupt-Vektor? Im Atmel Preliminary hab ich nichts dazu gefunden. Der Reset-Vektor ist ja vorerst der wichtigste, da er zum Startupcode führen muss. Weitere Verständnisprobleme: 1) Woher weiß openOCD, das ja von Eclipse aus gesteuert wird, wohin "geflasht" werden muss? Ich mein auf welche Adresse - je nach dem, ob man ein RAM oder FLASH Build hat. 2) Das Startup File muss ja immer im Flash programmiert werden, da ja dort der Remap gemacht wird. Wer oder was bringt das Eclipse/openOCD bei??? Sehr, sehr viele Fragen. Ich hoffe, mir kann hier jemand weiter helfen. Vielen Dank, Karl
Bei mir hing das ganze auch öfter bei 27%. Da war mein Startup-Code usw. noch nicht in Ordnung. Du weißt schon, dass es für deinen uC ein Tutorial mit Code gibt? Kennst du: http://www2.amontec.com/sdk4arm/ext/jlynch-tutorial-20061124.pdf ? Da gibt es auch den Source-Code für. Im OpenOCD Forum solltest du auch etwas finden können. Zu Ram und Rom Build kann ich dir nichts sagen. Bei dem uC, mit dem ich arbeite, wir bei Ram-Run einfach das Ram auf 0x0 gemappt, wo sonst das Flash liegt. Das ganze wird mit einem OpenOCD Befehl gemacht, bevor das Programm ins Ram geschrieben und gestartet wird. Wenn dein Programm im Ram laufen soll, wird gar nichts ins Flash geschrieben, auch kein Startup Code.. Zumindest ist das bei meinem uC so.
Tilo Lutz wrote: > Bei mir hing das ganze auch öfter bei 27%. Da war mein Startup-Code usw. > noch nicht in Ordnung. > > Du weißt schon, dass es für deinen uC ein Tutorial mit Code gibt? > > Kennst du: > http://www2.amontec.com/sdk4arm/ext/jlynch-tutorial-20061124.pdf ? > Da gibt es auch den Source-Code für. Das kenn ich noch nicht!! muss ich mir mal anschaun. Beim lesen des Inhaltsverzeichnis sieht es recht vielversprechend aus!!! > Zu Ram und Rom Build kann ich dir nichts sagen. Bei dem uC, mit dem ich > arbeite, wir bei Ram-Run einfach das Ram auf 0x0 gemappt, wo sonst das > Flash liegt. Das ganze wird mit einem OpenOCD Befehl gemacht, bevor das > Programm ins Ram geschrieben und gestartet wird. Das waren ja nur Vermutungen von mir. Deine Prozedur scheint einleuchtend zu sein. D.h., openOCD schreibt immer auf 0x0000 0000, und je nach dem, ob RAM oder Flash, wird vorher der entsprechende Speicher auf 0x0000 0000 gemapt. (eben mit den mww Befehlen) Hat openOCD was mit dem Linker-Script zu tun? Worauf ich hinaus will: woher weiß openOCD, dass es immer auf 0x0000 0000 schreiben muss? > > > Wenn dein Programm im Ram laufen soll, wird gar nichts ins Flash > geschrieben, > auch kein Startup Code.. Zumindest ist das bei meinem uC so. Mit welchem uC arbeitest du? vielen Dank für die Antworten. lg, Karl
Meine OpenOCD Befehle sehen so aus: target remote localhost:3333 monitor soft_reset_halt monitor mww 0xFFFF0220 0x1 <- Mappe Ram auf 0x0 monitor reg pc 0x00000000 <- Springe zu 0x0 monitor arm7_9 sw_bkpts enable break main load <- Lade Code ins Ram continue Es wird also explizit 0x0 angewählt, bevor das Programm geschrieben wird. Das Problem ist aber nicht einmal, dass man auf 0x0 schreiben muss. Der ARM-Core erwartet zumindest bei meinem uC, dass die Vektoren (Reset, IRQ, FRQ, ...) bei 0x0 liegen. Ich arbeite mit einem ADUC7000, da ich den 12bit ADC und DAC benötige. Die anderen uCs haben max 10bit. Dieser scheint allerdings etwas exotisch zu sein; es ist schwer, an Beispielcode zu kommen. Bis dann, Tilo
Der OpenOCD schreibt nicht immer an 0x0! Der Prozessor startet immer mit der Adresse 0x0. OpenOCD schreibt die Daten an die Adresse, die im Compiler (Linker) angegeben ist. Beim ARMSAM7 Beispielweise an 0x00100000 wenn das Programm im ROM (Flash) laufen soll. Soll nun das Programm im RAM ablaufen (schnellere Abarbeitung, da kein "wait state" für memory Zugriffe) muss das Programm in die Adresse 0x00200000. Durch Umschaltung (OpenOCD startup Befehl monitor mww 0xFFFFFF00 0x01) wird dann die RAM Adresse 0x00200000 auf 0x0 gelegt. Somit ist der Einstieg auf Adresse 0x0 ein "b _reset_handler" oder "ldr pc, _reset_handler" und der Prozessor arbeitet mit der Speicheradresse im RAM weiter.
Ahh, jetzt wirds schön langsam klar. D.h. also, dass der Program Counter (PC) immer irgendwo bei 0x0010 0000 (Flash) oder bei 0x0020 0000 (RAM) ist, außer direkt nach dem Reset und bei Interrupts. Weil im Binary sind ja immer die physikalischen Adressen eingetragen, und nicht die auf 0x0000 0000 gemapten... Da gibts bei den AT91SAM7 jetzt noch die Sache mit dem Reset. Gibt es da 2 Resetarten, oder? Die eine (soft_reset_halt, was macht der eigentlich hardwaremäßig??), da bleibt der Speicher so gemapt, wie vor dem Reset, und die 2., wo ein richtiger Reset (reset, zieht den nRST Pin des uC kurz auf Low) ausgeführt wird, und standardmäßig der Flash Speicher auf 0x0000 0000 gemapt wird. Ich bitte um Bestätigung meiner Vermutungen. lg, Karl
Es gibt mehrere Arten von Reset. Der Prozessor hat einen eigenen ResetController, der die verschiedenem Arten steuert. Der PowerOn Reset hat einen bestimmten festen Ablauf. Der NRST Reset (externer Taster) kann bei entsprechender Programmierung ebenfalls einen kompletten Reset (alle Peripherials und CPU auf 0x0) durchführen, kann aber auch so programmiert werden, das nur ein Interrupt ausgelöst wird. Per Software kann man ebenfalls einen Reset auslösen. Frage aber nicht wie, denn dann müsste ich selber die Dokumentation lesen. Ich habe einfach den NRST zugelassen und der externe Taster funktioniert (CPU auf 0x0).
Da hab ich den Reset-Controller immer unterschätzt. Der ARM7 ist mein erster seiner Klasse und daher hatte ich noch nie wirklich mit sowas zu tun. Der kann ja einiges! Im Reset Type Feld im Reset-Controller-Status-Register sind 5 Arten von Reset eingetragen: 1) General Reset (= Power on Reset) 2) Wake Up Reset (= nur VDD1V8 wurde eingeschaltet) 3) Watchdog Reset 4) Software Reset 5) User Reset (NRST-Pin detected low) Was jetzt openOCD für einen Reset ausführt hab ich nicht rausgefunden, jedoch glaube ich, dass der Befehl soft_reset_halt nur einen Prozessor Reset macht, die Peripherie-Einheiten jedoch unangetastet bleiben --> Memory Controller wird nicht neu initialisiert --> Memory Map bleibt gleich. Ich schließe daraus, dass der NRST Pin vom JTAG (Wiggler) bei den beiden openOCD befehlen gar nicht verwendet wird, weil der im Normalfall keine Wirkung hat. Erleuchtung deswegen funktioniert mein Reset-Taster am Board auch nicht!!! ;-) (hat mich bis jetzt nicht sonderlich gestört). lg, Karl
Hi, hast du das Problem mit dem Hängen bei 27% gefunden? Komischerweise habe ich bei einem Projekt das gleiche Problem. Bei einem anderen Projekt gibt es keine Probleme. Startup.c, Skript und Config-Datei sind bei beiden Projekten gleich. Verhindert die Applikation das Flashen das Debuggen der neuen Software? Gruß Stefan
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.