UART Bootloader ATtiny13 - ATmega644

Hallo Peter,

eine Frage: Was genau bedeutet die "BufferSize", bzw. was meinst Du mit 
"Attention: BufferSize must fit perfectly into BootStart!"?
Beim ATmega8 z.B. ist BufferSize = 15*PageSize = 15*32 = 480 = 0x1E0 
(warum dieser Wert?).
Beim ATmega168: BufferSize = 4*PageSize = 4*64 = 256 = 0x100
Ich Frage, da ich den Bootloader mit einem ATmega88 verwende, der eine 
PageSize von 32 hat. Ergo müsste ich bei BufferSize "8*PageSize" bei 
Verwendung der BOOTSTART-Adresse 0x0F00 eintragen, oder? Meine 
Feststellung ist nämlich, dass jeder Multiplikator zwischen 2 und 12 
funktioniert (weiter hab ich´s nicht getestet). Ich wäre Dir für eine 
kurze Erklärung sehr dankbar!

ciao Michael

Windows mag es nicht, wenn man immer nur ein Byte über die UART sendet.
Man sollte also möglichst große Blöcke senden, dann geht es wesentlich 
schneller.
Daher richte ich im SRAM einen Puffer ein und sage der PC-Software, wie 
groß dieser Puffer ist.
Diese Puffergröße muß natürlich ein Vielfaches der Pagegröße sein.

Um den Bootloader klein zu halten, programmiert er immer komplette 
Puffer. Daher muß die Puffergröße exakt, d.h. ohne Rest in den 
Userbereich passen.
Oder anders gesagt: n * Puffergröße = Bootstart.


Peter

Hallo Andreas,

wie Peter schon schrieb, die Programmierpins sind frei wählbar, da die 
serielle Schnittstelle als Softwarelösung implementiert ist.
Die Konfiguration der beiden Pins kannst Du in dem Deinem 
Mikrocontroller entsprechenden *.asm-File abändern und dann mit z.B. 
AVR-Studio das Hex-File für den Controller erzeugen.
Auf dem Weg nochmal Danke Peter für Deine Antwort. Jetzt habe ich 
verstanden dass Du mit Bootstart die Bootstart-Adresse meinst.

ciao Michael

Hallo Peter,

super Teil dein Bootloader.
Hab ihn gerade auf ATMega64 und RS-485 Schnittstelle angepasst und er 
läuft!
Jetzt muss ich nur noch das PC-Programm auf Dev-C++ portieren, da ich 
kein Borland C++ habe.

Vielen Dank
andie.

Andreas wrote:

> Kannst Du evtl. für die Noobs (wie ich  ;-)  ) ein paar Zeilen zum
> Einstieg schreiben, welche Pins jetzt benutzt werden, wie und wo man
> diese ändert, wie das Programmieren funktioniert usw. Also eine _kurze_
> Anleitung?


Die Pins können in folgenden Zeilen geändert werden

1

; Sendepin:

2

.equ    STX_PORT        = PORTB

3

.equ    STX_DDR         = DDRB

4

.equ    STX             = PB1

5

;Empfangspin:

6

.equ    SRX_PIN         = PINB

7

.equ    SRX_PORT        = PORTB

8

.equ    SRX             = PB0

Peter

Richard wrote:
> Kann mir einer verraten wie ich den sourcecode kopilieren kann?
>
> Habe es mit AVR Studio versucht ... kriege es aber leider nicht hin :-(

Du öffnest die Datei, die Du assemblieren willst, z.B. t13.asm.
Die anderen (*.inc, *.h) müssen sich im gleichen Verzeichnis befinden.


Peter

Uwe wrote:
> Sehe ich das richtig, dass AVRs mit mehr als 64k Flash (z. B. ATm128)
> nicht unterstützt werden?

Ja, der ATMega644 ist mein größter, größere habe ich nicht.

Hab ihn aber auch nur aus Interesse gekauft, weiß noch nicht, womit ich 
ihn vollkriegen kann.


Peter

Uwe wrote:
> Ist es viel Aufwand, den ATM128 noch mit einzubauen?

Im Prinzip nicht.

Die meisten Änderungen sind am PC Programm.
Ich müßte mir ansehen, wie ein Segmentrecord funktioniert (bisher 
ignoriere ich ihn) und alle Pointer, Adreßzähler auf long umstellen und 
ein farmemset selber schreiben.

Auf dem AVR muß ich RAMPZ mitzählen und ESPM, ELPM benutzen, sollte max 
10 Worte kosten.

Ich kanns aber nicht testen.


Peter

1

FBOOT.EXE /PC:\AVR_PR~1\LED_mega32.hex

so vielleicht?

Diese DOS-Anwendung kann leider keine langen Pfad- und Dateinamen (max 
8.3).


Peter

LED_mega32.hex

der dateiname ist immer noch 10 buchstaben lang ;)

Stimmt!

1

BOOT.EXE /PLED_me~1.hex

