AVR-Bootloader mit Verschlüsselung

[Julian B. (julinho)]

Hollo Forum!

Ich hab das Problem, dass beim programmieren die Fehlermeldung kommt:

"cannot find RJMP to Main".

Ich Benutze verwende einen Tiny167 und AVRStudio 4.18

Ich glaube zu wissen wo der Fehler liegt.

Im .lss file ist steht bei 000

0:  0c 94 28 00   jmp  0x50  ; 0x50 <__ctors_end>

aber kein rjmp.

Wie bringe ich den Compiler dazu ein rjmp zu verwenden?

Gruß Julinho

[Jesse (Gast)]

Das Problem ist, dass bei Tinys mit 16kByte Flash nicht jede Adresse mi 
RJMP erreichbar ist. Deswegen benutzt der Compiler wahrscheinlich den 
JMP-Befehl.
Entweder man erzwingt durch Inline-Assembler einen RJMP, oder Hagen muß 
das PC-Programm modifizieren.

[Morxi (Gast)]

Hallo@all,

hab den Bootloader bis jetzt immer erfolgreich einsetzen können und bin 
auch voll auf Begeister von dem Teil. Nun habe ich das Problem das mit 
dem neuesten AVR Studio 6 beim kompilieren eine wahrscheinlich vielen 
bekannte Fehlermeldung auftaucht. Gibt es hier im Studio 6 irgendeine 
Option die ich übersehen habe oder weiss irgendwer warum das mit Studio 
6 auf einmal nicht mehr funktioniert?

Relative branch out of reach  E:\Dokumente und Einstellungen\Eigene 
Dateien\Atmel Studio\avrootloader\avr\AVRootloader.inc  288

Es betrifft diese Stelle

rjmp Flashend +1

 im diesem Makro:

.macro  jmpapp
.if BLS
    rjmp FLASHEND +1 ; run application
.elif BootStart
    rjmp BootStart-1      ; run application
.else
    rjmp BootStart      ; dummy
.endif ; .if BLS
.endmacro

Kann da bitte einer weiterhelfen? Danke im voraus...
Gruß Morxi

[Fritz (Gast)]

Servus,

ich hab momentan ein kleines Problem, und zwar mit der Codegröße des 
Programms.

Ich verwende den Bootloader auf einen Attiny45 und mit der von mir 
verwendeten Konfiguration sollte ich 3584 Byte für die Applikation haben 
(wird auch so unter Device Information angezeigt).
Mein Programm hat momentan eine Codegröße von 3454 Byte, damit 
funktioniert der Flashvorgang auch problemlos. Wenn die Codegröße des 
Programms durch eine kleine Änderung auf 3460 Byte ansteigt, wird das 
Programm zwar problemlos geflasht, allerdings wird das Programm danach 
nicht ausgeführt, der Attiny bleibt im Bootloader hängen.

Ist das Verhalten normal oder hab ich irgendwas übersehen?

[Fritz (Gast)]

Edit:
Sorry, Tippfehler: Es ist ein Attiny44, nicht 45.

[Arne H. (piowux)]

Hallo Hagen,

wollte mal fragen, ob es schon eine Möglichkeit gibt, eine acy Datei zu 
erzeugen, ohne dass Kommunikation zum Bootloader besteht? Das wäre echt 
hilfreich für mich, da ich unter Linux arbeite und die Erzeugung so 
wahnsinning umständlich ist. Alternativ baue ich auch gerne ein kleines 
Programm, was dies macht, wenn du mir den Quellcode der passenden 
Funktion gibst. Das Script/ Programm würde ich dann auch hier 
reinstellen.

Es wäre echt eine unheimliche Erleichterung für mich und wahrscheinlich 
auch für viele andere.


Viele Grüße,

Arne

[Rolf P. (rolfp)]

br schrieb:
> -->wird lds temp_r,PORTJ
>         sbr temp_r,(1<<PJ0)
>         sts temp_r,PORTJ

Ich glaube die dritte Zeile ist falsch.
Müsste wohl so sein:
         sts PORTJ,temp_r

Rolf

[lichtwerk (Gast)]

Hallo Hagen,
ich hab zwar alle Post durchgelesen, hab aber folgendes nicht gefunden:
Ich würde gerne Deine PC Software (AVRootloader.exe) benutzen.
Ich habe einen selbstgebauten RS232-485 Wandler. Hier muss man aber über 
den RTS Pin der RS232 Schnittstelle zwischen Senden und Empfangen 
umschalten.
Ist das irgendwie möglich ?
Danke,Grüße
L.W

[Jürgen (Gast)]

Hallo Hagen,

zuerst einmal Danke dass du deinen Bootloader hier zur Verfügung 
stellst.
Ich habe ihn zwar bisher noch nicht verwendet, aber er erscheint mit 
sehr universell und auch für meine Belange geeignet.

Nun habe ich aber folgende Frage:
Wenn ich eine eigene Hostsoftware entwickeln möchte fehlt mir eine 
Protokollbeschreibung, oder habe ich etwas in diesem "dicken" Thread 
überlesen. Ansonsten stellst du eine DLL zur Verfügung welche in 
Eigenentwicklungen genutzt werden kann, oder?

Falls du hier noch liest, oder mich sonst jemand ein wenig erleuchten 
kann wäre ich für eine kurze Rückmeldung sehr dankbar.

Gruß
Jürgen

[Werner (Gast)]

ich habe die Absicht den AVRootloader aehnlich zu nutzen wie in der 
letzten Mail beschrieben.
Grund ist, dass ich den in einer Umgebung einsetzen moechte, bei der 
zahlreiche Microcontroller (AVR und andere) beteiligt sind.
Ein zentralerer Controller (ARM programmierbar in C, C++ und natuerlich 
Assembler) haelt alle zur Distribution notwendgne Firmware Varianten und 
programmiert diese bei Bedarf in die Peripherieprozessoren.
Dazu muesste ich in der Lage sein, ein ACY File mit dem ARM in einen AVR 
zu laden.
Das Protokoll muss also selbst implementiert werden.
Geht natuerlich mit reverse Engineering und dem lesen diverser Mails aus 
dem Therad und vielen Tests, schoener waere ein Quellcode (Sprache egal, 
ich spreche fast alles) oder eine Beschreibung.
Vemute aber mal, das es Hagen zuviel Arbeit mit der Beschreibung macht.
Denn ansonsten wirkt der Loader aufgrund des geringen Codeumfanges sehr 
geeignet.
Denn es macht wenig Sinn einen kleinen Tiny AVR mit riesiegne 
Bootloadern zu beladen und wenig Platz fuer eigenen Code zu haben.
Somit ist der Bootloader incl. Verschluesselung usw. in weniger als 512 
Worten schon eine tolle Sache.
Hat da vielleicht jemand noch ne Info ?

[Werner (Gast)]

nachdem ich mich nun einige Stunden mit den Mails/Thread als auch den 
Quellen beschaeftigt habe, bin ich inzwischen soweit mich mit einem AVR 
mit AVRootloader an Board basismaessig unterhalten zu koennen.
Eine Analyse der ACY Files sieht allerdings leider nicht so aus, als ob 
man diese direkt fuer eine eigene Implementation verwenden kann.
Ich war davon ausgegangen, dass das ACY die bereits verschluesselte 
Kommunikation entahelt und ich nicht selbst noch eigene Routinen dafuer 
schreiben muss.
Das sieht nicht so aus, entweder der Code ist wie gedacht entahlten und 
zusaetzlich nochmal veschluesselt oder er besitzt eine grundsaetzlich 
eigene Veschluesselung, die dann im Einsat nochmals umgesetzt wird.
Dann waere natuerlich klar, warum es die Quellen des PC Tools bzw. der 
DLL nicht frei gibt.
Aber spielt ja auch keine Rolle. Dann muss man das ja anhand der 
vorliegenden Infos nochmals implementieren.
Danke auf jeden Fall an Hagen, das er sich die wahnsinnige Muehe gemacht 
hat den AVR so kompakt in Assembler zu programmieren. Die 
grundsaetzliche Funktion in einer Hochsprache oder ineffizienterem 
Assembler Code waere ja schon einige Arbeit gewesen, aber das ganze dann 
so zu optimieren.
Tolle Sache.
Da mir jetzt klar ist, dass ich die Hostseite ohne groessere Probleme 
hinbekommen werde, werde ich den Loader bei mir einsetzen und Morgen 
erst einmal meine AVRs mit dem PC Tool beschreiben und in Kuerze dann 
das Comm Tool komplettieren.
Viel Spass noch mit dem Loader.

[Werner C. (werner03)]

Arne Helms schrieb:

Hallo Arne,

zwar schon alter Beitrag aber folgendes:

Ich nutze auch stets Linux und mit Wine per Kommandozeile klappt auch 
der AVRootloader einwandfrei. Ich musste nur die gemappte COM 
Schnittstelle direkt angeben, da mein Wine den AutoDetect nicht 
unterstuetzt:

Also:

wine AVRootloader.exe -PCOM1 ....

Klappt einwandfrei.

Gruss

Werner


> Hallo Hagen,
>
> wollte mal fragen, ob es schon eine Möglichkeit gibt, eine acy Datei zu
> erzeugen, ohne dass Kommunikation zum Bootloader besteht? Das wäre echt
> hilfreich für mich, da ich unter Linux arbeite und die Erzeugung so
> wahnsinning umständlich ist. Alternativ baue ich auch gerne ein kleines
> Programm, was dies macht, wenn du mir den Quellcode der passenden
> Funktion gibst. Das Script/ Programm würde ich dann auch hier
> reinstellen.
>
> Es wäre echt eine unheimliche Erleichterung für mich und wahrscheinlich
> auch für viele andere.
>
>
> Viele Grüße,
>
> Arne

[Jürgen (Gast)]

Hallo zusammen,

@Hagen: Klasse Arbeit, Danke!

Leider habe ich ein kleines Problem: Ich nutze den Bootmode 3 = start on 
watchdog reset or by call from application.
Ist nur der Bootloader installiert funktioniert das Verbinden mit der 
AVRootloader GUI einwandfrei, auch mehrmals Connect, Disconnect, ....
Sobald ich einmal mein User-Programm geflasht habe bekomme ich keine 
Verbindung mehr. Ich kann sehen, dass alle 2 Sekunden ein Watchdog-Reset 
kommt. Mein User-Programm schaltet eine LED ein nach ca. 2 Sekunden geht 
sie kurz (Bootdelay) aus.

Das Log sagt:
08.04.13-18:16:57-372 > Connecting on port COM16...
08.04.13-18:16:57-559 > Switch to 1-Wire mode
08.04.13-18:16:57-637 > Error: no Device found

Die Parameter in der AVRootloader.ini sind die Standardwerte.

Hat da jemand einen Tipp für mich?

Gruß
Jürgen

[JSt (Gast)]

Hallo zusammen,

nachdem ich nun den Bootloader sauber laufen habe und mit Hagens GUI 
problemlos connecte und flashe, versuch ich nun Hagens DLL in ein Delphi 
Programm zu packen.

Hier mal das Log mit Hagens GUI wo es funktioniert:

30.04.13-17:09:22-375 > Connecting on port COM4...
30.04.13-17:09:22-376 > Timeout.Connect       = 100 ms
30.04.13-17:09:22-377 > Timeout.Base          = 100 ms
30.04.13-17:09:22-378 > Timeout.Erase         = 10 ms
30.04.13-17:09:22-379 > Timeout.Flash         = 50 ms
30.04.13-17:09:22-380 > Timeout.Eeprom        = 10 ms
30.04.13-17:09:22-381 > Timeout.Buffer        = 1 ms
30.04.13-17:09:22-382 > Timeout.AppCmd        = 20 ms
30.04.13-17:09:22-383 > Timeout.KeepAlive     = 100 ms
30.04.13-17:09:22-384 > Timeout.RTSPulse      = 0
30.04.13-17:09:22-385 > Timeout.RTSInterval   = 0
30.04.13-17:09:22-386 > Timeout.ConnectTrials = 25
30.04.13-17:09:22-387 > Timeout.MaxPacketSize = 0
30.04.13-17:09:22-389 > send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
30.04.13-17:09:22-415 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
30.04.13-17:09:22-540 > received data   $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72 10 B0 54 65 73 74 93 0B 06 09 30
30.04.13-17:09:22-541 > Switch to 1-Wire mode
30.04.13-17:09:22-564 > Timer created
30.04.13-17:09:22-565 > Device connected
30.04.13-17:09:22-665 > send keepalive
30.04.13-17:09:22-777 > send keepalive
30.04.13-17:09:22-885 > send keepalive
30.04.13-17:09:22-993 > send keepalive
30.04.13-17:09:23-078 > Timer released
30.04.13-17:09:23-181 > Device disconnected

