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

> Ist doch im letzten ZIP drinnen ? oder was meinst du ?
Sorry ! Hab mich vielleicht falsch ausgedrückt ! Meinte den Aufruf der
Funktionen in der Test-Unit !
Also sowas in der Richtung:

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

Ich will die Functionen ja auch gerne in mein eigenes programm
übernehmen !


>Das Problem mit dem FTDI scheint ein Timing Problem zu sein.
>
>Hast du mal mehre Nullen zusätzlich getestet ?
Ja hab ich ! Bis zu 12x /00 hintereinander ! Macht aber keinen
Unterschied ! 1x /00 reicht aus ! Ist schon komisch, oder ?!?

Gruß Stefan

eigentlich nicht ;)

Wenn der Bootloader sich schon in seiner FSM befindet so benötigt er
exakt 0x00,0x00,0x00,0x00 um quasi einen Restart von sich selber zu
machen um erneut in die Baudraten Detektion zu springen. Gleich nach
diesen Nullen muß also 0x0D folgen, an Hand dessen die Baudrate
Detektion die Baudrate ermittelt.

Wenn aber die FSM schon aktiv ist und hat schon 1 Kommando Byte
verarbeitet dann reichen die 4 Null-Bytes nicht aus um ein gültiges
Restart Kommando zu dekodieren. Der Bootloader antwortet mit ERRORCRC
oder ERRORCOMMAND, hauptsache er macht nicht irgendwas unanständiges
(eben der Grund warum alle Kommandos separat mit CRC abgesichert sind).

Am besten ist es 7-8 solcher Nullen zu senden, und das ist in meiner
inoffiziellen Version auch schon gefixt.

Der Bootloader war bei dir aber schon in seiner FSM, weil du entweder
nach dem vorherigen Test den AVR nicht reset hast oder das
"RunApplication" Kommando der PC-Software nicht ordentlich ausgeführt
wurde. Es kann durchaus sein das der FTDI Treiber/FTDI selber sofort
alle Daten im Buffer löscht wenn die PC-Software nach dem Senden dieses
Kommandos sofort die VCom schließt. Ich rufe zwar FlushFileBuffers auf,
aber solche Probleme habe ich schon bei einigen Treibern gesehen.

Also wenn du mal testest dann prüfe auch mal ob deine Anwendung nach
einem Disconnect der PC-Software auch automatisch gestartet wird.

Die Aufrufe der neuen Methoden in IApplication sind trivial. Habe nur
wenig Zeit das Beispiel zu korregieren (weswegen es in den letzen ZIPs
auch nicht mehr drinnen ist). Beim nächsten offiziellen Update packe
ichs mit bei.

Gruß Hagen

Hallo.

ich habe das jetzt auch mal bei mir getestet.
Aber ich bekomme leider keine Verbindung zum AVR.

Folgende Einstellungen habe ich in der asm gemacht:

.include "m644def.inc"

#message "compile for" __PART_NAME__

.ifndef PageSize
.error "Device don't support Bootloader !"
.else
 

.equ  UseWDR      = 1        ; set to 0/1 to de/activate WatchDog Support
.equ  UseAutobaud    = 1        ; set to 0/1 to de/activate Baudrate Detection
.equ  UseVerify    = 0        ; set to 0/1 to de/activate Verify FLASH Command, FLASH write/erase includes implicit verify, can be deactivated
.equ  UseE2Write    = 0        ; set to 0/1 to de/activate EEPROM Write Command
.equ  UseE2Read    = 0        ; set to 0/1 to de/activate EEPROM Read Command
.equ  UseSRAM      = 0        ; set to 0/1 to de/activate SRAM Commands
.equ  UseCrypt    = 0        ; set to 0/1 to de/activate cryptography
.equ  UseCryptFLASH   = 0        ; set to 0/1 to de/activate only use of cryptography for writing to FLASH
.equ  UseCryptE2    = 0        ; set to 0/1 to de/activate only use of cryptography for writing to EEPROM
.equ  UseVersioning  = 0        ; set to 0/1 to de/activate Versioning for Application Software
.equ  UartInvert    = 0        ; set to 1 to invert UART levels, for RS232 drivers such as MAX232


.equ  RX_PORT      = PORTD      ; Receive Port and Pin
.equ  RX        = PD0
.equ  TX_PORT      = PORTD      ; Transmit Port and Pin
.equ  TX        = PD1

.set  XTAL      = 16000000    ; only important for BootDelay if Autobaud is used
.set  BootDelay    = XTAL/4    ; 250ms
.set  BootBaudrate  = 115200    ; only used if no Baudrate Detection activated, XTAL is important
.set  BootVersion    = 3        ; Version 3, must be not changed
.set  BootCodeSize  = 406      ; compile and set to value in [.cseg] Used, compile again

Fuses gesetzt auf:
BOOTSZ: Boot Flash size = 1024 words Boot address =$7C00
SUT_CKSEL: Ext. Crystal Osc. 8.0 - Mhz Start-up time: 16k CK+65ms

Quarz: 16Mhz.

Als Port ist bei mir Com10 und Baud habe ich mal auf 2400 gestellt.

Habe habe ich falsch gemacht ?

Danke, Markus

UartInvert=1, du benutzt doch einen Pegelwandler sagt mir meine
Glaskugel ;)

Gruß Hagen

Hallo.

Hab den Fehler gefunden.

.equ  UartInvert    = 0 muss 1 sein.

Ich nutzte den FTDI 232RL.

Jetzt geht es wunderbar und schön schnell.


Danke für dieses gute Programm.


lg, markus

@Markus:

> BOOTSZ: Boot Flash size = 1024 words Boot address =$7C00
> .set  BootCodeSize  = 406

Die BootCodeSize hast du nach der 1. Kompilation aus AVRStudio so
aktualisert ?

Wenn ja dann benötigt dein Bootloader 1024 Word = 2048 Bytes an FLASH.
Real verbraucht der Bootloader davon aber nur 406 Bytes. Somit stehen
1642 Bytes an FLASH ungenutzt zur Verfügung.
Ich empfehle dir also diesen verschwendeten Platz mit dem Bootloader in
anderer Konfiguration auszunutzen, setze

.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  UseVersioning  = 1
.equ  UartInvert    = 1

UseCryptFLASH/UseCryptE2 kannst du auch auf 0 setzen wenn du möchtest
das man den AVR mit oder ohne Verschlüsselung benutzen kann.
Wenn dann würde ich aber nur UseCryptE2=0 setzen, man kann also mit oder
ohne Verschlüsselung den EEPROM schreiben. Bei UsCryptFLASH=1 kann der
FLASH nur mit Verschlüsselung geschrieben werden. Das erhöht die
Sicherheit enorm. Besonders eben auch die Datenintegrität und ihre
Überprüfung wird mit der Verschlüsselung weitaus besser sein, da diese
quasi eine 64Bit secure Prüfsumme benutzt, neben der 16Bit CRC die
sowieso immer über die Daten berechnet wird.

Erzeuge vor der Kompilation mit der PC-Software ein neues Passwort mit
der PC-Software -> Button "Make Password".

Setze BootSign: auf einen längeren Wert, zb. BOOTLOADER, um die
Wahrscheinlichkeit einer Fehlanmeldung stark zu reduzieren.

Setze in BootMsg: einen für dich aussagekräftigen Titel/Copyright.

Selbst wenn du alle diese Features aktivierst wirst du maximal 950 Bytes
von den 2048 zur Verfügung stehenden Bytes des FLASHs verbrauchen.
Dh. der Bootloader ist für die großen ATMegas so klein das er mehrmals
in die minimale FLASH Size für eine Bootpage reinpasst.
Du könntest noch eine 1Kb Lookup Tabelle für deine Anwendung in diesem
FLASH unterbringen.

Gruß Hagen

> Am besten ist es 7-8 solcher Nullen zu senden, und das ist in meiner
> inoffiziellen Version auch schon gefixt.

Also dazu kann ich nur sagen, das der Connect jetzt mit jeder Version
funktioniert ! sobald ich in AppCMD 1x /00 setze !!