PS: Dann war obige Antwort auch nicht richtig. Da ist nur der Pfadname 
korrekt, der Dateiname aber immernoch zu lang.

Richard wrote:
> Asoo, Dateiname ... ich dachte Pfad^^. Danke jetzt geht es.

Beides.

Richard wrote:

> Muss ich irgendwas an den Security bits umstellen?

Die Fuses: firstboot und boot reset

sonst kann er ja den Bootloader nicht finden.

Bei nem leeren MC rauscht er durch die 0xFFFF durch bis zum Bootloader.


Peter

Gasti wrote:

> Vielleicht habe ich aber auf das ganze noch nicht richtig durchschaut.

Stimmt

Auf das SKIP folgt kein RJMP, d.h. auch bei einem Timeout wird nicht 
mehr zum Schleifenanfang gesprungen.


Peter

Hat jemand von euch schon das FBoot Programm von Peter auf Dev-C++ 
portiert?

Habe keine inportb() und outportb() Funktionen zur Verfügung.
Würde mich über jede Hilfe freuen.

andie.

Ich hab das ganze gerade auf VC++ umgeschrieben, da ich das ganze an 
einem USB-RS232 Wandler betreibe. Im Prinzip muss man nur noch einige 
casts hinzufügen und die seriellen Schnittstellenroutinen ändern.

Hat jemand eine Idee wie man den Bootloader starten könnte, wenn es 
keinen Reset Knopf gibt, der AVR über USB versorgt wird, und ebenso der 
FT232, der COM-Port also nicht vor dem Einschalten des AVRs geöffnet 
sein kann ?

Im controller eine resetfunktion implementieren?
Also, irgend ein zeichen bzw steuercode über rs232 der dann den watchdog 
einschaltet und wartet?

Benedikt K. wrote:

> Hat jemand eine Idee wie man den Bootloader starten könnte, wenn es
> keinen Reset Knopf gibt, der AVR über USB versorgt wird, und ebenso der
> FT232, der COM-Port also nicht vor dem Einschalten des AVRs geöffnet
> sein kann ?

Nimmste eben eins von den Handshakesignalen (RTS, DTR) und knallst es an 
den Resetpin.

Und im PC-Programm wird es dann kurz gepulst.


Peter

Stefan wrote:

> Ist denn auch eine Halb-Duplex-Kommunikation auf einem Pin
> konfigurierbar ?
> Gerade auf den 8-Pin-Prozessoren wäre das ungemein hilfreich... dafür
> würde ich gern auch noch ein wenig Speicher opfern; denn da ist man bei
> den neuen Tinys ja recht flexibel :)

Ist gerade in Arbeit, anbei schonmal der Schaltplan.
Die Dioden sind nur zum Schutz, wer Lust hat, kanns auch ohne probieren.

6 IO-Pins zu haben und trotzdem neu brennen zu können (ohne Fuses !), 
hat schon was.

Es sieht auch ganz gut aus, fehlt noch der Feinschliff.

Die Prolific-Dongle haben das viele RX-Traffic nicht ausgehalten und 
Bytes verschluckt und vertauscht (!), wenn einige Bytes 0x13 waren.
Ich bin fast verrückt geworden beim Debuggen.

Bis ich dann den FTDI benutzt habe, da lief alles.

Dann habe ich den neuen Profilic-Treiber installiert und dann gings 
auch.
Der Treiber muß von 2005 sein (der alte war von 2003).
Allerdings sinkt die Downloadrate auf 25%, wenn die Bytes 0x13 sind.


Für das 1-wire mußte ich auch noch das Protokoll etwas umstellen.
Ich muß mal das 2-wire überprüfen, ob das noch geht.

Die PC-Software erkennt den Modus automatisch und schmeißt dann alle 
Echos weg, so daß nur die echten Antworten übrig bleiben.

Damit die Paßworterkennung funktioniert, sendet der PC noch ein 0xFF 
dahinter und der AVR wartet auf das Starbit und hängt das Antwortbyte 
daran an.
Falls das fehlschlägt, macht es der AVR immer wieder, daher sollte das 
Paßwort eine gerade Anzahl Zeichen haben.

Daß das Zeichen 'a' im Paßwort vorkommen muß, hat vielleicht schon 
jemand gemerkt.
Die Baudratenerkennung akzeptiert nur bestimmte Zeichen, um eine 
Fehlerkennung (doppelte Bitzeit) zu vermeiden.


Peter

Ich habe hier ein ATMega 48 und möchte gerne den Bootloader zum laufen 
kriegen, habe daher die Ports und Includes angepasst (ich hoffe mal 
richtig, habe noch nie mit Assembler gearbeitet):

1

;*************************************************************************

2

;*                   *

3

;*        ATmega8 Bootloader       *

4

;*                                                                       *

5

;*                      Author: Peter Dannegger                          *

6

;*                   *

7

;*************************************************************************

8

.nolist

9

.include "m48def.inc"

10

