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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Etumic E. (etumic)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Stefan:

ich weiß nicht ob es von dir so beabsichtig ist aber die FLASH Adresse 
für WriteFlash() kann byteadressiert sein und muß nicht zwangsläufig mit 
zwei multipliziert werden um wordbasiert zu sein. Das Besondere an 
WriteFlash ist es das man an beliebige FLASH Adresssen beliebig große 
Datenbereiche schreiben kann. Man brauch nicht auf Wordalignment oder 
die Pagesize des FLASHs achten. Man kann also im Minimalfall nur 1 Byte 
an eine ungerade FLASH Adresse schreiben. Diese Funktion lädt dann die 
betroffene FLASH Page, modifiert an der richtigen Stelle das zu 
schreibende Byte aus dem SRAM Buffer und schreibt dann diese FLASH Page 
zurück.

Gruß Hagen

von Louis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich setzte den Bootloader schon längere Zeit ein und möchte ihn nicht 
mehr missen. Ich habe eine ältere Version im Einsatz die bisher super 
funktioniert hat. Bisher...

Diesen Bootloader habe ich compiliert und sie wie er ist mehrfach auf 
identische Hardware gebrannt. Das lief immer problemlos.

Gestern wollte ich noch zwei der Gerätchen bauen, nach dem Test habe ich 
den Bootloader drauf geschrieben, und bekomme keinen Kontakt. Hardware 
ist ein Mega644p, wenn ich meine Software direkt drauf flashe läuft 
alles prima, der Bootloader ist aber nicht ansprechbar.
Alle Fuses sind korrekt gesetzt, die Speichergröße im ASM-File auch, 
habe jetzt alles zigmal kontrolliert. Ebenso die Bootstrings usw. Alles 
wie früher. Ich habe sogar ein uraltes Backup zurück geschrieben um 
sicher zu gehen, dass ich wirklich denselben Bootloader habe. Nix 
klappt..

Was könnte das verursachen? PC-Macke? Mit der Windows-Software des 
Bootloaders kann ich auch auf die alten Geräte nicht mehr zugreifen, da 
kommt immer Checksum error. Mit meiner eigenen über die DLL klappt es 
dagegen mit den alten Geräten prima.

Ich habe mit der DLL damals eine Funktion in meine PC-Softwar eingebaut 
mit dem der Anwender neue Firmware flashen kann. Wenn ich jetzt die 
neueste Version des Bootloaders nehme, kann ich dann mit der alten DLL 
noch darauf zugreifen? Oder hat sich da immer wieder viel verändert? 
Meine Version ist aus dem Mai 2008. Ansonsten müssten alle ihre Software 
updaten, das wäre schlecht.

Louis

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Probiere in der AVRootloader.ini in [Timeouts] Options=2 oder Options=0.

Der "Login" Prozess beim Senden/Empfangen des BootSigns hat sich 
zwischen den Versionen geändert. Mit Options=2 wird der alte Loginstring 
gesendet und mit Options=0 der neue. Beim Neuen wird über das gesendete 
BootSign noch eine CRC erzeugt, mit gesendet und im Bootloader 
dementsprechend geprüft.

Zudem solltest du in Zukunft zu jedem deiner Projekte bei denen du den 
Bootloader einsetzen möchest ein kompletes Backup der entsprechend 
konfigurierten Bootloader Software dazu legen. Das beinhaltet auch die 
PC Software. So mache ich das immer und Speicherplatz ist heutzutage 
kein Problem mehr.

Gruß Hagen

von Louis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen, danke, das werde ich mal testen.

Ich habe ja ein Backup des Bootloaders, auch die Originale Version aus 
dem Backup, die schon mehrfach verwendet wurde, antwortet nicht mehr, 
das ist ja das seltsame.
Heute werde ich mal weiter versuchen es wieder zum Laufen zu bekommen, 
und einen anderen PC nehmen, mal sehen ob es daran liegt.

Louis

von Louis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tach auch,

gibts irgendwo noch eine Demo wie man die neue DLL in Delphi Programme 
einsetzt? Irgendwie klappt das so wie im alten Beispiel nicht mehr, da 
hagelt es Fehlermeldungen..

Vor allem meckert er wegen

    function GetAppCmd: WideString; stdcall;
    function GetAppCmdResponse: WideString; stdcall;
    function GetAppVersion(Masked: Bool = False): Integer; stdcall;
    function GetACYInfo: WideString; stdcall;


Welchen Sinn haben diese Funktionen? Kann man das irgendwo nachlesen?

Louis

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das was die Methodennamen aussagen. Im Grunde geben sie die Werte zurück 
die in meiner EXE aus der INI datei gelesen werden oder im GUI eingebbar 
sind.

Dein Objekt das dieses Interface benutzt muß also bei

- function GetAppCmd: WideString; stdcall;
+ aus AVRootloader.ini -> AppCmd
- function GetAppCmdResponse: WideString; stdcall;
+ aus AVRootloader.ini -> AppCmdResponse
- function GetACYInfo: WideString; stdcall;
+ aus GUI das Edit "ACY Info"
- function GetAppVersion(Masked: Bool = False): Integer; stdcall;
+ aus GUI die Edits/UpDown Controls bei Versionsnummer

zurückgeben. Spezialfall ist GetAppVersion() und das kannst du weiter 
oben im Thread nachlesen.

Es gibt keine weitere Dokumentation als die Beschreibung des aktuellen 
Interfaces, leider. Das liegt aber auch daran das die Nachfrage gegen 
Null geht und ich deswegen nicht Stunden meiner Freizeit opfern möchte. 
Wenn dann würde ich eher das Demoprojekt auf den neusten Stand bringen 
wollen da das weitaus weniger Zeit kostet als eine Doku.

Gruß Hagen

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Ich habe ja ein Backup des Bootloaders, auch die Originale Version aus
>dem Backup, die schon mehrfach verwendet wurde, antwortet nicht mehr,
>das ist ja das seltsame.

Dann würde ich aber eher auf ein Fehler in deinem PC-System, COM 
Schnittstelle tippen. Denn wenn selbst die alten, schonmal 
funktionierenden Module, mit den Backups nichts gehen, dann kann ja nur 
dort die Ursache sein.

Falschen COM Port eingestellt ? Manchmal sind es wirklich solche 
trivialen Fehler die man konsequent übersieht.

Gruß Hagen

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hagen schrieb:
> Wenn dann würde ich eher das Demoprojekt auf den neusten Stand bringen
> wollen da das weitaus weniger Zeit kostet als eine Doku.

Au ja Hagen, das wäre toll. Ich weiß, auch das ist viel Aufwand...
Am einfachsten wäre natürlich die Source von Deiner GUI, dann wäre keine 
DLL und keine Doku nötig. Aber Du wirst schon Deine Gründe haben, warum 
Du die Sourcen nicht veröffentlichst.

von Thilo M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achim schrieb:
> dann wäre keine
>
> DLL und keine Doku nötig

Btw., wenn ich grade DLL höre: DLLs mit demselben Namen können nicht 
alle beim System registriert werden, nur die zuerst veröffentlichte wird 
verwendet.
Vielleicht liegt der Fehler einiger User hier?
Wenn die alte DLL nachträglich aufgespielt wurde (in anderem 
Verzeichnis), dann bleibt die neuere, zuerst aufgespielte, gültig.

Evtl. mal alle DLLs löschen und nur die benötigte aufspielen, Neustart 
des Rechners nicht vergessen!

;-)

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Na ja, eine "normale" Dll wird ja nicht unbedingt beim System 
registriert sondern i.d.R statisch oder dynamisch gelinkt, also zur 
Laufzeit geladen. Man kann hier die Suchreihenfolge für Windows u.U. 
ändern, aber die erste gefundene wird halt geladen, es sei denn man gibt 
explizit die Datei vor.

von Tim O. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Guten Tag...

Ich nutze seit einiger Zeit diesen Bootloader (in V6.0) für ein Projekt,
das programmieren über die beiliegende Windows-Software funktioniert 
auch
wunderbar und alles könnte schön und gut sein.

Aber dann habe ich mir in den Kopf gesetzt, das Firmware-Update mit in 
die
Software zu integrieren, mit der ich die Hardware konfiguriere, bevor 
das
Ding Standalone seinen Dienst verrichtet. Praktischerweise holt sich 
diese
Software (Delphi) das aktuellste ACY-File aus dem Internet.

Auch hier ist alles schön und gut, und nun kommt das aber:

Mit denselben Timeout-Parametern wie in der beiliegenden Flash-Software
will die DLL (v6) nicht mit dem Bootloader (ebenfalls v6, selbes Archiv
wie die DLL).

Nun habe ich den Thread mehrfachst durchforstet, finde aber nichts zu 
meinem
konkreten Fehler:
268435456 - Connecting on port COM13...
268435456 - Timeout.Connect       = 50 ms
268435456 - Timeout.Base          = 50 ms
268435456 - Timeout.Erase         = 10 ms
268435456 - Timeout.Flash         = 15 ms
268435456 - Timeout.Eeprom        = 10 ms
268435456 - Timeout.Buffer        = 10 ms
268435456 - Timeout.AppCmd        = 0 ms
268435456 - Timeout.KeepAlive     = 250 ms
268435456 - Timeout.RTSPulse      = 0
268435456 - Timeout.RTSInterval   = 0
268435456 - Timeout.ConnectTrials = 100
268435456 - Timeout.MaxPacketSize = 0
268435456 - send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
268435456 - received data   $95 02 06 08 37
268435456 - send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
268435456 - send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
268435456 - received data   $95 02 06 08 37
268435456 - send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
268435456 - received data   $95 02 06 08 37
268435456 - send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
268435456 - received data   $95 02 06 08 37
268435456 - send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
268435456 - received data   $95 02 06 08 37
268435456 - send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
301989888 - aborted by User

Die DLL sendet ihren Ident (BOOTLOADER), die Antwort vom mega32 ist auch
richtig, nur "irgendwie" verschläft die DLL diese Antwort, oder erkennt 
sie
nicht gültig an.. ein Spielen mit den Timeouts blieb 2 Stunden 
"Intensivtest"
ohne Erfolg.

Die Ausgabe wurde mit (result.)Options = 1 ausgegeben.

Als Grundlage für das Delphiprogramm nehme ich die Interface-Unit, die
meisten Deklarationen habe ich aus den älteren Beispielen übernommen, 
auf
den aktuellen Stand angepasst (Rückgabewert bei ProcessMessages, als
Beispiel) und natürlich die "fehlenden" Deklarationen ergänzt.

Alles erscheint funktionsgfähig, ich habe mal nur den Bootloader 
aufgespielt,
die beiliegende Software connected/disconnected problemlos, nur die in 
die
eigene Software eingebundene DLL mag nicht.

Interessant ist noch ein Punkt: ohne (result.)Baudrate := 115200; in der
Timeouts-Function bekomme ich mit der letzten geposteten Variante von
OpenCommunication() keine Antwort von der MCU, wenn ich es setze, 
bekomme
ich eine ICOM: Read Error Exception (in der Delphi-IDE mit allen 
"negativen"
Konsequenzen, wird das Programm per Doppelklick ausserhalb der IDE 
gestartet,
kommt es zu keiner Meldung, und die Kommunikation von MCU an PC wird 
zumindest
im Memo-Feld wie oben zitiert dargestellt.

Entweder sehe ich den Wald vor lauter Bäumen nicht mehr, oder irgendwas
anderes ist im argen.

Gruss,
 Tim O.

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Die Ausgabe wurde mit (result.)Options = 1 ausgegeben.

Options = 2 setzen und/oder schauen das die Datei AVRootloader.dev auf 
den neusten Stand ist. Dein Auszug oben sieht gut aus und die einzige 
Erklärung ist die das die PC-Software aus den gesendeten Signaturdaten 
nicht die Infos zum richtigen AVR aus der AVRootloader.dev Datei laden 
kann.

Gruß Hagen

von Tim O. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moment..

Mit der Software geht es ja... benötigt die DLL denn überhaupt das DEV
File ?

Das connect-Problem hab ich mit der DLL, nicht mit der "originalen" 
(=deiner) Software.

Der Auszug ist aus dem Memo-Feld, das zu debugging-Zwecken in meine 
Software
gesetzt wurde.

GRuss,
Tim

von Tim O. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
... ja, die DLL braucht die DEV Datei ...

... mit derselben DEV Datei wie im Windows-Ordner in "meinen Ordner"
kopiert funktioniert es nun... argh.. seltsamerweise war sogar ne DEV
Datei vorhanden die ich sicher nicht hinkopiert hatte), nur 74 Byte 
gross..

Gruss,
Tim

von Manuel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mein Programm das ich mit den BOOTLOADER drauf geladen hat wird immer 
nur 2 sek ausgefürt danach startet sich das Programm neu habt ihr ein 
Lösungsvorschlag?

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Watchdog zurücksetzen oder in main() am Anfang deaktivieren, falls du 
ihn nicht per Fuses permanent aktiviert hast.

Gruß Hagen

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,
bin gerade mit Delphi User interface und Flashen von Acy Dateien 
beschäftigt.
Funktioniert auch ganz gut indem ich einfach alles rübersende, aber ein 
bisschen würde ich gern verstehen, was ich da mache.
"AVRootloader"
$06 (Bottloaderversion?)
$26 (??)
"ACYInfo"
$20 (Leerzeichen?)
"1.0.0.0" (Version Software)
$00 (Terminierung?)
$1E$xx$xx (Device Sign)
$00 (??)
$0F (??)
$06 (??)
$00 (??)
$2F (??)
Ab hier Befehle $FE $FE $XX $XX... Datenblöcke und Kommandos

1. Gibt es irgendwo eine Doku über den Aufbau der Datei?
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).

Wäre nett, wenn Du etwas die ?? aufklären könntest ...
Vielen Dank!

von Franz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,
ich habe mit der DLL die gleichen Probleme wie Tim O. Mit Deiner 
Anwendung
funktioniert alles. Mit der DLL bekomme ich einfach keine Verbindung. 
Ich habe bei dem Demo-Programm aber nur den COM-Port verändert.
Als Prozessor verwende ich einen Mega328P mit 20MHz.
Ich würde die DLL gerne mit einem Konfigurationsprogramm an dritte 
weitergeben. Darf man diese als Freeware weitergeben oder gibt es hier
eine Lizenzbestimmung.

Vielen Dank für Deine Antworten.

von Tim O. (tim_o)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Franz.

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

Gruss
Tim

von Andreas B. (Gast)


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

Hi Leute,
 Ich habe ebenso ein Multiprozessor System mit 4 ATmega8 (bzw. 
ATmega168) die ich am liebsten in einem Rutsch flashen würde. Der 
Bootloader funktioniert so weit prima auf einem Controller.
Da ich die RXD und TXD Leitungn jedes Controllers über 1k Widerstände 
miteinander verbunden habe dachte ich mir ich könnte jeden Controller 
mit einer unterschiedlichen individuellen "Bootsign" versehen und dann 
individuell mit der Programmiersoftware ansprechen.
Leider erzeugen alle Bootloader beim Empfang auf RXD auf TXD ein Signal 
und der "angesprochene" kommt nicht durch.
Hat jemand eine bessere Idee wie man das geschickt lösen kann?

Grüsse,
Andreas

von Andreas B. (ichwillnix)


Bewertung
0 lesenswert
nicht lesenswert
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:
BootSign: .db "BOOTLOAD01" ; alle weitern haben BOOTLOAD02,03,04 etc.
BootMsg:  .db "Controller No. 1 (2,3,4)"
BootInfo: .db SIGNATURE_001, SIGNATURE_002, BootVersion, BootPages

Zudem werden noch in der AVRotloader.ini die BootSigns bekant gemacht:
[Signs]
0=BOOTLOAD01
1=BOOTLOAD02
2=BOOTLOAD03
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. Power-off
2. In AVRootloader.exe die jeweilige sign auswählen z.B. "Bootload01".
3. Connect to device klicken
4. Power-On (jetzt connected sich der jeweilige controller)
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).
:start
echo #----------------------------------------------------#
echo Power aus und einschalten (PORST)
fboot.exe /c1 /b9600 /pHk_I2Cm1.hex /iBOOTLO01
if errorlevel 1 goto error
echo Controller 1 erfolgreich geflashed
echo #----------------------------------------------------#

echo Power aus und einschalten (PORST)
fboot.exe /c1 /b9600 /pHk_I2Cm2.hex /iBOOTLO02
if errorlevel 1 goto error
echo Controller 2 erfolgreich geflashed
echo #----------------------------------------------------#

echo Power aus und einschalten (PORST)
fboot.exe /c1 /b9600 /pHk_I2Cm3.hex /iBOOTLO03
if errorlevel 1 goto error
echo Controller 3 erfolgreich geflashed
echo #----------------------------------------------------#

echo Power aus und einschalten (PORST)
fboot.exe /c1 /b9600 /pHk_I2Cm4.hex /iBOOTLO04
if errorlevel 1 goto error
echo Controller 4 erfolgreich geflashed
echo #----------------------------------------------------#

echo Fertig!
echo PORST machen und
echo beliebige Taste zum Beenden druecken
pause
goto ende

:error
echo das flashen war leider nicht erfolgreich!
echo mit beliebieger Taste neu starten
pause
goto start

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

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sollte doch eigentlich schon gehen:
-A Automatikmodus/Befehle für den Bootloader
 e erase, lösche FLASH vor dem Programmieren, wird diese Option nicht angegeben so gelten die Einstellungen in AVRootloader.exe
 p program, schreibe FLASH/EEPROM mit der Datei die bei -F/-E angegeben wurde
 v verify, Überprüfe den FLASH Inhalt, wird diese Option nicht angegeben so gilt das was in AVRootloader.exe eingestellt wurde
 c close, Beende AVRootloader nach den Aktionen, aber nur falls keine Fehler aufgetreten sind

von Andreas B. (ichwillnix)


Bewertung
0 lesenswert
nicht lesenswert
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:
AVRootloader.exe -Apc -PCOM1 -SBOOTSIGN01 -FFIRMWARE01.hex

Viel Grüsse!

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Guten Tag ;)
hab ein kleines Problem mit dem Bootloader,
Wenn ich den SourceCode mit .set  BootCodeSize    = 0 Kompiliere klappt 
Alles!
Wenn ich dann aber den Wert aus .cseg Eintrage also:
.set  BootCodeSize    = 8192

bricht er mit nem Error ab:

C:\Dokumente und 
Einstellungen\chris\Desktop\AVRootloader\AVR\AVRootloader.asm(75): 
Including file 'C:\Programme\Atmel\AVR 
Tools\AvrAssembler2\Appnotes\m8def.inc'
C:\Dokumente und 
Einstellungen\chris\Desktop\AVRootloader\AVR\AVRootloader.asm(143): 
compile for ATmega8
C:\Dokumente und 
Einstellungen\chris\Desktop\AVRootloader\AVR\AVRootloader.asm(211): 
Including file 'C:\Dokumente und 
Einstellungen\chris\Desktop\AVRootloader\AVR\AVRootloader.inc'
C:\Dokumente und 
Einstellungen\chris\Desktop\AVRootloader\AVR\AVRootloader.asm(216): 
error: Overlap in .cseg: addr=0x0 conflicts with 0x0:0x1
C:\Dokumente und 
Einstellungen\chris\Desktop\AVRootloader\AVR\AVRootloader.asm(796): 
Including file 'C:\Dokumente und 
Einstellungen\chris\Desktop\AVRootloader\AVR\Special.inc'

