INTEL HEX file aus AVR Studio so richtig?

AVRli Gast #538944
Lesenswert?
• ▲
▼ 
Hi!

Ich habe einen Bootloader geschrieben wo man mithilfe des PC ein 
normales Intel HEX file einschreiben kann.

AVR Studio erzeugt mir folgenes fiele...

Ausschnitt:

1 :020000020000FC
2 :020000007DC7BA
3 :02001C00B5C667
4 :02004000E5C613
5 :020028005AC7B5
6 :0200480082C272
7 :02004C00BBC136



Mein Bootloader hängte sich immer an Zeile 5 auf und machte dann MURX.
Grund ist das erst Adresse 40 kommt dann Adresse 28 und dann Addresse 
48.

Da kommt es aus dem Tritt... sollte es nicht der reihe nach gehen?

28
40
48

also...

1 :020000020000FC
2 :020000007DC7BA
3 :02001C00B5C667
4 :020028005AC7B5
5 :02004000E5C613
6 :0200480082C272
7 :02004C00BBC136


dann klappt es auch mit dem einschreiben in den µC...

Hmm, kann es sein das das AVR Studio eine falsche Ausgabe macht oder ist 
es wirklich erlaubt das man mit den Adressen springen kann????


Gruß AVRli...
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
crazy horse Gast #538950
Lesenswert?
• ▲
▼ 
da beim Hex-File zu jeder Zeile eine Startadresse angegeben ist, ist die 
Zuordnung eindeutig. Es muss nicht in in der physikalisch aufsteigenden 
Folge angeordnet sein (ist es aber meist). Es wird also an deinem 
Bootlader liegen, der die Daten nicht richtig eintütet.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter Werner Gast #538959
Lesenswert?
• ▲
▼ 
> physikalisch aufsteigenden Folge angeordnet sein (ist es aber meist)

Da gibt es leider die abenteurlichsten Verrenkungen.
Der C18 Compiler von Microchip z.B. würfelt die Adressen wie bekloppt 
durcheinander.
Ich hab mir extra ein Sortierprogramm auf'm PC geschrieben um das in die 
passende Reihenfolge zu bügeln da der bootloader das nicht auseinander 
dividiert kriegt.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
AVRli Gast #538978
Lesenswert?
• ▲
▼ 
Hallo,

danke für die Antworten.
Ok ich muß ehrlich sagen das ich mich darüber wunder das die Adressen 
durcheinander und nicht der Reihe nach vergeben werden dürfen.

Man kann im Bootloader doch nur Pageweise schreiben und wenn die eine 
Adresse dann schon im Bereich der nächsten und die nächste Zeile im 
Bereich der vorherigen ist, wird es interessant... ;-)

Ok ich werde mir eine Sortiertroutine auf dem PC schreiben, das kann ja 
nicht sooo aufregend sein.

Damit ist meine Frage beantwortet und ich weiß nun das ich auf dem PC 
das file so bearbeiten muß das es für meinen Bootloader der der Reihe 
nach geht damit zurecht kommt.

Danke vielmals...
MfG AVRli
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Knut B. (Firma: TravelRec.) Persönliche Seite #539053
Lesenswert?
• ▲
▼ 
Normalerweise schreibt AVR-Studio die HEX-Files in der aufsteigenden 
Reihenfolge. Wenn Du allerdings wild verteilte .ORG - Instruktionen in 
Deinem Code hast, dann kommt oben Gesehenes dabei heraus. Die typischen 
Hex-Files enthalten außerdem 16 Datenbytes und nicht nur 2.
Dein Bootloader sollte folgendes machen: Anwender-Flash komplett löschen 
(alles "FF"). SRAM-Page-Buffer komplett mit "FF" beschreiben. Ankommende 
HEX-Daten in den Pagebuffer einsortieren, und zwar nur die laut HEX-File 
betroffenen Adressen. Die anderen bleiben "FF". Wenn die 
HEX-File-Adressen die aktuelle Page-Adresse verlassen, Flash-Page 
schreiben. Da gleiche Adressen in einem HEX-File nicht vorkommen, kann 
eine Flash-Page so mehrfach beschrieben werden, da die nicht betroffenen 
Adressen mit "FF" aus dem Buffer überschrieben werden, was an einer 
bereits beschriebenen Flash-Zelle nichts ändert.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
AVRli Gast #539641
Lesenswert?
• ▲
▼ 
Hi,

in der Tat, es ist wie Travel Rec. es beschrieben hat.
Ich habe bei den Interrupteinsprungadressen mich nicht ganz an die 
Reihenfolge gehalten wie es vorgesehen ist...

1
.org OVF0addr

2
  rjmp  int_TIMER0        ;T/C0 Überlauf-Int.

3
.org OVF2addr

4
  rjmp  int_TIMER2        ;T/C2 Überlauf-Int.


ändert man in...

1
.org OVF2addr

2
  rjmp  int_TIMER2        ;T/C2 Überlauf-Int.

3
.org OVF0addr

4
  rjmp  int_TIMER0        ;T/C0 Überlauf-Int.


und schon stimmt es wieder, super daumenhoch
Dann klappt auch alles, das ist sehr schön.

Ähm was die 16 Byte Breite angeht, die habe ich schon, nur bei den 
ersten sind es halt 2 Byte und da trat der Fehler auf. Deshalb nur die 
Stellen wo der "Fehler" war.

Problem geköst ohne viel Aufwand, nun noch merken das man sich immer 
schön an die Reihenfolge zu halten hat.

:-D


MfG AVRli...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren