Forum: Projekte & Code Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain


von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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

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

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.

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von eku (Gast)


Lesenswert?

Versuche es gerade unter Linux mit dem avr-gcc. Eine atmel_def.mak 
existiert nicht. Woher kommt die?

von Hc Z. (mizch)


Lesenswert?

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

von eku (Gast)


Lesenswert?

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?

von Karl H. (kbuchegg)


Lesenswert?

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.

von Hc Z. (mizch)


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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 :-)

von neuling (Gast)


Lesenswert?

Hallo,
ich versuche den Bootloader für einen AT90CAN128 zu Kompilieren.
Ich habe im Makefile folgende Änderungen vorgenommmen:
1
MCU = at90can128
2
ATMEL_INC = can128def.inc
3
F_CPU = 16000000
4
CFLAGS += -I . -I ./added -I ./converted -I /opt/avr/include

Wenn ich nun versuche den Bootloader zu kompilieren erhalte ich folgende 
Fehler und Warnungen:
1
$ make
2
./_conv.awk can128def.inc | gawk '/SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
3
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
4
avr-gcc -c -mmcu=at90can128 -DF_CPU=16000000  -I . -I ./added -I ./converted -I /opt/avr/include  \
5
-ffreestanding -gstabs+ -Wa,-adhlns=bootload.lst,-L,-gstabs+ -DRAM_START=0x0100 -DSRAM_SIZE=4096 added/bootload.S -o bootload.o
6
./converted/progmega.inc: Assembler messages:
7
./converted/progmega.inc:38: Warning: constant out of 8-bit range: 65535
8
./converted/progmega.inc:61: Warning: constant out of 8-bit range: 508
9
./converted/password.inc:6: Error: invalid sections for operation on `L0' and `Password'
10
./converted/message.inc:8: Error: invalid sections for operation on `L0' and `Messages'
11
./converted/progmega.inc:38: Error: operand out of range: 65535
12
./converted/progmega.inc:61: Error: operand out of range: 508
13
make: *** [bootload.o] Fehler 1

Hat da einer von euch eine Idee wie ich das lösen kann?

Schonmal Danke

von Hc Z. (mizch)


Lesenswert?

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

von avion23 (Gast)


Lesenswert?

z.B. für den atmega2560 wurde das weiter mit 16bit pointern gelöst. 
Intern hat der PC zwar 17bit. Das oberste Bit wird aber von Hand 
gesetzt. Also hat man zwei Bereiche, an der Trennlinie liegt ein 
Codestück welches das MSB setzt und damit das hochhüpfen in den oberen 
Bereich erlaubt.

Hintergrund ist der, dass der gcc entweder 16bit oder 32bit pointer 
verwendet. 24bit ist nicht. 17bit schon gar nicht. Man hat sich dann 
entschieden, es bei 16bit zu lassen weil man sonst immer 4byte für einen 
pointer bräuchte statt 2byte.


Ohne es mir angesehen zu haben: So etwas könnte man hier mit Sicherheit 
auch einführen.

von Hc Z. (mizch)


Lesenswert?

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.

von Juergen G. (jup)


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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

von Hagen R. (hagen)


Lesenswert?

ändere es in

#if FlashEnd > 0x7FFF

um.

von Hc Z. (mizch)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

1
#if __AVR_HAVE_JMP_CALL__
2
    jmp Application
3
#else
4
    rjmp Application
5
#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:
1
#if __AVR_ARCH__ == 2 || __AVR_ARCH__ == 25 || __AVR_ARCH__ == 4
2
   rjmp Application
3
#else
4
   jmp Application
5
#endif

von Hc Z. (mizch)


Lesenswert?

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.

von Juergen G. (jup)


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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.

von Hendrik P. (endrik)


Angehängte Dateien:

Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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.

von Hendrik P. (endrik)


Lesenswert?

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?

von Hc Z. (mizch)


Lesenswert?

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

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von Juergen G. (jup)


Lesenswert?

@ 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

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von Juergen G. (jup)


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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?

von Juergen G. (jup)


Angehängte Dateien:

Lesenswert?

Die tn85def.inc habe ich aus diesem Thread

Beitrag "tn85def.inc tn84def.inc"

Ju

von Hc Z. (mizch)


Lesenswert?

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

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von Hc Z. (mizch)


Lesenswert?

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.

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von Juergen G. (jup)


Lesenswert?

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

von Werner B. (werner-b)


Lesenswert?

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

Werner

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von Juergen G. (jup)


Lesenswert?

@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

von Hc Z. (mizch)


Lesenswert?

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
1
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
1
make -B
 übersetzen.

von Juergen G. (jup)


Lesenswert?

SUUUUPIIII, das wars.

jetzt tut er wie er soll.

1000000- Dank .

"realy great job"

Ju

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von Martin J. (bluematrix) Benutzerseite


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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

von Martin J. (bluematrix) Benutzerseite


Lesenswert?

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

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von Jochen (Gast)


Lesenswert?

Hallo Leute

ich versuche gerade den Bootloader auf einem ATmega2560 zu installieren. 
Makefile hab ich laut nach README angepasst, make ausgeführt. Versuche 
ich das hex-File zu flashen, gibts aber den folgenden 
verification-Fehler:
1
avrdude -p atmega2560 -P /dev/ttyUSB1 -c stk500v2 -U flash:w:bootload.hex:i -vvv
2
...
3
4
...
5
avrdude: reading on-chip flash data:
6
7
Reading | ################################################## | 100% 64.57s
8
9
avrdude: verifying ...
10
avrdude: verification error, first mismatch at byte 0x1fc00
11
         0xff != 0xf8
12
avrdude: verification error; content mismatch

Was mich stutzig macht, ist der Ort 0x1fc00 -- das ist doch irgendwie in 
der nähe der Bootloadergrenze (0x1fe00) auf welche ich die BOOTSZ-Fuses 
gesetzt hab. Der Output von "make" lautet:
1
Makefile:118: atmel_def.mak: No such file or directory
2
./_conv.awk m2560def.inc | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
3
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
4
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega2560 -DF_CPU=16000000  -I . -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs+ -DRAM_START=0x0200 -DSRAM_SIZE=8192 -DSTX_PORT=PORTE -DSTX=PE1 -DSRX_PORT=PORTE -DSRX=PE0 added/bootload.S -o bootload.o
5
avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega2560 -DF_CPU=16000000  -I . -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs+ -DRAM_START=0x0200 -DSRAM_SIZE=8192 -DSTX_PORT=PORTE -DSTX=PE1 -DSRX_PORT=PORTE -DSRX=PE0 added/stub.S -o stub.o
6
vars="$(./get_bootsection_addrs.sh 0x1ffff 0x1fe00 0x1fc00 0x1f800 )"; \
7
  eval "$vars"; \
8
  sed -e "s/@LOADER_START@/$LOADER_START/g" \
9
      -e s'/@RAM_START@/0x0200/g' \
10
      -e s'/@RAM_SIZE@/8192/g' \
11
      -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
12
      bootload.template.x > bootload.x; \
13
  avr-ld -N -E -T bootload.x -Map=bootload.map \
14
    --cref bootload.o stub.o -o bootload.elf --defsym Application=0
15
LOADER_START=0x3fc00
16
STUB_OFFSET=0x3fe
17
*** Note: set BOOTSZ fuses for the word address 0x1fe00 ***
18
avr-objcopy -O ihex bootload.elf bootload.hex

Versuche ich mit lboot zu flashen, beginnt das Programm mit dem 
Flashvorgang, bricht aber immer bei 85% ab.

Hm, wo mache ich was falsch?

Vielen Danke und beste Grüße

Jochen

von Hc Z. (mizch)


Lesenswert?

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.

von Hc Z. (mizch)


Lesenswert?

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
1
:020000023000CC
2
: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
1
: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.

von Hc Z. (mizch)


Lesenswert?

Übrigens:  Obiges geht auch kürzer.  Mach' mal
1
avr-objdump -h bootload.hex
und schau nach, wo die Flashadressen (VMA oder LMA, sollte beides 
dasselbe sein) sich befinden.

von Jochen (Gast)


Lesenswert?

Hallo

kann beides bestätigen, den Anfang der hex-Datei und das 
nicht-auftauchen der Adresse...

Grüße

von Jochen (Gast)


Lesenswert?

Oh, da war jemand schneller...

hier das Ergebniss:
1
avr-objdump -h bootload.hex
2
3
bootload.hex:     file format ihex
4
5
Sections:
6
Idx Name          Size      VMA       LMA       File off  Algn
7
  0 .sec1         00000400  0003fc00  0003fc00  00000011  2**0
8
                  CONTENTS, ALLOC, LOAD

von Hc Z. (mizch)


Lesenswert?

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.

von Jochen (Gast)


Lesenswert?

Hallo

Oh, das ist eine blöde Diagnose...

Was könnte ich denn mit dem vorhandenen Programmer (stk500v2) noch 
versuchen? Ansonsten würde mir nur bleiben einen neuen Flasher zu 
kaufen?

Das sieht ja schonmal nicht nach einem elektrischen Problem mit dem 
Flasher aus (Kabel defekt oder ähnliches), wegend er runden 
Speicheradresse bei der der Fehler auftritt. Könnte es vielleicht am 
Linux-Treiber liegen? Oder avrdude?

Grüße

von Hc Z. (mizch)


Lesenswert?

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.

von Jochen (Gast)


Lesenswert?

Hi,

der Chip könnte defekt sein? Eieiei...

Könnte ich das testen, in dem ich eine hex-File erstelle welche nur 
0xff's enthält, flashe und wieder auslese? Das auslesen des ganzen 
Flashspeichers zur Zeit geht. Wie finde ich die Adresse 0x1fc00 ?

Habe gerade mal mit Windows und AVR-Studio versucht zu flashen (die 
exakt gleiche hex-Datei). Da sagt er mir direkt "content matches", und 
flashen wäre erfolgreich gewesen. Danach scheint der Controller aber tot 
zu sein,  mit lboot kann ich mich dann auch (wieder unter Linux) nicht 
verbinden.

Flashe ich (erfolglos) mit Linux, verbindet sich lboot beim 
Controller-Reset ja immerhin, bricht dann aber nach einer bestimmten 
Zeit mit einem Fehler ab...

BOOTSZ1 und BOOTSZ0 sind beide auf "unprogrammed" (Bit=1) gesetzt, um 
einen 512byte großen Bootloader anzugeben. Das BOOTRST Bit ist 
"programmed" (Bit=0). Das SPIEN ist auch "programmed" (Bit=0).

Aber vielen Dank schonmal für die Hilfe... Hat mir schonmal was 
gebracht!

Grüße
Jochen

von Hc Z. (mizch)


Lesenswert?

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?

von Jochen (Gast)


Lesenswert?

Hm, ja wenn ich die zweite Zeile im hex lösche, gibts den entsprechenden 
Fehler:
1
avrdude: verifying ...
2
avrdude: verification error, first mismatch at byte 0x1fc10
3
         0xff != 0x60
4
avrdude: verification error; content mismatch

Andere Programme kann ich problemlos flashen, das aktuelle Projekt hat 
14382 bytes (laut avrdude, die hex-Datei ist 40kB groß?). Leider komme 
ich auf die schnelle auch nicht an einen anderen Programmer, also werde 
ich das "Projekt Bootloader" wohl verschieben müssen...

von Hc Z. (mizch)


Lesenswert?

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.

von eku (Gast)


Lesenswert?

Hallo Hc,

habe gerade den Umstieg von 1.7 auf 2.5 gewagt. Was läuft hier schief?

avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega8 -DF_CPU=8000000  -I . 
-I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding 
-gstabs+ -L,-gstabs+ -DRAM_START= -DSRAM_SIZE= -DSTX_PORT=PORTD 
-DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/bootload.S -o bootload.o
./converted/password.inc: Assembler messages:
./converted/password.inc:13: Error: non-constant expression in ".if" 
statement
./converted/message.inc:17: Error: non-constant expression in ".if" 
statement
./converted/message.inc:23: Error: non-constant expression in ".if" 
statement
./added/fastload.inc:73: Error: illegal relocation size: 1
./added/fastload.inc:74: Error: illegal relocation size: 1
./added/fastload.inc:76: Error: illegal relocation size: 1
./added/fastload.inc:77: Error: illegal relocation size: 1
./added/fastload.inc:78: Error: illegal relocation size: 1
./added/fastload.inc:80: Error: illegal relocation size: 1
./added/fastload.inc:81: Error: illegal relocation size: 1
./added/fastload.inc:82: Error: illegal relocation size: 1
make: *** [bootload.o] Fehler 1

von Hc Z. (mizch)


Lesenswert?

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.

von eku (Gast)


Lesenswert?

Hc Zimmerer schrieb:
> 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).

make -B war der entscheidende Hinweis:
_conv.awk fehlte das x-bit


und gleich das nächste Problem:

$ make -B
./_conv.awk 
/home/erik/src/avr/fastboot/avr_gcc/../../avrasm2/defs/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=8000000  -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=8000000  -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
tee: /dev/stderr: Keine Berechtigung
*** Note: set BOOTSZ fuses for the word address 0xf00 ***

get_bootsection_addrs.sh ist neu. Was soll das 'tee /dev/stderr' 
bewirken?

von Hc Z. (mizch)


Lesenswert?

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?

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von eku (Gast)


Lesenswert?

Hc Zimmerer schrieb:
> 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.

( printf... ) öffnet eine Subshell. Nichth so elegant. Nimm doch statt
tee die Ausgabeumleitung nach &2.

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

Linux. Wenn Du /bin/sh reinschreibst bekommst Du auch /bin/sh = Bourne
Shell. Nichts mehr und nicht weniger. Das schränkt zwar ein, bleibt
aber portabel.

von Hc Z. (mizch)


Lesenswert?

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

von Martin J. (bluematrix) Benutzerseite


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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.

von Martin J. (bluematrix) Benutzerseite


Lesenswert?

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

von eku (Gast)


Lesenswert?

Hallo Hc!

Noch eine Bitte fürs Makefile:
bootload.elf und bootload.hex in der clean-Regel löschen.

von Jochen (Gast)


Lesenswert?

Hallo,

Ich bins nochmal, in der Hoffnung an der rechten Stelle zu sein...

nachdem ich meinen avrisp2-Programmer in die Tonne getreten habe und mir 
einen neuen (AVRISPmkII) besorgt habe, klappte das Programmieren des 
Bootloaders. Bin genau nach der Anleitung im Wiki vorgegangen:
1
avrdude -p atmega2560 -P usb -c stk500v2 -U flash:w:"bootload.hex":i -U flash:v:"bootloader.hex":i -y

Leider erhalte ich dann beim Flashen mit lboot trotzdem einen 
CRC-Fehler:
1
./bootloader -v -d /dev/ttyUSB0 -b 115200 -p ../../version0.05/main.hex
2
3
=================================================
4
|           BOOTLOADER, Target: V2.1            |
5
=================================================
6
Port    : /dev/ttyUSB0
7
Baudrate: 115200
8
File    : ../../version0.05/main.hex
9
Reading : ../../version0.05/main.hex... File read.
10
Size    : 3767 Bytes
11
Program and verify device.
12
-------------------------------------------------
13
Waiting for device... connected!
14
Bootloader    : V2.1
15
Target        : 1E9801 
16
Buffer        : 7680 Byte
17
Size available: 261120 Byte
18
CRC enabled and OK.
19
Programming   : 00000 - 00EB7
20
Writing | ##################################################################################################################### | 100%
21
Elapsed time: 0.26 seconds, 14488 Bytes/sec.
22
23
 ---------- Programming failed (wrong CRC)! ----------
24
25
Verify        : 00000 - 00EB7
26
Verifying | ################################################################################################################### | 100%
27
Elapsed time: 0.54 seconds, 6976 Bytes/sec.
28
29
 ---------- Verification failed (wrong CRC)! ----------
30
31
...starting application

Das hier war eine minimal-Version, flashe ich meine komplette Firmware 
bricht lboot sogar nach einer Zeit ab (abhängig von der hex-Datei immer 
an der gleichen Stelle). Das USB-Kabel hab ich auch schon getauscht.

Bedeutet es das mein Flash wirklich defekt ist?

von Hc Z. (mizch)


Lesenswert?

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

von Jochen (Gast)


Lesenswert?

Die gleiche hex-Datei kann ich mit einem ISP ganz normal flashen, schon 
hundertmal gemacht -- läuft auch super. Aber das was im Flash steht, 
wird ja bei der Bootloader installation überschrieben, oder? Danach kann 
ich dann mit lboot nicht zugreifen.

Vielleicht ein Problem mit lboot?

Ich seh ein, das fastboot keine Probleme macht ;-) Vielen Dank für die 
Hilfe...

von Hc Z. (mizch)


Lesenswert?

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.

von F. W. (deichbiker)


Lesenswert?

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!

von Martin G. (mager)


Lesenswert?

Würde der Watchdog Dir helfen?

von Rev (Gast)


Lesenswert?

Martin Gerken schrieb:
> Würde der Watchdog Dir helfen?

Der Watchdog hilft leider nicht weiter wenn das Firmwareupdate 
"mittendrin" unterbrochen wird. Dann ist der Code ja potentiell 
überhaupt nicht mehr lauffähig.

Der Bootloader müsste halt bei Neustart eine Möglichkeit haben zu 
überprüfen ob der Flash-Vorgang erfolgreich war, bzw. ob eine 
funktionsfähige Firmware vorhanden ist.

von Hc Z. (mizch)


Lesenswert?

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.

von F. W. (deichbiker)


Lesenswert?

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.

von F. S. (franke)


Lesenswert?

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.

von Hc Z. (mizch)


Lesenswert?

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.

von paul (Gast)


Lesenswert?

abend...

ich versuche grad einen Bootloader für den atmega8 mit fastboot_build26 
zu erstellen.

aber ich bekomm es nicht hin. und ich hab es eigentlich 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

