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.
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
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 :-(
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
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!!!
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).
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
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); |
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.
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.
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?
so viel ich weiß verwende ich den atm6124. Welche IAR Version verwendest denn?
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.
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?
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.
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 ;-)
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
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???
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?
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???
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....
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?
>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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.