> Der Bootloader war bei dir aber schon in seiner FSM, weil du entweder
> nach dem vorherigen Test den AVR nicht reset hast oder das
> "RunApplication" Kommando der PC-Software nicht ordentlich ausgeführt
> wurde. Es kann durchaus sein das der FTDI Treiber/FTDI selber sofort
> alle Daten im Buffer löscht wenn die PC-Software nach dem Senden dieses
> Kommandos sofort die VCom schließt. Ich rufe zwar FlushFileBuffers auf,
> aber solche Probleme habe ich schon bei einigen Treibern gesehen.

Bei der Theorie muß ich dich leider enttäuschen ! Hab die letzten Tests
sowohl mit FTDI als auch mit Max232 getestet, bei beiden das exakt
gleiche verhalten !!

> Also wenn du mal testest dann prüfe auch mal ob deine Anwendung nach
> einem Disconnect der PC-Software auch automatisch gestartet wird.

Das funktioniert einwandfrei !

> Die Aufrufe der neuen Methoden in IApplication sind trivial.

Für dich vielleicht ! :-)

> Habe nur wenig Zeit das Beispiel zu korregieren (weswegen es in den
> letzen ZIPs
> auch nicht mehr drinnen ist). Beim nächsten offiziellen Update packe
> ichs mit bei.

Kein Problem ! Muß meine App. halt noch nen bißchen warten ! Ich werds
überleben !

Gruß Stefan

@Stefan:

>Bei der Theorie muß ich dich leider enttäuschen ! Hab die letzten Tests
>sowohl mit FTDI als auch mit Max232 getestet, bei beiden das exakt
>gleiche verhalten !!

Was benutzt du als BootSign: ?
Bzw. poste mal alles was in der ASM nach BootInfo: steht und die Section
[BootSign] aus der INI Datei.

Gruß Hagen

> Bzw. poste mal alles was in der ASM nach BootInfo: steht und die Section
> [BootSign] aus der INI Datei.
>
ASM:

BootSign:  .db    "BOOT"    ; iff you change it then change Sign in AVRootloader.ini
BootInfo:  .db    SIGNATURE_001, SIGNATURE_002, BootVersion, BootPages
BootEnd:
.if UseCrypt
; follow bytes should be keept secret and choosen randomly, 128 Bit Password, first 32 bit used as Signature
BootKey:  .db    $14,$70,$A1,$B3,$05,$73,$D7,$DC,$E9,$2F,$50,$6A,$64,$CD,$6B,$BA
.endif
.endif

INI-Datei:

[System]
Sign=BOOT
Port=COM4
Baudrate=256000
ConnectTrials=3
FLASH=
EEPROM=
ASMFile=AVRootloader.asm
Erase=1
Verify=0
Protocol=0
Password=7006C8F706ADAE04EE833D81503F31DC
AppCmd=/00
AppVersion=$01010107
AppVersionFlag=$0E
ACYInfo=

Sollte der Aufruf der AppCmd nicht ungefähr so funktionieren :

Result:= 'App-Code/00/00';

Gruß Stefan

Das Einzige was mir auffällt ist die Baudrate von 256000. Takt im AVR
sollte mindestens 7.68MHz sein ist dann aber schon Fehleranfällig bei
der Baudratedetektion. Hast du mal mit geringerer Baudrate probiert ?

>Hast du mal mit geringerer Baudrate probiert ?

Ja klar ! 256000 war nur mal zum Testen ob es damit auch geht !:-)
Aber durch die BaudRate-Detection sollte es ja eigentlich auch egal sein
was da drin steht !?

>Aber durch die BaudRate-Detection sollte es ja eigentlich auch egal sein
>was da drin steht !?

Jain ;) ganz egal ist es nicht, bei der Rechnung XTAL / Baudrate - 29
darf kein Wert kleiner 1 rauskommen. Aber selbst wenn 1 rauskäme so wäre
das schon sehr kritisch (Abtasttheorem).
Dh. je geringer die Taktfrequenz des AVRs und je
ungenauer/kurzzeit-instabiler desto geringer sollte die Baudrate
eingestellt werden.
Je geringer der Wert bei XTAL/Baudrate-29 ist desto exakter sollte die
Taktfrequenz durch die Baudrate teilbar sein, also ohne Rest.
Je geringer aber die Baudrate ist desto längere Timeouts muß die
PC-Software benutzen. Je größer diese Timeouts sind desto langammer ist
der Verbindungsaufbau. Die Wahrscheinlichkeit für ein ungünstiges
Connect-Timing steigt.

Gruß Hagen

OK ! Neue Erkenntnisse !

Feste BaudRate-BootSign(10Zeichen)-AppCmd(leer):
Connect funktioniert ! Aber nur das letzte Zeichen vom BootSign wird
angezeigt !

BaudRate-Detection-BootSign(10Zeichen)-AppCmd(leer):
Connect funktioniert ! Aber es wird abwechselnd das komplette BootSign
oder das letzte Zeichen ausgegeben !!!

Gruß Stefan

Und gleich noch was merkwürdiges hinterher !

Mit deiner Debug-AVRootloader Datei kommen abwechselnd das komplette
BootSign oder die letzten 2 Zeichen !!!

Mit deiner AVRootloader 3.1(bzw. 3.0 mit neuestem update) Datei kommen
abwechselnd das komplette BootSign oder das letzte Zeichen !!!

Übrigens sowohl mit FTDI als auch Max232 !

Gruß Stefan

> Mit deiner Debug-AVRootloader Datei kommen abwechselnd das komplette
> BootSign oder die letzten 2 Zeichen !!!
>
> Mit deiner AVRootloader 3.1(bzw. 3.0 mit neuestem update) Datei kommen
> abwechselnd das komplette BootSign oder das letzte Zeichen !!!

Sorry, da war ich ein bißchen voreilig !!
Hatte bei der AVRootloader 3.1 noch ein /00 im AppCMD stehen, dadurch
fehlte hier ein Zeichen !!

Also die beiden Versionen reagieren identisch !!

Gruß Stefan

Wo wird was angezeigt ? Beim Wert "Ident:" oder "Received:" ?

Beim Ident muß immer stehen:
AppCmd + $00 $00 $00 $00 $0D + BootSign

Bei Received darf niemals das BootSign drinnen stehen. Wenn das der Fall
sein sollte dann empfängt die PC-Software teilweise Daten die sie selber
abgesendet hat, und das darf überhaupt nicht sein, egal ob 1-Wire oder
nicht.

Lade dir mal aus dem WEB bei sysinternals.com den PortMon und sniff mal
real alles das mit was über die COM geht.

Deine Angaben sind teilweise sehr verwirrend für mich, kosten mir Zeit
und bringen im Endeffekt nichts. Es wäre auch gut wenn du bei solchen
Sachen die Ausgabe im Protkollfenster mit postest, dann kann ich mir
wesentlich besser ein Bild machen.

Gruß Hagen

> Wo wird was angezeigt ? Beim Wert "Ident:" oder "Received:" ?
Steht bei recived ! eine Kennzeichnung Ident hab ich noch nirgens
gesehen !!

> Beim Ident muß immer stehen:
> AppCmd + $00 $00 $00 $00 $0D + BootSign

So eine meldung hab ich noch nie gesehen !

> Bei Received darf niemals das BootSign drinnen stehen. Wenn das der Fall
> sein sollte dann empfängt die PC-Software teilweise Daten die sie selber
> abgesendet hat, und das darf überhaupt nicht sein, egal ob 1-Wire oder
> nicht.

Dann hab ich wohl nen riesen Problem !! Weil genau da steht das nämlich
drin.

29.01.09-18:22:25-812 > Device disconnected
29.01.09-18:22:26-640 > Connecting on port COM1...
29.01.09-18:22:26-703 > Switch to 2-Wire mode
29.01.09-18:22:26-765 > received:
$48,$61,$6C,$6C,$6F,$21,$21,$21,$21,$61,$61,$00,$93,$07,$03,$10,$FF,$FF,$FF,$FF,$39
29.01.09-18:22:26-765 > Device connected



> Lade dir mal aus dem WEB bei sysinternals.com den PortMon und sniff mal
> real alles das mit was über die COM geht.

Werd ich gleich mal versuchen !

