www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik WinAVR ATmega und Bootloader


Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat mal jemand mit der Bootloader-Funktionalität in C rumprogrammiert?
Ich wollte das ganze mal mit C versuchen. Aber es scheitert ja schon
daran, dass ich nicht weiß, wie ich nur den Bootloader-Bereich mittels
dem MISO/MOSI-Interface programmiere, geschweige denn in diesen
Bootloader-Programm nicht weiß, wie ich auf den Programmspeicher
zugreifen kann, also schreiben z.B.

Autor: Johannes M. Richter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau einmal in diesen Thread -
http://www.mikrocontroller.net/forum/read-4-53146.html - vllt. hilft
Dir da was.
Gruss.

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ich das gern selbst programmieren möchte, wäre mir eine C-Lösung eben
lieber. Ich verstehe nur eben ein paar Techniken nicht. Wie z.B.:

- Startadresse des Programmes im Flash festlegen
- Adressierung und Programmierung des Programm-Flash

Habe mir zwar da ein paar Sachen im Datenblatt durchgelesen, aber in C
ist doch irgendwie komplizierter.

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du winavr o.ä benutzt schau dir mal die datei boot.h an, die wirst
du brauchen

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke! Ich war gerade am suchen und habe ohnehin was gefunden. Aber dein
Tipp war eigentlich genau das richtige. Für den nächsten, der sowas
sucht:

http://www.nongnu.org/avr-libc/user-manual/group__...

.. oder eben lokal auf der Festplatte als Dokumentation.

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja aber wie ich die Startadresse des Bootloader-Programmes in C
festlege, wenn ich nicht von Adresse 0 booten möchte, weiß ich dennoch
nicht.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

mein USBisp enthält auch einen Bootloader mit STK500 Protokol in C.
Kannst du dir ja mal anschauen www.matwei.de

Matthias

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und noch ein wenig "eigenwerbung":
http://www.siwawi.arubi.uni-kl.de/avr_projects/ind...
allerdings in der freien version noch das "olle" AVR109/910 Protokoll

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2 Bootloader - wie schön. Aber ich habe halt immernoch nicht
rausgefunden, wie ich die Startadresse des Bootloaders festlegen kann.
Das muss ja irgendwie beim linken passieren. Zumindest habe ich bei der
Version von mthomas die Definition der Funktion zum Einsprung ins
Hauptprogramm nach dem programmieren gefunden:

void (*jump_to_app)(void) = 0x0000;

Aber wo der Start des Bootloaders steht, habe ich noch immer nicht
herausgefunden. Vielleicht könnt ihr mir ja einen kleinen Fingerzeig
geben? Der Bootloader soll in den Bootloaderbreich geflasht werden und
der ATmega (zum Test der ATmega 16) soll auch von da booten, wobei ich
letzteres ja in den FuseBits einstellen kann.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

geht über den Linker. Schau mal in mein makefile rein.

--section-start=.text=$(ROM_START) ist der entscheidende Parameter.

Matthias

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke! Nach langem suchen, habe ich das gerade eben gefunden ... Hätte
ich vorher ins Forum geschaut, hätte ich mir ne halbe Stunde Zeit
gespart. ;) Aber dafür weiß ich jetzt auch noch, wie ich binäre Dateien
erzeuge. grins

Autor: Ronny Schulz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Lange ist her ... genau den Parameter habe ich angegeben. ROM_START habe
ich eingestellt im makefile:

# Bootloader address (1F800 = FC00 * 2 = 1024 words)
ROM_START = 0x1F800

Die FUSE-Bits habe ich auch gesetzt. Allerdings startet das Programm im
Bootloader_Bereich nicht, was etwas blöd ist. Ist eine simple Augabe von
einem String an die serielle.

Laut Ponyprog liegt das Programm aber im richtigen Speicher. Woran
könnte es liegen?

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbst mit AVR-Studio und dem ELF-File wird der richtige Einsprung nicht
gefunden, obwohl Boot-Reset und entsprechende Adresse ausgewählt wurde.
Hier mal ein kurzer Ausschnitt aus dem Hex-File. Vielleicht hat ja
jemand einen Tipp und sieht gleich, warum es nicht gehen kann:

:020000021000EC
:10F800000C9446FC0C9463FC0C9463FC0C9463FC19
:10F810000C9463FC0C9463FC0C9463FC0C9463FCEC
:10F820000C9463FC0C9463FC0C9463FC0C9463FCDC

