Forum: Mikrocontroller und Digitale Elektronik ARM SAM7 Flash Speicher


von denis (Gast)


Lesenswert?

Hallo, ich bin grade dabei einen USB Bootloader zu schreiben und habe 
eine Frage zu den Adressen im Flash Speicher.

Ich füge hier einen klainen Auszug aus meinem .hex File um die Fragen 
besser formulieren zu können:


:1000000018F09FE518F09FE518F09FE518F09FE5C0
:1000100018F09FE5FFFFFFFF18F09FE518F09FE540
:10002000C417000004000000080000000C000000DD
:1000300010000000FEFFFFEA6C17000044170000EC
:10010000F7B5010000252A0000252B000025280056
:100110001206120E042A49D21206120E8D5C002D10
       .
       .
       .
:101F90004000FAFFDC06200000C20100000008003B
:04000005000017C41C
:00000001FF


1. Schreibe ich die Daten beginnend mit der Adresse 0x00 oder 0x100000 ?

2. Wieso springt die Adresse plötzlich von 0x0030 auf 0x0100 und soll
   ich den Bereich von 0x0040 bis 0x000F leer lassen?
   Ich kenne das bisher von AVR's dass die Adressen immer
   durchgängig/kontinuierlich steigend sind ohne Sprünge.

3. Wo wird die vorletzte Zeile mit dem "Record Typ" 05 kopiert?


Ich freue mich auf euere Antworten und bedanke mich schonmal ;-)

p.s. Ach ja, es ist ein SAM7A3 Controller und .hex File wurde mit IAR 
erstellt.

von gerhard (Gast)


Angehängte Dateien:

Lesenswert?

hallo,
anbei einm dokument, welches den aufbau einer intel hex datei 
beschreibt.
ansonsten würde ich mir mal das user's guide der iar workbench ansehen. 
dort findest du sicher hinweise darauf, welche angaben der linker 
benötigt (der ist nämlich für die erstellung deines hex-files 
zuständig).
desweiteren würde ich mir mald das datenblatt des at91sam7a3 ansehen und 
mich darüber schlau machen wie das memory aufgebaut ist (welches memory 
liegt wo im adressbreich).

gruss
gerhard

von denis (Gast)


Lesenswert?

Hi, danke zunächst für die Datei ;-)

Der Aufbau einer intel-hex Datei ist war mir schon bekannt, nur wie 
gesagt bin ich bei den Adressen etwas verunsichert weil ich das bisher 
nur von AVR kenne.

Das Datenblatt des A3 habe ich auch schon angeschaut. Dort steht ja das 
Flashspeicher auf dem Bereich 0x100000 gemappt wird. Soweit ist mir das 
auch schon verständlich. Nur wenn ich mir mit dem SAM-BA den 
Adressbereich anschaue, dann sehe ich an der Adresse 0x000000 und 
0x100000 die selben Daten (ist ja auch gemappt). Deshalb weiss ich nicht 
ob mein Bootoloader die Daten des .hexfiles beginnend mit der Adresse 
0x000000 schreiben soll und es wird automatisch auf die 0x100000 gemappt 
oder muss ich schon selber direkt auf die 0x100000 schreiben (oder 
beides)????

Ja und das mit der vorletzten Zeile des .hex Files konnte ich auch 
bisher nirgendswo nachlesen, wo diese geschrieben wird. Ich weiss nur 
das Sie die Einsprungadresse für die Programmausführung beinhaltet????

