Hallo,
ich habe mir den AVR Bootloader Teil des
http://www.microsyl.com/megaload/megaload.html
auf avr-cgg portiert ().
Wegen des doch relativ großen startup-code der avr-libC ist leider kein
512 wort bootloader möglich, aber der kombinierte flash+eeprom
bootloader passt immer noch in 1024 worte.
Seit mehreren wochen problemlos mit mega8, mega32 und mega128 in
verwendung.
Den windows counterpart und die docu dazu gibts unter oben genannter
URL. Alles weitere ... Makefile und main.c analysieren ;-)
With permission of Sylvain Bissonnette <Zitat>Yes you can there is no
problem!</Zitat>
Viel Spass
Werner
Habe versucht den Code zu Kompilieren mit AVRGCC 3.4.1 ,
bekomme aber eine Fehlermeldung........
avr-gcc -c -mmcu=atmega8 -I. -gdwarf-2 -DF_CPU=12000000UL -Os
-mcall-prologues -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst
-std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccaMaaaa.s: Assembler messages:
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccaMaaaa.s:497: Error: illegal
opcode jmp for mcu atmega8
make: *** [main.o] Error 1
Jemand eine Idee ? Ich leider nicht....
CPU in die MakeFile auf Mega8 gesetzt..... und den FCPU Wert
auf 12MHZ gesetzt, sollte aber nicht das Problem sein...
MfG,
Robert
Witzig aber wahr..
Änderung gemacht wie beschrieben, wieder die Fehlermeldung.
Mahl den CPU-Typ geändert auf Mega16, wunderbar! Code Kompiliert,
leider selber kein mega16 zuhause.....
??????
Robert
Hallo!
Hat schon jemand Erfahrung, bzw. kann mir erklären wie ich mit UISP die
Software kompilieren kann? Was muss eingetragen werden damit es die
Applikation wird und was damit es der Bootloader wird?
Die hex-files sehen ja unterschiedlich aus. Wie kann man das steuern?
Danke im Vorhinein.
Für den neuen MegaLoad.NET ... (der mit dem nervenden "You have time to
read")
"Old BootLd. compatible" setzen.
Der Bootloader aus der .NET version bringt (noch?) keine wirklichen
vorteile, da die neuen MCUs nicht wirklich unterstützt werden.
Jetzt habe ich mir die arbeit gemacht die änderungen des bootloader des
neuen MegaLoad.NET v4 auf AVR-GCC zu portieren. Dabei wurde die größe
des resultierenden codes durch umstrukturierung einiger codepassagen
und konsequenten einsatz von "static inline" weiter geschrumpft.
Erfolg:
bei verwendung einer festen baudrate und ohne die EEPROM programmier
funtionalität passt jetzt der bootloader für die mega8-familie in 256
Worte (512 bytes)
Der BOOTSTRT im makefile muss jeweils entsprechend angepasst werden.
Schalter im Makefile
Mit -DMEGALOAD_NET wird die kennung für den MegaLoad.NET
einkompiliert.
Ohne -DMEGALOAD_NET gehts auch mit dem Vorgänger MegaLoad v3.
Getestet ist allerding erst auf einem Mega128 da dieser alle
funktinalitäten unterstützt.
Rückmeldung über funtionalität auf den anderen MCUs erbeten.
Werner
Hallo Werner,
Hatte bis jetzt immer den von Arthur de Beun für WinAVR modifizierten
Bootloader verwendet. Der brauchte aber mehr als 512 Byte. Dein Code
passt ja in einen 256 Wort großen Bootloader. Auf dem Mega8 ging es
auch sehr gut. Nur nach dem download mit Megaload v3 startete das
Anwenderprogramm nicht. Ich habe dann am Ende
#if FLASHEND > 0x1FFF
asm("jmp 0x0000" : :); // Run application code
#else
asm("rjmp 0x0000" : :); // Run application code
#endif
durch
asm volatile ("push r1" "\n\t"
"push r1" "\n\t"
"ret" "\n\t"
::);
aus dem Code von Arthur de Beun ersetzt. Nun startet das
Anwenderprogramm nach erfolgreichem download. Das ist für meine
Anwendung sehr wichtig.
Gruß Frank.
Nochmals weiter überarbeitet und durch "wegotimieren" der
vektortabelle
(-nostartfiles -nodefaultlibs und eigenständiges, extrem reduziertes
startupfile) passt der bootloader für mega8 mit allen (sinnvollen)
features in weniger als 512 bytes. mega16, wenn ohne EEPROM oder (ohne
LOCKBIT+mit fester BAUDRATE und nur mit MegaLoad v3 option) auch in <=
256 bytes.
mega32 ohne EEPROM oder ohne LOCKBIT in <= 256 bytes. mega64 ohne
EEPROM option in <=256 bytes. mega128 kann ja minimal nur 512 bytes
bootsection programmieren, damit ist ein 256byte bootloader sinnlos.
zusätzliche änderungen:
- USART vor programmstart wieder deaktivieren.
@Frank
- ich hatte damit zwar keine probleme, ist aber übernommen worden :)
Danke für deine Portierung (und passend dazu die zusätzlichen Zeilen für
den c't COM-auf-LAN Adapter). Funktioniert wirklich gut auf dem
8535er.
Im Makefile hat sich ein Fehler eingeschlichen, der jedoch nur bei der
Nutzung über den XPort vom c't COM-auf-LAN Adapter zur Geltung kommt:
'DEST_DEST_XPORT' muss in 'DEST_XPORT' umbenamst werden.
Was mich wundert ist BOOTSTRT=0x1E00, denn gemäss Atmel Specs, Seite
233, sollte bei 256 Wörtern der Bootloader doch bei 0x1F00 liegen.
Setze ich BOOTSTRT=0x1F00, meldet der Linker jedoch ".text is not
within region text"... Hab das Makefile dem Posting beigelegt.
Config-Bits in PonyProg: Häkchen bei "Z1", keins bei "Z0": ist dies
die korrekte Einstellung für BOOTSTRT=0x1E00? So funktioniert es
zumindest...
@Olivier
Das 'DEST_DEST_XPORT' ist nie getestet worden, nur zur komplettierung
gedacht, Du hast natürlich Recht.
Wegen 0x1E00: - Der Linker den Offset in Bytes
erwartet, nicht als Worte.
8 kBytes = 0x2000 Bytes.
256 Worte = 512 Bytes = 0x200 Bytes.
0x2000 - 0x200 = 0x1E00;
Also liegt der Bootloader auf 0x1E00, logisch ;)
hallo zusammen,
große Leistung! hab schon lange danach gesucht!
Nur hab ich ein kleines Problemchen mit BootLoad_NET_GCC_v0_0_2.zip
Megaload.NET erkennt meinen Mikrocontroller falsch (Mega165 statt
Mega32), obwohl der richtig in makefile eingestellt ist, und dann bei
flashen tut sich nichts.
hat jemand Ideen?
danke
Sorry, aber wie schon im Sourcecode steht
//* ATMega165 not tested, please give me feedback!
Ich habe den Quellcode des Megaload.NET nicht, kann also auch nicht
nachsehen warum der statt Mega165 ein Mega32 erkennt :(
Stimmen denn die Bauraten? Am besten immer mit festen Parametern
arbeiten.
Guten Rutsch in's neue Jahr an Alle
Werner
Danke für schnelle Antwort, Werner,
kleine Korrektur,
ich habe einen Mega32, erkannt wird aber ein Mega 165.
Könntest Du mir schon getestete und kompilierte Version für
Megaload.NET posten?
Wenn das nicht geht, dann vielleicht für die vorlezte
Megaload-Version.
danke noch mal und guten Rutsch!
ATMEGA32.HEX für Megaload.HEX mit Autobaud, LOCKBIT und EEPROM enabled.
Gelinkt auf Bootload-Adresse 0x7C00 (Fuse für 1KB Bootloader).
Happy new year!
Werner
Hallo,
habe hier wohl ein Anfängerproblem. Wo stelle ich denn ein welche CPU
ich nutzen möchte?
Bekomme beim Befehl make all immer die Meldung "No rule to make
target".
Hallo,
habe hier wohl ein Anfängerproblem. Wo stelle ich denn ein welche CPU
ich nutzen möchte?
Bekomme beim Befehl "make all" immer die Meldung "No rule to make
target".Habe das letzte ZIP in ein Verzeichnis entpackt und rufe da
das MAKE ALL auf.
Ich wäre für eine kurze Hilfe dankbar, brenne zur Zeit immer mit ISP
meinen Atmega162, so ein Bootloader wäre praktisch.
Vorab danke !!
Hallo Werner,
danke. Mit der Version 1 ging es sofort, ich habe im Makefile MCU,
Frequenz und Start angegeben.
Mit der Version 2 gab es immer den Fehler
C:\WinAVR\bin\..\lib\gcc\avr\3.4.3\..\..\..\..\avr\bin\ld.exe:
missing argument(
s) to option "--section-start"
Hab dann Version 2 mit dem Makefile von Version 1 kompiliert und es gab
keinen Fehler (juhu...).
Muss die Tage mal probieren ob es läuft.
Danke!!
War erfolgreich, das funzt wie verrückt.
Was muss man ändern damit es auch mit dem AVR Studio läuft? Ist das
auch machbar?
Schönen Tag noch und danke!!
Thomas
AVR Studio - wo ist das Problem?
Hex-File erzeugen, MegaLoad starten und .hex auswählen.
Bei jedem Reset des AVR wird jetzt das jeweils aktuelle .hex file
programmiert. Problem ist nur falls keines erzeugt wurde.
Ich meinte Programm download mit AVR Studio ohne Megaload.
Das Studio kann ja auch Bootloader erkennen und damit programmieren.
Scheint aber anders zu kommunizieren, der findet diesen BL nicht. Muß
ich da im MAKE File etwas ändern?
Hallo,
ich habe ein Problem mit einen mega128 bei dem ich
nicht weiterkomme.
Wenn ich ein "hello world" Programm mit dem gcc 3.4.3 übersetze
dann läuft das auf einem mega 15 von Adresse #0 oder von der
Bootloaderaddresse. Wenn ich diese Sourcen für einen m128
übersetzte dann läuft dieser Code von Adresse #0 aber nicht als
Bootloader von 0x1fc00.
Das Makefile habe ich von Eurem abgekupfert. Die Mainfunktion ist
nur ein bisschen LCD Ansteuerung mit "Hello Wold" Ausgabe.
Weis jemand eine Antwort?
1. Mit .rar kann ich nix anfangen.
2. Wohl beim "abkupfern" des Makefile etwas übersehen.
3. Bester Tipp: Das makefile des bootloader genau analysieren!
In der von Dir verwendete Form von PROGMEM sind nur die ersten 64kB des
Flash erreichbar. Du musst jenseits der 64KB Grenze auf
pgm_read_byte_far() ausweichen und/oder das RAMPZ Register
mitverwalten.
Hallo,
ich habe ein Problem mit MegaLoadGcc.
Ich habe die makefile angepasst, die fuses gesetzt (BOOTRST und BOOTSZ
11), kompiliert, übertragen, hat alles gelklappt.
Megaload gestartet, den passenden COM-Port und passende baudrate
eingestellt (nur RTS beide checked).
Meinen Mega128 resetet, das Target wird dann von MegaLoad_NET erkannt
(Mega 128, Page Size: 256Bytes, BootSize: 512, FlashSize 128kByte,
EEpromSize: 4k Bytes).
Im Messagefenster steht dann folgendes:
- Open Flash Hex File
- Flash Hex File OK 18808 Bytes
- Sending Page #0 (5x)
- Programming Failed
- Sending Page #0
- Programming Failed
...
hat jemand eine Ahnung woran das liegen kann?
was mir auch noch aufgefallen ist, dass egal welche Baudrate ich in der
Makefile eingegeben habe, immer mit 9600baud das Startzeichen gesendet
wird und das obwohl Autoscale nicht definiert ist. Auch wenn ich die
Baudrate nicht definiere sendet er mit 9600.
Hat jemand eine Idee, woran das liegen kann?
Viele Grüße und danke
Clemens
HAllo,
das hilft Dir zwar nicht weiter, aber bei mir sieht das genauso aus.
Der Bootloader meldet sich >>>>> oder im Megaload.net mit UUUUU,
dann wird die erste Page gesendet aber es kommt kein responce.
MIchael
Hallo zusammen,
Ein kleiner Tipp, für alle, die wie ich am verzweifeln sind, weil ihr
AVR nicht richtig erkannt wird:
ich hab den Bootloader auf einem M128 laufen und wollte ihn auf einem
Mega32 zum laufen kriegen. - Leider erfolglos, er wurde nicht richtig
erkannt (meistens als Mega165).
Nachdem ich so ziemlich alle versionen der .hex-files ausprobiert hatte
und nicht mehr weiter wusste, hab ich einfach mal den
Pegelwandler(MAX232N) gegen ein anderes Exemplar ausgetauscht... und
siehe da, es funktioniert... (obwohl der andere MAX232 noch
funktionstüchtig war...)
Gruß
Johannes
Hallo, nach einem mäßigem Kampf mit dem Makefile hab ichs geschafft und
den Bootloader erfolgreich für einen ATmega16 Compiliert und Geflasht.
Er meldet sich mit "UBUBUB usw"
Leider will MegaLoad nicht.
Sendet 5x Page 0 und meldet "Programming Fail"
Hat jemand erfahrung ob die Sache mit MegaLoad .NET:7.0 noch unverändert
funktioniert.
@Clemens hast du eine Lösung finden können? welche?
Vielen Dank
Dominik
Hallo,
ich habe mir obige Version <BootLoad_NET_GCC_v0_0_2.zip> runtergeladen.
Ich habe noch ein paar Änderungen vorgenommen und für einen
mega16 compiliert, ist alles gut.
Nun habe ich umgestellt auf mega8 und bekomme nun auch die
Meldung:
../lib/gcc/avr/4.3.0/../../../../avr/bin/ld.exe: address 0x2082 of
atmega8.elf section .text is not within region text
im makefile habe ich den mega8 so aktiviert, d.h. auskommentiert:
# MCU name
# BootLoader mega8(5x5) 512 bytes => 0x1E00 =
(0x1000words<<1)-0x200bytes
BOOTSTRT = 0x1E00
MCU = atmega8
Heist das, mein Programm ist zu gross?
Ich verstehe auch ehrlich gesagt nicht den Zusammenhang von BOOTSTRT =
0x1E00
zur CPU, weil die Startadressen der BL section bei 0xF00 (256w) bzw.
0xE00 (512w) liegen.
Kann mir bitte jemand auf die Sprünge helfen?
gruss.
Uff, ist das lange her.
A) Da musst du evtuell mit der Optimierung des AVR-GCC spielen. Das Teil
ist damals für die Version 3.x optimiert worden (und der war etwas
"sparsamer" als der aktuelle 4.x). Obwohl 130 Bytes schon heftig ist.
Zusätzliche Optionen kannst du testen (ohne Garantie)
OPT += -fno-tree-scev-cprop
OPT += -fno-inline-small-functions
Und beachte zusätzlich:
Beitrag "Re: MegaLoad für avr-gcc"> +mit fester BAUDRATE und nur mit MegaLoad v3 option)> auch in <= 256 bytes.
B)
0xF00 ist die Wort-Adresse. Der AVR-GCC erwartet aber Byte-Adressen.
0xF00 Worte = 0x1E00 Bytes
0xE00 Worte = 0x1C00 Bytes
Danke Werner, ich hatte das mit den Byte und Word Adressen
verwechselt. Jetzt läuft es mit dem atmega8.
Leider habe ich beim arbeiten mit dem atmega128 das gleiche Problem wie
weiter oben von cauboy beschrieben. Das PC-Programm kommt nicht über
Sending Page0 hinaus. Ich habe beim debuggen heraus gefunden, das die
CPU neu startet
(Reset) wenn in WriteFlash() die Funktion "fill_temp_buffer()"
aufgerufen wird. D.h. er kommt nicht weiter als zu dieser Stelle, hängt
sich auf und startet den Bootloader neu.
Gibt es eine Lösung für dieses Problem ?
Da ich den ATmega128 selbst damit eingesetzt hatte bin ich mir sehr
sicher dass es in dieser Version geht.
Was ich mir vorstellen kann:
A) Die Mega103 Compatibility fuse noch gesetzt?
B) Kein "make clean" nach/vor dem Wechsel von mega8 auf mega128.
C) Dass die neuere Compilerversion doch etwas mehr "anders" macht.
Ich kann es (in nächster Zeit) leider nicht nachstellen.
Werner
Jetzt habe ich das Problem mit dem aktuellen AVR-GCC gefunden.
Beim AVR-GCC 3.x wurde im main() noch der Stack inititialisiert. Darum
hatte ich aus Platzgründen die Initialisierung aus der gcrt1.S entfernt.
Seit AVR-GCC v4.x wird der Stack nicht mehr im main() initialisiert.
Darum muss das jetzt wieder im gcrt1.S passieren.
Werner
Hallo,
Da ich die entsprechende Umsetzung noch nicht gefunden habe, probiere
ich mich gerade daran den Bootloader für MegaLoad_NET auf den AT90CAN128
zu portieren.
Leider kriege ich beim Kompilieren von Bootloader_NET_GCC_v0_0_2
folgende Fehlermeldung:
1
...\BootLoad_NET_GCC_v0_0_2/main.c:691: undefined reference to `__prologue_saves__'
Der Fehler scheint allerdings nicht aus der main.c, sondern aus der
Datei macros.inc zu kommen:
1
/* used only by fplib/strtod.S - libgcc internal function calls */
strtod.S kann ich auch meinem Rechner auch nicht finden, hab deswegen
von WinAVR-20090313 auf WinAVR-20100110 gewechselt. Leider ohne Erfolg.
Trotz intensiver Recherche hier, anderen Foren und einschlägigen
Suchmaschinen bin ich nicht wirklich weiter gekommen.
Der Rest meiner Entwicklungsumgebung:
