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

Hagen schrieb:
> @Etumic:
>
> Die BTM-222 sind bischen schwer zu konfigurieren und kannst du
> sicherstellen das diese korrekt laufen ? Wenn ja wird es ein Timing
> Problem sein und da kann ich dir nur schlecht weiter helfen.
>
> Gruß Hagen

BTM-222 läuft auf jeden Fall korrekt.

Inzwischen habe ich hiermit 
http://forum.pololu.com/viewtopic.php?f=23&t=651
meinen eigenen Bootloader geschrieben.
Mein Bootloader ist nicht so funktionsreich (nur feste Baudrate, keine 
Verschlüsselung usw.), ist total simpel. Ich brauche aber auch nicht 
mehr.
Damit kann ich aber über Bluetooth oder sonstige langsame 
Funkverbindungen problemlos übertragen. Auf dem Microcontroller gibt es 
nämlich gar keine Timeouts mehr, wenn man im Bootmodus ist. Theoretisch 
kann man auch mit dem Terminal Zeichen für Zeichen an den Controller 
senden und flashen.

Gruß,
Etumic

Hallo Franz.

Nachdem ich die .dev Datei mit in das Verzeichnis der DLL kopiert
habe, funktioniert alles.

Gruss
Tim

Hi Leute,

zum Thema Multicontroller-System bin mittlerweile etwas weiter gekommen.
Also: Bootloader im Zweidraht-Mode, alle RXD-Pins sind über 1k 
Widerstände und alle TXD-Pins sind über 1k Widerstände zusammen 
verbunden. Über Max232 gehen alle an PC.
Jeder Controller erhält eine eindeutige BootSign:

1

BootSign: .db "BOOTLOAD01" ; alle weitern haben BOOTLOAD02,03,04 etc.

2

BootMsg:  .db "Controller No. 1 (2,3,4)"

3

BootInfo: .db SIGNATURE_001, SIGNATURE_002, BootVersion, BootPages

Zudem werden noch in der AVRotloader.ini die BootSigns bekant gemacht:

1

[Signs]

2

0=BOOTLOAD01

3

1=BOOTLOAD02

4

2=BOOTLOAD03

5

3=BOOTLOAD04

Problem ist, dass jeder Controller mit "frischem" Bootloader und ohne 
Firmware sofort auf die RXD Leitung reagiert und auf TXD antworted.
Geholfen hab ich mir damit, dass ich die Controller einzeln nacheinander 
mit Bootloader und gleich darauf Firmware geflashed hab. Wenn auf allen 
Controllern bereits eine Firmware läuft, dann antwortet nur der jeweils 
angesprochene nach dem Reset. So weit funktioniert es also.

Die Progammier-Sequenz aller vier Controller läuft jetzt 
folgendermassen:

1

1. Power-off

2

2. In AVRootloader.exe die jeweilige sign auswählen z.B. "Bootload01".

3

3. Connect to device klicken

4

4. Power-On (jetzt connected sich der jeweilige controller)

5

5. Program klicken

Diese Sequenz muss dann 4-mal wiederholt werden.
Daher hätte ich einen Wunsch:
Der Windows-App "AVRloader.exe" können zwar beim Aufruf Parameter 
übergeben werden, allerdings erfolgt der Flash-Vorgang nicht 
automatisch, mann muss trotzdem noch auf "Connect to device" und 
"Program" klicken.
Praktisch wäre es wenn die AVRloader.exe auch als reines Kommandozeilen 
Programm lauffähig wäre. Dann könnte man mit einem kleinen Batchfile die 
Progammierung aller 4 Controller automatisieren. (Ähnlich wie mit der 
"FBOOT.EXE" von Peter Dannegger).

1

:start

2

echo #----------------------------------------------------#

3

echo Power aus und einschalten (PORST)

4

fboot.exe /c1 /b9600 /pHk_I2Cm1.hex /iBOOTLO01

5

if errorlevel 1 goto error

6

echo Controller 1 erfolgreich geflashed

7

echo #----------------------------------------------------#

8

9

echo Power aus und einschalten (PORST)

10

fboot.exe /c1 /b9600 /pHk_I2Cm2.hex /iBOOTLO02

11

if errorlevel 1 goto error

12

echo Controller 2 erfolgreich geflashed

13

echo #----------------------------------------------------#

14

15

echo Power aus und einschalten (PORST)

16

fboot.exe /c1 /b9600 /pHk_I2Cm3.hex /iBOOTLO03

17

if errorlevel 1 goto error

18

echo Controller 3 erfolgreich geflashed

19

echo #----------------------------------------------------#

20

21

echo Power aus und einschalten (PORST)

22

fboot.exe /c1 /b9600 /pHk_I2Cm4.hex /iBOOTLO04

23

if errorlevel 1 goto error

24

echo Controller 4 erfolgreich geflashed

25

echo #----------------------------------------------------#

26

27

echo Fertig!

28

echo PORST machen und

29

echo beliebige Taste zum Beenden druecken

30

pause

31

goto ende

32

33

:error

34

echo das flashen war leider nicht erfolgreich!

35

echo mit beliebieger Taste neu starten

36

pause

37

goto start

38

39

:ende

Mit einem solch einfachem Batchfile wäre dann eine einfache 
Programmierung aller 4 Controller möglich. Es muss nur 4-mal 
hintereinander die Power-supply aus und eingeschalten werden.

@ Hagen: Siehst Du die Möglichkeit ein solches Kommandozeilen 
"AVRloader.exe" zur Verfügung zu stellen?

Gruesse an alle!

Mensch! Jetzt fällt es mir wie Schuppen von den Augen...!
Wer lesen kann ist klar im Vorteil. Hab ich doch glatt den Schalter -A 
überlesen...Jetzt klappts sogar mit Batchfile.
Dankeschön für den Tip! Mich zerreists fast vor Begeisterung für diesen 
genialen Bootloader. Danke an alle die das Möglich gemacht haben und 
insbesondere an den Hagen Re!

So gehts jetzt wunderbar:

1

AVRootloader.exe -Apc -PCOM1 -SBOOTSIGN01 -FFIRMWARE01.hex

Viel Grüsse!

@Andreas:

>Problem ist, dass jeder Controller mit "frischem" Bootloader und ohne
>Firmware sofort auf die RXD Leitung reagiert und auf TXD antworted.

Bist du dir wirklich sicher das der Bootloader schon antwortet obwohl er 
nicht die korrekte BootSign empfangen hat ?

Normalerweise sollte der Bootloader nur auf RXD lauschen bis er die 
korrekte "Loginsequenz" empfangen hat. Das sind par Nullen gefolgt von 
#13 der BootSign und dadrüber eine 16Bit CRC berechnet.

Vorher darf er nichts auf TXD machen. Allerdings arbeitest du im 2-Draht 
Modus und somit geht der Bootloader immer davon aus das er TXD auf 
definierte Pegel ziehen muß.

Physikalisch würde ich also alle RXDs parallel verschalten ohne 
Serienwiderstände. Es sei denn du möchtest auf Nummer sicher gehen und 
verhindern das die AVRs am RXD Pin gegeneinander treiben, was bei 
ausschließlicher Nutzung vom RXD als Input, eg. hochohmig, nicht 
passieren sollte. Ergo: diese Serienwiderstände in RXD sichern nur gegen 
Softwarefehler ab. TXD-Pins müssen mit Serienwiderstände geschützt 
werden. Man könnte den Bootloader so umschreiben das er TXD als 
Opendrain/-collector ansteuert und dann auf die Serienwiderstände 
verzichten.

Eine andere Möglichkeit ist es vom MAX232 die RXD/TXD über Widerstand zu 
verbinden und so ein 1-Wire mit invertierten Pegeln im Bootloader zu 
benutzen. Die Serienwiderstände für die 1-Wire Pins an den AVRs 
entfallen dann und du benötigst pro AVR nur noch einen Pin. Am MAX232 
also RX/TX mit zb. 2k verbinden. Vom TX des MAX gehts dann an die AVRs. 
Der 2k dient dann einerseits zur Verschaltung von TX/RX und andererseits 
als Pulldown für TX da wir ja intern den 1-Wire-Modus mit invertierten 
Pegeln benutzen.

Gruß Hagen

@Achim: bin schon am arbeiten es dauert aber noch par Tage wegens 
zeitmangels. Sorry das du noch warten musst.

Hm, schwierig. Mir fällt auf das du Timeout.Base mit 100ms ziemlich groß 
gewählt hast, gehst du über einen USB-RS232 Wandler ? Ansonsten mal 
Timeout.Flash von 25ms auf 50ms oder 100ms erhöhen.

Und was hat sich geändert so das es jetzt zumindest teilweise geht ?

Gruß Hagen

Ähm ? daniel == hige ?

Hallo Hagen,

gibt es eine moeglichkeit nach beenden des programms
AVRootloader.exe die RTS leitung auf High zu setzen ?
ich weis ist unueblich aber so kann das programmerkabel
angeschlossen bleiben. (1wire mit RTS auf reset)
ich rufe den bootloader in der kommandozeile auf und
da waehre sowas ganz praktisch, oder gibts das schon
und i habs uebersehen ?

vlg
Charly

Nee gibts nicht und würde auch nicht gehen. Die EXE muß die COM 
Schnittstelle freigeben und setzt diese dann freundlicher Weise auf 
ihren Zustand zurück den die EXE beim Öffnen vorgefunden hat. Das nennt 
sich guter Ton und Rücksichtnahme auf andere Softwareentwickler ;) Davon 
abgesehen habe ich die EXE so programmiert das sie die COM Schnittstelle 
nur dann öffnet wenn sie benötigt wird und ansonsten anderen Programmen 
zur Verfügung stellt.

Ich denke auch das dein Problem anders lösbar sein könnte.

1.) verzichte auf RTS and Reset
2.) benutze nur den 1-Wire-Pin am AVR exklusiv für den Bootloader
3.) überwache in alle deinen Programmen diesen Pin auf Aktivität und 
wechsel per Watchdog Timeout in den Bootloader, heist führe einen 
"Software-Reset" durch.

Konzeptionell bedeutet dies zwar das deine Anwendungsprogramme ein Teil 
der Funktionalität des Bootloaders werden und du damit immer ein wenig 
an Source extra pflegen musst, aber ich habe die Erfahrung gemacht das 
das mit bischen Routine wirklich unproblematisch und am cleversten ist. 
Und natürlich benötigst du dann nur noch einen Pin am AVR.

Gruß Hagen

@Daniel:

Kannst du den USB-RS232 umgehen und eine echte RS232 verwenden ?

Die Fehlermeldungen sind sporadisch und immer wenn mir solche Probleme 
gemeldet wurden lag es an Übertragungsfehlern (zb. USB Wandler VCC nicht 
sauber) oder an den Treibern für den USB-RS232-Wandler.

Gruß Hagen

Zb. hier

>18.06.10-01:16:01-881 > Cmd.SetBuffer.ResCheck(2)  Error: 00 operation
>failed

Empfängt die EXE einen Fehlercode 00 den es als solches garnicht im 
definierten Protokoll gibt.

Gruß Hagen

@Daniel: ließ mal ab hier 
Beitrag "gleiche Fehler" die Beiträge von Jan.

Gruß Hagen

Hallo Hagen,

