Peter Dannegger wrote: > Michael H* wrote: >> kann es sein, dass der Bootloader eine Software-UART benutzt? > > Ja das tut er, sonst könnte man ja keinen ATtiny13 benutzen. > Und für die mit UART wollte ich mir nicht zusätzliche Arbeit machen. > > >> Wie würde es denn mit der Größe ausschaun, wenn man die Hardware-UART >> einsetzt - käme man vielleicht auf 128 Worte? > > Ja, mit HW-UART und ohne Autobaud, sollte es möglich sein. > > Ich sehe aber nur einen einzigen, wo das etwas bringt, den ATtiny2313. > > Alle Megas sind ja bis mindestens 16k zu haben und da sind 1,5% mehr > kaum der Rede wert. > > > Peter die Watchdog Definition im include-file beim m32 scheint anders codiert zu sein als beim m64? Ist das beabsichtigt. Habe beim m32 einen Compilierungsfehler da er den wdce nicht findet beim m32, der aber z.B. beim m64 und m8 vorhanden ist. habe die entsprechende Zeile probehalber in der m32 Deklaration aufgenommen und das compilat kommt ohne fehler zum Ende. Ich bin mir nicht sicher, ob der m32 dann auch laufen wird. Habe auch derzeit keinen um das zu probieren... Wäre nett eine Info zu bekommen!
Raimund Reh wrote: > die Watchdog Definition im include-file beim m32 scheint anders codiert > zu sein als beim m64? Ist das beabsichtigt. Das mußt Du Atmel fragen. Deshalb habe ich entsprechende Definitionen eingefügt:
1 | ;------------------------------------------------------ |
2 | ; redefinitions for compatibility |
3 | ;------------------------------------------------------ |
4 | .ifndef WDTCSR |
5 | .equ WDTCSR = WDTCR |
6 | .endif |
7 | ;--------------------------- |
8 | .ifndef WDCE |
9 | .equ WDCE = WDTOE |
10 | .endif |
11 | ;--------------------------- |
Peter
Hallo zusammen, zunächst erstmal ein Dankeschön an Peter für den tollen Bootloader. Hab ihn der Version 2.1 mit dem ATmega16 schon mehrfach erfolgreich eingesetzt und finde es echt praktisch auf dem Target keinen ISP-Header mehr auflöten zu müssen. Leider konnte ich ihn heut morgen allerdings nicht dazu überreden einen ATtiny2313 zu beschreiben. Als Software hab ich die letzte hier gepostete Linux-Version von fboot verwendet. Anscheinend befindet sich der Tiny im Dauer-Reset sobald der Bootloader geflasht ist. Wenn man dann fboot startet, erkennt es auch gleich den Bootloader und schreibt die Applikation anscheinend erfolgreich in den Chip. Startet man anschließend fboot mit der Option -v (verify) dann startet SOFORT wieder der Auslesevorgang. Nachdem der Chip gelesen wurde wird jedoch ein Fehler ausgegeben: Verify test.elf.hex: 00000 - 000A9 failed! Wenn man dann mit AVRDUDE den Chip ausliesst, steht auch nur 0xFF im Speicher. Hat schonmal jemand hier erfolgreich einen ATtiny2313 unter Linux mit dem Bootloader geflasht? Woran kann es liegen, dass der Linux-Client meldet dass die Software erfolgreich geflasht wurde, anscheinend aber nix geschrieben wurde?
Hi, welchen Linux-client hast Du verwendet? Two-wire modus? Falls Interesse besteht, ich habe den Linux Client von Andreas Butti "erweitert" (ich glaube, es war nicht seine letzte Version...), im wesentlichen habe ich mir den one-wire mode eingebaut... Im übrigen kannst Du unter Linux auch Peters original DOS-fboot unter DOSEMU benutzen... mal testen, obs damit läuft. Gruß, Bernhard
Bernhard M. wrote: > Falls Interesse besteht, ich habe den Linux Client von Andreas Butti > "erweitert" (ich glaube, es war nicht seine letzte Version...), im interessemeld ^^ ich suche noch nach einer möglichkeit, den bootloader schön in ein makefile zu packen. mit dosemu hatte ich keinen erfolg.
Na ja, dosemu im Makefile kann ich mir auch nicht vorstellen... Heute abend kann ich den posten, habe ihn nicht hier. Ich hab ihn übrigens bei mir auch im Makefile
Ronny wrote:
> Verify test.elf.hex: 00000 - 000A9 failed!
Warscheinlich die SELFPRGEN Fuse.
Peter
Jap, es war tatsächlich die SELFPRGEN Fuse. Nachdem das korrigiert war, lief zumindest der Verify einwandfrei durch. Merkwürdig ist allerdings, dass die Testapplikation (Port-Pin gewackel) in der Assembler-Version ordentlich läuft während die GGC-Variante davon weiter im Dauer-Reset hängt. Am C-Programm kann es eigentlich (fast) nicht liegen, per ISP geflasht tut sie es nämlich wie erwartet. Kann es sein dass der GCC irgendwelche Schweinereien mit der Interrupt-Vektor-Tabelle anstellt? Ist halt nur sehr merkwürdig, dass beim Atmega16 auch C-Programme problemlos geladen werden...
Hallo, hier nun der oben erwähnte Linux client source für fboot21. Ich habe den source von Andreas Butti etwas erweitert, so daß der one-wire Modus geht (ging zumindest in der Version die ich hatte nicht) und die Übertragungszeiten auch mit USB-Konverter entsprechend sind. Ausserdem gibts einen Fortschrittsbalken... Gruß, Bernhard
Zum Problem mit den ATtiny2313 noch einmal... Die C-Anwendung die nicht wollte basierte auf einem automatisch generiertem Makefile der Code::Blocks IDE. Nachdem ich hier noch einmal ein neues C-Projekt angelegt habe, lief das compilierte Programm auf einmal. Sobald ich dazu komme vergleiche ich einmal die beiden Makefiles, anscheinend ist in einem eine Option drin welche dem Bootloader nicht gefällt bzw. ihn davon abhält in die Applikation zu springen. Nochmal danke für die schnelle Hilfe und den schönen Bootloader :) Gruß, Ronny
Hi, im Linux-bootloader war noch eine uninitialisierte Variable für die Flash-size.... Hier die korrigierte Version. Gruß, Bernhard
Hallo zusammen, ich hoffe mir kann jemand helfen. Ich habe den Fastload V1.4 auf einen Mega8515 angepasst. Als grundlage habe ich den M8 genommen. Das Problem ist jetzt nur, ich kann das Porgramm wunderbar übertragen, aber der Bootloader springt nicht in das Programm. Wenn ich dann den Reset Knopf drücke springt startet er sofort das Hauptprogramm. Der Bootloader funktioniert wie erwartet, nach einen Reset ist er ansprechbar. Gruß Martin
Martin Baumann wrote: > Hallo zusammen, > > ich hoffe mir kann jemand helfen. Ich habe den Fastload V1.4 auf einen > Mega8515 angepasst. Als grundlage habe ich den M8 genommen. > > Das Problem ist jetzt nur, ich kann das Porgramm wunderbar übertragen, > aber der Bootloader springt nicht in das Programm. Wenn ich dann den > Reset Knopf drücke springt startet er sofort das Hauptprogramm. > > Der Bootloader funktioniert wie erwartet, nach einen Reset ist er > ansprechbar. > > Gruß Martin FUSE-Bits richtig gesetzt?? http://www.atmel.com/dyn/resources/prod_documents/doc2512.pdf hier findest Du alles notwendige, Seite 166, bzw. Seite 196 für das Flag BOOTRST Seite 177 für das FLag BOOTSZ0, BOOTSZ1 solltest du das Pferdchenprogramm verwenden sind die Bits jeweils zu invertieren viel erfolg 1. nachtrag - o.g. gilt natürlich nur für den Bootloader als solchen.
Hallo Raimund, danke für die Antwort. Die Fuses hatte ich richtig gesetzt. Mittlerweile habe ich herausgefunden das die Version 1.4 bei mir nur dann richtig funktioniert wenn ich für die Übertragung mit einen USB-zu-Seriell wandler benutze, bei einem festverbauten Com Anschluss Startet das Programm nicht. Als Abhilfe benutze ich jetzt die Version 1.7 hier stehen zwar noch tests aus, aber erste Tests haben gezeigt das es funktioniert. Was ich komisch fand, bei der Analyse meines Com Prots musste ich festellen, das bei den festverbauten Com Anschlüssen die Übertragung nicht mit "A6 05" Abschließt wie es das Protokoll erfordert sondern mit "FE". Gruß Martin
Hallo zusammen, erst einmal vielen Dank für den genialen Bootloader -- bisher oft verwendet und nie ein Problem damit gehabt. Jetzt stehe ich allerdings vor einem Rätsel: - Bootloader auf 10 Attiny25 geflasht, alle Fuses korrekt. - Zwei Programme darüber installiert, das erste funktioniert wunderbar (Taktgeber mit mehreren Frequenzen), lässt sich mehrfach flashen und verifizieren. - Das zweite Programm (Servotester) lässt sich zwar ein mal flashen, danach (bei /P und /V) erkennt fboot (Peters .21-er Version) immer fälschlicherweise den one-wire-Modus. Das Programm kann ich erst morgen testen, da alle verfügbaren Servos noch in der Schule liegen. 1. Frage: Kann man den Modus ausschalten oder könnte jemand das Programm mal kurz ohne die Auto-Erkennung kompilieren? 2. Frage: Kann das jemand nachvollziehen? (Hex s. Anhang, Tiny25, 8MHz intern, Bootloader-Fuse gesetzt) Dankbar für Tipps und Anregungen grüßt Dirk p.s.: Nutze einen Pl2303-basierten USB-Wandler. p.p.s.: Problem existiert bei allen Bitraten 1200, 4800, 9600, 19200, 115200)
Nachtrag: Das Programm funktioniert einwandfrei, aber neu flashen und/oder verifizieren kann ich über den Bootloader nicht mehr. Frage(n): Womit kann ich mir denn FBoot für den Rechner sauber kompilieren, um die one-wire-Funktion testweise rauszuwerfen? Das Ganze wird ja irgendwie über die Variable echocount ermittelt, sehe ich das richtig? Gruß, Dirk p.s.: Die Version Bootloader_CSharp_adv_v3 funktioniert problemlos. Bin aber leider großer Freund der Kommandozeile/Bash :(
Dirk W. wrote: > Nachtrag: Das Programm funktioniert einwandfrei, aber neu flashen > und/oder verifizieren kann ich über den Bootloader nicht mehr. Es wird geprüft, ob das 1. Zeicehn des Paßworts (Peda), also 'P' empfangen wurde. Eventuell mal das P durch ein anderes Zeichen ersetzen, der EXE kann man das neue Paßwort auf der Kommandozeile übergeben. Vielleicht reagiert Deine Applikation so, daß es wie ein Echo erscheint. Welche Pins hast Du denn als RXD und TXD definiert? Wie sind diese Pins in Deiner Applikation belegt? Es sollten Eingänge sein oder nach dem Reset ne Weile inaktiv. Peter
Hallo Dirk, bei mir erkennt er immer fälschlicherweise One-Wire, wenn ich statt einem USB-Adapter den echten COM-Port mit Max232 verwende, Grund: Der Max232 ohne Spannung sendet mir irgendwelchen Müll zurück, solange der Bootloader das PW im Endlessloop sendet. Abhilfe: Versorgung Max232 und µC trennen, µC erst nach Max einschalten, oder Zeit auf 1 sec hochsetzen und direkt nach dem Anklemmen der Spannung das Updateprogramm starten. Ich habe aber auch noch eine Frage an Peter: Ich bin derzeit dabei mir ein Updateprogramm in VB zu schreiben, um längere Dateinamen nutzen zu können, etc. Ich habe die Kommunikation zwischen deinem Kommandozeilenprogramm und dem µC mitgeloggt und versucht genau nachzubilden. Ich kann auch syncen, Buffergröße, Revision etc. abfragen, aber nach dem Senden des ersten Blocks erhalte ich kein A9, woran kann das liegen? Hier mal zwei Links zu meinen Logs: Log zwischen Kommandozeilenprogramm und µC: http://www.modellbau-regler.de/Sitzung.htm Log zwischen VB-Programm und µC: http://www.modellbau-regler.de/Sitzung_eigene.htm Für Tipps wäre ich sehr dankbar, ist nämlich ein Klasse Bootloader :-) Gruß Denis
Hi! Bei deinem eigentlichen Problem kann ich dir leider nicht helfen. Aber die Kommandozeilenversion unterstützt auch ohne Probleme lange Dateinamen und co, eigentlich alles, was das Herz begehrt :-) Im Kommandozeilenfenster einfach die ersten 1-2 Buchstaben eingeben und dann "Tab" drücken. Dadurch wird der Rest automatisch ergänzt. Um mehr Com-Ports ansprechen zu können, für eine Linux Version und für eine Version mit Schreibcache (-> Schnellerer Transfer bei USB-RS232 Wandlern) siehe hier im Thread diverse Patches... Die "älteren" PC Versionen funktionieren auch problemlos mit neuem Bootloader.
Hallo, mein Problem lag scheinbar daran, dass der Computer zu schnell geantwortet hat. Mit einem Sleep() klappt es nun wunderbar. Eine allerletzte Frage habe ich vor Weihnachten dann aber noch :-) Wie berechnet sich die CRC? In der Protokollbeschreibung steht mit dem 16-bit Polynom von A001, aber welche Daten/Zahlen nehme ich dafür als Grundlage? Ich kenne das so, dass man Daten sendet und am Ende die Checksumme. Hier wird ja aber ganz am Anfang eine Checksumme gesendet, dann nach dem Infos holen nochmal und schlussendlich nach dem Überspielen der Daten erneut, darum weiß ich nicht, wie sich diese nun berechnen... Gruß Denis
Hallo zusammen, erstmal ein grosses Lob an Peter! Ich bin gestern auf dieses Projekt gestossen, weil ich eine Flash-write-Routine für die AVRs gesucht hab. Runtergeladen - angepasst - assembliert - programmiert - LÄUFT!!! aber was anderes: Ich bin noch bischen neu bei den AVRs...daher: Wie ermittel ich in C die erste bzw. letzte freie Adresse im Flash? Ich wünsch allen frohe Weihnachten! Harry
Denis wrote: > Ich kenne das so, dass man Daten sendet und am Ende die Checksumme. stimmt. > Hier > wird ja aber ganz am Anfang eine Checksumme gesendet, Der Returnstatus wird aber ignoriert. Das dient nur dazu, die CRC mit 0 zu initialisieren. > dann nach dem > Infos holen damit nicht das alte Programm zerstört wird, wenn hier schon Fehler auftreten > nochmal und schlussendlich nach dem Überspielen der Daten > erneut, Das ist der letzte Test. Peter
Hallo Peter, ein super Bootloader hast du da geschaffen. Nach ein paar Anlaufschwierigkeiten läuft er jetzt perfekt auf einem ATMega644 @8MHz über einen FT232RL. Habe ihn auch direkt in mein Programmers Notepad integriert. Frohes Schaffen noch... ...und fröhliche Weihnachten :)
Hallo! Komme mit dem Bootloader am Atmega48/48P leider nicht zum Laufen. So hab ich das ASM File angepasst: .include "m48def.inc" (hatte auch schon die "m48pdef.inc" verwendet, ohne Erfolg) .equ STX_PORT = PORTB .equ STX = PB5 ;MISO Port .equ SRX_PORT = PORTB .equ SRX = PB4 ;SCK Port Fastload.h ist unverändert, 8Mhz, 333ms Wartezeit Fuses sind am 48er richtig gesetzt, self program enable sowie interner /8 Teiler deaktiviert. Konnte das Programm ohne Fehlermeldung assemblieren, Terminalverbindung wird auch hergestellt. Er überträgt mir jedoch keine Daten, sprich er flasht den Mega nicht. Bleibt permanent im Bootloader, und ich kann jederzeit über den Terminal wieder verbinden ohne Reset. C:\DOKUME~1\fb\Desktop\ROBOT-~1\BOOTLO~1\fboot21\FBOOT>fboot /C1 /b9600/test.hex COM 1 at 9600 Baud: Connected Bootloader V2.1 Target: 1E9205 ATmega48 Buffer: 64 Byte Size available: 3582 Byte CRC: o.k. Elapsed time: 0.27 seconds Flasht nicht :/ Habe einmal ein Programm im Bascom, und einmal mit AVR-Studio+WINGCC getestet. Beide Programme werden nicht geflasht. Ich bin leider etwas ratlos im Moment, vielleicht hat jemand nen Denkanstoß für mich? Danke!
Florian Berger wrote:
> Flasht nicht :/
Weil Du ihm nicht sagst, daß er was flashen soll.
Das ist ein Kommandozeilenprogramm:
fboot -pFILENAME.HEX
Und FILENAME = max 8 Zeichen.
"fboot -?" zeigt die möglichen Optionen.
Peter
Hallo Peter! Ich bin ein Idiot :D Danke! Hätt genauer lesen sollen.
Raimund wrote:
> Hast Du schon mal den ATMEGA644P-20 mit dem Bootloader betrieben?
Gibts denn Probleme?
Ich hab nur den ohne P.
Peter
... habe den gerade erst bekommen. Muss noch ein paar andere Dinge klären und melde mich, wenn ein erste Ergebnis vorliegt!
Angehängte Dateien:
-
Screenshot.jpg
310 KB
Hallo, ich habe mal das PC-Programm in Delphi umgesetzt. Die Bedienung sollte eigentlich selbsterklärend sein, deswegen verzichte ich mal auf eine weiterführende Beschreibung.
Hier noch das Programm inkl. Quelltext und der benötigten ComPort-Lib. Fehlermeldungen, Feedback etc. gerne auch per Mail, die Adresse steht im Quelltext.
Angehängte Dateien:
-
fuse_t13.jpg
160 KB
Hallo, ... wollte einmal fragen, wie die Fuses beim Tiny13 eingestellt werden müssen beim 1-Draht-Betrieb (Programmer aus Bascom + STK200 an LPT1) Danke !
Paulchen wrote: > ... wollte einmal fragen, wie die Fuses beim Tiny13 eingestellt werden > müssen beim 1-Draht-Betrieb (Programmer aus Bascom + STK200 an LPT1) Selfprog Der Rest entsprechend Deiner Taktquelle. Peter
Hallo, im Anhang gibt es eine aktualisierte Version vom UpdateLoader. Änderungen: -Anzeige von .hex-Dateien beschleunigt, Sanduhr-Cursor eingebaut (Danke an R. Willkomm) -Speicherüberlauf beim Einlesen von .hex Datein beseitigt (Danke an R. Willkomm) -Fehler beim Auslesen der Signatur und Puffergrößen behoben (Kommandozeichen wurden einfach ignoriert, allerdings können diese Zeichen auch im Bezeichner der Puffergröße vorkommen, wo sie dann auch ignoriert wurden. Dadurch wurde die Größe falsch berechnet) -Abbrech-Button zum Beenden des Verbindungs-, Programmier- und Verify-Modus eingefügt Eine Bitte hätte ich noch: Selbst nach mehrmaligem Lesen des Original-Programms, komme ich nicht dahinter wie das zu verstehen ist: >Es wird geprüft, ob das 1. Zeichen des Paßworts zurück kommt (Echo). >Protokoll im Eindrahtmodus: >In der PC-Software werden die gesendeten Bytes nach einem Kommando >gezählt. >Erst wenn die gleiche Anzahl Bytes empfangen wurde, werden die >nachfolgenden >Bytes als Antwort gewertet. >Davor werden die Bytes ignoriert (nur gezählt). Werden im 1-Draht Modus sämtliche Daten wieder zurück gesendet und das Programm soll dann zählen, ob wirklich alles wieder zurück kommt? Bis jetzt ignoriere ich diesen Modus in meinem Programm weitestgehend, habe es aber auch noch nicht geschafft einen lauffähigen 1-Wire-Test-Bootloader zu installieren um mir das näher anzusehen. Vielen Dank & Gruß vom Abwasch-König ;-)
Leo-andres Hofmann wrote: > Werden im 1-Draht Modus sämtliche Daten wieder zurück gesendet und das > Programm soll dann zählen, ob wirklich alles wieder zurück kommt? > Bis jetzt ignoriere ich diesen Modus in meinem Programm weitestgehend, > habe es aber auch noch nicht geschafft einen lauffähigen > 1-Wire-Test-Bootloader zu installieren um mir das näher anzusehen. Im one-wire mode werden die gesendeten Daten wieder empfangen, da ja Sende- und Empfangsleitung miteinander verbunden sind. Es wird geprüft, ob das erste Zeichen des Passwortes zurückkommt: ist dies der Fall, dann geht die PC-Software davon aus, daß der one-wire mode verwendet wird. Im one-wire mode werden die gesendeten Bytes gezählt, der Zähler wird beim empfangen erniedrigt; damit wird erkannt, wann das Echo der gesendeten Bytes zu Ende ist und Daten vom Controller kommen. D.h. es wird nicht gezählt um festzustellen, ob wirklich alles zurückkommt, sondern um das Ende des Echos festzustellen.. Ein Trick von Peter für den one-wire mode ist noch, daß der PC am der Sequenz zur Baudratenerkennung (und gleichzeitig Passwort, default: "peda") ein 0xff sendet. Damit wird an den Controller nur ein Startbit gesendet, in das der Controller seine Antwort (0xA0 glaube ich) hineinsendet, d.h. der PC sendet 0xff aber auf der Leitung (und damit auch wieder im Receiver des PC) erscheint das 0xA0... Gruß, Bernhard
@Leo-andres Hofmann Hi, erstmal fettes lob :) Hab hier noch ein paar bugs und vorschläge: - wenn bereits ein anderes prog die schnittstelle benutzt, dann zeigt der loader zwar ne fehlermeldung, haengt sich dann aber komplett auf und kann nur gewaltsam beendet werden. - eine option um die hinweise(update wirklich durchfuehren..., schalten sie das geraet ...) zu deaktivieren. weil ich benutze den uploader hauptsaechlich fuer prototypen flash dann mal schnell hintereinander was drauf und da stoeren die meldungen. koennte ja auch ueber ein ini eintrag geloest werden. - bei mir funktionniert die wahl der baudrate nicht?! auch im geraetemanager sind 57600 eingestellt, brauch aber fuers programmieren von 4kb ca 5min mit dem c# loader der hier im thread angeboten wird warens nur wenige sekunden (der hat aber nen anderen bug). und original fboot laeuft net unter 64bit :( gruss Sascha
Hallo zusammen, bitte habt Verständnis dafür, dass ich nicht den gesamten Thread gelesen habe. Ich beschäftige mich gerade zum ersten mal mit dem Thema Bootloader und bin auf Peters Bootloader gestossen. In [[AVR Bootloader FastBoot von Peter Dannegger]] steht, dass dieser nur COM1-4 unterstützt. Ist das noch der aktuelle Stand? Gibt es eine GUI-Alternative zu Peters "fboot"? Vielleicht sogar was im Quelltext, was man in eigene Applikationen integrieren kann? Danke und Gruß Dominique Görsch
@ Dominique such hier im thread nach Bootloader_release_adv_v4.zip oder UpdateLoader_2.1.9.zip (3 threads weiter oben ;) ) Sascha
Dominique Görsch wrote: > bitte habt Verständnis dafür, dass ich nicht den gesamten Thread gelesen such doch nach dateianhängen, wenn du dateien suchst... außerdem gibts noch AVR Bootloader FastBoot von Peter Dannegger
Michael H* wrote:
> außerdem gibts noch AVR Bootloader FastBoot von Peter Dannegger
Genau auf den Artikel hab ich mich doch bezogen ;)
@Sascha & Rainer: Ich schmeiß nur mal schnell eine Vermutung in den Raum, weil ich nicht viel Zeit habe. Vielleicht hilft dir das weiter, oder du könntest das mal nachprüfen. Ich verwende die Komponente ComPort 4 (Beta), gibt es bei Sourceforge. http://sourceforge.net/projects/comport/ Diese Komponente triggert ein Event, wenn der Sendepuffer leer ist. Nach jedem Byte wartet das Programm, bis dieses Event ausgelöst wurde, oder geht nach einem Timeout in eine Fehlermeldung. Allerdings hat die Komponente auch eigene Timeouts integriert. Ich konnte leider noch nicht nachvollziehen, wie das zusammen arbeitet. Meine Vermutung ist daher, dass der RS232-Adapter entweder garkein Event auslöst oder nur sehr verzögert und daher die Wartezeiten zustande kommen. Diese Situation konnte ich leider noch nicht nachvollziehen. Bei mir läuft das Programm fehlerfrei mit einem 5€-Logilink-Adapter. Programmieren + Verify von 20kb dauert grade mal 1:40 Minuten. Könntest du mir vielleicht sagen, welchen Adapter du verwendest? One- oder Two-Wire Modus wäre auch noch interessant, ersterer ist nicht bzw. fehlerhaft umgesetzt. Die Feature-Wünsche werde ich in einer kommenden Version noch umsetzen, besten Dank für die Anregungen. Habe per Mail auch noch ein paar Ideen bekommen, davon werde ich in jedem Fall noch etwas umsetzen. Grüße Leo-Andres Hofmann
@Leo-Andres Die Zeit von 60 ms/Zeichen wird in der SendChar-Routine verbraucht, d.h. gemessen von Rückkehr aus ComPort.WriteStr bis zum Aufruf von CalculateCRC. WriteStr beinhaltet eigentlich ja schon ein Timeout, d.h. die eigene Timeout-Routine wird nur gebraucht, wenn man auf eine Antwort vom Bootloader wartet. Hilft das? Gruß Rainer
Servus, habe mal ein Proof-of Concept Buffer eingebaut und einige Dinge geändert: @Leo-Andres schau es Dir doch mal an... 1. Flashen Mega8 in ca. 2s. (mit FDTI-Wandler) 2. Verify mit Puffer habe ich noch nicht angepasst... d.h. man sollte das Verify abschalten wenn es schnell gehen soll 3. Hex Datei wird automatisch vor dem nächsten Brennen neu von der Festplatte gelesen... 4. Unterstützte Bootloader Version zum Auswählen (einige Megas hatten noch die Firmware Version 1.9) 5. Dialog insgesamt verkleinert (es gibt noch Menschen die mit 1024x768 auf Bastelrechern arbeiten) 6. Hex Anzeige auf 2.Karteireiter verbannt 7. Stayontop ausgeschaltet; es war so nervig, da man auch noch andere Anwendungen unter Windows laufen lässt, die unmittelbar nach dem Flashvorgang bedient werden müssen 8. Comport öffnen Fehler beseitigt, falls dieser belegt ist.... Ihr könnt ja mal testen. Hatte jetzt nur ein Mega8 da. Gruß Sven
Hallo, ich bin auf der Suche nach einem Bootloader für den atmega128. ICh habe grad den Bootloader von AvrFreaks geladen und wollte ihn ausprobieren. In der BOOTLOAD.ASM kann der Bootloader ja für den entspechenden AVR angepasst werden. Wo bekomme ich aber die dafür vorgesehene m128def.inc her? Wo kann man diese Datei laden bzw. kann sie mir jemand bitte schicken? Vielen Dank für Eure Hilfe Jörg
Hallo Jörg, die Files mit den Devicedefinitionen sollten bei der Installation von AVR Studio in C:\Programme\Atmel\AVR Tools\AvrAssembler1\Appnotes bzw. in C:\Programme\Atmel\AVR Tools\AvrAssembler2\Appnotes abgelegt worden sein. Gruß Rainer
Hallo PeDa, ich muß dir ein sehr,sehr großes Lob für den Bootloader aussprechen....einfach genial. Hab mal den ganzen Beitrag durchgelesen und danach gleichmal ausprobiert... Alles wunerbar.................so Dann hät ich da mal noch neh frage.... Gibt es für das Fboot auch schon ein Windowsprogramm ??? super weiter so. Gruß mdiri
Hallo, Sorry, hab doch nicht alles gelesen.....es gibt ja ein Windows Programm von Sven. Dirk
@Leo-A. Hofmann ich verwende keinen Adapter sondern die serielle Schnittstelle meines PCs. Bootloader im twowire. Bisher hatte ich immer den "Bootloader_release_adv_v4" genutzt. Der hat aber auch noch nen doofen Bug. Die UpdateLoader Version von Sven K. ist zwar schnell, dafuer tuts nacher aber net^^ Sascha
hab Fboot17-Dev-Cpp.zip von Bingo genommen mit fboot21 kombiniert und nen bug entfernt. Ist jetzt halt 20mal so gross wie die Orginal, aber dafür tuts endlich unter 64Bit. Jippi
Nur einer info Ich habe einer neues Linux / MAC-OSX implementierung von die PC-loader sehen hier. http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_type=project&item_id=1927 mfg Bingo
Hallo, ich versuche mich gerade mit dem Atmega32 und dem Bootloader aus dem Verzeichnis fboot21.zip. Nun dies ist mein erster Versuch mit einem Bootloader und leider ist er auch gleich gescheitert. Mein Vorgehen: 1. zip Datei entpackt 2. PDF Datei von Peter Dannegger gelesen 3. Aus meinem AVR-Verzeichnis die avrasm32.exe und die m32def.inc in das Bootloader Verzeichnis kopiert 4.Bootload.asm verändert: 4.1 Semikolon vor m32def.inc entfernt. 4.2 Pins deklariert(waren die gleichen Pins da ich den Hardware UART nutze) 5.CMD geöffnet (vorsichtshalber über eine .bat um die Fehler mitzuschreiben(avrasm32.exe -fI BOOTLOAD.asm > avrasm.txt)) Und leider waren in dieser Textdatei doch eine ganze Menge Fehler
1 | Creating 'BOOTLOAD.hex' |
2 | |
3 | Assembling 'BOOTLOAD.asm' |
4 | Including 'm32def.inc' |
5 | Including 'fastload.inc' |
6 | Including 'fastload.h' |
7 | Including 'compat.h' |
8 | Including 'protocol.h' |
9 | Including 'watchdog.inc' |
10 | Including 'abaud.inc' |
11 | Including 'password.inc' |
12 | Including 'command.inc' |
13 | Including 'message.inc' |
14 | Including 'verify.inc' |
15 | Including 'progtiny.inc' |
16 | Including 'uart.inc' |
17 | |
18 | boatload.asm(52):warning: A .db segment with an odd numberof bytes is detected. A zero Byte is added. |
19 | protocol.h(1) : error : Syntax error |
20 | protocol.h(2) : error : Syntax error |
21 | protocol.h(3) : error : Syntax error |
22 | protocol.h(16) : error : Syntax error |
23 | protocol.h(17) : error : Syntax error |
24 | protocol.h(18) : error : Syntax error |
25 | protocol.h(25) : error : Syntax error |
26 | fastload.h(82) : error : Symbol is already already defined by the .equ directive |
27 | fastload.h(112) : error : undefined variable referenced |
28 | fastload.inc(36) : error : undefined variable referenced |
29 | command.inc(14) : error : undefined variable referenced |
30 | command.inc(37) : error : undefined variable referenced |
31 | command.inc(53) : error : undefined variable referenced |
32 | message.inc(20) : error : undefined variable referenced |
33 | verify.inc(25) : error : undefined variable referenced |
34 | progtiny.inc(15) : error : undefined variable referenced |
35 | progtiny.inc(55) : error : illegal argument type of count |
36 | progtiny.inc(56) : error : illegal argument type of count |
37 | progtiny.inc(85) : error : undefined variable referenced |
38 | uart.inc(45) : error : undefined variable referenced |
39 | fastload.inc(52) : error : operand expected |
40 | fastload.inc(53) : error : Syntax error |
41 | fastload.inc(54) : error : Syntax error |
42 | fastload.inc(55) : error : Syntax error |
43 | fastload.inc(56) : error : Syntax error |
44 | Assembly complete with 25 errors |
45 | |
46 | Deleting 'BOOTLOAD.hex' |
Ich kann mir nur vorstellen das ich etwas vergessen habe, da diese Version hier im Forum mit einem Atmega32 schon erfolgreich getestet worden ist. Über Hilfe würde ich mich sehr freuen.
Patrick Ries wrote: > 3. Aus meinem AVR-Verzeichnis die avrasm32.exe und die m32def.inc in das > Bootloader Verzeichnis kopiert Das ist der alte, Du mußt avrasm2 nehmen. Das Include nicht kopieren, das findet er selber (das alte löschen). Peter
Hmm... das finde ich merkwürdig, habe AVR-Studio ganz frisch runter geladen(vor zwei Tagen).....und da ist auch nur diese .exe drin......
Peter Dannegger wrote: > Patrick Ries wrote: >> 3. Aus meinem AVR-Verzeichnis die avrasm32.exe und die m32def.inc in das >> Bootloader Verzeichnis kopiert > > Das ist der alte, Du mußt avrasm2 nehmen. > Das Include nicht kopieren, das findet er selber (das alte löschen). > > > Peter JAJA wie sagt man so schön:"Augen auf beim Eierkauf". Ich danke dir Peter, funktioniert jetzt bestens.....
1 | AVRASM: AVR macro assembler 2.1.30 (build 592 Nov 7 2008 12:38:17) |
2 | Copyright (C) 1995-2008 ATMEL Corporation |
3 | |
4 | BOOTLOAD.asm(32): Including file 'C:\Program Files\Atmel\AVR Tools\AvrAssembler2\Appnotes\m32def.inc' |
5 | BOOTLOAD.asm(64): Including file 'fastload.inc' |
6 | fastload.inc(8): Including file 'fastload.h' |
7 | fastload.h(2): Including file 'compat.h' |
8 | fastload.h(3): Including file 'protocol.h' |
9 | fastload.inc(23): Including file 'watchdog.inc' |
10 | fastload.inc(32): Including file 'abaud.inc' |
11 | fastload.inc(33): Including file 'password.inc' |
12 | fastload.inc(45): Including file 'command.inc' |
13 | command.inc(68): Including file 'message.inc' |
14 | command.inc(71): Including file 'verify.inc' |
15 | command.inc(75): Including file 'progmega.inc' |
16 | fastload.inc(46): Including file 'uart.inc' |
17 | fastload.inc(59): Including file 'apicall.inc' |
18 | |
19 | ATmega32 memory use summary [bytes]: |
20 | Segment Begin End Code Data Used Size Use% |
21 | --------------------------------------------------------------- |
22 | [.cseg] 0x007e00 0x008000 472 20 492 32768 1.5% |
23 | [.dseg] 0x000060 0x000760 0 1792 1792 2048 87.5% |
24 | [.eseg] 0x000000 0x000000 0 0 0 1024 0.0% |
25 | |
26 | Assembly complete, 0 errors. 0 warnings |
Nachher, wenn ich zuhause bin, werde ich es gleich mal ausprobieren.
Hi, habe versuch den bootloader zu benutzen leider funtzt da bei mir was nicht, ich habe einen Atmega 644 auf einem Polim board mit 16 MHz. Gibt es da irgendwo eine schritt für schritt anleitung wie man das benutzt? have bis jetzt das file assembliert und von 8 auf 16 MHz im code geändert, leider hat das nicht geholfen, hier: http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger sheht man soll 256 Worte für den bootloadre in den fuses einstellen, aber laut http://www.engbedded.com/fusecalc/ ist das kleinste bei dem 644 sind 512 worte. PS: zum progen benutze ich pony prog Danke schon mal im vorras Trax
Hi, ich habe auch ein Problem mit dem Bootloader von Peter Ich hatte ihn schon eine ganze Weile erfolgreich mit dem ATmega162 und anderen benutzt. Jetzt wollte ich ihn wieder anpassen für den ATmega325...wieder ganz normal die Ports geändert, die Taktfrequenz ist gleich geblieben, und dann per ISP übertragen. Leider antwortet der Bootloader nicht auf die Signale der fboot.exe. Die Hardware funktioniert: in eigenen Programmen kann ich per RS232 Daten zum PC übertragen. Mit dem Oszi kann ich auch das Signal vom fboot abfangen wie es zum ATmega geht. Fuses sollten alle ordentlich gesetzt sein. Hat jemand Ahnung warum es nicht funktionieren könnte? ich musste ja die M325def.inc per Hand zur Bootload.h hinzufügen. Kann es sein, dass der Bootloader den Chip nicht unterstützt? Hab die Bootloader Versionen 1.7, 2.0 und 2.1 durchprobiert Vielen Dank für die Hilfe Rocken
Rocken wrote: > und dann per ISP übertragen. Leider antwortet der > Bootloader nicht auf die Signale der fboot.exe. Welchen Takt hast Du eingestellt? Probier mal ne kleinere Baudrate. Stimmen die UART-Pins? Das Assemblerlisting für den M325 sieht o.k. aus, aber ich hab keinen Chip zum Testen. Peter
Ich habe XTAL auf 11059200 Hz gesetzt (entsprechend dem externen Quarz) Baudraten habe ich schon sämtliche durchprobiert. (mit 19200baud hatte ich sonst immer gute Ergebnisse) Die UART Pins stimmen (PE0, PE1); ich hab mir ein echo-Programm geschrieben, dass die UART konfiguriert und mir ein gesendetes Char vom Rechner zurückschickt..und es funktioniert. Hab jetzt den Bootloader von Hagen probiert (AVR-Bootloader v1.0) auch dieser bekommt meinen ATmega nicht zum sprechen. Es sollte also nicht direkt am Bootloader liegen. Hab auch bei Hagens Bootloader mal die Baudraten-Detektion ausgeschaltet und auf einen festen Wert gesetzt..nix. Der Rechner schickt wie wild Signale die einfach nicht bearbeitet werden. Vllt. doch irgendwelche Fuses falsch..obwohl, ich hab zig mal drüber geguckt. Danke für schnelle Reaktion Peter Rocken
Hallo Peter, bei mir funktioniert der Bootloader mit einem ATmega128 einwandfrei (Version 2.1). Aber stimmt die Information noch, dass das Schreiben oberhalb von 64KB bis auf weiteres nicht funktioniert? (Und er vermutlich auch davon noch fälschlicherweise die Größe der Bootloadersektion abziehen wird?). Ich habe übrigens mal die Wiki Seite an die aktuelle Version angepasst.
Malte __ wrote: > Hallo Peter, > bei mir funktioniert der Bootloader mit einem ATmega128 einwandfrei > (Version 2.1). Aber stimmt die Information noch, dass das Schreiben > oberhalb von 64KB bis auf weiteres nicht funktioniert? Nein, die Version 2.1. kann das. Ich hab ihn bis zum ATmega2561 erweitert und getestet (256kB). Peter
Ist der Wiki Artikel noch aktuell? Ich nehme an dass mam jetzt statt m32.asm nur BOOTLOAD.asm asemblieren muss. Hab extra unter Windows AVR Studio installiert, aber irgendwie kommen bei mir 500 Errors ala "Invalid redefinition of <blabla>". Kennt jemand eine Lösung oder kann jemand die feritige HEX-Datei für einen 16NHz ATmega32 auf PortD hochladen? mfg
Manuel wrote: > Ist der Wiki Artikel noch aktuell? Ja, ich hatte ihn gerade auf den aktuellen Stand gebracht. > Ich nehme an dass mam jetzt statt m32.asm nur BOOTLOAD.asm asemblieren > muss. Ja, und vorher in dieser die richtige include auswählen und die betreffende Datei einfach in das gleiche Verzeichniss kopieren. > Hab extra unter Windows AVR Studio installiert, aber irgendwie kommen > bei mir 500 Errors ala "Invalid redefinition of <blabla>". Poste doch mal den genauen Assemberaufruf und die Ausgabe.
Ich konnte das Problem mit meinem nicht funktionierenden Bootloader etwas eingrenzen: Ich kann den Bootloader zwar per ISP/JTAG überspielen...er antwortet aber nie auf einkommende Signale über die RS232. Wenn ich jedoch den Bootloader im Debugmodus (Dragon Board über JTAG) durchlaufen lasse funktiert er und kann einwandfrei kommunizieren und Programme übertragen. Ich kann sogar während des Debugbetriebes den JTAG-Adapter abziehen und habe danach einen funktionierenden Bootloader. Wie ist das zu erklären? Ich kann ja nicht immer erst in den Debugmodus und dann, eigentlich unzulässiger Weise, den Adapter abziehen um mein Bootloader zu bekommen. Kennt jemand ds Problem und kann mir ggf. helfen? Rocken
Wo kannman den die version neuen versionen laden hier ist ja nur die alten 1.7 velinked :/
Angehängte Dateien:
-
Unbenannt3.JPG
23 KB
So,habe nun die ältere Version des Bootloaders draufgeflashed. (die neuere bekomme ich einfach nicht assembliert...), und laut dem angehängten Bild scheint die Übertragung ja zu funktionieren. Mein Problem ist aber, dass die Anwendung danach einfach nicht startet. Meine fusebits für einen 16 MHz ATmega32 lauten: hfuse: 8E lfuse: FF (Calc siehe http://www.engbedded.com/cgi-bin/fc.cgi ) Liegt mein Fehler an den Fuses, oder kann jemand sonst irgendwie helfen? Grüße Patrick
Trax Xavier wrote: > Wo kannman den die version neuen versionen laden hier ist ja nur die > alten 1.7 velinked :/ Einfach nach "fboot21" suchen. Oder Link aus dem Wiki Artikel nehmen.
Kann mir denn keiner helfen? Ich muss morgen das STK500 wieder zurückgeben, und da wäre es schön bis dahin meine ATmegas mit dem Bootloader geflashed zu haben. Ich würde mich über ein fertiges Intel-HEX-File für den ATmega32 @16Mhz @ PD0,PD1 oder auch über jegliche Hilfe sehr freuen. Ebenso über die richtigen hfuse und lfuse Werte, dies würde mir die Verwendung von avrdude sehr erleichtern. Meine Ersten Versuche habe ich bereits hier gepostet: Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" Ich wäre sehr dankbar dafür wenn mir hierbei jemand helfen kann. Vielen Dank! Patrick
Patrick wrote: > Kann mir denn keiner helfen? Ich muss morgen das STK500 wieder > zurückgeben, und da wäre es schön bis dahin meine ATmegas mit dem > Bootloader geflashed zu haben. Dann poste doch mal die komplette Fehlerausgabe mit dem genauem Assembleraufruf. Programmieren lässt sich ein AVR auch ohne STK mit einem LPT Adapter auf einem Steckbrett.
So, assemblieren hat nun geklappt. Fehler lag darin, dass ich zwar mega32def.inc einkommentiert, aber mega16?def.inc nicht auskommentiert habe. siehe: http://s1.image.gd/o/fe/fe514023f91afa9c5af99569ec104de9625fd697.jpg Doch nun bekomme ich beim Übertragen keine Verbindung (auch Reset wurde versucht). siehe: http://s1.image.gd/o/eb/ebd404ec046e5ebfc5fe18538f3a8c8761a89f3d.jpg Fusebits sind folgendermaßen gesetzt: http://s1.image.gd/o/c6/c6d155783739bfddd0f5759ce3f1265df0bd08c7.jpg MfG Patrick
Patrick wrote: > So, assemblieren hat nun geklappt. Fehler lag darin, dass ich zwar > mega32def.inc einkommentiert, aber mega16?def.inc nicht auskommentiert > habe. Na also :-) > Doch nun bekomme ich beim Übertragen keine Verbindung (auch Reset wurde > versucht). > siehe: > http://s1.image.gd/o/eb/ebd404ec046e5ebfc5fe18538f3a8c8761a89f3d.jpg Ich hatte manchmal das Problem, dass nur höhere Geschwindigkeiten richtig funktionierten (19200 baud). Außerdem brauchte ich manchmal folgene Reihnfolge: 1. AVR Power off 2. PC Programm starten, 3. AVR Power on. Außerdem machten manche USB->RS232 Konverter bei mir Probleme. > Fusebits sind folgendermaßen gesetzt: > http://s1.image.gd/o/c6/c6d155783739bfddd0f5759ce3f1265df0bd08c7.jpg Keine Ahnung, ob BOOTRST richitg ist, ist ja mit dem 0/1 programmed/unprogrammed immer etwas verwirrend.
Mit der Alten Version 1.4 funktioniert der Bootloader bei mir bereits, nur mit der neuen Version 2.1 konnte ich diesen Effekt noch nicht erzielen. Fuses sollten also ok sein. Schon mal vielen Dank an Malte für deine Hilfe. Ob ich jetzt die Version 1.4 oder 2.1 verwende wird für mich wohl kaum einen Unterschied machen, also bin ich damit schon glücklich, danke. MfG Patrick
weiß jemand, wie man die fboot.exe in DOSBOX unter Linux verwendet, wenn die Schnittstelle /dev/ttyUSB0 lautet? Und lässt sich das irgendwie vereinfachen, dass man nicht zuerst DOSBOX und dann das programm in DOSBOX starten muss, dort natürlich eine Partition mounten usw... am besten wäre ein befehl ala "dosboxxyz -<befehl, der in dosbox ausgeführt wird>", so dass ich es dann ggf. auch in ein Makefile einfügen kann. MfG Patrick
Hier ist doch irgendwo ne Linuxversion von dem Code gepostet, warum nicht die benutzen?
Ich habs mit Linux_Fast14 aus Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" versucht, aber das Programm kann nach dem Flashen leider nicht gestartet werden... Ansonsten sieht es so aus als wäre der Flashvorgang erfolgreich gewesen.
1 | patrick@patrick-laptop:~/Desktop/Linux_Fast14$ ./fboot /? |
2 | |
3 | /? Get this help message |
4 | /Bnnnn Define baud rate |
5 | /Ddevice Define serial port |
6 | /PFname,Ename Perform Program |
7 | /VFname,Ename Perform Verify |
8 | |
9 | |
10 | patrick@patrick-laptop:~/Desktop/Linux_Fast14$ ./fboot /D/dev/ttyUSB0 /Pblink1.hex |
11 | /dev/ttyUSB0 at 115200 Baud: / |
12 | Connected |
13 | readval: |
14 | a8 val 0 j 257 |
15 | 03 val 0 j 256 |
16 | 01 val 0 j 3 |
17 | 04 val 1 j 2 |
18 | aa val 260 j 1 |
19 | Bootloader V1.4 |
20 | readval: |
21 | a8 val 0 j 257 |
22 | 04 val 0 j 256 |
23 | 1e val 0 j 4 |
24 | 95 val 30 j 3 |
25 | 02 val 7829 j 2 |
26 | aa val 2004226 j 1 |
27 | Target: 1E9502 ATmega32 |
28 | readval: |
29 | a8 val 0 j 257 |
30 | 03 val 0 j 256 |
31 | 07 val 0 j 3 |
32 | 00 val 7 j 2 |
33 | aa val 1792 j 1 |
34 | Buffer: 1792 Byte |
35 | readval: |
36 | a8 val 0 j 257 |
37 | 04 val 0 j 256 |
38 | 00 val 0 j 4 |
39 | 7e val 0 j 3 |
40 | 00 val 126 j 2 |
41 | aa val 32256 j 1 |
42 | Size available: 32256 Byte |
43 | reading file... Done. |
44 | Program blink1.hex: 0000 - 00B9 successful |
45 | CRC: o.k. |
46 | Elapsed time: 0.15 seconds |
47 | patrick@patrick-laptop:~/Desktop/Linux_Fast14$ |
daher dachte ich mir mit DOSBOX könnte man es ja noch versuchen, wenns im Wiki schon steht. MfG Patrick
Patrick wrote: > weiß jemand, wie man die fboot.exe in DOSBOX unter Linux verwendet Linuxversion: http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1927&item_type=project Kann aber wohl kein 1-draht Modus. Peter
Hallo ALLE zUSAMMEN; Also irgendwie glaube ich geht die Übersicht völlig verloren. Welcher Update Loader geht nun 64bit 32bit mit gui ohne gui oder Linux 32 /64 bit Welcher Bootloader ist der aktuell Könnte mann nicht hier eine WIKI machen wo man das alles zusammenfasst und immer die Aktuellen Versione reinstellt. Also es gibt BootloaderFlashTool für GUI: Windows 32 bit Beitrag "UART Bootloader ATtiny13 - ATmega644" CMD: Windows 64/32BIT Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" LINUX: http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1927&item_type=project Bootloader selbst??? Beitrag "UART Bootloader ATtiny13 - ATmega644" Gruß Gerd
Wer sich nicht extra anmelden möchte bei AVRFreaks: Ich habe soeben die Linuxsoftware hier im Thread vom 3.12.2008 erfolgreich ausprobiert. Dabei kann ich die txblocksize nur auf max. 43 stellen, ansonsten treten Übertragungsfehler auf (Grund ist mir egal, Mega88 @ 230400 @ 0,77 Sekunden reicht mir).
Hier ist einer kleine script line für avrasm2.exe unter linux (wine) Kopiere die avrassembler dateis von einer windows pc mit avrstudio instaliert. wine ~/avr/AvrAssembler2/avrasm2.exe -I ~/avr/AvrAssembler2/Appnotes $1 mfg Bingo
Nur eine kurze Rückmeldung. Läuft problemlos auf Atmega8, 1Wire Modus an PB0, AVR Studio 4.16. Respekt und ein Dankeschön an Peter Dannegger.
Hallo zusammen, ich habe soeben das erste mal den Bootloader getestet. Bootloader V2.1 UpdateLoader v 2.1.9.106 Muss dazu sagen, ich habe absolut keine Erfahrung mit Assembler. Ich bin wie folgt vorgegangen: - neues ASM-Projekt in AVR-Studio angelegt - Dateien aus dem Archiv darein gezogen - .inc für meinen AVR (mega16) dazu kopiert - mit avrasm2 -fI Bootload.asm übersetzt - mit avrdude in den AVR geflasht. - die Fuse entsprechend gesetzt Wenn ich nun mit dem Updater ein Hex-File in den AVR schreiben will, passiert folgendes: ,--- | Verbunden: 2-Draht-Modus | CRC-Check: aktiviert | Bootloader-Version: 2.1 | Baustein: ATmega16 | Buffergröße: 512 Byte | Flash: 15872 Byte | CRC-Prüfsumme OK | Programmiere 3917 von 15872 Bytes Flash | Gesamtdauer: 00:01:04 `--- Im unteren Fenster steht: ,--- | Programmdatei "C:\Dokumente und Einstellungen\Administrator\Deskto | \Mixercontrol\Firmware\R2_001.HEX" geladen | Kommando "$6" fehlgeschlagen | Programmiere 3917 von 15872 Bytes Flash | Baustein reagiert nicht `--- Was mache ich falsch? Gruß Dominique Görsch PS: Der AVR ist über einen FT232RL über USB mit dem PC verbunden.
Dominique Görsch wrote: > UpdateLoader v 2.1.9.106 Ist das ein Linuxprogramm? > | Baustein reagiert nicht Bei Verbindungsproblemen mal ne andere Baudrate probieren. Peter
Hallo Peter, nein, dass ist ein Windowsprogramm hier aus dem Thread. Mehrere Baudraten habe ich schon durchprobiert. Woran könnte es sonst noch liegen? Die Schaltung an sich funktioniert, flashe ich über ISP meine eigentlich Firmware läuft alles wie es soll. Gruß Dominique Görsch
Hmm... habe nun den Bootleader erneut assembliert und geflashed und danach mal mit dem original fboot.exe getestet, das klappte problemlos. Danke, tolles Ding ;)
Hi, warum benötige ich beim Tiny2313 kein RJMP zum Bootloader???? bin grad total verwirrt?!
Angehängte Dateien:
-
Flash.jpg
270 KB
Hi, ich habe gerade das gleiche Problem, wie schon ein paar andere. Ich versuche nun schon seit ein paar Tagen die Version 2.1 mit einem Atmega8 zu verwenden. Kompeliert und geflasht bekomme ich es. Nur reagiert der µC dann nicht mehr auf die fboot.exe. Egal welche Baudrate ich verwende. Die Kabel sind auch richtig, einen Max benutze ich auch. Fuses habe ich wie folgt eingestellt: lfuse:0xbf hfuse:0xdc Benutze einen externen 8MHZ Keramik Resonator / Filter Habe das ganze schon am Rechner mit echter RS232, sowie am Notebook mit RS232-USB ausprobiert. Beides gleicher Effekt. Habe euch noch ein Bild mit dem ausgelesenem Flash Teil in PonyProg angehängt. Habe echt keine Ahnung mehr, wo's noch drann hängen kann. Ein Oszi hab ich leider nicht.
Eigentlich müsste sich im HEX File, wenn es richtig ist, der String "Peda" (das Passwort) finden lassen, finde ich aber nicht... also könnte das angehängte HEX falsch sein...
Moin, @Bernhard M. das Passwort "Peda" steht an Stelle 1FBE. Aber trotzdem schon mal danke, dass du es dir angeguckt hast. Ich habe in den Dateien auch nichts geändert. Für den ATmega8L @ 8Mhz passt das doch alles schon, oder hab ich da doch noch etwas übersehen? Sind die Fuses denn in Ordnung?
Ich habe COM2. wenn ich die EXE starte , wird geschrieben COM1 ist nicht da. Wie kann ich die EXE auf Com2 umstellen?
Schau doch einfach mal in die Hilfe... ,--- | C:\FBOOT>fboot /? | /? Get this help message | /Bnnnn Define baud rate | /Cn Define serial port n = 1..4 | /Pname Perform Program | /Vname Perform Verify | /Istring Init string `--- War das nu so schwer?
Hallo,
ich versuche gerade eine Java Software zu schreiben die den Bootloader
benutzt. Leider scheitere ich schon beim ersten check_crc().
Nachdem der Connect zustandegekommen ist wird geprüft ob der Bootloader
crc unterstützt. Vor diesem ersten Aufruf von check_crc() ist die
Variable crc=0.
Dann schicke ich das cmd CHECK_CRC an den Bootloader und bekomme SUCCESS
zurück. Jetzt sende ich den ersten CRC Wert an den BootLoader. Dieser
ist 53FB also FB und dann 53. Daraufhin bekomme ich FAIL zurück.
Ich weiss einfach nicht mehr wo ich noch suchen könnte.
Anbei der relevante Code:
private CRC_STATUS check_crc() throws IOException, InterruptedException,
NoAnswerException {
int i;
sendcommand(BL_CHECK_CRC);
Thread.sleep(50);
if (isAnswerArrived) {
if (answer[0] == BL_BADCOMMAND) {
return CRC_STATUS.NO_CRC;
}
}
int tmpCrc = crc;
System.out.println(Integer.toHexString(tmpCrc));
send(tmpCrc & 0xff);
send(tmpCrc >> 8);
waitForAnswer();
i = answer[0];
switch (i) {
case BL_SUCCESS:
return CRC_STATUS.CRC_OK;
default:
return CRC_STATUS.CRC_FAIL;
}
}
private void get_crc(int d) {
int tmpCrc = crc ^ d;
for (int i = 0; i<8; i++) {
if ((tmpCrc & 0x1) != 0) {
tmpCrc = (tmpCrc >> 1) ^ 0xA001;
} else {
tmpCrc = tmpCrc >> 1;
}
}
crc = tmpCrc & 0xffff;
}
private void send(int c) throws IOException {
isAnswerArrived = false;
out.write((char) c);
get_crc(c); // calculate transmit CRC
}
private void sendcommand(int cmd) throws IOException {
send(BL_COMMAND);
send(cmd);
}
Hallo zusammen, wäre es nicht mal an der zeit, dem Bootloader in AVRDude zu integrieren? Hielte ich zumindest in Verbindung mit Eclipse für extrem praktisch. Gruss Harry
Ach ja...eins wollte ich noch loswerden: Ich verwende diesen genialen Bootloader bereits seit einigen Monaten, auch, wenn ich mich hier selten zu Wort melde.. Mein Dank gilt allen, die das möglich gemacht haben! Gruss Harry
Hallo,
ja als erstes "Vielen Dank an Peter Dannegger" für den Bootloader und
allen andern die das hier möglich gemacht haben!
Habe FBOOT um wenige Zeilen (Programm Zeilen) erweitert.
Neu ist :
- Portiert auf C++Builder 2007 Kommando-Zeile (sollte aber auch mit
DevCpp laufen).
- Für Win32 XP und auch Vista.
- 1Wire laeuft nun auch unter windows XP / Vista;
- Mit USB auf RS232 Adapter(nicht TTL) und dann "PEDA 1Wire
Interface".
- Getestet mit Prolific USB auf RS232 Adapter (Quelle Glyn) wurde von
Vista sofort ohne Treiber Inst. erkannt.
- Vista mit RS232 konnte ich nicht testen da mein Laptop nur USB hat;
So und nun zu den Baudraten Max. bei mir :
- PC mit XP mit on Board RS232 (com1) weitere gibt es NICHT -> 57600
Baud.
- Gleicher PC mit PCI Multi-RS232-Card 8x -> 38400 Baud.
- Laptop mit USB auf RS232 Adapter(nicht TTL) und dann "PEDA 1Wire
Interface"-> 115200 Baud " ein Wunder !" NEIN , trotzdem ist die
UPLOAD-ZEIT 3 mal so lang statt 2 Sek. > 6 Sek ist halt USB mit
Vista.
Vielleicht hat mal einer die Zeit ein Interface von TTL auf 1Wire zu
basteln.
Gruss Alfred
Hab den Dateianhang nicht ........ Aber und so .... Gruss Alfred
Hallöchen Ich wollte nun auch mal den Bootloader ausprobieren, und bin leider noch zu keinem Ergebnis gekommen :( Mein Vorgehen wie folgt: -Version 2.1 runtergeladen -Bootload: xtal = 12000000 -fastload: m32 auskommentiert, m8 aktiviert -avrasm2 -fi bootload.asm -avrdude -p m8 -c ponyser -P com1 -U flash:w:"C:\fboot21\BOOTLOAD\bootload.hex":i -U flash:v:"C:\fboot21\BOOTLOAD\bootload.hex":i -y -avrdude -p m8 -c ponyser -P com1 -U lfuse:w:0xee:m -U hfuse:w:0x9c:m Wenn ich nun fboot starte passiert nichts, egal wie oft ichs probiere oder wie oft ich den m8 resete. Ebenso hilft es nicht die Baudrate runterzusetzen. Jemand eine Idee? Gruß
Ohje... dabei wollte ich den Beitrag nicht abschicken sondern löschen -.- Vergessts einfach, für die anderen die auch so ein Problem haben, benutzt die fboot version von Alfred über mir Gruß...
Hallo @ Alfred N. RIESEN DANKESCHÖN für deine FBOOT Version. Ich habe es nun auch endlich geschafft meinen Asuro per Bluetooth zu flashen. Dank deinem Programm klappt es nun endlich. Zum einen ist die Erweiterung auf bis zu 16 Com Ports richtig gut (Mein Bluetooth Dongle verbindet sich immer auf Port5) und die Verbesserte Unterstützung von USB Wandlern/Bluetooth ist einfach genial. Aber das Problem mit dem langsamen flahen habe ich auch. Für 7,6kb brauche ich über 40s, mit einer echten RS232 habe ich nur 2-3s gebraucht. Christian
Moin moin, fange gerade erst an mit Bootloader zu arbeiten. Und da habe ich mal eine Frage: Ich habe in das Programm eine Funktion eingebaut, dass zum Bootloader springt (entspricht ja einem Reset), wenn über die serielle Schnittstelle "res\r" empfangen wird. Dachte, dass fboot.exe ... /I[..] dann den String incl. carriage return sendet und somit der Bootloader über die rs232 aktiviert wird. Nur: Wie schreibe ich das \r bzw. den gesamten String in die Kommandozeile? /Ires\r hat nicht funktioniert. Hardware: ATmega644P. Das erste flashen funktioniert problemlos, der Bootloader funktioniert prinzipiell also. Vielen Dank schonmal! Tim
Das Tool sendet 0xff zum resetten, der String ("peda" als Default) ist
eine Art Passwort was erst später übermittelt wird.
Moin, ich versuche auch gerade auf das gesendete 0xFF zu reagieren, habe da aber noch so meine Probleme. Wenn ich ein einfaches 0xFF per HyperTerminal (als Textdatei) sende funktioniert es, aber mit der FBOOT.exe klappt es nicht. Ich benutze die UART Libary von Peter Fleury auf einem ATmgea8. Habe es erstmal so probiert:
1 | while(1) |
2 | {
|
3 | c = uart_getc(); |
4 | if(c==0xff) |
5 | uart_puts("Reset"); |
6 | }
|
Habe ich da noch einen Denkfehler drin? Christian
Wenn Du den Bootloader aus der Applikation aufrufen willst, mußt Du die UART vorher wieder abschalten. Er weiß ja nicht, ob der Chip (ATtiny13..ATmega2561) überhaupt ne UART hat. Am besten ist es, den Bootloader aus der Applikation per Watchdogreset zu starten. Peter
Ja so mache ich es bei mir und es klappt einwandfrei. Allerdings nutze ich momentan Bascom und kein C. Ich prüfe in der UART ISR einfach ob das Zeichen besagtes 0xff (255 binär) ist, und starte dann den Watchdog:
1 | Urxc_isr:
|
2 | Key = Inkey() |
3 | If Key = 13 Then |
4 | Flag = True |
5 | Elseif Key = 255 Then |
6 | Start Watchdog |
7 | Else
|
8 | Inputstr = Inputstr + Chr(key) |
9 | End If |
10 | Return
|
Ist es 13 (Return) setze ich ein Flag was ich in der Mainloop auswerte, bei jedem anderen Zeichen wird es einfach an einen String angeängt (für ankommende Befehle die ich in der Mainloop dann ausführe). Da ich aber nach jetzigem Stand mit 254 Befehlen auskommen werde, werde ich das bei Gelegenheit noch umstellen und die Klartext-Kommandos verwerfen. Gruß Dominique Görsch
Ich habe es jetzt mit dem Reset hinbekommen, hatte die Variable als int deklariert... Jetzt connected er aber immer im One Wire Mode, meldet dann aber die Falschen Device Informationen. Ich habe den Controller aber über eine Bluetooth Verbindung angebunden. Wenn ich den ATmega erst anschalte wenn er sich connecten soll geht es. Welche Bedingunggen braucht die Fboot.exe um den One Wire Mode zu nehmen?
Angehängte Dateien:
-
Screenshot.png
21 KB
@Harald L.
>Hielte ich zumindest in Verbindung mit Eclipse für extrem praktisch.
Oder ein Eclipse Plugin, das wie beim starten einer Java Applikation das
Flashen ermöglicht. (siehe Screenshot)
Leider funktioniert das ganze noch nicht, aber zumindest steht die GUI
und RS232 ist per rxtxSerial auch vorhanden...
Wenn jemand mitentwickelt will kann er sich bei mir melden;-)
Ich werde das ganze hier online stellen wenn ich es irgendwann mal
fertig kriegen sollte;-)
mfg Andreas
Habe auch das Problem mit dem OneWire Mode behoben. Allerdings nur wirklich nur behoben, nicht gelöst. Habe einfach in der Fboot.exe die OneWire Erkennung auskommentiert und neu übersetzt... Nu gehts jdf. schon mal.
Hallo, ich habe den Bootload leider ohne erfolg ausprobiert. Bei mir kommt folgendes: D:\FBOOT>fboot /C1 /B9600 /Pmain.hex COM 1 at 9600 Baud: / Aborted D:\FBOOT>fboot /C1 /B19200 /Pmain.hex COM 1 at 19200 Baud: \ Aborted D:\FBOOT>fboot /C1 /pmain.hex COM 1 at 115200 Baud: Connected Nach dem ich die Spannung beim letzten Versuch weggenommen habe kam das hier: Bootloader VFFFFFFFF.FF Error, wrong device informations Kann das an der Hardware liegen? Ich nutzen an einen ATMega8 mit internen RC-Oszillator auf 8MHz. .equ STX_PORT = PORTD .equ STX = PD5 .equ SRX_PORT = PORTB .equ SRX = PB7 Das hier sind meine Portkonfigurationen. Was mache ich Falsch? geht das Programm evt nicht mit einem XTAL Pin? Danke Schonmal. Peter
@andreasb Hallo, ich habe eine Implemntierung in Java als Eclipse Plugin. Zum ausprobieren die Class TestBootloader anschauen. Der OneWire Modus ist nicht implementiert zur zeit.
Hallo, mein Problem hat sich erledigt. Es war ein Harwarefehler(Stützkondensatoren des MAX232 für +/- 10 vergessen an Masse anzulöten. arg Gruß Peter
Hallo alle ;) Ich habe seit ewigen Zeiten keine Probleme mit dem hier genannten Bootloader gehabt, lief auf Anhieb und tut an sich das, was er soll. Allerdings habe ich "nur" die Version 1.4 in das Gerät gebrannt. Da der Bootloader eine "Selbstzerstörung" verhindert, kann ich ja leider nicht das Feature "Bootloader ersetzen" nutzen, das der hier zum Einsatz kommende mega32 ja grundsätzlich unterstützen sollte (ausser ich verstehe das Datenblatt in dieser Hinsicht falsch). Um den Schutzmechanismus "zu Umgehen", habe ich mir nun gedacht "verschiebe doch einfach das Bootloader-Programm von "BootStart" nach "0x0030" und springe entsprechend dorthin. Damit hab ich ja zunächst mal ein App-Space Programm, das natürlich kein SPM durchführen kann. In diesem Programm hab ich dann die Adressenabfrage auskommentiert und so ja zunächst einmal verhindert, das ich nicht in den BLS schreiben darf. Ein kurzer Blick aufs Map-File des Original-Bootloaders (und nach ersten Problemen auch einn Blick auf einen Hexdump einer MCU) hat sich für die Subroutine "do_spm" die Adresse 0x3FA5 ergeben. Nun habe ich versucht, anstelle RCALL do_spm einen CALL 0x3FA5 auszuführen, für die "App-Space-do_spm" ein JMP 0x3FA5 anstelle "do_spm:" bis zum zugehörigen "RET". (Das RET hab ich wegen der do_spm_rerww stehen lassen, selbst wenn es nie genutzt würde, würde es ja auch nicht stören.) Zum Testen habe ich eine Schaltung hier, wo ich auch SPI-Zugriff habe, habe mir also den Fastboot 1.4 (der beim Start eine LED anmacht) aufge- spielt (die Sprungadresse fürs SPM ist dabei gleich geblieben). Der BL funktioniert auch einwandfrei, praktisch habe ich hier den Zustand, den auch die Geräte haben, bei denen ich keinen Zugriff mehr auf SPI habe. Spiele ich nun per fboot.exe (1.4) meine "Bootloader-im-App-Space" Version auf (hier hab ich die LED "ausgeschaltet", zum Unterscheiden), kriegt fboot.exe auch eine Verbindung zu diesem AppSpace-Loader, zeigt alle Daten der MCU an und versucht, ein Hex-File zu flashen.. Dummerweise klappt es schon beim ersten Block nicht, es wird "failed" angezeigt, nachdem eine längere Zeit gar nichts passierte. Interessanter- weise geht die LED an, was mir sagt, das die MCU irgendwo hinspringt, wo die LED eingeschaltet wird. Nach dem "App-Space"-Bootloader-Versuch ist ab dem leuchten der LED wieder der "ursprüngliche" im BLS befindliche Bootloader aktiv, der App-Space-Loader springt nicht an. Gibt es eine Möglichkeit, den Bootloader von 1.4 auf eine höhere Version upzudaten, ohne Zugriff auf die SPI-Schittstelle zu haben ? Grundsätzlich sollte ja der Weg schonmal richtig sein, sich eine App-Space-Anwendung zu schreiben, die wie ein Bootloader den Flash neuschreiben kann, nur das ein SPM halt im BLS liegen muss, um ausgeführt zu werden. Auch wenn in der 1.4 das SPM nicht "allein" steht, sollte man doch (da die Sprung- adresse bekannt ist und später ein "RET", kein "JMP PC-????" oder auch "JMP PC+????" folgt) das Problem lösen können ? Ich hoffe hier auf weitere Anregungen, zugegeben habe ich "nur" 2 Stunden an dem Problem gesessen, aber mir will kein Fehler mehr auffallen. Grüsse, Tim
Tim schrieb: > Gibt es eine Möglichkeit, den Bootloader von 1.4 auf eine höhere Version > upzudaten, ohne Zugriff auf die SPI-Schittstelle zu haben ? Ich habe nichts vorgesehen, um ein Update zu ermöglichen. Ich weiß jetzt nicht, wieviel im Bootbereich des ATMega32 noch frei ist. Du brauchst mindestens eine Page, wohin Du ein neues do_spm schreiben kannst, da ja das alte gelöscht wird. Und dann muß natürlich alles klappen. Ist irgendwas im 1.Bootloader verändert, hast Du keinen 2.Versuch. Peter
Hallo Peter. Ja, das leuchtet mir nun ein mit dem Überschreiben - scheinbar ist genau das auch das Problem. Daran hatte ich zunächst gar nicht gedacht, das ich das do_spm ja überschreiben würde/werde.. hat was von den Wald vor lauter Bäumen nicht sehen .. Gruss, Tim
Hallo an alle. Habe von einem Kollegen von dem Thread und dem Projekt hier gehört und muss sagen: Respekt! Also ist nen super Projekt und so, aber einen Kritiktpunkt muss ich ja nochmal los werden: Das ist hier verdammt unübersichtlich und ich bin als Neueinsteiger eindeutig nicht bereit mir hier alles durchzulesen, denn das sind inzwischen über 120 Seiten Text! Also gibts irgendwo ne Seite/Beitrag wo alles mal zusammengefasst ist, alle Software, die inzwischen zu diesem Projekt gehört etc? Vor allem wo es jetzt die aktuellste Version des Bootloaders gibt.
@Fabian S.: Dass man die hier typischen 100-seitigen Artikel nicht lesen will, kann ich absolut nachvollziehen. Aber dass man zu faul ist, 10 Sekunden lang in die Artikelübersicht zu schauen, ist mir nicht verständlich... http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger
Angehängte Dateien:
-
fuses_mega8.png
31 KB
Ahh, ich hatte nur das PDF: http://www.mikrocontroller.net/attachment/25392/Bootloader_FastBoot_von_Peter_Dannegger.pdf Im Artikel sind wohl noch ein paar Downloads, danke! Ein großes Problem bleibt aber. Ich habe das Teil inzwischen kompiliert bekommen, aber ich weiß nicht genau wie ich es in die Karre Programmieren muss. Ich habe kein avrdude und avrdude unterstütz meinen Dongle auch nicht (soweit ich weiß). Ich habe den AVR ISP mkII. Daher programmiere ich immer über das Tool von AVR Studio. Ich habe die Hex einfach mal normal programmiert, die Fuses gesetzt und probiert, geht nicht. Dann hab ich gesehen, dass bei den Fuse-Einstellungen steht, dass er Bootloader an stelle 0x0F00 stehen muss. Wie bekomm ich den da hin?
Fabian S. schrieb: > Ich habe kein avrdude und avrdude unterstütz meinen > Dongle auch nicht (soweit ich weiß). Ich habe den AVR ISP mkII. Ist ja nicht zu fassen, wie suchfaul du bist! http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#SEC4
Alex H. schrieb: > Ist ja nicht zu fassen, wie suchfaul du bist! > http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#SEC4 So schlau war ich auch schon mal! > avrdude -p m8 -P usb -c avrispmkII -U flash:w:m8.hex:i -U flash:v:m8.hex:i -y > avrdude: usbdev_open(): did not find any USB device "usb" For the JTAG ICE mkII, if AVRDUDE has been built with libusb support, port may alternatively be specified as usb[:serialno]. In that case, the JTAG ICE mkII will be looked up on USB. If serialno is also specified, it will be matched against the serial number read from any JTAG ICE mkII found on USB. The match is done after stripping any existing colons from the given serial number, and right-to-left, so only the least significant bytes from the serial number need to be given. For a trick how to find out the serial numbers of all JTAG ICEs attached to USB, see Example Command Line Invocations. As the AVRISP mkII device can only be talked to over USB, the very same method of specifying the port is required there. Darauf hin habe ich damals versucht Avrdude mit libusb zu bauen, hat jedoch absolut nicht funktioniert, habe mir Tagelang dabei die Zähne dran ausgebissen, und hier konnte mir auch niemand helfen. Dann bin auf das mitgelieferte Tool umgestiegen, da es wunderbar funktioniert. Also nochmals meine Frage: Geht das auch mit dem was ich habe?
Ich habe mir mal mit dem hex File ganz allgemein beschäftigt und musste feststellen, dass da ja absolute Adressen drin stehen, dachte das wäre nur ein "Hex-Dump". So, interessant ist jetzt, dass in meinem hex File steht, dass die ganzen Daten an die Stelle 0x1E00 kommen: :101E0000F8940FE50DBF04E00EBF22243324909A0E Warum? Und kann ich das von vornerein korrigieren? Bin grade Dabei ein kleines Programm zu schreiben was mir das Hexfile umschiebt und die neuen Hash Werte berechnet, sauber ist das aber nicht wirklich :( Jemand eine Idee?
Fabian S. schrieb: > Ich habe mir mal mit dem hex File ganz allgemein beschäftigt und musste > feststellen, dass da ja absolute Adressen drin stehen, dachte das wäre > nur ein "Hex-Dump". Das Hex enthält Adressinformationen, damit man unprogrammierten Ballast nicht mitschleppen muß. Ist doch clever. > So, interessant ist jetzt, dass in meinem hex File steht, dass die > ganzen Daten an die Stelle 0x1E00 kommen: Das ist abhängig von dem AVR, den Du auswählst. Die Adresse wird auf die höchstmögliche im Bootbereich gelegt, damit maximal Flash für die Applikation übrig ist. > Bin grade Dabei ein kleines Programm zu schreiben was mir das Hexfile > umschiebt und die neuen Hash Werte berechnet, sauber ist das aber nicht > wirklich :( ??? Das ist Unsinn. Was bezweckst Du damit? Peter
Ich bezwecke damit das Teil zum laufen zu bekommen ;) Ich darf nochmal auf das Bild hinweisen: http://www.mikrocontroller.net/attachment/55440/fuses_mega8.png Da steht, dass der Bootloader an Adresse 0x0F00 liegen muss, warum steht dann im Hex-File, dass er an 0x1E00 liegt? Kann ich irgendwie ein Lebenszeichen aus dem Bootloader bekommen? Also die Daten vom Programm kommen zum µC und auch an den richtigen Anschluss, aber der µC reagiert nicht.
Hallo, ich habe eine Schaltung mit einem ATTiny45 ohne Quarz bei der zwei Eingänge über einen Optokopter (HCPL0603 - invertierend) nach außen geführt sind. Gibt es eine Möglichkeit den uC von außen zu flashen, obwohl ich über den Optokopler keine Rückmeldung realisieren kann Gruß Christian
Angehängte Dateien:
-
Attiny45_OK.GIF
9,6 KB
Anbei noch ein Ausschnitt aus meiner Schaltung. Könnte ich vielleicht ein ONEWIRE Interface realisieren, indem ich einen Pin des ISP Steckers mit Strobe1_24V verbinde? Vielleicht über eine Diode oder einen Hochohmigen Widerstand? Gruß Christian
Mhh wie ist das denn mit dem kompilieren des Bootloaders? In der Anleitung steht, dass ich die m8.asm nehmen soll, die gibt es aber nicht (in der Version 2.1). Dann habe ich die BOOTLOAD.ASM genommen, kompilierte ohne Probleme. War das denn richtig?
Fabian S. schrieb: > (in der Version 2.1). Dann habe ich die BOOTLOAD.ASM genommen, Ja. Die ist für alle möglichen AVRs. Du mußt daher das richtige Headerfile aktiveren (Kommentarzeichen entfernen), dann stimmt auch die Adresse. Und dann die Fuses für den Bootstart setzen, bzw. Die Selfprogrammfuse. Wenn die Verbindung nicht klappt, ne kleinere Baudrate probieren, insbesondere, wenn Du die Fuses auf 1MHz läßt. Peter
Muss ich das Selfprogrammfuse beim Atmega8 setzen? Dachte der hat keins? Baud ist schon auf 19200 runter. Habe inzwischen den Laptop rausgeholt und da nen USBSeriall Wandler angeschlossen um das ganze mal mit Windows XP 32Bit zu probieren (Hab sonst Vista64), geht aber auch nicht. Dann auch nicht mit dem original Tool. Habe die richtige Zeile in der bootload.asm einkommentiert und das was schon einkommentiert war, wieder auskommentiert. Ich habe die Pins so gelassen wie sie waren, also sind die Pins wie die Hardware-UART Pins. Für die Bootflags verweise ich nochmals auf den Screenshot: http://www.mikrocontroller.net/attachment/55440/fuses_mega8.png Noch ne Idee?
Hat hier schon mal jemand den Bootloader für nen Atmega8 kompiliert und auch zum laufen bekommen? Könnte derjenige mir bitte die hex File zukommen lassen, damit ich das Problem der Kompilation schon mal ausschließen kann? Vielen Dank. Edit: Ich habe grade etwas interessantes rausgefunden. Wenn ich den Bootloader programmiere und überprüfe meint AVR Studio, dass alles OK ist. Wenn ich den Flash dann aber auslese in ein anderes Hex-File steht der Bootloader nicht drin! Da ist überall nur FFFFFF...
So, große Erlösung! Es lag an dem Programm für den AVR ISP mkII des AVR Studio 4.16. Habe auf 4.17 aktualisiert und alles geht! Scheinbar war da irgendwie ein Bug beim interpretieren des Hex-Files.
Joa die Tatsache, dass er aus dem ATMega nur lauter FF gelesen hat und auch meinte, dass das mit dem hex-file übereinstimmt war schon etwas verdächtig. Habe das Hex-File dann nem Kollegen geschickt, der hats aufn mega8 gebrannt, wieder ausgelesen und das ausgelesene mir zurück geschickt, das konnte ich dann ohne Probleme brennen. :P Also alles sehr seltsam.
Das neuste AVRStuido hat da einen Bug. Kompiliert man ein HEX File das erst mitten im FLASH beginnt so steht im HEX File keine Daten für die Adresse 0x0000 im AVR. AVRStudio lädt dieses HEX File und wenn dort drinnen auch die Adresse 0x0000 mit Daten steht, egal was, wird es den AVR auch korrekt programmieren. Das erklärt auch warum das HEX deines Kollegen bei dir geht. Denn beim Auslesen des FLASHs wird ein HEX File erzeugt das alle Adressen umfasst und somit auch Adresse 0x0000. Lösung ist softwaretechnisch simpel: an org 0x0000 ein db 0xFF,0xFF einfügen. Auf dieses Problem bin ich hier gestoßen Beitrag "Re: AVR-Bootloader mit Verschlüsselung" Das Fatale daran ist das der AVRStudio Programmer selbst beim Verify meint alles wäre ok. Stimmt aus seiner SIcht auch, denn wenn der Parser des HEX Files meint der FLASH müsste komplett mit 0xFF gefüllt werden dann wird beim Verify auch kein Fehler auftreten wenn alles mit 0xFF gefüllt ist. Es liegt also definitiv am HEX File Parser des Programmers der HEX Files die nicht bei .Org 0 beginnen einfach alles mit 0xFF parst. Füge also in Peters Source folgendes ein
1 | .org 0 |
2 | .db 0xFF,0xFF |
Gruß Hagen
Sehr interessant. Du hast Recht, das steht in dem Hex-File nicht, aber GRADE in der aktuellen Version (4.17) gehts ja und in der alten (4.16) ging es nicht. :-/
Ich habe den Bug in Version 4.16 entdeckt, das es Version 4.17 schon gibt war mir garnicht bewusst. Schätze mal das dort der Bug schon wieder gefixt wurde. Dh. anscheinend ist nur Version 4.16 betroffen. Gruß Hagen
Auszug aus Release Notes 4.16 SP1 >Bug Fixes >9473 Programming dialog - Empty Flash's .hex file read-back after programming and verification >9510 Programming dialog - Cannot program a bootloader Der Fix mit .org 0 hilft aber. Gruß Hagen
Hallo nochmal ;) Da das ganze bei mir ja nun endlich funktioniert wollte ich eine Stufe weiter gehen und das ganze über ein Bluetooth Modul "tunneln". Ich verwende dafür den UpdateLoader 2.1.9.106, da er unter Vista 64Bit läuft. So, wie sollte es anders sein, es geht nicht. Das seltsame ist, dass das Bluetooth Modul garnicht mitbekommt, dass das Programm sich verbunden hat. Wenn ich mit hterm rauf gehe, kommt sofort ein CONNECT, aber beim UpdateLoader nicht. Woran kann das liegen? Nutzt das Programm den COM-Port in irgend einer abnormalen Weise oder so?
Hallo, @ Fabian S. vielleicht hilft es Dir einwening weiter. Mein Upload ist 3 Beiträge weiter oben. Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" Gruß Alfred
3 Beiträger weiter oben ist was von Hagen, ohne Anhang :( Selbst wenn, 16 Ports hilft mir 0. Der Bluetooth Port ist COM40! Und das er so lange braucht hatte ich auch bislang immer. Sowohl mit PCI-Seriell Erweiterung als auch mit USB-Seriell Adapter.
also dann so Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" Die Ports kannst Du aufbohren .... ist die Source bei. Gruß Alfred ( soviel Zeit muß sein)
Und warum geht der Source nur bis Port 16?
Da ist ja die Sonderbehandlung für Ports > 9 drin, geht das dann wieder
nur bis 16 oder wie?
// Open the serial port
if (port > 9)
sprintf(str,"\\\\.\\COM%d",port);
else
sprintf(str,"COM%d",port);
// Open the serial port
if (port > 9)
sprintf(str,"\\\\.\\COM%d",port);
else
sprintf(str,"COM%d",port);
IST nicht WICHTIG !
In fboot.cpp
#define COMPORTMAX 16
setze auf .... 40,41..
UND
int serial_connect (void)
{
char WAITSTRING[] = { '|', '/', '-', '\\' };
int i = 1;
int echo = 0;
char *s;
int j = 0;
clock_t t = clock();
readargs( ALONG, 'b', &Baud );
if( Baud < 2 )
Baud = 2;
if( Baud > 115200 )
Baud = 115200;
readargs( AINT, 'c', &ComPort ); // serial port
if( ComPort > COMPORTMAX ){
ComPort = 1;
printf("\nCOMport > 16 -> COMport = 1 !\n");
}
und hier
printf("\nCOMport > 41 -> COMport = 1 !\n");
so sollte es Laufen.
Gruß Alfred
Cool, danke! Hatte noch ein paar Fehler: ...\Proj>g++ -o fboot.exe fboot.cpp serial.cpp fboot.cpp: In function `int readhex(FILE*, long unsigned int*, unsigned char*)': fboot.cpp:423: error: invalid conversion from `char*' to `unsigned char*' fboot.cpp:423: error: initializing argument 1 of `int sscanhex(unsigned char*, unsigned int*, int)' fboot.cpp:426: error: invalid conversion from `char*' to `unsigned char*' fboot.cpp:426: error: initializing argument 1 of `int sscanhex(unsigned char*, unsigned int*, int)' fboot.cpp:431: error: invalid conversion from `char*' to `unsigned char*' fboot.cpp:431: error: initializing argument 1 of `int sscanhex(unsigned char*, unsigned int*, int)' fboot.cpp:435: error: invalid conversion from `char*' to `unsigned char*' fboot.cpp:435: error: initializing argument 1 of `int sscanhex(unsigned char*, unsigned int*, int)' fboot.cpp:446: error: invalid conversion from `char*' to `unsigned char*' fboot.cpp:446: error: initializing argument 1 of `int sscanhex(unsigned char*, unsigned int*, int)' Habe die einfach durch ein paar casts hingebogen, ist vermutlich OK. Habe die Software nun noch nicht getestet. Wer zu faul ist, im Anhang ist die exe ;) Womit hast die denn original kompiliert? Visual Studio? Die Warnings im g++ sind ja gresslich, solltest du dir mal ansehen.
OK. Hier mal die ganzen Warnings, falls du Lust hast dir das mal anzusehen: fboot.cpp:15: warning: ignoring #pragma hdrstop fboot.cpp:113: warning: ignoring #pragma argsused fboot.cpp: In function `int readargs(int, char, void*)': fboot.cpp:140: warning: conversion lacks type at end of format fboot.cpp:140: warning: too many arguments for format fboot.cpp: In function `int main(int, char**)': fboot.cpp:218: warning: double format, different type arg (arg 2) fboot.cpp:170: warning: unused variable 's' fboot.cpp: In function `int program(char*, int)': fboot.cpp:323: warning: comparison between signed and unsigned integer expressions fboot.cpp: In function `int read_info()': fboot.cpp:537: warning: comparison between signed and unsigned integer expressions fboot.cpp: In function `void getpasswd()': fboot.cpp:565: warning: unused variable 'j' serial.cpp: In function `void ShowLastError()': serial.cpp:231: warning: char format, void arg (arg 2) serial.cpp: In function `BOOL SerialIsChar()': serial.cpp:452: warning: unused variable 'str'
Hier mein ORGINAL POST !!!
*****************************
Hallo,
ja als erstes "Vielen Dank an Peter Dannegger" für den Bootloader und
allen andern die das hier möglich gemacht haben!
Habe FBOOT um wenige Zeilen (Programm Zeilen) erweitert.
Neu ist :
- Portiert auf C++Builder 2007 Kommando-Zeile (sollte aber auch mit
DevCpp laufen).
- Für Win32 XP und auch Vista.
- 1Wire laeuft nun auch unter windows XP / Vista;
- Mit USB auf RS232 Adapter(nicht TTL) und dann "PEDA 1Wire
Interface".
- Getestet mit Prolific USB auf RS232 Adapter (Quelle Glyn) wurde von
Vista sofort ohne Treiber Inst. erkannt.
- Vista mit RS232 konnte ich nicht testen da mein Laptop nur USB hat;
So und nun zu den Baudraten Max. bei mir :
- PC mit XP mit on Board RS232 (com1) weitere gibt es NICHT -> 57600
Baud.
- Gleicher PC mit PCI Multi-RS232-Card 8x -> 38400 Baud.
- Laptop mit USB auf RS232 Adapter(nicht TTL) und dann "PEDA 1Wire
Interface"-> 115200 Baud " ein Wunder !" NEIN , trotzdem ist die
UPLOAD-ZEIT 3 mal so lang statt 2 Sek. > 6 Sek ist halt USB mit
Vista.
*********************************
Aber ich kann ja morgen bzw (heute neu Compilieren)
und uploaden.
Gruss Alfred
So, bin nun grade mal dazu gekommen das ganze zu testen. Es funktioniert natürlich nicht. Gehe ich richtig in der Annahme, dass ich beim Parameter /I das Passwort angeben muss? Des weiteren habe ich es bisher so mitbekommen, dass das Protokoll zum Anfang das Passwort sendet. Das Programm macht das auch, aber scheinbar denkt der mega8, dass es falsch ist, denn er wartet nach dem Reset keine 0,33 Sekunden sondern startet sofort das Programm. Des weiteren ist mit aufgefallen, dass der UploadLoader und das Original Tool nach dem Passwort immer noch ein Zeichen senden. Glaube es war ein 0xFF. Dies passiert bei Programm von Alfred nicht. Warum?
Hallo Peter, ich habe deinen Bootloader mittlerweile schon mehrfach benutzt. Ich habe ihn in Controller geflasht die internen Takt haben und auch in Welche mit Quarz. Bei denen die den internen Taktgenerator verwenden habe ich immer eine externe Schaltung mit MAX232 verwendet, da bei diesen Projekten sonst kein RS232 vorgesehen ist. Ich habe ein paar Feststellungen gemacht und es würde mich freuen, wenn du was dazu erklären könntest. 1. Der Bootloader V1.4 schafft bei mir immer nur 9600 Baud, sonst startet er gar nicht erst. 2. Der Bootloader V2.1 geht erst unter 4800, aber am besten unter 2400 Baud, sonst kommt ein CRC-Error 3. Wenn ich Version 1.4 in den µC flashe, dauert das bestimmt 1 Minute (STK500, AVR-Studio, "richtiger" RS-232 Port), bei Version 2.1 geht es ca. 1-2 Sekunden 4. Im Grenzbereich der Baudrate also irgendwo zwischen 4800 und 9600 Baud kommt es vor, dass die Übertragung der Firmware fehlerfrei ist, aber dennoch das Programm nicht startet. Einmal startete es sogar, jedoch funktionierten bestimmte Sachen nicht. Wenn ich mit unter 2400 Baud Übertrage geht es immer problemlos. Diese Fuses habe ich z.B. bei einem Atmega8515 gesetzt: BOOTSZ: 256 Words BOOTRST: gesetzt Ich will wirklich nicht an deinem Bootloader herumkritisieren, denn er funktioniert ja sonst wunderbar. Ich würde nur gerne wissen, was ich falsch mache. MfG Paul
Hallo,
@ Fabian S.
das Passwort ist "Peda"
und ohne Passwort geht es NICHT !
char Passwd[130] = "Peda";
Fabian S. worte
Des weiteren ist mit aufgefallen, dass der UploadLoader und das Original
Tool nach dem Passwort immer noch ein Zeichen senden. Glaube es war ein
0xFF. Dies passiert bei Programm von Alfred nicht. Warum?
flasch !
for(;;){
if( (clock() - t) > 90 ){
t += 80;
printf( "\b%c", WAITSTRING[++j&3] );
}
if( kbhit() ){
// getch();
return 1;
}
s = Passwd;
do{
if( *s )
senden( *s );
else
senden( 0xFF );
Hier wird es gesendet !
Gruss Alfred
Ähhh, seltsam. Schau ich mir heute abend noch mal an. Auf jeden Fall hab ich mein PC mal ran gehalten und da kam nur das PeDa an und nicht das 0xff.
Klasse Sache, bei meinem ATMega8 läuft der Bootloader auch prima! Mir ist nur aufgefallen, dass man das hex-File vom Bootloader nicht mit AVRStudio "brennen" kann, warum auch immer jedenfalls ist der Chip immer leer. Dann habe ich es mit AVRDude + STK500 gemacht und schwups lief alles. Ich vermute mal es gibt irgendwo ne Funktion im AVRStudio um Bootloader zu schreiben oder ka. Ja jedenfalls Super Sache. Bin gerade dabei eine USB Steckdose zu bauen und da ist es ganz nett wenn ich den µC direkt über die USB Verbindung (FT232) beschreiben kann. Gruß Daniel http://itse.homeip.net
Das ist ein Bug in einer bestimmten Version von AVRStudio. Schau mal ein paar Posts weiter oben, da wurde das bereits Thematisiert.
Aus bootload.asm: ;set the SecondBootStart fuse Für m168 - um welche Fuse handelt es sich dabei, ich finde nichts im Datenblatt. Ist damit gemeint: "Boot Flash section size=256 words Boot start address=$1F00; [BOOTSZ=10]" (http://www.engbedded.com/fusecalc/ ) Aha: m168def.inc .equ SECONDBOOTSTART = 0x1f00
Hallöle :) Ich möchte mich an dieser Stelle mal für den tollen Bootloader bedanken ! Ich habe das Fboot und die Änderungen von Andreas N. in eine GUI verpackt und den Installer hier angehängt. Evtl. kann es ja jemand gebrauchen... :) Das Toolfenster verkleinert sich durch "X" in die Tray Leiste. Klicken auf das kleine IC- Symbol öffnet das Toolfenster wieder. Sollte der gewünschte Port nicht in der Liste erscheinen, kann er direkt eingegeben werden... Gruss kb
Hallo, @ Klaus Brandt (kcx650) Find ich gut das jemand da weiter gemacht hat wo ich aufgehört habe. Habe deinen Bootloader getestet und er läuft auch ganz gut nach dem ich mir die fehlende "BDERTL60.BPL" aus dem Netz geholt habe. Habe da doch einen Punkt der in das Programm einfliesen sollte. Das Passwort sollte (müßte ) frei wählbar sein. Dein Programm läuft aus dem Ruder wenn das falsche Passwort von der Hardware kommt. Auch ja da habe ich noch eine Kleinigkeit, Alfred.N und nicht Andreas.N. Kannst Du den Source-Code hier einstellen ? Gruss Alfred
Hallo Alfred, sorry für den "Andreas" ;) . Die fehlende Datei ist nun mit im Installer. Weiterhin ist die Eingabe des Passworts möglich. Wird dieses Feld leer belassen, wird automatisch "Peda" angenommen. Leider kommt vom Bootloader keinerlei Rückmeldung bei einem evtl. falschen Passwort. Erst wenn ein Teilstring des übertragenen Passworts mit dem "wirklichen" Passwort als übereinstimmend erkannt wird, antwortet der Bootloader mit einem "CONNECT". Hierdurch läuft das Flashtool, bei falschem Passwort, bis zum Timeout... Gruss Klaus
Hallo Klaus, Habe das Programm noch mal kurz getestet, alles läuft problemlos und fehlerfrei. Gute Arbeit ! Kannst Du den Source-Code (das Projekt ,nehme an C++Builder)hier einstellen ? Gruss Alfred
Hi, habe nun einiges probiert, aber der Mega88 bleibt stumm. Ich habn Oszi an RX TX um gleich zu sehen wenn antwort kommt, doch diese bleibt aus. Also im Bootloader sbi DDRD, 5 sbi PORTD, 5 direkt nach dem .org BootStart in der fastload.inc ergänzt....... LED bleibt auch dunkel. Dann ein eigenes Testprogram geschrieben: .include "m88def.inc" sbi DDRD, 6 sbi PORTD, 6 ende: rjmp ende .org FirstBootStart sbi DDRD, 5 sbi PORTD, 5 Das Funktioniert, schalt ich den bootvektor aus, geht eine led an. Schalt ich den bootvektor ein, gehen beide LEDs an. Dann nochmal mit SecondBootStart probiert. Funktioniert auch. Habt ihr ne Idee wieso es nicht geht? Der Mega scheint ja in Ordnung. LG Floppy
Hallo. Kann ich für OneWire auch den Reset-Pin (eines Tiny25) nutzen? Also Bootloader aufspielen, anschließend das Häkchen bei RSTDISBL in AVRStudio setzen und dann mit Onewire an PB2 (ehemals "Reset-Pin" bzw. "Reset-Nicht") Programme in den Speicher laden? Mit ISP lässt er sich anschließend nicht mehr ansprechen, das sehe ich schon ein. Ginge dann nur noch mit dem STK500. Daher wäre ich euch dankbar, wenn ich vorher eine Rückmeldung bekommen könnte. Auch für den Fall, dass meine Sorgen unbegründet sind. Viele Grüße Paul
Gemeint ist oben natürlich PB5, also Pin 1 (Reset), nicht PB2. Entschuldigung.
Ich habs noch nicht getestet, aber nach dem Umfusen ist der Reset-Pin ja normaler I/O. Daher sollte es gehen.
Hallo Bootloader, ich würde es gerne auch mit einem AtTiny25 versuchen. Die BOOTLOAD.ASM habe ich folgendermaßen angepasst: .equ STX_PORT = PORTB .equ STX = PB3 .equ SRX_PORT = PORTB .equ SRX = PB4 Die FASTLOAD.H so: .equ XTAL = 8000000 ; 8MHz, not critical .equ BootDelay = XTAL / 3 ; 0.33s alternativ auch mal XTAL = 1000000 Alles entsprechend verdrahtet, kompilieren hat auch prima funktioniert. Anschließen über AVR Studio flashen ging auch noch. SELFPRGEN ist enabled. Brown-out Detection auch. Leider folgt dann auf /fboot /C1 /b9600 /pMain.hex nur COM 1 at 9600 Baud: - Den Tiny starte ich auch erst anschließend, wie beschrieben. Leider komme ich dann aber nicht weiter. Es passiert nichts mehr, außer, dass sich der Strich dreht. Ich nutze den internen Oscillator, mal 8 Mhz, mal 8/8 Mhz und den MAX232 von TI. Getestet mit echter RS232 Schnittstelle unter Windows ME und alternativ mit Prolific 2303 USB zu RS232 Konverter unter Vista. Baudrate und COM Port jeweils mit dem Bootloader abgeglichen. Würde mich freuen, wenn jemand wüsste, woran es scheitern könnte, und wo vielleicht die Lösung liegen könnte. Und ist es schon mal jemandem gelungen, mit dem interen Oscillator den Bootloader zu nutzen? Viele Grüße Robert
Robert Zimmermann schrieb: > Würde mich freuen, wenn jemand wüsste, woran es scheitern könnte, und wo > vielleicht die Lösung liegen könnte. Dabei kann ich dir leider nicht weiterhelfen, aber: > Und ist es schon mal jemandem gelungen, mit dem interen Oscillator den > Bootloader zu nutzen? Ja, ich nutze den Bootloader ausschliesslich ohne Quarz nur mit internem Taktgeber, allerdings auf einem mega16.
Hallo, Robert Zimmermann schrieb: >Leider folgt dann auf /fboot /C1 /b9600 /pMain.hex nur >COM 1 at 9600 Baud: - Teste mal: fboot /b9600 /c1 /pMain.hex /vMain.hex /iPeda Das Passwort ist "Peda" ! Gruß Alfred
Danke Alfred. Leider kommt auch hier die gleiche Ausgabe. "COM 1 at 9600 Baud: - " und keine Möglichkeit zur Eingabe des Passworts. Kann ich vielleicht den Oszillator des Tinys kallibrieren? Aber soweit ich es verstanden habe, ist das schon Bestandteil des Bootloaders. Andererseits hätte ich ja noch das Oscillator Calibration Byte aus dem AVR Studio Programmierinterface. Könnte das dem Bootloader helfen? Und Danke für die Zuversicht, Dominique :) Vermutlich hast du beim Mega aber Hardware UART genutzt, oder? Viele Grüße Robert
Robert Zimmermann schrieb: > Und Danke für die Zuversicht, Dominique :) Vermutlich hast du beim Mega > aber Hardware UART genutzt, oder? Ja, normal tue ich das. Aber ich meine ich habs auch schonmal auf einem anderen Pin genutzt.
Hallo, ich hab es jetzt auch mit dem Mega8 an den Pins C1 und C2 getestet, also Software UART. Echte RS232 Schnittstelle unter Windows ME. Fuses wie in der Pdf gesetzt. Das führt bei mir zu COM 1 at 9600 Baud: Connected Bootloader V2.1 Target 1E9307 ATmega8 Buffer: 960 Byte Size available: 7600 Byte Program TEST.hex: 00000 - 00091 successful Verify TEST.hex: 00000 - 00091 failed! Verify-Error Ich hab auch beim Gerätemanager unterschiedliche Handshakes eingestellt und es mit unterschiedlichen Baudraten versucht. Jeweils mit dem Bootloader abgeglichen. Ebenso mit 1Mhz und 8 MHz. Bei manchen Baudraten kommt stattdessen auch "CRC: failed!" oder "Program ... failed" Mit dem Bascom Terminal unter Windows ME funktioniert der Datenfluss in beide Richtungen. Könnte mein serielles Kabel zu lang sein? Das misst 3 Meter. Ist der Bootloader da empfindlicher als das Bascom Terminal? Viele Grüße Robert
Versuch mal ne höhere Baudrate (19,2k oder 38,4k), vielleicht ist der Timeout etwas knapp. Peter
Danke, damit wäre ich jetzt kurz vor dem Ziel. Es funktioniert nun auch beim Attiny25. Leider aber nicht mit OneWire an PB5, dem nun deaktivierten RESET-Pin. fboot kommt über "COM 1 at 19200 Baud: / " nicht hinaus. Das Multimeter meldet währenddessen zwischen PB5 und GND 2,7 Volt. Läuft fboot nicht, zeigt es 0 V an. An PB3 funktioniert es tadellos, mit OneWire. Natürlich mit entsprechend geändertem Bootloader. Ich habe den Bootloader mit AVR Studio geflasht. Anschließend das Häkchen bei SELFPRGEN gesetzt und das Häkchen bei CKDIV8 entfernt, weil er ja mit 8 MHz laufen soll. Brown-out bei 4,3 V. So stehts auch in der Fastload.h. Und in der Bootload.asm steht .equ STX_PORT = PORTB .equ STX = PB5 .equ SRX_PORT = PORTB .equ SRX = PB5 und .include "tn25def.inc" Wurde auch fehlerfrei kompiliert. Um sicher zu gehen, habe ich erst danach auch das Häkchen bei RSTDISBL gesetzt. Int RC Osc. 8 MHz ...+64ms, also Standard. Man soll ja wohl den höchsten Wert nehmen. Ich hab allerdings statt der N4148 Dioden N4001 eingestezt. Reset-Versuch erfolgt An und Ausschlaten des Netzgeräts. Jumper bzw. Schalter sind nicht eingebaut. Könnte der Ex-Reset Pin damit Probleme haben? Bei PB3 hat es doch aber auch funktioniert. Ist PB5, wenn man Reset deaktiviert nicht ein vollwertiger I/O-Pin, oder gibt es da Besonderes zu beachten? Kann mir vielleicht jemand einen Vorwiderstand empfehlen. Gefunden hab ich dazu leider nichts. Oder muss ich vielleicht noch das Häkchen bei SPIEN entfernen. Ist mit meinem USB MKII erst mal nicht zu machen. Und hier steht ja auch bisher nichts dazu, scheint also auch unwahrscheinlich zu sein. Viele Grüße Robert
kleiner Nachtrag: Die Verbindung zwischen PB5 und 10 kOhm Widerstand -> GND besteht auch nicht mehr. Es führt nur eine Leitung wischen Diode und 4,7k Ohm Widerstand. Beitrag editieren funktioniert gerade nicht. Entschuldigung.
Hallo, gibt es eigentlich eine Möglichkeit im Bootloader ein paar Bytes an Userdata zu schreiben und auch wieder auszulesen. Hindergrund: Das wäre eine sehr komfortable Möglichkeit die Versionsnummer des geflashten Programms abzulegen und auszulesen. Natürlich könnte ich das auch in meinem Programm selbst machen, aber dann muss ich mich um die Schnittstelle und das Protokoll kümmern. Und das alles nur für eine Versionsnummer. Der Bootloader hat die grundsätzlichen Funktionen dafür ja schon... Gruß Christian
Funktioniert leider immer noch nicht (wie oben beschrieben). Ich würde es ja nun gerne mal mit dem Watchdog testen. Da hab ich allerdings, wie mir gerade auffiel, noch ein Verständnisproblem: Dazu müsste ich doch über die serielle Schnittstelle, bei mir an PB5 des Tiny25 auf den Speicher zugreifen können. Ich müsste also in das eigentliche Programm, also die "main.hex" eine Software UART Schnittstelle integrieren. Da es mir aber nicht gelingt, über mit dem Bootloader die main.hex in den Controller zu schreiben, komme ich so nicht weiter, oder? Könnte mich bitte mal jemand in die richtige Richtung schubsen? Würde mich freuen. Viele Grüße Robert
Moin, bei mir läuft der Bootloader jetzt schon seit ca. einem halben Jahr auf meinem Asuro. Jetzt suche ich nur noch eine Möglichkeit, den Bootloader mit einer GUI zu benutzen. Hier sind ja schon ein paar aufgetaucht, aber soweit ich das gesehen hab alle in Delphi geschrieben. Gibt es auch schon welche die in C geschrieben sind? Oder in Java, dass will ich sowieso noch lernen ... Christian
Hallo Christian, weiter oben habe ich schon mal java Code attached der den Bootloader steuert, aber noch ohne GUI drüber. Der Code von damals funktioniert ist aber noch nicht schön. Ich denke aber das ich in den nächsten 1-2 Monaten daran weiter arbeiten werde. Wenn er fertig ist werde ich ihn wieder hier einstellen.
Hallo, ich versuche nun seit mehr als 10Std den Bootloader von Peter zum Laufen zu bringen. Mir ist klar, dass das eine triviale Sache sein müsste, jedoch bin ich neu im AVR Sektor! Nun zu den Fakten: -------------------- > Pollin Funk AVR Board > USB-RS232 Adapter > Atmega8 > PonnyProg für den Upload (Serial: SI Prog API # Com4 # keine Hackerln gesetzt) > avrasm zum compilieren der ASM Ich habe schon ein kleines Programm via PonyProg raufgeladen und das hat funktioniert (LED aufleuchten). Nun zum Problem: ------------------- * ich habe in der Bootloader.asm (oder m8.asm wie ich sie nenne" das "m8def" für den Atmega8 entkommentiert und "m168def.inc" kommentiert. * Kompilation mittels avrasm (generic -fG, da PonnyProg sonst nur FF Werte anzeigt) zu einer HEX * Den Bootloader habe ich mittels PonnyProg
1 | versucht |
auf den Atmel zu laden, jedoch (nach 50min #Write-Verify#) "Write failed" !? Nun zu meinen weiterführenden Fragen: ------------------------------------- > Wenn ich den Bootloader auf den Chip geladen habe, wie kann ich dann Programme auf den > Chip laden: ISP(Rs232) oder Seriell (RS232)? > Wie müssen die Fuses gesetzt werden (externer Quarz ) > Mit welchem Programm müssen die Fuses gesetzt werden? Ich habe nun schon annähernd alle eure Tutorials für diese Themen gelesen und auch schon das Forum durchstöbert -> Kein Uploaderfolg =( Könnt ihr mir helfen? Lg Tobias
Mal eine allgemeine Frage: Wie funktioniert eigentlich der Bootloader für die Tinys? Bei den megas ist es klar: Durch die BootReset Fuse wird zuerst der Bootloader angesprungen, der dann an die Adresse 0 zurückspringt. Aber wie geht das bei den AVRs ohne die Fuse? Wird da der Befehl an Adresse 0 manipuliert? Und woher weiß der Bootloader wie er dann die eigentliche Software starten soll?
Startet der Bootloader bei irgendjemandem auch ständig neu? Habe ich eine Fuse vergessen? Lg Tobias
@Benedikt: Ja der RESET Vektor wird manipuliert. Dessen originaler Inhalt wird in den letzten 2 Bytes vor dem Bootloader als RJMP/JMP gespeichert. Wichtig ist dabei die Vorgehensweise aus Löschen, Patchen, Neuschreiben dieser zwei FLASH Pages im laufenden Bootloader Betrieb. Wenn man es richtig macht geht das ziemlich problemlos und sicher. Gruß Hagen
Danke für die Erklärung. Das hatte ich schon vermutet, nur hatte ich mich gefragt wie vor allem der Rücksprung geht, denn den führt ja der Bootloader aus, aber der kann nicht verändert werden. Diese Adresse direkt vor den Bootloader zu packen ist natürlich sehr geschickt...
Wobei im Unterschied zu Hagens Bootloader mein Bootloader alles nötige selber macht. Über die UART kann also der größte Stuß reinkommen, der Bootloader wird nie unerreichbar. Man müßte schon eine Applikation reinladen, die absichtlich den Bootloader löscht. Bei Hagen ist das PC-Programm voll verantwortlich, daß Sprungberechnung und Reihenfolge stimmen. Daher ist auch die CRC unbedingt nötig, um fehlerhafte Aktionen abzuweisen. Peter
Das ist eine Frage der Wahrscheinlichkeiten, hatten wir schonmal kurz diskutiert ;) Wenn die PC Software die 1. und letzte FLASH Page gesondert behandelt, dann sinken die Wahrscheinlichkeiten für einen Deadlock. Zb. zuert letzte Page löschen, damit vorherigen RJMP MAIN löschen. Dann alle Pages ab der 2. schreiben und erst am Schluß die 1. und letzte Page mit den neuen Werten. Da die CRC von Hause aus drinnen ist es nicht zwangsläufig eine Begründung für ihre Existenz. Es hat eben einen entscheidenden Vorteil. In den meisten Fälle nutzt man eh ATmegas und da trifft dieses Problem nicht zu. Im Fall des ATTinys lagert es aber zusätzliche Komplexität in die PC-Software aus und das führt dann dazu das mein Bootloader in diesem Fall bei gleicher Funkionalität bis zu 20% kleiner ist als deiner. Das war auch der Hauptgrund für meine Entscheidung da ich für Tinys möglichst jedes Byte an FLASH sparen wollte. Nungut, wer das I-Tüpfelchen Sicherheit mehr haben möchte dem rate ich natürlich zu Peters Bootloader ;) Gruß Hagen PS: >Über die UART kann also der größte Stuß reinkommen, der Bootloader wird >nie unerreichbar. Gewagte Aussage übrigens ;) Wenn ausgerechnet dieser JMP falsch reinkommt und ohne CRC abgesichert wurde dann wirds auch bei deinem Bootloader krachen. Selbst eine CRC deckt nicht alle Fehler ab, das weist du. Auch wenn gerade beim Programmieren dieser FLASH Page ein Spannungseinbruch erfolgt wird es einen Deadlock geben. Nie, zu behaupten ist also sehr gewagt.
Übrigens, das was ich an FLASH Sepicher sparen konnte durch mein Vorgehen habe ich teilweise verwndet um für das FLASH und EEPROM Schreiben ein implizites Verify einzubauen. Dh. jede FLASH page wird sofort nach dem Schreiben auch überprüft. Das verhindert natürlich keine Kommunikationsfehler aber falls dochmal das Schreiben fehlschlägt versucht es die PC-Software bis zu dreimal und bricht dann ab. Bei Tinys lässte es den RJMP Bootloader im RESET Vektor stehen und die letzte FLASH Page in der normalerweise der RJMP MAIN steht bleibt weiterhin gelöscht. So denke ich verhindere ich mit hoher aber nicht absoluter Wahrscheinlichkeit eines Deadlocks bei Schreibfehlern ins FLASH. Auf alle Fälle stimme ich mit Peter darin überein das man sehr genau vorgehen sollte und sich über den Programfluß 100% sicher sein sollte bei diesem Vorgehen. Ansich ist also die Implementierung der Berechnung dieser Sprungvektoren im AVR Bootloader zu machen eine gute Idee. Denoch schützt auch sie nicht zu 100% vor einem Deadlock. Also bei meinen Tiny Projekten hatte ich mit solchen Deadlocks noch nie Probleme. Gruß Hagen
Dominique Görsch schrieb: > Ja so mache ich es bei mir und es klappt einwandfrei. Allerdings nutze > ich momentan Bascom und kein C. > > Ich prüfe in der UART ISR einfach ob das Zeichen besagtes 0xff (255 > binär) ist, und starte dann den Watchdog: > >
1 | Urxc_isr:
|
2 | > Key = Inkey() |
3 | > If Key = 13 Then |
4 | > Flag = True |
5 | > Elseif Key = 255 Then |
6 | > Start Watchdog |
7 | > Else |
8 | > Inputstr = Inputstr + Chr(key) |
9 | > End If |
10 | > Return |
> > Ist es 13 (Return) setze ich ein Flag was ich in der Mainloop auswerte, > bei jedem anderen Zeichen wird es einfach an einen String angeängt (für > ankommende Befehle die ich in der Mainloop dann ausführe). Da ich aber > nach jetzigem Stand mit 254 Befehlen auskommen werde, werde ich das bei > Gelegenheit noch umstellen und die Klartext-Kommandos verwerfen. > > Gruß > Dominique Görsch Hallo Dominique, hallo Bootloader. Ich hätte ein paar Fragen zu diesem Schnipsel, wenn du erlaubst. 1)Habe ich es richtig verstaden, dass du Urcx_isr in der Mainloop bei jedem Programmdurchlauf aufrufst? 2) Wenn du keine Taste drückst, startet der Controller neu. Richtig? 3) Wenn ich nun wollte, dass der Controller bei Tastencode 65 neustartet, wo müsste ich denn das A (65) denn nun eingeben? In das Bascom-Terminal? Damit wäre doch aber der COM Port belegt, über den der Controller anschließend das Programm empfangen könnte. Oder sendest du das Programm auch gleich über das Bascom Terminal? Geht das? Würde mich freuen wenn du, oder jemand mir das erklären könnte(st). Viele Grüße Robertz
Hallo Robertz, 1. Die der RXC Interrupt wird immer dann angesprungen wenn dieser aktiviert ist und ein Zeichen vom Uart empfangen wurde. 2. Die 0xff werden vom PC-Programm gesendet, wenn du das ändern willst dann mußt du das PC Programm anfassen. Dadurch führt der µC einen Reset aus, so braucht keine Reset Taste gedrückt zu werden um in den Bootloader zu kommen. @Peter Ich hab es schon mehrfach geschafft den Bootloader zu killen. In einem Projekt mit dem Tiny2313 verwende ich alle I/O einschließlich Reset. UART ist nicht vorgesehen. Als einzige Möglichkeit einen Reset durchzuführen bleibt IMHO der Power-On Reset. Diesen Erzeuge ich manuell durch anhalten von Batteriehalter Klipsen. Nun kann es halt passieren dass die Spannungsversorgung nicht so ganz auf Anhieb klappt, der Bootloader aber schon am updaten ist, danach ist Sense. Komischerweise ist das Hexfile das ich danach vom µC auslesen kann im Bootloader Bereich korrumpiert. Gibt es hierzu eine einfache Erklärung/Abhilfe? Ich habe mal 2 files angehängt: Bootload.hex --> Bootloader wie ich ihn flashe und auch sehr gut funktioniert BL_def.hex --> µC Inhalt nach fehlgeschlagenem Flashversuch. Das soll in keinster Weise eine Kritik an dem hervorragend funktionierenden Bootloader sein. Leider hat das kleine Projekt mit der Zeit alle I/O`s gefressen, bis auch der Reset Pin weg war.So ist das eigentliche Problem hier zu suchen. Auch die Verbindung mit der Betriebspannung ist etwas tricky da sich der Tiny gern parasitär aus den Bootloaderleitungen versorgt. Am besten funktioniert es wenn ich den Bootloader und VCC verbinde, danach das PC Programm starte und dann erst GND verbinde. Mich wundert es echt dass ich dabei noch keinen µC komplett getötet habe es funktionieren alle noch prima. Auch das bei Fehlschlägen notwendige Auslöten der µC im SOIC20 Gehäuse haben bisher alle überstanden. Grüße Timo
Danke Timo! Ein paar Unklarheiten bleiben noch Timo S. schrieb: > 1. Die der RXC Interrupt wird immer dann angesprungen wenn dieser > aktiviert ist und ein Zeichen vom Uart empfangen wurde. Das funktioniert nicht bei der Software UART von Attinys, oder? Bascom sagt zumindest es sei eine "unknown interrupt source [URXC_ISR]" Gibts also bei Software UART gar keine Lösung, ein Programm zu laden, ohne den Strom abzuklemmen oder einen Reset-Knopf einzubauen? Leider hab ich auch nur einen Pin zur Verfügung und lade das Programm über den deaktivierten RESET-Pin. > 2. Die 0xff werden vom PC-Programm gesendet, wenn du das ändern willst > dann mußt du das PC Programm anfassen. Dadurch führt der µC einen Reset > aus, so braucht keine Reset Taste gedrückt zu werden um in den > Bootloader zu kommen. Welches PC Programm sendet die 0xff (255)? Die cmd.exe, sobald ich fboot /c4 /b9600 /pmain.hex eingebe? Ich müsste also außer dieser Zeile nichts anderes senden, und der Upload würde sofort starten? Viele Grüße Robert
naja die UART Funktion mußt du Dir in Bascom basteln habe keine Ahnung wie das bei Bascom/SoftUART aussieht. Den Reset löst man üblicherweise mit dem Watchdog aus. Man muss dann darauf achten dass der Watchdog sofort bei Programmstart deaktiviert wird! >Welches PC Programm sendet die 0xff (255)? Die cmd.exe, sobald ich fboot >/c4 /b9600 /pmain.hex eingebe? Ich müsste also außer dieser Zeile nichts >anderes senden, und der Upload würde sofort starten? Richtig erkannt aber eigenlich ist es die fboot.exe! Damit ist es sehr komfortabel zu arbeiten. Grüße Timo
Timo S. schrieb: > naja die UART Funktion mußt du Dir in Bascom basteln habe keine Ahnung > wie das bei Bascom/SoftUART aussieht. SoftUART geht ja so Open "comb.3:9600,8,n,1" For Output As #1 Meintestdu das mit SoftUART basteln? Wenn ich aber
1 | On Urxc_isr |
2 | Enable Urxc_isr |
3 | |
4 | Enable Interrupts |
eingebe, kommt beim Syntax-Check die Fehlermeldung "unknown interrupt source [URXC_ISR]" Oder muss ich mir die Urxc_isr auch selbst basteln? Meine Frage ging ja in die Richtung, ob ich es dieses Interrupt bei SoftUART überhaupt gibt, da es ja kein "richtiges" UART ist. > Den Reset löst man üblicherweise mit dem Watchdog aus. Man muss dann > darauf achten dass der Watchdog sofort bei Programmstart deaktiviert > wird! Kann ich den Watchdog nicht einfach erst mit "Start Watchdog" dann starten, sobald 0xff reinkommt? Ist es nicht das, was Dominique macht? Grüße Robert
Öhm ja, im Grunde wurde alles gesagt. Ich nutze Hardware-UART (auf einem ATmega16) und die Funktion "URXC_ISR" ist der UART-Interrupt (ich dachte immer ISR deutet generell auf eine Interruptroutine hin?!?). Das 0xff wird von fboot.exe oder auch anderen hier im Thread verlinkten Updateclients vor dem Verbindungsaufbau gesendet und sorgt in meiner Firmware mittels Watchdog für einen Reset des AVR. So braucht die Zielschaltung keinen Reset-Taster (der bei mir wegen Einbau ohnehin nicht zugänglich wäre). Bisher hatte ich noch keine Zeit dazu, aber die Update-Routinen sollen bei mir in die PC-Software einfliessen, mit der die Zielschaltung (I/O-Interface für ein Mischpult) auch konfiguriert wird. So braucht der Anwender nur eine Software mit der er auch die Firmware updaten kann, wenn ich mal eine neue Version rausbringe. Gruß Dominique Görsch
Ergänzend, nachdem sich das Schreiben der Beiträge überschnitt: Robert Zimmermann schrieb: > Wenn ich aber > >
1 | On Urxc_isr |
2 | > Enable Urxc_isr |
3 | >
|
4 | > Enable Interrupts |
> > eingebe, kommt beim Syntax-Check die Fehlermeldung "unknown interrupt > source [URXC_ISR]" Richtig, nachdem der ATtiny (außer dem ATtiny2313) kein UART hat, hat er natürlich auch keinen Interrupt dafür. >> Den Reset löst man üblicherweise mit dem Watchdog aus. Man muss dann >> darauf achten dass der Watchdog sofort bei Programmstart deaktiviert >> wird! > > Kann ich den Watchdog nicht einfach erst mit "Start Watchdog" dann > starten, sobald 0xff reinkommt? Ist es nicht das, was Dominique macht? Genau das mache ich. Der Watchdog ist vorkonfiguriert auf die kürzeste Wartezeit aber nicht gestartet. Somit führt er quasi direkt nach dem Start (weiß grad ned auswendig wieviel ms er wartet) einen Reset aus.
Hallo Dominique Dominique Görsch schrieb: > Öhm ja, im Grunde wurde alles gesagt. Ich nutze Hardware-UART (auf einem > ATmega16) und die Funktion "URXC_ISR" ist der UART-Interrupt (ich dachte > immer ISR deutet generell auf eine Interruptroutine hin?!?). Da haben sich die Beiträge wieder überschnitten. Daher 1x edit damit es nicht zu verwirrend wird: Dein Programmschnipsel funktioniert also nur mit Hardware UART. Habe ich mit einem kleinen Attiny25 also keine Chance, ohne Strom abklemmen oder Reset-Button ein Programm hochzuladen? Gibts dafür keine Software Variante? Gruß Robert
es funktioniert so: wenn deine Softwareuart ein Zeichen empfangen hat, dann prüft das Programm ob es 0xff ist wenn ja dann reset sonst..... Wie du das konkret in Bascom mit der dort verfügbaren Software Uart umsetzen kannst weiß ich nicht. Wenn du da nicht weiterkommst mach aber am besten einen neuen Thread auf, denn in der Codesammlung hat das nichts zu suchen. Der Thread hier ist schon verwirrend lang genug! Grüße Timo
Hallo Peter, vielen Dank für eines deiner zuverlässigen Programme. Die Software des Bootloaders funktioniert sehr zufriedenstellend. Ich benutze zum kabellosen programmieren das Bluetoothmodul BTM222. Das serielle Signal muss zum programmieren invertiert werden, wenn man kein klassisches RS232 Protokoll benutzt. An welcher Stelle in Deinem Bootloaderprogramm kann ich die Signale RXD und TXD invertieren. Hagen Re hat in seinem Bootloader dafür eine Variable eingebaut. Vielen Dank für Deine Bemühungen pemimu
Ich hab die Umpolung mit dem Eindrahtmodus kombiniert. Es sind diese Macros in der fastload.h:
1 | .macro TXD_0 |
2 | sbi STX_DDR, SRX ; strong pullup = 0 |
3 | .endmacro |
4 | .macro TXD_1 |
5 | cbi STX_DDR, SRX ; weak pullup = 1 |
6 | .endmacro |
7 | .macro SKIP_RXD_0 |
8 | sbis SRX_PIN, SRX ; low = 1 |
9 | .endmacro |
10 | .macro SKIP_RXD_1 |
11 | sbic SRX_PIN, SRX ; high = 0 |
12 | .endmacro |
Peter
Hallo Peter, vielen Dank für Deine Hilfe. Werde es gleich mal ausprobieren. Respekt für Deine Mühen und Deine Zeit, die Du hier im Forum rein steckst und dadurch vielen bei ihren kleineren Problemen hilfst. Eine besinnliche Weihnachtszeit wünscht Dir ein Fan Deiner eingestellten und zuverlässigen Codes :-) Nochmals vielen Dank dafür. pemimu
Hallo Peter, Sorry das ich noch mal stören muß. Ich habe Deinen Code folgendermaßen abgeändert. .macro TXD_0 cbi STX_DDR, SRX ; strong pullup = 0 .endmacro .macro TXD_1 sbi STX_DDR, SRX ; weak pullup = 1 .endmacro .macro SKIP_RXD_0 sbic SRX_PIN, SRX ; low = 1 .endmacro .macro SKIP_RXD_1 sbis SRX_PIN, SRX ; high = 0 .endmacro Nach dem Starten des Flashers fboot.exe und dem Resetten des Chips wird versucht, eine Kommunikation aufzubauen. (ich vermute mal, das das innerhalb der BootDelay – Zeit ist)Ich habe einen mal einen Oszzi am Onewirepin angeschlossen. Nach kurzer Zeit wird dieser Pin auf High durch den Chip gezogen während der Flasher weiterin versucht, eine Verbindung auf zu bauen. Gemessen jeweils an den Anschlüssen des R2 Widerstands. Irgendwo in der Routiene müßte noch was umgestellt werden. Könntest Du mir nochmal helfen? Vielen Dank dafür. pemimu
Thread beobachten
Seitenaufteilung abschalten
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.