makefile:118: atmel_def.mak: No such file or directory
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
make.exe: *** No rule to make target `all'.  Stop.

aber in dem ordner fastboot wird doch solch ein ordner erstellt mit 
folgendem inhalt:

SIGNATURE_000 = 0x1e
SIGNATURE_001 = 0x93
SIGNATURE_002 = 0x07
BOOTRST = 0
BOOTSZ0 = 1
BOOTSZ1 = 2
FLASHEND = 0x0fff
SRAM_START = 0x0060
SRAM_SIZE = 1024
***** = BOOTLOADER
PAGESIZE = 32
FIRSTBOOTSTART = 0xf80
SECONDBOOTSTART = 0xf00
THIRDBOOTSTART = 0xe00
FOURTHBOOTSTART = 0xc00
SMALLBOOTSTART = FIRSTBOOTSTART
LARGEBOOTSTART = FOURTHBOOTSTART

was ist daran jetzt falsch?

ich verwende WinAVR mit dem programmers notepad2.

danke für die hilfe
Paul

von Hc Z. (mizch)


Lesenswert?

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

von paul (Gast)


Lesenswert?

mhm... also war meine vermutung richtig...

nur die funktion "make" gibt es sicher nicht im programmer notepad 2 
oder?
ich kann es jedenfalls nciht finden.

da kann ich das ganze also nur mit dem avr studio machen oder? :-(

danke

von Hc Z. (mizch)


Lesenswert?

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

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von paul (Gast)


Lesenswert?

hab ich noch nie so gemacht ...
aber hat geklappt

danke

von Teshima (Gast)


Lesenswert?

Hallo

ich würde sehr gerne wissen mit welchem Compiler die Host-Software für 
windows kompiliert wurde. Da ich es mit MinGW nicht hinbekomme.

Mfg
Teshima

von Hc Z. (mizch)


Lesenswert?

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

von Teshima (Gast)


Lesenswert?

Den teil denn ich in Windows laufen lassen muss um die hex datei zu 
übertragen.

von Hc Z. (mizch)


Lesenswert?

Der Thread mit u.a. der Host-Software befinden sich laut Wiki 
(http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger#Downloads) 
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.

von Paul P. (dorpreuss)


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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

von Paul P. (dorpreuss)


Lesenswert?

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?

von Paul P. (dorpreuss)


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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.

von Paul P. (dorpreuss)


Lesenswert?

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.

von Hc Z. (mizch)


Lesenswert?

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

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

von Paul P. (dorpreuss)


Lesenswert?

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.

von Hc Z. (mizch)


Lesenswert?

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.

von Paul P. (dorpreuss)


Lesenswert?

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.

von Hc Z. (mizch)


Lesenswert?

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.

von Paul P. (dorpreuss)


Lesenswert?

Vielen Dank dafür!

von Hc Z. (mizch)


Lesenswert?

Gefunden.  Als Workaround: Ersetze in bootload.template.x ziemlich am 
Beginn die Zeile
1
OUTPUT_ARCH(avr:2)
durch
1
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.

von Paul P. (dorpreuss)


Lesenswert?

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

von Paul P. (dorpreuss)


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

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.

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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

von Paul P. (dorpreuss)


Lesenswert?

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?

von Hc Z. (mizch)


Lesenswert?

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

von Paul P. (dorpreuss)


Lesenswert?

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

von Paul P. (dorpreuss)


Lesenswert?

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

von Martin J. (bluematrix) Benutzerseite


Lesenswert?

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?

von Hc Z. (mizch)


Lesenswert?

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.

von Martin J. (bluematrix) Benutzerseite


Lesenswert?

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

von Hc Z. (mizch)


Lesenswert?

Martin J. schrieb:
> reicht 1024Byte?

Ja.

von Stefan (Gast)


Lesenswert?

Hi,

Ich habe versucht den Build 27 zu compilieren und bekam dabei den 
folgenden output:

Makefile:121: atmel_def.mak: No such file or directory
./_conv.awk m168def.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=atmega168 -DF_CPU=16000000  -I 
. -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding 
-gstabs+ -L,-gstabs+ -DRAM_START=0x0100 -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=atmega168 -DF_CPU=16000000  -I . 
-I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding 
-gstabs+ -L,-gstabs+ -DRAM_START=0x0100 -DSRAM_SIZE=1024 
-DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/stub.S -o 
stub.o
vars="$(./get_bootsection_addrs.sh 0x1fff 0x1f80 0x1f00 0x1e00 )"; \
        arch="$(avr-gcc -mmcu=atmega168 -### bootload.o  -o x 2>&1 | 
gawk '/\/bin\/ld/ {print $3}')";\
        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@/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
*** Note: set BOOTSZ fuses for the word address 0x1f00 ***
LOADER_START=0x3e00
STUB_OFFSET=0x1fe
avr-ld:bootload.x:18: syntax error
make: *** [bootload.elf] Error 1

an der Zeile 18 im boottload.x steht "OUTPUT_ARCH()"
dort wo der inhalt von $arch stehen sollte steht also nichts...
Was sollte denn eigentlich dessen inhalt sein? MCU? Quell-Architektur? 
Der Befehl ist mir ein bisschen zu lang um ihn zu verstehen... (bin 
nicht gerade fit was bash programmierung angeht :/ )

tatsächlich gibt >> arch="$(avr-gcc -mmcu=atmega168 -### bootload.o  -o 
x 2>&1 | gawk '/\/bin\/ld/ {print $3}')" << eine leere arch variable

Falls ich ein Einzelfall bin kann ich es ja per hand nachtragen

MFG, Stefan

von Hc Z. (mizch)


Lesenswert?

Kannst Du mir den Output der folgenden 2 Kommandos posten?
1
avr-gcc -mmcu=atmega168 -### bootload.o  -o X 
2
avr-gcc --version

von Stefan (Gast)


Lesenswert?

Ersteres:

Using built-in specs.
Target: avr
Configured with: 
/var/tmp/portage/cross-avr/gcc-4.4.3/work/gcc-4.4.3/configure 
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/avr/gcc-bin/4.4.3 
--includedir=/usr/lib/gcc/avr/4.4.3/include 
--datadir=/usr/share/gcc-data/avr/4.4.3 
--mandir=/usr/share/gcc-data/avr/4.4.3/man 
--infodir=/usr/share/gcc-data/avr/4.4.3/info 
--with-gxx-include-dir=/usr/lib/gcc/avr/4.4.3/include/g++-v4 
--host=i686-pc-linux-gnu --target=avr --build=i686-pc-linux-gnu 
--disable-altivec --disable-fixed-point --without-ppl --without-cloog 
--enable-nls --without-included-gettext --with-system-zlib 
--disable-checking --disable-werror --enable-secureplt 
--disable-libmudflap --disable-libssp --disable-libgomp --enable-cld 
--with-python-dir=/share/gcc-data/avr/4.4.3/python --disable-libgcj 
--enable-languages=c,c++ --enable-shared --disable-threads 
--disable-bootstrap --disable-libgomp 
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3 
p1.0'
Thread model: single
gcc version 4.4.3 (Gentoo 4.4.3 p1.0)
COMPILER_PATH=/usr/libexec/gcc/avr/4.4.3/:/usr/libexec/gcc/avr/4.4.3/:/u 
sr/libexec/gcc/avr/:/usr/lib/gcc/avr/4.4.3/:/usr/lib/gcc/avr/
LIBRARY_PATH=/usr/lib/gcc/avr/4.4.3/avr5/:/usr/lib/gcc/avr/4.4.3/../../. 
./../avr/lib/avr5/:/usr/lib/gcc/avr/4.4.3/:/usr/lib/gcc/avr/4.4.3/../../ 
../../avr/lib/
COLLECT_GCC_OPTIONS='-mmcu=atmega168' '-o' 'X'
 "/usr/libexec/gcc/avr/ld" "-m" "avr5" "-Tdata" "0x800100" "-o" "X" 
"/usr/lib/gcc/avr/4.4.3/../../../../avr/lib/avr5/crtm168.o" 
"-L/usr/lib/gcc/avr/4.4.3/avr5" 
"-L/usr/lib/gcc/avr/4.4.3/../../../../avr/lib/avr5" 
"-L/usr/lib/gcc/avr/4.4.3" 
"-L/usr/lib/gcc/avr/4.4.3/../../../../avr/lib" "bootload.o" "-lgcc" 
"-lc" "-lgcc"

Die version ist da zwar ersichtlich aber dennoch:
avr-gcc (Gentoo 4.4.3 p1.0) 4.4.3
Copyright (C) 2010 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.

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

MFG, Stefan

von Hc Z. (mizch)


Lesenswert?

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.

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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

von Stefan (Gast)


Lesenswert?

Danke für die Mühe bei mir wird jetzt jedenfalls die Zielarchitektur 
korrekt erkannt

MFG, Stefan

von Tobias S. (tryan)


Lesenswert?

Hallo,

ich würde gerne den Bootloader für einen ATmega64 verwenden. Leider 
kommt beim Compilieren des Bootloaders folgender Fehler:
1
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/
2
stub.S -o stub.o
3
4
vars="$(./get_bootsection_addrs.sh 0x7fff 0x7e00 0x7c00 0x7800 )"; \
5
    arch="$(./get_avr_arch.sh -mmcu=atmega64 bootload.o)"; \
6
    echo "arch=$arch";\
7
    echo "$vars"; \
8
    eval "$vars"; \
9
    sed -e "s/@LOADER_START@/$LOADER_START/g" \
10
        -e s"/@ARCH@/$arch/" \
11
        -e s'/@RAM_START@/0x0100/g' \
12
        -e s'/@RAM_SIZE@/4096/g' \
13
        -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
14
        bootload.template.x > bootload.x; \
15
    avr-ld -N -E -T bootload.x -Map=bootload.map \
16
      --cref bootload.o stub.o -o bootload.elf --defsym Application=0
17
*** Note: set BOOTSZ fuses to the word address 0x7e00 ***
18
./get_avr_arch.sh: awk: command not found
19
./get_avr_arch.sh: [: =: unary operator expected
20
get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld command line
21
arch=
22
LOADER_START=0xfc00
23
STUB_OFFSET=0x3fe
24
c:\WinAVR-20090313\bin\avr-ld.exe:bootload.x:18: syntax error
25
make: *** [bootload.elf] Error 1
26
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

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von julian (Gast)


Lesenswert?

Ich habe auch ein Problem mit der architecture Erkennung. Mit aktueller 
Version 2.18 sieht der make Output so aus:
1
vars="$(./get_bootsection_addrs.sh 0x3fff 0x3f00 0x3e00 0x3c00 )"; \
2
        arch="$(./get_avr_arch.sh -mmcu=atmega32 bootload.o)"; \
3
        echo "arch=$arch";\
4
        echo "$vars"; \
5
        eval "$vars"; \
6
        sed -e "s/@LOADER_START@/$LOADER_START/g" \
7
            -e s"/@ARCH@/$arch/" \
8
            -e s'/@RAM_START@/0x0060/g' \
9
            -e s'/@RAM_SIZE@/2048/g' \
10
            -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
11
            bootload.template.x > bootload.x; \
12
        avr-ld -N -E -T bootload.x -Map=bootload.map \
13
          --cref bootload.o stub.o -o bootload.elf --defsym Application=0
14
*** Note: set BOOTSZ fuses to the word address 0x3f00 ***
15
./get_avr_arch.sh: Zeile 38: [: =: Einstelliger (unärer) Operator erwartet.
16
get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld command line
17
arch=
18
LOADER_START=0x7e00
19
STUB_OFFSET=0x1fe
20
avr-ld:bootload.x:18: syntax error
21
make: *** [bootload.elf] Fehler 1

Hier die Ausgabe der beiden Befehle:
1
avr-gcc -mmcu=atmega168 -### bootload.o  -o X 
2
Using built-in specs.
3
COLLECT_GCC=avr-gcc
4
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.5.1/lto-wrapper
5
Target: avr
6
Configured with: ../configure --disable-libssp --disable-nls --enable-languages=c,c++ --infodir=/usr/share/info --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr --with-gnu-as --with-gnu-ld --with-as=/usr/bin/avr-as --with-ld=/usr/bin/avr-ld
7
Thread model: single
8
gcc version 4.5.1 20100610 (prerelease) (GCC) 
9
COMPILER_PATH=/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/
10
LIBRARY_PATH=/usr/lib/gcc/avr/4.5.1/avr5/:/usr/lib/gcc/avr/4.5.1/../../../../avr/lib/avr5/:/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/4.5.1/../../../../avr/lib/
11
COLLECT_GCC_OPTIONS='-mmcu=atmega168' '-o' 'X'
12
 "/usr/lib/gcc/avr/4.5.1/collect2" "-m" "avr5" "-Tdata" "0x800100" "-o" "X" "/usr/lib/gcc/avr/4.5.1/../../../../avr/lib/avr5/crtm168.o" "-L/usr/lib/gcc/avr/4.5.1/avr5" "-L/usr/lib/gcc/avr/4.5.1/../../../../avr/lib/avr5" "-L/usr/lib/gcc/avr/4.5.1" "-L/usr/lib/gcc/avr/4.5.1/../../../../avr/lib" "bootload.o" "-lgcc" "-lc" "-lgcc"
1
avr-gcc --version
2
avr-gcc (GCC) 4.5.1 20100610 (prerelease)
3
Copyright (C) 2010 Free Software Foundation, Inc.
4
This is free software; see the source for copying conditions.  There is NO
5
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Idee, woran es hapert?

Gruß,
Julian

von Hc Z. (mizch)


Lesenswert?

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.

von Tobias S. (tryan)


Lesenswert?

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

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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

von julian (Gast)


Lesenswert?

Inzwischen hat meine Distribution auf avr-gcc-4.5.1 stable aktualisiert.
Das Skript funktioniert trotzdem nicht.
Hier die Ausgaben:
1
make
2
Makefile:120: atmel_def.mak: Datei oder Verzeichnis nicht gefunden
3
./_conv.awk m32def.inc | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
4
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
5
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega32 -DF_CPU=12000000  -I . -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs+ -DRAM_START=0x0060 -DSRAM_SIZE=2048 -DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/bootload.S -o bootload.o
6
avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega32 -DF_CPU=12000000  -I . -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs+ -DRAM_START=0x0060 -DSRAM_SIZE=2048 -DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/stub.S -o stub.o
7
vars="$(./get_bootsection_addrs.sh 0x3fff 0x3f00 0x3e00 0x3c00 )"; \
8
        arch="$(./get_avr_arch.sh -mmcu=atmega32 bootload.o)"; \
9
        echo "arch=$arch";\
10
        echo "$vars"; \
11
        eval "$vars"; \
12
        sed -e "s/@LOADER_START@/$LOADER_START/g" \
13
            -e s"/@ARCH@/$arch/" \
14
            -e s'/@RAM_START@/0x0060/g' \
15
            -e s'/@RAM_SIZE@/2048/g' \
16
            -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
17
            bootload.template.x > bootload.x; \
18
        avr-ld -N -E -T bootload.x -Map=bootload.map \
19
          --cref bootload.o stub.o -o bootload.elf --defsym Application=0
20
*** Note: set BOOTSZ fuses to the word address 0x3f00 ***
21
get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld command line
22
arch=
23
LOADER_START=0x7e00
24
STUB_OFFSET=0x1fe
25
avr-ld:bootload.x:18: syntax error
26
make: *** [bootload.elf] Fehler 1
1
avr-gcc -mmcu=atmega32 -### bootload.o  -o X 
2
Using built-in specs.
3
COLLECT_GCC=avr-gcc
4
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.5.1/lto-wrapper
5
Target: avr
6
Configured with: ../configure --disable-libssp --disable-nls --enable-languages=c,c++ --infodir=/usr/share/info --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr --with-gnu-as --with-gnu-ld --with-as=/usr/bin/avr-as --with-ld=/usr/bin/avr-ld
7
Thread model: single
8
gcc version 4.5.1 (GCC) 
9
COMPILER_PATH=/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/
10
LIBRARY_PATH=/usr/lib/gcc/avr/4.5.1/avr5/:/usr/lib/gcc/avr/4.5.1/../../../../avr/lib/avr5/:/usr/lib/gcc/avr/4.5.1/:/usr/lib/gcc/avr/4.5.1/../../../../avr/lib/
11
COLLECT_GCC_OPTIONS='-mmcu=atmega32' '-o' 'X'
12
 "/usr/lib/gcc/avr/4.5.1/collect2" "-m" "avr5" "-o" "X" "/usr/lib/gcc/avr/4.5.1/../../../../avr/lib/avr5/crtm32.o" "-L/usr/lib/gcc/avr/4.5.1/avr5" "-L/usr/lib/gcc/avr/4.5.1/../../../../avr/lib/avr5" "-L/usr/lib/gcc/avr/4.5.1" "-L/usr/lib/gcc/avr/4.5.1/../../../../avr/lib" "bootload.o" "-lgcc" "-lc" "-lgcc"
1
avr-gcc --version
2
avr-gcc (GCC) 4.5.1
3
Copyright (C) 2010 Free Software Foundation, Inc.
4
This is free software; see the source for copying conditions.  There is NO
5
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

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.

von julian (Gast)


Lesenswert?

Danke, make läuft jetzt problemlos durch!

von Jens K. (jens_k56)


Lesenswert?

Hallo,

beim Versuch, den Fastboot (build29) für den ATmega8515 zu kompilieren 
(das Makefile habe ich wie in der Readme beschrieben angepasst), bekomme 
ich leider immer die folgenden Fehlermeldungen:

In file included from ./added/fastload.inc:22,
                 from ./converted/bootload.asm:57,
                 from added/bootload.S:47:
./added/fastload.h:109:1: warning: "BOOTSTART" redefined
In file included from added/bootload.S:30:
./atmel_def.h:6:1: warning: this is the location of the previous 
definition
./added/fastload.inc: Assembler messages:
./added/fastload.inc:76: Error: illegal relocation size: 1
./added/fastload.inc:77: Error: illegal relocation size: 1
./added/fastload.inc:78: Error: illegal relocation size: 1
make: *** [bootload.o] Error 1
Build failed with 1 errors and 2 warnings...

In der atmel_def.h steht nach dem build folgendes:

#define  FLASHEND 0xFFF
#define  SMALLBOOTSTART 0b00111110000000  // (0x0F80) smallest boot 
block is 128W
#define  SECONDBOOTSTART 0b00111100000000  // (0x0F00) 2'nd boot block 
size is 256W
#define  THIRDBOOTSTART 0b00111000000000  // (0x0E00) third boot block 
size is 512W
#define  LARGEBOOTSTART 0b00110000000000  // (0x0C00) largest boot block 
is 1KW
#define  BOOTSTART THIRDBOOTSTART  // OBSOLETE!!! kept for compatibility
#define  PAGESIZE 32  // number of WORDS in a page

Offenbar stört das Define "BOOTSTART" und es fehlen die Defines 
"SIGNATURE_000", "SIGNATURE_001" und "SIGNATURE_002".

Wenn ich testweise die atmel_def.h gegen die ursprüngliche Version aus 
dem Fastload-Archiv austausche und mit dem AVR-Studio nur einen Build 
ausführe, tritt kein Fehler auf. Bei einem Rebuild werden dann die 
atmel_def.mak und die atmel_def.h neu erzeugt und der Fehler tritt 
wieder auf.

Kann mir jemand sagen, was bei der Erzeugung schief läuft?

Jens

von Hc Z. (mizch)


Lesenswert?

Mit dem Mega8515 hat es vermutlich noch niemand probiert.  Die meisten 
Nutzer hier bevorzugen wohl µCs aus der Nach-Napoleonischen Zeit ... :).

Mach mal erst eines:  Lösche den vorhandenen atmel_def.h und starte den 
Make-Vorgang.  Der atmel_def.h wird dann neu gebaut.  Ich bitte um 
Rückmeldung, ob dieselben Fehler auftreten.

Falls ja (gleiches Fehlerbild), schau mal in dem von Dir im Makefile 
eingebundenen m8515def.inc nach dem Symbol SIGNATURE_000, konkret nach 
der Zeile
1
.equ    SIGNATURE_000   = 0x1e
Taucht die dort auf?

von Jens K. (jens_k56)


Lesenswert?

Erstmal vielen Dank für Deine schnelle Antwort! Ich muss wohl mal öfter 
meine Email abrufen ;-)

Wenn ich einen Clean Build mache oder die Datei atmel_def.h manuell 
lösche, wird sie so erzeugt, wie ich sie oben gepostet habe und der 
Fehler tritt auf.

Die m8515def.inc enthält keine Definition des Symbols SIGNATURE_000.

von Hc Z. (mizch)


Lesenswert?

Gut.  Wenn ich mir den von Dir geschriebenen Auszug aus atmel_def.h 
genauer anschaue, scheint mir, dass er nicht von einem originalen 
m8515def.inc von Atmel abgeleitet ist.  Falls das der Fall ist, besorge 
Dir bitte einen originalen.

Vom Hersteller gelieferte Include-Files zu nehmen, sie dann zu 
modifizieren, aber unter gleichem Namen wieder abzulegen, ist (höflich 
ausgedrückt) extrem böse.  Man lädt sich solche Probleme damit ein, und 
die kommen dann auch mit Freuden.  Die hinzugefügten Kommentare und ihr 
Stil¹ scheinen mir darauf hinzudeuten.

Sollte dieser Fall nicht vorliegen, ist die Ursache zwar unklar, aber 
besorge Dir mal einen m8515def.inc von einem aktuellen AVR Studio. 
Damit läuft es durch (eben probiert).

_______________
¹ 'Multiple exclamation marks,' he went on, shaking his head, 'are a 
sure sign of .... usw.

von Jens K. (jens_k56)


Lesenswert?

Es war zwar eine originale Datei von Atmel, aber eine veraltete. Ich 
habe den Fehler gemacht, die m8515def.h aus dem Ordner 
'...AvrAssembler\Appnotes' statt aus dem Ordner 
'...AvrAssembler2\Appnotes' zu verwenden; dabei handelte es sich um die 
Version 1.0 vom 16.04.2002. Mit der aktuellen Version 2.35 vom 
25.02.2010 funktioniert es jetzt.

Vielen Dank nochmal für Deine Unterstützung!

Jens

von Hc Z. (mizch)


Lesenswert?

Ok.  In der nächsten Version wird nochmal im Kommentar betont werden, 
dass es die Version aus AvrAssembler*2* sein muss.  Steht zwar schon da, 
aber Betonung kann nichts schaden.  Vielen Dank für die Rückmeldung.

von julian (Gast)


Lesenswert?

Mal eine kleine Frage: Wenn ich aus meiner uC Anwendung in den 
Bootloader zurückspringen möchte, kann ich das mittels
1
asm("jmp 0x0000"):
machen?

von Hc Z. (mizch)


Lesenswert?

Beim Compilieren wird eine Zeile à la

LOADER_START=0x1e00

ausgegeben.  Zu dieser (Byte-)Adresse musst Du springen.

Es gibt auch andere Möglichkeiten, die vom AVR-Typ abhängen.  Dazu 
gehört auch der jmp 0.  Er geht mit AVRs ohne 
Bootsection/BOOTRST-Fähigkeit, aber nur bei denen.

von julian (Gast)


Lesenswert?

Hm, make hat mir
1
LOADER_START=0x7e00
ausgegeben.

Wenn ich aber ein
1
asm("jmp 0x7e00");
ausführe, scheint der bootloader nicht zu starten. Zumindest kann lboot 
kein device finden. Irgendeine Idee wie ich das prüfen könnte?
Eine Bootmeldung oder so gibt der Loader ja nicht aus, oder?

von Hc Z. (mizch)


Lesenswert?

Hmm.  In dem Moment, in dem Du zum Bootloader springst, läuft da das 
PC-Programm bereits?  Der Bootloader prüft nur sehr kurz, ob sein 
Gegenstück läuft (ein paar 100 ms), um den normalen Restart nicht 
nennenswert zu verzögern.

von julian (Gast)


Lesenswert?

Ja, ich habe das Absetzen des Reset-Commands in das Tool eingebaut.
Würde der Bootloader einfach durchlaufen müsste anschließend ja meine 
Hauptanwendung auch wieder erreichbar sein. Ist sie aber nicht.

von Hc Z. (mizch)


Lesenswert?

Nur ein Verdacht:  Versuch's mal mit „asm volatile("jmp 0x7e00")“.

von Hc Z. (mizch)


Lesenswert?

Es gibt noch eine mögliche Falle:  Verwendest Du den UART in Deinem 
Programm und der Bootloader liegt auf denselben Pins?  Dann musst Du den 
UART-Sender disablen (TXEN weg), denn der Bootloader verwendet Soft-UART 
und kann sonst auf den Pin nicht zugreifen.

von julian (Gast)


Lesenswert?

Ah, der UART war das Problem!
Danke! Jetzt funktioniert es wunderbar!

von julian (Gast)


Lesenswert?

Ich hätte da noch mal eine Frage/Anregung:
Wäre es möglich das Starten der Anwendung nach 300ms zu unterbinden, 
wenn ein an den AVR angeschlossener Taster betätigt wird?
Sprich so lange PINX low ist unabhängig vom Timeout im Bootloader 
verweilen.

Die 300ms können nämlich etwas kurz sein, wenn der AVR hinter einem 
USB/seriell Wandler-hängt der beim Reset getrennt werden muss. Sprich 
man muss innerhalb von 300ms feststellen, dass Device ist jetzt da, und 
die Verbindung aufbauen... Das kann evtl knapp sein.

von Jens K. (jens_k56)


Lesenswert?

Hallo Julian,

schau mal in diesen Beitrag, da ist die Frage schonmal aufgekommen:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Und dann gibt's hier direkt eine Lösung dazu:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Das sollte eigentlich genau das sein, was du suchst.

Gruß,
Jens

von julian (Gast)


Lesenswert?

Perfekt, genau das habe ich gesucht! Danke!

von Jens K. (jens_k56)


Lesenswert?

Hallo,

ich nutze jetzt seit einiger Zeit den fastboot auf dem ATmega8515 und 
bin begeistert davon. Eben wollte ich ihn für einen AT90S8515 
kompilieren und bekomme trotz der entsprechenden Anpassungen im Makefile 
die folgenden Fehlermeldungen beim Kompilieren:

./converted/abaud.inc: Assembler messages:
./converted/abaud.inc:18: Error: illegal opcode movw for mcu at90s8515
./converted/abaud.inc:20: Error: illegal opcode movw for mcu at90s8515
./converted/abaud.inc:21: Error: illegal opcode movw for mcu at90s8515
./converted/abaud.inc:50: Error: illegal opcode movw for mcu at90s8515
./converted/password.inc:13: Error: illegal opcode lpm for mcu at90s8515
./converted/password.inc:13: Error: postincrement not supported
./converted/command.inc:26: Error: illegal opcode movw for mcu at90s8515
./converted/command.inc:47: Error: illegal opcode movw for mcu at90s8515
./converted/message.inc:17: Error: illegal opcode lpm for mcu at90s8515
./converted/message.inc:23: Error: illegal opcode lpm for mcu at90s8515
./converted/message.inc:23: Error: postincrement not supported
./converted/verify.inc:12: Error: illegal opcode lpm for mcu at90s8515
./converted/verify.inc:12: Error: postincrement not supported
./converted/progtiny.inc:8: Error: illegal opcode movw for mcu at90s8515
./converted/progtiny.inc:49: Error: constant value required
./converted/progtiny.inc:50: Error: illegal opcode spm for mcu at90s8515
./converted/progtiny.inc:62: Error: constant value required
./converted/progtiny.inc:63: Error: illegal opcode spm for mcu at90s8515
./converted/progtiny.inc:75: Error: constant value required
./converted/progtiny.inc:76: Error: illegal opcode spm for mcu at90s8515
./converted/uart.inc:17: Error: illegal opcode movw for mcu at90s8515
./converted/uart.inc:66: Error: illegal opcode lpm for mcu at90s8515
./converted/uart.inc:92: Error: illegal opcode movw for mcu at90s8515
./added/fastload.inc:73: Error: illegal relocation size: 1
./added/fastload.inc:74: Error: illegal relocation size: 1
make: *** [bootload.o] Error 1
Build failed with 1 errors and 0 warnings...

Es sieht ja so aus, als wenn ein falscher Befehlssatz für den Prozessor 
verwendet würde. Habe ich irgendeine Einstellung nicht beachtet, oder 
muss ich den Assembler Code auf den entsprechenden Prozessor anpassen?

Jens

von Hc Zimmerer (mizch) (Gast)


Lesenswert?

Hast Du ihn in dem Verzeichnis übersetzt, in dem Du zuvor eine andere 
Version erstellt hast?

Falls ja: „make -B“ aufrufen oder das komplette Paket in ein neues 
Verzeichnis auspacken und dort die andere Version erstellen.

von Jens K. (jens_k56)


Lesenswert?

Ja, zuerst hatte ich den ganzen Ordner mit der ATmega8515-Konfiguration 
kopiert und angepasst. Danach habe ich dann das Paket "fastboot_build29" 
komplett neu ausgepackt und dort die entsprechenden Einstellungen 
vorgenommen, jedoch mit denselben Fehlermeldungen beim Kompilieren. 
"make -B" bringt auch dieselben Fehlermeldungen.

von Hc Z. (mizch)


Lesenswert?

OK.  Ich kenne den at90s8515 nicht.  Was mich stutzig macht, ist, dass 
der laut Assembler-Fehlermeldungen die Befehle lpm und spm nicht kennen 
soll.  Vor ich mich tiefer hineinstürze: Liest hier jemand mit, der ihn 
kennt?  Ist das richtig so?  Ist dann ein Bootloader überhaupt möglich?

von Jens K. (jens_k56)


Lesenswert?

Ich habe gerade mal nachgeschaut; der ATmega8515 ist ja der Nachfolger 
des AT90S8515 mit einigen Verbesserungen und Fehlerbehebungen und es 
wird auch nur noch der ATmega8515 verkauft. Da ich nur noch einen 
einzigen AT90S8515 hier liegen habe, wird es das einfachste sein, in 
Zukunft einfach auf den ATmega zu gehen. Da läuft ja der Bootloader auch 
wunderbar.

von Hc Z. (mizch)


Lesenswert?

Ich denke auch, dass es sich nicht lohnt, da noch Gehirnschmalz zu 
investieren.  Schließen wir das Thema also mit „AT90S8515 geht nicht“ 
ab.

von eku (Gast)


Lesenswert?

Hallo Hc,

ich versuche mit Version 2.9 von 
Beitrag "Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain" den Bootloader für eien 
Tiny45 zum Laufen zu bekommen. Der Tiny45 spring nicht in den 
Bootloader. Beim Vergleich des generiereten bootload.hex mit dem unter 
Windows generierten fällt auf, dass nicht nur der Hexcode ein anderer 
ist, sondern auch der Opcode FC am Beginn des Flashs fehlt:

:020000020000FC

Soweit ich den Bootvorgang des Tinys verstanden habem funktioniert es 
ohne obigen Opcode nicht.

von Hc Z. (mizch)


Lesenswert?

Es fehlt kein Opcode.

Das letzte Byte (Dein „Opcode“ FC) ist immer die Prüfsumme des Records, 
also nie ein Opcode.  Sie trägt zum Inhalt nichts bei.

Der Rest des Records ist vom Typ 2, setzt somit die Segmentadresse, und 
zwar auf 0, was Default ist.  Als Segment-Record erzeugt es ebenfalls 
keinen Opcode.

Die von Dir vermisste Zeile darf also wegfallen, da sie nichts bewirkt 
und von avrasm2 nur automatisch generiert wird.

Solltest Du noch Zweifel haben, frag' mal Google oder die Wikipedia nach 
„Intel Hex“.

von Julian (Gast)


Lesenswert?

Ich bin's mal wieder...
Ich würde die Logik mit der Taste gerne noch etwas erweitern. Wenn die 
Taste mehr als (etwa) 3s gedrückt wurde, soll der Bootloader auch dann 
aktiv bleiben wenn die Taste losgelassen wird. Also so lange bis per 
Befehl die Haupt-Firmware gestartet wird oder das Device resettet wird.
Hat da jemand einen Tipp wie man das realisieren könnte?
Ich hatte gedacht ein zusätzliches Register zu verwenden, auf 10 zu 
initialisieren und per dec bis auf 0 herunterzuzählen. Falls das 
Register 0 ist sollte timeout_btncheck direkt wieder zu abaud springen. 
Aber die Implementierung ist mir bisher nicht geglückt...

Gruß,
Julian

von avion23 (Gast)


Lesenswert?

Hallo zusammen,
ich bekomme den one-wire Modus nicht an's Laufen und weiß auch nicht, wo 
das Problem liegt. Two-wire funktioniert.

Hardware: attiny25 8MHz interner RC-Oszillator, brownout 1,8V, 100nF 
Puffer
USB-Seriell-Wandler: pl2303 China Adapter, max232 entfernt, direkter 
0V-3,3V Pegel
Verschaltung:
TX---[ 1kΩ ]---PB4
RX-------------PB4

Software auf dem PC:
bootloader-1.1.tar.gz aus 
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1927&item_type=project 
und lboot.tgz aus
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Software auf dem µC:
fastboot_build29.tar.gz  aus 
Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain"

Anstatt zu flashen dreht sich nur der Wartebalken, die PC-Seite kommt 
dort auch nie weiter. Baudraten habe ich alles von 60 - 230400 
ausprobiert. Mit dem Oszi habe ich die Leitungen überprüft, der PC 
sendet fleißig und es ist auch wenig Jitter drauf. Der AVR zieht die 
Leitung anscheinend nie nach unten.

Mir ist nicht klar, wo der Fehler liegt.
Ist die GCC-Implementierung des bootloaders grundsätzlich one-wire 
fähig? Wenn ja, hat sie schon einmal bei jemanden funktioniert?

Ist die linux-software one wire fähig? Ich habe im source code nirgends 
die echo-Abfrage gefunden. Nur in protocol.h folgendes:
1
 Erkennung 1-Drahtmodus:
2
3
Es wird geprüft, ob das 1. Zeichen des Paßworts zurück kommt (Echo).
4
Das CONNECT wird gesendet auf der Startflanke des 0xFF.

Gibt es eine neuere Version oder habe ich veraltete Software erwischt? 
Im wiki-Artikel habe ich etwas von Version 2.2 gelesen. Der Link ist 
verstümmelt und ich habe die Version nicht gefunden.

Mit dem two-wire Modus funktioniert es einwandfrei, ich bin ganz 
begeistert. Für Vorschläge wo ich suchen kann bin ich dankbar.

von Bernhard M. (boregard)


Lesenswert?

Hallo,

wenn Du den Max einfach weglässt, und dann direkt verbindest, dürfte der 
One-Wire Modus nicht gehen, weil die Pegel invertiert sind. Deshalb 
antwortet der ATTiny nicht. Evtl. müssten die Pegel im bootloader code 
auch gedreht werden, ich habe das allerdings noch nicht ausprobiert.

Die Linux Version des Bootloaders Du probiert hast kann One-Wire Mode, 
eine neuere Version davon ist 
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" .

Gruß,
Bernhard

von avion23 (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Bernhard,
danke für deine Antwort.

Ich habe jetzt einen ft232 verwendet der die Pegel schon gedreht hat und 
auch die neuere Software. Der Fehler ist der gleiche. Kannst du mir 
sagen, wo ich den Fehler suchen kann? Ich bin komplett ahnungslos.

Der Zweidrahtmodus funktioniert übrigens immer noch einwandfrei. Auf dem 
Oszi sehe ich, dass die Leitung am Anfang konstant high ist und 
zwischendrin immer wieder kurz auf Masse gezogen wird.

Ich habe mal mein lst file angehängt, vielleicht erkennt jemand dadran 
meinen Fehler.

von avion23 (Gast)


Lesenswert?

Bernhard M. schrieb:
> wenn Du den Max einfach weglässt, und dann direkt verbindest, dürfte der
> One-Wire Modus nicht gehen, weil die Pegel invertiert sind.

Wenn ich den Abschnitt richtig verstanden hätte, wäre mir viel Arbeit 
erspart geblieben. Es funktioniert jetzt!
1
;-------------------------------------------------------------------------
2
;                               Macros
3
;-------------------------------------------------------------------------
4
#if ONEWIRE
5
  .macro        IOPortInit
6
        cbi     STX_PORT, SRX           ; for non-inverted logic
7
        ;sbi    STX_PORT, SRX           ; weak pullup on
8
        cbi     STX_DDR, SRX            ; as input
9
  .endm
10
  .macro        TXD_0
11
        sbi     STX_DDR, SRX            ; strong pullup = 0
12
  .endm
13
  .macro        TXD_1
14
        cbi     STX_DDR, SRX            ; weak pullup = 1
15
  .endm
16
  .macro        SKIP_RXD_0
17
        sbic    SRX_PIN, SRX            ; for non-inverted logic
18
        ;sbis   SRX_PIN, SRX            ; low = 1
19
  .endm
20
  .macro        SKIP_RXD_1
21
        sbis    SRX_PIN, SRX            ; for non-inverted logic
22
        ;sbic   SRX_PIN, SRX            ; high = 0
23
  .endm
24
#else
Das Problem war tatsächlich, dass alle Pegel invertiert waren.

Auf dem Weg dorthin habe ich VirtualBox + WinXP auf einem atom notebook 
installiert, um den windows fboot.exe client testen zu können und ~20 
Stunden mich mit assembler code und wild togglenden leds beschäftigt.

Danke für den super bootloader und die Hilfe:
1
./bootloader  -d /dev/ttyUSB0 -b 115200 -p solarLamp.hex 
2
3
=================================================
4
|           BOOTLOADER, Target: V2.1            |
5
|            (Dec 24 2010 20:47:23)             |
6
=================================================
7
Program device.
8
Port          : /dev/ttyUSB0
9
Baudrate      : 115200
10
File          : solarLamp.hex
11
Reading       : solarLamp.hex... File read.
12
Size          : 1086 Bytes
13
-------------------------------------------------
14
Waiting for device... connected (one wire)!
15
Bootloader    : V2.1
16
Target        : 1E930A ATmega88
17
Buffer        : 960 Byte
18
Size available: 7680 Byte
19
CRC enabled and OK.
20
Programming   : 0x00000 - 0x0043D
21
Writing [################################################################################################] 100%
22
Elapsed time  : 0.27 seconds, 4019 Bytes/sec.
23
24
 ++++++++++ Device successfully programmed! ++++++++++
25
26
...starting application

von Juergen G. (jup)


Lesenswert?

Just in case.

und natuerlich als lobendes feedback fuer die Autoren.

Ich hab mich jetzt auch an den ganz kleinen Attiny's mit dem bootloader 
versucht, aktuell den Attiny13A.

Und, es funktioniert ohne Probleme.

Die Eckdaten:
uC : Attiny13A @ 9.6MHz intern RC-Osc
Fuses for dem desaktivieren des Reset
lfuse: 0x7A
hfuse: 0xEF

fastboot_build29.tar.gz

PC Programm fuer den serial upload : bootloader-1.1

OS:
Ubuntu 10.04 (nur Packete aus den offiziellen Quellen)

gcc version :

avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ 
--prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man 
--bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib 
--enable-shared --with-system-zlib --enable-long-long --enable-nls 
--without-included-gettext --disable-checking --disable-libssp 
--build=i486-linux-gnu --host=i486-linux-gnu --target=avr
Thread model: single
gcc version 4.3.4 (GCC)


Hier nochmal ein dickes Danke an die Autoren.

Ju

von robert (Gast)


Lesenswert?

Ich hab da eine ähnliche Frage:
Meine Schaltung hat aus anderen Gründen einen Halbduplex-Eindraht-"Bus", 
der (wegen der höheren Spannungen) über einen Pegelwandler aus 
Transistoren angesteuert wird.
Sieht für den Controller aus wie "normales" 2-Wire, nur dass alles 
gesendete gleichzeitig auch wieder zurückkommt (und natürlich nur 
Halbduplexbetrieb mögich ist). Andere Busteilnehmer sind für den 
Bootloader nicht relevant, weil dann nicht vorhanden.

Nun ergibt sich folgendes Problem, dass der Bootloader (auf 2-Wire Mode 
konfiguriert) damit nicht zurechtkommt.

Testweise mal die Schaltung umgebastelt, so dass der Controller direkt 
mit dem PC verbunden ist, klappt es natürlich (also prinzipiell nichts 
defekt).

Bekommt der PC ein Echo, der Controller aber nicht, meint das Programm 
im 1-Wire Modus zu arbeiten, was dann auch problemlos funktioniert.
Den PC stört das Echo also nicht, und 1-wire->2-wire verträgt sich in 
die Richtung.

Sobald der Controller aber ein Echo bekommt funktioniert nix mehr, die 
PC-Software scheitert an der Erkennung, egal was PC-seitig los ist mit 
der Schnittstelle.

Gibts da eine Lösung?

von Hc Z. (mizch)


Lesenswert?

Versuch mal, in added/fastload.h an der Stelle
1
#if SRX == STX && SRX_PORT == STX_PORT
2
#define  ONEWIRE 3
3
#else
4
#define  ONEWIRE 0
5
#endif
die Zeile
1
#define  ONEWIRE 3  //Force onewire protocol
drunter zu setzen.  Das setzt den Vergleich darüber außer Kraft und 
erzwingt One-Wire-mode für die Software; Sende- und Empfangspins bleiben 
dennoch verschieden.

Einen Versuch ist es wert, Funktionsgarantie kann ich keine geben.

von robert (Gast)


Lesenswert?

Mittlerweile habe ich einen ziemlich ekelhaften Hack zusammengebaut, der 
aber zu funktionieren scheint. Elegant sind die fest definierten Pins 
natürlich nicht. Dazu stellt man in der Makefile irgendwas für RX und TX 
ein, nur eben das gleiche...

Mal so als feature request: Das ganze in "sauber" und zusätzlich 
aktivierbarer Sende/Empfangsumschaltung auf einem dritten Pin hätte 
durchaus nennenswertes Anwendungsgebiet, z.b. für Halbduplex RS485...
Wenn man die Polarität jedes einzelnen Pins noch "sauber" definieren 
könnte wäre das dann optimalst.
1
#if ONEWIRE
2
3
  .macro  IOPortInit
4
  cbi  PORTD, PD0    ; PU disable
5
  cbi  DDRD, PD0    ; RX as input
6
7
  sbi  PORTD, PD1    ; TX high
8
  sbi  DDRD, PD1    ; TX as output
9
  .endm
10
  .macro  TXD_0
11
  cbi  PORTD, PD1    ; TX low = 0
12
  .endm
13
  .macro  TXD_1
14
  sbi  PORTD, PD1    ; TX high = 1 
15
  .endm
16
  .macro  SKIP_RXD_0
17
  sbic  PIND, PD0    ; RX high = 1
18
  .endm
19
  .macro  SKIP_RXD_1
20
  sbis  PIND, PD0    ; RX low = 0
21
  .endm
22
#else

von klaus (Gast)


Lesenswert?

Hallo

Eins vorab , dies ist mein erster versuch mit winavr und avr studio, 
erbarmen ;-), bin Anfänger und programmier bis dato in bascom

- Also im Makefile habe ich alles bis "End user presets" eingestellt
und auch probehalber die Einstellung DEBUG = dwarf-2 eingestellt

- die m16def.ic reinkopiert

- Hab noch das File (get_avr_arch.sh ) mit dieser  : 
Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain" ersetzt

- dann im Avr Studio auf build gedrückt.

?Muß ich noch irgendwo was einstellen, damits richtig kompiliert wird ?

get_avr_arch.sh


Build started 14.2.2011 at 23:20:48
Makefile:120: atmel_def.mak: No such file or directory
./_conv.awk m16def.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=atmega16 -DF_CPU=16000000  -I 
. -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding 
-gdwarf-2 -L,-gdwarf-2 -DRAM_START=0x0060 -DSRAM_SIZE=1024 
-DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 ad
ded/bootload.S -o bootload.o

avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega16 -DF_CPU=16000000  -I . -I 
./added -I ./converted -I/usr/local/avr/include  -ffreestanding 
-gdwarf-2 -L,-gdwarf-2 -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 0x1fff 0x1f80 0x1f00 0x1e00 )"; \
    arch="$(./get_avr_arch.sh -mmcu=atmega16 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@/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
*** Note: set BOOTSZ fuses to the word address 0x1f00 ***
arch=avr5
LOADER_START=0x3e00
STUB_OFFSET=0x1fe
avr-objcopy -O ihex bootload.elf bootload.hex
Build failed with 1 errors and 0 warnings...

von klaus (Gast)


Lesenswert?

hier noch die generierte atmel_def.h


#define  SIGNATURE_000 0x1e
#define  SIGNATURE_001 0x94
#define  SIGNATURE_002 0x03
; ***** BOOT_LOAD ********************
#define  BOOTRST 0  // Select Reset Vector
#define  BOOTSZ0 1  // Select Boot Size
#define  BOOTSZ1 2  // Select Boot Size
#define  FLASHEND 0x1fff  // Note: Word address
#define  SRAM_START 0x0060
#define  SRAM_SIZE 1024
; ***** BOOTLOADER DECLARATIONS 
******************************************
#define  PAGESIZE 64
#define  FIRSTBOOTSTART 0x1f80
#define  SECONDBOOTSTART 0x1f00
#define  THIRDBOOTSTART 0x1e00
#define  FOURTHBOOTSTART 0x1c00
#define  SMALLBOOTSTART FIRSTBOOTSTART
#define  LARGEBOOTSTART FOURTHBOOTSTART

von klaus (Gast)


Lesenswert?

sorry ganz vergessen

ich verwende die version 29  von fastboot
Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain"

von klaus (Gast)


Lesenswert?

hmm ?
ich glaub die Antwort weiter oben ~100 Posts gefunden zu haben, beim 
ersten mal ist das normal weil sie erst erstellt wird??

von klaus (Gast)


Lesenswert?

eine frage hätte ich da noch , kann ich bascom kompilierte hex dateien 
auf einen Atmega mit FASTBOOT29 Bootloader, uploaden ?
wann nicht dann is eh schon wieder ende :-(

von Uwe S. (de0508)


Lesenswert?

Hallo klaus,

warum denn nicht, wenn der Code noch in den AVR passt ?

Du könntest auch eine ASM Datei übersetzen und dann auf einen AVR laden.

Ich verwende jetzt nur noch den Bootloader, entweder im 2-wire mode mit 
FT232RL oder im 1-wire mode mit Adapterkabel auf einen Eigenbau 
USB-RS232 Wandler.

AVR sind atTiny85, atMega32, atMega48, atMega88 und atMega8.

Funktioniert wunderbar..

von klaus (Gast)


Lesenswert?

ohoh ; es geeeeht :-)

von klaus (Gast)


Lesenswert?

Hallo Uwe

Danke übrigens für die Antwort

ja es hat bei mir jetzt auch geklappt, hab ja erst heut nachmittag mitm 
einlesen hier angefangen

es funktioniert jetzt zwar aber n paar dinge muss ich schon noch klären


 wie z.B heisst das passwort immer noch peda oder gibts das überhaupt 
noch
hab hald grad mal schnell windows software zum überspielen von meinem 
programm benutzt und da is alles voreingestellt auch das passwort , also 
jetzt gleich mal das testen :-)

Danke , leider ist mein Grundverständnis in sachen hex, ihex , assembler 
nicht so gut
Ich hoffe aber noch :-)

gruß Klaus

von klaus (Gast)


Lesenswert?

Also Peda gibts noch

Zum Thema software uart

derzeit hab ich ja die original ports im makefile eingstellt lassen aber 
daß is ja meine hardware uart, die benutz ich ja auch anderweitig

Aberr daß kommt sich ja nicht ins gehege da ja mein eigenes  Programm 
zur Laufzeit vom Bootloader  ... uploaden gar nicht läuft

Die SW Uart ist aber schon ne richtige , oder?
man kann also 2 xbeliebige Ports als uart verwenden ?

das werde ich zwar nicht machen aber würde das funktionieren?

das genialste finde ich die 1wire lösung , die werde ich morgen antesten 
:-)


herzlichste grueße an alle die sich an diesem Bootloader beteiligt haben
Danke

von klaus (Gast)


Lesenswert?

da ich bei mir die sache im auto verbaue hab ich einen Ausstand den es 
noch reinzuholen hilt

Wireless RS232

Habe mich schon bei den Zigbit Sachen eingelesen , scheint mir am 
sinnvollsten aber noch ist der Groschen nicht gefallen , vielleicht 
kennt ja jemand noch links ?

grüße

Ps.: Gute Nacht ... und ab in die Heia

von klaus (Gast)


Lesenswert?

oh gott die flasherei ufert etzad aus :-(
so gut geht das jetzt , strom aus , ein ... fertig
morgen brauch ich warsch. einen neuen atmega ;-)

von Juan Pablo C. (juanpablo_c)


Lesenswert?

Hello! I'm trying your bootloader but i'm in trouble...
The bootloader does not compile.
I'm using the fastboot_build29.tar.gz file just that

This is the makes's output:

Makefile:120: 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=8000000  -I . 
-I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding 
-gstabs+ -L,-gstabs+ -DRAM_START= -DSRAM_SIZE= -DSTX_PORT=PORTD 
-DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/bootload.S -o bootload.o
In file included from ./added/fastload.inc:22:0,
                 from ./converted/bootload.asm:57,
                 from added/bootload.S:47:
./added/fastload.h:109:0: warning: "BOOTSTART" redefined
./atmel_def.h:6:0: note: this is the location of the previous definition
avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega8 -DF_CPU=8000000  -I . -I 
./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ 
-L,-gstabs+ -DRAM_START= -DSRAM_SIZE= -DSTX_PORT=PORTD -DSTX=PD1 
-DSRX_PORT=PORTD -DSRX=PD0 added/stub.S -o stub.o
vars="$(./get_text_addrs.sh 0xFFF)"; \
        arch="$(./get_avr_arch.sh -mmcu=atmega8 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@//g' \
            -e s'/@RAM_SIZE@//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="$LOADER_START-2"
*** Last available byte address for the user program: 0x1dfd
get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld 
command line
arch=
LOADER_START=0x1e00
STUB_OFFSET=0x1fe
avr-ld:bootload.x:18: syntax error
make: *** [bootload.elf] Error 1

I'll be waiting for your response...

von Hc Z. (mizch)


Lesenswert?

Looks like you're using an avr-gcc version which is not (yet) known to 
the script.  Which version of avr-gcc are you using?  Please provide the 
output of
1
avr-gcc --version
and (maybe) a few words about where you got it from.  Thanks.

von Juan Pablo C. (juanpablo_c)


Lesenswert?

Hello!
I'm using
avr-gcc (GCC) 4.5.2
from comunity repo of archlinux...

Thanks!

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

Could you please replace your current get_avr_arch.sh in the 
bootloader's directory with the one attached to this article, then run 
'make -B' and post the results (important is the part from 'arch=' until 
'End of test.  Exiting now')?

It may take some time (depending on what I can see from the result, one 
day or so) until I come back as I am quite busy right now, however.

von Juan Pablo C. (juanpablo_c)


Lesenswert?

I think it's running successfully with the atmega324a, with the atmega8 
still doesn't compile...

here is the output from ATMEGA324A:
arch=1: '"/usr/lib/gcc/avr/4.5.2/collect2"'
2: '"-m"'
3: '"avr5"'
4: '"-Tdata"'
5: '"0x800100"'
6: '"-o"'
7: '";#magic1295671ghkl-."'
8: '"crtm324a.o"'
9: '"-L/usr/lib/gcc/avr/4.5.2/avr5"'
10: '"-L/usr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr5"'
11: '"-L/usr/lib/gcc/avr/4.5.2"'
12: '"-L/usr/lib/gcc/avr/4.5.2/../../../../avr/lib"'
13: '"bootload.o"'
14: '"-lgcc"'
15: '"-lc"'
16: '"-lgcc"'
End of test. Exiting now.
LOADER_START=0x7e00
STUB_OFFSET=0x1fe
sed: -e expression #2, char 16: unknown option to `s'
avr-objcopy -O ihex bootload.elf bootload.hex