also ein Test mit einem anderen Board + µC ergab keinerlei Probleme. 
Skeptisch wie ich war hab ich mal auf meinen luftverdrahteten RS232 
Pegelwandler getippt.
Da ich eh ein wenig mit dem Ding unzufrieden war hab ich mir jetzt ein 
paar Stunden Zeit genommen und einen neuen entworfen, geätzt, bestückt 
und getestet (siehe Anhang, speziell für die Heimätzer mit 
Tonermethode).

Fazit: geht immer noch nicht!

Also nochmal den anderen µC mit anderem Wandler ran - zack, geht. µC 
getauscht, neuer Wandler dran, geht auch. Also musste es was mit dem 
anderen µC zu tun haben. Und letztendlich Hand an den Kopf hau wars 
mir klar.

16MHz Quarz und CKOPT nicht gesetzt! Aahh... :-)


Naja, jetzt letztendlich läuft alles 1A. Und immerhin hab ich jetzt 
einen funktionierenden 2-Kanal-RS232-TTL-Pegelwandler mit optionalem 
RTS/CTS.


Gruß und Dank
Daniel

@Hagen: Hauptsache letztendlich siegt Köpfchen über Frust. :)
Eine Frage... weißt du wie sich die Implementierung eines Bootloaders in 
C größenmäßig zur Implementierung in Assembler verhält?
Gruß
Daniel

Hallo Hagen,
ich will mit der Frage sicher nicht die alte Diskussion vom Zaun 
brechen. Beide Sprachen haben ihre Daseinsberechtigung.

Worüber ich mir allerdings Gedanken mache, ist, inwiefern ein ASM 
Projekt mit einem in C geschriebenen Projekt erweitert werden kann.

Ich kenne zwar Projekte in einzelne Funktionen/teile dank Assembler auf 
Geschwindigkeit oder Größe optimiert wurden, jedoch kenn ich es bisher 
nicht, dass eine handgestrickte ASM Software einige in C codierte 
Routinen einbindet. Ich kenne zwar Assembler aber da ich nie damit 
arbeite kann ich mir auch keinen Eindruck davon machen, ob das möglich 
wäre. Wahrscheinlich müsste man alle "notwendigen" Register vor dem 
Aufruf der C-Routine wegsichern, quasi eine Stack-Implementierung, dann 
den assemblierten C-Code aufrufen, und später die Register rücksichern.


Gruß,
Daniel

Moin moin Hagen & Co.

nachdem sich Hagen 'weigert' RTS auf High zu lassen beim
beenden des Bootloaders damit der AVR weiter laeuft habe
ich nach Lösungen gesucht und gefunden, siehe Schaltplan

i hoffe der ein oder andere kann es gebrauchen...

vielen Dank nochmals an Hagen fuer den super Bootloader


vlg
Charly

@Charly:

>nachdem sich Hagen 'weigert' RTS auf High zu lassen beim beenden des
>Bootloaders

ich weigere mich ja nicht, es ist technisch nicht sauber oder sogar 
möglich weil das Betriebsystem nicht mitspielt. Wird der Bootloader 
beendet so werden auch alle genutzten Resourcen wieder freigegeben. 
Würde ich das nicht explizit machen dann würde spätestens das OS dies 
für mich machen. Danach ist die COM Schnittstelle wieder frei für andere 
Software und ich kann ja schlecht deren Funktion beeinflussen.

Gruß Hagen

@Hagen

das 'weigern' war nicht als vorwurf gemeint, ich hatte deine Argumente
verstanden und deswegen nicht weiter nachgefragt und nach einer anderen
Loesung gesucht, und gefunden.
Ich verwende den Bootloader per Komandozeile und so ist es halt
praktisch wenn der Bootloader einfach alles uebernimmt und ich in
meiner Soft es nicht beruecksichtigen muss, halt was fuer 'Faulpelze'
wie ich ;)

vlg
Charly

Hi,
nach dem mir bei PeDas fastboot wichtige Features fehlen bin ich auf 
AVRootloader gestoßen.

Von der Featureliste und Konfigurierbarkeit ist der ja ein Traum.

Leider bekomme ich ihn nicht zum laufen.

will ihn auf einem mega168 mit 16Mhz Quarz bekommen.
ich habe ein paar configs geändert, ihn übersetzt, die Größe 
eingetragen, noch mal übersetzt geflasht und die fuses gesetzt (e/h/l 
0x04/0xDF/0xF7)

(angepasstes Projekt im Anhang)

allerdings kann ich nicht mit dem Bootloader verbinden.

In dem Tool habe ich die Baudrate eingestellt und connect geklickt, dann 
am Target ein Reset ausgeführt.
Dann versucht er ewig eine Verbindung herzustellen.

Ließ dir mal den Thread hier durch.

1.) in AVRootloader.ini [Timeouts] Options=2 setzen um Debug Infos 
anzuzeigen
2.) einen Connect probieren
3.) den Output in der Protokollpage hier posten

Gruß Hagen

Hagen Re schrieb:
> Ließ dir mal den Thread hier durch.
ich habs mit ein paar Suchworten probiert.
aber ein 2 Jahre, 6 Sofftwareversionen und 600-Beiträge alten Thread 
komplett durchzuarbeiten bringt halt meistens auch nicht so viel, da 
auch eine Menge veraltete Infos drinstehen.

Das einfachste wäre, wenn die relevantesten Infos im Artikel 
zusammengetragen wären.

>
> 1.) in AVRootloader.ini [Timeouts] Options=2 setzen um Debug Infos
> anzuzeigen
> 2.) einen Connect probieren
> 3.) den Output in der Protokollpage hier posten

Am Output ändert das irgendwie gar nix.

es ist weiterhin nur folgendes zu lesen:

11.07.10-07:54:20-093 > Connecting on port COM4...
zwischendurch habe ich mehrere Male am Target die Stromzufuhr 
unterbrochen
bis ich dann irgendwann selbst auf abort klicke
11.07.10-07:55:27-656 > aborted by User

@Vlad

>Ließ dir mal den Thread hier durch.

Damit meinte ich das deine Infos einfach zu wenige sind um dir helfen zu 
können. Also fange ich nochmal an:

Wie sieht deine Hardware aus ?

Laut deiner Konfiguration des Bootloaders gehe ich davon aus das du
- 19200 Baudrate hast
- das du keinen RS232 Pegelwandler benutzt
- das du 2-Wire RS232 benutzt
- das dein AVR mit 16MHz läuft und auch die Fuses entsprechend gesetzt 
wurden

Da das eine ziemlich ungewöhnliche Konfguration ist gehe ich davon aus 
das du einen Pegelwandler benutzt.

Setze:

.equ UseAutobaud   = 1
.equ UseUartInvert = 1

UseAutoBaud nimmt dir nicht viel mehr an FLASH weg, dafür macht es den 
Bootloader unabhängig von einer festen Baudrate und unabhängig von 
falschen Quarzen und falschen Quarzfusebits. UseAutoBaud=0 ist also nur 
für Spezialanwendungen, bei denen der User weiß was er tut, interessant.

UseUartInvert muß 1 sein wenn mit einem Pegelwandler wie den MAX232 oä. 
gearbeitet wird.

In meinem letzten Posting sagte ich: Poste hier dein Protokoll Auszug, 
dann kann ICH mehr erkennen. Wo ist er ?

Ändere auf [Timeout] Options=1 und teste dann nochmal.

Gruß Hagen

@Achim: ja ich weiß :| und ich arbeite dran. Da ich heute nicht 
sonderlich viel zu tun habe, außer das ich mal ausspannen wollte, sehe 
ich mal zu deine Fragen zu beantorten. Schicke dir dann eine PN.

Gruß Hagen

Na dann spann mal erst aus!
PN gerne, wenn Du soweit bist.

Gruß
Achim

@Achim: du bist ja garnicht angemeldet, PN fällt flach.

"AVRootloader"
$06 (Bottloaderversion?)
$26 (??)

Das ist der File Format Identifier. String AVRootloader gefolgt von 1 
Byte Haupotversionsnummer -> 6. Am Ende $26 = EOF = End Of File. Ein 
ASCII Text Editor/Viewer zeigt nur bis hierhin Daten an.


"ACYInfo"
$20 (Leerzeichen?)
"1.0.0.0" (Version Software)
$00 (Terminierung?)

Ein benutzerdefeinierbarer Info-String über diese Datei. ACYInfo wird im 
GUI durch den User eingetragen. Wird Versioning benutzt so steht mit 
Leerzeichen getrennt die eingestellte Version aus dem GUI mit in diesem 
String. Null terminiert.

$1E$xx$xx (Device Sign)
$00 (??)
$0F (??)
$06 (??)
$00 (??)
$2F (??)

- 4 Bytes Device Signature
- 1 Byte Anzahl der FLASH Pages die der Bootloader benutzt
- 1 Byte Hauptversion des Bootloaders
- 2 Bytes Flags, bitkodierte Informationen über die Fähigkeiten des 
Bootloaders, zb. Verschlüsselung usw.

Die Infos sind unverschlüsselt und im Grunde identisch mit dem was der 
Bootloader im AVR bei einem Connect zurück meldet. Das GUI benutzt beim 
flshen einer ACY diese Infos und vergleicht sie mit denjenigen die sie 
vom AVR geliefert bekommt. Nur wenn diese übereinstimmen wird das GUI 
das ACY flashen. Dh. gleicher AVR, Bootloader usw. mit der die ACY 
erzeugt wurde und der aktuell programmiert werden soll.

> Ab hier Befehle $FE $FE $XX $XX... Datenblöcke und Kommandos

Korrekt.

>2. das Kommando $FE hab ich nicht so ganz klar. Dahinter kommt $00 wenn
>ich ins EEProm unverschlüsselt schreibe. In der ACY Datei aber $FE mit
>24 Byte irgendwas und danach $FF. Also "$FE $?? (highbyte Size) (lowbyte
>Size).

Bei Verschlüsselten Daten muß der AVR erstmal die Entschlüsselung 
initialisieren. Dazu wird ein verschlüsseltes Initialisierungs-Packet 
benutzt. Dieses Packet ist entweder 16 Nutzbytes oder 24 Bytes groß.

- 8 Bytes Zufall, quasi ein innerer zufälliger Initialisierungvektor = 
IV. Nirmalerweise überträgt man den in vielen Verfahren unverschlüsselt. 
Ich bevorzug dies verschlüsselte Variante, der Rest ist aus 
kryptographischer Sicht identisch zu den gewohnten Verfahren

Nun unterscheidet es sich jenachdem ob man Versioning benutzt oder 
nicht.

Ohne Versioning:
- 2 Bytes Signature des AVRs
- 1 Byte Bootloader Version
- 1 Byte Anzahl FLASH Pages des Bootloaders
- 4 Bytes, die ersten 4 Bytes des Schlüssels

Mit Versioning:
- 4 Bytes weiterer Zufall, ergibt 12 Bytes Zufallsblock am Anfang des 
Packetes
- 4 Bytes die Versionsnummer aber maskiert zur Überprüfung
- ab hier wieder gleich zu oben
- 2 Bytes Signature des AVRs
- 1 Byte Bootloader Version
- 1 Byte Anzahl FLASH Pages des Bootloaders
- 4 Bytes, die ersten 4 Bytes des Schlüssels

Dieser 16/24 Bytes Block wird verschlüsselt übertragen. Kommando

$FE$FE, 2 Bytes LÄnge der nachfoldenenden Daten, 16 Bytes Daten

Da der Verschlüsselungalgo., sprich der modifizierte 
Doppel-CBC-Feedback-Cipher-Mode nicht zurückgesetzt wird heist dies das 
sich die verschlüsselten 8/12 Bytes Zufallsbytes komplett durch die 
ganzen verschlüsselten Datenblöcke fortpflanzen. Würde man also die 
exakt gleiche HEX Datei mit exakt gleichen Info wie Passwort usw. 
mehrfach in ACY Dateien compilieren so würde sich denoch jedesmal ein 
komplett anderes verschlüsseltes Resulat ergeben. Das verhindert eine 
ganze Reihe von kryptologischen Angriffen.

Nachdem der AVR nun dieses 16/24 Bytes große verschlüsselte Packet 
empfangen hat wird er es erstmal entschlüsseln. Damit wird er sich, eg. 
sein internes Feedback Register auch mit den richtigen Zufallswerten 
synchronisieren. Er vergleicht erstmal die letzten 4 Bytes des 
entschlüsselten Datenblockes mit den ersten 4 Bytes seinen Passwortes. 
Sollten diese nicht identisch sein so wurde entweder mit falschem 
Passwort verschlüsselt, der AVR benutzt ein falsches Passwort zur 
Entschlüsselung, der Datenstrom wurde falsch übertragen (wir nutzten 
extern nur eine 16 Bit CRC) mit dem XTEA nutzen wir eine 64 Bit CRC die 
aber auf 32Bit truncated ist (unser 4 Bytes Vergleich mit dem Passwort).
Dieser 4 Bytes Vergleich erfolgt immer, egal ob Init-Packet oder später 
die einzelnen verschlüsselten Datenpackete empfangen wurden.
Beim Init-Packet vergleicht der AVR nun die Signature, Version, 
BootPages mit seinen eigenen. Stimmen sie nicht überein so gibts wieder 
einen Fehler. Bei jedem Fehler den die Entschlüsselung meldet wird jeder 
Befehl der verschlüsselt sein kann gesperrt. Dh. nur mit einem korrekt 
empfangenen und entschlüsselten Init-Packet arbeitet die interne 
Bootloader-FSM weiter ansonsten blockiert sie.

Wurde mit Versioning gearbeitet so lädt nun der AVR die entschlüsslte 
Versionsmaske und vergleicht sie mit der im AVR gespeicherten Version. 
Je nach Maskeneinstellung führt dies dazu das der AVR zb. erkennt das 
schon eine neuere Version installliert wurde und verhindert dann 
wiederum durch einne Fehlercode das man auf Downgrade machen kann.

So damit wäre die Initialisierung der Entschlüsselung im AVR 
abgeschlossen.
Da alle wichtigen Infos auch im ACY verschlüsselt gespeichert wurden, 
sie nur vom Erzeuger der ACY und des AVR ver/entschlüsselt werden 
können, ist das ziemlich sicher. Auch wenn man die unverschlüsselten 
Daten im Header der ACY Datei manipulieren würde so würde man nur das 
GUI austricksen damit aber nicht den AVR Bootloader.

Wenn also mit Verschlüssleung gearbeitet wird so überprüft der AVR 
selber ob die ACY Daten für ihn die richtigen sind.
Wird ohne Verschlüsselung gearbeitet so überprüft das das GUI.

Sonstige Kommandos im ACY File:

- CmdSetAddr: $FF, 3 Bytes Addresse, setzt die EEPROM,FLASH,SRAM 
Schreib/Leseadresse

- CmdWriteBuffer (unverschlüsselt): $FE00, 2 Bytes Datengröße, Daten
- CmdWriteBuffer (unverschlüsselt): $FE01, 2 Bytes Datengröße, Daten, 
dieses Kommando schreibt die empfangenen Daten in den SRAM an die mit 
CmdSetAddr übergebenen Speicheradresse. Siehe unten.
- CmdWriteBuffer (verschlüsselt): $FEFF, 2 Bytes Datengröße immer durch 
8 teilbar, Daten
- CmdWriteBuffer (verschlüsselt Init): $FEFE, 2 Bytes Datengröße 
(16/24), Daten

- CmdWriteFlash: $01, 1 Byte Wiederholungszähler, diese Kommando 
schreibt die mit CmdWriteBuffer empfangenen und eventl. entschlüsselten 
Daten an die mit CmdSetAddr angegebenen FLASH Addresse. Dabei werden 
soviele Bytes geschrieben wie mit CmdWriteBuffer empfangen wurden. Der 
Wiederholungszähler gibt an wie oft diese Operation nacheinander 
wiederholt wird, wobei aber der internen Addresszähler immer weiter 
inkrementiert wird. Man könnte also mit CmdWriteBuffer() nur das Zeichen 
$AA senden. Dann mit $01 $80 dieses Zeichen 128 mal in den FLASH 
schriben lassen, also einen Buffer der aus 128 mal $AA bestünde. Somit 
unterstützt das Bootloader Protokoll/Dateiformat etc.pp. schon eine 
primitve Komprimierung die redundante Daten entfernen kann.

- CmdEraseFlash: $02, 1 Byte Page Anzahl. Löscht die Flash Pages ab 
CmdSetAddr Addresse.

- CmdVerifyFlash: $03, 1 Byte Page Anzahl. Die mit CmdSetBuffer 
empfangenen/entschlüsselten Daten werden mit den Daten im FLASH ab 
Addresse mit CmdSetAddr vergliche

- CmdWriteEEPROM: $05, 1 Byte Wiederholungszähler, siehe CmdWriteFlash

Das sind die Kommandos die in einem ACY vorkommen dürfen. Der Bootloader 
versteht zusätzlich noch:

- CmdKeepAlive: $FD, $00, diese Kommando ist defakto garnicht 
implementiert. Das GUI sendet es im Interval < 2 Sekunden ab, der 
Bootloader empfängt es als illegales Kommando, sendet Fehler zurück, 
setzt aber auch intern seinen WDT zurück bei jedem 
Kommando/Kommunikation. Somit erzielen wir zwei Vorteile: der AVR 
Bootloader startet autom. die eigene Anwendung wenn sich das GUI nicht 
mehr meldet. Das GUI trennt autom. eine Verbindung wenn der AVR sich 
nicht mehr meldet.

- CmdReadEEPROM: $04, 1 Byte Anzahl Bytes, lese aus EEPROM

- CmdReadSRAM: $06, 1 Byte Anzahl Bytes, lese den SRAM

- CmdWriteSRAM: wird über CmdWriteBuffer() simuliert. Man setzt mit 
CmdSetAddr() erstmal die Startaddresse und mit CmdWriteBuffer() werden 
dann diese Daten ab dieser Address gespeichert. Dh. ab Address 0x0000 
bis 0x001F liegt das Registerfile. Man überschreibt somit die internen 
Register des AVRs. Danach kommen die Ports usw. dh. man überschrebt die 
Ports usw. Danach kommt der normale SRAM in den man schreiben kann.

Mit CmdRead/WriteSRAM: kann man also aus dem GUI heraus den AVR komplett 
steuern. Das ist so wie ein kleiner Mini-Debugger. Deshalb gilt: 
nieamls UseSRAM=1 setzen wenn man Kryptographie benutzt da das eine 
Hintertüt für einen Angreifer öffnen könnte.

Im Gegensatz zu den Kommandos in der ACY Datei werden alle Kommanods und 
Daten während der Kommunikation von/zum AVR mit einer 16 Bit CRC 
abgesichert. Es gibt also 2 oder 4 Bytes Kommandos. Danach kommen 2 
Bytes CRC üder diese Kommandos. Wenn Daten folgen dann kommen jetzt die 
Daten und darüber am Ende wieder 2 Bytes für die 16 Bit CRC. Das ist 
auch beim Lesen vom SRAM/EEPROM so.

Werden verschlüsselte Datenblöcke gesendet, also nachdem man die 
Initialisierung hinter sich hat so sind das immer glatt durch 8 teilbare 
Packetlängen. Es werden die Daten verschlüsselt gesendet mit einem 8 
Bytes abschließenden Datenpacket. Dieses Datenpacket ist so aufgebaut
- 3 Bytes Addressfeld, das ist die Addressinformation die man 
normalerweise mit CmdSetAddr sendet. Bei verschlüsselter Kommunikation 
steht diese Addresse natürlich hier in verschlüsselter Form. 
Manipulationen durch umsortieren der Addressen also ausgeschlossen
- 1 Bytes Daten-Längen-Korrektur-Byte. Alle verschl. Datenpackete müssen 
8 Bytes lang sein. Sollten Daten verschl. werden die nicht ein 
mehrfaches von 8 Bytes lang sind so werden diese mit Zufallsdaten 
aufgefüllt so das das Packet ein Mehrfaches von 8 Bytes lang wird. Die 
Anzahl der dafür nötigen Zufallsbytes kann von 1 bis 7 gehen und steht 
in diesem Datenfeld. Nach empfang aller Datenpackete und deren 
Entschlüsselung wird das interne Daten-Längen-Register durch Subtraktion 
mit diesem Korrekturbyte korregiert.
- 4 Bytes Prüfsumme = ersten 4 Bytes vom Passwort

Der AVR empfängt also das letzte 8 Bytes Packet, entschlüsselt es und 
vergleicht wiederum die 4 Bytes Prüfsumme. Gibts einen Fehler gilt das 
oben schon gesagte. Ansonsten nimmt der die Addressinfos und speichert 
die in sein internes bis zu 3 Bytes großes Addressregister.

So das wäre im Grunde das komplette Protokoll.

Gruß Hagen

PS: Ich habe nicht nochmal Korreturgelesen, sorry, Schreibfehler gehören 
euch

>@Achim: du bist ja garnicht angemeldet, PN fällt flach.

Jetzt habe ichs schon gepostet, hab dein Posting nicht gesehen ;)

Hagen Re schrieb:
> @Vlad
>
>>Ließ dir mal den Thread hier durch.
>
> Damit meinte ich das deine Infos einfach zu wenige sind um dir helfen zu
> können. Also fange ich nochmal an:
>
> Wie sieht deine Hardware aus ?
>
> Laut deiner Konfiguration des Bootloaders gehe ich davon aus das du
> - 19200 Baudrate hast
ja, die hatte ich runtergesetzt um Verbindungsprobleme auszuschließen
> - das du keinen RS232 Pegelwandler benutzt
richtig
> - das du 2-Wire RS232 benutzt
2-Wire UART um genau zu sein (USB-UART-Adapter)
> - das dein AVR mit 16MHz läuft und auch die Fuses entsprechend gesetzt
> wurden
jep, die passen.
wenn ich ein eigenes Programm draufflashe klappt die Kommunikation mit 
19200Baud reibungslos

>
> Da das eine ziemlich ungewöhnliche Konfguration ist gehe ich davon aus
> das du einen Pegelwandler benutzt.
nein, es ist wirklich eine UART
wieso ungewöhnlich?
es ist ein atmega168 mit 16Mhz in Minimalbeschaltung (reset, pullup, 
quarz+C, Abblock-C)


>
> Setze:
>
> .equ UseAutobaud   = 1
habe ich auch schon probiert.
> .equ UseUartInvert = 1
>
> UseAutoBaud nimmt dir nicht viel mehr an FLASH weg, dafür macht es den
> Bootloader unabhängig von einer festen Baudrate und unabhängig von
> falschen Quarzen und falschen Quarzfusebits. UseAutoBaud=0 ist also nur
> für Spezialanwendungen, bei denen der User weiß was er tut, interessant.
die Autobaudrate macht den Unterschied zwischen 512Byte bootloader und 
1k, deswegen wollte ich die ausschalten.
Wie gesagt, hatte ich es aber auch schon mit probiert - mit den selben 
Symptomen.

