Anbei mein AVRootloader.

- unterstützt alle selbstprogramierbaren 8Bit-AVRs
- 1-Wire und 2-Wire RS232 Modus, invertierbar
- Baudraten je nach XTAL von 600 bis zu 256000 Baud per USB-RS232
- XTEA Verschlüsselung für FLASH/EEPROM Schreiben
- 16Bit CRC für die komplette Datenübertragung, Senden & Empfangen
- FLASH schreiben/löschen mit implizitem Verify
- separates FLASH Verify
- EEPROM schreiben/lesen, schreiben mit implizitem Verify
- SRAM schreiben/lesen
- Baudrate Detektion, Baudrate kann aber auch fest eingestellt werden
- WatchDog Unterstützung
- fertige PC-Software mit HEX-Editoren für EEPROM & SRAM/Registerfile/IO 
Ports
- ATmega128 bei 115200 Baud in 16 sec mit Verschlüsselung 22 Sekunden
- im ZIP Datei AVRootloader.txt enthält Anleitung
- je nach Konfiguration zwischen 344 bis 906 Bytes Codegröße, letzters 
mit XTEA Entschlüsselungsfunktion

Gruß Hagen

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

// Pinchange ISR für PB6, bei LowLevel springen wir den Bootloader an
__attribute__ ((naked)) ISR(PCINT_vect) {

    if (PINB & (1 << PB6)) {
        asm volatile("reti");
    } else {
        asm volatile("rjmp  __vectors");
    }
}

int main(void) {

    MCUSR  = 0;
    WDTCR  = (1 << WDE) | (1 << WDCE);
    WDTCR  = 0;
// RX Pin auf Eingang mit Pullup
    DDRB  = 0;
    PORTB = (1 << PB6)
// PinChange on PB6, Bootloader Pin
    GIMSK  = (1 << PCIE1);
    PCMSK1 = (1 << PCINT14);
    sei();

.. blabla
    while (1) {
    }
}

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.

// Pinchange ISR für PB6, bei LowLevel springen wir den Bootloader an
__attribute__ ((naked)) ISR(PCINT_vect) {

    if (PINB & (1 << PB6)) {
        asm volatile("reti");
    } else {
        WDTCR = (1 << WDCE);
        WDTCR = (1 << WDE);
        for (;;) ;
    }
}

int main(void) {

    MCUSR  = 0;
    WDTCR  = (1 << WDE) | (1 << WDCE);
    WDTCR  = 0;
// RX Pin auf Eingang mit Pullup
    DDRB  = 0;
    PORTB = (1 << PB6)
// PinChange on PB6, Bootloader Pin
    GIMSK  = (1 << PCIE1);
    PCMSK1 = (1 << PCINT14);
    sei();

.. blabla
    while (1) {
    }
}

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:

uses AVRootIntf;

type
  TMyObj = class(IApplication)
    procedure ProcessMessages; stdcall;
    procedure Changed; stdcall;
    procedure Output(const Msg: WideString; Code: Integer); stdcall;

    function GetFLASHFileName: WideString; stdcall;
    function GetEEPROMFileName: WideString; stdcall;
    function GetACYFileName: WideString; stdcall;
    function GetPassword: WideString; stdcall;
    function GetBootSign: WideString; stdcall;
    function GetTimeouts: TTimeouts; stdcall;

    function OpenCommunication: ICOM; stdcall;
 
    constructor Create;   
  end;

procedure TMyObj.ProcessMessages;
begin
end;

procedure TMyObj.Changed; 
begin
end;

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

function TMyObj.GetFLASHFileName: WideString; 
begin
  Result := ExtractFilePath(ParamStr(0)) + 'test.acy';
end;

function TMyObj.GetEEPROMFileName: WideString; 
begin
  Result := '';
end;

function TMyObj.GetACYFileName: WideString; 
begin
  Result := '';
end;

function TMyObj.GetPassword: WideString; 
begin
  Result := '';
end;

function TMyObj.GetBootSign: WideString; 
begin
  Result := 'BOOT';
end;

function TMyObj.GetTimeouts: TTimeouts; 
begin
  Result.Base := 50;
  Result.Erase := 20;
  Result.Flash := 25;
  Result.Eeprom := 20;
  Result.Buffer := 1;
  Result.RTSPulse := 0;
  Result.RTSInterval := 0;
end;

function TMyObj.OpenCommunication: ICOM; 
begin
  Result := OpenCOM('\\.\COM2', Self);
  Result.SetParams(115200);
end;
 
constructor TMyObj.Create;
begin
  OpenAVRootloader(Self).DoProgram(False, False);
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.

var
  Loader: IAVRootloader;
begin
  Loader := OpenAVRootloader(Self, ...);
  if Loader.DoConnect() then
  try
    ShowMessage(Loader.Device.Info); // BootMsg anzeigen  
  finally
    Loader.DoDisconnect();
  end;
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

  // connected Device Information, part of IAVRootloader
  IDevice = interface
    ['{9EC8A92B-F6BB-47F3-A9C9-DF8F4F481F49}']
    function Signature: Integer; stdcall;
    function Name: WideString; stdcall;
    function Info: WideString; stdcall;
    function FlashSize: Integer; stdcall;
    function AppFlashSize: Integer; stdcall;
    function EepromSize: Integer; stdcall;
    function RamSize: Integer; stdcall;
    function RamStartAddress: Integer; stdcall;
    function PageSize: Integer; stdcall;
    function BufferSize: Integer; stdcall;
    function Version: Integer; stdcall;
    function UseBootSection: Bool; stdcall;
    function RetCode: Byte; stdcall;
    function Support: Integer; stdcall;
    function XMLFileName: WideString; stdcall;
  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

Hallo Hagen,

können wir Deine AVRootIntf.DLL etwas ausbauen ?

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

Aktuell wollte ich nämlich gerade einen Intel HEX Loader nachbauen hab 
aber Deinen Thread gesehen und glaube das ich mir das sparen könnte.

Und ich hab gesehen wir nutzen beide Pascal könnte Dich also 
unterstützen.

Gruß Gerry

@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

Hallo Hagen,

hab gerade gesehen das der Bootloader in ASM ist.

Tja und ASM ist für mich nur kryptisch. Da ja die Komunikation nicht 
über uart läuft müste also der Bootloader umgeschrieben werden und das 
kann ich definitiv nicht in ASM.

Gerry

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