und hier mit meinem Delphi-Testprogramm

Connecting on port COM4...
Timeout.Connect       = 100 ms
Timeout.Base          = 100 ms
Timeout.Erase         = 10 ms
Timeout.Flash         = 50 ms
Timeout.Eeprom        = 10 ms
Timeout.Buffer        = 1 ms
Timeout.AppCmd        = 20 ms
Timeout.KeepAlive     = 100 ms
Timeout.RTSPulse      = 0
Timeout.RTSInterval   = 0
Timeout.ConnectTrials = 25
Timeout.MaxPacketSize = 0
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
send ident      $00 00 00 00 00 00 00 00 00 0D 42 6F 6F 74 6C 6F 61 64 65 72
send appcmd     $FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Danach wirft DoConnect eine Exception ohne Beschreibung ()

.... mein Sourcecode im Anhang als zip-File

Kann mir da wer unter die Arme greifen?

Gruß
Schorsch

[Michael K. (mmike)]

Hallo zusammen,

nachdem ich den Bootloader vor langer Zeit mal sehr erfolgreich getestet 
und benutzt habe, will er nun leider nicht mehr :-|.

Hier das Setup:

- Eigenbauplatine mit einem ATMega88PA
- Rechner mit Windows 7x64
- 5V FTDI Adapter

Board lässt sich mittels STK500 per ISP programmieren und funktioniert 
auch wunderbar. Die UART Schnittstelle funktioniert einwandfrei aus dem 
Programm und die Daten erscheinen über den FTDI im hterm.

Eingesetzt wird der Bootloader Version 6.

Kompiliert wird mit AVR Studio 4.19 Build 730 (AvrAssembler2, 
avrasm2.exe Version 2.1.42).

Vorgehen:

1. AVRootloader.aps im Studio geöffnet
2. .include "m88PAdef.inc" einkommentiert. Der Rest der includes ist 
auskommentiert.
3. Bis auf UseAutobaud = 1 und UseResetDelay = 1 stehen alle 
Einstellungen auf 0
4. RX_PORT = PORTD     RX = PD0
5. TX_PORT = PORTD     TX = PD1
6. XTAL = 14745600 (die UART Kommunikation läuft bei 115200 einwandfrei)
7. BootCodeSize auf 0 gesetzt und kompiliert
8. .cseg sagt bei genutzter Größe 422
9. BootBodeSize auf 422 gesetzt und neu kompiliert (jetzt zeigt .cseg 
424, aber das hab ich nach Anleitung ignoriert)
10. Fuses:
  - BootSZ (Bootsize): auf size = 256 words eingestellt (0x0F00)
  - BootRST aktiviert
  - SUT_CKSEL steht auf Ext. Crystal 8.0- MHz ... + 65 ms
  - Sonstige Fuses bis auf SPIEN sind aus (RSTDISBL, DWEN, WDTON, 
EESAVE, CKDIV8, CKOUT)
11. Fuses programmiert
12. hex File geflasht und verified. Keine Fehler.
13. Board an den FTDI angesteckt.
14. AVRootloader.exe gestarted und Com port des FTDI eingestellt. Sign 
ist BOOTLOADER wie auch im Bootloader.asm (BootSign: .db "BOOTLOADER")
15. Nach dem Klicken auf "Connect to device" mehrmals das Board 
resetted. Aber er bekommt keine Verbindung. TX des FTDI blinkt kräftig 
beim Connect-Versuch. Hab 9600 bis 115200 baud durchprobiert, aber 
leider kein Erfolg. Auch ein Tauschen der RX und TX brachte leider 
keinen Erfolg.

Hab zusätzlich auch im FTDI die Timeoutzeiten auf 5ms verringert und die 
Buffersize für Senden und Empfangen auf 64 reduziert.

Was macht eigentlich genau die BootMsg? Ist das ein "String" der am 
Anfang des Bootloaders ausgegeben wird??

So langsam bin ich ratlos und hoffe Ihr könnt mir helfen!!

Beste Grüße,
Michael

[Michael K. (mmike)]

OK war klar ... nach Stunden des rumprobierens hab ich jetzt mal noch 
das UseUartInvert auf 1 gesetzt.
Und siehe da ... es funktioniert!!!

Beste Grüße,
Michael

[Charly B. (charly)]

Arne Helms schrieb:
> Hallo Hagen,
>
> wollte mal fragen, ob es schon eine Möglichkeit gibt, eine acy Datei zu
> erzeugen, ohne dass Kommunikation zum Bootloader besteht? Das wäre echt
> hilfreich für mich, da ich unter Linux arbeite und die Erzeugung so
> wahnsinning umständlich ist. Alternativ baue ich auch gerne ein kleines
> Programm, was dies macht, wenn du mir den Quellcode der passenden
> Funktion gibst. Das Script/ Programm würde ich dann auch hier
> reinstellen.
>
> Es wäre echt eine unheimliche Erleichterung für mich und wahrscheinlich
> auch für viele andere.
>
>
> Viele Grüße,
>
> Arne

Moinmoin

i meine Hagen hat mal gesagt das steht auf der TO DO Liste,
i trigger es auch mal wieder an da ich auch sehr gluecklich
darueber waehre, wie siehts aus Hagen ?, vielen Dank schonmal
im vorraus & ein schoenes WE

vlG
Charly

[Tim H. (rettungstim)]

Hallo zusammen,

das ist echt ein super Bootloader. Ich habe ihn jetzt auch ans laufen 
gebracht. :-)

Nun möchte ich aber in meinem C-Programm, welches ich mit dem Bootloader 
auf den AVR Brenne den Bootsign auslesen.
Hintergrund ist der das ich 7 AVR’s habe mit unterschiedlichen Zeiten. 
Jeder AVR hat seine eigene Bootsign.
Ich verstehe nicht ganz wie ich nun die Bootsign auslesen kann um dann 
die richtige Zeit auf dem richtigen AVR anzuwenden.
Könnt ihr mir da helfen?

Danke und Grüße
Tim

[Tim H. (rettungstim)]

Ich verzweifel bald? Kann mir den keiner einen Tipp geben?

Ich möchte gerne die Bootmsg auslesen und auf dem RS232 senden. Aber 
wie?!

[Omni (Gast)]

Morxi schrieb:

> hab den Bootloader bis jetzt immer erfolgreich einsetzen können und bin
> auch voll auf Begeister von dem Teil. Nun habe ich das Problem das mit
> dem neuesten AVR Studio 6 beim kompilieren eine wahrscheinlich vielen
> bekannte Fehlermeldung auftaucht.
>
> Relative branch out of reach  E:\Dokumente und Einstellungen\Eigene
> Dateien\Atmel Studio\avrootloader\avr\AVRootloader.inc  288
>
> Es betrifft diese Stellerjmp Flashend +1 im diesem Makro:
> .macro  jmpapp
> .if BLS
>     rjmp FLASHEND +1 ; run application
> .elif BootStart
>     rjmp BootStart-1      ; run application
> .else
>     rjmp BootStart      ; dummy
> .endif ; .if BLS
> .endmacro


Auch wenn die Frage schon etwas älter ist, für alle die durch Google 
hierhin weitergeleitet werden:

Wenn man in Zeile 288 rjmp gegen jmp ersetzt, funktioniert es wieder.
> jmp FLASHEND +1 ; run application

[Mario (Gast)]

Hallo,

Ich bin auf der Suche nach einem Linux-Kommandozeilenprogramm (ohne den 
ganzen Wine-Quatsch, es soll in einem kleinen embedded Linux laufen), 
mit dem man dem AVRootloader (Flash & EE) beschreiben kann.

Einzig brauchbares Ergebnis meiner Suche war ein avrdude-patch von 
Sascha Warner ( 
http://lists.nongnu.org/archive/html/avrdude-dev/2010-02/msg00005.html 
).

Ich vermute mal, dass sein Code auf Hagens Orgnial PascalCode (hier auch 
in einem der zip-Attachments zu finden) basiert.

Beide Codes sind jedoch derart lang und komplex, dass man sie nicht "mal 
eben so" kompilieren kann und dann ausprobieren, ob sie mit einem via 
/dev/ttyS... verbundenem AVR reden.

Gibt es eigentlich eine Beschreibung des Rootloader-Protokolls?

Ich hatte ganz naiv gehofft, dass das Rootloader-Protokoll so 
kompliziert nicht sein kann wie die oben genannten, seeehr langen 
Programmcodes.

Die meisten Bootloader arbeiten doch alle irgendwie nach dem Muster
"Sende mir 512 Bytes, und ich schreibe sie in den Flash und schick dir 
den CRC davon".
Klar- Magics, Timeouts, Befehlscodes, Speicheradressen sind auch dabei, 
aber ich hatte gehofft dass es trotzdem nicht derart komplex ist.
Verschlüsselung und Versioning benötige ich nicht, lediglich Flash && EE 
schreiben.

Danke schonmal,
Mario

[Charly B. (charly)]

wenn du keine verschluesselung & co brauchst gibt es
hier andere 'einfache' Bootloader denk ich...
es ist aber auch nix gehextes einen einfachen Bootloader
zu schreiben

vlG & schoenes WE
Charly

[Mario (Gast)]

Hallo Charly,

Ich habe schonmal versucht einen eigenen Bootloader zu schreiben. 
Allerdings in C, und ich habe ihn nicht kleiner als 513 Bytes gebracht - 
(und er war noch nichtmal vollständig). Das war mir zu viel Platz.
Hagens Rootloader ist halt doch sehr kompakt geschrieben, und kann alles 
das was ich mir wünsche, und es lässt sich auch alles, was ich nicht 
brauche, rauswerfen - wodurch er auch sehr klein wird.

Oder kann mir jemand einen simplen Bootloader empfehlen, der

* in 512 Bytes passt,
* Flash und/oder EEPROM beschreiben kann (inkl. verifizieren, aber 
auslesen, verschlüsseln etc. ist nicht nötig)
* dessen uC Quelltexte halbwegs verständlich sind - zumindest der 
Konfigurationsteil
* Über die serielle Schnittstelle ansprechbar ist (kein 
Baudraten-erkennen nötig, aber nice-to-have: Möglichkeit ein 
Driver-Enable für RS485 zu bedienen).
* Nach Reset kurz auf einen Magic auf der seriellen Schnittstelle 
lauscht, und, wenn das nach einer gewissen Zeit nicht kommt, selbst 
beendet
* eine Beschreibung seines Protokolls hat oder ein Kommandozeilen 
Linux-Flashprogramm hat.

Bisher habe ich keinen Bootloader gefunden der das soweit unter einen 
Hut gekriegt hat (mit Ausnahme des letzten Punktes) als Hagens, daher 
bin ich primär auf der Suche nach seinem Protokoll als nach Alternativen 
(bin aber open minded ;-) ).

[Mario F. (superdude)]

Hallo,

Ich habe einen AVRootloader-Client für Linux geschrieben - bisher kann 
er "nur" Upload auf Flash und EEPROM (mir genügt das), aber er ist 
leicht erweiterbar. Der Code läuft übrigens auch unter Windows.

Mich wundert es etwas, dass es bislang keinen Bedarf nach einem 
Linux-AVRootloader gegeben hat (ich habe jedenfalls keinen gefunden).
Bei mir z.B. hängt ein AVR via serieller Schnittstelle an einem 
RaspberryPi, und ich wollte, dass dieser auch den Firmware-Upload 
übernimmt:

pi@raspi1:% avrootloader -p /dev/ttyUSB1 -c "baud=115200 parity=N data=8 stop=1" -f bkb5.hex -e bkb5.eep
avrootloader (LINUX): start...
...
Opened serial port /dev/ttyUSB1 ...
Catching Bootloader ... 97 05 06 04 30  success!
Uploading File bkb5.hex (20020 Bytes) to Flash...
Upload succeded.
Uploading File bkb5.eep (42 Bytes) to EEPROM...
Upload succeded.
...
pi@raspi1 %

Eine technische Frage habe ich jedoch noch zur Funktionsweise dieses 
Bootloaders:

Ich habe dem bekannten Windows-Programm mit einem PortSniffer-Programm 
beim Upload zugeschaut:

Dabei ist mir aufgefallen, dass sie in Blöcken von ca. 16KB (!) auf 
einmal an den AVR lädt - aber soviel SRAM hat der AVR doch garnicht, um 
das zu puffern (uns später in den üblichen 512 Byte Blöcken in den Flash 
zu schreiben).

Also wieso funktioniert das ganze dann überhaupt?

Ich dachte immer, alle Bootloader empfangen jeweils immer nur einen 
FlashPage-grossen Block, dann schreiben sie ihn weg, und dann senden sie 
eine Bestätigung, dass man ihnen den nächsten Block senden darf.