And with ATMEGA8:
arch=1: '"/usr/lib/gcc/avr/4.5.2/collect2"'
2: '"-m"'
3: '"avr4"'
4: '"-o"'
5: '";#magic1295671ghkl-."'
6: '"/usr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr4/crtm8.o"'
7: '"-L/usr/lib/gcc/avr/4.5.2/avr4"'
8: '"-L/usr/lib/gcc/avr/4.5.2/../../../../avr/lib/avr4"'
9: '"-L/usr/lib/gcc/avr/4.5.2"'
10: '"-L/usr/lib/gcc/avr/4.5.2/../../../../avr/lib"'
11: '"bootload.o"'
12: '"-lgcc"'
13: '"-lc"'
14: '"-lgcc"'
End of test. Exiting now.
LOADER_START=0x1e00
STUB_OFFSET=0x1fe
sed: -e expression #2, char 16: unknown option to `s'
bootload.o: In function `Messages':
(.text+0x1d9): undefined reference to `SIGNATURE_000'
bootload.o: In function `Messages':
(.text+0x1da): undefined reference to `SIGNATURE_001'
bootload.o: In function `Messages':
(.text+0x1db): undefined reference to `SIGNATURE_002'
make: *** [bootload.elf] Error 1

Thanks != cisterns...

von Hc Z. (mizch)


Angehängte Dateien:

Lesenswert?

Things are getting more unclear to me instead of more clear.  Could you 
please do the same again with the attached get_avr_arch.sh?

von Juan Pablo C. (juanpablo_c)


Lesenswert?

OK.

This is with ATMEGA324A

1: '"/usr/lib/gcc/avr/4.5.2/collect2"' '"-m"'
2: '"-m"' '"avr5"'
Match found.
arch=avr5
LOADER_START=0x7e00
STUB_OFFSET=0x1fe
avr-objcopy -O ihex bootload.elf bootload.hex
-----
And this with ATMEGA8

1: '"/usr/lib/gcc/avr/4.5.2/collect2"' '"-m"'
2: '"-m"' '"avr4"'
Match found.
arch=avr4
LOADER_START=0x1e00
STUB_OFFSET=0x1fe
avr-ld:bootload.x:22: syntax error
make: *** [bootload.elf] Error 1

-----

von Hc Z. (mizch)


Lesenswert?

OK. Please try the get_avr_addr.sh from this link: 
[[Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain"]]
If you still get an error in bootload.x, please attach it to your next 
posting.

von Juan Pablo C. (juanpablo_c)


Lesenswert?

Still doesn't compile with atmega8...
---
arch=avr4
LOADER_START=0x1e00
STUB_OFFSET=0x1fe
avr-ld:bootload.x:22: syntax error
make: *** [bootload.elf] Error 1
---
here is the bootload.x:
/*

        bootload.template.x and bootload.x

         Time-stamp: <2010-01-14 21:22:26 hcz>

        Linker script for Peter Dannegger's bootloader.  Always make
        sure you edit bootload.template.x.  Any changes made to
        bootload.x will be overwritten during the next make.

        Symbols enclosed in @ will be replaced when bootload.x is
        generated (see sed part in Makefile).

*/


OUTPUT_FORMAT("elf32-avr","elf32-avr","elf32-avr")
OUTPUT_ARCH(avr4)
MEMORY
{
  text      (rx)   : ORIGIN = 0x1e00, LENGTH = 0x1fe + 2
  bss       (rw!x) : ORIGIN = 0x8000000 + , LENGTH =
}


/* PHDRS { stub PT_LOAD ; } */
SECTIONS
{
  .bss : { *(.bss) } > bss
  . = 0x1e00 ;
  .text : {
    bootload.o(.text)
    /* place a jump to api_call at the very end: */
    . = 0x1fe ;
    stub.o(.text)
  }

 /* Stabs and DWARF debugging sections, taken from 'avr-ld --verbose' 
*/
  .stab 0 : { *(.stab) }
  .stabstr 0 : { *(.stabstr) }
  .stab.excl 0 : { *(.stab.excl) }
  .stab.exclstr 0 : { *(.stab.exclstr) }
  .stab.index 0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment 0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the 
beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info) *(.gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
}


thanks

von Hc Z. (mizch)


Lesenswert?

There is a second problem, which is not related to get_avr_arch.sh. 
Let's continue tomorrow, around evening.

von avion23 (Gast)


Lesenswert?

Hi Juan,
i'm using gentoo with crossdev and gcc-4.5.2. Everything still works 
fine here. I suspect there is something wrong with your installation.

The output of avr-gcc --version:
1
avr-gcc (Gentoo 4.5.2 p1.1, pie-0.4.5) 4.5.2

And here is the output when i compile the projekt with make:
1
Makefile:125: atmel_def.mak: No such file or directory
2
./_conv.awk m8def.inc | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
3
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
4
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega8 -DF_CPU=8000000  -I . -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs+ -DRAM_START=0x0060 -DSRAM_SIZE=1024 -DSTX_PORT=PORTB -DSTX=PB2 -DSRX_PORT=PORTB -DSRX=PB2 added/bootload.S -o bootload.o
5
avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega8 -DF_CPU=8000000  -I . -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs+ -DRAM_START=0x0060 -DSRAM_SIZE=1024 -DSTX_PORT=PORTB -DSTX=PB2 -DSRX_PORT=PORTB -DSRX=PB2 added/stub.S -o stub.o
6
vars="$(./get_bootsection_addrs.sh 0x0fff 0xf80 0xf00 0xe00 )"; \
7
        arch="$(./get_avr_arch.sh -mmcu=atmega8 bootload.o)"; \
8
        echo "arch=$arch";\
9
        echo "$vars"; \
10
        eval "$vars"; \
11
        sed -e "s/@LOADER_START@/$LOADER_START/g" \
12
            -e s"/@ARCH@/$arch/" \
13
            -e s'/@RAM_START@/0x0060/g' \
14
            -e s'/@RAM_SIZE@/1024/g' \
15
            -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
16
            bootload.template.x > bootload.x; \
17
        avr-ld -N -E -T bootload.x -Map=bootload.map \
18
          --cref bootload.o stub.o -o bootload.elf --defsym Application=0
19
*** Note: set BOOTSZ fuses to the word address 0xf00 ***
20
arch=avr4
21
LOADER_START=0x1e00
22
STUB_OFFSET=0x1fe
23
avr-objcopy -O ihex bootload.elf bootload.hex

Just open the makefile and execute the commands by hand. Try to get to 
the part where it fails. Then fix it and / or report. Good luck :)

von Hc Z. (mizch)


Lesenswert?

Suspect files are the defs file from Atmel (m8def.inc) and 
atmel-defs.{h,mak}, if you want to investigate for yourself further. 
More tomorrow.

von Juan Pablo C. (juanpablo_c)


Angehängte Dateien:

Lesenswert?

Here is the m8def.inc i'd use...

The atmel_def.mak says

FLASHEND = 0xFFF
SMALLBOOTSTART = 0b00111110000000
SECONDBOOTSTART = 0b00111100000000
THIRDBOOTSTART = 0b00111000000000
LARGEBOOTSTART = 0b00110000000000
BOOTSTART = THIRDBOOTSTART
PAGESIZE = 32

I suspect that something is missing in the .def file but I do not know 
what...

von Hc Z. (mizch)


Lesenswert?

From the Makefile:
1
# Name of the Atmel defs file for the actual MCU.
2
[...]
3
# Be sure to use AVR Tools\AvrAssembler2\, not  AVR Tools\AvrAssembler\.
Your m8def.inc is the one from AVR Tools\AvrAssembler\.

von Juan Pablo C. (juanpablo_c)


Lesenswert?

Thanks!

With Atmega8 now
arch=avr4
LOADER_START=0x1e00
STUB_OFFSET=0x1fe
avr-objcopy -O ihex bootload.elf bootload.hex

and Atmega324A:

arch=avr5
LOADER_START=0x7e00
STUB_OFFSET=0x1fe
avr-objcopy -O ihex bootload.elf bootload.hex

It's a great bootloader!

von Chris L. (kingkernel)


Lesenswert?

Hat schonmal jemand den Bootloader unter AVR Studio 5 compilieren 
können?

Ich hab gesehen, dass der mega128 unterstützt wird. wird es auch eine 
version für den mega1284 geben?

von Robert (Gast)


Lesenswert?

Hat das Ganze eigentlich schon jemand auf dem Mega48 hinbekommen?
Bei mir will das jedenfalls nicht. mega88 geht, kein Problem.
Beim m48 allerdings:
stub.o: In function `stub':
(.text+0x0): undefined reference to `api_call'
make: *** [bootload.elf] Error 1

Kommentiere ich das entsprechende in der stub.S aus, läuft das durch 
ohne Fehler, der Bootloader auch, nur startet das Userprogramm natürlich 
nie.

von Uwe S. (de0508)


Lesenswert?

Kein Problem, wenn

die passenden ASM Datei für den atmega48.inc da ist und
vorher "make clean" aufgerufen wird.

Die Anpassungen in der Datei makefile setzte ich vorraus !

von Robert (Gast)


Lesenswert?

Uwe S. schrieb:
> und
> vorher "make clean" aufgerufen wird.

Argh, danke!
Da denkt man als IDE-verwöhnter User natürlich nicht dran, dass man das 
ggf. tun sollte...

von Neutrino (Gast)


Lesenswert?

Ich habe diese Version von get_avr_arch.sh 
http://www.mikrocontroller.net/attachment/103485/get_avr_arch.sh und für 
mein Atmega16 diese Datei 
http://www.mikrocontroller.net/attachment/29668/m16def.inc in das 
Verzeichnis des bootloaders runtergeladen. Das kompilieren funktioniert 
nicht und die Ausgabe ist die selbe (außer -mmcu=atmega16) wie avion23 
hier gepostet hat:
Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain"
Ich weiß nicht weiter, kann mir jemand helfen, das avr_arch script 
versteh ich nicht.

Ich benutze archlinux und avr-ld Version 2.21.1 und gcc version 4.6.1

oder hat mir jemand ein fertiges hexfile für den atmega16?

von Adi (Gast)


Lesenswert?

Hi,
 ich würde gerne diesen Bootloader einsetzten, hab hier auch schon 
einiges gelesen, hab aber mittlerweile die Übersicht verloren. zuviel 
verschiedene Versionen, platformen, whatever ...

 Welches ist die aktuelle (stabile) Version) und wo ist sie?



Mein Ziel im moment, den Bootloader in ein Mega16, dann mega8x, später 
auch tiny, .. aber erst mal der 16.
 Ich nutze XP habe AVRstudio, mit dem ich den bootloader dann auch gerne 
erzeugen können möchte. Für C das DEV-C
 Als Programm auf PC seite, ist ein DOS program das in der XP dosbox 
läuft ok.
 Anschluß läuft über USB/V24 kabel dann max auf µ seite.(später möchte 
ich auch die 1 wire ohne max probieren)

 der Downloadlink von 
(http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger)
 Version 2.1 des Bootloaders incl. DOS Host-Software (Forumsbeitrag):
 führt zu irgendwinem log, aber nicht zum dowbload von etwas 
brauchbarem.

Version 2.1 des Bootloaders für AVR-GCC-Toolchain (Forumsbeitrag):
  führt  zu  fastboot_build29.tar.gz hat das irgendwas mit V2.1 zu tun 
klingt irgendwie nach linux ne version 0.0.29 ... also nichts was man 
braucht. (Leute vergebt doch mal brauchbare Namen)

 die letzte version die ich gefunden hab ist fboot18.zip

Wenigstens in dem Artikel sollte doch unter downloads der erste Eintrag 
zu dem richtigen aktuellen Download führen.

von Uwe S. (de0508)


Angehängte Dateien:

Lesenswert?

Hallo Adi,

ich hänge Dir meine Quelle aus diesem Thread an und empfehle diese 
direkt zu übersetzen, da das Makefile einige Konfigurationsparameter 
enthält, die man für seinen Ziel µP. anpassen MUSS.

Weitere Makefiles sind dort enthalten, die schon Anpassungen an meine 
Hardware enthalten.

Viel Erfolg und bitte lese den Thread..

von Marten83 (Gast)


Lesenswert?

Hallo Zusammen,

ich versuche gerade auch den Bootloader ans laufen zu bekommen.
Leider bekommt die fboot.exe keine Verbindung zustande.
Deswegen hier zuerst mein Aufbau und dann Fragen:

ATMega88 mit internen 8Mhz an FTDI Wandler (USART - USB); BS WinXP SP3.
Ich habe den Code aus dem letzten Beutrag hier verwendet und die 
fboot.exe aus Version 1.7 (habe ich sonst nirgens gefunden). Nun stellt 
sich folgende Frage: Ich habe den Bootsector size mal mit 512 und mit 
1024 Wörtern probiert, funktioniert aber nicht (natürlich den entsp. 
Vector aktiviert). Ich hatte dann noch beim start des fboot eine 
Fehlermeldung von Windows, dass ein virtueller Treiber nicht 
initialisiert werden konnte. Habe das versucht zu ignorieren 
(RNBOVDD.dll) und entsprechend gibt es keine Kommunikation.
Hat jemand einen Tipp für mich?

Vielen Dank!

Gruß,

Marten83

von Uwe S. (de0508)


Lesenswert?

hallo,

hast du dir das makefile für den mega88 angepasst?
wie sehen deine fusebits aus?

welche ausgaben liefert der Make-Durchlauf? - Fehlermeldungen.

von Marten83 (Gast)


Lesenswert?

Hi,
 sorry, dass ich so spät wieder antworte.
