Hier ist Peter Danneggers Bootloader, umgemodelt von Atmel-Assembler auf
die GNU-Tools.

Beschreibung des Bootloader-Originals in
[[http://www.mikrocontroller.net/articles/AVR_Bootlo...]]

Kurzanleitung: Auspacken, ins ausgepackte Verzeichnis gehen, README
(englisch) lesen.  Es muss das Atmel-.def-File hinzugefügt werden und
der Makefile auf den MCU-Typ angepasst werden.

Bisher getestet mit ATmega168.  Ein Makefile-Ziel, das bei Problemen
binär mit dem Original vergleicht, ist vorgesehen -- auch dazu: README
lesen.

Vielen Dank an Peter für den feinen Bootloader und die Erlaubnis, seinen
Code weiterzuverbreiten.

Bitte schreibt eure Erfahrungen mit anderen MCU-Typen hier ins Forum.

Da ist ein Makefile ohne Erzeugung der Debugging-Symbole durchgerutscht.

Dasselbe also nochmal (erzeugter Code identisch, lässt sich aber mit gdb
und AVR Studio symbolisch debuggen).  Build 18.

Bitte die Datei README lesen.  Falls das Englische Probleme macht:
nochmal fragen, dann erläutere ich's auf deutsch.

eku schrieb:
> Gut, ich konnte den Bootloader nun generieren. Aber wieso braucht es die
> AVRStudio Headerdateien.

Hä.
AVRStudio ist eine IDE. Die bringt keine Headerdateien mit.

> Die avrlibc bringt doch avr/iom*.h mit. Warum
> kann man die nicht nehmen?

Die will man aber nicht nehmen.
Man möchte beim Aufruf des Compilers den Prozessortyp angeben und die
io.h sucht aufgrund dieser Angabe die richtige iom*.h heraus.
Eine Source ... für verschiedene Prozessoren verwendbar indem man beim
Aufruf des Compilers den Prozessortyp angibt.

eku schrieb:
> Gut, ich konnte den Bootloader nun generieren. Aber wieso braucht es die
> AVRStudio Headerdateien. Die avrlibc bringt doch avr/iom*.h mit. Warum
> kann man die nicht nehmen?

Das Original verwendet Symbole, die in den C-Headerdateien nicht zu
finden sind, beispielsweise die Flashgröße.

Karl heinz Buchegger schrieb:
> eku schrieb:
>> Gut, ich konnte den Bootloader nun generieren. Aber wieso braucht es die
>> AVRStudio Headerdateien.
>
> Hä.
> AVRStudio ist eine IDE. Die bringt keine Headerdateien mit.
Er meint vermutlich die AVR Definitionsdateien.

>> Die avrlibc bringt doch avr/iom*.h mit. Warum
>> kann man die nicht nehmen?
>
> Die will man aber nicht nehmen.
> Man möchte beim Aufruf des Compilers den Prozessortyp angeben und die
> io.h sucht aufgrund dieser Angabe die richtige iom*.h heraus.
> Eine Source ... für verschiedene Prozessoren verwendbar indem man beim
> Aufruf des Compilers den Prozessortyp angibt.
Darum ging es gar nicht :-)

Der Bootloader funktioniert nur bis zu Flashgrößen von 64k.  Für den
Bereich darüber wären andere Pointerarten nötig.

Machen ließe sich das sicher.  Zumal ja nicht mal die Notwendigkeit
besteht, innerhalb des Codes wie beschrieben zu springen, das Problem
dürfte deutlich einfacher liegen.  Fragt sich nur noch, wer das macht
;).  Ich komme in diesem Jahr jedenfalls nicht mehr dazu.

Es bleibt die Möglichkeit, das Original von Peda einzusetzen.

Ich versuche mit
fastboot_build18.tar.gz
den bootloader fuer einen ATtiny85 zu compilieren

und bekomme vom compiler

~/Devel/AVR/BootLoader/fastboot$ make
Makefile:96: atmel_def.mak: No such file or directory
./_conv.awk tn85def.inc | gawk '/SIGNATURE_|SRAM_|FLASHEND|BOOT/' >
atmel_def.h
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
avr-gcc -c -mmcu=attiny85 -DF_CPU=8000000  -I . -I ./added -I
./converted -I/usr/local/avr/include  -ffreestanding -gstabs+
-Wa,-adhlns=bootload.lst,-L,-gstabs+ -DRAM_START=0x0060 -DSRAM_SIZE=512
added/bootload.S -o bootload.o
./converted/command.inc: Assembler messages:
./converted/command.inc:63: Error: illegal opcode jmp for mcu attiny85
./added/fastload.inc:77: Error: illegal relocation size: 1
./added/fastload.inc:78: Error: illegal relocation size: 1
./added/fastload.inc:79: Error: illegal relocation size: 1
make: *** [bootload.o] Error 1


die relevanten Zeilen im file ./converted/command.inc
sind

#if FlashEnd > 0x0FFF
        jmp     Application
#else
        rjmp    Application             ; run application
#endif


wenn der compiler das selbe Datenblatt verwendet wie ich dann kann ich
den compiler verstehen, da steht nichts ueber einen jmp Befehl.

Kann mir jemand von den asm Gurus einen Tip geben.

Ju

Kannst Du die erzeugte atmel_def.h noch wiedergeben?  Interessant ist
das Symbol FLASHEND.

ändere es in

#if FlashEnd > 0x7FFF

um.

Äm, nö. Das würde zwar für diesen Fall funktionieren, in anderen --
jetzt funktionierenden -- Fällen aber abschmieren.  rjmp kann nun mal
keine 0x7fff springen, da brauchen wir nicht mal klären, ob es sich um
eine Byte- oder Wortadresse handelt.

Ich denke, der korrekte Wert wäre 1fff, ich möchte aber die Antwort
abwarten.

#if __AVR_HAVE_JMP_CALL__
    jmp Application
#else
    rjmp Application
#endif

_AVR_HAVE_JMP_CALL_ ist für GCC >= 4.3 dokumentiert.  Wenn es auch
mit älteren Compilern gehen soll, müsstest du die entsprechenden
Architekturen explizit testen:

#if __AVR_ARCH__ == 2 || __AVR_ARCH__ == 25 || __AVR_ARCH__ == 4
   rjmp Application
#else
   jmp Application
#endif

Prima.  Das ist die beste Möglichkeit.  Ich werde das (voraussichtlich
die 2. Version) in den Source übernehmen.  Da ich unterwegs bin, wird es
noch 1..2 Tage dauern, bis ich den hier veröffentliche.

bin erst jetzt dazugekommen

Weiss nicht ob es noch relevant ist, aber hier meine atmel_def.h


#define  SIGNATURE_000 0x1e
#define  SIGNATURE_001 0x93
#define  SIGNATURE_002 0x0b
; ***** BOOT_LOAD ********************
#define  FLASHEND 0x1FFF        // Note: Word address
#define  SRAM_START 0x0060
#define  SRAM_SIZE 512
; ***** BOOTLOADER DECLARATIONS
******************************************

Als asm-Unwissender hab ich die Zeilen mal wie von Jörg Wunsch
vorgeschlagen geaendert.

nun bleiben noch die Fehlermeldungen

./added/fastload.inc:77: Error: illegal relocation size: 1
./added/fastload.inc:78: Error: illegal relocation size: 1
./added/fastload.inc:79: Error: illegal relocation size: 1