Also bitte ich nochmal verzweifelt um Tips :-(

von Heiko_S (Gast)


Lesenswert?

Der ARM7 (ich kenne den S64/256) hat nach einem Power on den 
Flashspeicher auf Adresse 0x100000 und den Ramspeicher auf Adresse 
0x200000 festgelegt. Die Adresse 0x100000 ist auch gleichzeitig auf die 
Adresse 0x0 gemappt und der Prozessor läuft bei 0x0 los. Mit Software 
kann nun der Bereich Ramspeicher an die Adresse 0x0 gemappt werden, 
damit das Programm im Ram (schnellere Abarbeitung, da kein wait State 
bei Flash Zugriff) ablaufen kann. Das ab Adresse 0x3F auf 0x100 
gesprungen wird, liegt am Assembler Programm, was meist mit dem 
Toolchain eingebunden wird und im Grunde genommen den Reboot des 
Prozessor durchführt (Frequenz Einstellung; Initialisierung der 
Variablen; Interruptaddressen Initialisierung; ... wird hier gemacht). 
Die Adressen 0x0 bis 0x1F sind für die Interrupt Sprungtabelle 
reserviert. Aber da solltest Du besser die Dokumentation des Prozessors 
durchlesen!

MfG

von Rooney B. (rooney)


Lesenswert?

Nur so ein kleiner Tipp am Rande. Ich habe mir bereits einen Bootloader 
geschrieben, deswegen wirst du früher oder später auf die gleichen 
Probleme stoßen.

Der Bootloader selbst sollte im ersten Sektor des Flash stehen. Damit 
wird di r ermöglicht den Sektor über entsprechende Bits vor 
Überschreiben zu schützen. Bei einem SAM7S256 wäre also ein Sektor 
16kByte groß, damit musst du leben.

In IAR musst du also eine Linker Konfigurationsdatei entsprechend 
anpassen. D.h. du kompilierst deine Applikation für den Adressbereich 
nach dem Bootloader.
Beim SAM7S256 steht also für die Startadresse der Applikation 0x104000. 
Der Flash beginnt beim SAM7S256 bei 0x100000. Nach einem Reset ist der 
Flash auch auf Adresse 0x0 verfügbar. Machst du einen Remap, wird das 
SRAM auf 0x0 verfügbar. Nichts desto trotz bleibt das Flash bei 0x100000 
verfügbar sowie das SRAM bei 0x200000. Ich würde also empfehlen 
Flash-Applikationen immer für 0x100000 zu kompilieren, dann ist es egal 
ob du einen Remap ausgeführt hast oder nicht.

Da der Bootloader im Flash steht und du nicht aufs Flash schreiben 
kannst, wenn von dort auch ein Programm ausgeführt wird, musst du 
sämtliche Routinen, die den Flash beschreiben unter IAR als __ramfunc 
deklarieren. Diese Programm teile werden dann vor der Abarbeitung ins 
RAM geladen.


Viel Erfolg!!!

von denis (Gast)


Lesenswert?

Hallo Rooney Bob, vielen Dankf für die Erklärung. Ist genau das was ich 
brauche. Bis jetzt habe ich den USB Bootloader schon soweit dass 
zumindest der Transfer PC<->SAM7 problemlos läuft und ich den ganzen 
.hex File ohne Fehler übertragen kann ;-)

Den Bootloader würde ich gerne so machen, dass dieser als eine 
eigenständige Applikation am Anfang ausgeführt wird und kurz wartet ob 
von PC der Befehl zum Bootloading kommt. Wenn nicht dann soll er auf die 
Hauptapplikation springen.

Und genau da habe ich noch Fragen:
Den Bootloader möchte ich locken, sodass er immer im Flash erhalten 
bleibt für den Fall dass beim Bootloading etwas schief läuft.

Kann ich nicht den Bootloader so locken dass dieser im Flash 0x100000 
bleibt und von dort startet. Dann bekommt er neue Daten vom PC und 
kopiert diese weiter hinten im Flash ab Adresse 0x104000. Kann ich in 
diesem Fall den BL vom Flash aus ausführen oder muss es trotzdem aus RAM 
laufen? Weil ich habe nicht vor den BL aus dem Flash zu löschen (die 
ersten 16k sollen ja gesperrt bleiben).

von denis (Gast)


Lesenswert?

Oh... ich sehe grade....

" Da der Bootloader im Flash steht und du nicht aufs Flash schreiben
kannst, wenn von dort auch ein Programm ausgeführt wird... "

irgendwie habe ich das erst bei 2.mal lesen verstanden was du gemeint 
hast..glaube ich :-(

Also der BL bleibt während dem BL-Vorgang im Flash und ist auch dort 
innerhalb der ersten 16k gelockt, sodass er nicht überschrieben werden 
kann. Er darf aber von da aus nicht ausgeführt werden sondern muss beim 
start durch _ramfunc in den RAM verschoben werden um von dort ausgeführt 
zu werden. Stimmt es soweit?

Meine "neue" Applikation muss ich im Linker-File Editor soweit anpassen 
dass diese nicht von 0x100000 sondern von 0x104000 ausgeführt wird.

Der Bootloader aber wird beim Linker-File von 0x100000 gestartet.

Soweit auch noch ok?


Wie mache ich jetzt den entscheidenden Sprung auf die Applikation wenn 
der BL mit dem Vorgang fertig ist bzw. er nicht benötigt wird und das 
Hauptprogramm starten soll?


MfG Denis

von Rooney B. (rooney)


Lesenswert?

Nein, du musst nicht den ganzen Bootloader ins RAM kopieren, nur die 
Funktionen, die aufs Flash schreiben oder Sektoren löschen. Was genau 
bei dem __ramfunc passiert findest du in der Doku von IAR. Das Kopieren 
von Flash ins RAM übernimmt dankenswerterweise der Compiler für dich. 
Ich habe lange gesucht bis ich darauf gekommen bin, weshalb bei mir 
immer Fehler aufgetreten sind.

Ja, du hast es richtig verstanden.
Der Bootloader wird für 0x100000 kompiliert und die Applikation für 
0x104000.

Wie groß ist dein USB Bootloader?
Ich habe USB nie richtig zum Laufen bekommen, vielleicht kannst du mir 
ja weiterhelfen...


Der Sprung zur Applikation ist einfach und könnte folgendermaßen 
aussehen:

1
typedef void (*r_dull_proc_ptr)(void);
2
#define APP_START_ADDRESS ((void *) ((unsigned int)AT91C_IFLASH + (unsigned int)0x4000))
3
4
void r_goto(unsigned int addr)
5
{
6
    r_dull_proc_ptr p;
7
  p = (r_dull_proc_ptr)(addr);
8
    (*p)();
9
}
10
11
12
r_goto((unsigned int)APP_START_ADDRESS);

von denis (Gast)


Lesenswert?

Hey, das geht ja fix mit den Antworten ;-)

