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

Na da hab ich ja meine korrigierte Watchdogfunktion grad noch 
rechtzeitig gepostet.


Peter

@Peter: Ich habe sie nach Datenblatt des ATTiny461 und ATMega88-168 
programmiert. Ist sie etwa falsch ?

@Gast: Ja ist Delphi 5. Der HEX-Editor ist von Mirkes.de wobei ich 
diesen nur empfehlen kann weil es der einzigste freie für Delphi auf dem 
Markt ist.
COM Port Zugriff habe ich in eigenes Objekt implementiert und benutzt 
Overlapped-IO.

Gruß Hagen

Sieht gut aus. Noch ne Kleinigkeit, was für Z-Dioden verwendest du im 
Schaltplan? Steht nur die Bauteilnummerierung dran...

Werner

@Werner,
BAT54C sind SMD in SOT23, keine Z-Dioden, sind Schottky Dioden. Ist 
eventuell beim Eagle Symbol nicht so gut erkennebar ?!
Wichtig ist der 2k Widerstand, bei Peters Bootloader wurde dort ein 4k7 
angegeben. Ich habe diese bei meinen Tests mit ATmega128, ATmega168 und 
ATtiny461 dann auf 2k reduziert. Als RS232 habe ich die RS232 meines 
Laptops, der Dockingstation des Laptops und ein USB-RS232.Kabel 
getestet. Mit dem 2k ging es besser, aber ich benutze auf AVR Seite ja 
auch nur den interne PullUp statt einem externen. Das hat dann alles 
funktioniert mit Baudrate von 600 bis 256000 Baud, vorrausgesetzt der 
Takt des AVRs ist hoch genug für die hohen Baudraten. Den ATtiny461 habe 
ich mit internem RC Oszillator + PLL laufen, sind dann 16MHz. Den 
ATMega128 mit externem Quarz bei 15.97MHz.

@Peter,
ich habe noch mal in das ATmega168 Datenblatt geschaut und ich meine das 
ich keinen Fehler mit dem Watchdog gemacht habe. Im Datenblatt Seite 48 
ist exakt die Sequenz angegeben die ich auch benutzt habe, eben mit dem 
Unterschied das WDE über die ODER Verknüpfung gesetzt wird, ist auf 
Seiet 47 ebenfalls beschrieben.

Testen konnte ich den WatchDog eben nur für die genannten 3 AVRs und da 
hat er funktioniert.

Nur beim ATTiny461 sind par Ungereimtheiten die aber nichts direkt damit 
zu tuen haben. Wenn man bei dem Teil die WDTON Fuse setzt und dann 
wieder löscht so wird der WatchDog solange mit ständig gesetzem WDE Bit 
laufen bis man dem AVR den Saft abdreht. Ein RESET setzt das WDE Bit 
noch lange nicht zurück. Anderst ausgedrückt: löscht man die WDTON Fuse 
dann muß man dem AVR den Saft abdrehen damit das auch eine Wirkung 
erzielt. Ein einfaches RESET reicht nicht aus. Dh. nach dem Löschen von 
WDTON verhält sich der AVR noch solange als ob WDTON gesetzt ist bis er 
keinen Saft mehr hat !! Das hat mich Stunden an Fehlersuche gekostet und 
ich war schon der Meinung ich habe den ATTiny461 geschrottet.


Gruß Hagen

Hagen Re wrote:

> @Peter,
> ich habe noch mal in das ATmega168 Datenblatt geschaut und ich meine das
> ich keinen Fehler mit dem Watchdog gemacht habe.

Hab ich ja nicht behauptet, sondern das es die gleiche Sequenz ist, die 
ich als letztes gepostet hatte. Sie sollte daher funktionieren.

Ich hatte vorher ne andere, die nicht funktioniert hat.
Man darf beim ersten Schreiben nicht die WDP-Bits anders setzen, dann 
wirds ignoriert.
Steht aber nirgends im Datenblatt. Hat mich auch einige Zeit gekostet.


Den Rest des Codes habe ich noch nicht verdaut.
Ich hab da immer Probleme mit so großen monolitischen Brocken, daher 
unterteile ich gerne alles in kleine Häppchen. Auch wenn dann vielleicht 
ein paar CALLs und RETs mehr an Code entstehen.

Dein Code ist ja auch äußerst sparsam kommentiert.
Die Umleitung des Bootloader-Reset bei den ATtinyxxx/ATmega48 machst Du 
vermutlich schon in der EXE.
Ich habs deswegen im AVR gemacht, damit selbst bei Empfangsfehlern kein 
Aussperren möglich ist. Ist ja auch nicht viel Code.
Zumindest das Löschen sollte aber von oben nach unten erfolgen.


Peter

Hi Peter,

>Ich hatte vorher ne andere, die nicht funktioniert hat.
>Man darf beim ersten Schreiben nicht die WDP-Bits anders setzen, dann
>wirds ignoriert. Steht aber nirgends im Datenblatt.

Hm das es ignoriert werden soll wusste ich auch nicht. In irgendeinem 
der Datenblätter steht aber das man die WDP Bits erst setzen sollte wenn 
man vorher das WDCE Bit einmalig gesetzt hat da ansonsten der WatchDog 
Prescaler  beim Verkürzen der Zeitspanne schon vorzeitig auslössen 
könnte.

>Den Rest des Codes habe ich noch nicht verdaut.
>Ich hab da immer Probleme mit so großen monolitischen Brocken, daher
>unterteile ich gerne alles in kleine Häppchen. Auch wenn dann vielleicht
>ein paar CALLs und RETs mehr an Code entstehen.

Ja verstehe ich. Der Bootloader sollte so kompakt wie möglich werden und 
da sind Optimierungen über die einzelnen Blöcke hinaus manchmal 
notwendig. Es ist schon blöde wenn wegen 2 Bytes zuviel an Code der 
Bootloader eine ganze FLASH Page mehr benötigt.

>Dein Code ist ja auch äußerst sparsam kommentiert.
>Die Umleitung des Bootloader-Reset bei den ATtinyxxx/ATmega48 machst Du
>vermutlich schon in der EXE.

Ja, das ist aber auch abgesichert. Bei solchen AVRs wird erstmal der 
letzte FLASH Block gelöscht. Dann die 1. Page Programmiert. Der 
Bootloader arbeitet dabei immer mit einer CRC Prüfsumme beim Übertragen 
der Befehle und den darauf folgenden Daten der 1. Page. Nachdem der 
Bootloader die 1. Page programmiert hat wird auch immer gleich ein 
Verify gemacht. Dh. das FLASHEN/Löschen von Pages und Schreiben in den 
EEPROM enthält ein implizites Verify.

Benutzt man die Verschlüsselung so hat man sogar eine 64 Bit Prüfsumme 
inkusive über den XTEA mit Doppel-CBC Modus. Wenn dabei nur 1 Bit falsch 
sein sollte so propagiert sich dieser Bit Fehler durch alle 
nachfolgenden Datenblöcke bis zum letzten Datenblock. Der letzte 
Datenblock enthält eine 32 Bit Signatur (ersten 4 Bytes des Passwortes).

Ich hatte noch darüber nachgedacht per DEFINES zuschaltbar eine ähnlich 
Vorgehensweise wie bei deinem Bootloader umzusetzen, aber so langsam 
verbraucht das Projekt einfach zuviel Zeit. Es fragt sich wie 
gering/hoch sind die Wahrscheinlichkeiten.

Das mit der Souceformatierung ist so'ne Sache, jeder hat da seine 
Vorlieben. Ich mage es in gewisssen Projekttypen wenn ich nicht so viel 
zersplitterte Sourcedateien habe da man so den Überblick hat. Das 
Einlesen/Überblicken ist für Neulinge dann einfacher.

Gruß Hagen

Hallo Hagen,
hast Du vor Deine Delphi-Sourcen auch zu posten? Ich würde mir gerne mal 
ansehen, wie Du die Übertragung der Dateien zu Kontroller realisiert 
hast. Ich  bin im Augenblick dabei ein kleines Programm zu entwickeln, 
dass EEPROM-Inhalte an den Kontroller übertragen soll, aber irgendwie 
bekomme ich das nicht vernünftig hin.

Gruß
Frank

Gut, das heist 90% der wichtigen Arbeit geht schonmal, er hat eine 
2-Wire Verbindung erkannt und alle Device-Infos sind korrekt empfangen.

Ich habe die Timeouts sehr knapp bemessen. Bei den Zeiten für das 
Programmieren des FLASHs und EEPROMs habe ich fast alle Datenblätter 
duchwühlt und die maximalen Zeiten angenommen. Leider scheint es so zu 
sein das manche AVRs längere Zeiten benötigen als im Datenblatt 
angegeben.

Ich habe nun mal die wichtigsten Timeouts in der INI konfigurierbar 
gemacht. In der Section [Timeouts] kannst du das einstellen. Erhöhe als 
erstes den Timeout für Flash=25. Bis auf "Buffer" und "Base" Timeout 
kann man eigentlich alle Timouts nach oben setzen ohne das sich was an 
den Gesamtprogrammierzeiten verändern sollte. Der Timeout "Base" ist 
speziell, normalerweise berechnet die Software den BaseTimeout nach der 
eingestellten Baudrate, also den Timeout für 1 Zeichen bis es komplett 
übertragen wurde. Mit dem Wert in "Base" kann man nun die minimale 
Wartezeit für diesen Timeout einstellen. Bei hohen Baudraten kann also 
der Timeout für 1 Zeichen unter zb. 25 Millisekunden betragen. Möchte 
man das auf 25 ms limitieren dann stellt man dies in "Base=25" ein.

In AVRootloader.asm habe ich noch eine klitzekleine Verbesserung bei der 
XTEA Entschlüsselung die uns 6 Bytes FLASH einspart eingebaut.
Desweiteren habe ich beim 2-Wire die Ansteuerung so verändert das der 
RX-PIN mit Pullup arbeitet falls man beide PINs RX und TX auf den 
gleichen Port gelegt hat.

Gruß Hagen

Ach übrigens, das Full Verify kannst du eigentlich immer abhacken. Die 
FLASH löschen und schreiben und EEPROM schreiben Funktionen haben ein 
implizites Verify integriert. Das zusätzliche Full Verify dient 
eigentlich nur dazu um überprüfen zu können ob das schon geflashte 
Program auf dem AVR mit dem aktuellen HEX File identisch ist.

Und da du noch par Bytes Platz hast empfehle ich dir die Watchdog 
Unterstützung zu aktivieren. Der Watchdog wird damit nicht explizit 
aktiviert aber falls du per WachtDog aus deiner Applikation in den 
Bootloader springen möchtest oder generell den WatchDog eingeschaltet 
hast dann ist das sehr hilfreich.

Ich benutz eigentlich zwei Arten um aus der Anwendung in den Bootloader 
zu springen. Das ist sehr hilfreich beim Automatischen Programmieren des 
AVRs. Bei den ATtinys überwache ich per PinChange ISR den RX Pin und 
nutz eine ISR wie nachfolgende

1

// Pinchange ISR für PB6, bei LowLevel springen wir den Bootloader an

2

__attribute__ ((naked)) ISR(PCINT_vect) {

3

4

    if (PINB & (1 << PB6)) {

5

        asm volatile("reti");

6

    } else {

7

        asm volatile("rjmp  __vectors");

8

    }

9

}

10

11

int main(void) {

12

13

    MCUSR  = 0;

14

    WDTCR  = (1 << WDE) | (1 << WDCE);

15

    WDTCR  = 0;

16

// RX Pin auf Eingang mit Pullup

17

    DDRB  = 0;

18

    PORTB = (1 << PB6)

19

// PinChange on PB6, Bootloader Pin

20

    GIMSK  = (1 << PCIE1);

21

    PCMSK1 = (1 << PCINT14);

22

    sei();

23

24

.. blabla

25

    while (1) {

26

    }

27

}

Das hat den Vorteil das man die laufende Anwendung durch die PC-Software 
automatisch in den Bootlaoder kommt. Da es ohne Watchdog per direktem 
RJMP geht kann man über den SRAM Befehl der PC-Software den aktuellen 
Inhalt des SRAMs und IO/PORT Bereiches auslesen und analysieren.

Ansonsten gehts auch über den WatchDog.

1

// Pinchange ISR für PB6, bei LowLevel springen wir den Bootloader an

2

__attribute__ ((naked)) ISR(PCINT_vect) {

3

4

    if (PINB & (1 << PB6)) {

5

        asm volatile("reti");

6

    } else {

7

        WDTCR = (1 << WDCE);

8

        WDTCR = (1 << WDE);

9

        for (;;) ;

10

    }

11

}

12

13

int main(void) {

14

15

    MCUSR  = 0;

16

    WDTCR  = (1 << WDE) | (1 << WDCE);

17

    WDTCR  = 0;

18

// RX Pin auf Eingang mit Pullup

19

    DDRB  = 0;

20

    PORTB = (1 << PB6)

21

// PinChange on PB6, Bootloader Pin

22

    GIMSK  = (1 << PCIE1);

23

    PCMSK1 = (1 << PCINT14);

24

    sei();

25

26

.. blabla

27

    while (1) {

28

    }

29

}

Gruß Hagen

@Chris,

>Mir ist allerdings aufgefallen, das ich das EEPROM nur mit max. 38400b/s
>auslesen konnte...

Erhöhe den Wert für [Timeouts] Buffer=10 oder Base=50.
Anbei mal die neuste Version. Ich habe das Fehlerhandling dahingehend 
geändert das man sieht in welcher internen Funktion eine Exception 
ausgelösst wurde. Das vereinfacht uns die Suche nach der richtigen 
Stelle für die wir den Timeout anpasssen müssen. Leider ist es so das 
Windows ganz unterschiedlich nach Treiber des Seriellen Gerätes die 
Timeouts benötigt. Ohne Timeouts geht es nicht und mit zu großen 
Timeouts verplempern die Gerätetreiber mehr Zeit als der Rest der Arbeit 
kostet.
Teste es nochmal mit der neusten Version und sage mir was für eine 
Fehlermeldung kommt. Dann kann ich dir genau sagen welchen Timeoutwert 
wir erhöhen müssen.

>Crypted habe ich auch geflashed und hat auch geklappt. Einen minimalen
>Geschwindigkeitunterschied habe ich bemerkt, aber dieser war klein 2,22s
>zu 2,63sek bei 256000b/s.

Bei einem ATMega128 ist der Unterschied 16 sec. zu 22 sec. wobei der 
ATMega mit 16Mhz läuft. Leider ist eben sichere Kryptography per 
Software auf dem AVR immer aufwendig. Der XTEA ist da schon schnell im 
Vergleich zu zb. DES oder AES. Man kann ungefähr 700 Takte pro Datenbyte 
rechnen.


>Bei den folgenden settings brauche ich genau 514 bytes Bootcode size.
>Kann man das vieleicht noch um 2 bytes drücken, damit es in die 256words
>boot block passt? Gibt es da noch Optimierungsmöglichkeiten?

Kenn ich und mich nervt das dann auch sehr ;)
Du kannst UseVerify=0 setzen. Wie schonmal gesagt ist diese Option für 
den  Hobby-Betrieb meistens überflüssig. Alles an Datenübertragung ist 
per 16Bit  CRC abgesichert. Zuerst überträgt man 2 Bytes Kommandocode 
dann darüber eine 2 Bytes CRC. Sollte also da schon ein Bitfehler 
aufgetreten sein merkt das die Software schon frühzeitig. Bei den 
Komandos du danach noch weitere Daten senden werden diese wiederum per 
CRC abgesichert.
Nachdem man also einen FLASH/EEPROM Datenbuffer gesendet hat wird der 
Befehl zum Schreiben der Daten in den FLASH/EEPROM gesendet. Beide 
Fuktionen schreiben die Daten weg und verifizieren anschließend die 
geschriebenen Daten, indem diese Funktionen den FLASH/EEPROM erneut 
auslesen, mit den Daten im Buffer. Somit hat man schon ein implizites 
Verify das sehr schnell geht da keine Daten erneut zum AVR gesendet 
werden müssen. Die einzigste Schwachstelle an dem Konzept ist als die 
CRC Prüfsumme über die empfangenen Daten. UU. kann es vorkommen das 
mehrere Bitfehler gleichzeitg auftreten und die CRC Prüfsumme versagt. 
Dann schreibt man quasi fehlerhafte Daten in den FLASH und das implizite 
Verify merkt davon nichts. Bei meinen Test mit absichtlich schlecht 
gewählten Baudraten und somit ständigen Fehlern hat der AVR nicht ein 
einzigstes Mal den Datenübertragungsfehler nicht bemerkt. Bei meinen 
Test war nur eine Baudrate von 256000 kritisch (bei 16Mhz Takt mit 
interner PLL und RC-Oszi auf ATtiny461). Im Besonderen ist das Lesen von 
Daten vom AVR bei 256000 Baud kritisch. Die interne Zeitschleife ist 
dann sehr kurz und benötigt bei 16Mhz nur 33 Takte.

