Forum: Mikrocontroller und Digitale Elektronik Bootloader ATmega128 verstehen!?


von AVRli (Gast)


Lesenswert?

Hallo zusammen,

ich möchte mich nun mit dem Bootloader des ATmega128 beschäftigen.
In der Codesammlung habe ich auch die ganzen Beiträge schon gesehen.

Ist das wirklich alles so aufwendig?

Im Abschnitt Bootloader im Datenblatt ist der angebliche Quelltext auf 
einer Seite. Ich brauche keine Autobauderkennung oder Verschlüsselung.

Ich mag auch nicht einfach nen Quelltext übernehmen den ich nicht 
verstehe.

Ich möchte eine minimal Routine schreiben die den Inhalt des 
Programmmemorys aktualisisert und das auslesen denoch verhindert.

Wie fängt man da am besten an?
Hat jemand den Nerv das mal Stück für Stück zu erklären?

Wenn ich es richtig gelesen habe hat man einen Bereich im FLASH der 
nicht überschriben werden kann. In diesem muß das Programm welches 
ausgeführt werden soll um die Daten anzunehmen.

In meinem Fall soll das neue HEX file über die RS232 geladen werden.
Die gesamten Daten würde ich also im SRAM zwischenspeichern können.
Wenn das kopieren in den SRAM abgeschlossen ist soll man über ein Befehl 
den Inhalt in den Programmemory übernehmen. Nach einem RESET ist das 
dann ok und das neue Programm läuft.

Ist das im Ansatz ok?


Gruß AVRli...

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

>Ich möchte eine minimal Routine schreiben die den Inhalt des
>Programmmemorys aktualisisert und das auslesen denoch verhindert.

Was hindert Dich? Allerdings mußt Du mindestens alle benötigten Routinen 
für das Ansprechen des Flashs programmieren, da kommst Du nicht ´rum. 
Der Bootloader hat nichts mit dem Auslesen zu tun, dafür sind die 
LockBits zuständig. Wenn die alle gesperrt sind, wird´s auch mit dem 
Auslesen nichts mehr.

>In meinem Fall soll das neue HEX file über die RS232 geladen werden.
>Die gesamten Daten würde ich also im SRAM zwischenspeichern können.
>Wenn das kopieren in den SRAM abgeschlossen ist soll man über ein Befehl
>den Inhalt in den Programmemory übernehmen. Nach einem RESET ist das
>dann ok und das neue Programm läuft.

Soviel SRAM hast Du im Leben nicht. Im ungünstigsten Fall ist Deine .HEX 
über 270kByte groß (volle 128k Code mal Faktor 2.3 für das .hex Format). 
Dein Bootloader muß also die kommenden Daten sofort in Binärcode 
umfriemeln, in den SPM-Buffer schreiben und dann in´s Flash drücken, 
während er munter weiter über RS232 mit Daten bepflastert wird. Alleine 
das ist schon nicht mehr ganz trivial. Guck Dir mal die 
Bootloadebeschreibung im Datenblatt des Mega128 an und bau Dir dann die 
notwendigen "ZulieferRoutinen" drumherum.

von Stefan (Gast)


Lesenswert?

"Ist das im Ansatz ok?"

Ja.

Wobei ein HEX-File noch zu dem eigentlichen Binärfile dekodiert werden 
muss. Daher ist es vielleicht schlauer das Dekodieren auf dem Host (PC) 
zu machen und gleich das Binärfile zum Target (Atmega128) zu übertragen.

von unsichtbarer WM-Rahul (Gast)


Lesenswert?

>Ist das im Ansatz ok?
Ja.
Probier doch zuerst mal aus, eine Intel-Hex-Datei an den Controller zu 
schicken und sie dort zu dekodieren (und die Prüfsumme zu berechnen).
Danach würde ich mich an den Bootloader machen.
Sowas hatten wir damals an der FH als Terminal-Programm für den 8051.
Da konnte man dann auch eine (Hex-)Datei übertragen und dann ausführen 
lassen.