> Deine Angaben sind teilweise sehr verwirrend für mich, kosten mir Zeit
> und bringen im Endeffekt nichts. Es wäre auch gut wenn du bei solchen
> Sachen die Ausgabe im Protkollfenster mit postest, dann kann ich mir
> wesentlich besser ein Bild machen.

OK ! Ich gelobe Besserung ! Will es dir ja nicht noch schwerer machen
als du es mit mir eh schon hast ! :-)

Danke

Stefan

Hab mal 2 Scans mit Portmon gemacht.
Test2: AppCmd(leer)-> Connect
Test3: AppCmd(AppCMD)-> kein Connect

Sag mal, arbeiter der AVRootloader eigentlich mit einem WDR wenn er
keinen Connect bekommt, oder versucht er es immer weiter ?

Gruß Stefan

$48,$61,$6C,$6C,$6F,$21,$21,$21,$21,$61,$61,$00,
$93,$07,$03,$10,
$FF,$FF,$FF,$FF,
$39


$48,$61,$6C,$6C,$6F,$21,$21,$21,$21,$61,$61,$00, -> in ASCII
"Hallo!!!!aa" ist deine BootMsg:
Danach kommen 4 Bytes BootInfo: wobei $93,$07 -> ATmega8, $03 =
BootVersion 3 und $10 = Anzahl der FLASH Pages die der Bootlaoder
benötigt $10 * 64 = 1024 Bytes.
Nun kommen 4 Bytes Versionsnummer, $FFFFFFFF heist noch keine Anwendung
drinen.
Als letztes Byte $39 = SUCCESSCODE, du hast UseVersiong=1 und UseCrypt=1
aber UseCryptFLASH = 0 und UseCryptE2 = 0. Somit kannst du
unverschlüsselt wie auch verschlüsselt mit dem Bootloader kommunizieren.
Allerdings benuzt die PC-Software in diesem Fall immer keine
Verschlüsselung.

Sooo, mal abgesehen das du das Zeichen ! zu lieben scheinst, ich sehe in
diesen Daten nichts vom BootSign: Das BootSign: steht per Standard auf
"BOOT".

Zitat:

>> Bei Received darf niemals das BootSign drinnen stehen. Wenn das der Fall
>> sein sollte dann empfängt die PC-Software teilweise Daten die sie selber
>> abgesendet hat, und das darf überhaupt nicht sein, egal ob 1-Wire oder
>> nicht.

>Dann hab ich wohl nen riesen Problem !! Weil genau da steht das nämlich
>drin.

Das was ich sehe ist eine perfekte Antwort des Bootloaders im AVR.


>Sag mal, arbeiter der AVRootloader eigentlich mit einem WDR wenn er
>keinen Connect bekommt, oder versucht er es immer weiter ?

Nein nicht mit dem WDT. Ein WDR würde ja bedeuten das er sich immer
wieder
selber aufruft.
Solange der Bootloader in der Wartephase auf einen Connect ist und er am
RX Pin irgendwas empfängt (toggelt) wartet er solange bis er ein
gültiges Connect empfangen hat. Dh. er versucht die Baudrate zu
berechnen und wartet auf den Wert in BootSign. Sobald sich am RX Pin
nichts mehr tut wird nach einem Timeout die Anwendung gestartet. Deshalb
ist das #define XTAL und BootDelay wichtig.
Wenn also im Normalfalle der Bootloader per RESET/Poweron angesprungen
wurde und sich in BootDelay Millisekunden nichts am RX Pin getan hat
dann wird die Anwendung gestartet.
Wenn sich aber in dieser Zeitspanne was am RX Pin tut so wird quasi
diese Zeitspanne erneut gewartet, eben ein Timeout. Solange also irgend
eine PC-Software was in dieser Phase was sendet gibt es nur zwei
Möglichkeiten aus dieser Schleife rauszukommen: a) für BootDelay
Millisekunden hört die Software auf was zu senden oder b) sie sendet den
korrekte BootSign Sequenz und der Bootloader antwortet zB. mit den Daten
wie du sie oben gepostet hast.

Der Watchdog wird mit UseWDT unterstützt. Aber auch nur um die WDT
Zeiten zu verlängern damit der Bootloader nicht durch den WDT gestört
wird. Man kann ja den WDT per WDTON Fuse permanent aktivieren und würde
der Bootoader nicht das berücksichtigen so stört der WDT den Bootloader.

Finally: ich sehe in deinen geposteten Daten keinerlei Fehler.
Die Daten in den .LOG Files vom PortMon mal bitte auf HEX stellen, bei
Sonderzeichen macht PortMon ein '.' und somit wie0 man nicht was das
bedeutet. -> Menu -> Options -> Show HEX.

Gruß Hagen

Hallo Hagen !

OK, das mit dem BootSign hab ich wohl gründlich falsch verstanden
gehabt, Sorry !

Inwieweit beeinflußt eigentlich die Einstellung der Baudrate im Program
den Verbindungsaufbau ?
Hab nämlich festgestellt das bei AppCmd(leer) der Verbindungsaufbau mit
115200 Baud tadellos funktioniert, aber bei zunemender Zeichenanzahl in
der AppCmd ich mit der Baudrate runtermuß um sporadisch noch einen
Connect zu bekommen. Sprich Connect funktioniert dann nur noch zu 30-40%
!

Hab im Anhang nochmal 2 Test, diesmal mit Hex !

Gruß Stefan

In Test4_PortMon.LOG hast du zweimal einen Connect aufgezeichnet. Der 1.
davon hat super funktioniert, ab Zeile 22.

Beim 2. Connect, ab Zeile 76 reagiert der AVR erst auf den zweiten
Connect versuch. Er ist beim ersten noch in er FSM und antwortet deshalb
mit C2 C2 -> ErrorCRC. Ein Command kann minimal 4 Bytes lang sein, bei
2x Fehler C2 (ERRORCRC) hat er also 8 Bytes empfangen. Das stimmt
insoweit mit der Anzahl der voeher gesendeten Bytes über ein, sind 9
Bytes im Connect String.
Danach, beim zweiten Senden des Connect Strings, verbindet er sauber.
Das heist der AVR ist schon in der Command-FSM, denn das ist er einzige
Punkt an dem ein ERRORCRC gesendet wird.

Test5_PortMon.log ist da schon erheblich interessanter.
Nach senden des Connect Strings, Zeile 22 zb., wird vom AVR die Bytes 80
00 empfangen. Nur woher kommen die ? Vom AVR garantiert nicht. Es
scheint so auszusehen das irgendwas auf deinem Board nicht stimmig ist.
Es gibt kein Kommando das mit den gesendeten Bytes für "AppCmd"
übereinstimmen würde und der AVR würde mit C2 oder C3 darauf reagieren
müssen, wenn er in seiner FSM wäre. Einzige Erklärung die ich noch habe,
wenn es tatsächlich am Bootloader läge, ist das irgendeines der Bytes,
bzw. sogar mehrere, innerhalb der Baudrate Detektion, als 0D Sequenz
erkannt wird. Er arbeitet dann mit falscher Baudrate und sendet wiederum
ein C2, aber wir sehen es als 80 00 mit anderer Baudrate.
Wenn man den AVRootloader.ASM nun mit fester Baudrate programmieren
würde, zb. 112500, dann müsste beim gleichen Test wie in
Test5_PortMon.log was anderes rauskommen.

Die Gefahr das die Baudrate Detektion andere Bytessequenzen
fälschlicherweise als 0D Sequenz interpretiert ist gegeben und führt
zwangsläufig dazu das der AVR eine andere Baudrate detektiert.

Ich weiß es nicht warum es bei dir nicht sauber funktioniert. Es ist ja
nun nicht so das es mit dem FTDI nicht funktionieren würde, das
bestetigten ja die positiven Rückmeldungen hier im Forum.

Gruß Hagen

Sag mal, wenn du AVRootloader.ASM kompiliert hast, dann hast du doch aus
dem Message Window vom AVRStudio den Wert aus CSeg Used in das ASM bei
BootCodeSize eingetragen und mit AVRStudio erneut kompiliert. Dann hast
du dir den Output im Message Window nochmal genauer angeschaut und dort
den Hinweis gesehen auf welche Bootfuses du den AVR setzen solltest.
Nach dem Flashen des HEX über ISP hast du auch die Boot Fuses
entsprechend eingestellt, richtig.

Denn ich denke auch da könntest du einen Fehler gemacht haben. Dieser
Fehler könnte sein das der Bootloaderr Code im FLASH an einer falschen
Addresse gespeichert wurde im Vergleich zu den eingestellten Bootfuses.
Das würde dann nämlich bedeuten das nach einem RESET der AVR mitten in
den Bootloader springen könnte und es so zu erklären ist warum der AVR
ständig in der Command FSM drinnen ist statt in der Baudrate Detektion +
BootSign Überprüfung zu warten.

Gruß Hagen

Hagen Re wrote:
> Sag mal, wenn du AVRootloader.ASM kompiliert hast, dann hast du doch aus
> dem Message Window vom AVRStudio den Wert aus CSeg Used in das ASM bei
> BootCodeSize eingetragen und mit AVRStudio erneut kompiliert. Dann hast
> du dir den Output im Message Window nochmal genauer angeschaut und dort
> den Hinweis gesehen auf welche Bootfuses du den AVR setzen solltest.
> Nach dem Flashen des HEX über ISP hast du auch die Boot Fuses
> entsprechend eingestellt, richtig.

AVRASM: AVR macro assembler 2.1.30 (build 592 Nov  7 2008 12:38:17)
Copyright (C) 1995-2008 ATMEL Corporation

C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloader.asm(68):
Including file 'C:\Programme\Atmel\AVR
Tools\AvrAssembler2\Appnotes\m8def.inc'
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloader.asm(126):
compile for ATmega8
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloader.asm(164):
Including file 'C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloader.inc'
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloader.asm(161):
WARNING: actual settings compromise security !
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloader.inc(114):
Please program Boot Fuse to Third Boot Start !
C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloader.asm(955):
No EEPROM data, deleting C:\Dokumente und
Einstellungen\Stefan\Desktop\AVRootloader_3_0\AVRootloader\AVR\AVRootloader.eep

ATmega8 memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x001c00 0x001f3a    792     34    826    8192  10.1%
[.dseg] 0x000060 0x000060      0      0      0    1024   0.0%
[.eseg] 0x000000 0x000000      0      0      0     512   0.0%

Assembly complete, 0 errors. 0 warnings

->
BootSZ1 = 0 BooTSZ0 = 1 BootRST = 0

Hab mal die Baudrate-Detection raus genommen und mit 115200 und 19200
getestet! gleiches Ergebnis ! sobald was in der AppCmd drin steht kein
Connect ! Aber ... mache ich zwischen den Connect-Versuchen einen Reset,
dann bekommt er beim nächsten versuch 1x einen Connect !
Es sieht also so aus als ob ich irgendein problem mit dem 'Internen
Reset' bzw. des Ablaufs der ConnectRoutine im AVR habe. Und was mich
wirklich irritiert ist halt die Tatsache das es ohne AppCmd funktioniert
und mit eben nicht ! Bzw. wenn er connectet dann mal mit vollem BootSign
oder nur mit dem letztn Buchstaben. Siehe Test4 ab Zeile 23 und ab Zeile
81 ! So geht das dann immer im Wechsel !

Gruß Stefan

Hallo Hagen !

kannst du dir mal die angehängte LogDatei anschauen.
Beim ersten Connectversuch war AppCMD leer. Beim zweiten Versuch ab
Zeile 123 war AppCMD = /00 ! Die empfangenen Zeichen sind in beiden
Fällen identisch außer das Sie im ersten Fall hintereinander stehen und
im zweiten Fall untereinander. Kannst du mir sagen woran das liegen
könnte ? bzw. kann ich diese /00 nicht einfach auf AVR-Seite Hardcoden
??

GRuß Stefan

Hi Stefan,

probiere mal die neuste Version im Attachment aus. Ich habe den
Verbindungsaufbau verändert.

Bisher würde bei einem Connect Versuch erstmal auf 1-Wire eingestellt.
Dann wurde der Connect-String gesendet und versucht exakt diesen Wert
sofort wieder vom COM Port zu lesen. Schlug dies fehl so wurde auf
2-Wire Mode umgeschaltet. DIese Vorgehensweise birgt aber ein Problem.
Wenn nämlich der AVR den 2-Wire Modus benutzt so empfängt der PC ja
sofort den Signature-String des AVRs statt dem soeben gesendeten
Connect-String. Der AVR ist also schon in seiner FSM drinnen, aber die
PC-Software schaltet erst jetzt in den 2-Wire Modus. Darauf hin versucht
sie erneut einen Connect im 2-Wire Modus und sendet erneut den
Connect-String. Das ist der Grund warum bei dir diese Probleme
auftraten.

Nun ist das geändert. Die PC-Software geht erstmal von 2-Wire Modus aus.
Sendet den Connect-String und empfängt die komplette Antwort. Dieser
String kann nun am Anfang den Connect-String selber enthalten, ergo
1-Wire Modus muß benutzt werden. Aus den empfangen Daten wird der vorher
gesendete Connect-String entfernt und der Rest dieser Daten ist die
Signature des AVRs die er gesendet hat.

Der Verbindngsaufbau und die Unterscheidung zwischen 1/2-Wire ist nun
wesentlich stabiler und schneller.

Gruß Hagen

Achso, dein modifiziertes AppCmd kannste raus nehmen (die Nullen
entfernen).

Super !
Das neue Update hat auf anhieb funktioniert ! Echt klasse !
Ich danke dir für deine Mühe, war ja nun echt keine leichte Geburt :-)

Gruß Stefan

Hier die neuste Version 4

Neuerungen:

- RS485/Profibus Unterstützung, dh. im Halbduplex Verfahren kann man
RS485 Treiber benutzen die einen Data Enable (DE) Eingang besitzen. Im
AVRootloader.asm einfach UseRS485=1, DE_PORT und DE setzen. Möchte man
invertierte Pegel nutzen dann noch UseRS485invert=1 setzen. Diese
Funktionalität konnte ich aber leider noch nicht testen ;(

- verändertes Verhalten des Watchdog Timers. Wird UseWDT=1 gesetzt so
wird der WDT im Bootloader explizit aktiviert und auf 2 Sekunden Timeout
gesetzt. Tritt nach 2 Sekunden ein WDT auf so wird ein RESET
durchgeführt. Somit ist die Stabilität des Bootloaders verbessert worden
wenn zb. ein ungeplanter Verbindungsabbruch auftreten sollte. Bitte
beachten das in der eigenen Anwendung auf den WDT reagiert werden muß,
oder er deaktiviert wird. Wie das geht zeigt das Testprojekt im Ordner
\test\.

- Mit UseSaveMCUCSR=1 wird der Wert aus dem Reset-Register MCUCSR in den
Stack gespeichert (RAMEND) bevor er in den WDT Routinen gelöscht wird.
Somit stehen diese Informationen für die Anwendung zur Verfügung. Wie
man das zb. in WinAVR GCC benutzen kann sieht man im Beispiel Projekt im
Ordner \test\

- Mit UseBootMode=0/1/2/3/4 kann man das Startverhalten des Bootloaders
beeinflussen. Über diese Konfiguration wird eingestellt das der
Bootloader zb. nur bei einem Power Up, externen Reset, Watchdog Reset
oder per Jump aus der Anwendung gestartet wird. Mit diesen Bootmodis
kann man die Startup Zeit der Anwendung beeinflussen. eg. verkürzen und
nur auf ausgewählte Ereignisse fixieren.

- Mit UseBootVector=1 wird am Ende des FLASHs ein Sprungvektor zum
Einsprungspunkt des Bootloaders erzeugt. Über diesen Vektor kann man aus
der eigenen Anwednung universell für alle AVR Typen die diesen
Bootloader benutzen den Bootloader aufrufen. Man muß also nicht explizit
die Startadresse des Bootloaders mehr berechnen.

- Mit UseSpecialFuncs=1 werden am Ende des Bootloaders verschiedene
zusätzliche Funktionen und eine Sprungtabelle eingebunden. Diese
Spezialfunktionen können aus der eigenen Anwendung heraus aufgerufen
werden. Sie können auch durch eigenen Code/Lookup Tabelle erweitert
werden.
Der normale Anteil an Code des Bootloaders ist so kompakt das er auf
größeren ATMegas mehrmals in die kleinste Bootsektion reinpasst. Man
verschwendet also in diesem Fall ungenutzen FLASH den man nun für diese
Spezialfunktionen aus der Anwendung heraus benutzen kann.
Zur Demonstration wurden die Funktionen zur Abfrage der AppVersion und
BootMsg/BootInfo eingebaut. Wie man diese benutzt kann man im Test
Projekt im Ordner \test\ für WinAVR GCC anschauen und austesten.

- im Ordner \test\ ein Test-Projekt in WinAVR GCC zur Demonstration der
Bootloader Funktionalität. Im Headerfile AVRootloader.h eine universelle
Schnitstelle zum Bootloader.

- durch einige Optimierungen im Code konnte der benötigte FLASH
reduziert werden

- mehr Kommentierungen


Bugfixes/Veränderungen:

- die AVR Typen ATMega161/ATMega163/ATMega323 benötigen bei der
Ausführung des SPM Befehles ein spezielles programmtechnisches Vorgehen.
Diese wurde gefixt und eingebaut.

- der Connect Prozess wurde verändert. Die Abfrage/das Warten auf das
BootSign von der PC-Software benutzt nun einen Timeout innerhalb
BootDelays. Bei der alten Version mit UseAutobaud=1 konnte es an dieser
Stelle zu einer Endlosschleife kommen, der Bootloader verblieb also bei
einem Kommunikationsabbruch endlos in dieser Schleife.

- im neuen Connect Prozess erwartet der Bootloader nach dem Empfang des
BootSign eine 16 CRC über diese BootSign. Dies inkrementiert die
Stabilität des Connect Prozess und beseitigt gleichzeitig ein Problem
beim Connect. Bei der alten Version konnte man beim BootSign "BOOT" zb.
auch mit einem Wert wie "BOOT1234" einen Connect bekommen. Die
zusätzlichen Zeichen "1234" störten die Command-FSM des Bootloaders und
es stellt auch ein Sicherheitsrisiko dar wenn man das BootSign als
Passwort betrachtet.

- wenn UseVersioning=1, UseCrypt=1 und UseCryptFLASH=1 war so wird ja
die AppVersion Nummer auf cryptographisch sichere Weise bei einem Update
per ACY Datei überprüft. Diese Überprüfung war nicht ganz korrekt. Ist
gefixt.


PC-Software:
- die Kommunikationsgeschwindigkeit wurde durch Optimierungen
beschleunigt.

- einige Fehler in der Bedienung etc.pp. beseitigt

- neue Einstellungen in der AVRootloader.ini
* [System]-AppCmd, [System]-AppCmdResponse, [Timeouts]-AppCmd.
über diese Einstellung kann man der Software mitteilen das sie bei einem
Connect erstmal das AppCmd an die eigene Anwednung zu senden hat. Wenn
nun in AppCmdResponse ein Wert steht so wartet die Software auf den
Empfang dieses Wertes. Eure Anwendung muß also dann dieses Response
senden und startet dann den Bootloader per Watchdog oder direktem
Sprung.
Nach Empfang des Response wartet die Software [Timeuts]-AppCmd
Millisekunden bevor sie mit dem Connect weiter macht. Startet man den
Bootloader in der eigenen Anwendung zb. per Watchdog und Endlosschleife
dann entsteht ein minimaler Timout von 17ms. Damit die PC-Software
ebenfalls diese Zeitspanne wartet kann man zB. Timeouts.AppCmd=20
setzen.
* [Timeouts]-KeepAlive ist ein Interval in Millisekunden in dem die
PC-Software beim Bootloader nachfragt ob er noch aktiv ist. Hat man mit
UseWDT=1 den Watchdog aktiviert so muß dieser spätestens nach 2 Sekunden
periodisch zurückgesetzt werden. Exakt das macht die PC-Software im
Interval von KeepAlive. Das hat mehrere Vorteile. Die PC-Software
bekommt mit wenn eine Verbindung zum Bootloader unterbrochen wurde und
trennt die Verbindung automatisch. Der Bootloader seinerseits erkennt
das die Verbindung zur PC-Software getrennt wurde und wird spätestens
nach 2 Sekunden durch einen Watchdog Timeout terminiert. Zudem
inkementiert es auch die Stabilität des Bootloaders auf unvorhergesehene
Ereignisse. Ich empfehle also mit UseWDT=1 zu arbeiten.
* [Timeouts].Options. Dies ist ein Bitkodierter Wert. Bit 0 = 1 ist der
Debugmode der PC-Software. Bit 1=2 bestimmt das Verhalten im Connect
Prozess beim Senden der BootSign. Ist dieses Bit gesetzt so benutzt die
Software die alte Methode beim Senden des BootSign, also ohne CRC
Prüfsumme. Damit wird die Kompatibilität zum alten AVRootloader.asm
gewährleistet. Für die neuste Version darf dieses Bit nicht gesetzt
sein.

- der neue Connect Prozess geht von einer 2-Wire Verbindung aus und
schaltet erst während des Connects dynamsich auf 1-Wire um wenn dieser
benutzt wird. In der alten Version war es umgekehrt. Diese Veränderung
verbessert die Connect Performance und Stabilität.

- XPORT (TCP/IP zu RS232-Wandler) wird sauber unterstützt. Der Grund
einiger Änderungen in der Kommunikation. Bei Interesse gibt noch Tipps
wie man den XPORT ordentlich konfiguriert von mir.

Tipps:

Wird so wie im Testprojekt im Ordner \test\ der PinChange am RX Pin
benutzt um 1.) aus dem Power Down Sleep Mode aufzuwachen und 2.) den
Bootloader zu starten dann sollte man in AVRootloader.ini folgende
Einstellungen treffen
[system]
AppCmd=/AA
AppCmdResponse=
[timeouts]
AppCmd=20

Somit sendet die PC-Software erstmal das Zeichen 0xAA um den PinChange
in der ISR zu bedienen. Innerhalb dieser ISR wird der Bootlaoder per
Watchdog Reset gestartet mit minimalem Timeout von 17ms. Die PC-Software
wartet nun ihrerseits 20 ms und somit wird der gesammte Connect Prozess
verbessert da das Timing ideal aufeinander abgestimmt ist.

Lese Readme.txt im Ordner \test\ ;)

Wenn ich die Spezialfunktionen in Special.inc erweitert vergesst nicht
am Ende des Sources euren Sprungvektor einzubauen. Desweiteren muß die
.org Direktive aktualisiert werden. In AVRootloader.h könnt ihr sehen
wir ihr dann eure Funktionen aufrufen könnt.

Mit der Spezialfunktion "GetBootMsg" kann man nicht nur die BootMsg aus
dem FLASH auslesen sondern auch alles was danach kommt. Also auch
BootKey: das Passwort der Verschlüsselung. Das ist kein
Sicherheitsrisiko wenn ihr alle korrekt konfiguriert habt. Also
UseSRAM=0, UseCryptFFLASH=1, UseCrypt=1. Desweiteren liefert nur ihr
vorkompilierte ACY Dateien an eure Kunden aus. Somit ist jeder
Anwendungscode der programmiert wird durch euch authorisiert.


Gruß Hagen

@Hagen:

Ein fettes Dankeschön für den riesigen Ehrgeiz, den du hier in das
Projekt investierst! Absolut fettes Tool!

Vielleicht kann ich die Tage ja einige Funktionen testen.

Eine Sache ist mir noch aufgefallen. Ich benutze ja den 1-Wire Betrieb
auf einem ATtiny45 mit einem FTDI. Wenn ich in meiner Software den
1-Wire Pin als Ausgang nutze, dann erkennt die PC-Flash-Software in
einem Großteil der Fälle immer den 2-Wire Betrieb. In den Bootloader
komme ich durch das Trennen der Betriebsspannung. Den Resetpin benutze
ich als 1-Wire-Pin. Die Verbindung kommt zu Stande aber eben im 2-Wire
Betrieb, wodurch dann das Flashen fehlschlägt. Vielleicht hast du ja
eine Idee, woran es liegen könnte.

Grüße

Hm, der Reset Pin hat der einen internen Pullup ?

Der FTDI ist ein Pegelwandler und ich habe mit Use1Wire und
UseUartInvert=1 einige Probleme hardwaretechnischer Art gehabt. Zu
Testzwecken benutzte ich den Spare-RS232 vom STK500. Wenn man den RX-TX
per Brücke verschaltet dann empfängt die PC-Software korrekterweise das
was sie vorher gesendet hat. Überbrückt man RX-TX aber mit zb. einem 2k7
Widerstand so empfängt die Software nichts mehr. Warum dies so ist weiß
ich bisher auch noch nicht, es sollte ja kein Problem damit geben. Aber
exakt diese Minimalbeschaltung benötigt man wenn man 1-Wire mit
TTL-RS232 benutzen möchte.

Du kannst bei der neuen Version mal in der AVRootloader.INI
[Timeouts]-Options=1 setzen, bzw. auf 3 wenn du mit der alten
AVRootloader.asm testen möchtest (diese empfehle ich dir aber nicht da
gerade im Connect Prozess einige Änderungen erfolgten)

Mit diesen Änderungen siehst du dann im Protocol-Window der PC-Software
was sie sendet und was sie empfängt. Bei 1-Wire müsste bei "received
data:" erstmal das stehen was bei "send ident:" gesendet wurde. Plus am
Ende die Antwort des Bootloaders die mit 0x3? enden muß.

Hast du den 1-Wire in deiner Konfiguration überhaupt schonmal zum laufen
gebracht ?

Du könntest mir per PN, eg. Mail mal den Output des Protocolwindows
mailen. Vieleicht sehe ich ja mehr.

Gruß Hagen

@Hagen

Pullup am Resetpin ist auch drin. Überprüfe es aber morgen nochmal.

Ja die 1-Wire Konfiguration mit dem FTDI habe ich in den Griff bekommen.
Jedoch nur indem ich UseUartInvert=0 gesetzt habe und mit dem
Konfigurationsprogramm (MProg) von FTDI den FT232R so programmiert habe,
dass die RX/TX Leitungen invertiert werden. (Siehe Anlage)

Mit UseUartInvert=1 und 1-Wire tut sich gar nichts. Am Oszi sieht man,
dass der uC kein einziges Bit sendet.

Also die PC Software empfängt immer nur ihr eigenes Signal, wenn der Pin
ein hochohmiger Eingang ist. Ist er ein Ausgang, so liegt das
entsprechende Signal des uC am RX des Pegelwandlers. Der Widerstand ist
ja zwangsläufig nötig, da der TX des Pegelwanlders ja ein Ausgang ist.
Im 1-Wire Betrieb ist der uC Pin ja zumindest zeitweise auch ein Ausgang
und damit es dann keinen Kurzschluss gibt muss der Widerstand her.

Da die Verbindung ja korrekt Aufgebaut wird, nur eben der falsche
Wire-Modus erkannt wird, muss der uC Pin am Anfang nach dem
Wiederanlegen der Spannung ein Ausgang sein. Somit merkt deine Software,
dass die eigenen gesendeten Daten nicht ankommen. Der uC empfängt alles
korrekt und meldet sich dann zurück. Sehr strange. Also wenn man es
einfach mehrmals probiert, dann erkennt er irgendwann mit Glück den
1-Wire und man kann flashen^^

Ich schaue mir mal morgen die Sache mit deinen weiter angeführten Ideen
an

LG Mark

Liegt nicht an dir, es lag am Source. Es tut mir ja immer leid wenn mir
sowas passiert, sieht immer nach Schnellschuß aus, aber irgendwann
einmal muß ich an den Sourcen was kaputt repariert haben.

Im Attachment die gefixte Version. Ich habe sie nun in allen Modis
getestet. 1/2 -Wire, invertiert und nicht invertiert, direkt an RS232,
an USB-RS232 Wandler und am XPORT über TCP/IP.

So langsam überblicke ich die ganzen RS232 Kabel auf meinem Schreibtisch
nicht mehr ;)

Du nimmst einen zb. 2k7 Widerstand und schließt diesen zwischen RX und
TX am FTDI. Am RX Pin den RX des AVRs.

In deinem Falle ist es so das 1-Wire identisch zum zb. Dallas 1-Wire
oder I2C arbeitet. Der AVR zieht den RX/TX Pin aktiv nach Masse als
Ausgang. Ansonsten setzt er den Pin als Eingang. Der 2k7 Widerstand am
TX-FTDI zieht die Leitung auf VCC und ist also sowas ähnliches wie ein
externer Pullup und Stromegrenzung. Bei dieser Verschaltung benötigt man
keine Serienwiderstand falls man zb. mehrere AVRs an einer Leitung legen
möchte. Der AVR kann auch mit geringerer VCC betrieben werden als der
TX-FTDI Ausgang liefert.

Bei 1-Wire an nativer RS232, also ohne Pegelwandler, liegt ebenfalls ein
2k7 Widerstand zwischen RX und TX an der DB9. Auch dieser dient zur
Strombegrenzung und die internen Bodydioden des AVRs begrenzen negative
Spannung gegen Masse. Desweiteren zieht die TX Leitung ebenfalls den
RX-Pin gegen -15V. Der Bootloader benutzt hier Strong/Weak-High-Pegel
statt eben Strong-Low-Pegel wie bei dir. 1-Wire-native-RS232 läuft bei
mir bis auf 1.8 Volt VCC runter.

Gruß Hagen

>Wäre es nicht einfacher bei UseWDR=1 immer das gerettete MCUCSR zu
>restaurieren? - Dann könnte die Applikation immer gleich sein,
>unabhängig davon ob ein Bootloader vorhanden ist oder nicht.

Geht nicht, habe ich probiert. Man kann es nur löschen aber nicht wieder
neu setzen (M162). Wenn ich nur das WDRF lösche dann würde es für die
Anwendung nicht möglich sein darauf zu reagieren.

>Mit den Parametern UseBootMode=0, UseWDR=1 und UseSaveMCUCSR=0 überlebt
>das MCUCSR beim M168 ohne besondere Tricks, beim M128 ist es immer
>gelöscht (wie beschrieben).

Hm, das sollte eigentlich nicht der Fall sein. Bei UseWDR=1 lösche ich
es ja immer mit xout MCUCSR, zerol.

Ok, Fehler gefunden in der AVRootloader.inc auf folgendes abändern

; some redefinition of register names or bits
.ifndef  MCUCSR
.equ  MCUCSR      = MCUSR
.endif ; .ifndef  MCUCSR

Dämliche ständige Umbenammung der Registernamen durch Atmel. Wenn man
mal eine Librariy universell programmieren möchte muß man ständig seine
Registernamen per umdefinieren.

>unter Win98se folgt dem 'Connect' sofort darauf wieder ein 'Disconnect'.
>Auch im Debug-Modus ist kein Grund erkennbar.
>Ausprobiert auf zwei Win98-PC und drei WinXP-PC mit identischem AVR-Chip
>(M168).

Das deutet darauf hin das die Windows Timer nicht sauber funktionieren.
Im Attachment die Version habe ich mal gefixt und im Debug Modus zeige
ich an ob die Timer sauber arbeiten.

In der INI in der Sektion [Timeouts] KeepAlive=500 setzen.

Es sollte jetzt periodisch "send keepalive" zu sehen sein. Wird die
Verbindung abnormal unterbrochen steht dann "keepalive failed".

Hm, könnte auch am MCUSR-Fehler liegen. Denn wenn im MCUSR/MCUCSR
Register das WDRF gesetzt ist und nicht vor dem Zugriff auf WDTCR
gelsöcht wird vereigert die MCU die neuen Einstellungen. Da durch den
Fehler in der AVRootloader.inc nicht MCUSR sondern MCUCR manipuliert
wurde, wurde auch der WDT nicht korrekt programmiert. Sicherlich stand
er noch auf 17ms Timeout und hat somit den Bootloader terminiert. Ich
denke das es daran liegen wird.

Gruß Hagen

Um sicher zu gehen immer die neuste Version benutzen.

Du benutzt 1-Wire-TTL-Pegel und da ist es wichtig das extern ein Pullup
angeschlossen ist. Normalerweise ist das der Fall über den 2k7
Widerstand zwischen deinem RX-TX Pin am Pegelwandler. Der Pegelwandler
zieht den TX-Pin ja auf High wenn nichts gesendet wird. Exakt das könnte
das Problem bei dir sein. Der interne Pullup am Pin ist deaktivert damit
der 1-Wire-Source so funktionieren kann das beim Schalten auf Ausgang
der Pin Low-Pegel hat.

Problematisch wird es wenn man diesen vom AVR abtrennt, dann floated der
Eingang. Es ist also in jedem Falle empfehlenswert einen ext. Pullup am
Pin anzuschließen, da der interne nicht benutzt werden kann.

Gruß Hagen

Ah ok, dann ist klar was los ist. Ist intern der Pullup auch bei
UartInvert=0 abgeschaltet? Könnte man nicht den Pullup eingeschaltet
haben und bevor du den Pin als Ausgang benutzt ihn eben abschalten? Oder
soll das Aufgrund des kleinen Codes so sein? Wären ja aber auch nur eine
Hand voll ASM Befehle. Dann könnte man sich den ext. Widerstand sparen.

Ich Frage deshalb, weil ich sieben PCB Boards mit je 16 tinys schon
fertig habe. Aufgrund von Zeitdruck ist da ein neufräsen nicht möglich,
wohingegen die Platinen (bis auf die eine zum Testen) noch nicht
bestückt sind.

PS: Ich kann den neusten Bootloader nicht aufspielen, da auf der
Testplatine schon alles bestückt ist.. ISP ist da bei den 16 vernetzten
Tinys nicht drinne ;)

Besten Dank für die Erklärung! Achja, kannst du den Schaltplan für
1-Wire dann bitte updaten? Da ist kein Pullup drinne. Führt dann wie bei
mir heute dazu, dass es mal geht und mal nicht ;)

Beste Grüße
Mark

Hab grad mal in deinen Quellcode geguckt.

; initialize ports
  cbi  RX_DDR, RX
.if UseUartInvert && Use1Wire
  cbi  RX_PORT, RX
.else
  sbi  RX_PORT, RX  <<--- Pullup an für Uartinvert=0//1-Wire :)
.endif ; .if UseUartInvert && Use1Wire

Sehe ich das richtig, dass für UartInvert=0 der Pullup tatsächlich
aktiviert ist? Das wäre für mich ja perfekt :) Dann stelle ich den FTDI
wieder auf invertierenden Modus um, und die Sache läuft :)

Grüße

Ja, bei 1-Wire und UseUartInvert=0 ist der interne Pullp aktiv. Bei
1-Wire mit UseUartInvert=1 ist er nicht drinne. Das hat tatsächlich
Gründe in der Codegröße und dem Timing. Du kannst versuchen ihn am
Anfang des Bootloaders zu aktivieren und in putc: dann ein/ausschalten:

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

Sind 4 Bytes mehr Code und ob das wirklch geht weiß ich nicht.
Denn man müsste eigentlich ständig zwischen Eingang+Pullup und
Ausgang+Lowpegel umschalten. Dazu müsste aber die komplette putc und
waitf Routine umgeschrieben werden und deren Timing würde sich um 1 Takt
verändern. Diese Veränderung in der Zyklenanzahl hat es aber insich und
muß im komplettten Timing der UART Routinen bis hin zur Baudrate
Detektion berücksichtigt werden. Gehen tut grundsätzlich ja alles, aber
die Zeit und der Aufwand ist das Problem.

>Achja, kannst du den Schaltplan für 1-Wire dann bitte updaten?

Nö. der ist ja für 1-Wire mit UseUartInvert=0, also direkt an der RS232.
Man kann sogar noch die beiden Dioden rausnehmen, geht auch. Mit dieser
abgespeckten Schaltung habe ich 1-Wire mit UseUartInvert=0 und 1
erfolgreich getestet. Allerdings mit einem echten RS232-Pegelwandler von
Maxim. Kann schon sein das der FTDI sich da anders verhält. Ist ebenso
beim Spare-RS232 auf dem STK500 so, die haben da eine Schutzbeschaltung
eingebaut.

>PS: Ich kann den neusten Bootloader nicht aufspielen, da auf der
>Testplatine schon alles bestückt ist.. ISP ist da bei den 16 vernetzten
>Tinys nicht drinne ;)

Du hast also schon fest eine alte Version des Bootloaders drauf ?
Bedenke das je nach Version du in der AVRootloader.ini dann [Timeouts]
Options=2 setzen musst. Damit der Connect mit der alten BootSign Methode
arbeitet.

Gruß Hagen

>>Du hast also schon fest eine alte Version des Bootloaders drauf ?
>Es ist schon die Version 4 nur eben nicht der letzte Fix mit dem MCUCSR
>Register.

Du nutzt ATMega8, kein Problem bei diesem da dessen Register MCUCSR
heist.
ATTiny45 ist wiederum ein Problem dessen Register heist MCUSR.

Das sind so die miesen Stolperfallen durch Atmel die einem
Programmiererleben die Munition für Herzinfarkte liefern ;)
By the Way: großen Respekt für die Entwickler vom WinAVR GCC die solche
Probleme der Standardisierung mit Sicherheit auch kennen werden.

>>Nö. der ist ja für 1-Wire mit UseUartInvert=0, also direkt an der RS232.
>Ein Vermerk, dass die Beschaltung eben nur für den Mode gilt, kann nicht
>schaden.

Ich werde das Schematik anpassen wenn ich die Zeit dafür finde.
Grundsätzlich geht es eben auch ohne "Pullup" wenn man den
Serienwiderstand zwischen RX/TX am Pegelwandler mit betrachtet. Sauber
ist es nicht, das stimmmt.

Gruß Hagen

> keepalive failed, terminate connection

das bedeutet "create timer" und "release timer" und "send keepalive"
sisht du in dem Protokoll. Das heist die Timer funktionieren, nur der
Bootloader im AVR antwortet nicht auf das Keepalive Kommando. Falsch
Version ? falsch konfiguriert ?

Was seht bei [timeouts] ? Mal Wert Base auf 50 oder 100 hochgesetzt ?
Neuste Version mit dem BugFix für das MCUCSR benutzt ?

Gruß Hagen

>12.02.09-17:00:51-090 > send appcmd     $0A 0A 2A 52 53 54 0A
>12.02.09-17:00:51-090 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F
54
>12.02.09-17:00:51-200 > send appcmd     $0A 0A 2A 52 53 54 0A
>12.02.09-17:00:51-200 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F
54
>12.02.09-17:00:51-260 > received data   $C2 94 06 04 08 30

1.) nimm mal bitte die $0A aus deinem AppCmd raus, mindestens das 0A
Zechen am Ende des AppCmd.

Die Zeichen 0A,0B,0D,0F,85,87,C3,E1 werden von der Baudrate Detektion
erkannt und an Hand dieser die Baudrate berechnet.

Grundsätzlich betrachtet dürfte das kein Problem darstellen da die
neuste Version nur eine Verbindung akzeptiert wenn sie das exakte
BootSign empfängt und anschließend eine gültige 2 Bytes CRC über diese
BootSign.

2.) der AVR antwortet mit

C2 -> Error CRC
94 06 04 08 -> BootInfo
30 -> SUCCESS Code

Das er überhaupt C2 absendet deutet darauf hin das du garnicht die
neuste Version auf deinen AVRs installiert hast. Denn nur mit der alten
Version kann es zu solchen Synchronisationsproblemen der internen FSM
beim Verbindungsaufbau kommen, in Verbindung mit dem Connect Aufbau der
neusten Version. Das er rausfliegt ist dann nämlich logisch.

Der alte Source empfängt nach dem BootSign noch 2 Bytes der CRC über
dieses BootSign für die neue Version. Diese landen erstmal als Kommandos
in der FSM des Bootloaders. Er erwartet noch 2 weitere Bytes die die CRC
darstellen. Das erste mal nach einem Connect bei dem die PC-Software ein
Befehl absendet ist beim Keepalive wenn du nur verbindst. Der AVR
empfängt die ersten 2 Bytes dieses Befehles als 2 Bytes CRC des
vorherigen Befehles und sendet ErrorCRC als Antwort, meine PC-Software
disconnected dann.

3.) du benutzt "BOOT" als BootSign was der Standard der alten Version
ist. Die neuste benuzt "BOOTLOADER".

