Forum: Projekte & Code AVR-Bootloader mit Verschlüsselung

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

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

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

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

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

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

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

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

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

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

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

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:

1

pi@raspi1:% avrootloader -p /dev/ttyUSB1 -c "baud=115200 parity=N data=8 stop=1" -f bkb5.hex -e bkb5.eep

2

avrootloader (LINUX): start...

3

...

4

Opened serial port /dev/ttyUSB1 ...

5

Catching Bootloader ... 97 05 06 04 30  success!

6

Uploading File bkb5.hex (20020 Bytes) to Flash...

7

Upload succeded.

8

Uploading File bkb5.eep (42 Bytes) to EEPROM...

9

Upload succeded.

10

...

11

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.

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:

1

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

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:

1

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

2

3

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

4

5

 00 00 00 00 00 00 00 00 00 0D 3C 72 65 73 74 3E   ..........<rest>

6

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

7

 74 3E 74 F0                                       t>tð            

8

9

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

10

11

 97 05 06 04 30                                    ?...0

12

...              

13

14

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

15

16

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

17

18

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

19

20

 30                                                0

21

22

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

23

24

 FE 00 36 00 26 48 0C 94 B0 01 0C 94 CF 01 0C 94   þ.6.&H.?°..?Ï..?

25

 93 09 0C 94 CF 01 0C 94 CF 01 0C 94 CF 01 0C 94   ?..?Ï..?Ï..?Ï..?

26

 ... 861 (!) Zeilen später ...

27

 4F 92 5F 92 6F 92 7F 92 8F 92 9F 92 AF 92 BF 92   O?_?o?????¯?¿?

28

 CF 92 DF 92 EF 92 7D F8                           Ï?ß?ï?}ø        

29

30

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

31

32

 30                                                0               

33

34

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

35

36

 01 01 C0 50                                       ..ÀP

37

38

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

39

40

 30                                                0

41

42

...

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:

1

Connection                     : 2-Wire

2

Device name                    : ATmega1284P

3

Device signature               : 1E9705

4

SRAM size                      :  16384 Byte

5

EEPROM size                    :   4096 Byte

6

FLASH size                     : 131072 Byte

7

FLASH size for application     : 130048 Byte

8

FLASH pagesize                 :    256 Byte

9

Bootloader size                :   1024 Byte

10

Buffersize for data            :  16152 Byte

11

SRAM start address             :    256

12

Bootloader version             :      6

13

Use bootsection                :    Yes

14

Versioning supported           :     No

15

Cryptography supported         :     No

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

1

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.

> 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

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

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

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.

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.

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

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

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

1

pi@raspi1% ./run.sh

2

avrootloader (LINUX): start...

3

avrootloader - upload settings:

4

- Portname  : /dev/ttyUSB1

5

- Portconfig: baud=115200 parity=N data=8 stop=1

6

- Flashfile : ./test/bkb5.hex

7

- Eepromfile: ./test/bkb5.eep

8

- Trigger   : <rest>

9

Opened serial port /dev/ttyUSB1 (baud=115200 parity=N data=8 stop=1) handle=3.

10

Catching Bootloader ... \ 97 05 06 04 30  success!

11

Device name                    : ATmega1284P

12

Device signature               : 1e9705

13

SRAM size                      :  16384 Byte

14

EEPROM size                    :   4096 Byte

15

FLASH size                     : 131072 Byte

16

FLASH pagesize                 :    256 Byte

17

Buffersize for data            :  16152 Byte

18

Uploading File ./test/bkb5.hex (20020 Bytes) to Flash...

19

Upload succeded.

20

Uploading File ./test/bkb5.eep (42 Bytes) to EEPROM...

21

Upload succeded.

22

Hit any Key to exit Bootloader mode...

23

Exiting Bootloader, Starting Firmware.

24

Closed serial port.

25

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:

1

  /*

2

  if (flashfile == NULL)

3

  {

4

    static char ffn_buf[FILENAME_MAX];

5

    flashfile = openfiledialog("Select Flash File", ffn_buf, sizeof(ffn_buf));

6

  }

7

8

  if (eepfile == NULL)

9

  {

10

    static char efn_buf[FILENAME_MAX];

11

    eepfile = openfiledialog("Select EEPROM File", efn_buf, sizeof(efn_buf));

12

  }

13

  */

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

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

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

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

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

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

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

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

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

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:

1

wdt_enable(WDTO_15MS);

2

while(1);

wenn ich die Option

1

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?

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

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

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.

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

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

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.

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

Gruß Ingo

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.

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.

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:

1

.macro  jmpapp

2

.if BLS

3

    rjmp  FLASHEND +1  ; run application

in:

1

.macro  jmpapp

2

.if BLS

3

    jmp  FLASHEND +1  ; run application

geändert.

Grüße

Ralf

Ja, geht :)

Hallo zusammen,

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

Thomas

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

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.

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.

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

VlG
Charly

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

VlG
Charly

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

Ich kann Dir nur dies empfehlen:

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

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

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

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

LG

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

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

Hallo Ronald,

vielleicht ist ja das Programm für Dich hilfreich.

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

Mfg
Gerd

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"

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

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

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

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

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

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

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

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!

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

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

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