Die Makefile habe ich nur auf 8Mhz editiert und ein "-" vor das "include 
atmel_def.mak", da er ansonsten gemeckert hat.
Die Fusebits: low 0xE2; high 0xdf; extended 0xfe; lock 0x3f.
Ausserdem habe ich das den FTDI auf Com2 geändert.
Gibt es vielleicht probleme, weil ich bei 8Mhz und 115.2k einen Error 
von 8,5% habe?

MfG, Marten83

von Marten83 (Gast)


Lesenswert?

Hi,

so, habe den Fehler gefunden. Eine Leiterbahn auf meiner Platine 
(natürlich für den USART, wie könnte es anders sein) hatte einen 
Haarriss. Deswegen ist keine Verbindung zustande gekommen.

Aber nochmals zur Sicherheit: Die "section size" habe ich nun auf 256 
Wörter gesetzt. Beim kompilieren kommt aber ein Hinweis: *** Note: set 
BOOTSZ fuses to the word address 0xf00 ***.
Das wären in diesem Fall 1024 Wörter. Mit 256 hats geklappt, deswegen 
gehe ich davon aus, dass das richtig war?

MfG, Marten83

von Micky (Gast)


Lesenswert?

Hallo zusammen,

ich habe heute leider erfolglos versucht den bootloader in Betrieb zu 
nehmen.

AVR Studio 4 gibt folgende Fehlermeldung aus:

Build started 11.12.2011 at 20:12:46
Makefile:120: atmel_def.mak: No such file or directory
./_conv.awk m32def.inc | gawk 
'/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
Der Befehl "." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
make: *** [atmel_def.h] Fehler 255
Build failed with 1 errors and 0 warnings...

Ich verstehe nicht, warum der Befehl "." nicht ausgeführt wird. Kann mir 
jemand bitte helfen?

Danke :-)

Micky

von Uwe S. (de0508)


Lesenswert?

Hallo,

Du mußt mit das Programm 'make' und das Makefile direkt verwenden !

von Micky (Gast)


Lesenswert?

Wenn ich in der DOS-Konsole make eingebe, erhalte ich den gleichen 
Fehler.

ich verwende: GNU Make 3.81

von Stefan E. (sternst)


Lesenswert?

Micky schrieb:
> Der Befehl "." ist entweder falsch geschrieben oder
> konnte nicht gefunden werden.

Das ist eine Fehlermeldung von cmd.exe. Es wird also die falsche Shell 
aufgerufen/ausgeführt.

von Micky (Gast)


Lesenswert?

Hallo Stefan,

ich verstehe deinen Hinweis mit der "falschen Shell" nicht. Liegt es an 
meinem Betriebssystem?

Andere Projekte kann ich problemlos kompilieren. Ich nutze dann aber das 
makefile von AVR Studio. AVR Studio 5 habe ich ebenfalls installiert, 
kann es daran liegen?

von Nils S. (kruemeltee) Benutzerseite


Lesenswert?

Stefan Ernst schrieb:
> Micky schrieb:
>> Der Befehl "." ist entweder falsch geschrieben oder
>> konnte nicht gefunden werden.
>
> Das ist eine Fehlermeldung von cmd.exe. Es wird also die falsche Shell
> aufgerufen/ausgeführt.

"." ist der aktuelle Ordner in dem man sich befindet. Würde sagen, da 
fehlt der Befehl/Programm in dem Ordner, der direkt nach dem Punk mit 
Ordnertrennzeichen angegeben werden muss.

von Stefan E. (sternst)


Lesenswert?

Nils S. schrieb:
> "." ist der aktuelle Ordner in dem man sich befindet. Würde sagen, da
> fehlt der Befehl/Programm in dem Ordner, der direkt nach dem Punk mit
> Ordnertrennzeichen angegeben werden muss.

Nee, für cmd.exe ist der Schrägstrich danach kein Pfad-Trenner, also 
sieht es den Punkt alleine als auszuführendes Kommando. Die 
Kommandozeile muss mit einer Unix-artigen Shell ausgeführt werden.

von Micky (Gast)


Lesenswert?

Verstehe. Die Datei _conv.awk ist aber da. Könnte es aber auch an den 
Übergabeparametern liegen? Wenn einer Falsch oder garnicht definiert 
ist?

Ich muß für heute leider schluß machen. Ich melde mich morgen wieder 
:-). Danke für die bisherige Hilfe!

von Micky (Gast)


Lesenswert?

Hallo Stefan,

bezgl. deiner Unix-Shell. In der Anleitung zu dem Bootloader wird dies 
nicht erwähnt. Eigentlich soll make damit zurechtkommen oder?

von Stefan E. (sternst)


Lesenswert?

Micky schrieb:
> Eigentlich soll make damit zurechtkommen oder?

Make führt die Kommandos aber nicht selber aus. Es übergibt einfach die 
komplette Kommandozeile an eine Shell, und in deinem Fall an die 
falsche. Warum kann ich dir so aus dem Stegreif nicht sagen.

von Nils S. (kruemeltee) Benutzerseite


Lesenswert?

Wenns wirklich an der fehlenden Shell liegt, wäre cygwin wahrscheinlich 
eine Lösung.

Du kannst aber auch den Ordner Zippen, hier im Forum als Anhang 
hochladen und einer der Linux-User wird für dich schnell make tippen.
Ich hätte avr-gcc 4.3.4.

von Stefan E. (sternst)


Lesenswert?

Nils S. schrieb:
> Wenns wirklich an der fehlenden Shell liegt, wäre cygwin wahrscheinlich
> eine Lösung.

Dass sie fehlt ist gar nicht mal gesagt. Sie wird nur einfach nicht 
benutzt. Vielleicht ist z.B. eine Umgebungsvariable SHELL auf cmd.exe 
gesetzt, oder ähnliches. Ich kann so aus dem Stegreif nicht sagen, nach 
welchen Kriterien Make genau ermittelt, welche Shell aufzurufen ist und 
in das Makefile selber kann ich im Augenblick auch nicht rein schauen.

von Stefan E. (sternst)


Lesenswert?

Hier die Make-Doku zu dem Thema:
http://www.gnu.org/s/hello/manual/make/Choosing-the-Shell.html
Geh das doch bitte mal selber durch.
Insbesondere natürlich den Teil unter
> Choosing a Shell in DOS and Windows

von Micky (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Stefan,

anbei der gezippte Ordner. Danke für den Hinweis bezgl. Cygwin. Dies 
schaue ich mir morgen an. Heute geht es bei mir leider nicht mehr.

von Micky (Gast)


Lesenswert?

>Hier die Make-Doku zu dem Thema:
>http://www.gnu.org/s/hello/manual/make/Choosing-th...
>Geh das doch bitte mal selber durch.
>Insbesondere natürlich den Teil unter

Danke für den Link! Ich schaue ihn mir morgen an!

von Micky (Gast)


Lesenswert?

Stefan Ernst schrieb:
> Hier die Make-Doku zu dem Thema:
> http://www.gnu.org/s/hello/manual/make/Choosing-th...
> Geh das doch bitte mal selber durch.
> Insbesondere natürlich den Teil unter
>> Choosing a Shell in DOS and Windows

Danke Stefan! Daran lag es.

von Anon Y. (avion23)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,
seit gcc-4.6 (unsicher) und gcc-4.7 kann ich den bootloader nicht mehr 
verwenden. Eine gefixte get_avr_arch.sh ist angehängt.

Ein
1
./get_avr_arch.sh -x -mmcu=attiny85 bootload.o
 liefert bei mir immer
1
 get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld command line
 Um heraus zu finden, was da nicht funktioniert habe ich mir die 
Ausgaben von avr-gcc in den verschiedenen Versionen angesehen:
1
 "/usr/libexec/gcc/avr/4.5.2/collect2" "-m" "avr25" "-o" ";#magic1295671ghkl-."
2
"/usr/lib/gcc/avr/4.5.2/../../../../avr/lib/crttn85.o"
3
"-L/usr/lib/gcc/avr/4.5.2" 
4
"-L/usr/lib/gcc/avr/4.5.2/../../../../avr/lib"
5
"bootload.o" "-lgcc" "-lc" "-lgcc"
6
7
 /usr/libexec/gcc/avr/4.7.0/collect2 -m avr25 -o ";#magic1295671ghkl-."
8
/usr/lib/gcc/avr/4.7.0/../../../../avr/lib/crttn85.o 
9
-L/usr/lib/gcc/avr/4.7.0
10
-L/usr/lib/gcc/avr/4.7.0/../../../../avr/lib 
11
bootload.o -lgcc -lc -lgcc

Wie man sehen kann sind die \" der große Unterschied. Das skript habe 
ich "gefixt" in dem ich es hart auf neue gcc-Versionen umgebaut habe. 
Auf eine Versionsunterscheidung habe ich nach dieser Shell-Orgie keine 
Lust mehr; wer will kann es gerne einbauen. Hier noch das diff. Viel 
Spaß damit:
1
--- get_avr_arch.sh.backup      2012-05-28 11:40:35.851776973 +0200
2
+++ get_avr_arch.sh     2012-05-28 12:57:39.953442806 +0200
3
@@ -39,9 +39,12 @@
4
 magic=";#magic1295671ghkl-."
5
 # call gcc, asking it for the command line which it would use for
6
 # linking:
7
-set -- $(avr-gcc -m"$mcu" -### "$1" -o "$magic" 2>&1 \
8
-         | gawk '/^avr-gcc:/||/"-m".*'"$magic"'.*"-lgcc"/')
9
-
10
+# old command for <= gcc-4.5*
11
+#set -- $(avr-gcc -m$mcu -### "$1" -o "$magic" 2>&1 \
12
+#         | gawk '/^avr-gcc:/||/"-m".*'"$magic"'.*"-lgcc"/')
13
+# new command for > gcc-4.5*    
14
+set -- $(avr-gcc -m$mcu -### "$1" -o "$magic" 2>&1 \
15
+         | gawk '/^avr-gcc:/||/-m .*'"$magic"'.*-lgcc/')
16
 if [ "$1" = "avr-gcc:" ]; then
17
     # we have an error message from gcc:
18
     echo "$*"
19
@@ -51,7 +54,10 @@
20
 # retrieve architecture argument from gcc's commandline (the argument
21
 # which follows '"-m"'):
22
 while [ -n "$2" ]; do
23
-    if [ "$1" = '"-m"' ]; then
24
+# old command for <= gcc-4.5*
25
+#    if [ "$1" = '"-m"' ]; then
26
+# new command for > gcc-4.5*    
27
+    if [ "$1" = '-m' ]; then
28
        eval echo $2            # eval: remove quotes
29
        exit 0
30
     fi
31
@@ -59,4 +65,4 @@
32
 done
33
 echo >&2 "\
34
 $pname: Could not find an architecture in avr-gcc's internal ld command line"
35
-exit 1
36
\ No newline at end of file
37
+exit 1

von Anon Y. (avion23)


Angehängte Dateien:

Lesenswert?

Murphy fordert seinen Tribut: In der obigen Datei ist eine 
auskommentierte Zeile vom Debuggen übrig geblieben. Die habe ich jetzt 
gelöscht.

von pedro f. (healthhazard)


Lesenswert?

Hallo!

Ich habe ein Problem mit dem Bootloader Build 29 auf einem atmega48.

Ich benötige den Resetpin als IO und möchte deswegen einen Bootloader 
verwenden.

Bootloader ist geflasht. Noch habe ich den Reset nicht deaktiviert, also 
kann ich nach jedem Reset mein Programm hochladen (auch mehrmals). Wenn 
ich jetzt die Stromversorgung trenne, kann ich nach dem Wiederverbinden 
mein Programm nicht wieder hochladen - auch nach einem Reset nicht. Wenn 
ich jetzt den Bootloader nochmal neu flashe geht das Ganze wieder.
Ab und zu geht auch nach Strom aus-an ein Hochladen, aber eben sehr 
selten und nicht reproduzierbar.
Woran könnte es liegen?
Wenn es nach einem Reset durch drücken eines Reset-Buttons geht, kann ja 
auch mein Programm den Bootloader nicht überschreiben und wenn er nicht 
überschrieben ist, müsste er doch nach Aktivierung der Stromversorgung 
auch noch funktionieren....

Ich bin langsam echt ratlos... und es muss doch funktionieren, sonst 
würde der Bootloader ja iwie seinen Sinn verfehlen....

Vielen Dank schon mal im Voraus,
hhazard

von Kai (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich habe Probleme mit dem FastBoot 
Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain" auf einem Mega88.
FastBoot kompiliert problemlos. Das übertragen des Bootloaders, auf den 
AVR funktioniert auch. Ich habe mittlerweile wohl jeden Beitrag hier im 
Forum gelesen und vermutlich auch alle Tips ausprobiert, die ich 
gefunden habe, aber ich komme zu keinem Ergebnis.

Ich kann KEINE Firmware, mit dem Bootloader, vollständig übertragen.
Ich verwende dieses Tool 
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644", da "fboot.exe" aus 
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" unter Win7 (64Bit) bei 
mir mit einem Fehler, mit dem ungefähren Wortlaut, "Ungültige 
16Bit-Anwendung" abbricht.

Der Flashvorgang bricht bei 67% ab (Hex-File erzeugt mit AVRStudio6).
Wenn ich meine Firmware mit dem unten genannten avr-gcc erzeuge bricht 
der Flash-Vorgang bei 68% ab.

Der Bootloader startet darauf nicht mehr und muss neu geflashed werden. 
Unten habe ich die Ausgabe des Tools eingefügt.
Im Anhang habe ich "bootload.lst" beigefügt.

Ich verwende als Verbindung UART per Bluetooth (BTM-222) und 19200 Baud. 
Andere Baudraten ergeben keinen Unterschied. Die Bluetooth-Verbindung 
ist mit der eigentlichen Firmware bei 19200 Baud voll funktionstüchtig.

Die Firmware, welche ich übertragen möchte, funktioniert vollständig, 
wenn ich diese direkt (ohne FastBoot) auf den AVR übertrage.

Ich habe das Makefile folgendermaßen angepasst:
F_CPU=8000000
MCU=atmega88.
ATMEL_INC = m88def.inc

Die Fuses des m88:

Low: 0xE2
High: 0xDF
Ext: 0x04

Ich würde mich freuen wenn Ihr mir helfen könntet! Ich sehe leider nicht 
was das Problem ist oder was ich falsch mache.

Vielen Dank!

Grüße
Kai

-----------------------------------

Ausgabe von MAKE:

$ make
Makefile:120: atmel_def.mak: Datei oder Verzeichnis nicht gefunden
./_conv.awk m88def.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=atmega88 -DF_CPU=8000000  -I . 
-I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding 
-gstabs+ -L,-gstabs+ -DRAM_START=0x0100 -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=atmega88 -DF_CPU=8000000  -I . -I 
./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ 
-L,-gstabs+ -DRAM_START=0x0100 -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 )"; \
arch="$(./get_avr_arch.sh -mmcu=atmega88 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@/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
*** Note: set BOOTSZ fuses to the word address 0xf00 ***
arch=avr4
LOADER_START=0x1e00
STUB_OFFSET=0x1fe
avr-objcopy -O ihex bootload.elf bootload.hex



AVR-GCC:

avr-gcc -v
Using built-in specs.
Target: avr
Configured with: 
/opt/tools/ptxdist/OSELAS.Toolchain-1.99.3.6/platform-avr-gcc-4.4.4-libc 
-1.7.0-binutils-2.20.1/build-cross/gcc-4.4.4/configure  --target=avr 
--enable-multilib --disable-__cxa_atexit --enable-sjlj-exceptions 
--disable-nls --disable-decimal-float --disable-fixed-point 
--disable-win32-registry --enable-symvers=gnu 
--with-pkgversion=mwehr_avr_toolchain 
--with-gmp=/opt/tools/ptxdist/OSELAS.Toolchain-1.99.3.6/platform-avr-gcc 
-4.4.4-libc-1.7.0-binutils-2.20.1/sysroot-host 
--with-mpfr=/opt/tools/ptxdist/OSELAS.Toolchain-1.99.3.6/platform-avr-gc 
c-4.4.4-libc-1.7.0-binutils-2.20.1/sysroot-host 
--prefix=/opt/mwehr_avr_toolchain/avr/gcc-4.4.4-libc-1.7.0-binutils-2.20 
.1  --enable-languages=c,c++ --enable-threads=single --enable-c99 
--enable-long-long --enable-libstdcxx-debug --enable-profile 
--disable-shared --disable-libssp --enable-checking=release
Thread model: single
gcc version 4.4.4 (mwehr_avr_toolchain)



Ausgabe von "bootloader":

=================================================
|           BOOTLOADER, Target: V2.1            |
=================================================
Port    : /dev/rfcomm0
Baudrate: 19200
File    : ../../firmware/Debug/main.hex
Reading : ../../firmware/Debug/main.hex... File read.
Size    : 1389 Bytes
Program device.
-------------------------------------------------
Waiting for device... connected!
Bootloader    : V2.1
Target        : 1E930A ATmega88
Buffer        : 960 Byte
Size available: 7680 Byte
CRC enabled and OK.
Programming   : 00000 - 0056D
Writing | ############################# |  67%
 ---------- Failed! ----------

 ---------- Programming failed! ----------

...starting application

von Bernhard M. (boregard)


Lesenswert?

Hallo Kai,

hast Du mal eine andere / höhere Baudrate versucht? Mit 8 MHz laufen bei 
mir 115200 Baud zuverlässig.

Gruß,
Bernhard

von pedro f. (healthhazard)


Lesenswert?

Hey!
ich hab nochmal ein paar Facts zu meinem Problem, vll kann mir ja dann 
wer helfen.

Atmega48 @20Mhz

    -> FUSES: EXTENDED: 0xFE
              HIGH:     0xDF
              LOW:      0xDE

Bootloader geflashed -> Verify OK

Programm mit AVR-Studio 4 gebaut und einfach geladen (Programm 
funktioniert, wenn man es direkt ohne Bootloader flashed) -> Flash 
Verify (Bootloader) OK

Reset, erneutes hochladen des Programms -> Flash Verify (Bootloader) OK

soweit alles in Ordnung, aber sobald ich jetzt die Stromversorgung 
trenne und wieder verbinde kann ich nichts mehr hochladen

ein Flash Verify des Bootloaders bringt dann folgende Fehlermeldung:
   "WARNING: FLASH byte address 0x0F00 is 0xFF (should be 0x68).. 
FAILED!"

....so wars zumindest bis jetzt immer, aber nachdem ich das nochmal 
genau so reproduzieren wollte konnte ich 2 mal mein Programm nach 
Stromverbindung aus-an hochladen...aber dann wieder genau des selbe 
Fehler.

ich nehme mal an, dass 0x0F00 noch im Bootloader ist, sonst würde ja 
kein Fehler beim Verify auftreten...wieso wird also irgendwann der 
Bootloader überschrieben?
Liegt es vll am Atmega48, weil er keinen richtigen Bootloader-Support 
hat?

Ich kann auch noch mein HEX-File hochladen, wenn das bei der Fehlersuche 
helfen würde.

Vielen Dank im Voraus,
hhazard

von Tueftler (Gast)


Lesenswert?

Memo an mich selbst und evtl. auch andere:

Als Bootloader für Attiny84 den gleichen Code benutzen wie für Attiny85, 
hat gleiches Speicherlayout, Registeraddressierung etc....
Bootloader funktioniert nicht, wenn tn84def.inc genutzt und ATtiny84 im 
Makefile eingestellt werden.

von Pascal R. (pascal_r)


Lesenswert?

Cool, mit den Änderungen von avion23 an get_avr_arch.sh funktioniert das 
kompilieren auch mit dem avr-gcc v4.8.2 auf meinem Ubuntu 14.04 LTS. Ich 
habe hier einige Tests mit einem ATmega164PA gemacht, der jetzt per UART 
von einem Raspberry Pi mit FBoot-Linux geflashed werden kann. Dazu sind 
nur die RX,TX Pins (und GND, über bustreiber und seriellem Kabel) 
verbunden.

Soll ich mal nen Git Repository auf Github erstellen, indem die Updates 
hier zusammenlaufen können? Hat mich schon ne ganze Weile beschäftigt, 
hier zusammenzusuchen, welche Dateien ich als Update noch runterladen 
könnte.

Der Rest war dann mega einfach. Vielen Dank an die Beteiligten!

von Konrad S. (maybee)


Lesenswert?

Pascal R. schrieb:
> Soll ich mal nen Git Repository auf Github erstellen

Ja, oder hier auf dem SVN-Server.

von flo (Gast)


Lesenswert?

Hallo Zusammen.

Zuerst einmal: Cooles Projekt!
Ich finde es super dass sich so viele Leute Zeit nehmen sowas auf die 
Beine zu stellen.

Leider habe ich ein paar Probleme:

Einstellungen:

Version: fastboot-2.9_110804.zip

MCU: Atmega8

avr-gcc --version:
1
 avr-gcc (GCC) 4.8.1

Output:
1
fastboot-2.9 % make -f Makefile-m8
2
vars="$(./get_text_addrs.sh 0xFFF)"; \
3
  arch="$(./get_avr_arch.sh -mmcu=atmega8 bootload.o)"; \
4
  echo "arch=$arch";\
5
  echo "$vars"; \
6
  eval "$vars"; \
7
  sed -e "s/@LOADER_START@/$LOADER_START/g" \
8
      -e s"/@ARCH@/$arch/" \
9
      -e s'/@RAM_START@//g' \
10
      -e s'/@RAM_SIZE@//g' \
11
      -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
12
      bootload.template.x > bootload.x; \
13
  avr-ld -N -E -T bootload.x -Map=bootload.map \
14
    --cref bootload.o stub.o -o bootload.elf --defsym Application="$LOADER_START-2"
15
*** Last available byte address for the user program: 0x1dfd
16
arch=avr4
17
LOADER_START=0x1e00
18
STUB_OFFSET=0x1fe
19
avr-ld:bootload.x:22: syntax error
20
make: *** [bootload.elf] Error 1

Inhalt von bootload.x an der entsprechenden Stelle:
1
19: MEMORY
2
20: {
3
21:  text  (rx)   : ORIGIN = 0x1e00, LENGTH = 0x1fe + 2
4
22:  bss   (rw!x) : ORIGIN = 0x8000000 +, LENGTH =
5
23: }

Also in Zeile 22:
fehlen einmal die Laenge und nachdem Offset (0x800000) noch der Wert der 
aufaddiert werden sollte.

Kann mir jemand sagen woran es liegt, dass diese nicht geschrieben 
werden?

/Flo

von Uwe S. (de0508)


Angehängte Dateien:

Lesenswert?

Hallo,

hier ist ein Update zum Post: 
www.mikrocontroller.net/topic/146638#2340593

von Kevin (Gast)


Lesenswert?

Hallo,

ich versuche gerade den Bootloader auf einem Amtega128 zum laufen zu 
bekommen.
Version 2.9
Alles gemacht wie im Readme beschrieben.
Was muss in die atmel_def.h??

Ausgabe in Atmel Studio:
------ Build started: Project: bootload, Configuration: Debug AVR ------
Build started.
Project "bootload.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; 
('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\ATMEL\Atmel Studio 
6.1\Vs\Compiler.targets" from project "E:\Projekte\__Atmel Studio 
Libs\Fast Boot\fastboot-2.9-140709\fastboot-2.9\bootload\bootload.cproj" 
(target "Build" depends on it):
  Task "RunCompilerTask"
    C:\Program Files (x86)\ATMEL\Atmel Studio 6.1\shellUtils\make.exe -C 
"E:\Projekte\__Atmel Studio Libs\Fast 
Boot\fastboot-2.9-140709\fastboot-2.9" -f "Makefile" -B
    make: Entering directory `E:/Projekte/__Atmel Studio Libs/Fast 
Boot/fastboot-2.9-140709/fastboot-2.9'
    ./_conv.awk m128def.inc | gawk 
'/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
    Der Befehl "." ist entweder falsch geschrieben oder
    konnte nicht gefunden werden.
    make: *** [atmel_def.h] Error 255
    make: Leaving directory `E:/Projekte/__Atmel Studio Libs/Fast 
Boot/fastboot-2.9-140709/fastboot-2.9'
  Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "bootload.cproj" -- FAILED.
Done building project "bootload.cproj" -- FAILED.

Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped 
==========

von Chris (Gast)


Lesenswert?

flo schrieb:
> Kann mir jemand sagen woran es liegt, dass diese nicht geschrieben
> werden?

@Flo:
Ich hatte mit ähnlichen Problemen wie Du zu kämpfen, allerdings unter 
opensuse 13.1 mit avr-gcc 4.8.3 .
Ich konnte den Bootloader letztendlich problemlos kompilieren unter 
Ubuntu 12.04.5 Desktop 32bit, welche es nach wie vor noch zum Download 
auf ubuntu.com gibt. Man muss sich das Ubuntu nicht mal installieren, 
das geht auch mit dem von der Scheibe gestarteten Linux, die benötigten 
Pakete für das Fastboot lassen sich auch so installieren.

@all:
Ich konnte mir den erzeugten Bootloader zwar mit avrdude auf den Atmega8 
schieben, aber mit dem UpdateLoader von Leo Andres keine Verbindung 
herstellen. Da ich mit den AVRs noch ganz "frisch" bin, vermute ich mal, 
daß meine Fuses nicht stimmen ( Atmega8 14,74 Mhz , Low: 0xE1 High: 
0xDC). Sind meine Fuses richtig oder falls nicht mir jemand sagen, wie 
sie denn richtig wären?
Viele Grüße
Chris

von Werner (Gast)


Lesenswert?

Hallo,
ich will den Bootloader für einen Mega2560 verwenden, und zum Flashen 
den Updateloader 2.2.
Nun kann ich den Bootloader installieren, aber keine Files flashen die 
für den Mega2560 sind. Da sagt der Updateloader immer Checksum error. 
Hexfile ist 180kB groß.
Andere Files kann ich raufspielen, da kommt zwar die Meldung dass die 
Prüfsumme des Kontrollers nicht passt, aber dann werden alle Daten 
übertragen.
Verwende AVR Studio 6.2.
Kann der UpdateLoader nicht mit dem Mega2560?
Gibt es ein anderes passendes Flash Tool unter Windows?

LG!

von Nils E. (yetanotheruser)


Lesenswert?

Hat jemand mal den Bootloader mit einem 328P ausprobiert?

Die atmel/m328Pdef.inc fehlte, mit der von AVR Studio 4.18 assembliert 
er fehlerfrei und lässt sich genau 1 x programmieren. Danach wird der 
Bootloader nicht mehr gefunden.

Mit dem 1284P funktioniert alles prima.

von Uwe S. (de0508)


Lesenswert?

Hallo,

na wenn die Datei m328Pdef.inc fehlt, kannst Du auch den Bootloader 
übersetzen.

Bei mir läuft der auf verschiedenen atmega und attiny einwandfrei.

Man muss auch die Fusebits für den Bootloader "Modus" richtig setzten.

von Nils E. (yetanotheruser)


Lesenswert?

Jetzt klappt's auch mit dem m328P: es lag tatsächlich doch an den Fuses.

Ich hatte zwar die richtige Boot Flash section size ausgewählt, aber 
BOOTRST nicht auf 0 gesetzt. Beim Engbedded AVR Fuse Calculator muss man 
dazu das Häkchen setzen bei "Boot Reset vector Enabled (default 
address=$0000); [BOOTRST=0]".

Vielen Dank für die Hilfe!

von clonephon82 (Gast)


Lesenswert?

War jemand schon erfolgreich mit dem Atmel Studio 6.2 und Windows 7?

thx
mathias

von Merlin (Gast)


Lesenswert?

Hallo,
Ich versuche diesen Bootloader unter OSX 10.10 zu kompilieren, was mir 
bisher jedoch nicht gelungen ist.
Installiert habe ich CrossPack for AVR 
(http://obdev.at/products/crosspack/index.html) Kompilieren von 
C-programmen und programmieren des AVR mit AVRDude und USBasp 
funktioniert einwandfrei.

Wenn ich versuche den Bootloader zu kompilieren, schlaegt es leider 
fehl.
Aktuell versuche ich mich an der 2.9 aus diesem Thread. Andere versionen 
gaben die selben fehler.

bekomme ich die folgende ausgabe:

~/G/P/A/fastboot ❯❯❯ make all -B 
⏎
./_conv.awk atmel/m32def.inc | gawk 
'/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
/bin/bash: ./_conv.awk: /usr/bin/gawk: bad interpreter: No such file or 
directory
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega32 -DF_CPU=14745600 -I . 
-I ./added -I ./converted -I /usr/local/avr/include -I 
/usr/local/CrossPack-AVR-20131216/bin -ffreestanding -gstabs+ 
-L,-gstabs+ -DRAM_START=0x0060 -DSRAM_SIZE=2048 -DSTX_PORT=PORTD 
-DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/bootload.S -o bootload.o
./converted/password.inc: Assembler messages:
./converted/password.inc:13: Error: non-constant expression in ".if" 
statement
./converted/message.inc:17: Error: non-constant expression in ".if" 
statement
./converted/message.inc:23: Error: non-constant expression in ".if" 
statement
Makefile:182: recipe for target 'bootload.o' failed
make: *** [bootload.o] Error 1



Die Fehler in der Password.inc und message.inc entstehen in folgenden 
Linien:
1) XLPM  r0, z+
2) XLPM  yl, z
3) XLPM  a0, z+


