Boot Loader

Hero_123

Mitglied
17. Sep. 2010
183
3
18
Sprachen
  1. ANSI C
Hallo!

Bei meinem ATMega8 sind für den Boot Loader 1024 Worte (2kByte) reserviert (Boot Fuse programmiert), somit für Anwenderprogramm 3096 Worte (6kB) möglich.
Wenn ich ein (ganz kleines) Programm erfolgreich mit dem AVR Studio 4 kompiliere, wird angezeigt:

Program: 124 bytes (1,5% Full)
(.text +.data + .bootloader)

Data: 0 bytes (0.0% Full)
(.data +.bas + .noinit)

das heißt doch dann für mich, dass ich zu den 124 bytes Program noch die 1024 Worte (= 2048 bytes) dazuaddieren müßte, oder?
Das heißt dann wiederum, dass mein "größtes" Programm nicht größer als 6kB werden darf, sonst ....

Die Anzeige (.text +.data +.bootloader) ist m.E. verwirrend, da ja noch nicht die 2048 Bytes Boot Loader dazuaddiert wurden - oder mache ich da einen Fehler?


mfg

Hero_123
 
Also ich hab mich mit Bootloadern selbst noch nicht beschäftigt (beschäftigen müssen), aber meinem Verständnis nach reserviert die BOOTRST-Fuse nicht irgendwelche Speicherbereiche, sondern leitet ganz einfach nur die Reset-Adresse (also den Wert, der beim Reset in den Program Counter geladen wird) von Null nach "irgendwohin" um. "Irgendwohin" wird dabei durch die BOOTSZ-Fuses festgelegt (also 'ne konkrete Adresse). Was da für'n Code steht, ist eigentlich Wurscht (da muß weder irgendwelcher Code von irgendwo geladen werden, noch überhaupt irgndwelche Flash-Adressen beschrieben (programmiert) werden).
Aber die SPM-Instruction geht nur, aus diesem Bereich heraus.

Die Interrupt-Vektoren können übrigens auch in diesen Bereich umgeleitet werden, durch das IVSEL-Bit im GICR. D.h. im Bootloader können andere Interruptvektoren festgelegt werden, als später im Hauptprogramm wirksam werden sollen. (oder genauer: Mit IVSEL kannst Du quasi alternative ISRs implementieren, und zwischen denen zur Laufzeit umschalten lassen).

Der von Dir erzeugte Code enthält selbst keinen Bootloader (also besser gesagt keinen Code, der im entsprechenden Bereich landen soll), sondern eben nur 62 Words Instruktionen.
 
Zuletzt bearbeitet:
Hallo Hero,

dein Atmega8 hat 8kByte Programmspeicher (Flash memory).

Du hast aktuell 124Byte belegt, das sind 1,5% (allerdings vom gesamten Flash memory)
100%/8192Byte x 124Byte = 1,513%

.text +.data + .bootloader = Programm und Tabellen und Initialisierungen (Flash Memory)


Der Bootloader liegt am Ende des Flash Memory. Es gibt vier mögliche Einsprungadressen (dadurch ergeben sich vier Speichergrößen für den Bootloader).
Diese stellst du mit den Fuses BOOTSZ1 und BOOTSZ0 ein.

Dem Linker musst du noch mitteilen, ab wo er den Programmcode des Bootloaders ablegen soll.

Beispiel:
2kByte Bootloader
Startadresse 0xC00 (WORD) = 0x1800 (BYTE)
BOOTSZ1 = 0
BOOTSZ0 = 0
0 = programmiert

Toolchain
AVR/GNU Linker
General Options
-Wl,-section-start=.text=0x1800


Wenn du den Bootloader erstellt hast, kannst du dir die Position des Bootloader mit diesem Windows-Tool anschauen und kontrollieren ...

Dirk :ciao:
 
Hallo Dirk, hallo LotadaC

Vielen Dank für Eure Hilfe!

@Dirk - ich habe mir Dein Tool "AVR-HexVierwer" runtergeladen und installiert und den Speicher meines ATMega8 ausgelesen und bin etwas irritiert - das Programm beginnt ab Adresse 0x0000 - das ist ja korrekt. Ich hatte aber erwartet, dass ab Adresse 0x1800 die Daten des Boot Loaders zu sehen wären (da der ATMega8 mit installiertem Boot Loader und den Einstellungen gemäß Deinem Beispiel geliefert worden war) - aber das ist nach 0x00980 nichts - alles 0xFF im AVR HexViewer .... komisch.

Daten waren gemäß AVR HexViewer nur von 0x0000 - 0x009800 vorhanden (was gemäß -lss file auch korrekt ist -Anzeige lss - file 0x9a2 <__stop_program>).

Fast sieht es so aus, als wäre da kein Boot Loader drauf (es handelt sich um das Board "myAVR Board MK2" des myAVR - shops http://shop.myavr.de/index.php?sp=artlist_kat.sp.php&katID=14)...

Na jedenfalls verstehe ich Deinen Post #3 so, dass ich die Einstellungen so machen muss:
Beispiel:
2kByte Bootloader
Startadresse 0xC00 (WORD) = 0x1800 (BYTE)
BOOTSZ1 = 0
BOOTSZ0 = 0
0 = programmiert

Toolchain
AVR/GNU Linker
General Options
-Wl,-section-start=.text=0x1800
wenn ich selbst einen Boot Loader drauf laden will mit max 1024 Worte.

Wenn ich nur mein normales Programm laden will, muß ich aber keine Adresszuweisung vornehmen, oder?

mfg

Hero_123
 

Anhänge

  • ATMega8.gif
    ATMega8.gif
    34,9 KB · Aufrufe: 7
Hallo Hero,

anscheinend ist kein Bootloader programmiert, vielleicht hattest du den mal über ISP Programmierung gelöscht?!
(Dass du nur 0xFF liest, hat eventuell was mit Bootloader-Lockbits zu tun)

Kannst du denn ein Programm von dir über den Bootloader programmieren?

Wenn du keinen Bootloader nutzt, dann setzt du BOOTRST auf 1 (unprogrammiert, Resetadresse ist nun 0x0000). BOOTSZ1..0 sind dann egal.

Wenn du dein eigenes Programm erstellst, soll das ab Adresse 0x0000 starten, dann also keinen anderen Startpunkt angeben.

Erstellst du einen Bootloader der 1024 Word (2048 Byte) groß ist, musst du die Einstellungen so vornehmen, wie schon beschrieben.

Dirk :ciao:
 
Hallo Dirk

Vielen Dank für Deine Hilfe :)

Ich habe es jetzt nochmal ausprobiert und bei meinem ATMega8 das BOOTRST auf 1 gesetzt - das Ding läuft OHNE Boot Loader (d.h.ich kann Programme ohne Boot Loader flashen)! Da ist tatsächlich kein Boot Loader programmiert, obwohl es bei "myAVR.de" etwas anders dargestellt wird ...(da wird immer empfohlen, den ATMega mit Boot Loader zu ordern)

Ich weiß jetzt jedenfalls Bescheid:
- bei mir ist kein Boot Loader programmiert, zum Flashen ist auch keiner nötig :)
- wenn ich (jemals) einen Boot Loader benötigen sollte, muß ich so vorgehen, wie Du es in #3 beschrieben hast.
- mein Programm startet bei 0x0000

