SAM9G45 + IAR

[mikrokosmos21 (Gast)]

Hallo,

ich habe mir zum Testen für ein neues Projekt folgende Komponenten 
besorgt:

- das SAM9G45 OEM von in-circuit.de mit dem ADB 1003
- ein SAM-ICE Debugger
- Testversion IAR EWARM

Zunächst habe ich einige der IAR-Beispielprojekte ausprobiert und in den 
DDR geladen und editiert. Dies gelang recht gut.

Nun sind mir aber zwei Dinge aufgefallen:

1.Problem (Performance):  Wenn ich folgenden Code ausführe:

 for (int i = 0; i < 13200; i++)
  {
   asm("    nop");
  }

 Dann messe ich mit dem Oszi eine Zeit von etwa 3050us für die 
Ausführung anstelle von etwa 200us, die bei vollem Prozessortakt 
erreicht werden sollte.

Kann mir jemand sagen, wie man konkret den Prozessortakt/-Performance 
hochfahren kann? Wenn ich mich nicht verrechnet habe, dann müsste das 
'Ding' aktuell bei etwa 13MHz laufen. Im Moment bin ich etwas ratlos...

2. Problem (NORFLASH):
Gerne würde ich die erzeugte Software dauerhaft im Board speichern. Dazu 
steht ein 1MB großer NOR zur Verfügung. Wie kann ich das am Besten 
anstellen? Soweit ich gelesen und verstanden habe, befindet sich im NOR 
an Adresse 0x10000000 ein at91bootstrap, welches dann ab Adresse 
0x10020000 uboot läd, welches wiederum ursprünglich aus dem NAND ein 
Image läd...

Kann ich meinen Code (später mal >64kB) jetzt z.B. mit J-Flash von 
Segger an Adresse 0x10020000 im NOR schreiben und es wird dann 
gestartet? Bei IAR ist auch ein Beispielprojekt dabei, welches 
'at91bootstrap' heißt. Anscheinend kann man damit den ersten Teil an 
Adresse 0x10000000 spezifisch zusammenbauen (ich habe es aber noch nicht 
verstanden). Zudem enthält das at91bootstrap-Beispiel keinen Code für 
NOR. Hat jemand mehr Ahnung oder Erfahrung damit, als ich es aktuell 
habe? Ich bin momentan etwas ratlos...

Vielen Dank für etwaige Hilfe...
Gruß
Christian

[Sascha (Gast)]

Hallo Christian,
du brauchst ein geeignetes debugger script file, was die PLL und die 
internen Register wie auch den Cache zur Funktion bringt. Dann wird das 
Ding richtig schnell. Das müsste bei IAR ein Macro-File für den Debugger 
(.mac File) sein.
Die Initialisierung dann per Software ist auch nicht ganz ohne.
Ich habe das alles mit einem 9G10 schon durchlaufen.
Die Macro-Files für den Debugger gibt es vorgefertigt. Mit einem Editor 
kann man ohne weiteres das Macro-File auch abändern auf eine andere 
Konfiguration für den Prozessor.

Aber auch der Debugger kann unter Umständen die CPU ausbremsen. Durch 
schnelle Interrupts / SVC und durch verwendetes semihosting wird 
jedesmal der Debugger aktiv. Dann einfach die semihosting Funktion 
abschalten und zu normalen IAR-Breakpoint übergehen.

Gruß Sascha

[Sascha (Gast)]

Hallo Christian,
so nun Teil 2,
um deinen Code den du mit dem Debugger direkt ins RAM schreibst auch 
stand a lone zu starten, brauchst du einen Second-Bootloader.

Der Code wird dann automatisch durch den First-Bootloader der im 9G45 
ist ins interne RAM des Chips geladen und gestartet. Der Code muss dann 
erst deine ganze CPU + SDRAM wie es der Debugger mit dem .mac File 
initialisiert vorbereiten. Dann muss dieser Second-Bootloader dein 
Programm aus irgend einem Speicher selber ins DDR-RAM laden und starten.

Ich benutze dafür ein Dataflash von Atmel bzw. jetzt Adesto. Serielles 
Flash.
Ist aber egal der 9G45 kann aus mehreren Medien booten.

Mit dem Atmel Tool Samba und deinem Debugger kanst du direct in sehr 
angenehmer art auf die Speicher zugreifen.

Gruß Sascha

[mikrokosmos21 (Gast)]

Hallo Sascha,

zunächst einmal vielen Dank für deine Worte. Da das Board keine SD-Card 
besitzt, versuche ich jetzt aus dem NOR oder aus dem NAND zu booten.

Dazu editiere ich das at91bootstrap-Projekt aus dem IAR EW. Das bin-File 
brutzel ich dann an Adresse 0x0 des NOR und das bin-File meines 
eigentlichen Projektes packe ich an Adresse 0x20000 des NOR oder an 
Adresse 0x0 des NAND. So der Plan...

Seltsam ist nur, dass ich mit Samba nicht sauber in das NOR habe 
schreiben können. Mein NOR ist vielleicht anders aufgebaut. Leider gibt 
es auch keine Doku des Herstellers zu dem CPU-Board, was eigentlich 
untragbar ist.

Ich besorge mir zum ausprobieren jetzt eine Testversion des J-Flash. Mal 
schauen, was das bringt und werde dann berichten.

Sag mal Sascha, da du das alles bereits irgendwie gemacht zu haben 
scheinst - kann ich dich nicht gleich dafür engagieren? Insbesondere für 
das Problem mit der Performance. Mir erscheint das effizienter. Das 
könnte doch eine Win-Win-Situation sein...

Gruß
Christian

[Sascha (Gast)]

Hallo Christian,
wenn das Flash über den Samba nicht richtig funktioniert, must du den 
Source-Code von Samba (den gibt es glücklicher weise) abändern.
Es ist ein C-Programm, welches das Interface zu deinem Flash bildet und 
auf den ARM9 heruntergeladen wird und gestartet wird.
Bzw. es wird natürlich nur das compilierte binäry heruntergeladen.
Dann gibt der Samba Befehle an das Programm und das Programm führt die 
dann im Chip aus.
Das Interface von Samba kanst du mit TCL script auch anpassen. Ich habe 
den Samba auch komplett anpassen müssen, da ich mit einem eher 
untypischen Umgebung arbeite.
Aber bei Samba funktionieren nicht einmal die I2C EEPROMs da sie einige 
Fehler im Code haben, somit detectieren Sie nicht alle I2C EEPROMs 
richtig.

Ich glaube beim NOR-Flash gibt es sogar noch ein Problem mit dem BUS, da 
bei einem Reset der BUS durch das SDRAM (DDR-RAM???) blockiert sein 
kann. Somit kann er gar nicht mehr starten?!?
Deshalb boote ich nur vom seriellen Flash, der geht immer !

Gruß Sascha