Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain

[Uwe (de0508)]

hallo,

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

welche ausgaben liefert der Make-Durchlauf? - Fehlermeldungen.

[Marten83 (Gast)]

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

[Marten83 (Gast)]

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

[Micky (Gast)]

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

[Uwe (de0508)]

Hallo,

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

[Micky (Gast)]

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

ich verwende: GNU Make 3.81

[Stefan E. (sternst)]

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.

[Micky (Gast)]

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?

[Nils S. (kruemeltee)]

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.

[Stefan E. (sternst)]

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.

[Micky (Gast)]

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!

[Micky (Gast)]

Hallo Stefan,

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

[Stefan E. (sternst)]

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.

[Nils S. (kruemeltee)]

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.

[Stefan E. (sternst)]

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.

[Stefan E. (sternst)]

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

[Micky (Gast)]

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.

[Micky (Gast)]

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

[Micky (Gast)]

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.

[Anon Y. (avion23)]

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

./get_avr_arch.sh -x -mmcu=attiny85 bootload.o

 liefert bei mir immer

 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:

 "/usr/libexec/gcc/avr/4.5.2/collect2" "-m" "avr25" "-o" ";#magic1295671ghkl-."
"/usr/lib/gcc/avr/4.5.2/../../../../avr/lib/crttn85.o"
"-L/usr/lib/gcc/avr/4.5.2" 
"-L/usr/lib/gcc/avr/4.5.2/../../../../avr/lib"
"bootload.o" "-lgcc" "-lc" "-lgcc"

 /usr/libexec/gcc/avr/4.7.0/collect2 -m avr25 -o ";#magic1295671ghkl-."
/usr/lib/gcc/avr/4.7.0/../../../../avr/lib/crttn85.o 
-L/usr/lib/gcc/avr/4.7.0
-L/usr/lib/gcc/avr/4.7.0/../../../../avr/lib 
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:

--- get_avr_arch.sh.backup      2012-05-28 11:40:35.851776973 +0200
+++ get_avr_arch.sh     2012-05-28 12:57:39.953442806 +0200
@@ -39,9 +39,12 @@
 magic=";#magic1295671ghkl-."
 # call gcc, asking it for the command line which it would use for
 # linking:
-set -- $(avr-gcc -m"$mcu" -### "$1" -o "$magic" 2>&1 \
-         | gawk '/^avr-gcc:/||/"-m".*'"$magic"'.*"-lgcc"/')
-
+# old command for <= gcc-4.5*
+#set -- $(avr-gcc -m$mcu -### "$1" -o "$magic" 2>&1 \
+#         | gawk '/^avr-gcc:/||/"-m".*'"$magic"'.*"-lgcc"/')
+# new command for > gcc-4.5*    
+set -- $(avr-gcc -m$mcu -### "$1" -o "$magic" 2>&1 \
+         | gawk '/^avr-gcc:/||/-m .*'"$magic"'.*-lgcc/')
 if [ "$1" = "avr-gcc:" ]; then
     # we have an error message from gcc:
     echo "$*"
@@ -51,7 +54,10 @@
 # retrieve architecture argument from gcc's commandline (the argument
 # which follows '"-m"'):
 while [ -n "$2" ]; do
-    if [ "$1" = '"-m"' ]; then
+# old command for <= gcc-4.5*
+#    if [ "$1" = '"-m"' ]; then
+# new command for > gcc-4.5*    
+    if [ "$1" = '-m' ]; then
        eval echo $2            # eval: remove quotes
        exit 0
     fi
@@ -59,4 +65,4 @@
 done
 echo >&2 "\
 $pname: Could not find an architecture in avr-gcc's internal ld command line"
-exit 1
\ No newline at end of file
+exit 1

[Anon Y. (avion23)]

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

[pedro f. (healthhazard)]

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

[Kai (Gast)]

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

[Bernhard M. (boregard)]

Hallo Kai,

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

Gruß,
Bernhard