Assembly failed, 1 errors, 0 warnings

Hat jemand nen Idee was da schief läuft?

lg

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Chris, Du musst den wert von USED nicht den von SIZE !

HTH

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ups, Stimmt ;) bin ich blöd. Danke hehe

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen
wäre schön, wenn Du bei Gelegenheit auch mein Posting mal anschauen 
könntest... Beitrag "Re: AVR-Bootloader mit Verschlüsselung"
Ist wohl untergegangen bei alle Posts hier momentan. ;)
Grüße

von Hagen R. (hagen)


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

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Hagen: Danke für die Info schon mal!

von Nicolas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hagen, erstmal vielen Dank für den Superbootloader mit dem schönen 
Frontend!

Ich habe eine Frage:

Ich hab den Bootloader mit einem Mega88 im OneWire-Modus benutzt. Mein 
Hauptprogramm ist sehr einfach und zählt nur cycles und schaltet 
einzelne Ports (sowas wie ein Pulsgenerator). Ausgelöst wird es durch 
INT0. Mit ISP programmiert reagiert es innerhalb der vorgesehenen Zeit 
(~2mu s). Wenn die Bootloaderfirmware drauf ist, kommt es ab und an 
(etwa bei jedem 20. Trigger) zu einem "Aussetzer", d.h. der Interrupt 
wird anscheinend nicht ausgelöst. Kann sowas durch den Bootloader 
kommen? Pollt der den Pin für die serielle Kommunikation?

Ich hab es jetzt mit Peter Daneggers Bootloader probiert, da tritt das 
nicht auf. Und da wird ja ein reset benötigt zum flashen.

Nochmal vielen Dank!

Viele Grüße

Nicolas

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du UseWDT=1 im Bootloader aktiviert hast dann benutzt dieser den 
WatchDog Timer. In deiner Anwendung musst du diesen entweder 
deaktivieren oder regelmäßig zurücksetzen (WDT Opcode). Andere 
Alternative ist es mit UseWDT=0 den Bootloader zu kompilieren. 
Allerdings würde ich dir das nicht anraten da mit dem WDT der Bootloader 
viel robuster=sicherer arbeitet. Besonders eben wenn es zu 
unvorhersehbaren Störungen kommt, die ja immer nur per WDT, als letztes 
Mittel, behandelt werden können.

Peters Bootloader nutzt den WDT nicht soviel ich weiß.

So bald deine Anwendung angesprungen wurde ist der Bootloadercode 
absolut inaktiv.

Gruß Hagen

von Nicolas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

das wars tatsächlich - jetzt läuft es wie vorgesehen!

Danke und Viele Grüße

Nicolas

von hige (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

bin echt ein großer Fan deines Bootloaders.
Leider hab ich gerade ein Problem damit.

Ich habe eine Schaltung, die ich mit Atmega8 und Atmega168 betreiben 
will.
Je nach Softwareumfang.

Hab ein serielles Kabel nach der Onewire Anleitung umgebaut (Dioden).

Wenn ich den Bootloader für den Atmega8 erstelle und Flashe, klappt 
alles wunderbar. Wenn ich aber das selbe für den Atmega168 mache, findet 
AVRootloader den Controller wohl nicht.

Wie gesagt, die Schaltung und das Kabel sind immer die gleichen. Daran 
kann es nicht liegen. Am µC kann es auch nicht liegen.

Wenn ich den Atmega168 in nem Entwicklerboard mit MAX232 und nicht 
Onewire-Mode teste, klappt es auch.

Weiß leider nicht weiter.

Grüße,
Hige.

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Beide Bootloader benutzen ein anderes BootSign und sind ansonsten in den 
Kommunikationsparametern identissch konfiguriert ?

Gruß Hagen

von hige (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

ich hab in der avrootloader.asm nur den jeweiligen Controller 
ausgewählt.
Die Fuse hab ich auch richtig gesetzt, habs x-mal kontrolliert.

von hige (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hagen schrieb:
> Beide Bootloader benutzen ein anderes BootSign

Die Controller befinden sich nicht gleichzeitig in der Schaltung. Ich 
verwende entweder den Mega8 oder Mega168.
Mega8 funktioniert ohne Probleme.
Mega168 funktioniert leider nicht.

von daniel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der Bootblock funktioniert soweit, Kommunikation läuft, SRAM, EEPROM 
lesen und Flash löschen geht auch. Sobald ich aber was programmieren 
will schmiert die Kommunikation ab (siehe Log).
Was muss ich ändern?

Gruß,
Daniel
17.06.10-17:26:14-129 > Connecting on port COM2...
17.06.10-17:26:14-129 > Timeout.Connect       = 100 ms
17.06.10-17:26:14-129 > Timeout.Base          = 100 ms
17.06.10-17:26:14-129 > Timeout.Erase         = 10 ms
17.06.10-17:26:14-129 > Timeout.Flash         = 25 ms
17.06.10-17:26:14-129 > Timeout.Eeprom        = 10 ms
17.06.10-17:26:14-129 > Timeout.Buffer        = 1 ms
17.06.10-17:26:14-129 > Timeout.AppCmd        = 0 ms
17.06.10-17:26:14-129 > Timeout.KeepAlive     = 500 ms
17.06.10-17:26:14-129 > Timeout.RTSPulse      = 0
17.06.10-17:26:14-129 > Timeout.RTSInterval   = 0
17.06.10-17:26:14-129 > Timeout.ConnectTrials = -1
17.06.10-17:26:14-129 > Timeout.MaxPacketSize = 0
17.06.10-17:26:14-129 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
17.06.10-17:26:14-534 > received data   $95 02 06 04 30
17.06.10-17:26:14-534 > Timer created
17.06.10-17:26:14-534 > Device connected
17.06.10-17:26:15-049 > send keepalive
17.06.10-17:26:15-548 > send keepalive
17.06.10-17:26:16-063 > send keepalive
17.06.10-17:26:16-297 > Timer released
17.06.10-17:26:16-297 > Reading SRAM...
17.06.10-17:26:19-105 > Timer created
17.06.10-17:26:19-604 > send keepalive
17.06.10-17:26:20-119 > send keepalive
17.06.10-17:26:20-244 > Timer released
17.06.10-17:26:20-259 > Reading EEPROM...
17.06.10-17:26:21-617 > Timer created
17.06.10-17:26:22-131 > send keepalive
17.06.10-17:26:22-646 > send keepalive
17.06.10-17:26:22-880 > Timer released
17.06.10-17:26:22-880 > Erase FLASH...
17.06.10-17:26:24-003 > FLASH erased in 1,12 sec
17.06.10-17:26:24-019 > Timer created
17.06.10-17:26:24-518 > send keepalive
17.06.10-17:26:25-033 > send keepalive
17.06.10-17:26:25-532 > send keepalive
17.06.10-17:26:25-579 > Timer released
17.06.10-17:26:25-579 > Program...
17.06.10-17:26:25-579 > execute compiled data
17.06.10-17:26:25-579 > selected options in compiled file:
17.06.10-17:26:25-579 > - programming FLASH
17.06.10-17:26:25-579 > - erase FLASH during programming
17.06.10-17:26:29-479 > Cmd.SetBuffer.ReadByte() ICOM: read error.
17.06.10-17:26:29-495 > Timer created
17.06.10-17:26:30-015 > send keepalive
17.06.10-17:26:30-115 > Timer released
17.06.10-17:26:30-115 > keepalive failed, terminate connection
17.06.10-17:26:30-215 > Device disconnected

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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 ?

von Charly B. (charly)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Nicht Gast (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gebe doch einfach den Quellcode Deiner Exe raus, so kann er sich den 
Progger selber umschreiben wie er ihn braucht!

von daniel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,
danke für die schnelle Antwort. Ja, ich benutze einen USB-RS232 Wandler 
(PL2303). Deswegen ist der Timeout bereits so weit oben. Den 
Flashtimeout (und sämtliche anderen Timeouts) hab ich schon um 
Dimensionen erhöht, hat leider nichts gebracht.
Der Fehler tritt nur bei Verify und Flash auf. :/
Gruß,
Daniel (Nicht Higi)

von daniel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hier noch als Nachtrag die wechselnden Fehlermeldungen:

18.06.10-01:15:57-758 > - programming FLASH
18.06.10-01:15:58-627 > Cmd.SetBuffer.ReadByte() ICOM: read error.
..
18.06.10-01:16:01-367 > - programming FLASH
18.06.10-01:16:01-881 > Cmd.SetBuffer.ResCheck(2)  Error: 00 operation 
failed
..
18.06.10-01:16:04-652 > - programming FLASH
18.06.10-01:16:05-522 > Cmd.SetBuffer.ReadByte() ICOM: read error.
..
18.06.10-01:16:07-835 > - programming FLASH
18.06.10-01:16:08-335 > Cmd.SetBuffer.WriteData() ICOM: write error.
..
18.06.10-01:16:10-786 > - programming FLASH
18.06.10-01:16:10-887 > Cmd.SetAddr.ReadByte() ICOM: read error.
..

Komische Sache, hm?

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


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

Gruß Hagen

von My D. (mydani)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@hige:

>ich hab in der avrootloader.asm nur den jeweiligen Controller
>ausgewählt.

und dann

1.) BootCodeSize = 0 geändert
2.) erneut alles kompiliert
3.) aus CSeg Used im Messagewindow vom AVRStudio den Wert in 
BootCodeSize geschrieben
4.) alles nochmals kompiliert

?

Gruß Hagen

PS: wenn nicht dann

5.) den Thread hier und die Readme nochmals gelesen ? ;)

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Daniel: somit steht es geschätzte 534 zu 1 für die Fehlerquote bei den 
Anwendern zu AVRootloader ;)

von My D. (mydani)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es ist schwer objektive Aussagen zu machen. Das einizige Projekt bei dem 
ich mal die gleiche Library in C und handmade Assembler programmiert 
habe war meine Nokia Grafik Library. Entwickelt in WinAVR GCC einmal als 
fast reiner C Source und einmal als handmade Assembler aber auch in 
WinAVR GCC.
Ergebisse waren:
1.) Assembler war nur 50% so groß
2.) Assemblerversion war weitaus schneller in der Ausführung
3.) der nutzbare Funktionsumfang der Assemblerversion ist größer

Aber alle Punkte waren das Resultat der gewonnenen Freiheiten die man im 
Assembler hatte. Zb. wurde in der Assemblerversion die 
Aufrufkonventionen der einzelnen Funktionen und die dabei benutzten 
Register/Stack usw. so manuell verteilt das es auch in den 
übergeordneten Funktionen nicht notwendig war diese Register zu sichern. 
Dann gibt es Zeichenroutinen zb. für Ellipsen und Linien die in C intern 
mit 32Bit Variablen rechnen mussten. In Assembler konnte das aber so 
optimiert werden das zb. nur 24Bit Berechnungen nötig waren. Desweiteren 
gibt es verschiedene Funktionen die im Grunde sich nur in den Parametern 
unterschieden und dann immer die gleiche Unterfunktion aufrufen. Hier 
kann man im Assembler einigen an unötigem Code wegoptimieren indem man 
die Einsprungpunkte quasi inmitten einer Basisfunktion legt. Das spart 
im Vergleich zum C Compiler ne Menge an Stackrame, Register sichern, 
CALLs und sogar RETs.

Alles zusammen genommen bewirkte also obige drei Resultate. Die dazu 
benutzten Optimierungen zeigen aber auch deutlich das bewusst die 
technologisch bedingten Schwachstellen des Compiliers ausgenutzt wurden. 
Und somit ist der Vergleich C Copmiler vs. Mensch und Assembler unfair 
und wenig aussagekräftig. Wir Menschen sind immer noch besser als die 
Maschinen.

Übrigens falls das Argument kommt: Mit dem C Compiler wäre man 
schneller. Das ist in diesem Falle nicht so gewesen. Da ich zuerst die C 
Version gebaut habe, mich sowohl in C, den C Compiler Eigenheiten gut 
auskennen und weiß was der C Compiler in Assembler hätte optimalerweise 
erzeugen können, wusste ich bei der Asseblerversion von Anfang an was 
ich wie exakt wollte. Das Schreiben der Assemblerversion hat mich weit 
weniger Zeit, < 2 Tage, gekostet. Aber auch hier wieder das Argument das 
es ohne die vorherige C Version und der Vorarbeit des C Compilers eben 
nicht so gewesen wäre.

Den AVRootloader.asm Source habe ich nach den gleichen Regeln codiert 
und ich bin mir ziemlich sicher das eine reine C Version mindestens 
doppelt so groß wäre. Verzichtet man auch alle zusätzlichen Funktionen 
in AVRootloader so ist dieser schon sehr kompakt, ca. 360 Bytes groß. 
Selbst für einen erfahrenen ASM Programmierer dürfte es schwierig sein 
da noch > 32 Bytes rauszuholen (und nur das macht Sinn auf Grund der 
Pagesize des FLASHs).


Gruß Hagen

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und um Diskussionen über Sinn und Unsinn eines solchen Aufwandes 
vorzubeugen. Ja, beim AVRootloader, der ja alle selbst programmierbaren 
AVRs unterstützt ist es schon wichtig auch auf die geringste Codegröße 
hin zu programmieren. Als Zielsetzung wars von Anfang an auch die 
kleinen AVRs angestrebte oberste Priorität. Damit ist die Wahl der 
Mittel defakto entschieden.

Gruß Hagen

von My D. (mydani)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nö das geht in beide Richtungen. Klar ist jedoch das man die 
Aufrufkonventionen festlegen und beachten muß. Aber das ist nicht das 
Problem da das auch bei Assemblerstücken innerhalb eines C Projektes der 
Fall ist.

Ich sehe es so: beides sind Werkzeuge, ein Mittel um ein Ziel zu 
erreichen. Die unterschiedlichen Möglichkeiten beider Werkzeuge erhöhen, 
clever benutzt, doch nur die Flexibilität die wir uns leisten können um 
eben das Ziel zu erreichen.

Eine Diskussion über das für und wider, ob C, Delphi, Assembler, VHDL 
usw. exitiert für mich garnicht, bzw. ist am Thema vorbei.
Am besten man beherrscht alle und nutzt sie als Mittel zum Zweck, es 
sind eben nur Werkzeuge. Das wäre ja so als ob man sich streitet das nun 
die Statue der Athene viel besser künstlerisch aussehen würde wenn man 
statt Hammer und Meisel einen elektrischen Vorschlaghammer genommen 
hätte. Der künstlerische Anspruch, warum uns die Athene gefällt, hat 
doch nichts mit den benutzten Werkzeugen primär zu tun. Punkt.

Gruß Hagen

von Hige (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hagen schrieb:
> und dann
>
> 1.) BootCodeSize = 0 geändert
> 2.) erneut alles kompiliert
> 3.) aus CSeg Used im Messagewindow vom AVRStudio den Wert in
> BootCodeSize geschrieben
> 4.) alles nochmals kompiliert
>
> ?

Ja, so mach ich es immer. Nutze deinen Bootloader nicht zum ersten mal. 
Verstehs auch nicht. Werd die Onewire-Verbindung mal in einem anderen 
Board testen.

Grüße Hige

von Charly B. (charly)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Charly B. (charly)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Vlad T. (vlad_tepesch)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
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

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,
schade, falls Du doch noch mal Zeit/Lust haben solltest ein bisschen 
Doku zu machen, würde ich Dich an mein Post vom 30.04 erinnern: 
[Beitrag "Re: AVR-Bootloader mit Verschlüsselung"]

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Achim X. (hallali)


Bewertung
0 lesenswert
nicht lesenswert
Na dann spann mal erst aus!
PN gerne, wenn Du soweit bist.

Gruß
Achim

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Hagen R. (hagen)


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

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

von Vlad T. (vlad_tepesch)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
11.07.10-12:09:17-218 > Connecting on port COM4...
11.07.10-12:09:17-218 > Timeout.Connect       = 50 ms
11.07.10-12:09:17-218 > Timeout.Base          = 50 ms
11.07.10-12:09:17-218 > Timeout.Erase         = 10 ms
11.07.10-12:09:17-218 > Timeout.Flash         = 15 ms
11.07.10-12:09:17-218 > Timeout.Eeprom        = 10 ms
11.07.10-12:09:17-218 > Timeout.Buffer        = 1 ms
11.07.10-12:09:17-218 > Timeout.AppCmd        = 0 ms
11.07.10-12:09:17-218 > Timeout.KeepAlive     = 250 ms
11.07.10-12:09:17-218 > Timeout.RTSPulse      = 0
11.07.10-12:09:17-218 > Timeout.RTSInterval   = 0
11.07.10-12:09:17-218 > Timeout.ConnectTrials = -1
11.07.10-12:09:17-218 > Timeout.MaxPacketSize = 0
11.07.10-12:09:17-234 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
11.07.10-12:09:17-437 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
11.07.10-12:09:17-640 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
[...  (bis auf die Zeiten immer das gleiche)]
11.07.10-12:09:28-421 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
11.07.10-12:09:28-625 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
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.

von Achim X. (hallali)


Bewertung
0 lesenswert
nicht lesenswert
Suppi!!! Danke herzlichst Hagen!

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

Ich kopiers mir ;-)

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
>> - 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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
>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

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
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:
11.07.10-13:44:49-484 > Connecting on port COM4...
11.07.10-13:44:49-484 > Timeout.Connect       = 50 ms
11.07.10-13:44:49-484 > Timeout.Base          = 50 ms
11.07.10-13:44:49-484 > Timeout.Erase         = 10 ms
11.07.10-13:44:49-484 > Timeout.Flash         = 15 ms
11.07.10-13:44:49-484 > Timeout.Eeprom        = 10 ms
11.07.10-13:44:49-484 > Timeout.Buffer        = 1 ms
11.07.10-13:44:49-484 > Timeout.AppCmd        = 0 ms
11.07.10-13:44:49-484 > Timeout.KeepAlive     = 250 ms
11.07.10-13:44:49-484 > Timeout.RTSPulse      = 0
11.07.10-13:44:49-484 > Timeout.RTSInterval   = 0
11.07.10-13:44:49-484 > Timeout.ConnectTrials = -1
11.07.10-13:44:49-484 > Timeout.MaxPacketSize = 0
11.07.10-13:44:49-484 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
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
11.07.10-13:44:49-703 > Switch to 1-Wire mode
11.07.10-13:44:49-703 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
11.07.10-13:44:49-921 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
11.07.10-13:44:50-125 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
11.07.10-13:44:50-328 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
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.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
ich habe jetzt mal ganz am Anfang des Bootloaders folgenden Code 
eingebaut:

.org BootStart
init:
    cli
    xwdr
    clr   zerol
    
    sbi   DDRC,0    ; die 
    sbi   PORTC,0   ; und die


    ldi   cmdl, byte1(RamEnd)

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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
jupnöö, also jain, oder Ja und Nein. Blöde Fragestellung.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


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

Gruß Hagen

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
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
[...]
.endif ; .if UseAutobaud

    sbi   DDRC,  1  ;  von mir
    sbi   PORTC, 1  ;  von mir
    ldi   paral,'H' ;  von mir
    rcall putc;     ;  von mir

; identifier (BootSign) scanning with timeout and checksum
[...]

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?

