UART Bootloader ATtiny13 - ATmega644

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

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

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

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

Hi,

im Linux-bootloader war noch eine uninitialisierte Variable für die 
Flash-size....
Hier die korrigierte Version.

Gruß,
Bernhard

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 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)

Hier das Hex-File

... und hier das .c-File

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 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 :)

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

Raimund wrote:
> Hast Du schon mal den ATMEGA644P-20 mit dem Bootloader betrieben?

Gibts denn Probleme?

Ich hab nur den ohne P.


Peter

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

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

Danke, werde ich mal testen.

Michael H* wrote:
> außerdem gibts noch AVR Bootloader FastBoot von Peter Dannegger

Genau auf den Artikel hab ich mich doch bezogen ;)

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

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

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

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

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.

Wo kannman den die version neuen versionen laden hier ist ja nur die 
alten 1.7 velinked :/

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.

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.

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.

Hier ist doch irgendwo ne Linuxversion von dem Code gepostet, warum 
nicht die benutzen?

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).

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,

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?

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

Geniale Idee, dem kann ich nur beipflichten.

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

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

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?

@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

@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.

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 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

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.

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?

Ja

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...

Hast du mal nen zweiten mega8 zum Testen hergenommen?

Jop, ist genau das gleiche Problem.

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.

Glückwunsch, da muss man erstmal drauf kommen.

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.

Portiert auf C++Builder 2007 Kommando-Zeile


Gruß Alfred

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.

das Passwort ist "Peda" und NICHT PeDa !!!

Das ist ein Bug in einer bestimmten Version von AVRStudio. Schau mal ein 
paar Posts weiter oben, da wurde das bereits Thematisiert.

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

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.

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,
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