Code download via JTAG in Dataflash (SPI)

[Bernd S. (mms)]

Hallo,

ich arbeite gerade mit dem AT91RM9200 Controller von Atmel. An diesen 
möchte ich gern ein Dataflash anschließen über SPI. Des Weiteren arbeite 
ich mit Keil - hier ist es so, dass man stets einen Speicherbereich 
definieren muss, wohin der Code, welcher über JTAG downgeloaded werden 
soll, gespeichert wird.

In der Auflistung des Adress-Bereichs im Datenblatt vom Controller 
taucht der SPI Controller natürlich nicht auf. Muss ich für den 
Download-Vorgang den Adressbereich des internen ROMs dann verwenden?

So dass, der Controller selbst nach einer geeigneten Möglichkeit sucht, 
wo der Code gespeichert werden kann?
ähnlich wie beim Bootvorgang:
Beim Bootvorgang sucht der Controller zuerst ob ein Dataflash über SPI, 
oder ein EERPOM über TWI connected ist und bootet entsprechend dann von 
der ersten Quelle.

gruß
Bernd

[Tilo (Gast)]

Ich denke das wird nur etwas, wenn das Flash direkt am Datenbuss des uC 
angeschlossen ist.

Alles andere wirst du selbst programmieren müssen. Ich lasse mich aber 
auch gerne eines Besseren belehren.

Den Schluss habe ich nicht mehr verstanden. So einen Bootloader wirst du 
selbst programmieren müssen.

[Bernd S. (mms)]

eigneltich möchte ich lediglich mein Programm im SPI Dataflash speichern 
- allerdings arbeite ich ohne Bootloader etc.

Hab grad die Speicheraddresse vom SPI in einem anderen Dokument von 
Atmel gefunden... keine Ahnung warum diese nicht im Memory Mapping 
(Datenblatt Controller) auftaucht / erwähnt wird.

>Alles andere wirst du selbst programmieren müssen

d.h. ich muss ein programm schreiben, welches den SPI Controller 
aktiviert (und dieses Programm muss zuvor im internen RAM vom Controller 
ausgeführt werden)

Bernd

[Tilo (Gast)]

Hinzu wird kommen, dass der Code nicht direkt im SPI-Flash ausgeführt 
werden kann. Trivial wird das nicht.

[Bernd S. (mms)]

>>Trivial wird das nicht

d.h. am einfachsten zu verwenden ist ein flash-IC der über Daten- und 
Adressbus angeschlossen wird?

Und alles was über SPI, I2C oder Burst Controller angeschlossen wird, 
muss zum einen bevor man etwas hineinschreibt initialisiert werden... - 
d.h. ein Bootloader führt hier schon einige aufgaben aus, wenn der Code 
aus dem Dataflash in den RAM kopiert werden soll, die ich zu fuß 
durchführen müsste?

welche Schwierigkeiten erwarten mich denn beim ausführen des Codes (z.B. 
aus dem SPI Dataflash)?


Bernd

[Martin T. (mthomas) (Moderator)]

Ohne das jemals selbst ausprobiert zu haben...:

In der Evaluierungsversion von uVision (keine Ahnung welche Version) 
sehe ich im Verz. Keil\ARM\Flash\AT91SAM9_DF einen auf der Keil 
Flash-Library aufbauenden Code, um DF zu schreiben. Da man eine 
"FLX-Datei" wohl selbst kompilieren kann (uVision Workspace liegt bei), 
bietet es sich an, diesen Code als Vorlage zur Anpassung an den 
vorhandenen AT91 zu nehmen. Die Übertragung in das externe Device 
erfolgt also mit "eigenem" Code. Ich sehe keinen Grund dafür, dass beim 
Flash-Speicher etwas "memory-mapped" sein sollte bzw. an einem Data-Bus 
hängen muss. Um die spätere "Ausführung des Codes" aus dem Dataflash 
indem dessen Inhalt ins RAM kopiert und von dort gestartet wird, kümmert 
sich soweit ich das aus dem Manual entnehmen kann ohnehin das 
controllerinterne Boot-Programm.

Damit dürfte das wohl so ablaufen (nicht viel mehr als Spekulation...):

- per JTAG werden ein paar Routinen ins RAM kopiert, in denen u.a. eine 
die DF-Schreibfunktion enthalten ist (eine Art temporärer Bootloader)
- per JTAG (mglw. DDC) wird ein Teile der in den DF-Baustein zu 
übertragenden Daten in einen Pufferbereich im Controller geladen
- die vorher geladene Schreibroutine wird aufgerufen (über JTAG) und 
diese übertragt dann den Inhalt des Puffers in den DF.
- Vorgang wird solange wiederholt bis gesamter DF-Inhalt übertragen ist.

Langer Rede: das Ganze ist recht werkzeug- und targetspezifisch, scheint 
mir aber von Keil/ARM gut vorgekaut. Direkte Anfrage beim 
Keil-Support(-Forum) dürfe dennoch erfolgversprechender sein.

[Tilo (Gast)]

Die Rumkopiererei kostet halt Zeit. Ich denke, der Code wird relativ 
groß sein und dann wird oft kopiert werden müssen.

Wenn das Flash direkt am Bus hängt, muss nichts kopiert werden, da 
dieser
direkt adressiert werden kann.

So fern im Flash nur Daten und kein Code liegt, sieht die Sache 
natürlich anders aus.