(und ich benutze dabei nur meine Glaskugel und mein Hirn)

Ergo wie oben in einigen Postings zu lesen war:

1.) Setze [Timeouts] Options=3 oder =2 um den alten Verbindungsaufbau
zur alten Version des Bootloaders zu aktivieren. Dann dürfte es sauber
laufen.

2.) du hast auf deinen AVRs mit Sicherheit die alte Version installiert.
Wenn du updatest dann [Timeouts] Options=1 oder =0 setzen.

3.) man erkennt an Hand solcher Fehler das die interne FSM sehr stabil
gegen Protokollfehler ist. Schlimmer wäre es nämlich wenn sie in einem
solchen Fall zb. den FLASH löscht oder falsch programmiert.

Gruß Hagen

Hi Heinrich,

lade dir mal die neuste Version
Beitrag "AVR-Bootloader mit Verschlüsselung"
Entpacke sie in einen separaten Ordner, wir sind nur an der neuen
PC-Software interessiert.

Im Ordner \Windows\ ist die neuste PC-Software. Setze alle Parameter
deren AVRootloader.ini auf die in deiner aktuellen AVRootloader.ini.
Zusätzlich [Timeouts] Options=3. Der Parameter Debug= der alten Version
ist entfernt worden und befindet sich als Bit in Options.

Nun starte diese neue Version und versuch eine Verbindung zum AVR mit
alten Bootloader.

Wenn das nicht funktioniert versuche sukzessive in [Timeouts] die Werte
für Base und Connect zu erhöhen. Zb. Base=100 und Connect=50 oä.
Bei solchen virtuellen Treiber wie dem FTDI eg. USB-Serialwandler sollte
Base auf minimal 50ms stehen.

Ein weiteres Problemfeld könnte der virtuelle Treiber des FTDIs auf
diesem Notebook sein. Mal reinstallieren.

Achso, und schau mal in die Datei AVRootloader.dev rein und suche nach
9502=, dort muß bei dir dann folgendes stehen
9502=1E9502, ATmega32     ,  32768, 1024, 2048,  96, 128,  4,  8, 16, 32

Nur die AVRs in dieser Datei werden erkannt. Man kann also durch die
Editierung dieser Datei bestimmte AVRs ausschließen oder neue AVRs
nachträglich dem Bootloader mitteilen.

Gruß Hagen

Ich sehe gerade du hast UseAutoBaud=0 gesetzt. Es könnte sein das das
Timing des AVR-RS232 und FTDI-RS232 nicht exakt übereinstimmt. Deshalb
normalerweise immer UseAutobaud=1 setzen. Ich weiß nicht wie der FTDI
sein Timing erzeugt, es ist eigentlich unlogisch das das vom USB Host
abhängen sollte, aber vorstellbar ist heutzutage alles.

Andererseits empfängt ja die PC-Software eine gültige Rückmeldung vom
AVR. Ich denke also das mit der neuen PC-Sofwtare und höheren
Timeouts.Base das problem beseitigt sein sollte.

Gruß Hagen

Alle PC-Bootloader sollten vollständig abwärtskompatibel sein. Nur bei
der neusten Version muß man in der .INI bei [Timeouts] Options=0 oder 2
setzen wenn man mit der alten oder neuen AVRootoader.ASM arbeitet. Dh.
das Bit #1 = 2 muß in Options bei der neusten PC-Software gesetzt sein
wenn man mit dieser eine ältere AVRootloader.ASM verbinden möchte.
Options=0 muß gesetzt sein wenn mit der neuen PC-Software auch mit der
neusten AVRootloader.ASM verbunden werden soll. Der Hintergrund ist eine
Änderung beim Verbinden mit dem Bootloader. In der neusten Version
erwartet der Bootloader nach dem Empfang des BootSigns noch eine 16 Bit
CRC über das zuvor empfangene BootSign. Dies beseitigt ein kleineres
Problem der älteren Versionen und macht den Verbindungsaufbau stabiler
und sicherer (wenn man das BootSign als Passwort betrachtet).

Ansonsten ist jede Version zu 100% abwärtskompatibel, was ich auch als
wichtig erachte wenn man zb. schon fertige Geräte mit älteren
AVRootloader Versionen updaten möchte.

Allerdings, wie du siehst, habe ich einiges an den PC-Softwares
verbessert um den Gesamtprozess der Kommunikation stabiler und auch
performanter zu machen.

Am Kommunikationsprotokoll selber hat sich, bis auf zwei Punkte, rein
garnichts geändert. Die zwei Punkte sind:
1.) neues Kommando 0xFD hinzugekommen. Dies ist nun das offizielle
"KeepAlive" Kommando und im Grunde nur ein Platzhalter. Dh. im
AVRootloader.ASM musste dafür garnichts geändert werden, es wird auf PC
Seite erwartet das der AVR mit 0xC3 = unbekanntes Kommando, antwortet.
Es dient nur dazu den Watchdog Timer im AVR zurückzusetzen. Dieser wird
bei jedem Kommmando zurückgesetzt falls UseWDT=1 gesetzt ist.
2.) bei UseVersioning=1 hat sich der Aufbau des ersten verschlüsselten
Initialisierungs-Blockes verändert. Statt 16 Bytes hat dieser Datenblock
dann 24 Bytes Größe. In den zusätzlichen 8 bytes ist die
Versionsnummernüberprüfung verschlüsselt kodiert. Da die alten
Bootloader Versionen das Versioning nicht unterstützen ist auch hier die
Abwärtskompatibilität sicher gestellt.

Ansonsten ist es eh immer so das nur verschlüsselte ACY Dateien
geupdated werden können die 1 zu 1 zur jeweiligen Bootloaderversion
erzeugt wurden. Dh. PC-Software-Version 3 kann nur ACY erzeugen für
Bootloader Version 3. Eine ACY erstellt mit Version 3 kann nicht auf
AVRs mit Bootloader Version 4 oder 2 installiert werden. Das mag im
ersten Moment eine starke Restriktion darstellen aber hier gilt aus
meiner Sicht die kryptographsiche Sicherheit als Priorität. Wenn
gewünscht kann das aber durchaus verändert werden, so daß die
PC-Software für den Bootloader der aktuell verbunden ist eine
versionerichtige ACY Datei kompiliert. Das aalles gilt aber nur bei
aktivierter Verschlüsselung.

Gruß Hagen

Hallo zusammen,

ich habe den Bootloader erfolgreich auf einem ATTiny25 installiert und
er funktioniert soweit sehr gut. Ich benutze den 1-wire Mode an PB0.
Wenn ich aber PB5 zuschalte (RSTDISBL) dann kann ich keine Verbindung
mehr zum Bootloader herstellen. Ich wollte aber gern PB0 freimachen und
PB5 benutzen. Hat einer eine Ahnung woran das liegen kann? Desweiteren
bekomme ich auch keinen Zugang wenn die Taktfrequenz des Tiny nur 1 MHz
beträgt. Ist das einfach zu wenig für die Baudrate Detektion?

Gruß Rene

@Rene
Hast du vor dem Setzen des RSTDISBL Flags, Hagens ASM Datei geändert,
dass PB5 der 1-Wire-Pin ist und vorher auch geflashed?
Habe den Bootloader auf einem ATtiny45 laufen. Benutze aber eine feste
Baudrate von 115200 mit internen 8Mhz.

Hast du vor dem Setzen des RSTDISBL Flags, Hagens ASM Datei geändert,
dass PB5 der 1-Wire-Pin ist und vorher auch geflashed?

Ja habe ich, aber auch wenn ich den 1 Wire an PB0 lasse und nur RSTDISBL
setze geht es schon nicht mehr. Das finde ich sehr komisch. Benutzt du
PB5 (Reset) für 1-Wire? Kannst du das mal für mich überprüfen?

Gruß Rene

Ja ich benutze den Resetpin. Um in den Bootloader zu kommen, musst du
erst auf "Connect" gehen, dann die Spannung kurzzeitig unterbrechen. So
gehts bei mir. Wenn das geht, kannst du auch nen Pin-Change-Interrupt
nehmen um aus der Applikation in den Bootloader z.B. per Watchdogreset
zu kommen.