11

12

;please burn this BootStart Fuse:

13

14

.equ  BootStart  = SecondBootStart

15

16

17

;Attention: BufferSize must fit perfectly into BootStart !

18

;e.g. BufferSize * 8 = BootStart

19

20

.equ  BufferSize  = (15*PageSize)

21

22

;-------------------------------------------------------------------------

23

;                               Port definitions

24

;-------------------------------------------------------------------------

25

.equ    STX_PORT        = PORTD

26

.equ    STX_DDR         = DDRD

27

.equ    STX             = PD0

28

29

.equ    SRX_PIN         = PIND

30

.equ    SRX_PORT        = PORTD

31

.equ    SRX             = PD1

32

;-------------------------------------------------------------------------

33

.include "fastload.inc"

34

;-------------------------------------------------------------------------

Und kriege dann beim kompilieren folgende Fehler:

1

AVRASM: AVR macro assembler 2.1.2 (build 99 Nov  4 2005 09:35:05)

2

Copyright (C) 1995-2005 ATMEL Corporation

3

4

C:\avr\bootloader\bootloader.asm(9): Including file 'C:\Programme\Atmel\AVR Tools\AvrAssembler2\Appnotes\m48def.inc'

5

C:\avr\bootloader\bootloader.asm(14): warning: Use of undefined or forward referenced symbol 'SecondBootStart' in .equ/.set

6

C:\avr\bootloader\bootloader.asm(33): Including file 'C:\avr\bootloader\fastload.inc'

7

C:\avr\bootloader\fastload.inc(9): Including file 'C:\avr\bootloader\compat.h'

8

C:\avr\bootloader\fastload.inc(10): Including file 'C:\avr\bootloader\fastload.h'

9

C:\avr\bootloader\fastload.inc(21): error: Overlap in .cseg: addr=0x0 conflicts with 0x0:0x1

10

C:\avr\bootloader\bootloader.asm(33): info: 'C:\avr\bootloader\fastload.inc' included from here

11

C:\avr\bootloader\fastload.inc(38): Including file 'C:\avr\bootloader\abaud.inc'

12

C:\avr\bootloader\fastload.inc(39): Including file 'C:\avr\bootloader\password.inc'

13

C:\avr\bootloader\fastload.inc(83): Including file 'C:\avr\bootloader\checkcrc.inc'

14

C:\avr\bootloader\fastload.inc(90): Including file 'C:\avr\bootloader\verify.inc'

15

C:\avr\bootloader\fastload.inc(101): Including file 'C:\avr\bootloader\message.inc'

16

C:\avr\bootloader\fastload.inc(104): Including file 'C:\avr\bootloader\progmega.inc'

17

C:\avr\bootloader\fastload.inc(110): Including file 'C:\avr\bootloader\uartcrc.inc'

18

C:\avr\bootloader\bootloader.asm(35): warning: end of .dseg at 0x4c0 is beyond end of memory at 0x2ff

19

20

Assembly failed, 1 errors, 2 warnings

Und wenn ich sowieso schon schreibe, hat jemand den Bootloader für Linux 
auf den aktuellen Stand gebracht? (war ja im vorhergehenden Thread mal 
dabei).

Danke.

mfg Andreas

Der ATmega48 gehört bezüglich Bootfunktion zu den ATtinys.

Daher gibts kein Secondbootstart.

Nimm daher das T45.ASM als Vorlage.


Peter

Ok, Danke!
Der Bootloader ist drauf, nur wartet der unendlich lange?
Ich konnte mein Programm aufspielen, aber es wurde nicht gestartet. 
Selbst wenn ich über eine Minute warte kann ich immer noch das Flash 
bespielen. Wie muss ich mein Programm starten, bzw. wenn wird es 
gestartet? (da ich den vorherigen Thread auch gelesen habe gehe ich mal 
davon aus das dein Bootloader auf 0x00 eine rjmp zur Adresse in der der 
Bootloader ist geschrieben hat, und dann von dort auf zurück auf 0x01 
springt wo das Programm beginnt, oder so ähnlich?)


Wie schon genannt, ATMega 8, und ich kann immer noch kein Assembler;-)

mfg Andreas

Die Applikation startet, sobald das PC-Programm fertig ist bzw. etwa 
0,3s nach einem Reset.

Bei den AVRs ohne Bootstartfuses muß der erste Befehl ein RJMP sein, 
sonst geht es nicht.

Und die Applikation muß lauffähig sein, d.h. eine Mainloop haben.


Peter

Die Applikation hat eine Hauptschleife, es ist in C geschrieben, wie 
muss ich das realisieren?
Es ist so das mein Programm definitiv nicht startet, weder nach einem 
Reset noch nach dem Flashen.


mfg Andreas

Andreas B. wrote:

> Es ist so das mein Programm definitiv nicht startet, weder nach einem
> Reset noch nach dem Flashen.

Verify und CRC sind o.k. ?


Wenn Du überzeugt bist, daß Dein Programm funktioniert, dann lade es mal 
direkt, ohne Bootloader.


Peter

Ohne Bootloader läuft es, und CRC habe ich nicht drauf, zumindest wird 
ausgegeben das CRC nicht implementiert ist.
Auch wenn ich .crc = 17 auskommentiere erscheint dies.
Ich benutze den Internen Oszi, habe Datenübertragung mit 9600 Baud 
klappt bei meinem Programm, ich habe beim Flashen auch 9600 Baud 
angegeben (wobei das wahrscheinlich eh nichts bringt da du sowieso das 
ganze per Software machst).

Ist es möglich das ich den Bootloader falsch geflasht habe, also das der 
auf 0x00 steht und mein Programm hintendran oder so?
Ich habe einfach das .hex File mit AVR Studio aufgespielt.


mfg Andreas

Ich muss natürlich nicht CRC auskommentiern sonder VERIFY 
einkommentieren.
Und dann erscheint auch "fail" warum weiss ich noch nicht...
Aber demfall wurde mein Programm nicht augespielt, oder zumindest nicht 
richtig aufgespielt...

Danke für die Antworten und ich hoffe mal ich kriege das noch selbst 
raus, oder du hast nochmals einen Vorschlag...

mfg Andreas

Schau mal bei den Fuses nach, der ATmega48 hat noch ne 
Self-Programming-Enable Fuse, die muß man setzen.


Peter

Danke!
Das wars!


mfg Andreas

So, hier mein Linuxport des Bootloader Programmers. (Basiert auf dem 
Original und dem Port von Sascha Biedermann vom vorherigen Thread)

Leider nicht ganz so schnell wie das original, und mit ein paar 
unschönen Hacks drin...:

1

/dev/ttyS0 at 115200 Baud: /

2

Connected

3

Bootloader V1.4

4

Target: 1E9205 ATmega48

5

Buffer: 64 Byte

6

Size available: 3582 Byte

7

reading file... Done.

8

Program project.hex: 0000 - 0D25 successful

9

CRC: o.k.

10

Elapsed time: 28 seconds

11

andreas@andreas:~/avr/bootloader_linux$ ./main /Vproject.hex

12

/dev/ttyS0 at 115200 Baud: \

13

Connected

14

Bootloader V1.4

15

Target: 1E9205 ATmega48

16

Buffer: 64 Byte

17

Size available: 3582 Byte

18

reading file... Done.

19

Verify project.hex: 0000 - 0D25 successful

20

CRC: o.k.

21

Elapsed time: 41 seconds

Trotzdem möglicherweise nützlich für Linuxuser ;-)

mfg Andreas

Hier eine neue Linuxversion, nun klappt das Programmieren innert 
Sekunden (bei meinem ATMega48 sinds sogar nur 0.44 Sekunden) und einige 
Bugs behoben.

Und noch eine Frage, kann der Bootloader aus C gestartet werden?
Ich habes versucht mit

1

cli();

2

asm volatile ("rjmp 0");

das klappt aber nicht, da hängt sich alles auf.

ps. ich habe versucht einen Pin mit dem Resetpin zu verkabeln, da hängt 
sich aber alles auf wenn ich den auf LOW setzte, irgendwie funktioniert 
das nicht... bzw. ich mache was falsch.

mfg Andreas

Werner B. wrote:
> Du musst natürlich an den Anfang des Bootloader springen, nicht nach
> Null.

Das stimmt, aber ich weiss nicht wo der Bootloader beginnt, und ich habe 
gelesen das der an erster Addresse ein Jump zum Bootloader drin ist.

Ich versuchs mal noch mit dem Watchdog.


mfg Andreas

Ich bin mir nicht sicher ob ich ein Problem mit dem Bootloader oder 
sonst etwas habe, hier mal die Beschreibung:
Ich mache einen Reset per Watchdog:

1

void reset(void)

2

{

3

  uint8_t i;

4

5

  uart_puts("reset\r\n");

6

7

  for(i = 30; i > 0; i--) {

8

    uart_puti(i);

9

    uart_puts("\r\n");

10

    _sleep();

11

  }

12

13

14

  //Interrups deaktivieren

15

  cli();

16

17

  //Watchdog einschalten

18

  WDTCSR = (1 << WDE);  

19

  for(i = 0;1; i++) {

20

    uart_puti(i);

21

    uart_puts("\r\nw");

22

  }

23

24

}

Aufem Treminal kriege ich:

1

...

2

2

3

1

4

0

5

w1

6

w2

7

w3

Daher kann ich davon ausgehen das er einen Reset macht. Aber danach wird 
mein Programm nicht mehr gestartet. Wenn ich versuche ein Programm 
aufzuspielen erscheint gerade noch (ich beende natürlich das Terminal, 
sonst würde es ja meine serielle Schnittstelle blockieren)

1

/dev/ttyS0 at 115200 Baud: -

2

Connected