von Favian D. (Firma: vsilicon) (ikhwan_h17f)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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 ;)

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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.
[...]
.endif ; .if UseAutobaud

    sbi   DDRC,  1  ;  von mir
    sbi   PORTC, 1  ;  von mir
    ldi   paral,'H' ;  von mir
    rcall putc;     ;  von mir

; identifier (BootSign) scanning with timeout and checksum
[...]

Das bringt garnichts. Die wichtigen Parameter für "putc" und damit 
SW-UART sind noch garnicht initialisiert.
; fixed baudrate
    ldi    yl, byte1(Baudrate)
    ldi    yh, byte2(Baudrate)
    movw  baudl, yl
.endif ; .if UseAutobaud

; identifier (BootSign) scanning with timeout and checksum

;id1:  sbiw  xl, 
;...    brne  id1
;... alles auskommentieren
  
; send info about chip/bootloader (BootMsg + BootInfo)
info:  ldi    parah, (BootInfo - BootSign) * 2 +4
in1:  xlpm  paral, z+
    rcall  putc
    dec    parah
    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

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
;) @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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Favian D. (Firma: vsilicon) (ikhwan_h17f)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
>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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Favian D. (Firma: vsilicon) (ikhwan_h17f)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
@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.

13.07.10-16:30:26-843 > Connecting on port COM4...
13.07.10-16:30:26-843 > Timeout.Connect       = 500 ms
13.07.10-16:30:26-843 > Timeout.Base          = 500 ms
13.07.10-16:30:26-843 > Timeout.Erase         = 100 ms
13.07.10-16:30:26-843 > Timeout.Flash         = 150 ms
13.07.10-16:30:26-843 > Timeout.Eeprom        = 100 ms
13.07.10-16:30:26-843 > Timeout.Buffer        = 10 ms
13.07.10-16:30:26-843 > Timeout.AppCmd        = 0 ms
13.07.10-16:30:26-843 > Timeout.KeepAlive     = 2500 ms
13.07.10-16:30:26-843 > Timeout.RTSPulse      = 0
13.07.10-16:30:26-843 > Timeout.RTSInterval   = 0
13.07.10-16:30:26-843 > Timeout.ConnectTrials = -1
13.07.10-16:30:26-843 > Timeout.MaxPacketSize = 0
13.07.10-16:30:26-859 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54
13.07.10-16:30:27-500 > received data   $94 06 06 04 30
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
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.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
>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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
>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.)
void bootloader_start_jump(void) {

    asm volatile("jmp -2");
}

void bootloader_start_wdt(void) {

    cli();
    wdt_reset();
    _WD_CONTROL_REG = (1 << WDE) | (1 << _WD_CHANGE_BIT);
    _WD_CONTROL_REG = (1 << WDE);
    for (;;);
}


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

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Jo steht alles hier im Thread, mehrmals sogar.

von Arne H. (piowux)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von Arne H. (piowux)


Bewertung
0 lesenswert
nicht lesenswert
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

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
@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)

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von MartinS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen, Hallo an andere 1-wire Nutzer!

Ich habe ein kleines Problem in der 1-wire Nutzung sobald ich mehrere 
Mega8 am gleichen Draht habe. Habe hier Brushlessregler, jeder hat noch 
einen 220R vor dem einzigen Nutzbaren Pin (PD1/RXD).

Dazu die letzt Schaltung aus dem Wiki an einem FTDI Breakout von 
Sparkfun, 2k7 zwischen FTDI TX & RX, FTDI RX and AVR-RX/Bootloaderpin 
und noch ein 100k Pullup. TTL Pegel, UartInvert =1 und die Sache 
funktioniert soweit auch.

Auch wenn nur 1 Regler angeschlossen ist komme ich nicht immer sofort in 
den Bootloader, muss immer wieder 3-4x den AVR resetten um in den 
Connected-Status zu kommen, ist er aber mal connected bleibt er das aber 
auch tagelang, flashen funktioniert,... ist das so normal - das mehrfach 
reset's notwendig sind...?

Und jetzt geht es daran, mehrere der Regler über den Bootloader 
anzusprechen. GND und die Bootloader-Pins verbinden und an die Schaltung 
die am FDTI hängt dran. Hier hätte ich maximal bedenken das bei n 
Reglern die nx vorgeschaltenen 220R ein Problem sind.

Jeder hat seine eigene ID (BLCLOADER1..8) und kann einzeln auch 
angesprochen werden.

Sobald ich einen 2ten Regler anschließe, komm ich nicht mehr zum 
connect, egal wie oft ich die AVRs resette, die PC-Anwendung geht nie in 
den Connected-Status. Im Testaufbau habe ich die Verbindung über ein 
Steckbrett, trenne ich hier den 2. Regler, sodaß nur ein AVR verbunden 
ist, komme ich sofort wieder in den connected-status. Bin ich in diesem 
und verbinde dann den 2ten regler, so bleibt alles connected und ich 
kann, trotz des 2ten Reglers flashen. Connected-Status kann ich mit 
Disconnect beenden, oder den Regler 1 abstecken, dann wird dies auch 
erkannt.

D.h. ich gehe davon aus, das sich die AVR betreff kommunikation nicht in 
die quere kommen (die Regler-Soft aktiviert den UART-RX), sonst würde ja 
die Kommuniktation beim Flashen, der Keepalive,... nicht funktionieren.

Nur warum kann ich nicht connecten?

Hat irgendjemand ein ähnliches Problem? Hab hier zwar ein paar Stunden 
gelesen, aber in diesem langen Thread nichts dazu gefunden, bzw. 
hoffentlich nichts übersehen?

Danke für die Unterstützung & lG, Martin.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas O. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

ich benutzte dein prg sehr gerne. Auch von mir ein super Danke für 
dieses tolle Tool. Ich glaube einen kleinen Fehler entdeckt zu haben.
Wenn ich AVRootloader per Batch aufrufe und ein '-' (Minuszeichen) im 
Pfad oder Dateinamen sich befindet, wird danach alles abgeschnitten und 
es geht natürlich nicht mehr weiter! Tausche ich alle 'Minus' z.B. gegen 
ein Unterstrich aus, gehts.

MfG. Tom

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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.

von Arne H. (piowux)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
@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

von MartinS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Hagen:

Danke für die rasche Rückmeldung, hatte nur selbst nicht eher Zeit ;)

UseAutoBaud hatte ich schon auf 1,
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.
BootDelay hatte ich schon auf XTAL/2 bzw. 500ms.

[TimeOuts] Base=25 ist in Zusammenhang mit 57600 Baud in 95% der Fälle 
sofort beim ersten Reboot vom AVR erfolgreich - also mehr als 
ausreichend!

Beim 1-wire Problem hatte ich schon mal mit/ohne Pullup/down probiert... 
Hab jetzt unterschiedliche Werte ausprobiert, bei 2 Reglern funktioniert 
es mit einem 10k Pulldown mit sehr guter Connect-Rate!

In diesem Sinne DANKE für diesen genialen Bootloader!!!

lG, Martin.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
>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

von Bernd (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wo finde ich denn eine aktuelle Version? oder ist die aus dem ersten 
Beitrag aktuell?

von David Ferrer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hello,

I was looking for an alternative to AVR231 bootloader with encryption,
and Luiz told me about this one he is very happy with.

I see that ATmega328 is not in the list of supported devices.
What do I need to do in order to make it work for ATmega328?

ps: sorry I don't speak German. I started learning, but I am quite far 
from writing it.


Best regards,
David

von Hagen R. (hagen)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
.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

von David Ferrer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Many thanks for the update!

One more question,
when I send the encrypted firmware to someone,
he needs to update the firmware using the AVRootloader.exe, right?

Is the source code of AVRootloader.exe available (the part for updating 
the firmware to the microcontroller)?
(I would need to integrate the feature of updating the firmware in my 
own GUI)


Regards,
David

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
3.) i provide a AVRootloader.dll that export some DCOM/COM interfaces 
with all functionality needed of the bootloader, without any GUI. If you 
understand Delphi/PASCAL then you can in this way access with any other 
programming language that supports DCOM/COM/ActiveX interfaces the 
functionality of the bootloader.

Best reagrds, Hagen

von David Ferrer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hello Hagen,

Thanks again for your answer!

Sending the firmware by USB "emulated RS232" has the problem that the 
user needs to install a driver such as this one: D2XX Direct Drivers: 
http://www.ftdichip.com/Drivers/D2XX.htm

I saw that this AN10711 bootloader emulates a Mass Storage Class Device, 
so no drivers need to be installed. Then the user (or the application) 
updates the firmware by directly copying it to the MSCD.
http://www.nxp.com/documents/application_note/AN10711.pdf

Would it be possible to combine such a bootloader with the encryption?

It's just an idea; I don't really have the budget to finance it. :'-)


Regards,
David

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
>Would it be possible to combine such a bootloader with the encryption?

yes if you have access to the source you can implement anything you 
want.

As example should it possible to use a AVR that support USB. We have 
basicly to implement in AVRootloader.asm only USB initialization and two 
io-functions. But then you need even a driver for this custom USB device 
on your PC and the AVRootloader.exe must be rewritten or a VCOM driver 
to the custom USB driver must be written. Thus, useing todays 
mass-products like common USB-RS232 cables are most times cheaper.

Best regards, hagen

von Bennj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Hagen,

Versuche grad den Bootloader am ATMega128 auf PortF aber ich bekommen 
immer:

C:\Data\AVR\AVRootloader.inc(308): error: Operand 1 out of range: 0x60


Gehts generell nicht oder mach ich was falsch ?

Sonst erstmal vielen danke für diese geniale Arbeit

Gruß

von Arne H. (piowux)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

gerade wollte ich ein neues acy-File erstellen, musste aber festellen, 
dass alle relevanten Buttons hierfür deaktiviert waren, obwohl ich mich 
ordnungsgemäß verbinden konnte.

Es sind die Buttons Program, Verify und Compile grau.

Eine passende main.hex ist ausgewählt und existiert. Die Verbindung 
funktioniert und es sind sinnvolle Device informationen aufgelistet:

Connection                     : 2-Wire
Device name                    : ATmega8, ATmega8A
Device signature               : 1E9307
SRAM size                      :   1024 Byte
EEPROM size                    :    512 Byte
FLASH size                     :   8192 Byte
FLASH size for application     :   7168 Byte
FLASH pagesize                 :     64 Byte
Bootloader size                :   1024 Byte
Buffersize for data            :    984 Byte
SRAM start address             :     96
Bootloader version             :      6
Use bootsection                :    Yes
Versioning supported           :     No
Cryptography supported         :     No
Bootloader information         : (c) abcdef

Hat jemand eine Idee?

Viele Grüße,

Arne

von Arne H. (piowux)


Bewertung
0 lesenswert
nicht lesenswert
Ok ich habs. Als ich das Zeilenende der Hex-Datei von win auf unix und 
dann wieder auf win geändert hatte, ging es. Scheinbar gab es ein 
Problem mit dem Zeilenendenformat. Nachdem ich die Hex-Datei aber neu 
erzeugt hatte gings plötzlich ohne Probleme. Aber scheint so, dass das 
Programm ein Problem mit dem Zeilenende hat.


Viele Grüße,

Arne

von GierigeSau (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Bootloader-Freunde :)
Erstmal Respekt für die tolle Arbeit.
Ich habe leider ein Problem. Ich versuche die oben gepostete Delphi 
Source anzupassen. Ich benötige auch eine "Ein Button Bootloader" 
Version. Leider bekomme ich mit der Delphi File keinen Kontakt. Aktuelle 
Version läuft, also Hardware in Ordnung. Habe die aktuelle .ASM und die 
alte "beiliegende" probiert. Ports jeweils angepasst, Takt eingestellt, 
Fuse so stehen gelassen wie es mit der aktuellen funktioniert. Was ich 
merkwürdig finde, die aktuelle Version schickt ja ein "BOOTLOADER" über 
die Serielle Schnittstelle (FTDI-USB FT232RL) was ich auch über ein 
Terminalprogramm mithören kann. Die "Delphi-Version" oben schickte erst 
ein "BOOT" was ich in "BOOTLOADER" geändert habe. Trotzdem ohne Erfolg. 
Wer kann mir helfen und mir evtl mal eine "Ein Knopf" Source Version 
schicken?

Vielen Dank. MFG