[pedro f. (healthhazard)]

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

[Tueftler (Gast)]

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.

[Pascal R. (pascal_r)]

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!

[Konrad S. (maybee)]

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

Ja, oder hier auf dem SVN-Server.

[flo (Gast)]

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:

 avr-gcc (GCC) 4.8.1

Output:

fastboot-2.9 % make -f Makefile-m8
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
arch=avr4
LOADER_START=0x1e00
STUB_OFFSET=0x1fe
avr-ld:bootload.x:22: syntax error
make: *** [bootload.elf] Error 1

Inhalt von bootload.x an der entsprechenden Stelle:

19: MEMORY
20: {
21:  text  (rx)   : ORIGIN = 0x1e00, LENGTH = 0x1fe + 2
22:  bss   (rw!x) : ORIGIN = 0x8000000 +, LENGTH =
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

[Uwe (de0508)]

Hallo,

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

[Kevin (Gast)]

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

[Chris (Gast)]

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

[Werner (Gast)]

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!

[Nils E. (yetanotheruser)]

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.

[Uwe (de0508)]

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.

[Nils E. (yetanotheruser)]

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!

[clonephon82 (Gast)]

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

thx
mathias

[Merlin (Gast)]

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

[Hans (Gast)]

Hallo Merlin,

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

Welchen Compiler verwendest Du ?

[Merlin (Gast)]

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.

[Merlin (Gast)]

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

[Axel (Gast)]

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

[Uwe (de0508)]

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"

[Axel (Gast)]

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

[Axel (Gast)]

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

[Uwe (de0508)]

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.

[Axel (Gast)]

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

[Nils E. (yetanotheruser)]

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

[Axel (Gast)]

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

[Uwe (de0508)]

Hallo Axel,

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

[Klaus W. (klausw1)]

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.

[Bernhard M. (boregard)]

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

[Klaus W. (klausw1)]

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

[Klaus W. (klausw1)]

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

[Uwe (de0508)]

Hallo Klaus,

wie sieht deine Fusebit Einstellung aus ?

Ist "Self programming enable" aktiviert ?

[Klaus W. (klausw1)]

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.

[clonephone82 (Gast)]

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

[Klaus W. (klausw1)]

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.

[Bernhard M. (boregard)]

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

[Daniel B. (bradan)]

Hallo,

Ich habe AVR-GCC 5.2.0 (unter Arch Linux) und es kommt wieder die 
Fehlermeldung

get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld command line

Komplettes Log:

vars="$(./get_text_addrs.sh 0x3FFF)"; \
arch="$(./get_avr_arch.sh -mmcu=atmega32 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: 0x7dfd
get_avr_arch.sh: Could not find an architecture in avr-gcc's internal ld command line
arch=
LOADER_START=0x7e00
STUB_OFFSET=0x1fe
avr-ld:bootload.x:18: syntax error
Makefile:133: die Regel für Ziel „bootload.elf“ scheiterte
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:

arch=atmega32
LOADER_START=0x7e00
STUB_OFFSET=0x1fe
avr-ld: cannot represent machine `atmega32'

Mit freundlichen Grüßen,
Daniel

[Hendrik L. (lbd)]

Hallo zusammen,

da obige Prozedur (Makefile) im letzten Schritt (Bind) noch nicht 
geklappt hat (bei mir auf DEBIAN)

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

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:

Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper
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-libssp --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=avr
Thread model: single
gcc version 4.7.2 (GCC)
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/
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/
COLLECT_GCC_OPTIONS='-mmcu=atmega2560' '-o' '+'
 /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:

magic=";#magic1295671ghkl-."
# call gcc, asking it for the command line which it would use for
# linking:
set -- $(avr-gcc -m"$mcu" -### "$1" -o "$magic" 2>&1 \
         | gawk '/^avr-gcc:/||/ld.*'"$magic"'.*"-lgcc"/')

if [ "$1" = "avr-gcc:" ]; then
    # we have an error message from gcc:
    echo "$*"
    exit 1
fi

# retrieve architecture argument from gcc's commandline (the argument
# which follows '"-m"'):
while [ -n "$2" ]; do
    if [ "$1" = '"-m"' ]; then
  eval echo $2    # eval: remove quotes
  exit 0
    fi
    shift
done
echo >&2 "\
$pname: Could not find an architecture in avr-gcc's internal ld command line"
exit 1

Any Help is pretty much appreciated ;-)

Grüße

[Hendrik L. (lbd)]

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

+ [ Using = avr-gcc: ]
+ [ -n built-in ]
+ [ Using = -m ]
+ shift
+ [ -n specs. ]
+ [ built-in = -m ]
+ shift
+ [ -n COLLECT_GCC=avr-gcc ]
+ [ specs. = -m ]
+ shift
+ [ -n COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper ]
+ [ COLLECT_GCC=avr-gcc = -m ]
+ shift
+ [ -n Target: ]
+ [ COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper = -m ]
+ shift
+ [ -n avr ]
+ [ Target: = -m ]
+ shift
+ [ -n Configured ]
+ [ avr = -m ]
+ shift
+ [ -n with: ]
+ [ Configured = -m ]
+ shift
+ [ -n ../src/configure ]
+ [ with: = -m ]
+ shift
+ [ -n -v ]
+ [ ../src/configure = -m ]
+ shift
+ [ -n --enable-languages=c,c++ ]
+ [ -v = -m ]
+ shift
+ [ -n --prefix=/usr/lib ]
+ [ --enable-languages=c,c++ = -m ]
+ shift
+ [ -n --infodir=/usr/share/info ]
+ [ --prefix=/usr/lib = -m ]
+ shift
+ [ -n --mandir=/usr/share/man ]
+ [ --infodir=/usr/share/info = -m ]
+ shift
+ [ -n --bindir=/usr/bin ]
+ [ --mandir=/usr/share/man = -m ]
+ shift
+ [ -n --libexecdir=/usr/lib ]
+ [ --bindir=/usr/bin = -m ]
+ shift
+ [ -n --libdir=/usr/lib ]
+ [ --libexecdir=/usr/lib = -m ]
+ shift
+ [ -n --enable-shared ]
+ [ --libdir=/usr/lib = -m ]
+ shift
+ [ -n --with-system-zlib ]
+ [ --enable-shared = -m ]
+ shift
+ [ -n --enable-long-long ]
+ [ --with-system-zlib = -m ]
+ shift
+ [ -n --enable-nls ]
+ [ --enable-long-long = -m ]
+ shift
+ [ -n --without-included-gettext ]
+ [ --enable-nls = -m ]
+ shift
+ [ -n --disable-libssp ]
+ [ --without-included-gettext = -m ]
+ shift
+ [ -n --build=arm-linux-gnueabihf ]
+ [ --disable-libssp = -m ]
+ shift
+ [ -n --host=arm-linux-gnueabihf ]
+ [ --build=arm-linux-gnueabihf = -m ]
+ shift
+ [ -n --target=avr ]
+ [ --host=arm-linux-gnueabihf = -m ]
+ shift
+ [ -n Thread ]
+ [ --target=avr = -m ]
+ shift
+ [ -n model: ]
+ [ Thread = -m ]
+ shift
+ [ -n singlegcc ]
+ [ model: = -m ]
+ shift
+ [ -n version ]
+ [ singlegcc = -m ]
+ shift
+ [ -n 4.7.2 ]
+ [ version = -m ]
+ shift
+ [ -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/ ]
+ [ 4.7.2 = -m ]
+ shift
+ [ -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/ ]
+ [ 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 ]
+ shift
+ [ -n COLLECT_GCC_OPTIONS=-mmcu=atmega2560 ]
+ [ 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 ]
+ shift
+ [ -n -o ]
+ [ COLLECT_GCC_OPTIONS=-mmcu=atmega2560 = -m ]
+ shift
+ [ -n + ]
+ [ -o = -m ]
+ shift
+ [ -n /usr/lib/gcc/avr/4.7.2/collect2 ]
+ [ + = -m ]
+ shift
+ [ -n -m ]
+ [ /usr/lib/gcc/avr/4.7.2/collect2 = -m ]
+ shift
+ [ -n avr6 ]
+ [ -m = -m ]
+ eval echo avr6
+ echo avr6
avr6
+ 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

[Karl M. (Gast)]

Hallo,

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

[Hendrik L. (lbd)]

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

#(Makefile)
...
bootload.elf : bootload.o stub.o
#---- ab hier buggy ------------------------------------------------------
ifndef BOOTRST
  vars="$$(./get_text_addrs.sh $(FLASHEND))"; \
  arch="$$(./get_avr_arch.sh -mmcu=$(MCU) 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@/$(SRAM_START)/g' \
      -e s'/@RAM_SIZE@/$(SRAM_SIZE)/g' \
      -e "s/@STUB_OFFSET@/$$STUB_OFFSET/g" \
      bootload.template.x > bootload.x; \
  avr-ld -N -E -T bootload.x -Map=$(patsubst %.elf,%,$@).map \
    --cref $+ -o $@ --defsym Application="$$LOADER_START-2"
#---- bis hier buggy -----------------------------------------------------
else
  vars="$$(./get_bootsection_addrs.sh $(FLASHEND) $(FIRSTBOOTSTART) \
                $(SECONDBOOTSTART) $(THIRDBOOTSTART) $(FORTHBOOTSTART))"; \
...

[Oliver (Gast)]

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

[Fritz G. (fritzg)]

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?

[Uwe (de0508)]

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.

[clonephone82 (Gast)]

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

[clonephone82 (Gast)]

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?

[clonephone82 (Gast)]

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

[Bernhard M. (boregard)]

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.

[Bernhard M. (boregard)]

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.

[Bernhard M. (boregard)]

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

[Nils S. (kruemeltee)]

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

[clonephone82 (Gast)]

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

[Nils S. (kruemeltee)]

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.

[Nils S. (kruemeltee)]

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.

[Fritz G. (fritzg)]

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

[clonephone82 (Gast)]

Hallo Fritz,

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

danke

[Fritz G. (fritzg)]

Ja, nachdem ich den String "Peda" erkannt habe:

                lcdClrscr();
                lcdGotoxy(0, 0);
                lcdWrite_P(PSTR("Loading firmware"));
                lcdGotoxy(0, 1);
                lcdWrite_P(PSTR("Please wait...  "));
                beepOk();
                wdt_reset();
                wdt_enable(WDTO_1S);
                wdt_reset();
                while (1);

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

[Mathias G. (mgiaco)]

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

[Klaus W. (klausw1)]

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?

[Karl M. (Gast)]

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.

[Klaus W. (klausw1)]

Das hier ist die Ausgabe:

D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload>make Makefile-tiny4
5 all
makefile:125: atmel_def.mak: No such file or directory
./_conv.awk atmel/m32def.inc | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/'
> atmel_def.h
gawk '{ printf "%s = %s\n", $2, $3 }' atmel_def.h > atmel_def.mak
make: Nothing to be done for `Makefile-tiny45'.
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega32 -DF_CPU=14745600  -I . -I ./a
dded -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs
+ -DRAM_START=0x0060 -DSRAM_SIZE=2048 -DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORT
D -DSRX=PD0 added/bootload.S -o bootload.o
avr-gcc -c -Wa,-adhlns=stub.lst -mmcu=atmega32 -DF_CPU=14745600  -I . -I ./added
 -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs+ -D
RAM_START=0x0060 -DSRAM_SIZE=2048 -DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORTD -D
SRX=PD0 added/stub.S -o stub.o
vars="$(./get_bootsection_addrs.sh 0x3fff 0x3f00 0x3e00 0x3c00 )"; \
        arch="$(./get_avr_arch.sh -mmcu=atmega32 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@/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

Ich hatte schon mit mehreren Übertragungsraten probiert. Zuletzt mit 
9600.
Die Ausgabe beim Flaschen ist:

COM-Port öffnen
Verbindungsaufbau...
Verbunden: 2-Draht-Modus, 1 Versuch
Übertragung CRC-gesichert!
Überprüfung (Verify) unterstützt!
Chip-Signatur: 1E 92 06
Bootloader V2.1 auf ATtiny45 gefunden
Flash-Größe: 3kB (Puffer: 64 Byte)
CRC-Prüfsumme OK
Programmiere 362 Byte von 3kB Flash...
Programmieren erfolgreich
Überprüfe gespeicherte Firmware...
Fehler aufgetreten, Update abgebrochen!

[Konrad S. (maybee)]

Klaus W. schrieb:
> -mmcu=atmega32

???

> make Makefile-tiny45 all

Sollte das nicht eher so sein?

make -f Makefile-tiny45 all

[Klaus W. (klausw1)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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 …

[Aruinoquäler (Gast)]

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.

[Klaus W. (klausw1)]

So, hab es nochmal in ner VM probiert. Das ist also die Ausgabe des 
Atmel Studio, womit ich damals auch komiliert hatte:

Build started 1.12.2016 at 13:49:56
Makefile-tiny45:130: atmel_def.mak: No such file or directory
./_conv.awk atmel/tn45def.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=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
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
vars="$(./get_text_addrs.sh 0x07ff)"; \
    arch="$(./get_avr_arch.sh -mmcu=attiny45 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@/256/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: 0xdfd
arch=avr2
LOADER_START=0xe00
STUB_OFFSET=0x1fe
avr-objcopy -O ihex bootload.elf bootload.hex

[Klaus W. (klausw1)]

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.

------ Rebuild All started: Project: bootload, Configuration: default AVR ------
Build started.
Project "bootload.cproj" (Clean target(s)):
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):
  Task "RunCompilerTask"
    Shell Utils Path F:\Program Files (x86)\WinAVR-20100110\bin
    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 
    "F:\Program: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3)
  Done executing task "RunCompilerTask" -- FAILED.
Done building target "Clean" in project "bootload.cproj" -- FAILED.
Done building project "bootload.cproj" -- FAILED.

Build FAILED.
------ Rebuild All started: Project: bootload, Configuration: default AVR ------
Build started.
Project "bootload.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
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):
  Task "RunCompilerTask"
    Shell Utils Path F:\Program Files (x86)\WinAVR-20100110\bin
    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 
    make: Entering directory `D:/Eigene Dateien/Atmel/Studio7/fastboot-2.9-140709/bootload'
    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
    ./converted/password.inc: Assembler messages:
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\converted\password.inc(13,1): error: non-constant expression in ".if" statement
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\converted\message.inc(17,1): error: non-constant expression in ".if" statement
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\converted\message.inc(23,1): error: non-constant expression in ".if" statement
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(73,1): error: illegal relocation size: 1
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(74,1): error: illegal relocation size: 1
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(76,1): error: illegal relocation size: 1
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(77,1): error: illegal relocation size: 1
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(78,1): error: illegal relocation size: 1
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(80,1): error: illegal relocation size: 1
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(81,1): error: illegal relocation size: 1
D:\Eigene Dateien\Atmel\Studio7\fastboot-2.9-140709\bootload\added\fastload.inc(82,1): error: illegal relocation size: 1
    make: *** [bootload.o] Error 1
    make: Leaving directory `D:/Eigene Dateien/Atmel/Studio7/fastboot-2.9-140709/bootload'
  Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "bootload.cproj" -- FAILED.