der entsprechende code aus der Datei

.byte           UserFlash>>16
.byte           (UserFlash>>8) & 0xff
.byte           UserFlash & 0xff


Ju

Edit:

meine gcc's  sind
gcc --version
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
avr-gcc --version
avr-gcc (GCC) 4.2.2

Also noch ein weiteres Problem.

Ich werde mich ab morgen darum kümmern.  Dann steht mir der Rechner, auf
dem der Bootloader-Source sich befindet, zur Verfügung.

Guten Abend
ich wollte mich rstmal fuer diesen netten Bootloader bedanken, er
verrichtet hier brav seine Dienste und erleichtert vieles.

Nun wollte ich fastboot_build18.tar.gz auch mal auf einen Atmega8
spielen und stoße da leider auf ein paar Probleme.

Wie fuer Mega32 aendere ich einfach das Makefile auf atmega8 und die
m8def.inc
Nur leider scheint hier das awk/gawk etwas mist zu bauen.

im atmel_def.h bzw atmel_def.mak ist
FLASHEND auf 0x1FFF gesetzt - wenn ich damit compile gibts einen jmp
fehler... wenn ich FLASHEND auf 0x0FFF setzte (wie in der m8def.inc
stehend) compiled er ohne Fehler. Die anderen Werte sehen richtig aus.
Koennt ihr den awk fehler reproduzieren?


Das ganze packe ich dann per avrdude auf den Mega8, wo ich vorher die
fuses gesetzt habe. (Da mein USB-ISP Adapter noch nicht fertig ist noch
per Bit-Banging)

avrdude -p m8  -c ponyser -P /dev/ttyUSB0 -v -U flash:w:bootload.hex
...
avrdude: Device signature = 0x1e9307
avrdude: safemode: lfuse reads as EF
avrdude: safemode: hfuse reads as DC
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be
performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "bootload.hex"
avrdude: input file bootload.hex auto detected as Intel Hex
avrdude: writing flash (8192 bytes):

Writing | ##                                                 | 4% 32.24s

Die fuses sollten richtig gesetzt sein, das ganze laeuft auf einem
Pollin Eval Board.


Das ganze geht gut, Bootloader startet auch, nimmt per lboot auch meine
.hex Datei entgegen, nur leider wird das Hauptprogramm nie gestartet.
Ohne ein Reset kann ich per lboot wieder was neues Flashen, er scheint
also immer nur den Bootloader zu starten, aber nie ins Hauptprogramm zu
springen.

Ich bin in Assembler nicht wirklich fit, deshalb hab ich mal den ganzen
Ordner angehaengt, vllt seht ihr ja wo es hapert.

Sofware nutze ich folgende:
awk --version :GNU Awk 3.1.6 ,genauso wie gawk
avr-gcc --version : avr-gcc (GCC) 4.3.4
Das ganze auf einem Debian squeeze (zzt testing)


Vielen Dank schon einmal
Hendrik

Der gawk macht's schon richtig.  Während FLASHEND für den
Atmel-Assembler eine Wortadresse ist, muss sie für avr-gcc in eine
Byteadresse übersetzt werden.  Das macht das gawk-Skript.  8 kBytes sind
dann 0x1fff.

Zum Problem mit dem jmp/rjmp siehe ein paar Beiträge höher.  Ich bin
leider noch nicht dazu gekommen, mich darum zu kümmern.  Wenn Du
FLASHEND einfach mitten in den Flash-Bereich setzst, kommt der Sprung
zum Programmbeginn dorthin, aber dort gehört er nicht hin.

Okay, hatte ich nicht so ganz verstanden mit Wort und Byte.

Hab mal den _AVR_ARCH_ Teil eingebaut.
Dann beschreibt
"avrdude: ERROR: address 0x3e10 out of range at line 1 of bootload.hex"
das rjmp Problem von oben?

Ich habe das Problem noch nicht nachvollzogen, aber ich denke, dass die
Lösung mit AVR_ARCH auch darauf zutrifft.

Hier die neue Version, die alle Fehler mit rjmps beheben sollte.

Für Neuanwender: bitte README lesen.  Es gibt einen Abschnitt "QUICK
START", der alles nötige erklären sollte.

@ mizch

erst mal vielen Dank fuer Deine Version und fuer Dein bemuehen.

Hab leider immer noch Probleme beim compilieren

hier die Ausgabe vom Compiler


flaco:~/Devel/AVR/BootLoader/fastboot$ make
Makefile:102: atmel_def.mak: No such file or directory
./_conv.awk tn85def.inc | gawk '/SIGNATURE_|SRAM_|FLASHEND|BOOT/' >
atmel_def.h
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
avr-gcc -c -mmcu=attiny85 -DF_CPU=8000000  -I . -I ./added -I
./converted -I/usr/local/avr/include  -ffreestanding -gstabs+
-Wa,-adhlns=bootload.lst,-L,-gstabs+ -DRAM_START=0x0060 -DSRAM_SIZE=512
added/bootload.S -o bootload.o
./added/fastload.inc: Assembler messages:
./added/fastload.inc:77: Error: illegal relocation size: 1
./added/fastload.inc:78: Error: illegal relocation size: 1
./added/fastload.inc:79: Error: illegal relocation size: 1
make: *** [bootload.o] Error 1


und die relevanten Zeilen aus ./added/fastload.inc


.byte UserFlash>>16
.byte (UserFlash>>8) & 0xff
.byte UserFlash & 0xff

Ju

Du bist offensichtlich der Erste, der die avr-gcc/avr-gas-Version auf
einem µC ohne Boot Section einsetzt.  Dann läuft einiges anders.
Könntest Du bitte auch dann eine Rückmeldung geben, wenn alles
funktioniert?

Hier die Version, die die von Dir gemeldeten Fehler behebt.

@mizch

Klar doch gebe ich auch Rueckmeldung wenn ales tut wie es soll.

Das Problem mit dem Compiler hast Du im Griff, er laeuft durch ohne
irgendetwas zu beanstanden, doch avrdude meckert beim flashen.


flaco:~/Devel/AVR/BootLoader/fastboot$ avrdude -cusbasp -pt85
-Uflash:w:bootload.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100%
0.01s

avrdude: Device signature = 0x1e930b
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be
performed
         To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is 1 (if being tracked)
avrdude: erasing chip
avrdude: reading input file "bootload.hex"
avrdude: input file bootload.hex auto detected as Intel Hex
avrdude: ERROR: address 0x3e2e out of range at line 1 of bootload.hex
avrdude: write to file 'bootload.hex' failed

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Da hat er recht.  0x3e2e ist "out of range" für ein 8k-Teil.  Ich
kümmere mich darum.

Woher hast Du Deine tn85def.inc?  Beim neuesten AVR Studio (4.18SP1) ist
nur eine für den Tiny45 dabei.  Falls Du eine aus offiziellen Quellen
hast, könntest Du sie mir zukommen lassen?

Falls Du sie Dir aus der tn45def.inc gebaut hast:  Hast Du beachtet,
dass die Flashgröße dort in Worten (16 Bit) angegeben ist?

Die tn85def.inc habe ich aus diesem Thread

Beitrag "tn85def.inc tn84def.inc"

Ju

Kannst Du in Deiner atmel_def.h nachschauen, welchen Wert dort FLASHEND
hat?