Ich würde dir also raten wieder auf 128000/115200 Baud runter zu gehen. 
Wenn du das mal genauer analysierst (also die Programmierzeiten) so 
wirst du feststellen das die USB-RS232-Treiber keinen großen 
Geschwindigkeitsvorteile bringen. Bei mir ist es sogar so das eine 
normale COM-Schnitstelle bei 115200 leicht schneller ist als ein 
USB-RS232-Dongle bei 256000. Davon mal abgesehen, erzeugt dieser 
USB-RS232 Treiber auf meinem System bei dieser Baudrate sporadisch einen 
Bluescreen (das sind die einzigsten Bluescreens die ich seit Jahren 
gesehen habe auf meinem System!)

Ansonsten könntest du UseAutobaud=0 setzen, du benutzt ja einen externen 
Quarz.

Oder du verkürzt BootSign:  db. "BOOT" auf zb. "BT". Dann gehst du in 
AVRootloader.INI und ändert in [System] Sign=BT um.

Was anderes fällt mir nicht ein, es gibt aus meiner Sicht keine anderen 
Möglichkeiten des Code noch kürzer zu machen ohne das man was an der 
Funktionalität verändert.

>b) eine Fortschrittsanzeige beim flashen wäre nett. Es wird zwar
>"working" angezeigt und er hat 16kb in 2,2sek reingeflashed, aber wenn
>ein Laufbalken keine Mühe machen würde, wäre das klasse.

Nicht so einfach möglich, auf Grund des Datenkonzeptes schon. Denn wenn 
wir mit verschlüsselten Daten arbeiten dann wird alles in eine binäre 
"Scriptdatei" compiliert, passiert auch bei unverschlüsselten Daten, 
aber die Verschlüsselung war der Grund für diese Scriptdateien. Eine 
solche Scriptdatei ist quasi eine Liste aller Befehle + Daten die an den 
AVR gesendet werden. Vorteil ist eben das ich das als Basis für weitere 
Features benutzen wollte, zb. man kann extern solche Scripte erzeugen 
und durch meine Software ausführen lassen.
Nun das verschlüsselte Format verschlüsselt nicht nur die Daten und ihre 
wahre Größe sondern auch die Addresen an die diese Daten geflasht werden 
sollen. Da meine Sofwtare beim Erzeugen solcher Dateien auch "Lücken" im 
FLASH die nur mit 0xFF gefüllt werden erkennt und entfernt (dh. es 
werden nur Pages programmiert die nicht vollständig mit 0xFF gefüllt 
sind, solche Pages werden per Erasekommando nur gelöscht).

Es gibt also konzeptionell gesehen keine so einfache Möglichkeit einen 
Fortschrittsbalken zu bauen, bzw. wenn dann würde er eher nach der 
Anzahl der Befehle funktionieren und keinen zeitlichen Zusammenhang zur 
Gesamtdauer der Befehle enthalten.

Ich denke mal drüber nach, aber dann kann es nur so sein das ich die 
Anzahl der abzuarbeitende Befehle/Kommandos dafür benutze.

>Auch ist unter "EEPROM Content" der "write
>to devive" Button dekativiert, wenn ich ein externes *.eep file geladen
>habe.

Hm geht schon nur gewusst wie ;) Ich habe diesen "Fehler" aber in obiger 
Version beseitigt. Normalerweise ist es nämlich so das du im HEX Editor 
Daten veränderst. Diese werden rot markiert dargestellt. Im 
EEPROM-HEX-Editor kannst du per rechten Mausklick ein Popupmenu öffen 
mit dem du diese Selektion auch selber setzen kannst. Markiere einfach 
mal im EEPROM die Addressen 0x0000 bis 0x001F. Dann Rechten Mausklick 
und im Popup "Select Cells" auswählen. Wenn du nun "Write to Device" 
oder "Save to File" anklickst so werden nur diese ausgewählten Zellen 
programmiert bzw. gespeichert. Alle anderen nicht markierten Zellen 
werden im AVR nicht verändert. Lange Rede kurzer Sinn: Man kann also von 
einem AVR den EEPROM auslesen. Dann markiert/editiert man nur einen 
ausgewählten Bereich davon und speichert das in eine EEP Datei. Nun 
wählt man diese EEP Datei samt HEX Datei für den FLASH auf der 1. Page 
der Sofwtare. Dann drückt man "Copile" und erzeugt eine ACY-Datei. Wird 
diese Datei ausgeführt dann werden nur die EEPROM Zellen programmiert 
die man vorher manuell ausgewählt hat.
Sinn ist es das man selektive Konfigurationen in das EEPROM schreiben 
kann.

In der neusten Version wird wenn nichts in den HEX-Editoren selektiert 
ist alles geschrieben. Beim SRAM Content aber nur der SRAM Bereich. Das 
violette Registerfile und der grüne IO-Bereich wird nicht geschrieben.
Den IO-Bereich musst du also weiterhin explizit editieren.

>vielen Dank für den tollen Loader + Windows Application. Großes
>Dankeschön auch an Peter, der viel dazu beigetragen hat.

Ja dem schließe ich mich an, habe viel gelernt.

Gruß Hagen

>Das verkürzen des Boot sign von "BOOT" auf "BT" würde in meinem Fall
>wirklich helfen, wow. :)

Kürzer geht halt nicht mehr, es sollten also mindestens 2 Zeichen sein 
und der komplette String sollte eine gerade Anzahl an Zeichen haben.

Dieser String dient einerseits als Identifier/Passwort, andererseits 
auch zum "Testen" der Verbindung. Wenn es also möglich ist sollte der 
String schon länger sein da so Übertragungsfehler auf Grund einer leicht 
daneben liegenden Auto-Baudrate besser erkannt werden.

>Durch Erhöhung des Wertes auf 50 funktioniert es gut. Es gibt keine
>Fehlermeldung mehr. Allerdings auch genau ab 50, Werte <50 resultieren
>im oben genannten Fehler. Dies habe ich bis max. Baudrate getestet.

Das deutet auf schon oben genanntes Verhalten der verschiedenen 
RS232-USB-Treiber hin. Normalerweise benötigt der AVR maximal 10 Takte 
bis er anfängt die ersten Datenbytes aus dem EEPROM an den PC zu senden. 
Also niemals 50ms an Zeit. Der Timeout entsteht beim ersten zu 
empfangenden Datenbyte beim Auslesen des EEPROMs, gleich nach dem Senden 
der 2 Kommandobytes + 2 Bytes CRC. Sowas kann nur passieren weil der 
USB-RS232-Treiber oder das USB-Hardware-Protokoll Zeitverzögerungen 
einbaut.

Du solltest also in deinem Falle den Timeout "Base" immer auf minimal 
50ms stehen lassen, denn bei deiner Hardware/Treiber kommen quasi 50 + 
1000000/Baudrate * Datenbytes Zeitverzögerung raus. Rechnet man das 
Verhältnis aus so sieht man das dise 50ms weit über der Zeit liegen die 
man für ganze Datenpackete ansich benötigen würde. Deshalb nutz ich die 
gute alte UART meines Laptops ;)

Eventuell müsstest du auch "Buffer" auf 50ms setzen, aber das erhöht 
drastisch die Programmierzeiten !

Vielleicht findest du ja einen Dreh wie man den USB-RS232-Treiber dazu 
überedet mit kürzeren Zeitverzögerungen zu arbeiten.

Ich arbeite zZ. mit

Base=25
Erase=5
Flash=10
Eeprom=10
Buffer=1

und normaler UART bei 115200 Baud ohne Probleme.


Gruß hagen

Hier die neuste Version, geändert wurden:

- Anleitung zur Benutzung der Verschlüsselung und der prekompilierten 
ACY- Dateien beigefügt
- Wenn AVRootloader.exe eine Verbindung herstellen möchte so zieht er 
den DTR-Pin der RS232 auf High-Pegel. Damit kann man über DTR eine 
Stromversorgung zb. eines Treibers machen, aber bitte RS232 
Spezifikationen beachten
- unter Win2k/Win95 wurde das Fenster der AVRootloade.exe nicht in den 
Vordergund geholt. Stattdessen blinkte nur das Icon in der Tastleiste. 
Dieses Problem wurde behoben (ist aber auch Standardverhalten auf diesen 
Windowsversionen)
- Darstellungsprobleme im SRAM-Content HEX-Editor beseitigt
- mit rechten Mausklick in diese HEX-Editoren öffnet sich ein Popup-Menu 
mit dem man zb. selektierte Zellen im Editor rot markieren kann. Beim 
Zurückschreiben in den AVR oder beim Speichern in eine Datei werden dann 
nur diese selektierten Zellen berücksichtigt. Mit diesem Feature kann 
man zb. selektive EEPROM Dateien erzeugen die nur ausgeählte 
Speicheraddressen schreiben.
- die AVR Device Liste in AVRootloader.asm (.includes) wurde auf den 
neusten Stand gebracht
- die Datei AVRootloader.dev wurde ebenfalls auf den neusten Stand 
gebracht, möchte man diese neu erzeugen lassen so muß AVRStudio im 
System korrekt installiert sein. Löscht die aktuelle AVRootloader.dev 
Datei und startet die Anwendung. Aus den XML Part Description Files des 
AVR Studios wird dann eine neue AVRootloader.dev erzeugt.
- Howto für selektive EEPROM Updates hinzugefügt

Gruß Hagen

Leider war noch ein Fehler drinnen, ich hasse das wenn man unter 
Zeitdruck arbeitet.

Die Funktion "make Password" veränderte die Formatierung des Passwortes 
in der AVRootloader.asm und in der AVRootloader.ini falsch. Jetzt ist's 
richtig ;)

Danke an Wolfgang der mich darauf aufmerksam gemacht hat.

Gruß Hagen

@ Neugieriger
Z.Bsp. wenn du mehrere Geraete im Umlauf hast und bei einer 
Programaenderung nicht selbst von Standort zu Standort wandern und diese 
updaten willst.

@Hagen Re
Danke für Dein Programm. Werde es in meiner naechsten grösseren Serie 
mal einsetzen.

Möglich ist sowas aber nicht mit dem Bootloader wie er jetzt ist, 
vielleicht sogar ja doch. Wenn alle AVR Bootloader als BootSign: einen 
anderen Wert hätten, zb. AVR1 hat "BOOT1" AVR2 hat "BOOT2" usw. Alle 
liegen sie per 1-Wire auf dem gleichen Bus und die 1-Wire-RS232 wäre der 
Master. Dann könnte eine Point-to-Point Kommunikation von mehreren 
Geräten quasi im Halb-Duplex funktionieren, eben so wie auf einem 
1-Wire-Bus. Die PC-Software müsste dann nacheinander erst die Signatur 
"BOOT1" senden und warten bis sich der entsprechende AVR meldet. Dann 
wird dieser Programmiert, danach sendet der PC nun "BOOT2" und verbindet 
mit AVR2 usw. usw.

Gruß Hagen

Damit müssen doch die Bootloader wieder unterschiedlich sein. Im 
zweifelsfall reicht es ja vielleicht unterschiedliche Passwörter zu 
nehmen. Es reagiert dann jeweils nur der Controller, wo das Passwort 
passt.

Hardwaremäßig ist es am einfachsten im 1-Wire-Modus zu arbeiten, das 
geht ohne Umprogrammierung der Software (AVR-Bootloader) jetzt schon.

Das BootSign: aktuell der Wert "BOOT" ist das was du unter Passwort 
verstehst. Das lässt sich in der PC-Software in AVRootloader.ini jetzt 
schon ändern.

Man müsste die PC-Software so umprogrammmieren das sie diesen Wert 
autom. inkrementiert.

Allerdings ist es schon richtig das man bei diesem Verfahren die 
AVRootloader.asm individuell programmieren müsste.

Vorstellbar wäre es diese Software so zu erweitern das eine Serialnummer 
im EEPROM abgelegt wird. Am Anfang installiert man auf den AVR diese 
Software und programmiert diese Serialnummer individuell, also immer nur 
ein AVR an der 1-Wire Hardware angeschlossen. Nach diesem Setup kann man 
alle AVRs parallel am 1-Wire hängen. Die PC Software fragt nun wie beim 
Original-1-Wire diese Serialnummer=ID ab und ermittelt auf diese Weise 
alle AVRs die am 1-Wire-Bus hängen. Danach kann man per PC-Software 
selektiv all Geräte flashen oder eben eine Auswahl oder alle in einem 
Rutsch sequientiell nacheinander.


Gruß Hagen

Ich fände es gut, wenn die Windowssoftware noch ein "simples" Terminal 
Program mitbringen würde. Da ich über dieselbe serielle Schnittstelle 
programiere wie die, auf der ich Statusmeldungen ausgebe fände ich es 
gut, wenn das in einer Software wäre.
Was hälst du davon?
  Werner

Hatte ich auch schon dran gedacht aber es stellt sich die entscheidende 
Frage wie solls gehen ? Der Bootloader sollte primär vollkomman 
unabhängig zur eigentlichen Anwendungssofwtare sein. Die PC-Software 
wäre demnach eine Kombination aus Bootloader-Software für den 
AVR-Bootloader und Terminal-Software für die Anwendung. Soweit 
unproblematisch wenn dieses Terminal vollkommen separat funktioniert. 
Dh. also eigener Verbindungsaufbau usw. da ja nicht mit dem Bootloader 
connected wird sondern mit der installierten Anwendung. Die Anwendung im 
AVR muß also selber die UART Kommunikation machen unabhängig vom 
Bootloader.

Dazu hatte ich angedacht eine 1-Wire Bibliothek die per Interrupts 
arbeitet vorzusehen die man dann in die eigene Anwendung einbinden 
könnte. Nur die liebe Zeit ist das Problem. Ich programmiere in meiner 
Freizeit nur Dinge die ich auch selber benötige, verständlich oder ? 
Wenn also irgendeiner eine solch fertige Library mir anbietet dann bin 
ich gerne bereit meine PC-Software dahingehend anzupassen. Das ist im 
Grunde kein großer Aufwand.

Ich habe mir auch schon AVR309 (IgorPlug-USB) angeschaut und als 
untauglich verworfen da dort keine Kommunikationstimeouts unterstützt 
werden die aber für das Bootloaderprotokoll essentiell sind.

>Da ich über dieselbe serielle Schnittstelle
>programiere wie die, auf der ich Statusmeldungen ausgebe fände ich es
>gut, wenn das in einer Software wäre.

Siehst du, Du machst es so. Ich zb. habe am gleichen 1-Wire-Pin 
normalerweise eine LED, also Ausgang dran, im aktuellen Projekt.

Wenn sich bei mir also der Bedarf nach so einer Schnittstelle andeutet 
würde ich das auch in die gleiche PC-Software integrieren, logisch.

Gruß Hagen

Ich arbeite mit den "normalen" Uart-Routinen aus meinem Hauptprogramm. 
Da ich "genügend" I/O habe benutze ich auch den 2-Draht Modus.
Aber schön zu hören, dass das vielleicht noch kommt ;-)

Wenn ich das richtig verstanden habe, ist der normale Ablauf doch wie 
folgt
 - PC Software starten
 - Connect to device
 - AVR einschalten bzw. resetten
 - PC Software connected
 - danach kann ich programmieren
Manchmal habe ich nun, dass die PC Software zwar in den connected Modus 
wechselt, aber die alte Anwendung auf dem AVR trotzdem gestartet wird. 
Dann kann ich natürlich nicht programmieren.
Würde es hierbei etwas bringen, die Wartezeit des Bootloader 
hochzusetzten, oder was läuft hier schief?

Werner