Done building project "bootload.cproj" -- FAILED.

Build FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

[Matthias T. (matthias_199)]

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

[Matthias T. (matthias_199)]

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

[Markus L. (Gast)]

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:

.macro IOPortInit
  sbi SRX_PORT, SRX  ;<= PORTH, PH0
  sbi STX_PORT, STX ;<= PORTH, PH1
  sbi STX_DDR, STX ;<= DDRH, PH1
.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

; Definitions marked "MEMORY MAPPED" are extended I/O ports
; and cannot be used with IN/OUT instructions
.equ  PORTH  = 0x102  ; MEMORY MAPPED
.equ  DDRH  = 0x101  ; MEMORY MAPPED
.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

[Karl M. (Gast)]

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.

.macro gCbi
.if @0<32
cbi  @0,@1
.else
xIn  WL,@0
cbr  WL,(1<<@1)
xOut  @0,WL
.endif
.endmacro

.macro gSbi
.if @0<32
sbi  @0,@1
.else
xIn  WL,@0
sbr  WL,(1<<@1)
xOut  @0,WL
.endif
.endmacro

Es folgt also noch umschreiben von IOPortInit:

.macro IOPortInit
  gSbi SRX_PORT, SRX  ;<= PORTH, PH0
  gSbi STX_PORT, STX ;<= PORTH, PH1
  gSbi STX_DDR, STX ;<= DDRH, PH1