da das Laden des Bootloaders sonst klappt gehe ich davon aus das 
irgendetwas nicht richtig initialisiert wird beim Reset mit Watchdog, 
oder was könnte es sonst sein? Hat noch keiner den Bootloader per C 
gestartet?


mfg Andreas

Die Warnungen kannst du ignorieren, diese sind unwichtig, jedoch das 
Problem mit der Grösse hatte ich auch, ich habe darum etwas einfach so 
"gebastelt" das es bei mir funktioniert, warum das es bei dir nicht 
funktioniert kann ich so nicht sagen, was hast du für ein Controller? 
(Vor allem wie viel Speicher hast du)

Ich habe hier mal eine "Debugversion" angehängt, diese schreibt die 
entscheidenden Zahlen auf die Konsole, einfach die Ausgabe kopieren, ich 
hoffe ich kann damit zumindest feststellen was schief läuft.

Ich habs bis jetzt nur mit einem Mega48 probiert, und einfach alles so 
angepasst das es damit funktioniert, was mir nicht klar war warum das 
ich einmal falsche Zahlen empfangen habe (mir wird die Länge der Zahl 
übertragen, in Byte, die war jedoch bei zwei Werten immer um eins zu 
hoch).

mfg Andreas

Versuch mal diese Version. Bei ich musste ein paar Änderungen machen, 
damit der Bootloader Programmer bei mir lief, ich denke aber für den 
ATMega 8 scheinen diese nicht nötig zu sein (der ATMega 48 war ja auch 
nicht in der Liste, darum hats wahrscheinlich auch nicht funktioniert.)

Ich warte auf dein Ergebnis und werde hoffentlich dann eine Finale 
Version machen können die mit allen Controllern funktioniert...

mfg Andreas

Irgendwo ist beim portieren ein Fehler passiert, denn das ist 1:1 die 
Funktion die auch in der Windowsversion eingesetzt wird. Ich werde das 
ganze morgen nochmals vergleichen, und vielleicht komme ich auf einen 
Fehler.

Ich kann dir auf jeden Fall mal sagen wo das es schief läuft (in der 
Hoffnung ein mitdenkender Forumuser könnte mir die Lösung sagen;-)):
ATMega 48: er sagt er sendet mir 2Bytes, sendet aber nur eines (Buffer: 
64Byte, 64 passt in ein Byte), dann beim Speicher sagt er er Sendet 
3Bytes, sendet aber zwei, usw.
Dein Controller sagt auch er Sendet zwei Byte beim Buffer, sendet aber 
zwei...
Ich weiss (noch) nicht wo der Fehler liegt.


mfg Andreas

Es wäre sinnvoll dafür einen Artikel im Wiki zu erstellen:
Anleitung: Artikel erstellen

Hi,

hab jetzt nach über einem Tag intensivem probieren meine ganzen Fehler 
rausgekriegt und der Bootloader läuft ;-)

Da der ein oder andere Anfänger sicher ähnliche Probleme hat, hab ich 
mal ne kleine Anleitung geschrieben.

Seh auch grad die Frage nach dem Wiki. Wenn Ihr nichts dagegen habt 
schreib ich die Anleitung auch noch ins Wiki.

Am Support durch die ATMega IDE schreib ich gerade. Sollte also heute 
oder morgen dann downloadbar sein.

Die Geschwindigkeit ist echt der Hammer. Ich hab für ein Programm im 
168er mit dem ISP immer so 1,5 Minuten gebraucht. (inkl. Verify) Jetzt 
brennt er das in nur 3 Sekunden rein (ohne Verify).

Echt toll ;-)

Ciao
Karsten

So Wiki ist drin.

http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger

Ciao
Karsten

Hallo,
ich würde das PC-Programm gerne in VB schreiben. Allerdings ist Java und 
C nicht gerade meine Stärke ;-)

Gibt es irgendwo eine ausführliche Dokumentation zum Protokoll zwischen 
MC und PC ?

Viele Grüße
David Herrmann

So, ich hab mich in Unkosten gestürzt und nen ATmega2561 gekauft.

Über 64kB brennen geht jetzt.

Allerdings ist noch irgendwo der Wurm drin, dauert sehr lange.

Daher hier erstmal ne Vorabversion.

Das Protokoll ist geändert, betrifft aber nur den Verbindungsaufbau 
(extra Zeichen nach Paßworterkennung), wurde für den Eindrahtmodus 
nötig.


David Herrmann wrote:
> Gibt es irgendwo eine ausführliche Dokumentation zum Protokoll zwischen
> MC und PC ?

Bisher noch nicht. Mal sehen, wann ich dazu komme.


Peter

Der Bootloader ist pure Assembler.

Nur das PC-Programm ist in C geschrieben, muß man aber nicht neu 
übersetzen, die EXE ist ja schon dabei.

Ist nur für die, die es modifizieren (GUI) oder an Linux usw. anpassen 
wollen.
Manche mögen ja keine automatischen Programme, sie wollen lieber 
jedesmal umständlich umherklicken müssen.


