hallo, hast du dir das makefile für den mega88 angepasst? wie sehen deine fusebits aus? welche ausgaben liefert der Make-Durchlauf? - Fehlermeldungen.
Gast
#2404071
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
Gast
#2404822
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
Gast
#2454598
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
Hallo, Du mußt mit das Programm 'make' und das Makefile direkt verwenden !
Gast
#2454607
Wenn ich in der DOS-Konsole make eingebe, erhalte ich den gleichen Fehler. ich verwende: GNU Make 3.81
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.
Gast
#2454627
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?
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.
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.
Gast
#2454650
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!
Gast
#2454655
Hallo Stefan, bezgl. deiner Unix-Shell. In der Anleitung zu dem Bootloader wird dies nicht erwähnt. Eigentlich soll make damit zurechtkommen oder?
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.
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.
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.
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
Gast
#2454726
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.
Gast
#2454729
>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!
Gast
#2455936
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.
Hallo zusammen, seit gcc-4.6 (unsicher) und gcc-4.7 kann ich den bootloader nicht mehr verwenden. Eine gefixte get_avr_arch.sh ist angehängt. Ein
1 | |
liefert bei mir immer
1 | |
Um heraus zu finden, was da nicht funktioniert habe ich mir die Ausgaben von avr-gcc in den verschiedenen Versionen angesehen:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Wie man sehen kann sind die \" der große Unterschied. Das skript habe ich "gefixt" in dem ich es hart auf neue gcc-Versionen umgebaut habe. Auf eine Versionsunterscheidung habe ich nach dieser Shell-Orgie keine Lust mehr; wer will kann es gerne einbauen. Hier noch das diff. Viel Spaß damit:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
Murphy fordert seinen Tribut: In der obigen Datei ist eine auskommentierte Zeile vom Debuggen übrig geblieben. Die habe ich jetzt gelöscht.
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
Gast
#2782151
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
Hallo Kai, hast Du mal eine andere / höhere Baudrate versucht? Mit 8 MHz laufen bei mir 115200 Baud zuverlässig. Gruß, Bernhard
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
Gast
#2959077
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.
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!
Pascal R. schrieb: > Soll ich mal nen Git Repository auf Github erstellen Ja, oder hier auf dem SVN-Server.
Gast
#3716559
Hallo Zusammen. Zuerst einmal: Cooles Projekt! Ich finde es super dass sich so viele Leute Zeit nehmen sowas auf die Beine zu stellen. Leider habe ich ein paar Probleme: Einstellungen: Version: fastboot-2.9_110804.zip MCU: Atmega8 avr-gcc --version:
1 | |
Output:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
Inhalt von bootload.x an der entsprechenden Stelle:
1 | |
2 | |
3 | |
4 | |
5 | |
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
Hallo, hier ist ein Update zum Post: www.mikrocontroller.net/topic/146638#2340593
Gast
#3812136
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 ==========
Gast
#3863024
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
Gast
#4012725
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!
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.
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.
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!
Gast
#4066596
War jemand schon erfolgreich mit dem Atmel Studio 6.2 und Windows 7? thx mathias
Gast
#4082368
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
Gast
#4082389
Hallo Merlin, nun Dir fehlen ein paar Shell Tools, u.a. gawk und der Assembler will auch nicht. Welchen Compiler verwendest Du ?
Gast
#4082567
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.
Gast
#4082724
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
Gast
#4084982
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
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"
Gast
#4085543
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
Gast
#4085825
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
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.
Gast
#4086101
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
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
Gast
#4087152
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
Hallo Axel, ja und warum ? Da es sich um Unix Pfadangaben handelt. Du musst auch vorher eine Unix Shell starten.
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.
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
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
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
Hallo Klaus, wie sieht deine Fusebit Einstellung aus ? Ist "Self programming enable" aktiviert ?
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.
Gast
#4355140
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
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.
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...
Hallo, Ich habe AVR-GCC 5.2.0 (unter Arch Linux) und es kommt wieder die Fehlermeldung
1 | |
Komplettes Log:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
Laut diesem Thread gibt es eine neue Version dieser Datei, aber die funktioniert leider auch nicht. Kann mir jemand vielleicht sagen, was das Resultat dieser Datei ist bei einem atmega32? Dann könnte ich das vielleicht manuell einsetzen. Ich habe bereits m32 und atmega32 versucht, aber ohne Erfolg, denn dann kommt:
1 | |
2 | |
3 | |
4 | |
Mit freundlichen Grüßen, Daniel
Hallo zusammen, da obige Prozedur (Makefile) im letzten Schritt (Bind) noch nicht geklappt hat (bei mir auf DEBIAN)
1 | |
... habe ich mir 'mal den Vorgang untersucht und verschiedene Fragen stellen sich mir (bin Anfänger): Was bewirkt eigentlich der nachfolgende Befehl in dem Bash Script "get_avr_arch.sh"?
1 | |
Wo bitte ist die "Magic..." Abfrage dokumentiert? Leider funktioniert der Befehl nur auf der Konsole, das System antwortet mit:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Hieraus entnehme ich - der Mega 2560 ist in avr-gcc definiert (hätte mich auch gewundert!) Was mache ich denn damit? Das Bash-Script steigt mit exit 1 aus, weil diese Antwort wohl nicht zurückkommt, dadurch kann make den ersehnten Bootloader nicht zu einem Executable linken. Das Problem ist wohl auch in einigen Posts zuvor schon aufgetreten, bin mir aber nicht sicher, ob das Problem richtig erkannt wurde - die Prozessoren waren offensichtlich definiert - nur das Script scheint die Antwort nicht zu bekommen. Ist wahrscheinlich eher ein Scripting Problem in "get_avr_arch.sh" in Zeilen 4 & 5:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
Any Help is pretty much appreciated ;-) Grüße
So - bin ein Stück weiter: Für den ATmega 2560 wäre die erwartete Antwort gewesen ..., die dann aufgelöst nach den Positional Parametern $1 ... $x
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
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
Gast
#4404894
Hallo zusammen, nachdem diese Klippe umschifft, habe ich es geschafft, eine bootload.exe für die AVR6 Klasse (ATmega2560) zu erstellen. Ich gehe davon aus, dass er auch läuft - auf Windows Plattform funktioniert jedenfalls läuft PEDA's Bootloader für den 2560 hervorragend, den ich bereits dort vor Jahren generiert habe. Für die ATtiny Klasse (ohne BOOTRST) ist an dieser Stelle leider im letzten Schritt Schluss - der folgende Scripting Abschnitt im Makefile (siehe unten) ist definitiv (auch - neben dem oben geschildertem Problem, was man aber "manuell" umschiffen kann) "buggy" und mir fehlt das Wissen, um überhaupt analysieren zu können, woran es liegt könnte - gawk und sed sind nicht mein Thema ...! Werde jetzt auf Windows umsteigen und dort meinen ATtiny mit Hilfe von PEDA erstellen. Der müsste ja dann auch mit einem Linux Host kommunizieren können. Schade, dass dieses schöne Tool nicht ganz fertig geworden ist. Wirklich eine geniale Arbeit! Grüße
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
Gast
#4456716
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
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?
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.
Gast
#4611328
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
Gast
#4611333
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?
Gast
#4611367
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
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.
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.
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....
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...
Gast
#4611668
@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.
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.
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.
Ich lausche, ob das Passwort kommt und mache dann den Reset.
Gast
#4613001
Hallo Fritz, Wie machst du den den Reset? Ist das ein SW Reset? danke
Ja, nachdem ich den String "Peda" erkannt habe:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Das funktioniert zuverlässig, da das Flashprogramm immer 0x0d, das Passwort und dann 0xff schickt, bis es einen Connect bekommt.
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
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?
Gast
#4808918
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.
Das hier ist die Ausgabe:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
Ich hatte schon mit mehreren Übertragungsraten probiert. Zuletzt mit 9600. Die Ausgabe beim Flaschen ist:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
Klaus W. schrieb: > -mmcu=atmega32 ??? > make Makefile-tiny45 all Sollte das nicht eher so sein?
1 | |
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.
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 …
Gast
#4812803
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.
So, hab es nochmal in ner VM probiert. Das ist also die Ausgabe des Atmel Studio, womit ich damals auch komiliert hatte:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
Aruinoquäler schrieb: > Klaus W. schrieb: >> Da damit das Kompilieren nicht funktionierte, > > Ich habe Atmel AVR Studio 4 (4.18) und WinAVR2010 unter Windows 7 > installiert und das funktioniert. > > Wenn was nicht funktioniert dann deshalb weil man vielleicht > vergisst dass das AVR Studio ohne Compiler daherkommt, also > (möglichst vorher) muss der WinAVR Compiler explizit installiert > werden. Nein, das ist es leider nicht. Ein anderes Projekt, was komplett im AVRstudio geschrieben ist, funktioniert auch einwandfrei. Scheinbar liegt es an dem Mix zwischen C und ASM. Das neue AVRstudio macht da Chaos zwischen Winavr und mitgelieferten Tools.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
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
sudo apt-get install gawk und neue get_avr_arch.sh + chmod +x nicht vergessen :)
Gast
#5097170
Hallo, Ich bin kürzlich auf dieses Projekt gestossen, und finde es Klasse. Nach etwas rum probieren, habe ich es auch geschafft das ganze Zusammenzusetzen und einen funktionierenden Bootloader für den Atmega2560 zu kompilieren (PORTD). Mein Problem: ich müsste den Bootloader soweit bringen das er auf PORTH reagiert. Soweit ich das Problem zurückverfolgen konnte ist PORTH nicht gleich anzusprechen wie PORTD. Das Problem beginnt dann in /added/fastload.inc ab Zeile 180:
1 | |
2 | |
3 | |
4 | |
5 | |
avr-gcc meldet Fehler wie: ./added/fastload.inc:42: Error: number must be positive and less than 32 Ähnliche Fehler melden auch /converted/abaud.inc, /converted/command.inc sowie /converted/uart.inc (ob es sich um folge Fehler handelt kann ich leider nicht beurteilen) Dies ist soweit auch korrekt, da PORTH definitiv >= 32 ist. Die relevanten Einträge aus: /atmel/m2560def.inc
1 | |
2 | |
3 | |
4 | |
5 | |
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
Gast
#5097183
Hallo Markus, das ist kein richtiges Problem, sbi, cbi sind nur für bestimmte Adressbereiche nutzbar. Wir nutzen in unsere Entwicklungsumgebung folgende Macros. Als Arbeitsregister wird WL verwendet, das muss im Code auf "frei" sein.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
Es folgt also noch umschreiben von IOPortInit:
1 | |
2 | |
3 | |
4 | |
5 | |
Gast
#5097186
Nachtrag, und man braucht natürlich noch diese beiden Macros
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
Gast
#5097191
Hallo Karl, Wow, Danke - das ging aber flott! werde dies gleich austesten. Freundlichst, Markus
Gast
#5097320
Hallo Karl, Bin etliche Schritte weitergekommen, in fastload.h: Im Kopf der Datei
1 | |
Neue Macros:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
Die von Dir genannten xin / xout macros waren nicht nötig, die sind bereits im /added/compat.h vorhanden. Angepasst:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
eine Unschönheit habe ich noch, in der /converted/abaud.inc
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
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
Gast
#5097882
Guten Morgen, Nach etwas weiterer Recherche bin ich auf folgende Lösung gekommen.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
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
Gast
#5098104
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
Gast
#5098187
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
Gast
#5098193
Siehe: Damit muss das Sprungziel erreicht werden: JMP k ; 0 <= k < 4M
1 | |
2 | |
3 | |
4 | |
> Also den breq durch rjmp ersetzt. da der "not equal" case bereits > abgedeckt ist dürft dies auf das selbe rauskommen. Prinzipiell richtig, aber der Befehl "brne _aba3" wird durch das Macro SKIP_RXD_0 ggf. übersprungen, oder eben nicht. Die Kombination SKIP/brne/breq ist zusammen also eine 3-fach Verzweigung. Vielleicht so:
1 | |
2 | |
3 | |
4 | |
5 | |
Gast
#5098360
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
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.
Gast
#5098540
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
Gast
#5099168
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"
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.
Gast
#5100385
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
Gast
#5100503
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.
Gast
#5100608
Hallo, ..einige Tests später, hier die angepasste Version. Diese Version enthält gegenüber dem letzeten Build in diesem Thread einige in der vorhanden Updates, sowie die Anpassungen aus: https://www.mikrocontroller.net/topic/goto_post/3362478 Meine Anpassungen, weiter oben in diesem Thread sind entsprechend raus, da dies bereits von Michael Hoffmann (verm. besser) hinzugefügt wurden. Beim Testen stellte sich heraus das ich noch einen Takt hinzufügen musste. Dieser was nötig damit 115'200 bps auf einem USB-SER Adapter (FTDI) klappt. Für RS232 direkt am PC war diese zusätzlich Takt nicht nötig, störte aber zumindest in meiner Umgebung nicht. Konkret: _memmap_delay von 3 auf 4 geändert in der /added/fastload.h
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Ein grosses Danke an alle! Es grüsst freundlichst, Markus
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.
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.
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.
Gast
#5775657
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?
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.
Gast
#5776290
Hallo, bei mir hat es funktioniert. Welche Fehlermeldung hast du denn bekommen? lg
Gast
#5776337
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!)
Gast
#5776484
Hallo DanielU, Setzte die passenden und hier richtigen Bootloaderflag!
Gast
#5776894
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.
Gast
#5776980
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
Gast
#5777068
So die Mitteilung vom Makescript ist nicht richtig? *** Note: set BOOTSZ fuses to the word address 0x3f00 ***
Gast
#5777106
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/
Gast
#5778255
So wie weiss man dass 0x3e00 ist die richtige Adresse? (Schade wenn das Script gibt falsches Information.)
Gast
#5778358
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
Gast
#5778365
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
Gast
#5778400
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
Gast
#5780706
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?
Gast
#5780826
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.
Gast
#5781488
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?
Angehängte Dateien:
-
Screenshot_20190322-225332.png
(250 KB)
-
Screenshot_20190322-225702.png
(230 KB)
Gast
#5782090
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.)
Angehängte Dateien:
-
SDS00002.png
(3,7 KB)
Gast
#5782127
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 --------------
Gast
#5782284
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?
Gast
#5782328
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?
Gast
#5783824
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.
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
Gast
#5784279
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.
Gast
#5784790
At least we have all learned something new again ?
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?
Gast
#5798406
Hallo, 1MHz? ich nutze entweder 8MHz oder 16MHz und jeder muss die richtigen Fusebits einstellen, so dass auch ein Bootloader schreiben darf!
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?
Gast
#5798562
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/
Gast
#5798563
Korrektur: der markierte Abschnitt: "-U flash:w:<dateiname>:a" abgerutscht.
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.
Gast
#5798587
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!
Gast
#5798592
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.
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
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).
Gast
#5798598
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.
Gast
#5798600
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.
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.
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/
Wenn ich mir das generierte File des Bootloaders ansehe, dann fehlt dort bei 0x0000 doch der Sprung zum Bootloader?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
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.
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.
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.
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?
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.
Gast
#5800813
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.
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.
Sorry für die Unklarheit: im obigen Post sind beide Diagramme gemessen am PD0 des µC.
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.
See ich das richtig, dass im ONEWIRE eine "1" (low-pegel) durch
1 | |
2 | |
3 | |
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.
Gast
#5802826
Hallo Randy B., bei mir sieht die Beschaltung, wie ähnlich aus. Quelle: habe ich mal irgendwo gefunden.
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?
Gast
#5803185
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.
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.
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 ...
Gast
#5803284
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
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.
Gast
#5803306
Hallo Randy B., ich nutze ein Linux Programm ================================================= | BOOTLOADER, Target: V2.1 | ================================================= No hexfile specified! ./booloader [-d /dev/ttyS0] [-b 9600] -[v|p] file.hex -d Device -b Baudrate -v Verify -p Programm Author: Andreas Butti (andreasbutti@bluewin.ch)
Karl M. schrieb: > Hallo Randy B., > > > ich nutze ein Linux Programm > > ================================================= > | BOOTLOADER, Target: V2.1 | > ================================================= > No hexfile specified! > ./booloader [-d /dev/ttyS0] [-b 9600] -[v|p] file.hex > -d Device > -b Baudrate > -v Verify > -p Programm > > Author: Andreas Butti (andreasbutti@bluewin.ch) Das (fboot) nutze ich auch, aber das meine ich nicht. Sondern auf dem µC (fastboot): https://github.com/jdeitmerg/fastboot
Gast
#5803360
Ok, fastboot-2.9 Version 140709
Karl M. schrieb: > Ok, > > fastboot-2.9 Version 140709 Von welcher Quelle? Oder kannst Du mir genau die Version zur Verfügung stellen?
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.
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?
Angehängte Dateien:
-
Compilerlog-Linux.jpg
(170 KB)
-
Bootloaderlog-Linux.jpg
(100 KB)
Selbst wenn: würde ja nicht stören. Korrekterweise müsste man den Puffer mit 0xff vorbelegen.
Gast
#5954175
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.
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.
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
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?
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
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).
Hallo Oliver, anbei der von mir verwendete Source Code.
@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.
Thomas N. schrieb: > er ist also definitiv beim "bootloaden" entstanden. Daran hatte ich nicht den leisesten Zweifel.
Ich habe nun zu Beginn von fastload.inc folgende Zeilen zum Löschen von PROGBUFF ergänzt:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Damit wandert mein Bootloader Start zwar von 0x3F00 auf 0x3E00, aber die undefinierten Code Fragmente hinter meinem Anwenderprogramm sind verschwunden.
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.
Gast
#5955025
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.
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
Gast
#5992862
Moin Männers, irgendwie bin ich zu Blöd den Bootloader zu Kompilieren. Ne hex-File bekomm ich mal nicht raus. Immer nur die Fehlermeldung Severity Code Description Project File Line Error atmel_def.mak: No such file or directory bootload C:\Users\Leopold\Downloads\Bootloader\fastboot_build30.tar\fastboot\Make file 120 Error recipe for target 'atmel_def.h' failed bootload C:\Users\Leopold\Downloads\Bootloader\fastboot_build30.tar\fastboot\Make file 166 Das ganze Läuft bei mir im Atmel-Studio7 und die ReadMe habe ich nach bestem wissen und gewissen beachtet. Gibts da irgendwelche Fallstricke Gruß aus dem Westerwald
Beitrag #5992863 wurde von einem Moderator gelöscht.
Beitrag #5992879 wurde von einem Moderator gelöscht.
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".
Gast
#5993680
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
Gast
#5994052
Guten Tag, in meiner Installation steht im Makefile ab Zeile 177ff:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Ich editiere dann nur noch die Datei get_avr_arch.sh:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Das Script liefert nicht das richtige, war mir zu müßig das zu debuggen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.