Hagen Re wrote:

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

 Nun bei mir läuft nichts über Uart :) Alles schön Parallel

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

  Ja, ABER in ASM ;)

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

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

 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

  TCOM = class(TInterfacedObject, ICOM)
  private
    FApplication: IApplication;
    FHandle: THandle;
    FDCB: TDCB;
    FTimeouts: TCommTimeouts;
    FDCBSet: Boolean;
    FTimeoutsSet: Boolean;
    FTimeout: Cardinal;
    FEcho: Bool;
    FWCRC: TCRCDef;
    FRCRC: TCRCDef;
    FOverlapped: TOverlapped;
  public
    constructor Create(const APort: WideString; const AApplication: IApplication);
    destructor Destroy; override;

    procedure SetTimeout(Value: Cardinal; const ProcName: WideString = ''); stdcall;
    procedure SetParams(Baudrate: Cardinal; Parity: Byte = NOPARITY; Databits: Byte = 8; Stopbits: Byte = ONESTOPBIT; const ProcName: WideString = ''); stdcall;
    procedure SetEchoMode(Value: Bool); stdcall;
    function  EchoMode: Bool; stdcall;

    procedure Flush; stdcall;
    procedure Purge; stdcall;

    procedure SetDTR(Value: Bool); stdcall;
    procedure SetRTS(Value: Bool); stdcall;

    procedure InternalWriteData(Buffer: Pointer; Size: Integer; Flags: TCRCFlags = []; const ProcName: WideString = '');
    procedure WriteData(Buffer: Pointer; Size: Integer; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
    procedure WriteByte(Value: Byte; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
    procedure WriteChar(Value: Char; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
    procedure WriteWord(Value: Word; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
    procedure WriteLong(Value: Cardinal; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
    procedure WriteCRC(const ProcName: WideString = ''); stdcall;
    procedure ResetCRC; stdcall;

    procedure ReadData(Buffer: Pointer; Size: Integer; Flags: TCRCFlags = []; const ProcName: WideString = ''); stdcall;
    function  ReadByte(Flags: TCRCFlags = []; const ProcName: WideString = ''): Byte; stdcall;
    function  ReadChar(Flags: TCRCFlags = []; const ProcName: WideString = ''): Char; stdcall;
    function  ReadWord(Flags: TCRCFlags = []; const ProcName: WideString = ''): Word; stdcall;
    function  ReadLong(Flags: TCRCFlags = []; const ProcName: WideString = ''): Cardinal; stdcall;
    function  ReadCRC(const ProcName: WideString = ''): Bool; stdcall;
  end;

Natürlich implementierst du alle Methoden durch.

2.) du stellst ja eine IApplication Schnittstelle zur Verfügung, als 
ebenfalls ein Object wie zb. ein TForm das die IApplication 
implementiert. Deren Methode function OpenCommunication: ICOM; stdcall; 
sähe dann so aus:

function TForm1.OpenCommunication: ICOM;
begin
  Result := TCOM.Create('COM1', Self);
end;

Obiges TCOM Objekt ist ein Copy aus meinen internen Sourcen zum Zugriff 
auf die RS232.

3.) falls du Fragen bzgl. den Methoden, Parameter und Arbeitsweise der 
ICOM Methoden hast, dann frag.

Gruß Hagen

Hi Stefan,

als erstes vorweg: möchtest du mit geringsten Aufwand arbeiten dann 
benutze den Virtuellen COM Port Treiber den der FTDI liefert. Dann musst 
du diesen nur im System installieren und kannst sofort mit dem 
bestehenden AVRootloader damit arbeiten, also ohne irgendwelche 
Programmierung.
Die Frage ist eben was für Vorteile du dir durch die direkte Ansteuerung 
des FTDIs auf Windows Seite erhoffst. Schneller als der viruelle COM 
über RS232 wirds wohl nicht gehen (denke ich zumindest) und der Aufwand 
den virtuellen COM Port Treiber im System zu instalieren (ohne brauchst 
du ja nur die FTDI-DLL) ist auch nicht so enorm.

Die Schnittstellen des AVRootloaders bestehen aus vier Interfaces:

IApplication, muß durch den Benutzer (also dir) implementiert werden. 
Par Postings weiter oben findest du einen Delphi Source der das 
demonstiert.

ICOM, das ist die native Schnittstelle zum eigentlichen 
Kommunikationstreiber unter WIndows. Für den Zugriff auf RS232 = COM 
Schnittstellen habe ich schon alles implementiert. Für den direkten 
Zugriff auf zb. deine FTDI-DLL musst du diese ICOM Schnittstelle durch 
ein eigenes Objekt implementieren. Eine beispielhafte Deklaration eines 
solchen Objektes habe ich im vorherigen Post schon aufgezeigt (meine 
Implementierung für die RS232).

IAVRootloader, ist der eigentliche Bootloader Code. Dieser greift auf 
das übergebene IApplication Interface zu um zb. Parameter, Einstellungen 
und Ausgaben im eigenen GUI zu machen. Desweiteren fragt er das 
Kommunikations-Interface = ICOM Objekt bei IApplication ab und benutzt 
dieses um mit der eigentlichen Kommunikationshardware zu reden.

IDevice, ist ein Sub-Interface von IAVRootloader und nur eine 
Strukturierung der vielen Methoden des Bootloader Interfaces. IDevice 
stellt quasi gruppiert alle Informationen zum verbundenen AVR dar.

Schau dir also mal meine Beispiel-Anwednung par Postings weiter oben an. 
Dann beginnst du deine eigenes ICOM Objekt zu bauen und gibts es statt 
dem Aufruf OpenCOM() als Resultat in deiner IApplication Schnittstelle 
bei der Methode .OpenCommunication() zurück.

Gruß Hagen

> ist das so richtig ?

Ja.

> Was bedeutet 'const ProcName: WideString ' ?
> bzw was muß ich hier übergeben ?

Musst du nicht benutzen, ist nur für eine gezieltere Fehlerbehandlung 
nötig.

Zb. hat die ICOM Schnittstelle die Methode:

ReadByte(CRCFlags, ProcName);

und wird in verschiedenen higher-Level Funktionen des IAVRootloader 
Interfaces benutzt. Zb. so

      FCOM.Purge;
      FCOM.SetTimeout(FTimeout.Base, 'Cmd.ReadEeprom.SetTimeout(1) ');
      FCOM.WriteWord($0400 + Bytes mod 256, [crcReset, crcSend], 'Cmd.ReadEeprom.WriteWord() ');
      CRCOk := False;
      Buf[0] := FCOM.ReadByte([crcReset], 'Cmd.ReadEeprom.ReadByte(1) ');
      try
        if Bytes > 1 then
        begin
          Buf[1] := FCOM.ReadByte([], 'Cmd.ReadEeprom.ReadByte(2) ');
          if Bytes > 2 then
          begin
            FCOM.SetTimeout(Bytes * FTimeout.Base, 'Cmd.ReadEeprom.SetTimeout(2) ');
            FCOM.ReadData(@Buf[2], Bytes -2, [], 'Cmd.ReadEeprom.ReadData() ');
            FCOM.SetTimeout(FTimeout.Base, 'Cmd.ReadEeprom.SetTimeout(3) ');
          end;
        end;
        CRCOk := FCOM.ReadCRC('Cmd.ReadEeprom.ReadCRC() ');
        Res := FCOM.ReadByte([], 'Cmd.ReadEeprom.ReadByte(3) ');
      except
        on E: ECOMReadError do Res := Buf[0]
          else raise;
      end;

Falls also TCOM.ReadByte() einen Fehler meldet, Timeout oder so wird 
.ReadByte() eine Exception auslösen und in dieser wird der Wert in 
ProcName  als Message mit eingebaut. Sowas geht mit anderen Sprachen wie 
.NET und C# schon automatisch, allerdings erzeugen die auch einen 
trace-baren Aufrufstack und mit Delphi erzeugt man optimierten Nativcode 
der durch die Registeroptimierung der Parameter oft ohne Stack auskommt. 
Ergo denke ich pragmatisch und baue so einen Paramater ein, im Hobby 
kann man ja so vorgehen.

> Außerdem bekomme ich bei FWCRC: TCRCDef; FRCRC: TCRCDef;
> eine Fehlermeldung über nicht definierte Variablen !

Ähm, du hast ja nicht meinen vollständigen Source und damit auch nicht 
meine Unit CRC.pas.

Das Beste wird es sein du schickst mir einen PN oder lädst dir von hier 
http://www.michael-puff.de/Developer/Delphi/Import... mein 
Delphi Encryption Compendium. In diesem enthalten ist meine CRC.pas 
Unit, kannste sowieso immer gebrauchen da sie alle Cyclic Redundance 
Checksum unterstützt.

Gruß Hagen

Nochwas, wir betrachten mal

FCOM.WriteWord($0500 + Pages, [crcReset, crcSend], '');

Das sendet das Kommando zum EEPROM schreiben. Die CRCFlags bedeuten nun 
folgendes:

1.) crcReset, setzt die FWCRC: TCRCDef Struktur zurück, also resetet die 
Schreib CRC auf $0000. Und das bevor die CRC über die Bytes $05 $00 
gesendet werden.

2.) nun wird das Byte $05 und ($00 + Pages) gesendet über COM und auch 
darüber die FWCRC updated.

3.) crcSwend bedeutet das WriteWord() als letztes die berechnete CRC 
über COM sendet

In Summasumarum werden also 4 Bytes gesendet

$05   = Kommando Write Eeprom
Pages = Anzahl zu schreibender Pages
CRC   = CRC16
CRC

Die zu programmierenden Daten wurden schon vor diesem Kommando in den 
SRAM Buffer im AVR geschrieben und ebenso die Anzahl der Bytes die in 
diesem Buffer gültig sind. Ebenso die Addresse an die diese Daten 
geschriben werden sollen.

Angenommen man hat vorher mit dem SetBuffer() Kommando also die 
Datenbytes $FF $FF $FF $FF gesendet und möchte nun aber mit dem 
WriteEeprom Kommando ($05) aber 512 Bytes im Eeprom schreiben dann würde 
man einfach das Kommando

$05 $80 crc crc

absetzen.

Die Sequenz um ab Addresse $012345 512 Bytes mit $FF im Eeprom zu 
befüllen sähe also so aus

1.) SetAddr()     -> $FF $01 $23 $45 crc crc
2.) SetBuffer()   -> $FE $00 $00 $04 crc crc $FF $FF $FF $FF crc crc
3.) WriteEeprom() -> $05 $80 crc crc

Jedesmal wenn die CRC gesendet wurde wird sie neu initialisiert.
SetAddr() benutzt 24 Bit lineare Addressen, egal ob SRAM/EEPROM/FLASH 
gelesen/geschrieben wird.

Das erste Byte ist immer das Kommando. Verschiedene Kommandos bestehen 
aus 2 oder 4 Bytes + 2 Bytes CRC danach. Also auch die Kommandos sind 
mit CRC separat abgesichert. Je nach Kommando werden danach entweder 
weitere Daten  gesenedet oder empfangen oder das Kommando ist schon 
fertig, arbeitet also ohne Daten. Falls Daten gesendet oder empfangen 
werden so sind diese ebenfalls mit der 16 Bit CRC abgesichert.