>
> UseUartInvert muß 1 sein wenn mit einem Pegelwandler wie den MAX232 oä.
> gearbeitet wird.
>
> In meinem letzten Posting sagte ich: Poste hier dein Protokoll Auszug,
> dann kann ICH mehr erkennen. Wo ist er ?

mit Protokoll meinst du doch den Protocol-Tab, oder?
da tauchen wirklich nur diese beinde Zeilen auf.

>
> Ändere auf [Timeout] Options=1 und teste dann nochmal.

ok, jetzt ist das ganze etwas gesprächiger:

1

11.07.10-12:09:17-218 > Connecting on port COM4...

2

11.07.10-12:09:17-218 > Timeout.Connect       = 50 ms

3

11.07.10-12:09:17-218 > Timeout.Base          = 50 ms

4

11.07.10-12:09:17-218 > Timeout.Erase         = 10 ms

5

11.07.10-12:09:17-218 > Timeout.Flash         = 15 ms

6

11.07.10-12:09:17-218 > Timeout.Eeprom        = 10 ms

7

11.07.10-12:09:17-218 > Timeout.Buffer        = 1 ms

8

11.07.10-12:09:17-218 > Timeout.AppCmd        = 0 ms

9

11.07.10-12:09:17-218 > Timeout.KeepAlive     = 250 ms

10

11.07.10-12:09:17-218 > Timeout.RTSPulse      = 0

11

11.07.10-12:09:17-218 > Timeout.RTSInterval   = 0

12

11.07.10-12:09:17-218 > Timeout.ConnectTrials = -1

13

11.07.10-12:09:17-218 > Timeout.MaxPacketSize = 0

14

11.07.10-12:09:17-234 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

15

11.07.10-12:09:17-437 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

16

11.07.10-12:09:17-640 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

17

[...  (bis auf die Zeiten immer das gleiche)]

18

11.07.10-12:09:28-421 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

19

11.07.10-12:09:28-625 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

20

11.07.10-12:09:28-718 > aborted by User

Und nochmal danke für die Zeit, die du dir für die Erklärungen nimmst.

Gruß,
Vlad

Edit:
Im Anhang mal die Fuses-Eisntellungen.
Die sollten aber eigentlich passen.

Suppi!!! Danke herzlichst Hagen!

Hagen Re schrieb:
> Jetzt habe ichs schon gepostet, hab dein Posting nicht gesehen ;)

Ich kopiers mir ;-)

Mensch Kommando 0x00 vergsssen:

- CmdRestart: 0x0000, startet den Bootloader neu
- CmdStartApp: 0x00??, startet die geflashte Anwendung

Ist ein 2 Bytes Code. CmdRestart -> 0x0000 würde mit 2 Bytes CRC also 
0x00 0x00 0x00 0x00 sein, da 16 Bit CRC über 0x0000 = 0x0000 ist.
Somit werden alle sich wiederholenden 0x00 Bytes Sequenzen autom. als 
Soft-Reset des Bootloaders interpretiert. Der Bootloader startet dann 
normalerweise wieder seine AutoBaud Detektion, ermittelt Baudrate neu, 
prüft BootSign erneut und sendet bei Erfolg seine Informationen wie 
BootInfo erneut zum GUI. Somit erklärt sich auch warum man kein extra 
Kommando für die Ermittlung der Fähigkeiten des Bootloaders benötigt, 
also Ermitteln von FLASH/EEPROM/Version usw.
Zudem hat man so, auch bei falschen Baudraten einen Weg wie der 
Bootloader aus seiner FSM wieder neu gestartet werden kann. Die 
Wahscheinlichkeit ist groß das bei falscher Baudrate und dem Senden von 
wiederholten 0x00 der Bootloader das denoch als CmdRestart Kommando 
erkennen kann und somit neu startet, neu Baudrate usw. usw. wie oben 
schonmal erklärt.

Letzendlich dient das und der WDT (CmdKeepAlive), UseResetDelay=1 usw. 
alles dazu den Bootloader äußerst stabil zu machen.

Wird als 2. Byte <> 0x00 benutzt so wird die Applikation gestartet.

Gruß Hagen

>> - das du keinen RS232 Pegelwandler benutzt
>richtig
>> - das du 2-Wire RS232 benutzt
>2-Wire UART um genau zu sein (USB-UART-Adapter)

Gut dann benutzt du also einen RS232-Pegelwandler, nicht einen MAX232 
aber einen USB-RS232.

Es muß UseUartInvert=1 gesetzt werden.

Aus dem Protokoll erkennt man das nichts empfangen wird. Überprüfe
1.) USB Treiber
2.) virtuellen COM4 Port, oder benutze mal AUTO
3.) sind RX/TX an PD0 und PD1 richtig ?
4.) Oszi an RX/TX dran und schauen
5.) Debug-Trick

- UseRS485=1 setzen
- DE_PORT und DE setzen auf einen freien Pin oder auf einen an dem eine 
LED dran ist
- UseRS485Invert=0 oder 1 setzen je nach LED Polarität

Wenn der AVR nun korrekte Daten empfangen hat wird der den in DE_PORT/DE 
konfigurierten Pin, deine LED beim Senden ein/ausschalten. Du siehst 
also wenn die LED flackert das der Bootloader auf den gesendeten Connect 
Versuch reagieren möchte.

6.) BootSign in GUI und AVRootloader.asm identisch ? In ARRootloader.asm 
am Ende des Sources. Denke das ist bei dir der Fall, BOOT im ASM und 
BOOT im Protokoll.

7.) verbinde mal RX/TX des USB-RS232 miteinander. Dann schaue dir 
nochmal das Protokoll beim Connect an. Du solltest dort den gesendeten 
Ident als empfangenen sehen. Wenn nicht, USB-RS232 Scheiße, dort Fehler 
suchen...

Gruß Hagen

>die Autobaudrate macht den Unterschied zwischen 512Byte bootloader und
>1k, deswegen wollte ich die ausschalten.

Darum kümmern wir uns später, jetzt erstmal UseAutoBaud=1 setzen, bis es 
bei dir funktioniert.

Deine Fuses sehen erstmal richtig aus, auch wenn ich die Software nicht 
kenne. Im Compiler-Message-Window vom AVRStudio siehst du nach der 
Compilation welche Fuses (BOOTSZ) du setzen musst.

Gruß Hagen

Hagen Re schrieb:
>>> - das du keinen RS232 Pegelwandler benutzt
>>richtig
>>> - das du 2-Wire RS232 benutzt
>>2-Wire UART um genau zu sein (USB-UART-Adapter)
>
> Gut dann benutzt du also einen RS232-Pegelwandler, nicht einen MAX232
> aber einen USB-RS232.
nein, gar kein RS232. einen reinen USB-UART
um genau zu sein:
http://www.recursion.jp/avrcdc/

>
> Es muß UseUartInvert=1 gesetzt werden.
>
> Aus dem Protokoll erkennt man das nichts empfangen wird. Überprüfe
> 1.) USB Treiber
> 2.) virtuellen COM4 Port, oder benutze mal AUTO
beides funktioniert. Wenn ich den Adapter kurzschließe, bekomme in einem 
Terminalprogramm das echo

> 3.) sind RX/TX an PD0 und PD1 richtig ?
Ich habs an die Hardware-UART-Pins angeshlossen (PD0, PD1).
> 4.) Oszi an RX/TX dran und schauen
hab kein Oszi
> 5.) Debug-Trick
>
> - UseRS485=1 setzen
> - DE_PORT und DE setzen auf einen freien Pin oder auf einen an dem eine
> LED dran ist
> - UseRS485Invert=0 oder 1 setzen je nach LED Polarität
>
> Wenn der AVR nun korrekte Daten empfangen hat wird der den in DE_PORT/DE
> konfigurierten Pin, deine LED beim Senden ein/ausschalten. Du siehst
> also wenn die LED flackert das der Bootloader auf den gesendeten Connect
> Versuch reagieren möchte.
>
> 6.) BootSign in GUI und AVRootloader.asm identisch ? In ARRootloader.asm
> am Ende des Sources. Denke das ist bei dir der Fall, BOOT im ASM und
> BOOT im Protokoll.
ja, die sind identisch
>
> 7.) verbinde mal RX/TX des USB-RS232 miteinander. Dann schaue dir
> nochmal das Protokoll beim Connect an. Du solltest dort den gesendeten
> Ident als empfangenen sehen. Wenn nicht, USB-RS232 Scheiße, dort Fehler
> suchen...
>
> Gruß Hagen


wenn ich RX/TX an meinem UART-Adapter kurzschliße und das Tool benutze, 
kommt folgendes Log:

1

11.07.10-13:44:49-484 > Connecting on port COM4...

2

11.07.10-13:44:49-484 > Timeout.Connect       = 50 ms

3

11.07.10-13:44:49-484 > Timeout.Base          = 50 ms

4

11.07.10-13:44:49-484 > Timeout.Erase         = 10 ms

5

11.07.10-13:44:49-484 > Timeout.Flash         = 15 ms

6

11.07.10-13:44:49-484 > Timeout.Eeprom        = 10 ms

7

11.07.10-13:44:49-484 > Timeout.Buffer        = 1 ms

8

11.07.10-13:44:49-484 > Timeout.AppCmd        = 0 ms

9

11.07.10-13:44:49-484 > Timeout.KeepAlive     = 250 ms

10

11.07.10-13:44:49-484 > Timeout.RTSPulse      = 0

11

11.07.10-13:44:49-484 > Timeout.RTSInterval   = 0

12

11.07.10-13:44:49-484 > Timeout.ConnectTrials = -1

13

11.07.10-13:44:49-484 > Timeout.MaxPacketSize = 0

14

11.07.10-13:44:49-484 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

15

11.07.10-13:44:49-703 > received data   $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 10 60

16

11.07.10-13:44:49-703 > Switch to 1-Wire mode

17

11.07.10-13:44:49-703 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

18

11.07.10-13:44:49-921 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

19

11.07.10-13:44:50-125 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

20

11.07.10-13:44:50-328 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

21

11.07.10-13:44:50-484 > aborted by User

Merkwürdig finde ich, dass da noch ein 10 60 dahinter kommt (\n>)
Aber da er in den 1-Wire-Modus wechselt scheint das normal zu sein.
Das sollte für ein Funktionieren der Schnittstelle sprechen, oder?

Hagen Re schrieb:
> Deine Fuses sehen erstmal richtig aus, auch wenn ich die Software nicht
> kenne. Im Compiler-Message-Window vom AVRStudio siehst du nach der
> Compilation welche Fuses (BOOTSZ) du setzen musst.
jep, das habe ich gesehen und gemacht.
Das Tool ist der AVR8-Burn-O-Mat, das ist eine JAVA-GUI für avrdude.

Edit:

Ach so, die Sache mit dem RS485 debug-Trick:
da passiert überhaupt nix, egal, ob invert, oder nicht (die LED ist über 
den Pin nach GND geschalten)

Ich habe das gefühl, dass die ich entweder beim Bauen, oder beim Flashen 
irgendwas falsch mache.

