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

Hallo Hagen,

mal 'ne andere Frage, womit hast Due die Windows-Applikation
programmiert?
Nur eine EXE, das gefällt mir und die Optik ist Dir auch ganz gut
gelungen.

Danke.
Gast

Ah, ich denke ich habs schon gefunden. Schient Delphi zu sein!?

Gast

Ah, ich denke ich habs schon gefunden. Scheint Delphi zu sein!?

Gast

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

Hallo Hagen,

ich wollte deinen bootloader auf einen m168 ausprobieren, aber leider
komme ich nicht zum Erfolg.

a) Hardware: habe einen FTDI232BM zwischen dem mega168 und USB hängen
der mega168 ist im 256word boot mode gefused.


b) SW

; copyright HR

.nolist

; supported devices
;.include "can128def.inc"      ; AT90CAN128 
;.include "can32def.inc"      ; AT90CAN32  
;.include "can64def.inc"      ; AT90CAN64  
;.include "m1280def.inc"      ; ATmega1280 
;.include "m1281def.inc"      ; ATmega1281 
;.include "m128def.inc"        ; ATmega128  
;.include "m161def.inc"        ; ATmega161  
;.include "m162def.inc"        ; ATmega162  
;.include "m163def.inc"        ; ATmega163  
;.include "m164Pdef.inc"      ; ATmega164P 
;.include "m165def.inc"        ; ATmega165  
;.include "m165Pdef.inc"      ; ATmega165P 
.include "m168def.inc"        ; ATmega168  
;.include "m168Pdef.inc"      ; ATmega168P
;.include "m169def.inc"        ; ATmega169  
;.include "m169Pdef.inc"      ; ATmega169P 
;.include "m16def.inc"        ; ATmega16   
;.include "m2560def.inc"      ; ATmega2560 
;.include "m2561def.inc"      ; ATmega2561 
;.include "m323def.inc"        ; ATmega323  
;.include "m324Pdef.inc"      ; ATmega324P 
;.include "m3250def.inc"      ; ATmega3250 
;.include "m3250Pdef.inc"      ; ATmega3250P
;.include "m325def.inc"        ; ATmega325  
;.include "m325Pdef.inc"      ; ATmega325P 
;.include "m3290def.inc"      ; ATmega3290 
;.include "m3290Pdef.inc"      ; ATmega3290P
;.include "m329def.inc"        ; ATmega329  
;.include "m329Pdef.inc"      ; ATmega329P 
;.include "m32def.inc"        ; ATmega32   
;.include "m406def.inc"        ; ATmega406  
;.include "m48def.inc"        ; ATmega48   
;.include "m48Pdef.inc"        ; ATmega48P  
;.include "m640def.inc"        ; ATmega640  
;.include "m644def.inc"        ; ATmega644  
;.include "m644Pdef.inc"      ; ATmega644P 
;.include "m6450def.inc"      ; ATmega6450 
;.include "m645def.inc"        ; ATmega645  
;.include "m6490def.inc"      ; ATmega6490 
;.include "m649def.inc"        ; ATmega649  
;.include "m64def.inc"        ; ATmega64   
;.include "m8515def.inc"      ; ATmega8515 
;.include "m8535def.inc"      ; ATmega8535 
;.include "m88def.inc"        ; ATmega88   
;.include "m88Pdef.inc"        ; ATmega88P  
;.include "m8def.inc"        ; ATmega8    
;.include "pwm2Bdef.inc"      ; AT90PWM2B  
;.include "pwm2def.inc"        ; AT90PWM2   
;.include "pwm3Bdef.inc"      ; AT90PWM3B  
;.include "pwm3def.inc"        ; AT90PWM3   
;.include "tn13def.inc"        ; ATtiny13   
;.include "tn2313def.inc"      ; ATtiny2313 
;.include "tn24def.inc"        ; ATtiny24   
;.include "tn25def.inc"        ; ATtiny25   
;.include "tn261def.inc"      ; ATtiny261  
;.include "tn44def.inc"        ; ATtiny44   
;.include "tn45def.inc"        ; ATtiny45   
;.include "tn461def.inc"      ; ATtiny461
;.include "tn84def.inc"        ; ATtiny84   
;.include "tn85def.inc"        ; ATtiny85   
;.include "tn861def.inc"      ; ATtiny861  
;.include "usb1286def.inc"      ; AT90USB1286
;.include "usb1287def.inc"      ; AT90USB1287
;.include "usb162def.inc"      ; AT90USB162 
;.include "usb646def.inc"      ; AT90USB646 
;.include "usb647def.inc"      ; AT90USB647
; unsupported devices, no self programming or sram to small
;.include "1200def.inc"        ; AT90S1200  
;.include "2313def.inc"        ; AT90S2313  
;.include "2323def.inc"        ; AT90S2323  
;.include "2343def.inc"        ; AT90S2343  
;.include "4414def.inc"        ; AT90S4414  
;.include "4433def.inc"        ; AT90S4433  
;.include "4434def.inc"        ; AT90S4434  
;.include "8515def.inc"        ; AT90S8515  
;.include "8535def.inc"        ; AT90S8535  
;.include "AT86RF401def.inc"    ; AT86RF401  
;.include "m103def.inc"        ; ATmega103  
;.include "tn11def.inc"        ; ATtiny11   
;.include "tn12def.inc"        ; ATtiny12   
;.include "tn15def.inc"        ; ATtiny15   
;.include "tn22def.inc"        ; ATtiny22   
;.include "tn26def.inc"        ; ATtiny26   
;.include "tn28def.inc"        ; ATtiny28   