Ich werde das gleich mal ausprobieren ob das soweit gut klappt.


Was USB angeht kann ich dir gerne helfen. Was genau möchtest du wissen, 
bzw. was klappt bei dir nicht?

Mein USB BL ist zur Zeit 15k groß (Größe des .hex Files, reine Daten 
sind ca. 5k) da fehlen aber noch die Funktionen für Write Page und Read 
Page.

von Rooney B. (rooney)


Lesenswert?

denis wrote:
> Hey, das geht ja fix mit den Antworten ;-)
>
Da ich im Krankenstand bin, hab ich ohnehin nichts besseres zu tun g



Ich hab mir zwar die Beispiele von ATMEL schon runtergeladen, aber USB 
funktioniert bei mir nicht wirklich. Ich haben ein WinXP bzw. Win2000 
System. Sobald ich den Treiber installiere hängt sich mein System auf. 
Hin und wieder klappts dann mal, jedoch gibt dann mein Hyperterminal den 
Geist auf sobald ich Daten schicken will.
Ich weiß also nicht an was es genau liegt, vielleicht ist es der Windows 
Treiber oder die USB Firmware.

von denis (Gast)


Lesenswert?

Also ich habe das ATMEL Beispiel benutzt mit der cdc_enumerate.c und den 
dazugehörigem Treiber atm6124.

Bei mir läuft es bisher problemlos. Allerdings hatte ich Probleme als 
ich das USB_Framework Beispiel von IAR benutzt habe.

Verwendest du den orginalen ATMEL (atm6124) Treiber oder libusb?

von Rooney B. (rooney)


Lesenswert?

so viel ich weiß verwende ich den atm6124.

Welche IAR Version verwendest denn?

von denis (Gast)


Lesenswert?

Ich verwende die ARM 5.11 Baseline Version. Die "alten" Atmel Beispiele 
mit der cdc_enumerate stammen von der 4.42 Version aber die kannst du 
mit der Neuen auch benutzen wenn du die aktuellen Startups benutzst.

von Rooney B. (rooney)


Lesenswert?

Und welches Board verwendest du?
Ich verwende ein Olimex SAM7-P256.


Würdest du deinen Source Code für die USB Kommunikation zugänglich 
machen?

von denis (Gast)


Lesenswert?

Am Anfang habe ich das AT91SAM7A3-EK benutzt aber jetzt verwende ich 
eigene Hardware aus unserer Firma.

Den Sourcecode darf ich nicht zur Verfügung stellen, da dieser nicht von 
mir privat ist sondern gehört zur Hardware die wir in der Firma 
entwickeln.

Kann dir aber gerne so helfen wenn du mir die Fragen gezielt stellst.

Wie gesagt. Für USB nimmst du am besten das alte ATMEL Beispiel BasicUSB 
wo die cdc_enumerate.c und .h enthalten ist im Vebindung mit dem atm6124 
Treiber. Das hat bei uns am stabilsten funktioniert.

Ich musste kleinere Änderungen vornehmen weil unser Gerät self-powered 
ist und beim trennen vom USB weiterhin im Hauptprogramm läuft.

von Rooney B. (rooney)


Lesenswert?

Alles klar...

Dann werd ich mal nach diesem IAR Projekt im Netz suchen und das ganze 
noch einmal probieren.

Wenns nicht funktioniert, nehm ich jetzt mal an, meld ich mich wieder 
;-)