.endmacro

[Karl M. (Gast)]

Nachtrag,

und man braucht natürlich noch diese beiden Macros

.macro xIn
.if @1<64
in  @0,@1
.else
lds  @0,@1
.endif
.endmacro

.macro xOut
.if @0<64
out  @0,@1
.else
sts  @0,@1
.endif
.endmacro

[Markus L. (Gast)]

Hallo Karl,

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

Freundlichst, Markus

[Markus L. (Gast)]

Hallo Karl,

Bin etliche Schritte weitergekommen, in fastload.h:

Im Kopf der Datei

#define  WL r26

Neue Macros:

.macro gCbi p0 p1
.if \p0<32
  cbi  \p0,\p1
.else
  xin  WL,\p0
  cbr  WL,(1<<\p1)
  xout  \p0,WL
.endif
.endm

.macro gSbi p0 p1
.if \p0<32
  sbi  \p0,\p1
.else
  xin  WL,\p0
  sbr  WL,(1<<\p1)
  xout  \p0,WL
.endif
.endm

.macro skbs p0, p1
.if \p0>0x3F
  lds  WL, \p0
  sbrs WL, \p1
.elseif \p0>0x1F
  in   WL, \p0
  sbrs WL, \p1
.else
  sbis \p0, \p1
.endif
.endm