Hast du einen kommerziellen USB-RS232-Wandler oder vielleicht sogar 
einen echten COM Port an deinem Rechner ? Wenn ja probier es mal damit 
aus, einfach um Fehler in der exotischen HW ausschließen zu können. Sehr 
oft, ja sogar am häufigsten lag es nämlich bisher immer an der SW oder 
HW der USB-RS232 Wandler.

>Merkwürdig finde ich, dass da noch ein 10 60 dahinter kommt (\n>)

Ist die 16 Bit CRC Prüfsumme, die sichtbar wird beim Empfangen.

>Aber da er in den 1-Wire-Modus wechselt scheint das normal zu sein.
>Das sollte für ein Funktionieren der Schnittstelle sprechen, oder?

Ja, aber das soll noch nichts heissen.

Eine Idee hätte ich noch: Öffne die AVRootloader.dev Datei mit einem 
Texteditor. Suche darin nach dem ATMege168, der muss da drinnen stehen.
Hm, auch blöder Voschlag, wir wissen ja das überhaupt nichts zurück 
kommt.

Tja, versuch es mit kommerziellen USB-RS232 Wandler, vielleicht stimmt 
bei deinem ja irgendwas mit den Pegeln nicht oder so.

Hast du schon einen anderen Bootloader mit der gleichen HW zum laufen 
bekommen ?

Gruß Hagen

PS: USB-RS232 == USB-UART

ich habe jetzt mal ganz am Anfang des Bootloaders folgenden Code 
eingebaut:

1

.org BootStart

2

init:

3

    cli

4

    xwdr

5

    clr   zerol

6

7

    sbi   DDRC,0    ; die 

8

    sbi   PORTC,0   ; und die

9

10

11

    ldi   cmdl, byte1(RamEnd)

damit sollte doch direkt nach einem Reset eine LED an dem Pin angehen, 
oder sehe ich das falsch?

jupnöö, also jain, oder Ja und Nein. Blöde Fragestellung.

Um sicher zu gehen:

1.) konfiguriere alle Use???? Defines in AVRootloader.asm
2.) setze BootCodeSize = 0
3.) compiliere mit AVRStudio
4.) nun aus Messagewindow CSEG [used] nach BootCodeSize kopieren
5.) compiliere mit AVRStudio
6.) achte im Messagewindow auf die BOOTSZ Einstellungen
7.) flashen
8.) Fuses

Gruß Hagen

Hagen Re schrieb:
> Hast du einen kommerziellen USB-RS232-Wandler oder vielleicht sogar
> einen echten COM Port an deinem Rechner ? Wenn ja probier es mal damit
> aus, einfach um Fehler in der exotischen HW ausschließen zu können. Sehr
> oft, ja sogar am häufigsten lag es nämlich bisher immer an der SW oder
> HW der USB-RS232 Wandler.

bevor ich den alten laptop rauskrame:
ist dein Programm auf win95 lauffähig?

Hagen Re schrieb:
> Hast du schon einen anderen Bootloader mit der gleichen HW zum laufen
> bekommen ?

jep, mit PeDas hatte ich es schon mal

>
> Gruß Hagen
>
> PS: USB-RS232 == USB-UART
RS232 heißtfür mich "Hochspannung" und invertierte Pegel.


Was ich gerade noch gecheckt habe:
Die Adresse im Hex-file stimmt auf jeden fall mit der zu der Fuse-Config 
überein. und nach dem Auslesen des Controllers passt auch alles.


Hagen Re schrieb:
> jup

"jup, ich sehe das falsch", oder "jup, die sollte angehen"
an geht nämlich nichts.
ich werd mal vorsichtshalber nen anderen Controller dranhängen, kann 
aber erst später weitermachen.


Nochmal danke, für die Hilfe.

Vlad Tepesch schrieb:
> "jup, ich sehe das falsch", oder "jup, die sollte angehen"
ok, das hast du schon beantwortet.
> an geht nämlich nichts.
habs nochmal überprüft.
es geht doch an, ich hatte nur vergessen RS485 zu deaktivieren und es 
auf den selben Pin gelegt.

Ich habs jetzt nochmal mit einem anderen Kabel (USB->Nokia-FBUS (ist 
auch ein usb-Uart)) probiert gleicher Effekt (gar keiner).

Die Kabel miteinander reden zu lassen, klappt aber super, so dass ich da 
eine Fehlfunktion für unwahrscheinlich halte.

Habe testweise auch mal probiert in der Gerätesteuerung die Puffer 
abzuschalten, hat aber auch nix gebracht.

Hab einen anderen mega168 und sogar einen mega8 probiert.
Irgendwie klappt gar nix.

kannst du mal ein Codesnippet posten, dass man direkt am Anfang einfügen 
kann, welches ein "Hallo" per UART verschickt? (am besten per fester 
Baudrate)

wenn ich das in ASM hinschreibe, bin ich mir immer noch nicht sicher, 
ob, wenn nix ankommt, mein Code oder die Verbindung schuld ist.

Gruß,
Vlad

Gebe mir lieber die Konfiguration die du benötigst, ich compiliere es 
dann für dich undmaile dir das HEX.

Gruß Hagen

die Konfiguration, die ich oben schon gepostet habe.
Aber was das bringen soll, frage ich mich.
Ob du oder ich das kompiliere, sollte ja egal sein.

Dass es an meiner Hardware liegt, kann man ja mittlerweile auch fast 
ausschließen.
2 verschiedene Kabel, die miteinander und mit Pedas Bootloader 
funktionieren.
In anderen Projekten wurde das eine ja auch schon oft benutzt.

Am interessantesten im Sinne des Debugging wäre jetzt ein 
Test-Bootloader, der mit deinem aktuellen Code ein paar Zeichen am 
Anfang rausschickt.

ich habe das hier mal probiert

1

[...]

2

.endif ; .if UseAutobaud

3

4

    sbi   DDRC,  1  ;  von mir

5

    sbi   PORTC, 1  ;  von mir

6

    ldi   paral,'H' ;  von mir

7

    rcall putc;     ;  von mir

8

9

; identifier (BootSign) scanning with timeout and checksum

10

[...]

Ob ich was übersehen habe und ob es so funktionieren kann, weiß ich 
nicht.
Die LED geht nach dem Boot an, Zeichen kommen keine.

Seh ich das richtig, das das ganze rein auf SW-Uart basiert?

hallo hagen

Ich möchte über Ihre Bootloader-Programm fragen.
Nach dem Lesen einiger Kommentare Ich weiß, dass Sie XTEA verwenden, um 
die kompilierte Programm zu verschlüsseln.
Aber ich bin wenig über die Verschlüsselung verwechselt. Wo sind die 
Verschlüsselung verwendet? Ist es in injiziert Programm AVR's oder in 
der GUI-Software?
Wenn ich mein Programm verwendet werden, um die Firmware mit Hilfe 
gegeben makefile kompilieren, ist es nur kompiliert oder 
zusammengestellt und verschlüsselt?

Ich bin auf Ihre Antwort warten.

Was
Favian

@Favian: I try a answer in english, think thats better ;)

With the GUI you can encrypt your HEX files into so called ACY files. 
You deliver this encryted ACY file to your customers. Your customers use 
the same GUI to download the ACY content encrypted to your preprogrammed 
AVR devices with installed AVRootloader. This bootloader receives the 
encrypted content and decrypt it.

Thus, only your GUI and your AVRootloader.asm Bootloader knows the 
password and any communication, thus upgrades are encrypted. Otherwise 
it would be useless.

Please remember follow important points to make it secure:

- newer deliver any keys to your customer
- thus ensure that in AVRootloader.ini at your customers in section 
[System] the topic Password= is empty
- compile AVRootloader.asm with follow defines
* UseCrypt = 1
* UseCryptFLASH = 1
* UseCryptE2 = 1, iff you want secure EEPROM updates
* UseSRAM = 0
- choose always for each of your projects a new uniqe password, use the 
GUI and click the "Make Password" button.
- make a full backup of the AVRootloaderproject to each of your projects
- never deliver unencrypted HEX files to your customers
- always setup the right security fuses of your AVR device !!
- to increase upgrade security activate the versioning -> UseVersioning 
= 1. With this options you can finecontrol up/downgrading process and 
the versionnumber help you for better supports.

Best regards, Hagen

PS: as a little job i provide the possibility to you to costumize the 
GUI to your needs. As example changing the logo to your own ;)

@Vlad:

>Seh ich das richtig, das das ganze rein auf SW-Uart basiert?

Ja, sehr ähnlich zu PeDa's Bootloader. Infact stammen die relevanten 
Teile von Peter und ich habe sie an die Bedürfnisse vom AVRootloader 
angepasst.

Wenn du also PeDa's Bootloader zum laufen bekommen hast dann sollte der 
AVRootloader ebenfalls auf Anhieb laufen. Die 
Konfigurierbarkeit/Compilation ist für Anfänger beim AVRootoader in 
meinen Augen sogar noch einfacher.

1

[...]

2

.endif ; .if UseAutobaud

3

4

    sbi   DDRC,  1  ;  von mir

5

    sbi   PORTC, 1  ;  von mir

6

    ldi   paral,'H' ;  von mir

7

    rcall putc;     ;  von mir

8

9

; identifier (BootSign) scanning with timeout and checksum

10

[...]

Das bringt garnichts. Die wichtigen Parameter für "putc" und damit 
SW-UART sind noch garnicht initialisiert.

1

; fixed baudrate

2

    ldi    yl, byte1(Baudrate)

3

    ldi    yh, byte2(Baudrate)

4

    movw  baudl, yl

5

.endif ; .if UseAutobaud

6

7

; identifier (BootSign) scanning with timeout and checksum

8

9

;id1:  sbiw  xl, 

10

;...    brne  id1

11

;... alles auskommentieren

12

13

; send info about chip/bootloader (BootMsg + BootInfo)

14

info:  ldi    parah, (BootInfo - BootSign) * 2 +4

15

in1:  xlpm  paral, z+

16

    rcall  putc

17

    dec    parah

18

    brne  in1

probier es mit obiger Änderung. Nach der Baudraten Detektion -> 
UseAutoBaud=1 setzen, wird sofort das BOOTSIGN, BOOTMSG und BOOTINFO 
gesendet.

Du solltest das dann als HEX-Antwort im Protokollfenster des GUIs sehen.

Gruß Hagen

Hagen Re schrieb:
> PS: as a little job i provide the possibility to you to costumize the
> GUI to your needs. As example changing the logo to your own ;)

i think it would be great if the gui could contain a possibility to 
create a little Stand-Alone-Firmware-Updater.
So the customer only need to select the com-port and hit flash and he 
does not have to configure that many options.


This should not be difficult.
You only need a template program that loads the logo, the firmware, 
eeprom (if any) and some parameters (signature, baudrate, version) from 
the exe-ressources.

If i get the loader running and you will publish the delphi sources of 
the gui, maybe i can do that.

;) @Vlad: I provide this as little job to earn a realy small fee, such 
as small that as example the normal money transfer from france to 
germany make it useless ;) Thus no public delphi sources of the GUI and 
no feature to make these changes self.

Are the bootloader now running ?

Best regards, Hagen

@Vlad:
>You only need a template program that loads the logo, the firmware,
>eeprom (if any) and some parameters (signature, baudrate, version) from
>the exe-ressources

I do'nt prefer this solution. The GUI supports already commandline 
options, including automatic updates. And the compiled ACY files are 
infact like encrypted scripts supporting in one file the data for FLASH 
and EEPROM programming and FLASH verifications.

