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
>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.
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
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
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
