mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bootloader und ATmega128


Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen Wert hat die M103C Fuse?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Welchen Wert hat die M103C Fuse?

M103C=0

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Watchdog war aktiviert und hat somit den Bootloader immer wieder 
abgewürgt. So kann das natürlich nichts werden.

Markus

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chrisi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Bootloader ist mindestens um 0x61, also 97 Bytes zu gross.

Autor: nop(); (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bootloader im Tiny13 ist cool. Bleibt da noch genug Platz für´s Programm 
;-)?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.