Packing all into a single EXE provide no effects
- EXE size is already and always big, separate distributations lead to 
only transfer the small ACY files
- todays anti-spam, anti-virus technologie dont like self modified EXEs, 
or packed EXE stubs and so on

A distibutation contains
- AVRootloader.exe
- AVRootloader.ini
- AVRootloader.dev

- ????.acy, your ACY file contaning FLASH/EEPROM data
- ????.bat or ????.lnk to start AVRootloader.exe per commandline in 
automatic mode

Iff we register the ACY extension to AVRootloader.exe then we store in 
registry all paramaters and thus we do need only the ACY file it self, 
no BAT/LNK files needed.

Best regards, Hagen

Hagen Re schrieb:
> Wenn du also PeDa's Bootloader zum laufen bekommen hast

definitiv, habs grad auch noch mal ausprobiert -> geht.


Hagen Re schrieb:
> Konfigurierbarkeit/Compilation ist für Anfänger beim AVRootoader in
> meinen Augen sogar noch einfacher.
jep, seh ich genauso


Hagen Re schrieb:
> probier es mit obiger Änderung. Nach der Baudraten Detektion ->

die Änderung setzt doch an der selben Stelle an, wie meine.

Aber auch hier passiert nix - zum Verzweifeln.

@Vlad:

>die Änderung setzt doch an der selben Stelle an, wie meine.

Jo das sehe ich jetzt auch. Baue dort noch den Code für deine LED ein.

> Aber auch hier passiert nix - zum Verzweifeln.

dann kommt der Bootloader nicht über die Baudraten Detektion hinaus.

Ich weiß so langsam auch nicht weiter, was bei dir da schief läuft. 
Überprüfe nochmal ganz genau deine Fuses. Lösche den AVR komplett und 
programiere AVRootloader.hex und Fuses nochmal.

Und kauf dir mal ein Oszi ;)

Ach und überprüfe ob du mehrere Installationen von AVRootloader hast und 
lösche alle bis auf die aktuelleste. Lösche auch das HEX File vor dem 
Compilieren. Meine Erfahrung sagt mir das manche Programmierer echte 
Schlampen sind, das unterstelle ich dir nicht, aber manchesmal arbeitet 
man auf den falschen Daten und wundert sich (ist mir auch schon 
passiert).

Gruß Hagen

Thanks for your reply... I'm glad that you understand English...

About the GUI, would you like to share the source code before compiled 
(C/C++ program)? So that I can modify some parts, like the logo, the 
appearance, and the other parts.

I try to understand this part
; follow bytes should be keept secret and choosen randomly, 128 Bit 
Password, first 32 bit used as Signature
BootKey:  .db 
$A7,$39,$C9,$AD,$A2,$D1,$1E,$F6,$45,$7F,$75,$7A,$6D,$4C,$21,$41
As I know, the GUI software generate password from that Boot key. am I 
right? If I'm wrong, what does that boot key mean?

thanks.
regards.
Favian

>As I know, the GUI software generate password from that Boot key. am I
>right? If I'm wrong, what does that boot key mean?

Thats the password, eg. key for the XTEA decryption. The GUI can make 
for you a random password. The GUI can patch your AVRootloader.asm 
source file with this new random key for you. The GUI copy the random 
key into your clipboard. The GUI can store the random key into your 
AVRootloader.ini iff you want this.

If you click "compile" in the GUI the program use the given FLASH + 
EEPROM File + checked Options + Versionsnumber + even the password = 
bootkey to compile a encryted ACY file with all this content. Thus the 
data in this ACY file are encryted with the same password as stored into 
BOOTKEY.

Thus: the AVRootloader.hex must be secure, your AVR devices must be 
secured by the fuse settings, and in the customers AVRootloader.ini you 
must delete thePassword topic. In your production AVRootloader.ini you 
can store the actual used Password, or the GUI ask you everytime for the 
password.

Try it.

>About the GUI, would you like to share the source code before compiled
>(C/C++ program)? So that I can modify some parts, like the logo, the
>appearance, and the other parts.

No. As i told some postings prior, i make with this a small fee. All 
other remains free, even for commercial purpose. The only thing where i 
can get a small return are the customization of the GUI or protocoll for 
commercials.

Once more i provided a AVRootloader.dll wich contains COM/DCOM 
compatible interfaces to all functionality of the bootloader. It's even 
free. A expirienced developer can access with his own GUI to the 
bootloader features.

Thus, i think thats all fair and enough "free of charge work". Over the 
time i tend even more to not publish my work again in this manner.

Best regards, Hagen

Hm, ok step by step:


1.) start the GUI and press "Make Password" button, let patch the 
AVRootloader.asm source, let save this key into AVRootoader.ini
2.) configure AVRootloader.asm to your need and compile it as descripbed
3.) program your device with the AVRootloader.hex
4.) setup fuses of your device to protect it from reading back, protect 
even application access to the bootloader section
5.) in the GUI choose your HEX File for the FLASH and EEPROM, setup all 
option checkboxes to your need
6.) press "Compile" Button and create a ACY file

7.) your customer get from you
- AVRootloader.exe, AVRootloader.dev, AVRootloader.ini with PAssword 
topic empty
- your device, with AVRootloader bootloader and protected by fuses
- the compiled and encrypted ACY file

8.) the customer select this ACY file in the FLASH file combobox and 
press the "Program" button. All options, contents and so on thats was 
configured on creation of this ACY file are now executed, regardless of 
the options checked in the GUI.

Thus, Your developement computer and your devices shares the same 
password=key=BOOTKEY, nobody others should knew it. You alone provide 
compiled and encryted ACY files. Thus all upgrades are secure.

Regards, Hagen

Dear Hagen

I have tried to follow your instruction to create *.acy file from 
AVRootloader.exe.

But until now I always fail. why it can happen? Can you explain to me?

this is my step to make *.acy
10) run AVRootloader.exe and configure parameters (COM port, baud rate, 
daily organizer)
11) pick in the input field "FLASH" a HEX file to be compiled
12) pickin the box "EEPROM" an EEP file to be stored in the EEPROM
13) press switch "compile"
14) pick from the file dialog, the name and location of the file ACY

In my case, I don't use eeprom, so I let eeprom empty.
Is it OK with my way?

Thanks

do you have a AVR device, with right installed bootloader, already 
connected on the COM port ?

The GUI won't work offline, because it get from bootloader important 
params like signature, version, crypto support and so on..

If you let the comboboxes for FLASH and/or EEPROM empty they would be 
ignored. You can choose

- only a *.HEX into FLASH File
- only a *.EEP into EEPROM File
- *.HEX into FLASH File and *.EEP into EEPROM File
- only a *.ACY into FLASH File, EEPROM File are ignored then

If you now press "Compile" then both files are compiled and, maybe if 
the AVR device support encryption, encrypted into ACY file. Prior the 
GUI must be connected to AVR.

If you press "Program" button then the GUI try to connect, if not 
already connected, to the AVR, and program the FLASH and/or EEPROM 
dependend of selected files in combobox. Dependend of features installed 
on AVR bootloader the GUI encrypt live the FLASH/EEPROM communication 
suppose the AVR can be only updated encrypted. If you have configured 
the Bootloader to support encryted and unencryted the GUI choose the 
unencrypted communication. This configuration is

UseCrypt=1 -> Bootloader supports encrytion.

UseCryptFLASH=0
UseCryptEEPROM=0 -> Bootloader accepts encrypted and not encryted 
communication.

UseCryptFLASH=1
UseCryptEEPROM=1 -> Means FLASH/EEPROM datas must be encryted. 
Unencryted are'nt allowed.

If the GUI have to encrypt the communication it looks into 
AVRootloader.ini on topic Password=. If is empty the GUI ask you for the 
password.

Think not to deeply about all possible combinations, do and try it, it's 
bullet proof and idiot secured ;)
Watch the caption and the "connect" Button of the GUI when you do any 
actions.

Regards, Hagen

@hagen
Ich geh kaputt, ich hab jetzt nochmal ganz von vorn angefangen und jetzt 
funktionierts.

Ein diff zu dem Projekt, was ich hochgeladen habe zeigt keine 
Unterschiede, außer dem UARTInvert, was ich ja aber vorher auch schon 
(und zwischendurch immer wieder) probiert hatte.

Mir ist aber noch unklar, warum die invertiert werden muss.
Wenn ich sonst die UART verwende, häng ich die auch direkt an meinen 
Adapter.


Wenn ich den UseWDR konfiguriere, disconnected sich das device aber 
immer wieder.

1

13.07.10-16:30:26-843 > Connecting on port COM4...

2

13.07.10-16:30:26-843 > Timeout.Connect       = 500 ms

3

13.07.10-16:30:26-843 > Timeout.Base          = 500 ms

4

13.07.10-16:30:26-843 > Timeout.Erase         = 100 ms

5

13.07.10-16:30:26-843 > Timeout.Flash         = 150 ms

6

13.07.10-16:30:26-843 > Timeout.Eeprom        = 100 ms

7

13.07.10-16:30:26-843 > Timeout.Buffer        = 10 ms

8

13.07.10-16:30:26-843 > Timeout.AppCmd        = 0 ms

9

13.07.10-16:30:26-843 > Timeout.KeepAlive     = 2500 ms

10

13.07.10-16:30:26-843 > Timeout.RTSPulse      = 0

11

13.07.10-16:30:26-843 > Timeout.RTSInterval   = 0

12

13.07.10-16:30:26-843 > Timeout.ConnectTrials = -1

13

13.07.10-16:30:26-843 > Timeout.MaxPacketSize = 0

14

13.07.10-16:30:26-859 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54

15

13.07.10-16:30:27-500 > received data   $94 06 06 04 30

16

13.07.10-16:30:27-515 > Timer created

17

13.07.10-16:30:27-515 > Device connected

18

13.07.10-16:30:30-015 > send keepalive

19

13.07.10-16:30:30-515 > Timer released

20

13.07.10-16:30:30-515 > keepalive failed, terminate connection

21

13.07.10-16:30:31-031 > Device disconnected

Ist da vielleicht ein Bug? der Bootloader müsste den WDT doch am Anfang 
deaktivieren und am Ende wieder aktivieren, oder hab ich den Sinn der 
Option falsch verstanden.

Gibt es eine Option, mit der man den WDT einfach nur deaktivieren kann.
Ich will den WDT benutzen um ein Reset auszulösen.

Am allerliebsten wäre mir jedoch, wenn ich per UART ein Kommando 
schicke, dass der µC den Bootloader startet.
Da gibt es allerdings 2 Probleme: wie komme ich zum Bootloader ohne fixe 
Addressen in meinem C-Code zu haben? Der Sprung zum Bootloader ginge ja 
nur über inline-Asm, oder? Ich vermute genau hierfür ist das 
UseSpecialBootVect, aber wie benutze ich das?

das 2. ist, dass das Flashtool, dieses Kommando senden müsste, oder man 
müsste die Wartezeit am Anfang sehr lang machen.

>Mir ist aber noch unklar, warum die invertiert werden muss.
>Wenn ich sonst die UART verwende, häng ich die auch direkt an meinen
>Adapter.

Das ist eine Frage des Standpunktes ;)

