SAM9G45 + IAR

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

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

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

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