von AVRli (Gast)


Lesenswert?

Danke Euch für die Antworten, werde es erstmal so machen wie 
"unsichtbarer WM-Rahul" es vorgeschlagen hat, Stück für Stück zum Ziel.

Denke mir das wenn man das alles mit Chk Summen berechnet es kaum schief 
gehen kann. Naja mal sehen wann's raucht :-D

Bis die Tage ich spiel mal...

MfG AVRli...

von Stefan (Gast)


Lesenswert?

Am besten gleich sowas wie X-Modem Protokol implementieren, dann braucht 
man für den PC keine Zusatzsoftware schreiben, und kann mit einem 
handelsüblichen Terminalprogramm das Programm übertragen.

Stefan

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Zusatzsoftware für den PC schreiben ist nicht nötig, XModem auch nicht, 
es gibt aus dem PC-Forum hier ein nettes Programm namens HTerm, damit 
geht das alles wunderbar. Einfach die .hex an den Controller senden, der 
Bootloader macht den Rest.

von AVRli (Gast)


Lesenswert?

Hi,

um die Zusatzsoft auf dem PC mache ich mir die kleinsten Gedanken, da 
bich etwas fitter als in ASM. ;-)

Ich habe nun angefangen, Programm was die Aktion Bootloader sein soll 
ist im Speicher plaziert und wird auch dort abgelegt. Soweit sogut.

Nun denke ich das ich die ganzen UART Sachen auch in diesen Bereich 
legen muß. Denn wenn ich "update" dann fängt er ja an die Bereiche zu 
überschreiben und irgendwann hat er dann auch meine UART Sachen aus dem 
Tritt gebracht oder?

Kann man speziel für den BOOTLOADER neue Einsprungadressen deklarieren 
oder geht das nur einmal im gesamten Programm?

Oder wie läuft das... ;)

Gruß AVRli --... ...--

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Die USART-Sachen müssen zwingend im Bootloader untergebracht werden. 
Dabei ist es am einfachsten, wenn der Bootloader und das eigentliche 
Programm komplett eigene USART-Routinen hat, dann muß man nicht 
umdeklarieren und das Programm kann so geschrieben sein, als gäbe es den 
Bootloader gar nicht. Prinzipiell muß das Programm von dem Bootloader 
gar nichts wissen, dann läuft nämlich jedes Programm, was auch sonst 
ohne den Bootloader laufen würde (abgesehen von denen, die das ganze 
Flash für sich beanspruchen). Wenn der Bootloader auch noch ohne 
Interrupts auskommt, muß man nicht mal die Vektoren verbiegen, bevor man 
in´s Hauptprogramm springt. Aber das ist reine Geschmacksache.

von AVRli (Gast)


Lesenswert?

@Travel Rec.
Ok soweit verstnaden, wir würde es den aussehen wenn man die Vektoren 
verbiegen möchte. Ich wüste im Moment nicht wie man es ohne den 
Interrupts macht.

Also ich könnte mir schon vorstellen das ich die generell erstmal auf 
die BOOTLOADER Sachen lege und dann wenn der nicht gebraucht wird 
einfach auf's Heuptprogramm.

Ich möchte ja den BOOTLOADER starten indem ich nach dem RESET eine Taste 
gedrückt halte. Ist die gedrückt dann bootloader sonst Mainprogramm.

Gruß AVRli...

von AVRli (Gast)


Lesenswert?

Hallo,

der aktuelle Stand ist nun bei mir folgender.
Boot Loader und Application Section ist klar.
Eigene Interrupts im Boot Loader gehen auch.
Dazu eben folgene Zeilen verwendet.

ldi wrH, (1<<IVCE)        ;Enable change of interrupt vectors
out MCUCR,wrH
ldi wrH, (1<<IVSEL)        ;Move interrupts to boot flash section
out MCUCR,wrH
sei              ;INTERRUPTS freigeben