Ja, Wartezeit hochsetzen. Die PC-Software sendet beim Connect (egal ob 
manuell mit Connect-Button ausgelösst oder durch Button 
"Program"/"Erase" etc.pp. automatisch ausgelösst) permanent ein 
#0#0#0#0#13BOOT. #0#0#0#0 steht für Kommando "Restart Bootloader", #13 
ist das Zeichen für die AutoBaud Funktion und "BOOT" das Passwort/die 
Signature. Das Interval dieses Packetes definiert sich über die 
Baudrate, je höher die Baudrate desto höher kann das 
Wiederholungsinterval werden. Der AVR-Bootloader versucht nun innerhalb 
von zb. 300ms (default und fix) darauf zu reagieren. Nun kann es 
vorkommen das das Timing so ungünstig ist das sich diese Intervalle auf 
eine Art überschneiden das keinerlei Connect möglich ist. Dann einfach 
nochmal RESET/POWER OFF drücken. Oder aber in der Applikation so wie 
oben schon angedeutet auf Pegelwechsel am RX-PIN reagieren. Dann würde 
die Applikation solange in den Bootloader springen bis die PC-Software 
aufhört irgendwas zu senden. In diesem Falle kann man das BootDelay im 
AVR-Bootloader als defakto deaktiviert ansehen und die PC-Software 
steuert den AVR fern.
Alternativ könnte ich das BootDelay so abändern das nicht exakt x 
Milliskunden im Gesamten gewartet wird, also fester Timeout, sondern das 
wenn nach x Millisekunden rein garnichts passiert ist ein Timeout 
entsteht. D.h. würde das BootDelay zb. auf 300ms stehen und nach 200ms 
kommt irgendein Impuls auf Rx rein so verlängert sich das Delay um 
weitere 300ms. Somit würde der Bootloader solange im Delay bleiben bis 
entweder eine gültige Verbindung zustande kam (Bootloader startet) oder 
aber die PC-Software für mindestens 300ms Ruhe gibt (Applikation 
startet). Ist also keine PC-Software aktiv so startet die Applikation 
nach 300ms, ist eine PC-Software aktiv so läuft der Connect-Prozess so 
lange bis die PC-Software "aufgibt" und 300ms später startet die 
Applikation, oder es aber zu einer gültigen Verbindung kommt (nochmal in 
anderen Worten;).

Solche Probleme lassen sich nur dann umgehen wenn man zusätzliche 
Steuerleitungen mit diesen Funktionen vorsieht. Eine Möglichkeit habe 
ich jetzt schon integriert. Der DTR Ausgang der RS232 wird beim Beginn 
eines Connects in der PC-Software auf HIGH-Peel gezogen (ist 
normalerweise -12 bzw. -6 oder sogar 0 Volt, je nach RS232 Hardware). 
Man könnte also den DTR über eine Shottky wie beim 1-Wire an einen Pin 
des AVRs legen. DTR wird momentan so geschaltet damit man aus diesem Pin 
quasi eine Spannungsversorgung eines Pegelwandlers (2x Transistor) 
aufbauen kann.

Ich hatte auch schon vorgesehen das der RTS Pin ebenfalls kurzeitigt 
seinen Pegel verändert, von HIGH auf LOW und wieder HIGH. Über eine 
Shottky wie beim 1-Wire direkt an den RESET des AVRs. Die PC-Software 
pulst diesen Pin nun vor jedem Connect-Versuch. Habe ich aber wieder 
rausgenommen und kann wenn gewünscht wieder eingebaut werden.

Aber genau der Punkt das man auch nur mit wenigen Kabeln arbeiten kann 
ist primäres Ziel gewesen bei diesem Bootloader ;)

Gruß Hagen

Hm, das sieht übel aus. Es bedeutet das dein AVR kaputt geflasht ist. 
Mal davon abgesehen das auch ein Fehler im Bootloader voehanden sein 
könnte ;)

Nach dem Programmieren einer FLASH Page wird der FLASH sofort wieder 
ausgelesen und mit den soeben programmierten Daten im SRAM Buffer 
verglichen. Sollte es dabei zu einer Inkonsistenz kommen wird der Fehler 
"Verify failed" zurückgeliefert. Also schlägt bei dir das implizite 
Verify zu und meint das dein FLASH nicht sauber programmiert werden 
kann. Gehen wir davon aus das der Bootloader keinen Fehler macht, deine 
Hardware ansonsten sauber ist (keine Spannungseinbrüche in der 
Versorgung zb.) dann heist dies das dein AVR defekt ist.

Wenn du den ISP noch dran hast dann solltest du erstmal versuchen deinen 
AVR damit zu flashen. Es sollte dann ebenfalls ein Verify Fehler 
auftreten. Dann wäre dein AVR FLASH definitiv kaputt. Am besten flasht 
du alle Zellen einmal auf 0x00 und einmal auf 0xFF um sicher zu gehen. 
Wenn kein Verify Fehler per ISP auftritt dann muß ein Fehler im 
Bootloader vorliegen, kann aber beim besten Willen nicht sagen was dort 
falsch sein sollte.


>Die Idee mit dem Terminal ist mir auch gleich aufgefallen, ich hab hier
>ZOC in Verwendung, und wenn das gestartet ist kommt die AVRootloader.exe
>nicht mehr an die COM, also Programm beenden, AVRootloader.exe aufrufen,
>programmieren, usw.,

Ja ich weiß :) Ich hatte als ich began mit dem Bootloader schon die 
gleiche Idee aber immer wieder verworfen. Es ist eben eine Bootlaoder 
Software und keine Applikationsbezogene Software. Ich denke nochmal 
drüber nach verspeche aber nichts, es stehen erstmal andere Änderungen 
an.

1.) die Funktionalität des Bootloaders wird in ein Interface gepackt. 
Die Funktionalität der Kommunikationsschnittstelle (bisher COM-Port) ist 
schon längst in einem solchen Interface. Das Ganze kommt in eine DLL. 
Nun kann man mit allen Standard-Programmiersprachen für Windows die 
Interfaces, also COM, DCOM unterstützen auf diese Interfaces der DLL 
zugreifen. Somit ist die komplette Bootloader Funktionalität auch aus 
eigenen Programmen heraus nutzbar. Man kann so auf einfache Weise 
entweder das Kommunikations-Interface durch ein egenes ersetzen, zb. 
direkter USB Treiber, AVR309 wenn man möchte etc.pp. Oder man kann 
eigene Befehle die man in den AVR-Bootloader integriert hat mit dem 
Bootloader Interface erweitern.

2.) es wird eine PIN geben. In den ersten par EEPROM Zellen des AVRs 
kann in Zukunft eine PIN programmiert werden. Der Bootloader bekommt ein 
neues Kommando bei dem man diese PIN dem Bootloader mitteilen muß damit 
er alle anderen Kommandos überhaupt akzeptiert. So kann man jeden AVR 
individuell mit dieser PIN schützen. Kann sie nach Eingabe der PIN über 
das EEPROM Kommando neu schreiben oder löschen. Statt PIN könnte man 
sagen Serialnummer die als programmierbares Passwort benutzt wird.

Damit gibt es also insgesamt drei verschiedene Schutzmaßnahmen die der 
Bootloader unterstützt. Das BootSign -> "BOOT" das als harcoded Passwort 
für alle AVRs mit gleichem Bootloader dienen kann. Die PIN die im EEPROM 
individuell für jeden AVR programmiert werden kann, zb. auch durch die 
Endkunden. Und schlußendlich die Verschlüsselung samt 128 Bit Passwort 
um Fernupdates gesichert durchführen zu können. Natürlich ist die 
Unterstützung einer solchen PIN ebenfalls konfigurierbar.

3.) das Verfahren des Boot Timeouts wird leicht geändert.

4.) Vieleicht, aber nur vieleicht ! Ein Standalone Bootloader für den 
PC. Mit der jetzigen PC Software würde man dann eine eigene EXE 
kompilieren die die verschlüsselte ACY-Datei (HEX für FLASH/EEPROM) 
enthält. Das GUI dieser Anwendung würde wie ein Setup-Assistent 
aussehen, die automatische Ermittlung der Schnittstelle enthalten und 
auch autom. die eingebundene ACY-Datei flashen.

Gruß Hagen

Uff. Versorgt der ISP den AVR mit Spannung ? Das Problem was ich sehe 
ist das die Routine die den FLASH programmiert ihre Daten aus dem SRAM 
bekommt. Damit wird der Pagebuffer befüllt und anschließend der Program 
Befehl ausgeführt. Danach lädt der AVR nochmal die soeben programmierten 
Zellen aus dem FLASH und vergleicht sie mit den Daten im SRAM. Es gibt 
also nur 4 Möglichkeiten wo ein Fehler passieren kann.

1.) FLASH Programmierung, dh. dein FLASH ist wirklich defekt oder kann 
nicht sauber programmiert werden weil deine Spannungsversorgung schlecht 
ist
2.) SRAM Daten verändern sich willkürlich zwischen der 
FLASH-Programierphase und FLASH Verifyphase. Auch das könnte an einer 
Spannungsversorgung liegen
3.) meine Software im AVR hat an dieser Stelle noch einen Bug. Das halte 
ich aber für unwahrscheinlich, ich hatte bisher noch nie einen solchen 
Verify Fehler selbst mit einem Projekt bei dem die Spannungsversorgung 
sehr heikel ist (Solar-Panel -> 1.2V NiMH Akku -> Stepup auf 3.0 Volt).
4.) Datenübertragung, dh. alles läuft im AVR korrekt ab, am Ende wird 
der Returncode SUCCESS gesendet aber als ERRORVERIFY empfangen. Das ist 
aber enorm unwahrscheinlich da diese Fehlercodes sich im oberen Nibble 
komplett unterscheiden -> $3x -> $Cx.

Wie gesagt bisher hatte ich bei meinen Projekten (ATtiny45, ATtiny461, 
ATmega168) keinerlei Probleme.

Mache mal folgendes:

1.) AVRootloader.asm -> UseSRAM = 1, UseE2Read=1, UseE2Write=1 setzen, 
neu compilieren und installieren, WICHTIG! vergiß nicht BootCodeSize=??? 
anzupassen so wie es in der Readme steht.
2.) AVRootloader.exe starten und über Button "Connect to device" eine 
Verbindung herstellen
3.) auf Page "Device Information" überprüfen ob alle Angaben mit deinem 
AVR übereinstimmen
4.) auf Page "SRAM Content" gehen und Button "Read from Device" drücken
5.) in dem grünen Bereich des HEX Editor gehen und rechten Mausklick 
machen, im Popup "Clear Cells" drücken
6.) auf Button "Write to device" klicken
7.) auf Button "Read from device" klicken und schauen ob alle Zellen im 
grünen Bereich weiterhin auf 0x00 stehen (bis auf die letzten par Bytes 
-> Stack)
8.) nun alle Zellen im grünen Bereich auf 0xFF setzen und Steps 6.-7. 
wiederholen

Du musst dann immer exakt das wieder aus dem SRAM auslesen was du vorher 
dort hineingeschrieben hast. Sollte das nicht der Fall sein so hast du 
ein Kommunikationsproblem, zb. mit dem MAX-Treiber.

Die gleichen Tests kannst du auch mit dem EEPROM machen -> Page "EEPROM 
Content". Hier wird wie beim FLASH ebenfalls das implizite Verify 
durchgeführt.

Gruß Hagen

>die Idee mit der DLL ist sehr gut, da ich nämlich hier schon ein
>Sourceproject für ein Terminal-programm habe, allerdings in C,
>aber vielleicht kann man dann beide irgendwie verheiraten, :-))

Ich möchte keine falschen Erwartungen wecken. zZ. verifiziere ich 
erstmal ob mein angedachtes Konzept auch funktioniert. Ich werde mit 
Interfaces arbeiten und das in deiner DLL. Alle Programmiersprachen die 
Windows-COM-Interfaces unterstützen können dann darauf zugreifen (also 
keine IDispatch-Interfaces!) Das unterscheidet sich zu einer normalen 
DLL gewaltig da meine DLL quasi nur ein Objekt exportiert und keine 
Funktionen. Jeder der sich mit Interfaces auskennt weiß welche Vorteile 
das hat es bedeutet aber auch das diese DLL eher wie ein OCX/ActiveX 
funktioniert statt wie eine normale DLL mit exportierten Funktionen.

Desweiteren könnte man diese Interfaces benutzen um auf die 
COM-RS232-Schitstelle zu zugreifen um damit dann deine 
Terminal-Geschichte zu machen. Das hat aber dann keinen Zusammenhang zum 
eigentlichen Bootloader sondern bietet nur die Anbindung der RS232. Ich 
sehe nämlich einen ziemlichen Aufwand in dem Punkt wie man Bootloader 
uund Terminalclient in der eigenen Applikation miteineraner verbindet. 
Der Bootloader arbeitet per Pollling in der Kommunikation und 
unterdrückt jede asynchrone Verarbeitung per ISRs. Der Terminal Client 
in der Applikation sollte so in keinem Falle arbeiten, dieser sollte 
Interrrupt-gesteeurt funktionieren. Zusätzlich noch das problem das je 
nach Kommunikationshardware, also 1-Wire/2-Wire/invertiert/nicht 
invertiert, müsste der Terminalclient in der Applikation alle diese 
Modis auch unterstützen. Es macht ja keinen Sinn wenn der Bootloader im 
1-Wire läuft und das Terminal nur im invertierten 2-Wire Modus 
funktioniert.

Ich bin eventl. gerne bereit einen kleinen Terminal-Srver in der 
PC-Software zu integrierten die aufbauend auf den aktuellen 
Verbindungsparametern die der Bootloader zuvor ausgehandelt hat sich mit 
dem AVR nach dem Start der Applikation weiterhin zu verbinden, bzw. 
verbunden zuz bleiben. D.h. man verbindet erstmal zum Bootloader (zwecks 
AutoBaud, Autodetektion 1-Wire/2-Wire). Man bleibt verbunden wechselt zu 
terminal Page und Startet die Applikation im AVR. Diese Applikation 
müsste sich die Baudrate etc.pp. aus den internen Registern des AVRs 
holen und ihrerseits eine Terminalkommunikationssoftware initialisieren. 
Bisdahin aber nicht weiter. Dh. die UART-Kommunikation in der eigenen 
Awnedung um den terminalclient zu implementieren wäre nicht meine 
Aufgabe.

Gruß Hagen

Also du hast ja Probleme ;)

Erstmal müssen wir die PC-Software bei dir richtig zum laufen bringen. 
Welches Betriebsystem hast du ? Welche Einstellungen hast du bei der 
Darstellung, Fonts, Scalierung etc.pp. ? Du bist der Erste der solche 
Probleme hat.

Ich habe das Program mit Delphi 5 programmiert und verlasse mich darauf 
das Delphis VCL da alles richtig macht, sprich Ausrichtung der Controls 
usw. Das es damit Probleme geben soll ist mir neu, immerhin arbeite ich 
damit professionell seit dem es Delphi auf dem Markt gibt.

Schick mir doch mal ne PN so das du mir per EMail noch mehr Screenshots 
schicken kannst. Du must da auch nicht auf die Bildgröße achten, mein 
Postfach ist ziemlich groß.

Also ich habe das bei mir mal versucht zu reproduzieren, Systemfonts, 
Scrollbars, Bildschirmscalierung etc.pp. verändert, bekomme es aber nie 
hin das so ein Fehler auftritt wie der bei dir.

Probiere doch mal die EXE aus dem Attachment. Ich habe den Font, den 
BIDI-Mode und die Autoscalierung und einige andere Werte geändert. Denke 
zwar nicht das das hilft aber probieren können wir es ja mal.

Ich bräuchte also als erstes von dir noch mehr Infos über dein System.

>Das mit dem SRAM würd ich ja gern probieren, da schein aber noch ein
>Problem mit dem PC-Programm zu sein, die Buttons "Read from device" usw.

Falls es mit der geänderten Version geht dann probiere das mit dem SRAM 
und EEPROM aus, damit wir wissen ob es an der Kommunikation liegt.

>bzgl. Terminal, der letzte Abschnitt von Deiner vorherigen Mail bringt
>mich auf einen Gedanken:
>Wie wäre es wenn dein PC Programm eine virtuelle COM anbietet, damit
>kann dann JEDES Terminalprogramm benutzt werden.
>die COM-Parameter werden vom PC Programm einfach übernommen, und es
>werden die Zeichen, die nichts mit der Bootloader-Kommunikation zu tun
>haben, einfach durchgereicht. Allerdings weiß ich nicht wie es
>programm-technisch schwierig ist eine virtuelle COM zu implementieren.

Ich soll einen Windows Kernelmode Treiber mal eben programmieren ? 
Vergiß es ganz schnell, den Streß will ich nicht nochmal haben.

Es ist ja kein Problem für mich, aufsetztend auf die schon bestehende 
COM-Verbindung ein Terminal laufen zu lassen, das ist das geringste 
Problem. Das was die Sache so zeitaufwendig macht ist die nötige 
Bibliothek die wir auf AVR Seite benötigen um sie in die eigene 
AVR-Applikation einbinden zu können. Und exakt diese Bibliothek werde 
ich in nächster Zeit nicht programmieren.

In der PC-Software wäre das ein Kinderspiel, einfach Verbindung zum 
Bootloader, Run-Kommando senden das die Applikation durch den Bootloader 
im AVR gesteartet wird und dann übernimmt die Terminalbibliothek die 
Kontrolle über die RS232. Nur, damit ich die PC-Software dann ordentlich 
testen kann müsste ich für den AVR eben auch diese Bibliothek 
programmieren und das mache ich jetzt nicht. Und sowas blind, ohne reale 
Tests zu programmieren, um dann einen erhöhten Support zu haben, weil 
Nichts ohne Test sofort in der Praxis laufen kann, mache ich ebenfalls 
nicht. Es ist Hobby und ich muß mir ganz genau überlegen welches meiner 
Projekte, von den vielen, ich mal endlich fertig bekommen will. Dazu 
gehört dieses Terminal eben nicht, weil ich es nicht brauche. Denke das 
das wohl nachvollziehbar ist, oder ?