Kein Boot Loader heißt dann aber auch für mich, dass ich die 8kB für mein Programm zur Verfügung habe :)

Achja - Dein AVR HexViewer - tolles Tool :good3:

mfg

Hero_123
 
Ich habe es jetzt nochmal ausprobiert und bei meinem ATMega8 das BOOTRST auf 1 gesetzt - das Ding läuft OHNE Boot Loader (d.h.ich kann Programme ohne Boot Loader flashen)!
Die BOOTRST-Fuse wirkt sich (nur) auf den Start des Controllers nach dem Reset (also jeden echten Start) aus. Mehr nicht. Sie legt lediglich fest, ob der Controller den Flashinhalt ab Adresse 0x0000 ausführt, oder ab der durch BOOTSZ bestimmten Adresse.
Unabhängig von dieser Fuse kannst Du den Controller trotzdem via SPI-ISP programmieren (sofern SPIEN aktiv, und RSTDSBL inaktiv sind). Üblicherweise geht dem flashen via SPI-ISP ein Chiperase voraus, der dann je nach Boot-Lockbits auch den Boot-Bereich mit löscht.

Willst Du einen vorhandenen Bootloader verwenden, übernimmt der Loader ja das eigentliche Flashen - es wird nicht wie sonst üblich via SPI-ISP geflasht.
Wie dem Loader der Code zugeführt wird (und wie das Flashen gestartet wird) ist Sache des Loaders (also dem Code, der ab der, durch BOOTSZ festgelegten Adresse ausgeführt wird) . Meist über den UART, aber prinzipiell ist alles möglich: vorhandene Hardware-Schnittstellen, irgendwelche Software-implementierten Schnittstellen, was auch immer...
Achja - Dein AVR HexViewer - tolles Tool :good3:
Der wertet aber auch nur das zu programmierende HEX-File aus, also nicht, was sich wirklich (vorher) im Controller befindet. Ader hast Du den Controllerinhalt auslesen lassen, und das ausgelesene Hexfile ausgewertet?