[Werner (Gast)]

Interesse gab es schon an Linux.
Ich hatte auch mal einen Nachmittag angefangen das ganze mit Crypto etc 
zu implementieren, dann fehlte aber die Zeit und es ist nix fertig 
geworden.
Das ist schon fast ein Jahr her, da in dem Projekt wo der AVR genutzt 
werden sollte dann doch ein kleiner ARM eingesetzt wurde.
Sowiet ich den AVR Code ueberblicke wird da wohl online decodiert und 
geschrieben, nachdem geloescht wurde.
Kann auch sein, dass die Blockgroesse von dem jeweiligen AVR Typ und 
dessen Blockgroesse abhaengt.
So genau erinnere ich mich nicht mehr.

Danke auf jeden Fall schonmal fuer die Implementierung.

Gruss

Werner

[Werner (Gast)]

Hallo,

gerade mal das Compilieren getestet und auf zwei kleine Dinge gestossen

Erstens muessen beim g++ die char als vorzeichenlos vordefiniert sein, 
sonst gibt es zumindestens Warnungen beim Compilieren.
Zweitens existiert das Subdir test nicht, in den das Output File 
geschrieben werden soll.

Angepasste Zeile des compile.sh

g++ -o ./avrootloader  -funsigned-char -lrt -DLINUX *.cpp

Verschluesselung scheint nicht integriert zu sein so wie ich sehe.
Trotzdem super.

Gruss

Werner

[Mario (Gast)]

Hallo,
Danke fürs Feedback!

Korrekt, Verschlüsselung (sowie Versionierung, und Download von Flash, 
EEPROM, SRAM) ist (noch) nicht implementiert.

Korrekt, das mit dem ./test Unterverzeichnis  ist noch ein Rudiment 
meines Entwicklungs-Szenarios.

Korrekt, das mit den unsigned chars nölt der g++ gerne mal an. Die 
Option -funsigned-char macht Sinn, passieren kann nicht viel wenn man 
die Warnung ignoriert.

Ich wollte noch darauf hinweisen, dass ich meinen Linux-Rootloader nicht 
an allen Varianten der AVR-Gegenseite getestet habe.
Genaugenomen nur an einem ATmega1284p mit 18,432MHz, fixer 115kBaud 
Firmware- und Bootloader-Speed, und im AVRootloader alles disablet 
ausser Upload Flas und Upload EEprom (damit er in 512 Bytes passt). Bei 
Bedarf kann ich auch den Asm posten.

Ebenfalls will ich nochmal darauf hinweisen, dass ich das mit der 
PageSize noch nicht ganz geblickt habe:
Wie gesagt, ich habe beobachtet, dass das Delphi-Programm den AVR mit 
16K-grossen Blöcken beschiesst, und mir rätselhaft ist, wie der AVR das 
so schnell puffern und/oder wegschreiben kann.
Der Linux-Bootloader ist daher vorsichtig und schickt immer nur 
512-Byte Blöcke.
Das könnte jedoch für irgendwelche ATTinys auch schon zu gross sein, 
daher gibt es die Optionen "-pf FLASHPAGESIZE" und "-pe EEPROMPAGESIZE" 
um das ggf. runterzusetzen.

Ein ToDo ist deshalb auch, dass der Linux-Bootloader die 
Bootloader-Signature genauer parst, und daraus selbstständig vernünftige 
Presets für den Zielprozessortyp benutzt.
Im Delphi-Programm steckt das alles schon irgendwie drinnen (im Reiter 
"Device Information"), aber ich hab noch nicht gefunden, wie es das 
dekodiert und/oder nachblättert.

Achja, noch eine Empfehlung:
Sehr praktisch ist, wenn man in seiner Firmware bzw seinem 
UART-Protokoll das Kommando zu einem Soft-Reset gleich dem 
Bootloader-Trigger setzt, dann ist das Ding an bequemlichkeit kaum zu 
überbieten und man muss auch keine RTS- oder DTR- Leitungen an 
Reset-Pins hängen:

// in Firmware
void uart_handlemsg(const char* msg)
{
  ...
  if (0 == strcmp_P(msg, PSTR("<rest>"))
  {
    cli(); wdt_enable(WDTO_15MS); while (1) {  }
  }
  ...
}

// in AVRootloader.asm
BootSign:  .db    "<rest>"

[Achim X. (hallali)]

Mario schrieb:
>
> Ebenfalls will ich nochmal darauf hinweisen, dass ich das mit der
> PageSize noch nicht ganz geblickt habe:

IMHO bezieht sich das ganz klar auf die hardware definierte Größe der 
Speicherseiten. Daran kann man z.B. entscheiden, wie viele Seiten 
gelöscht werden müssen, falls man nur einen Teilbereich beschreiben 
will.


> Wie gesagt, ich habe beobachtet, dass das Delphi-Programm den AVR mit
> 16K-grossen Blöcken beschiesst, und mir rätselhaft ist, wie der AVR das
> so schnell puffern und/oder wegschreiben kann.

Dein ATmega hat doch 1KB SRAM, was 64 Flash Seiten entspricht. Meiner 
Rechnung nach steht dann mindestens 63 Seiten als Puffer zur Verfügung.

> Der Linux-Bootloader ist daher vorsichtig und schickt immer nur
> 512-Byte Blöcke.
> Das könnte jedoch für irgendwelche ATTinys auch schon zu gross sein,
> daher gibt es die Optionen "-pf FLASHPAGESIZE" und "-pe EEPROMPAGESIZE"
> um das ggf. runterzusetzen.

Die Namensgebung würde ich überdenken.

Es ist auf jeden Fall geschickt, die erlaubte Puffergröße in der 
Anwendung zu errechnen. Hagen macht das ja auch anhand der Device id.
Ich hab da damals eine Formel von Hagen genannt bekommen:

(SRAM_Size div PageSize -1) * PageSize +24

Schau mal hier die Posts am 03.01.2010 und 04.01.2010.

Meiner Erfahrung nach ist es wichtig immer die Flashseiten komplett zu 
schreiben. Warum weiß ich nicht.


> Ein ToDo ist deshalb auch, dass der Linux-Bootloader die
> Bootloader-Signature genauer parst, und daraus selbstständig vernünftige
> Presets für den Zielprozessortyp benutzt.
> Im Delphi-Programm steckt das alles schon irgendwie drinnen (im Reiter
> "Device Information"), aber ich hab noch nicht gefunden, wie es das
> dekodiert und/oder nachblättert.

Schau mal in "AVRootloader.dev" rein.

[Mario F. (superdude)]

Achim X. schrieb:
>> Wie gesagt, ich habe beobachtet, dass das Delphi-Programm den AVR mit
>> 16K-grossen Blöcken beschiesst, und mir rätselhaft ist, wie der AVR das
>> so schnell puffern und/oder wegschreiben kann.
>
> Dein ATmega hat doch 1KB SRAM, was 64 Flash Seiten entspricht. Meiner
> Rechnung nach steht dann mindestens 63 Seiten als Puffer zur Verfügung.
>

Sorry, das habe ich irgendwie nicht verstanden:
Der ATmega1284p hat 4k SRAM und eine SPM_PAGESIZE von 256 words == 512 
Bytes. Mehr als 7 Pages puffern kann er also kaum.
Wo liegt mein Denkfehler?

Ich habe mir den PortSniff nochmal angesehen und nachgezählt:
AVRootloader.exe schickt dem AVR folgendens:

Port geöffnet durch Vorgang "AVRootloader.exe" (PID: 2004)

Request: 14.11.2013 11:19:10.98864 (+56.7684 seconds)

 00 00 00 00 00 00 00 00 00 0D 3C 72 65 73 74 3E   ..........<rest>
 74 F0 00 00 00 00 00 00 00 00 00 0D 3C 72 65 73   tð..........<res
 74 3E 74 F0                                       t>tð            

Answer: 14.11.2013 11:19:10.25364 (+0.1248 seconds) // boot signature

 97 05 06 04 30                                    ?...0
...              

Request: 14.11.2013 11:19:12.49964 (+0.1560 seconds) // 0xFF=set address

 FF 00 00 00 30 14                                 ÿ...0.

Answer: 14.11.2013 11:19:12.51564 (+0.0156 seconds)

 30                                                0

Request: 14.11.2013 11:19:12.51564 (+0.0000 seconds)

 FE 00 36 00 26 48 0C 94 B0 01 0C 94 CF 01 0C 94   þ.6.&H.?°..?Ï..?
 93 09 0C 94 CF 01 0C 94 CF 01 0C 94 CF 01 0C 94   ?..?Ï..?Ï..?Ï..?
 ... 861 (!) Zeilen später ...
 4F 92 5F 92 6F 92 7F 92 8F 92 9F 92 AF 92 BF 92   O?_?o?????¯?¿?
 CF 92 DF 92 EF 92 7D F8                           Ï?ß?ï?}ø        

Answer: 14.11.2013 11:19:13.71664 (+0.0000 seconds)

 30                                                0               

Request: 14.11.2013 11:19:13.73264 (+0.0156 seconds) // 1=program flash

 01 01 C0 50                                       ..ÀP

Answer: 14.11.2013 11:19:14.20064 (+0.4680 seconds)

 30                                                0

...

Der 805 Zeilen lange Block ist durchgehendes Senden und entspricht weit 
über 13 kB (-> verdächtig ähnlich zu "Buffersize for data", s.u.) - wie 
will der AVR das puffern? Bei 115kBaud the fly wegschreiben kann ich mir 
kaum vorstellen, Flash löschen und beschreiben dürfte nicht so schnell 
sein.

Wie kann das ganze also funktionieren?

Abgesehen davon: Mit dem selbstständigen herausfinden der korrekten 
Page- bzw- Puffergrössen via Formel und .dev-File stimme ich dir 
natürlich zu, das werd ich mir jetzt mal alles anschauen...

Das sagt übrigens AVRootloader unter Device-Information:

Connection                     : 2-Wire
Device name                    : ATmega1284P
Device signature               : 1E9705
SRAM size                      :  16384 Byte
EEPROM size                    :   4096 Byte
FLASH size                     : 131072 Byte
FLASH size for application     : 130048 Byte
FLASH pagesize                 :    256 Byte
Bootloader size                :   1024 Byte
Buffersize for data            :  16152 Byte
SRAM start address             :    256
Bootloader version             :      6
Use bootsection                :    Yes
Versioning supported           :     No
Cryptography supported         :     No

[Achim X. (hallali)]

Sorry, ich meinte natürlich 16KB SRAM nicht 1KB...

Dein Denkfehler besteht darin, nicht die Daten von Deiner MCU richtig 
angeschaut zu haben.

So zeigt auch die .dev Datei

9705=1E9705, ATmega1284P  , 131072, 4096,16384, 256, 256,  4,  8, 16, 32

Vielleicht verwechselst Du das mit der EEProm Größe = 4KB.

Lies auch mal Seite 300 f. im Atmel Manual zum Thema Flash. Da steht 
eindeutig  128 words /page size.

Also 64 * 256 = 16KB, oder?

Kein Problem also mit den von Dir angenommenen 13KB in den Puffer und 
dann write Flash Command und fetisch.
Flash ist ziemlich zügig; EEProm dauert dagegen länger beim internen 
Übertragen aus dem Puffer.

[Hagen R. (hagen)]

> SRAM size                      :  16384 Byte
> FLASH pagesize                 :    256 Byte
> Buffersize for data            :  16152 Byte

(SRAM / PageSize -1) * PageSize + 24 = 16152 Bytes maximal am Stück.
+24 für Extradaten wenn man mit Verschlüsselung arbeitet, 3x8=24 also 3 
Cipherblöcke a 8 Bytes mit den verschlüsselten zufälligem Init-Vector, 
Versionsinformationen und Cipher-Message-Authentication Prüfsummen. 
Somit verbleiben minimal 32-24=16 Bytes für den Stack (32 bytes minimale 
PageSize). Man sendet also (SRAM / PageSize -1) FLASH Pages am Stück 
wenn man den FLASH programmieren möchte. Beim EEPROM/SRAM ist diese 
Regel unwichtig ausser den +24 Bytes, die sind immer identisch wenn man 
verschlüsselt arbeitet.

Die Latenzzeiten von zB. USB-Serial-Wandlern oder TCP/IP-Serial-Wandlern 
wie der XPORT haben mich dazu bewogen so große Datenblöcke wie möglich 
in einem Rutsch zu senden. Diese Treiber/Hardware hat große Latenzen 
wenn man ständig zwischen Senden und Empfangen von Bytes umschaltet und 
dann warten muß. Dies macht einen enormen Anteil an der Performance des 
AVRootloader's aus. Wichtig ist nur das man diese Datenblöcke nicht 
größer als obige Formel macht. Man kann in AVRootloader.ini dieses 
Blockgröße beschneiden indem man zB. MaxPacketSize=512 setzt.