Im Hauptporgramm initialisisert man das wieder um und alles geht so wie 
es vorher ging ;-)

Daten werde nun vom Boot Loader eingelesen nun geht es an das 
eigendliche, die INTEL HEX Auswertung. Dazu habe ich mir ein kleines 
Tool auf dem PC geschrieben um gezielt eine Zeile zum ATMEL zu schicken. 
Die kommt auch schon an, nun das Auswerten, dann das einschreiben.

Das mit dem Einschreiben ist mir noch nicht ganz klar, kann man eine 
beliebe Anzahl einschreiben oder gehen auch jeweils eine Zeile Daten?

Das Intel HEX Format hat ja im güstigsten Fall 16 Byte die ab Adresse X 
geschrieben werden, könnte ich das auch so abarbeiten? Zeilenweise?


Gruß AVRli...

von Peter D. (peda)


Lesenswert?

AVRli wrote:

> Das Intel HEX Format hat ja im güstigsten Fall 16 Byte die ab Adresse X
> geschrieben werden, könnte ich das auch so abarbeiten? Zeilenweise?

Nö, erlaubt sind 0 ... 255 Byte pro Record.
Viele Programme erzeugen maximal 16 Byte, ist aber kein Muß.

Allerdings sollte man schon auf dem PC nach binär wandeln, das 
verdreifacht fast die Programmiergeschwindigkeit (HEX ~ 2,8 * BIN).


Auch braucht man ne Art Handshake, da oftmals während des Flashens einer 
Page die CPU steht, d.h. nicht empfangen kann.

Ich hab in meinem Mega8 nen Buffer von 512 eingerichtet, d.h. der PC 
sendet max 512 Byte am Stück und wartet dann auf die Fertigmeldung des 
Mega8.


Peter


von Peter D. (peda)


Lesenswert?

AVRli wrote:

> Im Hauptporgramm initialisisert man das wieder um und alles geht so wie
> es vorher ging ;-)

Nö, das Hauptprogramm erwartet den Resetzustand.

D.h es ist die verdammte Pflicht des Bootloaders, alle verbogenen 
Register wieder gerade zu richten.


Ein Bootloader hat ja nur eine Aufgabe, d.h. es ist ein leichtes, ihn 
ohne Interrupts zu schreiben (UART pollen).


Peter

von AVRli (Gast)


Lesenswert?

Hi,

ok mit dem Resetzustand habe ich nun geändert, ich möchte ja in jedem 
Fall das der Boot Loader vom Hauptprogramm völlig getrennt ist. Warum 
man es dann so machen sollt leuchtet sogar mir dann ein. :-D

Nun bin ich aber auf ein ganz anderes Problem gestoßen und habe keinen 
Rat.

.cseg
.org FOURTHBOOTSTART
...
  Interrupt Einsprungadressen
...

BL_CMD_UPDATE:    .db "UPDATE",0


BL_NEW RX:
ldi ZL, low(BL_CMD_UPDATE*2)
ldi ZH,high(BL_CMD_UPDATE*2)
...


Das Problem ist das Z nicht die Adesse 0xF040 enthält sondern 0xE080.
Das liegt mit Sicherheit an der (BL_CMD_UPDATE*2) Anweisung, nur wie 
geht es an dieser Stelle denoch?

Gruß AVRli...

von AVRli (Gast)


Lesenswert?

Hi,

also ich habe nochmal gelesen, wenn ich es richtig verstanden habe kann 
man Zeichenketten nur in den ersten 64kb ablegen weil man im 
Programmmemory immer *2 machen muß. Das kann dann nix werden.

Problem ist hier so gelöst das ich meinem "Befehl" UPDATE nun Buchstabe 
für Buchstabe vergleiche, ist ja nicht schlimm... ;)

Dann geht's auch wieder.

Gruß AVRli...

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.