mikrocontroller.net

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


Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Arne:

Ich wäre sehr daran interessiert wenn deine bisherige Arbeit weiter 
perfektioniert würde. Melde dich bitte bei mir per PN und wir können 
dann besprechen wie ich dich besser unterstützen kann (Sourcen usw.).

Zum Problem "offline ACY":
Ich habe es mal in meine Todo Liste aufgenommen. Es bestehen drei 
Lösungen für dieses Problem. Per GUI wählt man AVR, Bootloader Größe 
etc.pp. vor der Compilierung aus. Drückt man also auf den Compile Button 
erschiene ein Dialog. In diesem Auswahlelemente für die fehlenden Daten 
die auch automatisch von einem connected Device befüllt werden können. 
Alternativ dann von einem AVRootloader.asm, also dem aktuellen Source 
des Bootloaders, geparst werden können. Dieser Dialog eröffnet also die 
Möglichkeit entweder manuell, automatisch aus verbundenen Device oder 
ausgelesen aus einem AVRootloader.asm alle Parameter zu setzen. So würde 
ich mir diese Änderung vorstellen damit ich mit diesen Änderungen und 
dem verbundenen Aufwand gleich mehrere Fliegen mit einer Klappe 
erschlagen kann (lohnt ansonsten ja nicht). Ist halt bischen Arbeit da 
ich einiges am Basic Code verändern müsste, mal schauen.

Demnächst wollte ich sowieso noch ein weiteres Feature einbauen (merge 
zweier HEX Files um Bootloader HEX und App HEX in einem Rutsch 
programmieren zu können).

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Arne:

Habe mir mal deinen Source angeschaut. Weist du ob Lazaraus auch 
Interfaces unterstützt ? Wenn ja dann wäre es doch viel besser wenn du 
mein Interfaces Source gleich direkt benutzt da ich meine das dieser 
portierbar nach Lazarus sein müsste. Dieser Source beinhalted alles 
ausser dem GUI. Dh. die komplette Protokollebene und Kommunikationsebene 
wäre fast fertig. Fehlte nur noch das GUI und das wäre Fleißarbeit. Ich 
habe versucht möglichst Delphi VCL und Windows API entfernt zu arbeiten 
(geht bei den Kommunikationsinterface natürlich nicht so einfach).

Gruß Hagen