Nach dem Senden dieser Pakete werden die Daten entschlüsselt, was sehr 
schnell geht im Vergleich zum Programmieren des FLASHs oder EEPROMs. Die 
PC-Software wartet dann entsprechend der Anzahl transferierter FLASH 
Pages -> AVRootloader.ini -> [TimeOuts] Flash=25 ms * Pages an 
Millisekunden.

Das Löschen des FLASHs erfolgt noch vor dem Senden dieser Pakete als 
eigenständiges Kommando. So hat die PC-Software die Chance mit 
unterschiedlichen Wartezeiten für das Löschung und Schreiben der 
FLASH-Pages zu arbeiten und hat auch nach dem Löschen eine Rückmeldung 
vom AVR Bootloader im Falle eines Fehlers.

> Im Delphi-Programm steckt das alles schon irgendwie drinnen (im Reiter
> "Device Information"), aber ich hab noch nicht gefunden, wie es das
> dekodiert und/oder nachblättert.

An Hand der 3 Bytes Signatur die gleich am Anfang der Kommunikation vom 
AVR gesendet werden schlägt die PC-Software in der Datei 
AVRootloader.dev Datei nach. Ich habe mich bewusst für diesen Weg 
entschieden da so 1. im AVR FLASH nur 3 Bytes als Signatur nötig sind 
ohne all die anderen Infos. Und 2. kann man so in Zukunft sehr einfach 
in AVRootloader.dev neue AVRs nachtragen ohne das man ständig alles neu 
kompilieren muß. Und 3. die Daten die Atmel in seinen Includes einträgt 
sind nicht immer korrekt, man sollte sich also auf diese Infos nicht 
verlassen und im eigenen Sourcecode direkt darauf zugreifen ohne sie 
vorherig überprüft zu haben. Das geht aber nicht aus Sicht eines 
Programmiers eines universellen und zukunftsfähigem Bootloaders, denn 
ich weiß ja  nicht welche AVrs in Zukunft auf dem Markt sind.

Gruß hagen

[Achim X. (hallali)]

Hallo Hagen,
wirklich ein super Bootloader Dein AVRootloader.
Vielen Dank nochmals auf diesem Weg für die tolle Arbeit!!!

Besonderer Vorteil aus meiner Sicht: man kann ihn unter 512 Bytes 
bringen, wenn man die Verschlüsselung weg lässt, trotzdem erlaubt er 
noch EEprom Zugriff.

Der weg ihn ohne DLL in Delphi einzubinden, war anfangs mangels Doku 
schon ein wenig holperig, aber ich kann gut verstehen, dass Doku 
schreiben nicht eben Deine Leidenschaft ist. Meine auch nicht ;)

BTW: Kannst Du bestätigen, dass man das Flash immer als komplett Seiten 
in den Buffer schreiben muss (also immer ein glattes Vielfaches der 
Seitengröße)?

[Hagen R. (hagen)]

Jain ;)

Man programmiert immer eine Page, so funktioniert die Hardware. Man kann 
aber auch erstmal eine FLASH Page lesen, im Buffer nur die Bytes ändern 
die interessant sind und dann die Page, quasi teilweise modifiziert, 
wieder neu programmieren.

Schau mal in Datei Special.inc bei Write_Flash(), diese Funktion kann 
FLASH Pages auch Bruchstückenweise neu schreiben, auch das 2 Bytes 
Alignment ist dabei egal, d.h. man kann an ungeraden FLASH Adressen 
beliebige Daten aus dem SRAM neu programmieren. Diese Funktion kann 
direkt in GCC C Source aufgerufen werden. Man linkt sie einfach mit in 
den Bootloader ein -> UseSpecialWrite=1 setzen, dann wird am Ende in der 
letzten FLASH Page eine Sprungtabelle hinterlegt mit der man dann aus 
dem eigenen C-Program diese Spezial Funktionen aufrufen kann.

Ab Label wf4: findest du die Loop die den FLASH Buffer lädt, entweder 
mit dem Inhalt aus dem FLASH oder dem Inhalt aus dem übergebenen SRAM 
Buffer, je nach Addresszähler. Wenn der FLASH Buffer voll geschrieben 
wurde wird die Page erst gelöscht dann mit dem FLASH Buffer Inhalt 
programmiert. Danach gehts auf zur nächsten Page solange bis der Inhalt 
aus dem SRAM Buffer = Parameter Size = 0 wurde.

D.h. Write_Flash() könnte defakto den kompletten FLASH aus dem SRAM 
heraus neu programmieren falls genügend SRAM zur Verfügung stünde. Es 
ist dabei eben egal ob die Adresse an Wordgrenze ausgerichtet ist und ob 
der SRAM Datenbereich eine ganze Page an daten enthält. Anders 
ausgedrückt, man kann ein einziges Byte im FLASH neu schreiben lassen, 
intern wird aber immer eine komplette Page neu programmiert, dann eben 
mit dem Originalem Inhalt + 1 geändertes Byte.

Gruß Hagen

[Achim X. (hallali)]

Danke für die Erklärung zu Special_Write!

Ich gehe derzeit so vor, dass ich entweder das komplette Flash neue 
schreibe, oder aber den alten Inhalt Seitenweise auslese, die Seite(n) 
lösche, den Inhalt ändere und die Seite(n) zurückschreibe.

Beim kompletten Schreiben hatte ich dann Probleme, wenn ich mitten in 
einer Seite aufgehört habe, weil halt alle Bytes geschrieben waren. 
Geholfen hat die Seite mit 0FFh zu füllen und komplett zu ende zu 
schrieben.

Hagen Re schrieb:
> 2 Bytes
> Alignment

Klingt, als könnte das der Schlüssel sein...

Edit: Nö. ist er nicht, ich muss die Seiten komplett rüberschicken sonst 
steigt der Bootloader aus.

[Hagen R. (hagen)]

welchen Bootloader meinst du ?

Du kannst den FLASH immer nur Pageweise programmieren. Du kannst aber 
durchaus nur Teile einer Page verändert programmiern. Dazu liest du die 
Page in den FALSH Page Buffer ein und nur die Bytes die geändert werden 
sollen schreibst du in diesen Buffer. Wenn du Assembler verstehst dann 
schaue dir meine write_flash() Procedure an, die macht das so.

[Achim X. (hallali)]

Das Verfahren verstehe ich schon.
Meine Absicht war:
1. AVRootloader ein page erase command für die betroffene Seiten 
schicken
2. Nur die benutzen Bytes schicken (fill buffer), z.b. nur Byte 1 bis 
23, schicken.
3. Als Abschluss write flash command.

Da muss ich halt bei Schritt 2 immer eine volle Seite schicken.
Vielleicht liegt es auch ein meiner Handhabung, ich werd mir das nochmal 
anschauen...

[Hagen R. (hagen)]

achso, AVRootloader's FLASH Command kann nur Pageweise arbeiten. Das ist 
der Preis den man zahlt wenn man mit weniger als 512 Bytes an FLASH für 
den Bootloadercode auskommen möchte. Dann muß man Intelligenz auslagern 
in die PC-Software. Davon abgesehen stellt sich die Frage wie sinnvoll, 
eg. wahrscheinlich ist es das man mit einem Bootloader Programme flashen 
möchte die kleiner als eine Page sind. Mit anderen Worten: das was du 
möchtest ist keine gewöhnliche Bootloader Funktionalität mehr.

Gruß hagen

[Achim (Gast)]

Vielen Dank nochmal für die Erklärung.

Ne, ich finde die Funktionalität von AVRootloader völlig in Ordnung und 
ausreichend. Ich wollte nur Klarheit, ob ich einen Fehler bei mir 
übersehen habe oder meine Vermutung richtig war.

Es ging immer um die letzte Flashseite, die fülle ich dann mit 0ffh auf.

[Mario F. (superdude)]

Guten Abend,
hier ein Update meines Linux-Uploaders:
Neben einem variierbaren Timeout beim "fangen" des Bootloaders habe ich 
jetzt auch das von Hagen & Achim erwähnte .dev-File eingebaut 
(get_dev_by_id).
"Eingebaut" im doppeltem Sinne: zum einen als externe Datei 
AVRootloader.dev, die im selben Dir wie die "exe" liegen muss, zum 
Anderen noch als Fallback als einkompilierteListe (devlist.h)).

pi@raspi1% ./run.sh
avrootloader (LINUX): start...
avrootloader - upload settings:
- Portname  : /dev/ttyUSB1
- Portconfig: baud=115200 parity=N data=8 stop=1
- Flashfile : ./test/bkb5.hex
- Eepromfile: ./test/bkb5.eep
- Trigger   : <rest>
Opened serial port /dev/ttyUSB1 (baud=115200 parity=N data=8 stop=1) handle=3.
Catching Bootloader ... \ 97 05 06 04 30  success!
Device name                    : ATmega1284P
Device signature               : 1e9705
SRAM size                      :  16384 Byte
EEPROM size                    :   4096 Byte
FLASH size                     : 131072 Byte
FLASH pagesize                 :    256 Byte
Buffersize for data            :  16152 Byte
Uploading File ./test/bkb5.hex (20020 Bytes) to Flash...
Upload succeded.
Uploading File ./test/bkb5.eep (42 Bytes) to EEPROM...
Upload succeded.
Hit any Key to exit Bootloader mode...
Exiting Bootloader, Starting Firmware.
Closed serial port.
pi@raspi1%

Zur Transfer-Buffer-Size:
Rechnerisch komme ich zwar auf die bereits erwähnten 16152 Byte 
Transferbuffer-Größe (die ich jetzt auch nicht mehr als "Pagesize" 
benenne).
Allerdings hatte ich kein rechtes Glück damit, auf einen Schlag 16152 
Bytes hochzuladen, der Upload war gescheitert.
Daher ist die Stelle auch noch auskommentiert, und ich belasse die 
Transfer-Buffersize bei 512 Bytes.
Das funktioniert so sehr gut, evtl nicht ganz so schnell, da Hagens 
erwähnte Richtungswechsel des USB-Comports (bei mir ein CP210x) das 
ganze etwas abbremsen. Allerdings sieht man so auch mehr von der Upload 
Prozentanzeige ;-)
Als Fallback gibt es daher noch die Kommandozeilenparameter "-xbf 
FLASHTRANSFERBUFSIZE" und "-xbe EEPROMTRANSFERBUFSIZE" wenn 512 
unpassend sein sollte.
Wie gesagt, ich weis nicht, warum es mit dem 16k-Buffer bei mir nicht 
ging, aber mit 512 Bytes läuft der Upload immer erfolgreich.

NACHTRAG:
(kann man hier auch Attachnents nachbearbeiten?)
Gerade noch einen blöden Fehler gefunden, das da muss in der main() raus 
das funktioniert noch nicht richtig:

  /*
  if (flashfile == NULL)
  {
    static char ffn_buf[FILENAME_MAX];
    flashfile = openfiledialog("Select Flash File", ffn_buf, sizeof(ffn_buf));
  }

  if (eepfile == NULL)
  {
    static char efn_buf[FILENAME_MAX];
    eepfile = openfiledialog("Select EEPROM File", efn_buf, sizeof(efn_buf));
  }
  */

[Hagen R. (hagen)]

>"Eingebaut" im doppeltem Sinne: zum einen als externe Datei
>AVRootloader.dev, die im selben Dir wie die "exe" liegen muss, zum
>Anderen noch als Fallback als einkompilierteListe (devlist.h)).

;) in meiner PC-Software besteht dieser Fallback darin das die Software 
in der installierten Atmel AVR Studio Kopie alle Includes und Part 
Descpription XML Dateien scant und autom. die AVRootloader.dev Datei neu 
aufbaut.

Gruß hagen

[Marco D. (dreamboy21)]

Hallo Herr Hagen,

ich nutze den AVrootloader V1.6 mit eentsprechenden HEX auf einem 
Atmega644P.
Direkt am PC ist das kein Problem.
Aber wenn ich über einen VSP (Virtual Serial Port = Serial auf IP 
wandler mit HW-Group-Software) mit AVrootloader V1.6 flashen möchte, 
dann bekomme ich nur einen Connect, gefolgt sofort von disconnect. Ich 
kann aber wenn ich schnell genug bin bis zu ca. 4...5 mal connecten , 
mit gefolgten sofortigen
disconnecten. Die Information kann ich fast immer korrekt lesen mit 
2-Wire ect...

Ich habe schonmal in der Programm Konfig alle Möglichen Parameter 
versucht.

