Hallo zusammen, anbei ein LAN-Bootloader, den ich dieses Wochenende für mein Pollin-Board gebastelt habe. Vielleicht kann ja außer mir noch jemand etwas damit anfangen. Die Version im Anhang ist für einen Mega644. Nicht die Fuses vergessen: BOOTSZ1 = 0, BOOTSZ0 = 0, BOOTRST = 0. Der Bootloader wartet nach dem Einschalten/Reset 3 Sekunden auf Befehle des Flashtools. Bekommt er keine Antwort, wird die Applikation gestartet. Fragen, Kritik und Verbesserungsvorschläge willkommen. Tobias
Hört sich interessant an, es gab schon mal eine solche Implementierung hier im Forum. Möchtest du den Quellcode herausgeben? Ich würde den Bootloader gerne per Website aufrufen können. Grüße, Peter
>es gab schon mal eine solche Implementierung hier im Forum. In der Tat. Jetzt wo Du's sagst hab ich auch etwas entdeckt. Aber halb so schlimm. >Möchtest du den Quellcode herausgeben? Sobald die Sache etwas gediehen ist denke ich schon. >Ich würde den Bootloader gerne per Website aufrufen können. Lässt sich das nicht über einen jmp zu dessen Startadresse oder einen Watchdog-Reset erledigen, oder verstehe ich da etwas falsch? Anbei ein kleines Update mit einer Version für das originale AVR-NET-IO mit mega32-Controller. Die Fuse-Settings sind die gleichen wie beim mega644. Tobias
Ohne Quellcodes kan keiner damit wirklich etwas anfangen! Das Consolenprogramm ist unzureichend, und verbesserungswürdig! Zudem benutzt nicht jeder M32 und m644 für den ENC28j60!
>Ohne Quellcodes kan keiner damit wirklich etwas anfangen! Weil? >Das Consolenprogramm ist unzureichend, und verbesserungswürdig! Daher auch meine Bitte um Verbesserungsvorschläge :-)
Tobias wrote: > > Weil? > Mehr Augen mehr sehen als Zwei! Programmfehler sind so nur duch "merkwürdige Reaktionen" feststell aber nicht beseitigbar!
Also ohne codes ist sowas ja nahe zu useless, man kan ja nichts manuel nach bessert oder sachen adden :/
Dann schieß mal los mit Verbesserungsvorschlägen. Du willst mich doch hoffentlich nicht arbeitslos machen? :)
Naja, "Verbesserungsvorschlägen" ist ewas relative, was ich zB. gerne bräuchte wäre dsa der loader auch per Serial port ansprechbar wäre. Wer anderer würde vieleicht eine PW obtion brauchen, so das nicht jeder die firmware flashen kann, usw... Eine Binnary ist halt unflexibel.
Tobias wrote: > Dann schieß mal los mit Verbesserungsvorschlägen. Du willst mich doch > hoffentlich nicht arbeitslos machen? :) Geht nicht, da ich keinen M32 und M644 benutze! Dein Windowsprogramm werde ich auch so nicht öffnen, da ich nicht weis was im Code alles verborgen liegt! Du kommst um eine Codeveröffendlichung also nicht rum!
> Ich sehe es genauso: Ohne Sourcecode ist das unbrauchbar! Das verstehe ich nicht. Ich habe nur das Hexfile geflasht und es funktionierte auf Anhieb. > Du kommst um eine Codeveröffendlichung also nicht rum! Um was wetten wir? Naja, however: Hiermit entschuldige ich mich bei allen für meine Dreistheit, etwas, das vielleicht noch jemand außer mir brauchen könnte, einfach hier zu veröffentlichen. Kommt nicht mehr vor, versprochen. Tobias
Tobias wrote: >> Ich sehe es genauso: Ohne Sourcecode ist das unbrauchbar! > > Das verstehe ich nicht. Ich habe nur das Hexfile geflasht und es > funktionierte auf Anhieb. > >> Du kommst um eine Codeveröffendlichung also nicht rum! > > Um was wetten wir? > > Naja, however: Hiermit entschuldige ich mich bei allen für meine > Dreistheit, etwas, das vielleicht noch jemand außer mir brauchen könnte, > einfach hier zu veröffentlichen. Kommt nicht mehr vor, versprochen. > > Tobias Wenn Du meine Posts so liest wie Du sie zitierst, ist es klar das Du es nicht verstehst! Wie soll ich ein M32-Hexfile in nen M128 bringen? Das geht doch garnicht!
Leute, nun lasst ihn doch das machen wie er will... Wenn er den Code nicht veröffentlichen möchte (warum auch immer) dann ist das halt so. Ihr braucht seine Software ja nicht benutzen! Alle anderen freuen sich das es funktioniert (oder auch nicht) und sind auch glücklich...
Das hier ist doch ein Forum oder? Wenn er etwas postet, ohne Quelle, dann ist das nonsens! Eventuell hat er den Loader garnicht selber geschrieben, sondern im Netz gefunden. Solange er die Codes nicht offenlegt, erntet er keinen Dank! Alleine das Windows-Programm ist für mich verdächtig!
Peter Diener wrote: > Hört sich interessant an, es gab schon mal eine solche Implementierung > hier im Forum. Wo genau, irgendwie kann ich die grade nicht finden :/ @Tobias habe das teil man ganz vorsichtig ausprobiert und wen es drauf ist funtzt die uart Schnittstelle nicht mehr, kommt nur noch müll an :(
>Wo genau... Hier: Beitrag "Atmega via Ethernet flashen" Ich habe auch mal in dem AVR-Net-IO Thread etwas darüber gelesen, hier wurde vorgeschlagen, eboot von Ethernut als Basis dafür zu verwenden: Beitrag "Re: AVR für wenig Geld im LAN" Beitrag "LAN-Bootloader" Siehe: http://www.ethernut.de/en/eboot/index.html Grüße, Peter
Ich beschränke meine Antworten auf die konstruktiven Beiträge: @docean: Du schreibst mir aus der Seele :) @trax: Der UART wurde nach Verlassen des Bootloaders nicht in den gleichen Zustand wie nach einem Hardware-Reset gesetzt. Hätte nicht gedacht, dass das ein Problem werden könnte. Hab dies jetzt mal geändert. Das PC-Tool führt jetzt zusätzlich nach dem Schreiben noch ein Verify durch. Tobias
Hallo Tobias, ich habe das Tool ausprobiert und auf Anhieb Erfolg beim Programmieren gehabt. Herzlichen Glückwunsch! Vor ein paar Wochen habe ich eine andere Form von Bootloader programmiert: Er benutzt das Standard-Protokoll TFTP, um sich sein Hex-File von einem TFTP-Server zu holen. Falls jemand daran Interesse hat, ich habe den Stand 'as it is' mal angefügt. Er basiert auf Ulrich Radigs Webserver und ist soweit kompatibel zu ihm. Interessant evtl. das kleine Modul syslog.c, dass das Versenden von SYSLOG-Nachrichten erlaubt. Hiervon gibt es auch noch eine etwas erweiterte Version, die eigentlich zur Veröffentlichung bereitliegt. Beim Programmieren sind mir die Probleme mit dem Verlassen und Neustarten der AVR-Applikation auch untergekommen, gelöst sind sie noch nicht perfekt: Man sollte wohl am besten alle Interrupts der Applikation sicher sperren (also auch die einzelnen Enable-Bits), bevor man den Bootloader anspringt. Oder (besser UND) dieser sollte das als erste Massnahme auch tun, um Seiteneffekte zu verhindern. Vielleicht liegt es daran, dass Dein Bootloader bei mir nur nach einem Hardware-Reset funktioniert. Wenn ich meine Funktion zum Anspringen des meines Bootloaders verwende, geht nichts mehr: void command_load (void) { char temp; cli(); // Disable all interrupts temp = MCUCR; // Get MCUCR MCUCR = temp | (1<<IVCE); // Enable change of Interrupt Vectors MCUCR = temp | (1<<IVSEL); // Move interrupts to Boot Flash section asm volatile ( "jmp 0xE000" );// start bootloader } Zu meinem / unserem Verständis: Wie läuft die Kommunikation zwischen PC-Teil und AVR-Board ab? Da keine IP-Adressen angegeben werden, wohl irgendwie über Ethernet-Pakete mit Broadcast. Über Router hinweg kommt man da wohl nicht... Gruß Jens
@Tobias Danke, nun funtzt das uart wieder wie es soll :) Ich benutze das uart zum debugen lase mit da texte und so ausgeben.
@Jens: Um von der Applikation aus den Bootloader aufzurufen ist ein Watchdog-Reset vermutlich die sicherste Lösung. Eine elegantere Möglichkeit wäre vielleicht noch, den Bootloader selber anhand der entsprechenden Statusflags erkennen zu lassen wie er aufgerufen wurde und ihn ggf. selbst einen Watchdog-Reset auslösen zu lassen. Werde dies bei der nächsten Änderung mal umsetzen. Die Kommunikation läuft tatsächlich nur über Broadcasts und ist auf's LAN begrenzt. Ich wollte ein Tool haben, das komplett ohne Angaben von IPs/MACs oder der Einrichtung irgendwelcher Server einfach direkt nach dem Anstöpseln funktioniert. Im Augenblick fehlt jedoch noch jegliche Adressierung - will sagen: Sollten einmal mehr als ein Bootloader zur gleichen Zeit aktiv sein, gibt's mit Sicherheit Chaos. Steht aber schon auf der ToDo-Liste. @Trax: Endlich auch mal positives Feedback :) Freut mich! Tobias
Was noch cool wäre wäre wen man in der eigenen Anwendung irgendwie ein reset machen könnte so das man da das teil progen kann ohne hinzugehen und es manuell zu reseten, das wäre dieses Watchdog-teil wen ich das richtig verstehe, darauf freue ich mich schon. Ansonst was noch cool wäre, wären comando zeilen obtionen für 1- wie lange er warten soll incl unendlich 2- kein verify fals man nur schnell was testet Trax
Hallo zusammen, an einem handlichen Stück Code zum Auslösen des WD-Resets wäre ich auch interessiert. Bisherige Versuche sind da leider gescheitert. Wäre die optimale Abrundung zum Bootloader. Meine Version weiter oben hat allerdings einen Vorteil: Damit kann der Bootloader auch gestartet werden, wenn BOOTRST nicht aktiv ist... Trax Ideen zur Optimierung des PC-Tools klingen auch für mich schlüssig... Jens
@Trax: Während Deine Applikation läuft hat der Bootloader keine Möglichkeit, sich selbst zu starten. Das muss schon Deine Applikation auf ein Kommando von Dir hin erledigen. Dazu einfach den Watchdog starten und in einer Endlosschleife auf einen Reset warten. Voraussetzung ist natürlich - wie Jens schreibt - die aktivierte BOOTRST-Fuse. Die Kommandozeilenparameter sind in Arbeit.
Oki, soweit klar, aber wie kann ich nun in der Anwendung ein Reset auslösen, gibst da ne fertige C Funktion, oder muss ich in ASM irgendwas aufrufen?
@Jens schau mal unter folgenden Link [1], dort hatte ich schon mal gepostet wie man einen WD-Reset auslöst. Steht auch so in der AVR-libc als Beispiel. Funktioniert so auch auf einen ATmega644, auf einen ATmega32 habe ich es noch nicht getestet, sollte aber auch gehen. [edit] Danach könnte man im Bootloader doch abfragen ob es ein WD-Reset war oder nicht, und dann entsprechend den Bootloader ausführen? CAY Dirk [1] Link: Beitrag "Re: Atmega2561 Watchdog"
@ Dirk, danke für Deinen Tip, den ich jetzt mal umgesetzt habe: Das eigentliche Programm hat dieses Stück Code bekommen, um den WD auszulösen:
1 | //------------------------------------------------------------------------------
|
2 | // jump to bootloader
|
3 | void command_load (void) |
4 | {
|
5 | char temp; |
6 | |
7 | cli(); // Disable all interrupts |
8 | |
9 | // changing interrupt vector to bootloader section
|
10 | // only needed if BOOTRST is not used
|
11 | temp = MCUCR; // Get MCUCR |
12 | MCUCR = temp | (1<<IVCE); // Enable change of Interrupt Vectors |
13 | MCUCR = temp | (1<<IVSEL); // Move interrupts to Boot Flash section |
14 | |
15 | // enable watchdog and release it
|
16 | do { |
17 | wdt_enable(WDTO_15MS); |
18 | for(;;){} |
19 | } while(0); |
20 | }
|
Und im Bootloader wurde dieses eingefügt:
1 | //----------------------------------------------------------------------------
|
2 | // wdt_init - Watchdog Init used to disable the CPU watchdog
|
3 | // placed in Startcode, no call needed
|
4 | #include <avr/wdt.h> |
5 | |
6 | void wdt_init(void) __attribute__((naked)) __attribute__((section(".init1"))); |
7 | |
8 | void wdt_init(void) |
9 | {
|
10 | MCUSR = 0; |
11 | wdt_disable(); |
12 | |
13 | return; |
14 | }
|
Es scheint zu funktionieren. Die seltsame for/while-Schleife ist wohl für - oder besser gegen - den Optimierer? @ Tobias, wenn ich alles richtig verstanden habe, wäre es notwendig, dass auch Dein Bootloader den 'Watchdog-Absteller' bekommt, um per WD-Reset gestartet werden zu können. Ist das machbar? Denn ich merke schon, dass die Handhabung in vielen Fällen wesentlich einfacher ist als bei meinem. Zumindest wenn wir über ein kleines Netz reden. Jens
> ...dass auch Dein Bootloader den 'Watchdog-Absteller' bekommt...
Gute Idee. Hab ich soeben eingebaut.
Tobias
Also wen ich jetzt den code von Jens aufrufe wird der rebooten und eine neue FW laden, ist ja supi danke.
Also irgendwie funtzt das bei mir nicht, wen ich den code aufrufe bleibt das teil hängen und verbleibt so bis ich es lönger vom strom trenne :/
Sorry, das wird vermutlich mein Fehler gewesen sein. Probier's mal hiermit.
Moin, bin Anfänger(µC und C) deshalb meine blöde frage. Is an dem Code was auszusetzen? Und kann man das irgendwie besser schreiben? Vorallem diese Kopiererei am Anfang gefällt mir nicht wirklich. if((ip->IP_Destaddr == 0xFFFFFFFF) && ETHERNET_IP_DATAGRAMM ) { DEBUG_STACK("Broadcast empfangen...\r\n"); char str_buf[11]; for (int a = UDP_DATA_START;a < (UDP_DATA_START+11);a++) { str_buf[a-UDP_DATA_START] = eth_buffer[a]; } str_buf[11] = '\0'; if ( strcmp(str_buf, "AVRnetflash") == 0 ) { DEBUG("AVRnetflash -> reset..."); cli(); // disable interrupts char temp; temp = MCUCR; MCUCR = temp | (1<<IVCE); // Enable change of Interrupt Vectors MCUCR = temp | (1<<IVSEL); // Move interrupts to Boot Flash section do { wdt_enable(WDTO_15MS); for(;;){} } while(0); } } Grüße Hans Wurst
Hab den Bootloader auch gerade mal ausprobiert, völlig problemlos. Jetzt wäre es nur hübsch, wenn es das Flashtool auch irgendwie für andere Betriebssysteme gäbe... /Hannes
Johannes Studt schrieb: > Hab den Bootloader auch gerade mal ausprobiert, völlig problemlos. Jetzt > wäre es nur hübsch, wenn es das Flashtool auch irgendwie für andere > Betriebssysteme gäbe... > > /Hannes Falls Du mit "für andere Betriebssysteme" "für andere ATmegas" meinst, so spricht du mir aus dem Herzen :)
Hallo zusammen, aus aktuellem Anlaß zwei Ergänzungen zum meinem weiter oben gepostetem Bootloader per TFTP: - bei Files größer 48k gibt es Probleme. Abhilfe: In tftp.c, Zeile 70, die Variable tftp_block von Char auf Unsigned Int umstellen (Danke, Heiko!) - bei verschiedenen Compilerversionen wird der Bootloader zu groß. Da hilft sparen an den Texten... Gruß Jens
Hallo Jens, Mega vielen Dank :-) - mehr kann ich dazu nicht sagen außer dir noch Schöne Feiertage zu wünschen.
Hallo, bin vor einiger Zeit über diesen Thread gestolpert. Gibt es hier was neues? Finde den Bootloader von Jens Mundhenke interessant, habe ihn aber noch nicht auf meinem AVR NetIO mit 644P getestet. Hab nur kurz die Quellen übereflogen. Sehe ich das richtig, dass sich der Atmel nach jedem Reset mit dem TFTP verbindet und updatet? Oder hab ich was übersehen? Gruß, Alexander
Der TFTP-Bootloader wird mittlerweile von mehreren Personen zusammen mit einem ATmega 644 auf dem AVR-NET-IO genutzt und funktioniert meines Erachtens hervorragend. Richtig ist daß der Bootloader bei jedem Hardwarereset aktiv wird und sich das Bootfile zieht. Vermutlich ist das auch nur über das Ablegen einer "Seriennummer" sowohl im EEPROM wie auch auf dem TFTP-Server abzustellen, da für eine Überprüfung des Hexfiles zuerst eingelesen und mit dem Flash-Inhalt vergleichen werden müßte. Viele nutzen den Bootloader im Zusammenhang mit dem tftpd32 für Windows und starten den tftpd32 nur wenn sie neu flashen wollen. Unter Linux verlinke ich avr0.hex (so heißt die angeforderte Datei bei mir) mit der entsprechenden WebserverXXX.hex und lösche den Link nach erfolgreichem Booten.
Wenn kein TFTP-Server gefunden wird, wird also normal gebootet?
Danke für die Info. Gibt es einen aktuelleren Stand als den weiter oben (newStack1_1_00_bootloader_console_20090316.zip)? Gruß, Alexander
Dominique Görsch schrieb:
> Wenn kein TFTP-Server gefunden wird, wird also normal gebootet?
Ja bei einem Timeout sprint der Bootloader zum (hoffentlich)
existierenden Code
xelarep schrieb: > Danke für die Info. Gibt es einen aktuelleren Stand als den weiter oben > (newStack1_1_00_bootloader_console_20090316.zip)? Nicht offiziell. Ich habe mir eine eigene Version gemacht mit rein optischen Veränderungen und enthält sonst nur die hier im Thread angesprochenen Änderungen (wegen Hexfilegröße).
Hallo zusammen, schön, dass sich der eine oder andere für den Bootloader interessiert. Änderungen gibt es wirklich keine, vielleicht, weil ich ihn derzeit selbst gar nicht nutze ;-) Sollte jemand Wünsche haben, kann er sie ja hier gern schreiben, gibt allerdings keine Umsetzungsgarantie, zu viele andere Basteleien auf dem Tisch. Wäre ein Pin, der den Loader dazu bringt, nichts zu tun, ok? Andere Idee habe ich auf die Schnelle nicht... Gruß Jens
Ein Pin wäre keine schlechte Sache. Sollte aber konfigurierbar sein welcher und im Idelfall auch noch ob er bei High oder Low via TFTP bootet.
Eine weitere, sehr nette Firmware ist http://ethersex.de/. Es lässt sich auch ein TFTP-Bootloader bauen: http://ethersex.de/index.php/Downloader Besonders nett ist, dass die Firmware sowohl IPv4 als auch IPv6 unterstützt. Dazu unterstützt sie noch diverse Protokolle und Dienste und ist modular aufgebaut (erweiterbar). Gruß
Hallo Jens, Tobias, * ich bin schon längere Zeit auf der Suche nach einem wirklich "kleinen" LAN Bootloader für den ATmega 644. Vom Platz her bräuchte ich so was wie das FastBoot von Peter Dannegger mit 512 Byte, allerdings habe ich wg. Pinmangel keine RS232 mehr auf meinem Board. Andererseits ist das Flash meine 644ers schon ziemlich ausgelutscht. Jens' Bootloader wäre eine feine Sache, allerdings sind mir die 8k BOOTSIZE definitiv zu viel. Nachdem ich mal in den Code gesehen habe, ist mir aufgefallen, daß evtl. Potential für Größenoptimierung im IHEX Teil besteht, wenn man direkt binaries + CRC überträgt. Allerdings ist das Potential sehr beschränkt durch die TFTP-Wahl, da ja zumindest ein rudimentärer Protokollstack für Schicht 1-5 implementiert werden muss. Interessanter könnte da der Ansatz von Tobias sein, da hier schätzungsweise über Schicht 2 geflashed wird. Ohne Source ist leider nicht definitiv zu sagen, wenn man nicht den Wireshark bemühen möchte. Ohne es getestet zu haben, habe ich mal das HEX File angeschaut und komme das auf eine Bootfile-Size von 4k (korrekt ?). Allerdings hilft mir der AVRnetflash nicht wirklich weiter, da ich mangels Source das Programm nicht verwenden möchte. Die Randbedingungen auszutesten, z.B. komme ich mit dem Protokoll über Router (schätze mal nicht, wäre aber o.k für mich), was passiert, wenn ich mehrere Targets im Netz betreibe, Bootkonfiguration, Target nicht 100% Funktionskompatibel zu Pollin AVR sind mir zu unüberschaubar. Deshalb meine Frage: Gibt's neben ethersex und den beiden genannten Implementierungen noch andere "kleine" LAN-Bootloader, oder ist Tobias Implementierung schon soweit 'gediehen' daß eine Codeveröffentlichung möglich/gewünscht ist ? Viele Grüsse Andreas
hallo, gibt es für diesen Bootloader eine 644p und 1284p Unterstützung? gruss Jonas
Sorry fürs aufwecken;) Hier mal eine erweiterte Version des Bootloaders von Jens. Der kann jetzt auch ATmegas mit mehr als 64kB flashen. Getestet mit ATMega1280. Das lesen und flashen einer IHEX Datei mit Daten größer 64kB funktioniert nach ersten Tests. ATMega1284P, ATMEga640, ATMega2561 usw. sollten mit evtl. kleinen Änderungen am Code auch gehen.
@Jens @Holger Vielen Dank für die Umsetung. Was noch schön wäre einen Port für zb. xMega128A1. lg, markus
Hallo, ich grabe mal diesen Thread aus. Hier mein AVR Ethernet Bootloader für ENC28J60. Der Bootloader ist 4K groß und ist eigentlich für mein AVR Art Net Node gedacht (ATmega328). Andere Hardware sollte mit einigen Anpassungen auch gehen. Natürlich mit Sourcen ;-) Gruß Uli
sporky schrieb: > welche änderungen müßte man für einen Atmega1284p im AVR-Net-IO machen? Erstmal alles, was der Compiler als Fehler auswirft ;)
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.