Ich verstehe leider nicht, woran dies liegen koennte.
Jemand eine Idee?
Hat jemand diesen Bootloader unter OSX kompilieren koennen?

Merlin

von Hans (Gast)


Lesenswert?

Hallo Merlin,

nun Dir fehlen ein paar Shell Tools, u.a. gawk und der Assembler will 
auch nicht.

Welchen Compiler verwendest Du ?

von Merlin (Gast)


Lesenswert?

Hallo Hans,

gawk habe ich bereits installiert, Version 4.1.0 API 1.0
avr-gcc ist in der Version 4.8.1 (GCC) installiert

Danke fuer den Tipp mit dem Assembler, ich werde gleich mal versuchen 
mich etwas schlauer zu machen. Ich bin bisher davon ausgegangen dass 
dieser teil vom avr-gcc ist.

von Merlin (Gast)


Lesenswert?

Hallo nochmals Hans,
Dein Kommentar hat mich in die richtige Richtung gebracht, mir fehlte 
wohl die avr-libc. Mit HomeBrew installiert, und mit der letzten 
get_avr_arch.sh hier hat das Kompilieren nun geklappt.

Der Test auf dem AVR kommt dann spaeter zu Hause.

Vielen dank!
Merlin

von Axel (Gast)


Lesenswert?

Hallo in die grosse Runde,

um nicht alle Fehler zu wiederholen, war war mein Plan das gesamte 
Bootloaderprojekt von Uwe S. einfach mal durchlaufen zu lassen. Auch 
wenn ich spatter einen anderen Prozessor verwenden möchte, sollte es 
doch mit den Beispieldaten funktionieren.

Hier mein Weg zum Fehler: Ich habe

a) die original fastboot-2.9_110804.zip in das ein Verzeichnis 
D:\bootload entpackt.

b) im Makefile lediglich DEBUG = dwarf-2 geändert, weil ich AVR Studio 
4.19 nutze.

c) Im Studio ein neues Projekt angelegt, als Projektordner der oben 
genannte D:\bootload eingegeben

d) die Projektkonfiguration auf <use external makefile: Makefile> 
geändert

e) und den ersten BUILD gewagt.

Das Ergebnis war ernüchternd:

Build started 9.4.2015 at 11:52:23
Makefile:125: atmel_def.mak: No such file or directory
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak

avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega32 -DF_CPU=14745600  -I 
. -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding 
-gdwarf-2 -L,-gdwarf-2 -DRAM_START= -DSRAM_SIZE= -DSTX_PORT=PORTD 
-DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/bootload.S -o bootload.o


./atmel_def.h: Assembler messages:
./atmel_def.h:1: Error: junk at end of line, first unrecognized 
character is `2'
./converted/password.inc:13: Error: non-constant expression in ".if" 
statement
./converted/message.inc:17: Error: non-constant expression in ".if" 
statement
./converted/message.inc:23: Error: non-constant expression in ".if" 
statement
./added/fastload.inc:73: Error: illegal relocation size: 1
./added/fastload.inc:74: Error: illegal relocation size: 1
./added/fastload.inc:76: Error: illegal relocation size: 1
./added/fastload.inc:77: Error: illegal relocation size: 1
./added/fastload.inc:78: Error: illegal relocation size: 1
./added/fastload.inc:80: Error: illegal relocation size: 1
./added/fastload.inc:81: Error: illegal relocation size: 1
./added/fastload.inc:82: Error: illegal relocation size: 1
make: *** [bootload.o] Fehler 1
Build failed with 1 errors and 0 warnings...

Bin auch nach mehrfachem rauf und runterlesen Eurer Beiträge ratlos.

Mag mir jemand einen Tipp geben?

Danke und Gruß
Axel

von Uwe S. (de0508)


Lesenswert?

Hallo Alex,

Hast Du das Makefile angepasst ?

Denn dort passiert die eigentliche Programmierung und Auswahl des 
Zielprozessors.

Wie sieht für den atmega32 m32def.inc aus und wo liegt diese ??

Bitte hier das Makefile mal anhängen.

PS. es sei auf eine aktuellere Datei verwiesen:
# Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain"

: Bearbeitet durch User
von Axel (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Uwe,

ich habe den Link auf diese Diskussion direkt aus dem Artikel 
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger 
bekommen.

Mein Makefile habe ich angehängt, als Text vielleicht doch etwas zu 
lang.

Das m32def.inc liegt genau dort wo es im ZIP gewesen ist, im Verzeichnis 
d:\bootloader\atmel

Und damit es ganz bestimmt gefunden wird, habe ich noch eine Kopie im 
d:\bootloader abgelegt (im Makefile wird jedoch mit ./atmel/ auf das 
eben genannte atmel-Verzeichnis gezeigt.

Die von Dir referenzierte neuere Datei schaue ich mir nach dem 
Abendessen mal an.

Gruß und Dank
Axel

von Axel (Gast)


Lesenswert?

Hallo Uwe,

ich habe nochmals nachgesehen welches ZIP-File ich für meinen Versuch 
verwendet hatte und muss mich (leider) korrigieren.

Es ist genau die Datei die Du mir vorhin empfohlen hattest verwendet 
worden <fastboot-2.9-140709.zip>.

Meine ursprüngliche Angabe  <fastboot-2.9_110804.zip> war als 
Quellenangabe definitiv falsch.

Sorry!!!

Gruß
Axel

von Uwe S. (de0508)


Lesenswert?

Hallo,

da ich keine Atmel IDE verwende, kann ich auch nicht weiter helfen.
Du musst dich selbst um eine funktionierende Kompilerumgebung mit allen 
Tools kümmern.

: Bearbeitet durch User
von Axel (Gast)


Lesenswert?

Hallo Uwe,

schade, dass Du mir nicht weiterhelfen kannst.

Ich schreibe in meiner Kompilerumgebung seit Jahren sowohl große 
Assembler- als auch große C-Pakete. Daher dachte ich, dass es nicht an 
meiner Umgebung liegen könne.

So kann man sich täuschen.

Mal sehen, wo ich noch um Hilfe bitten kann.

Gruß
Axel

von Nils E. (yetanotheruser)


Lesenswert?

Hallo Axel,

die Version für die AVR-GCC-Toolchain macht einige Umstände mit diversen 
Scripts, um die ursprüngliche Version für den avrasm2 für den avr-gcc 
passend zu basteln.

Wenn Du doch aber ohnehin unter Windows entwickelst, wärst Du vielleicht 
mit der ursprünglichen Version von Peter Danneger besser beraten.

Viele Grüße
Nils

von Axel (Gast)


Lesenswert?

Hallo Nils,

aus reiner Neugier hier mal das Ergebnis, wenn ich direkt unter einer 
DOS-Umgebung das <Make clean> und dann <Make> starte.

E:\>cd fastboot

E:\fastboot>make
makefile:125: atmel_def.mak: No suc
./_conv.awk atmel/m32def.inc | gawk
> atmel_def.h
Der Befehl "." ist entweder falsch
konnte nicht gefunden werden.
make: *** [atmel_def.h] Fehler 255

E:\fastboot>make clean
makefile:125: atmel_def.mak: No suc
./_conv.awk atmel/m32def.inc | gawk
> atmel_def.h
Der Befehl "." ist entweder falsch
konnte nicht gefunden werden.
make: *** [atmel_def.h] Fehler 255

Da wird schlicht _conv.awk nicht gefunden, obwohl es im Verzeichnis 
e:\fastboot liegt...

Gruß
Axel

von Uwe S. (de0508)


Lesenswert?

Hallo Axel,

ja und warum ? Da es sich um Unix Pfadangaben handelt.
Du musst auch vorher eine Unix Shell starten.

: Bearbeitet durch User
von Klaus W. (klausw1)


Lesenswert?

Hallo,

ich weiß, der Quellcode des Bootloaders ist offen. Allerdings bin ich in 
diesem Thema nicht wirklich firm, naja und C ist auch nicht wirklich so 
mein Freund.
Wäre es möglich, dass jemand noch eine Funktion einbaut, um auch das 
EEPRom zu beschreiben? Soweit ich das im MCS-Bootloader gesehen habe, 
dürfte das kein großer Aufwand sein, da das Prinzip des Upload gleich 
bleibt. Ich wäre sehr dankbar dafür.
Falls die Funktion wegen des größeren Bootloaders nicht implementiert 
ist, würde ich vorschlagen, per Präprozessor-Flag beim Kompilieren die 
Funktion bei Bedarf aktivieren zu können. Dann kann der Nutzer 
entscheiden, ob er die Funktion nutzen möchte und halt weniger Speicher 
fürs Programm übrig bleibt, oder nicht.

von Bernhard M. (boregard)


Lesenswert?

Hallo,

der bootloader selbst bietet kein EEPROM beschreiben, und wenn man es 
einbaut, dann wird er größer.
Die Frage ist, wann man das EEPROM beschreiben will - ich immer nur vor 
dem schreiben des Programmes (meist nur beim ersten mal).
Also behelfe ich mir damit, daß ich vor dem Programmieren ein Programm 
in den AVR flashe, das das EEPROM beschreibt, und danach erst das 
richtige Programm.

Wenn man das regelmässig braucht, kann man das im Makefile 
automatisieren.
Ich habe dafür mal unter Linux ein Programm geschrieben, das mit der 
EEPROM section ein AVR C-Program schreibt, das dann compiliert und 
hochgeladen wird. Nach dem start beschreibt es dann da EEPROM. Das wird 
dann bei Bedarf im Makefile aufgerufen..

Gruß,
Bernhard

von Klaus W. (klausw1)


Lesenswert?

Hallo,

dass der Bootloader dadurch größer wird, ist klar. Hab ich ja auch oben 
geschrieben. Deswegen ja die Idee, dass man per Präprozessor-Anweisung 
das Einkompilieren der EEProm-Routine bei Bedarf aktivieren kann.

Wenn man am Entwickeln ist, könnte es schon interessant sein, weil man 
sonst den Mikrocontroller wieder ausbauen muss.
Wo es auch nützlich sein kann, wenn man dem Endkunden ein Update 
anbieten kann, wo sich vielleicht aus Änderungen der EEProm-Inhalt 
geändert haben sollte.

Gruß,
Klaus

von Klaus W. (klausw1)


Angehängte Dateien:

Lesenswert?

Ich hätte mal wieder ne Frage.
Für den Atmega8 und Atmega168 habe ich den Bootloader erfolgreich 
erstellt.

Nun bin ich am Attiny2313A. Er ist vom Prinzip drauf, der Upload der 
Firmware funktioniert dann auch erstmal augenscheinlich, bricht dann 
aber beim Programm überprüfen ab. Auch wenn ich den Flash auslese, ist 
kein Programm drin, nur der Bootloader am Ende.
Da der Controller aufgelistet wird, nehme ich mal an, dass es irgendwie 
gehen muss.

Gruß,
Klaus

von Uwe S. (de0508)


Lesenswert?

Hallo Klaus,

wie sieht deine Fusebit Einstellung aus ?

Ist "Self programming enable" aktiviert ?

von Klaus W. (klausw1)


Lesenswert?

Hallo Uwe,

da hätte ich auch selbst drauf kommen können. Das war es wohlt 
tatsächlich. Zumindest funktioniert es hier mit einem Controller. Muss 
ich zuhause mal mit exakt dem, der gestern nicht wollte, probieren.

von clonephone82 (Gast)


Lesenswert?

Eine Frage,
Bei einem kleinen Projekt wo ich leider nur eine Rx Leitung zur 
Verfügung habe hätte ich doch gerne einen Bootloader integriert.

Blöderweise kann ich auch nur in eine Richtung senden. Die Leitung wird 
auf-modelliert usw.
Meint ihr das es möglich ist nur über die Rx Leitung fastboot zu nützen. 
Ich dachte an einen abgeänderte Hostsoftware die einfach das Protokoll 
so abarbeitet als wie die richtige Antwort kommt. Ich hätte dafür genau 
verifiziert wie die Timeouts sein müssen etc. Also das ist dann schon 
recht zugeschnitten usw. aber das ist mir bewusst. Aber was denkt ihr 
das müsste schon gehen.

Danke
sg
mathias

von Klaus W. (klausw1)


Lesenswert?

Fastboot unterstützt auch einen 1-wire modus. Du musst ihn nur im 
1-wire-modus kompilieren und einen Adapter bauen. Im PDF-Handbuch ist 
beschrieben, wie der aussehen muss.

von Bernhard M. (boregard)


Lesenswert?

Wenn du wirklich nur an den AVR senden kannst, ist das aber ein 
Glücksspiel...

Der AVR gitb ja dem Ladeprogramm beim initialisieren zurück, wer er ist, 
und wie groß sein Buffer ist, d.h. in welchen Blockgrößen gesendet 
werden soll.

Wenn man das weiß, kann man im Ladeprogramm mit den vorgegeben Werten 
arbeiten.
Dann Block senden, einige Zeit warten (der Block muss ja geschrieben 
werden), und nächsten Block senden.

Soweit ich mich erinnere, hat der Bootloader selbst keine Timeouts mehr, 
d.h. man kann dann einfach großzügig warten. Du musst also keine 
Timeouts verifizieren...

von Daniel B. (bradan)


Lesenswert?

Hallo,

Ich habe AVR-GCC 5.2.0 (unter Arch Linux) und es kommt wieder die 
Fehlermeldung
1
get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld command line

Komplettes Log:
1
vars="$(./get_text_addrs.sh 0x3FFF)"; \
2
arch="$(./get_avr_arch.sh -mmcu=atmega32 bootload.o)"; \
3
echo "arch=$arch";\
4
echo "$vars"; \
5
eval "$vars"; \
6
sed -e "s/@LOADER_START@/$LOADER_START/g" \
7
    -e s"/@ARCH@/$arch/" \
8
    -e s'/@RAM_START@//g' \
9
    -e s'/@RAM_SIZE@//g' \
10
    -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
11
    bootload.template.x > bootload.x; \
12
avr-ld -N -E -T bootload.x -Map=bootload.map \
13
  --cref bootload.o stub.o -o bootload.elf --defsym Application="$LOADER_START-2"
14
*** Last available byte address for the user program: 0x7dfd
15
get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld command line
16
arch=
17
LOADER_START=0x7e00
18
STUB_OFFSET=0x1fe
19
avr-ld:bootload.x:18: syntax error
20
Makefile:133: die Regel für Ziel „bootload.elf“ scheiterte
21
make: *** [bootload.elf] Fehler 1

Laut diesem Thread gibt es eine neue Version dieser Datei, aber die 
funktioniert leider auch nicht.

Kann mir jemand vielleicht sagen, was das Resultat dieser Datei ist bei 
einem atmega32? Dann könnte ich das vielleicht manuell einsetzen. Ich 
habe bereits m32 und atmega32 versucht, aber ohne Erfolg, denn dann 
kommt:
1
arch=atmega32
2
LOADER_START=0x7e00
3
STUB_OFFSET=0x1fe
4
avr-ld: cannot represent machine `atmega32'

Mit freundlichen Grüßen,
Daniel

von Hendrik L. (lbd)


Lesenswert?

Hallo zusammen,

da obige Prozedur (Makefile) im letzten Schritt (Bind) noch nicht 
geklappt hat (bei mir auf DEBIAN)
1
Linux version 4.1.13-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #826 SMP PREEMPT Fri Nov 13 20:19:03 GMT 2015

... habe ich mir 'mal den Vorgang untersucht und verschiedene Fragen 
stellen sich mir (bin Anfänger):

Was bewirkt eigentlich der nachfolgende Befehl in dem Bash Script 
"get_avr_arch.sh"?
1
avr-gcc -mmcu=atmega2560 -### bootload.o -o+  ;#magic1295671ghkl-.

Wo bitte ist die "Magic..." Abfrage dokumentiert?

Leider funktioniert der Befehl nur auf der Konsole, das System antwortet 
mit:
1
Using built-in specs.
2
COLLECT_GCC=avr-gcc
3
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper
4
Target: avr
5
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=avr
6
Thread model: single
7
gcc version 4.7.2 (GCC)
8
COMPILER_PATH=/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/../../../avr/bin/
9
LIBRARY_PATH=/usr/lib/gcc/avr/4.7.2/avr6/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr6/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/
10
COLLECT_GCC_OPTIONS='-mmcu=atmega2560' '-o' '+'
11
 /usr/lib/gcc/avr/4.7.2/collect2 -m avr6 -Tdata 0x800200 -o "+" /usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr6/crtm2560.o -L/usr/lib/gcc/avr/4.7.2/avr6 -L/usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr6 -L/usr/lib/gcc/avr/4.7.2 -L/usr/lib/gcc/avr/4.7.2/../../../avr/lib bootload.o -lgcc -lc -lgcc

Hieraus entnehme ich - der Mega 2560 ist in avr-gcc definiert (hätte 
mich auch gewundert!)

Was mache ich denn damit?

Das Bash-Script steigt mit exit 1 aus, weil diese Antwort wohl nicht 
zurückkommt, dadurch kann make den ersehnten Bootloader nicht zu einem 
Executable linken.
Das Problem ist wohl auch in einigen Posts zuvor schon aufgetreten, bin 
mir aber nicht sicher, ob das Problem richtig erkannt wurde - die 
Prozessoren waren offensichtlich definiert - nur das Script scheint die 
Antwort nicht zu bekommen. Ist wahrscheinlich eher ein Scripting Problem 
in "get_avr_arch.sh" in Zeilen 4 & 5:
1
magic=";#magic1295671ghkl-."
2
# call gcc, asking it for the command line which it would use for
3
# linking:
4
set -- $(avr-gcc -m"$mcu" -### "$1" -o "$magic" 2>&1 \
5
         | gawk '/^avr-gcc:/||/ld.*'"$magic"'.*"-lgcc"/')
6
7
if [ "$1" = "avr-gcc:" ]; then
8
    # we have an error message from gcc:
9
    echo "$*"
10
    exit 1
11
fi
12
13
# retrieve architecture argument from gcc's commandline (the argument
14
# which follows '"-m"'):
15
while [ -n "$2" ]; do
16
    if [ "$1" = '"-m"' ]; then
17
  eval echo $2    # eval: remove quotes
18
  exit 0
19
    fi
20
    shift
21
done
22
echo >&2 "\
23
$pname: Could not find an architecture in avr-gcc's internal ld command line"
24
exit 1
Any Help is pretty much appreciated ;-)

Grüße

von Hendrik L. (lbd)


Lesenswert?

So - bin ein Stück weiter:

Für den ATmega 2560 wäre die erwartete Antwort gewesen ..., die dann 
aufgelöst nach den Positional Parametern $1 ... $x
1
+ [ Using = avr-gcc: ]
2
+ [ -n built-in ]
3
+ [ Using = -m ]
4
+ shift
5
+ [ -n specs. ]
6
+ [ built-in = -m ]
7
+ shift
8
+ [ -n COLLECT_GCC=avr-gcc ]
9
+ [ specs. = -m ]
10
+ shift
11
+ [ -n COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper ]
12
+ [ COLLECT_GCC=avr-gcc = -m ]
13
+ shift
14
+ [ -n Target: ]
15
+ [ COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper = -m ]
16
+ shift
17
+ [ -n avr ]
18
+ [ Target: = -m ]
19
+ shift
20
+ [ -n Configured ]
21
+ [ avr = -m ]
22
+ shift
23
+ [ -n with: ]
24
+ [ Configured = -m ]
25
+ shift
26
+ [ -n ../src/configure ]
27
+ [ with: = -m ]
28
+ shift
29
+ [ -n -v ]
30
+ [ ../src/configure = -m ]
31
+ shift
32
+ [ -n --enable-languages=c,c++ ]
33
+ [ -v = -m ]
34
+ shift
35
+ [ -n --prefix=/usr/lib ]
36
+ [ --enable-languages=c,c++ = -m ]
37
+ shift
38
+ [ -n --infodir=/usr/share/info ]
39
+ [ --prefix=/usr/lib = -m ]
40
+ shift
41
+ [ -n --mandir=/usr/share/man ]
42
+ [ --infodir=/usr/share/info = -m ]
43
+ shift
44
+ [ -n --bindir=/usr/bin ]
45
+ [ --mandir=/usr/share/man = -m ]
46
+ shift
47
+ [ -n --libexecdir=/usr/lib ]
48
+ [ --bindir=/usr/bin = -m ]
49
+ shift
50
+ [ -n --libdir=/usr/lib ]
51
+ [ --libexecdir=/usr/lib = -m ]
52
+ shift
53
+ [ -n --enable-shared ]
54
+ [ --libdir=/usr/lib = -m ]
55
+ shift
56
+ [ -n --with-system-zlib ]
57
+ [ --enable-shared = -m ]
58
+ shift
59
+ [ -n --enable-long-long ]
60
+ [ --with-system-zlib = -m ]
61
+ shift
62
+ [ -n --enable-nls ]
63
+ [ --enable-long-long = -m ]
64
+ shift
65
+ [ -n --without-included-gettext ]
66
+ [ --enable-nls = -m ]
67
+ shift
68
+ [ -n --disable-libssp ]
69
+ [ --without-included-gettext = -m ]
70
+ shift
71
+ [ -n --build=arm-linux-gnueabihf ]
72
+ [ --disable-libssp = -m ]
73
+ shift
74
+ [ -n --host=arm-linux-gnueabihf ]
75
+ [ --build=arm-linux-gnueabihf = -m ]
76
+ shift
77
+ [ -n --target=avr ]
78
+ [ --host=arm-linux-gnueabihf = -m ]
79
+ shift
80
+ [ -n Thread ]
81
+ [ --target=avr = -m ]
82
+ shift
83
+ [ -n model: ]
84
+ [ Thread = -m ]
85
+ shift
86
+ [ -n singlegcc ]
87
+ [ model: = -m ]
88
+ shift
89
+ [ -n version ]
90
+ [ singlegcc = -m ]
91
+ shift
92
+ [ -n 4.7.2 ]
93
+ [ version = -m ]
94
+ shift
95
+ [ -n GCCCOMPILER_PATH=/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/../../../avr/bin/ ]
96
+ [ 4.7.2 = -m ]
97
+ shift
98
+ [ -n LIBRARY_PATH=/usr/lib/gcc/avr/4.7.2/avr6/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr6/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/ ]
99
+ [ GCCCOMPILER_PATH=/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.7.2/../../../avr/bin/ = -m ]
100
+ shift
101
+ [ -n COLLECT_GCC_OPTIONS=-mmcu=atmega2560 ]
102
+ [ LIBRARY_PATH=/usr/lib/gcc/avr/4.7.2/avr6/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/avr6/:/usr/lib/gcc/avr/4.7.2/:/usr/lib/gcc/avr/4.7.2/../../../avr/lib/ = -m ]
103
+ shift
104
+ [ -n -o ]
105
+ [ COLLECT_GCC_OPTIONS=-mmcu=atmega2560 = -m ]
106
+ shift
107
+ [ -n + ]
108
+ [ -o = -m ]
109
+ shift
110
+ [ -n /usr/lib/gcc/avr/4.7.2/collect2 ]
111
+ [ + = -m ]
112
+ shift
113
+ [ -n -m ]
114
+ [ /usr/lib/gcc/avr/4.7.2/collect2 = -m ]
115
+ shift
116
+ [ -n avr6 ]
117
+ [ -m = -m ]
118
+ eval echo avr6
119
+ echo avr6
120
avr6
121
+ exit 0

mit exit 0 für "avr6" geendet hätte.

"avr6" ist also das "Objekt der Begierde", das gesucht war.

Was nun ist avr6 ??? Offensichtlich kann der Linker damit etwas anfangen 
...!

Wer kann bitte mein Skript-Problem auflösen, damit der Automatismus 
durchläuft  - ansonsten muss ich von Hand eintragen!

Danke im Voraus

von Karl M. (Gast)


Lesenswert?

Hallo,

avr6 ist die AVR Klasse (Generation) zu der dein AVR µC gehört.

von Hendrik L. (lbd)


Lesenswert?

Hallo zusammen,

nachdem diese Klippe umschifft, habe ich es geschafft, eine bootload.exe 
für die AVR6 Klasse (ATmega2560) zu erstellen. Ich gehe davon aus, dass 
er auch läuft - auf Windows Plattform funktioniert jedenfalls läuft 
PEDA's Bootloader für den 2560 hervorragend, den ich bereits dort vor 
Jahren generiert habe.

Für die ATtiny Klasse (ohne BOOTRST) ist an dieser Stelle leider im 
letzten Schritt Schluss - der folgende Scripting Abschnitt im Makefile 
(siehe unten) ist definitiv  (auch - neben dem oben geschildertem 
Problem, was man aber "manuell" umschiffen kann) "buggy" und mir fehlt 
das Wissen, um überhaupt analysieren zu können, woran es liegt könnte - 
gawk und sed sind nicht mein Thema ...!

Werde jetzt auf Windows umsteigen und dort meinen ATtiny mit Hilfe von 
PEDA erstellen. Der müsste ja dann auch mit einem Linux Host 
kommunizieren können.

Schade, dass dieses schöne Tool nicht ganz fertig geworden ist. Wirklich 
eine geniale Arbeit!

Grüße
1
#(Makefile)
2
...
3
bootload.elf : bootload.o stub.o
4
#---- ab hier buggy ------------------------------------------------------
5
ifndef BOOTRST
6
  vars="$$(./get_text_addrs.sh $(FLASHEND))"; \
7
  arch="$$(./get_avr_arch.sh -mmcu=$(MCU) bootload.o)"; \
8
  echo "arch=$$arch";\
9
  echo "$$vars"; \
10
  eval "$$vars"; \
11
  sed -e "s/@LOADER_START@/$$LOADER_START/g" \
12
      -e s"/@ARCH@/$$arch/" \
13
      -e s'/@RAM_START@/$(SRAM_START)/g' \
14
      -e s'/@RAM_SIZE@/$(SRAM_SIZE)/g' \
15
      -e "s/@STUB_OFFSET@/$$STUB_OFFSET/g" \
16
      bootload.template.x > bootload.x; \
17
  avr-ld -N -E -T bootload.x -Map=$(patsubst %.elf,%,$@).map \
18
    --cref $+ -o $@ --defsym Application="$$LOADER_START-2"
19
#---- bis hier buggy -----------------------------------------------------
20
else
21
  vars="$$(./get_bootsection_addrs.sh $(FLASHEND) $(FIRSTBOOTSTART) \
22
                $(SECONDBOOTSTART) $(THIRDBOOTSTART) $(FORTHBOOTSTART))"; \
23
...

von Oliver (Gast)


Lesenswert?

Hallo,