Da ich leider kein Programmierer bin bräuchte ich Hilfestellung wo da 
Fehler liegen kann . Können sie mir weiter helfen ?

Mfg
M.Dittmann

[Michael K. (mmike)]

Hallo zusammen,

ich nutze Hagens Bootloader mit Genuss und möchte an dieser Stelle noch 
einmal für seine Arbeit danken. Derzeit ist er im Einsatz auf einer 
kleinen Serie von Platinen mit einem ATMega88PA. Hier funktioniert 
soweit alles wunderbar.

Leider sind bei der letzten Lieferung der µC einige Mega88-20AU dabei 
gewesen und die bekomme ich leider einfach nicht zum laufen.

Hier mein Vorgehen:

1. Bootloader mit neuem Include "m88def.inc" kompiliert (Size: 554bytes)
2. Bootloader geflasht (Fuses: 512 words boot section boot reset vector 
enabled)
3. Mit AVrootloader.exe mit dem µC verbunden. Das funktioniert auch 
einwandfrei!
4. Hex-File (für den Mega88 kompiliert) auf den Proz geladen (über den 
AVrootloader). Auch das funzt.
5. Das Programm startet und funktioniert auch einwandfrei. ABER: Ich 
komme auf den Bootloader nicht mehr drauf! AVrootloader.exe gestartet 
und ein PowerCycle am Board --> AVrootloader melde Device not found.

Über einen Tipp wäre ich sehr dankbar, da es mit den Mega88PA 
einwandfrei funktioniert!

Beste Grüße,
Michael

[Charly B. (charly)]

steht der Resetvektor wirklich auf den Bootloader (geprueft?)
oder timing problem

hatte mal sowas aehnliches, als ich autobaud ausgeschaltet
hatte funktionierte es

vlG & viel erfolg
Charly

[Michael K. (mmike)]

Hallo Charly,

vielen Dank für die schnelle Antwort. Resetvektor steht wirklich auf 
Bootloader. Ist gecheckt.
Das timing könnte sein, aber das Programm gibt zyklisch per USART 
(115200) Daten aus. Die kommen auch alle richtig an.
Ich probier mal das autobaud abzuschalten ...

Beste Grüße,
Michael

[Georg B. (schorschi)]

Hallo zusammen,
ich nutze in einem Projekt den AVRoutloader mit Verschlüsselung in der 
Version 6  zusammen mit den ATMega1284P.
Funktioniert absolut zuverlässig und so möchte ich ihn in einem weiteren 
Projekt einsetzen.
Da ich so in der Lage bin Firmware Updates auch auf Entfernung " *.acy" 
Files zu versenden kann ich einzelne MCs auch mit unterschiedlichen 
Passwörten versehen.

Nun kommt mein Problem:
für die Verschlüsselung brauche ich ja immer eine Verbindung zum MC mit 
gleichem Passwort. Wenn ich aber mehrere Passwörter verwenden möchte 
(jeder MC ein anderes) kann ich ja nicht für jeden verwendeten und 
verschickten MC einen zweiten mit dem gleichen Passwort vorhalten oder 
jedesmal den Bootloader auf einem MC nur für die Verschlüsselung neu 
aufzuspielen.

Ich habe auch schon versucht mich in die Sourcen der Version 2 für 
Delphi einzuarbeiten ...........leider fehlt mir da noch der endgültige 
Durchblick da ich den Bootloader Version 2, in Verbindung mit dem 
Windows Programm nicht zum Laufen bekomme.

Die Frage die sich mir stellt, kann ich überhaupt die Verschlüsselung 
"ohne" Verbindung zum MC im Zielsystem realisieren, sieht das die 
Software bzw. die AVRootloader.dll in der Version 2.0.0.0 134Kb vom 
6.5.2008 vor.

Wenn es geht ???? !!!, vielleicht hat das schon ein User realisiert ????
oder kann was dazu sagen.
Eine Ja / Nein Aussage, vielleicht auch vom Entwickler wäre super.

Gruß
Schorschi

[Charly B. (charly)]

Damit hab ich den Hagen auch schon belaestigt, er hat es auf
der TO DO Liste

ich hab es im Moment so geloest das jede einheit eine ID hat
und dann kann ich die Soft fuer diese ID schreiben

vlG
Charly

[Michael K. (mmike)]

Hallo Charly,

also mein Problem mit dem Loader ist gelöst. Es war ein Kabelbruch im 
ISP Kabel (eine Leitung war hin). Nachdem dies identifiziert war lief 
alles einwandfrei sowohl mit den 88ern und auch mit den 88PAs.

Vielen Dank nochmals für Deine Tips!

Beste Grüße,
Michael

[Georg B. (schorschi)]

Hallo Chraly,
erklär mal bitte wie du das meinst mit der ID je Einheit ??

Ich kenne jetzt nur die Eintragung des 128Bit Schlüssels im unteren 
Bereich der Bootloader Software der mit dem brennen in dem AVR landet 
und dem im AVRootloader hinterlegten Schlüsselvergleich (Eingabe per 
Hand oder copy & paste im Eingabefenster) nach Betätigung des Compile 
Button.

Nur so kann ich doch die ACY Datei herstellen !!!!

Geht das auch anders ????

Gruß
Schorschi

[Dario C. (dario)]

Hallo Zusammen.

Danke erstmal an Hagen für den Loader.

Ich habe mich nun durch den 5 Jahre Thread gequält und trotzdem noch 
drei Punkte, deren Klärung ich mir durch dieses Posting, bzw. die 
Antworten darauf erhoffe:

1. Watchdog
Ich springe von meiner App aus den Bootloader an mit:

wdt_enable(WDTO_15MS);
while(1);

wenn ich die Option

UseWDR = 1

aktiviere geht auch alles. Wenn aber nicht, habe ich folgendes Problem:
Bei einem ATmega328P bleigt der WDT aber aktiv und so resettet
sich der mega328P ständig.

Gut wäre, wenn der AVRootloader den WDT deaktivieren könnte, auch wenn 
man den WDT im Bootloader selber nicht nutzen will.
Eventuell nur bei den Controllern, die den WDT nach einem Reset nicht 
automatisch deaktivieren.

Wenn ich das selber patchen will: An welche stelle müsste ich den WDT 
disablen?

2. Bluetooth
Gibt es jemanden, der den Bootloader hier mit so einem Bluetooth-Modul
HC-04 oder HC-05 erfolgreich einsetzt? Ich würde gerne wissen, ob das
Out-of-the-Box geht, oder was man ggf. beachten muss.

3. Unterschiedliche Baudraten
Ich möchte in der APP eine andere BAUD-Rate verwenden als im Bootloader.
Kann man dem AVRootloader.exe über die AVRootloader.ini auch 
diesbezüglich unterschiedliche BAUD-Raten beibringen?

[Jürgen (Gast)]

Hallo zusammen,

weiter oben im Thread wurde mal die Vorbereitungen für den XMega-Support 
angedeutet. Ist da schon jemand weiter?

Gruß
Jürgen

[Charly B. (charly)]

Hi Georg,

das mit der ID macht meine Soft, es liegt im EEPROM
eine ID. Diese wird beim Start der Soft geprueft und
wenn die passt startet die Anwendung


vlG
Charly

[Casper de Boer (Gast)]

Hai

kan ich av rootloader auch in ein linux umgebung gebrauchen.

Casper de Boer

[Ingo S. (ingo-s)]

Erst mal auch von mir vielen Dank an Hagen für diesen super Bootloader, 
den ich seit Jahren erfolgreich einsetze.

Aber nun möchte ich die PC-Seite für einen eigenen one-wire Bootloader 
für die STM32F05x/F1xx Serie einsetzen. Das sollte doch mit einem 
gefaktem AVR Eintrag im .dev File möglich sein oder? Funktionell wird 
nur Flash write+verify benötigt.

Daher suche ich eine Beschreibung des Übertragungs Protokolls, hat da 
jemand mal Aufzeichnungen gemacht?

Gruß Ingo

[sascha (Gast)]

Hat jemand die letzte Version vom Bootloader mit einen ATmega1280 zum 
laufen gebracht ?
Die erste Version funktioniert bei mir sauber und ohne Probleme.

Dagegen die Version 6.0 da bekomme ich keine Rückmeldung vom uC und kann 
somit keine Verbindung aufbauen.

Viele Grüße
sascha

[Martin Mueller (Gast)]

Hallo zusammen,

auch erstmal Dank an Hagen fuer den schicken Bootloader.

Ich selbst habe ihn in eignen Projekten noch nicht eingesetzt, hatte 
aber kuerzlich das Problem ein Geraet, auf dem er sich befand, 
aktualisieren zu wollen. Leider hatte ich gerade kein Windows zur Hand 
und hab daher recherchiert, welche anderen Moeglichkeiten es gibt.

Dabei habe ich auf github den AVRFreeLoader gefunden, der aber noch 
nicht soweit ist, dass er mir weitergeholfen haette: 
https://github.com/prof7bit/AVRFreeLoader

Mit wine 1.6.2 auf debian jessie war ich dann aber, wie folgt, 
erfolgreich:
In die Datei ~/.wine/system.reg muss man folgende Zeilen eintragen:

[Hardware\\Devicemap\\Serialcomm] 1231984861 @=""
"Serial0"="COM1"
"Serial1"="COM2"
"Serial2"="COM3"
"Serial3"="COM4"
"Serial4"="COM5"
"Serial5"="COM6"
"Serial6"="COM7"
"Serial7"="COM8"
"Serial8"="COM9"

Und dann noch den symbolischen link fuer com1 anlegen:

ln -s /dev/ttyUSB2 ~/.wine/dosdevices/com1

Man muss natuerlich /dev/ttyUSB2 durch den Port ersetzen, an dem 
wirklich das Geraet haengt und im AVRootloader dann COM1 auswaehlen.

Vielleicht hilft es ja dem einen oder anderen.

[Werner (Gast)]

Vielen Dank für den Tipp.
Hatte das auch schon mal mit Wine versucht, aber die 
Schnittstellenautoerkennung ging nicht und es wurden keine 
Schnittstellen angeeigt oder detektiert.
Die @... Zeile in der Form scheint es da zu bringen.
Bin halt eher ein Linux Mensch und mache nur extrem wenig wenig 
Windoofs..

[Jürgen (Gast)]

Hallo AVRootloader Fans & natürlich Hagen

Ich habe mich die letzten Tage durch den Thread gearbeitet um den 
Bootlaoder, Verschlüsselung, etc. zu verstehen.
Nun bleiben mir beim Aufbau der ACY-Datei noch einige Fragen die ich mir 
(noch) nicht erklären kann.
Beispielhaft habe ich einen Screenshot eines Dateiheaders im Hexeditor 
angefügt. Folgendes denke ich erkannt zu haben:

0x00 - 0x0b  Identifier "AVRootloader"
0x0c         0x06 Bootloader Version
0x0d         0x07 ???
0x0e - 0x14  App-version "0.2.0.3"
0x15 - 0x18  0x00 0x1e 0x93 0x0b = ATTiny85 Signature
0x19         0x0f Anzahl Pages
0x1a         0x06 ??? Wiederholung Bootloader Version
0x1b         0x00 ???
0x1c         0x25 ???
0x1d -       ab hier Kommandos & Daten

Kann mir jemand bei den Fragezeichen auf die Sprünge helfen?

Gruß Jürgen

[Bernd K. (prof7bit)]

Jürgen schrieb:
> Hallo AVRootloader Fans & natürlich Hagen
>
> Ich habe mich die letzten Tage durch den Thread gearbeitet um den
> Bootlaoder, Verschlüsselung, etc. zu verstehen.
> Nun bleiben mir beim Aufbau der ACY-Datei noch einige Fragen die ich mir
> (noch) nicht erklären kann.
> Beispielhaft habe ich einen Screenshot eines Dateiheaders im Hexeditor
> angefügt. Folgendes denke ich erkannt zu haben:
>
> 0x00 - 0x0b  Identifier "AVRootloader"
> 0x0c         0x06 Bootloader Version
> 0x0d         0x07 ???
> 0x0e - 0x14  App-version "0.2.0.3"
> 0x15 - 0x18  0x00 0x1e 0x93 0x0b = ATTiny85 Signature
> 0x19         0x0f Anzahl Pages
> 0x1a         0x06 ??? Wiederholung Bootloader Version
> 0x1b         0x00 ???
> 0x1c         0x25 ???
> 0x1d -       ab hier Kommandos & Daten
>
> Kann mir jemand bei den Fragezeichen auf die Sprünge helfen?
>
> Gruß Jürgen


0x0d         0x07 ???
0x0e - 0x14  App-version "0.2.0.3"

das Byte vor dem String ist die String-Länge in guter alter 
Pascal-Manier.


