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
In asmPart.S -- entferne -- #if _AVR_MEGA_ #define XJMP jmp #define XCALL call #else #define XJMP rjmp #define XCALL rcall #endif ++füge ein #define XJMP rjmp #define XCALL rcall
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
P.S. Codegröße <= 512 Worte, nicht wie im ersten Beitrag angegeben 1024 Worte. ;) Werner
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 :)
gerade nochmal gelesen... 256 bytes ist natürlich quatsch, es sind 256 WORTE gemeint! Werner
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 !!
Das makefile muss an die eigene Umgebung angepasst werden. F_CPU, MCU, BAUDRATE etc.
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
Das Problem hatte ich auch - lag daran, dass die Bootloader- und die Megaload-Version nicht zusammenpassten.
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 */
|
2 | #define PROLOGUE_SAVES(offset) XJMP (__prologue_saves__ + 2 * (offset))
|
3 | #define EPILOGUE_RESTORES(offset) XJMP (__epilogue_restores__ + 2 * (offset))
|
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:
1 | AVR Studio 4.14.589 |
2 | GUI Version 4, 14, 0, 589 |
3 | JTAG ICE 1, 0, 0, 39 |
4 | AT90CAN128 170 |
5 | |
6 | Operating System (WinXP) |
7 | Major 5 |
8 | Minor 1 |
9 | PlatformID 2 |
10 | Build 2600 |
11 | Service Pack 3 |
12 | |
13 | Plugins: |
14 | |
15 | AVRSIM~1 1, 0, 0, 4 |
16 | AVRICE~1 1, 0, 0, 7 |
17 | AVRSIM~1 1, 0, 0, 4 |
18 | AvrPluginAvrAsmObject 1, 0, 0, 46 |
19 | AvrPluginavrgccplugin 1, 0, 0, 9 |
20 | Stk500Dll 1, 0, 1, 10 |
21 | AVRSIM~1 1, 0, 0, 4 |
PS.: Eine GCC-Portierung der Source von http://www.microsyl.com/index.php/2010/05/06/megaload-u-beta-tester-needed/ gibt es noch nicht, oder? PPS.: Mein AVRStudio Projekt anbei. ICC hab ich leider nicht zur Verfügung.
Hallo, ich hab' hier gerade mal die aktuelle Version ergoogelt: http://www.microsyl.com/index.php/2010/05/06/megaload-u-beta-tester-needed/
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.