Schick mir ne PN, und wir können dann eine Zusammenarbeit anstreben. 
Wenn du die Tests und die Terminalbibliothek für den AVR übernimmst, 
baue ich die entsprechende Funktionalität in die PC-Software sofort ein.

Gruß Hagen

SMTP error from remote mailer after RCPT TO:.....:
    host mx0.gmx.net [213.165.64.100]: 550 5.1.1 ... User is unknown 
{mx094}

Du musst mir schon deine richtige EMail Addresse geben. Oder melde dich 
hier im Forum als registrierter Benutzer an, dann geht das auch per PN 
indem du meinen Namen anklickst (ist dann blau)

>ich hab hier das normale Windows XP mit Sp2 zum Laufen, also nichts...

ich entwickle die PC-Software auch auf diesem System, und läuft. Du 
musst also irgendwas anders eingestellt haben.

Gruß Hagen

Für alle die es interessiert. Das Problem vom Micha konnte eingegrenzt 
werden.

Der ATmega162 kann im Kompatibilitätsmodus als ATmega161 laufen. Meine 
PC-Software ermittelt alle nötigen Parameter wie FLASH/EEPROM/SRAM 
Position/Größe aus den ATMEL Part Decsrption XMLs die beim AVR Studio 
enthalten sind. In diesen XMLs ist der ATmega161comp unvollständig bzw. 
fehlerhaft beschrieben, es fehlen die Infos für die BootPages.
Desweiteren benutzt mein Bootloader aus Effizienzgründen eine spezielle 
Berechnung der Signatur der AVRs. Diese Berechnung reduziert die 3 Bytes 
Signatur auf eine 1 Bytes Signatur. Das funktioniert auch wunderbar bis 
eben auf den Punkt ATmega161. Dessen Signatur überschneidet sich dann 
mit der Signatur des neueren ATtiny88.

31=1E9311, ATtiny88     ,   8192,   64,  512, 256,  64,  0,  0,  0,  0
31=1E9401, ATmega161    ,  16384,  512, 1024,  96, 128,  8,  0,  0,  0
31=1E9401, ATmega161comp,  16384,  512, 1024,  96, 128,  0,  0,  0,  0
34=1E9404, ATmega162    ,  16384,  512, 1024, 256, 128,  2,  4,  8, 16

Losung dieser Probleme mit der aktuellen Version sieht so aus:

1.) .DEV Datei so abändern

31=1E9311, ATtiny88     ,   8192,   64,  512, 256,  64,  0,  0,  0,  0
3E=1E9401, ATmega161    ,  16384,  512, 1024,  96, 128,  8,  0,  0,  0
3F=1E9401, ATmega161comp,  16384,  512, 1024,  96, 128,  2,  4,  8, 16
34=1E9404, ATmega162    ,  16384,  512, 1024, 256, 128,  2,  4,  8, 16

also aus 31 wird 3E/3F beim ATmega161/comp, beim ATmega161comp müssen 
die letzten 4 Zahlen synchron wie beim ATMega162 geändert werden

2.) in AVRootloader.inc

.set  SIGNATURE_CRC  = (SIGNATURE_000 << 3) + (SIGNATURE_001 << 4) + 
SIGNATURE_002

ersetzen mit

.set  SIGNATURE_CRC  = 0x3E oder 0x3F je nachdem ob man ATmega161 oder 
ATmega161comp benutzt wird

3.) in AVRootloader.asm muß beim ATmega162 im Kompatibilitätsmodus

.include "m161def.inc"        ; ATmega161

Inkludiert werden, nicht m162def.inc !!

Da dieses Problem nur mit dem ATMega162/161comp. auftritt wird es 
erstmal keinen HotFix geben, das Teil ist eh abgekündigt.

Gruß Hagen

Version 2.0

Die SIGNATURE_CRC wurde entfernt. Der neue ATtiny88 überschneidet sich 
mit dem ATmega161 beim Verfahren der Version 1.0. Nötige Änderung dafür 
ist in AVRootloader.asm -> BootSign: die 4 Bytes. Die PC-Software kann 
aber weiterhin mit der Version 1.0 benutzt werden, ist also 
abwärtskompatibel.

AVRootloader.dev aktualisert auf die neusten AVRs und beim ATMega161/ 
ATmega161comp. (ATmega162 im 161 Kompatibilitätsmodus) Fehler aus den 
AVR Studio XML Dateien beseitigt. ATMEL hat dort falsche Angaben 
gemacht.

Die PC-Software ist intern komplett neu geschrieben worden. Wer 
Interesse hat kann die AVRootloader.DLL benutzen um die komplette 
Funktionalität der PC-Software (ohne GUI) in seine eigene Anwendung zu 
integrieren. Diese DLL implementiert die Funktionalität über Interfaces, 
sollte also auch über andere Programmiersprachen nutzbar sein. Delphi 
Header in AVRootIntf.pas. Über diese Schnittstelle kann man auch eigene 
Communications-Interfaces vorgeben über die dann die AVRootloader 
Schnittstelle kommuniziert, zb. AVR309 USB oä.

Über AVRootloader.ini in Section [Timeouts] RTSPulse=? kann man das 
Verhalten beim Verbindungsaufbau der PC-Software von der RTS-Leitung der 
RS232 einstellen. Man kann über diese Option also den RTS PIN der RS232 
zb. für x Millisekunden von HIGH auf LOW und wieder HIGH ziehen. Damit 
könnte man, über Serienwiderstand und Shottky Diode den RTS Pin auf den 
RESET Pin des AVRs klemmen. Bei jedem Verbindungsaufbau der PC-Software 
zum Bootloader wird somit autom. der AVR in den Reset versetzt.

Wer möchte kann ein Copyright String oä. in AVRootloader.asm einbauen. 
Dieser String wird dann in der PC-Software in der Device Information 
angezeigt.

Das geht so:

BootSign:  .db    "BOOT"
BootInfo:  .db    SIGNATURE_001, SIGNATURE_002, BootVersion, BootPages
BootMsg:    .db     SUCCESS, "Hello World"
BootEnd:

Wichtig ist das das erste Byte immer SUCCESS ist.

Das Timeout-Handling in der Baudratedetektion wurde geändert. Sollte 
innerhalb des Timeouts, zb. 250ms, eine gültige Baudrate detektiert 
worden sein so verlängert sich der Timeout ab diesem Moment um weitere 
250ms. Entweder der Bootloader empfängt das korrekte BootSign: (zb. 
BOOT) und springt in den Kommandomodus oder aber die Baudrate-Detektion 
startet erneut mit weiteren 250ms. Wenn also Ruhe auf der RX-Leitung 
ist, so startet die Applikation wie gewohnt nach dem Timeout. Wenn aber 
eine PC-Software versucht eine Verbindung aufzubauen so bleibt der 
Bootloader solange in der Baudrate-Detektion bis die PC-Software aufhört 
eine Verbindung aufzubauen. Diese Vorgehensweise macht das Verfahren 
wesentlich robuster. In Version 1.0 war der Timeout ein Gesamt-Timeout 
des Verbindungsversuches. Nach den zb. 250ms wurde immer die Applikation 
gestartet, egal ob eine PC-Software einen Verbindungsaufbau versuchte 
oder nicht.

Gruß Hagen

Nochmal zurück zu Michaels Problem mit dem ATMega162 im ATMega161 
Kompatibiliätsmodus.

Zuerst zur Lösung des Problemes:

1.) in AVRootloader.asm

.include "m161def.inc"  ; ATmega161

.equ  RWWSRE = 4  ; activate for ATmega162 in ATmega161 compatibility 
mode

einfügen. Wichtig ist das das RWWSRE Bit manuell nachträglich deklariert 
werden muß.

2.) in AVR-Studio Fuses

M161C=Häckchen
BOOTSZ=Boot Flash size=512 words start address=$1E00
BOOTRST=Häckchen

3.) AVR-Studio Lockbits

BLB0 und BLB1 nicht setzen.

Erklärung:

Der ATMega161 kennt das "Read While Write" Feature des SPM Befehles 
nicht. Der ATMega162 kennt diese Feature aber. Lässt man den ATMega162 
im Kompatibilitätsmodus arbeiten als 161'er dann muß man nach dem 
Programmieren einer FLASH Page denoch diese Page wieder für den 
Lesezugriff   freischalten. Da aber in m161def.inc das nötige RWWSRE Bit 
nicht deklariert ist wurde also die geschriebene FLASH Page nicht zum 
Lesen freigeschaltet. Das anschließende Verify musste somit scheitern. 
Zum Glück betrifft die nur das Sorgenkind ATMega161 bzw. den 
Kompatibilitäsmodus des ATMega162. Die PC-Software erkennt nun korrekt 
einen ATmega161. Die Problematik entstand weil der ATMega162 im m161 
Modus das Extended IO ausblendet und somit die SRAM Startaddresse von 
0x0100 auf 0x0060 vorverlagert und einiges der Peripherie deaktiviert. 
Man kann also nicht den Bootloader so compilieren das er als ATmega162 
läuft und die Fuse des M161C Modus setzen. Man muß den Bootloaer auf dem 
M162 wirklich als M161 compilieren, aber dann unterscheiden sich die 
Programmierbefehle (SPM) trotzdem. Kurz gesagt: der ATMega162 im M161C 
Modus ist nicht vollständig kompatibel zum ATMega161, der SPM Befehl 
funktioniert dann weiterhin wie bei einem ATmega162.

Gruß Hagen

Es tut mir ja leid, aber ein neues Update. Mit bestimmten HEX Files, bei 
denen die Speicherblöcke nicht linear aufsteigend in ihrer Addresse 
vorlagen, kam es zu Fehlern. Die PC-Software hat also HEX Files falsch 
interpretiert. Unter normalen Umständen dürfte das aber kein Problem 
sein da die meisten Tools wie WinAVR GCC oder AVR Studio solche HEX 
Files immer mit linear nachfolgenden Addressen erzeugen.

Mit der neuen Version ist das natürlich gefixt.

Gruß Hagen

Hallo,

hast Du zufällig irgendwo eine Anleitung wie man den Loader in seine 
eigene Delphi-app einbauen kann?

Ich komme da nicht recht weiter, würde gerne einen "One-Button" upload 
von meiner Software aus einbauen, Comport ist da schon bekannt.

Ich müsste also nur dem Loader den Comport übergeben und eine Datei zum 
flashen. Irgendwelche Tipps?

Louis

Ja, das geht. Der Bootloader relevante Teil befindet sich auch in der 
AVRootloader.dll. Du kannst diese DLL in deine Delphi Anwendung 
einbinden, das sähe so aus wie im Attachment gezeigt.

Als erstes entpackst du diese ZIP zb. nach c:\programme\atmel\ mit 
Ordnern. Dann startest du Delphi und öffnest das Project1.dpr im Pfad 
..\AVRootlaoder\Test DLL\. Darin zeige ich wie man die AVRootloader.dll 
über die Unit AVRootIntf.pas benutzen könnte. Ist alles auf ein Minimum 
reduziert damit man die Funktionweise besser sehen kann. Im Grunde für 
ein bischen erfahrenen Laien echt einfach.

Du benötigst später deine EXE, die AVRootloader.dll, AVRootloader.dev 
und die von dir compilierte *.ACY Datei zu deiner *.HEX und *.EEP Datei. 
Eine ACY Datei enthält das HEX für den FLASH (Programm) wie auch die 
EEPROM Daten aus der *.EEP Datei wenn man das möchte. Die Daten im ACY 
sind natürlich mit dem Paswort und XTEA verschlüselt. Im DEMO prjekt 
kannst du solch eine ACY Datei ezeugen lassen und sie dann 
Programmieren.

Die AVRootloade.asm habe ich so angepasst das sie für einen ATmega162 im 
1-Wire-RS232 mit sicherer Verschlüsselung arbeitet. Das musst du an 
deine Bedürfnisse anpassen, steht aber in der Readme drinnen wie und 
was. Das Test.hex das ich mitliefere ist für einen ATmega162.

Ich würde das DEMO an deiner Stelle also soweit reduzieren das man nur 
noch den "Program" Button hat. Eventuell sogar ganz ranehmen und die 
Aktion gleich nach dem Start der Anwendung ausführen. Mit der normale 
PC-Bootloader-Software im Ordner \AVRootloader\Windows\ kannst du nun 
deine  *.ACY Dateien verschlüsselt erzeugen und sie dann mit deinem 
Program in den AVRladen lassen. Also alles wie die Buttons "Connect", 
"Erase", "Compile" raus. Die Methoden .GetACYFileName und 
.GetEEPROMFileName liefern immer '' zurück. Nur die Methode 
.GetFLASHFileName gibt den Namen deiner *.ACY Datei zurück.

Minimalistisch sähe es so aus:

1

uses AVRootIntf;

2

3

type

4

  TMyObj = class(IApplication)

5

    procedure ProcessMessages; stdcall;

6

    procedure Changed; stdcall;

7

    procedure Output(const Msg: WideString; Code: Integer); stdcall;

8

9

    function GetFLASHFileName: WideString; stdcall;

10

    function GetEEPROMFileName: WideString; stdcall;

11

    function GetACYFileName: WideString; stdcall;

12

    function GetPassword: WideString; stdcall;

13

    function GetBootSign: WideString; stdcall;

14

    function GetTimeouts: TTimeouts; stdcall;

15

16

    function OpenCommunication: ICOM; stdcall;

17

18

    constructor Create;   

19

  end;

20

21

procedure TMyObj.ProcessMessages;

22

begin

23

end;

24

25

procedure TMyObj.Changed; 

26

begin

27

end;

28

29

procedure TMyObj.Output(const Msg: WideString; Code: Integer); 

30

begin

31

end;

32

33

function TMyObj.GetFLASHFileName: WideString; 

34

begin

35

  Result := ExtractFilePath(ParamStr(0)) + 'test.acy';

36

end;

37

38

function TMyObj.GetEEPROMFileName: WideString; 

39

begin

40

  Result := '';

41

end;

42

43

function TMyObj.GetACYFileName: WideString; 

44

begin

45

  Result := '';

46

end;

47

48

function TMyObj.GetPassword: WideString; 

49

begin

50

  Result := '';

51

end;

52

53

function TMyObj.GetBootSign: WideString; 

54

begin

55

  Result := 'BOOT';

56

end;

57

58

function TMyObj.GetTimeouts: TTimeouts; 

59

begin

60

  Result.Base := 50;

61

  Result.Erase := 20;

62

  Result.Flash := 25;

63

  Result.Eeprom := 20;

64

  Result.Buffer := 1;

65

  Result.RTSPulse := 0;

66

  Result.RTSInterval := 0;

67

end;

68

69

function TMyObj.OpenCommunication: ICOM; 

70

begin

71

  Result := OpenCOM('\\.\COM2', Self);

72

  Result.SetParams(115200);

73

end;

74

75

constructor TMyObj.Create;

76

begin

77

  OpenAVRootloader(Self).DoProgram(False, False);

78

end;

Gruß Hagen

Im Attachment mal das Test project für den ATmega162 das ich benutze. 
8Mhz interner Takt, an PD0 der 1-Wire-RS232 RX, wenn man 2-Wire testen 
möchte dann an PD1 der TX Pin und an PD3 eine LED mit Vorwiderstand nach 
VCC.

Vergiß niemals die Lockbits entsprechend zu setzen. Also nach dem Upload 
der Bootloader Software die Lockbits so setzen das ein Auslesen des AVRs 
nicht mehr möglich ist. Ansonsten hat das alles ja keinen Nutzen ;)

Gruß Hagen

Naja andererseits kannst du dir auch die Arbeit sparen und meine fertige 
PC-Software benutzen, rufe sie in deinem Falle mit folgenden Parametern 
auf

AVRootloader.exe -PCOM2 -B112500 -Dc:\pfad_zu_deinen_ACY_files\ 
-Ftest.acy -Apc

Damit startest du meine PC-Software, diese versucht eine Verbindung über 
COM2 mit 112500 Baud und flasht Test.ACY das im Pfad 
c:\pfad_zu_deinen_ACY_files\ liegt und schließt die PC-Software nach 
erfolgereicher Aktion wieder automatisch -> Parameter -Apc.

Die Erklärung dieser Kommandozeilenparameter findest du in 
AVRootloader.txt.

Möchtest du eine unverschlüsselte HEX/EEP Datei auf diese Weise in einen 
AVR uploaden der nur mit verschlüsselten Daten arbeitet dann füge den 
Parameter -K5441C8CA4DDF8EEA19AAAFD877AEB488 noch hinzu. Natürlich den 
Key den du in deinem Bootlaoder auch benutzt. Sollte einer dieser 
Parameter nicht übergeben worden sein so lädt die PC-Software die 
nötigen Einstellugen aus der INI-Datei AVRootloader.ini. Man könnte also 
auch einfach "AVRootloader.exe -Apc" aufrufen und sollte dann vorherig 
einmalig alle Parameter im GUI der Software voreingestellt haben.