Vergiss die vorige Frage, es war mein Fehler.  Ich konnte das Problem
jetzt reproduzieren.  Mitgeliefert eine Version, die es korrigiert.

Für Neueinsteiger:  Bitte README lesen.

Bitte die Version mit 21 im Namen nur für den Tiny85 benutzen.  Sie
behebt Probleme damit, schafft aber andere.  Alle anderen bitte bei
Build#20 (fastboot_build20.tar.gz) bleiben.

Hier ist eine neue, gründlich überarbeitete Version.  Ich habe sie
querbeet mit den Typen Tiny45, Tiny85, mega8, mega64 und mega2560
geprüft.  Auch die Typen "dazwischen" sollten keine Probleme bereiten.

Die 64k-Grenze ist also weg, ebenso das Problem mit dem Tiny85.  Was
nicht geht, sind die ganz kleinen Typen ohne 'movw'-Instruktion wie der
Tiny26.

Es muss nur noch der Makefile angepasst werden und das Atmel-def-File
hinzugefügt werden; siehe README.  Bitte diesen lesen.

Ich hab das jetzt mal fuer einen m8 konfiguriert

Der build22 meckert bei mir eine fehlende Datei an.

./get_bootsection_addrs.sh

fehlt ihm.


flaco:~/Devel/AVR/m8/BootLoader/fastboot$ make clean
rm -f atmel_def.h bootload.x *.defs *.o *.gas *.mak *.lst *.02x *.map
flaco:~/Devel/AVR/m8/BootLoader/fastboot$ make
Makefile:118: atmel_def.mak: No such file or directory
./_conv.awk m8def.inc | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/'
> atmel_def.h
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega8 -DF_CPU=16000000  -I .
-I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding
-gstabs+ -L,-gstabs+ -DRAM_START=0x0060 -DSRAM_SIZE=1024
-DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/bootload.S
-o bootload.o
avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega8 -DF_CPU=16000000  -I . -I
./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+
-L,-gstabs+ -DRAM_START=0x0060 -DSRAM_SIZE=1024 -DSTX_PORT=PORTD
-DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/stub.S -o stub.o
vars="$(./get_bootsection_addrs.sh 0x0fff 0xf80 0xf00 0xe00 )"; \
  eval "$vars"; \
  sed -e "s/@LOADER_START@/$LOADER_START/g" \
      -e s'/@RAM_START@/0x0060/g' \
      -e s'/@RAM_SIZE@/1024/g' \
      -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
      bootload.template.x > bootload.x; \
  avr-ld -N -E -T bootload.x -Map=bootload.map \
    --cref bootload.o stub.o -o bootload.elf --defsym Application=0
/bin/bash: ./get_bootsection_addrs.sh: No such file or directory
avr-ld:bootload.x:21: syntax error
make: *** [bootload.elf] Error 1

Versuche es einmal mit der umbenannten get_text_addrs.sh.
Da steht etwas "plausibles" drin.

Werner

get_bootsection_addrs.sh ist neu und fehlt in der Liste der zu packenden
Programme.  Das habe ich übersehen und deshalb ist sie leider nicht
mitgeliefert.

Sie befindet sich im Anhang.  Morgen kommt eine neue gepackte Version,
die dann komplett ist.

Hier die komplette neue Version.

Es muss nur noch der Makefile angepasst werden und das Atmel-def-File
hinzugefügt werden; siehe README.  Bitte diesen lesen.

@mizch

Hut ab, "You got it".

Um das ganze mal laufen zu sehen habe ich es zuerst mit einem m8
getestet. Und nachdem ich die fuses alle richtig gesetzt habe lief der
bootloader astrein und mein Programm startet nach dem upload.

Dann zurueck zum t85.

Bootloader compiliert einwandfrei und laesst sich per ISP flashen.

efuse auf 0xFE gesetzt

Upload-Programm auf dem PC gestartet und es "uploaded"