0x1a         0x06
Ja, das ist in der Tat die Bootloader Version


0x1b         0x00 ???
0x1c         0x25 ???

Das ist eine 16 bit breite Flag variable (WORD, big endian!):

$0001  Flashdaten sind verschlüsselt
$0002  EEPROM-Daten sind verschlüsselt
$0004  Flash soll geschrieben werden
$0008  EEPROM soll geschrieben werden
$0010  Flash soll verifiziert werden
$0020  Flash soll (vorher?) gelöscht werden
$0040  EEPROM soll komplett geschrieben werden

Aber nagel mich nicht drauf fest, alles ohne Gewähr.

[Jürgen (Gast)]

Hallo Bernd,

das war aber fix. Vielen Dank.

Gruß
Jürgen

[Ingo S. (ingo-s)]

Die AVRootloader.exe mißbrauche ich für einen STM32F05x STRootloader.
Den habe ich geschrieben, weil ich eine serielle one-wire Lösung haben 
wollte. Wenn er fertig ist, werde ich ihn hier auch vorstellen.

Im Moment meldet sich der STM32 als ein ATMega16/32/64, was auch 
funktioniert.
In der AVRootLoader.dev lassen sich aber auch neue ID's eintragen, in 
denen man besser auf den STM32 zugeschnittene Parameter eintragen 
könnte.

Kennt jemand die Bedeutung der Spalten BZ1,BZ2,BZ3,BZ4?
Was diese Parameter bedeuten ist mir noch nicht klar.

Gruß Ingo

[Bernd K. (prof7bit)]

Ingo Stahl schrieb:
> Kennt jemand die Bedeutung der Spalten BZ1,BZ2,BZ3,BZ4?
> Was diese Parameter bedeuten ist mir noch nicht klar.

Das (die ganze Tabelle) ist aus den orginal Atmel PartDescriptionFiles 
xml Dateien rausgeparst. Diese 4 besagten Einträge entsprechen den 
Einträgen von:

MEMORY/BOOT_CONFIG/BOOTSZMODE1/PAGES
MEMORY/BOOT_CONFIG/BOOTSZMODE2/PAGES
MEMORY/BOOT_CONFIG/BOOTSZMODE3/PAGES
MEMORY/BOOT_CONFIG/BOOTSZMODE4/PAGES

[Bernd K. (prof7bit)]

Ingo Stahl schrieb:

> für einen STM32F05x STRootloader.
> Den habe ich geschrieben, weil ich eine serielle one-wire Lösung haben
> wollte.

Das ist sehr begrüßenswert! Ich bin auch schon auf der Suche nach einem 
adäquaten Ersatz. Den guten alten AVRootloader in die ARM-Welt 
hinüberzuretten wäre sehr begrüßenswert bevor er mangels Aufmerksamkeit 
vollends stirbt, auch eine Version für die NXP-ARMs wäre nicht schlecht.

Ich hoffe Deine Version wird quelloffen und frei sein?

Das würde mich auch motivieren wieder etwas Energie für meine 
mittlerweile eingeschlafene unvollendete freie (und cross-plattform) 
Re-Implementierung eines AVRootloader.exe Klons zu stecken.

[Ingo S. (ingo-s)]

Danke für die Info.
Das dient wohl nur zum Überprüfen der Anzahl BootPages, die der Target 
zurück meldet.

Gruß Ingo

[Bernd K. (prof7bit)]

Ingo Stahl schrieb:
> Danke für die Info.
> Das dient wohl nur zum Überprüfen der Anzahl BootPages, die der Target
> zurück meldet.

Genau. So wie ich das momentan überblicken kann wird damit nichts 
anderes getan als zu detektieren ob der betreffende AVR eine 
Bootloader-Sektion hat und ob die Größe die das Target meldet plausibel 
ist.

[Florian B. (dabone_206)]

Hallo Zusammen,
hat jemand Erfahrungen mit dem Bootloader von Hagen und Atmel Studio 
6.2.
Bekomme da immer folgenden Fehler beim Komilelieren:
-Relative branch out of reach

Hoff mir kann jemand weiterhelfen.

[Ralf K. (elral)]

Hallo Florian,

das Problem hatte ich vor längere Zeit beim Wchsel auf AVRStudio 6 auch.
Wenn ich mich recht erinnere habe ich in AVRootloader.inc die Zeile 288 
von:

.macro  jmpapp
.if BLS
    rjmp  FLASHEND +1  ; run application

in:

.macro  jmpapp
.if BLS
    jmp  FLASHEND +1  ; run application

geändert.

Grüße

Ralf

[3162534373 .. (3162534373)]

Ja, geht :)

[Thomas P. (topla)]

Hallo zusammen,

hat eventuell jemand den Code auf den ATMega2560 / PORTH oder auf eine 
echte (Hardware)UART angepasst?

Thomas

[Matthias (Gast)]

Hallo,
erstmal danke für den tollen Bootloader. Habe ihn an einem Mega328P im 
1-wire Modus benutzt. Kompiliert mit Atmel Studio 6.1. Funktioniert an 
5V einwandfrei. Allerdings läuft mein AVR im finalen Board nur bei 3,3V 
weil ich Peripherie dran habe, welche nicht mehr als 3,3V verträgt. Bei 
der geringeren Spannung kann ich dann aber keine Verbindung mehr über 
den Bootloader herstellen. Nutze einen echten COM Port.
Als Adapter habe ich schon ausprobiert:
2,7k und 2xBAT85
1k und 2xBAT85
10k und 2xBAT85
2,7k und 2xSB120
1k und 2xSB120
10k und 2xSB120
auch mal noch zusätzlich eine 3,3V Zener gegen GND. Hat aber auch nichts 
gebracht.

Hat jemand eine Idee wie es gehen könnte? Wie schon erwähnt mit 5V gehts 
immer.
Danke schonmal.
Matthias

[Ste N. (steno)]

Kann mir bitte mal jemand eine unverschlüsselte und veschlüsselte .acy 
Datei einstellen? Der Inhalt ist vollkommen egal und den Schlüssel 
benötige ich natürlich auch nicht. Der gewählte Bufferspeicher sollte 
allerdings kleiner als die Flashgröße sein, damit die Datei in mehreren 
Blöcken übertragen wird. Der Hintergrund ist folgender. Die 
verschlüsselte Übertragung gefällt mir und ich möchte einen Bootloader 
für PIC schreiben. Dazu würde ich gern den Aufbau des .acy Fileformats 
besser verstehen. Leider habe ich selber kein Equipment für AVR um es 
mal kurz auszuprobieren.

Das einzige was ich dazu finden kann steht unter
Beitrag "Re: AVR-Bootloader mit Verschlüsselung".
Hier sieht man das ab Position $1B das Initialisierungs-Paket $FEFE 
beginnt. Kann ich davon ausgehen, das danach die einzelnen 
Flash-Daten-Pakete, welche bei Verschlüsselung mit $FEFF beginnen, 
hintereinander ohne Trennzeichen in der Datei stehen? Und stehen die 
Anweisungen zum Flashen $0101 auch in der .acy Datei, oder werden diese, 
nach senden einer Page und Bestätigen durch MC, von der PC-Software 
generiert?

Welche Antworten erwartet die PC-Software vom zu flashenden MC nach der 
Übertragung der Daten?

Hier
Beitrag "Re: AVR-Bootloader mit Verschlüsselung"
siehr man schön, das bei OK ein $30 übertragen wird. Aber was ist, wenn 
ein Fehler auftritt?


Viele Grüße und schon mal Danke,
Steffen

[Bernd K. (prof7bit)]

Steffen N. schrieb:
> Aber was ist, wenn
> ein Fehler auftritt?

Dann bricht es leider ab. Der code (das ganze Protokoll) sollte 
dahingehend verbessert werden daß Übertragungsfehler durch automatisches 
Halbieren der Blockgröße und Neuübertragen abgefangen werden.

[Ste N. (steno)]

Danke Bernd.

Das er abbricht, war mir ja eigentlich fast klar. Aber wie gibt der AVR 
kund, das was nicht stimmt? Antwortet er einfach nicht und es gibt einen 
Timeout, oder gibt es einen speziellen Befehlscode? Fragen über 
Fragen...

> Dann bricht es leider ab. Der code (das ganze Protokoll) sollte
> dahingehend verbessert werden daß Übertragungsfehler durch automatisches
> Halbieren der Blockgröße und Neuübertragen abgefangen werden.

Also das stell ich mir mit den veschlüsselten Daten im .acy sehr schwer 
vor. Die Adresse der Daten steht ja verschlüsselt am Ende jeden Blockes. 
Wenn ich die Blockgröße OnTheFly verändern will, muß der PC-Bootloader 
die darin enthaltenen Daten mit der Adresse in Echtzeit wieder neu 
verschlüsseln, wozu er auch Kenntnis vom Schlüssel haben müßte. Das 
würde die Sache in meinen Augen extrem anfällig gegen Angriffe machen. 
Ich könnte mir vorstellen, die Blockgröße von vorn herein auf ein 
erträgliches Maß, wie eine Flash-Page, zu reduzieren. Das würde zwar die 
Übertragung langsamer machen, aber man könnte fehlerhafte Blöcke 
einfacher wiederholen. Dazu würde man das Feedback Register der XTEA 
Entschlüsselung im MC vor jeden neuen Block zwischenspeichern und bei 
einer Blockwiederholung auf diesen alten Wert zurück setzen.

[Simon (Gast)]

Hallo,
ich würde gerne nur bei der TX Leitung den Pegel invertieren.
Weiß jemand, ob das problemlos änderbar ist ohne die 512kB Grenze zu 
sprengen?
Kann mir jemand bezüglich der nötigen Änderung auf die Sprünge helfen?
Vielen Dank, Simon

[Thomas (Gast)]

Hallo in die Runde,
Es wurden ja hier schon einige Fehlersituationen bei der Verwendung des 
AVRootloaders diskutiert und dank Hagens und Eurer tatkräftigen Hilfe 
auch oft gelöst. Nachdem ich nach Studium des kompletten Thread und der 
Nachbarthreads meine auftretende Fehlermeldung nicht finden konnte, 
möchte ich um Tipps für mein Problem bitten...

Ich habe den AVRootloader per 1-wire an einem attiny85 zum Flashen der 
Betriebssoftware eines Lokdecoders (Modellbahn) an einer herkömmlichen 
seriellen Schnittstelle (9pol.) im Einsatz. Die Verbindung zum Win98SE 
Rechner mittels Avrootloader.exe klappt stabil. Microcontoller Infos 
werden problemlos ausgelesen und verstanden. Will ich aber flashen, 
Eeprom löschen, lesen oder schreiben, oder sonst den Inhalt des Chips 
manipulieren, bricht der Vorgang mit der Meldung "Overlapped I/O event 
object not in signaled state: win32 error 996".

Ich habe schon herumgespielt:
-alle timeouts in alle Richtungen verändert
-Den Com Port mit anderem Handshake und Buffer Einstellungen in der 
Systemsteuerung versehen
- andere Widerstände in die tx-Leitung
- andere Stromversorgung des MC
- alle Avrootloader Versionen von 3 bis 6 ausprobiert
- den MC zu unterschiedlichen Phasen des Verbindungsvorgangs 
eingeschalten.

Es hat alles keine merkliche Veränderung ergeben, und ich nage bereits 
an der Tischkante. Hat noch jemand hier eine Idee, auf welchem Schlauch 
ich wohl stehe?

Danke für die freundliche Beachtung meiner Frage und Gruss,
Thomas.

[Julinho (Gast)]

Vielleicht liegt es an WIN89se?

Mit WIn7 habe ich ein Tiny85 schon tausende Male im 1-wire Modus 
geflasht.

[Charly B. (charly)]

vllcht mal mit anderem OS testen, i verwende auch
1Wire und W7-64 und funktioniert bestens

VlG
Charly

[Thomas (Gast)]

Guten Morgen Julinho und Charly,

Das werd ich mal testen, alle anderen Rechner bei mir hatten bloss kein 
RS232. Jetzt muss erstmal ein Adapter zu Usb her, oder der alte Rechner 
kriegt Vista aufgespielt (bei Win7 macht er wahrscheinlich die 
Grätsche).

Danke, Thomas.

[Charly B. (charly)]

Hi Thomas,
i verwende machmal den usb2seriell mit dem CH340 unter W7
geht damit 1wire mit 38400, ABER nicht am HUB

VlG
Charly

[Thomas (Gast)]

Hallo,

Kurze Rückmeldung von mir! Ich habe auf besagtem betagten Rechner WinXP 
aufgespielt, da mir Vista zu suspekt war. Was soll ich sagen, der 
Avrootloader funktioniert tadellos, als wäre es nie anders gewesen! 
Daher: vielen lieben Dank nochmals für die Anregung :-) .