Vergiß auch nicht ein neues Passwort zu erzeugen, damit du nicht das im 
Source vordefinierte benutzt, macht ja keinen Sinn wenn jeder dein 
Passwort kennt ;) Dazu startest du meine PC-Software und drückst den 
"Make Password" Button auf der ersten Seite. Daraufhin wird per Zufall 
ein Passwort erzeugt und auch gleich in AVRootloader.asm geschrieben. 
Alternativ kannst du auch noch dieses neue Passwort in die 
AVRootlaoder.ini schreiben lassen. Und es wird auch noch in die 
Zwischenablage kopiert, also einfach STRG+EINFG drücken wenn du es 
woanderst sichern möchtest.

Gruß Hagen

Vielen vielen Dank für die ausführliche Info! Echt super, dann kann ich 
ja gleich loslegen :)

Ich habe nur ein kleines Problemchen: Meine Hardware meldet sich nicht, 
ich flashe den Bootloader nach dem Compilergang, das klappt wunderbar.

Aber leider bekomme ich keine Verbindung.
Ich habe einen Mega644p mit 16 MHz, habe BOOTRST gesetzt, BOOTSZ0 und 
BOOTSZ1 nicht.

Mit dem Fastboot von Peter Danegger klappt es an der Hardware prima, 
Deiner läuft offenbar nicht. Was könnte ich da falsch machen?
Habe den normalen Uart0 an, also PD0 und PD1 als Pins.
Uartinvert habe ich beide ausprobiert.

Irgendwelche Tipps?

Louis

1.) in AVRootloader.asm
.include "m644Pdef.inc"
.equ  UseWDR      = 1
.equ  UseAutobaud    = 1
.equ  UseVerify    = 1
.equ  UseE2Write    = 1
.equ  UseE2Read    = 1
.equ  UseSRAM      = 0
.equ  UseCrypt    = 1
.equ  UseCryptFLASH           = 1
.equ  UseCryptE2    = 1
.equ  UartInvert    = 1

.equ  RX_PORT      = PORTD
.equ  RX      = PD0
.equ  TX_PORT      = PORTD
.equ  TX      = PD1

.set  XTAL      = 16000000
.set  BootDelay    = XTAL/4
.set  BootBaudrate          = 115200
.set  BootVersion    = 2
.set  BootCodeSize          = 852

nun neu kompilieren, und HEX file auf AVR uploaden. Fuse auf "First Boot 
Start" und BOOTRST setzen. Boot Flash size=512 words Boot start 
address=$7E00 ($FC00)

Danach AVR über RS232, du benutzt doch einen Pegelwandler ? falls nicht 
und du benutzt direkt die RS232 Leitungen dann UartInvert=0 setzen.

PC-Software starten, und richtigen COM Port auswählen und Baudrate 
einstellen 112500 ist ein guter Wert. Nun Button "Connect to Device" 
drücken und eventuell den AVR reset'en. Im "Protocol" Window sollte dann 
stehen das er auf 2-Wire Modus gewechselt ist.

Wenn er dann eine Verbindung hat kannst du in "Device Information" alle 
wichtigen Einstellungen zum AVR sehen.

Als nächsten Test "EEPROM Content" und "Read from Device" ausprobieren. 
Und dann mal einige Änderungen von Hand im HEX Editor machen und "Write 
to Device" drücken.

>> Deiner läuft offenbar nicht.

bei dir nicht ;)

Hast du sonst igrendwas in AVRootloader.asm verändert ? zb. BootSign: 
"BOOT" oder sowas ?

Gruß Hagen

Arg...es war der Programmer, der Hat Mist geschrieben, am Ende fehlte 
etwas, anscheinend ist der defekt. Ich habe es jetzt aber am Laufen, 
wunderbar!
Encryption läuft auch, genau das habe ich gesucht. Super, vielen vielen 
Dank!

Louis

Hi Louis,

beachte bitte folgendes damit es auch kryptographisch sicher ist:

1.) erzeuge mit der PC-Software einen neuen Schlüssel
- steht dann in AVRootloader.asm bei BootKey: drinnen, 16 Bytes
- steht wenn du möchtest in AVRootloader.ini in Password=?? drinnen
2.) stelle sicher das die Option UseSRAM=0 ist. Ansonsten kann nämlich 
ein cleverer Angreifer den Bootloader ausnutzen um ihn zu knacken indem 
er gezielt den SRAM und damit IO/Register Bereiche manipuliert.
3.) stelle sicher das UseCryptFLASH=1 ist, ansonten bei UseCryptFLASH=0 
kann man verschlüsselte wie auch unverschlüsselte Daten schreiben, und 
somit auch ein eigenes Program das den Bootlaoder FLASH ausliest und 
somit auch den BootKey:, es sei denn das LPM/SPM in der Application 
Section verboten wird über die Fuses.
4.) wenn du deine/meine Bootloader-PC-Software deinen Kunden gibts 
stelle sicher das dort in der AVRoiotloader.ini bzw. nirgends der 
Schlüssel gespeichert ist
5.) liefere ausschließlich nur verschlüsselte ACY Dateien aus

Falls du mit Delphi meine AVRootloader.dll benutzt wäre ich für ein 
Feedback sehr dankbar, ich würde gerne sehen was daraus wird ;)

Gruß Hagen

Hallo Hagen,

danke für die Tipps, ich habe sie jetzt bei einem Exemplar mal 
angewandt, das Teil ist jetzt sozusagen dicht und nur noch durch meine 
Software beschreibbar. Das ist genau das, was ich gesucht habe, jeder 
kann ein Update flashen, aber nur eins dass von mir kommt und geprüft 
ist. So kann auch keiner den Code knacken und sehen wie die Software 
arbeitet. perfekt.

Mein Mega64 wird nach Abschluss mit beiden Lockbits gelockt, das sollte 
so bombensicher sein.

Ich gebe bescheid wenn ich die Software soweit habe, noch ist sie nicht 
100% fertig.

Louis

>Mein Mega64 wird nach Abschluss mit beiden Lockbits gelockt, das sollte
>so bombensicher sein.

Aber nicht den Fehler machen, wie ich aus Überschwenglichkeit, alle 
Lockbits zu setzen, auch diejenigen die dem Bootloader den LPM/SPM 
Befehl sperren ;)

Gruß Hagen

Hehe, nene, so doof bin ich nun auch wieder nicht..

Btw, was genau bedeutet eigentlich SPM und LPM? Steht überall im 
datasheet, nur die Erklärung fehlt...

Louis

SPM - Store Program Memory
LPM - Load Program Memory

Weist auf die beiden gleichnamigen Assembler Mnemonics, mit denen sich 
der Mikrocontroller selbst den Flash schreiben bzw. aus seinem eigenen 
Flash (innerhalb des Programms) lesen kann.

Ich habe die sehr nette AVRootloader fuer ein ATmega32 implimentiert. Es 
funksioniert auch schon, aber nicht alles wie es beschreibt ist.

"Make Password" ohne in AVRootloader.ini zu spechern tut nichts. Was 
heist "in die Zwischenablage kopiert und kann so anderenorts gespeichert 
werden"?

Bei mir wird nichts weiter abgefragt un nichts gespeichert.

Muss in AVRootloader "Password =   " stehen mit blank?

Doch, tut es: Das Kennwort wird in die .asm-Datei des Loaders 
gespeichert, (ganz unten...) Beim Assembler-Lauf wird es dann in den 
Code eingefügt, der Loader muss es ja irgendwo her wissen wenn er einsam 
und alleine in seinem Megaxxx seitzt und auf Programme wartet.

Das Passwort selbst wird in die Zwischenablage kopiert, öffne Notepad 
und drücke STRG+V, dann siehst Du es.

Das Kennwort solltest Du GUT aufbewahren, ist es weg kannst Du keine 
Software mehr laden!

Louis

> Muss in AVRootloader "Password =   " stehen mit blank?

Jain ;) Entweder

[System]
Password=

mit oder ohne Leerzeichen ist egal da diese intern entfernt werden, oder

[System]
Password=0A5ED11C8B0FA36F7C4F1EE20526904B

oder

Password=$0A,$5E,$D1,$1C,$8B,$0F,$A3,$6F,$7C,$4F,$1E,$E2,$05,$26,$90,$4B

Alle Sonderzeichen, auch Spaces werden entfernt und das was übrig bleibt 
sind die HEX-Chars und das wird als Passwort benutzt. Ob man A..F groß 
oder klein schreibt ist egal.

Wenn kein Passwort in der INI Datei gespeichert wurde fragt die 
PC-Software per Dialogbox das Passwort ab wenn es benötigt wird. Das 
Passwort in die INI Datei zu speichern erleichtert dem Programmierer 
also die Arbeit. Bei der Installation der Software bei deinen Kunden 
sollte das Password nicht gespeichert werden, logisch.

Beantwortet man die Frage "Do you want to save Password in INI-File ?" 
mit NEIN/NO dann wird das Password in der INI Datei gelöscht.
Danach wird die AVRootloader.asm Datei mit dem neuen Passwort 
modifiziert und zusätzlich ins Clipboard kopiert. Du kannst es also per 
Paste irgendwo selber abspeichern.

Um das Passwort nicht zu verlieren bietet es sich an die geänderte 
AVRootloader.asm zu sichern, im Projektbackup das ja jeder Programmierer 
auch macht ?!

Nach "Make Password" muß also AVRootloader.asm neu kompiliert werden.

Gruß Hagen

Vielen Dank fuer die erklaerung. Jetz habe Ich wieder etwas neues von 
Deutsch gelernt: Zwischenablage = Clipboard !

Ich werd es mal wieder probieren.

letzte Version der PC-Bootloader Software downloaden.
Mit welchem Entwicklungswerkzeug hast du dein HEX erzeugt ? Also das was 
du über den Bootloader flashen möchtest.

In den älteren Versionen der PC-Software war bei der Interpretation der 
Daten im HEX File ein Fehler. Sobald im HEX File die Addressen nicht 
linear sortiert gespeichert wurden gabs mit der alten Version Probleme. 
Wenn man mit AVR Studio oder WinAVR GCC arbeitet entstand dieses Problem 
nicht.

Alternativ in der AVRootloader.INI die Section [Timeouts] modifizieren, 
sprich größere Timeouts wählen.

Ich tippe aber auf ersteres Problem. Kannst ja mal das HEX File posten.

Übrigens kannst du das UseVeritfy = 0 sezten und so par Bytes Code 
sparen was dazu führt das die 518 Bytes in deinem Falle unter 512 Bytes 
sinken und du somit eine Flashpage (64 Bytes) weniger für den Bootloader 
verbrauchst. Beim Schreiben vom FLASH/EEPROM ist schon eine Prüfsumme 
enthalten und auch ein integrierter Lesetest der soeben programmierten 
Daten, ergo: ein implizites Verify. Das zusätzliche externe Verify das 
mit UseVerify=1 aktiviert wird dient nur als zusätzliche Absicherung 
bzw. um testen zu können ob der FLASH eines schon programmierten AVRs 
mit einem HEX File übereinstimmt. Wenn man also nur sichergehen möchte 
das die aktuelle Programmierung korrekt verlief dann recith das 
impliziete Verify aus und man kann mit UseVerify=0 einiges an Code 
sparen (der natürlich dann deiner Anwednung zugute kommt).

Gruß Hagen

Ok, aktuellste Version hast du und HEX sieht auch sauber aus. Bleiben 
noch zwei Möglichkeiten

a) erhöhe die Timeouts, denke aber nicht das das was ändert
b) dein AVR könnte defekt sein, bzw. dessen Spanungsversorgun instabil. 
Versuche den AVR mal über ISP zu flashen.

Connecte mal mit dem Bootloader und poste hier alle was im Info Fenster 
angezeigt wird, vielleicht kann ich ja daraus was erkennen.

Downloadplace ist hier dieser Thread ;)

Gruß Hagen

Daniel wrote:
> Leider kommt beim Flashen folgender Fehler:
> Cmd.WriteFlash.ResCheck()  Error: Verify failed

Ich tippe mal auf Selbstprogrammierfuse nicht gesetzt.


Peter

@Elektroniker

Ich habe das Datenblatt des ATMega8535 nicht zur Hand aber die Fuses 
müssen so programmiert werden das
- das Auslesen per ISP etc.pp. nicht mehr möglich ist
- das die korrekte Bootsection eingestellt wird, also >= 512 Bytes = 256 
Words
- evntl. den SPM Befehl aus der Application Section verboten wird
- evntl. der LPM Befehl aus der Application Section verboten wird
- der Code in der Boot Section, eg. der Bootloader, per SPM und LPM 
Zugriff auf die Application Section und mindestens per LPM Zugriff auf 
die Boot Section hat

Der Bootloader muß also per SPM + LPM in die Application Section Zugriff 
haben. Du kannst den SPM ZUgriff des Bootloaders in die eigene Boot 
Section verhindern damit sich der Bootloader nicht selber löschen kann. 
Aber in jedem Fall muß der Bootloader per LPM den kompletten FLASH 
auslesen können. Einerseits weil der Bootloader nach dem Programmieren 
des FLASH/EEPROM per LPM diesen wieder ausliest und mit den soeben 
programmierten Daten im SRAM-Buffer vergleicht, ergo implizites Verify 
beim Programmieren. Und andererseits weil der Bootloader am Ende im 
FLASH eine Tabelle mit wichtigen Daten enthält die er auslesen können 
muß, also solche Daten wie Signatur und Identifier.

Lange Rede kurzer Sinn: ich schätze du hast zu viele Lockbits gesetzt 
und damit den Bootloader ausgesperrt.

Gruß Hagen

>Bei der Function "Button2Click..." habe ich "FLoader.DoProgram(False,
>False)" probiert und bekommen die gleichen Rückmeldungen wie unter
>Einstellungen von "True":

Der Parameter "VerifyFlash" = TRUE kann nur dann von Relevanz sein wenn 
die Datei die du flashen möchtest eine reine HEX Datei ist. Ist es aber 
eine "precompilierte" ACY-Datei dann entscheiden die Optionen die bei 
ihrer Kompilierung gesetzt waren. Erkennen kannst du das ganz einfach am 
letzten Punkt im Protokoll

>selected options in compiled file:
>- programming FLASH
>- erase FLASH during programming
>- full verify FLASH after programing

full verify FLASH after programming ist VerifyFLASH=TRUE bei einer 
HEX-Datei oder die vergleichbare Checkbox in der 
PC-Bootloader-Applikation bei der Erstellung einer ACY-Datei.

Ändert aber nichts an der Sache, da der Bootloader schon während des 
impliziten Verifys gleich nach der Programmierung aussteigt. Dieses 
Verify kann nicht deaktiviert werden per PC-Software, höchstens indem 
man die AVRootloader.ASM Datei umschreibt.

Es gibt also im AVRootloader gleich zwei Arten des Verify. Das implizite 
Verify wie vorher ausgiebig beschrieben. Und das separate und zu jeder 
Zeit nachträglich durchführbare Verify, wie bei den vielen anderen 
Bootloadern üblich. Letzeres benötigt man eigentlich nur um verifizieren 
zu können ob der Inhalt einer gegebenen HEX Datei mit dem Kontext im AVR 
übereinstimmt.

Gruß Hagen

>Soviel ich verstanden habe, werden die Lockbits immer gelöscht (egal vom
>Bootloader oder über ext. Programmer), wenn das FLASH gelöscht oder neu
>beschrieben wird.
>Leider geht es nicht mit EXE-Progr. weil er gleich den Inhalt lesen
>möchte und nicht vorher löscht oder neu beschreibt. Könnte das nicht
>abgeändert werden, wenn ich den µC FLASH neu beschreiben möchte?
>Oder?

Nee da hast du was falsch verstanden. Der Bootloader selber setzt die 
Fuses nicht, das kann er garnicht. Man könnte für neuere AVRs die 
verschiedene Fuses per Program setzen können, diese Funktionalität in 
den Bootloader implementieren, aber dabei sehe ich keinen wirklichen 
Nutzen.

Du programmierst über ISP/JTAG/DW die AVRootloader.HEX in den AVR, 
natürlich vorher kompiliert für deinen AVR mit deinen gewünschten 
Optionen. BOOTSZ Fuse setzen damit der AVR beim RESET den Bootloader 
startet. Danach mit PC verbinden und PC-Bootloader starten und als Test 
mal EEPROM/SRAM auslesen und schreiben. Wenn das geht kannst du die 
Lockfuses setzen. Das dürfte schon reichen denn nun kann man den 
ISP/JTAG nur noch aktivieren wenn man den AVR vollständig löscht.