von Alfred (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe leider auch ein Problem mit dem Bootloader. Ich versuche schon 
seit Stunden einen Bootloader für mein Mega128-Projekt zu finden. Hier 
sind
mein Einstellungen:


.include "m128def.inc"
.equ  UseBootMode      = 2
.equ  UseWDR        = 0
.equ  UseSaveMCUSR            = 1
.equ  UseE2Write      = 0
.equ  UseE2Read      = 0
.equ  UseCrypt      = 0
.equ  UseCryptFLASH             = 0
.equ  UseCryptE2      = 0
.equ  UseVerify      = 0
.equ  UseVersioning            = 0
.equ  UseSRAM        = 0
.equ  UseSpecialBootVect          = 0
.equ  UseSpecialWrite           = 0
.equ  UseSpecialWriteBoot             = 0
.equ  UseSpecialRead            = 0
.equ  UseSpecialMsg            = 0
.equ    UseAutobaud                     = 1
.equ    UseResetDelay                   = 1
.equ    UseUartInvert                   = 1
.equ    UseRS485                        = 0
.equ    UseRS485Invert                  = 0
.equ    RX_PORT                         = PORTE
.equ  RX              = PE0
.equ  TX_PORT        = PORTE
.equ  TX        = PE1
.equ  DE_PORT        = PORTE
.equ  DE              =
.set  XTAL        = 16000000
.set  BootDelay      = XTAL/4
.set  BootBaudrate            = 115200
.set  BootVersion      = 6
.set  BootCodeSize            = 476

BootSign:  .db    "BOOTLOADER"
BootMsg:  .db    "16Mhz Mega128 SCADA"

Ich benutzte einen Max232N Pegelwandler an der UART0. Im LoaderTool 
(V.6) antwortet der Controller nicht, obwohl ich den RESET-Taster auf 
meinem Board druecke. Den Bootloader habe ich aus dem zuletzt von Hagen 
geposteten Code compiliert. COM1 ist der richtige Port, weil ich darüber 
auch ueber ISP flashe. Die Fusebits nach Ponyprog sind im Anhang.

Vielen Dank fuer eure Hilfe

Alfred

von Alfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hat keiner eine Idee oder ist der Fred schon zu alt?

von Josef Bernhardt (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Liebe Bootlader Freunde,

ich würde gerne mit einem C# Programm weiterhelfen,
es müsste mir nur jemand eine Spec. senden wo das
Protokoll genau erklärt ist.

Anbei ein Foto von einem Seriellen Testprogramm

Beste Grüße

Josef

von alex (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

Benutze deinen Bootloader schon in meheren Projekten und bin sehr 
zufrieden damit.
Habe dich damals auch schon um Hilfe gebeten weil wir ein Modul für 
avrdude schreiben wollten. Das haben wir auch erfolgreich gemacht und 
versucht es in avrdude aufzunehmen.
Leider haben Sie es noch nicht aufgenommen.
Wir können jetzt somit mit einem embedded Linux Rechner und avrdude den 
AVR8 über die RS232 oder RS485  flashen.
Klappt wunderbar soweit.
Jetzt haben wir aber einen anderen embedded Linux Rechner der eine RS485 
Schnitstelle hat.
Das Problem dabei ist das er nach dem Senden zum Bootloader noch seinen 
(send enable) 1 ms an lässt und somit keine Antwort vom Bootloader 
mitbekommt weil der Bootloader ja sofort zurück sendet.
Ich bräuchte hierfür ein Delay. Habe schon probiert das selber 
hinzubekommen aber ich bin nicht so fit in Assembler.
Könntest du mir bitte helfen.

Vielen Dank im Voraus.
Alex

von OlliW (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

seit kurzen bin ich auch BEGEISTERTer Benutzer Haagens Bootloaders. Es 
klappt auch alles perfekt (auch wenn ich noch nicht alle Einstellungen 
durchschaue), und ich war erstaunt wie "einfach" alles ging (Hut ab).

Jedenfalls würde ich jetzt gerne das Eeprom über einen anderen AVR 
lesen/schreiben wollen. Mit dem PC-Program geht das natürlich 
einwandfrei, aber ich würde gerne die Konfiguration meiner AVR Projekte 
(Werte im Eeprom) mit ner weiteren kleinen Schaltung einstellen können, 
ohne PC. Kennt man z.B. im RC-Modelbereich bei den Brushless-Reglern.

Ich habe mich die letzten 2 Tage durch den ganzen Thread gewühlt, und 
mir das was man im Protocolfenster sieht angesehen, aber so ganz klar 
sind mir einige Punkte bzgl. der genauen Abläufe bei der Kommunikation 
noch nicht (ich hoffe dass ich DEN entscheidenden Post nicht übersehen 
habe, wenn doch, sorry schon mal).

HW-mässig will ich das mit 1-Wire machen, bei der Zusatzschaltung (ab 
jetzt Programmer) werde ich einfach die RS232 des Programmers benutzten, 
d.h. die 1-Wire-Schaltung mit den Dioden an Rx/Tx des Programmers. Es 
geht also eigentlich "nur" darum was genau auf Rx u. Tx passiert.

Meine Fragen:
-Frage:  habe ich nirgends erwähnt gefunden: Stoppbits,Paritybits, oder 
nichts von dem?

zum Kommunikationsaufbau wird wohl als erstes vom PC die Zeichenfolge 9x 
$00 + $0D + BootSign (bei mir "BOOTLOADER") abgeschickt, der PC empfängt 
die selbe Zeichenfolge + zusätzlich die Zeichen $3E $1E

-Frage: wo kommen die Zeichen 3E 1E her? Was bedeuten sie?

anhand dieser Vorkommnisse erkennt das PC Program dass 1-Wire vorliegt 
und "schaltet" in 1-Wire um

-Frage: woran genau erkennt der PC den 1-Wir mode? Daran dass die 
1-Wire-Schaltung wie ein "Spiegel" wirkt und alles zurücksendet?
-Frage: was passiert eigentlich beim Umschalten in den 1-Wire-Mode? Wird 
einfach dass was "rückgespiegelt" wird ignoriert?

als nächstes wird wohl so oft die Zeichenfolge 9x $00 + $0D + BootSign 
vom PC gesendet, bis die Zielschaltung mit dem Bootloader eingeschalten 
worden ist und dieser mit einer Antwort reagiert. Diese Antwort ist wohl 
"komplizierter" aufgebaut. Was ich bisher meine rausgefunden zu haben 
ist's so

wenn Encryption des Flashs an und Versioning:
ACYInfo (wie in einem der obigen Posts und im PC-Program genannt)
$20
2 Bytes Signature des AVR (also von 1EXXYY nur XX und YY)
$06 Version des Bootloaders
1 Byte Anzahl der Flashpages
4 Bytes mit der Version in umgekehrter Reihenfolge
1 Byte mit der "Konfiguration" des Bootladers

ohne Encryption und ohne Versioning:
2 Bytes Signature des AVR (also von 1EXXYY nur XX und YY)
$06 Version des Bootloaders
1 Byte Anzahl der Flashpages
1 Byte mit der "Konfiguration" des Bootladers

-Frage: Ist das richtig so? Wie sieht die Antwort im Allgemeinen aus?
-Frage: woran erkennt das PC-Program eigentlich dass die Antwort 
vollständig gesandt worden ist? (bzw. woher würde es die Länge der 
Antwort kennen?)
-Frage: Wie ist der Aufbau des Konfiguration-Bytes?

damit erkennt das PC-Program das Device als connected an
als nächstes ist dann einfach lapidar z.B. Reading EEPROM... zu 
erkennen.

-Frage: was muss man zum Lesen/Schreiben machen? Das was oben in Haagens 
Antwort vom 11.07.2010 12:11 steht? senden von $04 1 Byte Anzahl Bytes, 
und den Inhalt einfach empfangen?

-Zusatzfrage: Woher kennt das PC-Program eigentlich die FLASH size for 
application? Aus FLASH size - FLASH pagesize*No.of Flashpages?

Ich weis, viele Fragen, sorry dafür, aber vielleicht hat ja doch der 
eine oder andere die ein oder andere Antwort :)
Thx,
 Olli

von thorsten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

ich versuche mich gerade daran die AVRootloader DLL in eine Delphi 
Anwendung einzubinden, das hat auch soweit alles funktioniert, nur 
bekomme ich kein Connect. Mit der AVRootloader.exe funktioniert es 
allerdings einwandfrei.
Die Schnittstelleneinstellungen sind bei beiden Programmen identisch.

Meine Delphi-Anwendung setzt folgende Timeouts:
function Tlasher.GetTimeouts: TTimeouts;
begin
  Result.Connect := 0;
  Result.Base := 50;
  Result.Erase := 10;
  Result.Flash := 15;
  Result.Eeprom := 10;
  Result.Buffer := 1;
  Result.AppCmd := 0;
  Result.KeepAlive := 250;
  Result.RTSPulse := 0;
  Result.RTSInterval := 0;
  Result.ConnectTrials := 0;
  Result.MaxPacketSize := 0;
  Result.Options := 0;
end;
Die Timeouts in AVRootloader.ini sind identisch.

Um zu überprüfen, ob die Schnittstelleneinstellungen richtig sind habe 
ich die Kommunikation mal mit PortMon aufgezeichnet.

AVRootloader.exe:
0  0.03930639  AVRootloader.ex  IRP_MJ_CREATE  VCP0  SUCCESS  Options: Open   
1  0.00000335  AVRootloader.ex  IOCTL_SERIAL_GET_BAUD_RATE  VCP0  SUCCESS    
2  0.00000223  AVRootloader.ex  IOCTL_SERIAL_GET_LINE_CONTROL  VCP0  SUCCESS    
3  0.00000196  AVRootloader.ex  IOCTL_SERIAL_GET_CHARS  VCP0  SUCCESS    
4  0.00000223  AVRootloader.ex  IOCTL_SERIAL_GET_HANDFLOW  VCP0  SUCCESS    
5  0.00000196  AVRootloader.ex  IOCTL_SERIAL_GET_TIMEOUTS  VCP0  SUCCESS    
6  0.00000196  AVRootloader.ex  IOCTL_SERIAL_SET_TIMEOUTS  VCP0  SUCCESS  RI:0 RM:0 RC:1000 WM:0 WC:1000  
7  0.00000307  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
8  0.00000196  AVRootloader.ex  IOCTL_SERIAL_GET_BAUD_RATE  VCP0  SUCCESS    
9  0.00000196  AVRootloader.ex  IOCTL_SERIAL_GET_LINE_CONTROL  VCP0  SUCCESS    
10  0.00000196  AVRootloader.ex  IOCTL_SERIAL_GET_CHARS  VCP0  SUCCESS    
11  0.00000196  AVRootloader.ex  IOCTL_SERIAL_GET_HANDFLOW  VCP0  SUCCESS    
12  0.00285120  AVRootloader.ex  IOCTL_SERIAL_SET_BAUD_RATE  VCP0  SUCCESS  Rate: 19200  
13  0.00200752  AVRootloader.ex  IOCTL_SERIAL_CLR_RTS  VCP0  SUCCESS    
14  0.00198265  AVRootloader.ex  IOCTL_SERIAL_CLR_DTR  VCP0  SUCCESS    
15  0.00298921  AVRootloader.ex  IOCTL_SERIAL_SET_LINE_CONTROL  VCP0  SUCCESS  StopBits: 1 Parity: NONE WordLength: 8  
16  0.00000223  AVRootloader.ex  IOCTL_SERIAL_SET_CHAR  VCP0  SUCCESS  EOF:0 ERR:0 BRK:0 EVT:0 XON:0 XOFF:0  
17  0.00896958  AVRootloader.ex  IOCTL_SERIAL_SET_HANDFLOW  VCP0  SUCCESS  Shake:0 Replace:0 XonLimit:0 XoffLimit:0  
18  0.00153595  AVRootloader.ex  IOCTL_SERIAL_SET_DTR  VCP0  SUCCESS    
19  0.00000251  AVRootloader.ex  IOCTL_SERIAL_SET_TIMEOUTS  VCP0  SUCCESS  RI:0 RM:0 RC:50 WM:0 WC:50  
20  0.00000223  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
21  0.00000335  AVRootloader.ex  IOCTL_SERIAL_PURGE  VCP0  SUCCESS  Purge: TXABORT RXABORT TXCLEAR RXCLEAR  
22  0.00000223  AVRootloader.ex  IOCTL_SERIAL_GET_COMMSTATUS  VCP0  SUCCESS    
23  0.00093531  AVRootloader.ex  IRP_MJ_WRITE  VCP0  SUCCESS  Length 10: 00 00 00 00 00 00 00 00 00 0D   
24  0.00000196  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
25  0.00098309  AVRootloader.ex  IRP_MJ_WRITE  VCP0  SUCCESS  Length 12: 42 4F 4F 54 4C 4F 41 44 45 52 3E 1E   

26  0.00000251  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
27  0.00000223  AVRootloader.ex  IOCTL_SERIAL_SET_TIMEOUTS  VCP0  SUCCESS  RI:0 RM:0 RC:197 WM:0 WC:197  
28  0.00000223  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
29  0.19347962  AVRootloader.ex  IRP_MJ_READ  VCP0  CANCELLED  Length 283  
30  0.00000447  AVRootloader.ex  IOCTL_SERIAL_SET_TIMEOUTS  VCP0  SUCCESS  RI:0 RM:0 RC:50 WM:0 WC:50  
31  0.00000307  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS   
 
32  0.00000978  AVRootloader.ex  IOCTL_SERIAL_PURGE  VCP0  SUCCESS  Purge: TXABORT RXABORT TXCLEAR RXCLEAR  
33  0.00000223  AVRootloader.ex  IOCTL_SERIAL_GET_COMMSTATUS  VCP0  SUCCESS    
34  0.00044279  AVRootloader.ex  IRP_MJ_WRITE  VCP0  SUCCESS  Length 10: 00 00 00 00 00 00 00 00 00 0D   
35  0.00000251  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
36  0.00097163  AVRootloader.ex  IRP_MJ_WRITE  VCP0  SUCCESS  Length 12: 42 4F 4F 54 4C 4F 41 44 45 52 3E 1E   

37  0.00000196  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
38  0.00000223  AVRootloader.ex  IOCTL_SERIAL_SET_TIMEOUTS  VCP0  SUCCESS  RI:0 RM:0 RC:197 WM:0 WC:197  
39  0.00000196  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
40  0.19568660  AVRootloader.ex  IRP_MJ_READ  VCP0  TIMEOUT  Length 0:   
41  0.00000251  AVRootloader.ex  IOCTL_SERIAL_SET_TIMEOUTS  VCP0  SUCCESS  RI:0 RM:0 RC:50 WM:0 WC:50  
42  0.00000223  AVRootloader.ex  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS 
   

Mein Programm:
0  0.03941618  Test.exe  IRP_MJ_CREATE  VCP0  SUCCESS  Options: Open   
1  0.00000391  Test.exe  IOCTL_SERIAL_GET_BAUD_RATE  VCP0  SUCCESS    
2  0.00000251  Test.exe  IOCTL_SERIAL_GET_LINE_CONTROL  VCP0  SUCCESS    
3  0.00000251  Test.exe  IOCTL_SERIAL_GET_CHARS  VCP0  SUCCESS    
4  0.00000223  Test.exe  IOCTL_SERIAL_GET_HANDFLOW  VCP0  SUCCESS    
5  0.00000279  Test.exe  IOCTL_SERIAL_GET_TIMEOUTS  VCP0  SUCCESS    
6  0.00000223  Test.exe  IOCTL_SERIAL_SET_TIMEOUTS  VCP0  SUCCESS  RI:0 RM:0 RC:1000 WM:0 WC:1000  
7  0.00000307  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
8  0.00000223  Test.exe  IOCTL_SERIAL_GET_BAUD_RATE  VCP0  SUCCESS    
9  0.00000196  Test.exe  IOCTL_SERIAL_GET_LINE_CONTROL  VCP0  SUCCESS    
10  0.00000196  Test.exe  IOCTL_SERIAL_GET_CHARS  VCP0  SUCCESS    
11  0.00000196  Test.exe  IOCTL_SERIAL_GET_HANDFLOW  VCP0  SUCCESS    
12  0.00224721  Test.exe  IOCTL_SERIAL_SET_BAUD_RATE  VCP0  SUCCESS  Rate: 19200  
13  0.00201785  Test.exe  IOCTL_SERIAL_CLR_RTS  VCP0  SUCCESS    
14  0.00197735  Test.exe  IOCTL_SERIAL_CLR_DTR  VCP0  SUCCESS    
15  0.00295959  Test.exe  IOCTL_SERIAL_SET_LINE_CONTROL  VCP0  SUCCESS  StopBits: 1 Parity: NONE WordLength: 8  
16  0.00000223  Test.exe  IOCTL_SERIAL_SET_CHAR  VCP0  SUCCESS  EOF:0 ERR:0 BRK:0 EVT:0 XON:0 XOFF:0  
17  0.00897013  Test.exe  IOCTL_SERIAL_SET_HANDFLOW  VCP0  SUCCESS  Shake:0 Replace:0 XonLimit:0 XoffLimit:0  
18  0.00141890  Test.exe  IOCTL_SERIAL_SET_DTR  VCP0  SUCCESS    
19  0.00000307  Test.exe  IOCTL_SERIAL_SET_TIMEOUTS  VCP0  SUCCESS  RI:0 RM:0 RC:50 WM:0 WC:50  
20  0.00000307  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
21  0.00000531  Test.exe  IOCTL_SERIAL_PURGE  VCP0  SUCCESS  Purge: TXABORT RXABORT TXCLEAR RXCLEAR  
22  0.00000810  Test.exe  IOCTL_SERIAL_GET_COMMSTATUS  VCP0  SUCCESS    
23  0.00089006  Test.exe  IRP_MJ_WRITE  VCP0  SUCCESS  Length 10: 00 00 00 00 00 00 00 00 00 0D   
24  0.00000335  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
25  0.00090095  Test.exe  IRP_MJ_WRITE  VCP0  SUCCESS  Length 12: 42 4F 4F 54 4C 4F 41 44 45 52 3E 1E   

26  0.00000196  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS 
27  0.00000251  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    

28  0.00000307  Test.exe  IOCTL_SERIAL_PURGE  VCP0  SUCCESS  Purge: TXABORT RXABORT TXCLEAR RXCLEAR  
29  0.00000223  Test.exe  IOCTL_SERIAL_GET_COMMSTATUS  VCP0  SUCCESS    
30  0.00295568  Test.exe  IRP_MJ_WRITE  VCP0  SUCCESS  Length 10: 00 00 00 00 00 00 00 00 00 0D   
31  0.00000251  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
32  0.00596640  Test.exe  IRP_MJ_WRITE  VCP0  SUCCESS  Length 12: 42 4F 4F 54 4C 4F 41 44 45 52 3E 1E   

33  0.00000223  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS 
34  0.00000223  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS   

35  0.00000279  Test.exe  IOCTL_SERIAL_PURGE  VCP0  SUCCESS  Purge: TXABORT RXABORT TXCLEAR RXCLEAR  
36  0.00000223  Test.exe  IOCTL_SERIAL_GET_COMMSTATUS  VCP0  SUCCESS    
37  0.00492521  Test.exe  IRP_MJ_WRITE  VCP0  SUCCESS  Length 10: 00 00 00 00 00 00 00 00 00 0D   
38  0.00000279  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS    
39  0.00696401  Test.exe  IRP_MJ_WRITE  VCP0  SUCCESS  Length 12: 42 4F 4F 54 4C 4F 41 44 45 52 3E 1E   

40  0.00000251  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS
41  0.00000223  Test.exe  IRP_MJ_FLUSH_BUFFERS  VCP0  SUCCESS 
   

Der Ablauf ist soweit identisch, allerdings scheint meine Anwendung 
nicht zu versuchen vom COM-Port zu lesen.
Zwischen Zeile 26 und 31 (jeweils IRP_MJ_FLUSH_BUFFERS) wird im 
AVRootloader Mitschnitt wird versucht vom COM-Port zu lesen.
Bei meinem Programm folgt auf Zeile 26 (IRP_MJ_FLUSH_BUFFERS) in Zeile 
27 direkt das nächste IRP_MJ_FLUSH_BUFFERS.
Das Ganze wiederholt sich in dem Protokollauzug in Zeile 38-43 bzw. 
33/34
Ich weiß leider nicht, wie ich den Code einfärben kann um das zu 
verdeutlichen, darum habe ich Leerzeilen eingefügt.

Ich bitte um Hilfe bei der Lösung dieses Problems. Weitern Code stelle 
ich bei Bedarf noch zur Verfügung, ich halte mich aber weitestgehend an 
die Beispiele weiter oben.

Allerdings habe ich den Eindruck, das ich einen ganz blöden, 
offensichtlichen Fehler mache :(

Danke,
  Thorsten

von Christian B. (christianbesemann)


Bewertung
0 lesenswert
nicht lesenswert
@Alfred
Alfred schrieb:
> Hi,
>
> ich habe leider auch ein Problem mit dem Bootloader. Ich versuche schon
> seit Stunden einen Bootloader für mein Mega128-Projekt zu finden. Hier
> sind
> mein Einstellungen:

Hast Du das Problem schon gefunden, ich versuche so ungefähr das Gleiche 
wie Du, der PC bekommt aber keinen Connect zum Mega128 zu Stande? Er 
bleibt in der Routine "send ident" und der mega128 antwortet nicht. 
Warum....?



Grüße Chris

von L. S. (lschreyer)


Bewertung
0 lesenswert
nicht lesenswert
Mir gehts genauso, ein Mega1284P soll ein Bootloader bekommen,

beim Compilerlauf kommt dies:

error: Operand 1 out of range: z

warning: .cseg .db misalignment - padding zero byte


Hat jemand eine Ideeo wie es klappt?
Scheint eine Macke des 128 zu sein?

Louis

von Christian B. (christianbesemann)


Bewertung
0 lesenswert
nicht lesenswert
L. Schreyer schrieb:
> Hat jemand eine Ideeo wie es klappt?
> Scheint eine Macke des 128 zu sein?
>
> Louis

Hallo Louis,

der Fehler sitzt meist vor der Tastatur, bei mir war es jedenfalls so, 
hatte das falsche "device file" included, es gibt für den 128 einige. 
Evtl. liegt auch hier Dein Problem.

Grüße Chris

von Louis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nö, das war korrekt. Es war der Assembler, der wohl zu alt war. Ich habe 
den neuesten von Atmel installiert, und dann ging es.

Durch die ganze Fehlersuche bin ich auf so manche Option gestoßen, die 
in diesem doch sehr langen Thread verborgen liegt. Ich nutze ja schon 
länger die DLL um in meiner Software den Upload der Firmware zu 
ermöglichen. Aufbauend auf das Beispiel, dass ziemlich zu Anfang von 
Hagen gegeben wurde.

Nachdem die neueren Versionen herauskamen, gab es auch Änderungen in der 
DLL, die dazu führten, dass das ursprüngliche Beispiel nicht mehr 
funktionierte. Da Hagen leider keine Doku der DLL herausgegeben hat 
(verständlich, kostst Zeit und Arbeit) muss man sich da ein bisschen 
selbst einfinden, was nicht immer einfach ist, da die Rückgabefunktionen 
nicht immer selbsterklärend sind.

Verstreut in diesem Thread findet man dann die eine oder andere Info, zu 
den Rückgabewerten und z.B. der Funktion Processmessages. So habe ich es 
dann zum Laufen bekommen, aber wirklich 100% ist das nicht, da ich z.B. 
bei Processmessages nicht kapiert habe was man da machen soll. Ich setze 
das Ergebnis einfach auf False, dann gehts. Ich denke mal, da steckt 
insgesamt viel mehr drin als ich ahne, daher wäre es immer noch super, 
wenn es da eine Doku gäbe, die die ganzen Parameter usw. erklärt. Auch 
die ganzen Timeouts, Options usw. Evtl. hat jemand ein Delphi-Projekt 
mit allen Schikanen zum reinschauen?


Ich habe den Loader jetzt auf 3 Gerätchen am laufen, die ich für 
Modellbaukollegen baue, zwei davon haben die 2er Version drauf, einer 
die 6er. Dank der nun gefundenen Optionen der DLL kann ich beide mit 
einer Software bedienen, das Option-Byte erlaubt es ja das Protokoll zu 
ändern, alt und neu. Das neue Teil läuft sogar mit viel höherer Bitrate, 
die man in der neuen DLL ja auch setzen kann, wieder so eine nette 
Sache, die einem das Leben leichter macht.

Eine Frage hätte ich noch: Gibt es irgendwo eine Liste mit den 
Rückgabewerten des Loaders? Wenn der PC Kontakt aufnimmt sendet der 
Loader ja 5 Bytes, woran man wohl sehen kann ob ein Fehler auftrat. 
Kennt jemand die Bedeutung der Werte?

Louis

von Bjoern (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Hab gerade den Bootloader ausprobiert und bin wirklich begeistert von 
dem Teil. Dafür erst mal vielen Dank an Hagen.

Da ich mich bisher leider nur mit der Programmierung in C beschäftigt 
habe, fällt es mir echt schwer den Code zu verstehen. Ich würde gerne 
einen PIN des AVR, z.B. PC3 blinken lassen, während die neue Firmware 
auf den Controller geschrieben wird. Kann mir vielleicht jemand sagen an 
welcher Stelle im Programm ich das machen muss?

Vielen Dank und Gruß,
Bjoern

von Rene S. (rs-main)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe den Rootloader erfolgreich auf verschiedenen Prozessoren mit 
Verschlüsselung eingesetzt (128, 644P, 328P). Nun habe ich eine 
Applikation, bei welcher ich per Fuse den Reset des 328P abschalten muss 
um einen Port-Pin zu gewinnen. Da fängt dann mein Problem an.
AVRootloader.EXE kann zum AVR nach Aus-und Einschalten der 
Versorgungsspannung verbinden. Das Flashen der ACY-Datei wird jedoch mit 
folgendem Fehler abgebrochen :

20.11.10-18:58:15-386 > Connecting on port COM4...
20.11.10-18:58:23-393 > Device connected
20.11.10-18:58:34-831 > Program...
20.11.10-18:58:34-832 > execute compiled data
20.11.10-18:58:34-832 > 1.2.0.0
20.11.10-18:58:34-832 > selected options in compiled file:
20.11.10-18:58:34-833 > - programming FLASH
20.11.10-18:58:34-833 > - FLASH data are encrypted
20.11.10-18:58:34-833 > - erase FLASH during programming
20.11.10-18:58:34-833 > - full verify FLASH after programing
20.11.10-18:58:34-855 > Cmd.SetBuffer.ResCheck(2)  Error: Decryption 
failed

Der gleiche Vorgang geht Problemlos bei einem 328P mit aktiviertem 
Reset.
Kann jemand helfen ?
Danke, Rene

von Erich F. (erichabg)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Nachdem ich mich nun mehrere Tage durch diesen Thread gekämpft habe, 
habe ich nun den Bootloader mal eingesetzt.

Ich möchte über den Bootloader mein Programm vor unberechtigter 
Benutzung und Vervielfältigung schützen, habe deshalb die 
Verschlüsselung aktiviert:

Hier meine Settings:
.equ  UseBootMode    = 0
.equ  UseWDR      = 1
.equ  UseSaveMCUSR    = 1
.equ  UseE2Write    = 1
.equ  UseE2Read    = 1

.equ  UseCrypt    = 1
.equ  UseCryptFLASH     = 1
.equ  UseCryptE2    = 1

.equ  UseVerify    = 0
.equ  UseVersioning    = 0
.equ  UseSRAM      = 0
.equ  UseSpecialBootVect  = 0
.equ  UseSpecialWrite   = 0
.equ  UseSpecialWriteBoot = 0
.equ  UseSpecialRead    = 0
.equ  UseSpecialMsg    = 0
.equ  UseAutobaud    = 1
.equ  UseResetDelay    = 1
.equ  UseUartInvert    = 1
.equ  UseRS485    = 0
.equ  UseRS485Invert    = 0

Solange ich nun keinerlei Lock-Bits setze geht alles wunderbar.

Setze ich
"Further programming and verification disabeld"
"SPM prohibited in Application Section" und
"SPM prohibited in Boot Section"    funktioniert's noch immer wunderbar.

Aber bei diesen Lock-Bits kann ich den Flash immer noch problemlos 
auslesen.  Genau das möchte ich aber verhindern.

Setze ich nun

"Further programming and verification disabeld"
"LPM and SPM prohibited in Application Section" und
"SPM prohibited in Boot Section"

erhalte ich die Fehlermeldung:
28.11.10-18:58:13-867 > Program...
28.11.10-18:58:13-882 > execute compiled data
28.11.10-18:58:13-882 > selected options in compiled file:
28.11.10-18:58:13-882 > - programming FLASH
28.11.10-18:58:13-882 > - FLASH data are encrypted
28.11.10-18:58:13-882 > - erase FLASH during programming
28.11.10-18:58:14-413 > Cmd.WriteFlash.ResCheck()  Error: Verify failed

Jetzt bin ich etwas ratlos.

Im vorausgegangenen Thread habe ich folgendes gefunden:

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

Aber wie gesagt, mit dieser Einstellung kann ich den Flash immer noch 
problemlos mittels ISP-Adapter auslesen.

Was mach ich falsch?

Grüße
  Erich

von Erich F. (erichabg)


Bewertung
0 lesenswert
nicht lesenswert
Ach fast vergessen: Ist ein ATMega644P

Grüße
  Erich

von Erich F. (erichabg)


Bewertung
0 lesenswert
nicht lesenswert
Jetzt werd ich immer ratloser, jetzt bekomme ich oben genannten Fehler 
auch mit der Einstellung

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


Bitte um Hilfe!  Hagen weist du Rat?

Grüße
  Erich

von Gopy N. (gopy29)


Bewertung
0 lesenswert
nicht lesenswert
This is nice post for Bootloader,
Respect to Hagen and Peter.

I would like to use this bootloader with my  application. I am using 
Atmega32 Microcontroller and Top2005+ programmer.I can use this 
Bootloader to protect my flash data.

What are the configuration want to do for atmega32.

can i use PORTB_1?
Do i want to use OSC to Microcontroller when i program it?
I can use 1 Wire right?
Windows application will automatically pick bootloader right?
How to set fuse bit for external 16MHZ osc?

thanx

von Gopy N. (gopy29)


Bewertung
0 lesenswert
nicht lesenswert
Ich bekomme diesen Fehler.

21.12.10-15:51:53-063 > Connecting...
21.12.10-15:51:53-345 > Switch to 2-Wire mode
21.12.10-15:53:20-065 > ICOM: write error.

Bitte helfen Sie mir, dieses Problem zu lösen. Ich bin mit 2-Draht mit 
Max232.

von Erich F. (erichabg)


Bewertung
0 lesenswert
nicht lesenswert
Gopy Nagalingam schrieb:
> Ich bekomme diesen Fehler.
>
> 21.12.10-15:51:53-063 > Connecting...
> 21.12.10-15:51:53-345 > Switch to 2-Wire mode
> 21.12.10-15:53:20-065 > ICOM: write error.
>
> Bitte helfen Sie mir, dieses Problem zu lösen. Ich bin mit 2-Draht mit
> Max232.

Hi!

A hint: Download one of the older packages with size more than 800kB.
These packages contain Readme's. f.e. How to configure the port. How to 
configure the MAX232 (invert). etc.

The latest package unfortunately is without any explanations.

Regards
   Erich

von Wolfgang O. (karlo)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich bin mal wieder seit langer Zeit im Forum, um eine Frage bezüglich 
des
AVRootloader's zu klären. Der Seitenaufbau der Website dauert bei mir 
leider ewig lange.

Ich benutze den Bootloader in einer Kleinserie, bstückt mit ATMega8. Als 
Loader kam damals die AVRootloader.asm Version 1.0 vom 8.4.2008 zum 
Einsatz. Mit Hilfe der Windows-Anwendung AVRootloader 1.0 kann ich die 
Baugruppen einwandfrei mit der Firmware flashen.

Nun wollte ich den Kunden eine neue Firmware zur Verfügung stellen und 
mit Hilfe der AVRootloader.dll, die ab Version 2.0 zur Verfügung steht, 
eine eigene Anwendung schreiben, die es ermöglicht mit einem "Mausklick" 
die Firmware in den ATMega8 zu transportieren.

Dabei stellte ich fest, dass die Windows-Anwendungen von Hagen ab V2.0 
zwar den Bootloader in meiner Anwendung (V1.0) connected, die Firmware 
aber leider nicht geflasht wird.

Hier das Protocol:

30.03.11-16:46:37-244 > Connecting...
30.03.11-16:46:37-307 > Switch to 2-Wire mode
30.03.11-16:46:40-552 > Device connected
30.03.11-16:46:43-235 > Program...
30.03.11-16:46:43-235 > execute compiled data
30.03.11-16:46:43-235 > selected options in compiled file:
30.03.11-16:46:43-235 > - programming FLASH
30.03.11-16:46:43-235 > - FLASH data are encrypted
30.03.11-16:46:43-235 > - erase FLASH during programming
30.03.11-16:46:43-235 > - programming EEPROM
30.03.11-16:46:43-235 > - EEPROM data are encrypted
30.03.11-16:46:43-266 > Cmd.SetBuffer.ResCheck(2)  Error: 3F operation
failed

Bin momentan ratlos, vielleicht hat jemand einen Tipp?

Viele Grüße aus Karlsruhe
Wolfgang

von Andreas B. (ichwillnix)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ist zwar schon länger nichst mehr passiert in diesem Forum aber ich 
probiers troztdem mal:

@ Hagen, bin nach wie vor begeisterter User des Bootloaders!
Es gibt die wunderschöne Funktion das Flashen von hex- und acy- files 
per commandozeile und parameter zu automatisieren. Das funktioniert auch 
wunderbar.

Frage: Gib es auch einen Kommandozeilen Parameter zum Generieren von 
acy-files aus den hexfiles?

Ich möchte aus einer µC-Software 32 verschiedene Varianten mit 
unterschiedlichen Parametern generieren und als ACY-File zur Verfügng 
stellen. Bisher mach ich das immer händisch, was ziemlich zeitaufwändig 
ist.

Wäre es möglich so was zu implementieren?

Viele Grüsse,
Andreas

von Lefebvre (Gast)


Bewertung
0 lesenswert
nicht lesenswert
AVR is AT Tiny 85

bug, i'm not flash a µC

help me please

best regard



[System]
Sign=BOOTLOADER
Port=COM2
Baudrate=115200
ConnectTrials=1
FLASH=C:\Users\SLE\Documents\SL-Sys\CPT_TOUR\PRG_AVR\Cpt_V2.hex
EEPROM=
ASMFile=AVRootloader.asm
Erase=1
Verify=0
Protocol=1
Password=7006C8F706ADAE04EE833D81503F31DC
AppCmd=/FF/FF/FF/FF/FF/FF/FF/FF/FF/FF/FF/FF/FF/FF/FF/FF
AppCmdResponse=
AppVersion=$01020000
AppVersionFlag=$0C
ACYInfo=

[Timeouts]
Connect=0
Base=25
Erase=5
Flash=10
Eeprom=10
Buffer=1
AppCmd=20
KeepAlive=500
MaxPacketSize=0
RTSPulse=0
RTSInterval=0
Options=1

; Timeouts in Millisekunden
; Base = Minimum Timeout für 1 Zeichen über UART, bei hohen Baudraten 
stellt dieser Wert das Minimum an Timeout dar
; Erase = Timeout zum Löschen einer FLASH Page, normalerweise 5 ms laut 
Datenblätter
; Flash = Timeout zum Löschen und Programmieren eienr FLASH Page, 
normalerweise 2*5ms
; Eeprom = Timeout zum Programmieren eines Bytes im EEPROM, 
normalerweise 5 ms
; Buffer = Timeout beim Warten auf ein Fehlercodebyte beim Schreiben von 
Bufferdaten, sollte mit 1ms immer gehen
; RTSPulse = PC-Sofwtare pulst für RTSPulse Millisekunden die RTS 
Leitung, bei RTSPulse=0 ist das deaktiviert
; bei RTSPulse > 0 wird von HIGH->LOW->HIGH und bei RTSPulse < 0 von 
LOW->HIGH->LOW gepulst.
; Bsp: RTSPulse=20 bedeutet HIGH->20ms LOW ->HIGH
; RTSInterval, wenn RTSPulse <> 0 ist bestimmt dieser Wert in welchem 
Interval das Pulsen von RTS erfolgen soll.
; Beim Wert 0 wird nur einmalig beim Verbindungsaufbau RTS gepulst. Beim 
Wert 1 vor jedem einzlenen Connect Versuch zum AVR.
; Bei Wert 2 jedes zweitemal usw. Ein Wert von 4 bedeutet also das nach 
einem RTS Puls exakt 4 Connect Versuche folgen
; bis es wieder von vorne losgeht.


[Baudrates]
0=2400
1=4800
2=9600
3=14400
4=19200
5=28800
6=38400
7=56000
8=57600
9=115200
10=128000
11=230400
12=256000
13=921600

[Signs]
0=BOOTLOADER
1=ys\_ATMEL_\bootload\AVRootloader\Windows\AVRootloader.exe"
2=BOOTLOADERs
3=BOOT
[GUI]
Left=478
Top=278
Width=571
Height=522
[FLASH]
0=C:\Users\SLE\Documents\SL-Sys\CPT_TOUR\PRG_AVR\Cpt_V2.hex




11.09.11-13:59:50-113 > Connecting on port COM2...
11.09.11-13:59:50-123 > Timeout.Connect       = 25 ms
11.09.11-13:59:50-124 > Timeout.Base          = 25 ms
11.09.11-13:59:50-125 > Timeout.Erase         = 5 ms
11.09.11-13:59:50-126 > Timeout.Flash         = 10 ms
11.09.11-13:59:50-127 > Timeout.Eeprom        = 10 ms
11.09.11-13:59:50-128 > Timeout.Buffer        = 1 ms
11.09.11-13:59:50-129 > Timeout.AppCmd        = 20 ms
11.09.11-13:59:50-129 > Timeout.KeepAlive     = 500 ms
11.09.11-13:59:50-130 > Timeout.RTSPulse      = 0
11.09.11-13:59:50-131 > Timeout.RTSInterval   = 0
11.09.11-13:59:50-131 > Timeout.ConnectTrials = -1
11.09.11-13:59:50-132 > Timeout.MaxPacketSize = 0
11.09.11-13:59:50-135 > send appcmd     $FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF
11.09.11-13:59:50-166 > send ident      $00 00 00 00 00 00 00 00 00 0D 
42 4F 4F 54 4C 4F 41 44 45 52
11.09.11-13:59:50-217 > received data   $00 00 00 00 00 00 00 00 00 0D 
42 4F 4F 54 4C 4F 41 44 45 52 3E 1E 38 4D 68 7A 20 32 2E 37 56 20 42 4F 
44 00 93 0B 06 09 30
11.09.11-13:59:50-221 > Switch to 1-Wire mode
11.09.11-13:59:50-242 > Timer created
11.09.11-13:59:50-243 > Device connected
11.09.11-13:59:50-743 > send keepalive
11.09.11-13:59:51-258 > send keepalive
11.09.11-13:59:51-773 > send keepalive
11.09.11-13:59:52-272 > send keepalive
11.09.11-13:59:52-787 > send keepalive
11.09.11-13:59:53-286 > send keepalive
11.09.11-13:59:53-801 > send keepalive
11.09.11-13:59:54-301 > send keepalive
11.09.11-13:59:54-815 > send keepalive
11.09.11-13:59:55-319 > send keepalive
11.09.11-13:59:55-829 > send keepalive
11.09.11-13:59:56-329 > send keepalive
11.09.11-13:59:56-523 > Timer released
11.09.11-13:59:56-524 > Program...
11.09.11-13:59:56-527 > execute compiled data
11.09.11-13:59:56-527 > selected options in compiled file:
11.09.11-13:59:56-528 > - programming FLASH
11.09.11-13:59:56-528 > - erase FLASH during programming
11.09.11-13:59:56-694 > Cmd.WriteFlash.ReadByte() ICOM: read error.
11.09.11-13:59:56-721 > Timer created
11.09.11-13:59:57-234 > send keepalive
11.09.11-13:59:57-269 > Timer released
11.09.11-13:59:57-271 > keepalive failed, terminate connection
11.09.11-13:59:57-309 > Device disconnected

von Weingut P. (weinbauer)


Bewertung
0 lesenswert
nicht lesenswert
Job zu vergeben !!!!!!!!!!!

Ich suche jemanden, der mir aus dem Code
zwei Programme strickt, einmal für mich um einen
Hex oder Bin zum Flashen für die Kunden zu erstellen,

einmal ein Progrämmchen für die Kunden um den
Bin auf das Gerät zu flashen

und natürlich nen Hex für mich mit dem passenden Loader
für meinen Chip.

Chip ist:
ATMega128
14,74456 MHz
UART0
RS485-Halbduplex, Richtungsumschaltung PortE.2 aktiv high

Wie gesagt, gegen Entlohnung, bitte um Angebote,
bin leider scheinbar zu doof um die Anpassungen selber vor zu nehmen :(

von Weingut P. (weinbauer)


Bewertung
0 lesenswert
nicht lesenswert
Ach so, Baudrate 19200

von charly (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,
liest du hier noch mit ?, hatte dich per PN angeschrieben
aber keine antw. erhalten  ;(

vlG
Charly

von br (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

bei meinem Aufbau, hängt ein FT232RL am PORTJ des atm2560.

Nun ist ja bekannt, dass mit den Befehlen sbi, cbi, sbic, sbis nicht den 
PortJ ansprechen kann.

Mann muss also im Programm die Bitbearbeitungsbefehle ändern:

zB. aus sbi PORTA,PA0

-->wird lds temp_r,PORTJ
        sbr temp_r,(1<<PJ0)
        sts temp_r,PORTJ

und aus sbis PINA,PINA0

wird dann lds temp_r,PINJ
          sbrs temp_r,PINJ0

soweit so gut.
Es wird aber trotzdem keine Verbindung zum bootloader aufgebaut.
Wenn ich aber den PORTE benutze, dann funktioniert das ohne Probleme.
Ich kann mir das Verhalten irgendwie nicht erklären.
Hat einer von euch vielleicht eine Idee?

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Hi,
ist es möglich irgendwie noch ein par bytes einzusparen?
zB, wenn beide Pins am selben Port sitzen?

micht nervt. dass ich mit meiner Lieblingskonfiguration immer 8Byte 
zuviel für einen 512Byte Bootloader habe, wenn ich autobaud aktiviere

wär cool wenn einer der asm-freaks nochwas finden könnte, ich vermute 
das fuchst auch noch andere

hier die Conf:
.equ  UseBootMode      = 0      ; 0 = start bootloader always
                    ; 1 = start on power up reset or by call from application
                    ; 2 = start on external reset or by call from application
                    ; 3 = start on watchdog reset or by call from application
                    ; 4 = start on USB reset or by call from application (only USB Devices)
                    ; 5 = start only by call from application (not recommended)
                    ; with these bootmodes you can shorten startup time for application

.equ  UseWDR        = 1      ; Watchdog support (2 sec timeout, remember to deactivate WDT in your application if not needed)
.equ  UseSaveMCUSR    = 0      ; save MCUSR on stack (RAMEND) for access by application (on UseWDR=1 MCUSR must be cleared)

.equ  UseE2Write      = 1      ; EEPROM write command (have implicit verify)
.equ  UseE2Read      = 1      ; EEPROM read command

.equ  UseCrypt      = 0      ; cryptography (crypt.inc)
.equ  UseCryptFLASH     = 0      ; explicit use of cryptography for writing to FLASH
.equ  UseCryptE2      = 0      ; explicit use of cryptography for writing to EEPROM

.equ  UseVerify      = 0      ; Verify FLASH command (FLASH write/erase have implicit verify, can be deactivated)
.equ  UseVersioning    = 0      ; Versioning for application software (stored 4/6 bytes before BootStart)
.equ  UseSRAM        = 0      ; SRAM read/write commands (attention! can be a security risk)

.equ  UseSpecialBootVect  = 0      ; use a rjmp BootStart at end of FLASH to start bootloader from application code
.equ  UseSpecialWrite   = 0      ; special function "write_flash" to reprogram FLASH
.equ  UseSpecialWriteBoot = 0      ; "write_flash" can write to bootloader section with magic code, only usefull if SPM is allowed by lockbit fuses in BLS
.equ  UseSpecialRead    = 0      ; special function "read_flash" to read from FLASH
.equ  UseSpecialMsg    = 0      ; special function to return address and size of BootMsg
                    ; look into AVRootloader.h and M162 test project in folder \test\ for use of special funcs

.equ  UseAutobaud      = 1      ; Baudrate detection
.equ  UseResetDelay    = 1      ; Reset the boot delay everytime if any activity is detected on RX pin.
                    ; First after BootDelay milliseconds inactivity the application is called.
                    ; Otherwise the timeout BootDelay defines an overall timeout for connection.

.equ  UseUartInvert    = 1      ; invert UART levels (for RS232 drivers such as MAX232)
.equ  UseRS485      = 0      ; activate RS-485 Data Enable pin
.equ  UseRS485Invert    = 0      ; inverted logic of RS-485 DE pin (HIHGH for receive, LOW for transmit)

.equ  RX_PORT        = PORTD    ; Receive port and pin
.equ  RX          = PD0
.equ  TX_PORT        = PORTD    ; Transmit port and pin
.equ  TX          = PD1

.if UseRS485
.equ  DE_PORT        = PORTB    ; DE enable pin of RS-485 
.equ  DE          = PB2    ; must be only set if RS485 DE is used
.endif

.set  XTAL        = 20000000  ; 
.set  BootDelay      = XTAL/4  ; about 250ms (don't set to fast to avoid connection problems)
.set  BootBaudrate    = 57600; only used if no Baudrate detection activated, XTAL is than important
.set  BootVersion      = 6      ; Version 6 (must be not changed)
.set  BootCodeSize    = 0    ; set to 0, compile and set to value in [.cseg] Used, compile again
                    ; after this step cseg used is +2 bytes greater, ignore it (AVRStudio 4.16 bugfix)
                        

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
BootSign kürzen auf minimal 2 Zeichen und in Windows Software 
entsprehend anpassen.

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Hagen Re schrieb:
> BootSign kürzen auf minimal 2 Zeichen und in Windows Software
> entsprehend anpassen.

klar, das ist naheliegend, bringt aber nur 2 von 8 Byte.
die Frage ist, ob woanders noch was rausgeholt werden kann, zB durch 
zusammenfassung durch gleiche Port- und Datanrichtungsregister.

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> zB durch
> zusammenfassung durch gleiche Port- und Datanrichtungsregister

wenn du mir sagst wo das der Fall ist ?

Ausser das du weitere Funktionalität "opferst" kenne ich keinen weiteren 
Weg. Du könntest UseWDR=0 setzen was ich als gravierenden Nachteil 
erachte da so eine wichtige Sicherheit gegen unverhersehbare Ereignisse 
entfernt wird. Oder du benutzt UseAutoBaud=0 und musst dann immer mit 
fester Baudrate arbeiten was die Ansprüche an das Kommunikationssystem 
an enge Rahmenbedingungen inkrementiert. Oder eben auf die EEPROM 
Routinen verzichten.

Du musst es auch mal so sehen: 512 Bytes sind 256 Assemblerbefehle und 
das mit den von dir gewählten Funktionalitäten ist defakto schon enorm 
kompakt. Jede der Funktionen, sei es Serielle Schnittstelle, FLASH 
programmieren, der Command-Handler usw. habe ich Opcode für Opcode auf 
Kompaktheit programmiert. Ich sehe keine weitere 
Optimierungsmöglichkeiten wenn man nicht entscheidende Funktionalität 
beschneiden möchte.

Gruß Hagen

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
hm es könnte noch einen Weg geben. Wir kürzen das BootSign auf 1 Zeichen 
und benötigen somit keinen Zeiger mehr in den FLASH zum BootSign.

Nachfolgend die Änderungen zwischen den Lines markiert. Das BootSign 
besteht aus dem Buchstaben Z.

Allerdings ist das BootSign auch ein Schutz gegen falsch ermittelte 
Baudraten. Je kürzer dieses Sign je höher die Wahrscheinlichkeit das 
krumm ermittelte Baudraten diesen Code überwinden und der Bootloader mit 
schlechten Baudraten arbeitet.

Ich habe die Änderungen nicht getestet, also keine Garantie. Es müssten 
14 Bytes weniger an Code rauskommen.
Den Wert bei Label BootSign: komplett löschen.

Gruß Hagen
; baudrate and identifier scanning
.if UseResetDelay    
abd:  
.endif
    ldi    cmdl, byte3(BootDelay / 6)
    ldi    xh, byte2(BootDelay / 6)
    ldi    xl, byte1(BootDelay / 6)
.if !UseResetDelay
abd:  
.endif
    movw  crcl, zerol

;-------------------------------------------------------------
;    ldi    parah, (BootMsg - BootSign) * 2
;    ldi    zl, byte1(BootSign * 2)
;    ldi    zh, byte2(BootSign * 2)
;-------------------------------------------------------------

.if UseAutobaud
; baudrate detection
; autobaud based on P.Dannegger with some optimization
; detects 0x0A,0x0B,0x0D,0x0F,0x85,0x87,0xC3,0xE1
    movw  yl, zerol          ; scan for 1x baudrate low to high followed with 4x baudrate low
ab1:  add    yl, yl
    adc    yh, yh
    movw  cntl, zerol
ab2:  sbiw  xl, 1          
    sbc    cmdl, zerol
    rx_0
    brne    ab2
    breq    id2        ; exit
ab3:  sbiw    yl, 1
    adiw    cntl, 2          
    brcs    exit
    rx_1
    rjmp    ab3
    asr    yl
    sbiw    yl, BaudTolerance
    adiw    yl, BaudTolerance * 2
    movw  yl, cntl
    brcc    ab1
    sbiw  cntl, UartLoop 
    brcs  ab1
    movw    baudl, cntl
.else
; fixed baudrate
    ldi    yl, byte1(Baudrate)
    ldi    yh, byte2(Baudrate)
    movw  baudl, yl
.endif ; .if UseAutobaud

; identifier (BootSign) scanning with timeout and checksum

id1:  sbiw  xl, 1                ; UART getc with timeouts
    sbc    cmdl, zerol
    rx_1
    brne  id1
id2:  breq  exit
id3:  sbiw  xl, 1
    sbc    cmdl, zerol
    rx_0
    brne  id3
    breq  exit
    rcall  getx
;---------------------------------------------
;    xlpm  r0, z+
;    cp    r0, paral
                cpi     paral, 'Z'
;---------------------------------------------
    brne  abd
;---------------------------------------------
;    dec    parah
;    brne  id1
;---------------------------------------------
    rcall  getw
    brne  abd

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
br schrieb:
> Hallo zusammen,
>
> bei meinem Aufbau, hängt ein FT232RL am PORTJ des atm2560.
>
> Nun ist ja bekannt, dass mit den Befehlen sbi, cbi, sbic, sbis nicht den
> PortJ ansprechen kann.
>
> Mann muss also im Programm die Bitbearbeitungsbefehle ändern:
>
> zB. aus sbi PORTA,PA0
>
> -->wird lds temp_r,PORTJ
>         sbr temp_r,(1<<PJ0)
>         sts temp_r,PORTJ
>
> und aus sbis PINA,PINA0
>
> wird dann lds temp_r,PINJ
>           sbrs temp_r,PINJ0
>
> soweit so gut.
> Es wird aber trotzdem keine Verbindung zum bootloader aufgebaut.
> Wenn ich aber den PORTE benutze, dann funktioniert das ohne Probleme.
> Ich kann mir das Verhalten irgendwie nicht erklären.
> Hat einer von euch vielleicht eine Idee?

Es wird aus diesem Grund keine Verbindung zustande kommen. Durch deine 
Änderungen ändert sich das kritsche Timing, und dh. jeder einzelne Takt 
mehr macht den Source unbrauchbar.

Nun, leider ist es so das ohne Änderungen an diesen kritischen Stellen 
dein problem nicht lösbar ist. Dh. das komplette Timing, AutoBaud, 
waitf, putc und getc muß angepasst werden.

Wenn es für dich machbar ist nehme ein PORT auf den man normal mit 
sbi/sbis zugreifen kann.

Ansonsten bleibt nichts anders übrig als das komplette Timing 
anzupassen, und das ist ziemliche Frickellei da zb. die Proceduren getc 
und putc in ihren Taktzyklenanzahlen gleich gewichtet geändert werden 
müssen. Dann muss du noch den Korrektufaktor in der AutoBaud Funktion 
anpassen, wenn ich mich recht erinner ist der jetzt -29 Taktzyklen. Der 
sollte dann um rund +4 größer sein.

Und dann noczh die Benutzung von temp_r könnte kritisch sein. Man muß 
sicherstellen das man zu diesem Zeitpunkt ein register nimmt das auch 
frei verfügbar ist da ansonsten mit diesem Code wichtige Register 
überschrieben werden könnten.
Gruß Hagen

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
charly schrieb:
> Hallo Hagen,
> liest du hier noch mit ?, hatte dich per PN angeschrieben
> aber keine antw. erhalten  ;(
>
> vlG
> Charly

seit längerer Zeit schaue ich hier mal wieder rein. Warum die PNs nicht 
ankommen weiß ich auch nicht, bzw. ich hatte vor einiger Zeit den Fall 
das das AntiSPAM System meines Providers mal eben EMails löschte die es 
nicht löschen durfte. Auffälig daran war das das meistens Absender waren 
die häufig Newsletter versenden. Also alle EMailnewsletter von 
XILINX,Alter,TI,Intel,MS,Lattice,NXP,Maxim waren davon betroffen, 
inkluse einige wichtige Firmenmails von Auftraggebern die ihrerseits mit 
ihrem Absenderadrese Werbung versendeten.
Hat übrigens par Wochen gedauert bis ich das bemerkte, bzw. bis mich ein 
Kunde darauf ansprach.

Gruß Hagen

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Lefebvre schrieb:
> AVR is AT Tiny 85
>
> bug, i'm not flash a µC
>
> help me please
>
> best regard

change in AVRootloader.ini

[Timeouts]
base=50 or 100

best regards hagen

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Andreas Baier schrieb:
> Frage: Gib es auch einen Kommandozeilen Parameter zum Generieren von
> acy-files aus den hexfiles?
> Wäre es möglich so was zu implementieren?

diese Forderung hatten wir in diesem Thread schon öfters. Und ich habe 
das auch immer noch auf der ToDo Liste, leider rückt diese in immer 
weiterer Ferne und deswegen möchte ich keine falschen Hoffnungen wecken.

Machbar ist es und Konzept wie ich es machen würde kannst du weiter oben 
im Thread nachlesen.

Gruß Hagen

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang O. schrieb:
> 30.03.11-16:46:43-266 > Cmd.SetBuffer.ResCheck(2)  Error: 3F operation
> failed
>
> Bin momentan ratlos, vielleicht hat jemand einen Tipp?
>
> Viele Grüße aus Karlsruhe
> Wolfgang

in AVRootloader.ini

[timouts]
eeprom=

größer machen.

Grüße zurück nach Karlsruhe, hagen

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Hagen Re schrieb:
> Vlad Tepesch schrieb:
>> zB durch
>> zusammenfassung durch gleiche Port- und Datanrichtungsregister
>
> wenn du mir sagst wo das der Fall ist ?
keine Ahnung, ich habe mir den Code selbst nicht imdetail angeschaut, da 
ich nicht so in AVR-ASM drin stecke.

wenn du sagst, da ist nix mehr rauszuholen, glaube ich dir das.
Ich dachte halt, das da noch was zu holen sein könnte, wenn die SW auf 
vielseitigkeit ausgelegt ist und da nicht das komplette Potential 
ausgeschöpft hat, wenn beide Pins an dem selben Port hängen.

>
> Ausser das du weitere Funktionalität "opferst"

Ich will ebend gerade nicht auf eine der genannten Funktionen verzichten 
;)

Hagen Re schrieb:
> hm es könnte noch einen Weg geben. Wir kürzen das BootSign auf 1 Zeichen
> und benötigen somit keinen Zeiger mehr in den FLASH zum BootSign.

nur ein Zeichen ist natürlich auch nicht schön

trotzdem danke.

Gruß
Vlad

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Hi Hagen, ich hab den Loader jetzt auf einen tiny461 gepackt
der Tiny soll mit 1Mhz laufen.
Baudrate wollte ich eigentlich 1200 benutzen, aber damit funktioneirt 
der Bootloader im Autobaud scheinbar gar nicht.
stelle ich in der Gui auf höhere Baudraten funktioniert das connecten.

wenn ich programmieren will bekomme ich folgende Ausgaben:
26.01.12-23:56:49-640 > Connecting on port COM9...
26.01.12-23:56:49-640 > Timeout.Connect       = 50 ms
26.01.12-23:56:49-640 > Timeout.Base          = 50 ms
26.01.12-23:56:49-640 > Timeout.Erase         = 10 ms
26.01.12-23:56:49-640 > Timeout.Flash         = 15 ms
26.01.12-23:56:49-640 > Timeout.Eeprom        = 10 ms
26.01.12-23:56:49-640 > Timeout.Buffer        = 1 ms
26.01.12-23:56:49-640 > Timeout.AppCmd        = 100 ms
26.01.12-23:56:49-640 > Timeout.KeepAlive     = 250 ms
26.01.12-23:56:49-640 > Timeout.RTSPulse      = 0
26.01.12-23:56:49-640 > Timeout.RTSInterval   = 0
26.01.12-23:56:49-640 > Timeout.ConnectTrials = -1
26.01.12-23:56:49-640 > Timeout.MaxPacketSize = 0
26.01.12-23:56:49-640 > send ident      $00 00 00 00 00 00 00 00 00 0D 4D 53 4E 44
26.01.12-23:56:50-843 > received data   $92 08 06 08 30
26.01.12-23:56:50-859 > Timer created
26.01.12-23:56:50-859 > Device connected
26.01.12-23:56:51-109 > send keepalive
26.01.12-23:56:51-359 > send keepalive
26.01.12-23:56:51-609 > send keepalive
26.01.12-23:56:51-859 > send keepalive
26.01.12-23:56:52-109 > send keepalive
26.01.12-23:56:52-359 > send keepalive
26.01.12-23:56:52-609 > send keepalive
26.01.12-23:56:52-859 > send keepalive
26.01.12-23:56:52-921 > Timer released
26.01.12-23:56:52-921 > Program...
26.01.12-23:56:52-921 > execute compiled data
26.01.12-23:56:52-921 > selected options in compiled file:
26.01.12-23:56:52-921 > - programming FLASH
26.01.12-23:56:52-921 > - erase FLASH during programming
26.01.12-23:56:53-812 > Cmd.SetBuffer.ReadByte() ICOM: read error.  <============
26.01.12-23:56:53-843 > Timer created
26.01.12-23:56:54-093 > send keepalive
26.01.12-23:56:54-343 > send keepalive
26.01.12-23:56:54-593 > send keepalive
26.01.12-23:56:54-843 > send keepalive
26.01.12-23:56:55-093 > send keepalive
26.01.12-23:56:55-343 > send keepalive
26.01.12-23:56:55-593 > send keepalive
26.01.12-23:56:55-843 > send keepalive
26.01.12-23:56:56-093 > send keepalive
26.01.12-23:56:56-343 > send keepalive
26.01.12-23:56:56-593 > send keepalive
26.01.12-23:56:56-687 > Timer released
26.01.12-23:56:56-734 > Device disconnected


der Fehler wurde hier zwar schon mal erwähnt, aber es gab kein feedback 
dazu.

Hoffe du hast eine Idee.

MfG
Vlad

hier meine config:

; set follow equ to 0/1 to de/activate....
.equ  UseBootMode      = 0      ; 0 = start bootloader always
                    ; 1 = start on power up reset or by call from application
                    ; 2 = start on external reset or by call from application
                    ; 3 = start on watchdog reset or by call from application
                    ; 4 = start on USB reset or by call from application (only USB Devices)
                    ; 5 = start only by call from application (not recommended)
                    ; with these bootmodes you can shorten startup time for application

.equ  UseWDR        = 1      ; Watchdog support (2 sec timeout, remember to deactivate WDT in your application if not needed)
.equ  UseSaveMCUSR    = 0      ; save MCUSR on stack (RAMEND) for access by application (on UseWDR=1 MCUSR must be cleared)

.equ  UseE2Write      = 1      ; EEPROM write command (have implicit verify)
.equ  UseE2Read      = 1      ; EEPROM read command

.equ  UseCrypt      = 0      ; cryptography (crypt.inc)
.equ  UseCryptFLASH     = 0      ; explicit use of cryptography for writing to FLASH
.equ  UseCryptE2      = 0      ; explicit use of cryptography for writing to EEPROM

.equ  UseVerify      = 0      ; Verify FLASH command (FLASH write/erase have implicit verify, can be deactivated)
.equ  UseVersioning    = 0      ; Versioning for application software (stored 4/6 bytes before BootStart)
.equ  UseSRAM        = 0      ; SRAM read/write commands (attention! can be a security risk)

.equ  UseSpecialBootVect  = 0      ; use a rjmp BootStart at end of FLASH to start bootloader from application code
.equ  UseSpecialWrite   = 0      ; special function "write_flash" to reprogram FLASH
.equ  UseSpecialWriteBoot = 0      ; "write_flash" can write to bootloader section with magic code, only usefull if SPM is allowed by lockbit fuses in BLS
.equ  UseSpecialRead    = 0      ; special function "read_flash" to read from FLASH
.equ  UseSpecialMsg    = 0      ; special function to return address and size of BootMsg
                    ; look into AVRootloader.h and M162 test project in folder \test\ for use of special funcs

.equ  UseAutobaud      = 1      ; Baudrate detection
.equ  UseResetDelay    = 1      ; Reset the boot delay everytime if any activity is detected on RX pin.
                    ; First after BootDelay milliseconds inactivity the application is called.
                    ; Otherwise the timeout BootDelay defines an overall timeout for connection.

.equ  UseUartInvert    = 1      ; invert UART levels (for RS232 drivers such as MAX232)
.equ  UseRS485      = 0      ; activate RS-485 Data Enable pin
.equ  UseRS485Invert    = 0      ; inverted logic of RS-485 DE pin (HIHGH for receive, LOW for transmit)

.equ  RX_PORT        = PORTB    ; Receive port and pin
.equ  RX          = PB5
.equ  TX_PORT        = PORTB    ; Transmit port and pin
.equ  TX          = PB4

.if UseRS485
.equ  DE_PORT        = PORTB    ; DE enable pin of RS-485 
.equ  DE          = PB2    ; must be only set if RS485 DE is used
.endif

.set  XTAL        = 1000000  ; 
.set  BootDelay      = XTAL/4  ; about 250ms (don't set to fast to avoid connection problems)
.set  BootBaudrate    = 2400  ; only used if no Baudrate detection activated, XTAL is than important
.set  BootVersion      = 6      ; Version 6 (must be not changed)
.set  BootCodeSize    = 506    ; set to 0, compile and set to value in [.cseg] Used, compile again
                    ; after this step cseg used is +2 bytes greater, ignore it (AVRStudio 4.16 bugfix)
                  

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
in AVRootloader.inc
equ  BaudTolerance  = 5

in AVRootloader.asm
.set  BootDelay      = XTAL/1 oder 2 

in AVRootloader.ini

Timeout.Base          = 100 ms

setzen. Mehr kann ich auch nicht empfehlen, außer deine Schaltung mit 
einem Oszi auch mal durchzumessen.


Gruß Hagen

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
hmm - scheint nix zu bringen.
Der bootloader scheint bei 1Mhz einfach nicht zu funktionieren

lösch ich das div8 (und asembliere neu natürlich) gehts

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> lösch ich das div8 (und asembliere neu natürlich) gehts

div8 heist was ?

Bei 1Mhz sollte die Baudrate nicht größer als 33kBit/s sein.

von Ante (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen,

super Arbeit Hagen!. Habe mich wieder dem Bootloader gewidmet. Leider 
bekomme ich ihn auf meinem Atmega32A nicht zum laufen. Die Kofi:
FT232R – RX an PD2 TX an PD3 sonst ist keine Verbindung zum Atmega32A
Atmega32 siehe Anhang

.include "m32Adef.inc“

.equ  UseBootMode    = 0

.equ  UseWDR      = 0
.equ  UseSaveMCUSR    = 0

.equ  UseE2Write    = 1
.equ  UseE2Read    = 1

.equ  UseCrypt    = 1
.equ  UseCryptFLASH     = 1
.equ  UseCryptE2  = 1

.equ  UseVerify    = 1
.equ  UseVersioning    = 1
.equ  UseSRAM      = 0
.equ  UseSpecialBootVect  = 0
.equ  UseSpecialWrite           = 0
.equ  UseSpecialWriteBoot       = 0
.equ  UseSpecialRead    = 0
.equ  UseSpecialMsg    = 0

funcs

.equ  UseAutobaud  = 1
.equ  UseResetDelay  = 1


.equ  UseUartInvert  = 1
.equ  UseRS485    = 0
.equ  UseRS485Invert  = 0

.equ  RX_PORT    = PORTD
.equ  RX    = PD2
.equ  TX_PORT    = PORTD
.equ  TX    = PD3

.if UseRS485
.equ  DE_PORT    = PORTB
.equ  DE    = PB2
.endif

.set  XTAL    = 14745600
.set  BootDelay  = XTAL/4
.set  BootBaudrate  = 115200
.set  BootVersion  = 6
.set  BootCodeSize  = 914

Die PC Software kann keine Verbindung zum Modul aufbauen. Kann mir 
jemand helfen?


Gruß
 - Ante –

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Ante schrieb:
> RX an PD2 TX an PD3 sonst ist keine Verbindung zum Atmega32A
> Atmega32 siehe Anhang

du hast schon noch eine GND-Verbindung, odeR?

von Ante (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja klar! Es hägen ja andere sachen noch am Atmel. Ich habe nur die 
Verbindung zum FT232R beschrieben. Da habe ich nur RX und TX dran, kein 
RTS DTS usw.

Gruß
 - Ante -

von OlliW (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

erstmal, ich benutze Hagens Bootloader für meine Projekte aus dem 
RC-Modellbaubereich (www.olliw.eu)... deswegen erstmal wieder 1000 Dank 
an dich, Hagen, für diese tolle Arbeit!

Meine Frage wäre, hat Jemand von Euch schon mal probiert die 1-Wire 
Verbindung über ein Bluetooth-Seriel-Modul ablaufen zulassen, bzw. hat 
Jemand das schon erfolgreich hinbekommen?

Ich benutze den Bootloader mit UseUartInvert=0 im 1-Witre Modus (das 
muss leider aus versch. Gründen so sein, ist also eine Randbedingung)

Ich habe das Bluetooth Arduino Modul von JY-MCU (nur als Beispiel, das 
http://www.ebay.de/itm/ws/eBayISAPI.dll?ViewItem&item=250968195320&ssPageName=ADME:X:DERP:DE:1123). 
Für die Umsetzung der TTL-Pegel auf die vom Bootloader erwartet 
RS232-artigen Level benutze ich zwei Inverter eines 74HCT04, und als 
"Widerstand" zwischen der Rx und Tx line habe ich einen 100 Ohm 
Widerstand mit ner 1n4148 Diode (rictig rum) parallel geschaltet. Der 
kleine Widerstand und die Diode sind wichtig um mit allen "meinen" 
Geräten, bei denen ich die Eingangsbeschaltung nicht ändern kann, zu 
funktionieren. Das mit dem Widerstand/Diode ist aber IMHO NICHT 
relevant. Benutze ich einen USB-TTL Adapter dann funktioniert das 
ausgezeichnet.

Benutze ich nun den Bluetooth-Adapter dann klappt das im Prinzip schon 
auch, nur leider extrem instabil, d.h. die Verbindung geht sehr oft 
einfach verloren. Ich habe Baudraten von 19200-57600, die bei Verwendung 
des USB-Adapters+74HCT04Inverter+RD-Netzwerk problemlos funktionieren, 
getestet. Immer das Selbe, Verbindung klappt... aber bleibt meistens nur 
sehr kurz bestehen. EPPROM lesen geht z.B. gar nicht.

Ich kenne mich nun mit den "Geheimnissen" von Bluetooth überhaupt nicht 
aus. So ganz naiv würde ich meinen dass Bluetooth anscheinend, im 
Vergleich zu den USB-Seriel-Adaptern, nicht sehr gut beim Einhalten von 
Zeiten ist. Aber Wissen tu ich's nicht.

Wie auch immer, kann das mit Blueetooth funktionieren, und wenn ja was 
mache ich Falsch, oder kann das etwa prinzipbedingt gar nicht 
zuverlässig funktionieren?

Danke,
  Olli

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Olli,

Ich lese da nur 9600bps, hast Du aber sicher auch probiert...
btw: wie schwer ist das Teil?

Ansonsten befürchte ich mal, dass der Booloader ja mehr auf Bit Banging 
angewiesen sein dürfte, was evtl. mit BT schwierig ist.
Aber das bin ich gespannt auf die anderen Antworten hier...

;)

von OlliW (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Achim
9600bps geht bei mir eigentlich nie gut, bei verschiedenen 
USB-TTL-Adaptern in verschiedenen Konfigurationen, deswegen 19200-57600. 
Frag mich aber nicht warum. Der BT-Adapter alleine wiegt 3.5 g. Das mit 
dem Bitbanging ist IMHO eine andere "Baustelle", der Bootloader benutzt 
ja normales serielles Protokoll.
Cheers, Olli

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
OlliW schrieb:
> dem Bitbanging ist IMHO eine andere "Baustelle", der Bootloader benutzt
> ja normales serielles Protokoll.
Protokoll ja, AFIAK tut er das aber nur über Bit Banging, eben nicht 
über die ATMega Hardware UART. Sonst wäre man schon auch etwas 
eingeschränkt in der Pin Wahl.
Das funktioniert ja auch ganz prima, nur evtl. ist das ja ein Problem in 
Zusammenspiel mit dem BT Modul, was dann nur mit 9600bps geht...
Vielleicht bringt es ja was ein bisschen mit dem XTAL Wert im Bootloader 
auf 9600Bps zu korrigieren.

von OlliW (Gast)


Bewertung
0 lesenswert
nicht lesenswert
das BT Modul habe ich natürlich jeweils mit dem entspr. AT-Befehl auf 
die gewählte Baudrate, also z.B. 19200, eingestellt. (mit falscher 
Baudrate geht gar nichts, auch das Übertragen einfacher serieller Daten 
nicht, ist ja aber auch irgendwo logisch :))

Du denkst wohl ein bischen in Richtung dass die Datenbytes an für sich 
schon gar nicht zuverlässig übertragen werden? Wegen z.B. ungenauem 
"Takt"? Hatte ich jetzt nicht vermutet, die Übertragung von "normalen" 
Daten, also Daten die halt einfach nur ankommen müssen aber egal wann, 
funktioniert, bzw. schien mir so. Muss ich nochmal genau testen ob es 
auch da schon zu Problemen kommt.

Thx.

von Charly B. (charly)


Bewertung
0 lesenswert
nicht lesenswert
moin moin Hagen,

besteht die moeglichkeit bei der EXE ein Eingabefeld f. das
Passwort einzubauen ?, ein PW aus der .ini wird dann im speicher
ueberschrieben, ebenso waehre es nett wenn Compile auch ohne
angeschlossene Device funktioniert.
Das wuerde das erzeugen von ACY files extrem erleichtern, vielen
dank

vlG
Charly

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Charly B. schrieb:

> besteht die moeglichkeit bei der EXE ein Eingabefeld f. das
> Passwort einzubauen ?, ein PW aus der .ini wird dann im speicher
> ueberschrieben,

Lösche das Password in der .INI Datei und bei jeder Notwendigkeit wird 
ein extra Dialog geöffnet.

> ebenso waehre es nett wenn Compile auch ohne
> angeschlossene Device funktioniert.
> Das wuerde das erzeugen von ACY files extrem erleichtern, vielen
> dank

Das wurde schon öfters gewünscht und steht auf Top 1 der ToDo Liste. Die 
Frage ist letzendlich nur wann ich mal wieder die Zeit finde, diese doch 
aufwendigere Änderung, einzubauen. Das Problem dabei ist nämlich das 
wichtige Parameter, die letzendlich von der AVRootloader Konfiguration 
im AVR abhängig sind, manuell eingegeben werden müssen.

Gruß Hagen

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt wohl morgen eine neue Version - ich hab sie schon :-)
Auch hier noch mal vielen Dank an Hagen für den schnellen support.

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
Na gut, wenn Hagen hier keine neue Version reinstellt:

Wer versioning benutzt und den flash bis in die vorletzte/letzte page 
vor dem bootloader nutzen will/muss - funktioniert nicht. Version kommt 
auf eine falsche Adresse. Nicht verzweifeln - Hagen fragen.

von micha68 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich nutze den Bootloader auch in ein einem privaten Modellbahnprojekt.


Zunächst mal Daumen hoch! Top Arbeit!


Nun würde ich gerne von meiner PC-Software aus den Bootloader füttern.
Ich programmieren in RealBasic. Hat das schon mal jemand gemacht?
Oder gibt es eine Protokollbeschreibung?
Einfachste Funktionen reichen. Wenn ich connecten und das neue hex-file 
flashen könnte wär schonmal super.

Danke und Gruss,
Micha

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Kannst du aus RealBasic die Kommandozeile benutzen ? Wenn ja ist dies 
der einfachste Weg.

AVRootloader.exe -PCOM1 -B115200 -SBOOT -Dc:\Test\ -FTest.hex -ETest.eep 
-K5441C8CA4DDF8EEA19AAAFD877AEB488 -Aepvc

Programmiert die Dateien Test.hex und Test.epp im Ordner c:\text\ über 
COM1 mit 115200 Baud verschlüsselt mit dem Key 
5441C8CA4DDF8EEA19AAAFD877AEB488 und mit dem BootSign 'BOOT', und wenn 
alles glatt gelaufen ist wird AVRootloader.exe beendet.

Gruß hagen

von Micha .. (micha68) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo hagen!

Danke für die Antwort!

Das habe ich auch schon probiert - funtioniert Prinzipiell auch - habe 
dabei aber folgendes Problem:

Meine Software ist über RS485 mit den Controllern verbunden.
Mein Versuch sah so aus, das mein Programm einen der Atmegas in den 
Bootloader geschickt hat, den ComPort geschlossen hat und über 
Kommandozeile Dein Programm gestartet hat.

Allerdings habe ich das Timingmässig nicht hinbekommen.
Entweder war der Port noch offen und Dein Programm streikt oder der 
Bootloader war im Atmega schon wieder verlassen.
Auch ein verlängern des bootdelay auf zB 1 Sekunde hats nicht gebracht.

Sollte ich - bevor ich im Atmega in den Bootloader hüpfe - noch 
irgendwelche Einstellungen, zB am UART, vornehmen?

gruss,
Micha

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Dein Program schickt deinen ATMega über RS485/232 in den Bootloader.

Dazu sendest du doch ein Kommando, damit deine Applikation auf dem AVR 
darauf reagiert ?

Das kannst du uU. auch mit dem AVRootloader machen, in der INI die Werte 
bei AppCommand, AppCommandResponse usw.

Gruß hagen

von Micha .. (micha68) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi!
Die /FF sind Hex-Werte und werden bei Programmstart an den Amega 
geschickt?
Was macht response?

Teste ich !

Danke und Gruss,
Micha

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Ja.

Du setzt

[System]
AppCmd=BootStart/0D/0A
AppCmdResponse=BootHasStarted/0D/0A

[Timeout]
AppCmd=20


AVRootloader.exe sendet vor jedem Connect den Wert in [System].AppCmd, 
wobei Sonderzeichen hexadezimal angegeben werden. Doppelslash // für 
Slash.

Dann wartet AVRootloader.exe, wenn AppCmdResponse nicht leer ist, auf 
diesen String von deiner Applikation im AVR.

Wenn AppCmdResponse empfangen wurde, oder wenn es leer ist, dann wartet 
AVRootloader.exe [Timeous].AppCmd Millisekunden bevor es mit dem 
eigentlichen Connect Aufbau beginnt.

Sollte der Connect fehlschlagen beginnt das ganze Spiel von vorne.

Es ist nun sinnvoll:

- AVRootloader.asm mit UseAutoBaud=1 und UseWDT=1 zu kompilieren
- in AVRootloader.exe die Baudrate einzustellen die deine Applikation im 
AVR benutzt

Deine Applikation im AVR empfängt also den Wert aus [System].AppCmd, 
antwortet wenn gewünscht mit dem Wert aus [System].AppCmdResponse und 
startet dann den WatchDog Timer mit minimalstem Timeout = 20ms. Der WDT 
reset den AVR und startet sauber über den Reset Vektor den Bootloader.

Das kann man auch hier im Thread alles nachlesen, ich weiß aber auch das 
der Thread ziemlich lang ist ;)

Gruß Hagen

von Micha .. (micha68) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi!

Danke für die Antwort!

Ich habe (fast) den ganzen Beitrag gelesen. Nur so zusammensetzen konnte 
ich die Infos nicht :)

Ich probiere es nachher aus...

Gruss,
Micha

von FrankJ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

als erstes will ich Hagen für den super BL danken. "Kabelgebunden" ist 
die SW (uC & PC) nicht aus dem Tritt zu bekommen.

Da kommen wir auch schon zu meinem Problem:
An einem M16 Uart hängt eine BTM-222 (SPP Profil) mit 19.2k. Ziel ist es 
Messdaten zu senden (funktioniert auch) und ab und an zu flashen. Bis 
zur Fertigstellung der SW lag die HW direkt neben dem PC und flashen 
funktionerte super (Rest auch). Jetzt hab ich die HW an ihren 
"Einsatzort" gebracht (ca. 30m entfernt) und kann nun nicht mehr flashen 
-->  Cmd.SetBuffer.ReadByte() ICOM: read error
RAM und E2P lesen geht meinsten, ebenso das (zyklische) senden der 
Messdaten. Auch Diagnosebefehle an die Applikation werden richtig 
beantwortet.
Stell ich die HW wieder zurück funktioniert auch wieder das flashen.

Ich nehme stark an, daß sich durch die Entfernung das Timing von Sende- 
/ Empfangsdaten verschlechtert. Ich habe auch versucht in der INI Datei 
die TO zu verändern - leider ohne Erfolg.

Habt Ihr einen Tipp wie wieder ein stabiles flashen möglich wird ?

Gruß
Frank

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
experimentiere mal mit
-> AVRootloader.ini -> [Timeous] -> MaxPacketSize=64...512

Ich würde nämlich eher davon ausgehen das das BTM-222 mit großen 
kontinuierlichen Datenpacketen, die ja beim FLASH/EEPROM programmieren 
auftreten und der Unterschid zu den anderen Packeten sind, nicht zurecht 
kommt.

Ich habe selber mal mit dem BTM-222 Teilen rumgespielt und wenn ich eine 
Wette abgeben müsste über deren Software dann das diese Software über 
eine Mainloop per Polling jedes einzelnen Zeichens arbeitet und 
demzufolge nicht interruptgesteuert geschweige denn ansynchron arbeitet 
(also Mist aus Sicht der SW-Entwicklung ist).

MaxPacketSize setzt nun die maximale Packetgröße die die PC-Software 
versendet. Normalerweise ist diese die maximale Größe des im AVR 
vorhandenen SRAM Speichers minus par Zerquetschte für den Stack etc.pp. 
Hat man nun einen Big-AVR mit viel SRAM dann kann diese Packetgröße 
schonmal 1-8Kb betragen. Normalerweise ist es günstig wenn die 
Packetgröße möglichst groß gewählt wird da so das SW-Handshaking 
reduziert wird und ergo die Gesamtperformance steigt.

MaxPacktSize limitiert dieses Verhalten künstlich und wurde damals 
eingebaut als es um die Unterstützung der TCP/IP-XPorts übers INet ging. 
Denn auch dort gab es Latenzen die proportional zur Packetgröße zunahmen 
und irgendwann so groß wurden das die Timeouts überschritten wurden. 
Auch dort lag es letzendlich an der Softwareimplementierung der 
Windows-XPorts Treiber.

Und wenn du kannst gehe mal mit der Baudrate runter, je mehr Zeit die 
BMT-222 Software pro Zeichen in Relation zur Blutooth-Datenrate bekommt 
desto besser.

Gruß Hagen

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
Ach und lass uns nicht dumm sterben falls du es hinbekommst ;)

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
und noch was: setze AVRootloader.ini -> [Options] ->  = 2 das aktiviert 
den "Debug-Modus" der Software. Wenn du dann eine Connection aufgebaut 
hast schaust du in das Protokoll rein und kannst dort nachschauen mit 
wlcher MaxPacketSize sie real läuft. Nicht jeder Wert in der INI bei 
MaxPacketSize kann benutzt werden, es bedarf eine Mindestgröße und ein 
Mehrfaches einer FLASH Page, logisch da nur komplette Pages programmiert 
werden können.

Gruß hagen

von FrankJ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

danke für deine Bemühungen, natürlich werde ich alle Infos her 
verteilen.

Also:
1. Options=2
Damit bekomme ich gar keine Verbindung mehr. Bei mir gehen nur "0" für 
deaktivierte Debug-Infos und "1" für aktive Debug-Infos.
Bei "1" sehe ich alle TOs (auch max Package Size)

2. MaxPacketSize=64...512
Der M16 hat ja 128B Pages, hab also alles von 128 bis 512 getestet (wird 
auch bei den Debug-Infos  angezeigt) → leider kein Unterschied

3. Base=120
Dieser Parameter hat massiven Einfluss auf die „Übertragungsqualität“. 
Ist er zu hoch geht zuerst das SRAM lesen und dann das E2P lesen nicht 
mehr. Bei  zu kleinen Werten geht’s natürlich auch nicht mehr. „Bester“ 
Wert ist so bei 120

4. Enfernung
Bei ca. 30m bekomme ich das hier:
09.05.12-21:06:02-937 > Connecting on port COM12...
09.05.12-21:06:07-078 > Device connected
09.05.12-21:06:11-078 > Reading EEPROM...
09.05.12-21:06:14-765 > Reading SRAM...
09.05.12-21:06:37-328 > Program...
09.05.12-21:06:37-375 > execute compiled data
09.05.12-21:06:37-375 > selected options in compiled file:
09.05.12-21:06:37-375 > - programming FLASH
09.05.12-21:06:37-375 > - erase FLASH during programming
09.05.12-21:06:37-375 > - full verify FLASH after programing
09.05.12-21:06:38-562 > Cmd.SetBuffer.ReadByte() ICOM: read error.
09.05.12-21:06:39-578 > Device disconnected

Direkt neben den PC das hier:
09.05.12-20:58:04-328 > Connecting on port COM7...
09.05.12-20:58:09-843 > Device connected
09.05.12-20:58:15-546 > Reading EEPROM...
09.05.12-20:58:22-703 > Reading SRAM...
09.05.12-20:58:31-953 > Program...
09.05.12-20:58:32-031 > execute compiled data
09.05.12-20:58:32-031 > selected options in compiled file:
09.05.12-20:58:32-031 > - programming FLASH
09.05.12-20:58:32-031 > - erase FLASH during programming
09.05.12-20:58:32-031 > - full verify FLASH after programing
09.05.12-20:58:48-640 > executed in 16,61 sec
09.05.12-20:58:55-937 > Device disconnected

(unterschiedliche COMs kommen durch das von mir getriggert „neu finden“)

Als Info noch der Rest der INI:
[System]
Sign=BOOTLOADER
Port=COM12
Baudrate=19200
ConnectTrials=1
FLASH=X:\Zisterne\1_src\_out\zisterne.hex
EEPROM=
ASMFile=AVRootloader.asm
Erase=1
Verify=1
Protocol=0
Password=
AppCmd=$/0A/F0/02/0D
AppCmdResponse=Start_BL
;AppCmdResponse=
AppVersion=$01020000
AppVersionFlag=$00
ACYInfo=

[Timeouts]
Connect=0
Base=120
Erase=50
Flash=50
Eeprom=50
Buffer=10
AppCmd=1
KeepAlive=500
MaxPacketSize=0
RTSPulse=0
RTSInterval=0
Options=0

An allen TOs habe ich auch schon (planlos) gedreht.
Ich bin leider etwas Ratlos …

Gruß
Frank

von Hagen R. (hagen)


Bewertung
0 lesenswert
nicht lesenswert
bleibt nur noch:

1. Baudrate runter
2. Fehler im BTM-222 suchen:
- zB. alle Versorungspins mit Blockkondensatoren
- Qualität der Funkstrecke sicherstellen, denke das das ja den 
Unterschied ausmacht
3. [Timeouts] -> Flash höher setzen, das ist der Wert der bestimmt wie 
lange die Sofwtare nach einem FLASH Commando wartet
4. letzendlich die Feststellung das der Bootloader nicht mit dem BTM 
funktioniert

Mehr kann ich leider auch nicht helfen.

Gruß hagen

von Matthias W. (tius)


Bewertung
0 lesenswert
nicht lesenswert
Lieber Hagen,

kurze Frage: Warum hast Du Dich für XTEA + Doppel-CBC statt XXTEA 
entschieden? Ich nehme an, dass die "eingebaute" Prüfsumme über alles 
ein Vorteil Deiner Lösung ist. Wenn ich das richtig verstehe, wäre XXTEA 
dafür schneller bei großen Blöcken (XTEA: N * 32 Runden, XXTEA: (N * 6 + 
52 Runden).

Viele Grüße und schon vorab danke für Dein Feedback!

Tius

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das hatte mehrere Gründe:

1. XTEA ist auf AVRs effizienter
2. mit XTEA hatte ich Erfahrungswerte, XXTEA kannte ich damals noch 
garnicht
3. alle Angriffe auf XTEA/XXTEA usw. brauchen bestimmte Vorrausetzungen 
die in der Benutzung im AVRootloader nicht gegeben sind.


Zu Punkt 3.

Es geht primär um Known Plain Text Angriffe. Dh. der Angreifer ist 
praktisch in der Lage eine gezielt gewählte Nachricht, unverschlüsselt, 
dem Angegriffenen so unter zu schieben das dieser auf seinem System mit 
seinem Passwort diese Nachricht verschlüsselt und diesen Ciphertext 
wieder zum Angreifer zur Analyse sendet. Natürlich reicht da nicht eine 
solche Nachricht alleine sondern es müssen schon tausende solcher 
Nachrichten durchgeschleust werden damit dieser Angriff funktioniert. Es 
handelt sich also im praktischen Sinne um einen sehr theoretischen, eg. 
analytischen Angriff.

Die Arbeitsweise des AVRootloader widerspricht diesem Verhalten. Warum 
sollte ein Herausgeber einer verschlüsselten HEX Datei nun für Andere 
tausende HEX Dateien mit seinem Schlüssel verschlüsseln wollen ?

Dazu kommen aber noch par andere Punkte:

Mein XTEA benutzt einen äußeren Feedback Modus. Dieser soll 
normalerweise die Abhängigkeiten zwischen allen sukzessiven 
Nachrichtenblöcken, Teilstücke der Nachricht, inkrementieren. Dh. nur 
wenn alle vorherigen Blöcke korrekt entschlüsselt wurden soll der 
aktuelle Block ebenfalls korrekt entschlüsselt werden. Mit anderen 
Worten: der letzte Block soll nur dann korrekt entschlüsselt werden wenn 
die komplette Nachricht davor es auch wurde. Das macht mein Doppel-CBC. 
Er teilt die 32 Runden des XTEAs in 2x 16 Runden und macht vor beiden 
16'er Runden die CBC-Feedback Operation. Somit bewirkt diese Feedback 
Operation bei der 2'ten 16'er Runde das in die internen Statusregister 
des XTEAs Informationen einfließen die aus den teilverschlüsselten 
Nachrichtenbits bestehen. Die Nachricht wird also indirekt (eg. 
verschlüsselt) in den internen XTEA Status eingerechnet und damit ist 
die komplette Verschlüsselung meiner XTEA Variante nicht nur vom 
Schlüssel selber sondern auch von der Nachricht die verschlüsselt wird 
abhängig, die Nachricht wird zu einem Teil des Schlüssels. Nun kommt der 
Fakt hinzu das die AVRootloader Software jede Nachricht mit einem 
zufälligen Datenblock am Anfang der Nachricht vor der Verschlüsselung 
expandiert. Dh. in den XTEA laufen als erstes 16 Bytes an Zufall rein 
und somit ist dies ähnlich wie ein externer, unverschlüsselter 
zufälliger InitVector. Das hat zur Folge das man eben keine Known Plain 
Text Angrigffe mehr sinnvoll durchführen kann da der real benutzte Plain 
Text in der AVRootloader Software für den Angreifer eben unbekannt ist. 
Da ja die bekannte HEX Datei noch intern um 16 Bytes Zufall am Anfang 
expandiert wurde die dem Angreifer aber unbekannt sind, und da der 
Doppel-CBC Modus sicherstellt das der interne Status der XTEA Register 
auch immer indirekt abhängig sind vom verschlüsselten Nachrichtenblock, 
hier also der zufällig gewählte 16 Bytes Block gleich zu Begin der 
Verschlüsselung der aber Einfluß hat auf alle nachfolgendenen Datenbits 
der kompletten Nachricht. Ergo: Known Plain Text Attack mit AVRootloader 
ist unpraktikabel.

Positiver Seiteneffekt ist nun das man am Ende der Nachricht einen 
Signaturblock verschlüsselt dranhängen kann der später bei der 
Entschlüsselung als Verfikation dienen kann. Ich benutze dazu 4 Bytes 
des benutzten XTEA Schlüssels. Da dies nur ein kleiner Teil des 
kompletten Keys ist denke ich ist das der beste Kompromiss ist, besser 
als mit einer allgmein bekannten Signatur zu arbeiten, da ja der Key 
selber für jeden Anwender und Projekt zufällig gewählt wird.

Für die Bewertung der Sicherheit eines Systemes reicht es also nicht aus 
sich nur auf die Sicherheit des Ciphers alleine zu konzentrieren sondern 
man muß immer das Gesamtsystem analysieren. Im Falle des AVRootloaders 
heist dies das die Benutzung des speziellen Feedback Modus, die 
Anwendung eines verschlüsselten internen IVs, das geplante 
Benutzerverhalten usw. es sicher macht. Ein Cipher wird nicht 
zwangsläufig unsicher in einem jeweiligen Kontext nur weil er auf 
spezielisierte Angriffe anfällig ist. Denoch sollte man bei der Wahl des 
Ciphers während der Planung eines Sicherheitskonzeptes natürlich schon 
bekannt schwache Cipher nicht mehr berücksichtigen ;)

Gruß Hagen

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zur Korrektur für die Experten: oben meinte ich Known und/oder Choosen 
Plain Text Angriffe. Beide werden erschwert. Choosen Plain Text ist eine 
Untergruppe der Known Plain Text Angriffe wobei der Angreigfer den 
Inhalt des Plain Texts gezielt beeinflussen kann. Known Plain Text heist 
erstmal nur das der Plain Text bekannt ist. Und dies träfe auf AVR HEX 
Files auch mit hoher Wahrscheinlichkeit zu da ja am Anfang jedes HEX 
Files mit hoher wahrscheinlichkeit immer ähnliche Dateninhalte 
vorkommen, sprich ISR Vektoren, bekannter Startup Code des C Compilers 
usw. Deswegen stand es ausser Frage das der AVRootloader jede Nachricht, 
eg. HEX File, am Anfang mit Zufallsbytes expandiert und der Feedbak 
Modus eine "Alles oder Nichts" Verschlüsselung garantieren musste.

Gruß Hagen

von Matthias W. (tius)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

vielen Dank für die ausführlichen Erläuterungen! Bei mir geht es um eine 
andere Anwendung, da muss ich das wohl selber noch einmal bewerten.

Zur Sicherheit will ich die Punkte noch einmal kurz zusammenfassen:

1. Effizienz
Ich kenne bisher keine XXTEA-Implementierung in Assembler für AVR. Das 
Verfahren sieht etwas komplexer aus als XTEA, dafür ist die Rundenzahl 
bis zu Faktor 5 kleiner. Käme aus meiner Sicht auf einen Versuch an. 
Allerdings dürfte ich Schwierigkeiten haben, Deinen Optimierungsgrad in 
Assembler zu erreichen. Das spricht zunächst sehr für XTEA :-)

2. Erfahrungswerte
Habe ich weder für XTEA noch für XXTEA. Soweit ich die Analysen (v. a. 
http://eprint.iacr.org/2010/254.pdf) verstanden habe, haben beide 
Verfahren theoretische Schwächen, sind aber für mittlere 
Sicherheitsanforderungen mehr als ausreichend. Natürlich nur, wenn kein 
Fehler bei der Verwendung gemacht wird. XXTEA ist wohl aufgrund der 
kleineren Rundenzahl tendenziell schwächer ("We describe a
chosen plaintext attack for XXTEA using about 2^59 queries and 
negligible work.")

3. IV
Der erste Block sollte sich natürlich auf keinen Fall wiederholen. Dein 
Verfahren wirkt wie ein veränderlicher IV und scheint mir dafür gut 
geeignet zu sein. Bei Verwendung von XXTEA könnte das ähnlich erfolgen.

4. Doppel-CBC und geheime Signatur
Da reicht mein kryptografisches Verständnis leider bei weitem nicht. 
Einen geeigneten Betriebsmodus braucht man natürlich zwingend bei XTEA. 
Wenn ich das richtig verstehe, nutzt Du die Fehlerfortpflanzung und die 
Signatur bei Deinem Verfahren zur sicheren Erkennung der Integrität der 
Gesamtdaten. Bei einem Betriebsmodus ohne Fehlerfortpflanzung müsste 
also Integrität anderweitig sichergestellt werden.

Viele Grüße und noch einmal herzlichen Dank für die Infos!
Tius

von Hagen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
1. Effizienz

XXTEA wird meines Erachtens inperformanter sein, ich lasse mich aber 
gerne vom Gegenteil überzeugen. Begünden würde ich meine Aussage mit dem 
Fakt das der Registerdruck und SRAM verbrauch für Zwischenresultate, auf 
grund der größeren Blockgröße, ansteigt. Somit steigt die Anzahl von 
Registerkopieroperationen und Variablen. Ich habe sehr bewusst mich für 
XTEA entschieden, zur Auswahl stand auch zB. RC4, weil man alle 
Parameter schon in Registern halten kann.

2.

>("We describe a
>chosen plaintext attack for XXTEA using about 2^59 queries and
>negligible work.")

Mal überlegt wieviel 2^59 ist ?
Angenommen pro Query 1 Mikrosekunde dann sind dies 18279 Jahre 
Rechenzeit. Für einen Mathematiker/Kryptographen ist es korrekt 
infinitimal zu denken, ein Techniker sollte solche Aussagen einfach mal 
nachrechnen ;)

Und wie gesagt, mit Hilfe des verschlüsselten und für den Angreifer 
unbekannten IVs erledigt sich ein solcher Angriff, bzw. wird 2^(8 * IV 
Länge in Bytes) = 2^128, im Fall vom AVRootloader, mal komplizierter.


3. IV

Der InitVector muß nicht zwangsläufig geheim sein. Standard ist es sogar 
so das dieser einfach ein mit Zufall befüllter 0. Datenblock ist der 
eben nicht verschlüssselt wird. Der IV sollte mit Zufall befüllt werden 
und ist damit immer veränderlich bezogen auf seinen Inhalt. Technisch 
muß der IV denoch mit den verschlüsselten Daten gespeichert werden.

Ich bevorzuge dagegen diesen IV mit zu verschlüsseln so als wenn man die 
eigentliche Nachricht am Anfang vor der Verschlüsselung um Zufallsbytes 
erweitert hat. Technisch bleibt es der gleiche Aufwand wie vorher aber 
dieser Zufall ist eben noch zusätzlich durch das Passwort des Ciphers 
geschützt. Somit stehen für einen Angreifer weniger Informationen zur 
Verfügung als mit externem unverschlüsselten IV.

Und wie ichs oben schon verargumentierte heist dies das Known Plain Text 
Angriffe eben schwierger werden da ein wichtiger Teil des realen Plain 
Texts eben nicht mehr unverschlüsselt/ungeschützt ist.

4. Doppel-CBC und geheime Signatur

>Wenn ich das richtig verstehe, nutzt Du die Fehlerfortpflanzung und die
>Signatur bei Deinem Verfahren zur sicheren Erkennung der Integrität der
>Gesamtdaten. Bei einem Betriebsmodus ohne Fehlerfortpflanzung müsste
>also Integrität anderweitig sichergestellt werden.

Korrekt. CBC ist normalerweise ein sich selbst synchronisierender 
Feedback Modus. Tritt ein Bitfehler in einem Block auf dann ist 
mindestens dieser Block und eventuell der nachfolgende Block falsch 
entschlüsselt. Spätestens der übernächste Datenblock wird wieder korrekt 
entschlüsselt. Die Wahl was man nun nimmt hängt von der Zielsetzung ab. 
Im Fall des AVRootloaders ist es ganz einfach diese Entscheidung zu 
treffen. Was für einen Sinn hat es wenn ein x kBytes Program geflasht 
wird wenn nur ein einziges Bit falsch geflsht wurde ? Keinen. Ergo ist 
keine Selbstsynchronisation notwendig sondern das exakte Gegenteil. Es 
muß sichergestellt werden können, mit höherer bzw. gleichhoher 
mathematisch statistischer Wahrscheinlichkeit als die Wahrscheinlichkeit 
das eine FLASH Speicherzelle stirbt, das man fehlerhafte Übertragungen 
oder unberechtigte Manipulatonen am Bitstrom detektieren kann.

Gruß Hagen

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
hi,
Ich würde gern die DLL in einem eigenen kleinen Tool benutzen. Hat denn 
jemand zufälligerweise ein kleines Beispielprojekt, wo die dll schon 
benutzt wird?
Ich habe keinenblassen schimmer, wie ich die dll benutzen muss.
viel dokumentation ist da ja leider auch nicht drin ;(
Sprache sollte irgendwas aus c#, c++ oder delphi sein.

Danke Vlad

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

Ich mein Tool jetzt mit Delphi gebaut, aber ich komme mit der 
AVRootloader-Integration nicht wirklich weiter.

Unten bestehenden Code habe ich mir aus Fragmenten in diesem Thread 
zusammengeklaubt.

Allerdings bleibt er irgendwann hängen.
die letzte Callback in die er geht ist die GetAppCmdResponse.


Dannach gibts eine laaange Wartezeit und dann kommt eine MessageBox:
  I  Project xyz raised too many consecutive exceptions: 
     'integer divide by zero at 0x0036c8e2'. Process Stopped. Use Step or Run to continue.
         [OK] [&Help]

@HAgen,
wär es nicht möglich, dass du ein komplettes Minimal-Programm postest?

das unter
Beitrag "Re: AVR-Bootloader mit Verschlüsselung"
ist veraltet


procedure TLedConfigTool.BtnWriteToEEPROMClick(Sender: TObject);
var bootloader:IAVRootloader;
begin
  bootloader := OpenAVRootloader(self);
  bootloader.DoProgram(False, False);
  bootloader.DoDisconnect();
end;


    // Avr Rootloader wants this
function TLedConfigTool.ProcessMessages:bool;
begin
  Result := true;
end;

procedure TLedConfigTool.Changed;
begin
end;

procedure TLedConfigTool.Output(const Msg: WideString; Code: Integer);
begin
  memo1.Lines.Append(Msg + '  0x' + IntToHex(code, 8));
end;

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

function TLedConfigTool.GetEEPROMFileName: WideString;
begin
  Result := 'test.eep';
end;

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

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

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

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

function TLedConfigTool.OpenCommunication(Index: Integer): ICOM;
begin
  Result := nil;
  if(index = 1) then
  begin
    Result := OpenCOM('\\.\COM4', Self);
    Result.SetParams(9600);
  end;
end;

function TLedConfigTool.GetAppCmd: WideString; stdcall;
begin
  Result := '';
end;

function TLedConfigTool.GetAppCmdResponse: WideString; stdcall;
begin
  Result := '';
end;

function TLedConfigTool.GetAppVersion(Masked: Bool = False): Integer; stdcall;
begin
  Result := 0;
end;


function TLedConfigTool.GetACYInfo: WideString; stdcall;
begin
  Result := '';
end;


von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
ok, mir ist jetzt aufgefallen, dass die TTimeouts mehr werte enthält und 
die ProcessMessage-Methode false zurückgeben sollte.
Außerdem habe ich noch try-catches um die Interface-calls gemacht.

die entsprechenden geänderte Routinen siehe unten.

Das Connect scheint jetzt zu klappen.
beim programm bekomme ich allerdings folgende Ausgabe:
send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54  0x10000000
received data   $91 08 06 10 30  0x10000000
Device connected  0x10000000
Program...  0x10000000
execute compiled data  0x10000000
selected options in compiled file:  0x10000000
- programming EEPROM  0x10000000
Cmd.SetAddr.ReadByte() ICOM: read error.  0x11000000
Device disconnected  0x10000000

Ich bekomme allerdigns keine Exception von der Dll.

Ein weiteres Problem ist, dass ich nicht weiß, wo ich den Communicatoin 
Port wieder schließen soll.

Wieseo sact er "execute compiled data"? ich gebe ihm doch nur ein 
eeprom-file.

Ein anderes Problem, was ich habe ist, dass ich den Code nicht 
vernünftig debuggen kann, da Delphi ständig wegen Exceütions meckert, 
die jedoch wieder gefangen werden.


procedure TLedConfigTool.BtnWriteToEEPROMClick(Sender: TObject);
var bootloader:IAVRootloader;
begin
  Try
    bootloader := OpenAVRootloader(self);
    bootloader.DoProgram(False, False);
    bootloader.DoDisconnect();
  except
    on E : Exception do
      ShowMessage(E.ClassName+' error raised, with message : '+E.Message);
  end;
end;


    // Avr Rootloader wants this
function TLedConfigTool.ProcessMessages:bool;
begin
  Result := false;
end;

function TLedConfigTool.GetTimeouts: TTimeouts;
begin
  Result.Baudrate := 9600;
  Result.Connect :=0;
  Result.Base := 50;
  Result.Erase := 10;
  Result.Flash := 15;
  Result.Eeprom := 10;
  Result.Buffer := 1;
  Result.AppCmd := 100;
  Result.KeepAlive := 250;
  Result.RTSPulse := 0;
  Result.RTSInterval := 0;
  Result.ConnectTrials := 10;
  Result.MaxPacketSize := 0;
  Result.Options := 1;
end;

function TLedConfigTool.OpenCommunication(Index: Integer): ICOM;
begin
  Result := nil;
  if(index = 1) then
  begin
    Try
      Result := OpenCOM('\\.\COM4', Self);
      Result.SetParams(9600);
    except
      on E : Exception do
        ShowMessage(E.ClassName+' error raised, with message : '+E.Message);
    end;
  end;
end;


Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.