Tjo, soweit zum grundsätzlichen Aufbau der Kommando/Daten des 
Protokolles.

Übrigens alles ist Big-Endian !!

WriteWord($FF00) sendet also $FF $00
WriteLong($01020304) sendet $01 $02 $03 $04

Gruß Hagen

Es wird schnell ersichtlich das man mit der obigen Methode den 
Kommunikationsaufwand reduzieren kann. Ich hatte mal eine Testversion 
meiner PC-Bootloader-Software geschrieben die die zu programmierenden 
Daten für den FLASH und EEPROM nach sich wiederholenden Sequenzen 
analysierte und dann mit der obigen Methode quasi eine Komprimierung 
durchführte. Solange man viele solcher Sequenzen hat konnte man 25-50% 
an Kommunikation damit einsparen. Leider zeigte aber die Realität, also 
normale Programme für AVRs, das man dieses Ratio eben nicht erreichen 
kann. Also habe ich in der aktuellen Version der PC-Software darauf 
verzichtet und benutze diese Feature nur mein zb. Löschen des EEPROMs. 
Die ansosten einzige Optimierung in dieser Richtung ist beim Schreiben 
des FLASHs. Sollten dort komplette Pages im HEX auftauchen die alle mit 
$FF gefüllt sind so werden diese nur durch ein EraseFlash() Kommando 
programmiert. Auch dieses Kommando -> $02 Pages crc crc, kann mehrere 
Pages am Stück löschen.

Gruß Hagen

Hallo Hagen,

habe ein Problem mit dem AVRootloader,
ruft man das Prg. per Komandozeile auf funktioniert es nicht
wenn im Pfad ein Leerzeichen ist (oder bin ich zu dumm ? )
z.B. -Dc:\programme\avr tools\ -Ftest.hex ergibt
c:\programme\avr\test.hex

koenntest du das bitte pruefen & event. beheben ? vielen Dank !!!

vlg
Charly

@Charly:

Uff, das ist so ein Feature von Delphis RTL das ich schon seit langem 
hasse. Es kann solche Parameter nicht korrekt auswerten, Leerzeichen 
stellen einen Separator zwischen mehreren Parametern dar.

Das müsste ich definitiv im Source ändern, wird aber dann heissen das 
ich die Kommandozeile aufwendig von Hand parsen müsste, statt eben auf 
fertige Funktionen der RTL zurück zu greifen.

Vorerst musst du den Ordner umbenennen zb. in avr_tools, also mit 
Unterstrich statt Leerzeichen.

Mal sehen, es könnte demnächst sowieso eine Version 3.0 kommen.

Gruß Hagen

Mal ne kleine Umfrage meinerseits.

Was für Erweiterungen und Verbesserungen schweben euch noch vor ?

- Versionsverwaltung der geflashten Software
- Updates überprüfen diese Versionsnummer
- diese Versionsnummer wird nur bei Verschlüsselung überprüft, also 
durch den AVR selber mit verschlüsselten Daten. Manipulationen sind 
ausgeschlossen. Dieses Feature würde nur vorhanden sein bei aktvierter 
Verschlüsselung. Nur dort macht es auch kryptographisch einen Sinn, 
alles andere wäre nur informativ. Das bedeutet das im vorgefertigten und 
verschlüsselten ACY File die Versionsnummer der verschlüsselten HEX 
Datei gespeichert wird. Im ACY File steht das alles geschützt drinnen. 
Diese Daten werden beim Kunden zum AVR gesendet und dieser überprüft die 
aktuell installierte Version mit der gerade empfangen Versionsnummer. 
Nur wenn es eine neuere Version ist wird eine Programmierung des FLASHs 
zugelassen. Die Versionsnummer könnte in den letzten Zellen im 
Anwendungs-FLASH gespeichert werden, quasi so wie der Einsprungsvektor 
bei den kleinen AVRs. Es würden also zb. 4 Bytes vom Anwendungs-FLASH 
weniger zur Verfügung stehen.

- Bug beseitigen mit der BootMsg: im Zusammenhang mit der 
Verschlüsselung
- Bug beseitigen mit der Kommandozeile

- Autodetektion des COM Ports bzw. Serielle Schnittstellen
- separate Bootloader-EXE die nur vorgefertigte ACY Dateien 
programmieren kann, quasi die jetzige Bootloader Software in 
abgespeckter Version. Dafür enthält diese EXE, quasi wie ein 
selbstextrahierendes ZIP, schon die ACY Datei.
- Auswahlbox für das BootSign: in die PC-Software integrieren. Welchen 
Sinn hat das ? Nun, wenn man den Bootloader auf 1-Wire benutzt dann kann 
man jetzt schon mehrere AVRs am gleichen 1-Wire-Bus auf einer Platine 
verdrahten. Werden diese mit dem Bootloader programmiert, benutzen aber 
alle eine andere BootSign: dann kann man mit der PC-Software über einen 
Draht alle AVRs programmieren. Man könnte also zb. 10 baugleiche AVRs 
auf einer Platine per 1-Wire-Bus verbinden. Alle benötigen im Grunde die 
gleiche Anwendungssoftware. Man muß also nur 10 Versionen von 
AVRootloader.ASM komplieren mit jeweils anderen BootSign: zB. BOOT00 bis 
BOOT09. Dann programmiert man diese 10 unterschiedlichen Bootloader in 
diese AVRs. Danach kann man sie alle über die PC-Software programmieren. 
Entweder indem man diese 10 BootSign in einer Auswahlbox von Hand 
auswählt und dann jeden AVR einzeln programmiert oder aber die 
PC-Software geht automatisch alle Einträge in dieser Auswahlbox durch 
und versucht alle mit der gleichen Software zu programmieren.

- bitte keinen Vorschlag wie "Terminal" integrieren ;)

Gruß Hagen

@Henry:


>"" ?
>-D"c:\programme\avr tools\"

Nee geht nicht, habs sicherheisthalber probiert. Um eine Änderung im 
Source, wie oben beschrieben käme ich also nicht rum. Nur kann ich dann 
ja gleich alles richtig machen, statt mit Tricks zu arbeiten. Ist halt 
schade das das es die Delphi RTL nicht gleich richtig macht.

Gruß Hagen

Die .Flush() Funktion sollte beide Buffer vollständig senden oder 
empfangen, nicht Purgen.

procedure TCOM.Flush;
begin
  if FHandle <> 0 then
    FlushFileBuffers(FHandle);
end;

versuche es mal mit einer Leermethode also ohne Implementierung.

> Außerdem ist keine Echo Funktionalität vorgesehen. Wird diese zwingend
> benötigt ?

Würde ich einbauen, da nicht sooo schwierig. Alle Methoden die mit 
.Read??? und .Write??? beginnen landen intern immer bei .ReadData() und 
.WriteData()

Also nur in diesen beiden Methoden findet die komplexere Komunikation, 
CRC Berechnung und auch der EchoMode statt.

Bei .EchoMode=TRUE musst du also in .WriteData() nur exakt die Bytes 
wieder sofort einlesen die du gesendet hast und verwerfen, überprüfen 
mit den gesendeten Bytes.

> ... ReadCrc,WriteCRC und ResetCRC.

Ganz einfach:

procedure TCOM.WriteCRC;
var
  CRC: Word;
begin
  CRC := CRCDone(FWCRC);
  InternalWriteData(@CRC, SizeOf(CRC)); // WriteData() ohne CRC berechnung
  CRCDone(FWCRC);
end;

procedure TCOM.ResetCRC;
begin
  CRCDone(FWCRC);
  CRCDone(FRCRC);
end;

function TCOM.ReadCRC(const ProcName: WideString): Bool;
begin
  ReadWord([], ProcName);
  Result := CRCDone(FRCRC) = 0;
end;

>..Autodetektion des COM Ports bzw. Serielle Schnittstellen
>Wie stellst du dir das vor ?

1.) alle COM Ports im System ermitteln, samt FriendlyName, also sowas

"COM4: Bluetooth serieller Kommunikationsanschluß"

2.) COM Port ComboBox wird umgebaut zu einer reinen DropDown Liste. Also 
keine manuelle Eingabe eines COM Ports merh möglich. Zusätzlich wird es 
in dieser Liste einen Eintrag wie "AUTO" geben. Ist dieser ausgewählt so 
versucht die Software bei einem Connect() alle in der Liste vorkommenden 
Ports anzusprechen und mit einem evntl. angeschlossen AVR zu 
kommunizieren. Das geht natürlich nur dann wenn der AVR aus der 
Anwendungssoftware in den Bootloader gesprungen ist. Dazu gibt es 
mehrere Möglichkeiten:

a) man überwacht per PinChange den Bootloader-RX/1-Wire-Pin und springt 
dann aus der PinChange-ISR direkt in den RESET Vektor zum Bootloader 
oder benutzt den WatchDog um einen RESET auszulösen. Oder man benutzt 
den RTS Pin der RS232, konfiguriert in der .INI Datei das Verhalten der 
RTS Leitung entsprechend und verbindet die RTS Leitung mit RESET am 
Board oder legt sie an einen extra Pin am AVR der wiederum mit 
PinChange-ISR überwacht wird.

Wichtig bei dieser Auto-Detektion des Ports ist es also das der AVR in 
den Bootloader springt auf Verlangen der PC-Software. Ansonsten muß man 
permanter den RESET-Taster.

Gruß Hagen

@JoJo:

Warum dann aber nicht auf den Wert in BootSign: in der Applikation 
reagieren ?

Die PC-Software sendet bei einem Connect() wiederholt den Wert

0x00,0x00,0x00,0x00, "BOOT"

bzw. das was in BootSign: drinnen steht, bis
a) der Bootloader reagert mit einer Rückmeldung
b) der Connect() Versuch in der PC-Software manuell beendet wird
c) eine gewisse Anzahl von Connect() Versuchen abgelaufen ist (* neue 
Version wird das so machen müssen wenn sie ein AUTO Connect() 
durchführt)

Desweiteren muß klar sein das die Baudrate stimmen muß. Die eigene 
Anwendung hängt also am UART und erwartet eine Kommunikation mit der 
richtigen Baudrate, ganz im Gegensatz mit dem Bootloader der eine 
Baudrate-Detektion besitzt.

Ich denke also das dein angedachtes Feature schon jetzt mit dem 
Bootloader geht, du musst nur richtig konfigurieren ;)

Der Connect() ist ein zeimlich Timining kritischer Prozess, sowohl im 
AVR wie auch auf PC Seite.

gruß Hagen

@Jojo,

Du möchtest also in der PC-Software das sie bei einem Connect folgendes 
macht

1.) einen konfigurierbaren String über RS232 senden
2.) eine kurze Zeit warten
3.) mit der bisherigen Vorgehensweise weitermacht

Hm, könnte ich so ändern wenn du dich bereit erklärst diese neue Version 
speziell auf dieses Feature hin zeitnah zu testen ;-)

Gruß Hagen

>Ob und wie man in diesen String Steuerzeichen (Escape-Sequenzen, CR, LF
>etc.) mit einbauen kann ist mir noch nicht ganz klar.

Kommt eh, auch für die BootSigns als ESCaped Sequence. Etwa so

Test/0a/0dString//

eräbe dann

test
<lf><cr>
String
/

> das in der "Ini"- Datei zu "verstecken"

nur so geplant.

Gruß hagen

@JoJo: hier zum Testen ;)

@Andere:

neuste Version 3.0, was hat sich geändert ?

- Versionsverwaltung für eure eigene Software in AVRootloader.ASM 
eingebaut. Die Versionsnummer ist 4 Bytes groß und wird in den letzten 4 
Bytes im Anwendungsflash gespeichert. Bei AVRs mit Bootsektion exakt die 
4 Bytes vor BootStart, also letzten 4 Bytes des nutzbaren FLASHs für 
eure Anwendung. Bei AVRs ohne Bootsektion steht in den letzten 2 Bytes 
der JMP zu Main. Deshalb steht die Version in den 4 Bytes davor. Ihr 
könnt also in eurer Software per LPM auf diese Versionsnummer zugreifen. 
Der Bootloader sendet diese Versionsnumer beim Connect zur PC-Software. 
Diese stellt die Versionsnummer im "Device Information" Fenster dar. In 
AVRootloader.ASM könnt ihr per UseVersioning=1 die Versionsverwaltung 
aktivieren. Wird die Verschlüsselung als Updatemöglichkeit benutzt kann 
bei einem Update eurer AVRs mit einem kompiliertem ACY File eine 
Versionsnummernprüfung erfolgen. Dabei vergleicht der Bootloader im AVR 
die im ACY verschlüsselt gespeicherte neue Versionsnummer mit der 
aktuell installierten Versionsnummer. Ist die neue kleiner als die alte 
wird ein Fehler zurückgemeldet und der AVR kann nicht programmiert 
werden. In der PC-Software sind 4 Eingabefelder in denen ihr eure 
Versionsnummer eingeben könnt die bei der Kompilation einer ACY Datei 
benutzt werden soll. Über die "Verify Mask" könnt ihr bestimmen welche 
Teile der Versionsnummer im AVR  überprüft werden sollen. Somit könnt 
ihr ein "Back-Update" des AVRs durchführen indem ihr einfach eine ACY 
Datei kompiliert und alle 4 Checkboxen abhackt. Diese Versionsverwaltung 
ist kryptographisch sicher, also nur ihr als Besitzer des Paßwortes 
bestimmt das Verhalten der Versionsverwaltung. Alle Daten sind 
verschlüsselt, sowohl in der erzeugten ACY Datei wie auch bei der 
Datenübertragung zum AVR. Nur der Bootloader im  AVR entschlüsselt und 
vergleicht diese Versionsnummern. Diese geschützte Versionsverwaltung 
funktioniert beim Schreiben des FLASHs wie auch EEPROMs. Dafür muß aber 
die zwingende Verschlüsselung des FLASHs und EEPROMs in AVRootloader.ASM 
aktiviert sein.

- Autodetektion der COM Ports auf dem PC. Dabei werden die installierten 
und verfügbaren COM Ports im System ermittelt und mit ihren FriendlyName 
angezeigt.

- Autodetektion des COM Ports an dem der Bootloader angeschlossen ist. 
In der COM Port Auswahlliste einfach "AUTO" auswählen. Diese könnt ihr 
auch in der Kommandozeile nutzen. Ist AUTO gewählt und es wird eine 
Verbindung aufgebaut dann versucht die PC-Software jeden COM Port in der 
Auswahlliste. Die Anzahl der Trials bei diesem Versuch pro COM Port kann 
in der AVRootloader.INI -> [System] -> ConnectTrials=? eingestellt 
werden. Damit dies aber funktioniert muß euer Gerät autom. in den 
Bootloader wechseln können. Es gibt mehrere Wege, zb. PinChange ISR am 
RX Pin des Bootloader, oder RTS-Leitung der RS232 am RESET des AVRs und 
RTSPulse/RTSInterval in AVRBootloader.ini entsprechend konfiguriert.

- Neu ist die Möglichkeit das die PC-Software bei der Verbindung einen 
definierbaren String sendet. Eure Anwendung im AVR, die selber die UART 
benutzt, kann diesen Befehl dann benutzen um in den Bootloader zu 
springen.  Dazu konfiguriert ihr in AVRootloader.INI -> [System] -> 
AppCmd= . Der Wert in AppCmd kann Sonderzeichen enthalten zb. so 
AppCmd=RunBoot/0ATest//
Ein Backslash mit anschließend einem HEXadecimalen Wert, immer zwei 
Zeichen lang. Ein Doppelslash hebt den ESCapecode auf.
VORSICHT! ihr könnt nicht das Zeichen #13 -> /0D benutzen, leider. Das 
liegt daran das die Baudrate Detection im Bootloader dieses 
Sonderzeichen auswertet. Wollt ihr es denoch benutzen so müsst ihr den 
Bootloader ohne "Baudrate Detection" konfigurieren, also mit fest 
eingestellter Baudrate (was meistens dann auch Sinn macht).

- Auswahlbox für das BootSign in PC-Software eingebaut. Man kann, wenn 
man 1-Wire Kommunikation benutzt, alle AVRs eines Gerätes am gleichen 
1-Wire-Pin verdrahten. Alle AVRs, können unterschiedliche Typen sein, 
benutzen den AVRootloader. Nun kann man mit der PC-Software all diese 
AVRs updaten.

- Fehler beim Auswerten der Kommandozeile beseitigt, Leerzeichen im Pfad 
wurde als Separator erkannt.

- Fehler bei der BootMsg beseitigt. Die BootMsg wurde in AVRotloader.asm 
verschoben und kann nun auch mit der Verschlüsselung benutzt werden.

- Der Wert im Eingabefeld "ACY Info" in der PC-Software wird beim 
Kompilieren einer ACY Datei in diese lesbar gespeichert. Neben diesem 
Wert auch die lesbare Versionsnummer. Mit einem einfachen Texteditor 
kann man diese Infos aus einer ACY Datei auslesen.