Du Implementierst im Studio einen Bootloader, und flasht den via SPI-ISP ab einer der vier BOOTSZ-Adressen in den Flash, und setzt die BOOTRST-Fuse entsprechend.
Dieser Zustand ist ggf bei Deinem Controller bereits vorhanden gewesen.
Der Controller startet dann bei jedesmal mit dem Code des Loaders - Ziel ist dann normalerweise, zu flashenden Code zu laden, d.H. Du brauchst "PC-seitig" 'ne zum Loader passende Software, die mit dem Loader kommuniziert. Wird dieser Kontakt nicht hergestellt, startet der Loader "das normale Programm" oder korrekter: er springt zu Adresse 0x0000. Der Loader aknn natürlich weitere Bedingungen enthalten, zB daß irgend'ne Taste beim Start des Programmes gedrückt sein muß/ein Jumper gesteckt,...
 
Zuletzt bearbeitet:
Hallo LotadaC

Vielen Dank für Deine Hilfe :)

Ader hast Du den Controllerinhalt auslesen lassen, und das ausgelesene Hexfile ausgewertet?

Ich habe den Flash Speicher meines ATMega8 auslesen lassen (wollte ja wissen, wo bzw ob ein Boot Loader implementiert ist - siehe auch #4).
Ich habe dann die Fuses ausgelesen:
- Low Fuses: FD
- High Fuses: D8
- Lock Bits: FF

=> BOOTRST Flag gesetzt (Boot Loader enabled), Lock Bits Mode1, BLB0 Mode1, BLB1 Mode => gemäß Atmel Doku bedeutet das ja "no Memory lock features enabled", "no lock on SPM and LPM in Application section","no lock on SPM and LPM in Boot section", d.h. für mich, dass ein evtl vorhandener Boot Loader überschrieben bzw beim Chip erase gelöscht wird, wenn ich mein Anwenderprogramm flashe (ich habe im AVR Studio angegeben, dass vor dem Flashen der Chip gelöscht wird)
Ich habe dann das BOOTRST Flag disabled, den Boot flash size von 1024 words habe ich gelassen
- Low Fuses: FD
- High Fuses: D9
- Lock Bits: FF

Geflasht wird der Prozessor mittels http://shop.myavr.de/Systemboards u...er und Bridge).htm?sp=article.sp.php&artID=42 (der 10-polige ISP Stecker ist nicht aufgelötet, ich flashe per USB).

Wenn ich also (irgendwann mal zum testen) einen Boot Loader implentieren würde, müsste ich das BOOTRST Flag setzen, die Lock Bits entsprechend setzen und so vorgehen, wie Dirk in #3 beschrieben hat.

mfg

Hero_123
 
Hallo Dirk

Nochmal zu Deinem post #3
-Wl,-section-start=.text=0x1800

diese Angaben beim Linker sind nur für den Boot Loader nötig, oder? Wenn ich ein "normales" file übersetzen/linken lasse, ist diese Angabe nicht mehr nötig, oder?

mfg

Hero_123

Nachtrag - ich hab's mal eingegeben bei den Linker Options - wenn ich ein "kleines" file übersetze / linke => kein Problem; bei einem größeren Programm erhalte ich eine Fehlermeldung des AVR Studio 4.18 " .....address 0x2116 of ampel_neu.elf section .text is not within region text"(das Programm normal übersetzt => Program: 2338 bytes
Data: 50 bytes
 
Zuletzt bearbeitet:
Hallo Dirk

Vielen Dank für Deine Hilfe :)

Alles klar!!

mfg

Hero_123
 
Nachtrag - ich hab's mal eingegeben bei den Linker Options - wenn ich ein "kleines" file übersetze / linke => kein Problem; bei einem größeren Programm erhalte ich eine Fehlermeldung des AVR Studio 4.18 " .....address 0x2116 of ampel_neu.elf section .text is not within region text"(das Programm normal übersetzt => Program: 2338 bytes
Data: 50 bytes