Allseits schönes Wochenende,
Gruß Thomas

[Thomas P. (topla)]

Hallo an alle AVRootloader-Kundigen,

nachdem das Thema AVRootloader und ATMega2560 bei mir längere Zeit 
liegen geblieben ist, steht es nun wieder auf der Tagesordnung. Da die 
vorhandene Hardware böderweise so designt ist, dass der Bootloader über 
den Port H des ATMega2560 angesprochen werden muss, habe ich erstmal den 
Code auf Portadressen über 0xff angepasst und die damit verbundene 
Änderung des Timings in der AVRootloader.asm vorgenommen.

Für die ersten Versuche habe ich auf Verschlüsselung verzichtet, also in 
der AVRootloader.ini Passwort auf blank gesetzt.

Der AVRootloader ist in den ATMega2560 geflasht und die Fuses sind 
entsprechend gesetzt (siehe Anhang).

Über die LockBits sind keinerlei Einschränkungen programmiert.

Nach dem Start der AVRootloader.exe kann ich mich mit dem ATMega2560 
verbinden und die Device-Informationen auslesen, auch das Auslesen aus 
dem SRAM und dem EEPROM funktioniert. Damit sollten doch die 
grundlegenden Funktionen in Ordnung sein.

Leider funktioniert das Schreiben nicht. Beim Versuch, den EEPROM mit 
einem geänderten Byte zu beschreiben, gibt es den Fehler:
Cmd.WriteEeprom.ReadByte() ICOM: read error
mit anschließendem
Device disconnected.
In der AVRootloader.ini ist
Buffer = 1
Base = 100
gesetzt.

Beim Ändern eines Bytes des SRAM-Bereichs führt das Schreiben zwar nicht 
zum Abbruch, wird aber auch nicht ausgeführt; der ursprüngliche Wert 
wird beim nächsten Read wieder angezeigt.

Kann mir da bitte jemand weiterhelfen?

Thomas

[Georg (Gast)]

Hallo und guten Tag,
nach längerer Abwesenheit wollte ich mal fragen ob an dem AVRootloader 
weiter gearbeitet wurde oder ob jemand das Projekt weiter geführt hat.

Speziell interessiert mich die Möglichkeit der Verschlüsselung 
(Herstellung des ACY File) ohne das der Zielmicrocontroller eine 
Verbindung zur Windows Software hat.

Danke Euch.... eine echte Supper Software die mich bis heute begleitet 
und noch nie im Stich gelassen hat.

[Wilhelm M. (wimalopaan)]

Ich kann Dir nur dies empfehlen:

http://jtxp.org/tech/onewayloader.htm

[Georg (Gast)]

Hallo Wilhelm,
ich benutze den AVRootloader 6.0 für eine Anwendung in die auch für 
Grundeinstellungen das EEprom eingebunden ist. Wenn die ACY Datei und 
die eep über den AVRootloader aufgespielt sind ist die Anwendung quasi 
in der Grundeinstellung.

1. Schritt
Andere Parameter in der Grundeinstellung einstellen.
So benutze ich den AVRootloader, stelle connect zum AVR (ATMega1248p) 
her und lese das unverschlüsselte EEprom aus, speichere es auf dem 
Rechner zwischen.

2.Schritt
Mit einer auf Delphi geschriebenen separaten Software verändere ich die 
einzelnen Byte in der Eprom Datei. Die Änderung wird visualisiert und 
ist so besser und übersichtlicher einstellbar.
Siehe Anhang Software.... in der untersten Zeile siehst du was durch die 
Visualisierung geändert wird (nur wenn das Dummy File im gleichen 
Verzeichnis ist). Quasi in der ersten/zweiten Zeile des EEpromspeichers.
Danach wird das veränderte EEProm File auf dem Rechner zwischen 
gespeichert.

3. Schritt
ich rufe abermals den AVRootloader auf, connectier und spiele das neue 
EEprom File auf.

Diesen Ablauf: Auslesen der EEpromdatei, verändern und wieder aufspielen 
möchte ich gerne in einer Software erledigen. Die Verschlüsselung des 
EEpromfiles wäre geil aber nicht unbedingt notwendig.

Richtig gut würde es wenn die Software nur mit dem passenden zuvor 
eingestellten AVR mit dem Schlüssel funktioniert. Der Schritt käme aber 
erst als zweites

DANKE !

[Georg (Gast)]

Hallo und guten Morgen zusammen,
ich arbeite mit einem ATMega1284p -> USB Seriell FT232 -> Win7 Notebook.
Die Programmierung mit der AVRootloader Software funktioniert ebenfalls 
mit einem ATTiny44 und Attiny45 tadellos so richtig klasse. Sowohl mit 
externem und internem Takt.

Da ich wie im letzten Post geschrieben zwei Softwaren mit einander 
verbinden will habe ich mir in den letzten 4 Tagen die Delphi 
Testsoftware aus dem Beispiel des AVRootloaders 6 vorgenommen um mich in 
die Sourcen einzuarbeiten.

In diesen 4 Tagen habe ich Stunde um Stunde mit der Delphi Testsoftware 
für die Anbindung eines AVR an den PC verbracht. Der Verbindungsversuch 
wird in dem Memofeld dargestellt.

Ich kann auch erkennen das der PC zunächst ein paar Einstellungswerte 
sendet und dann zwei sich wiederholende Zeichenketten sendet.
Zeile 1: FF FF FF und so weiter und in der zweiten Zeile sendet er unter 
anderen nach den FF FF den BootMSG "Bootloader"..... bis die Software 
nach zig versuchen abbricht.

Screenshot folgt....

Nur scheint der AVR nicht zu antworten.

Hat einer Erfahrungen mit der Testsoftware oder kann mir einen Tipp 
geben ? ob wohl das Thema uralt ist
Ich werde mal weiter forschen und schauen ob die Baudraten zueinander 
passen, obwohl sie identisch eingestellt sind.

Ok.... danke für die Mühe

[Charly B. (charly)]

Hi,

hat jemand den Bootloader auf dem mega1284p mit 1wire am laufen?,
habe ihn schon auf diversen anderen Type schon am laufe, aber
der m1284p will nicht.
Konfigutation: 1wire an portb.3, m1284p-mu mit 20Mhz, Baud fix
19200

hab mit dem oszi geschaut, die v24 seite zappelt, vom mega
kommt nix.
ein testprg das den pb.3 zappeln laesst funktioniert auch.
clk/8 ist auch deaktiviert.

vlG
Charly

[Charly B. (charly)]

wie's aussieht liest ja hier keiner mehr mit............... ;(

falls sich doch jemand mal hierher verirrt hab i folgendes gemacht:
hauptproblem war der usb-ser wandler mit CH340 (und/oder sein Treiber)
auch musste i UseUartInvert = 1 setzen obwohl kein max232 o.ae.
dazwischen sitzt .........., dann konnt i zwar mit dem CH340 eine
Verbindung aufbauen, auch EEprom lesen ging anscheinend aber weder EE
noch Flash konnten beschrieben werden......

dann hab i den CH340 wandler gegen einen mit PL2303 getauscht und schon
war ein schreiben des EE und Flash moeglich, dann hatte ich autobaud
eingeschaltet und es funktioniert auch mit versch. Baudraten.

Mit dem Oszi* beobachtet sehen die Signale des PL2303 steiler aus,
haben aber bei high einen ca 1V grossen rippel drauf mit ca. 250khz
das ist beim CH340 nicht da sehen die Signale aber 'schlapper' aus....

* Oszi ist nur ein HDS2062M ist also nicht so super von der Aufloesung

ps. ich meine ich haette frueher schon mit dem CH340 erfolgreich
geflasht......

vlG
Charly

[Georg (Gast)]

Hallo Charly, na klar lese ich noch mit.
ich möchte immer noch die AVRootloader.dll in eine eigene Anwendung 
einbinden und bekomme da die Verbindung zum AVR nicht auf die Kette. Die 
Demo Delphi Anwendung die dabei ist stellt bei mir keine Verbindung zum 
AVR her.

Also wenn ich etwas helfen kann immer gerne.
Ich habe einen.... mehrere ATMega1284P mit 18,432 MHz (zusammen mit zwei 
MCP 2515) aber in 2 Wire laufen.
Die Verbindung läuft allerdings über den Rx0 und Tx0 an PD0 und PD1. 
Mein USB RS232 Wandler ist auch ein FDTI RL232. Die Baudrate habe ich 
fest auf 38400 eingestellt und die UseUartInvert = 1 steht wie bei dir. 
Die Schnittstelle benutze ich sonst nur für Debug Ausgaben.
Eingestellt habe ich Flash verschlüsselt und Eprom ohne. Wenn du dir das 
Programm weiter oben anschaust weißt du warum. Wenn du den Code vom 
AVRootloader sehen möchtest kopiere ich dir den gerne hier ein oder die 
ganze Codedatei.

Läuft soweit alles einwandfrei. Win 7 x64

Wenn ich am Wochenende dazu komme probiere ich auch gerne mal deine 
Konfiguration.


Jetzt kommt das aber. In der Doku zum AVRootloader steht wie man den RTS 
Pin für den Reset des AVR benutzen kann und wie man ihn einstellt. So 
habe ich mir zu den Breakout usb rs232 (weil einfach schön klein und 
passt wunderbar Huckepack auf den AVR) noch einen anderen gekauft der 
diesen RTS Pin besitzt. Leider funktioniert der RTS Pin wie der DTR Pin 
an den Breakout... also bei öffnen der Schnittstelle wird der Pin auf 
Masse gezogen und Ende...... sehr  unzufrieden, den Dauerreset braucht 
kein Mensch.
Eigentlich möchte ich nur die Bedienung des AVRootloader möglichst 
einfach für den Endanwender gestallten.
Das Programm (weiter oben) habe ich mitlerweile so erweitert das ich aus 
meinem Programm den AVRootloader mit Parametern aufrufe und so ohne 
große Umstände das Eprom File in den AVR bekomme. Das funktioniert auch 
echt 1A, nur den Rest bekam ich, so wie beschrieben, zunächst nicht hin.
So habe ich mir mit einem zusätzlichen kleinen ATTiny aus dem DTR Signal 
des Breakout einen Restbaustein gebastelt. Etwas Aufwand aber besser so 
als einen teuren USB RS232 Wandler zu nutzen an dem der RTS auch nicht 
geht.

[Charly B. (charly)]

Georg schrieb:
>............
> Jetzt kommt das aber. In der Doku zum AVRootloader steht wie man den RTS
> Pin für den Reset des AVR benutzen kann und wie man ihn einstellt. So
> habe ich mir zu den Breakout usb rs232 (weil einfach schön klein und
> passt wunderbar Huckepack auf den AVR) noch einen anderen gekauft der
> diesen RTS Pin besitzt. Leider funktioniert der RTS Pin wie der DTR Pin
> an den Breakout... also bei öffnen der Schnittstelle wird der Pin auf
> Masse gezogen und Ende...... sehr  unzufrieden, den Dauerreset braucht
> kein Mensch.

ich hatte vor Jahren (ca. am anfang der Veroeffentlichung) schon den BL 
mit Wire und Reset im Betrieb also 3 Leitungen und das hat bestens 
funktioniert, zu RTS hatte i ein C in reihe, 220nF wenn i mich richtig 
erriner, wenn's dich interessiert kann i mal schauen ob i noch was an 
Unterlagen habe. Am AVR waren meines wissens am Reset 10k nach VCC mit 
paraleller Diode und 100nF nach GND, hoffe i hab mich verstaendlich 
genug ausgedrueckt. I meine i haette 'damals' sogar eine kleine Platine 
als Huke-Pack f. den USB-Ser Wandler fertigen lassen, wenn du magst 
kannste mir auch deine email per PN schicken wenn i da noch was fine 
mail i es dir

vlG

nachtrag: 
Beitrag "Re: AVR-Bootloader mit Verschlüsselung"

[Georg (Gast)]

Hallo Charly,
jawoll das interessiert mich sogar brennend.
Ich melde mich mal an. (schorschi)
Ja, hast dich verständlich ausgedrückt, ich hatte es mal mit der Arduino 
Variante versucht, aber beim Arduino haben die wohl nicht den 10K 
(Reset-VCC). Scheinbar geht es deshalb beim Arduino. Ich werde aber auf 
den 10K an der Position und dem 100nf Ceramik zur Entstörung nicht 
verzichten.

Bin gespannt auf deine Schaltung.
LG

[Georg B. (schorschi)]

So.... hier kannst du mir was an meine Email Adresse schicken.

LG

[Schorsch (Gast)]