Peter

Tom wrote:

> Ich habe dann das Flash wieder per ISP ausgelesen, dabei stellte sich
> heraus das die erste 48 Bytes komplett verschieden sind.

Hab ich jetzt auch keine Erklärung dafür.

Versuch mal ganz oben Version 1.4, die sollte eigentlich laufen.

Die Version 1.6. hab ich nur ganz kurz getestet und noch nicht weiter 
verwendet.


Peter

In der Anleitung steht das man die Fuses auf 256 words setzen soll, in 
meinem Fall bin ich aber auf 512 gekommen.

Am besten machst du mal ein Chip Erase, brennst den bootloader und liest 
dann mal den Flash aus, wenn ich mich recht entsinne (bin gerade nicht 
am richtigen Rechner) fängt der Bootloader mit der Standard Config bei 
:101E0000 (Intel Hex) an.

@Johannes
der Bootloader sitzt am oberen Ende im Flash. Der brennt praktisch 
erstmal ein leeres Programm und oben den Bootloader. Der Bootloader legt 
danach das eigentliche Programm wieder an der richtigen Stelle (weiter 
unten) ab.

Frequenz sollte nicht stören. Ich hab den M8 mit der 3,68er und den M168 
mit 8,000MHz benutzt. Die Wartezeit hat bei mir bisher keine Probleme 
gemacht.

Ich benutze auch die Hardware-Pins da ich da eh schon ne RS232 dran hab.

Größe ermitteln: avr-size -A m8.hex


@Kriewitz
256 Worte = 512 Bytes. und der Bootloader hat weniger als 512 Bytes 
(zumindest V1.4, 1.6 hab ich noch nciht getestet weil ich im Urlaub 
war).

Hab jetzt mal die Version 1.6 genauer getestet, die ist Schrott.
Mein Borland-C 3.0 weigert sich standhaft, Felder über 64kB zuzugreifen.

Also erstmal Version 1.4 verwenden.

Wenn da oft Bytes 0x13 vorkommen, geht die Geschwindigkeit über USB 
drastisch in die Knie.
Wird in Version 1.7 abgestellt (muß aber erstmal nen funktionierenden 
Compiler besorgen).

Wenn gar nichts geht, kann das an speziellen LPT-Treibern für direkte 
IO-Zugriffe (ISP) liegen, die können sich mit der COM im DOS-Fenster 
beißen. Also diesen mal deaktivieren.


> Program test.hex: 0000 - 1300 failed !

könnte das nicht aktivierte SELFPRGEN-Fusebit sein.


Peter

P.S.:
Ein kompletter ATmega2561 dauert ~33s.

Mit dem C-Builder von Borland (jetzt CodeGear) gehen auch 
Konsolenanwendungen. Die haben auf der Homepage auch eine Testversion 
zum Download.

An sonsten könnte ich was mit Delphi schreiben. Da kommt das je eh in 
die ATMega IDE rein.

Karsten

Anbei die neueste Version.

Wie es scheint, muß ich bei meinem uralt BC3.0 die 
Segment/Offset-Rechnung zu Fuß machen. Jedenfalls geht es jetzt.

Können sich die Windowsprogrammierer mal einen ablachen, was früher so 
für Verrenkungen notwendig waren.


Peter

Bin aber eher froh das ich mich mit sowas nicht mehr rumplagen muss. 
Wenn ich da so an Overlay Dateien usw. denk. Oder die selbstgeschriebne 
XMS Unit ;-)

Karsten

Sorry, natürlich 256 words, nicht 512!

@Tom
Im Anhang ist eine funktionierende M8535.ASM, der mega8535 hat im 
Gegensatz zum mega8 nur 512kByte SRAM, BufferSize muss also auch 
angepasst werden.

@Peter
Du kannst die Datei gerne mit reinnehmen.
Hier nochmal die device id vom mega8535

1

case 0x1e9308: s = "ATmega8535"; break;

Kompletter flash (7680 Byte) hat bei mir 2,3 Sekunden gedauert :)

Getestet mit 115200 BAUD @ 14318180 Hz und FBOOT V1.7

Bin noch dabei.

Karsten

Anbei das PC-Programm mit einigen Typen hinzugefügt. Die Typenliste 
sollte man wohl besser auslagern.
Werde mal noch 8051-er hinzufügen, das Flip ist mir zu langsam und zu 
umständlich.

Den ATtiny44 hab ich noch getestet.

Der Eindrahtmodus funktioniert bei mir auch sehr gut bei 115200 Baud, 
geht also auch ohne MAX232.
Das Abzählen der Echobytes funktioniert zuverlässig.
Die Programmierzeiten sind gleich.


Peter

Tom wrote:

> Mich würde noch interessieren was es mit der password.inc auf sich hat,
> kann man damit den Bootloader Zugriff beschränken? Falls ja, wie?

