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
Der Watchdog war aktiviert und hat somit den Bootloader immer wieder abgewürgt. So kann das natürlich nichts werden. 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
Bootloader im Tiny13 ist cool. Bleibt da noch genug Platz für´s Programm ;-)?
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.
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.