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.
Schau einmal in diesen Thread - http://www.mikrocontroller.net/forum/read-4-53146.html - vllt. hilft Dir da was. Gruss.
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.
wenn du winavr o.ä benutzt schau dir mal die datei boot.h an, die wirst du brauchen
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__avr__boot.html .. oder eben lokal auf der Festplatte als Dokumentation.
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.
Hi mein USBisp enthält auch einen Bootloader mit STK500 Protokol in C. Kannst du dir ja mal anschauen www.matwei.de Matthias
und noch ein wenig "eigenwerbung": http://www.siwawi.arubi.uni-kl.de/avr_projects/index.html#avrprog_boot allerdings in der freien version noch das "olle" AVR109/910 Protokoll
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.
Hi geht über den Linker. Schau mal in mein makefile rein. --section-start=.text=$(ROM_START) ist der entscheidende Parameter. Matthias
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
Angehängte Dateien:
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?
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?
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 = .
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
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 :(
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.
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 ...
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/source/boot_00000.zip http://mitglied.lycos.de/projectsilence/syscontrol/source/boot_1FC00.zip Aber wäre nett, wenn mal jemand rüberschaut. Ich kann mir nicht vorstellen, dass da was an der Hardware defekt ist.
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.
@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.
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.
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.
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.
<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?
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.