Hallo,
Ich versuche seit einiger Zeit den Bootloader von
http://www.siwawi.arubi.uni-kl.de/avr_projects/#avrprog_boot auf einem
ATmega128 zum Laufen zu bekommen.
Die Konfiguration ist folgende (main.c):
#define F_CPU (16000000)
#define BAUDRATE 19200
#define DEVTYPE DEVTYPE_ISP
#define START_WAIT
#define START_WAIT_UARTCHAR 'S'
Und im Makefile:
MCU = atmega128
BOOTSIZE=512
BOOTINTVEC=yes
Der Bootloader passt gerade so (2 Bytes sind noch Platz) in die
Bootloader-Sektion. Mit der korrekten Platzierung des Codes im Flash bin
ich mir aber nicht ganz sicher. Ponyprog zeigt als Startadresse 0x01fc00
an, während er laut Datenblatt bei 0xfe00 liegen sollte. Das scheint
aber an der Unterschiedlichen Zählweise von Ponyprog zu liegen.
Die Fuse-Bits sind folgendermaßen gesetzt:
BOOTTRST=0
BOOTSZ1=1
BOOTSZ0=1
Wenn ich mich mit einem Terminalprogramm mit dem Bootloader verbinde,
antwortet der Bootloader auf ein 'S' aber nur bei ca. jedem dritten mal
und dann nicht mit dem ganzen String "AVRBOOT" sonder nur mit einem
einzelnen 'A'. Mehr Funktion konnte ich dem Bootloader bisher noch nicht
entlocken. Der Bootloader scheint also ausgeführt zu werden, tut aber
nicht so ganz das, was er soll. Wo liegt jetzt der Fehler?
Gruß,
Markus
0=programmed. Dann hast du keinen Atmega128 vor dir, sondern einen
Atmega103.
U.a. wird dadurch das FIFO im USART abgeschaltet, d.h. das Timing wird
kritischer.
Ausserdem hat der Atmega103 keine Bootloader-Fähigkeiten. D.h. der
Bootloader wird zwar als Programm laufen, kann aber kein Userprogramm
einprogrammieren, schätze ich mal.
> 0=programmed. Dann hast du keinen Atmega128 vor dir, sondern einen
Atmega103.
Dann andersrum. Ich hatte jedenfalls beide Werte probiert, weil ich mir
nicht ganz sicher war. Als ATmega103 hat er überhaupt nicht reagiert.
Markus
Hallo,
ich probiere nun schon eine ganze Weile verschiedene Bootloader für den
Mega128 aus. Bei dem oben erwähnten bekomme ich bei gleichen
Einstellungen immer die unten angehängte Fehlermeldung. Kann mir
vielleicht jemand sagen, was ich falsch mache ?
Viele Grüße,
Tobias
> "make.exe" all
-------- begin --------
avr-gcc (GCC) 4.1.1 (WinAVR 20070122)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Compiling: main.c
avr-gcc -c -mmcu=atmega128 -I. -gstabs -DBOOTSIZE=512 -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 -MD -MP -MF
.dep/main.o.d main.c -o main.o
Linking: main.elf
avr-gcc -mmcu=atmega128 -I. -gstabs -DBOOTSIZE=512 -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=main.o -std=gnu99 -MD -MP -MF
.dep/main.elf.d main.o --output main.elf -Wl,-Map=main.map,--cref
-lm -Wl,--section-start=.text=0x1FC00
c:\winavr\bin\..\lib\gcc\avr\4.1.1\..\..\..\..\avr\bin\ld.exe: address
0x20060 of main.elf section .text is not within region text
make.exe: *** [main.elf] Error 1
> Process Exit Code: 2
Bootloader-programmierer,
ist vielleicht schon aufgefallen, dass die kritische Zeit beim
bootloader die Flash-schreib-zeit ist ? Ein Wort benoetigt ca. 4ms. dh
eine Baudrate von 19200 ist zu schnell. Je nach codierung ist 9600 oder
4800 genuegend.
>eine Baudrate von 19200 ist zu schnell
Flashprogrammierung und Datenübertragung sind zwei unteschiedliche
Funktionen des Bootloaders. Man hat also durchaus Vorteile bei schnellen
Übertragungsraten, da der Puffer dann zügiger gefüllt werden kann, bevor
der eigentliche Transfer von Puffer zu Flash ausgelöst wird. Das Timing
durch Begrenzung der UART-Übertragungsrate sicherzustellen, ist
halbherzige Bastelei, denn dies ist Aufgabe des Protokolls zwischen
Hostsoftware und Bootloader. In der Art: weitermachen, wenn positive
Bestätigung vom Bootloader empfangen wurde.
>"...Flash-schreib-zeit... Ein Wort benoetigt ca. 4ms."
Die Angabe "programming time for flash" im Datenblatt (z.B. max 4,5ms
bei ATmega644V) beziehen sich auf Speicherseiten.
Vielleicht einfach nochmal den Abschnitt "self programming" im
Datenblatt zu Gemüte führen und evtl. noch Application-Note AVR109
durchlesen. Wobei das in AVR109 beschriebene nicht das einzig mögliche
Protokoll ist und ein Bootloader auch nicht unbedingt über UART
angesteuert werden muss. (Evtl. bringt auch ein Blick in meinen
AVRProg-Bootloader-Code (link s.o.) ein wenig weiter.)
Martin Thomas
>eine Baudrate von 19200 ist zu schnell
Bei geschickter Programmierung des Bootloaders (Flash-Page buffern) sind
durchaus höhere Baudraten drin, da der Flash geschrieben wird, während
über die UART neue Daten in den Buffer geschaufelt werden. Wir
'bootloaden' hier auf Arbeit z.B. mit 77kBaud, geht einwandfrei.
Ich mache das so, daß zuerst das PC-Programm die Puffergröße des
Bootloaders abfragt, z.B. beim ATmega644 nehme ich 3584 Byte.
Dann kann er eine volle Puffergröße an Bytes rausrotzen und danach
wartet er auf die Quittung vom AVR.
Man könnte natürlich schon, wenn die erste Page im Puffer ist, anfangen
mit Programmieren, aber dadurch wird der Bootloader größer und meiner
soll ja schon in nen ATtiny13 passen.
Wenn man mit 115200 Baud sendet, kommt man beim ATMega644 auf 8s und das
reicht mir.
Peter
Ach ja - bevor ich´s vergesse: Ein wichtiger Punkt ist noch, ob der
Bootloader reale .hex-Dateien verarbeitet, oder Binärfiles, also reine
Datenbytes. Bei .hex- Dateien hat man noch eine gewisse Kontrolle über
die Richtigkeit der übertragenen Daten, braucht aber mehr Platz und
Preformance im Bootloader.
Travel Rec. wrote:
> Bootloader im Tiny13 ist cool. Bleibt da noch genug Platz für´s Programm> ;-)?
Immerhin noch 606 Byte, siehe:
Beitrag "ATtiny45 Bootloader"
Peter
Travel Rec. wrote:
> Ach ja - bevor ich´s vergesse: Ein wichtiger Punkt ist noch, ob der> Bootloader reale .hex-Dateien verarbeitet, oder Binärfiles, also reine> Datenbytes. Bei .hex- Dateien hat man noch eine gewisse Kontrolle über> die Richtigkeit der übertragenen Daten, braucht aber mehr Platz und> Preformance im Bootloader.
Also Hex ist ja nun total ungeeignet.
Man hat überhaupt keine Möglichkeit, wie der Bootloader die Puffergröße
anzeigen kann und wann er fertig ist und den nächsten Block bekommen
darf.
Man kann dann höchstens die Baudrate soweit runtersetzten, daß die
Transferrate mit Sicherheit unter der Programmierzeit liegt.
Aber bei den Tinys und Mega48 und der RWW-Sektion der Megas hilft selbst
das nichts, da dann ja beim Proggen die CPU anhält.
Außerdem hat das Hex-Format fast den 3-fachen Overhead, d.h. bei 9600
Baud werden nur etwa 300 Byte/s an Daten übertragen.
Hex ist also Schrott.
Deshalb nehme ich ein Protokoll und PC-Programm, was alle diese
Nachteile nicht hat.
Bezüglich Sicherheit kann ich Dich beruhigen. In den nächsten Tagen
folgt ein erweiterter Bootloader, der erstmal per 16Bit-CRC die
Übertragung kontrolliert und auch ne Verify-Funktion hat.
Ein CRC-Fehler ist ja durchaus möglich, wenn Quarztakt und Baudrate sich
etwas beißen. Dann probiert man es eben mit ner kleineren Baudrate
nochmal.
Einen Verify-Fehler habe ich aber noch nie gehabt. Sowas ist eigentlich
nur bei direkter SPI-Programmierung vom LPT-Anschluß möglich.
Peter
>Also Hex ist ja nun total ungeeignet.
Naja total vielleicht nicht. Wenn Du vor der Aufgabe stehst, ein Update
an einem Gerät zu machen, was in einer anderen Stadt steht, was an einem
anderen Gerät mit Ethernet-Anschluß hängt, dann ist die Eigensicherheit
einer solchen HEX-Datei gar nicht mal so dumm. Der Overhead ist zu
verkraften.