von denis (Gast)


Lesenswert?

Ok viel Erfolg, meld dich sobald du was hast ;-)

Hier ein Link zum zugehörigen pdf

http://www.atmel.com/dyn/resources/prod_documents/doc6123.pdf

von denis (Gast)


Lesenswert?

Hallo nochmal,

habe noch eine Frage bzgl. des Einsprungpunktes.

:1000000018F09FE518F09FE518F09FE518F09FE5C0
:1000100018F09FE5FFFFFFFF18F09FE518F09FE540
:10002000C417000004000000080000000C000000DD
:1000300010000000FEFFFFEA6C17000044170000EC
:10010000F7B5010000252A0000252B000025280056
:100110001206120E042A49D21206120E8D5C002D10
       .
       .
       .
:101F90004000FAFFDC06200000C20100000008003B
:04000005000017C41C                                 <- Wohin????
:00000001FF


Wo wird denn die letzte Zeile des .hex Files kopiert? Muss ich diese von 
meinem Bootloader irgendwo kopieren lassen oder kann er sie 
vernachlässigen???

von Rooney B. (rooney)


Lesenswert?

Die letzte Zeile kannst du verwerfen, ist ein EOF Record.

Verarbeiten, also ins Flash schreiben, musst nur Record-Typ 0.
Record Typ 2 ist wichtig für die 32Bit Adressierung.


Alle anderen Record-Typen sollten mit IAR nicht vorkommen, zumindest 
habe ich noch nie andere Typen in meinen HEX Datein gefunden.



Weißt du noch wo du das BasicUSB Projekt her hast?

von denis (Gast)


Lesenswert?

Ah danke ok.

Ja habe das von einer DVD-Rom von Atmel die wir damals mit dem alten 
SAM7S64 EK bekommen haben. Wenn du willst kann ich dir das Beispiel per 
mail zukommen lassen.

Hmm... das mit dem rekord ist komisch. Wenn ich mit IAR ein Programm auf 
die Adresse 0x104000 kopiere und dann meinen Bootloader auf 0x100000 und 
von Bootloader aus mache ich inen Sprung auf 0x104000 dann wird das 
andere Programm nach dem BL ohne Probleme ausgeführt.

Wenn ich aber meine Daten per Bootloader ab der Adresse 0x104000 kopiere 
und dann den Sprung mache passiert gar nichts.

Wenn ich mir mit SAMBA den Speicher anschaue dann sieht er komplett 
identisch aus (das was IAR kopiert hat mit dem was mein BL kopiert hat) 
und trotzdem geht das nicht???? Total komisch???

von gerhard (Gast)


Angehängte Dateien:

Lesenswert?

@rooney:
suchst du das beispiel (siehe anhang)?

gruss
gerhard

von gerhard (Gast)


Lesenswert?

@denis:
hast du mit das remapping benutzt?

gruss
gerhard

von denis (Gast)


Lesenswert?

Hi, ich glaube das was Gerhard obern als Anhang hat ist das Beispiel was 
ich meine.

Bin grade auf der Arbeit und habe eingeschränkte downloadrechte ;-( 
deswegen kann ich nicht sagen ob es genau das ist aber ich denke schon 
von Namen her. Schaue zu Hause nochmal nach.

Wegen dem Einsprung: ich habe das endlich hingekriegt. Im der ganzen 
Hektik habe ich vergessen den Linkerfile der eigentlichen Anwendung auf 
0x104000 zu mappen. Es ist mir auch nicht aufgefallen da ich die Adresse 
im WriteFlash des BL auf Offset: 0x104000 eingestellt habe.
Der hat es zwar richtig hinkopiert wo es auch hin soll, aber in der 
Initialisierung hat diese Info wahrscheinlich irgendwo gefehlt....

von denis (Gast)


Lesenswert?

Hallo,

habe mal 'ne andere Frage was IAR angeht. Kann ich da beim Code 
kompilieren irgendwo sehen wie groß mein Code ist? Also reine Daten, 
Flash, SRAM?

von gerhard (Gast)


Lesenswert?

>habe mal 'ne andere Frage was IAR angeht. Kann ich da beim Code
>kompilieren irgendwo sehen wie groß mein Code ist? Also reine Daten,
>Flash, SRAM?
ja, laß dir von linker eine map-datei erstellen, da steht alles drin was 
du suchst.
zu aktivieren unter:
project - options - linker - list - generate linke listing

gruss
gerhard

von denis (Gast)


Lesenswert?

Danke :) :) :)

Das geht ja super fix mit den Antworten.

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.