Hallo, ich weiß, bootloader gibt es viele. Aber entweder gibts die nur als hex-file und man muß sie nehmen, wie sie sind oder sie sind in Assembler geschrieben. Nicht dass ich Assembler nicht lesen könnte, aber man versucht ja es sich so einfach wie möglich zu machen. Ich suche also einen Bootloader für den ATmega128(1281) in C. Er soll ganz normal über das Hyperterminal bedienbar sein, also nicht STK500-kompatibel. Er muß auch nicht effizient programmiert sein. So weit ich weiss habe ich ja bis zu 4k-Bootbereich. Ich will mir das Teil auf einen FTDI245BL umschreiben. Gruß Matthias
Zwar nicht U-Boot, aber schau mal unter http://www.chip45.com/index.pl?page=chip45boot&lang=de Tschüss Torsten
>chip45boot geht einen anderen Weg. chip45boot kann eine standard Motorola >s-record Datei, die einfach aus dem häufig verwendeten Intel Hex Format >erzeugt werden kann, über einen UART eines AVR Mikrocontrollers einlesen. Warum nicht gleich hex? Schade, dass die wenigsten Bootloader Autobaud unterstützen.
Das macht schon mal einen schlanken Fuß. Es ist auf Dauer aber etwas nervig .hex in .s19 zu übersetzen. Den Loader auf hex-files umzuschreiben, kommt einem Neubau gleich. Wenn sich nichts anderes findet, werde ich es wohl nehmen. Erstmal vielen Dank Gruß Matthias
Ich hab kuerzlich selbst einen Bootloader geschrieben. Auch mit 4k macht man keine grossen Spruenge. Dann kommen noch diese und jene Wuensche und zum Schluss nimmt man noch die Debugfunktionen raus. Man bedenke dass 4k nur ca 2000 ASM Instruktionen sind. Die kann man nun mit einem Compiler vertun oder mit ASM. Man kan dass eine oder andere goodie, wie Crypto, Sync des RC auf einen 32k Quarz, Autobaud, ein tolles Protokol, usw. Jeder hat eben seine eigenen Prioritaeten
Hallo, man muss doch nicht die hex-Files übersetzen. Eine kleine Änderung im Makefile und schon werden srec-Files generiert. Der Bootloader hat aber ein Problem, wenn srec-Files generiert werden, die mittendrin mal eine kürzere Zeile haben. So etwas passiert, wenn man Strings verwendet. Ich habe deshalb den Bootloader modifiziert und bin vom Terminal auf ein spezielles Download-Tool umgestiegen (siehe hier: http://home.arcor.de/torsten.schoenitz/uc_dev/avrboot/avrboot.html) Tschüss Torsten
Wenn ich mir das jetzt so besehe, ist der chip45 wohl doch nicht erste Wahl. Da kann man sich den Bootloader auch gleich selber schreiben. Hat jemand noch eine Idee, wo irgendwo im Netz so ein Teil rumpurzelt, bei dem man nur die UART gegen FTDI245 tauschen muß? Gruß Matthias
Demnächst werde ich meinen Bootloader hier veröffentlichen. Ist in ASM und das aus gutem Grund. Kurz umrissen: - Autobaud aber auch feste Baudrate - 1Wire und 2Wire RS232, mit invertierbaren Pegeln - mit USB-RS232 Dongle bis zu 256kBaud - Protokoll abgesichert mit CRC - sichere Verschlüsselung per XTEA, 128Bit Passwort und 32Bit Checkcode - läuft mit allen AVRs die Selfprogramming unterstützen und mehr als 2* Pagesize SRAM haben, also im Grunde alle AVRs mit Selfprogramming, auch 8 Pinner - FLASH schreiben/löschen mit impliziter Verfikation oder separate Verifikation möglich - EEPROM lesen & schreiben - SRAM lesen & schreiben (für spezielle Debugfeatures) - Watchdog Unterstützung - alles konfigurierbar, dh. jedes der Features kann einfach aktiviert/deaktiviert werden - ATMega128 wird in 16 Sekunden geflasht und verifiziert - fertige PC-Software mit der man den Bootloader anspechen kann, diese Software enthält auch 2 HEX-Editoren zum direkten Ändern des EEPROM/SRAM Inhaltes des AVRs so und das alle mit Verschlüsselung in 844 Bytes = 422 Worten und ohne Verschlüsselung aber mit allen anderen Features 512 Bytes und wenn man nur das Nötigste aktiviert dann 348 Bytes, das umfasst CRC, FLASH Programmierung/Löschung und fester Baudrate. Das wird man in C so nicht hinbekommen können. Gruß Hagen
@Hagen: Wann hast du vor deinen Bootloader zu veröffentlichen? Wie sieht die Sache auf der PC-Seite aus. Nehme an, dass du dafür ein kleines Programm geschrieben hast.
Angehängte Dateien:
-
neu-6.png
330 KB
Ja, anbei ein Screenshot. Diese Software unterstützt auch das Verschlüsseln der FLASH/EEPROM HEX Dateien. Dabei entstehen quasi sowas wie binäre Befehlsdateien bei denen die Daten auf sichere Weise verschlüsselt wurden, mit XTEA im speziellen Feedbackmodus. Dabei kann in einer Datei auch der Inhalt der FLASH und EEPROM Datei enthalten sein. Diese Dateien können nur auf dem ausgewähltem AVR und Bootloader geladen werden. Der Bootloader kann serialisert werden und nur auf ihn serialisierte verschlüselte Dateien können geladen und korrekt entschlüsselt werden. Bald wird er fertig sein. Eigentlich funktioniert er schon vollständig (auf AVR Seite) es fehlt nur noch die saubere Integration der Verschlüsselung auf PC Seite. Testen konte ich ihn bisher mit allen Feature auf ATMega461 und ATMega128 jeweils im 1Wire und 2Wire-invertert (MAX232) Modus, mit Laptop RS232 und USB-RS232 Wandler. Gruß Hagen
@Hagen Das ist ja wunderbar, ganz dickes Lob! Aber scheinbar hast Du mich nicht verstanden. 1. Ich habe keine Platzprobleme. Daher kann das Teil auch 4k groß sein und nur die Hälfte Deiner Features unterstützen. 2. Niemand knackt mein Auto, um auf mein Steuergerät illegal eine Software zu flashen und dann das Fahrzeug wieder ordnungsgemäß zu verschließen. Also brauche ich auch keine Verschlüsselung. 3. Ich will die Software ohne Spezialprogramm flashen können. 4. Es sollte C sein, da man es wesentlich leichter editieren kann. Wie bereits geschrieben, verwende ich keinen USB-RS232 Dongle sondern einen FTDI245. Somit komme ich um eine Softwareänderung nicht herum. Ich suche also wie anfangs erwähnt eine Bastellösung zum Ausbau und keine Superduperhyperlösung, die überhaupt nicht meinen Bedürfnissen entspricht. Nicht böse sein, Du hast Dir bestimmt große Mühe gegeben. Gruß Matthias
Jo kein Problem, ich habe das Ding nicht für dich speziell gebastelt ;-) Gruß Hagen
So, ich bins wieder. Ich bin gerade dabei mir so ein Teil basierend auf chip45 hinzubasteln und dabei auch sämtliche Schwächen von chip45boot auszumerzen. Dabei ist wieder eine Frage aufgetaucht, die mir das Datenblatt nicht beantworten kann. Sind die Adressen byte- oder word-aligned? Da die AVRs 8-bit- Maschinen sind, wäre ja byte-aligned denkbar. Dummerweise kann man in die Page nur wordweise schreiben. Wenn man jetzt wüßte ob der GCC oder ein beliebiger andere Compiler nie Hex-Files mit ungeraden Adressen oder Datenlängen erstellt (kann wahrscheinlich nur bei Konstanten im Code passieren), wäre die Sache leichter. Weiss jemand, ob man bei Hex-Files für AVRs ungerade Adressen oder Datenlängen berücksichtigen muß? Gruß Matthias
Das ist schon klar, aber heißt das, dass eine einzelne byte-Konstante im Flash zu eimem Word aligned wird und somit nie ungerade Adressen oder Datenlängen im Hex-File auftauchen? Gruß Matthias
Hi >Das ist schon klar, aber heißt das, dass eine einzelne byte-Konstante im >Flash zu eimem Word aligned wird und somit nie ungerade Adressen oder >Datenlängen im Hex-File auftauchen? Das ist Sache des Assemblers: Aus .db $FF wird FF00 aus .db $AA,$55 wird AA55 Wenn du z.B mit Z auf den Flash zugreifst geschieht das byteweise. abc: .db $AA,$55.... abc ist eine Wordadresse. Zugriff: ldi ZL,Low(abc<<1) ldi ZH,High(abc<<1) Wordadresse wird in Byteadresse umgewandelt. ... lpm Das erste Byte einer db-Anweisung immer an einer geraten Byteadresse. MfG Spess
Heißt das, dass alle Assembler und Compiler für AVR immmer ein word-align machen und es somit zu keinen ungeraden Adressen oder Datenlängen im Hex-File kommen kann? Gruß Matthias
Ich wünschte mir eine rege Beteiligung wie im Thread Beitrag "Transistor (Verzweiflung)" Aber vielleicht ist mein Thema zu langweilig ;-)
Neues Problem! Ich bekomme den Receive Interrupt von USART1 im Bootloader nicht ans laufen. Das IVSEL-Bit wird gesetzt, scheint aber keine Auswirkung zu haben. Es wird zwar ein Zeichen empfangen. Dann startet der Bootcode aber erneut. Dafür kann es zwei Ursachen geben: 1. ein direkter Reset oder 2. die Interruptvektoren der Applikation werden verwendet und wenn dort 0xFF steht, rennt der Controller durch den ganzen Flash bis er wieder beim Einsprungpunkt des Bootloaders ankommt. Ich hab das Datenblatt schon rauf und runter gelesen und hab erst mal keine Idee mehr. Ist bei dem IVSEL-Bit noch etwas spezielles zu beachten (außer IVCE)? Gruß Matthias
Matthias Kölling wrote: > Aber vielleicht ist mein Thema zu langweilig ;-) Nö, aber zu umständlich. Bei AVRfreaks sind ja auch einige Unentwegte, die mit vielen Tricks versuchen, C für nen Bootloader zu vergewaltigen. Die Threads werden dabei sehr lang. > Ich bekomme den Receive Interrupt von USART1 im Bootloader nicht ans > laufen. Wozu braucht man denn im Bootloader Interrupts, um den Code noch mehr aufzublähen? Ein Bootloader ist ja eine einzige lineare Task. Ich programmiere meine Anwendungen fast ausschließlich in C. Aber den Bootloader doch besser und schneller in Assembler. Der Bootloader sollte ja auch universell sein, d.h. nicht nur auf dem ATmega laufen. Peter
Hallo Peter, ich will hier nicht über Sinn oder Unsinn diskutieren. Letztendlich geht es nur um einen einfachen technischen Sachverhalt: Interrupts in der Bootsection sind laut Datenblatt möglich und auch gewollt. Meine Frage war, was mache ich falsch. Wenn jemand eine Konfiguration für Timer1 braucht, fragt man ja auch nicht, ob er denn keine Armbanduhr hat. Gruß Matthias
Hallo Matthias, ich hatte beim chip45boot auch Probleme mit dem UART-Interrupt, habe den Empfang dann aber komplett ohne Interrupts realisiert, da bei mir die Aktivierung des Bootloader-Modus über ein IO-Pin läuft. Im Bootloader-Mode selbst ist meiner Meinung nach die Verwendung des Interrupts unnütz, da sowieso in einer Schleife gewartet wird, bis eine Zeile angekommen ist. Ich hatte vermutet, dass die Umschaltung der Interrupt-Vektoren zwischen Bootloader und Applikationsbereich nicht sauber läuft. Tschüss Torsten
Matthias Kölling wrote: > Interrupts in der > Bootsection sind laut Datenblatt möglich und auch gewollt. Nicht alles, was möglich ist, ist auch immer sinnvoll. Und ob der Compilerbauer irgendwas gewollt hat, ist mir sowas von schnurzegal. Ich lasse mir nicht vorschreiben, daß ich Interrupts verwenden muß. In meinem alten Bootloader hatte ich Interrupts ausprobiert und es funktioniert auch (in Assembler): http://www.avrfreaks.net/index.php?module=Freaks%20Files&func=viewFile&id=1142&showinfo=1 > Meine Frage > war, was mache ich falsch. Woher soll das ein Leser dieses Threads wissen? Bei Fragen zu Software muß man auch immer ein compilierfähiges Programm herzeigen. Kaffeesatzlesen hilft da nicht. Und im Falle des Bootloader ist auch das Assemblerlisting mit den eingefügten Codezeilen wichtig, damit man sieht, was wohin gelinkt wurde. Ich schaue mir bei Problemen immer erstmal das erzeugte Assemblerlisting an. Peter P.S.: Du weißt schon, daß beim Programmieren der NRWW-Section alle Interrupts gesperrt sein müssen?
"Du weißt schon, daß beim Programmieren der NRWW-Section alle Interrupts gesperrt sein müssen?" So lange der Code nicht größer als 120k wird, sollte das ja auch kein Problem sein. Wenn ich während des Schreibens auf die Page Interrupts zulasse, spare ich bei 115kBaud 30% der Zeit. Gruß Matthias
"Bei Fragen zu Software muß man auch immer ein compilierfähiges Programm herzeigen." Anbei das Projekt als zip. Gruß Matthias
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.