Der Linker versucht dein Programm ab Adresse 0x1800 im Flash Memory abzulegen. Dies ist die Startadresse für den Bootloader mit max. 2048 Byte Größe. Dein Programm ist nun aber größer (2338 Byte), das passt nicht mehr in das Flash Memory (0x1800 + 2338d > 8192d). Der Linker "beschwert" sich somit. :)

Dirk :ciao:
 
Hallo Dirk

Vielen Dank für Deine Hilfe :)

Mann, klar - 0x1800 = 6144d!!! Das hab' ich glatt ... übersehen!!!! Schande (über mich) :mad:.

mfg

Hero_123
 
Hallo

Was passiert, wenn ich ein file auf den ATMega8 flashe, das größer als 6144d ist, wenn auf dem ATMega8 ab 0x1800 der Bereich für den Boot Loader beginnt und dieser Bereich gelockt ist? Da müßte der Flashvorgang abgebrochen werden, oder?
Das AVR Studio 4.18 "weiß" (der Compiler / Linker) ja nicht, dass das file nicht größer als max 6142d sein darf und würde deshalb auch keine Warnung beim Compilieren ausgeben.

mfg

Hero_123
 
Der Compiler/Linker weiß nicht, was sich im Flash Memory des Mikrocontrollers befindet. Spätestens beim Verify wird der Programmer-Dialog einen Fehler melden.

Wenn du zuvor das Kommando Chip-Erase ausführst, dann wird das komplette Flash Memory gelöscht, auch die Lockbits. Eventuell ist das am Anfang ja bei dir passiert, weil anscheinend kein Bootloader programmiert war.

Dirk :ciao:
 
Hallo Dirk

Vielen Dank für Deine Hilfe!

Bei meinem AVRStudio 4.18 ist "Erase device before flash programming" angewählt => damit werden also auch die Lockbits gelöscht - hätte ich nicht gedacht...

Ich bin nun etwas verunsichert - ich war bislang der Meinung, dass ich den Flash Speicher explizit löschen muss, bevor ich ihn erneut programmiere ....
Und wenn dabei die Lockbits auch gelöscht werden...

Das compilierte / gelinkte file beinhaltet ja die Adresse für den Start und die Adresse für das Programmende ...Muss ich den Flashspeicher wirklich löschen, wenn ich ein neues file auf den Controller flashe?

Ich habe mich bislang damit (Speicheraufteilung, Lockbits, Boot Sector etc) nie so richtig befasst ...

mfg

Hero_123
 
Hallo Hero,

wenn du einen Bootloader nutzt, programmierst du deine Applikation ja normalerweise nicht über zB. ISP (MISO, MOSI, SCK), sondern über die Schnittstelle des Bootloaders (das wird bei dir wahrscheinlich der UART sein). Der Bootloader kann den Applikationsbereich pageweise löschen und danach programmieren und verifizieren.

Wenn du über ISP programmierst, wird auch pageweise programmiert. Zuvor muss aber der zu programmierende Bereich gelöscht sein. Gelöscht heißt, dass eine Speicherstelle 0xFF beinhalten muss. Löschen kann man mit ChipErase. Das bedeutet aber auch, dass der Bootloaderbereich gelöscht wird und dass Lockbits gelöscht werden (Fuses nicht!). Das ist bei dir wahrscheinlich passiert. Du hättest nicht über ISP programmieren sollen, sondern über den Bootloader.

ChipErase stellt wieder den "Werkszustand" her (Fusebits beeinflusst dies nicht).

Wenn du das Hexfile des Bootloaders hast, kannst du diesen ja wieder programmieren.
Wenn du aber sowieso über einen ISP Programmer programmierst, benötigst du den Bootloader eigentlich nicht. Dann hast du auch mehr Platz für deine Applikation. Da setze immer den Haken bei "Erase device before flash programming" (ChipErase).

ChipErase löscht auch das EEprom. Es gibt einige Mikrocontroller, die haben ein spezielles Fusebit, um dies zu verhindern.

Dirk :ciao:
 
ChipErase löscht auch das EEprom. Es gibt einige Mikrocontroller, die haben ein spezielles Fusebit, um dies zu verhindern.
auf den ATMega8 flashe
Beim Mega8 ists das Bit EESAVE im High Fuse Byte. Ist es programmiert, ist der Eeprom vor dem Chip Erase geschützt.

ChipErase stellt wieder den "Werkszustand" her (Fusebits beeinflusst dies nicht).
Im Gegensatz dazu können programmierte Lockbits nur durch ein Chiperase zurückgesetzt werden (Genau das ist ja deren Schutzfunktion)
 