sorry, doch könnte mal jemant sagen, was ich tun mus um den Bootloader 
für einen Atmega32 zu erstellen?

Scheiter immer noch an der Meldung "atmel_def.mak: No such file or 
directory"

Was müste ich tun, um eine .hex Datei zu erhalten.


Gruß

Oliver

von Fritz G. (fritzg)


Lesenswert?

Moin!

Ich habe in mein Board jetzt auch Fastboot eingebaut. get_avr_arch.sh 
funktioniert nicht, ich habe da aber den avr5 hardgecodet damit ich 
weitermachen kann.
Zum Programmieren verwende ich FBoot-Linux-master 2.1 auf OS X. Das geht 
(fast) tadellos, ausser dem Manko, dass ich keine 230400 Baud verwenden 
kann. Es kommt da einfach kein Connect zustande. Mit 115200 Baud 
funktioniert es. Ich habe mit meinem Board bisher immer mit 230400 Baud 
ohne Probleme kommunizieren können. Ich verwende einen FT232R als 
Adapter.
Die Quarzfrequenz ist 7372800Hz, so ist es auch im bootloader 
eingestellt.
MCU ist ein ATMEGA644PA, im Makefile ist MCU = atmega644p eingestellt.

Weis jemand einen Rat?

: Bearbeitet durch User
von Uwe S. (de0508)


Lesenswert?

Guten Morgen Fritz,

das ist schon ok so. Fasstboot 2.0 ist ein eigenständiges Programm, dass 
durch die zu geringe Taktfrequenz 7,3728MHz bei 230400 Bit/s nur 32 
Takte für jedes Bit Zeit hätte.
Wenn die Übertragung mit 115200 Bit/s funktioniert, dann hat Du mit 64 
Takten pro Bit sicherlich eine Grenze gefunden.

Ich nutze meistes 19200 Bit/s - 57600 Bit/s als 
Übertragungsgeschwindigkeit.

von clonephone82 (Gast)


Lesenswert?

Gibt es eine Möglichkeit beim fastboot einen CRC check einzuschalten 
damit - falls was beim Download schief geht auch nochmals etwas 
nachgeladen werden kann?

danke

von clonephone82 (Gast)


Lesenswert?

Sorry die Frage ist so glaube ich nicht ganz verständlich ich meine von 
der Applikation selbst oder macht das fastboot - bin da nicht ganz 
sicher.

Ich kenne das beispielsweise so: Der Bootloader mach vor er in die App 
springt eien CRC check dazu wurde die CRC an einen bestimmte Adresse 
gelegt beim Build-Prozess der App. Wie lauft das beim Fastboot es gibt 
ja eine CRC aber berechnet er sich diese selber?

von clonephone82 (Gast)


Lesenswert?

Hallo,

Noch einen Frage wie ist hier denn der Zusammenhang?

.equ  XTAL    = 8000000   ; 8MHz, not critical
Um die Wartezeit auf das Firmware-Update beim Booten anzupassen:
.equ  BootDelay  = XTAL / 3  ; 0.33s


Was git diese 0.33s bei XTAL 8MHz?

Danke

von Bernhard M. (boregard)


Lesenswert?

clonephone82 schrieb:
> Gibt es eine Möglichkeit beim fastboot einen CRC check einzuschalten
> damit - falls was beim Download schief geht auch nochmals etwas
> nachgeladen werden kann?
>
> danke

Normalerweise macht der Bootloader eine CRC beim laden, man kann das 
aber deaktivieren (vor dem assemblieren des bootloaders).
Nachgeladen wird da (automatisch) nichts, wenn die CRC nicht stimmt, 
dann wird halt gemeldet, dass das Laden nicht funktioniert hat.

von Bernhard M. (boregard)


Lesenswert?

clonephone82 schrieb:
> Sorry die Frage ist so glaube ich nicht ganz verständlich ich meine von
> der Applikation selbst oder macht das fastboot - bin da nicht ganz
> sicher.
>
> Ich kenne das beispielsweise so: Der Bootloader mach vor er in die App
> springt eien CRC check dazu wurde die CRC an einen bestimmte Adresse
> gelegt beim Build-Prozess der App. Wie lauft das beim Fastboot es gibt
> ja eine CRC aber berechnet er sich diese selber?

Du meinst, dass bei jedem starten geprüft wird, ob die CRC stimmt?
Nein, das macht der bootloader nicht, was sollte er auch tun, wenn das 
nicht der Fall ist???

Beim Fastboot wird die CRC beim Laden / flashen des Programmes 
überprüft. Eien CRC selbst muss dazu im bootloader nicht gespeichert 
werden, wenn die CRC am Ende 0 ist, dann war alles in Ordnung.

von Bernhard M. (boregard)


Lesenswert?

clonephone82 schrieb:
> Hallo,
>
> Noch einen Frage wie ist hier denn der Zusammenhang?
>
> .equ  XTAL    = 8000000   ; 8MHz, not critical
> Um die Wartezeit auf das Firmware-Update beim Booten anzupassen:
> .equ  BootDelay  = XTAL / 3  ; 0.33s
>
>
> Was git diese 0.33s bei XTAL 8MHz?
>
> Danke

Die Frage ist mir nicht ganz klar.
Der Bootloader wartet nach dem Reset darauf, daß er ein neues Kommando 
über die serielle Schnittstelle bekommt. Falls nichts kommt, dann 
springt er nach einer gewissen Zeit in das eigentlich Programm (und 
beendet sich damit).
Diese Zeit wird hier auf 1/3 Sekunde festgelegt (mit XTAL / 3). Wenn der 
Wert nicht stimmt (z.B. XTAL falsch gesetzt ist), dann ist diese Timeout 
anders, meistens funktioniert der Bootloader aber trotzdem....

von Nils S. (kruemeltee) Benutzerseite


Lesenswert?

Bernhard M. schrieb:
> Wert nicht stimmt (z.B. XTAL falsch gesetzt ist), dann ist diese Timeout
> anders, meistens funktioniert der Bootloader aber trotzdem....

1/3 Sekunde ist für einen Controller auch eine Ewigkeit.
Bei 115200/8N1 dauert es, das Magic-Byte zu übertragen, ca. 80µS.

80µS vs 333333µS...

von clonephone82 (Gast)


Lesenswert?

@Bernhard: Danke das mit der CRC ist mir nun klar.
@BootDelay: Okay aber wie kommt man hier auf eine drittel Sekunde? Die 
Frage ist eben war der Kommentar für einen 1MHz Takt oder 8MHz Takt oder 
14,.. MHz Takt wie im Makefile vom orginal.

Weil 8MHz / 3 => 1/3 sekunde?

Mein Problem ist das ich den Loader für einen Attiny85 verwende aber 
manchmnal Probleme beim nachladen habe.

Jetzt habe ich die Wartezeit im Verdacht. Ich muss machmachal 2 mal 
reseten bis er im Loader hängen bleibt.

von Nils S. (kruemeltee) Benutzerseite


Lesenswert?

8Mhz => 8,000,000 Takte pro Sekunde
8/3 => ~2,666,666 müssen vergehen, bis 1/3 Sekunde vorbei ist.

Ist der Takt richtig angegeben, dann stimmt auch die 1/3s.

: Bearbeitet durch User
von Nils S. (kruemeltee) Benutzerseite


Lesenswert?

clonephone82 schrieb:
> Ich muss machmachal 2 mal
> reseten bis er im Loader hängen bleibt.

Vielleicht reagiert dein Taster nicht immer? Hast du direkt optische 
Rückmeldung für den Reset?

Ich verwende die DTR Leitung um über 10nF den Reset auszulösen, dann 
geht alles automatisch.

von Fritz G. (fritzg)


Lesenswert?

Ich lausche, ob das Passwort kommt und mache dann den Reset.

von clonephone82 (Gast)


Lesenswert?

Hallo Fritz,

Wie machst du den den Reset? Ist das ein SW Reset?

danke

von Fritz G. (fritzg)


Lesenswert?

Ja, nachdem ich den String "Peda" erkannt habe:
1
                lcdClrscr();
2
                lcdGotoxy(0, 0);
3
                lcdWrite_P(PSTR("Loading firmware"));
4
                lcdGotoxy(0, 1);
5
                lcdWrite_P(PSTR("Please wait...  "));
6
                beepOk();
7
                wdt_reset();
8
                wdt_enable(WDTO_1S);
9
                wdt_reset();
10
                while (1);

Das funktioniert zuverlässig, da das Flashprogramm immer 0x0d, das 
Passwort und dann 0xff schickt, bis es einen Connect bekommt.

von Mathias G. (mgiaco)


Lesenswert?

Hallo Zusammen,

Ich musst für eine LED Anwendung bei einem Attiny85 auf internal PLL mit 
16MHz zurückgreifen. Funktioniert soweit gut - mal sehen ob der Tiny den 
hohen Takt hält.

Jedenfalls habe ich dort auch einen fastboot drauf. Bisher war ich 
eigentlich nur Anwender dieses schöne Loaders. Jetzt muss ich diesen 
aber auf PLL mit 16HMz anpassen - oder kann es sein das ich einfach nur 
von 8MHz auz 16MHz stellen?

Aktuell funktioniert der Loader noch - aber das Fenster ist zu kurz muss 
mehrmals reseten zum nachladen.

Danke

von Klaus W. (klausw1)


Lesenswert?

Ich bin gerade dabei und versuche einem ATtiny45 den Bootloader bei zu 
bringen. Er ist auch soweit ansprechbar, allerdings schlägt das Verify 
immer fehl. Entsprechend startet auch das Programm gar nicht, sondern 
immer der Bootloader.
Der Tiny45 besitzt ja normalerweise keinen Bootvektor. Wie ich aber in 
älteren Beiträgen gelesen habe, müsste der Fastboot doch inzwischen den 
Tiny45 unterstützen, oder sehe ich das falsch? Das ist doch eine 
Weiterentwicklung des Tinyload, oder?

von Karl M. (Gast)


Lesenswert?

Hallo Klaus,

wie sehen deine FuseBit Einstellungen aus?
Hast Du den Bootloader selbst übersetzt ? Ausgabe ?
Wie schnell überträgst Du die Daten zum attiny45 ?
Nutze mal 19200 Bit/s und zeige das Logfile der Übertragung bitte.

von Klaus W. (klausw1)


Lesenswert?

Das hier ist die Ausgabe:
1
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload>make Makefile-tiny4
2
5 all
3
makefile:125: atmel_def.mak: No such file or directory
4
./_conv.awk atmel/m32def.inc | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/'
5
> atmel_def.h
6
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
7
make: Nothing to be done for `Makefile-tiny45'.
8
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega32 -DF_CPU=14745600  -I . -I ./a
9
dded -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs
10
+ -DRAM_START=0x0060 -DSRAM_SIZE=2048 -DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORT
11
D -DSRX=PD0 added/bootload.S -o bootload.o
12
avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega32 -DF_CPU=14745600  -I . -I ./added
13
 -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs+ -D
14
RAM_START=0x0060 -DSRAM_SIZE=2048 -DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORTD -D
15
SRX=PD0 added/stub.S -o stub.o
16
vars="$(./get_bootsection_addrs.sh 0x3fff 0x3f00 0x3e00 0x3c00 )"; \
17
        arch="$(./get_avr_arch.sh -mmcu=atmega32 bootload.o)"; \
18
        echo "arch=$arch";\
19
        echo "$vars"; \
20
        eval "$vars"; \
21
        sed -e "s/@LOADER_START@/$LOADER_START/g" \
22
            -e s"/@ARCH@/$arch/" \
23
            -e s'/@RAM_START@/0x0060/g' \
24
            -e s'/@RAM_SIZE@/2048/g' \
25
            -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
26
            bootload.template.x > bootload.x; \
27
        avr-ld -N -E -T bootload.x -Map=bootload.map \
28
          --cref bootload.o stub.o -o bootload.elf --defsym Application=0
29
*** Note: set BOOTSZ fuses to the word address 0x3f00 ***
30
arch=avr5
31
LOADER_START=0x7e00
32
STUB_OFFSET=0x1fe
33
avr-objcopy -O ihex bootload.elf bootload.hex
Ich hatte schon mit mehreren Übertragungsraten probiert. Zuletzt mit 
9600.
Die Ausgabe beim Flaschen ist:
1
COM-Port öffnen
2
Verbindungsaufbau...
3
Verbunden: 2-Draht-Modus, 1 Versuch
4
Übertragung CRC-gesichert!
5
Überprüfung (Verify) unterstützt!
6
Chip-Signatur: 1E 92 06
7
Bootloader V2.1 auf ATtiny45 gefunden
8
Flash-Größe: 3kB (Puffer: 64 Byte)
9
CRC-Prüfsumme OK
10
Programmiere 362 Byte von 3kB Flash...
11
Programmieren erfolgreich
12
Überprüfe gespeicherte Firmware...
13
Fehler aufgetreten, Update abgebrochen!

von Konrad S. (maybee)


Lesenswert?

Klaus W. schrieb:
> -mmcu=atmega32

???

> make Makefile-tiny45 all

Sollte das nicht eher so sein?
1
make -f Makefile-tiny45 all

von Klaus W. (klausw1)


Lesenswert?

Wofür ist "-f"? Und warum kommt damit ne andere MCU?

Jetzt muss ich mir erst nochmal irgendwo ein Atmel Studio 4 
installieren. Damit hatte ich nämlich den Bootloader kompiliert, den ich 
benutzt habe. Leider hat mein Rechner in der Zwischenzeit den Geist 
aufgegeben und ich musste alles neu machen. Da habe ich mir gleich Atmel 
Studio 7 installiert. Da damit das Kompilieren nicht funktionierte, habe 
ich einfach die Kommandozeile benutzt, um die Ausgabe nochmal zu 
reproduzieren. Was damals wirklich genau raus kam, habe ich heute leider 
nicht mehr.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Klaus W. schrieb:
> Wofür ist "-f"?

Es gibt dem "make" an, welches Makefile es benutzen soll.

Ohne -f wird "makefile" oder "Makefile" benutzt (in dieser Reihenfolge,
die natürlich auf Windows nicht interessiert, weil das OS für beide
Anfragen die gleiche Datei zurückgeben würde).

> Und warum kommt damit ne andere MCU?

Ohne -f wird mit dem Standard-Makefile versucht, zuerst
"Makefile-tiny45" neu zu erstellen (dafür ist nichts zu tun, das
ist bereits aktuell :), danach "all".

Mit -f wird "Makefile-tiny45" benutzt, und darin dann das Target "all"
gesucht und gebaut …

von Aruinoquäler (Gast)


Lesenswert?

Klaus W. schrieb:
> Da damit das Kompilieren nicht funktionierte,

Ich habe Atmel AVR Studio 4 (4.18) und WinAVR2010 unter Windows 7
installiert und das funktioniert.

Wenn was nicht funktioniert dann deshalb weil man vielleicht
vergisst dass das AVR Studio ohne Compiler daherkommt, also
(möglichst vorher) muss der WinAVR Compiler explizit installiert
werden.

von Klaus W. (klausw1)


Lesenswert?

So, hab es nochmal in ner VM probiert. Das ist also die Ausgabe des 
Atmel Studio, womit ich damals auch komiliert hatte:
1
Build started 1.12.2016 at 13:49:56
2
Makefile-tiny45:130: atmel_def.mak: No such file or directory
3
./_conv.awk atmel/tn45def.inc | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
4
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
5
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=attiny45 -DF_CPU=8000000  -I . -I ./added -I ./converted -I./atmel -ffreestanding -g -L,-g -DRAM_START=0x0060 -DSRAM_SIZE=256 -DSTX_PORT=PORTB -DSTX=PB4 -DSRX_PORT=PORTB -DSRX=PB3 added/bootload.S -o bootload.o
6
avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=attiny45 -DF_CPU=8000000  -I . -I ./added -I ./converted -I./atmel -ffreestanding -g -L,-g -DRAM_START=0x0060 -DSRAM_SIZE=256 -DSTX_PORT=PORTB -DSTX=PB4 -DSRX_PORT=PORTB -DSRX=PB3 added/stub.S -o stub.o
7
vars="$(./get_text_addrs.sh 0x07ff)"; \
8
    arch="$(./get_avr_arch.sh -mmcu=attiny45 bootload.o)"; \
9
    echo "arch=$arch";\
10
    echo "$vars"; \
11
    eval "$vars"; \
12
    sed -e "s/@LOADER_START@/$LOADER_START/g" \
13
        -e s"/@ARCH@/$arch/" \
14
        -e s'/@RAM_START@/0x0060/g' \
15
        -e s'/@RAM_SIZE@/256/g' \
16
        -e "s/@STUB_OFFSET@/$STUB_OFFSET/g" \
17
        bootload.template.x > bootload.x; \
18
    avr-ld -N -E -T bootload.x -Map=bootload.map \
19
      --cref bootload.o stub.o -o bootload.elf --defsym Application="$LOADER_START-2"
20
*** Last available byte address for the user program: 0xdfd
21
arch=avr2
22
LOADER_START=0xe00
23
STUB_OFFSET=0x1fe
24
avr-objcopy -O ihex bootload.elf bootload.hex

von Klaus W. (klausw1)


Lesenswert?

Aruinoquäler schrieb:
> Klaus W. schrieb:
>> Da damit das Kompilieren nicht funktionierte,
>
> Ich habe Atmel AVR Studio 4 (4.18) und WinAVR2010 unter Windows 7
> installiert und das funktioniert.
>
> Wenn was nicht funktioniert dann deshalb weil man vielleicht
> vergisst dass das AVR Studio ohne Compiler daherkommt, also
> (möglichst vorher) muss der WinAVR Compiler explizit installiert
> werden.
Nein, das ist es leider nicht. Ein anderes Projekt, was komplett im 
AVRstudio geschrieben ist, funktioniert auch einwandfrei. Scheinbar 
liegt es an dem Mix zwischen C und ASM. Das neue AVRstudio macht da 
Chaos zwischen Winavr und mitgelieferten Tools.
1
------ Rebuild All started: Project: bootload, Configuration: default AVR ------
2
Build started.
3
Project "bootload.cproj" (Clean target(s)):
4
Target "Clean" in file "F:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\bootload.cproj" (entry point):
5
  Task "RunCompilerTask"
6
    Shell Utils Path F:\Program Files (x86)\WinAVR-20100110\bin
7
    F:\Program Files (x86)\WinAVR-20100110\utils\bin\make.exe -C "D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload" -f "Makefile-tiny45" clean 
8
    "F:\Program: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3)
9
  Done executing task "RunCompilerTask" -- FAILED.
10
Done building target "Clean" in project "bootload.cproj" -- FAILED.
11
Done building project "bootload.cproj" -- FAILED.
12
13
Build FAILED.
14
------ Rebuild All started: Project: bootload, Configuration: default AVR ------
15
Build started.
16
Project "bootload.cproj" (default targets):
17
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
18
Target "CoreBuild" in file "F:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\bootload.cproj" (target "Build" depends on it):
19
  Task "RunCompilerTask"
20
    Shell Utils Path F:\Program Files (x86)\WinAVR-20100110\bin
21
    F:\Program Files (x86)\WinAVR-20100110\utils\bin\make.exe -C "D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload" -f "Makefile-tiny45" all 
22
    make: Entering directory `D:/Eigene Dateien/Atmel/Studio7/fastboot-2.9-140709/bootload'
23
    avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=attiny45 -DF_CPU=8000000  -I . -I ./added -I ./converted -I./atmel -ffreestanding -g -L,-g -DRAM_START= -DSRAM_SIZE= -DSTX_PORT=PORTB -DSTX=PB4 -DSRX_PORT=PORTB -DSRX=PB3 added/bootload.S -o bootload.o
24
    ./converted/password.inc: Assembler messages:
25
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\converted\password.inc(13,1): error: non-constant expression in ".if" statement
26
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\converted\message.inc(17,1): error: non-constant expression in ".if" statement
27
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\converted\message.inc(23,1): error: non-constant expression in ".if" statement
28
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(73,1): error: illegal relocation size: 1
29
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(74,1): error: illegal relocation size: 1
30
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(76,1): error: illegal relocation size: 1
31
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(77,1): error: illegal relocation size: 1
32
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(78,1): error: illegal relocation size: 1
33
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(80,1): error: illegal relocation size: 1
34
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(81,1): error: illegal relocation size: 1
35
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(82,1): error: illegal relocation size: 1
36
    make: *** [bootload.o] Error 1
37
    make: Leaving directory `D:/Eigene Dateien/Atmel/Studio7/fastboot-2.9-140709/bootload'
38
  Done executing task "RunCompilerTask" -- FAILED.
39
Done building target "CoreBuild" in project "bootload.cproj" -- FAILED.
40
Done building project "bootload.cproj" -- FAILED.
41
42
Build FAILED.
43
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

von Matthias T. (matthias_199)


Angehängte Dateien:

Lesenswert?

Huhu ,

ich wollte das auch bauen aber leider ;(

matthias@redrain:~/ramdisk/avr/avr8RFM-firmware/bootloader$ make
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega644p -DF_CPU=16000000 
-I . -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding 
-gstabs+ -L,-gstabs+ -DRAM_START= -DSRAM_SIZE= -DSTX_PORT=PORTD 
-DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 added/bootload.S -o bootload.o
./converted/password.inc: Assembler messages:
./converted/password.inc:13: Error: Nicht-konstanter Ausdruck in 
».if«-Anweisung
./converted/message.inc:17: Error: Nicht-konstanter Ausdruck in 
».if«-Anweisung
./converted/message.inc:23: Error: Nicht-konstanter Ausdruck in 
».if«-Anweisung
make: *** [bootload.o] Fehler 1
matthias@redrain:~/ramdisk/avr/avr8RFM-firmware/bootloader$ make -B
./_conv.awk m644Pdef.inc | gawk 
'/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > atmel_def.h
/bin/bash: ./_conv.awk: /usr/bin/gawk: Defekter Interpreter: Datei oder 
Verzeichnis nicht gefunden
/bin/bash: gawk: Befehl nicht gefunden
make: *** [atmel_def.h] Fehler 127


ist gawk nicht mehr teil von ubuntu 14.04.5?

atmel_def.h und mak sind leer ;(

m644Pdef.inc hängt an :)

MFG
Matze

von Matthias T. (matthias_199)


Lesenswert?

sudo apt-get install gawk
 und neue get_avr_arch.sh + chmod +x nicht vergessen :)

von Markus L. (Gast)


Lesenswert?

Hallo,

Ich bin kürzlich auf dieses Projekt gestossen, und finde es Klasse.

Nach etwas rum probieren, habe ich es auch geschafft das ganze 
Zusammenzusetzen und einen funktionierenden Bootloader für den 
Atmega2560 zu kompilieren (PORTD).

Mein Problem: ich müsste den Bootloader soweit bringen das er auf PORTH 
reagiert.

Soweit ich das Problem zurückverfolgen konnte ist PORTH nicht gleich 
anzusprechen wie PORTD.

Das Problem beginnt dann in /added/fastload.inc ab Zeile 180:
1
.macro IOPortInit
2
  sbi SRX_PORT, SRX  ;<= PORTH, PH0
3
  sbi STX_PORT, STX ;<= PORTH, PH1
4
  sbi STX_DDR, STX ;<= DDRH, PH1
5
.endm

avr-gcc meldet Fehler wie:
./added/fastload.inc:42: Error: number must be positive and less than 32

Ähnliche Fehler melden auch /converted/abaud.inc, /converted/command.inc 
sowie /converted/uart.inc (ob es sich um folge Fehler handelt kann ich 
leider nicht beurteilen)

Dies ist soweit auch korrekt, da PORTH definitiv >= 32 ist.

Die relevanten Einträge aus: /atmel/m2560def.inc
1
; Definitions marked "MEMORY MAPPED" are extended I/O ports
2
; and cannot be used with IN/OUT instructions
3
.equ  PORTH  = 0x102  ; MEMORY MAPPED
4
.equ  DDRH  = 0x101  ; MEMORY MAPPED
5
.equ  PINH  = 0x100  ; MEMORY MAPPED

Hat dieses Problem bereits jemand gelöst? Mein Freund Google wusste da 
leider auch nicht weiter.
..oder könnte hier beschreiben wie dies gelöst werden könnte.

Auch muss leider gestehen das meine Assemblerkentnisse gleich null sind. 
Also Anmerkungen wie: Verwende doch STS/LDS würden mir hier auch nicht 
weiterhelfen.

An dieser Stelle schon mal Danke für diesen Bootloader als solches und 
für jeden weiteren Tipp.

mfg, Markus

von Karl M. (Gast)


Lesenswert?

Hallo Markus,
das ist kein richtiges Problem,

sbi, cbi sind nur für bestimmte Adressbereiche nutzbar.

Wir nutzen in unsere Entwicklungsumgebung folgende Macros.
Als Arbeitsregister wird WL verwendet, das muss im Code auf "frei" sein.
1
.macro gCbi
2
.if @0<32
3
cbi  @0,@1
4
.else
5
xIn  WL,@0
6
cbr  WL,(1<<@1)
7
xOut  @0,WL
8
.endif
9
.endmacro
10
11
.macro gSbi
12
.if @0<32
13
sbi  @0,@1
14
.else
15
xIn  WL,@0
16
sbr  WL,(1<<@1)
17
xOut  @0,WL
18
.endif
19
.endmacro

Es folgt also noch umschreiben von IOPortInit:
1
.macro IOPortInit
2
  gSbi SRX_PORT, SRX  ;<= PORTH, PH0
3
  gSbi STX_PORT, STX ;<= PORTH, PH1
4
  gSbi STX_DDR, STX ;<= DDRH, PH1
5
.endmacro

von Karl M. (Gast)


Lesenswert?

Nachtrag,

und man braucht natürlich noch diese beiden Macros
1
.macro xIn
2
.if @1<64
3
in  @0,@1
4
.else
5
lds  @0,@1
6
.endif
7
.endmacro
8
9
.macro xOut
10
.if @0<64
11
out  @0,@1
12
.else
13
sts  @0,@1
14
.endif
15
.endmacro

von Markus L. (Gast)


Lesenswert?

Hallo Karl,

Wow, Danke - das ging aber flott!
werde dies gleich austesten.

Freundlichst, Markus

von Markus L. (Gast)


Lesenswert?

Hallo Karl,

Bin etliche Schritte weitergekommen, in fastload.h:

Im Kopf der Datei
1
#define  WL r26

Neue Macros:
1
.macro gCbi p0 p1
2
.if \p0<32
3
  cbi  \p0,\p1
4
.else
5
  xin  WL,\p0
6
  cbr  WL,(1<<\p1)
7
  xout  \p0,WL
8
.endif
9
.endm
10
11
.macro gSbi p0 p1
12
.if \p0<32
13
  sbi  \p0,\p1
14
.else
15
  xin  WL,\p0
16
  sbr  WL,(1<<\p1)
17
  xout  \p0,WL
18
.endif
19
.endm
20
21
.macro skbs p0, p1
22
.if \p0>0x3F
23
  lds  WL, \p0
24
  sbrs WL, \p1
25
.elseif \p0>0x1F
26
  in   WL, \p0
27
  sbrs WL, \p1
28
.else
29
  sbis \p0, \p1
30
.endif
31
.endm
32
33
.macro skbc p0, p1
34
.if \p0>0x3F
35
  lds WL, \p0
36
  sbrc WL, \p1
37
.elseif \p0>0x1F
38
  in WL, \p0
39
  sbrc WL, \p1
40
.else
41
  sbic \p0, \p1
42
.endif
43
.endm

Die von Dir genannten xin / xout macros waren nicht nötig, die sind 
bereits im /added/compat.h vorhanden.

Angepasst:
1
  .macro  IOPortInit
2
  gSbi  SRX_PORT, SRX
3
  gSbi  STX_PORT, STX
4
  gSbi  STX_DDR, STX
5
  .endm
6
  .macro  TXD_0
7
  gCbi  STX_PORT, STX
8
  .endm
9
  .macro  TXD_1
10
  gSbi  STX_PORT, STX
11
  .endm
12
  .macro  SKIP_RXD_0
13
  skbc  SRX_PIN, SRX
14
  .endm
15
  .macro  SKIP_RXD_1
16
  skbs  SRX_PIN, SRX
17
  .endm

eine Unschönheit habe ich noch, in der /converted/abaud.inc
1
_aba3:
2
  sbiw  twl, 1    ;2
3
  sbci  a0, 0      ;1
4
  SKIP_RXD_0      ;1  wait until RXD = 0
5
  brne  _aba3      ;2 = 6
6
  //breq  timeout

Wenn die letzte Zeile (breq) aktiv ist (wie im Original Code), erhalte 
ich einen Fehler:
/converted/abaud.inc:27:(.text+0x52): relocation truncated to fit: 
R_AVR_7_PCREL against `no symbol'