#message "compile for" __PART_NAME__

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



.equ  UseWDR      = 0        ; set to 0/1 to de/activate WatchDog
.equ  UseAutobaud    = 1        ; set to 0/1 to de/activate Baudrate Detection
.equ  UseVerify    = 1        ; set to 0/1 to de/activate Verify FLASH Command, FLASH write/erase includes implicit verify, can be deactivated
.equ  UseE2Write    = 1        ; set to 0/1 to de/activate EEPROM Write Command
.equ  UseE2Read    = 1        ; 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 cryptography for writing to FLASH
.equ  UseCryptE2    = 0        ; set to 0/1 to de/activate only use cryptography for writing to EEPROM
.equ  UartInvert    = 1        ; 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      = 14745600    ; only important for BootDelay if Autobaud is used
.set  BootDelay    = XTAL / 3    ; 300ms
.set  BootBaudrate  = 115200    ; only used if no Baudrate Detection activated, XTAL is important
.set  BootVersion    = 1        ; Version 1
.set  BootCodeSize  = 494      ; compile and set to value in [.cseg] Used, compile again

c) error Meldung im flash Windowsprogramm:

30.03.08-22:24:34-875 > Connecting...
30.03.08-22:24:34-968 > Switch to 2-Wire mode
30.03.08-22:24:39-328 > Device connected
30.03.08-22:24:39-359 > programming Device...
30.03.08-22:24:39-375 > execute compiled data
30.03.08-22:24:39-375 > selected options in compiled file:
30.03.08-22:24:39-375 > - programming FLASH
30.03.08-22:24:39-375 > - erase FLASH during programming
30.03.08-22:24:39-375 > - full verify FLASH after programing
30.03.08-22:24:39-375 > - programming EEPROM
30.03.08-22:24:39-546 > ICOM: read error.
30.03.08-22:24:39-578 > Device disconnected


hast du eine Idee?

Nachtrag:

folgendes kommt bei "device information":

Connection                     : 2-Wire
Device name                    : ATmega168
Device signature               : 1E9406
SRAM size                      :   1024 Byte
EEPROM size                    :    512 Byte
FLASH size                     :  16384 Byte
FLASH size for application     :  15872 Byte
FLASH pagesize                 :    128 Byte
Bootloader size                :    512 Byte
Buffersize for data            :    920 Byte
SRAM start address             :    256
Bootloader version             :      1
Use bootsection                :    Yes
Cryptography supported         :     No