Oder was benötigt man noch zur besseren Analyse des Fehlers?

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sieht eigentlich gut aus, bei meinem bootloader auf 0x1FC00 sieht
das so aus

:020000021000EC
:10FC000011241FBE0C9414FE982F80919B0085FF39
:10FC1000FCCF90939C00089580919B008823E4F78B

Also tippe ich mal auf ein anderes problem.

wie sieht denn das .map file aus?

Zeile ca. 113 sieht hier so aus

.text           0x0001fc00      0x226
 *(.vectors)
 .vectors       0x0001fc00        0x8 gcrt1.o
                0x0001fc00                __vectors
                0x0001fc08                __ctors_start = .

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So bei mir ab Zeile 116:

.text           0x0001f800      0x3f0
 *(.vectors)
 .vectors       0x0001f800       0x8c
C:/Programme/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/cr 
tm128.o
                0x0001f800                __vectors
                0x0001f800                __vector_default
                0x0001f88c                __ctors_start = .
 *(.ctors)
                0x0001f88c                __ctors_end = .
                0x0001f88c                __dtors_start = .
 *(.dtors)
                0x0001f88c                __dtors_end = .

Und hier auch aus dem map-file:

Memory Configuration

Name             Origin             Length             Attributes
text             0x00000000         0x00020000         xr
data             0x00800060         0x0000ffa0         rw !x
eeprom           0x00810000         0x00010000         rw !x
default        0x00000000         0xffffffff

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im .map steht die startadresse auch auf 0x1F800.

Fuses:BOOTSZ1=unprogrammiert=1, BOOTSZ0=programmiert=0 => 0xFC00
BOOTRST=programmiert=0=Booten von Bootloader-section

Dann kann's nur noch am programm liegen :(

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja aber selbst mit AVR-Studio klappts nicht. Also der springt nicht an
der richtigen Stelle ein. Wenn es unter AVR-Studio gehen sollte, dann
wäre das Thema klar. Und das Programm läuft ja auch, wenn es nicht im
Bootloader-Bereich ausgeführt wird.

Also heisst es weiter suchen und hoffen, dass ich mal was finde. Ich
hab einzwischen schon eine kleine Menge Fehler, die ich einfach nicht
lokalisieren kann, obwohl ich sämtliche Dokus gewälzt und gelesen habe.

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So nochmal ich. Ich habe jetzt nochmal ein kleines Programm geschrieben,
was in den kleinen Bootbereich (FE00, 512 words) passt. Dabei wird ein
Beeper angeschaltet und nach ein paar ms wieder per Timer abgeschaltet.
Das ist mein Quasi-Testprogramm, ob überhaupt der Controller startet.
Ist eben wie beim PC, das piepen.

Um zu analysieren, habe ich folgende Kombinationen probiert (die
FUSE-bits sind natürlich invertiert):

Adresse im Makefile = 0, BOOTRST = 1, BOOTZ0 = 1, BOOTZ1 = 1:

Programm startet ohne Probleme. Beeper geht an und wieder aus. Schalte
ich nun BOOTRST auf 0, wird der Bootloader aktiviert und nichts sollte
funktionieren, da der Bereich ja mit FF gelöscht war. Der Beeper piept
dennoch, was ich nicht verstehen kann. Als hätte ich nichts verstellt.
WARUM ist das so?

Die zweite Idee ist natürlich gleich im Makefile auf 1FC00 umzustellen
und den Flash zu löschen und dann neu zu programmieren. Hier geht der
Beeper nur an, aber nicht wieder aus. Auch das verstehe ich nicht. Ich
habe nur den Adressbereich verschoben. Die Startadresse sollte ja die
Einsprungadresse sein.

Irgendwas muss ich doch falsch machen oder einfach nur denken ...

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt nochmal 2 Versionen ins Netz gestellt. Einmal mit Adresse
0 und einmal mit 1FC00. Prinzipiell kann man das ja auch neu
kompilieren. Wenn kein Beeper dranhängt geht es ja auch mit einer LED.
Allerdings ist mein Beeper Low-aktiv gesteuert.... VIel Programm ist es
ja nicht. Deshalb leicht durchschaubar.

http://mitglied.lycos.de/projectsilence/syscontrol...
http://mitglied.lycos.de/projectsilence/syscontrol...

Aber wäre nett, wenn mal jemand rüberschaut. Ich kann mir nicht
vorstellen, dass da was an der Hardware defekt ist.