Nur startet mein Programm nicht. :-(

Das Test-Programm was ich "uploade" wackelt nur an einem Pin. Wenn ich
es per ISP flashe dann wackelt der Pin auch. Nur nach bootloader-upload
wackelt er nicht.

Ich kann das upload-Programm auf dem PC mehrmals aufrufen und immer
wieder "uploaded" es. (ich muss keinen Reset am ATTiny dazu machen).

hier die Ausgabe vom upload-Programm

flaco:~/Devel/AVR/tn85/FirstTry$ ./bootloader -p main.hex -d /dev/ttyS1
-b 9600

=================================================
|             BOOTLOADER, Target: V2.1          |
=================================================
COM dev  : /dev/ttyS1
Baudrate : 9600
Program  : main.hex
-------------------------------------------------
Waiting for device... Press CTRL+C to exit. \
...Connected!
Bootloader    : V2.1
File "devices.txt" not found!
Target        : 1E930B (?)
Buffer        :     64 Bytes
Size available:   7678 Bytes

CRC enabled and OK.
Reading main.hex... File read.
Highest address in hex file: 0x0006D (109 Bytes)
Writing program memory...
Programming "main.hex": 00000 - 0006D SUCCESS

CRC: o.k.
Elapsed time: 1.292 seconds
...starting application


Wie bewegt man den t85 dazu das er erst den Bootloader und wenn nichts
ueber serial rein kommt dann das Programm startet. Beim m8 war es die
BOOTRST - Fuse, die der t85 nicht hat.


Ju

Bei MCUs ohne Bootsection überschreibt der Lader den Reset-Vektor (biegt
ihn auf sich um) und merkt sich den eigentlich dort geschriebenen Inhalt
in den 2 Flash-Bytes direkt unterhalb seiner eigenen Beginnadresse.

Dadurch startet immer erst der Bootlader.  Wenn der ins Timeout fällt
(0,3 sec oder so), wird das Anwenderprogramm gestartet.

Es gibt einen Punkt, den ich im Verdacht habe.  Nehme mal aus dem
Makefile im Abschnitt

bootload.elf : bootload.o stub.o

das „-c” direkt nach get_text_addrs.sh heraus und probiere, ob das
Anwenderprogramm dann startet.  Nach der Textersetzung den Bootlader
komplett neu mit

make -B

 übersetzen.

SUUUUPIIII, das wars.

jetzt tut er wie er soll.

1000000- Dank .

"realy great job"

Ju

Danke fürs Testen.  Dann will ich die korrigierte Version mal hiermit
unter's Volk bringen.

Für Neueinsteiger, die z.B. durch den Wiki hierher geleitet wurden:

Bitte die Datei 'README' als Erstes anschauen.  Es muss der Makefile
angepasst werden und das Atmel-def-File hinzugefügt werden.

Hallo euch allen, ich wollt mir grad einen Bootloader für den atmega 8
bauen ... aber ich bekomm es nicht hin. und ich hab es eigentlcih nach
anleitung gemacht.
1. alles extrahiert
2. die m8def.inc datei ausm AVR studio in den ordner kopiert
3. MCU = atmega8,  ATMEL_INC = m8def.inc im makefile definiert
4. --> make all

Fehler:
Build started 22.1.2010 at 02:57:24
vars="$(./get_bootsection_addrs.sh 0x0fff 0xf80 0xf00 0xe00 )"; \
    eval "$vars"; \
    sed -e "s/@LOADER_START@/$LOADER_START/g" \
        -e s'/@RAM_START@/0x0060/g' \
        -e s'/@RAM_SIZE@/1024/g' \
        -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
        bootload.template.x > bootload.x; \
    avr-ld -N -E -T bootload.x -Map=bootload.map \
      --cref bootload.o stub.o -o bootload.elf --defsym Application=0
./get_bootsection_addrs.sh: objdump: command not found
c:\WinAVR-20081205\bin\avr-ld.exe:bootload.x:21: syntax error
make: *** [bootload.elf] Error 1
Build failed with 1 errors and 0 warnings...

an was liegt das?

bitte um Hilfe... danke

> ./get_bootsection_addrs.sh: objdump: command not found

Oha - da wird 'objdump' statt 'avr-objdump' aufgerufen.  Das fällt
natürlich auf einem System wie meinem nicht auf, wo auch ein nativer gcc
installiert ist und objdump deshalb existiert.  Ersetze in Datei
get_bootsection_addrs.sh „objdump” durch „avr-objdump” (oder Du wartest
bis heute abend, dann kommt eine korrigierte Version).

Der andere Fehler dürfte nur ein Folgefehler sein.

das ging schnell...
ich kann eh erst heut abend neu testen .. dann werde ich weiter
probieren.

Hat jemand schon mal einen Bootloader für den AT90CAN128 via CAN
realisiert.
ich suche schon ewig nach so einer lösung und finde nicht wirklich
etwas.
Als verbindung würde ich den CAN <> USb adapter von mictronics
nehmen....
der funktioniert wunderbar und ist einfach aufgebaut.
siehe link:  http://www.mictronics.de/projects/usb-can-bus/

Vielen Dank
für die hilfe

Hier die aktualisierte Version, die nicht objdump, sondern avr-objdump
voraussetzt.  Letzterer ist u.a. Teil von WinAVR und sollte somit immer
vorhanden sein.  Sonst hat sich nichts geändert.

Für Neueinsteiger, die z.B. durch den Wiki hierher geleitet wurden:

Bitte die Datei 'README' als Erstes anschauen.  Es muss der Makefile
angepasst werden und das Atmel-def-File hinzugefügt werden.

Mir sieht es danach aus, als ob bei der Erzeugung des .hex-Files etwas
schieflief.  Das wäre dann ein Fehler des Programms, nicht auf Deiner
Seite.

Es dürfte 1 oder 2 Tage dauern, bis ich mich das genauer ansehen kann.
Hab' solange Geduld.

Ich habe doch schon was.  Ich habe nämlich zufällig die Datei hier, mit
der ich für dem m2560 getestet habe.  Könntest Du bitte verifizieren, ob
Deine .hex-Datei mit

:020000023000CC
:10FC0000

beginnt (die zweite Zeile ist auf den Teil abgeschnitten, auf den es
ankommt)?  Das ist die Startadresse des Bootloaders ((3000 << 4) +
fc00).

Falls das zutrifft, könntest Du bitte noch überprüfen, dass nirgendwo
anders im .hex-File eine Zeile auftritt, die mit

:02000002

beginnt?  Damit wäre sicher gestellt, dass das Hex-File nirgendwo unter
0x30000 gehen kann (es bleibt - oder sollte bleiben - sowieso oberhalb
3fc00, das fc00 wird aber dann durch die einzelnen Records bestimmt).

Ist beides der Fall, dürfte davon auszugehen sein, dass es sich um ein
Problem beim Flashen handelt und dass im Bootloader-.hex nichts ist, was
die von avrdude monierte Adresse 0x1fc00 betreffen kann.

Übrigens:  Obiges geht auch kürzer.  Mach' mal

avr-objdump -h bootload.hex

und schau nach, wo die Flashadressen (VMA oder LMA, sollte beides
dasselbe sein) sich befinden.

Dann ist es ein Problem Deines AVRs oder Flashers, sorry.  Der
Bootloader will ja nicht nach 0x1fc00, sondern nach 0x3fc00.

Die 0x1fe00 als Beginn der Boot-Section sind übrigens eine Wortadresse
und liegen daher nur optisch nahe bei Byteadresse 0x1fc00 (avrdude
verwendet Byteadressen), auf der der Fehler auftritt.

Mir ist nicht klar, was der avrdude mit der Adresse 0x1fc00 zu schaffen
hat, wenn das zu flashende .hex ausschließlich Adressen im Bereich
0x3fc00..0x3ffff enthält.  (Da Du die Option -D (disable auto erase)
nicht angegeben hast, sollte übrigens ein Erase stattgefunden haben und
dort 0xff stehen.  Das deutet auf einen Fehler des Chips hin.)

Meine allererste Vermutung war wegen der Fehleradresse, dass der
Bootloader sich fälschlicherweise doch dorthin lädt, aber das ist ja nun
ausgeschlossen.  Vielleicht kann jemand anderes etwas dazu sagen.

Auffällig ist ja schon, dass auf 3fc00 der Inhalt 0xf8 steht und dieser
Dir auf 1fc00 zurückgemeldet wird.  Neben einem Chipdefekt könnte bei
serieller Programmierung auch ein Verschleifen mit dem Nachbar-Adressbit
in Frage kommen, da sich beide Adressen nur in einem Bit unterscheiden.

Du könntest spaßeshalber die zweite Zeile im .hex herausnehmen (die
erste mit :020000023000CC MUSS drinbleiben) und schauen, ob dann als
Fehler 0x60 auf Adresse 1fc10 gemeldet wird.  Dann weißt Du zwar, dass
die Adressen der oberen Flashhälfte in der unteren doppeln, aber viel
bringt das Wissen eigentlich nicht.

Kannst Du denn andere größere Programme mit avrdude flashen?

Die Größe der .hex-Datei kommt schon hin.  Je 16 Code-Bytes enthält sie
42 Bytes.  Dazu kommen Vor-und Nachspannzeilen.

14k ist nicht besonders groß für einen 256k-Flash.  Ich denke, dass Du
bei höheren Größen über dieselben Probleme stolpern wirst; einen
Zusammenhang mit dem Bootloader kann ich jedenfalls beim besten Willen
nicht erkennen.

Es fehlen die defines für SRAM_START und SRAM_SIZE.

Mach' doch mal einen „make -B” und poste dann die Zeile, die mit
./conf.awk beginnt.  Füge bitte als Anhang Deine m8def.inc, atmel_def.h
und atmel_def.mak dazu (sie sind nicht gross).

Irgendetwas ist auf dem Weg von m8def.inc zu diesen beiden Dateien
schief gegangen.

Das tee /dev/stderr soll bewirken, dass die Werte auch sichtbar
ausgegeben werden, mehr nicht.  Es kann also auch wegbleiben, bis ich
mir eine andere Anzeigemethode habe einfallen lassen.

Auf welchem System arbeitest Du (Linux, FreeBSD, Windows, ...)?  Weißt
Du zufällig, welche Standard-Shell dort benutzt wird?

Hier eine Version, in der der tee nach /dev/stderr herausgenommen und
ersetzt wurde.  Sonst hat sich an der Funktionalität nichts geändert, es
sollte aber auf einer größeren Vielfalt an Systemen durchlaufen.

Für Neuanwender: bitte README lesen.  Es gibt einen Abschnitt "QUICK
START", der alles nötige erklären sollte.

> ( printf... ) öffnet eine Subshell. Nichth so elegant.

Ich weiß nicht, was an einer Subshell unelegant sein soll.  Sie ist ein
normales Programmierkunstrukt, um etwas zusammenzufassen.

> Nimm doch statt tee die Ausgabeumleitung nach &2.

Das ist gewiss nicht die Lösung.  Denn damit habe ich es auf stdout
nicht mehr.  Dort wird es aber gebraucht.  Oder warum glaubst Du, dass
das tee da ist?  Um Dich zu verwirren?  Das wäre ja geschafft.

> Linux. Wenn Du /bin/sh reinschreibst bekommst Du auch /bin/sh = Bourne
> Shell.

Dann bekomme ich ein Shell, die Boune-kompatibel sein sollte, aber mehr
nicht.  Insbesondere nicht, wie Dein "/bin/sh = Bourne Shell"
vortäuscht, eine bestimmte.  Das kann nämlich dash, bash, ash, busybox,
... sein.  Das nicht wissend, hast Du die Frage eben schnippisch mit
"/bin/sh = Bourne Shell" beantwortet. Lassen wir's.

Hallo euch allen,

ich bin schon seit einiger Zeit auf der Suche nach einem CAN-Bootlader
für den AT90CAN. Leider konnte ich dazu aber kein fertiges Projekt
finden.
Genauere Informationen gibt es unter fogendem Link:

Titel - Beitrag "CAN BUS Bootloader AT90CAN"

Ich hoffe es finden sich einige um dieses Projekt zu realisieren oder
die dabei helfen können.

Grüße martin

Könntet ihr die Diskussion bitte an eine passende Stelle verlagern?  Das
hat mit dem Thema des Threads nichts zu tun und eine solche Unterhaltung
gehört auch nicht in die Codesammlung.

Das Thema soll auch nicht hier diskutiert werden.

Ich wollte mit dem Eintrag auf das Problem aufmerksam machen.
Da diesen Thread viele lesen, die Ahnung von der Programmierung von
bootloadern und den zugehörigen Terminal-Programmen haben.
Mit dieser Erfahrung können Sie sehr wahrscheinlich bei einer Lösung
helfen.

danke martin

@Jochen:
Du könntest die Datei zur Überprüfung mit dem ISP flashen und
verifizieren.  Aber auch so ist es eher unwahrscheinlich (wenn auch
nicht ausgeschlossen), dass es sich um ein Problem des Bootloaders
handelt.

@eku:
Das ist sinnvoll (in Übereinstimmung mit dem, was andere Makefiles bei
'clean' machen).  Für die nächste Version notiert.

Ich kann Dir leider keine endgültige Antwort geben, da ich nicht jeden
ATmega-Typ einzeln testen kann.  Ich kann nur gewährleisten, dass der
erzeugte Code identisch mit dem Original (fastboot von Peter Dannegger)
ist.

Da auch dort kein entsprechender Fehler gemeldet ist und es den schon
etwas länger gibt, vermute ich, dass Du in Deiner Hardware suchen musst.
Aber sicher kann ich es nicht sagen.

Moin,
ich habe zwei Fragen zum Bootloader, da meine Assembler-Kenntnisse nicht
sonderlich groß sind:

1. Ich möchte den AtMega128 gerne über eine Modemverbindung
aktualisieren. Hierzu boote ich meine Hauptapplikation und starte so den
Bootloader und nehme das Update vor. Das funktioniert soweit auch ganz
gut, wenn die Verbindung nicht unterbrochen wird. Kommt es aber zu einer
Unterbrechung, dann ist das Gerät leider nicht mehr erreichbar. Es hilf
dann nur noch ein Hardware-Reset, wozu man logischerweise am Gerät
stehen muss. Ich wollte daher gerne wissen, ob im Bootloader keine
Überprüfung beim Flashen vorgenommen werden kann, ob ALLE Daten korrekt
geschrieben worden? Falls nicht, dann springt der Bootloader erst gar
nicht in die Hauptapplikation und wartet auf das erneute Einspielen der
Firmware. Woran erkennt der Bootloader aktuell, dass sich (angeblich)
eine Applikation im Flash befindet?

2. Ist es möglich die Lockbits nach dem Firmwareupdate durch den
Bootlader zu setzen. Ich möchte gerne das Auslesen der Firmware über ISP
verhindern.

Vielen Dank schon mal!

Würde der Watchdog Dir helfen?

F. Wuro schrieb:
> Hierzu boote ich meine Hauptapplikation und starte so den
> Bootloader und nehme das Update vor. Das funktioniert soweit auch ganz
> gut, wenn die Verbindung nicht unterbrochen wird.

Wenn das Programm unvollständig geschrieben wurde, wird es bei der
Ausführung mit hoher Wahrscheinlichkeit in den Watchdog laufen und der
Bootlader wird neu gestartet, wenn die Fuses richtig gesetzt sind.  Von
daher scheint mir der Watchdog schon ein möglicher Ausweg.

Ein Schreiben der Lockbits ist zwar für einen Bootloader theoretisch
möglich.  Da die 512 Bytes für den Bootloader aber gesteckt voll sind,
habe ich gewisse Zweifel, dass Peter Dannegger das implementiert (Du
müsstest ihn fragen).  Ich möchte mit der AVR-GCC-Version jedenfalls
immer seiner Vorlage folgen und keinen Fork machen.

Vielen Dank für die schnelle Unterstützung!

In der Tat ist der Watchdog die Lösung. Wichtig dabei ist den Watchdog
über die Fuse WDTON zu aktivieren und nicht über die Software, da diese
im Falle einer Verbindungsabbruchs ja nicht korrekt geschrieben wird.

Bezüglich der Lockbits werde ich mich wie vorgschlagen an Peter
Danneberger wenden.

Hc Zimmerer schrieb:
> Die 64k-Grenze ist also weg,...

Hallo zusammen,

ich habe das Problem, dass Applications >64k auf einem ATmega2561 nicht
programmiert werden können (<64k ohne Probleme). Programmierung >64k mit
ISP und avrdude oder AVR Studio ist ohne Probleme möglich.

@Hc Zimmerer du schreibst die Grenze ist weg. Kannst du mir einen Tip
geben wo du was geändert hast? Ich verwende momentan den Bootloader v2.1
aufm AVR - programmiert wird von einem externen Master gem. Protokoll.

mit Bootloader programmiert:

:10FFE0009F4F2817390739F481E08093AA084957B1
:10FFF0004093E110089550913310952F52FF0BC09C
:020000021000EC
:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0

mit AVR Studio programmiert:

:10FFE0009F4F2817390739F481E08093AA084957B1
:10FFF0004093E110089550913310952F52FF0BC09C
:020000021000EC
:100000008091E50F873639F481E08093AA0887E470
:100010008093E210089593FF0BC08091E60F873222

Vielen Dank schon mal im Voraus.

F. S. schrieb:
> du schreibst die Grenze ist weg. Kannst du mir einen Tip
> geben wo du was geändert hast?

Das war eine ganze Reihe von Änderungen, die aber alle darauf
hinausliefen, dass der erzeugte Code identisch ist mit dem durch avrasm2
erzeugten Original von peda.  Die Originale, mit denen geprüft wird,
sind ein paar Tinys, der Mega8, Mega64 und Mega2560.  Der 2561 ist also
nicht dabei, die Unterschiede dürften aber für einen Bootloader nicht
ins Gewicht fallen.

Der Vergleich läuft so ab: Das Makefile besitzt ein Target (cmp), das
die Codes vergleicht.  Dabei werden zunächst beide Versionen (avrasm2
und avr-gcc) in reines Binärformat gewandelt, um Unterschiede im Aufbau
der Intel-Hex-Dateien wegzubekommen. Diese beiden Binärdateien werden in
einen Hexdump gewandelt und die zwei Hexdumps schließlich mit etwas
Shellskript-Magie verglichen.  Die Magie sorgt dafür, dass die
Unterschiede (falls vorhanden) mit Adressinformationen angereichert
werden, so dass sie einfach im Listing wiedergefunden werden können.
(Dieser Teil des Makefiles setzt ein Unix-artiges Betriebssystem
voraus.)

Ein Test mit allen denkbaren AVRs am lebenden Objekt würde den Rahmen
sprengen.  Auch habe ich hauptsächlich mit den kleineren AVRs zu tun;
der größte, den ich hier habe, ist ein 644.

Dein Hex-Auszug deutet darauf hin, dass nichts oberhalb der 64-k-Grenze
geschrieben wurde.  Wenn ich mich richtig erinnere, gab es zumindest
einen Fehlerbericht hier in diesem Thread, wo zuviel dort geschrieben
wurde (und der letztlich nicht ganz geklärt blieb - es schien mir
unwahrscheinlich, dass ein Fehler des Bootladers vorliegt).

Ich kann frühestens ab Wochenende nochmal tiefer in das Thema einsteigen
... nur wüsste ich im Moment nicht, wie.  Ich kann wahrscheinlich (und
muss) davon ausgehen, dass das Original von peda seine Sache schon
richtig macht.  Vielleicht gibt diese Antwort hier Dir eine Ideee zu
einem Vorschlag, vier Augen sehen schließlich mehr als zwei.

> makefile:118: atmel_def.mak: No such file or directory
> gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
>
> aber in dem ordner fastboot wird doch solch ein ordner erstellt

Dieser Ablauf ist so schon in Ordnung; die 'No such file' - Meldung
kommt immer beim ersten Mal und es wird daraufhin, wie Du richtig
festgestellt hast, die angemeckerte Datei schon erstellt.  Das Anmeckern
kann nicht abgestellt werden, da der Makefile sie includet.

Das hat nichts damit zu tun:

> make.exe: *** No rule to make target `all'.  Stop.

Der Grund: Du musst einfach 'make' aufrufen, ohne Argumente (wie 'all').

> nur die funktion "make" gibt es sicher nicht im programmer notepad 2
> oder?

Das weiß ich nicht.  Was spricht dagegen, ein Kommandozeilenfenster
aufzumachen, 'cd' ins Verzeichnis zu machen und 'make' zu tippen?

Alternativ dazu kannst Du auch beiliegendes Makefile nehmen.  Die
einzige Änderung gegenüber dem Original ist, dass es über ein Dummy-Ziel
namens 'all' verfügt, das vom wirklichen Ziel abhängt.

Was genau verstehst Du unter „Host-Software für windows“?

Der Thread mit u.a. der Host-Software befinden sich laut Wiki
(http://www.mikrocontroller.net/articles/AVR_Bootlo...)
hier („Host-Software für Win32“):
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" .

Dort nachzuschauen bzw. anzufragen dürfte für Deine Zwecke besser
geeignet sein, da der Thread hier sich mit der residenten
AVR-GCC-Version beschäftigt und keine Host-Software behandelt.

Hallo,

ich versuche seit gestern einen Bootloader auf einem Atmega1281 zum
Laufen zu bewegen. Ich habe bereits den Bootloader t13 - m644
ausprobiert, mit dem ich bis jetzt auch keine Probleme hatte. Leider
fällt er diesmal durch sporadische Nichtfunktion auf.

Daher dachte ich mir, probierst du eben mal diesen hier. Leider habe ich
da schon beim Erstellen meine Probleme. Ich denke, alles so wie in der
README gemacht zu haben. Ich benutze AVR-Studio 4.17 build 666 mit
WinAVR-20090313.

Beim Übersetzen kommt der Fehler:

Makefile:118: atmel_def.mak: No such file or directory

Was aber wohl ganz normal ist, wie ich weiter oben gelesen habe. Die
Datei atmel_def.mak wird aber erstellt.

Nach mehreren grün markierten Erfolgsmeldungen kommen zum Abschluss
diese beiden Fehler.

d:\Programme\Atmel\WIN_AVR\bin\avr-ld.exe: avr:51 architecture of input
file `bootload.o' is incompatible with avr output
d:\Programme\Atmel\WIN_AVR\bin\avr-ld.exe: avr:51 architecture of input
file `stub.o' is incompatible with avr output

Das ist doch bestimmt was ganz simples und ich bin einfach nur zu doof
es zu finden.

Könnt Ihr mir bitte weiterhelfen?

Gruß Paul

Hast Du im Makefile die nötigen Anpassungen durchgeführt, z.B. den
µC-Typ eingestellt?  Welcher ist dort eingestellt und welcher im Studio?

Ja, habe ich alles gemacht. Auch im AVR-Studio ist als Device atmega1281
eingestellt. Ist es richtig, das in den Projektordnern auf der linken
Seite (source files, header files usw.) nichts eingebunden ist?

Das war jetzt dumm ausgedrückt von mir. Auf der linken Seite ist nur das
Makefile eingebunden, aber sonst nichts.

Ja, das ist richtig.  Der Source ist für die Übersetzung ohne AVR-Studio
gedacht, kann aber natürlich auch mit verwendet werden.  Du kannst die
Quelldateien angeben, aber da mit Makefile übersetzt wird, steuert nur
dieser die Übersetzung.

Dein Problem dürfte aber darin liegen, dass die Quellen für einen andren
Typ kompiliert wurden als der Linker erwartet.  Hast Du mal übersetzt
und danach den µC-Typ geändert?  Egal.  Starte mal cmd.exe, wechsle in
das Projekt-Verzeichnis, und rufe „make -B“ auf.

So, habs mit make -b versucht, aber da kommt der gleiche Fehler wie im
AVR Studio. Wenn ich im Makefile atmega8 und m8def.inc einstelle
funktioniert die Übersetzung problemlos.

Paul P. schrieb:
> So, habs mit make -b versucht

make -B.  Das ist was Anderes als make -b.

Oh, das wusste ich nicht, aber leider hat es dennoch nichts genützt.
Aber:

Eben habe ich aus Spaß im Makefile mal den Proessortyp in Atmega2560
geändert, aber mit m1281def.inc übersetzt. Hat funktioniert. Dann habe
ich den Prozessortyp wieder in Atmega1281 geändert und nochmal
übersetzt. Und es hat wieder geklappt. Ich kann danach unendlich oft
problemlos übersetzen. Wenn ich aber zwischendurch wieder mal auf
atmega2560 umstelle, geht es danach auch mit atmega1281 nicht mehr. Der
atmega2560 ist wie ein umschalter, mit dem ich zwischen "geht" und "geht
nicht" wechseln kann.

Wenn Du übersetzt, dann den Makefile änderst, arbeitet das Ding weiter
mit den für einen anderen Typ übersetzten Dateien.  Das ist nicht
sinnvoll.  Denn Makefiles sind dazu da, dass bereits gemachte Arbeit
nicht nochmal gemacht werden muss.  Durch Deine Änderungen am Makefile
sorgst Du dafür, dass die bereits gemachte Arbeit den falschen µC-Typ
betrifft und mit ungeeigneten Dateien weitergemacht wird.

Wenn Du am Makefile was änderst, musst Du vor der nächsten Übersetzung
„make clean“ aufrufen.

Ich kenne mich mit Makefiles eigentlich gar nicht aus. Mich interessiert
mehr die Aufgabe die der Controller dann erledigen soll, daher war ich
dafür immer zu bequem und habe das Makefile automatisch erstellen
lassen.

Ich habe gerade mal ein paar Controllertypen ausprobiert und habe dabei
immer den Controllertyp mit entsprechendem .inc File getestet. Es gehen
eigentlich alle außer:

atmega128
atmega1280
atmega1281

Ich habe nach jeder Änderung im Makefile "make clean" durchgeführt.

Vielen Dank schonnmal für deine schnelle Hilfe.

Makefiles werden so richtig auch erst bei wesentlich größeren Projekten
nützlich, wo die Übersetzungszeit einen wesentlichen Anteil am
Debug-Zyklus bekommt.

Wie dem auch sei:  Ich habe heute Nachmittag einen Termin und werde
abends oder morgen die Übersetzung für die von Dir genannten Typen
nochmal prüfen.  Für'n Moment ist mir die Zeit zu knapp, noch
einzusteigen.

Vielen Dank dafür!

Gefunden.  Als Workaround: Ersetze in bootload.template.x ziemlich am
Beginn die Zeile

OUTPUT_ARCH(avr:2)

durch

OUTPUT_ARCH(avr:51)

und baue dann neu, also entweder „make -B“ oder „make clean; make“
ausführen.

Dieser Workaround ist nur für diesen speziellen Fall (ATmega128x)
gültig.  Eine allgemeine Lösung wird voraussichtlich bis zum Wochenende
warten müssen.  Dann gibt es eine neue Version.

Hallo,

du bist einfach der Beste. Es hat sich ohne Probleme bauen lassen und
auch der Bootloader scheint jetzt richtig zu funktionieren. Bei dem
anderen hatte ich immer das Problem, dass die Host Software ständig
Onewire Modus erkannt hat, obwohl ich Twowire benutze. Ich hoffe das ist
jetzt vorbei, aber bis jetzt sieht es gut aus.

Vielen Dank nochmals für deine schnelle Hilfe.

Grüße Paul

Hallo nochmal,

kurz nachdem du mir der Workaround gezeigt hast, hatte ich keine
Probleme mit dem Bootloader. Eben wollte ich was auf den Controller
übertragen, da kommt wieder dieser Fehler mit dem Onewire!

COM1 at 38400 Baud: Connected <One Wire>
Bootloader VFFFFFFFF.FF
Error, wrong device informations

Eine Verringerung der Baudrate nützt auch nichts. Ich hatte sogar in dem
.def File der Host-Software den atmega1281 mit eingetragen. Leider ohne
Erfolg.

Ich hab mir jetzt gerade Version 1.7 der Host Software runtergeladen und
mit der scheint es zu funktionieren. Iss ja auch nicht so, dass ich hier
einen Drahtverhau habe. Der Controller sitzt auf einer richtigen Platine
und ist mit ca. 10cm langen Kabeln an einen TTL->RS232 Wandler von
Pollin angeschlossen. Nichts Breadboard oder so.

Naja, vielleicht funktioniert es ja weiterhin, dann wäre alles gut.

Gruß

Paul

Das dürfte, wie Du bemerkt hast, ein Problem der Host-Software sein.
Ich drück' Dir die Daumen, dass es mit der neuen Version weiterhin geht.

Hier die aktuelle Version (für alle Typen inklusive des Bugfixes für die
ATmega128x).

Vor dem Loslegen bitte README lesen und den ersten Teil des Makefile
anpassen.  Die Anpassungen geschehen hier im Makefile (anders als im
Wiki beschrieben, der die avrasm2-Version behandelt).

Hallo,

das ging ja sauschnell, herzlichen Dank. Du konntest es wohl nicht
erwarten mir zu helfen? ;-) Ich habe eben build27 auf den Atmega1281
geflasht. Bauen ging absolut reibungslos.

Das Problem mit fehlerhaften Onewire-Erkennung liegt mit Sicherheit an
der Host-Software, denn es trat ja auch mit dem anderen Bootlaoder auf.
Ich habe eben problemlos ein paar mal mit beiden Versionen (1.7, 2.1)
Firmware auf den Controller geladen. Ich kann aber noch nichts Genaues
sagen, werde aber zunächst mal wieder Version 2.1 testen.

Da ich den Bootloader bei meiner Applikation eigentlich brauche und auch
schon mittelschwer verzweifelt war, weil er nicht ging, hatte ich mich
schon nach anderen umgeschaut. Keiner den ich gefunden hatte, ist so
bequem, vielseitig und universell. Der auf avr_asambler2-Basis war ja
auch schon bequem, aber jetzt ist es ein reiner Genuss.

Der Bootloader kann ja nicht den EEPROM programmieren. Kann ich die
Variablen/Konstanten per ISP "EEPROMMEN" und die Firmware dann per
Bootloader?

Grüße Paul

P.S.: Könntest du vielleicht bitte kurz erklären (aber nicht zu
kompliziert), was da nun faul war? Was ist denn an den Atmega128x so
anders, dass so ein Fehler auftreten kann?

Was geändert wurde:  Ich verwende ein eigenes Linker-Script.  Das
Linkerscript bestimmt die Speicheraufteilung.  Da der Bootloader ans
Ende des Flash kommt, ist das standardmäßige Linkerscript des AVR-GCC
ungeeignet, deshalb das eigene in einem eigenen Linker-(avr-ld-)Lauf.

Das Linkerscript (bootload.x) wird während des Make-Laufs aus einer
Vorlage (bootload.template.x) erstellt.  Bisher war die AVR-Architektur,
für die gelinkt wird, fest vorgegeben.  Das führte beim ATmega128x zu
dem Fehler, den Du bekommen hast.

Nun wird der AVR-GCC gefragt, welche Architektur er nehmen würde, wenn
er normal linken würde (die Zeile mit avr-gcc -### ... | gawk ...).  Die
Architektur wird extrahiert und ins Linkerscript eingetragen.

Zu Deiner anderen Frage:  Der Bootloader löscht das EEProm nicht, Du
kannst es also mit ISP „vorprogrammieren“.

Hallo,

danke für die Erklärung. Das konnte ich schon halbwegs verstehen. Was
ich nur komisch fand, war halt, dass ausgerechnet die m128x Typen
betroffen waren.

Ich habe übrigens heute den Controller mehrmals problemlos mit Version
2.1 der Host-Software programmiert. Der beschrieben Fehler trat auch
nicht einmal auf.

Ich werde mich nochmal melden, sollte der Fehler wieder auftreten. Wenn
er wieder auftritt, steige ich wieder auf Version 1.7 um.

Das mit dem EEPROM dachte ich mir schon, ich wollte nur noch mal sicher
gehen. Ich hab schon Stunden nach Fehlern im Code gesucht, aber keine
gefunden; dabei hatte ich Rinv... nur vergessen die *.eep-Datei zu
übertragen.

Gruß Paul

AHRGHHHHHHHHHHHH!!!

Ich werde noch verrückt. Jetzt geht das wieder nicht. Beide Versionen
der Host Software gehen nicht mehr. Das Übertragen von Firmware geht nur
nach dem der Bootloader frisch geflasht wurde. Kann es sein, dass da
irgendwas mit den Adressen nicht stimmt und er sich mit der Firmware
teilweise selbst überschreibt?

Gruß Paul

hallo,
ich glaube ich habe den selben Fehler.
  - nutze winavr
  - Bootloader für den AT90can128 auf den UART1(Port D1 und D0)

ich habe es mit einem Bootloader für den atmega 8 versucht, da klappt
alles besten. jedoch bekomme ich bei der auswahl alle dinge für den
AT90Can128 folgende Fehler:

*** Note: set BOOTSZ fuses for the word address 0xfe00 ***
LOADER_START=0x1fc00
STUB_OFFSET=0x3fe
c:\WinAVR-20100110\bin\avr-ld.exe: avr:51 architecture of input file
`bootload.o' is incompatible with avr output
c:\WinAVR-20100110\bin\avr-ld.exe: avr:51 architecture of input file
`stub.o' is incompatible with avr output
make.exe: *** [bootload.elf] Error 1

Probiert habe ich es mit dem speziellen Makefile mit dem Befehl makeall
und über das Kommandozeilenfenster. Beide bringen den selben Fehler.

kann mir jemand möglichst schnell helfen?

Hast Du auch die aktuelle Version
Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain"
(Build 27) dazu verwendet?

Nachtrag:

Martin J. schrieb:
> Probiert habe ich es mit dem speziellen Makefile

Das klingt mir eher so, als hättest Du stattdessen (oder zusätzlich)
einen speziellen Workaround für einen bestimmten Prozessor blind
übernommen (auch avr:51 passt dazu), der durch die neue Version
hinfällig wurde.

--> ich meite dieses Makefile
Hc Zimmerer schrieb:
> Alternativ dazu kannst Du auch beiliegendes Makefile nehmen.  Die
> einzige Änderung gegenüber dem Original ist, dass es über ein Dummy-Ziel
> namens 'all' verfügt, das vom wirklichen Ziel abhängt.

ich hatte ncoh die version 26, mit der gab es dieses Problem, mit der
Version 27 ist es behoben.

danke

kannst du mir sagen wie Große der Bootloader ist? reicht 1024Byte?

Martin J. schrieb:
> reicht 1024Byte?

Ja.

Kannst Du mir den Output der folgenden 2 Kommandos posten?

avr-gcc -mmcu=atmega168 -### bootload.o  -o X 
avr-gcc --version

Stefan schrieb:
> Die toolchain und gcc habe ich vor knapp 4 monaten mit hilfe von
> crossdev gebaut, bisher hatte ich aber noch keine probleme damit

Kein Problem.  Das Problem ist vielmehr, dass ich Annahmen über den
internen Aufbau der Toolchain gemacht habe, die bei Dir nicht zutreffen.
Es war mir dabei klar, dass das u.U. Probleme machen könnten, es schien
mir aber sehr unwahrscheinlich.  Tja, war wohl nix.

Gegen Abend werde ich eine neue Version fertig haben, die auch mit
Deinem avr-gcc läuft.

Hier nun die modifizierte Version.  Die Zielarchitektur wird jetzt so
ermittelt, dass auch mit Nicht-Standard-avr-gccs keine Probleme mehr
auftauchen sollten.  Sonst hat sich nichts geändert; es gibt also keinen
Grund, von den Vorversionen zu wechseln.

Vor dem Loslegen bitte README lesen und den ersten Teil des Makefile
anpassen.  Die Anpassungen geschehen hier im Makefile (anders als im
Wiki beschrieben, der die avrasm2-Version behandelt).

Hallo,

ich würde gerne den Bootloader für einen ATmega64 verwenden. Leider
kommt beim Compilieren des Bootloaders folgender Fehler:

avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega64 -DF_CPU=14745600  -I . -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gdwarf-2 -L,-gdwarf-2 -DRAM_START=0x0100 -DSRAM_SIZE=4096 -DSTX_PORT=PORTE -DSTX=PE1 -DSRX_PORT=PORTE -DSRX=PE0 added/
stub.S -o stub.o

vars="$(./get_bootsection_addrs.sh 0x7fff 0x7e00 0x7c00 0x7800 )"; \
    arch="$(./get_avr_arch.sh -mmcu=atmega64 bootload.o)"; \
    echo "arch=$arch";\
    echo "$vars"; \
    eval "$vars"; \
    sed -e "s/@LOADER_START@/$LOADER_START/g" \
        -e s"/@ARCH@/$arch/" \
        -e s'/@RAM_START@/0x0100/g' \
        -e s'/@RAM_SIZE@/4096/g' \
        -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
        bootload.template.x > bootload.x; \
    avr-ld -N -E -T bootload.x -Map=bootload.map \
      --cref bootload.o stub.o -o bootload.elf --defsym Application=0
*** Note: set BOOTSZ fuses to the word address 0x7e00 ***
./get_avr_arch.sh: awk: command not found
./get_avr_arch.sh: [: =: unary operator expected
get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld command line
arch=
LOADER_START=0xfc00
STUB_OFFSET=0x3fe
c:\WinAVR-20090313\bin\avr-ld.exe:bootload.x:18: syntax error
make: *** [bootload.elf] Error 1
Build failed with 2 errors and 0 warnings...

Ich hoffe jemand kann mir weiter helfen. Ich gehe nach der README vor
und benutze AVR Studio 4.18

Vielen Danke Tobias

Tobias S. schrieb:
> ./get_avr_arch.sh: awk: command not found

Probiere mal die angehängte Datei get_avr_arch.sh.  Einfach in das
ausgepackte Verzeichnis gehen und die vorhandene überschreiben.

Vermutlich ist das ein Problem mit WinAVR: ich nahm an, dass er das
Unix-Standard-(POSIX-)Kommando „awk“ kennt.  Ich vermute nun, dass er es
nur unter dem speziellen Namen „gawk“ kennt.

julian schrieb:
> Idee, woran es hapert?

Es hängt damit zusammen:

> avr-gcc (GCC) 4.5.1 20100610 (prerelease)

und dass „collect2“ statt „avr-gcc“ zum Compilieren aufgerufen wird
(siehe Deine Ausgabe zu „avr-gcc -mmcu=atmega168 -### bootload.o  -o
X“).  Da Dein avr-gcc ein Prerelease ist, kann ich Dir leider nur sagen,
dass ich da erst abwarten möchte, ob das so bleibt und Dich bitten, bis
dahin mit einem stabilen Release zu übersetzen.

Vielen Dank jetzt hat es funktioniert.
Danke für deine Mühe.

Ich finde es super, was du da auf die Beine gestellt hast.

Respekt.

Vielen Dank Tobias

Die aktuelle Version, so angepasst, dass es auch wieder mit WinAVR läuft
(enthält das geänderte get_avr_arch.sh von ein paar Artikel darüber).
Sonst keine Änderungen.

Vor dem Loslegen bitte README lesen und den ersten Teil des Makefile
editieren.  Die Anpassungen geschehen hier im Makefile (anders als im
Wiki beschrieben, der die avrasm2-Version behandelt).

Der get_avr_arch.sh im Anhang sollte sowohl für bisherige als auch für
neue Versionen von avr-gcc gehen.  Einfach über den vorhandenen
reinkopieren. Probier's mal damit aus und gib bitte Rückmeldung, ob es
klappt.