besten Dank

:-)

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

Hallo Hagen,

super vielen Dank für dein schnelles update.

Ich habe deinen neuen Bootloader auf den mega168 mit gleichen settings
geflasht. Das flashen mit dem neuen Windows programm hat auf anhieb
geklappt. Ich brauchte keine weiteren timings anpacken. Baudrate war
256000b/s (FTDI chip).
Wollte dann rausfinden welches der minimum timeout Wert ist und bliebt
dann bei Flash=13 hängen. Alles über 13 war OK. Flash und Eeprom konnte
beides gleich gut geschrieben werden.

Mir ist allerdings aufgefallen, das ich das EEPROM nur mit max. 38400b/s
auslesen konnte ("EEPROM Content"). Hohere Baudratenwerte resultierten
zu einem "ICOM: read error". Auch ist unter "EEPROM Content" der "write
to devive" Button dekativiert, wenn ich ein externes *.eep file geladen
habe.
Bei "SRAM content" sieht es genau so aus. Leider nur bis 38400b/s ist
das auslesen möglich.

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

Du hast zwar geschrieben, das der Bootloader so gut wie fertig ist, aber
ich würde trotzdem gerne paar kosmetische Wünsche äußern.

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

.equ  UseWDR      = 0
.equ  UseAutobaud    = 1
.equ  UseVerify    = 1
.equ  UseE2Write    = 1
.equ  UseE2Read    = 1
.equ  UseSRAM      = 1
.equ  UseCrypt    = 0
.equ  UseCryptFLASH           = 0
.equ  UseCryptE2    = 0
.equ  UartInvert    = 1

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.


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

mfg.

chris

@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

Hallo Hagen,

deine ausführlichen Antworten sind wirklich bemerkenswert. Du steckst ne
menge Zeit da rein, aber ich denke ich habe nun alles soweit hinbekommen
und verstanden.

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

Deine neue Windows Applikation gibt mir folgende Meldung aus, wenn Base
auf 25 steht.

Connecting...
31.03.08-21:48:09-064 > Switch to 2-Wire mode
31.03.08-21:48:09-846 > Device connected
31.03.08-21:48:09-877 > read EEPROM...
31.03.08-21:48:09-908 > CmdReadEeprom.ReadByte(1) ICOM: read error.
31.03.08-21:48:09-924 > Device disconnected

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.

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

Ja, du hast recht. Sieht so aus, das der "normale" flashvorgang reicht
um eine recht hohe Fhashwahrscheinlichkeit zu erreichen.
Das verkürzen des Boot sign von "BOOT" auf "BT" würde in meinem Fall
wirklich helfen, wow. :) Wenn dieses keine weiteren Auswirkungen hat,
würde ich jetzt einfach mal dauerhaft bei mir so einstellen.

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

Das ist absolut kein Thema. Sowas ist auch wirklich nur "nice to have".
Es gibt ja ein feedback im Protocol was einem anzeigt ob alles geklappt
hat.

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

ja, ich  habe mittlerweile auch rausgefunden, wie man den Editor richtig
bedient. :) trotzdem sehr hilfreich das man jetzt ohne Änderung des
Inhaltes sofort die EEPROM Inhalt schreiebn kann. Sowas brauche ich
recht regelmäßig da ich ein Parameterimage im EEPROm ablege.


vielen Dank und ich hoffe das dies auch anderen Leuten geholfen hat.

cu
chris

>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

@Hagen
Mal 'ne einfache Frage, ich überlege schon seit Tagen, wofür man einen
Bootloader mit Verschlüsselung benötigt. Wer soll da wo Daten klauen und
vor allem wie?
Wäre froh, wenn Du mir das erklärst, damit ich wieder schlafen kann ;-)

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