Bin dem Fehler bereits etwas nachgegangen, allerdings ohne wirklich eine 
Lösung zu finden.

Ohne diese Zeile läuft es durch. allerdings noch ungetestet. Muss leider 
für heute schliessen, werde es aber weiter versuchen.

Es grüsst, Markus

von Markus L. (Gast)


Lesenswert?

Guten Morgen,

Nach etwas weiterer Recherche bin ich auf folgende Lösung gekommen.
1
_aba3:
2
   sbiw  twl, 1    ;2
3
   sbci  a0, 0      ;1
4
   SKIP_RXD_0      ;1  wait until RXD = 0
5
   brne  _aba3      ;2 = 6
6
   rjmp  timeout
Also den breq durch rjmp ersetzt. da der "not equal" case bereits 
abgedeckt ist dürft dies auf das selbe rauskommen. (wie erwähnt hab 
keine ASM Kentnisse).

Wenn ich richtig liege wäre ich um eine kurze Bestätigung froh.
Beginne nun den modifizieren Bootloader auf den Atmega2560 zu testen.

Danke & Gruss, Markus

von Karl M. (Gast)


Lesenswert?

Hallo Markus L.,

ja von der Logik passt es.

Es gibt zwei Sprünge, relativ und direkt, bei deinem mega2560
RJMP k ; -2k <= k < 2k
JMP k ; 0 <= k < 4M

von Markus L. (Gast)


Lesenswert?

Hallo Karl,

Leider harzt es. Wenn ich den BREQ durch JMP / RJMP ersetzte geht der 
bootloader weder auf PORTD, nocht auf PORTH.
Habe nun einen Weg gefunden wie ich den BREQ beibehalten kann (im 
bootload.asm entweder CRC oder VERIFY definieren [=deaktivieren]) dann 
ist die "Sprungadresse" für BREQ wieder in Reichweite.
So kompiliert klappt es dann auf PORTD, allerdings immer noch nicht auf 
PORTH.

Soweit ich es beurteilen kann, klappt eines der neuen Macros nicht wie 
ich es mir vorstelle. Da absolut keine Verbindung via UART aufgebaut 
werden kann.

Werde da mal ansetzen, und berichten falls ich Erfolg habe.

Danke & MFG, Markus

von Karl M. (Gast)


Lesenswert?

Siehe:

Damit muss das Sprungziel erreicht werden:
JMP k ; 0 <= k < 4M

von Leo C. (rapid)


Lesenswert?

1
   sbci  a0, 0      ;1
2
   SKIP_RXD_0      ;1  wait until RXD = 0
3
   brne  _aba3      ;2 = 6
4
   //breq  timeout

> Also den breq durch rjmp ersetzt. da der "not equal" case bereits
> abgedeckt ist dürft dies auf das selbe rauskommen.

Prinzipiell richtig, aber der Befehl "brne  _aba3" wird durch das Macro 
SKIP_RXD_0 ggf. übersprungen, oder eben nicht. Die Kombination 
SKIP/brne/breq ist zusammen also eine 3-fach Verzweigung.

Vielleicht so:
1
        SKIP_RXD_0                      ;1  wait until RXD = 0
2
        brne    _aba3                   ;2 = 6
3
        brne    _aba4
4
        rjmp    timeout
5
_aba4:

von Markus L. (Gast)


Lesenswert?

Hallo Leo,

Danke! dieses Problem wäre gelöst - klappt so.
Kann nun CRC und VERIFY benutzen, allerdings bleibt das Problem das es 
nur auf PORTD/PORTE funktioniert, nicht auf PORTH und PORTJ.

Bin noch am "basteln" mit den Macros:
Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain"

Den #define  WL r26 habe ich auf r20 gesetzt, das einzig freie Register 
(>15), welches nicht bereits irgendwo deklariert war.

Könnte es ein das WL in SKB[x] und g[x]bi makros beist und es deshalb 
nur mit PORTD/E klappt.

Gruss, Markus

von Leo C. (rapid)


Lesenswert?

Für die Ports H/J verlängern sich die Macros um 2 bis 4 Taktzyklen.
Die Funktionen in uart.inc und abaud.inc sind sehr zeitkritisch. 
Möglicherweise wirst Du die Takte neu auszählen und die Funktionen 
entsprechend anpassen müssen.

von Markus L. (Gast)


Lesenswert?

Leo C. schrieb:
> Möglicherweise wirst Du die Takte neu auszählen und die Funktionen
> entsprechend anpassen müssen.

