Forum: Projekte & Code ATtiny45 Bootloader


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

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

von Bernd T. (bastelmensch)


Lesenswert?

Hört sich gut an.

von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

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

von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

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

von Malte _. (malte) Benutzerseite


Lesenswert?

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?

von Michael S. (keil)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

@Michael

tboot -?

Verify und EEPROM wird (noch) nicht unterstützt.


Peter

von Der T. (Gast)


Lesenswert?

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!

von Peter D. (peda)


Lesenswert?

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

von Roger K. (birder)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

Nimm die aktuelle Version 2.1.:

Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"


Peter

von Roger K. (birder)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

Roger Xxx wrote:

> Programm chiptest.hex: 00000 - 00040 failed!

Du mußt natürlich die SELFPRGEN-Fuse enablen.


Peter

von Roger K. (birder)


Lesenswert?

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

von Roger K. (birder)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Roger K. (birder)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Roger K. (birder)


Lesenswert?

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

von Roger K. (birder)


Lesenswert?

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

von Roger K. (birder)


Angehängte Dateien:

Lesenswert?

ups, wollte mal ein Bild von besagtem Adapter zulegen. Mit diesem flashe 
ich übrigens auch mit dem Bootlader.

mfg birder

von Peter D. (peda)


Lesenswert?

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

von Roger K. (birder)


Lesenswert?

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

von Roger K. (birder)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Roger K. (birder)


Lesenswert?

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

von Kurt (Gast)


Lesenswert?

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?

von Peter D. (peda)


Lesenswert?

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

von Bernhard M. (boregard)


Lesenswert?

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

von Kurt (Gast)


Lesenswert?

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.

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
Noch kein Account? Hier anmelden.