- Kompatibilität zum Bootloader Version 1 und 2 sollte gewährleistet 
sein.

- einige kleinere Darstellungsfehler beseitigt

- alle Dateien wie AVRootloader.dev und AVRootloader.ASM wurden auf die 
neusten AVRs aktualisiert (AVR Studio 4.15 Build 623)

- neuer Parameter -SBOOT für die Kommandozeile eingebaut, damit kann man 
das BootSign für den Bootloader-Connect vorgeben

- für diejenigen die die AVRootloader.DLL benutzen. Diese ist nicht 
kompatibel zur alten Version !

Testen konnte ich das Ganze zZ. nur auf einem ATmega162, also mit einem 
AVR mit Bootsektion. Es wäre lieb wenn einer, der zZ. mit einem ATTiny 
den Bootloader benutzt, die neuste Version testet. Speziell BootMsg, 
UseVersioning mit/ohne Verschlüsselung, danke.

Gruß Hagen

@JoJo:

> Anzeige der verfügbaren Schnittstellen: Com2 erscheint 4mal

Echt blödes Betriebssystem. Tja was kann ich tun, ich weiß es nicht !
Denn es scheint keine Methode zu geben die gerade im System aktiven 
Schnittstellen mit ihrem FriendlyName abfragen zu können. Ich habe nun 
mittlerweile 4 verschiebene Vorgehensweisen zur Ermittlung der aktiven 
COM Ports implementiert und getestet (alle aus dem WEB, zb. MSDN) Keine 
hat davon richtig funktioniert, also habe ich mir selber eine 
zusammengestrickt. Ich gehe nur über die Registry. Das Problem ist nun, 
ich kann zwar ermitteln welche COM Ports im System aktiv sind, aber ich 
kann deren eindeutigen FriendlyName nicht ermitteln. So wie bei dir, 
kann es vorkommen das über einen längeren Zeitraum verschiedene 
Installationen erfolgten. Oder das zb. ein USB-Seriell-Wandler an 
verschienden USB-Hubs angeschlossen wurde. Jedesmal kann dann der 
gleiche COM Port für ein anderes Gerät benutzt werden. Diese Infos 
stecken in der Registry und ich lese sie aus. Dummerweise weiß ich zwar 
das es einen aktiven COM2 im System gibt (auch aus der Regustry) kann 
aber die möglichen installierten Treiber/Geräte aber nur über den 
Portnamen zuordnen. Installierte Treiber können es aber eben mehrere zu 
einem Port sein, welcher davon aktiv ist kann man nicht aus der Registry 
auslesen, bzw. ich habe keinen Trick im WEB dafür gefunden.

Ich bin kurz davor alles wieder umzubauen auf mein altes GUI, dh. 
FriendlyName wieder aus der Anzeige raus zu nehmen. Denn was nützt es 
wenn man den COM2 zb. dreimal sieht, mit drei unterschiedlichen 
FriendlyNames, und damit dann doch wieder keinerlei sinnvolle 
Information mehr hat welches Gerät nun real angeschlossen ist.

> AppCmd wird jetzt immer vor Bootsign gesendet.

Ja, ich dachte mir das dies der beste Kompromiß ist. Denn es könnte ja 
sein das die Applikation selber nicht beim ersten Senden von AppCmd 
richtig reagiert. Für meinen Bootloader im AVR ist dieses AppCmd egal, 
solange AppCmd kein #13 enthält und nichts mit BootSign überreinstimt !!

Ich habe diese Änderung ja nur für dich, als bisher einzigen Nutzer, 
eingebaut.

Gruß Hagen

Ich habe den Friendlyname der COM Ports wieder rausgenommen.
Es gibt keine Methode die Liste der aktiven COM Ports (aus der Registry) 
mit der Liste der möglichen COM Ports + FriendlyName zu synchronisieren.
Auf meinen Rechnern ist die Registry und Installationen sauber, deshalb 
tratt dieses Problem so nicht auf.

Zusätzlich habe ich einen weiteren Parameter für die Kommandozeile 
eingebaut, Parameter -V. Dieser setzt die Daten für die 
Versionsverwaltung. Das könnte so aussehen

-V0102F01A0F

Daraus wird Version 1.2.240.26 und alle Verify Checkboxen angehackt. Der 
letzte 2 Zeichen HEXadezimal Wert im Parameter gibt die Bitkodierung 
dieser Checkboxen vor.

Gruß Hagen

@Stefan:

hier mein Code, geht einfach über die Registry.

procedure GetComPorts(Items: TStrings);

  function DoSort(List: TStringList; Index1, Index2: Integer): Integer; register;
  begin
    Result := Integer(List.Objects[Index1]) - Integer(List.Objects[Index2]);
  end;

var
  N,R: TStringList;
  S: String;
  I,J,M: Integer;
begin
  N := TStringList.Create;
  R := TStringList.Create;
  try
    with TRegistry.Create do
    try
      RootKey := HKEY_LOCAL_MACHINE;
      if OpenKeyReadOnly('\HARDWARE\DEVICEMAP\SERIALCOMM\') then
      begin
        GetValueNames(N);
        for I := 0 to N.Count -1 do
        begin
          S := AnsiUpperCase(ReadString(N[I]));
          if Pos('COM', S) = 1 then
          begin
            M := 0;
            for J := 4 to Length(S) do
            begin
              M := M * 10;
              if S[J] in ['0'..'9'] then
                M := M + Ord(S[J]) - Ord('0');
            end;
            R.AddObject(S, Pointer(M));
          end;
        end;
      end;
    finally
      Free;
    end;
    R.CustomSort(@DoSort);
    Items.Assign(R);
  finally
    N.Free;
    R.Free;
  end;
end;

Die Devicemap in der Registry zeigt alle zZ. aktiven COM Ports an.

Gruß Hagen

Hi Petr,

i know less about you special hardware setup, it is very uncommon to me. 
To get more information i need some error protocol output from my 
bootloader software. Normaly the connection process is always the same, 
even if cryptography is used. I do not see any point why it should 
differently work with and without cryptography. The only suggestion, or 
even my opinion, where that the XPORT LAN-protocol, to transfer the 
virtual COM port data, must be wrong or probable the timing is quit 
different. Try to increment the values in AVRootloader.ini in section 
[Timeouts], especialy value for Base. But iff you get no 
correspondending error messages, eg. timout errors in my bootloader 
software this suggestion would by pretty useless.

Best regards, Hagen

@Stefan,

danke dir, kannte ich aber schon und habe alle Methoden probiert. Der 
Weg übers SetupAPI funktioniert leider nicht richtig. Also das was es 
anzeigt ist zwar richtig (aktive Ports und FriendlyName) aber es zeigt 
nicht alle aktiven Ports im System an. Zb. mit Bluetooth und USB Wandler 
soll es ein Problem haben. Kann man irgendwo bei MSDN nachlesen.

Meine obige gepostete Methode funktioniert sehr gut, solange man keine 
Friendlynames benötigt. Und mit der letzten Version benötige ich sie 
auch nicht mehr, da dieses Feature raus ist.

Der Trick mit dem testweisen Öffenen des COM Ports ist absolut nicht das 
was ich möchte. Es kann durchaus sein das ein COM Ports durch eine 
andere Anwendung geöffnet ist und diesen Port möchte ich denoch in der 
Liste anzeigen.

Grundsätzlich sehe ich es im Hobby nicht ein den "Mist" den andere 
Entwickler verzapft haben ausbessern zu wollen. Dazu ist mir, und vielen 
anderen Benutzern des Bootloaders, dieses Feature einfach zu unwichtig. 
Wenn man sich mal den Aufwand, nur par COM Ports im System zu ermitteln, 
anschaut dann ist dieser nicht gerecht fertigt. Ein vorausschauender 
Systementwickler berücksichtig im Besonderen die Useablity dessen was er 
erschafft für die darauf aufsetzenden Entwickler. So entsteht ein gutes 
OS und kein MS-Windows. Es ist Aufgabe vom OS solche Daten sauber und 
möglichst einfach abfragbar zur Verfügung zu stellen. Wenn aber für 
diese Abfrage ein 250-Zeiler benötigt wird dann stimmt da was am Konzept 
und Umsetzung des OS nicht. Nun, und ich werde mich nicht hinsetzen, 
viel Zeit verschwenden, um diese Schwachstelle auszubügeln.

Ergo: AVRootloader zeigt keine Friendlynames an, fertig, Thema 
abgegessen ;)

Sorry musste aber mal Luft raus lassen.

Gruß Hagen

@James, lies mal hier Beitrag "Re: AVR-Bootloader mit Verschlüsselung"

@Stefan:

>Du hast geschrieben das die neue AVRootloader.dll nicht mehr zur alten
>kompatibel ist ! Betrifft das auch meine TCom Function oder hat das
>ausschließlich mit der Versionsabfrage zu tun ?