Autor: Barti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm wenn Du auf einen Speicherbereich zeigst, der leer ist, dann dürfte
der Programm-Counter weiterzählen, bist er in einen Bereich kommt wo
wieder ausführbarer Code steht. Wenn ich Dich richtig verstanden hab
müßte er also wieder am Anfang ankommen und Dein "Piep-Programm"
ausführen.

Habe mit AVR-GCC auch schon nen Bootloader geschrieben, aber wenn ich
ihn flashe ist nicht der komplette Code an der Bootloader-Startadresse.
Ein Teil wird immer bei 0x0000 geschrieben. Das ist der Code, den der
Compiler immer erzeugt. Weiß aber nicht für was dieser gut ist. Egal
wie groß ein Programm(z.B. nur einen Port umschalten->rel. kleines
Programm) ist, GCC erzeugt am Anfang immer eine relativ lange Sequenz
und ich weiß nciht wofür sie steht.

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@bBarti:
Also bei mir wird in 0x0000 nichts geschrieben. Das sollte ja
eigentlich auch nicht wirklich so sein.

Ich vermute es liegt irgendwie an der ROM_START-adresse. Ich fummel
hier schon Stunden rum und habe noch immer keine endgültige Lösung
gefunden. Mit Hilfe von AVRStudio (was nicht unbedingt das
zuverlässigste ist) habe ich mir einfach auch die Disassembler-Daten
angeschaut.

Im Vergleich habe ich einfach mal ein paar Sachen mit dem Atmega8
ausprobiert, da mich ja nur interessiert, ob er an der richtige Stelle
einspringt. Der Code an sich war gleich. Was allerdings verwunderlich
war, dass NUR beim Atmega128 die Debuginformationen nicht im
Disassembler zu sehen waren. Also sonst steht da drin, wo welches File
an welcher Adresse beginnt. Das stimmt beim atmega8. Aber beim
Atmega128 fehlten diese Informationen.

Unterm Strich läuft das immernoch nicht. Und ich weiß nicht, wo ich
noch suchen sollte. Wenn jemand real mal wirklich ein kleines
Porttestprogramm im Bootloaderbereich des Atmega128 hat laufen lassen,
wäre das eine große Hilfe. Da könnte ich dann ansetzen.

Autor: Ronny Schulz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich heute schon wieder ewig mit der Fehlersuche beschäftigt.
Diesmal mit MAP-File, Disassembler, Assembler usw.

Meine Diagnose lautet:

Ein bootloader läuft durchaus auf meinem Atmega128. In Assembler lief
mein Testprogramm. In C läuft es auch, solange ich die IRQs in Ruhe
lasse. Da mein Beep-Programm zum testen mittels IRQ-Routine
abgeschaltet wird, liegt da das Problem. Nutze ich den compare match
von Timer0, dann wird das Programm bei erreichen des compare match
einfach neu gestartet. Warum dem so ist, weiss ich aber auch nicht. Ich
denke sämtliche IRQ-Sachen enden im Neustart. Deshalb ging bisher auch
nichts.

Aber woran kann das liegen. Ab Adresse 0 läuft es doch auch und im
Disassembler ist auch erstmal kein Fehler ersichtlich.

Hat irgendjemand eine Idee, was das sein kann? Ich raste echt bald aus
und komme kein Stück weiter.

Im angehängten File sind die Timer-Sachen drin.

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AhhhhhhhJa... Interrupts davon wusste natürlich niemand etwas!

Dann musst Du aber auch die Interruptvektoren in den bootloader Bereich
verlegen.
Stichwort IVSEL im MCUCRgister, Datenblatt Seite 57ff.

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja ich habe es gefunden. Aber toll. Ich wusste, dass wieder mal
irgendwas war, was ich nicht wusste. Ich meine das komplette Datenblatt
lesen, geht einfach nicht.

Aber da ich sowieso keine IRQs mehr beim Bootloader nutze, sollte das
jetzt egal sein. Der Bootloader ist jetzt eigentlich auch fertig. Ziel
war es mittels Programm einfach binär die Daten zu schicken und das
sieht schon ganz funktionell aus. Fehlt nur noch das Programm auf der
PC-Seite.

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<zitat>
"Ich meine das komplette Datenblatt lesen, geht einfach nicht."
</zitat>

Dann verschwendest Du Deine Zeit (und die Zeit Anderer) lieber damit
unnötig nach Lösungen für Probleme zu suchen die eigentlich keine sind?

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.