Die Soft-UART des Bootloaders kann direkt mit ihren Pins an ein 
RS232-Kabel angeschlossen werden. Das nennen wir mal 1-zu-1 Pegel.
Wird ein RS232-Pegel-Konverter benutzt so werden die Signalpegel defakto 
invertiert. Aus RS232 wird TTL Pegel mit invertierter logischer 
Bedeutung was nun ein 1- oder 0-Datenbit darstellt. Siehe 
http://de.wikipedia.org/wiki/RS-232

Desweiteren kann der Bootoader im 2-Wire und 1-Write-RS232 Modus 
arbeiten. Statt also mit getrennten RX/TX Leitungen, invertiert oder 
nicht invertiert, kann man mit einer einizgen Leitung für RX/TX, also 
1-Wire arbeiten. Ebenfalls invertierte und nicht invertierte Pegel. Im 
1-Wire Modus kann man mit einem kleinen Adapter (Schaltplan ist im  JPG) 
auch direkt an die RS232 ohne Pegelwandler. Aber auch mit Pegelwandler 
wie MAX232, USB-UART usw. kann man noch 1-Wire benutzen, dann mit 
UseUARTInvert=1.
Im 1-Wire-Modus kann man mehrere AVRs mit meinem Bootloader auf einem 
Board platzieren und alle sind am gleichen 1-Wire-Bus angeschlossen. 
Wenn die einzelnen Bootloader dieser AVRs alle unterchiedliche BOOTSIGNs 
koinfiguriert haben dann kann man damit alle AVRs updaten über eine 
einizige Leitung und einem einzigen Windows-Program.

Gruß Hagen

>Wenn ich den UseWDR konfiguriere, disconnected sich das device aber
>immer wieder.

>13.07.10-16:30:27-515 > Timer created
>13.07.10-16:30:27-515 > Device connected
>13.07.10-16:30:30-015 > send keepalive
>13.07.10-16:30:30-515 > Timer released
>13.07.10-16:30:30-515 > keepalive failed, terminate connection

Das Protokoll sagt es schon:
1.) keepalive failes, termnate connection
2.) Timeouts.KeepAlive=2500 ms

Der WDT im AVR wird im Bootloader immer auf 2 Sekunden=2000ms 
programmiert. Ergo 2500ms KeepAlive Interval ist bei weitem zu lange, 
ich habe das so nie konfiguriert. Setze es auf 500ms bis 1000ms wieder 
zurück. Selbst 1500ms wären zu lang, bedenke das Nyquist Theorem.

Nutzt du UseWDT=1 so hat das mehrere Vorteile:
1.) der WDT wird auf 2s Timeout programmiert
2.) wenn eine Bootloader Software connected ist so muß diese alle max. 
2s ein Kommanod senden oder irgendwas senden.
3.) erfolgt dies nicht so geht der Bootloader von einer gebrochenen 
Kommunikation, startet über WDT-Reset sich quasi selber erneut, kommt in 
seine Baudrate Detektion und/oder BootSign Detektion, Timeouted dort und 
ruft dann final die istallierte Anwendung auf.
4.) sendet nun das GUI periodisch Daten oder eben ein KeepAlive und der 
Bootloader antwortet nicht mehr so trennt das GUI die Verbindung autom. 
Also auch hier wartet es dann nicht unendlich.

5.) du kannst in deiner Anwendung selber über einen absichtlichen 
WDT-Timeout den Bootloader starten. Ich empfehle das exakt so weil es 
technologisch den saubersten und stabilsten Programablauf ermöglicht. 
Der AVR wird auch aus unvorhersehbaren Situationen immer sauber 
recovern.
Naja, du lässt also den WDT mit zb. 20ms und einer Endlosschleife bei 
gesperrten IRQs "timeouten". Daraufhin wird der AVR zurückgesetzt, also 
auch alle Register und Ports in jedem Falle neu iniatilisiert.

Der Nachteil oder auch ein Vorteil:
Nutzt du den WDT in deiner Anwendung nicht dann musst du den WDT in 
deiner Anwendnung sofort beim Startup deaktivieren. Nun kann das aber 
auch ein Vorteil sein, denn wenn deine Anwendung vorher schon hängt, 
weil FLASH kaputt oder irgendwas falsch programmiert wurde, dann würde 
deine App den WDT nicht deaktieren. Da mein Bootloader vor dem Aufruf 
deiner Anwendung den WDT zurück gesetzt hat hast du somit rund 2 
Sekunden Zeit den WDT zu deaktivieren oder ihn zurück zu setzen. Erfolgt 
das wie geagt auf Grund enes Fehler nicht so entsteht ein RESET und 
schwups sind wir wieder im Bootloader. Somit Kreislauf geschlossen, auf 
unvorhergesehene Fehler reagiert das System indem es den Bootloader 
startet, ergo AVR ist erreichbar per GUI.

Ich empfehle dir also dringends den WDT zu benutzen, über ihn den 
Bootloader zu starten. Damit erledigt sich auch dein Problem den 
Bootloader per JUMP anspringen zu wollen. Wobei aucn das sehr simpel 
ist:

1.) UseSecialBootVec=1 setzen
2.)

1

void bootloader_start_jump(void) {

2

3

    asm volatile("jmp -2");

4

}

5

6

void bootloader_start_wdt(void) {

7

8

    cli();

9

    wdt_reset();

10

    _WD_CONTROL_REG = (1 << WDE) | (1 << _WD_CHANGE_BIT);

11

    _WD_CONTROL_REG = (1 << WDE);

12

    for (;;);

13

}

Durch die Arithmetic führt dieser Sprung bei allen AVR deren 
addressierbarer FLASH eine Größe einer Potenz von 2 hat immer dazu das 
an die letzte FLASH Addresse, bzw. OpCode gesprungen wird.

Aber beachte dabei auch folgendes:
Alle deine gemachten Einstellungen an den Ports, ISRs, IRQs musst du 
manuell sauber zurücksetzen damit der Bootloader eine saubere Umgebung 
vorfindet. Der Bootloader, erbt also alle deine Einstellungen. Das kann 
von Nutzen sein wenn du den Bootloader als "Mini-Debugger" benutzen 
möchtest, dann möchtest du ja das zb. im SRAM/PORT Fenster des GUIs das 
steht was du in deiner Applikation eingestellt hast.

>Am allerliebsten wäre mir jedoch, wenn ich per UART ein Kommando
>schicke, dass der µC den Bootloader startet.

Das geht auch schon ;)

1.) in AVRootloader.ini setze
- AppCmd=StartBoot/0D
- AppCmdResponse=BootStart
- Timeouts.AppCmd=20

2.) in deiner Applikation nutzt du eine eigene UART Library mit gleichen 
RX/TX Pins wie der Bootloader
3.) in dieser Library warte nun auf den Befehl "StartBoot" + 0x0D
4.) wenn eingetroffen sende "BootStart"
5.) aktiviere Bootloader mit bootloader_start_wdt(), ergo 20ms Timeout

Wenn du mit dem GUI einen Connect versuchst sendet es
1.) StartBoot + 0x0D
2.) wartet auf BootStart, also AppCmdResponse wenn da was drinnen steht
3.) wenn es AppCmdResponse empfangen hat oder es leer ist
4.) wartet es TimeOuts.AppCmd Millisekunden
5.) und beginnt dann einen Connect zum Bootloader

Das wäre die SW-Lösung. Die HW-Lösung

1.) verbinde RTS der RS232 mit RESET am AVR
2.) setze in ARootloader.ini
-RTSPulse=
-RTSInterval=
entsprechend dem was dort beschrieben ist
3.) das GUI pulst nun die RTS=RESET Leistung des AVRs vor jedem x'ten 
Connect Versuch


Gruß Hagen

aso, die Timeouts hatte ich testweise mal vergrößert und wieder 
vergessen zurückzusetzen.
jetzt gehts alles.

Hagen Re schrieb:
>>Am allerliebsten wäre mir jedoch, wenn ich per UART ein Kommando
>>schicke, dass der µC den Bootloader startet.
>
> Das geht auch schon ;)
>
> 1.) in AVRootloader.ini setze
> - AppCmd=StartBoot/0D
> - AppCmdResponse=BootStart
> - Timeouts.AppCmd=20

Super! Stand das irgendwo? ich hatte extra die txts überflogen.

Nochmal vielen Dank für dieses super Stück Software und deine Zeit für 
Erklärungen.

Jo steht alles hier im Thread, mehrmals sogar.

Hi Favian,
as might saw it in this thread, there is simple opensource alternative 
gui for that bootloader. 
Beitrag "Re: AVR-Bootloader mit Verschlüsselung" Once i programmed it 
since of a lack of a GUI working under Linux. (This one is compilable 
for windows aswell as linux)
Unfortunately its really simple and you cant create encrypted files on 
your own like the original can do. Thus you have to use the original 
loader to create your acy image which you can upload by that alternative 
one then. Another restriction by now is that it only supports Atmega8 
processors. Just because i was lazy and just needed support for that uC. 
But it shouldn't be any problem to add other uC signatures with their 
matching memory layout to extend its functionality. Feel free to do it!

@Hagen:
Es wäre echt super, wenn deine GUI ein ACY File auch in Abwesenheit 
eines uC erstellen könnte. Dass die ganzen Prozessordaten stimmen für 
mein ACY Image stimmen, dafür nehme ich gerne die verantwortung. :-)

Regards, Grüße,
Arne

@Arne: ja du bist nicht der Einzige der diesen Wunsch hat. Dummerweise 
war das nicht konzeptionell geplant und somit wird es mehr Arbeit werden 
als nur nebenbei mal das Logo auszutauschen oder par Buttons zu 
verschieben.
Es steht auf der Todo Liste als erster Punkt.

Gruß Hagen

Hagen Re schrieb:
> @Arne: ja du bist nicht der Einzige der diesen Wunsch hat. Dummerweise
> war das nicht konzeptionell geplant und somit wird es mehr Arbeit werden
> als nur nebenbei mal das Logo auszutauschen oder par Buttons zu
> verschieben.

schon klar. Kein Stress! Wollte nur mal den Wunsch etwas auffrischen..

> Es steht auf der Todo Liste als erster Punkt.

Yeah!

> Gruß Hagen

Gruß, Arne

@Hagen:

Du hast in dem Bootloader.zip leider keine Texte, die auf die Lizenz 
schließen lassen. Auch die Sourcen enthalten nix dahingehendes.
Ich würde diesen Bootloader gerne in der Word Clock* verwenden.

Der Einfachheit halber wäre es schön, wenn ich den Bootlader mit den 
Sourcen und dem Flash-Tool dort dazupacken könnte, da dies das 
unkomplizierteste wäre und die Leute, es so nicht separat herunterladen, 
in ein vorgegebenes Verzeichnis entpacken und konfigurieren müssen.


Bitte schreib, wie du dazu stehst.


Gruß,
Vlad


*
ein GPL-Projekt
-> http://www.mikrocontroller.net/articles/Word_Clock
-> http://www.mikrocontroller.net/topic/156661)

Jo geht so. Der Bootloader ist so wie du ihn hier findest Freeware, wie 
alles was ich veröffentliche. Einziger Wunsch ist das Copyright, bzw. 
ein Hint in deiner ReadMe/AboutBox auf meinen Bootloader, aber selbst 
das kann ich nich kontrollieren.

Alles was in Richtung kommerzielle Nutzung geht kann, muß aber nicht, 
mit mir per EMail nochmal abgesprochen werden und ich bin gerne bereit 
Modifikationen zb. im GUI der Windows Software vorzunehmen.

Gruß Hagen

Hi Martin,

Zur Verbesserung des Connects:

* in AVRootloader.asm
- UseAutobaud = 1
- UseResetDelay = 1
- BootDelay vergrößern zb. auf XTAL/2, XTAL/1 -> 500ms, 1sec

* in AVRootloader.inc
- BaudTolerance  = 3 oder langsam höher setzen, je größer der Wert desto 
größer der Fangbereich bei abweichenden Baudraten. Ich empfehle max. 5 
bis 6

* in AVRootloader.ini
- Baudrate=115200
- [timeouts] Base = 25

Je höher die Baudrate und desto kleiner der Base-Wert desto mehr 
Connect-Versuche im gleichen Zeitraum können stattfinden, desto höher 
die Wahrscheinlichkeit eines Connects im Zeitbereich. Aber auch desto 
kritischer das Timing bei der Kommunikation.
Je geringer die Baudrate und je größer Base desto stabiler wird die 
Kommunikation aber der Connecttrial wird pro Zeitspanne weniger häufig 
stattfinden können.

Zum 1-Wire:
Ich habe den Multi-Bus-1-Wire nur mit physikalischen RS232 Pegeln 
getestet. Du benutzt einen TTL Pegelwandler und dadurch invertieren sich 
alle Signale und damit auch das Verhalten der DDR-Ansteuerung. Die AVRs 
kennen nur interne PullUps und keine PullDowns. Versuche also auch mal 
extern einen PullUp oder PullDown Widerstand dran zu pappen.

Die Bootloader SW übernimmt erst dann die Kontrolle über den 1-Wire-Bus 
wenn sie das korrekte BootSign und demnach die korrekte Baudrate 
ermittelt hat.

Gruß Hagen

@Thomas:

ja da wirds immer ein Problem geben. Ich bekomme den kompletten 
Parameter als Kommandozeile. In dieser befindet sich der Pfad + der Name 
der EXE + die Parameter. Im Pfad können fast alle Zeichen vorkommen, so 
auch - und Leerzeichen. Ich muß aber irgendein Token/Zeichen benutzen um 
den Begin eines Parameters zu signalisieren.

Leerzeichen im Pfad würde den Pfad als solches abschneiden. Minus im 
Pfad würde die SW als Parameter interpretieren. Ich könnte nun beim 
Parsen das Minus nur dann als Parameterstart akzetieren wenn vor dem 
Minus und Leerzeichen steht. Das würde die Fehlerwahrscheinlichkeit 
reduzieren aber das Problem nicht real sauber lösen.

Andere Option wäre es die Pfade in Anführungsstriche zu setzen. 
Dummerweise geht das aber nicht autom. wenn Windows eine Anwendung 
startet. Geht also nur bei Batches/Verknüpfungen etc.pp.

Egal wie ich es drehe:
- Windows hat mit seinen langen Dateinamen und dem Zulassen von bisher 
unter DOS illegalen Zeichen in den Pfaden uns Progrmmiern die Arbeit 
erschwert
- ich müsste das komplette Parameter-Format abändern

Ergo: Verzichte auf Minus in deinen Pfadangaben.

Gruß Hagen

PS: ich könnte das Minus durch Slash ersetzen., weiß aber jetzt nicht 
aus dem Stand heraus ob das wirklich eine gute Idee ist oder ob ich mir 
damit neuen Ärger einfange.

Hagen Re schrieb:
> @Thomas:
>
> ja da wirds immer ein Problem geben. Ich bekomme den kompletten
> Parameter als Kommandozeile. In dieser befindet sich der Pfad + der Name
> der EXE + die Parameter. Im Pfad können fast alle Zeichen vorkommen, so
> auch - und Leerzeichen. Ich muß aber irgendein Token/Zeichen benutzen um
> den Begin eines Parameters zu signalisieren.

Nimm doch testweise den nächsten Token, füge ihn an den alten an und 
prüfe, ob der Pfad existiert. Wenn nicht -> als Paramter interpretieren, 
wenn nicht, ists der Pfad.

Oder alternativ, falls du Delphi verwendest, Parameterstring nach 
ExtractFileName(application.exename) durchsuchen und bis dahin alles 
abschneiden. Dann besteht der String nur noch aus Paramtern. Wäre eine 
Zeile.

> Egal wie ich es drehe:
> - Windows hat mit seinen langen Dateinamen und dem Zulassen von bisher
> unter DOS illegalen Zeichen in den Pfaden uns Progrmmiern die Arbeit
> erschwert

Hab auch schon oft Erfahrungen mit gemacht...

Viele Grüße,
Arne

@Arne: das hatte ich mir auch schon überlegt, fixt aber das Problem auch 
nicht vollständig. Man kann als Parameter einen Arbeitspfad und Pfade zu 
ACY/EEP/HEX Dateien angeben. Auch dort tritt das Problem dann auf und 
dort kann ich das mit dem EXEPath Trick nicht erschlagen.

Ich werde es wohl so bauen das man in der AVRRootloader.ini das 
Parameter-Token angeben kann. Standard wird Slash, ersetzt man es durch 
Minus gibts keine Probleme mehr mit veralteten Kommandozeilen. Die 
Benutzer der Kommandozeilenaufrufe müssen dann halt ihre Kommandozeilen 
bei Bedarf anpassen.

Übrigens arbeite ich mit Delphi. Ich bin aber gezwungen einen eigenen 
Parser für die CommandLine zu schreiben da man der Delphi RTL nicht eine 
andere CommandLine unterjubeln kann. Das bräuchte ich aber da ich nur 
Single Instances der EXE zulasse und wenn die EXE mehrfach gestartet 
wird so kommuniziert die neu gestartet EXE ihre Kommandozeile zur schon 
gestarten Instanz und terminiert sich dann selber. Die schon laufende 
Instanz lädt dann ihre Parameter neu auf Grund der Parameter die man der 
zweiten Instanz übergeben hat, und setzt sich in den Vordergrund. Ergo: 
ich muß die Commandline per Hand auswerten und kann nicht die RTL 
Funktionen von Delphi benutzen.

Gruß Hagen

>bei 2 Reglern funktioniert
>es mit einem 10k Pulldown mit sehr guter Connect-Rate!

Je nachdem was du als Widerstand zwischen RX/Tx geschaltet hast würde 
ich den Pulldown sogar auf 4k7 reduzieren.

>UseResetDelay geht nicht - im regulären (Flug-)Betrieb könnte der Regler
>abstürzen, bekommt ständig Daten zugesendet, da muss der Reboot so rasch
>wie möglich durchlaufen, sonst stürzt das Modell ab. UseResetDelay=1
>würde bedeuten das er für immer im Bootloader bleibt.

Hm. Dann hätte ich aber den Bootloader über einen externen Pin 
angesprochen der nicht auch deinen Kommunikationskanal macht.

Du kannst aber auch mit UseBootMode=1 den Bootloader so konfigurieren 
das er nur startet wenn:

a) noch keine Applikation geflasht wurde
b) wenn ein Powerup die Ursache des Resets war

Damit schließt du "künstliche" Resets wie WatchDog und eben BrownOut 
Reset aus. Besonders letzere beide sollten für dich interessant sein da 
ich vermute das über diese beiden Reset Sources dein Regler recovert.

Oder UseBootMode=2 startet den Bootloader dann nur bei externem 
absichtlichen Reset, falls du den noch nutzt ;)

Eine andere, aber gefährlichere Einstellung wäre noch UseBootMode=5. Bei 
dieser Einstellung startet der Bootloader nur bei nicht installierter 
Applikation automatisch. Wurde einmalig eine Anwendung programiert so 
muß diese per CALL/JMP den Bootloader selber aufrufen. Somit entscheidet 
dann deine Anwerndung alleinig ob und wann der Bootloader gestartet 
wird. Ein Fehler in deiner Anwdnung führt dann aber zum Ausperren.

Ich denke mal das UseBootMode=1 und aktiviertem WatchDog + Brownout die 
cleverste Wahl für dich wäre. Dein Regler recovert falls er per WDT 
timeouted, also bei Hängern in der Regler Software. Er recovert bei 
absinkender Spannung, eg. Spannungeinbruch über den Brownout Reset.
Nur wenn der Regler komplettt neu mit Saft versorgt wird, er also 
längere Zeit als der Brownout, keine Spannung hatte wird der Bootloader 
in seine Warteschleife verzweigen. Ansonsten springt er sofort in deine 
Anwendung, ohne Zeitverzögerung. Hast du UseWDT=1 gesetzt so wird vorher 
sogar noch der WatchDog mit 2sec Timeout aktiviert.
Mit UseSaveMCUSR=1 sichert er sogar noch auf dem Stack (OnTop an 
höchster SRAM Addresse) noch das oroginale MCUCSR/MCUSR Register bevor 
das mit 0x00 überschrieben wird. Dh. in der Anwendung kannst du über den 
Stack an die originalen RESET Sources gelangen um dann in deinem Startup 
Code gezielt auf die spezifischen RESETs reagieren zu können.

Gruß Hagen

ATmega328P is supported. The Bootloader supports all self programmable 
AVR devices, except XMega series. Even future devices. To include these 
install newest AVRStudio on your computer. Delete AVRootloader.dev file 
and start AVRootloader.exe on your machine. The software parse on 
startup the AVRStudio XML part description and include files and create 
a new AVRootloader.dev file based on these files.
Or you take manual the changes needed. First include follow line into 
AVRootloader.asm source

1

.include "m328Pdef.inc"        ; ATmega328P

then open AVRootloader.dev file an add follow line

950F=1E950F, ATmega328P   ,  32768, 1024, 2048, 256, 128,  4,  8, 16, 32


The parameters are as follow:

- 950F, short hexadecimal ID of the device
- 1E950F, full hexadecimal ID of the device, eg. same as first param 
with leading 1E
- ATmega328P, the device name
- 32768, FLASH size in bytes
- 1024, EEPROM size in bytes
- 2048, SRAM size in bytes
- 256, start of SRAM or in other words the Register File and Port size 
in Bytes
- 128, FLASH page size in bytes
- 4, FLASH page count of FIRST_BOOT eg. the size for Bootloader section
- 8, FLASH page count of SECOND_BOOT
- 16, FLASH page count of THIRD_BOOT
- 32, FLASH page count of FOURTH_BOOT

The version in the attachment already known the ATmega328P.

Best regards, Hagen

The sources for the AVRootloader.exe are'nt free avaiable.
There exists two possible ways for you:

1.) use the commandline to startup AVRootloader.exe. As example:

AVRootloader.exe -PCOM1 -B115200 -Fc:\test\my.acy -Apc

Startup AVRootloader.exe with COM1 and 115200 baudrate to execute file 
my.acy and close the GUI after successfully finishing all actions. If 
any error occur the GUI remains stay open. On creation of your encrypted 
ACY file you choose wich action are todo when a customer execute this 
file. Eg. you compile into you ACY file the HEX file for the FLASH 
and/or the EEP File for the EEPROM, maybe choose the application version 
number, and/or if the FLASH contents should be erased prior and/or 
verified later.

2.) give me a contract and i take any changes for you :)

Please remember to clear in AVRootloader.ini the topic Password= if you 
use encryted ACY files. Otherwise your customers have full access to 
your devices. Setup in AVRootloader.asm

UseCrypt=1
UseCryptFLASH=1
UseSRAM=0

and change the provided password in BootKey: (maybe withelp of 
AVRootloader.exe GUI) to provide the maximal security.

Best regards, Hagen