Hallo Hagen!

Ist es möglich mehrere Controller gleichzeitig zu programmieren, Wenn
diese alle parallel an der Seriellen Schnittstelle hängen.

Wie soll das gehen, wenn eine Point-to-Point Kommunikation stattfindet?

Es geht hier um einen Bootloader und nicht etwa um ein
Programmiergerät...

Ja ich weiß.
Ich habe aber eine Anwendung wo ich bis zu 10 Controller parallel
betreiben will. Diese laufen alle mit der gleichen software. Ist nur
blöd immer jeden einzeln zu programmieren. Vielleicht hat jemand ja eine
Idee.

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

Ich hatte an etwas ähnliches gedacht.
Komfortabler wäre es doch wenn mann in der Windows Software die Anzahl
der Controller angeben könnte, damit die Windows Software dann je nach
Anzahl der Controller, nacheinander die Abfrage tätigt (also z.B.
BOOT1,BOOT2..) Alle Controller lauschen auf der RX Leitung und
aktivieren den TX Zweig zum Antworten nur wenn sie gefragt werden.
Danach deaktivieren sie diesen wieder. Wenn die Windows Software alle
Antworten gesammelt hat kann die Programmierung ja parallel laufen. Oder
ist solches nicht möglich?

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

Wenn man sich die Anforderung von James ansieht und daraus ableitet,
welcher Aufwand schon beim Programmieren der einzelnen Bootloader zu
betreiben wäre, oder den Aufwand, der seitens Hagen notwendig wäre, dann
würde ich mal ein back-to-the-roots anregen.
Warum nicht einfach ein Lötpad in der Nähe eines jeden Controllers und
diesen mal kurz mit einer Prüfspitze berühren. Parallel dazu einen
Taster, der die Betriebsspannung aus-einschaltet und fertig, oder
einfach den Pin vom Controller aus überwachen, so wie Hagen es oben
dargestellt hat.
Das geht doch ratz-fatz...

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

Hallo Hagen,

ich wollte jetzt mal auch Deine tollen Bootloader benutzen,
an einem ATMEGA162,
nachdem ich n halben Tag gesucht habe und endlich gefunden hab,
das ich ja n MAX232 davorgeschaltet habe und natürlich dann:

.equ  UartInvert    = 1

setzen muß, bin ich jetzt ein Stück weiter,
Aber leider funktioniert das Programmieren nicht:

18.04.08-18:02:02-958 > Switch to 2-Wire mode
18.04.08-18:02:03-083 > Device connected
18.04.08-18:02:04-833 > programming Device...
18.04.08-18:02:04-833 > execute compiled data
18.04.08-18:02:04-833 > selected options in compiled file:
18.04.08-18:02:04-833 > - programming FLASH
18.04.08-18:02:04-942 > CmdFlash.ResCheck()  Error: Verify failed

Ich hab schon verschiedene Baudraten und Timeouts probiert, daran schein
es nicht zu liegen.
Hast Du evtl. n Tip ?
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.,
Ne integrierte Lösung wär schon nicht schlecht,
muß ja kein ausgewachsenes Terminal sein, nur Ein- und Ausgaben.
Da ich meißtens ein CommandLineInterface in meine größeren AVRs
integriere wäre das echt hilfreich.

Danke und Grüße,
Micha

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

Hallo Hagen,

Danke für Deine schnelle und ausführliche Antwort,
da können wir ja noch einiges erwarten von Deinem Projekt, :-)
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, :-))

bzgl. meinem AVR, gottseidank hatte ich noch den ISP dran,
war ja noch am Bootloader-basteln,
also das Programmieren/Verify über ISP funktioniert stabil und
problemlos,
sowohl alles FFFF (kriegt man ja durch erase schnell hin :-)), als auch
alles 0000, oder die Applikation selbst, wie gesagt über ISP ist alles
ok.

still any ideas ?? :-))

Grüße,
Michae

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
i