Ich hab jetzt mal den Bootloader für die kleinen AVRs umgeschrieben. Er benötigt nur noch 450 Byte. Man kann ihn also ab dem ATtiny13 verwenden. Es wird keinerlei Peripherie verwendet (Timer, UART), dadurch ist er sehr leicht auf andere AVRs anpaßbar bzw. die Programmierpins sind frei wählbar. Man kann also auch den Resetpin nutzen und hat damit alle 6 IO-Pins verfügbar. Nur die Fuses sind dann nicht mehr änderbar (ohne STK500). Die Baudratenerkennung ist jetzt verbessert: Bei USB-UART Konvertern sind die Bitzeiten nicht exakt gleich, sondern haben einen Jitter. Damit funktionierte die Erkennung bei kleinen Baudraten nicht mehr richtig, sondern nur auf PCs mit echter UART. Das Hauptproblem war der fehlende Bootvektor. Die ATtinys fangen beim Reset immer bei 0x0000 an. Um nun trotzdem immer den Bootloader zu starten und ein Totflashen zu verhindern, wird an 0x0000 ein Sprung zum Bootloader eingetragen. Der eigentliche Sprung zur Applikation wird dann in das letzte Wort vor dem Bootloader programmiert. Dazu ist es notwendig, daß die Applikation immer mit einem RJMP beginnt. Und das ist ja in C immer der Fall bzw. in Assembler leicht zu machen. Sonst gibt es keinerlei Einschränkungen für die Applikation. Damit auch bei Unterbrechung des Downloads der Bootloader nicht unerreichbar wird, wird das Erase von der obersten Page abwärts durchgeführt. D.h. der Sprung zum Bootloader wird als letztes gelöscht und als erstes wieder programmiert. Selbst bei einem Reset genau dazwischen kann nichts passieren, da dann alles 0xFFFF ist und einfach wie ein NOP durchlaufen wird. Das EEPROM schreiben und ein CRC-Test wird noch nicht unterstützt. Geplant ist auch Halb-Duplex (nur ein IO-Pin). Man muß also nicht mehr mindestens den ATMega8 benutzen, um die Bequemlichkeit eines Bootloaders zu haben. Peter
Wie es scheint, hat noch keiner den Code ausprobiert. Es waren noch 2 Bugs drin, nun läufts. 3646 Byte auf den ATtiny45 zu laden, dauert etwa 5s bei 115200Baud mit USB-RS232-Adapter. Peter
So, ich hab jetzt mal mein STK500 gequält und alle meine AVRs gebootloadet. Der Bootloader ist so gut, daß ich meinen alten ATmega Bootloader entsorgt habe und sauschnell ist er außerdem. Die Brennzeiten liegen von 1s (ATtiny13) ... 8s (ATmega644). Folgende AVRs sind getestet: ATtiny13 ATtiny2313 ATtiny45 ATmega8 ATmega16 ATmega162 ATmega168 ATmega32 ATmega323 ATmega644 Anbei der komplette Quellcode und die fertigen HEX-Files. Die xxDEF.INC Files muß man sich aus der AVRStudio Installation nehmen. Die Programmierpins sind frei wählbar. In den Macros für die Programmierpins kann man auch die Polarität umdrehen, wenn man nen Spar RS232-Anschluß ohne MAX232 nehmen will (Widerstand vor den RX-Pin). Die PIC-Leute machen das ja besonders gerne. Für zerschossene Pins übernehme ich natürlich keinerlei Haftung. Die MAX232 sind ja speziell auf hohe ESD-Festigkeit ausgelegt. Wie man sieht, sind nur sehr wenige Anpassungen an die verschiedenen AVRs nötig. Es sind nur 2 verschiedene Programmierroutinen nötig, eine für AVRs mit BootStartFuses und eine für AVRs ohne. Um also Bootloader für ATtiny84, ATtiny85 und ATmega48 zu erzeugen, nimmt man die gleiche Konfiguration, wie für den ATtiny45. Peter
Hört sich super an. Schade dass ich in den nächsten Wochen keine Zeit habe ihn auszuprobieren. Ist das übertragungsprotokoll kompatibel zur alten Version?
Hallo Peter, es funktioniert! Und wie! Ich habe, wie Du es beschrieben hast, die Datei T45.asm so geändert, das die Datei m48def.inc für den ATmega48 "includiert" wird und die entsprechenden Port definitions angepasst. Nach einer Fehlermeldung von AVR-Studio, dass es mit "SPMEN" nichts anfangen kann, habe ich den entsprechenden Eintrag in der m48def.inc rausgesucht (dort heißt es "SELFPRGEN") und ebenfalls abgeändert. Nachdem ich nicht wusste, welche Paramter ich in der Kommandozeile hinter "tboot" eingeben muss, habe ich ein bisschen rumprobiert und herausgefunden, dass ich nach "tboot" ein "-p" direkt gefolgt von der zu flashenden Datei, also ohne Leerzeichen, eingeben muss. Hast Du die Parameter eigentlich irgendwo beschrieben? Wenn ja wo? Noch eine Kleinigkeit: Als Comport ist COM1 fest eingestellt. Ist es möglich, den Comport ebenfalls als Parameter mit tboot.exe aufzurufen? Besten Danke für diesen universell einsetzbaren und sehr kleinen Bootloader! ciao Michael
Hallo Peter, Eine Frage: Mit welchem Compiler hast du das PC-Programm erstellt? Bzw. könntest du den Mega64 und den Mega128 auch noch mitaufnehmen? :) Danke!
Der Techniker wrote: > Eine Frage: Mit welchem Compiler hast du das PC-Programm erstellt? Borland C++ 3.0 als DOS-Programm, Model: Compact. > Bzw. könntest du den Mega64 und den Mega128 auch noch mitaufnehmen? Den Mega64 kannst Du ganz leicht aus dem Mega644 entlehnen. Der Mega128 bräuchte einige kleine Änderungen: - Auswertung des Segmentrecords im PC-Programm - ELPM, RAMPZ im Bootloader Ich hab allerdings keinen Mega128 zum Testen, so groß wurden meine Programme bisher nicht. Da das Topic etwas unglücklich gewählt ist (nur Tiny45 stimmt ja nicht), habe ich hier weiter gemacht: Beitrag "UART Bootloader ATtiny13 - ATmega644" Peter
Hallo Forum, zur Zeit versuche ich krampfhaft mit Peters Bootlader einen tiny zu flashen. Wie man ersehen kann, funktioniert die Kommunikation zwischen PC und MC schon mal, von daher keine Probleme, abgesehen vielleicht von der Baudrate. Um es kurz zu machen, hier mal meine Vorgehensweise beim Programmanpassen: Programmkopf: .nolist .include "tn2313def.inc" .list ;*** Konstanten *** .equ bootstart = 0x0310 ;Bootlader-Adresse .equ application = bootstart-2 ;Sprung zum Programm .equ cpu_takt = 8000000 ;CPU-Takt=8 MHz ohne Prescaler . . . ; .CSEG .org application ;Sprung zum Programm unterhalb des Bootladers rjmp main ;*** Interrupttabelle *** .org 0 rjmp bootstart ;Sprung zum Bootlader reti ;INT0, externer Interrupt für Flankensteuerung . . . Fehlermeldungen beim Flashversuch: COM 1 at 115200 Baud: connected Bootloader VFFFFFFFF.FF Target: FFFFFFFE.FF E:\..... Buffer: -2 Byte Error, wrong device informations gehe ich mit der Baudrate runter: COM 1 at 19200 Baud: connected Bootloader V2.1 Target: FE910A E:\..... Size available: 1566 Byte Programm chiptest.hex: 00000 - 00040 failed! Programm-Error Nun sitze ich ziemlich ratlos hier und weiß nicht weiter. Stimmen meine Einträge im Programm überhaupt? Ich gehe mal davon aus, daß der Bootlader nach dem Flashen an einer bestimmten Stelle die Einsprungadresse aufruft. Mein Problem ist nun, wie trage ich diese wo ein. Beim Debuggen hat er sich in der Baudratenerkennung festgerödelt, darum konnte ich dies nicht rausfinden. Beim Nachvollziehen des Listings habe ich immer wieder den Faden verloren und schließlich aufgegeben. Ich hoffe, mir kann geholfen werden. Danke. mfg Roger
hallo Peter, mit dieser Antwort kann ich leider nichts anfangen. Diesen und auch deinen angegebenen Link habe ich durchgeackert, aber nichts konkretes über die Einsprungadresse zum und sonstige Einträge im eigenen Programm gefunden. Übrigens, diese Version versuche ich ja auch zu benutzen. mfg birder
Roger Xxx wrote:
> Programm chiptest.hex: 00000 - 00040 failed!
Du mußt natürlich die SELFPRGEN-Fuse enablen.
Peter
Diese Fuse habe ich auch gesetzt. Die Verbindung zum Bootlader ist mir klar und was ich dafür wo einstellen muß. Mir geht um die Verbindung zum Programm. Wie muß ich diese bewerkstelligen. Wird sie als rjmp Adresse, so wie ich es in meinem Programm eingetragen habe, oder nur als Adresse ohne rjmp und vor allem wo genau, im Ram oder im Flash eintragen dies konnte ich bisher nirgens herausfinden. Dies ist auch nicht aus der PDF-Hilfe zu ersehen. Es ist zwar genau beschrieben, was ich wo eintragen muß, um den Bootlader im AVR lauffähig zu machen, aber nicht, was ich in meinem Programm ändern oder sonst noch eintragen muß außer an Adresse 0 (in meinem Fall Tiny2313) einen Sprung zum Bootlader. Stimmt den mein Eintrag überhaupt? .equ application = bootstart-2 ;Sprung zum Programm bootstart ist der Einsprung zum Bootlader. Da er im Flash steht und dieser in Worten organisiert ist, bin ich mir nicht sicher, ob es so richtig ist. Am besten wäre ein Programmschnipsel, wo ich dies genau ersehen könnte. Ich gehe mal davon aus, daß mein Bootlader korrekt installiert ist und die Fuses richtig eingestellt sind. Ansonsten kann ich dies ja nachlesen, das sollte nicht so das Problem sein. Ich bin durch die völlig unterschiedlichen Fehlermeldungen bei unterschiedlichen Baudraten total durcheinander und weiß überhaupt nix mehr. mfg birder
noch ein Nachsatz. Deine Formulierung im ersten Thread: "... Der eigentliche Sprung zur Applikation wird dann in das letzte Wort vor dem Bootloader programmiert. Dazu ist es notwendig, daß die Applikation immer mit einem RJMP beginnt. ..." ist mir zu ungenau. Das ist mein Problem. Wie meinst du das genau? mfg birder
Roger Xxx wrote: > noch ein Nachsatz. > Deine Formulierung im ersten Thread: > > "... > Der eigentliche Sprung zur Applikation wird dann in das letzte Wort vor > dem Bootloader programmiert. > Dazu ist es notwendig, daß die Applikation immer mit einem RJMP beginnt. > ..." > > ist mir zu ungenau. Das ist mein Problem. Wie meinst du das genau? Genau das, was da steht: Der erste Befehl in Deiner Applikation muß ein RJMP sein. Mit welchem Takt läuft dennn Dein AVR? Bei 8MHz sollten 19200 Baud eigentlich klappen. Peter
Hallo Peter, alles klar, ich habe das Problem gelöst. Bin mit der Baudrate noch weiter runter und bei 9600 hat es geklappt. Ich arbeite mit W2k und dieses scheint mit der Übertragung so seine Probleme zu haben. Danke für die Unterstützung. mfg birder
Roger Xxx wrote: > alles klar, ich habe das Problem gelöst. Bin mit der Baudrate noch > weiter runter und bei 9600 hat es geklappt. Könnte es sein, daß Du noch die Werkseinstellung (1MHz) benutzt? Peter
Hallo Peter, habe mir eben die Fusebits nochmal angesehen. Der Proz. ist ein tiny2313, der von einem 8.0MHz-Quarz getaktet wird. gesetzt sind: SELFPREN BOLEVEL disabled Ext.Cryst.Osz.3.0-8.0 MHz Start-up time 14 CK+65ms Es scheint ein Windowsproblem zu sein, aber damit kann ich leben. Ob die Flashzeit nun 0,3s oder 20s sek dauert, ist mir vollkommen wurscht, hauptsache, ich kann die Pins für die Übertragung frei wählen. Manchmal ist es vom Layout her am besten so. mfg birder
Hier noch eine Bemerkung, um ein Programm zu testen, lasse ich manchmal einige Werte während des Programmlauf süber HyperTerminal auf den PC ausgeben. Dazu habe ich mir einen Adapter gebaut. Da habe ich mit 115 KBaud keine Probleme. Zur Kommunikation habe ich eine ganz normale UART-Routine eingebunden. Vielleicht ist das ja ein Denkansatz, soll aber um gotteswillen keine Kritik sein. mfg birder
Angehängte Dateien:
-
pict0001.jpg
120 KB
ups, wollte mal ein Bild von besagtem Adapter zulegen. Mit diesem flashe ich übrigens auch mit dem Bootlader. mfg birder
Roger Xxx wrote: > BOLEVEL disabled > Ext.Cryst.Osz.3.0-8.0 MHz Start-up time 14 CK+65ms Würde ich nicht machen. Kann sein, daß der Quarz instabil anschwingt und durch die niedrigere Baudrate hat er mehr Zeit zum stabilisieren. Brownout sollte man immer einschalten. Und bei 8MHz würde ich die Einstellung ab 8MHz- benutzen, da ist die Schwingschaltung stabiler. > Es scheint ein Windowsproblem zu sein, aber damit kann ich leben. Glaube ich nicht. Peter
Hallo Peter, danke dir, hast recht, es hat was gebracht.Jetzt habe ich eine stabile Verbindung bis 57 kBaud. BODLEVEL 4,3V habe ich sonst eigentlich immer eingeschaltet, aber in diesem Fall habe ich es weggelassen, weil ich in der Vergangenheit mal Probleme damit hatte und auf diese wollte ich verzichten. Bei den 8.0- MHz dachte ich, dies gilt nur für Quarze oberhalb von 8MHz, aber da steht ja auch 8.0 bis..., also ab 8MHz. Hätte es ja auch mal ausprobieren können. mfg birder
Hallo Forum, habe es bisher geschafft, mit dem Bootlader ein Programm zu laden, aber es dabei belassen, weil ich noch mit was anderem beschäftigt war. Jetzt wollte ich weitermachen und mußte feststellen, daß das Programm überhauptnicht läuft. Dies liegt sicherlich an der Adressierung. Der Sprung zum Programm wird bei Startadresse Bootlader-2 eingetragen, ist soweit klar, aber wie ermittle ich die Adresse des Bootladers? Beim Debuggen des Ladercodes habe ich 0x0310 ermittelt, aber dies kann offensichtlich nicht stimmen. Wie kann ich dieses Problem lösen? Was trage ich im Programm ein außer dem rjmp bootlader in der Interrupttabelle? mfg birder
Roger Xxx wrote: > Beim > Debuggen des Ladercodes habe ich 0x0310 ermittelt, aber dies kann > offensichtlich nicht stimmen. Wozu willst Du die wissen, die geht Dich garnichts an. Schreib einfach Deine Applikation mit nem RJMP zu Deinem Init-Code. > Wie kann ich dieses Problem lösen? Was trage ich im Programm ein außer > dem rjmp bootlader in der Interrupttabelle? Mache in Deinem Programm alles, wozu Du lustig bist, aber auf keinen Fall einen Sprung in den Bootloader. Pfusch dem Bootloader nicht ins Handwerk, dann klappt das auch. Peter
Hallo Peter, aha, verstehe, der Bootlader kümmert sich um die entsprechenden Eintragungen selbst. Ich habe mit Formulierungen, wie du sie am Anfang benutzt hast, so meine Schwierigkeiten: "Um nun trotzdem immer den Bootloader zu starten und ein Totflashen zu verhindern, wird an 0x0000 ein Sprung zum Bootloader eingetragen. Der eigentliche Sprung zur Applikation wird dann in das letzte Wort vor dem Bootloader programmiert. Dazu ist es notwendig, daß die Applikation immer mit einem RJMP beginnt." Dies hatte ich so verstanden, als wenn ich mich selbst drum kümmern müßte. Das vereinfacht die Sache ja ungemein. Hätte es ja auch ausprobieren können, aber ich war so damit beschäftigt den Bootlader zum Laden zu bewegen, daß mir garnicht in den Sinn gekommen ist, mal auszuprobieren, ob das geladene Programm auch läuft. Nun ist alles klar. Danke, tolles Teil. mfg birder
Hallo Forum Ich habe gerade eine riesen Verwirrung. Nachdem ich mit PeDa´s fboot21 einen Attiny13 mit Applikation gefüttert habe ist diese nicht wie ich es vom Atmega8 gewohnt bin angesprungen. Zum Starten braucht es einen Reset! Mit PonyProg kann ich folgendes feststellen: Der in der Version 21 enhaltene und auf den AtTiny13 angepasste Loader fängt bei Adresse 0x220 an. Meine Applikation (LED blinken), mit PonyProg geflasht geht bis 0x07D. Wenn ich mit PonyProg den Loader flashe und dann mit dem Loader die Applikation lade, würde ich erwarten, dass der Bereich von 0x07D bis 0x21F mit 0xFF gefüllt ist. Mit PonyProg ausgelesen sehe ich aber dass der Inhalt der Adressen 0x060 bis 0x07F in diesen Bereich kopiert ist (13 mal). Am Attiny habe ich das Fusebit SELFPRGEN gesetzt. Als Änderung im Loader habe ich nur den Include .include "tn13def.inc" scharf gemacht, die Programmierpins auf PB4 gelegt (OneWire) und .equ XTAL=9600000 auf 9,6MHz gesetzt. - Was habe ich da übersehen? Ersetzt fboot21 die Versionen fastboot_V14 und tinyload3?
Kurt wrote: > Hallo Forum > Ich habe gerade eine riesen Verwirrung. Nachdem ich mit PeDa´s fboot21 > einen Attiny13 mit Applikation gefüttert habe ist diese nicht wie ich es > vom Atmega8 gewohnt bin angesprungen. Zum Starten braucht es einen > Reset! Kann sein, daß fboot zu schnell terminiert, d.h. das Start-Kommando ist noch im UART-Puffer und wird nicht mehr gesendet. Schreib das "fboot" in ne Batch und dahinter "pause", dann bleibt die DOS-Box offen und die UART kann alles senden. > dass der Bereich von 0x07D bis 0x21F mit 0xFF gefüllt ist. Mit PonyProg > ausgelesen sehe ich aber dass der Inhalt der Adressen 0x060 bis 0x07F in > diesen Bereich kopiert ist (13 mal). Ja, das ist korrekt. Um den Programmieralgorithmus einfach zu halten, wird immer der gesamte User-Flash programmiert. Es sollte ja egal sein, was in dem ungenutzten Flash steht. Peter
Hallo, ich habe den Bootloader (endlich mal...) eingesetzt, und alle möglichen Varianten durchprobiert (two-wire, one-wire) um das Linux-Programm zum laufen zu bringen. Der Bootloader ist super, machte von Anfang an was er sollte. Das Linux-Programm von Andreas Butti habe ich etwas umgestrickt u.a. konnte es den one-wire Mode nicht. Bei der ganzen Testerei ist mir aufgefallen, daß ich im one-wire Mode auch eine untere Grenze habe. So geht ein Atmega 32 mit 16MHz bei one-wire sicher zwischen 38400 Baud und 230400 Baud, manchmal mit 19200 Baud, mit 9600 Baud nie. Ich habe gemerkt, daß es etwas mit der Größe des Pullups an der AVR-Seite zusammenhängt (ich benutze Peters Schaltung mit den 2 Dioden und 2 Widerständen). Wenn der Pull-up auf 10kOhm ist funktioniert 19200 Baud nie, mit 4,7kOhm meistens....ich habe den Pull-up direkt am AVR, den Rest der Schaltung am V24 Stecker, dazwischen ca. 1,5m Kabel. Im übrigen funktioniert die Autobaud auch hier, er meldet den connect, und beim lesen der Infos gibts dann bei den Antworten Müll, d.h. es werden vom PC falsche Zeichen empfangen. Ich könnte mir einiges erklären, wenn es mit hohen Geschwindigkeiten Probleme gibt, aber mit niedrigen? Mit two-wire läuft die Übertragung auch mit 1200 Baud immer problemlos... Gibts dafür eine Erklärung? Gruß, Bernhard
Hallo PeDa Vielen Dank für deine schnelle Antwort. Ich habe jetzt die Pause in meine Batchdatei reingemacht, brachte aber nichts. Ich habe nun meine Applikation erweitert - sie ist jetzt 0x215 Bytes groß - und siehe da, auch ohne Pause im Batch, springt sie sofort nach dem Flashen an. Gibt es da eine Erklärung? Und jetzt der Ornung halber nochmal die Frage: wenn fboot21 funktioniert, kann ich meine gesammelten Werke fastboot_V14 und tinyload3 einstampfen? Nochmals vielen Dank für deine Geduld und Mühe.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.