Ja und Nein ;) Einfach die AVRootIntf.pas bei dir neu einbinden als 
Header. Es betrifft das IApplication Interface (muß weitere Parameter 
zurückliefern) und den TTimeout Record, enthält ebenfalls neue Felder.

Allerdings, schäm mich :( habe ich schon wieder par kleinere 
Veränderungen am Bootloader gemacht. Diesen werde ich nach einer 
gewissen Wartezeit hier ebenfalls veröffentlichen. Es nutzt ja nichts 
das Forum wegen par unwichtigen Änderungen ständig voll zu müllen. Ich 
warte also noch ab ob irgendwelche Fehler oder Verbesserungswünsche 
eintrudeln und veröffentlich dann die neuste Version.

Essentiell gehts um das XPORT Problem vom Petr. Ich denke das der XPORT 
mit großen Datenpacketen ein Problem hat. Also wurde mein AVRootloader 
dahingehend geändert das man die maximale Packetgröße der 
Datenübertragung konfigurieren kann.


@roeben:

>Ich möchte den Bootloader per DMX-Schnittstelle nutzen, d.h. vor dem
>UART des Controllers sitzt ein RS485 Pegelwandler (Standardteil). Rx und
>Tx sind seperat angeschlossen, allerdings muss ich nun den Pegelwandler
>von Empfangen auf Senden umstellen können. Reicht das in deinem Code an
>ein/zwei Stellen die entsprechenden Ports zu setzen, oder wird das
>Deiner Meinung nach ein größeres Unterfangen???

Sollte sehr einfach gehen:

1.) vor der Baudrate Detektion, also gleich am Anfang auf Empfang 
stellen
2.) bei putc: nach den rcall waitf auf Senden stellen
3.) bei getc: die erste schleife leicht abändern und auf Empfang 
stellen. Hier sollte der rjmp getc auf eine neue Addresse nach deinem 
Umstellen auf Empfang zeigen

etwa so:

putc: rcall waitf
      rcall waitf
      sbi   RS485_PORT, PinRX_TX  
      ldi   cnt, 10
      com   paral

getc: cbi  RS485_PORT, PinRX_TX
get0: rx_1
      rjmp get0

und am Anfang des Booloaders vor

       cbi  RS485_PORT, PinRX_TX
       sbi  RS485_DDR, PinRX_TX

.if UseAutobaud
; baudrate detection
abd:   ldi  cmdl, byte3(BootDelay / 6)

Das dürfte es gewesen sein. Ich bitte dich um zwei Dinge

1.) baue deine Änderungen, wenn sie so funktionieren sollten, per 
DEFINES und bedingter Comilierung in den AVRootloader.ASM ein. Also wie 
bei RX_PORT/TX_PORT/RX/TX zwei neue Defines. Die obigen Änderungen, 
falls sie funktionieren dann per bedingte Compilerswitches einbauen. Und 
finally UseRS485 als Compilerswitch.

2.) veröffentliche deine Änderungen, wenn sie denn funktionieren, bitte 
hier im Forum oder maile sie mir, das ich sie übernehmen kann. So haben 
alle was davon.

Gruß Hagen

@Stefan, sende mir doch mal ne PN.

@Hagen: Hab gerade die Test-Dll vom AVRootloder 3.0 getestet !
Leider bekomme ich mehrere Fehler:
[Fehler] Unit1.pas(43): E2003 Undefinierter Bezeichner: 'GetAppCmd'
[Fehler] Unit1.pas(43): E2003 Undefinierter Bezeichner: 'GetAppVersion'
[Fehler] Unit1.pas(43): E2003 Undefinierter Bezeichner: 'GetACYInfo'
[Fehler] Unit1.pas(43): E2211 Deklaration von 'OpenCommunication' 
unterscheidet sich von der Deklaration in Interface 'IApplication'

Gruß Stefan

Datei AVRootIntf.pas mal anschauen, das sind die besagten Änderungen. 
Das was ich dir per Mail geschickt habe ist alles auf diese neue Version 
compiliert. Du musst also nur deine Sourcen updaten.

Gruß Hagen

@Stefan:

jetzt hab ichs kapiert ;) Du musst in deiner Application natürlich diese 
neuen Methoden des Interfaces auch deklarieren und implementieren. Dh. 
in deinem TForm hast du als Schnittstelle IApplication angegeben, hast 
aber diese neuen Methoden nicht im TForm deklariert. Der Compiler 
meckert es also an. Die function OpenCommunication(Index: Integer): 
ICOM; stdcall; hats einen neuen Parameter Index um die Autodetektion des 
COM Ports zu realisieren. Index beginnt dabei immer bei 1 und zählt 
hoch, so lange bis der IAVRootloader eine Verbindung herstellen konnnte 
oder aber die Methode .OpenCommunication() den Rückgabewert auf nil 
setzt, eg. Result := nil;


Meine .OpenCommunication sieht also so aus:

function TMainForm.OpenCommunication(Index: Integer): ICOM;
var
  PortName: String;
begin
  Result := nil;
  if AnsiCompareText(Port, 'AUTO') = 0 then
  begin // Auto Detection
    if Index >= CBPort.Items.Count then
    begin
      Output('Error: no Device found', ocError);
      Exit;
    end;
    PortName := CBPort.Items[Index];
    try
      Result := OpenCOM('\\.\' + PortName, Self);
    except
      Output(Format('Info: can not open port %s', [PortName]), ocInfo);
      raise EAbort.Create('');
    end;
  end else
  begin // one COM Port is selected
    if Index > 1 then Exit;
    PortName := Port;
    try
      Result := OpenCOM('\\.\' + PortName, Self);
    except
      raise Exception.CreateFmt('Error: can not open port %s', [PortName]);
    end;
  end;
  try
    Result.SetParams(Baudrate);
  except
    raise Exception.CreateFmt('Error: can not setup baudrate to %d', [Baudrate]);
  end;
  Output('Connecting on port ' + PortName + '...', ocInfo);
end;

Gruß Hagen

Hallo Hagen !
Danke für die erklärung der OpenComunication Function ! jetzt bin ich 
schon wieder nen bißchen weiter ! :-)

Aber was ich eigentlich gemeint habe waren nicht die Sourcen die du mir 
gemailt hast, sondern die Test-Dll aus dem AVRootloader.Zip !
Da hast du zwar die Anpassungen bezüglich der Ausgabe der Versionsnummer 
usw. gemacht, aber die Implementierung der GetAppVersion usw. wohl nicht 
vervollständigt ?! Ich kann Sie bei mir auf jedenfall nicht kompilieren 
ohne besagte Fehlermeldungen !

Gruß Stefan

Stimmt, Ordner Test-DLL ist veraltet.

Hallo in die große Runde,

erstmal ein großes Lob für diesen super Bootloader! Respekt!

Nun zu einem kleinen Problem was ich habe.

Ich habe hier einen Attiny45 mit der neusten AVRootloader Version den 
ich per 1-Wire (PB3) flashen möchte. Das funktioniert auch ohne Probleme 
mit der in der pdf gezeigten Schaltung. Nun möchte ich aber einen FTDI 
benutzen.

Ich habe dafür entsprechend im Bootloader folgende Zeile angepasst und 
neu geflashed.
.equ  UartInvert    = 1

Bei der Schaltung habe ich einfach die Dioden entfernt. RX hängt also 
direkt an PB3 und TX über den 2k Widerstand auch an PB3.

Nun leider funktioniert die Kommunikation gar nicht. Auf dem Oszi konnte 
ich nach erstem Test keine Antwort des Tiny sehen. Irgendwann ist der 
Pin dann einfach ein Ausgang und HIGH.

Meine zweite Frage wäre noch, wie die Verschaltung aussehen müssten, 
wenn man mehrere Controller programmieren möchte. Das Vorgehen mit dem 
BootSign hab ich verstanden.
Ich würde mal vermuten, dass vor jeden uC mit einem Widerstand am 
1-Wire-Bus hängt oder? Sonst könnten sich die Controller ja gegenseitig 
kurzschließen.

Vielen Dank!
PS: Danke nochmal für die tolle Software!

Grüße

Nachtrag:

Also ich hab folgendes probiert: UartInvert = 0 und mit der FTDI 
Software eingestellt, dass die TX/RX Leitungen invertiert werden sollen.
Es klappt sofort!

Kann es sein, dass es dann ein Softwarefehler ist, wenn UartInvert = 1 
und 1-Wire-Mode gleichzeitig an sind?

>Kann es sein, dass es dann ein Softwarefehler ist, wenn UartInvert = 1
>und 1-Wire-Mode gleichzeitig an sind?

Denke ich nicht, es müsste funktionieren. Definieren wir erstmal:

- RX_out ist Output des FTDI für die empfangenen Daten
- TX_in in Input des FTDI für die zu sendenden Daten

Serienwiderstand 2k zwischen RX_out und TX_In. TX_In an AVR Pin.

Nun liegt bei 1-Wire, bei keiner Aktvität immer der Pullup nach VCC am 
Pin an. Durch die Verschaltung am FTDI zieht aber RX_out über den 2K den 
TX_In auf LOW Pegel.

Schaue also mal ob dein 2k Serienwiderstand in der richtgen Leitung ist.
Ich habe aber selber noch nicht diese Kombination getestet und es könnte 
also durchaus sein das es damit noch Softwareprobleme gibt.

Wenn du mehrere AVRs über 1-Wire programmieren möchtest dann sollte 
UartInvert=0 sein.

Jeder AVR könnte aus Sicherheitsgründen einen Serienwiderstand von zb. 
220-470 Ohm am Pin haben, je nach VCC.

Normalerweise sollten die sich aber nicht in die Query kommen wenn alle 
Bootloader der AVRs im definierten Zustand sind, dh. sie warten alle 
erstmal das Connect Commando ab.

Wenn nun die AVRs alle unterschiedliche BootSign: haben dann reagiert 
immer nur derjenige AVR der mit der jeweiligen BootSign: angesprochen 
wurde, alle anderen AVRs lauschen nur auf der Leitung. Es gibt aber 
denoch das Problem das durch dummen Zufall, während gerade ein AVR 
programmiert wird, die Connect Sequenz im Datenstrom auftauchen könnte. 
Somit würde ein zweiter AVR in die bestehende Verbindung zwischen 
funken. Man sollte also die BootSign: der AVRs möglichst lang wählen und 
so das die Wahrscheilichkeit das diese als Daten im normalen Datenstrom 
vorkommen sehr gering ist.
Angenommen die BootSign's benutzen nur Großbuchstaben, sind 8 Zeichen 
lang dann beträgt die Wahrscheinlichkeit für eine Fehldetektion 1 zu 
229607785695641627262976 = 256^5 * 26^8. 256^5 für die ersten 5 Bytes -> 
0x00,0x00,0x00,0x00,0x0D gefolgt von den 8 Buchstaben der Bootsign. 
Alles bezogen auf die Übertragung von 13 normalen Datenbytes im 
Datenstrom = 20282409603651670423947251286016 mögliche Kombinationen. 
Die Bootsign der AVRs selber sollten sich stark voneinander 
unterscheiden.

Die Bootloader Software ist im Grunde nicht dafür konstruiert worden, 
ich weiß aber das es real funktioniert und wie man sieht ist es auch 
bischen Wahrscheinlichkeitsrechnung ;)