.macro skbc p0, p1
.if \p0>0x3F
  lds WL, \p0
  sbrc WL, \p1
.elseif \p0>0x1F
  in WL, \p0
  sbrc WL, \p1
.else
  sbic \p0, \p1
.endif
.endm

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

Angepasst:

  .macro  IOPortInit
  gSbi  SRX_PORT, SRX
  gSbi  STX_PORT, STX
  gSbi  STX_DDR, STX
  .endm
  .macro  TXD_0
  gCbi  STX_PORT, STX
  .endm
  .macro  TXD_1
  gSbi  STX_PORT, STX
  .endm
  .macro  SKIP_RXD_0
  skbc  SRX_PIN, SRX
  .endm
  .macro  SKIP_RXD_1
  skbs  SRX_PIN, SRX
  .endm

eine Unschönheit habe ich noch, in der /converted/abaud.inc

_aba3:
  sbiw  twl, 1    ;2
  sbci  a0, 0      ;1
  SKIP_RXD_0      ;1  wait until RXD = 0
  brne  _aba3      ;2 = 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

[Markus L. (Gast)]

Guten Morgen,

Nach etwas weiterer Recherche bin ich auf folgende Lösung gekommen.

_aba3:
   sbiw  twl, 1    ;2
   sbci  a0, 0      ;1
   SKIP_RXD_0      ;1  wait until RXD = 0
   brne  _aba3      ;2 = 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