Das ist nur die Auswerteroutine für das Paßwort.

Du kannst auch ein anderes und auch längeres Paßwort als "PeDa" 
definieren, es muß bloß ein für die Baudratenerkennung geeignetes 
Zeichen enthalten, z.B. 'a'.

Und dann natürlich mit:

fboot17 -ineues_Passwort ...

dem PC-Programm übergeben (sehe gerade, das fehlt im Hilftext).

Ohne das Paßwort kommt keiner in den Bootloader.
Man kann also ruhig Geräte an die UART anschließen, die schon beim 
Einschalten sehr gesprächig sind.


> Und wie verhält sich der booloader wenn man etwas in den booloader
> Bereich flashen will (wenn man keine LockFuses programmiert hat)?

Die Programmierroutine macht immer einen Adreßcheck und verweigert die 
Selbstzerstörung.

Aber auch schon das PC-Programm bricht ab, wenn die höchste Adresse über 
dem Applikationsbereich liegt.


> Bin mir gerade nicht sicher, aber kann man eigentlich auch per Booloader
> Fuses ändern, fände eine Möglichkeit die RSTDISBL Fuse zu ändern noch
> sehr praktisch.

Die Fuses kann der AVR nicht selber ändern.


Peter

Nun, das Paßwort enthält ja verschiedene Bytes, die Low-Impulse von 1..9 
Bitzeiten enthalten können.

Damit nun die Baudratenerkennung nicht austillt, prüft sie das 
Verhältnis zweier aufeinanderfolgender Low-Pulse, ob es 1:4 beträgt. Das 
ist z.B. beim 'a' der Fall.


Man könnte sie in die Irre führen, indem man die Bytefolge 0x20,0x80 
sendet, dann hat man 2 Bitzeiten gefolgt von 8 Bitzeiten, was auch 1:4 
ist. Dann steht die Baudratenerkennung aber auf der halbe Baudrate. 
Daher dürfen derartige Bytefolgen nicht im Paßwort vorkommen.


Peter

Der Techniker wrote:

> Habe jedoch mit dem FBOOT17 hin und wieder ein Problem. Manchmal
> reagiert die DOS-Box, in der ich das Programm starte nicht mehr (Keine
> Rückmeldung).

Hast Du USB/RS232 oder ne echte RS232 ?
Hast Du nen LPT-Treiber installiert, z.B für SPI ?

Bei USB mal den neuesten Treiber installieren.
Bei LPT mal den Treiber deaktivieren.
Drauf achten, daß keine andere Anwendung die gleiche COM belegt.

Das Protokoll werd ich demnächst aufschreiben.


Peter


P.S.:
Ich hab ja kürzlich mal den ATtiny13 programmiert, da hab ich mich über 
den Bootloader geärgert :-)
Und zwar, warum ich ihn nicht früher entwickelt habe.
Es macht jetzt richtig Spaß. Besonders der 1-Drahtmodus bei den 
8-Pinnern ist goil. Und man kann endlich alle 6 IOs benutzen ohne nur 
einen einzigen Schuß zu haben.