Also mit AVRStudio so:

BOOTSZ=Boot Flash size=256 words Boot address=$0F00

Lockbits:
LB=Further programming and verification disabled
BLB0=SPM prohibited in Application Section
BLB1=No lock on SPM and LPM in Boot Section

Ergibt Lockbits=0x38

Man kann also den ATMega8535 schon so konfigurieren das es ziemlich 
sicher ist.

Die Frage ist also mit welchem Programmiertool du den AVR flash'st.

Gruß Hagen

>bei Verwendung von 'BootMsg' unbedingt darauf achten, dass der Text eine
>UNGERADE Anzahl von Zeichen enthält.
>Ansonsten hängt der Assembler ein NullByte an.
>Dieses Byte wird auch ausgegeben und verwirrt das PC-Programm.

Das lässt sich im PC-Program sehr einfach abstellen, werde das demnächst 
mal bereinigen. BootMsg kann man auch nur verwenden wenn der Bootloader 
ohne Verschlüsselung arbeitet.

>Das PC-Prog erkennt den connect nur zum Teil. Das Senden der 'BootSign'
>wird eingestellt, das Programm selbst geht aber nicht in den Zustand
>"connected".

Könntest du mir genauer erklären was du damit meinst ?
Ich interpretiere deine Aussage so das die PC-Software den 
Connection-Aufbau einstellt, sprich in den Connect-Status wechselt, 
obwohl der Bootloader im AVR immer noch im Connectaufbau verbleibt.
Eigentlich ist das aber sehr unwahrscheinlich. Die PC-Software sendet 
permanent das BootSign. Solange bis der AVR die richtige Baudrate 
detektiert hat und das empfangene BootSign mit dem im AVR im FLASH 
gespeicherten verglichen hat und Übereinstimmung existiert. Danach 
sendet der AVR seine BootInfo an die PC-Software. Diese geht erst in den 
Connect Status wenn sie diese BootInfo sauber empfangen hat und die 
darin enthaltenen Angaben auch stimmig sind. Dh. normalerweise geht der 
AVR als erster in den Connect-Status und erst danach die PC-Software. 
Von daher ist es also unwahrscheinlich das die PC-Software schon im 
Connectstatus ist der AVR aber noch nicht.
Sollte es zu dem Fall kommen das der AVR nach Senden der BootInfo im 
Connectstatus ist die PC-Software aber die empfangene BootInfo nicht 
erkennt dann beginnt der Connectionaufbau von vorne. Die PC-Software 
sendet also weiterhin #0#0#13 + BootSign. Der AVR der schon in der 
Kommandoschleife ist, also connected, erkennt aber die beiden #0#0 
Zeichen als Restart-Kommando. Bei diesem Kommando springt also der AVR 
wieder an den Anfang des Bootloaders und befindet sich dann wieder im 
Connection Aufbau Status. Dh. selbst wenn der AVR schon im Connectstatus 
ist die PC-Software aber noch nicht so synchronisiert sich der AVR 
spätestens beim nächsten Connectionaufbau der PC-Software neu.

Je länger also BootSign gewählt wird desto wahrscheinlicher kann die 
PC-Software und der AVR einen Fehler in der autom. Baudrate-Erkennung 
oder Datenübertragung erkennen. Es ist also von Vorteil für die 
Stabilität wenn BootSign länger gewählt wird.

Gruß Hagen

>AVR antwortet mit:
>[94][06][02][08][30] = 4 Byte 'BootInfo' + Success
>[48][65][6C][6C][6F][20][57][6F][72][6C][64][30] = 11 Byte 'BootMsg' +
>Success
>[C2][94][06][02][08][30] = 1 Byte ??? + 4 Byte 'BootInfo' + Success
>[48][65][6C][6C][6F][20][57][6F][72][6C][64][30] = 11 Byte 'BootMsg' +
>Success

Was mich wundert ist das der AVR zweimal die BootInfo sendet. Das 
unbekannte Byte 0xC2 ist ein Fehlercode.

Im Attachment mal eine geänderte Version der AVRootloader.exe. In dieser 
behandle ich die evntl. auftretenden Nullterminatoren der BootMsg.

Gruß Hagen

BootMsg liegt zwischen BootInfo und BootKey. Bei der Aushandlung der 
Verschlüsselung zwischen Bootloader und PC Software wird ein verschl. 
Prüfcode benutzt. Dieser besteht aus BootInfo und ersten 4 Zeichen von 
BootKey. Bevor die verschl. Daten an den AVR gesendet werden, muß dieser 
Prüfsummen-Block an den AVR gesendet werden. Nur wenn die entl. 
Prüfsumme identisch zu BootInfo + 4 Zeichen BootKey ist, kann der AVR 
programmiert werden, bzw. akzeptiert der Bootloader die 
Programmierungskommandos.
Liegt nun eine BootMsg zwischen BootInfo und BootKey so verändert dies 
die Signatur.

Gruß Hagen

Hallo Hagen,
ich muß gestehen daß ich Deinen Code noch nicht so ganz verstehe. Den 
anfänglichen Verbindungsaufbau durch Vergleich von [BootSign] und 
anschließender Übertragung der [BootInfo]+ SUCCESS, sowie optionaler 
[BootMsg] + SUCCESS zum PC habe ich soweit begriffen. Doch wie geht's 
weiter? Ich glaube erkannt zu haben daß zuerst eine komplette Page ins 
SRAM abgelegt wird, die im AVR berechnete CRC16 mit der vom PC 
verchickten CRC16 verifiziert wird und anschließend der eigentliche 
,Erase-Flash'-Vorgang gestartet wird.

OK,ich weiß - eigentlich läßt sich Dein Bootloader ohne nennenswerte 
Modifikationen verwenden. Das ist bei meinem Projekt (Funkvernetztes 
Multicontrollersystem) so nicht möglich. Ich würde mich deshalb sehr 
freuen wenn Du mir das Protokoll im Detail beschreiben könntest.

Viele Grüße
Marcus

@Klugscheisser:

1.) XTEA ist eine Stromverschlüsselung. Normalerweise benutzt man bei 
diesen Ciphern keine Feedbackoperationen sondern wendet sie direkt auf 
den Datenstrom an. Dabei wird mit XTEA aus einem Key ein Schlüsselstrom 
erzeugt, quasi wie bei einem Pseudozufallsgenerator der Seed und der 
Zufallsbitstrom, und dieser wird einfach per XOR mit den Daten 
verknüpft.

2.) CBC ist ein Feedbackmodus der für die Blockverschlüsselungen 
sinnvoll ist. CBC ist dabei ein sogenannter selbstsynchronisierender 
Feedbackmodus, es gibt auch noch andere. Eine Blockverschlüsselung 
zerlegt die Nachricht in Datenblöcke a zb. 8 Bytes und verschlüsselt 
dann mit dem Cipher diese Blöcke, jeweils immer komplett separat ohen 
Abhängigkeiten zwischen den einzelnen Blöcken. Das wäre der ECB Modus -> 
Electronic Code Book Cipher Mode. CBC verknüpft nun diese Datenblöcke 
untereinander. Angenommen wie haben eine Nachricht aus 4 Datenblöcken a 
8 Bytes. Der zu entschlüsselnde Ciphertext wurde aber mit einem 
Bitfehler empfangen der sich im 2. Datenblock befindet. Wird nun 
entschlüsselt so passiert beim CBC folgendes: 1. Datenblock wird korrekt 
entschlüsselt. 2. Datenblock wird auf Grund des Bitfehlers komplett 
falsch entschlüsselt. 3. Datenblock kann unter Umständen ebenfalls noch 
falsch entschlüselt werden, aber der 4. Datenblock wird wieder korekt 
entschlüsselt.

Dh. Selbstsynchronisation bei einem Feedback Modus heist das sich ein 
Bitfehler in einem Datenblock maximal diesen Datenblock + dem 
nachfolgenden Datenblock falsch entschlüsselt. Alle nachfolgenden 
Datenblöcke, wenn ohne Fehler empfangen, werden auch wieder korrekt 
entschlüsselt.

3.) angenommen unser Ciphertext umfasst 10 Datenblöcke. Der 10. 
Datenblock enthält eine Prüfsumme oder einen bekannten Identifier oä. 
Wir möchten nun das wenn in einem der 10 Datenblöcke ein Bitfehler 
entstanden ist das der letzte 10. Prüfsummendatenblock mit 100% 
Sicherheit auch komplet zerstört wird. Dh. wir möchten das ein Bitfehler 
im Ciphertext sich bis zum letzten Datenblock propagiert.

Dies zerstört die Selbstsynchronisation des CBC-Modus, dh. die 
Selbstsynchronisation des CBCs ist für unserer Zwecke unerwünscht. Denn

4.) wie wollen mit XTEA nicht nur Daten schützen sondern deren 
Integrität sicherstellen. Und dazu kann man sogennate CMACs benutzen, 
also Message Authentification Codes basierend auf 
Ciphern/Verschlüsselungen.

5.) Da XTEA eine Stromverschlüsselung ist habe aber die Plaintextdaten 
keinen Einfluß auf den internen Zustand des Ciphers. Dh. der Copher 
produziert nur vom Passwort abhängige Schlüsselströme. Bei einem 
Blockcipher stellt der äußere Feedbackmodus, hier CBC, aber sicher das 
der Ciphertext sowohl vom Passwort wie aber auch Datenstrom abhängig 
ist. Und exakt das benötigen wir auch um überhaupt einen CMAC aufbauen 
zu können, also die Abhängigkeit alle nachfolgenden verschlüsselten 
Datenbytes vom Schlüsselstrom wie auch von den vorherig verschlüsselten 
Datenbytes.

6.) also benutzt meine XTEA implementierung einen Feedbackmodus der im 
Grunde genommen für XTEA als Stromverschlüsselung normalerweise garnicht 
benutzt wird. Würde man diesen äußeren CBC Feedback nur anwenden nachdem 
ein Datenblock durch XTEA verschlüsselt wurde dann würden sich die 
Datenbytes der Nachricht aber nicht auf die internen Zustandsregister 
des XYTEAs nicht auswirken. Es fehlt also eine grundlegende Bedingung um 
mit XTEA+CBC einen CMAC errechnen zu können. Deshalb arbeitet mein XTEA 
so das er die 32 Runden in 2x 16 Runden XTEA splittet. Der CBC Modus 
wird nun zweimal angewendet, einmal vor der Entschlüsselung des 
Datenblockes, für die ersten 16 Runden. Dann wird das 
CBC-Feedback-Register erneut mit dem internen XTEA Registern 
xor-verknüpft und nochmals die zweiten 16 Runden XTEA angewendet. Nun 
ist sichergestellt das auf kryptographisch sichere Weise der Datenstrom 
der Nachrichtenbytes in den internen Status des XTEAs eingearbrieitet 
wurde. Wir können nun mit diesem XTEA Daten verschlüsseln wie auch die 
Integrität der Daten durch einen CMAC überprüfen. Denn ein empfangener 
Bitfehler führt mit 100% sicherheit immer dazu das alle nachfolgenden 
Datenbits bishin zum letzen Datenblock fehlerhaft entschlüsselt werden 
müssen.

Nun der Bootloader verschlüsselt mehrere FLASH Pages in folgender Weise:

1.) ein 8 Bytes Datenblock aus ZUfall wird erzeugt + 8 Bytes BootInfo 
Signatur + ersten 4 Bytes des Schlüssel. Dieser Datenblock wird als 
allerrster zum AVR gesendet und initialsiert die Entschlüsselung. Durch 
die Zufallsbytes und der Eigenschaft der vollständigen Propagation 
meiner XTEA+2xCBC Implementierung heist dies das unsere kompletter 
Ciphertext randomisiert wurde. Also selbst wenn man die exakt gleiche 
HEX Datei mit dem exakt gleichen Key merhmals verschlüsseln würde so 
wäre der Ciphertext immer komplett anderst. Dies verhindert solche 
Angriffe wie Known Plain-/Ciphertext/Reply/Exchange Attacks.
Zusätzlich serialisiert man das HEX auf den spezifischen AVR da die 
nächsten 4 Bytes identisch zur BootInfo sein müssen. Dh. ein verschl. 
HEX kann nur entschlüsselt werden wenn die im ersten Block enthaltene 
BootInfo (Signatur des Bootloaders + AVR) identisch ist. Die letzen 4 
Bytes im Datenblock sind die ersten 4 Bytes des Passwortes, also 32Bit. 
Der AVR entschlüsselt also diesen ersten Datenblock und nur wenn diese 4 
Schlüsselbytes identisch zum Key sind kann korrekt entschlüsselt werden. 
Man detektiert somit also entweder einen Datenübertragungsfehler mit 
1/2^32 Wahrscheinlichkeit oder aber man erkennt das mit einem falschen 
Passwort gearbeitet wurde. Wichtig dabei ist es das dem Angreifer 
keinerlei Möglichkeiten in die Hand gegeben werden einen Ciphertext 
schneller als bei einer Brute Force Attacke brechen zu können und auch 
das der Angreifer unsere "Prüfsummenlogik" mißbrauchen kann um seine 
Brute Force Attacke zu beschleunigen. Das stellt der Zufallsseed und das 
unbekannte Passwort als Verifier sicher.

2.) Nun sendet der AVR Blockweise die zu programmierenden FLASH Daten. 
Dabei sind diese Daten in Blöcke a max. nutzbarere SRAM für Buffer 
aufgesplittet. Bei einem SRAM mit 256 Bytes und einer FLASH Pagesize von 
64 Bytes wird dieser Buffer also 192 Bytes groß sein und man kann 3 
FLASH Pages am Stück übertragen. Der XTEA Cipher wird dabei nicht mehr 
neu initialisiert sondern arbeitet mit der Initialisierung im Step 1.) 
immer weiter. Somit hängt der Erfolg der korrekten Entschlüseelung 
dieser Datenblöcke von allen vorherigen Datenblöcken ab. Der PC sendet 
nun 192 Bytes an Daten die ge-flasht werden sollen und hängt als letzten 
8 Bytes Datenblock wiederum einen Spezialdatenblock an. In diesem wird 
auf die Addresse des FLASHs in dem die Daten geflasht werden sollen 
verschlüsselt. Also auch die Addresse wohin man die Daten schreiben soll 
sind verschlüselt gespeichert. Neben dieser Addresse (3 Bytes) sind in 
diesem Datenblock wiederum die ersten 4 Bytes des Keys verschlüsselt, 
quasi als Prüfsumme. Da mein XTEA+2xCBC, wenn er mit einem Bitfehler 
dekodiert, alle nachfolgenden Datenbytes ebenfalls falsch dekodiert, 
wird somit diese 4 Bytes Prüfsumme ebenfalls falsch dekodiert. Man kann 
also mit einer Entschlüsselung nicht nur die Daten schützen sondern 
sparrt sich einen extra Prüfsummen Algorithmus zu implementieren der 
auch kryptographsich sicher sein muß ! Eine CRC ist ja kryptographsich 
nicht sicher man müsste schon mit einem HMAC-> Hash Message 
Authenfication Code arbeiten und somit würden wie einen Hashalgo. wie 
SHA1 oä. implementieren müssen. Das sparen wir uns mit meiner 
abgewandelten Form des XTEAs.

Einen kryptographischen Beweis der Sicherheit meiner Abwandlung kann und 
werde ich dir nicht liefern können. Aber wenn du mal genau drüber 
anchdenkst ist das auch nötig da ich nur die bekiannten Verfahren 
entsprechend kombiniert habe. Ich gehe also davon aus das meine 
Abwandlung nicht die Eigenschaften des XTEAs noch CBCs kryptrographisch 
negativ beeinflusst. Immerhin wende ich wie gehabt CBC vor der 
Entschlüsselung an, das ist Standard. Dann nach der Hälfte der 
Entschlüsselung wende ich CBC erneut an und beeinflusse nur indirekt 
über die XOR Operation den internen Status des XTEAs, das hat keinen 
Einfluß auf die Sicherheit vom XTEA da wir nur die zu entschl. Daten 
modifizieren.

Sogesehen basiert mein 2x CBC zwar auf CBC hat aber längst nicht mehr 
die Eigenschaften eines normalen CBC Modus.

Gruß Hagen

PS: ich habe jetzt nicht nochmal alles quergelesen, Tip- und 
Rechtschreibfehler kannste behalten ;)

Ich musste bei der Konstruktion verschiedene Aspekte berücksichtigen