[Karl M. (Gast)]

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

[Markus L. (Gast)]

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

[Karl M. (Gast)]

Siehe:

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

[Leo C. (rapid)]

   sbci  a0, 0      ;1
   SKIP_RXD_0      ;1  wait until RXD = 0
   brne  _aba3      ;2 = 6
   //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:

        SKIP_RXD_0                      ;1  wait until RXD = 0
        brne    _aba3                   ;2 = 6
        brne    _aba4
        rjmp    timeout
_aba4:

[Markus L. (Gast)]

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

[Leo C. (rapid)]

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.

[Markus L. (Gast)]

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

[Markus L. (Gast)]

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"

[Leo C. (rapid)]

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.

[Markus L. (Gast)]

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

[Markus L. (Gast)]

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.

[Markus L. (Gast)]

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

;------------------------------  UART delay loop value --------------------
#if STX_PORT > 0x1F
#define  _memmap_delay_ 4
#else
#define  _memmap_delay_ 0
#endif

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

[Robert H. (robhoff)]

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.

[Malte _. (malte)]

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.

[Arno M. (quirxi)]

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.

[DanielU (Gast)]

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?

[Uwe (de0508)]

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.

[quirxi (Gast)]

Hallo,

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


lg

[DanielU (Gast)]

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

[Karl M. (Gast)]