Hallo Leute,
ich habe in den letzten Tagen versucht, den Bootloader (V1.7) bei mir 
ans Laufen zu bekommen. Leider nur mit wenig Erfolg :-(.

Zunächst mal meine Konfiguration: ATMEGA644, TXD auf PD1, RXD auf PD0 
(Standard-UART vom 644)

Ich bin dann nach der Wiki-Anleitung vorgegangen:
- fastload.h angepasst :".equ XTAL = 20000000 ; 20MHz, not critical"
- in m644.asm die Ports auf Port D angepasst
- übersetzt mit "avrasm2 -fI m644.asm"
- gebrannt mit "avrdude -p m644 -c stk200 -P lpt1 -U 
flash:w:"m644.hex":i -U flash:v:"m644.hex":i -y"
- Fuses gesetzt: BOOTRST programmiert, BOOTSZ0 und BOOTSZ1 nicht 
programmiert. Das heißt allerdings beim 644 "Boot size=512 Words" 
(kleinster möglicher Wert). In der Wiki steht etwas von 256 Worte. Ist 
das ein mögliches Problem???
- Wenn ich jetzt fboot17 aufrufe, kommt folgende Ausgabe:

D:\Daten\AVR\BOOTLO~1>fboot17 /C1 /Pflash.hex
COM 1 at 115200 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

D:\Daten\AVR\BOOTLO~1>

Wenn ich beim fboot ein anderes Passwort setze, z.B. "fboot17 /ifoo" 
kommt es nicht zum Connect. Ich nehme daher mal an, dass zumindest die 
Passwortabfrage funktioniert!?!

Die Version 1.4 hab ich auch schon mal kurz probiert, hier kommt es noch 
nicht mal zum Connect.

Vielleicht fällt einem von Euch noch etwas dazu ein oder hat Tipps dazu.

Gruß

Dirk

Versuchs mal mit einer niedrigeren BAUD rate (/B9600)

@freddy436

Danke für den Tip. Hab´s gleich probiert. Funktioniert aber leider auch 
nicht :-(.

Bingo wrote:
> Im Dev-Cpp bist 1000 clock() ticks pro sekunde , vie viel ist im Borland
> ??

Das ist der DOS-Timertakt:

1

#define CLOCKS_PER_SEC 18.2

2

#define CLK_TCK        18.2

Peter

Hat denn jemand von Euch wirklich so viele RS232-USB Adapter 
gleichzeitig in Betrieb, daß er so hohe COMs braucht ?

Ich habe am Notebook nur 2 USB-Anschlüsse und die habe ich als COM1 und 
COM2 konfiguriert.

Und am Desktop habe ich ne interne COM1 und die 2 USB an der Frontseite 
sind dann COM2 und COM3.


Peter

Joerg wrote:

> Ein paar Dinge sind mir aber noch unklar.
> Der ATtiny85 hat ja keinen Bootblock... wie wir er nun aufgerufen.
> normalerweise wird der bootloader ja zuerst gestarte... und wenn die die
> definierte Bootloader-Bedinging (was auch immer) erfüllt ist, dann
> bleibt er im Bootloader und wenn nicht, dann wird das Hauptprogramm
> gestartet. Wie funktioniert das jetzt hier? Denn der Chip startet ja
> immer auf 0x0000. Aber hier liegt ja mein Hauptprogram. Oder muss ich
> die Bedingung in meinem Hauptprogramm einbauen und dann nach 0x1E00
> springen um den  Bootloader zu aktivieren?

Der Bootloader leitet den ersten Sprungbefehl (RJMP) Deiner Applikation 
um.
Du brauchst also auf den Bootloader keinerlei Rücksicht zu nehmen.


> Habe einen 12MHz Quarz. und BootDelay auf XTAL / 10 gesetzt... was
> bedeutet das jetzt?

Das ist die Zeit, in der der Bootloader die Baudrate und das Paßwort 
erkennt.

1/10s = 100ms, könnte etwas knapp werden.
Ich nehme lieber 1/3 = 333ms.


Peter

Der Bootloader "patcht" quasi bei Upload einer neuen Anwendung den RESET 
Vektor so das er immer aufgerufen wird.

Gruß Hagen

Joerg wrote:
> hmmm... habe jetzt ewig gesucht und nicht verstanden, warum auf 0x0000
> kein Code steht...

Ein leerer Flash enthält ja 0xFFFF.
Es ist zwar nicht offiziell, aber dieser Befehl wirkt wie ein NOP, der 
Code läuft also das erste mal durch bis zum Bootloader.
Kannst natürlich auch nen Sprung eintragen.


Peter

Dein letzter Bootloader war schon super, aber dieser ist noch besser. 
Ich hatte damals überlegt ob es möglich wäre den alten Bootloader auch 
in 512 Byte zu quetschen, hatte aber keinen Weg gefunden, der neue hat 
mehr Funktionen und erfüllt den 512 Byte Wunsch :-)
EEProm schreiben war aber bei den 470 Byte nicht mehr möglich, oder?

1

.equ  ONEWIRE      = 3

Peter

Stefan wrote:
> Ähm, den Bootloader finde ich klasse und um so bedauerlicher ist es,
> dass die Kokumentation des Protokolls immer noch "fehlt". Das "fehlt"
> deshalb in Anführungszeichen, da wir ja nicht wirklich einen Anspruch
> darauf haben. Aber einige -mich eingeschlossen- möchten gern die
> PC-Seite in andere Sprachen umsetzen oder gleich ganz in eine
> Applikation einbinden. Wäre doch schade, wenn so eine feine Applikation
> über die ersten, wenn auch sehr erfolgreichen, Schritte nicht hinaus
> kommt...
> Haben wir da noch Chancen ?


O.k., hier isses.


Peter

Und schon den ersten Fehler gefunden:

...
5.
Abfrage Useflashgrö0e:

Senden: COMMAND, USERFLASH
Antwort: ANSWER, 0x04, Flash_high, Flash_mid, Flash_low, SUCCESS
...

Peter

CRC vergessen.


Peter

Danke für das Protokoll ;-)

Ich war leider mehrere Wochen ohne Internet (warum gibts sowas 
eigentlich nich im Krankenhaus?).

Aber jetzt code ich wieder weiter an der IDE und auch nem Tool für den 
Bootloader mit klicki bunti g

Ciao

Karsten

Kurt wrote:
> Ich kann die Defines in der Source nicht finden - gibt es eine neuere
> Version von Loader als tinyload3.zip

http://www.mikrocontroller.net/attachment/25943/fboot17.zip


Peter

Falls es jemanden interessiert:

Ich hab den Bootloader in nen ATtiny45 gebrannt und danach Reset 
disabled.

Dann hab ich per Bootloader ein Programm reingeschrieben, welches PB5 
toggled und es läuft.


Peter