Hallo zusammen,
ich nutze den Avrootloader nun schon einige Jahre für meine ATTiny 85 
Projekte. Für meine aktuellen Basteleien möchte ich einen der "neuen" 
Tinys (Series 1), den ATTINY1614,  nutzen. Hat schon mal jemand probiert 
den Avrootloader entsprechend anzupassen (kein SPM sondern NVMCONTROLLER 
) oder evtl. nach C zu portieren?

Gruß Schorsch

[Pluggie (Gast)]

Hat der Attiny 1614 nicht eh schon UPDI, also Programmierung über eine 
Leitung?
Oder benötigst du die Verschlüsselung?

[Schorsch (Gast)]

Hallo Pluggie,

ja, der ATTiny1614 hat UPDI, aber ich nutze die verschiedenen 
Möglichkeiten die mir der AVRootloader im Frontend bietet: 
Versionierung, Verschlüsselung, Editieren des EEProm.

Gruß Schorsch

[Ronald P. (ronald_p)]

Hallo Forum, hallo Leute
Immer wenn ich hier was schreibe, dann hackt es mit etwas.
Jetzt muss ich doch leider diese alt Kamelle aus der Versenkung holen.
Da der Bootlader mir schon öfters ein paar Drähte gespart hat, wie auch 
hier.
Frage:
Hat es schon mal jemand geschafft einen Tiny1634 zu Programmieren?
Es funktioniert bis zum Programmieren alles tadellos.
Nur jetzt bleib ich an den ">Error: Can not find RJMP to Main" hängen.
Seltsamerweise gibt es nur mit den 1634 Ärger, alle anderen Tiny's 
funktionieren TOP.
Ich hab schon alles mögliche probiert Bascom (net meckern) den 
Lösungsvorschlag

.org 0
  rjmp Main
Main:

beizubringen, aber die Fehlermeldung bleibt hartnäckig.

Wäre für einen kleinen 'Anstubser' sehr glücklich.

Danke schön
Beste Grüße
Ronnie

[Julian B. (julinho)]

zitiere mal eine alten Beitrag siehe oben:

"Das Problem ist, dass bei Tinys mit 16kByte Flash nicht jede Adresse 
mit
RJMP erreichbar ist. Deswegen benutzt der Compiler wahrscheinlich den
JMP-Befehl.
Entweder man erzwingt durch Inline-Assembler einen RJMP, oder Hagen muß
das PC-Programm modifizieren."

[Gerd H. (gerd02)]

Hallo Ronald,

vielleicht ist ja das Programm für Dich hilfreich.

http://www.jtxp.org/tech/onewayloader.htm

Mfg
Gerd

[Wilhelm M. (wimalopaan)]

Gerd H. schrieb:
> Hallo Ronald,
>
> vielleicht ist ja das Programm für Dich hilfreich.
>
> http://www.jtxp.org/tech/onewayloader.htm

Ich denke nicht, sonst hätte er ja schon vor langer Zeit darauf 
reagiert:

Beitrag "Re: AVR-Bootloader mit Verschlüsselung"

[Ronald P. (ronald_p)]

Danke euch schon mal.

Gerd H. schrieb:
> Hallo Ronald,
>
> vielleicht ist ja das Programm für Dich hilfreich.
>
> http://www.jtxp.org/tech/onewayloader.htm
>
> Mfg
> Gerd

Gerd,
eigentlich bin ich ja mit Hagen's Bootlader total zufrieden und weis 
auch wie ich alles zum funktionieren bekomm, aber ich werde mir die 
Lektüre mal reinziehen.


Julian B. schrieb:
> zitiere mal eine alten Beitrag siehe oben:
>
> "Das Problem ist, dass bei Tinys mit 16kByte Flash nicht jede Adresse
> mit
> RJMP erreichbar ist. Deswegen benutzt der Compiler wahrscheinlich den
> JMP-Befehl.
> Entweder man erzwingt durch Inline-Assembler einen RJMP, oder Hagen muß
> das PC-Programm modifizieren."

Julian,
Opps, den alten Beitrag hab ich wohl übersehen..
Hab ich ja schon damit herum probiert, wird aber scheinbar nix.
Naja, ich glaub nicht das Hagen nur weil der 1634 nicht geht, an dem 
Programm noch was ändert.
Funktioniert ja TOP
Werde alles auf einen 328 umbauen, da hab ich noch ein paar im MU 
Gehäuse.
Sind zwar total überdimensioniert und auch leicht größer als die 1634 im 
MU
Aber da ist dann auch noch Luft nach oben und ein paar pin's mehr :))

Seit mir gegrüßt, bist zum nächsten Problemchen.

Ronnie

[Gerd H. (gerd02)]

Hallo Wilhelm,

das Programm hatte ein Update, 03.2021.
Ronald wollte es sich ja anschauen.

Zitat aus" http://www.jtxp.org/tech/onewayloader.htm "

Der One-Way-Loader unterstützt aktuell die folgenden AVR-Controller:
m1280 m1281 m1284 m1284P m128A m128 m128RFA1 m128RFR2 m162 m164A m164PA 
m164P m165A m165PA m165P m168A m168 m168PA m168P m169A m169PA m169P m16A 
m16 m16HVA m16HVB m16M1 m16U2 m16U4 m2560 m2561 m256RFR2 m324A m324PA 
m324P m3250A m3250 m3250PA m3250P m325A m325 m325PA m325P m328 m328PB 
m328P m3290A m3290 m3290PA m3290P m329A m329 m329PA m329P m32A m32C1 m32 
m32HVB m32M1 m32U2 m32U4 m406 m48A m48 m48PA m48P m640 m644A m644 m644PA 
m644P m6450A m6450 m6450P m645A m645 m645P m6490A m6490 m6490P m649A 
m649 m649P m64A m64C1 m64 m64M1 m64RFR2 m8515 m8535 m88A m88 m88PA m88P 
m8A m8 m8HVA m8U2 tn13A tn13 tn1634 tn167 tn2313A tn2313 tn24A tn24 tn25 
tn261A tn261 tn4313 tn441 tn44A tn44 tn45 tn461A tn461 tn48 tn80 tn840 
tn841 tn84A tn84 tn85 tn861A tn861 tn87 tn88

MfG
Gerd

[Ronald P. (ronald_p)]

Hallo,
also ich hab mir den OWL mal angesehen.
Da zieh ich aber den Hagen seinen wegen der Progammieroberfläche vor.
Außerdem hab ich 2std damit herum probiert, mit 0 Erfolg.
Das generieren des Bootladers funktioniert.
Auch das speichern in den target scheint zu klappen (da sitzt was fein 
am ende vom target)
Fuses gesetzt, es wird auch etwas Richtung target geschickt, wird aber 
nicht
gespeichert.
Das target bleibt leer (der Bootlader ist aber weiterhin vorhanden und 
nicht überschrieben)
Nicht schön finde ich das Programmiert wird, obwohl kein target 
angeschlossen ist.
Sei's wies sei, Kommandozeilen hin oder her, ist mir zu umständlich.
Hier sei auf den 2. Satz verwiesen.

Grüßle
Ronnie

[Gerd H. (gerd02)]

Hallo Ronald,

schade das es nicht so gut geklappt hat.
Hier" http://cvieth.bplaced.net/elektronik_atmel_bootloader.html ",
hat Christian alles mal zusammengefasst, und wenn mann höflich anfragt, 
bekommt man eine gute Windows-Gui.
Mfg Gerd

[Ronald P. (ronald_p)]

NA, HOPPERLA.. OHOH

Nach der tollen Erklärung von Christian, bin ich vielleicht auf meinen 
Problem  gestoßen.

Firmware kodieren
owl.exe --targetname=owl_loader_m168pb_d0.hex --flashfile=Test_1.hex 
--transfile=Test_1.hex
CHECK!

Kodierte Firmware übertragen
owl.exe --transfile=Test_1_owl_loader_m168pb_d0.owl --serialport=COM8 
--baud=9600
CHECK!

Fehler 1, ich hab die Endung .owl nicht angegeben, wobei ich meinen das 
es die nicht braucht.

ABER! Das Haupding könnte USB Adapter sein, wie Christian auch seine 
Fehlversuche beschrieben hat.
Werde Morgen nochmal rangehen und mit einen FTDI Basierten Wandler 
ausprobieren. Ist alles schlüssig, große Datei die den Tiny fast 
vollpackt.

gut's Nächtla
Ronnie

[Ronald P. (ronald_p)]

Von wegen 'Gut's Nächtla' ;)
Das hat mir jetzt keine Ruhe gelassen und JA! es funktioniert! JUHU
Es war tatsächlich an dem USB Adapter gelegen!
Hatte mit dem Teil und dem Lader von Hagen nie Probleme.
Aber mit dem FTDI Chip funktionierte es beim ersten Versuch.
Ich glaub ich kann mich mit dem Teil doch noch anfreunden!
Wobei ich eine Funktion schmerzlich vermisse und zwar das EP zu lesen.
Da steht bei mir immer eine Version Nr. drin damit es keine 
Verwechslungen gibt. Hatte da schon die wildesten Erfahrungen mit falsch 
geflashten Files.
Später werd ich mir ein schönes Glas Honig besorgen und den Christian 
mal Kontaktieren. :))
Jetzt aber
'Gut's Nächtla'
Ronnie

[Gerd H. (gerd02)]

Hallo Ronald,

bei mir hat auch die Übertragung des Programmes mit einfachen 
RS232/PC817 und mit PL2303/PC817 funktioniert.

Bei der Verwendung von Seriennummer/Zuordnungen, Zitat:
" http://www.jtxp.org/tech/onewayloader.htm ==>>
Die Verwendung von Krypto bringt neben dem Schutz der Daten vor 
neugierigen Blicken und der zuverlässigen Erkennung von 
Übertragungsfehlern noch weitere
Vorteile: Starke kryptografische Schlüssel werden nach dem 
Zufallsprinzip erzeugt. Auf diese Weise bekommt jeder Krypto-Bootloader 
schon bei "Geburt" eine
einzigartige Geräteadresse (im Sinne einer UUID) zugeteilt, und wir 
müssen uns später nie wieder mit Passwort-Phantasie-Problemen und 
möglichen Kollisionen
herumschlagen."

MfG
Gerd

[NixSchwabe (Gast)]

Ronald P. schrieb:
> 'Gut's Nächtla'

Ich "hasse" Schwaben, diese kulturfremdelnden u. stumpfsinnigen 
Arbeitsroboter bzw. -sklaven!

[Ronald P. (ronald_p)]

Gerd,
irgendwie werde ich mit dem Teil nicht wirklich warm.
Irgendwas mach ich falsch.
Ein Bootlader steht für mich jetzt einmal im Controller (for ever).
So, dann flash ich mein Programm, gut geht läuft.
Jetzt mach ich eine Änderung im Programm benenne es so wie das vorherige
aber Pustekuchen, es wird zwar was übertragen (LED am FTDI und owl zählt 
auch schön hoch, leider bleibt immer das allererste übertragene 
bestehen.
Der überschreibt den Flash nicht. Auch der Parameter --flasherase bringt 
nix.

Es macht mich einfach nervös, wenn ich mich nicht auf Sachen verlassen 
kann, zumal man nicht mehr an den Controller rankommt weil er vergossen 
ist.

Ronnie

PS: NixSchwabe (Gast) Du bist auch so ein seltsamer Vogel den die Welt 
nicht braucht!
Wem glaubst interessiert dein stumpfsinnige Meinung!

[Gerd H. (gerd02)]

Hallo Ronald,

es muss natürlich 100% passen.
Hast Du Christian mal nach der Win-GUI gefragt?
Probiere mal das Beispiel aus der Schnellstart-Anleitung mit 
verschiedenen Blink-Frequenzen und vielleicht einer Batch-Datei.
MfG
Gerd

[Ronald P. (ronald_p)]

Hi Gerd,
nein noch nicht, mach ich aber jetzt :)

[Ronald P. (ronald_p)]

SO!,
jetzt hab ich meinen Weg gefunden.
Alles funktioniert bestens, jetzt!
Mein Hauptfehler war das ich den Reset zu früh gedrückt hab, da war der 
Timeout vom Bootlader schon durch bis das senden losging.
Eine Fehlermeldung kann es ja in dem Fall nicht geben.
Die GUI vom Christian habe ich bekommen, Danke noch mal an dieser 
Stelle.
Da ich auch EEProm schreibe, hab ich mir die Zeilen für die Konsole als 
REM in den Programmcode Kopiert COPY & PASTE fertig.

Ich werde aber dem Loader vom Hagen treu bleiben, ist einfach 
Komfortabler.

Dank nochmal an alle Beteiligten.
Auch an den seltsamen Vogel, obwohl ich garnet aus der Ecke komme. :)

Grüssle (NA!)
Ronnie