Gruß Hagen

Hallo Hagen,

danke für deine ausführliche Antwort.
>- RX_out ist Output des FTDI für die empfangenen Daten
>- TX_in in Input des FTDI für die zu sendenden Daten

Finde ich persönlich verwirrend, da RX für receive und TX für transmit 
steht. D.h. RX ist der Empfangspin des FTDI und der TX der Sendepin des 
FTDI. Bezogen auf den zweiten Kommunikationspartner genau umgekehrt, 
aber das ist ja erstmal Konventionssache.

Der Widerstand ist in der Sendeleitung des FTDI, er verhindern ja z.B. 
dass ein Kurzschluss entsteht, wenn der Tiny grad Sender ist. Tiny z.B. 
High und FTDI Low. Passt soweit auch von der Schaltung. Einen 
Pullupwiderstand gibt es ja gar nicht (abgesehen vom internen Pullup der 
ja bestimmt aktiviert ist, wenn der Tiny Empfänger ist). Habe den 
Nachmittag ein bisschen getestet und der Tiny meldet sich einfach nicht 
im 1-Wire Modus mit aktivierter Invertierung.

Aber mit der Invertierung der Signale im FTDI klappt ja alles wunderbar.

>Normalerweise sollten die sich aber nicht in die Query kommen wenn alle
>Bootloader der AVRs im definierten Zustand sind, dh. sie warten alle
>erstmal das Connect Commando ab.

Das müsste aber voraussetzen, dass der Tiny Pin im Hauptprogramm nur als 
Eingang genutzt wird oder? Weil wenn das BootSign keine Übereinstimmung 
findet, laden die Tinys ja das Hauptprogramm und wenn dort eben der Pin 
ein Ausgang ist, funken alle anderen uC dem einen der geflasht werden 
soll in die quere. Oder wird der Bootvorgang angehalten, wenn ein 
Connect Commando erkannt wurde, das BootSign aber nicht stimmt?

Die Sache mit den langen BootSigns ist ein guter Tip! Vielleicht mache 
ich mal einen Testaufbau. Gibt es eigentlich eine Beschränkung in der 
Zeichenanzahl des BootSign?

Nette Grüße
Mark

>Gibt es eigentlich eine Beschränkung in der Zeichenanzahl des BootSign?

ja, 256 Zeichen. 256 deshalb weil der Zähler beim Senden/Empfangen ein 
8Bit Register ist. Würde man dies auf 0 setzen == 256 mod 256, dann kann 
man 256 Zeichen als Maximalanzahl betrachten.

> Finde ich persönlich verwirrend, da RX für receive und TX für transmit

Ich habe in der Benamung nur die Sendrichtung mit angegeben, ergor 
stimmen unsere Sichtweise ansonsten überein. Da ich aber weiß das hier 
desöfteren Interpreatationsfehler gemacht werden, wollte ich nur sicher 
gehen.


probiere mal folgende Modifikation:

; send char
putc:
  rcall waitf
  rcall waitf
  ldi   cnt, 10
  com   paral
  sbi   TX_DDR, TX
put3:
  tx_out
  rcall waitf
  lsr   paral
  brcs  put4
  tx_0
put4:
  rcall put5
  dec   cnt
  brne  put3
  cbi   TX_DDR, TX
put5:
  ret  

in AVRootloader.inc änderst du das Makro:

.macro tx_out
  xout  TX_PORT, cnth            
.endmacro

Gruß Hagen

Hallo Hagen !

Hab jetzt erstmal die Anbindung des FTDI per D2xx.dll auf Eis gelegt. 
Ich bekomme trotz identischer Implementierung der vorhandenen FT_W32 
functionen immernoch, für mich unerklärliche, Fehlermeldungen. Außerdem 
funktioniert die Einbindung über VCP-Treiber ja zufriedenstellend. 
Einziger Wehrmutstropfen war die fehlende automatische Erkennung des 
richtigen Devices, die ich ja jetzt durch den Anmeldestring ersetzten 
kann.

Damit wären wir dann bei meinem nächsten Problem. Da die Test-Dll 
veraltet ist fehlt mir die Implementierung der neuen Funktionen.
Könntest du die wohl hier posten oder mir als PN zukommen lassen ?!

Ich habe übrigens noch einen Verbesserungsvorschlag für die 
AVRootloader.asm ! Kannst du die so verändern, das bei aktivierter 
Versionsverwaltung automatisch die Verschlüsselung aktiviert wird ? 
Damit bin ich nämlich erstmal ganz schön auf die Schnautze gefallen ! 
:-)
(Ja ja, wer nicht lesen kann und so...)

Gruß Stefan

Hab gerade ein riesen Problem mit der Versionsüberprüfung !!
Immer wenn ich die Option im AVR aktiviere bekomme ich keinen Connect 
mehr !!
Hab schon alle möglichen Konfigurtionen ausprobiert, auch 
unterschiedliche BootSize und BootReset. Alles andere funktioniert 
einwandfrei, nur wenn ich die Versionsprüfung aktiviere geht nichts mehr 
!!
Irgendwelche Vorschläge ???

Gruß Stefan

@Hagen

Danke für die Modifikation! Kann ich aber erst in ca. einer Woche 
testen, da ich jetzt erstmal eine Woche nicht mehr zu Hause bin. Melde 
dann aber wies aussieht.

Grüße Mark

@Stefan:

>Hab gerade ein riesen Problem mit der Versionsüberprüfung !!
>Irgendwelche Vorschläge ???

Welcher AVR, welche Konfiguration ?

Das Versioning funktioniert mit und ohne Verschlüsselung. Aber nur mit 
aktivierter Verschlüsselung wird ein Update an Hand seiner 
verschlüsselten neuen Versionnummer in der ACY Datei auch überprüft. 
Ohne Verschlüsselung ist das Versioning ein informativer Wert, muß also 
manuell verifiziert werden und kann jederzeit auch downgraded werden.