Dies übersteigt leider meine Möglichkeiten, habe keinen Ansatz wie/wo 
ich dies tun könnte :-(

Trotzdem besten Dank und freundliche Grüsse, Markus

von Markus L. (Gast)


Lesenswert?

Offtopic: In meinen Tests habe ich den UpdateLoader verwendet, diesem 
musste ich noch die Signatur für den Atmega2560 beibringen. Falls von 
Interesse, die entsprechend modifizierte Version ist hier zu finden:
Beitrag "Re: UpdateLoader: Benutzeroberfläche für FastBoot AVR-Bootloader"

von Leo C. (rapid)


Lesenswert?

Markus L. schrieb:
> Leo C. schrieb:
>> Möglicherweise wirst Du die Takte neu auszählen und die Funktionen
>> entsprechend anpassen müssen.

> Dies übersteigt leider meine Möglichkeiten, habe keinen Ansatz wie/wo
> ich dies tun könnte :-(

Kann ich mir nicht vorstellen, bzw. kann man das ja ändern.
Mich würde es ja schon reizen, das hinzukriegen, oder Dir auf die 
Sprünge zu helfen, aber da ich das selber gerade nicht brauche, habe ich 
auch keine Zeit dazu. Zufälligerweise habe ich aber festgestellt, daß es 
schon mal jemand hier gemacht hat:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Wenn Du beim GNU Assembler bleiben willst, mußt Du die Anpassungen von 
Michael Hoffmann in Deine Version übertragen.

von Markus L. (Gast)


Lesenswert?

Hallo Leo,

Danke für den Hinweis, hätte ich den früher gefunden - hätte ich mir 
wohl viel Zeit ersparen können. Sehen wir es positiv, musste mich etwas 
mit Assembler beschäftigen und hab etwas gelernt ;-)

Leo C. schrieb:
> Wenn Du beim GNU Assembler bleiben willst, mußt Du die Anpassungen von
> Michael Hoffmann in Deine Version übertragen.

..Will ich; hab mir mal die verschiedenen Patchlevels geholt und 
begonnen zu vergleichen, scheint machbar.

Es grüsst, Markus

von Markus L. (Gast)


Lesenswert?

HEUREKA! ist wie Ostern und Weihnachten am selben Tag - gleich das erste 
Kompilat hat geklappt!

Werde nun noch etwas weiter Testen (ob auch die Ports D/E noch gehen), 
bin sehr zuversichtlich. Dann selbstredend hier hochladen.

von Markus L. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

..einige Tests später, hier die angepasste Version.

Diese Version enthält gegenüber dem letzeten Build in diesem Thread 
einige in der vorhanden Updates, sowie die Anpassungen aus:

https://www.mikrocontroller.net/topic/goto_post/3362478

Meine Anpassungen, weiter oben in diesem Thread sind entsprechend raus, 
da dies bereits von Michael Hoffmann (verm. besser) hinzugefügt wurden.

Beim Testen stellte sich heraus das ich noch einen Takt hinzufügen 
musste. Dieser was nötig damit 115'200 bps auf einem USB-SER Adapter 
(FTDI) klappt. Für RS232 direkt am PC war diese zusätzlich Takt nicht 
nötig, störte aber zumindest in meiner Umgebung nicht.

Konkret: _memmap_delay von 3 auf 4 geändert in der /added/fastload.h
1
;------------------------------  UART delay loop value --------------------
2
#if STX_PORT > 0x1F
3
#define  _memmap_delay_ 4
4
#else
5
#define  _memmap_delay_ 0
6
#endif

Ein grosses Danke an alle!
Es grüsst freundlichst, Markus

von Robert H. (robhoff)


Lesenswert?

Hallo,

hat jemand schon eine Atmega48 mit dem Bootloader bearbeitet?
Bin leider Neuling was das ganze Thema angeht.

Den Bootloader bekomme ich noch drauf das eigentliche Programm dann aber 
nicht.
Hier kann die Verbindung nicht aufgebaut werden. Kann das an den Fuses 
liegen?

Kann eventuell jemand Hilfestellung geben?

Der Atmega48 soll für die TMC262 Schrittmotortreiber von avrsteffen 
sein.
Soll also direkt mit dem Bootloader in der Datei bespielt werden.

von Malte _. (malte) Benutzerseite


Angehängte Dateien:

Lesenswert?

Vielen Dank für die Anpassung an die AVR GCC Toolchain.
Bei mir lief das get_avr_arch.sh Skript nicht mit GCC 4.9.2 (aus Debian 
Stretch)
Da ich offen gesagt auf die schnelle nicht durchgeblickt habe, was das 
Script wie extrahiert, habe ich es für mich angepasst (und mit einem 
ATmega328P erfolgreich getestet).
Die notwendigen .inc Dateien erhält man, wenn man das AVR Studio 4.19 
installiert (WINE):
http://www.microchip.com/avr-support/avr-and-sam-downloads-archive
Der in der Readme genannte Downloadlink für die Includes funktionierte 
nicht mehr. Das 5er Studio installierte (mit diversen Fehlermeldungen) 
zwar mit WINE, enthielt aber keine Includes, bei dem 7er ging gleich der 
Installer nicht mit WINE.

von Arno M. (quirxi)


Lesenswert?

Malte _. schrieb:
> Vielen Dank für die Anpassung an die AVR GCC Toolchain.
> Bei mir lief das get_avr_arch.sh Skript nicht mit GCC 4.9.2 (aus Debian
> Stretch)

Vielen Dank für die Anpassung des Skripts an die neuere AVR Toolchain!
Ich habe mich ein wenig schwer getan, um die richtigen Version der 
diversen Files, welche über den Thread verstreut sind, zu finden.
Deshalb hab ich jetzt eine Version zusammengestellt welche unter einen 
neueren Linux ohne Probleme funktionieren sollte und sie auf:
https://github.com/quirxi/FastBoot-Linux
online gestellt.
Diese Version wurde unter Debian 9.4 (stretch) mittels avr-gcc 4.9.2 
getestet.
Die fehlenden inlcude files für die ATmega328 und ATmega328P Prozessoren 
(m328def.inc und m328Pdef.inc) und die include files für den avr wurden 
hinzugefügt und in das/die Makefile(s) integriert.

von DanielU (Gast)


Lesenswert?

Ich habe jetzt viele Versuche mit einem Atmega328P und diesen letzten 
Build von quirxi (und auch von jdeitmerg 
https://github.com/jdeitmerg/fastboot/ ) ohne Erolg gemacht. Es 
funktioniert nur einmal.
Das AVR habe ich jetzt für ein mega168V ausgetauscht und dann hat alles 
funktioniert. Hat jemand dem 328P wirklich geprüft?

von Uwe S. (de0508)


Lesenswert?

Klar DanielU,

Wenn man sein Makefile für sein Projekt richtig anpasst, die passenden 
Assembler Include hat, dann kann man einen Bootloader erzeugen.
Dann noch die Fusebits passen setzen und schon geht's los.

von quirxi (Gast)


Lesenswert?

Hallo,

bei mir hat es funktioniert. Welche Fehlermeldung hast du denn bekommen?


lg

von DanielU (Gast)


Lesenswert?

Kein Fehlermeldung. Alles läuft zuerst.
The bootloader starts and I am able to upload my program. But only once. 
Next time the client software cannot connect but also the application 
firmware does not start as long as the client is trying to upload code. 
So it seems that the bootloader code is running on the AVR but not 
functioning properly. Maybe it writes something over itself, which makes 
it broken. If the fuse bits were wrong I suppose I would see the 
application code running after reset regardless of state of 
client/uploader.
I have used this bootloader many times on mega168 without problem but 
now with 328P there is this different behavior.
(Please keep responding in German - I am from Sweden so cannot write so 
good, but I understand everything and need to practice!)

von Karl M. (Gast)


Lesenswert?

Hallo DanielU,

Setzte die passenden und hier richtigen Bootloaderflag!

von DanielU (Gast)


Lesenswert?

Karl M,
Meinst du Fuse bits?
Ich verwende für 328P:

LFUSE = 0xe2
HFUSE = 0xde
EFUSE = 0xff

das heist,

BOOTRST = 0
und
BOOTSZ0 = 1
BOOTSZ1 = 1

für reset vektor bei 3F00.

von Karl M. (Gast)


Lesenswert?

Also du nutzt den RC Oszillator mit 8MHz
und dann mit 512 Word (0x3e00) Bootvektor:

-U lfuse:w:0xe2:m -U hfuse:w:0xd4:m -U efuse:w:0xff:m

von DanielU (Gast)


Lesenswert?

So die Mitteilung vom Makescript ist nicht richtig?

*** Note: set BOOTSZ fuses to the word address 0x3f00 ***

von Karl M. (Gast)


Lesenswert?

DanielU schrieb:
> So die Mitteilung vom Makescript ist nicht richtig?
>
> *** Note: set BOOTSZ fuses to the word address 0x3f00 ***

Ok, diese Info habe ich nicht überprüft.

Ich nutze meistens: http://www.engbedded.com/fusecalc/

von DanielU (Gast)


Lesenswert?

So wie weiss man dass 0x3e00 ist die richtige Adresse?
(Schade wenn das Script gibt falsches Information.)

von quirxi (Gast)


Lesenswert?

Hallo Daniel,


ich hab mich leider schon seit einiger Zeit nicht mehr mit der 
Mikrocontroller Programmierung beschäftigt, und müsste selber wieder 
nachlesen, um dir eine halbwegs seriöse Antwort geben zu können.
Hier findest du einen guten Beitrag über die Fuse Bits des 328P:
http://www.martyncurrey.com/arduino-atmega-328p-fuse-settings/

Auf der Herstellerseite unter "Documents" findest du alle Dokumente, die 
man eingentlich benötigt:
https://www.microchip.com/wwwproducts/en/ATMEGA328P

Hier auf Seite 290 werden die Fuse Bits beschrieben:
http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf

Ich kann dir das Buch: "Make: AVR Programming" von Elliot Williams 
wärmstens empfehlen. Ich hab fast alles, was ich über die AVR 
Programmierung weiss aus diesem Buch gelernt, und es hat mir richtig 
Spass gemacht:
https://www.amazon.de/Make-Programming-Learning-Software-Technology/dp/1449355781

von quirxi (Gast)


Lesenswert?

Noch ein Nachtrag:

hier noch 2 Fuse Bit Calculator, der dir bei der Berechnung helfen:

http://www.engbedded.com/fusecalc
http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p

von quirxi (Gast)


Lesenswert?

What else came to my mind:

have you made sure that you did not accidently use the makfile for the 
mega168 ? Or that your makefiles includes the m168def.inc instead of the 
m328Pdef.inc  ?








#ATMEL_INC = ./atmel/m168def.inc
ATMEL_INC = ./atmel/m328Pdef.inc

von DanielU (Gast)


Lesenswert?

quirxi,
Danke für die Web-Tipps.

Ich habe mit Makefile-m328P compiliert. (ln -s Makefile-m328P Makefile).
Hier ist es natürlich richtig:

#ATMEL_INC = ./atmel/m168def.inc
ATMEL_INC = ./atmel/m328Pdef.inc

Es gibt:

$ make
Makefile:131: atmel_def.mak: No such file or directory
./_conv.awk atmel/m328Pdef.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=atmega328p -DF_CPU=8000000  -I 
. -I ./added -I ./converted -I./atmel -I./avr -ffreestanding -g -L,-g 
-DRAM_START=0x0100 -DSRAM_SIZE=2048 -DSTX_PORT=PORTD -DSTX=PD1 
-DSRX_PORT=PORTD -DSRX=PD0 added/bootload.S -o bootload.o
avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega328p -DF_CPU=8000000  -I . 
-I ./added -I ./converted -I./atmel -I./avr -ffreestanding -g -L,-g 
-DRAM_START=0x0100 -DSRAM_SIZE=2048 -DSTX_PORT=PORTD -DSTX=PD1 
-DSRX_PORT=PORTD -DSRX=PD0 added/stub.S -o stub.o
vars="$(./get_bootsection_addrs.sh 0x3fff 0x3f00 0x3e00 0x3c00 )"; \
  arch="$(./get_avr_arch.sh -mmcu=atmega328p 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@/2048/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 0x3f00 ***
arch=avr5
LOADER_START=0x7e00
STUB_OFFSET=0x1fe
avr-objcopy -O ihex bootload.elf bootload.hex


Meine frage zu Dir ist ob die mitteilte Adresse 0x3f00 ist falsch oder 
richtig? Soll es 0x3e00 sein, wie KarlM schreibt?

von Karl M. (Gast)


Lesenswert?

Hallo,

wenn da in der Konsole nach dem Make-Bild - 0x3f00 ausgegeben wurde, 
dann ist dies einzustellen.

In mein Erinnerung hatte ich noch den Attiny45, der nur 512B Word für 
den Bootloader benötigt.

von quirxi (Gast)



Lesenswert?

DanielU schrieb:
> Meine frage zu Dir ist ob die mitteilte Adresse 0x3f00 ist falsch oder
> richtig? Soll es 0x3e00 sein, wie KarlM schreibt?

Meiner Meinung nach muss BOOTSZ auf 0x3f00 eingestellt werden.
Siehe auch:
https://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger#Einstellen_der_Fuses
und:
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf 
(Seite 239 / Table 26-7)
und angehängte Screenshots.

Lass es mich wissen, ob es funktioniert, ok?

von DanielU (Gast)


Angehängte Dateien:

Lesenswert?

Hmm, ihr sei beide richtig. Wenn ich ins hex-file gucke beginnt es bei 
0x7e00 und das ist die Word-Adresse 0x3f00.
Mit oscilloscope sehe ich jetzt das Bootloader code antwortet dem PC 
(Raspberry Pi) aber kein Connection Established. (Sehe Bild.)
Aber was lustig ist ist das es immer funktioniert einmal, wenn nur 
Bootloader auf AVR programmiert ist.
(Und ja, ich weiss das Raspberry Pi gibt 3.3V Pegel und AVR hier 5V.)

von quirxi (Gast)


Lesenswert?

Hallo,

mit welchen Parametern hast du die Fuses gebrannt?

hier ein Beispiel:

------------

avrdude -p m328p -c usbasp -P usb -e -U lfuse:w:0xff:m -U hfuse:w:0xde:m 
-U efuse:w:0x05:m

Beispiel für einen Arduino Pro Mini 16 MHz Qwarz 5V mit Atmega328p

--------------

von DanielU (Gast)


Lesenswert?

qirxi, wie ich oben geschrieben habe:

LFUSE = 0xe2
HFUSE = 0xde
EFUSE = 0xff

das heist,

BOOTRST = 0
und
BOOTSZ0 = 1
BOOTSZ1 = 1

für reset vektor bei 3F00.

BUT, I think I now know the problem!
And it is not in the AVR but in the connecting side. The program I load 
into my AVR uses the serial port. When I start the lboot/bootloader the 
first time, when the chip is blank, it readily programs the code. But 
the next time the application software is running and the data sent from 
the PC/RaspberryPi is looped back, together with other data sometimes. 
When I then reset the AVR, the RaspberryPi serial port, or the 
bootloader program, has already gone into a state where it is not 
receptive anymore and then I get the situation as in the picture above. 
The program asks for the bootloader and the bootloader on the AVR 
replies, but the program cannot receive this and hence everything just 
stops. If I, on the other hand, put a jumper on the reset pin of the 
AVR, stop the bootloader program, start it again and then release the 
jumper, then it programs the AVR fine!
So it seems that the problem is in the bootloader client/PC-side 
software, or in the Raspberry Pi serial port. Don't you agree?

von quirxi (Gast)


Lesenswert?

Hallo Daniel,

ich hoffe, dass ich dich richtig verstanden habe.
As far as I remember you always have to reset the chip over the reset 
pin when you want to start the bootloader.
The fuse BOOTRST = 0 makes that not the program at address 0x00 is 
started but the bootloader at address 0x3f00. The bootloader then looks 
at the serial port if there is some data (aka, program code) waiting.
If yes it reads this code and writes it into the program memory at 0x00. 
If no it jumps to the program memory at 0x00 and the program itself is 
loaded and executed and the bootloader ends here.
So if you don't reset the avr it wont jump into bootloader mode and you 
cannot flash it. And if you wait too long after a reset before you 
transfer the program code it is too late and the bootloader has already 
finished and the old program itself is executed.
Hope that I did fully understand how it works and my simplified 
description makes sense?
I am not sure what your program is actually doing or not.

Here is a short description how it works on the Arduino: 
https://playground.arduino.cc/Main/ArduinoReset/

So it looks like your client Raspberry Pi does not trigger the reset 
before trying to flash the program?

von DanielU (Gast)


Lesenswert?

quirxi,

Correct. I agree with your description and I am aware that I have to 
reset the device to make it start at the bootloader adress, from where 
it normally continue to 0x00 if there is no data on serial port.
But, in this case, if I start the lboot program on the Raspberry Pi and 
then hit reset manually on the AVR (pulling reset pin low with a 
switch), the system goes into a situation where the data in the 
oscilloscope picture above is transmitted and received over and over 
again. But nothing more happens.
If I instead put the AVR into continuous reset (or power it off), then 
start lboot on the Raspberry Pi, and then activate the AVR by releasing 
reset pin to high (or power the AVR up) - it works as it should.
The client Raspberry Pi does not trigger the reset, I chose to do that 
manually, but I find it strange that it goes into the never ending loop 
if I do it like in the first case.

von Malte _. (malte) Benutzerseite


Lesenswert?

Bist du sicher, dass ansonsten deine Applikation nichts auf dem 
seriellen Port sendet?
Wenn der AVR läuft (Anwendung, nicht Bootloader), der lboot vom 
Raspberry Daten hinschickt und dein Programm irgendwie darauf antwortet, 
geht der lboot eventuell in einen anderen Zustand und wenn dann Reset am 
AVR gedrückt wird, sendet lboot eventuell nicht mehr das passende.

Für mich war die normale Prozedur immer:
1. AVR Powerdown
2. PC Programm starten (läuft das Prog vorher schon wird der AVR unter 
Umständen parasitär per RS232 versorgt)
3. AVR mit Spannung versorgen

von DanielU (Gast)


Lesenswert?

Malte_,
Yes, my application uses the serial port. So what I see is probably the 
same as what you have seen. The lboot program receives random data and 
goes into a state where it expects some other data that it doesn't 
receive and this causes it to fail when the AVR is reseted. This is 
quite logical and I am sorry that I created a lot of confusion here. I 
really thought the problem was related to the bootloader AVR code or 
fuse bits. I got confused by the fact that it seemed to work for mega168 
but not mega328P, but I realize that I must have done the reset 
procedure differently between these cases. Now I have it all running on 
the mega328P if I do the reset correct.
Thank you all for your help and comments.

von quirxi (Gast)


Lesenswert?

At least we have all learned something new again ?

von Randy B. (rbrecker)


Lesenswert?

Ich versuche fastboot mit fboot/linux für eine tiny85 zum Laufen zu 
bringen. Der Bootloader ist per ISP geflasht auch den tiny. Der läuft 
mit 1MHz, was auch so im Bootloader eingetragen ist.

Ich benutze einen CP2102 USB/UART. Damit ist Ruhepegel auf High.

Ich habe für die Verbindung von TXD nach RXD einen 4K7 Widerstand 
eingesetzt (OneWire-Mode).

Leider wartet fboot vergebens auf eine Antwort vom tiny85. Es wird zwar 
ein paar Bytes gesendet mit 9600 Baud, aber der Tiny sendet keine 
Antwort.

Was mich wundert, ist das der Low-Pegel für eine 1 nur bis auf ca 2V 
runter geht. Vermute, der wird dann nicht erkannt vom tiny. Habe auch 
eine Diode versucht, damit komme ich auf 0,9V runter.

Frage: ist das jetzt mit dem Ruhepegel auf High (TTL) so richtig?

Hinweise?

von Karl M. (Gast)


Lesenswert?

Hallo,

1MHz?

ich nutze entweder 8MHz oder 16MHz und jeder muss die richtigen Fusebits 
einstellen, so dass auch ein Bootloader schreiben darf!

von Randy B. (rbrecker)


Lesenswert?

Karl M. schrieb:
> Hallo,
>
> 1MHz?

Natürlich 8MHz ... sorry.

>
> ich nutze entweder 8MHz oder 16MHz und jeder muss die richtigen Fusebits
> einstellen, so dass auch ein Bootloader schreiben darf!

Jetzt habe ich das im two-wire Modus ausprobiert.

Der PC sendet fleißig: 0x0D, 0x70, 0x65, 0x64, 0x61, 0xff

Der µC antwortet nicht auf seinem Sende-Pin.

Das sind die fuses:
-U lfuse:w:0xe2:m -U hfuse:w:0xd7:m -U efuse:w:0xfe:m

So habe ich den Bootloader geflashed:

avrdude -p attiny85 -P usb -c avrisp2 -U bootload.elf

Ich habe das Makefile-tiny85 benutzt, und dort die Pins wie auch die 
Taktfrequenz angepasst.

Hinweise?

von Karl M. (Gast)


Lesenswert?

Hallo,

das ist schon mal entgegen dem mir zu Verfügung stehenden Manual:

# avrdude -p attiny85 -P usb -c avrisp2 -U bootload.elf
---------------------------------------->^^^^^^^^^^^^^^

Ich kann nur direkt binär Dateien, i.A. *.bin oder als intel HEX-Datei 
kodiert, i.A. *.hex schreiben!

der markierte Abschnitt: "-U flash:w:<dateiname>,a"

Ich würde die Fuse-Bits wie folgt nutzen, bei Vcc=5V:

"-U lfuse:w:0xe2:m -U hfuse:w:0xd4:m -U efuse:w:0xfe:m"

Siehe: http://www.engbedded.com/fusecalc/

von Karl M. (Gast)


Lesenswert?

Korrektur:

der markierte Abschnitt: "-U flash:w:<dateiname>:a"

abgerutscht.

von Randy B. (rbrecker)


Lesenswert?

Karl M. schrieb:
> Hallo,
>
> das ist schon mal entgegen dem mir zu Verfügung stehenden Manual:
>
> # avrdude -p attiny85 -P usb -c avrisp2 -U bootload.elf
> ---------------------------------------->^^^^^^^^^^^^^^
>
> Ich kann nur direkt binär Dateien, i.A. *.bin oder als intel HEX-Datei
> kodiert, i.A. *.hex schreiben!

Nein: avrdude kann auch .elf

>
> der markierte Abschnitt: "-U flash:w:<dateiname>,a"
>
> Ich würde die Fuse-Bits wie folgt nutzen, bei Vcc=5V:
>
> "-U lfuse:w:0xe2:m -U hfuse:w:0xd4:m -U efuse:w:0xfe:m"

Das ist nur brown-out detection, hier unrelevant.

von Karl M. (Gast)


Lesenswert?

Hallo,

meine Referenz Avrdude, man avrdude oder

# https://www.cs.ou.edu/~fagg/classes/general/atmel/avrdude.pdf
Seite 12

Für ELF finde ich keine Beschreibung mit dieser Syntax!

von Karl M. (Gast)


Lesenswert?

Hallo Randy B.,

Ich schrieb ja, das ich es so mache und Du Ideen sammelst.

Randy B. schrieb:
> Das ist nur brown-out detection, hier unrelevant.

Ist je nach Spannungsversorgung schon wichtig, insbesondere wenn man den 
EEPROM verwendet.

Aber auch der Flash braucht eine stabile und belastbare 
Spannungsversorgung.

von Randy B. (rbrecker)


Lesenswert?

Karl M. schrieb:
> Hallo,
>
> meine Referenz Avrdude, man avrdude oder
>
> # https://www.cs.ou.edu/~fagg/classes/general/atmel/avrdude.pdf
> Seite 12
>
> Für ELF finde ich keine Beschreibung mit dieser Syntax!

Manual page:

-U memtype:op:filename[:format]
Perform a memory operation as indicated.  The memtype field specifies 
the memory type to operate on.  The available memory types are 
device-depen‐
dent, the actual configuration can be viewed with the part command in 
terminal mode.  Typically, a device's memory configuration at least 
contains
the memory types flash and eeprom.  All memory types currently known 
are:
calibration  One or more bytes of RC oscillator calibration data.
eeprom       The EEPROM of the device.
efuse        The extended fuse byte.
flash        The flash ROM of the device.
fuse         The fuse byte in devices that have only a single fuse byte.
hfuse        The high fuse byte.
lfuse        The low fuse byte.
lock         The lock byte.
signature    The three device signature bytes (device ID).
fuseN        The fuse bytes of ATxmega devices, N is an integer number 
for each fuse supported by the device.
application  The application flash area of ATxmega devices.
apptable     The application table flash area of ATxmega devices.
boot         The boot flash area of ATxmega devices.
prodsig      The production signature (calibration) area of ATxmega 
devices.
usersig      The user signature area of ATxmega devices.
The op field specifies what operation to perform:
r        read device memory and write to the specified file
w        read data from the specified file and write to the device 
memory
v        read data from both the device and the specified file and 
perform a verify
The filename field indicates the name of the file to read or write.  The 
format field is optional and contains the format of the file to read or
write.  Format can be one of:
i    Intel Hex
s    Motorola S-record
r    raw binary; little-endian byte order, in the case of the flash ROM 
data
e    ELF (Executable and Linkable Format)
m    immediate; actual byte values specified on the command line, 
separated by commas or spaces.  This is good for programming fuse bytes 
without
having to create a single-byte file or enter terminal mode.
a    auto detect; valid for input only, and only if the input is not 
provided at stdin.
d    decimal; this and the following formats are only valid on output. 
They generate one line

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karl M. schrieb:
> Für ELF finde ich keine Beschreibung mit dieser Syntax!

Nun, dann solltest du dir vielleicht keine 3rd-party documentation 
ansehen, wenn du eine definitive Referenz haben möchtest.

https://www.nongnu.org/avrdude/user-manual/avrdude_4.html#Option-Descriptions

Fast ganz unten hast du die Beschreibung der -U-Option, und dort findest 
du unter format auch ELF.

Die von dir verlinkte Doku beschreibt Version 5.1, mittlerweile sind wir 
bei 6.3 (und eine neue Version ist eigentlich schon lange überfällig).

: Bearbeitet durch Moderator
von Karl M. (Gast)


Lesenswert?

Hallo Randy B. schrieb:

Danke für die Korrektur, unter "man avrdude" ist der Parameter gelistet.

Fann beleibt nur das Aufrufformat für eine korrekte Funktion übrig.

von Karl M. (Gast)


Lesenswert?

Danke Jörg W. schrieb:
> Nun, dann solltest du dir vielleicht keine 3rd-party documentation
> ansehen, wenn du eine definitive Referenz haben möchtest.
>
> https://www.nongnu.org/avrdude/user-manual/avrdude_4.html#Option-Descriptions

Da habe ich nicht aufgepasst und habe Avrdude Version 5.1 auch noch in 
meinem Pfad.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karl M. schrieb:
> Da habe ich nicht aufgepasst und habe Avrdude Version 5.1 auch noch in
> meinem Pfad.

Dann hast du natürlich wirklich eine ziemlich angestaubte Version.

Die Release Notes (aka. "NEWS") sagen, dass ELF-Support in Version 6.0 
hinzu gekommen ist. Das war immerhin schon im Jahr 2013.

: Bearbeitet durch Moderator
von Malte _. (malte) Benutzerseite


Lesenswert?

Also für den Attiny84 hatte ich den Bootloader damals in Benutzung. Der 
ist ja ziemlich ähnlich zu dem Attiny85.
Bootloader .hex, Beschreibung welche Fuses wie gesetzt sind und welche 
Version des PC Programms ich verwendet hab und wie der Aufruf des 
Bootloaders war, gibt es alles in der Software zu meinem Projekt von 
damals:
http://www.marwedels.de/malte/fahrradlader/

von Randy B. (rbrecker)


Lesenswert?

Wenn ich mir das generierte File des Bootloaders ansehe, dann fehlt dort 
bei 0x0000 doch der Sprung zum Bootloader?
1
bootload.elf:     file format elf32-avr
2
Disassembly of section .text:
3
00001e00 <init>:
4
1e00:       f8 94           cli
5
1e02:       6f e5           ldi     r22, 0x5F       ; 95
6
1e04:       6d bf           out     0x3d, r22       ; 61
7
1e06:       62 e0           ldi     r22, 0x02       ; 2
8
1e08:       6e bf           out     0x3e, r22       ; 62
9
1e0a:       22 24           eor     r2, r2
10
1e0c:       33 24           eor     r3, r3
11
1e0e:       a8 95           wdr
12
1e10:       61 b5           in      r22, 0x21       ; 33
13
1e12:       60 61           ori     r22, 0x10       ; 16
14
1e14:       7f e0           ldi     r23, 0x0F       ; 15
15
1e16:       61 bd           out     0x21, r22       ; 33
16
1e18:       63 fd           sbrc    r22, 3
17
1e1a:       71 bd           out     0x21, r23       ; 33
18
1e1c:       c3 9a           sbi     0x18, 3 ; 24
19
1e1e:       c4 9a           sbi     0x18, 4 ; 24
20
1e20:       bc 9a           sbi     0x17, 4 ; 23
21
1e22:       21 e0           ldi     r18, 0x01       ; 1
22
1e24:       30 ea           ldi     r19, 0xA0       ; 160

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Randy B. schrieb:
> Wenn ich mir das generierte File des Bootloaders ansehe, dann fehlt dort
> bei 0x0000 doch der Sprung zum Bootloader?

Ein Bootloader wird nicht explizit angesprungen, sondern implizit durch 
die entsprechende Fuse direkt nach dem Reset von der Hardware aktiviert.

Deshalb ist es auch wichtig, dass die Fuses (es gibt mehrere Optionen 
für die Größe des Bootloaders) zum tatsächlichen Code und dessen 
Basisadresse passen.

von Randy B. (rbrecker)


Lesenswert?

Jörg W. schrieb:
> Randy B. schrieb:
>> Wenn ich mir das generierte File des Bootloaders ansehe, dann fehlt dort
>> bei 0x0000 doch der Sprung zum Bootloader?
>
> Ein Bootloader wird nicht explizit angesprungen, sondern implizit durch
> die entsprechende Fuse direkt nach dem Reset von der Hardware aktiviert.

Beim tiny85? Der hat doch kein BootRST.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Randy B. schrieb:
> Beim tiny85? Der hat doch kein BootRST.

Stimmt.

Dann ist man auf die Kooperation der im Flash ab Adresse 0 befindlichen 
Applikation angewiesen, denn diese muss aktiv den Bootloader anspringen.

Solange es noch keine solche Applikation gibt, hat der Flash durchweg 
0xFFFF, was beim AVR wie ein NOP gewertet wird. Es werden also dann 
einfach eine größere Zahl NOPs durchlaufen, danach startet der 
Bootloader ganz normal.

von Randy B. (rbrecker)


Lesenswert?

Jörg W. schrieb:
> Randy B. schrieb:
>> Beim tiny85? Der hat doch kein BootRST.
>
> Stimmt.
>
> Dann ist man auf die Kooperation der im Flash ab Adresse 0 befindlichen
> Applikation angewiesen, denn diese muss aktiv den Bootloader anspringen.
>
> Solange es noch keine solche Applikation gibt, hat der Flash durchweg
> 0xFFFF, was beim AVR wie ein NOP gewertet wird. Es werden also dann
> einfach eine größere Zahl NOPs durchlaufen, danach startet der
> Bootloader ganz normal.

Ok, was mache ich, wenn der AVR nicht mehr jungfräulich ist. Sprich, wie 
bekomme ich an die Adresse 0x0 den Sprung zum Bootloader? Muss das ein 
spezielles Linkerskript erledigen?

Ich nehme an, der fastboot nach dem timeout dann einfach an die erste 
Instruktion nach dem Interruptvektor springt?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Randy B. schrieb:
> Ok, was mache ich, wenn der AVR nicht mehr jungfräulich ist.

Wenn du den Bootloader programmierst, machst du doch sowieso vorher 
einen chip erase.

von Karl M. (Gast)


Lesenswert?

Hallo

Randy B. schrieb:
> Ok, was mache ich, wenn der AVR nicht mehr jungfräulich ist. Sprich, wie
> bekomme ich an die Adresse 0x0 den Sprung zum Bootloader? Muss das ein
> spezielles Linkerskript erledigen?
>
> Ich nehme an, der fastboot nach dem timeout dann einfach an die erste
> Instruktion nach dem Interruptvektor springt?

Der Bootloader merkt sich den Einsprung auf den Reset Vektor 0x0000 
(Steht in der HEX-Datei des zu programmierenden Programms) und speichert 
anstatt seine Eigene - die Startadresse des Bootloaders.

Bei mir läuft das seit Jahren hervorragend.

von Randy B. (rbrecker)


Angehängte Dateien:

Lesenswert?

Fastboot im Zweidraht-Modus läuft nun erstmal auf einem atmega88p und 
einem atmega1284p. Soweit so gut.

Nun habe ich fastboot für one-wire konfiguriert (RX/TX beide auf PD0). 
Damit geht es nicht.

Schaue ich mir den TX-Ausgang des USB/Seriell-Wandlers an (fb01) sieht 
alles gut aus. Schließe ich nun über den 4k7-Widerstand den Ausgang 
ebenfalls an PD0 an, ergibt sich das Bild fb02. Der Low-Pegel stimmt 
nicht. Nehme ich stattdessen eine Diode, geht der Low-Pegel zwar bis auf 
0,8V runter, funktioniert aber trotzdem nicht: keine Antwort des µC.

von Randy B. (rbrecker)


Lesenswert?

Sorry für die Unklarheit: im obigen Post sind beide Diagramme gemessen 
am PD0 des µC.

von Randy B. (rbrecker)


Lesenswert?

Ok, hatte oben noch gelesen, dass es ggf. Probleme mit >64k gibt. Also 
jetzt noch einen m32 ausprobiert: gleiches Ergebnis: twowire geht 
sofort, onewire nicht.

von Randy B. (rbrecker)


Lesenswert?

See ich das richtig, dass im ONEWIRE eine "1" (low-pegel) durch
1
  .macro  TXD_1
2
  cbi  STX_DDR, SRX    ; weak pullup = 1
3
  .endm

erzeugt werden soll? Also es wird nur auf input umgeschaltet? Wenn der 
USB/Serial-Wandler an RX aber ebenfalls pullups hat, kann das ja nicht 
funktionieren.

von Karl M. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Randy B.,

bei mir sieht die Beschaltung, wie ähnlich aus.

Quelle: habe ich mal irgendwo gefunden.

von Randy B. (rbrecker)


Lesenswert?

Karl M. schrieb:
> Hallo Randy B.,
>
> bei mir sieht die Beschaltung, wie ähnlich aus.

Und wie sieht sie genau aus?
Welchen USB/Seriell-Wandler bzw. Schnittstelle hast Du?

von Karl M. (Gast)


Lesenswert?

Randy B. schrieb:
> Karl M. schrieb:
>> Hallo Randy B.,
>>
>> bei mir sieht die Beschaltung, wie ähnlich aus.
>
> Und wie sieht sie genau aus?
> Welchen USB/Seriell-Wandler bzw. Schnittstelle hast Du?

4,7K, 1N4148 und liefert einen TTL (5V) RS232 Pegelbezug, dann einen 
RS232-Wandler (MAX232, Pegel +/-9V) und anschließend eine FT232RL in 
Eigenbau mit erweiterter EMV-Filterbaugruppe.

von Randy B. (rbrecker)


Lesenswert?

Karl M. schrieb:
> Randy B. schrieb:
>> Karl M. schrieb:
>>> Hallo Randy B.,
>>>
>>> bei mir sieht die Beschaltung, wie ähnlich aus.
>>
>> Und wie sieht sie genau aus?
>> Welchen USB/Seriell-Wandler bzw. Schnittstelle hast Du?
>
> 4,7K, 1N4148 und liefert einen TTL (5V) RS232 Pegelbezug, dann einen
> RS232-Wandler (MAX232, Pegel +/-9V) und anschließend eine FT232RL in
> Eigenbau mit erweiterter EMV-Filterbaugruppe.

Kannst Du die Schaltung mal genau posten bitte.

von Randy B. (rbrecker)


Angehängte Dateien:

Lesenswert?

Anbei noch zwei LA Mitschnitte:

ow.png: OneWire Modus
tw.png: TwoWire Modus

Im TW-Modus sieht man

- nach dem dem Reset ist Debug0 auf L
- nach dem autobaud geht Debug0 auf H
- nach dem Erkennen des Passwortes geht Debug1 auf H
- nach dem Senden des Connect geht Debug0 wieder auf L

(in dem Bild ist RX nicht verbunden)

IM OW-Modus sieht man
- nach dem dem Reset ist Debug0 auf L
- nach dem autobaud geht Debug0 auf H

Das Passwort wird nicht erkannt (Debug1 geht nicht auf H)

Das ist etwas merkwürdig: denn zumindest bis zum Erkennen des Passwortes 
sollte es keine Rolle spielen, ob im TW oder OW-Modus gearbeitet wird 
...

von Karl M. (Gast)


Lesenswert?

Randy B. schrieb:
> Kannst Du die Schaltung mal genau posten bitte.

Den hast Du im PDF.

Der Rest ist nicht öffentlich, es sind von Außen gesehen mehrere RS232 
(+-9V) Schnittstellen am PC, auf die man über Device /dev/ttypUSB* 
zugreifen kann.

ID 0403:6001 Future Technology Devices International, Ltd FT232 
USB-Serial (UART) IC

von Randy B. (rbrecker)


Lesenswert?

Karl M. schrieb:
> Randy B. schrieb:
>> Kannst Du die Schaltung mal genau posten bitte.
>
> Den hast Du im PDF.

Den hattest Du als "so ähnlich" bezeichnet.

>
> Der Rest ist nicht öffentlich, es sind von Außen gesehen mehrere RS232
> (+-9V) Schnittstellen am PC, auf die man über Device /dev/ttypUSB*
> zugreifen kann.
>
> ID 0403:6001 Future Technology Devices International, Ltd FT232
> USB-Serial (UART) IC

Welche Version benutzt Du denn von fastboot?
Den ersten Fehler darin habe ich schon gefunden, und nun wird auch das 
Passwort richtig erkannt.

von Karl M. (Gast)


Lesenswert?

Hallo Randy B.,


ich nutze ein Linux Programm

=================================================
|           BOOTLOADER, Target: V2.1            |
=================================================
No hexfile specified!
./booloader [-d /dev/ttyS0] [-b 9600] -[v|p] file.hex
-d Device
-b Baudrate
-v Verify
-p Programm

Author: Andreas Butti (andreasbutti@bluewin.ch)

von Randy B. (rbrecker)


Lesenswert?

Karl M. schrieb:
> Hallo Randy B.,
>
>
> ich nutze ein Linux Programm
>
> =================================================
> |           BOOTLOADER, Target: V2.1            |
> =================================================
> No hexfile specified!
> ./booloader [-d /dev/ttyS0] [-b 9600] -[v|p] file.hex
> -d Device
> -b Baudrate
> -v Verify
> -p Programm
>
> Author: Andreas Butti (andreasbutti@bluewin.ch)

Das (fboot) nutze ich auch, aber das meine ich nicht.
Sondern auf dem µC (fastboot): https://github.com/jdeitmerg/fastboot

von Karl M. (Gast)


Lesenswert?

Ok,

fastboot-2.9 Version 140709

von Randy B. (rbrecker)


Lesenswert?

Karl M. schrieb:
> Ok,
>
> fastboot-2.9 Version 140709

Von welcher Quelle?
Oder kannst Du mir genau die Version zur Verfügung stellen?

von Randy B. (rbrecker)


Lesenswert?

Ok, vergesst das alles.
Ich habe meinen OneWire-Bootloader gefunden. Und es hat gerade ganze 
7min gedauert, alles aufzusetzen, den Bootloader zu flashen und das 
erste blinkie zur transferieren.
Echt krass! Super Doku, super Code!
Fastboot ist Geschichte für mich ... Und meinen bisher präferierten 
TwoWire-Bootlader Optiboot werde ich wohl nur noch für alte Projekte 
verwenden.

von Thomas N. (tonevi)


Angehängte Dateien:

Lesenswert?

Auf der Basis von fastboot_build26.tar.gz habe ich der Anleitung im 
README folgend einen Bootloader für den ATmega328P erstellt. Dieser 
funktioniert auf den 1. Blick perfekt: Die Anwender Firmware lässt sich 
in den unteren Teil des SRAM flashen, und die Firmware macht danach auch 
was sie soll.

Wenn ich den Flash Speicher allerdings mit einem externen Programmer 
auslese, fällt auf, dass hinter dem Ende meines Programms (in dem Fall 
bis zur Adresse 0x3FF = 1023) weiterer Code steht und nicht wie erwartet 
FF FF..

Habe ich da noch irgendwas bei der Konfiguration falsch gemacht oder ist 
der 1024 Byte Buffer nicht richtig initialisiert?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Selbst wenn: würde ja nicht stören.

Korrekterweise müsste man den Puffer mit 0xff vorbelegen.

von Raph (Gast)


Lesenswert?

Jörg W. schrieb:
> Selbst wenn: würde ja nicht stören.

Doch! Sollte sein Programm aus irgendeinem Grund dort hineinspringen, so 
führt er Code aus. Bei einem 0xFF gingegen (NOP) läuft er zum Ende durch 
und macht ggf. einen Watchdog-Reset

> Korrekterweise müsste man den Puffer mit 0xff vorbelegen.

Korrekt.

Eventuell lag im Flash noch was drinne? Würde aber bedeuten das er nicht 
gelöscht wurde. Oder sein Programm schreibt als EEPROM-Ersatz dort 
herum.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Raph schrieb:
> Sollte sein Programm aus irgendeinem Grund dort hineinspringen

… dann macht es ohnehin irgendwas, und Hopfen und Malz sind verloren. 
Es ist dann ziemlich egal, ob nun in der Folge ein (unerwarteter) Reboot 
oder was ganz anderes passiert. Es hätte schließlich stattdessen genauso 
gut an eine völlig andere Stelle des Flashs hüpfen können, inklusive 
"inmitten" eines Mehrwort-Befehls oder in Flash-Daten hinein.

von Oliver S. (oliverso)


Lesenswert?

Raph schrieb:
> Doch! Sollte sein Programm aus irgendeinem Grund dort hineinspringen, so
> führt er Code aus.

Das ist natürlich ein zwingender Grund ;)
Allerdings ist ein Programm, was "aus irgend einem Grund" unkontrolliert 
irgendwohin springt, doch eher ein Programmierfehler, und kein 
Normalzustand.

Oliver

von Thomas N. (tonevi)


Lesenswert?

Mein MiniPro Programmierer ist so konfiguriert, dass er vor dem Flashen 
das SRAM komplett löscht. EEPROM Zugriffe hat meine Anwender Firmware 
nicht. Der zusätzliche Code muss also von der Bootloader Firmware 
stammen. Es ist schon richtig, dass der Code nicht stört, aber unschön 
ist es allemal. Bin ich der erste, der darüber gestolpert ist?

von Oliver S. (oliverso)


Lesenswert?

Thomas N. schrieb:
> Wenn ich den Flash Speicher allerdings mit einem externen Programmer
> auslese, fällt auf, dass hinter dem Ende meines Programms (in dem Fall
> bis zur Adresse 0x3FF = 1023) weiterer Code steht und nicht wie erwartet
> FF FF..

Dein Programm mit 231 bytes braucht zwei flash pages a 128 byte, da 
sollte eigentlich nach 256 Bytes nichts mehr programmiert werden.

Kannst du den bootloader im Sourceode hier mal hochladen?

Oliver

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Thomas N. schrieb:
> Mein MiniPro Programmierer ist so konfiguriert, dass er vor dem Flashen
> das SRAM komplett löscht.

Ein Bootloader kann niemals „alles“ löschen, er muss daher selektiv 
löschen.

Vermutlich jedoch löscht dein Bootloader die entsprechende Page 
ordentlich (sonst könnte er keine sinnvollen Bits programmieren), aber 
der zum anschließenden Beschreiben der Page benutzte Buffer hat einen 
zufälligen Inhalt statt 0xff. Der Buffer wird dann von den ankommenden 
Daten überschrieben (und damit korrekt programmiert), nur der Rest 
zwischen Ende der Daten und Ende der Page ist Müll (der aber eigentlich 
nicht stört).

von Thomas N. (tonevi)


Angehängte Dateien:

Lesenswert?

Hallo Oliver,

anbei der von mir verwendete Source Code.

von Thomas N. (tonevi)


Lesenswert?

@Jörg
den Bootloader habe ich mit dem externen MiniPro geflasht. Hierbei wurde 
das gesamte SRAM vom MiniPro (nicht vom Bootloader) gelöscht - das habe 
ich verifiziert. Erst nach der Übertragung meines Anwenderprogramms per 
Bootloader und erneutem Auslesen des M328 per MiniPro war der 
zusätzliche Code vorzufinden, er ist also definitiv beim "bootloaden" 
entstanden.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Thomas N. schrieb:
> er ist also definitiv beim "bootloaden" entstanden.

Daran hatte ich nicht den leisesten Zweifel.

von Thomas N. (tonevi)


Lesenswert?

Ich habe nun zu Beginn von fastload.inc folgende Zeilen zum Löschen von 
PROGBUFF ergänzt:
1
  ldi a0, 0xff    ; SRAM Puffer löschen
2
  ldi xl, lo8(PROGBUFF)
3
  ldi xh, hi8(PROGBUFF)
4
ClrLoop:
5
  st x+, a0
6
  cpi xh, hi8(PROGBUFFEND)
7
  brlo ClrLoop
8
  cpi xl, lo8(PROGBUFFEND)
9
  brlo ClrLoop

Damit wandert mein Bootloader Start zwar von 0x3F00 auf 0x3E00, aber die 
undefinierten Code Fragmente hinter meinem Anwenderprogramm sind 
verschwunden.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Wenn es dich glücklich macht. ;-) Wie gesagt: Code, der gar nicht 
erreicht werden kann, ist letztlich dem Prozessor wurscht. Ist also ein 
rein ästhetisches Problem gewesen.

von Karl M. (Gast)


Lesenswert?

Thomas N. schrieb:
> Ich habe nun zu Beginn von fastload.inc folgende Zeilen zum
> Löschen von ...

Das hat was von Wettbewerb, für die Funktion des Bootloaders ist der 
Patch unnötig.

von Oliver S. (oliverso)


Lesenswert?

Thomas N. schrieb:
> Ich habe nun zu Beginn von fastload.inc folgende Zeilen zum Löschen von
> PROGBUFF ergänzt:

Eigentlich fehlt da beim schreiben auch noch eine Abfrage, damit da 
nicht unnötig der ganze buffer ins Flash geschrieben wird, wenn der gar 
nicht voll ist.

Und dann hat in bootload.template.x die bss-Sgement-Adresse eine 0 zu 
viel, die lautet 0x800000, nicht 0x8000000

Das  hat aber wohl auf die Funktion des Programms keine Auswirkung, da 
bss eh nicht initialisiert wird.

Oliver

: Bearbeitet durch User
von Hans-Hubert Grendel (Gast)


Lesenswert?

Moin Männers,

irgendwie bin ich zu Blöd den Bootloader zu Kompilieren. Ne hex-File 
bekomm ich mal nicht raus. Immer nur die Fehlermeldung

Severity  Code  Description  Project  File  Line
Error    atmel_def.mak: No such file or directory  bootload 
C:\Users\Leopold\Downloads\Bootloader\fastboot_build30.tar\fastboot\Make 
file   120
Error    recipe for target 'atmel_def.h' failed  bootload 
C:\Users\Leopold\Downloads\Bootloader\fastboot_build30.tar\fastboot\Make 
file   166


Das ganze Läuft bei mir im Atmel-Studio7 und die ReadMe habe ich nach 
bestem wissen und gewissen beachtet. Gibts da irgendwelche Fallstricke
Gruß aus dem Westerwald

Beitrag #5992863 wurde von einem Moderator gelöscht.
Beitrag #5992879 wurde von einem Moderator gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans-Hubert  Grendel schrieb:
> Immer nur die Fehlermeldung

In irgendeinem anderen Fenster muss es die tatsächlichen 
Compiler-Fehlermeldungen geben, nicht nur dieses Blabla von Visual 
Studio, das weiter nichts besagt als "Ooooch, da ist was schief 
gelaufen".

von quirxi (Gast)


Lesenswert?

Hallo,


Hans-Hubert  Grendel schrieb:
> Severity  Code  Description  Project  File  Line
> Error    atmel_def.mak: No such file or directory  bootload
> C:\Users\Leopold\Downloads\Bootloader\fastboot_build30.tar\fastboot\Make file
> 120
> Error    recipe for target 'atmel_def.h' failed  bootload
> C:\Users\Leopold\Downloads\Bootloader\fastboot_build30.tar\fastboot\Make file
> 166

Der Text sagt meiner Meinung aus, dass er die Datei atmel_def.mak nicht 
finden kann. Und dies steht im Makefile 
(C:\Users\Leopold\Downloads\Bootloader\fastboot_build30.tar\fastboot\Mak 
efile)  in der Zeile 120. Ich würde mal nachschauen was im Makefile in 
der Zeile 120 und Zeile 166 genau steht und warum er die Datei 
atmel_def.mak nicht finden kann. Vielleicht ist sie nicht installiert, 
oder nicht im Suchpfad oder sie muss auch erst noch generiert werden.

lg,
Arno

von Karl M. (Gast)


Lesenswert?

Guten Tag,

in meiner Installation steht im Makefile ab Zeile 177ff:
1
atmel_def.h: $(ATMEL_INC) Makefile
2
#        We use gawk instead of egrep here due to problems with
3
#        WinAVR's egrep (which I didn't dive into):
4
  ./_conv.awk $< | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > $@$@
5
6
atmel_def.mak: atmel_def.h
7
  gawk '{ printf "%s = %s\n", $$2, $$3 }' $< > $@

Ich editiere dann nur noch die Datei get_avr_arch.sh:
1
#!/bin/sh
2
# Get AVR architecture
3
# http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/AVR-Options.html
4
# attiny4313
5
# attyin85, attiny45
6
echo "avr25"
7
# atmega48, atmega88, atmega168, atmega328
8
#echo "avr4"
9
# atmega1284p
10
#echo "avr51"
Das Script liefert nicht das richtige, war mir zu müßig das zu debuggen.

Bitte 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
Noch kein Account? Hier anmelden.