www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik einfach mal eine Seite in den Flash schreiben.


Autor: Stephan W. (stephan-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan W. schrieb:
> Ich kann die Zeichenkette nicht wiedererkennen...

Und was kannst Du erkennen?

Autor: Stephan W. (stephan-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan W. (stephan-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stephan W. (stephan-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan W. (stephan-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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__... 
gelesen?

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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__...
und Datenblatt.

Ich habe am WE wenig Zeit, aber wenn das nicht hinhaut gehen wir Montag 
nochmal alles systematisch durch.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>zumindest sehe ich wiedermal nix von 1234 im Hexdump.

Schon mal nach '2143' gesucht?

MfG Spess

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan W. (stephan-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

@grrr, wie siehts aus bei Dir? würde das Problem gern mit Dir nochmal 
durchgehen...

vG Stephan

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Boot.h ?

Was meinst Du damit eigentlich?

Autor: Stephan W. (stephan-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan W. (stephan-w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan W. schrieb:
> Stimmst du dieser Logik zu?

Nein.

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Äh. Ist das verständlich? Bin wohl etwas müde gerade.

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan W. (stephan-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Grrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.