>Ich habe übrigens noch einen Verbesserungsvorschlag für die
>AVRootloader.asm ! Kannst du die so verändern, das bei aktivierter
>Versionsverwaltung automatisch die Verschlüsselung aktiviert wird ?

Also nein ;) da je nach Konfiguration so mehrere Möglichkeiten 
entstehen.

Gruß Hagen

> Welcher AVR, welche Konfiguration ?

Atmega8, und an der Konfiguration hat sich nichts geändert zum 
AVRootloader2 ! Habs mit und ohne Autobaud, mit und ohne Verschlüßelung, 
usw. probiert ! Der AVR hängt übrigens an nem FT232R !

> Das Versioning funktioniert mit und ohne Verschlüsselung.

Dann hab ich das wohl falsch verstanden ! :-)


> Also nein ;) da je nach Konfiguration so mehrere Möglichkeiten
> entstehen.

Hat sich ja dann auch erledigt, da es ja auch ohne Verschlüßelung 
funktioniert ! Hatte halt die Verschlüßelung in Verdacht weshalb das bei 
mir nicht funktioniert! Muß aber wohl woanders dran liegen !

Ich werde nacher nochmal nen paar Tests machen !

Gruß Stefan

Hallo Hagen !

Also hab mal noch nen paar Tests gemacht !
Ergebnis beim Versioning bleibt das gleiche ! Sobald es aktiviert ist 
kein Connect.
Dann hab ich mal unter AppCMD einen Wert =Test eingegeben. Ergebnis: 
Kein Connect !!!

Also schließe ich daraus das die Probleme irgendwo in der kommunikation 
mit dem FTDI liegen müßen, da du und auch andere Benutzer anscheinend 
keine Probleme haben !

Gibt es jemanden hier der den neuen AVRootloader zusammen mit einem FTDI 
erfolgreich betreibt ?

Hab schon nen bißchen mit den Timeouts gespielt, leider ohne Ergebnis !!
Werde jetzt mal ne alte schaltung mit RS232 raussuchen und da mal 
testen.

Gruß Stefan

@all

Also erstmal entwarnung was den FTDI angeht ! Der hat damit nichts zu 
tun !

@Hagen

Das problem liegt beim irgendwo beim Reset des AVR ! Wenn ich per Hand 
einen Reset ausübe(was in meiner Schaltung leider nicht verbaut ist) 
bekomme ich problemlos einen Connect. Ohne den Reset bekomme ich keine 
Verbindung !
Konfig:
- ATMega8 mit 10 MHZ-Kristall
- Nur der Rootloader installiert !
- Bootsize und Bootreset sind programmiert
- mit und ohne Autobaud getestet

Ohne Versioning und AppCmd klappt der Connect immer, mit einem der 
beiden aktiviert geht nichts mehr !

Woran kann das liegen ?

Gruß Stefan

@Stefan:

benutze mal die Version im Attachment. Setze in AVRootloader.INI den 
Wert in [System] -> Debug=1.

Mache einen Connect und schaue im Protokol nach was beim Wert "Received: 
" angezeigt wird.

Je nach Konfiguration den AVRootloader.ASM sollte folgendes angezeigt 
werden (in HEX)


1.) ohne Versioning, ohne BootMsg

4 Bytes BootInfo, 1 Byte SUCCESS Code $3x wobei X die Features anzeigen

2.) mit Versioning, ohne BootMsg

4 Bytes BootInfo, 4 Bytes Version ($FF,$FF,$FF,$FF bei ungeflashten 
AVR), 1 Byte SUCCESS Code

3.) ohne Versioning, mit BootMsg

x Bytes BootMsg immer gerade Anzahl Bytes, 4 Bytes BootInfo, 1 Byte 
SUCCESS Code

4.) mit Versioning, mit BootMsg

x Bytes BootMsg, 4 Bytes BootInfo, 4 Bytes Version, 1 Byte SUCCESS

- wenn die BootMsg definiert wurde dann wird sie immer als erstes 
gesendet
- wenn es eine Version gibt dann wird sie als letztes gesendet und er 
SUCCESS Code muß >= $38 sein, Version ist immer 4 Bytes, und bei AVRs 
ohne geflashte Anwednung immer $FF,$FF,$FF,$FF
- BootInfo wird immer dazwischen gesendet und ist 4 Bytes

Der SUCCESS Code ist immer $30
+ $08 wenn UseVersioning = 1
+ $04 wenn UseCryptE2 = 1
+ $02 wenn UseCryptFASH = 1
+ $01 wenn UseCrypt = 1


Das System in der PC-Software geht nun so vor:

Warte auf Zeichen von RS232 bis Timeout von [Timeouts].Base eintritt.
Solange kein Timeout Fehler baue einen String aus allen empfangenen 
Zeichen auf.
Nach einem Timeout zeige bei [System].Debug=1 in INI Datei den 
empfangenen Sring HEX-formatiert im Protocol Fenster an.
Analysere nun diesen String:
- steht am Ende ein gültiger SUCCESS Code ?
- ist der SUCCESS Code mit UseVersiong konfiguriert ? wenn ja 
vorhergenenden 4 Bytes als Verson interpretieren und wegschneiden, wenn 
neun nur SUCCESS Code wegschneiden.
- nun stehen am Ende 4 Bytes an BootInfo, auswerten und auf 
Plausibilität prüfen und wegschneiden.
- nun ist dieser String entweder leer oder enthält die BootMsg.


Gruß Hagen

Hallo Hagen
hab das mal alles der Reihe nach durchprobiert !
> 1.) ohne Versioning, ohne BootMsg
>
> 4 Bytes BootInfo, 1 Byte SUCCESS Code $3x wobei X die Features anzeigen
$93 $07 $03 $10 $37


> 2.) mit Versioning, ohne BootMsg
>
> 4 Bytes BootInfo, 4 Bytes Version ($FF,$FF,$FF,$FF bei ungeflashten
> AVR), 1 Byte SUCCESS Code
nur recieved: !! hier findet auch vorher kein switch to 2-wire mode.. 
statt


> 3.) ohne Versioning, mit BootMsg
>
> x Bytes BootMsg immer gerade Anzahl Bytes, 4 Bytes BootInfo, 1 Byte
> SUCCESS Code
abwechselnd:
recived: $C2 $C2 $C2
recived: $C2 $C2

egal was ich bei AppCmd eingebe !

> 4.) mit Versioning, mit BootMsg
>
> x Bytes BootMsg, 4 Bytes BootInfo, 4 Bytes Version, 1 Byte SUCCESS

wieder abwechselnd:
recived: $C2 $C2 $C2
recived: $C2 $C2

habs mit und ohne AutoBaud versucht ! Und hab auch mal den Timeout enorm 
erhöht (500 !), gleiches Ergebnis !

Kannst du damit was anfangen ?

Gruß Stefan

$C2 = ERRORCRC, der AVR Bootloader scheint also zu antworten was 
bedeuten würde das er schon längst in der Command FSM läuft, also 
connected ist.

Probiere mal als AppCmd

1.)

AppCmd=/00/00/00/00

2.)

AppCmd=test/00/00/00/00


wir senden also par Nullen mehr, also Kommando "Restart Bootloader".
Du kannst auch längere Sequenzen aus Nullen ausprobieren.

Woher dein Problem nun rührt kann ich dir auch nicht sagen. Du meinst 
also das mit der alten Version 2.0 keinerlei Probleme mit deiner HW 
entsteht, aber mit der neuen wie oben beschrieben.

Wenn du AVRootloader.asm in AVRStudio kompilierst dann gibts keine 
Fehler oder Warnungen ?

Ausgewählte BootSign stimt mir der im ASM überein ?

Gruß Hagen

PS: ich sleber habe nun schon mit ATMega162 und ATiny461 alle Optionen 
getestet, Laptop-RS232 mit 1-Wire, geht wunderbar.

Hagen du bist der Beste !!

Sobald ich in der AppCmd ein /00 einsetze geht es !!!
Und zwar beide Funktionen !!!
Und wenn du nicht weißt woran das liegt, dann weiß ich das schon lange 
nicht !
Ist mir persönlich aber egal, ich kann mit der Lösung leben !!

Vielen Dank !!!

Gruß Stefan

PS: Wenn du mir jetzt noch die Implementation der 3 neuen Funktionen für 
die Test-Dll zukommen lassen könntest, wäre das Spitze !! :-)

>PS: Wenn du mir jetzt noch die Implementation der 3 neuen Funktionen für
>die Test-Dll zukommen lassen könntest, wäre das Spitze !! :-)

Ist doch im letzten ZIP drinnen ? oder was meinst du ?

Gruß Hagen

Das Problem mit dem FTDI scheint ein Timing Problem zu sein.

Hast du mal mehre Nullen zusätzlich getestet ?

Gruß Hagen