Hallo DanielU,

Setzte die passenden und hier richtigen Bootloaderflag!

[DanielU (Gast)]

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.

[Karl M. (Gast)]

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

[DanielU (Gast)]

So die Mitteilung vom Makescript ist nicht richtig?

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

[Karl M. (Gast)]

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/

[DanielU (Gast)]

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

[quirxi (Gast)]

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

[quirxi (Gast)]

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

[quirxi (Gast)]

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

[DanielU (Gast)]

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?

[Karl M. (Gast)]

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.

[quirxi (Gast)]

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?

[DanielU (Gast)]

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

[quirxi (Gast)]

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

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

[DanielU (Gast)]

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?

[quirxi (Gast)]

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?

[DanielU (Gast)]

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.

[Malte _. (malte)]

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

[DanielU (Gast)]

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.

[quirxi (Gast)]

At least we have all learned something new again ?

[Randy B. (rbrecker)]

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?

[Karl M. (Gast)]

Hallo,

1MHz?

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

[Randy B. (rbrecker)]

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?

[Karl M. (Gast)]

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/

[Karl M. (Gast)]

Korrektur:

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

abgerutscht.

[Randy B. (rbrecker)]

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.

[Karl M. (Gast)]

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!

[Karl M. (Gast)]

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.

[Randy B. (rbrecker)]

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

[Jörg W. (dl8dtl) (Moderator)]

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

[Karl M. (Gast)]

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.