Autor: ARV (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, Hagen!
You have news concerning to "offline ACY"?
Sorry, but my Deutsch is much worse than English.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ARV: no sorry, upto date timing is critical.

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Zuerst möchte ich mich für den tollen Bootloader und die darin steckende 
Arbeit bedanken!

Allerdings habe ich jetzt ein seltsames Problem und könnte ein bisschen 
Hilfe gebrauchen.
Zunächst (am Dienstag) habe ich den Bootloader für 1-Wire Betrieb mit 
nicht invertiertem Uart für einen Mega8 (8MHz, Autobaud, nicht 
verschlüsselt) kompiliert und auf den Controller geflasht. Zum 
Programmieren habe ich die Schaltung aus dem beigefügten Bild verwendet, 
direkt an eine echte RS232. Die Dioden waren BAT46, als Widerstand habe 
ich 3k3 verwendet, da grad kein 2k7 verfügbar war.

Zwei Mega8 konnte ich so problemlos (auf jeweils verschiedenen Pins) 
ansprechen und flashen. Zugriff aur Ram/EEprom ging auch (nachdem ich 
dann die BOOTRST Fuse programmiert hatte)

Am nächsten Tag wollte ich dann auch einen Mega32 mit Bootloader 
ausstatten, allerdings reagierte er nicht auf die Verbindungsversuche.
Zunächst dachte ich an ein Problem mit dem Controller, egal ob Software- 
oder Hadrwareseitig, also hab ich nochmal die M8 vom vortag angeklemmt. 
Hier tat sich diesmal aber auch nichts, egal mit welcher Baudrate ich es 
versucht habe.
Danach hatte ich befürchtet, dass es die Schnittstelle erwischt hat, 
darum habe ich im Terminal getestet, ob gesendete Zeichen am Eingang 
wieder reinkommen. Schnittstelle OK.
Mein nächster Verdacht war, dass das Windowsprogramm aus irgendeinem 
Grund nichts mehr sendet. Das habe ich dann mit dem Oszilloskop auch 
ausschließen können. Sauberer +-12V Hub.
Mit dem Programmieradapter am AVR Pin sieht man das gleiche Muster, 
allerdings eben im Bereich von 0-5V und mit nicht ganz so steilen, bzw. 
etwas verrundeten steigenden Flanken.

So langsam gehen mir jetzt aber die Ideen aus, was noch falsch laufen 
könnte. Hat jemand eine Idee?
Falls das hilft könnte ich versuchen, das Oszillogramm auf den Rechner 
zu kriegen und hochzuladen.

Gruß,
Timo

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Timo,
ich hatte auch Probleme mit dem mega32 (siehe weiter oben), allerdings 
nicht one-wire.
Das Setzen der CKOPT-Fuse brachte das Teil zum laufen, evtl. geht das 
bei dir auch?

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thilo,
CKOPT Fuse ist bereits gesetzt, hat bei mir aber leider keine 
Veränderung gebracht.
Am meisten wundert mich bei der ganzen Sache ja, dass es mit den Mega8 
am Anfang funktioniert hat.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ändere mal in AVRootloader.inc den Wert bei BaudTolerance von 3 auf zb. 
5 oder höher. Je nach MCU-Takt und ausgewählter Baudrate ist die 
Baudraten Toleranz von 3 zu optimistisch gewählt. Mein aktuelles Projekt 
hatte damit Probleme, tratt hier also zum ersten Mal als Problem auf, 
und eine Änderung auf 5 beseitigte es.

Gruß Hagen

Autor: L. Schreyer (lschreyer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich erhalte seit einigen Tagen auf einmal diese Fehlermeldung beim 
Upload von Firmware:

15.08.09-10:49:30-578 > Connecting...
15.08.09-10:49:30-703 > Switch to 2-Wire mode
15.08.09-10:49:32-140 > Device connected
15.08.09-10:49:32-140 > Program...
15.08.09-10:49:32-234 > execute compiled data
15.08.09-10:49:32-234 > selected options in compiled file:
15.08.09-10:49:32-234 > - programming FLASH
15.08.09-10:49:32-234 > - FLASH data are encrypted
15.08.09-10:49:32-234 > - erase FLASH during programming
15.08.09-10:49:32-234 > - full verify FLASH after programing
15.08.09-10:49:32-328 > Cmd.SetAddr.ResCheck()  Error: Invalid checksum
15.08.09-10:49:32-328 > Device disconnected


Bisher ging es immer problemlos. Das komische ist: Meine eigene Software 
mit der DLL geht problemlos, nur die Avrootloader-Windows-Software gibt 
diese Meldung aus. Was könnte das bloß sein?

Louis

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schwer zu sagen. Benutzt du das Versioning ?

Probiere doch erstmal ohne Verify zu arbeiten und schaue ob der Fehler 
dann immer noch passiert.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
15.08.09-10:49:30-578 > Connecting...
15.08.09-10:49:30-703 > Switch to 2-Wire mode
15.08.09-10:49:32-140 > Device connected

Das deutet auf eine alte Bootloader Version hin. Installiere bitte die 
neuste Version 6.

Erkennen kannst du das daran das er explizit auf 2-Wire-Mode umschaltet. 
Das hat die ältere Version so gehandhabt, die standardmäßig auf 1-Wire 
eingestellt ist und beim Verbindungsaufbau erkennt das 2-Wire vorliegt. 
Die neue Version (ab Version 4 glaube ich) geht exakt andersherum vor. 
Standardmäßig 2-Wire und erkennt bei Bedarf 1-Wire.

Gruß Hagen

Autor: L. Schreyer (lschreyer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

versioning verwende ich nicht, ich habe einen Bootsign gesetzt um die 
verschiedene Hardware zu unterscheiden.

Die neueste Version zeigt dieselbe Meldung...

Ich habe nichts verändert, flashe die Datei schon seit Monaten. Ist 
schon seltsam, zumal es über die DLL geht.

Louis

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auch ohne Verify ? und BootSign korrekt ?

Gruß Hagen

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo*

Autor: L. Schreyer (lschreyer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Args, ich bin noch nicht dazu gekommen das zu testen, wird noch 
nachgeholt.

Louis

Autor: Vladimir (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,
danke für deinen exzellenten Bootloader!

Ich brauche eine zusätzliche Möglichkeit bei zwei gleichzeitig 
gedruckten Tasten am Gerät bei einschalten Bootloader starten.
Nur Assembler gehört nicht zu meinen Stärksten…

Tasten Abfrage habe ich so realisiert:

...
.include "AVRootloader.inc"
;.listmac
.list


.org BootStart
init:  cli
;-----------------------------
.def  tmp  = r28
.def  tmp1  = r29

   ldi   tmp, $00
   out   DDRA, tmp  ;PORTA als Eingang
   ldi   tmp, 0b11111100
   out   PORTA, tmp  ;PullUp

   in   tmp, PINA
   andi tmp, 0b10001000
   ldi   tmp1, 0b10001000
   eor   tmp, Tmp1
   ldi   tmp1, 0
   cpi   tmp, 0b10001000
   brne NoButtons
   ldi   tmp1, 1    ;wenn gedruckt, immer auf PC warten (tmp1=1)

NoButtons:    ;sonst starten wie immer
;-----------------------------
   clr    zerol

.if Use1Wire
u.s.w….

Frage:
was soll ich am Besten ändern und, wenn möglich, wie?
ich verwende "fixed baudrate, identifier scanning with timeout"
also in dem Fall timeout soll unendlich dauern?

Hochachtungsvoll

Vladimir

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachfolgend die zwei Stellen im ASM die du änderst:
check:  xwdr
        sbrs    PIND, PD0
        sbrc    PIND, PD1
        rjmpapp

; baudrate and identifier scanning
.if UseResetDelay    
abd:  
.endif

...
...

; identifier (BootSign) scanning with timeout and checksum

id1:     sbiw   xl, 1                ; UART getc with timeouts
         sbc    cmdl, zerol
         rx_1 
         brne   id1
id2:     breq   check; exit
id3:     sbiw   xl, 1
         sbc    cmdl, zerol
         rx_0
         brne   id3
         breq   check; exit
         rcall  getx
...
...


Bei Label check:
- Watchdog, falls eingeschaltet, zurücksetzen
- beide Pins abfragen, hier low-active
- wenn nicht beide gedrückt mit jmpapp die Anwendung starten

danach normale Baudrate Detection und BootSign Detection. Falls eines 
davon fehlschlägt Sprung nach Label Check: statt Label Exit:

Deine Tasterpins sollten per internem Pullup arbeiten und nach GND 
gezogen werden. Falls es nicht so ist musst du die sbrs/sbrc Abfragen 
umdrehen.

Wenn nicht beide Tasten gedrückt sind startet sofort deine Anwendung. 
Solange beide Tasten gedrückt sind wird auf einen gültigen Connect 
gewartet, ohne Timeout oder Watchdog RESET.

Gruß Hagen

PS: ich habe das jetzt nicht getestet sondern hier live eingetippt.

Autor: Vladimir Medvedev (wim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke! Jetzt alles funkzioniert wie ich wollte.
Nach deinem Vorschlag ich habe das so gemacht:

.org BootStart
init:   cli
        clr    zerol
;-----------------------------
        ldi   r28, $00
        out   DDRA, r28       ;PORTA als Eingang
        ldi   r28, 0b11111100
        out   PORTA, r28      ;PullUp

        ldi   r28, 0
        sbis  PINA, PA7       ;Pruefen, ob PfeilNachUnten gedruckt ist
        sbic  PINA, PA3       ;Pruefen, ob PfeilNachOben gedruckt ist
        rjmp  NoButtons
        ldi   r28, 1          ;Sonst warten auf PC unendlich (r28=1)
        sbi    PORTD, PD6     ;Led "OK" ein
NoButtons:
;-----------------------------

...
...

; fixed baudrate, identifier scanning with timeout
        ldi    cmdl, byte1(Baudrate)
        ldi    cmdh, byte2(Baudrate)
        movw  baudl, cmdl
;-------------------------------------
        rjmp  abd
abd0:   cpi    r28, 1
        brne  exit
;-------------------------------------
abd:    movw  xl, zerol
        ldi    cmdl, byte3(BootDelay / 6)
ab1:    ldi    parah, (BootInfo - BootSign) * 2
        ldi    zl, byte1(BootSign * 2)
        ldi    zh,  byte2(BootSign * 2)
ab2:    rx_1
        rjmp    ab2
ab3:    sbiw  xl, 1
        sbc    cmdl, zerol
        rx_0
        brne  ab3
        ;breq  exit
;-------------------------------------
        breq  abd0
;-------------------------------------
        rcall  getx
        xlpm  r0, z+
        cp    r0, paral
        brne  abd
        dec    parah
        brne  ab2

.endif
; send info about chip/bootloader

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bedenke das mit deiner Lösung du mit beiden gedrückten Tasten in die 
Baudrate/Bootinfo Schleife reinkommst aber nur mit einem Connect oder 
eben RESET wieder raus. Bei meinem Vorschlag bleibt der Bootloader so 
lange in dieser Schleife wie entweder beide Tasten gedrückt sind oder 
ein Connect erfolgte. Dh. ist der AVR noch in dieser Schleife, also ohne 
gültigem Connect, und werden die Tasten losgelassen so startet die 
installierte Anwendung.

Gruß Hagen

Autor: Vladimir Medvedev (wim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast recht. Aber genau das war mein Ziel. In einigen Fällen beim 
Update passieren unerwünschte Fehler. Dann weiteres Update ist nicht 
möglich. Hauptprogramme existiert nicht mehr und Kunde kommt nicht in 
Bootloader. Jetzt, wenn so was passiert, Kunde trotzdem hat Möglichkeit 
Bootloader starten.

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

Dein Bootloader ist echt super.
Habe ihn schon bei meheren Geräten eingesetzt.
Jetzt will ich ein Konsolenprogramm für Linux schreiben.
Habe in diesem Thread gelesen das jemand schon mal angefangen hat.
Will das ganze in C schreiben. Vielleicht später auch mal eine einfache 
GTK Gui. Aber Vorrang hat erst mal das Konsolenprogramm.
Könntest du mir dafür die nötigen Infos geben wenn es geht.

MFG Alex

Autor: Hü (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hagen !

Genialer Loader, sehr schnell !

Ich verwende Bascom, kann dort die AVRootloader.exe als
Programmer einbinden. Übergeben wird dann :

AVRootloader.exe -PCOM1 -B115200 -SBOOTLOADER -DD:\Projekte\GPS\gps3dec\ 
-F{FILE} -Aepc

Für {FILE} setzt Bascom dann GPS.hex automatisch ein.

Wenn ich nun auf "Flash" klicke startet der AVRootloader und
löscht den Flash des Atmels. Danach sollte er dann ja den
Flash programmieren, aber das macht er nicht. Ich muss per
Hand auf "Program" klicken, dann flasht er artig den Chip.

Mit der Option -Aepc sollte er aber doch den kompletten Vorgang
automatisch ausführen, oder? Mache ich da was falsch ?

Matthes

Autor: Hü (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS.

- ist eine 1Wire Verbindung
- per Hand funktioniert alles bestens

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
probiere mal -Apc, der Bootloader wird dann so flashen als wäre die 
Checkbox "erase during programming" angehackt. Es kommt letztendlich 
auf's Gleiche raus nur eben mit dem Unterschied das es mit dieser Option 
schneller ist.

Denoch sollte er alle Kommandos auch ausführen wenn sie als Parameter 
angegeben wurden. Entweder mal wieder einen Bug eingebaut oder die 
interne Funktion .DoEraseFlash() gibt einen Fehler zurück. Sobald eine 
der angegebenen Parameter einen Fehler auslösst wird der komplette 
Vorgang der Auswertung der Parameter abgebrochen.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@alex,

hier im Forum anmelden dann kannst du auf einen Link neben meinem Namen 
klicken und mir eine PN schicken. Ich antworte dann auf die EMail und 
schon können wir kommunizieren.

Gruß Hagen

Autor: D. M. (misterdima)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grüß Hagen!

Erst Riesige "Danke Schön" für deinen Bootloader, ist einfach Klasse.

Nun mein Problem:

Ich verknupfe deine DLL V2 mit eigener Anwendung, ich möchte EEPROM 
auslesen mit Function ReadEeprom aus dem AVRootIntf  und dann in einem 
File speichern. Aber BufOut ist immer leer. Was mache ich  falsch?


Hier ist eine Stück vom Code

procedure TForm1.Button8Click(Sender: TObject);
var
  EBuffer: pointer;
  BufOut : array of byte;
begin
  SetLength(BufOut,64);
  EBuffer := Addr(BufOut);
  FNameEEPROM := ExtractFilePath(ParamStr(0)) + 'temp1.eep';
  if FLoader.Mode = moDisconnected then FLoader.DoConnect;
  if FLoader.Command.ReadEeprom(EBuffer, 64) then
    begin
      Hex_File_Write;
    end;
  if FLoader.Mode = moConnected then FLoader.DoDisconnect;
end;

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuche folgendes
procedure TForm1.Button8Click(Sender: TObject);
var
  Buffer: array of Byte;
begin
  with FLoader do
    if DoConnect(True) then
    try
      try
        SetLength(Buffer, 64);
        if Command.ReadEeprom(@Buffer[0], Length(Buffer)) then
        begin
          FNameEEPROM := ExtractFilePath(ParamStr(0)) + 'temp1.eep';
          Hex_File_Write;
        end; 
      except
        on E: Exception do
          ShowMessage(E.Message);
      end;
    finally
      DoDisconnect;
    end;
end;

1.) Codeschutzblöcke mit try finally end
2.) DoConnect(), DoDisconnet() kann rekursiv benutzt werden, wichtig ist 
nur für jedes erfolgreiche DoConnect() muß ein DoDisconnect() 
aufgerufenw werden, ergo Punkt 1.) Schutzblock einrichten
3.) try except Block, du bist der On-Top-Caller und damit der 
On-Top-Fehler/Ausnahmen-Behandler
4.) Niemals Addr() verwenden, obsolete. Wenn dann mußt du bei 
dynamischen Arrays -> das sind Zeiger auf Records die Zeiger auf Daten 
enthalten, das erste Datenelement mit Addr() ermitteln. Also zb. 
Addr(Buffer[0]) kurz geschrieben also @Buffer[0]. Das dynamische Array 
könnte ja auch mehrdimesional sein.
5.) Aktionen, also vorbereitender Programcode immer nur zum Zeitpunkt 
ausführen wenn er nötig ist


Gruß Hagen

Autor: Christian Radermacher (cradi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

ich möchte mich für den Bootloader und die umfangreiche Doku bedanken.
Ich bin recht neu im Thema AVR unterwegs. Gestern habe ich es geschafft, 
den Loader erfolgreich auf einem Mega 8 zu installieren. Ich habe 
Anfangs etwas Probleme gehabt, da ich nicht wusste, dass bei einem MAX 
232 und bei meinem USB Seriell Wandler mit Atiny 2313 (ist auf dem Board 
von Ulrich Radig drauf) das UART Siganl umgekehrt werden muss.
Aber jetzt geht es, somit kann ich nun auch meinen 666p in Angriff 
nehmen.

Also, vielen Dank für Deine Arbeit, und dafür, dass Du dies alles 
öffentlich stelltst.

Gruß
Christian

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, und
.equ  UseUartInvert    = 1      ; invert UART levels (for RS232 drivers such as MAX232)

so steht's im AVRootloader.asm ;)

Was ist 666p ?

Gruß Hagen

Autor: Christian Radermacher (cradi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

ja, ich habe den Kommentar dann auch gesehen. Ist also wirklich sehr gut 
dokumentiert, nur lesen muss man(n) alles :-))

Beim 666p habe ich  mich vertippt muss nachtürlich ein 644p sein.

Gruß
Christian

Autor: D. M. (misterdima)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grüß Hagen!

Danke für schnelle Antwort und deine Tips, den Code habe ich 
Ausprobiert, genau das, was ich brauchte.

Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,
tolles Projekt, tausend Dank für Deine Arbeit!!!

Ich würde gerne in Delphi eine kleine App zu Deiner DLL schreiben, mit 
der ich dass EEProm modifizieren kann (lesen/schreiben), aber leider 
krieg ich keinen connect.

Wenn ich bei GetAppCmdResponse '' zurückgebe, geht die Anwenndung baden 
und meldet irgendwann zuviel Exeptions "Integer divide by zero 
at0x0037c8e2". Wenn ich ' ' zurückgebe geht das zwar gut aber Connect 
hab ich trotzdem nicht.

Ich bräuchte das Verhalten der AVRootloder.exe, die ja auf Reset meines 
ATTiny wartet.

Wäre toll, wenns einen Tip gäbe.

Autor: A. M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigt....
Ich mach halt mein eigenes Interface über RS232.

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

herzlichen Dank für dein tolles Projekt, leider habe ich nich gewisse 
Startschwierigkeiten...

Es tut mir leid dich trotz der umfangreichen Doku damit zu behelligen.

Folgender Aufbau:
Ein Atmega644 mit max232 an D0 un D1 angeschlossen.

.include "m644Pdef.inc"
.equ  UseWDR      = 1
.equ  UseAutobaud    = 1
.equ  UseVerify    = 1
.equ  UseE2Write    = 1
.equ  UseE2Read    = 1
.equ  UseSRAM      = 0
.equ  UseCrypt    = 1
.equ  UseCryptFLASH           = 1
.equ  UseCryptE2    = 1
.equ  UartInvert    = 1

.equ  RX_PORT      = PORTD
.equ  RX      = PD0
.equ  TX_PORT      = PORTD
.equ  TX      = PD1

.set  XTAL      = 8000000
.set  BootDelay    = XTAL/4

BootCodeSize habe ich gesetzt.
Compilieren und flashen hat ohne Probleme geklappt.

Fuses:
SPIEN gesetzt
BootFlash size=512 words Boot start address=$7E00
BOOTRST gesetzt
sonst alles aus.

Leider meldet mir AVRootloader immer "Error: no Device found".
Angeschlossen ist das ganze an einen Com am Mainboard.
Die Taktquelle ist der interne 8MHz Oszillator. Kann der zu ungenau 
sein?
Ich kann übrigens mit HTerm Daten vom Controller empfangen.

Hat vielleicht jemand eine Idee was das Problem verursacht?

Vielen Dank,
Manuel

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. BootCodeSize auf 0 setzen
2. neu kompilieren
3. BootCodeSize auf Wert aus AVRStudio setzen
4. neu kompilieren
5. schaue im Messsagewindow von AVRStudio nach welche Boot Fuses du 
setzen sollst
6. flashen
7. Fuses setzen

Takt kann nicht das Problem aus Sicht des Bootlloaders sein da du die 
AutoBaud benutzt, das sollte ausreichend kurzzeit stabil sein.

- neuste Version ?
- AVRootloader.INI alles richtig ?

Gruß Hagen

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
danke fuer die schnelle Antwort.

1-4 habe ich gemacht,
5: Please program Boot Fuse to First Boot Start !
Welche ist das? Die einzige die mir AVRStudio in diese Richtung anbietet 
ist BOOTRST, welche auch gesetzt ist.

Version sollte passen, 6.0; habe das letztmoegliche hier aus dem thread 
gezogen.

In der ini habe ich testweise
ConnectTrials=30
Connect=100
gesetzt; Sonst unveraendert gelassen.

Vor dem Compilieren habe ich noch make password ausgefuehrt und 
gespeichert.


Gruss Manuel

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt first, second, third und fourth Bootstart ;)
in AVRStudio gibt es eine DropDown Auswahl mit, na rate mal, vier 
Einträgen.
Wenn also zb. second Bootstart gemeint ist dann stellt man in dieser 
DropDown Liste den 2. Eintrag ein.

Ansonsten sieht alles richtig aus nach deinen Beschreibungen.

- COM Port in Windows Anwendung richtig ?
- das BootSign richtig eingestellt ?
- hast du mal die Debug Option probiert und dir dann das Protokoll 
angeschaut ?

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "Error: no Device found"

Diese Meldung kann eigentlich nur kommen wenn der COM Port auf AUTO 
steht. Setze den COM Port auf den an dem der AVR dran ist und probier 
dann einfach den Connect Button. Die Software verbleibt dann so lange im 
Connect bis du es manuell abbrichst.

Gruß hagen

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, mit den ComPort Einstellungen habe ich schon gespielt, leider ohne 
Erfolg.
BOOT-Sign habe ich gelassen wie es war (BOOTLOADER).
Das Message Fenster bleibt stumm, auch bei Debug=1 in [System].
Kann es sein, dass es an meinem Port am PC liegt?
Mir ist frueher schon aufgefallen, dass HTerm empfangene Zeichen nur 
blockweise anzeigt, da scheint irgendein Puffer im Spiel zu sein. 
Vielleicht ist das sendeseitig genauso?
Waere super wenn das doch noch laufen wurde.

Viele Gruesse und schoenes Wochenende,

Manuel

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Debug=1 ist veraltet. Probiere [Timeouts] Options=1.
Du müsstest dann im Protokoll Fenster wesentlich mehr Infos sehen. Poste 
diese hier.

Gruß Hagen

Autor: Christopher B. (chrimbo) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe ein Problem.
Ich habe den Bootloader auf einen Atmega8 aufgespielt (ja ich habe das 
richtige Include ausgewählt). Nach viel Probieren bin ich nun soweit, 
dass ich über die Software Connecten kann. Jedoch heißt es bei Device 
name, es sei ein ATtiny87.
Ich habe dann versucht, aus dem Tut das erste Beispiel aufzuspielen.
Aber das Programm (AVRootloader 6.0) sagt, es fehlt ein RJMP to MAIN 
oder sowas.

Gerade ist ein neues Problem aufgetaucht.
Er braucht nun sehr lange um zu connecten, und wenn es klappt, dann nur 
sehr kurz.
40 Seiten lang  27.11.09-20:55:53-642 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
dann
27.11.09-20:55:53-642 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:55:53-730 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:55:53-819 > received data   $93 07 06 08 30
27.11.09-20:55:53-828 > Timer created
27.11.09-20:55:53-833 > Device connected
27.11.09-20:55:54-084 > send keepalive
27.11.09-20:55:54-338 > send keepalive
27.11.09-20:55:54-598 > send keepalive
27.11.09-20:55:54-864 > send keepalive
27.11.09-20:55:55-114 > send keepalive
27.11.09-20:55:55-378 > send keepalive
27.11.09-20:55:55-644 > send keepalive
27.11.09-20:55:55-902 > send keepalive
27.11.09-20:55:56-158 > send keepalive
27.11.09-20:55:56-424 > send keepalive
27.11.09-20:55:56-679 > send keepalive
27.11.09-20:55:56-938 > send keepalive
27.11.09-20:55:57-203 > send keepalive
27.11.09-20:55:57-453 > send keepalive
27.11.09-20:55:57-718 > send keepalive
27.11.09-20:55:57-722 > Timer released
27.11.09-20:55:57-725 > keepalive failed, terminate connection
27.11.09-20:55:57-772 > Device disconnected

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier die Ausgabe:
Das Teil sendet sporadisch irgendwelchen Mist zurueck.

27.11.09-20:57:27-453 > Connecting on port COM1...
27.11.09-20:57:27-453 > Timeout.Connect       = 100 ms
27.11.09-20:57:27-453 > Timeout.Base          = 50 ms
27.11.09-20:57:27-453 > Timeout.Erase         = 10 ms
27.11.09-20:57:27-453 > Timeout.Flash         = 15 ms
27.11.09-20:57:27-453 > Timeout.Eeprom        = 10 ms
27.11.09-20:57:27-453 > Timeout.Buffer        = 1 ms
27.11.09-20:57:27-453 > Timeout.AppCmd        = 0 ms
27.11.09-20:57:27-453 > Timeout.KeepAlive     = 250 ms
27.11.09-20:57:27-453 > Timeout.RTSPulse      = 0
27.11.09-20:57:27-453 > Timeout.RTSInterval   = 0
27.11.09-20:57:27-453 > Timeout.ConnectTrials = -1
27.11.09-20:57:27-453 > Timeout.MaxPacketSize = 0
27.11.09-20:57:27-453 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52

.
.
.

27.11.09-20:57:42-765 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:57:42-937 > received data   $96 09 06 04 37 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2
27.11.09-20:57:42-937 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:57:43-125 > received data   $C2
27.11.09-20:57:43-125 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52

.
.
.

27.11.09-20:57:44-171 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:57:44-343 > received data   $96 09 06 04 37 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2
27.11.09-20:57:44-343 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:57:44-531 > received data   $C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2
27.11.09-20:57:44-531 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:57:44-703 > received data   $C2 C2
27.11.09-20:57:44-703 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:57:44-875 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52

.
.
.


27.11.09-20:57:49-109 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:57:49-281 > received data   $96 09 06 04 37 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2 C2
27.11.09-20:57:49-281 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:57:49-468 > received data   $C2 C2
27.11.09-20:57:49-468 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52

.
.
.

27.11.09-20:57:51-046 > send ident      $00 00 00 00 00 00 00 00 00 0D 42 4F 4F 54 4C 4F 41 44 45 52
27.11.09-20:57:51-171 > aborted by User

Autor: Christopher B. (chrimbo) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

hab mein Problem gelöst. Es lag an einer leeren 9V Batterie.
Das Programm ist echt super, großes Lob an dich.

gruß
Christopher

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Manuel:

der Bootloader scheint zu verbinden sendet dann aber permanent den Feler 
$C2 zurück was heist CRC Fehler. Es sieht so aus als ob deine Hardware 
Kommuniaktion unsauber ist. Auf alle Fälle empfängt der AVR permanent 
irgendwelche Zeichen.

Antworten tut er auf alle Fälle korrekt, das kannst du an $96 09 06 04 
37.. erkennen.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
$9609 -> ATmega644
$06 -> Bootloader Version 6
$04 -> 4 FLASH Pages für Bootloader = BZ1 gesetzt
$37 -> $30 für alles Ok, $07 -> UseCrypt = 1, UseCryptFLASH = 1, 
UseCryptE2 = 1, UseVersioning = 0

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hast du bei AVRootloader.ini [Timeouts] -> Options stehen ?

Autor: Christian Radermacher (cradi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe noch ein Problem mit dem Bootloader. Ich denke ich stelle mich 
nur dämlich an, aber ich finde es nicht raus.

Ich kann den Mega8 nur einmal über den Bootloader flashen. Danach 
springt er den Loader nicht an.

Er müsste doch, wenn die SW sendet bei einem Reset den Bootloader 
anspringen, oder?

Meines Fuses füge ich mal bei.
Der Mega8 läuft mit Quarz 12MHz. Es lauft dort ein Programm, welches 
Daten ADC Daten auf der seriellen Schnittstelle ausgibt. Die kommen auch 
am PC an.

Als Interface kommt ein FTD232 RL zum Einsatz, angeschlossen über 
Rxd/Txd.

Der erste Flash funktioniert über diese Verbindung.

Im Protokoll des AVRootloader.exe sehe ich, dass Daten gesendet werde, 
und das der AVR auch etwas sendet. Aber dies sind die Daten, die er auf 
der seriellen ausgibt.

Der Reset liegt auf einem Taster mit PullUp Widerstand, und funktioniert 
auch.

Wo ist mein Fehler?

Gruß
Christian

Autor: Sven K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wo ist mein Fehler?

BOOTRST=Häckchen

Gruß Sven

Autor: Christian Radermacher (cradi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sven,

danke für die Rückmeldung.
Leider geht es dann immer noch nicht.
Ein Reset des AVR löst weiterhin kein Connect mit dem AVROotloader aus.

Ich habe mal die Logdatei aus dem AVRootloader beigefügt.

Vielleicht kann damit jemand etwas anfangen.

Gruß
Christian

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian:

kannst du mir sagen was 'Channel 5 value 1023' bedeutet ?
Das ist nämlich das was die PC-Bootloader Software über deinen COM Port 
empfängt.

Also am Bootloader liegt es nicht.

Gruß Hagen

Autor: Christian Radermacher (cradi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

das ist die Ausgabe des laufenden Programms. Es gibt nacheinander den 
ADC Wert der 8 Ports aus.

Aus meiner Sicht bedeutet dies, der Bootloader wird nach dem Reset nicht 
angesprungen. Nur beim ersten mal Flashen wird der Bootloader 
angesprungen.

Wenn ich also jetzt mit meinem Programmiergerät über die IPS 
Schnittstelle das HEX File des Bootloader flashe und im Anschluß über 
den AVRootloader das Programm übertrage geht es. Beim zweiten Versuch 
jedoch schon nicht mehr.

Gruß
Christian

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich kenne nur zwei Probleme die solche Symptome verurschen

1.) BOOTRST nicht gesetzt
2.) nicht an die beschrieben Vorgehensweise beim Kompilieren gehalten.
- BootCodeSize=0 setzen
- neu kompilieren
- aus AVRStudio Message Fenster cseg [used] auslesen
- in BootCodeSize eintragen
- neu kompilieren

Ansonsten kann man keine weiteren Ausagen dazu treffen, wie im Thread 
hier schon mehrmals angesprochen, hast du nicht die nötigen Infos 
geliefert.

Gruß Hagen

Autor: Christian Radermacher (cradi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

ich habe jetzt nochmal ein wenige getestet, und jetzt geht es. Ich weiss 
aber nicht so richtig warum.

Vielen Dank für Eure Unterstützung.

Gruß
Christian

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

habe bei [Timeouts] -> Options=1 stehen.

Heute Nachmittag werde ich das Teil mal an einem anderen Rechner testen.


Vielen Dank.
Manuel

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also jetzt verstehe ich die Welt nicht mehr...

Nach viel rumprobieren schaffe ich es eine Verbindung herzustellen.
Ich benutze einen max232n mit Standardbeschaltung nach Datenblatt (5x 
1muF). Beschaltet ist pin13(max) mit pin3(com) und pin14(max) mit 
pin2(com). Andere Seite: pin11(max) mit pd1 und pin12(max) mit pd0.
Verbinde ich die Pind der Controllerseite habe ich ein schoenes 
Loopback. Funktioniert tadelos.
Versuche ich nun mit AVRootloader zu verbinden klappt das nicht, bis ich 
mindestens einen der Pumpelkos rausziehe, dann verbindet er sich sofort; 
es koennen sogar Programme uebertragen werden. Stecke ich die Elkos 
zurueck, bricht die Verbindung ab.

Was soll das? Ich bin kein voelliger Neuling auf dem Gebiet, habe sowas 
aber noch nie gesehen?

Autor: MSP430 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manuel,

ich hatte schon ein ähnliches Problem mit dem MSP430.

Ich erinnere mich noch dunkel das sich bei der INIT Sequenz über den 
JTAG Programmer der RST Puls mit dem MAX232 gestritten haben. Der eine 
will runter der andere ist per Default auf high, oder umgekehrt...

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das verstehe ich nicht, JTAG habe ich per fuse deaktiviert, ein Wechsel 
auf andere Controllerpins aendert nichts.
Wenn ich den Controller Daten ausgeben lasse ist es uebrigens genauso, 
mit Pumpelkos geht nichts; ziehe ich einen raus kommen sofort die Werte. 
Stecke ich ihn wieder ein klappt die Uebertragung weiterhin, bis zum 
reset des Controllers, dann geht das Spiel von vorne los.
Am Chip liegt es nicht, wurde bereits getauscht.

Das kann doch nicht so schwer sein, als ich den Chip die letzten Male 
verbaut habe hats immer auf Anhieb geklappt. Fallen euch noch 
Fallstricke ein, die ich uebersehen habe?

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einzige Erklärung meinerseits: dein Elko brückt den TX des MAX. Dh. du 
meinst du hast diesen richtig angeschlossen, schließt ihn aber am TX 
Eingang des MAX an und baust so einen schönen Tiefpass für die 
Datenleitung. Zumindest würde das das beschriebene Verhalten erklären.

Gruß Hagen

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wäre schön, dann würde ich die Sache verstehen...

Es ist egal welchen Pufferelko ich rausziehe (können auch beide sein). 
An den Vout kann ich nachvollziehen, dass die Ladungspumpen arbeiten.
Wie gesagt, Loopback funktioniert mit Elkos, Übertragung zum AVR aber 
nur ohne Elkos.
Geisterhaft...

Autor: Robert Zimmermann (robertz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen.

Hagen Re schrieb:

> Ich benutz eigentlich zwei Arten um aus der Anwendung in den Bootloader
> zu springen. Das ist sehr hilfreich beim Automatischen Programmieren des
> AVRs. Bei den ATtinys überwache ich per PinChange ISR den RX Pin und
> nutz eine ISR wie nachfolgende
>
>
> // Pinchange ISR für PB6, bei LowLevel springen wir den Bootloader an
> __attribute__ ((naked)) ISR(PCINT_vect) {
> 
>     if (PINB & (1 << PB6)) {
>         asm volatile("reti");
>     } else {
>         asm volatile("rjmp  __vectors");
>     }
> }
> 
> int main(void) {
> 
>     MCUSR  = 0;
>     WDTCR  = (1 << WDE) | (1 << WDCE);
>     WDTCR  = 0;
> // RX Pin auf Eingang mit Pullup
>     DDRB  = 0;
>     PORTB = (1 << PB6)
> // PinChange on PB6, Bootloader Pin
>     GIMSK  = (1 << PCIE1);
>     PCMSK1 = (1 << PCINT14);
>     sei();
> 
> .. blabla
>     while (1) {
>     }
> }
> 
>
> Das hat den Vorteil das man die laufende Anwendung durch die PC-Software
> automatisch in den Bootlaoder kommt. Da es ohne Watchdog per direktem
> RJMP geht kann man über den SRAM Befehl der PC-Software den aktuellen
> Inhalt des SRAMs und IO/PORT Bereiches auslesen und analysieren.
>


Leider kann ich kein Assembler, würde aber gerne grob verstehen, was du 
damit meinst. Wenn ich einen Attiny ohne Hardware UART habe, stehen mir 
doch auch keine UART Interrupts zur verfügung. Was bedeutet in diesem 
Fall "PinChange"?
Bascom könnte ich verstehen. Da funktioniert der Befehl ISCHARWAITING() 
z.B. nicht beim Attiny mit Software UART. Ich kann nur mit Inkey() das 
momentan empfangene Zeichen lesen oder mit waitkey() solange das 
Programm anhalten, bis ein Zeichen empfangen wird und dieses einlesen. 
(Soweit ich das verstaden habe)

Bei "meiner" Watchdog Lösung gibts das Problem, dass die Verbindung 
häufig erst nach einigen Sekunden hergestellt wird, oder auch mal gar 
nicht. Vermutlich weil die restlichen 4 Pins permanent damit beschäftigt 
sind, einen Schrittmotortreiber zu füttern und ADC Signale zu empfangen. 
Dann reagiert die Serielle Schnittstelle gar nicht.
Vielleicht käme ich mit der Alternative zum Watchdog weiter.

Viele Grüße
Robertz

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PinChange = Pin Change Interrupt so wie im Datenblatt beschrieben. Man 
wartet also auf verändeerungen an einem Pin, hier also der RX Pin des 
Bootloaders und ruft den Bootloader aus der Anwendung auf. Wenn du in 
deiner Anwendung mit IRQs arbeitest hat dies den Vorteil das deine 
beschtriebenen Wartezeiten wegfallen. Ich vermute mal du benutzt in 
deienr App eherr das Polling.
Der Watchdog wird dann benutzt um einen echten RESET des AVRs zu 
bewerkstelligen und damit den Bootloader definiert zu starten. Das ist 
besser als ein direkter Sprung zum Bootloader aus der Applikation.

Also:

1.) schreibe eine ISR für den Pin Change IRQ
2.) in dieser ISR prüfst du den RX Pin auf Veränderung und aktivierst 
den WDT mit anschließdender Endlosschleife. Somit schlägt der WDT zu und 
reset den AVR.
3.) in deiner Main aktiviere den Pin Change IRQ und setze die Pin-Maske 
für den PinChange IRQ korrekt. Also auf welchen Pin die PinChange ISR 
reagieren soll.
4.) in deiner Main aktiviere die Interrupts mit SEI().

Das von dir zitierte Beispiel arbeitet zwar mit dem PinChange aber nicht 
mit dem Watchdog sondern direktem Sprung zum Bootloader.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls du eher der HW-Typ bist und die SW nicht gebacken bekommst kannst 
du auch per HW einen RESET auslösen lassen. Die PC-Software unterstützt 
die Konfiguiration des DTR/DSR Pin der RS232. Diesen Pin kannst du an 
den RESET des AVRs legen. Jedesmal wenn nun die PC-Software einen 
Connect versucht pulst sie die DTR/DSR Leitung der RS232 und somit den 
RESET Pin des AVRs.

Wie es konkret geht steht hier im Thread, Readme's und AVRootloader.ini 
beschrieben.

Gruß Hagen

Autor: Nora L. (nudl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich arbeite mit dem AT90USB1287 auf einem AT90USBKey Board und wollte 
gerne Deinen Bootloader ausprobieren. Leider hat das Board aber keine 
RS232-Schnittstelle sondern nur USB (und JTAG).
Das Kompilieren des Bootloaders und das Laden in den Flash hat auch 
geklappt, allerdings erkennt der PC das Device nicht (im Devicemanager). 
Vermutlich liegt das daran, dass eine USB-Kommunikation zwischen 
Bootloader und PC nicht vorgesehen ist sondern nur RS232 oder?
Kann ich den Bootloader trotzdem irgendwie verwenden bzw. gibt es eine 
Version mit USB? Oder sollte es eigentlich funktionieren und ich hab nur 
was falsch gemacht?

Danke für die Hilfe!

Gruß,

Nora

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alle auf RS232 und RS485 basierten Schnittstellen gehen, nicht USB. Das 
müsstest du schon selbst programmieren.
Am besten dürfte es sein wenn du einen beliebigen Pin des AVRs als 
1-Wire-RS232 Bootloader Pin benutzt. Du brauchst dann nur bischen zu 
löten, siehe 1-Wire.png im ZIP und einen USB-Seriell Wandler.

Gruß Hagen

Autor: matthes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen,

ich setze den Rootloader seit einiger Zeit ein.
Läuft soweit prima!

Jedoch habe ich jetzt was ganz merkwürdiges:

2 identische Schaltungen mit Mega8L und Quarz 8Mhz,
3V3 UB und 1 Wire Mode.
Der einzige Unterschied zwischen den Beiden sind die
Prozessoren die aus unterschiedlichen Chargen stammen.
Eine Schaltung kann ich problemlos flashen, bei der
anderen kommt kein Connect zustande.
Flashe ich herkömmlich, also mit normalen Programmer,
läuft die Schaltung einwandfrei.
Fusebits sind natürlich richtig gesetzt, das hex des
Rootloaders ist natürlich immer das gleiche.

Kann mir dabei jemand helfen?

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi matthes,

ich hatte mal das Problem, dass der Quarz nicht recht anschwingen wollte 
und somit der Bootloader nur ab und zu funktionierte. Das Setzen der 
CKOPT-Fuse hat geholfen. Evtl. liegt's auch am Quarz? ;)

Autor: matthes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CKOPT habe ich auch schon probiert.
Auch alle Geschwindigkeiten der Schnittstelle.
Und die Startzeit des Atmel ......

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ändere in AVRootloader.inc
.equ  BaudTolerance  = 3

zb. auf den Wert 5 um. Vielleicht "lindert es die Symptome" ohne die 
Ursache zu kennen.

Gruß Hagen

Autor: Matthes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, danke, werde ich testen.

Gibt es noch eine Möglichkeit dem "Symptom" auf
die Schliche zu kommen?

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du könntest die Prozessoren mal in den Schaltungen tauschen, dann weißt 
du zumindest, ob's der µC ist oder die Schaltung. ;)
Bei SMD natürlich etwas aufwändiger ...

Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal eine Frage: Das Windows Programm zeigt ja eine maximale 
Buffergröße des Bootloaders an. Wie finde ich heraus wie viel SRAM bei 
meiner Booloader-Konstellation für den Buffer übrig bleibt. Deine 
Software meint 472 Byte; ich haben aber keine Idee, wie Du das abfragst 
oder aus den Device-Parametern
berechnest.

Ach ja: BootloaderSize = Flash_PageSize * BootPages;

Stimmt das?

Vielen Dank für eine Erleuchtung!

Achim

Autor: matthes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, BaudTolerance auf 5 bringt auch nix.

Prozessor kann ich nicht über kreuz tauschen, da die
andere Schaltung wasserdicht vergossen ist.

Habe jetzt praktisch jeden Parameter ausprobiert,
egal was ich mache, es klappt nicht. Auch die Quarzfrequenz
stimmt. Ich gehe mal davon aus, das "faststartup" bei den
Fuses richtig ist. Habe da aber auch mehrere Einstellungen
versucht......

Auf allen anderen Schaltungen mit einem Mega8 die ich
auftreiben konnte funktioniert der Bootloader einwandfrei.

Ich mache mir nur Sorgen, wenn ich bei der nächsten Bestellung
nur solche "Ausreißer" bekomme ...........

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da bleibt nur eins übrig:
zukünftig eine 100% - Prüfung vor dem Vergießen. ;)

Autor: matthes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
neee, ich möchte das Problem schon lösen !

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ach ja: BootloaderSize = Flash_PageSize * BootPages;
>Stimmt das?

Ja.

(SRAM Size / FLASH_PageSize -1) * FLASH_PageSize ergibt maximale 
Buffergröße. Somit ist sichergestellt das 1. noch genügend SRAM für den 
Stack vorhanden ist und die 2. 8 bytes Prüfsummenblöcke auch noch 
reinpassen.
Maximal benutzt die Software also (SRAM Size / FLASH_PageSize -1) * 
FLASH_PageSize +8 bytes.

Gruß hagen

Autor: Dennis P. (seedman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,
erstmal vielen Dank für deinen genialen Bootloader.
Ich verwende folge Zusammenstellung:

Atmega8L (TQFP32) 8Mhz (extern)

Kommunikation mit dem PC über ein Bluetooth-Modul BTM-222.

Wird wie ein gewöhnlicher COM-Port behandelt.

Dein Bootloader in der Version 6.0

Mein Ziel: Atmega über Bluetooth flashen OHNE manuellen Reset per Knopf.


Mein Stand: Flashen mit externen Reset funktioniert jetzt einwandfrei 
nach langen Versuchen mit den Timeouts.

Dann habe ich die Watchdog Methode gewählt.

Diese Funktioniert auch soweit gut hatte bei mir bis jetzt aber den 
Nachteil, dass mein Hauptprogramm ungewollt alle 2 Sekunden resettet.

Daraufhin habe ich den Watchdog im Hauptprogramm deaktiviert, dann 
funktionierte aber wie erwartet nicht mehr der Bootloader-Reset über die 
PC Software. Und ein Watchdog-Reset alle 2 Sekunden möchte ich nicht im 
Hauptprogramm verwenden.

Jetzt würde ich gerne die PinChange Funktion nutzen um meinen Atmega8 zu 
resetten.
Weil der BTM-222 hat zwar ein RTS/CTS Pin kann diesen aber nicht nutzen.
Sprich ein Reset über ein RTSPulse kann ich leider auch nicht nutzen.

Muss ich dann nur ein Codeschnipsel in mein Hauptprogramm einfügen um 
ein PinChange zu erreichen?

Das BTM-222 verwendet mit dem Atmega8 ein 2Wire Modus ohne Pegelwandler 
aber mit deiner UARTInvert option.

Verstehe ich es richtig, dass deine PC-Software über AppCMD z.b. den 
Wert 0x55 ans Hauptprogramm schickt und der Atmega dann über PinChange 
resettet.


Sorry,... ich bin noch recht neu in der MCU-Programmierung und weiß 
jetzt nicht welche Lösung ich verwenden soll...


P.S. Dein Test-Sourcecode im Ordner Test lässt sich bei mir im 
AVR-Studio 4.18 mit dem AVR-GCC Compiler nicht compilieren. Da kommt 
immer ein Fehler von der ld.exe

Über eine Hilfe würde ich mich sehr freuen. :-)

Gruß Dennis

Autor: Matthes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Dennis,

wie du weiter oben gelesen hast, habe ich einen Atmel der
nicht so richtig will. Was verwendest du für Timeouts?
Ich habe auch schon mit denen gespielt, evtl. sind diese
aber noch zu eng eingestellt?

Autor: Dennis P. (seedman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Timeouts in der INI nur bei BASE geändert. Auf 100ms.
Das funktioniert sogar über Bluetooth 100% zuverlässig allerdings nur 
per RESET-Taster.

Da ich aber Bluetooth verwende, nervt mich der Reset-Taster.

Ich möchte demnach einen Reset per Software durchführen, bekomme das 
aber nicht gebacken!

Reset via RTS-Signal ist leider auch ausgeschlossen, weil das BTM-222 
unterstützt diese Funktion nicht.

Jetzt bleibt nur noch Watchdog oder ein "Jump to Bootloader" übrig.

Nur mir fehlt ein Lösungsansatz. Das Beispiel im Ordner Test verstehe 
ich nicht so ganz.

Zumal wie ich jetzt herausgefunden habe besitzt der Atmega8 keine 
PinChange Funktion über "PCINT", der 8er hat nur den externen INT0 und 
INT1 Pin.

Gruß
Dennis

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast mehrer Möglichkeiten:

1. Polling des RX Pins des Bootloaders in deiner Anwendung. Falls der RX 
pin toggelt dann über Watchdog Reset den Bootloader starten

2. PinChange oder Ext. Int. am RX Pin benutzen und auf Toggeln der RX 
datenleitung warten.

3. schreibe UART Funktionen für deine Anwendung. In der Empfangsroutine 
wartest du auf eine von dir festlegbaren Command String, zb. sowas wie 
"bootstart". Wenn du den empfängst kannst du einen Response String 
zurück senden, zb. "startboot" und wiederum per Watchdog Timeout einen 
Reset zum Bootloader durchführen. In der AVRootloader.ini setzt du das 
Topic AppCmd=bootstart und AppCmdresponse=startboot. Setze [Timeouts] 
AppCmd=20.

Der PC-Bootloader sendet nun vor jedem Connect Versuch den String 
"bootstart" an deine Anwendung im AVR. Dort reagierst du indem du 
"startboot" sendest und den WDT startest. Die PC Software wartet bis sie 
"startboot" also das AppCmdresponse empfangen hat, fügt ein 20 
Millisekunden Delay ein und macht mit dem normalen Connect zum 
AVRootoader im AVR weiter.
Somit hast du also den Bootloader im AVR softwaremäßig gestartet.

Wenn AppCmdResponse nicht benutzt wird, also leer ist, dann wartet die 
PC Software nicht auf eine Bestätigung Seitens deiner UART Routinen 
sondern macht gleich mit dem AppCmd delay und dem Connect weiter.

Letztere Methode ist mit ihrem Handshaking relativ stabil und sicher hat 
aber den Nachteil das die Baudrate in deinen UART Routinen meistens 
hardcoded ist, dh. die AutoBaud Funktion die im Bootloader drinnen ist 
steht dir nicht zu Verfügung.

Gruß Hagen

Autor: CJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin gerade dabei den AVRootloader auf meinem ATmega8 in Gang zu 
bringen, leider funktioniert es bisher nicht:
Ich habe die AVRootloader.hex laut Anleitung erstellt (AVR-Studio, mit 
"m8def.inc" sowie der richtigen Portbeschreibung für den ATmega8, also 
PD0 und PD1).
Die hex-Datei habe ich mit Ponyprog auf den ATmega8 geladen.
Bei der Fusebits bin ich mir 100%ig sicher:
BOOTSZ1 = 1 (kein Häkchen)
BOOTSZ0 = 0 (Häkchen)
BOOTRST = 0 (Häkchen)
Der Code hat nur 432Bytes (<256Words), also sollten die Fusebits 
eigentlich passen, oder?
Wenn ich nun die Verbindung mit AVRootlaoder aufbauen möchte findet er 
leider keine Device

im Protocol steht:
29.12.09-15:28:04-687 > Connecting on port COM1...
29.12.09-15:28:05-796 > Connecting on port COM41...
29.12.09-15:28:06-875 > Connecting on port COM42...
29.12.09-15:28:15-546 > Error: no Device found

Die Kommunikation über die RS232 funktioniert aber sicher, hab eben grad 
getestet.

Mache ich grundsätzlich irgendwas falsch, oder ist zumindest mein 
vorgehen korrekt? oder hat zufällig einer einen konfigurierten 
Bootloader fürn ATmega8 mit passenden Fusebits herumliegen?

Vielen Dank für Eure Hilfe!

Schöne Grüße
CJ

Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re schrieb:
> (SRAM Size / FLASH_PageSize -1) * FLASH_PageSize ergibt maximale
>
> Buffergröße. Somit ist sichergestellt das 1. noch genügend SRAM für den
>
> Stack vorhanden ist und die 2. 8 bytes Prüfsummenblöcke auch noch
>
> reinpassen.
>
> Maximal benutzt die Software also (SRAM Size / FLASH_PageSize -1) *
>
> FLASH_PageSize +8 bytes.

Vielen Dank Hagen, aber bitte hilf mir doch nochmal:

Bezogen auf meinen ATTiny84 wäre das dann:
(512/64 -1)* 64 =448 Bytes Buffergröße
Mit Deinem Programm bekomme ich aber folgendes:

Connection                     : 1-Wire
Device name                    : ATtiny84
Device signature               : 1E930C
SRAM size                      :    512 Byte
EEPROM size                    :    512 Byte
FLASH size                     :   8192 Byte
FLASH size for application     :   7232 Byte
FLASH pagesize                 :     64 Byte
Bootloader size                :    960 Byte
Buffersize for data            :    472 Byte
SRAM start address             :     96
Bootloader version             :      6
Use bootsection                :     No
Versioning supported           :    Yes
Cryptography supported         :    Yes
FLASH data must be encrypted   :    Yes
EEPROM data must be encrypted  :     No
Bootloader information         :
Application software version   : 3.2.2.0
Application version address    : 0x001C3A

Autor: Hagen Re (hagen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Die PC-Software geht von SRAM_Size - PageSize + 24 aus. Ergibt 512 -64 
+24 = 472 Bytes. Ganz genau genommen geht sie immer davon aus das 
SRAM_Size mod PageSize = 0 ist also immer ohne Rest teilbar. Am 
korrektesten wäre also die Formel (SRAM_Size div PageSize -1) * PageSize 
+ 24.

Das ist der vom Protokoll her gesehen maximale Buffer der benutzt wird. 
Wird Verschlüsselung benutzt so muß man die 512 Bytes erstmal in x 
PageSize Buffer unterteilen. Damit für den Stack noch was übrig bleibt 
ziehen wir erstmal PageSize ab und erhalten so den minimal nutzbaren 
Datenbuffer = 448 Bytes. Das ist die maximal nutzbare Größe für die 
Daten im FLASH/EEPROM. Bei der Entschlüsselung wird im SRAM noch 
zusätzlich 3 XTEA-Buffer a 8 Bytes benötigt. Der erste XTEA Datenblock 
ist intern das Feedback Register, der 2. Datenblock a 8 Bytes ist das 
Ausgaberegister. Der 3. 8 Bytes Buffer liegt dann am Ende des SRAMs und 
enthält den zu entschlüsselnden Prüfsummenblock. Vor diesem liegen nun x 
Pages a PageSize Bytes an FLASH/EEPROM Daten. Somit ergibt sich das wir 
den SRAM erstmal in 64 bytes (Pagesize) Blöcke aufteilen. Somit kommt 
man auf Max. Buffersize = SRAM_Size - Page_Size + 24. Es verbleiben dann 
40 Bytes für den Stack.
Dieser Buffer wird aber nur so groß benötigt wenn mit der 
Verschlüsselung gearbeitet wird, ohne Verschlüsselung fallen die 24 
Bytes weg.
Bei der Verschlüsselung sieht es also so aus: Feedback | Output | 
Datenblock 1 | Datenblock 2 | ... | Datenblock x | Prüfsummenblock.
Alle diese Blöcke sind 8 Bytes groß. Die Anzahl x dieser Datenblöcke ist 
immer x = (SRAM_Size - Page_Size) / 8.
Wird nun entschlüsselt so "wandern" die Bedeutung dieser 8 bytes Blöcke. 
Am Anfang wird das Feedback Register mit den Datenblock 1 XOR verknüpft. 
Dann wird dieser Block mit XTEA halb entschlüsselt und dieses 
Zwischenresultat mit dem Feedback Register erneut xor-verküpft. Nun die 
zweite Hälte der XTEA Entschlüsselung durchgeführt und in den als Output 
markierten Datenblock gespeichert. Aus dem ehemaligen "Output" Block 
wird der nächste "Feedback" Datenblock und aus Datenblock 1 wird der 
neue "Output" Block. Nun beginnt wieder alles von vorne usw. Somit 
stehen die verschlüsselten Datenblöcke am Anfang der Entschlüsselung um 
8 bytes nach hinten versetzt im SRAM und nach der Entschlüsselung sind 
diese Daten um 8 bytes nach vorne kopiert wurden. Damit wird die 
Entschlüsselungsfunktion so wie erforderlich in ihrer Performance 
gesteigert und das gesammte System arbeitet wie ein "sliding Window" 
während der Entschlüsselung über den kompletten Buffer. Das erklärt die 
zusätzlichen 24 Bytes die man benötigt.

Gruß Hagen

Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hage,
super vielen Dank für Deine ausführliche Antwort!!!
Ich verstehe ungefähr 30% davon, den Rest werde ich mir noch erarbeiten.

Ansonsten läuft Dein Bootloader bei mir einfach nur spitzenmäßigg, 
reibungslos, wie es sein soll. Vielen vielen Dank für Deine AArbeit!!!

Gruß Achim

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

kann mir auf die Schnelle jemand verraten wie ich aus der Applikation 
direkt in den Bootloader springen kann?

Bei BootMode = 0 sollte das doch mit einem jmp gehen.

Es geht um einen Atmega644; das Datenblatt sagt, bei FirstBootStart 
beginnt die BootLoader Flash Section bei 0xfe00.

Warum bringt mich
asm volatile("rjmp 0xfe00") dann ins Hauptprogramm?


Vielen Dank.
Manuel

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaue dir mal den \Test\ Ordner im ZIP an. Dort zeige ich wie man mit 
WinAVR GCC in C den Bootloader startet. Entweder per direktem Jump oder 
viel besser mit dem WatchDog. Machst du einen Jump dann musst du 
sicherstellen das du alle HW und Ports usw. manuell so zurücksetzt das 
der AVR so wie nach einem RESET eingestellt ist. Nutzt du dagegen den 
WD-Timeout wird der AVR einen RESET machen und alles ist so wie es der 
Bootloader erwartet.

Gruß Hagen

Autor: Kostadin (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

vielen Dank für dein AVRootloader, ich finde ihm TOP!

Ich habe es geschafft eine Verbindung zwischen dem PC und einem 
AT90USB1287 (AT90usbkey Plattform) zu kriegen. Als Verbidung habe ich 
den 1-Wire verwendet ( aber nicht mit 2,7 kOhm, sondern mit 2 kOhm 
Widerstand, ich hoffe,dass das kein Problem ist ;) ) Das einziges 
Problem ist, dass die Baudrate kann nicht mehr als 28800 eingestellt 
werden, keine Ahnung warum.

Ich habe kleine Anwednung, ein paar LEDs leuchten lassen, geschrieben 
und mittels dein Windows-Programm verschlüsselt und drauf geladen. Es 
ging ohne Probleme!

Das Problem ist, wenn ich eine großere hex-Datei auf dem µC laden will. 
Es funktioniert irgenwie nicht. Ich habe keine Ahnung warum nicht, habe 
alles durchgesucht, nochmal alles gelesen, aber nichts gefunden. Ich 
habe auch mit den Werten für Timeouts gespielt, aber wieder ohne Erfolg!

Vielleicht hättest du eine Idee woran mein Problem liegt? Ich hänge dir 
das Protocol an. In dem kann man sehen, dass ich zuerst eine kleine 
Anwendung erolfreich lade, dann versuche ich eine großere Anwendung( 
60kBytes) zu laden, aber es gibt einen Fehler.

Es ist egal, ob ich die Verschlüsselung benutze oder nicht, in beiden 
Fällen es funktioniert nicht.

Vielen Dank im Voraus! Wenn du andere Infos brauchst, sag einfach 
bescheid.

Gruß Kostadin

Autor: Etumic E. (etumic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe jetzt auch versucht den Bootloader auf meinem Atmega8 zu 
verwenden. Leider bekomme ich keine Verbindung!

Meine Einstellungen:
.include "m8def.inc"

.equ  UseAutobaud    = 0      
.equ  UseResetDelay  = 1  
                  
.equ  RX_PORT      = PORTD  
.equ  RX           = PD0
.equ  TX_PORT      = PORTD  
.equ  TX           = PD1

.set  XTAL         = 12000000  
.set  BootDelay    = XTAL/4  
.set  BootBaudrate = 9600    
.set  BootVersion  = 6      
.set  BootCodeSize = 466  


FuseBits:
BOOTSZ1  = 1
BOOTSZ0  = 0
BOOTTRST = 0

Wenn ich meinen Controller resette (Taste) dann empfange ich eine 0 
(Byte-WERT) mit dem Terminal.
Ist das richtig? Sendet der Bootloader eine 0 beim starten?

Autor: Etumic E. (etumic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigt.
Ich hatte das Invertieren nicht gesetzt.

Ich bin begeistert von dem Bootloader. Mit AppCmd und Watchdog 
automatisch resetten. Funktioniert alles bestens.

TOP Bootloader

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kostadin:

du benutzt 1-WIRE-RS232 ? Laut Protokoll, ja, er bringt aber auch einen 
ICOM-Echo-Fehler was darauf schließen lässt das du eben nicht 1-Wire als 
Hardware benutzt. Bei 1-Wire muss das was die PC-Software an Daten 
sendet auch von der PC-Software wieder empfangen werden, das sogenannte 
Echo der Daten. Das wird durch mein RS232 1-Wire Treiber berücksichtigt. 
Das Echo wird wieder empfangen und mit den vorher gesendeten Daten 
verglichen. Sollten Unterschiede im Echo gefunden werden oder das Echo 
ganz ausbleiben so wird der ICOM-Echo-Error gemeldet.

Ich vermute also: entweder nutzt du keine 1-Wire Hardware und die 
PC-Software detektiert nicht den richtigen Modus, also 1-Wire statt 
2-Wire. Oder du benutzt 1-Wire Hardware und diese ist nicht stabil.

Gruß Hagen

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo euch allen,

ich bin schon seit einiger Zeit auf der Suche nach einem CAN-Bootlader
für den AT90CAN. Leider konnte ich dazu aber kein fertiges Projekt
finden.
Genauere Informationen gibt es unter fogendem Link:

Titel - Beitrag "CAN BUS Bootloader AT90CAN"

Ich hoffe es finden sich einige um dieses Projekt zu realisieren oder
die dabei helfen können.

Grüße martin

Autor: swarner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

ich hab mal versucht, Dich via PM zu kontaktieren, was bisher nicht 
gelang. Wahrscheinlich ist Deine t-offline Addy nicht mehr aktuell.

Auf alle Faelle hab ich nen avrdude Patch, der Flash schreiben und 
verifizieren (implizit und bissl hingedreht auch explizit) kann.

Jetzt steht nur noch EEPROM schreiben (lesen muesste gehen) und 
Encryption an. Und genau bei der Encryption brauch ich Deine Hilfe. Wie 
funktioniert das Verfahren? Ich werde das dann fuer avrdude 
implementieren, damit der bootloader vollstaendig unterstuetzt wird. 
Ziel ist natuerlich die Aufnahme der Unterstuetzung in Mainline, womit 
dann alle wichtigen Systeme abgedeckt sein duerften.

Ich bin unter swarner ät mibtec punkt de zu erreichen.

Gruß,

Sascha

Autor: Arne Helms (piowux)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Swarner,
deine Idee finde ich klasse! Ich habe auch mal ein Programm für den 
Bootloader geschrieben. Wahlweise Kommandozeile oder GUI. Das ganze ist 
in Lazarus geschrieben, sodass es auf vielen Plattformen funktioniert. 
Verschlüsseln kann es nicht. Dafür kann es aber schon verschlüsselte 
Dateien programmieren.
im Beitrag
Beitrag "Re: AVR-Bootloader mit Verschlüsselung"
ist der Quellcode. Ich hoffe er hilft dir weiter. Auf das alles bald im 
AVRDude erscheint, was richtig klasse wäre!

Viele Grüße,
piowux

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sascha: sorry aber zZ. bin ich gebunden mit anderen Projekten. Wenn 
deine Mail sich nur auf ein kleines Problem bezöge hätte ich sichderlich 
just in time auch geantwortet. Da du aber eine ausführliche 
Dokumentation von mir benötigst brauche ich mehr Zeit dazu, und die habe 
ich eben nicht. Ich schaue zu das ich die nächste freie zeit benutzte um 
dir alle infos sauber zusammen zu stellen.

Gruß Hagen

Autor: swarner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen: Danke fuer die Antwort. Solange Deine Mail Adresse richtig war, 
bin ich beruhigt :) Die Encryption eilt nicht, wahrscheinlich ist es 
sogar besser, wenn ich da inkrementell vorgehe. Also mach Dir da keinen 
Stress deswegen - ich bin noch laenger da.

@Arne: Danke fuer Deinen Code. Wenn ich wo Zweifel hab, kann ich jetzt 
nachsehen, wie Du es Dir gedacht hast :) Ich hab z.B. ganz vergessen den 
"RUN" Command zu nutzen ;)

Wegen Deines ATMEGA8-only-Poblems: Du brauchst glaub ich CPU abhaengig 
nur die RAM Puffergroesse. Wenn Du einfach die Pagesize nimmst, die du 
fuer die Bootloadergroesse eh brauchst (erase pages usw.), liegst Du auf 
der sicheren Seite (ok, muesstest Du je CPU die Pagesizes verwalten, 
alternativ nimmst Du die kleinste Pagesize, die vom Bootloader 
unterstuetzt wird, 32 Bytes. Das Flashen wird dadurch wesentlich langer 
dauern, aber immerhin kannst so alles flashen.) Ich musste genau 
deswegen dem dude noch ein sramsize in die Chip Config pflanzen - 
leider.

Gruesse

Sascha

Autor: Etumic E. (etumic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Der Bootloader läuft bei mir super mit Kabel.
Jetzt möchte ich über Bluetooth (BTM-222) flashen.

Leider bekomme keine Verbindung über Bluetooth.
Wie muss ich die Timeouts einstellen?
Base habe ich schon versucht zu erhöhen. 50, 100, 200

Es kann keine Verbindung aufgebaut werden!

Meine Einstellungen:

Connection                     : 2-Wire
Device name                    : ATmega16, ATmega16A
Device signature               : 1E9403
SRAM size                      :   1024 Byte
EEPROM size                    :    512 Byte
FLASH size                     :  16384 Byte
FLASH size for application     :  15360 Byte
FLASH pagesize                 :    128 Byte
Bootloader size                :   1024 Byte
Buffersize for data            :    920 Byte
SRAM start address             :     96
Bootloader version             :      6
Use bootsection                :    Yes
Versioning supported           :    Yes
Cryptography supported         :     No
Application software version   : not defined
Application version address    : 0x003BFC

[Timeouts]
Connect=0
Base=100
Erase=10
Flash=15
Eeprom=10
Buffer=1
AppCmd=0
KeepAlive=250
MaxPacketSize=0
RTSPulse=0
RTSInterval=0
Options=1

Autor: Stefan R. (stefan09)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen !

Ich hab mal zwei kurze Fragen zu UseSpecialWrite.
Da mein ganzes Projekt in ASM ist, hab ich den Aufruf folgendermassen 
programmiert:
ldi r18, low(Puffer)      ;Buffer
ldi r19, high(Puffer)

ldi r20, low(32)          ;size
ldi r21, high(32)

ldi r22, 0x00             ;Adresse die Überschrieben wird (0x0f00)
ldi r23, 0x0f
clr r24
clr r25

RJmp Flashend -5

Ist das so richtig ? (Denn bei mir funktionierts leider nicht)
Bin leider kein C-Profi, deshalb ist das Test-Project für mich nicht 
immer ganz so leicht zu verstehen !


UseSpecialWrite = 1 !
Muß ich sonst noch was einstellen oder ändern ?

Gruß

Stefan

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Ist das so richtig ?

Nein, benutze RCALL statt RJMP da ja die Bootloader Funktionen mit RET 
zum Aufrufer zurückkehren. Es sei denn dein obiger Sourceausschnitt wird 
selber per RCALL aufgerufen und du möchtest das die Bootloader 
Funktionen direkt zu derem Aufrufer zurückkehren sollen.

Desweiteren sollte der Offset -2 statt -5 sein. Im C Source ist dort -5 
weil die FLASH Adressen als Byteaddressen interpretiert werden in ASM 
aber als Wordadressen.

Deine Parameter->Register sind korrekt.

Aktiviere mal UseSpecialRead=1 und UseSpecialMsg=1. Dann schreibe einen 
Aufruf für UseSpecialMsg

RCALL FlashEnd-4

In R25 sollte nach Rückkehr der Funktion die Länge des Boot-Msg-Strings 
drinnen stehen und in r24:r23:r22 der Zeiger auf die FLASH Adresse an 
der die BootInfo steht. Nun kannst du damit die BootInfo aus dem FLASH 
lesen ,wenn die Security-Fuses so gesetzt sind das die App auf den 
Boot-FLASH zugreifen kann. Somit hats du erstmal eine reine ReadOnly 
Funktion und zerschießt dir nicht gleich den FLASH wie bei falschem 
Aufruf von WriteFlash().

Im nächsten Schritt benutze ReadFlash() um Daten aus dem FLASH in einen 
SRAM Buffer zu lesen. Wenn das geht mit WriteFlash() weitermachen und 
mit ReadFlash() verifizieren.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

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

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan:

nochwas:
- alle diese Funktionen benutzen Byteadressen als FLASH-Zeiger
- r25 des 4-Bytes Zeiger auf die zu schreibende FLASH Adresse ist 
normalerweise 0x00 (es gibt ja nicht soviel FLASH in einem AVR). Benutzt 
du in r25 den Wert 0xAC als Magic Code kannst du in den Boot-FLASH 
schreiben, falls du die Securityfuses entsprechend gesetzt hast.
- in ASM ist FlashEnd = FLASH_SIZE_IN_BYTES / 2 -1, sollte also bei dir 
die Word Addresse sein.

Gruß Hagen

Autor: Stefan R. (stefan09)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen !

Vielen Dank für die Hilfe !
Es lag am Rjmp Flashend -5 !
Das sind halt die feinen Unterschiede zwischen C und ASM !

Fals nochmal jemand danach sucht:
Hier der Funktionierende Code für den Aufruf von UseSpecialWrite aus 
Assembler:

ldi r18, low(Puffer)      ;Puffer im SRam
ldi r19, high(Puffer)

ldi r20, low(32)          ;Anzahl der zu schreibenden Bytes
ldi r21, high(32)

ldi r22, Byte1(Adresse*2) ;Adresse im Flash die Überschrieben wird
ldi r23, Byte2(Adresse*2)
ldi r24, Byte3(Adresse*2) ;wird nur bei großen AVR's benötigt, sonst  
ldi r25, Byte4(Adresse*2) ;einfach auf 0x00 setzen

RCall Flashend -2         ;Rücksprung aus Bootloader mittels 'Ret'


Gruß

Stefan

Autor: Etumic E. (etumic)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: Louis (Gast)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: Louis (Gast)
Datum:

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

Autor: Louis (Gast)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: Achim (Gast)
Datum:

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.

Autor: Thilo M. (Gast)
Datum:

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!

;-)

Autor: Achim (Gast)
Datum:

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.

Autor: Tim O. (Gast)
Datum:

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.

Autor: Hagen (Gast)
Datum:

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

Autor: Tim O. (Gast)
Datum:

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

Autor: Tim O. (Gast)
Datum:

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

Autor: Manuel (Gast)
Datum:

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?

Autor: Hagen (Gast)
Datum:

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

Autor: Achim (Gast)
Datum:

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!

Autor: Franz (Gast)
Datum:

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.

Autor: Tim O. (tim_o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Franz.

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

Gruss
Tim

Autor: Andreas B. (Gast)
Datum:

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

Autor: Andreas Baier (ichwillnix)
Datum:

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!

Autor: Achim (Gast)
Datum:

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

Autor: Andreas Baier (ichwillnix)
Datum:

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!

Autor: chris (Gast)
Datum:

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

Autor: Achim (Gast)
Datum:

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

HTH

Autor: chris (Gast)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Achim (Gast)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Achim (Gast)
Datum:

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

Autor: Nicolas (Gast)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: Nicolas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

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

Danke und Viele Grüße

Nicolas

Autor: hige (Gast)
Datum:

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.

Autor: Hagen (Gast)
Datum:

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

Gruß Hagen

Autor: hige (Gast)
Datum:

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.

Autor: hige (Gast)
Datum:

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.

Autor: daniel (Gast)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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 ?

Autor: Charly B. (charly)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Nicht Gast (Gast)
Datum:

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!

Autor: daniel (Gast)
Datum:

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)

Autor: daniel (Gast)
Datum:

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?

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Gruß Hagen

Autor: My D. (mydani)
Datum:
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

Autor: Hagen (Gast)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: My D. (mydani)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: My D. (mydani)
Datum:

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

Autor: Hagen (Gast)
Datum:

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

Autor: Hige (Gast)
Datum:

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

Autor: Charly B. (charly)
Datum:
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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Charly B. (charly)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:
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.

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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

Autor: Achim (Gast)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Achim X. (hallali)
Datum:

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

Gruß
Achim

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:
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.

Autor: Achim X. (hallali)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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.

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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?

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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?

Autor: Favian Dewanta (Firma: vsilicon) (ikhwan_h17f)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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.

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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.

Autor: Hagen Re (hagen)
Datum:

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

Autor: Favian Dewanta (Firma: vsilicon) (ikhwan_h17f)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Favian Dewanta (Firma: vsilicon) (ikhwan_h17f)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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.

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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.

Autor: Hagen Re (hagen)
Datum:

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

Autor: Arne Helms (piowux)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Arne Helms (piowux)
Datum:

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

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
-> Beitrag "Brauche Hilfe beim Bau einer Uhr")

Autor: Hagen Re (hagen)
Datum:

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

Autor: MartinS (Gast)
Datum:

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.

Autor: Hagen Re (hagen)
Datum:

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

Autor: Thomas O. (Gast)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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.

Autor: Arne Helms (piowux)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: MartinS (Gast)
Datum:

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.

Autor: Hagen Re (hagen)
Datum:

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

Autor: Bernd (Gast)
Datum:

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

Autor: David Ferrer (Gast)
Datum:

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

Autor: Hagen Re (hagen)
Datum:
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

Autor: David Ferrer (Gast)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: David Ferrer (Gast)
Datum:

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

Autor: Hagen Re (hagen)
Datum:

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

Autor: Bennj (Gast)
Datum:

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ß

Autor: Arne Helms (piowux)
Datum:

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

Autor: Arne Helms (piowux)
Datum:

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

Autor: GierigeSau (Gast)
Datum:

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

Autor: Alfred (Gast)
Datum:
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

Autor: Alfred (Gast)
Datum:

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

Autor: Josef Bernhardt (Gast)
Datum:
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

Autor: alex (Gast)
Datum:

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

Autor: OlliW (Gast)
Datum:

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

Autor: thorsten (Gast)
Datum:

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

Autor: Christian Besemann (christianbesemann)
Datum:

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

Autor: L. Schreyer (lschreyer)
Datum:

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

Autor: Christian Besemann (christianbesemann)
Datum:

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

Autor: Louis (Gast)
Datum:

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

Autor: Bjoern (Gast)
Datum:
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

Autor: Rene Schmidt (rs-main)
Datum:

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

Autor: Erich Freibert (erichabg)
Datum:

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

Autor: Erich Freibert (erichabg)
Datum:

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

Grüße
  Erich

Autor: Erich Freibert (erichabg)
Datum:

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

Autor: Gopy Nagalingam (gopy29)
Datum:

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

Autor: Gopy Nagalingam (gopy29)
Datum:

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.

Autor: Erich Freibert (erichabg)
Datum:

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

Autor: Wolfgang O. (karlo)
Datum:

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

Autor: Andreas Baier (ichwillnix)
Datum:

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

Autor: Lefebvre (Gast)
Datum:

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