1.) Algo. muß auf AVR performant und Resourcenschonend sein
2.) alle mir bekannten Angriffe müssen ausgeschlossen sein. Also zb. das 
der Angreifer mal eben zwei Datenblöcke austauschen kann ohne das der 
Bootloader dies detektieren kann. Denn sonst wäre es möglich "gezielt" 
eine/mehrere verschl. Nachrichten neu zu rekombinieren, ohne das der 
Angreifer überhaupt Ahnung davon haben muß was er da an Daten vor sich 
hat.
3.) der Bootloader muß sicherstellen können das das verschl. HEX für 
seinen Prozessor/Bootloadertypus erzeugt wurde.
4.) der Bootloader soll erkennen ob die Daten mit dem korrekten Passwort 
verschlüsselt wurden
5.) oberste Priorität hat die Integrität der zu flashenden Daten. Dh. es 
muß ausgeschlossen sein das der Bootloader falsche Daten flasht.

Also aus meiner Sicht, und ich habe mittlerweile über 5 Jahre 
intensivste praktische Erfahrungen mit der Kryptographie, sehe ich zZ. 
keinen erfolgversprechenden Angriff auf die durch meinen AVRootloader 
geschützen Daten.

An der Dokumentation des kompletten Kommando-/Daten-/Verschl- 
Protokolles muß ich noch arbeiten. Bitte habt Verständnis das das noch 
ein bischen Zeit benötigt. Es ist für mich ein Aufwand von 6 Stunden 
sowas zu programmieren aber ein Aufwand von weit mehr Stunden sowas zu 
dokumentieren und nachfollziehbar zu erklären warum es so und nicht 
anders konstruiert wurde.

Gruß Hagen

>Vielleicht erlaubst Du mir doch die Bitte, doch den Quellcode der
>Windows-Software zu posten. Das wäre nett. (oder habe ich was
>übersehen?)

Hm, logisch betrachtet hat das Eine nichts mit dem Anderen zu tuen. 
Meine Intention die Windows-Software nicht frei verfügbar zu machen ist 
nicht in der Kryptograhie begründet, also zb. einer Hintertür die ich 
hätte einprogramieren können. Es ist eine Frage des Supportaufwandes und 
eben auch der Kontrolle der Verbreitung des AVRootloaders. Ich würde 
also vorschlagen das du mir eine PN sendest und wir dann per EMail 
aushandeln ob und wie du meine Sourcen benutzen/bekommen kannst. Die PC 
Software wurde mit Delphi5 also PASCAL programmiert.

>Wir können nun mit diesem XTEA Daten verschlüsseln wie auch die
>Integrität der Daten durch einen CMAC überprüfen. Denn ein empfangener
>Bitfehler führt mit 100% sicherheit immer dazu das alle nachfolgenden
>Datenbits bishin zum letzen Datenblock fehlerhaft entschlüsselt werden
>müssen.

Diese Aussage von mir ist nicht ganz korrekt. Denn eine 100%'tige 
Propagation von Fehlern kann es garnicht bei dem Verfahren geben. Wenn 
der letzte 8 Bytes Datenblock falsch entschlüsselt wurde dann haben wir 
mit 1/2^64 Wahrscheinlichkeit eine falsche Fehlerantwort vom System 
bekommen. Logisch da das interne Feedbackregister für den 2x CBC nur 8 
Bytes und der interene Status des XTEAs ebenfalls nur 8 Bytes groß ist. 
Somit ist dies identisch zu einer 64 Bit breiten Prüfsumme.

Der letze 8 Bytes Datenblock der nach den zu flashenden Daten gesendet 
wird besteht aus folgenden Daten:

3 Bytes Addresse an die diese Daten geflasht/geeepromt werden sollen
1 Byte Datenblock-Längen-Korregier-Byte. Angenommen wir möchten nur 5 
Bytes im FLASH speichern dann haben wir das Problem das XTA+2x CBC aber 
immer mit volständigen 8 Bytes großen Datenblöcken arbeiten muß. Wir 
müssen also diese 5 Bytes mit 3 Bytes Zufall auffüllen. Bei der 
ENtschlüsselung benötigen wir dann die Information das von den soeben 
entschl. 8 Bytes nur 5 Bytes von relevanz sind. Nun dieses 
Datenbblöck-Längen-Korrekturbyte macht dies, es würde dann den Wertt 3 
enthalten der dann am Ende der XTEA Prozedur von der 
Datenlängenvariablen subtrahiert wird. Dies hat den Vorteil das wir nur 
1 Byte an Datenmenge verbrauchen denn ansonsten müsste man eine 
Längenangabe der zu flashenden Daten benutzen und das wären mehr als 1 
Byte an Information die jedesmal pro Packet gespeichert werden müssen. 
Davon abgesehen kann der Korrekturfaktor nur den Wert 0 bis 7 annehmen 
und somit verbleiben 5 Bits ind diesem Byte die man noch anders benutzen 
könnte, als Flags zb.
4 Bytes Verifier, das sind die ersten 4 Bytes des BootKey. Dieser wird 
nach der ENtschlüsselung mit dem Bootkey verglichen und nur wenn 
identisch arbeitet das System weiter.

Beim allerersten empfangen Datenblock (16 Bytes) besteht der letzte 
Datenblock mit fast identischen Aufbau wie vorher beschrieben. Nur mit 
dem Unterschied das in den ersten 4 Bytes nun die BootInfo gespeichert 
wurde, statt Addresse + Korrektufaktor. Somit ist die 
Überprüfungsfunktion dieser "Prüfsumme" bei der Initialsierung wie auch 
Datenentschlüsselung fast identisch.

Dh. alle Datenblöcke im verschl. HEX File sind vom allerersten 
Initialiserungsdatenblock abhängig und somit auch von den allerersten 8 
Bytes des verschlüsselten Zufallsseeds.

Gruß Hagen

>1. In Deine Datei AVRootloader.txt lese ich "  Das zweifache XOR'ing des
>Feedback vor den ersten 16 Runden und vor den zweiten 16 Runden
>verändert den XTEA auf eine Weise das eine Alles oder Nichts
>Entschlüsselung entsteht. Ändert sich also nur 1 Bit in den Daten so
>wird der komplette Datenblock und alle auf ihn nachfolgenden Datenblöcke
>falsch entschlüsselt."

Alles oder Nichts aus Sicht der aktuellen Position eines Bitfehlers oder 
Bitmanipulation. Würde also das allererste Datenbit gekippt im 
Ciphertext dann soll der AVR die komplette Nachricht bis hin zum 
"Prüfsummen"block komplett fehlerhaft entschlüsseln. Sogesehen: man kann 
nur Alles oder Nichts korrekt entschlüsseln. Wir benötigen dieses 
Feature für den CMAC.

>2. Die Terminologie weicht von der mir bekannten ab.
>Was ist mit Feedback gemeint? Wo bleibt der Initialization Vector?

Feedback, das ist das zusätzlich mötige 8 Bytes Register das bei fast 
jedem Cipher-Feedbackmodus nötig ist. Feedback heist dann das über 
dieses Register und meistens per XOR Operation eine Verknüpfung der 
Datenblöcke untereinadner erfolgt. Würde man dies nicht machen, also im 
ECB Modus arbeiten dann kann man verschiedene Angriffe durchführen ohne 
den Cipher real brechen zu müssen. Zb. wir haben eine verschl. 
Banküberweisund die aus 2 Datenblöcken bestünde. Im ersten Datenblöck 
steht Absender + Betrag drinnen. Im 2. Datenblock steht der Empfänger. 
Wir veranlassen als Angreifer die Zielperson uns eine Banküberweisung zu 
machen, auf unser Konto. Wir fangen aber jede der verschl. 
Banküberweisungen der Zielperson ab. Diese tätigt nun eine Überweisung 
der Miete. Wir fangen diese Nachricht ab und ersetzen den letzen 
Datenblock mit dem Datenblock unserer Banküberweisung die an uns gehen. 
Schon geht die Miete auf unser Konto. Das ist möglich weil die 
Datenblöcke eben vollständig separat voneinander durch ECB verschlüsselt 
wurden.

Der InitVector ist hardcoded alles Nullen. Denn real betrachtet senden 
wir ja als ersten 16 Bytes Datenblock einen verschl. Block bei dem die 
ersten 8 bytes verschlüselster Zufall ist. Damit ist das real der 
InitVector aber eben verschlüsselt. Denn es ist ja egal ob wir den IV am 
Anfang mit lesbaren/ungeschützen Zufall benutzen oder aber einfach den 
ersten zu entschlüsselenden Datenblock per Zufall erzeugen und diesen 
dann als quasi "nachfolgenden" IV benutzen. Vorteil ist dabei das wir 
das System kryptogaphisch damit stärken, ich vertrete also die 
Auffassung das es besser ist mit einem fixen IV also Nullen o.ä. zu 
benutzen und dafür den ersten oder sogar noicht den 2. Datenblock 
einfach mit Zufall zu füllen und verschlüsselt zu speichern. In beiden 
Fällen haben wir technsich betrachtet den gleichen Aufwand nur ist bei 
meiner Methode der IV auch noch durch den Cipher geschützt.

Gruß Hagen.

Hm, jetzt rede ich die ganze Zeit davon das XTEA ein Streamcipher ist, 
das ist natürlich falsch denn es ist ein Blockcipher, sorry.

Gruß Hagen

Die zweistufige CBC Verknüpfung hat den Vorteil das man nur ein 8 Bytes 
großes Feedback Register benötigt. Wollte man die gleichen Features mit 
anderen Ciphermodis, die auch dafür konstrueirt wurden (also für CMAC) 
implementieren, dann benötigt man größere Register, also mehr an 
Variablen. Das wird für die Optimierung auf dem AVR den Registerdruck 
auf die CPU erhöhen und somit mehr Resourcen verbrauchen und damit die 
Performance reduzieren. Es ist dann einfacher XTEA als Funktion jeweils 
mit auf 16 reduzierten Rundenanzahl auf zwei Aufrufe zu implementieren. 
Und dann eben im Zwischenschritt das CBC-Feedbackregister erneut zu 
manipulieren.

Mein XTEA benutzt also ein Feedbackmodus der auf CBC als Operation 
basiert aber im Grunde ganz andere Eigenschaften des Gesamtsystemes 
erzeugt. Damit ist es kein CBC mehr basiert aber analytisch auf dem 
Kryptobeweis des CBCs.

Gruß Hagen

Melde dich hier an und sende mir eine PN und dann kannst du die Sourcen 
haben. Ich bin immer daran interessiert wenn sich dritte Personen die 
Zeit nehmen und meine Sourcen analysieren und somit eventuelle Fehler 
finden und beseitigt werden. Dasa erhöht ja die Anwendungssicherheit und 
verifiziert meine Arbeit. Davon abgesehen könnten wir so per EMail noch 
mehr Erfahrungen und Wissen austauschen und eventuell kann auch ich dir 
gerade bei den Kryptosachen noch par Tipps geben.

>XTEA wird es halt auf jeden Fall, da der Code dafür wirklich extrem
>klein sein kann.

Falls du ihn kürzer als meine Implementierung bekommst dann wäre ich dir 
sehr dankbar wenn du mich daran partizipieren ließest.

Gruß Hagen

Hi Hagen,

habe heute mittag deine Soft runtergeladen, a bissel gelesen (bin 
lesefaul)
parameter geaender (auf 2te rs232 des 128 mit max232)
Bootloder programmiert und funktioniert !,

!!! VIELEN DANK FUER DIE TOLLE SOFT !!!!

vlg
Charly

@ Hagen Re
So. Habe mich jetzt mal angemeldet.
Kriegst noch ne PN.

Hi Louis,

du beziehst dich auf obigen Post mit der BootMsg: ?
Du benutzt die AVRootIntf.DLL und allozierst mit OpenAVRootloader(...) 
ein IAVRootloader Interface. Dieses Interface hat mehere Sub-Interfaces 
wie .CommandSet: ICommandSet oder eben .Device: IDevice. Über dieses 
.Device Member des AVRootloader Interfaces kommst du an die .Info: 
WideString ran. Nach dem also über .DoConnect() eine Verbindung 
aufgebaut ist, kann man auf diese Info = BootMsg zugreifen. Oder aber in 
deinem IApplication Interface die "Callback-.Methode" .Changed. Diese 
Methode .Changed wird immer dann aufgerufen wenn sich zb. im 
Verbindungsstatus verändert hat.

1

var

2

  Loader: IAVRootloader;

3

begin

4

  Loader := OpenAVRootloader(Self, ...);

5

  if Loader.DoConnect() then

6

  try

7

    ShowMessage(Loader.Device.Info); // BootMsg anzeigen  

8

  finally

9

    Loader.DoDisconnect();

10

  end;

11

end;

Alle Daten in .Device stehen auch nach einen .Disconnect() weiter zur 
Verfügung. Erst beim nächsten .DoConnect() werden diese Daten 
aktualisiert. Du kannst also ohne Probleme auf .Info zugreifen um damit 
deine AVRs noch mehr zu serialisieren usw. Du hast über .Device Zugriff 
auf alle Daten die auch meine PC-Software anzeigen kann.

Gruß Hagen

1

  // connected Device Information, part of IAVRootloader

2

  IDevice = interface

3

    ['{9EC8A92B-F6BB-47F3-A9C9-DF8F4F481F49}']

4

    function Signature: Integer; stdcall;

5

    function Name: WideString; stdcall;

6

    function Info: WideString; stdcall;

7

    function FlashSize: Integer; stdcall;

8

    function AppFlashSize: Integer; stdcall;

9

    function EepromSize: Integer; stdcall;

10

    function RamSize: Integer; stdcall;

11

    function RamStartAddress: Integer; stdcall;

12

    function PageSize: Integer; stdcall;

13

    function BufferSize: Integer; stdcall;

14

    function Version: Integer; stdcall;

15

    function UseBootSection: Bool; stdcall;

16

    function RetCode: Byte; stdcall;

17

    function Support: Integer; stdcall;

18

    function XMLFileName: WideString; stdcall;

19

  end;

Aber beachte dabei das mit der Nutzung von BootMsg: keine XTEA 
Verschlüsselung mehr nutzbar ist. Man könnte aber mit wenigen Änderungen 
im Source BootMsg auch mit Verschlüsselung benutzen. Das habe ich aber 
nicht weiter ausgebaut da der Trick mit BootMsg: quasi nur ein 
Abfallprodukt war. Warum mit BootMsg: die Verschl. nicht mehr richtig 
funktioniert habe ich in einem der verherigen Postings erklärt.

Gruß Hagen

Hallo hagen,

kann man den bootloader auch in externen anwendungen verwenden???

Habe ein VB 2008 Programm indem würde ich gerne eine update funktion 
einbauen und dann die firmware flashen.

Kannst mir bitte mal n code exampel schicken oder so???

danke

Uff ich denke VB2008 sollte DLLs laden können und mit statischen 
Interfaces umgehen können. Ich habe nur ein Beispiel für Delphi 
beigepackt und mit VB2008 kenne ich mich im Grunde nicht aus. Meine Zeit 
als ich mit Basic zu tun hatte war ja vor 20 Jahren, oder länger.

Du müsstest dann nur noch die Interfaces in AVRootIntf.pas nach VB 
portieren. Ich habe dabei sehr darauf geachtet möglichst mit den 
Standard Datentypen zu hantieren und alles stdcall deklariert wie es bei 
COM/DCOM/ActiveX Controls nach MS Standard üblich ist.

Allerdings sind es eben statisch importierbare Interfaces und keine von 
IDispatch ableiteten Interfaces wie bei leicht zu importierenden 
COM/ActiveX Controls. Dazu hätte ich eine TypeLib bauen müssen und das 
war mir einfach zuviel Overhead.

Ich meine du solltest es einfach mal probieren und wenn du möchtest 
können wir bei EMail dann gemeinsam über deine Sourcen schauen. Also 
verstehen würde ich ein VB Script schon nur dir jetzt ein 
funktionierendes Beispiel liefern nicht. Dazu müsste ich mich erst 
einarbeiten und das kostet zuviel Zeit.

Aber gehen solltes es wenn VB2008 DLLs importieren kann und Interfaces 
unterstützt, was ich denke auch so ist.

Gruß Hagen

Du musst bei allem Megas die BOOTSZ Fuses entsprechend setzen. Wenn du 
mit AVRStudio das ASM kompilierst dann wird im Message-Window auch 
angezeigt welche BOOTSZ Fuses du setzen musst. Das hängt ja von der 
Größe des compilierten Bootloaders ab. Zusätzlich kannst du dann noch 
die Lock-Fuses setzen um den Mega dicht zu machen.

Leider kann ich dir aber nicht exakt sagern welche Einstellungen du bei 
deinem Programmer treffen musst.

Machst du diese Einstellung nicht, so kannst du einmal die 
AVRootloader.HEX programmieren und dann darüber nur einmal ein eigenes 
Progranm über den Bootloader laden. Danach springt der AVR immer sofort 
das eigen Program an und nicht zuerst den Bootloader.

Gruß Hagen

@Gerry:

>Es wäre schön wenn man zum Beispiel die Com Port Geschichte auch umgehen
>kann um direkt über USB zu Flaschen (Stichwort: FTDI o. LPC...).

