Hallo zusammen, ich habe die Aufgabe einen Bootloader für den ATMega 1281 zu schreiben, der per serieller Schnittstelle ein Programmupdate erhalten können soll. Da ich noch ganz am Anfang bin, was µCs angeht, habe ich nun mal versucht eine Seite in den Flash zu schreiben. Ich möchte ganz einfach ein festes Muster 0x1234 eine Seite lang in den Flash schreiben, beginnend bei der Adresse 0x0000. Die entsprechende Applkation dazu (der spätere Bootloader, siehe Anhang) habe ich bereits per Linkerscript in die Boot-Sektion gemappt und per BOOTRST-Fuse den Resetvektor auf die erste Adresse meines Bootbereichs (0xF000) "umgelegt". Nachdem nun das Muster 128 mal geschrieben worden sein müsste, habe ich mir mit dem AVR-Studio einen HexDump des Flashs erzeugen lassen um nachvollziehen zu können, ob der Flash auch in der von mir beabsichtigten Weise beschrieben wurde..... Wie ihr sicher ahnt hat es nicht funktioniert. Ich kann die Zeichenkette nicht wiedererkennen... Wo liegt mein Denkfehler im Programm? Ich hoffe auf Eure Unterstützung, vG Stephan P.S.: die zeile mit dem pgm_read_... an Anfang kann ignoriert werden, da hatte ich nur versucht zu ermitteln was an Adresse 0x0000 im Flash steht, bevor ich die AVR-Studio-interne Alternative kannte.
Stephan W. schrieb:
> Ich kann die Zeichenkette nicht wiedererkennen...
Und was kannst Du erkennen?
hallo grrr, schön, dass du wieder an meiner Seite bist :-) ich habe mal das HEXDUMP angehangen. Ich weiß noch nicht so recht, ob ich das Hexdump schon richtig "verstehe"... Ich habe den gasamten Flash (128K) als Hexfile herausgeschrieben (siehe Anhang). Da habe ich eigentlich vermutet, dass mein Programm auch bei 0xF000 anfangen müsste, so wie ich es per Linkerskript vermittelt habe. Das Programm (der spätere Bootloader) finde ich zwar in komplettem Umfang wieder, aber erst ab Addresse 0x2A300... das ist das erste, was ich nicht verstehe, warum das an dieser Stelle steht. Dann habe ich natürlich versucht, meinen Hex-Word 0x1234 wiederzufinden. Aber die eingebaute Suche meines Hexeditors (Tiny Hex Editor) lieferte mir keine Treffer. Zumal ich die erste Page (0x0000) im Flash beschreiben "wollte" und somit erwartet habe, dass ich beginnend ab Addresse 0x0000 128 mal "12 34" zu lesen bekomme... Nun habe ich noch festgestellt, dass das Programm immer in der Schleife boot_spm_busy_wait hängt... Denke, dass dort der fehler liegen könnte, aber laut Beispiel in der boot.h soll diese Funktion an dieser Stelle aufgerufen werden... ich weiß nicht weiter... Gruß Stephan
Einen Fehler konnte ich bereits beseitigen: die for Schleife lief endlos, da mein 8-Bit-Zähler nie größer als 256 (=SPM_PAGESIZE) werden konnte,... Das Progamm läuft jetzt durch, die angegebene LED leuchtete auch. Wenn ich das Programm im Debugger durchgehe (F11) dann kommt er allerdings nie über die boot_spm_busy_wait() hinaus. Aber ich denke, dass das ein Problem des Debuggens ist... der Fehler muss also woanders liegen. Ich füge noch den aktuellen Code an. Bin auf Eure Meinung gespannt, vG Stephan
Stephan W. schrieb: > Nun habe ich noch festgestellt, dass das Programm immer in der Schleife > boot_spm_busy_wait hängt... Wie? Poste mal den Linkerscript. Was tut sich bei der Simulation?
Hallo grrr, anbei das Linkerscript. Ich habe damit noch kaum erfahrungen. Ich habe einfach das Standardskript vom avr genommen (arv51.x) und habe die data Section auf den Beginn des Bootloaders (F000) gelegt. Was meinst du mit Simulation? Etwa den Debugger? Dort ist bleibt er nämlich hängen, jedoch nicht, wenn die Applikation auf dem Mikrocontroller ausgeführt wird. Dort scheint alles durchlaufen zu werden und die LED leuchtet am Ende... vG Stephan
Die Tatsache, das die LED angeht, deutet auch für mich darauf hin, das das Pgm. an sich geht. Komisch sind mir: 1. Die while-Schleife mit nichts drin. Toggel da mal einen Port. 2. Ausgerechnet die Zero-Page zum test verwenden. Sollte gehen, aber irgendeine Page die keine besondere Bedeutung hat wäre mir persönlich angenehmer. Stephan W. schrieb: > data > Section Wieso die data Section und nicht text? Ausfühbarer Code sollte eigentlich in text stehen. > Was meinst du mit Simulation? Etwa den Debugger? Nein. Den Simulator. Denke daran, das Du die Fuse für BOOTRST von Hand setzen musst. Gerade im Debugger sollte er nicht in dem Warten auf das Fertigprogrammieren hängen können. Schalte mal auf die Assembler-Ansicht und guck mal was passiert.
ich glaube ich das gefunden, was du als Simulator bezeichnest :-) Der brachte mir noch folgende Warnung bei der Simulation 28-Jan-2010 16:16:18 AVR Simulator: Invalid opcode 0xffff at address 0x00f000 Bei der Simulation blieb er übrigens nicht hängen! vG Stephan
Hallo, unsere Beiträge haben sich wohl eben überschnitten --> natürlich muss es text-Section sein, Fehler von mir, im Script stimmt es aber --> Ich habe nun den AVR Simulator ausgewählt. Wie setze ich die BOOTRST-Fuse von Hand? Im vorhergehenden Post habe ich noch eine Fehlermeldung angegeben, die mir entgegensprang... vG Stephan
Hallo, wenn ich das ganze ding simuliere, dann schreibt er mir brav meine Einträge (wenn auch vertauscht, da ich das "Little Endian" Problem nicht beachtet habe, in den Flash). Warum also nicht auf dem Gerät an sich? Ich werde noch etwas probieren und spätestens morgen berichten. Ich würde mich freuen, wenn du mich dabei noch etwas begleiten könntest. Du hast mir bislang sehr geholfen... Danke dafür! zu Deinen Bedenken: Die Endlos while-Schleife ist derzeit noch sinnlos, das stimmt. Das schreiben der Zero Page hat im Simulator anscheinend geklappt. Sollte es nun auf der Hardware wieder nicht klappen, dann nehme ich mal eine andere Seite. Ich wünsch Dir nen schönen Abend und danke nochmals! vG Stephan
So, nach vielem Hin und Her bin ich jetzt an dem Stand, dass in der Simulation eine gewünschte Seite ordentlich geflasht wird... Im AVR Simulator kann ich gut nachvollziehen, dass alles dort steht, wo es sein soll. Sobald ich das Programm nun wieder auf meinen µC schreibe und dort ausführe wird scheinbar nix in den Flashbereich geschrieben... zumindest sehe ich wiedermal nix von 1234 im Hexdump. Im aktuellen Quellcode (siehe Anhang) habe ich probiert, die vierte Seite im Flash zu schreiben. Ich kann mir nicht erklären, warum das auf dem µC nicht funzt... Kann es sein, dass ich nicht "berechtigt" bin, in die RWW Section zu schreiben? Bootlock-Bits sind jedenfalls so gesetzt, dass keine Einschränkungen bestehen. Ich weiß nicht weiter Ich bin über jede Hilfe dankbar. vG Stephan
Denkst Du daran das erase und write nicht die Seitennummer sondern die Byteadresse als Parameter wollen? Sieht im Code nicht so aus. Hast Du die Doku unter http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html gelesen?
Guten Morgen, Das mit der Addressierung ist mir auch schon ins Auge gefallen. So müsste es doch eigentlich korrekt sein: uint32_t page_address=0x000; //addressiert 1.Seite uint32_t page_address=0x300; //addressiert 4.Seite ...usw. Auch hier macht der Simulator was ich will, aber nicht die Hardware. Die Doku, die du genannt hast habe ich bereits gelesen. Weitergeholfen hat sie mir leider bei diesem Problem nicht. Hast du noch eine Idee? vG Stephan
Hm. Irgendwas müssen wir übersehen haben. Mir fällt noch ein, das die rww section enabled werden muss. Siehe http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html#geb0dba1dd9d338516a94c0bd8a8db78a und Datenblatt. Ich habe am WE wenig Zeit, aber wenn das nicht hinhaut gehen wir Montag nochmal alles systematisch durch.
Hi
>zumindest sehe ich wiedermal nix von 1234 im Hexdump.
Schon mal nach '2143' gesucht?
MfG Spess
Hallo Ihr zwei, danke für Eure Beiträge: @Grrr: hmm, ich dachte bislang, dass die RWW Section lediglich enabled sein muss, damit vom Flash gelesen werden kann (LPM-Befehle)?!? In meinem Programm schreibe ich ja lediglich in den Flash. Das Auslesen habe ich bislang über die AVR-Studio interne Variante des Hex-Exports gemacht (AVR-Symbol --> Programm Tab --> Read im Flashbereich drücken). Aus dem Datenblatt habe ich entnommen, dass RWW automatisch disabled wird, sobald ein SPM-Befehl (schreiben, löschen) auf den RWW ausgeführt wird... Ich habe erst Sonntag abend meinen µC wieder zur Verfügung, bis dahin bleiben mir lediglich einige Experimente mit dem Simulator (wo allerdings alles soweit klappt). Ich danke Dir trotzdem für Deine Hilfe. Auch dass du mir wieder am Montag "beistehen" möchtest finde ich richtig klasse! Dickes Lob. Mach Dir ein schönes Wochenende. @Spess Danke auch für Deine Hilfe. Auf das Little-Endian / Big-Endian Problem habe ich schon geachtet. Wenn ich das ganze im Simulator betrachte, kann ich auch wunderschön die Zeichenkette 1234 eine Seite lang bewundern. Führe ich die Applikation auf der Hardware aus, dann lese ich weder 1234, noch 4321 noch irgend eine andere Kombination dieser 4 Ziffen ;-). Die Applikation selbst kann ich auch im Hexdump wiederfinen, nur eben diese verflixte Seite nicht... Ich glaube, dass ich noch irgendetwas übersehen haben muss. Irgend eine Fuse oder Lockbits, die Hardwaremäßig verhindern, dass ich nicht von der NRWW-Sektion in die RWW-Sektion schreiben darf (Die Bootlock-Bits sind es schon mal nicht.) Da der Simulator diese Fuses (oder was auch immer) anscheinend nicht kennt, kann er auch erfolgreich simulieren. Also, nochmals danke an Euch beide, ich hoffe, dass sich das ganze bald klärt, kann doch so schwer nicht sein, oder? In diesem Sinne, ein schönes WE!!! Stephan
Für den Fall, das ich doch dazu komme, poste bitte mal das komplette Projekt ( den kompletten Ordner nach "Clean" in einer ZIP-Datei) und nenne uns die Version von AVRStudio sowie von WinAVR. Stephan W. schrieb: > dass die RWW Section lediglich enabled sein > muss, damit vom Flash gelesen werden kann (LPM-Befehle) Das ist eben die Frage dabei. Wenn es für den LPM-Befehl nötig ist die RWW Section zu reaktivieren (und, soweit ich weiss, auch für die Ausführung von Code darin) dann ist es zumindest plausibel, das dies auch für das auslesen des Flash nötig sein könnte. Denn dazu greift die CPU vermutlich mit den selben Resourcen auf das Flash zu wie beim LPM oder bei der Ausführung. Der Grund dafür dürfte schlicht ökonomischer Art sein. Warum sollte die Resource zum auslesen des Flash zweimal vorhanden sein? Einmal für LPM und Ausführung und einmal zum auslesen? Auch das die Notwendigkeit des Re-Enablen nicht ausdrücklich in der Dokumentation bestätigt wird, heisst noch nicht, das es tatsächlich nicht nötig ist. Mancher Autor von Dokumentation könnte die gegenteilige Annahme für selbstverständlich halten. (Leidvolle Erfahrung von ein paar Jahrzehnten Doku lesen). Das im Simulator, ich sage mal, "gewisse" Dinge gehen die im realen Prozessor nicht gehen ist, wie auch das Gegenteil, leider eine Tatsache.
Grrr schrieb: > Warum sollte die Resource zum auslesen des Flash zweimal > vorhanden sein? Einmal für LPM und Ausführung und einmal zum auslesen? Und warum sollte diese Resource einmal so gestaltet sein das ein Re-Enable nötig ist und ein andermal so, das dies nicht notwendig ist?
Wie mir gerade noch eingefallen ist (sorry, mein letzter Bootloader ist schon ein paar Monate her), muss die RWW-Section auch nach dem Erase re-enabled werden. Zumindest ist dies bei Deiner Reihenfolge der Fall. Siehe dazu auch das Codebeispiel im Datenblatt, Seite 328 und folgende. Insgesamt muss sie also zweimal re-enabled werden!
Schau Dir mal meinen Bootloader an: Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" Der funktioniert von ATtiny13 bis ATmega2561. Du kannst in ja reinbrennen und den API-Call aufrufen. Die Brennroutine für ATmega >4kB ist in "progmega.inc". Peter
Hallo zusammen, @grrr: ich habe mal ein Zipfile von dem "Projekt" erstellt und mit angehangen. Was mich am Rande noch interessieren würde: Kann man eigentlich wenn man solch ein Projekt im AVR-Studio bearbeitet zwischen dem Simulatormodus (AVR Simulator) und dem "Nicht-Simulator"-Modus (in meinem Fall JTAGICE mkII mit ATMEGA 1281) wechseln? Bisher musste ich für jede Variante ein eigenes Projekt anlegen. Den AVR Simulator konnte ich nur dann verwenden, wenn ich ein Projekt neu angelegt habe... meine AVR-Studio Version: 4.17 Build 666 meine WinAVR Version: WinAVR-20090313 @Peter Danke, dass du mir helfen möchtest und ich Deinen Bootloader nutzen darf. Ich stehe noch ganz am Anfang und da muss ich zugeben, dass mir Dein Code etwas "zu hoch" scheint. Wozu dient mir die API? Die verwendete Syntax der beinhalteten ASM Befehle verstehe ich nicht so recht... Wo kann ich mir denn nen Crashkurs holen, dass ich auch solche Zeilen verstehen kann?: static void apicall( void ) _attribute_ ((noinline)); static void apicall( void ) { asm volatile("ldi r22, %0" :: "M" ((FLASHEND>>1)&0xFF)); // lo asm volatile("push r22"); asm volatile("ldi r22, %0" :: "M" ((FLASHEND>>9)&0xFF)); // hi asm volatile("push r22"); #if( FLASHEND > 0x1FFFF ) asm volatile("ldi r22, %0" :: "M" ((FLASHEND>>17)&0xFF)); // xhi asm volatile("push r22"); #endif asm volatile("ldi r22, %0" :: "M" (API_PROG_PAGE)); // function return; // jump to API } Momentan verstehe ich davon nur Bahnhof... :-( Konntest du beim Anblick meines Codes irgendwelche Fehler feststellen? Also, ich danke Euch vielmals, morgen abend habe ich wieder meinen µC zur Verfügung und dann probiere ich die Sache mit dem RWW-Enablen nochmal aus. Ich finde grrr's Argumentation sehr plausibel, sodass die Hoffnung groß ist :-) In diesem Sinne, nochmals danke für die Unterstützung. vG Stephan
Einen schönen guten Abend, ich habe nun noch verschiedene Sachen ausprobiert. Im Datenblatt des 1281 fand sich auf Seite 328 ein Assembler-Beispiel für einen Bootloader. Dieses habe ich übernommen, für meinen Versuch angepasst (Muster 1234 eine Seite lang schreiben) und siehe da: ES FUNKTIONIERT. Nach dem Auslesen des Hexdumps fand ich meine 1234-Seite wieder :-) Gut, das war auch abzusehen, wenn es im Datenblatt des Herstellers steht. Danach habe ich mir auch nochmal meine C-Variante vorgeknöpft, leider ohne Erfolg. Ich habe einerseits versucht, die RWW Section nach dem Schreibvorgang zu enablen andererseits habe ich mir die Boot.h nochmal angesehen und mein Beispiel vom Ablauf her 1:1 auf das Musterbeispiel in dem header-file angepasst... es tut sich leider nix. Es mag zwar komisch klingen, aber kann es sein, dass die Funktionen der Boot.h nicht bei allen Prozessoren funktionieren? Das glaube ich zwar nicht, aber ich dachte, ich frage Euch mal. Gibt es eigentlich einen Zwischenweg zwischen der Verwendung dieser Funktionen und der Verwendung von reinen Assembleranweisungen? Irgendwie traue ich diesen Boot-Funktionen nicht... :-) Ich freue mich auf Eure Hinweise und Ideen und hoffe, dass wir uns morgen wieder austauschen können. Danke im Voraus, vG Stephan
Guten Morgen, @grrr, wie siehts aus bei Dir? würde das Problem gern mit Dir nochmal durchgehen... vG Stephan
Stephan W. schrieb: > Danach habe ich mir auch nochmal meine C-Variante vorgeknöpft, > leider ohne Erfolg. Ich habe einerseits versucht, die RWW Section nach > dem Schreibvorgang zu enablen Und auch nach dem Löschen? > andererseits habe ich mir die Boot.h > nochmal angesehen und mein Beispiel vom Ablauf her 1:1 auf das > Musterbeispiel in dem header-file angepasst... es tut sich leider nix. So? Postest Du bitte den "aktuellen" Code? Ich habe keine Lust alles nochmal zu tipppen, was Du ohnehin schon eingegeben hast. Da Du mit dem Code aus dem Datenblatt Erfolg hattest, wäre es vielleicht sinnvoll, das Du Dir die App-Notes von Atmel zu dem Thema anschaust.
Stephan W. schrieb: > Kann man > eigentlich wenn man solch ein Projekt im AVR-Studio bearbeitet zwischen > dem Simulatormodus (AVR Simulator) und dem "Nicht-Simulator"-Modus (in > meinem Fall JTAGICE mkII mit ATMEGA 1281) wechseln? Ja. Was geschieht denn, wenn Du die Plattform umschalten willst?
hallo grrr, danke, dass du wieder dabei bist. Im Anhang findest du den aktuellen Quellcode. -Ja, ich führe das RWW-Re-enable auch nach dem löschen durch (siehe source) -Die Boot.h ist eine Header-Datei, die dem AVR-Studio beilag. Sie enthält vorgefertigte Funktion zur verwendung der SPM-Instruktionen in C. -Der Wechsel der Plattform (zum Simulator) gelingt nicht, da der Simulator beim Wechsel (Klick auf "Con"-Symbol im AVR Studio) nicht mit aufgeführt ist... Ich kann ihn lediglich auswählen, wenn ich ein neues Projekt anlege. -ok, ich schaue mir die Appnotes dazu mal an (sofern ich welche finde...) Kannst du mal schauen, ob das Programm bei Dir funktionieret? vG Stephan
Stephan W. schrieb: > -Ja, ich führe das RWW-Re-enable auch nach dem löschen durch (siehe > source) Gut. > -Der Wechsel der Plattform (zum Simulator) gelingt nicht, da der > Simulator beim Wechsel (Klick auf "Con"-Symbol im AVR Studio) nicht mit > aufgeführt ist... Ich kann ihn lediglich auswählen, wenn ich ein neues > Projekt anlege. Hmm. Der Connect-Dialog verbindet zu der Platform, die Du vorher, z.B. unter Debug->Select-Platform-and-Device ausgewählt hast. >Kannst du mal schauen, ob das Programm bei Dir funktionieret? Nein. Kein 1281 da. Aber wenn es in Assembler geht, brauchst Du Dir ja nur noch den Unterschied anzuschauen.
Sag mal, bist Du absolut sicher, das Du beim Anschauen des zurückgelesenen Flash-Speichers auch wirklich nicht das OriginalHex-File vor Dir hast? Sein Datum müsste jünger als das der Originaldatei sein.
Grrr schrieb: >> -Der Wechsel der Plattform (zum Simulator) gelingt nicht, da der >> Simulator beim Wechsel (Klick auf "Con"-Symbol im AVR Studio) nicht mit >> aufgeführt ist... Ich kann ihn lediglich auswählen, wenn ich ein neues >> Projekt anlege. > Hmm. Der Connect-Dialog verbindet zu der Platform, die Du vorher, z.B. > unter Debug->Select-Platform-and-Device ausgewählt hast. Danke, das hat geholfen >>Kannst du mal schauen, ob das Programm bei Dir funktionieret? > Nein. Kein 1281 da. ok, kein Problem > Aber wenn es in Assembler geht, brauchst Du Dir ja nur noch den > Unterschied anzuschauen. Beim vergleich des deassemblierten C-Codes mit dem Assembler Code konnte ich eben leider keine Unterschiede feststellen. Es werden grundsätzlich die gleichen Schritte gemacht... au mann, ich raffe es nicht... vG Stephan
Grrr schrieb: > Sag mal, bist Du absolut sicher, das Du beim Anschauen des > zurückgelesenen Flash-Speichers auch wirklich nicht das OriginalHex-File > vor Dir hast? Sein Datum müsste jünger als das der Originaldatei sein. Schicke doch bitte das HEX-File das Du zurückliest. Wir sind uns darüber einig, das Du im Flash ab Wort - Adresse 0x180 die Bytes 0x1234 (im Simulator) siehst? Du liest von der realen CPU das komplette Flash aus? Womit zeigst Du das Hex-File an?
Stephan W. schrieb:
> au mann, ich raffe es nicht...
Mach' Dir nichts d'raus.
Ich habe da auch schon ganz blöde Dinger gesucht. Mein letzter war in
Assembler und ich dachte schon, das er geht und nach ein paar Tagen ging
es auf einmal nicht mehr. Naja..... Ein paar Packungen Kaffee und
Zigaretten später gings dann wieder.
Stephan W. schrieb: > Beim vergleich des deassemblierten C-Codes mit dem Assembler Code konnte > ich eben leider keine Unterschiede feststellen. Es werden grundsätzlich > die gleichen Schritte gemacht... Das stimmt nicht ganz. In dem Assembler-Code wird jedesmal vor einem SPM-Befehl geprüft ob ein evtl. vorheriger schon fertig ist. Im C-Code ist das nicht so. Man könnte sicherheitshalber nach der Fill-Function nochmal das boot_spm_busy_wait() aufrufen. Das wäre noch so ein Unterschied.
das stimmt, da gebe ich Dir Recht. ich habe noch ein boot_spm_busy_wait hinter der Fill-Funktion eingefügt. brachte leider keinen Erfolg >Wir sind uns darüber einig, das Du im Flash ab Wort - Adresse 0x180 >die Bytes 0x1234 (im Simulator) siehst? Naja, in meinem "jüngsten" Upload hier ist page_address mit 0x100 definiert, sodass er ab Word-Adresse 0x80 das Muster einträgt. Und ja, ich sehe es im Simulator >Du liest von der realen CPU das >komplette Flash aus? Womit zeigst Du das Hex-File an? ich gehe dazu im AVR-Studio auf den AVR-Button, dann auf den Reiter Program, dann im Bereich Flash auf Read und speichere das File ab. Ich bin mir sicher, dass dieser Weg auch funktioniert, da das Auslesen nach dem Beschreiben mit der ASM-Routine ja auch auf diesem Wege funktioniert hat. Im Anhang findest du das Hex-File. Ich schaue es mir mit dem Standard-Windows-Editor notepad.exe an. Nicht hübsch, aber o.k. Habe es auch schon mit anderen Editoren probiert (Tiny Hex View, HexViewer, etc...) vG Stephan
Ich glaub ich hab es. Und zwar sieht man im Debugger, das der Code ab Wortadresse 7800 steht. Da aber kann man den Bootloader garnicht hinsetzen und von da funktioniert im richtigen Chip auch SPM nicht. Der Bootloader kann nach Datenblatt Seite 331 frühestens ab Wortadresse FE00 stehen
das ist mir auch schonmal aufgefallen. Aber ich glaube nicht, dass es daran liegt, da, soweit ich weiß, beim Simulator die FUSES für die Größe des Bootbereichs (Fuse BOOTSZ) und die Verschiebung des Resetvektors auf den Beginn des Bootbereichs(Fuse BOOTRST) manuell per Software festlegen muss, was ich nicht gemacht habe. Wenn ich das ganze auf Hardware bringe, dann sind die Fuses durch mich gesetzt (AVR-Button) und wirken auch. Im Hexfile ist auch ersichtlich, dass das Programm auch wirklich erst ab F000 läuft, nämlich genau an dem Ort, den ich mittels BOOTSZ und BOOTRST festgelegt habe. Ich glaube, dass die 7800, die im Simulator zusehen sind (= 1/2 * F000) nicht ernst zu nehmen sind... Stimmst du dieser Logik zu? vG Stephan
Stephan W. schrieb:
> Stimmst du dieser Logik zu?
Nein.
hmm, aber ich habe doch keinen anderen Einfluss darauf, den Beginn meiner Applikation in den Bootbereich zu legen als über diese genannten Fuses, oder? Gut, im Linkerscript noch (siehe weiter oben: myscript.x), aber dort steht auch als Startadresse der text-Sektion 0xF000. Verstehst du, was ich meine? Ich kann mir auch nicht erklären, warum der AVR-Simulator im Debugger die Adresse 0x7800 statt dem doppelten Wert 0xF000 anzeigt... Und wie gesagt, im gelesenen Hexdump stimmen die Adressen ja auch... Es ist zum Mäuse melken. Stimmst du dieser Logik jetzt zu? Danke für Deine Hilfe, vG Stephan
Es ist definitiv so, das der Simulator echte Wortadresse anzeigt.
Man könnte sonst auch z.B. irgendwelche Sprungadressen garnicht
verwenden, da die im Befehl kodiert sind und der Simulator das Pgm.
nicht einfach irgendwohin schieben kann.
Der Satz über die Boot-Fuses ist Dir grammatisch irgendwie verunglückt.
Ich verstehe nicht was Du mir sagen willst.
Wir müssen hier zwischen zwei Dingen unterscheiden. Die Fuses und das
Linker-File.
Im Linker-File hast Du die Byteadresse 0xF000 stehen und der Simulator
startet folgerichtig bei der Wortadresse 0x7800 entsprechend 0xF000 / 2.
Ich kann im Moment nicht erklären, woher der Simulator die Startadresse
nimmt, da man ja dort die Fuses nicht angeben kann.
Die Fuses aber beeinflussen lediglich die reale Start-Adresse, also den
Wert des PC beim Reset. Ob dort Code liegt oder nicht, beeinflussen
nicht die Fuses sondern der Linkerscript.
Das eine hat mit dem anderen nichts zu tun.
Im Simulator hingegen musst Du unter Debug->AVR-Simulator-Options
einstellen, damit Du die BOOTRST und die Lage-Fuse einstellen kannst.
(Ich habe Dich vor einigen Posts danach gefragt, das aber dann aus den
Augen verloren).
Wenn im Linker file die falsche Adresse steht, kommt er durch die lange
Kette NOPS dann eben irgendwann auch zu 0x7800 aber das soll ja nicht so
sein.
Stephan W. schrieb:
> Stimmst du dieser Logik jetzt zu?
Also, leider stimme ich auch jetzt nicht.
Grrr schrieb: > Ich kann im Moment nicht erklären, woher der Simulator die Startadresse > nimmt, da man ja dort die Fuses nicht angeben kann. Das ist natürlich Quatsch. Ich meinte, das Du die Fuses vermutlich nicht angegeben hast.
Äh. Ist das verständlich? Bin wohl etwas müde gerade.
Stephan W. schrieb:
> Und wie gesagt, im gelesenen Hexdump stimmen die Adressen ja auch...
Im Intel-Hex-File haben wir ja auch Byte-Adressen. Daher "scheint" es zu
stimmen. Stimmt aber nicht.
DAS PROBLEM IST GELÖST!!!!!!! Im Grunde hast du mir die entscheidende Wende gegeben mit: >Im Linker-File hast Du die Byteadresse 0xF000 stehen und der Simulator >startet folgerichtig bei der Wortadresse 0x7800 entsprechend 0xF000 / 2. und ich habe richtig geschlussfolgert, indem ich den Beginn der .text section im Linker-File auf 1E000 (2*F000) gesetzt habe. Damit komme ich auf die richtige Word-Adresse und siehe da: HEXDUMP: ... ... ... :1000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40 :1000D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF30 :1000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20 :1000F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF10 :1001000012341234123412341234123412341234BF :1001100012341234123412341234123412341234AF :10012000123412341234123412341234123412349F :10013000123412341234123412341234123412348F :10014000123412341234123412341234123412347F :10015000123412341234123412341234123412346F :10016000123412341234123412341234123412345F :10017000123412341234123412341234123412344F :10018000123412341234123412341234123412343F :10019000123412341234123412341234123412342F :1001A000123412341234123412341234123412341F :1001B000123412341234123412341234123412340F :1001C00012341234123412341234123412341234FF :1001D00012341234123412341234123412341234EF :1001E00012341234123412341234123412341234DF :1001F00012341234123412341234123412341234CF :10020000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE :10021000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEE :10022000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDE ... ... ... Ich denke damit ist es gelöst. Ich möchte Dir für all Deine geleistete Hilfe abermals danken! Es ist großartig, wenn sich jemand, den man noch nicht einmal kennt soviel Zeit für jemand anderen nimmt, um ihm zu helfen. Hut ab! In diesem Sinne wünsche ich Dir alles Gute, vG Stephan
Stephan W. schrieb: > Im Grunde hast du mir die entscheidende Wende gegeben Ich weiss. :-) Stephan W. schrieb: > Ich möchte Dir für all Deine geleistete Hilfe abermals danken! Es ist > großartig, wenn sich jemand, den man noch nicht einmal kennt soviel Zeit > für jemand anderen nimmt, um ihm zu helfen. Hut ab! Alles sublimierte Agression... Aber, schön, dass Du Dich bedankst. Stephan W. schrieb: > In diesem Sinne wünsche ich Dir alles Gute, Gleichfalls.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.