Hallo Dirk, hallo LotadaC

Vielen Dank für Eure Hilfe :good3:

Ich hab' mir nun mal meinen Programmieradapter im Detail angesehen - der Adapter programmiert den Controller mittels ISP (damit auch kein Boot Loader nötig); vor dem Flashen erfolgt ein ChipErase (=> Lockbits werden zurückgesetzt, sind auch nicht nötig); das EESAVE Bit ist nicht programmiert.

Wenn mal ein Boot Loader auf dem ATMega8 war, dann ist er jetzt gelöscht; macht aber nichts, da das BOOTRST Bit gelöscht ist (kein Boot Loader), ChipErase ist aktiviert, die LockBits sind zurückgesetzt und das EESAVE Bit ist auch nicht programmiert.

Dass vor dem Flashen mittels ISP ein ChipErase nötig ist, war mir nicht bewusst. Da hatte ich ja Glück, dass dies ChipErase aktiviert ist ...

mfg

Hero_123
 
Ich hab' mir nun mal meinen Programmieradapter im Detail angesehen - der Adapter programmiert den Controller mittels ISP (damit auch kein Boot Loader nötig)
Der, den Du in #8 verlinkt hattest? Der besteht aus einem USB-seriell Wandler (CP2102), der vom PC her als virtueller Comport oder sowas erkannt wird, und (wahrscheinlich) mehrere TTL-Kanäle bietet. Einer dieser Kanäle kommuniziert mit dem Mega8 der auch auf dieser Platine sitzt, und seinerseits das Programmieren des Targets übernimmt.
Dein "Programmer" kann aber auch als USB-TTL-seriell-Wandler genutzt werden (möglicherweise über einen anderen Kanal, ohne den Mega).
Du kannst damit also wenn nötig via SPI-ISP einen Bootloader in ein Target brennen bzw dort Fuses und Locks verändern.
Wenn ein Loader vorhanden ist, kann der "Programmer" aber auch als Wandler von USB auf TTL-UART wandeln um den Code in den Bootloader zu füttern.


das EESAVE Bit ist nicht programmiert.
Ich habs bei meinem Mega8 aus dem Bascom-Anfänger-Thread hier trotzdem aktiviert - mir(!) stellt sich allerdings jetzt die folgende Frage: In den Datenblättern ist ja quasi die Anzahl der maximal garantierten(!) Lösch-Schreib-Zyklen angegeben.
Das betrifft eigentlich das löschen, oder? "Zählt" da das löschen bereits gelöschter Bits mit?
(Hintergrund war doch meiner Meinung, daß salop gesagt jeder Löschvorgang die Speicherzelle "abnutzt" - gilt das auch, wenn die Zelle zwischendurch nicht beschrieben wurde? @dino03 ?
Und ja, mir ist klar, daß der Program Flash viel eher abgenudelt ist als der Eeprom - durch ChipErases selbst kannst Du den Eeprom nicht abnutzen, weil der Flash viel früher hinüber ist.)

das BOOTRST Bit gelöscht ist (kein Boot Loader)
Du meinst "nicht programmiert". Es hat aber selbst nichts mit dem Loader zu tun, es bewirkt nur(!!) daß der Controller nach einem Reset eben nicht bei Flashadresse 0x0000 beginnt, sondern bei der Adresse, die die BOOTSZ-Bits festlegen. Was da für Code steht, ist Wurscht. Du kannst auch irgendein Programm zurechtstricken, welches nach jedem Reset im Boot-Bereich beginnt, und dann von da aus (wenn nötig) im restlichen Flash herumhopsen. Insbesondere muß dort nie irgendwelcher Code nachgeladen werden oder irgendwas in den Flash geschrieben werden.


Dass vor dem Flashen mittels ISP ein ChipErase nötig ist, war mir nicht bewusst. Da hatte ich ja Glück, dass dies ChipErase aktiviert ist ...
Beim eigentlichen Brennen (flashen) können nur gesetzte Bits gelöscht werden, das Erase setzt alle Bits. Beim Flashen enthält die Zelle als Ergebnis (alter-Zustand AND soll-Zustand). Wenn da also vorher keine 0xFFs drinn standen, weichet neuer-Zustand von soll-Zustand ab, was Dir als Fehlermeldung beim Verifying um die Ohren gehauen wird.
Ein Bootloader muß entsprechend natürlich auch Zellen (Pages) die er beschreibt löschen, im allgemeinen soll er seine eigene Page aber nicht löschen (obwohl auch sowas möglich ist).
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)