Garnicht nötig, wird schon unterstützt ;)

Konzeptionell sind in AVRRootloader.DLL drei Interface implementiert.

1.) IAVRRootloader
dieses Interface wurde durch mich entwickelt und setzt die abstrakte 
highlevel Schnittstelle der Bootloader Funktionen um. Es enthält also 
das Kommunikationsprotokoll des Bootlaoders usw.

2.) ICOM
dieses Interface erledigt die serielle Kommunikation. Es ist die 
Verbindungsschnittstelle zwischen IAVRRootloader und dem seriellen 
COM-Port.
Auch dieses Interface habe ich komplett durchimplementiert.

3.) IApplication
Diese abstrakte Schnittstelle muß der Programmierer der die beiden 
vorherigen Schnittstellen anwenden möchte implementieren. Es übernimt 
die Aufgabe der Abfrage alle Parameter.
Einer der Parameter die das IAVRootloader Interface vom IApplication 
Interface abfragt ist das Kommunikations-Interface, also die ICOM 
Implementierung.

Wenn man nun per USB kommunizieren möchte so braucht man nur ein eigenes 
ICOM Interface zu bauen das nicht auf dem COM Port aufsetzt sondern auch 
USB.
Das eigene IApplication Interface wird in der Methode

function OpenCommunication: ICOM; stdcall;

also ein eigenes ICOM Objekt zurückgeben das dann auf die USB 
Schnittstelle aufsetzt. Normalerweise wird jetzt die Funktion OpenCOM(), 
importiert aus der DLL, aufrufen, und damit meine standardmäßige 
Implementierung auf dem seriellen COM Port.

Du musst also in deinem IApplication Interface (Callbacks) nur die 
OpenCommunication() abändern und dort eine eigene Implementierung eines 
ICOM Interfaces das auf USB aufsetzt.

Gruß Hagen

@Gerry:

soweit erstmal so gut. Man muß aber nun noch überprüfen ob das 
eigentliche Kommunikationsprotokoll des Bootloaders für USB auch 
konzeptionell tauglich ist. Im zb. ICOM Interface sind zb. die Timeouts 
der Kommunikation einstellbar. Davon macht das IAVRootloader Interfcae 
intern regen Gebrauch, da nur so sicherzustellen war das alle performant 
und denoch stabil läuft.
Auch die einzelnen Protokollschritte des Bootloaders sind auf ein 
serielles Protokoll, wie die RS232, aufsetzend. Ich denke aber das es 
relativ einfach sein müsste auch auf USB aufsetzen zu können, Hauptsache 
es ist ein serielles USB Protokoll, und das ist imer der Fall.

Denoch muß die überprüft werden und das geht im Grunde nur wenn man 
erstens Ahanung vom USB hat und zweitens es praktisch auch versucht.

Gruß Hagen

Ja der AVR Teil ist in Assembler, das ist eine zwingende Voraussetzung 
wenn man sowas effizient haben möchte, bzw. das letzte Quentchen an 
Optimierung haben möchte.

Die obige Vorgehensweise macht dann Sinn wenn man zb. per USB direkt 
einen USB-Serial-Wandler ansprechen möchte. Auf AVR Seite hat man ja 
sowieso alles auf RS232. Möchte man dies aber abändern dann muß man 
natürlich auch den Assembler Source des Bootloaders anpassen. Das werde 
ich aber mit Sicherheit nicht machen wollen ;)

Allerdings dürfte auch das garnicht mal so schwierig zu ändern sein, es 
gibt defakto nur 3 Stellen im Source die angepasst werden müssten.
1.) Baudrate-Detektion gleich am Anfang im Source
2.) die Sub-Funktion getc() um ein Zeichen vom der RS232 zu lesen
3.) und putc() um ein Zeichen in die RS232 zu schreiben

Man könnte durch die Änderung der letzten beiden Punkte zb. auch die 
HW-UART der AVRs benutzen, oder eben auf USB Hardware zugreifen, falls 
sie im AVR vorhanden ist.

Gruß Hagen

>Kein Problem, werd wohl Ende der Woche meinen BL fertig haben.
>Schade so erfindet man das Rad jedesmal neu.

Naja, es hängt halt von den Prioritäten ab die man sich setzt. Man hat 
dann zwar zwei Räder aber für jeweils unterschiedliche Konzepte. Eine 
wichtige Priorität in meinem Bootloader war es eben ihn sehr kompakt zu 
bekommen und das geht mit zb. C eben längst nicht so kompakt wie in 
Assembler. Ich habe bewusst den Punkt der Portierbarkeit, der Lesbarkeit 
für viele Anwender, zurückgestellt. Das ist eben dann der Nachteil den 
ich in Kauf nehmen musste. Ansich kein Nachteil für mich und dem Wunsch 
im Hobby einen eigenen Bootloader zu haben. Aber eben für diejenigen 
Nutzer denen ich im Nachinein frei den Bootloader zur Verfügung gestellt 
habe und kein Assembler verstehen.

Gruß Hagen

Jo ich ;)

Wie hast du die ACY Datei erzeugt ? Normalerweise geht das so:
1.) AVR mit RS232 verbinden
2.) PC-Bootloader starten
2.1.) dort dein HEX als FLASH-File eintragen/Auswählen
2.2.) nun Compile Button drücken
2.3.) PC Software verbindet mit AVR und fragt somit alle Informationen 
ab
2.4.) nun wird aus der HEX Datei eine ACY Datei erzeugt
2.5.) PC Software trennt sich vom AVR

So ist sichergestellt das das ACY File auch zum Bootloader im AVR passt. 
Nur auf AVRs die den gleichen Bootloader installiert haben kann dieses 
ACY installiert werden.

Wichtig dabei ist das das Passwort das die PC Software benutzt, steht 
wenn man es möchte in AVRootloader.INI unter Password, identisch mit dem 
Passwort in AVRootloader.ASM ist und diese ASM erneut auch compiliert 
wurde.

Ich schätze das gerade letzeres bei dir nicht der Fall ist.
Also starte PC Software und drücke Button "Make Pasword". Danach erzeugt 
die Software per Zufall ein 16 Bytes Schlüssel. Dieser wird in die 
Zwischenablage kopiert, in die AVRootloader.INI gespeichert wenn du es 
wünscht und auch sofort in die AVRootloader.ASM Datei geschrieben. 
Danach mit AVRStudio diese AVRootloader.ASM erneut kompilieren und das 
daraus entstehende HEX File auf den AVR installieren.

Sollte das Passwort der ACY Datei nicht identisch zum Passwort im AVR 
sein, oder die verschlüsselten AVR-Device-Informationen im ACY File 
nicht identisch zum Bootloader im AVR sein, dann tritt dieser Fehler den 
du beschrieben hast auf.

Gruß Hagen

Wobei, mit dem ATMega162 hatten wir schon ganz andere Probleme, siehe 
par Postings weiter oben.

Ach und nochwas:

du hast die AVRootloader.ASM mit Verschlüsselung konfiguriert, also

UseCrypt=1
UseCryptFLASH=1
UseCryptEEPROM=1
UseSRAM=0

und ein neues Passwort erzeugt hast, per PC Software, und alles im 
AVRStudio neu kompiliert hast.

Flashe nun AVRootloader.HEX in den AVR und setze die Fuses. Dann 
startest du die PC Software und verbindest m it dem AVR -> Button 
"Connect". Nun wählst du als FLASH File deine HEX Datei aus und drückst 
den Button "Program". Die PC Software wird nun im Hintergrund erkennen 
das der AVR nur mit Verschlüsselung programmierbar ist und somit dein 
HEX File live im Hintergrund erstmal in eine im Speicher liegende ACY 
Datei compilieren und diese dann flashen. Wenn das bei dir geht dann 
hast du vorher mit falschen Passwörtern gearbeitet ;)

Gruß Hagen

Uff mal im Ernst, warum muß ich immer die Probleme Anderer lösen, geht 
nicht gegen Dich oder Andere. Ist eher ne Frage das ich ein bischen 
jammern möchte ;)

Also zeige mal den Anfang der Konfiguration der AVRootloader.ASM und 
dann alles an Daten am Ende, also ab BootInfo: dieser Datei.

Könte es sein das du eine BootMsg, wie obem im Thread beschrieben, 
benutzt ?

Achso, die Fuses sehen gut aus.

Gruß Hagen

>HAbe so gemacht und das hex ausgesucht, er hat nicht erkannt das es ein
>hex ist und wieder die gleiche FEhlermeldung gebracht.

Doch hat er erkannt sonst würde im Log nicht dieser Fehler auftauchen.

Poste auch mal bitte den kompletten Inhalt des Log-Memos.

Gruß Hagen

@Luis:

>Man kann ja einen Bootstring angeben, der z.B die Hardwareversion
>enthalten kann.
>Wenn ich jetzt mit der DLL eine neue Software in den Controller laden
>möchte, und der Bootstring nicht korrekt ist (z.B. falsches Gerät für
>die Software), kommt bei mir keine Fehlermeldung, sondern es passiert
>nichts.

Du könntest das aber jetzt schon ohne Änderungen an der Software machen. 
Dafür gibt es zwei Wege:

1.) ohne Verschlüsselung:
Du benutzt für dein Gerät eine eigene BootVersion. Also in 
AVRootloader.ASM die BootVersion verändern, auf größer 2. Nun startest 
du die PC-Software, wählst dort dein HEX+EEP File für das Gerät aus und 
kompilierst eine ACY-Datei. Wenn man eine ACY-Datei kompiliert dann 
verbindet die PC-Software erstmal mit dem Bootloader im AVR und fragt 
dort die BootInfo ab, also auch die BootVersion. Diese Daten stehen dann 
im ACY-File und diese wird verteilt. Später programmiert man den AVR mit 
dieser ACY-Datei und nur wenn die BootInfo im AVR identisch zu den Daten 
im ACY-File sind kann diese den AVR programmieren.

2.) mit Verschlüsselung:
Du erzeugst für dein Gerät eine neue AVRootloader.ASM Datei mit einem 
nur für diese Geräte gültigen Passwort, und Verschlüsselung ist 
eingestellt. Dazu in der PC-Software den Button "Make Password" drücken 
und das .ASM im AVRStudio erneut kompilieren.
Danach mit der PC-Software aus deinem HEX+EEP File eine ACY-Datei 
erzeugen. Auch in diesem Moment steht im ACY die Kopie der BootInfo aus 
dem AVR aber zusätzlich werden alle Daten mit dem Passwort 
verschlüsselt. Diese ACY Datei kann dann später nur auf den Geräten 
installiert werden die das gleiche Passwort benutzen. Zusätzlich können 
deine Kunden nun über die PC-Software und voreingestellte Parameter (zb. 
per Windows-Verknüpfung) in einem Rutsch diese verschl. ACY-Datei 
programmieren. Aber nur du kannst, weil du als Einziger das Passwort 
kennst, solche ACY-Dateien für deine Geräte erzeugen. ABER! beachte das 
du in diesem Fall keine BootMsg: benutzen darfst, sonst geht das mit der 
Verschl. nicht.

Gruß Hagen

Danke Ali, dein Vorsatz ist schon eine Belohnung und ein netter 
Geburtstagsgruß für mich ;)

Hallo Hagen,

hab heute Deinen Bootloader mal ausprobiert und habe keine Problem damit 
gehabt. Compiliert, gelinkt, geflasht und dann gebootloaded ... Einfach 
klasse!

Vielen vielen Dank für Deine Arbeit!

Beste Grüße,
Michael

Hallo Hagen,

ich versuche deine AVRootloader.dll mit einem VB Express Programm 
anzusprechen.
Die DLL kann ich wie folgt einbinden.

1

 Public Declare Function OpenAVRootloader Lib "AVRootLoader.dll" Alias "OpenAVRootloader" () As String

Das Programm meldet mir aber sobald ich die Funktion verwende einen 
Fehler.
Ich weiß nicht genau was oder ob die Funktion von dir was zurück gibt. 
und was ich ihr übergeben muss.

Hast du vielleicht eine Schnittstellenbeschreibung zu der DLL?

Ich glaube das würde auch anderen helfen, die versuchen mit VB, C/C++ 
oder C# usw. die DLL anzusprechen.

Ich kann leider überhaupt kein Delphi.

Vielleicht kannst du auch kurz erläutern wie die prinzipielle 
Vorgehensweise bei der Initialisierung der Verbindung ist.

MfG Andy :)

PS: Der Bootloader ist echt klasse. Auch die Anleitung wie man ihn 
benutzt und einrichtet.

So wie du das versucht hast kann das nicht funktionieren.

Diese Funktion erwartet ein Interface und gibt auch ein Interface 
zurück. Das sind ähnliche "Datenstrukturen" wie Objekte, genauer gesagt 
sind es Schnittstellen von Objekten. Dafür gibt es einen Standard von MS 
damit eben verschiedene Programmiersprachen über diesen Weg kompatibel 
sein können.

Leider kenne ich mich in diesem Fall nur mit Delphi/PASCAL sehr gut aus, 
vielleicht noch ein bischen C. Aber wie es heutzutage in VB, ergo BASIC 
geht weiß ich leider auch nicht.

Ein erfahrener Programmierer in VB und Delphi sollte in der Lage sein an 
Hand der AVRootIntf.pas Source diese zu portieren.

Die einzigen beiden normal exportierten Funktionen in der DLL sind also 
Funktionen die solche Interface-Objekte erzeugen und zurückgeben. Die 
eigentliche Schnittstelle steckt dann als Methoden in diesen Interfaces. 
Deren Deklaration, also Namen, Typen, Parameter, Rückgabewerte und 
Aufrufkonventionen (stdcall, cdecl usw.) kann man in der AVRootIntf.pas 
Source nachlesen. Dieser Source ist damit auch die Dokumentation der 
DLL.

Gruß Hagen

Ok danke.

Ich hab in der VB Hilfe auch schon was zu diesen Interface Typen 
gefunden.
Ich werds einfach weiter versuchen.

Wenn ich was zustande bekomme werde ich berichten.

Grüße

Melde dich per PN bei mir, einfach auf den blauen Namen klicken bei 
meinen Postings.

Ein bischen kenne ich mich ja schon mit VB aus und somit könnte ich dir 
helfen bei der Translation nach VB. Ich habe es halt nicht installiert 
und normalerweise rücke ich auch nur Sourcen raus die ich auf 
Korrektheit verifiziert habe. Per EMail könnten wir quasi gemeinsam am 
Problem arbeiten, bis es läuft. So hätte auch ich einen Vorteil dabei.

Gruß Hagen

Je geringer die Baudrate desto höher sollte der Wert in Base sein. Dies 
ist das Basistimeout zum Warten auf 1 ASCII Zeichen beim Empfang über 
die Schnittstelle. Intern werden die Timeouts aus der Baudrate 
errechnet, allerdings ohne die Berücksichtigung der eventl. zusätzlichen 
Timeouts die durch den USB und dessen Treiber entstehen. Deren 
Berechnungsmethoden sind nicht öffentlich und höchstwarscheinlich von 
Hersteller zu Hersteller auch noch unterschiedlich.

Letzendlich wird man über die Parameter in der INI einen Kompromiß für 
die eigene Hardware/Treiber Kombination finden müssen der einerseits die 
Gesamtperformance des Bootloaders nicht so sehr negativ beeinflusst und 
andererseits die Stabilität des Bootloaders (Anzahl Timoutfehler) 
negativ beeinträchtigt. Ich bevorzuge natürlich die Stabilität und 
Zuverlässigkeit statt die um par Bruchteile einer Sekunde schnellere 
Programmierzeiten.

>Fehlermeldung "Cmd.ReadEeprom.ReadByte(1) ICOM: read error" bzw.
>"Cmd.ReadRam.ReadByte(1) ICOM: read error".

Exakt diese Fehlermeldungen beeinflußt man über den Wert Base in der INI 
Datei. Sie entstehen weil die PC-Software voeher ein Kommando an den AVR 
gesendet hat und nun auf eine Antoert vom AVR warten muß. Minimal wartet 
die PC-Software den Wert in Base in Millisekunden oder die Zeitspanne 
die sich aus der Baudrate und der Übertragung von 1 ASCII Zeichen 
ergäbe.

Gruß Hagen

1.) du baust dir ein neues Object, abgeleitet von TInterfacedObject mit 
der Schnittstelle ICOM, inetwa so

1

  TCOM = class(TInterfacedObject, ICOM)

2

  private

3

    FApplication: IApplication;

4

    FHandle: THandle;

5

    FDCB: TDCB;

6

    FTimeouts: TCommTimeouts;

7

    FDCBSet: Boolean;

8

    FTimeoutsSet: Boolean;

9

    FTimeout: Cardinal;

10

    FEcho: Bool;

11

    FWCRC: TCRCDef;

12

    FRCRC: TCRCDef;

13

    FOverlapped: TOverlapped;

14

  public

15