Forum: Compiler & IDEs ARM AT91SAM7 - openOCD und Eclipse (YAGARTO)


von Karl Z. (griffin27)


Lesenswert?

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

von Tilo (Gast)


Lesenswert?

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.

von Karl Z. (griffin27)


Lesenswert?

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

von Tilo (Gast)


Lesenswert?

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

von Heiko_S (Gast)


Lesenswert?

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.

von Karl Z. (griffin27)


Lesenswert?

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

von Heiko_S (Gast)


Lesenswert?

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).

von Karl Z. (griffin27)


Lesenswert?

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

von Stefan H. (Gast)


Lesenswert?

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