[Karl M. (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Malte _. (malte)]

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/

[Randy B. (rbrecker)]

Wenn ich mir das generierte File des Bootloaders ansehe, dann fehlt dort 
bei 0x0000 doch der Sprung zum Bootloader?

bootload.elf:     file format elf32-avr
Disassembly of section .text:
00001e00 <init>:
1e00:       f8 94           cli
1e02:       6f e5           ldi     r22, 0x5F       ; 95
1e04:       6d bf           out     0x3d, r22       ; 61
1e06:       62 e0           ldi     r22, 0x02       ; 2
1e08:       6e bf           out     0x3e, r22       ; 62
1e0a:       22 24           eor     r2, r2
1e0c:       33 24           eor     r3, r3
1e0e:       a8 95           wdr
1e10:       61 b5           in      r22, 0x21       ; 33
1e12:       60 61           ori     r22, 0x10       ; 16
1e14:       7f e0           ldi     r23, 0x0F       ; 15
1e16:       61 bd           out     0x21, r22       ; 33
1e18:       63 fd           sbrc    r22, 3
1e1a:       71 bd           out     0x21, r23       ; 33
1e1c:       c3 9a           sbi     0x18, 3 ; 24
1e1e:       c4 9a           sbi     0x18, 4 ; 24
1e20:       bc 9a           sbi     0x17, 4 ; 23
1e22:       21 e0           ldi     r18, 0x01       ; 1
1e24:       30 ea           ldi     r19, 0xA0       ; 160

[Jörg W. (dl8dtl) (Moderator)]

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.

[Randy B. (rbrecker)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Randy B. (rbrecker)]

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?

[Jörg W. (dl8dtl) (Moderator)]

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.

[Karl M. (Gast)]

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.

[Randy B. (rbrecker)]

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.

[Randy B. (rbrecker)]

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

[Randy B. (rbrecker)]

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.

[Randy B. (rbrecker)]

See ich das richtig, dass im ONEWIRE eine "1" (low-pegel) durch

  .macro  TXD_1
  cbi  STX_DDR, SRX    ; weak pullup = 1
  .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.

[Karl M. (Gast)]

Hallo Randy B.,

bei mir sieht die Beschaltung, wie ähnlich aus.

Quelle: habe ich mal irgendwo gefunden.

[Randy B. (rbrecker)]

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?

[Karl M. (Gast)]

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.

[Randy B. (rbrecker)]

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.

[Randy B. (rbrecker)]

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

[Karl M. (Gast)]

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

[Randy B. (rbrecker)]

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.

[Karl M. (Gast)]

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 ([e-mail])

[Randy B. (rbrecker)]

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 ([e-mail])

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

[Karl M. (Gast)]

Ok,

fastboot-2.9 Version 140709

[Randy B. (rbrecker)]

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

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

[Randy B. (rbrecker)]

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.

[Thomas N. (tonevi)]

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?

[Jörg W. (dl8dtl) (Moderator)]

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

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

[Raph (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Oliver S. (oliverso)]

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

[Thomas N. (tonevi)]

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?

[Oliver S. (oliverso)]

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

[Jörg W. (dl8dtl) (Moderator)]

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

[Thomas N. (tonevi)]

Hallo Oliver,

anbei der von mir verwendete Source Code.

[Thomas N. (tonevi)]

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

[Jörg W. (dl8dtl) (Moderator)]

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

Daran hatte ich nicht den leisesten Zweifel.

[Thomas N. (tonevi)]

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

  ldi a0, 0xff    ; SRAM Puffer löschen
  ldi xl, lo8(PROGBUFF)
  ldi xh, hi8(PROGBUFF)
ClrLoop:
  st x+, a0
  cpi xh, hi8(PROGBUFFEND)
  brlo ClrLoop
  cpi xl, lo8(PROGBUFFEND)
  brlo ClrLoop

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

[Jörg W. (dl8dtl) (Moderator)]

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.

[Karl M. (Gast)]

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.

[Oliver S. (oliverso)]

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

[Hans-Hubert Grendel (Gast)]

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

[Jörg W. (dl8dtl) (Moderator)]

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

[quirxi (Gast)]

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

[Karl M. (Gast)]

Guten Tag,

in meiner Installation steht im Makefile ab Zeile 177ff:

atmel_def.h: $(ATMEL_INC) Makefile
#        We use gawk instead of egrep here due to problems with
#        WinAVR's egrep (which I didn't dive into):
  ./_conv.awk $< | gawk '/PAGESIZE|SIGNATURE_|SRAM_|FLASHEND|BOOT/' > $@$@

atmel_def.mak: atmel_def.h
  gawk '{ printf "%s = %s\n", $$2, $$3 }' $< > $@

Ich editiere dann nur noch die Datei get_avr_arch.sh:

#!/bin/sh
# Get AVR architecture
# http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/AVR-Options.html
# attiny4313
# attyin85, attiny45
echo "avr25"
# atmega48, atmega88, atmega168, atmega328
#echo "avr4"
# atmega1284p
#echo "avr51"

Das Script liefert nicht das richtige, war mir zu müßig das zu debuggen.