UART Bootloader ATtiny13 - ATmega644

[Peter D. (peda)]

Hier ist nun mein neuer Bootloader V1.4

Die Programmierzeiten sind z.B.:

ATtiny13: 0,8s
ATmega8: 1,8s
ATmega644: 8,2s

Hinzugekommen ist ein CRC-Check und eine Verify-Funktion.

Bei den ATtinys kann man sie deaktivieren, bringt bis zu 64Byte mehr 
Flash für die Applikation.


Peter

[Michael S. (keil)]

Hallo Peter,

eine Frage: Was genau bedeutet die "BufferSize", bzw. was meinst Du mit 
"Attention: BufferSize must fit perfectly into BootStart!"?
Beim ATmega8 z.B. ist BufferSize = 15*PageSize = 15*32 = 480 = 0x1E0 
(warum dieser Wert?).
Beim ATmega168: BufferSize = 4*PageSize = 4*64 = 256 = 0x100
Ich Frage, da ich den Bootloader mit einem ATmega88 verwende, der eine 
PageSize von 32 hat. Ergo müsste ich bei BufferSize "8*PageSize" bei 
Verwendung der BOOTSTART-Adresse 0x0F00 eintragen, oder? Meine 
Feststellung ist nämlich, dass jeder Multiplikator zwischen 2 und 12 
funktioniert (weiter hab ich´s nicht getestet). Ich wäre Dir für eine 
kurze Erklärung sehr dankbar!

ciao Michael

[Peter D. (peda)]

Windows mag es nicht, wenn man immer nur ein Byte über die UART sendet.
Man sollte also möglichst große Blöcke senden, dann geht es wesentlich 
schneller.
Daher richte ich im SRAM einen Puffer ein und sage der PC-Software, wie 
groß dieser Puffer ist.
Diese Puffergröße muß natürlich ein Vielfaches der Pagegröße sein.

Um den Bootloader klein zu halten, programmiert er immer komplette 
Puffer. Daher muß die Puffergröße exakt, d.h. ohne Rest in den 
Userbereich passen.
Oder anders gesagt: n * Puffergröße = Bootstart.


Peter

[Andreas (Gast)]

Hallo Peter,

in dem anderen Thread schreibst Du, "die Programmierpins sind frei
wählbar"...

Kannst Du evtl. für die Noobs (wie ich  ;-)  ) ein paar Zeilen zum 
Einstieg schreiben, welche Pins jetzt benutzt werden, wie und wo man 
diese ändert, wie das Programmieren funktioniert usw. Also eine kurze 
Anleitung?

Wäre echt prima und sicher für viele sehr hilfreich.

Vielen Dank
Andreas

[Michael S. (keil)]

Hallo Andreas,

wie Peter schon schrieb, die Programmierpins sind frei wählbar, da die 
serielle Schnittstelle als Softwarelösung implementiert ist.
Die Konfiguration der beiden Pins kannst Du in dem Deinem 
Mikrocontroller entsprechenden *.asm-File abändern und dann mit z.B. 
AVR-Studio das Hex-File für den Controller erzeugen.
Auf dem Weg nochmal Danke Peter für Deine Antwort. Jetzt habe ich 
verstanden dass Du mit Bootstart die Bootstart-Adresse meinst.

ciao Michael

[Andreas K. (andie)]

Hallo Peter,

super Teil dein Bootloader.
Hab ihn gerade auf ATMega64 und RS-485 Schnittstelle angepasst und er 
läuft!
Jetzt muss ich nur noch das PC-Programm auf Dev-C++ portieren, da ich 
kein Borland C++ habe.

Vielen Dank
andie.

[Peter D. (peda)]

Andreas wrote:

> Kannst Du evtl. für die Noobs (wie ich  ;-)  ) ein paar Zeilen zum
> Einstieg schreiben, welche Pins jetzt benutzt werden, wie und wo man
> diese ändert, wie das Programmieren funktioniert usw. Also eine _kurze_
> Anleitung?


Die Pins können in folgenden Zeilen geändert werden

; Sendepin:
.equ    STX_PORT        = PORTB
.equ    STX_DDR         = DDRB
.equ    STX             = PB1
;Empfangspin:
.equ    SRX_PIN         = PINB
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB0

Peter

[SRX_DDR (Gast)]

SRX_DDR

[Richard (Gast)]

Kann mir einer verraten wie ich den sourcecode kopilieren kann?

Habe es mit AVR Studio versucht ... kriege es aber leider nicht hin :-(

[Richard (Gast)]

Diese Fehlermeldung bekomme ich:

AVRASM: AVR macro assembler 2.1.12 (build 87 Feb 28 2007 07:31:13)
Copyright (C) 1995-2006 ATMEL Corporation

C:\Documents and Settings\Admin\My Documents\AVR 
Projects\fastload_V14\ABAUD.INC(18): error: zl: Unknown instruction or 
macro
C:\Documents and Settings\Admin\My Documents\AVR 
Projects\fastload_V14\ABAUD.INC(18): error: syntax error, unexpected ','

Assembly failed, 2 errors, 0 warnings

[Uwe (Gast)]

Sehe ich das richtig, dass AVRs mit mehr als 64k Flash (z. B. ATm128) 
nicht unterstützt werden?

[Peter D. (peda)]

Richard wrote:
> Kann mir einer verraten wie ich den sourcecode kopilieren kann?
>
> Habe es mit AVR Studio versucht ... kriege es aber leider nicht hin :-(

Du öffnest die Datei, die Du assemblieren willst, z.B. t13.asm.
Die anderen (*.inc, *.h) müssen sich im gleichen Verzeichnis befinden.


Peter

[Peter D. (peda)]

Uwe wrote:
> Sehe ich das richtig, dass AVRs mit mehr als 64k Flash (z. B. ATm128)
> nicht unterstützt werden?

Ja, der ATMega644 ist mein größter, größere habe ich nicht.

Hab ihn aber auch nur aus Interesse gekauft, weiß noch nicht, womit ich 
ihn vollkriegen kann.


Peter

[Uwe (Gast)]

Ist es viel Aufwand, den ATM128 noch mit einzubauen?

[Peter D. (peda)]

Uwe wrote:
> Ist es viel Aufwand, den ATM128 noch mit einzubauen?

Im Prinzip nicht.

Die meisten Änderungen sind am PC Programm.
Ich müßte mir ansehen, wie ein Segmentrecord funktioniert (bisher 
ignoriere ich ihn) und alle Pointer, Adreßzähler auf long umstellen und 
ein farmemset selber schreiben.

Auf dem AVR muß ich RAMPZ mitzählen und ESPM, ELPM benutzen, sollte max 
10 Worte kosten.

Ich kanns aber nicht testen.


Peter

[Der T. (Gast)]

Hallo Peter,

kann man den alten Borland C-Compiler legal irgendwo runterladen?
Oder ist der immer noch kostenpflichtig?

Schöne Grüße,
Techniker

[Richard (Gast)]

Kann mir einer sagen was ich falsch mache?


C:\AVR_programm>FBOOT.EXE /PLED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds

C:\AVR_PR~1>FBOOT.EXE /PC:\AVR_programm\LED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File C:\AVR_programm\LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds

C:\AVR_PR~1>



Die Datein liegen so:

C:\AVR_PR~1>dir
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 1819-D039

 Verzeichnis von C:\AVR_PR~1

15.07.2007  19:08    <DIR>          .
15.07.2007  19:08    <DIR>          ..
07.07.2007  16:20            16.441 FBOOT.EXE
15.07.2007  19:05             1.036 LED_mega32.hex
               2 Datei(en)         17.477 Bytes
               2 Verzeichnis(se), 66.330.902.528 Bytes frei

C:\AVR_PR~1>


Danke

[Simon K. (simon)]

FBOOT.EXE /PC:\AVR_PR~1\LED_mega32.hex

so vielleicht?

[Peter D. (peda)]

Diese DOS-Anwendung kann leider keine langen Pfad- und Dateinamen (max 
8.3).


Peter

[Richard (Gast)]

Geht aber auch nicht :-(

C:\AVR>FBOOT.EXE /PLED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds

C:\AVR>FBOOT.EXE /PC:\AVR\LED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File C:\AVR\LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds

C:\AVR>

[Hauke R. (lafkaschar)]

LED_mega32.hex

der dateiname ist immer noch 10 buchstaben lang ;)

[Simon K. (simon)]

Stimmt!

BOOT.EXE /PLED_me~1.hex

PS: Dann war obige Antwort auch nicht richtig. Da ist nur der Pfadname 
korrekt, der Dateiname aber immernoch zu lang.

[Richard (Gast)]

Asoo, Dateiname ... ich dachte Pfad^^. Danke jetzt geht es.

Hab aber folgendes Problem:

Habe erfolgreich folgendes Programm draufgespielt:

#include <avr/io.h>

// Sollte normalerweise schon im Makefile definiert sein.
// In dem Fall hier einfach löschen.
#define F_CPU 11059200
        
#define BAUD        2400UL
#define UBRR_BAUD   ((F_CPU/(16UL*BAUD))-1)

void ioinit(void);
void delay_ms(unsigned int ms);
void uart_init(void);



// USART initialisieren
void uart_init(void)
{
    // Baudrate einstellen (Normaler Modus)
    UBRRH = (uint8_t) (UBRR_BAUD>>8);
    UBRRL = (uint8_t) (UBRR_BAUD & 0x0ff);

    // Aktivieren von receiver und transmitter
    UCSRB = (1<<RXEN)|(1<<TXEN);

    // Einstellen des Datenformats: 8 Datenbits, 1 Stoppbit
    UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
}



// Hauptprogramm
int main(void) {
    unsigned char i;   

    ioinit();   

    uint8_t buffer;

    // USART initialisieren
  //  uart_init();

   
    // Endlosschleife
    while (1) {
        PORTD ^= (1 << PD7);
       
        // Eine Sekunde warten
        delay_ms(1000);
    }   

    return 0;
}

// Initialisierung
void ioinit(void)
{
    DDRD = 0xff;    // PortB als Ausgang deklarieren
    PORTD = 0x00;   // Ports auf LOW schalten
}

// Warteschleife
void delay_ms(unsigned int ms)
{
    unsigned int zaehler;
   
    while (ms) {
        zaehler = F_CPU / 5000;
       
        while (zaehler) {
            asm volatile("nop");
            zaehler--;
        }
        ms--;
    }
}

Das Programm funktioniert auch ... aber jetzt kann ich kein neues 
Programm brauchspielen .. er kann sich nicht mehr connecten.

Liegt es daran weil ich komplett die Ports D:

    DDRD = 0xff;    // PortB als Ausgang deklarieren
    PORTD = 0x00;   // Ports auf LOW schalten

als ausgang geschaltet habe und meine Pins beim Bootloader sind auch die 
von PortD:

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
.equ    STX_PORT        = PORTD
.equ    STX_DDR         = DDRD
.equ    STX             = PD1

.equ    SRX_PIN         = PIND
.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

[Simon K. (simon)]

Richard wrote:
> Asoo, Dateiname ... ich dachte Pfad^^. Danke jetzt geht es.

Beides.

[Richard (Gast)]

Ich habe ein bisschen rumprobiert ... habe jetzt andere pins benutzt ... 
das komische ist aber .. ich kann nur einfach eine hex draufspielen.

C:\AVR>FBOOT.EXE /PLED.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
Program LED.hex: 0000 - 016B successful
CRC: o.k.
Elapsed time: 0.33 seconds

C:\AVR>FBOOT.EXE /PLED.hex
COM 1 at 115200 Baud: /
Aborted

C:\AVR>FBOOT.EXE /PLED.hex
COM 1 at 115200 Baud: -
Aborted

C:\AVR>FBOOT.EXE /PLED.hex
COM 1 at 115200 Baud: |

Bei allen anderen versuchen geht es nicht, wenn ich schon einmal 
gebrannt habe. ;-(

Muss ich irgendwas an den Security bits umstellen?

[Richard (Gast)]

Der Startet sofort das Programm ... nicht den Bootloader. Wieso? Wie 
muss ich mein Programm ändern ... damit es immer funktioniert?

[Peter D. (peda)]

Richard wrote:

> Muss ich irgendwas an den Security bits umstellen?

Die Fuses: firstboot und boot reset

sonst kann er ja den Bootloader nicht finden.

Bei nem leeren MC rauscht er durch die 0xFFFF durch bis zum Bootloader.


Peter

[Richard (Gast)]

Ahhh danke für die Info.
Welche Bits sind es in PonyProg sprache?

http://mikrocontroller.cco-ev.de/php/counter/counter.php?datei=PonyProgeinstellungen_ISA_Ctrl.jpg&location=http://mikrocontroller.cco-ev.de/files&type=count


Heißt das ich muss bei BootLock01 ein häckchen machen und bei BOOTRST ??

Danke im voraus.

[Gasti (Gast)]

Hallo PeDa,
ist in der Abaud Funktion noch ein Bug enthalten?
Wenn RxD immer High bleibt kommt es nie zum Timeout, da die Prüfung nach 
dem SKIP_RXD_O stattfindet. Bei der TinyLoad 1v3 wurde vorher geprüft.
Vielleicht habe ich aber auf das ganze noch nicht richtig durchschaut.

[Peter D. (peda)]

Gasti wrote:

> Vielleicht habe ich aber auf das ganze noch nicht richtig durchschaut.

Stimmt

Auf das SKIP folgt kein RJMP, d.h. auch bei einem Timeout wird nicht 
mehr zum Schleifenanfang gesprungen.


Peter

[Andreas K. (andie)]

Hat jemand von euch schon das FBoot Programm von Peter auf Dev-C++ 
portiert?

Habe keine inportb() und outportb() Funktionen zur Verfügung.
Würde mich über jede Hilfe freuen.

andie.

[Richard Brose (Gast)]

@Andreas Kasper

Ich bin dabei eine Win32 Anwendung zu machen mit GUI etc.

[Benedikt K. (benedikt)]

Ich hab das ganze gerade auf VC++ umgeschrieben, da ich das ganze an 
einem USB-RS232 Wandler betreibe. Im Prinzip muss man nur noch einige 
casts hinzufügen und die seriellen Schnittstellenroutinen ändern.

Hat jemand eine Idee wie man den Bootloader starten könnte, wenn es 
keinen Reset Knopf gibt, der AVR über USB versorgt wird, und ebenso der 
FT232, der COM-Port also nicht vor dem Einschalten des AVRs geöffnet 
sein kann ?

[Hauke R. (lafkaschar)]

Im controller eine resetfunktion implementieren?
Also, irgend ein zeichen bzw steuercode über rs232 der dann den watchdog 
einschaltet und wartet?

[Peter D. (peda)]

Benedikt K. wrote:

> Hat jemand eine Idee wie man den Bootloader starten könnte, wenn es
> keinen Reset Knopf gibt, der AVR über USB versorgt wird, und ebenso der
> FT232, der COM-Port also nicht vor dem Einschalten des AVRs geöffnet
> sein kann ?

Nimmste eben eins von den Handshakesignalen (RTS, DTR) und knallst es an 
den Resetpin.

Und im PC-Programm wird es dann kurz gepulst.


Peter

[Stefan (Gast)]

Wirklich grossartig...
Ist denn auch eine Halb-Duplex-Kommunikation auf einem Pin 
konfigurierbar ?
Gerade auf den 8-Pin-Prozessoren wäre das ungemein hilfreich... dafür 
würde ich gern auch noch ein wenig Speicher opfern; denn da ist man bei 
den neuen Tinys ja recht flexibel :)

Vielen Dank noch einmal !


Gruß, Stefan


---

[Peter D. (peda)]

Stefan wrote:

> Ist denn auch eine Halb-Duplex-Kommunikation auf einem Pin
> konfigurierbar ?
> Gerade auf den 8-Pin-Prozessoren wäre das ungemein hilfreich... dafür
> würde ich gern auch noch ein wenig Speicher opfern; denn da ist man bei
> den neuen Tinys ja recht flexibel :)

Ist gerade in Arbeit, anbei schonmal der Schaltplan.
Die Dioden sind nur zum Schutz, wer Lust hat, kanns auch ohne probieren.

6 IO-Pins zu haben und trotzdem neu brennen zu können (ohne Fuses !), 
hat schon was.

Es sieht auch ganz gut aus, fehlt noch der Feinschliff.

Die Prolific-Dongle haben das viele RX-Traffic nicht ausgehalten und 
Bytes verschluckt und vertauscht (!), wenn einige Bytes 0x13 waren.
Ich bin fast verrückt geworden beim Debuggen.

Bis ich dann den FTDI benutzt habe, da lief alles.

Dann habe ich den neuen Profilic-Treiber installiert und dann gings 
auch.
Der Treiber muß von 2005 sein (der alte war von 2003).
Allerdings sinkt die Downloadrate auf 25%, wenn die Bytes 0x13 sind.


Für das 1-wire mußte ich auch noch das Protokoll etwas umstellen.
Ich muß mal das 2-wire überprüfen, ob das noch geht.

Die PC-Software erkennt den Modus automatisch und schmeißt dann alle 
Echos weg, so daß nur die echten Antworten übrig bleiben.

Damit die Paßworterkennung funktioniert, sendet der PC noch ein 0xFF 
dahinter und der AVR wartet auf das Starbit und hängt das Antwortbyte 
daran an.
Falls das fehlschlägt, macht es der AVR immer wieder, daher sollte das 
Paßwort eine gerade Anzahl Zeichen haben.

Daß das Zeichen 'a' im Paßwort vorkommen muß, hat vielleicht schon 
jemand gemerkt.
Die Baudratenerkennung akzeptiert nur bestimmte Zeichen, um eine 
Fehlerkennung (doppelte Bitzeit) zu vermeiden.


Peter

[Stefan (Gast)]

Das klingt ja vielversprechend !
Wenn ich das richtig interpretiert habe, läuft die Flußsteuerung dann 
komplett via Software, der entsprechende Port wird also umgeschaltet ..?
Das sollte für den Hausgebrauch auch ausreichend sein; wenn es dann mal 
via RS485, also mit externer Treiberumschaltung sein soll, kann man das 
ja nach Belieben selbst reinfriemeln ;)

Vielen Dank für Deine Anstrengungen...

[Andreas B. (andreasb)]

Ich habe hier ein ATMega 48 und möchte gerne den Bootloader zum laufen 
kriegen, habe daher die Ports und Includes angepasst (ich hoffe mal 
richtig, habe noch nie mit Assembler gearbeitet):

;*************************************************************************
;*                   *
;*        ATmega8 Bootloader       *
;*                                                                       *
;*                      Author: Peter Dannegger                          *
;*                   *
;*************************************************************************
.nolist
.include "m48def.inc"


;please burn this BootStart Fuse:

.equ  BootStart  = SecondBootStart


;Attention: BufferSize must fit perfectly into BootStart !
;e.g. BufferSize * 8 = BootStart

.equ  BufferSize  = (15*PageSize)

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
.equ    STX_PORT        = PORTD
.equ    STX_DDR         = DDRD
.equ    STX             = PD0

.equ    SRX_PIN         = PIND
.equ    SRX_PORT        = PORTD
.equ    SRX             = PD1
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

Und kriege dann beim kompilieren folgende Fehler:

AVRASM: AVR macro assembler 2.1.2 (build 99 Nov  4 2005 09:35:05)
Copyright (C) 1995-2005 ATMEL Corporation

C:\avr\bootloader\bootloader.asm(9): Including file 'C:\Programme\Atmel\AVR Tools\AvrAssembler2\Appnotes\m48def.inc'
C:\avr\bootloader\bootloader.asm(14): warning: Use of undefined or forward referenced symbol 'SecondBootStart' in .equ/.set
C:\avr\bootloader\bootloader.asm(33): Including file 'C:\avr\bootloader\fastload.inc'
C:\avr\bootloader\fastload.inc(9): Including file 'C:\avr\bootloader\compat.h'
C:\avr\bootloader\fastload.inc(10): Including file 'C:\avr\bootloader\fastload.h'
C:\avr\bootloader\fastload.inc(21): error: Overlap in .cseg: addr=0x0 conflicts with 0x0:0x1
C:\avr\bootloader\bootloader.asm(33): info: 'C:\avr\bootloader\fastload.inc' included from here
C:\avr\bootloader\fastload.inc(38): Including file 'C:\avr\bootloader\abaud.inc'
C:\avr\bootloader\fastload.inc(39): Including file 'C:\avr\bootloader\password.inc'
C:\avr\bootloader\fastload.inc(83): Including file 'C:\avr\bootloader\checkcrc.inc'
C:\avr\bootloader\fastload.inc(90): Including file 'C:\avr\bootloader\verify.inc'
C:\avr\bootloader\fastload.inc(101): Including file 'C:\avr\bootloader\message.inc'
C:\avr\bootloader\fastload.inc(104): Including file 'C:\avr\bootloader\progmega.inc'
C:\avr\bootloader\fastload.inc(110): Including file 'C:\avr\bootloader\uartcrc.inc'
C:\avr\bootloader\bootloader.asm(35): warning: end of .dseg at 0x4c0 is beyond end of memory at 0x2ff

Assembly failed, 1 errors, 2 warnings

Und wenn ich sowieso schon schreibe, hat jemand den Bootloader für Linux 
auf den aktuellen Stand gebracht? (war ja im vorhergehenden Thread mal 
dabei).

Danke.

mfg Andreas

[Peter D. (peda)]

Der ATmega48 gehört bezüglich Bootfunktion zu den ATtinys.

Daher gibts kein Secondbootstart.

Nimm daher das T45.ASM als Vorlage.


Peter

[Andreas B. (andreasb)]

Ok, Danke!
Der Bootloader ist drauf, nur wartet der unendlich lange?
Ich konnte mein Programm aufspielen, aber es wurde nicht gestartet. 
Selbst wenn ich über eine Minute warte kann ich immer noch das Flash 
bespielen. Wie muss ich mein Programm starten, bzw. wenn wird es 
gestartet? (da ich den vorherigen Thread auch gelesen habe gehe ich mal 
davon aus das dein Bootloader auf 0x00 eine rjmp zur Adresse in der der 
Bootloader ist geschrieben hat, und dann von dort auf zurück auf 0x01 
springt wo das Programm beginnt, oder so ähnlich?)


Wie schon genannt, ATMega 8, und ich kann immer noch kein Assembler;-)

mfg Andreas

[Peter D. (peda)]

Die Applikation startet, sobald das PC-Programm fertig ist bzw. etwa 
0,3s nach einem Reset.

Bei den AVRs ohne Bootstartfuses muß der erste Befehl ein RJMP sein, 
sonst geht es nicht.

Und die Applikation muß lauffähig sein, d.h. eine Mainloop haben.


Peter

[Andreas B. (andreasb)]

Die Applikation hat eine Hauptschleife, es ist in C geschrieben, wie 
muss ich das realisieren?
Es ist so das mein Programm definitiv nicht startet, weder nach einem 
Reset noch nach dem Flashen.


mfg Andreas

[Peter D. (peda)]

Andreas B. wrote:

> Es ist so das mein Programm definitiv nicht startet, weder nach einem
> Reset noch nach dem Flashen.

Verify und CRC sind o.k. ?


Wenn Du überzeugt bist, daß Dein Programm funktioniert, dann lade es mal 
direkt, ohne Bootloader.


Peter

[Andreas B. (andreasb)]

Ohne Bootloader läuft es, und CRC habe ich nicht drauf, zumindest wird 
ausgegeben das CRC nicht implementiert ist.
Auch wenn ich .crc = 17 auskommentiere erscheint dies.
Ich benutze den Internen Oszi, habe Datenübertragung mit 9600 Baud 
klappt bei meinem Programm, ich habe beim Flashen auch 9600 Baud 
angegeben (wobei das wahrscheinlich eh nichts bringt da du sowieso das 
ganze per Software machst).

Ist es möglich das ich den Bootloader falsch geflasht habe, also das der 
auf 0x00 steht und mein Programm hintendran oder so?
Ich habe einfach das .hex File mit AVR Studio aufgespielt.


mfg Andreas

[Andreas B. (andreasb)]

Ich muss natürlich nicht CRC auskommentiern sonder VERIFY 
einkommentieren.
Und dann erscheint auch "fail" warum weiss ich noch nicht...
Aber demfall wurde mein Programm nicht augespielt, oder zumindest nicht 
richtig aufgespielt...

Danke für die Antworten und ich hoffe mal ich kriege das noch selbst 
raus, oder du hast nochmals einen Vorschlag...

mfg Andreas

[Peter D. (peda)]

Schau mal bei den Fuses nach, der ATmega48 hat noch ne 
Self-Programming-Enable Fuse, die muß man setzen.


Peter

[Andreas B. (andreasb)]

Danke!
Das wars!


mfg Andreas

[Andreas B. (andreasb)]

So, hier mein Linuxport des Bootloader Programmers. (Basiert auf dem 
Original und dem Port von Sascha Biedermann vom vorherigen Thread)

Leider nicht ganz so schnell wie das original, und mit ein paar 
unschönen Hacks drin...:

/dev/ttyS0 at 115200 Baud: /
Connected
Bootloader V1.4
Target: 1E9205 ATmega48
Buffer: 64 Byte
Size available: 3582 Byte
reading file... Done.
Program project.hex: 0000 - 0D25 successful
CRC: o.k.
Elapsed time: 28 seconds
andreas@andreas:~/avr/bootloader_linux$ ./main /Vproject.hex
/dev/ttyS0 at 115200 Baud: \
Connected
Bootloader V1.4
Target: 1E9205 ATmega48
Buffer: 64 Byte
Size available: 3582 Byte
reading file... Done.
Verify project.hex: 0000 - 0D25 successful
CRC: o.k.
Elapsed time: 41 seconds

Trotzdem möglicherweise nützlich für Linuxuser ;-)

mfg Andreas

[Andreas B. (andreasb)]

Hier eine neue Linuxversion, nun klappt das Programmieren innert 
Sekunden (bei meinem ATMega48 sinds sogar nur 0.44 Sekunden) und einige 
Bugs behoben.

Und noch eine Frage, kann der Bootloader aus C gestartet werden?
Ich habes versucht mit

cli();
asm volatile ("rjmp 0");

das klappt aber nicht, da hängt sich alles auf.

ps. ich habe versucht einen Pin mit dem Resetpin zu verkabeln, da hängt 
sich aber alles auf wenn ich den auf LOW setzte, irgendwie funktioniert 
das nicht... bzw. ich mache was falsch.

mfg Andreas

[Werner B. (Gast)]

Du musst natürlich an den Anfang des Bootloader springen, nicht nach 
Null.

[Werner B. (Gast)]

> ich habe versucht einen Pin mit dem Resetpin zu verkabeln, da hängt
sich aber alles auf wenn ich den auf LOW setzte

Mach das am besten über den Watchdog.

Pseudocode

cli();
WdtEnable(WDT_1MS);
while(!0) {}

[Andreas B. (andreasb)]

Werner B. wrote:
> Du musst natürlich an den Anfang des Bootloader springen, nicht nach
> Null.

Das stimmt, aber ich weiss nicht wo der Bootloader beginnt, und ich habe 
gelesen das der an erster Addresse ein Jump zum Bootloader drin ist.

Ich versuchs mal noch mit dem Watchdog.


mfg Andreas

[Andreas B. (andreasb)]

Ich bin mir nicht sicher ob ich ein Problem mit dem Bootloader oder 
sonst etwas habe, hier mal die Beschreibung:
Ich mache einen Reset per Watchdog:

void reset(void)
{
  uint8_t i;
  
  uart_puts("reset\r\n");
  
  for(i = 30; i > 0; i--) {
    uart_puti(i);
    uart_puts("\r\n");
    _sleep();
  }
  
  
  //Interrups deaktivieren
  cli();

  //Watchdog einschalten
  WDTCSR = (1 << WDE);  
  for(i = 0;1; i++) {
    uart_puti(i);
    uart_puts("\r\nw");
  }
  
}

Aufem Treminal kriege ich:

...
2
1
0
w1
w2
w3

Daher kann ich davon ausgehen das er einen Reset macht. Aber danach wird 
mein Programm nicht mehr gestartet. Wenn ich versuche ein Programm 
aufzuspielen erscheint gerade noch (ich beende natürlich das Terminal, 
sonst würde es ja meine serielle Schnittstelle blockieren)

/dev/ttyS0 at 115200 Baud: -
Connected

da das Laden des Bootloaders sonst klappt gehe ich davon aus das 
irgendetwas nicht richtig initialisiert wird beim Reset mit Watchdog, 
oder was könnte es sonst sein? Hat noch keiner den Bootloader per C 
gestartet?


mfg Andreas

[Tobias W. (Gast)]

Hallo,
bei mir zeigt der Linux-Client seltsame Buffergrößen an...
hängt das mit den Compilerwarnings zusammen?
Ansonsten danke an Peter für den tollen Bootloader und an Andreas für 
den Linux-Client.
Grüsse Tobias

vm-debian-testing:~/tmp# make
gcc -Wall -g -c main.c -o main.o
main.c: In function 'readhex':
main.c:327: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
main.c:330: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
main.c:333: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
main.c:339: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness
gcc -Wall -g -c readargs.c -o readargs.o
readargs.c: In function 'readargs':
readargs.c:46: warning: conversion lacks type at end of format
readargs.c:46: warning: too many arguments for format
gcc -Wall -g main.o readargs.o -o main
vm-debian-testing:~/tmp# ./main
/dev/ttyS0 at 115200 Baud: \
Connected
Bootloader V1.4
Target: 1E9307 ATmega8
Buffer: -2 Byte
Size available: -2 Byte
CRC: o.k.
Elapsed time: 0.03 seconds
vm-debian-testing:~/tmp#

[Andreas B. (andreasb)]

Die Warnungen kannst du ignorieren, diese sind unwichtig, jedoch das 
Problem mit der Grösse hatte ich auch, ich habe darum etwas einfach so 
"gebastelt" das es bei mir funktioniert, warum das es bei dir nicht 
funktioniert kann ich so nicht sagen, was hast du für ein Controller? 
(Vor allem wie viel Speicher hast du)

Ich habe hier mal eine "Debugversion" angehängt, diese schreibt die 
entscheidenden Zahlen auf die Konsole, einfach die Ausgabe kopieren, ich 
hoffe ich kann damit zumindest feststellen was schief läuft.

Ich habs bis jetzt nur mit einem Mega48 probiert, und einfach alles so 
angepasst das es damit funktioniert, was mir nicht klar war warum das 
ich einmal falsche Zahlen empfangen habe (mir wird die Länge der Zahl 
übertragen, in Byte, die war jedoch bei zwei Werten immer um eins zu 
hoch).

mfg Andreas

[Tobias W. (Gast)]

Hallo,
danke für Die schnelle Antwort, ich hab nen Atmega8. Und hier die 
Debug-Daten.
Grüsse Tobias

vm-debian-testing:~/tmp2/debug# ./main
/dev/ttyS0 at 115200 Baud: |
Connected
->--------------
->168
->3
->1
->4
->170
Bootloader V1.4
->--------------
->168
->4
->30
->147
->7
->170
Target: 1E9307 ATmega8
->--------------
->168
->3
->3
->192
Buffer: -2 Byte
->--------------
->170
->168
->4
->30
->170
->-1
Size available: -2 Byte
CRC: o.k.
Elapsed time: 0.00 seconds
vm-debian-testing:~/tmp2/debug#

Das sagt Peters Programm:

E:\avr\fastboot1.4>fboot
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9307 ATmega8
Buffer: 960 Byte
Size available: 7680 Byte
CRC: o.k.
Elapsed time: 0.11 seconds

E:\avr\FASTBO~1.4>

[Andreas B. (andreasb)]

Versuch mal diese Version. Bei ich musste ein paar Änderungen machen, 
damit der Bootloader Programmer bei mir lief, ich denke aber für den 
ATMega 8 scheinen diese nicht nötig zu sein (der ATMega 48 war ja auch 
nicht in der Liste, darum hats wahrscheinlich auch nicht funktioniert.)

Ich warte auf dein Ergebnis und werde hoffentlich dann eine Finale 
Version machen können die mit allen Controllern funktioniert...

mfg Andreas

[Tobias W. (Gast)]

fast...

vm-debian-testing:~/tmp3# ./main
/dev/ttyS0 at 115200 Baud: \
Connected
Bootloader V1.4
Target: 1E9307 ATmega8
Buffer: 960 Byte
Size available: -2 Byte
CRC: o.k.
Elapsed time: 0.01 seconds
vm-debian-testing:~/tmp3#

[Andreas B. (andreasb)]

Irgendwo ist beim portieren ein Fehler passiert, denn das ist 1:1 die 
Funktion die auch in der Windowsversion eingesetzt wird. Ich werde das 
ganze morgen nochmals vergleichen, und vielleicht komme ich auf einen 
Fehler.

Ich kann dir auf jeden Fall mal sagen wo das es schief läuft (in der 
Hoffnung ein mitdenkender Forumuser könnte mir die Lösung sagen;-)):
ATMega 48: er sagt er sendet mir 2Bytes, sendet aber nur eines (Buffer: 
64Byte, 64 passt in ein Byte), dann beim Speicher sagt er er Sendet 
3Bytes, sendet aber zwei, usw.
Dein Controller sagt auch er Sendet zwei Byte beim Buffer, sendet aber 
zwei...
Ich weiss (noch) nicht wo der Fehler liegt.


mfg Andreas

[Christian (Gast)]

Super!!!

Vielen Dank an  Peter Dannegger !

Hab den File auf meinen ATmega8 geflasht und konnte mit dem beigefügten 
Tool (fboot.exe) sofort meine hex-Files in den uC kopieren.
Sehr geil...  und auch noch dazu superschnell!

mfg Christian

[Jochen (Gast)]

Wirklich super der Bootloader! Hab ihn bei meinen RS485 Bussen 
mittlerweile auf jedes Device gebracht und bin wirklich sehr zufrieden!

Warte jetzt nur noch auf eine Weiterentwicklung des FBOOT.EXE Tools, die 
auch unter Vista läuft.

[Stefan (Gast)]

hast Du bidirektionale RS-485 oder unidirektionale mit Umschaltung der 
Sende- / Empfangsrichtung ?

[Jochen (Gast)]

Halbduplex - unidirektional.

[Horst (Gast)]

Ich habe mir nochmal die Linux-Version von fboot.c vorgenommen,
nachdem ich auch den Fehler mit der negativen Buffergroesse usw.
hatte.
Der Fehler lag wohl in "com_getc()".

horst.

[Tobias (Gast)]

Hallo Peter,

hast du für deine Bootloader mal eine Dokumentation gemacht.
Leider muß man sich alles aus den 3 Threads mit so vielen Beiträgen 
zusammen suchen :-(

Außerdem bi ich recht neu im Bereich der Mikrocotroller.

Mich würde eine genaue Bescreibung des AVR Programms
und eine genaue Beschreibng des PC Programms interessieren.

Gruß Tobias

[Andreas S. (andreas) (Admin)]

Es wäre sinnvoll dafür einen Artikel im Wiki zu erstellen:
Anleitung: Artikel erstellen

[Karsten D. (karstendonat)]

Hi,

hab jetzt nach über einem Tag intensivem probieren meine ganzen Fehler 
rausgekriegt und der Bootloader läuft ;-)

Da der ein oder andere Anfänger sicher ähnliche Probleme hat, hab ich 
mal ne kleine Anleitung geschrieben.

Seh auch grad die Frage nach dem Wiki. Wenn Ihr nichts dagegen habt 
schreib ich die Anleitung auch noch ins Wiki.

Am Support durch die ATMega IDE schreib ich gerade. Sollte also heute 
oder morgen dann downloadbar sein.

Die Geschwindigkeit ist echt der Hammer. Ich hab für ein Programm im 
168er mit dem ISP immer so 1,5 Minuten gebraucht. (inkl. Verify) Jetzt 
brennt er das in nur 3 Sekunden rein (ohne Verify).

Echt toll ;-)

Ciao
Karsten

[Karsten D. (karstendonat)]

So Wiki ist drin.

http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger

Ciao
Karsten

[David H. (davherrmann)]

Hallo,
ich würde das PC-Programm gerne in VB schreiben. Allerdings ist Java und 
C nicht gerade meine Stärke ;-)

Gibt es irgendwo eine ausführliche Dokumentation zum Protokoll zwischen 
MC und PC ?

Viele Grüße
David Herrmann

[Peter D. (peda)]

So, ich hab mich in Unkosten gestürzt und nen ATmega2561 gekauft.

Über 64kB brennen geht jetzt.

Allerdings ist noch irgendwo der Wurm drin, dauert sehr lange.

Daher hier erstmal ne Vorabversion.

Das Protokoll ist geändert, betrifft aber nur den Verbindungsaufbau 
(extra Zeichen nach Paßworterkennung), wurde für den Eindrahtmodus 
nötig.


David Herrmann wrote:
> Gibt es irgendwo eine ausführliche Dokumentation zum Protokoll zwischen
> MC und PC ?

Bisher noch nicht. Mal sehen, wann ich dazu komme.


Peter

[Stefan (Gast)]

Hallo...

nachdem Halb-Duplex ja mittlerweile implementiert ist, -vielen Dank 
dafür- habe ich den Code mal überflogen. Wenn ich's richtig verstanden 
habe, dient der C-Code hauptsächlich dem strukturierteren Aufbau; der 
eigentliche Bootloader ist jedoch in Assembler geschrieben !?
Jetzt bin ich in C nicht eben die Leuchte und möchte den Loader gern mit 
meinem bestehenden Assembler-Source verbinden, bzw. der Einfachkeit 
halber, den Assembler-Teil nachladen. Muss ich den Assembler-Code an 
eine bestimmte Adresse legen, damit's möglichst reibungslos funktioniert 
?
µC wäre ein Tiny45...


Gruß, Stefan


---

[Peter D. (peda)]

Der Bootloader ist pure Assembler.

Nur das PC-Programm ist in C geschrieben, muß man aber nicht neu 
übersetzen, die EXE ist ja schon dabei.

Ist nur für die, die es modifizieren (GUI) oder an Linux usw. anpassen 
wollen.
Manche mögen ja keine automatischen Programme, sie wollen lieber 
jedesmal umständlich umherklicken müssen.


Peter

[Stefan (Gast)]

Das macht die Angelegenheit doch schon viel transparenter ;)

Ich dachte ursprünglich, dass es jetzt ein Flag gibt, das zwischen uni- 
oder bidirektionale Kommunikation selektiert und dass noch Definitionen 
für den Pin für's Umschalten zwischen Senden und Empfangen, bei RS-485 
Treibern dazu gekommen sind.
Aber es sieht so aus, als ob man in der jeweiligen controller.asm 
einfach nur Senden und Empfangen auf den gleichen Pin legt und 
eventuelle Konflikte mit den Widerständen begrenzt !?
Demzufolge müsste für aktive Treiber, deren Umschaltung noch von Hand 
reingefrickelt werden !?
Wäre an sich kein Problem, wollte nur fragen, bevor ich den Source nach 
den TxD/RxD-Geschichten durchsuche...

Stefan


---

[Tom (Gast)]

Hallo,

ich habe gerade versucht den bootloader mit einem mega8535 ans laufen zu 
bekommen.
Habe dazu einfach das m8.asm file kopiert, und oben den include geändert 
(mega8535 hat auch 8kbyte flash).

Grundsätzlich scheint es auch zu laufen, er sagt das alles wunderbar 
ist:

COM 2 at 4800 Baud: Connected
Bootloader V1.6
Target: 1E9308
Buffer: 960 Byte
Size available: 7680 Byte
Program test.hex: 00000 - 0022F successful
CRC: o.k.
Elapsed time: 1.65 seconds

Das eigentliche Programm startet dann aber nicht.
Ich habe dann das Flash wieder per ISP ausgelesen, dabei stellte sich 
heraus das die erste 48 Bytes komplett verschieden sind.

Die ist .hex Datei (per ISP ausgelesen):

:10000000EC0102C02196E8DF88818823D9F7DF91CF
:10001000CF910895CF93DF93EC0101C0DDDFFE01A6
:10002000219684918823D1F7DF91CF910895FFCF56
:10003000D2E0DEBFCDBF10E0A0E6B0E0E0E3F2E04A

Die soll .hex Datei (compiliert):

:1000000014C02EC02DC02CC05BC02AC029C028C07F
:1000100027C026C025C05FC088C022C021C020C024
:100020001FC01EC01DC01CC01BC011241FBECFE5B9
:10003000D2E0DEBFCDBF10E0A0E6B0E0E0E3F2E04A

Erst ab der 4ten Zeile sind sie wieder identisch

Was ist da passiert?

PS:

case 0x1e9308: s = "ATmega8535"; break;

für die fboot.c ;)

[Werner B. (Gast)]

Ein Mega8535 ist nun mal kein Maga8.
z.B. die Interruptvektoren ganz am Anfang sind unterschiedlich.

Da musst du die Datenblätter vergleichen.

[Peter D. (peda)]

Tom wrote:

> Ich habe dann das Flash wieder per ISP ausgelesen, dabei stellte sich
> heraus das die erste 48 Bytes komplett verschieden sind.

Hab ich jetzt auch keine Erklärung dafür.

Versuch mal ganz oben Version 1.4, die sollte eigentlich laufen.

Die Version 1.6. hab ich nur ganz kurz getestet und noch nicht weiter 
verwendet.


Peter

[Johannes (Gast)]

Hallo,

ich versuche schon seit einiger Zeit den Bootloader (v1.4) zum laufen zu 
bekommen - leider ohne Erfolg. Versucht hab ichs mit einem M32 und einem 
M8. Als RX/TX benutze ich die Hardware Schnittstelle:

M32.asm:
;----------------------------------------------------------------------- 
--
;                               Port definitions
;----------------------------------------------------------------------- 
--
.equ    STX_PORT        = PORTD
.equ    STX_DDR         = DDRD
.equ    STX             = PD1

.equ    SRX_PIN         = PIND
.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0
;----------------------------------------------------------------------- 
--
.include "fastload.inc"
;----------------------------------------------------------------------- 
--

Habe das Programm mit AVRASM2 compiliert und anscließend mit dem 
AVR-Burn-o-mat in den COntroller geladen. Was mir sehr seltsam vorkommt, 
ist dass insgesamt 32722 Bytes in den Controller geladen werden (beim 
M32). Damit ist der Flash doch voll...?

Die Fuses sind auch gesetzt(nach Anleitung)...
Wenn ich jetzt fboot mit COM4 im Verzeichnis mit der Zielfirmware 
starte, kommt das Programm nicht weiter als "COM4 at 115200 Baud".
Zu erwähnen ist noch, dass ich den M32 mit einem Quarz 16MHz 
betreibe(ist auch in Fastload.h eingestellt.
Beim M8 gibts genau das gleiche Problem, der läuft aber mit 7,37MHz.
Die Bootzeit habe ich wegen der höheren Frequenz etwas erhöht, mehrer 
Werte von 3-16 ausprobiert, funktioniert trotzdem nicht...

Was mache ich falsch?? Könnt ihr mir weiterhelfen?

Gruß
Johannes

[F. K. (freddy436)]

In der Anleitung steht das man die Fuses auf 256 words setzen soll, in 
meinem Fall bin ich aber auf 512 gekommen.

[Johannes (Gast)]

hab das mit den 512Byte mal ausprobiert, hilft aber leider auch nix... 
Wo kann ich denn nachgucken, wieviel Bytes das compilierte Programm hat? 
Ist das der Wert, der nach dem Compilieren bei "Summery ... USED Memory" 
steht? (bei mir 470Bytes.

Kann das vielleicht auch mit dem USB- Seriell Adapter zusammenhängen?
Aber eigentlich läuft alles Andere wie geschmiert mit dem Adapter...

danke für den Tipp!

[F. K. (freddy436)]

Am besten machst du mal ein Chip Erase, brennst den bootloader und liest 
dann mal den Flash aus, wenn ich mich recht entsinne (bin gerade nicht 
am richtigen Rechner) fängt der Bootloader mit der Standard Config bei 
:101E0000 (Intel Hex) an.

[Tom (Gast)]

Habe es nun mit dem 1.4er versucht, jetzt brennter garnichts mehr ;)
Immer failed...

COM 2 at 4800 Baud: Connected
Bootloader V1.4
Target: 1E9308
Buffer: 64 Byte
Size available: 7680 Byte
Program test.hex: 0000 - 1300 failed !
Elapsed time: 21.59 seconds

Das /D lässt fboot anscheinend auch nur festfahren.

[Karsten D. (karstendonat)]

@Johannes
der Bootloader sitzt am oberen Ende im Flash. Der brennt praktisch 
erstmal ein leeres Programm und oben den Bootloader. Der Bootloader legt 
danach das eigentliche Programm wieder an der richtigen Stelle (weiter 
unten) ab.

Frequenz sollte nicht stören. Ich hab den M8 mit der 3,68er und den M168 
mit 8,000MHz benutzt. Die Wartezeit hat bei mir bisher keine Probleme 
gemacht.

Ich benutze auch die Hardware-Pins da ich da eh schon ne RS232 dran hab.

Größe ermitteln: avr-size -A m8.hex


@Kriewitz
256 Worte = 512 Bytes. und der Bootloader hat weniger als 512 Bytes 
(zumindest V1.4, 1.6 hab ich noch nciht getestet weil ich im Urlaub 
war).

[Peter D. (peda)]

Hab jetzt mal die Version 1.6 genauer getestet, die ist Schrott.
Mein Borland-C 3.0 weigert sich standhaft, Felder über 64kB zuzugreifen.

Also erstmal Version 1.4 verwenden.

Wenn da oft Bytes 0x13 vorkommen, geht die Geschwindigkeit über USB 
drastisch in die Knie.
Wird in Version 1.7 abgestellt (muß aber erstmal nen funktionierenden 
Compiler besorgen).

Wenn gar nichts geht, kann das an speziellen LPT-Treibern für direkte 
IO-Zugriffe (ISP) liegen, die können sich mit der COM im DOS-Fenster 
beißen. Also diesen mal deaktivieren.


> Program test.hex: 0000 - 1300 failed !

könnte das nicht aktivierte SELFPRGEN-Fusebit sein.


Peter

P.S.:
Ein kompletter ATmega2561 dauert ~33s.

[Karsten D. (karstendonat)]

Mit dem C-Builder von Borland (jetzt CodeGear) gehen auch 
Konsolenanwendungen. Die haben auf der Homepage auch eine Testversion 
zum Download.

An sonsten könnte ich was mit Delphi schreiben. Da kommt das je eh in 
die ATMega IDE rein.

Karsten

[Peter D. (peda)]

Anbei die neueste Version.

Wie es scheint, muß ich bei meinem uralt BC3.0 die 
Segment/Offset-Rechnung zu Fuß machen. Jedenfalls geht es jetzt.

Können sich die Windowsprogrammierer mal einen ablachen, was früher so 
für Verrenkungen notwendig waren.


Peter

[Karsten D. (karstendonat)]

Bin aber eher froh das ich mich mit sowas nicht mehr rumplagen muss. 
Wenn ich da so an Overlay Dateien usw. denk. Oder die selbstgeschriebne 
XMS Unit ;-)

Karsten

[F. K. (freddy436)]

Sorry, natürlich 256 words, nicht 512!

@Tom
Im Anhang ist eine funktionierende M8535.ASM, der mega8535 hat im 
Gegensatz zum mega8 nur 512kByte SRAM, BufferSize muss also auch 
angepasst werden.

@Peter
Du kannst die Datei gerne mit reinnehmen.
Hier nochmal die device id vom mega8535

case 0x1e9308: s = "ATmega8535"; break;

Kompletter flash (7680 Byte) hat bei mir 2,3 Sekunden gedauert :)

Getestet mit 115200 BAUD @ 14318180 Hz und FBOOT V1.7

[Stefan (Gast)]

Hat sich schon mal jemnad die Mühe gemacht, den PC-Teil in Delphi 
umzusetzten ?

[Karsten D. (karstendonat)]

Bin noch dabei.

Karsten

[Peter D. (peda)]

Anbei das PC-Programm mit einigen Typen hinzugefügt. Die Typenliste 
sollte man wohl besser auslagern.
Werde mal noch 8051-er hinzufügen, das Flip ist mir zu langsam und zu 
umständlich.

Den ATtiny44 hab ich noch getestet.

Der Eindrahtmodus funktioniert bei mir auch sehr gut bei 115200 Baud, 
geht also auch ohne MAX232.
Das Abzählen der Echobytes funktioniert zuverlässig.
Die Programmierzeiten sind gleich.


Peter

[Tom (Gast)]

Hallo,

super bootloader!

Mich würde noch interessieren was es mit der password.inc auf sich hat, 
kann man damit den Bootloader Zugriff beschränken? Falls ja, wie?

Und wie verhält sich der booloader wenn man etwas in den booloader 
Bereich flashen will (wenn man keine LockFuses programmiert hat)?

Bin mir gerade nicht sicher, aber kann man eigentlich auch per Booloader 
Fuses ändern, fände eine Möglichkeit die RSTDISBL Fuse zu ändern noch 
sehr praktisch.

[Peter D. (peda)]

Tom wrote:

> Mich würde noch interessieren was es mit der password.inc auf sich hat,
> kann man damit den Bootloader Zugriff beschränken? Falls ja, wie?

Das ist nur die Auswerteroutine für das Paßwort.

Du kannst auch ein anderes und auch längeres Paßwort als "PeDa" 
definieren, es muß bloß ein für die Baudratenerkennung geeignetes 
Zeichen enthalten, z.B. 'a'.

Und dann natürlich mit:

fboot17 -ineues_Passwort ...

dem PC-Programm übergeben (sehe gerade, das fehlt im Hilftext).

Ohne das Paßwort kommt keiner in den Bootloader.
Man kann also ruhig Geräte an die UART anschließen, die schon beim 
Einschalten sehr gesprächig sind.


> Und wie verhält sich der booloader wenn man etwas in den booloader
> Bereich flashen will (wenn man keine LockFuses programmiert hat)?

Die Programmierroutine macht immer einen Adreßcheck und verweigert die 
Selbstzerstörung.

Aber auch schon das PC-Programm bricht ab, wenn die höchste Adresse über 
dem Applikationsbereich liegt.


> Bin mir gerade nicht sicher, aber kann man eigentlich auch per Booloader
> Fuses ändern, fände eine Möglichkeit die RSTDISBL Fuse zu ändern noch
> sehr praktisch.

Die Fuses kann der AVR nicht selber ändern.


Peter

[Tom (Gast)]

Danke!

>Du kannst auch ein anderes und auch längeres Passwort als "PeDa"
>definieren, es muß bloß ein für die Baudratenerkennung geeignetes
>Zeichen enthalten, z.B. 'a'.
Was macht das 'a' so gut tauglich für die Baudratenerkennung?

[Peter D. (peda)]

Nun, das Paßwort enthält ja verschiedene Bytes, die Low-Impulse von 1..9 
Bitzeiten enthalten können.

Damit nun die Baudratenerkennung nicht austillt, prüft sie das 
Verhältnis zweier aufeinanderfolgender Low-Pulse, ob es 1:4 beträgt. Das 
ist z.B. beim 'a' der Fall.


Man könnte sie in die Irre führen, indem man die Bytefolge 0x20,0x80 
sendet, dann hat man 2 Bitzeiten gefolgt von 8 Bitzeiten, was auch 1:4 
ist. Dann steht die Baudratenerkennung aber auf der halbe Baudrate. 
Daher dürfen derartige Bytefolgen nicht im Paßwort vorkommen.


Peter

[Tom (Gast)]

ah ok, danke für die Erklärung

[Der T. (Gast)]

Zuerst einmal Respekt! :)

Habe jedoch mit dem FBOOT17 hin und wieder ein Problem. Manchmal 
reagiert die DOS-Box, in der ich das Programm starte nicht mehr (Keine 
Rückmeldung). Aber wie gesagt nicht immer. (so ca. bei jedem 10. Mal) 
Als System hab ich ein aktuelles WinXP Home. Hast du eine Idee, woran 
das liegen könnte?

Deshalb die Frage: Ist ein Windows-Tool geplant bzw. in Arbeit? :)

Falls nein: Könntest du bitte Details zum Protokoll veröffentlichen, 
dann werd ich vorr. übernächste Woche (kommende Woche bin ich im Urlaub 
- juhu) mal mit VB ein Windows-Tool zusammenstricken..

Falls ja: Wann (ca.) und wo kann es downloaden? Ist dann hoffentlich 
Freeware?

Gruß,
Techniker

[Peter D. (peda)]

Der Techniker wrote:

> Habe jedoch mit dem FBOOT17 hin und wieder ein Problem. Manchmal
> reagiert die DOS-Box, in der ich das Programm starte nicht mehr (Keine
> Rückmeldung).

Hast Du USB/RS232 oder ne echte RS232 ?
Hast Du nen LPT-Treiber installiert, z.B für SPI ?

Bei USB mal den neuesten Treiber installieren.
Bei LPT mal den Treiber deaktivieren.
Drauf achten, daß keine andere Anwendung die gleiche COM belegt.

Das Protokoll werd ich demnächst aufschreiben.


Peter


P.S.:
Ich hab ja kürzlich mal den ATtiny13 programmiert, da hab ich mich über 
den Bootloader geärgert :-)
Und zwar, warum ich ihn nicht früher entwickelt habe.
Es macht jetzt richtig Spaß. Besonders der 1-Drahtmodus bei den 
8-Pinnern ist goil. Und man kann endlich alle 6 IOs benutzen ohne nur 
einen einzigen Schuß zu haben.

[Der T. (Gast)]

Ich arbeite an meinem alten Desktop -> also echte RS232..

[Tom (Gast)]

Also das "nicht reagieren" kenne ich auch nur wenn der Port bereits von 
einem anderen Programm verwendet wird.

Eventuell irgend ein Programm im Hintergrund was von Zeit zu Zeit alle 
Ports abklappert?

[Der T. (Gast)]

..hmm..

Sollte eigendlich nichts laufen, was die RS232 stören könnte..
Alle anderen Anwendungen, die RS232 benuten laufen ja problemlos..
(..davon läuft aber keins im Hintergrund..)

PS: Auch ein wechsel der Schnittstelle auf COM2 bringt keine wesentliche 
Verbesserung.. :-/

[Dirk S. (disc)]

Hallo Leute,
ich habe in den letzten Tagen versucht, den Bootloader (V1.7) bei mir 
ans Laufen zu bekommen. Leider nur mit wenig Erfolg :-(.

Zunächst mal meine Konfiguration: ATMEGA644, TXD auf PD1, RXD auf PD0 
(Standard-UART vom 644)

Ich bin dann nach der Wiki-Anleitung vorgegangen:
- fastload.h angepasst :".equ XTAL = 20000000 ; 20MHz, not critical"
- in m644.asm die Ports auf Port D angepasst
- übersetzt mit "avrasm2 -fI m644.asm"
- gebrannt mit "avrdude -p m644 -c stk200 -P lpt1 -U 
flash:w:"m644.hex":i -U flash:v:"m644.hex":i -y"
- Fuses gesetzt: BOOTRST programmiert, BOOTSZ0 und BOOTSZ1 nicht 
programmiert. Das heißt allerdings beim 644 "Boot size=512 Words" 
(kleinster möglicher Wert). In der Wiki steht etwas von 256 Worte. Ist 
das ein mögliches Problem???
- Wenn ich jetzt fboot17 aufrufe, kommt folgende Ausgabe:

D:\Daten\AVR\BOOTLO~1>fboot17 /C1 /Pflash.hex
COM 1 at 115200 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

D:\Daten\AVR\BOOTLO~1>

Wenn ich beim fboot ein anderes Passwort setze, z.B. "fboot17 /ifoo" 
kommt es nicht zum Connect. Ich nehme daher mal an, dass zumindest die 
Passwortabfrage funktioniert!?!

Die Version 1.4 hab ich auch schon mal kurz probiert, hier kommt es noch 
nicht mal zum Connect.

Vielleicht fällt einem von Euch noch etwas dazu ein oder hat Tipps dazu.

Gruß

Dirk

[F. K. (freddy436)]

Versuchs mal mit einer niedrigeren BAUD rate (/B9600)

[Dirk S. (disc)]

@freddy436

Danke für den Tip. Hab´s gleich probiert. Funktioniert aber leider auch 
nicht :-(.

[Bingo (Gast)]

Hallo

Habe probiert Peters PC program Fboot17.exe zum portieren aus DEV-Cpp , 
ich glaube ich habe success. Ich kann programmiere mit 57600 , aber 
115200 geht nicht , vielleicht ob die uart routinen optimiert bist.

Aber da ist support von Com 1..5 , ind source ist inkludiert.

Installiere Dev-Cpp
http://www.bloodshed.net/dev/devcpp.html

Download
http://prdownloads.sourceforge.net/dev-cpp/devcpp-4.9.9.2_setup.exe

Und extract die Fboot source , dan "Klik" am fboot.dev file.
Zum die projekt loaden.
Selektiere im Dev-Cpp select : Execute->Rebuild All

Danke an Peter , und hoffe diser program ist brauchbar.

Ps: Die program hast sources von Peter-D , und snippets von Peter Fleury 
, und die linux programmer von diser thread.

Pps: Ich habe nur die program kurtzes testet.
Das ist nur einer schnell C program mit serial  I/O usv im C ... und 
kein C++ braucht.



Grüsse aus Dänemark
/Bingo

Hoffe meiner "Schule Deutch" ist verstehbar

[Bingo (Gast)]

Nur einer kleine dinge mehr

Die program unterstutzt auch lange dateinahme

/Bingo

[Bingo (Gast)]

@Peter

Ich bin nicht 100% sicher , das ich habe die timeout implementiert 
korrekt.

Im Dev-Cpp bist 1000 clock() ticks pro sekunde , vie viel ist im Borland 
??

mfg
/Bingo

[Peter D. (peda)]

Bingo wrote:
> Im Dev-Cpp bist 1000 clock() ticks pro sekunde , vie viel ist im Borland
> ??

Das ist der DOS-Timertakt:

#define CLOCKS_PER_SEC 18.2
#define CLK_TCK        18.2

Peter

[Bingo (Gast)]

Einer kleine verbesserung

Im serial_connect (void) routine
Erszatz die linie
  if (--i > 6)
mit
  if (--i >= (sizeof(devtab)/sizeof(devtab[0])))

Dann passt mehre comports im diser linie automatisch
char *devtab[] = { "COM1", "COM2", "COM3", "COM4", "COM5", "COM6" };

/Bingo

[Gast (Gast)]

... und ab Com9 muss es "\\.\Com9" heißen.

Bei Com1..Com8 stört der Präfix auch "\\.\" nicht.

[Bingo (Gast)]

@Gast
"... und ab Com9 muss es "\\.\Com9" heißen." ........

Bist du sicher ???

Ich habe nur diser syntax sehen , im die com-bridge das lady-aya 
brauchst im eure, Atmel USB programmer. Und ich glaube die prefix war im 
die driver.
Nicht im einer standard Windows

/Bingo

[Gast (Gast)]

siehe hier:
http://support.microsoft.com/kb/115831/en-us

[Bingo (Gast)]

@Gast

Du hast recht , das ist einer Native Windows dinge

/Bingo

[Peter D. (peda)]

Hat denn jemand von Euch wirklich so viele RS232-USB Adapter 
gleichzeitig in Betrieb, daß er so hohe COMs braucht ?

Ich habe am Notebook nur 2 USB-Anschlüsse und die habe ich als COM1 und 
COM2 konfiguriert.

Und am Desktop habe ich ne interne COM1 und die 2 USB an der Frontseite 
sind dann COM2 und COM3.


Peter

[Bingo (Gast)]

@Peter

Ich habe COM1 .. COM6 (2x eingebaut und 2x2 von PCI karte), und das ist 
ohne die viele FTDI virtual Comadapters , ich glaube meiner höheste 
comport ist 9

/Bingo

Ps: Hast jemand die Dev-Cpp program probiert ??

[Joerg (Gast)]

So, jetzt muss ich diesen genialen Bootloader auch mal probieren... 
scheint ja meine Probleme lösen zu können ;-)

will ihn für den ATtiny85 verwenden, da ich den reset-pin als io 
verwenden muss und daher ISP nicht mehr nutzen kann.

habe mit jetzt eine datei T85.asm mit folgendem Inhalt angelegt:

.nolist
.include "tn85def.inc"

.equ  CRC      = 17
.equ  VERIFY      = 15
.equ  ONEWIRE      = 3

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
.equ    STX_PORT        = PORTB
.equ    STX_DDR         = DDRB
.equ    STX             = PB2

.equ    SRX_PIN         = PINB
.equ    SRX_DDR         = DDRB
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB2
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

soweit so gut... kompilieren ging auch alles sehr einfach von der Hand. 
-> der Bootloader wurde auf Adress 0x1E00 gelegt.
Ein paar Dinge sind mir aber noch unklar.
Der ATtiny85 hat ja keinen Bootblock... wie wir er nun aufgerufen. 
normalerweise wird der bootloader ja zuerst gestarte... und wenn die die 
definierte Bootloader-Bedinging (was auch immer) erfüllt ist, dann 
bleibt er im Bootloader und wenn nicht, dann wird das Hauptprogramm 
gestartet. Wie funktioniert das jetzt hier? Denn der Chip startet ja 
immer auf 0x0000. Aber hier liegt ja mein Hauptprogram. Oder muss ich 
die Bedingung in meinem Hauptprogramm einbauen und dann nach 0x1E00 
springen um den  Bootloader zu aktivieren?

Habe einen 12MHz Quarz. und BootDelay auf XTAL / 10 gesetzt... was 
bedeutet das jetzt?

Danke und liebe Grüsse
Jörg

[Peter D. (peda)]

Joerg wrote:

> Ein paar Dinge sind mir aber noch unklar.
> Der ATtiny85 hat ja keinen Bootblock... wie wir er nun aufgerufen.
> normalerweise wird der bootloader ja zuerst gestarte... und wenn die die
> definierte Bootloader-Bedinging (was auch immer) erfüllt ist, dann
> bleibt er im Bootloader und wenn nicht, dann wird das Hauptprogramm
> gestartet. Wie funktioniert das jetzt hier? Denn der Chip startet ja
> immer auf 0x0000. Aber hier liegt ja mein Hauptprogram. Oder muss ich
> die Bedingung in meinem Hauptprogramm einbauen und dann nach 0x1E00
> springen um den  Bootloader zu aktivieren?

Der Bootloader leitet den ersten Sprungbefehl (RJMP) Deiner Applikation 
um.
Du brauchst also auf den Bootloader keinerlei Rücksicht zu nehmen.


> Habe einen 12MHz Quarz. und BootDelay auf XTAL / 10 gesetzt... was
> bedeutet das jetzt?

Das ist die Zeit, in der der Bootloader die Baudrate und das Paßwort 
erkennt.

1/10s = 100ms, könnte etwas knapp werden.
Ich nehme lieber 1/3 = 333ms.


Peter

[Hagen R. (hagen)]

Der Bootloader "patcht" quasi bei Upload einer neuen Anwendung den RESET 
Vektor so das er immer aufgerufen wird.

Gruß Hagen

[Joerg (Gast)]

hmmm... habe jetzt ewig gesucht und nicht verstanden, warum auf 0x0000 
kein Code steht...

kann sein, dass die Datei "fastload.inc" auf folgendes geändert gehört:

.nolist
.include "fastload.h"
.listmac
.list

.ifndef BootFuse
  .org  0x0000
  rjmp  init
.endif

  .org  BootStart
init:

oder habe ich was übersehen, wo der "rjmp init" sonst gemacht gehört?

[Peter D. (peda)]

Joerg wrote:
> hmmm... habe jetzt ewig gesucht und nicht verstanden, warum auf 0x0000
> kein Code steht...

Ein leerer Flash enthält ja 0xFFFF.
Es ist zwar nicht offiziell, aber dieser Befehl wirkt wie ein NOP, der 
Code läuft also das erste mal durch bis zum Bootloader.
Kannst natürlich auch nen Sprung eintragen.


Peter

[Joerg (Gast)]

habe das ganze jetzt probiert und es funktioniert SUPER!!!!

ich mich niederknien und verbeugen tu

habe mir mit einem Pogo-Pin einen Adapter zum 1wire programmieren 
gemacht... und unglaublicherweise hat es gleich funktioniert. pogo-pin 
auf SMD-Widerstand gedrückt, und ab ging die Post hut ab

[Stefan (Gast)]

@Karsten

Gibt's denn schon was Neues in bezug auf Deine Delphi-Portierung ?

[Der T. (Gast)]

..und ich warte immer noch auf die Protokoll-Doku..  ;)

[Joerg (Gast)]

Habe gestern den Bootloader auf einem ATmega88 mit der Onewire probiert 
-> GENIAL.

also der One-Wire mode ist schon ein nettes Feature. Versorgung und 
Pogo-Pin und ab geht die Post

[Malte _. (malte)]

Dein letzter Bootloader war schon super, aber dieser ist noch besser. 
Ich hatte damals überlegt ob es möglich wäre den alten Bootloader auch 
in 512 Byte zu quetschen, hatte aber keinen Weg gefunden, der neue hat 
mehr Funktionen und erfüllt den 512 Byte Wunsch :-)
EEProm schreiben war aber bei den 470 Byte nicht mehr möglich, oder?

[Alexander (Gast)]

Was muß man zur Benutzung des „Eindrahtmodus“ an den Port-Pins ändern?

;----------------------------------------------------------------------- 
--
;                               Port definitions
;----------------------------------------------------------------------- 
--
.equ    STX_PORT        = PORTB
.equ    STX_DDR         = DDRB
.equ    STX             = PB1

.equ    SRX_PIN         = PINB
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB0

Mit einem MAX232 mit zwei Drähten läuft alles super, nur der 
„Eindrahtmudus“ aus Peters 1wire.pdf will noch nicht so, wie ich es 
will…
Würde gern ohne MAX232 auskommen.

[Joerg (Gast)]

also meine Einstellungen für einen ATtiny85 1-wire schaut so aus:

.nolist
.include "tn85def.inc"

.equ  CRC        = 17    ; 17 = additional code size
.equ  VERIFY      = 15
.equ  ONEWIRE      = 3

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
.equ    STX_PORT        = PORTB
.equ    STX_DDR         = DDRB
.equ    STX             = PB2

.equ    SRX_PIN         = PINB
.equ    SRX_DDR         = DDRB
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB2
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

[Alexander (Gast)]

Kann sich bitte jemand meinen Schematischen Schaltplan für den 
„Eindraht-Betrieb“ ansehen, ob dort ein Fehler in der Schaltung ist…
Ich hoffe, ich habe Peters Schaltplan richtig aufgebaut.

Leider habe ich den Eindrahtmodus am ATmega8 noch nicht zum laufen 
gebracht. Mit zwei Drähten und einen MAX232 klappt es sofort. Würde gern 
den MAX232 einsparen.

Hier meine Porteinstellungen für den Eindrahtmodus
;----------------------------------------------------------------------- 
--
;                               Port definitions
;----------------------------------------------------------------------- 
--
.equ    STX_PORT        = PORTB
.equ    STX_DDR         = DDRB
.equ    STX             = PB1

.equ    SRX_PIN         = PINB
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB1
;----------------------------------------------------------------------- 
--

[Peter D. (peda)]

.equ  ONEWIRE      = 3

Peter

[Alexander (Gast)]

Der Eindrahtmodus funktioniert jetzt :-)
Es lag an:
.equ  ONEWIRE      = 3

Danke für Eure Hilfe

[Kurt (Gast)]

Ich verfolge jetzt schon eine Zeitlang diesen super threat.
Nun plane ich einen mega8 mit dem "ONEWIRE" zu flashen.
Dazu habe ich mir tinyload3.zip heruntergeladen, in m8.asm die Ports 
angepasst und mit dem AVR-Studio ein Hexfile erzeugt - aber wo finde ich

.equ  CRC        = 17    ; 17 = additional code size
.equ  VERIFY      = 15
.equ  ONEWIRE      = 3

Werde mir Morgen noch das Kabel schnitzen
Vielen Dank die Info

[Stefan (Gast)]

Ähm, den Bootloader finde ich klasse und um so bedauerlicher ist es, 
dass die Kokumentation des Protokolls immer noch "fehlt". Das "fehlt" 
deshalb in Anführungszeichen, da wir ja nicht wirklich einen Anspruch 
darauf haben. Aber einige -mich eingeschlossen- möchten gern die 
PC-Seite in andere Sprachen umsetzen oder gleich ganz in eine 
Applikation einbinden. Wäre doch schade, wenn so eine feine Applikation 
über die ersten, wenn auch sehr erfolgreichen, Schritte nicht hinaus 
kommt...
Haben wir da noch Chancen ?

Gruß, Stefan


---

[Peter D. (peda)]

Stefan wrote:
> Ähm, den Bootloader finde ich klasse und um so bedauerlicher ist es,
> dass die Kokumentation des Protokolls immer noch "fehlt". Das "fehlt"
> deshalb in Anführungszeichen, da wir ja nicht wirklich einen Anspruch
> darauf haben. Aber einige -mich eingeschlossen- möchten gern die
> PC-Seite in andere Sprachen umsetzen oder gleich ganz in eine
> Applikation einbinden. Wäre doch schade, wenn so eine feine Applikation
> über die ersten, wenn auch sehr erfolgreichen, Schritte nicht hinaus
> kommt...
> Haben wir da noch Chancen ?


O.k., hier isses.


Peter

[Peter D. (peda)]

Und schon den ersten Fehler gefunden:

...
5.
Abfrage Useflashgrö0e:

Senden: COMMAND, USERFLASH
Antwort: ANSWER, 0x04, Flash_high, Flash_mid, Flash_low, SUCCESS
...

Peter

[Peter D. (peda)]

CRC vergessen.


Peter

[Kurt (Gast)]

Nochmal
Wo bitte finde ich die Defines

.equ  CRC        = 17    ; 17 = additional code size
.equ  VERIFY      = 15
.equ  ONEWIRE      = 3

Ich kann die Defines in der Source nicht finden - gibt es eine neuere 
Version von Loader als tinyload3.zip

[Karsten D. (karstendonat)]

Danke für das Protokoll ;-)

Ich war leider mehrere Wochen ohne Internet (warum gibts sowas 
eigentlich nich im Krankenhaus?).

Aber jetzt code ich wieder weiter an der IDE und auch nem Tool für den 
Bootloader mit klicki bunti g

Ciao

Karsten

[Peter D. (peda)]

Kurt wrote:
> Ich kann die Defines in der Source nicht finden - gibt es eine neuere
> Version von Loader als tinyload3.zip

http://www.mikrocontroller.net/attachment/25943/fboot17.zip


Peter

[Peter D. (peda)]

Falls es jemanden interessiert:

Ich hab den Bootloader in nen ATtiny45 gebrannt und danach Reset 
disabled.

Dann hab ich per Bootloader ein Programm reingeschrieben, welches PB5 
toggled und es läuft.


Peter

[Elektrikser (Gast)]

Hallo Peter,

das interessiert schon. Vielen Dank!

Ich muss im nächsten Bastelprojekt einen Tiny45 ausreizen. Da kommt es 
natürlich gut, wenn man alle Pins belegen kann. Da werde ich es 
ausprobieren.

Gruß Gerd G.

[Kurt (Gast)]

Hallo Peter
Vielen Dank für den Hinweis.
Ich habe den mega8-Loader zunächst mal für Bidirektional angepasst.
Die Sende und Empfangspins
.equ    STX_PORT        = PORTD
.equ    STX_DDR         = DDRD
.equ    STX             = PD1

.equ    SRX_PIN         = PIND
.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0
-------------------------------
Ich verwende einen 16Mhz Quarz
.equ  XTAL    = 16000000  ; 8MHz, not critical
.equ  BootDelay  = XTAL / 3  ; 0.33s

Fusebits BOOTSZ0=0
         BOOTSZ1=1
         BOOTRST=0

Wenn ich Fboot17.exe mit /Pxy.hex starte (das Programm xy.hex lief mit 
ISP Programmierung), kann ich mit dem Skope an PD0 (RX) wildes Zappeln 
zwischen -0,9 und +6V sehen. An PD1 (TX) sehe ich einen 4V Pegel und 
alle 8ms für 240µs 0V. Am PC sehe ich "Com 1 at 115000 Baud: |" das 
letzte Zeichen dreht sich bis zun St. Nimmerleinstag. Warum kann der PC 
die Baudrate nicht finden? Liegt es an meinen 16MHz?

[Peter D. (peda)]

Kurt wrote:

> Wenn ich Fboot17.exe mit /Pxy.hex starte (das Programm xy.hex lief mit
> ISP Programmierung), kann ich mit dem Skope an PD0 (RX) wildes Zappeln
> zwischen -0,9 und +6V sehen.

Ohne MAX232 habe ich nur den 1-Drahtmodus vorgesehen (geht ja auch nicht 
anders).
Im 2-Drahtmodus mußt Du noch die Bitmacros invertieren, wenn Du keinen 
MAX232 benutzt.


Peter

[Kurt (Gast)]

Hey Peter.......
Der Wahnsinn. Der Loader läuft jetzt mit ONEWIRE und das auch noch super 
schnell!!!!
Vielen Dank für deine Geduld.

[Der T. (Gast)]

Hallo Peter,

Da ich leider der Assembler-Sprache nicht so mächtig bin (g) wollte 
ich dich fragen, ob es ein großer Aufwand für dich wäre wenn du mir 
einen kurzen Tipp gibst, was ich für 3 zusäzlich abfragbare Variablen am 
Bootloader ändern muss.. (Im Prinzip so, wie die Versionsabfrage des 
Bootloaders..)

Ich möchte gerne zwei 16Bit-Zahlen (für Software-, und Hardwarestand) 
hinzufügen. Zusätzlich bräuchte ich noch eine 16Byte breite Variable für 
die "Softwarebeschreibung". (Damit man nicht beim Gerät x die Firmware 
für Gerät y aufspielen kann; zur Not reicht hier auch eine 16Bit-Zahl - 
falls es einfacher zu realisieren ist..)

Das ändern der PC-seitigen Software ist kein Thema..

Problematisch ist für mich nur der Assembler-Code. :(

Danke schonmal im Vorraus! :)

Gruß,
Techniker


PS: Der Bootloader ist echt absolute spitze! ;-)

[Peter D. (peda)]

Der Techniker wrote:

> Da ich leider der Assembler-Sprache nicht so mächtig bin (g) wollte
> ich dich fragen, ob es ein großer Aufwand für dich wäre wenn du mir
> einen kurzen Tipp gibst, was ich für 3 zusäzlich abfragbare Variablen am
> Bootloader ändern muss.. (Im Prinzip so, wie die Versionsabfrage des
> Bootloaders..)

Anbei die Routine.
Abgefragt werden die 3 Parameter mit den Codes 253,254,255.
Die Definitionen sind zwischen den =============-Zeilen.


Peter

[Der T. (Gast)]

Hallo Peter!

Zuersteinmal vielen dank! :)

Leider ist mir gerade vorhin aufgefallen, dass es ja ein taktischer 
Blödsinn ist, wenn der Softwarestand im Bootloader hinterlegt ist.. 
dummguck

Naja.. Hardwarestand und Software-ID werd ich aber auf jedenfall dort
hinterlegen..


Zum Assembler-Code:

Mittlerweile hab ich auch schon ein bischen rumexperimentiert.. ;-)
(..habs aber noch nicht getestet..)

Du schreibst:

;=====================================================================
.equ  user_no_253  = 0x1234
.equ  user_no_254  = 0x5678
.equ  user_no_255  = 0x9ABC
;=====================================================================
  subi  a0, -3      ; add 3 messages (253,254,255)
  cpi  a0, 7
  brcs  sendmessage    ; 0 ... 6
  subi  a0, 3
;=====================================================================

Könnte ich auch das so formulieren: (?)
In FASTLOAD.H hinzufügen:

.equ  hwVER    = 0xabcd
.equ  swID    = 0x1234

FASTLOAD.INC siehe Anhang

Gruß,
Techniker

[J.L. (Gast)]

Hallo

ich hab da auch mal eine frage.

Ich möchte über die DTR leitung, einen Transistor ansteuern der mir dann 
reset kurz aktiviert. Dieses möchte ich mit der Option "/R" aktivieren 
können.

Leider macht die DTR-Leitung jedoch bei jedem Init für etwa 625ms einen 
12V-Impuls. Warum? Kann ich diesen irgendwie unterdrücken?

outportb(ComPort+4, 0x00);

..macht keinen Unterschied zu..

outportb(ComPort+4, 0x01);

Grüsse,
Jochen

[Peter D. (peda)]

Der Techniker wrote:

> Mittlerweile hab ich auch schon ein bischen rumexperimentiert.. ;-)
> (..habs aber noch nicht getestet..)

Dadurch verschieben sich aber auch alle bisher definierten Funktionen.


Peter

[Dirk (Gast)]

>Leider macht die DTR-Leitung jedoch bei jedem Init für etwa 625ms einen
>12V-Impuls. Warum? Kann ich diesen irgendwie unterdrücken?


Hallo, koennte das wie beim USB FTDI CHIP die Enumaration ?

[Der T. (Gast)]

@Peter:

Ja - das habe ich aber auch berücksichtigt.
Mittlerweile läuft er wunderbar.. ;) - Danke!

Die Idee mit der DTR-Leitung von "J.L." gefällt mir, jedoch habe ich das 
selbe "Problem".. :-/

Gibt es dafür eine Lösung?


@Dirk:
Wer oder was ist eine "Enumaration"?
Kann man das essen?  :o)


Gruß,
Techniker

[Der T. (Gast)]

@Dirk:

Jetzt hab ich verstanden, was du meinst! ;)

Auf gut deutsch: Mir funkt XP dazwischen.. :(

Hab das ganze auf einem Win98-Rechner ausprobiert -> funktioniert 
einwandfrei! :)

Auf einer XP-Kiste kommen immer noch ein paar Impulse zusätzlich.. :(

Gibts da einen Workaraound?

Gibts sowas wie MS Visual C++ als kostenlose Open-Source, damit man das 
DOS-Proggi XP-tauglich bekommt? Kennt da zufällig jemand etwas in der 
Richtung?

Gruß,
Techniker

[Bingo (Gast)]

Einer update von meiner dev-cpp (Windows 32) port von Peters bootloader
Exe datei ist inkludiert.
Ich habe nur probiert mit einer kleiner hexdatei , und ich brauche 57600 
bps nicht 115200 (gibts probleme bei mir)

grusse von Dänemark

Bingo

[Jogi (Gast)]

Hallo PeDa,

kleine OT-Nachfrage an den Praktiker:

Wie bekommst Du den Bootloader das erste mal in den AVR?
Nicht beim Labormuster sondern bei der Produktion?

Bei DIL/DIP kein Thema, aber was ist bei den SMD-Typen?
a) Erst einlöten - dann werden aber die ISP-Pins trotzdem benötigt
   und kosten Platz/Stecker.
b) Spezielle Programmierfassung - sehr (Sau) teuer.
c) Beim Distributer progammieren lassen - unflexibel weil Fusebits 
bekannt
   sein müssen (Takt  Startup  Brownout...)

Gruß Jogi

[Andreas K. (andie)]

Hallo zusammen,

ich würde gerne den Bootloader von Peter für mein Gerät mit RS485 
Schnittstelle verwenden. Ich schalte nun in der putchar-Routine zu 
Beginn den RS485-Treiber auf Senden und vor dem Verlassen der Routine 
wieder auf Empfangen.
Diese Änderung funktioniert nun nur leider nicht sehr zuverlässig. Ich 
bekomme sehr oft einen CRC-Error. Ich habe es schon mit diversen Pausen 
vor und nach der Umschaltung versucht, doch ich bekomme das Timing nicht 
100% in den Griff.
Hat vielleicht von euch schon einer in dieser Richtung Erfahrungen 
gemacht?
Wäre über jeden Tipp dankbar.

Schöne Grüße
andie.

[Patrick (Gast)]

Hallo,
ich versuche gerade den bootloader auf meinem mega644 zum laufen zu 
bringen. Klappt jedoch nicht so richtig. Ich habe genau das gleiche 
Problem wie es schon Dirk Schmidt (disc) am 13.09.2007 weiter oben 
geschildert hat. Nur leider gab es damals keine Antwort...

Ich bin beim flashen nach der wiki Anleitung vorgegangen.
meine Einstellungen: TX und RX auf PortD, XTAL=18432000, 
bootdelay=xtal/3
->mit "avrasm2 -fI m644.asm" übersetzt und mit ponyprog (lpt1) gebrannt
->fuses gesetzt: bootrst=0,bootsz1=1,bootsz0=0

beim Start von fboot.exe erscheint nun folgender fehler für V1.4

C:\boot>fboot /C1 /Pmain.hex
COM 1 at 115200 Baud: Connected
Bootloader VFFFFFFFF.FF
Target: FFFFFFFF
Buffer: -1 Byte
Size available: -1 Byte
CRC: error !
Elapsed time: 0.55 seconds

und für V1.7

C:\boot>fboot17 /C1 /Pmain.hex
COM 1 at 115200 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

Ich habs auch schon mit einer geringeren Baudrate (wie oben empfohlen) 
probiert, leider ohne Erfolg.
Dumme Frage: Könnte es an meinem Kabel liegen? Ich verwende in normales 
Nullmodemkabel. ´Hat jemand das selbe Problem gehabt und/oder kann mir 
helfen?

Patrick

[Der T. (Gast)]

@Jogi:

Würde mich auch mal interessieren.. ;)

Den einzigen Vorteil von einem Bootloader (den ich sehe) ist, dass der 
Kunde ohne große Kenntnisse eine neue Firmware selber aufspielen kann..

Ich mache das schon seit einiger Zeit so, dass ich mir ein spezielles 
Footprint angelegt habe welches 3 Bohrungen und die ISP-Pins als kl. 
Kontaktflächen besitzt. Dann habe ich mir einen Handadapter aus Pertinax 
gebaut, der die 3 Bohrungen als Fixierung verwendet und die Kontakte 
mittels feinen Prüfnadeln herstellt.

Das programmieren geht so recht einfach und fix - ohne große 
Plazverschwendung und Bauteilkosten. Sollte dann die Baugruppe in Serie 
gehen , werden die Kontakte dann mittels einer Prüflingsaufnahme 
kontaktiert..

Mit einem Bootloader wird das programmieren nur noch ein einziges mal 
gemacht und der Rest läuft über die RS232 oder einer 
"Programmierbuchse"..

:)

Gruß,
Techniker

[Peter D. (peda)]

Patrick wrote:

> Ich habs auch schon mit einer geringeren Baudrate (wie oben empfohlen)
> probiert, leider ohne Erfolg.

In Deinen Screenshots sinds aber immer nur 115200Baud, versuche mal 
/b19200.

Die Versionen 1.4 und 1.7 sind zueinander inkompatibel, kann also nicht 
gehen.

Die Version 1.7 ist besser, benutze diese (Assemblerprogramm und 
fboot17.exe).


Peter

[Peter D. (peda)]

Jogi wrote:
> Wie bekommst Du den Bootloader das erste mal in den AVR?
> Nicht beim Labormuster sondern bei der Produktion?
>
> Bei DIL/DIP kein Thema, aber was ist bei den SMD-Typen?

Ich habe keine Platzprobleme, benutze bisher nur DIP (gesockelt).

Und die Serienproduktion lassen wir extern machen.


Peter

[Patrick (Gast)]

@Peter

Danke erstmal für die schnelle Antwort.

Ich habe alles nochmal neu heruntergeladen (V1.7) und kompiliert. Es 
funktioniert aber trotzdem nicht. Hier kurz der Nachweis:

D:\fboot17>fboot17 /C1 /Ptest.hex
COM 1 at 115200 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

D:\fboot17>fboot17 /C1 /B19200 /Ptest.hex
COM 1 at 19200 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

D:\fboot17>fboot17 /C1 /B9600 /Ptest.hex
COM 1 at 9600 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

Ich habe jetzt mal die fastload.h, m644.asm und die m644.hex angehangen. 
Vielleicht hab ich dort irgendwo was verpeilt.

Grüße,
Patrick

[Peter D. (peda)]

@Patrick,

muß irgendwie an Deinem PC liegen, das Connect wird noch empfangen und 
ab da nichts mehr.
Hast Du irgendwelche Treiber für COM/LPT installiert?
Erzähl mal was über Deinen PC (CPU, RAM, MHz, OS, COM, CPU-Auslastung 
usw.).

Ich könnte mal ne Version mit nem längeren Timeout machen.


Peter

[Patrick (Gast)]

@Peter

Ich hab hier einen "alten" sony vario notebook: intel P2, 64mb ram, 
Windows2000 SP4, eine Com Schnittstelle, CPU Auslastung nach start von 
fboot geht auf 30%, über MHZ konnte ich nichts rausbekommen (wird 
irgendwie nicht angezeigt).

Gestern hab ich es auch schon auf einem Acer notebook (winXP, 1.5GHz, 
512MB ram, intel centrino) probiert. -> gleiches Problem...
dabei muss ich aber sagen, dass bis gestern abend noch die version 1.4 
auf dem µC war und der comport über einen usb2rs232 dongel emuliert 
wurde...

Es wäre eigentlich wichtig, dass der loader auch über den vario läuft. 
Da ich hier keinen anderen pc zur Verfügung habe.

Patrick

[Patrick (Gast)]

ups meinte natürlich sony vaio....

Patrick

[Tino (Gast)]

Ich hatte das Problem auch mal, ich glaube ich musste den Watchdog per 
fuse abschalten damit es richtig klappte. Müsste aber nochmal nachsehen 
ob es das war.

[Patrick (Gast)]

@Tino

Ich habs gleich mal probiert. Das Problem besteht jedoch weiterhin...

Grüße,
Patrick

[Tino (Gast)]

Hier mal ein Screenshot der Fusebits, damit hat es bei mir funktioniert.

[Peter D. (peda)]

Tino wrote:
> Ich hatte das Problem auch mal, ich glaube ich musste den Watchdog per
> fuse abschalten damit es richtig klappte. Müsste aber nochmal nachsehen
> ob es das war.

Mein Bootloader unterstützt keinen Watchdog. Der Watchdog muß 
abgeschaltet sein!

Man sollte den Watchdog nicht überschätzen.
Er ist ein völlig ungeeignetes Mittel, um seine eigenen 
Programmierfehler zu verschleiern.


Wer den Watchdog benutzt, sollte ihn ja leicht in den Bootloader 
einfügen können.


Peter

[Patrick (Gast)]

@Tino + Peter

Es klappt, super! Es lag wirklich am Wotchdog. Danke für die schnelle 
Hilfe.

Das einzige was noch komisch ist, ist dass ich ab dem 2ten mal den Rest 
manuell machen muss. Woran könnte das liegen?

Patrick

[Patrick (Gast)]

Ok, möchte mich für die dumme Frage entschuldigen. Wer lesen kann ist 
klar im Vorteil. Also vielen Dank nochmal für die Lösungsvorschläge!!

Patrick

[Tino (Gast)]

Ich weiß gerade nicht was du meinst, was musst du manuell machen?

[Vladimir Y. (Firma: INELT) (kabron)]

Hi Peter. Wonderfull product!
I'd tested it on Tiny45 with great success.
Now I designed DS2450 ADC emulator based on Tiny45 and 1wire bootloading 
is especially interesting for me. But in your 1wire variant you excluded 
TTL-RS232 level converter, so the data is inverted for 1wire case. It is 
not quite suitable. What I need to correct in the bootloader code to 
make it work with, say max232?

Thanks in advance,
Vladimir.

[Tobi (Gast)]

Hallo Peter,

ich war schon von deinem ersten Bootloader fasziniert.
Nutze diesen schon lange auf dem ATmega8.

Den aktuellen Bootloader würde ich gerne nutzen, da dieser noch kleiner 
geworden ist.

Zum aktuellen Bootloader habe ich allerdings eine Frage.
Wie kann es sein, das der neue Bootloader erst nach einem Reset 
funktioniert, wo doch der alte Bootloader nach einem Reset und einem
Power on funktioniert?

Danke für deine Hilfe,

Gruß Tobi

[Peter D. (peda)]

Tobi wrote:

> Wie kann es sein, das der neue Bootloader erst nach einem Reset
> funktioniert, wo doch der alte Bootloader nach einem Reset und einem
> Power on funktioniert?

Jedes Reset startet den Bootloader für ~0,3s

Ist der Resetpin aber als IO definiert, geht nur noch das Poweronreset.


Peter

[Benedikt Patt (Gast)]

Hallo,

ich versuche im Moment vergeblich den Bootloader auf einem Mega32 zum 
laufen zu bekommen. Im Anahng ist meine Konfiguration. Ich habe 
eigentlich nur die Frequenz auf 16000000 umgestellt und die 
Schnittstellen Pins auf die der Hardware UART gelegt. Das BOOTRST 
Fuse-Bit habe ich auf 0 gesetzt und die BOOTSZ Fuses auf 11 für 256 
Words. 10 für 512 Words habe ich auch schon getestet, weil ich da 
verschiedene aussagen gelesen habe.
Das FBoot Tool bleibt mit diesem Output stehen 'COM 1 at 115200 Baud:'. 
Dahinter dreht sich dann der Balken. Am RX-Pin vom Controller kann ich 
dann die eingehenden Daten mit dem Oszi sehen. Jedoch Antwortet der 
Controller nicht. Der Controller ist über einen MAX232 mit dem PC 
verbunden. woran könnte das liegen? Ich habe alles anhand des Artikels 
gemacht. Ich habe das Gefühl als würde der Bootloader nicht ausgeführt. 
Hat da Jemand noch eine Idee?

Danke im Voraus!
Gruß
Benedikt

[Peter D. (peda)]

@Benedikt

setz mal die Baudrate runter:
fboot17 -b9600


Schwingt Dein Quarz?

setz mal die Fuses auf internen Takt 8MHz


Peter

[Benedikt Patt (Gast)]

Hallo Peter,

vielen Dank für deine Antwort!
Leider bin ich erst gerade zum testen gekommen.
Ich habe sowohl die niedrigere Übertragungsrate als auch die 8MHz intern 
Quarzfrequenz getestet. beides funktioniert leider nicht.
Der Bootloader Antwortet einfach nicht.

Hast du vielleicht noch eine Idee?

Im Anhang ist die Hex-Datei die ich aus dem Mega32 wieder ausgelesen 
habe. Das sieht eigentlich gut aus, die Bootloader Adresse stimmt.

Gruß
Benedikt

[Benedikt Patt (Gast)]

Hallo Peter,

ich habe den (dummen) Fehler gefunden...
Es hatte nix mit dem Bootloader oder den Fuses zu tun.
Ich hatte einfach nur ein mini kleine Brücke von GND auf Reset gemacht. 
Dann kann der AVR natürlich nicht laufen ;-) Danke trotzdem für deine 
Antwort! Der Bootloader ist echt genial.

Gruß
Benedikt

[Stefan (Gast)]

Gibt es schon 'was Neues von der Delphi-Umsetzung des PC-Teils ?

[Walter (Gast)]

habe jetzt auch mal den Bootloader ausprobiert, funktioniert bis auf ein 
größeres Problem einwandfrei:
ich kann fboot.exe nur ein Mal verwenden, beim 2.Mal hängt es sich beim 
Versuch zu connecten auf (Ausgabe bis zum "Propeller", dieser wird aber 
nicht ein einziges Mal ausgegeben)
wenn ich Windows98 neu starte geht es wieder ein einziges Mal.
Wenn der Bootloader im AVR nicht aktiv ist und ich das Programm mit 
Tastendruck abbreche kann ich es immer wieder starten und es propellert

Was tun?

[Peter D. (peda)]

@Walter

Wie startest Du das Programm, DOS-Box oder im Explorer?

Bei der DOS-box mal mit den erweiterten Einstellungen spielen.

Hängt sich W98 richtig auf oder kannst Du die Task killen?

Benutzt Du ne echte RS232 oder nen USB-RS232 Dongle?

Welchen AVR benutzt Du?
Probier mal nen kleineren AVR (<64k).

Hast Du keinen Rechner mit XP drauf?


Peter

[holm (Gast)]

Ich opere hier mit einem ATMEGA324P herum und komme nicht zu Stuhle.

Mal eine Frage, was hat es mit mit folgenden Statement in m32.asm auf 
sich?

;Attention: BufferSize must fit perfectly into BootStart !
;e.g. BufferSize * 18 = BootStart

.equ    BufferSize      = (14*PageSize)

Die Pagesize ist 64 Bytes, so das bei 256 Bytes von 3f00 bis 3fff
da nur 4 hinen passen, also wie hängt das hier zusammen?

14*64 = 380 hex bzw. 896 dez Bytes.... ?

Gruß,

Holm

[Walter (Gast)]

@Peter

Hallo Peter,

>Wie startest Du das Programm, DOS-Box oder im Explorer?
ich hab eine Batchdatei mit dem Aufruf geschrieben die ich per 
Doppelklick starte. Jetzt habe ich es mal in der DOS Box probiert, da 
funktioniert es immer wenn ich den Aufruf per Hand eintippe, will ich 
aber die Batchdatei starten, kommt eine MSDOS Meldung:
ON oder OFF muss angegeben werden, was soll uns das sagen? Hat zwar nix 
mit deinem Programm zu tun aber vielleicht kennst du die Meldung ja.
Mit der DOS Box kann ich gut leben, würde mir aber wenn möglich die 
Tipparbeit sparen wollen ...

>Hängt sich W98 richtig auf oder kannst Du die Task killen?
nein, nur die Task hängt, lässt sich problemlos stoppen

>Benutzt Du ne echte RS232 oder nen USB-RS232 Dongle?
eine echte RS232

>Welchen AVR benutzt Du?
mega8

>Probier mal nen kleineren AVR (<64k).

>Hast Du keinen Rechner mit XP drauf?
nein, und beim nächsten Rechner werde ich mich Mal mit Linux 
herumschlagen ...

Grüße
Walter

[Peter D. (peda)]

holm wrote:
> Ich opere hier mit einem ATMEGA324P herum und komme nicht zu Stuhle.

Nimm das File für den M32 und ändere Die Portpins und das Include.


> Mal eine Frage, was hat es mit mit folgenden Statement in m32.asm auf
> sich?
>
> ;Attention: BufferSize must fit perfectly into BootStart !
> ;e.g. BufferSize * 18 = BootStart

Um die Schreibroutine einfach zu halten schreibt sie immer komplette 
Buffergrößen, auch wenn der letzte Buffer nur ein Word beinhaltet.
Es ist ja auch egal, was noch hinter dem Programm steht, wird ja nie 
ausgeführt.

Deshalb muß die Buffergröße ohne Rest in den Flash vor dem Bootloader 
passen. Wenn man das nicht beachtet, gibts ne Fehlermeldung, wenn man 
den Userflash komplett voll schreiben will.

Die Buffergröße muß natürlich ein Vielfaches der Pagegröße sein und 
kleiner als der SRAM (in Words).


Peter

[Peter D. (peda)]

Walter wrote:

> ich hab eine Batchdatei mit dem Aufruf geschrieben die ich per
> Doppelklick starte. Jetzt habe ich es mal in der DOS Box probiert, da
> funktioniert es immer wenn ich den Aufruf per Hand eintippe, will ich
> aber die Batchdatei starten, kommt eine MSDOS Meldung:
> ON oder OFF muss angegeben werden, was soll uns das sagen?

Zeig mal die Bat.

Häng mal den Befehl Pause ans Ende, kann sein, daß dem Programm die UART 
weggezogen wird, befor es fertig ist.


Peter

[Werner B. (Gast)]

Das ON oder OFF kommt von sicher einem "ECHO" ohne Text. Muss man 
"ECHO." schreiben (echo<Punkt>).


WIN9x macht eine DOS-Box die von einem BATCH geöffnet wird nicht 
automatisch zu. Da muss ein "EXIT" ans Ende.

[Walter (Gast)]

die Batchdatei enthält z.B. für Verify nur eine Zeile:
fboot /C1 /B2400 /Vdefault/hauszent.hex

ich habe festgestellt dass es ja jetzt V1.7 statt 1.4 gibt, es bleibt 
aber beim gleichen Effekt. Komisch dass ich scheinbar der einzige bin 
...??
Keiner mehr mit W98??

Pause bringt übrigens auch nix.

Ich habe jetzt mal fboot.c für Visual C 6.0 angepasst, das funktioniert 
einwandfrei. Falls es jemand gebrauchen kann bitte melden ...
Könnte auch V1.7 anpassen, aber da müsste ich dann die Segmentierung 
wieder zurückdefinieren :-(

@Werner
ECHO ist keins in der Batchdatei, nur der Aufruf von fboot.exe

Walter

[holm (Gast)]

Ich habe auch kein W98 mehr aber operiere auf einem W2K herum wenn ich 
schon irgend eine Form Dos benutzen muß ...

Ich weiß, das etwas mit dem fboot17 nicht stimmt, wenn ich das Help
aufrufe steht da das ich die any key pressen soll, aber beenden kann ich 
das nur wenn ich den Task von CMD abschieße. Konsoleeingaben sind 
irgendwie blockert.

Gruß,

Holm

[Fabian G. (kjion)]

Ich habe mal den C Code des PC-Teils mal nach Python portiert (siehe 
Anhang), da ich ihn aus einer Python GUI verwenden will.

Getestet bisher nur unter Ubuntu mit einem ATMega168, sollte aber auch 
unter Windows lauffähig sein.

Leider gibt es noch ein Problem mit dem CRC Check, scheinbar wird da 
irgendwas nicht korrekt berechnet, der AVR meldet jedenfalls immer einen 
Fehler obwohl die Daten korrekt geschrieben werden. CRC ist daher im 
Moment deaktiviert.

Grüße
Fabian

PS: Aktuellere Versionen gibt's dann unter folgender Adresse: 
http://www.kreatives-chaos.com/artikel/fastboot17-frontend-python

[Friedhelm Altmann (Gast)]

@Fabian

super das es jetzt auch einen Client für Linux für die 1.7 Version gibt.
Leider bekomme ich keinen connect. Der Bootloader futzt da es mit 
Fboot17.exe  klappt.

Ich verwende einen Mega162. Der Anschluss an den uC erfolgt über 
/dev/ttyS0 auf einen Max232. Habe alle Baudraten probiert. Daran sollte 
es auch nicht liegen da unter Win es mit 115k klappt.

Python ist nicht so mein Ding aber mir ist aufgefallen das der Mega162 
nicht bei den Targets in deinem Programm enthalten ist. Aber bis zu 
dieser Abfrage kommt er ja erst gar nicht.

Wäre nett wenn Du eine Idee hast wie ich einen connect bekomme.

@Peter Dannegger

Vielen Dank für den tollen Bootloader


Viele Grüße

Fred

[Friedhelm Altmann (Gast)]

So bin nun schon 2 schritte weiter.
In deinem Programm habe ich hinter den Passwortstring noch ein 0x00 
gehängt dann hatte ich den gewünschten connect.

# try to connect to the bootloader
  echo = False

  password += chr(0xff)
  password += chr(0x00)
  pos = 0

Und dann noch das target ergänzt so das dann auch die Daten übertragen 
wurden. Leider funktioniert das Programm im uC noch nicht :(


targets = {
      0x1e9007: "ATtiny13",
      0x1e910A: "ATtiny2313",
      0x1e9206: "ATtiny45",
      0x1e9205: "ATmega48",
      0x1e9307: "ATmega8",
      0x1e9403: "ATmega16",
      0x1e9406: "ATmega168",
      0x1e9502: "ATmega32",
      0x1e9609: "ATmega644",
      0x1e9802: "ATmega2561",
      0x1e9404: "ATmega162",
    }

Viele Grüße

Fred

[Friedhelm Altmann (Gast)]

So ich hab mal die beiden HEX-Files mit Ponyprog ausgelesen und 
verglichen
dabei habe ich festgestellt das der letzte Datenblock nicht mit 
übertragen wurde.

Leider habe ich wie gesagt von Python nicht viel Ahnung aber der Fehler 
liegt
zwischen den Zeilen 280-313. Vieleicht ist dies auch der Fehler warum 
das CRC nicht funktioniert.

Könnte das bitte mal jemand checken der was von Python versteht.

Vielen Dank

Fred

Hier die Programmzeilen 280-313

while True:
      # get one byte
      byte = hex_data[addr]

      # escape and send it
      if byte == self.ESCAPE or byte == 0x13:
        self.send(self.ESCAPE)
        byte |= self.ESC_SHIFT
      self.send(byte)

      bufferpos -= 1
      if bufferpos == 0:
        print "\b\b\b\b\b\b%05x" % (addr + 1),
        sys.stdout.flush()

        if not verify and self.receive(10) != self.CONTINUE:
          print " failed!"
          return 1

        bufferpos = self.buffersize

      addr += 1
      if addr == len(hex_data):
        print "\b\b\b\b\b\b%05x" % addr,

        # send the end-record (0xA5, 0x80)
        self.send_command(self.PROGEND)

        if self.receive(10) == self.SUCCESS:
          print " successful"
          return 0
        else:
          print " failed!"
          return 1

[Friedhelm Altmann (Gast)]

Hallo Fabian,

jetzt komm ich nicht mehr weiter da nicht nur am Ende sonder 
zwischendurch auch 3 Fehler aufgetreten sind.

Zur veranschulichung gabe ich das Ergebniss von diff mal als Anhang 
beigefügt.

Linke Spalte ist das HEX-File wenn ich mit fboot.exe übertrage und die 
rechte Spalte ist die Fehlerhafte.

Ich hoffe es hilft um den Fehler zu finden.


Viele Grüße

Fred

[Peter D. (peda)]

So, hier nochmal ein paar kleine Verbesserungen:

Es gibt jetzt nur noch ein Assemblerfile für alle AVRs.

Einfach vor dem gewünschten Include das ; entfernen, die UART-Pins 
auswählen, fertig.

Buffersize, Bootstart, Onewire werden nun automatisch ermittelt.


Als neue Funktion ist die Watchdogunterstützung hinzugekommen.
Der Watchdog wird auf 2s verlängert, wenn er enabled ist.
Das PC-Programm muß also mindestens alle 2s ein Byte senden.
Das sollte für das PC-Programm ausreichen.

Die Liste mit den Signaturen ist jetzt als extra File ausgelagert.
Man kann also dort noch neue AVRs eintragen.
Das DEF-File muß im gleichen Verzeichnis wie die EXE stehen.


Am Protokoll hat sich nichts geändert.


Peter

[Friedhelm Altmann (Gast)]

Hallo Fabian,

ich hoffe Du hast nichts dagegen das ich in deinem Programm 
rumgewurschtelt habe.

Jetzt läuft es bei mir endlich einwandfrei.

In Zeile 77 mußte ich ne kleine Pause einbauen sonst gibts kein connect.

Den sys.stdout.flush() beim Bufferende musste ich bei mir auch 
rauswerfen da sonst Daten fehlen

Der eigentliche Fehler ist jedoch in Zeile 285ff

if (byte == self.ESCAPE) or (byte == 0x13):

Da Peter mit einer unsigned char Variablen arbeitet kommt dann
beim byte |= self.ESC_SHIFT unter Python ein ganz anderer Wert raus als 
unter C.

Ich hoffe du entwickelst das Programm noch weiter da es wiklich Prima 
ist.

so und nun einen guten Rutsch ins neue Jahr

vom Fred

[Michael (Gast)]

Hallo Peter,

ich habe den Bootloader in v1.8 auf meinen Mega644 gespielt. Das hat 
auch alles so weit funktioniert, nur leider startet das 
Anwendungsprogramm nach dem flashen nicht.
Hast du da einen Tipp für mich?

[Tobias (Gast)]

Hallo,

ich habe ebenfalls grade den FBOOT18 auf einen ATmega8 gespielt.
Funktioniert alles einwandfrei.

Danke.

Kann mir evtl. jemand mit den Look Bits weiterhelfen?
Welche kann ich setzten, damit der Bootloader noch funktioniert?
Welche dürfen auf keinen Fall gesetzt werden?
Ich habe mir zwar das Datenblatt schon angesehen, steige aber nicht so 
ganz durch.

Ich würde gerne den Bootloader und die Aplikation gegen Auslesen 
schützen.

MfG Tobias

[Bingo (Gast)]

@Peter D

Peter ich habe deiner version 18 und die version 17a von AvrFreaks 
compared. (Nur die teile vie lauft am Pc). Ich kan keiner differenz 
sehe.

Ist das korrekt das die PC programm , ist die selber im 17a und 18 ??

Und das alle verbesserungen ist im die neye AVR target files layout ??

Dan funktioniert meiner devcpp port von 10.11.2007 auch (oder ??)

Danke fur die bootloader

mfg
Bingo aus Dänemark

[Peter D. (peda)]

Bingo wrote:

> Ist das korrekt das die PC programm , ist die selber im 17a und 18 ??

Ja, die Versionen sind gleich.


> Und das alle verbesserungen ist im die neye AVR target files layout ??

Auch da ist alles gleich, nur die Watchdogunterstützung ist 
hinzugekommen.
Und einige Vereinfachungen, um andere AVRs einzubinden.


Peter

[Daniel M. (usul27)]

Ich hätte noch eine PC-Software in Java. Diese unterstützt KEIN OneWire 
und ist nur mit Version 1.7 getestet.
Aber vielleicht ist das ja für den einen oder anderen interessant.

Der Code findet sich in der PC-Software meines Motorcontrollers:
http://www.matuschek.net/motorsteuerung-software/

Viele Sachen sind dort sehr einfach gehalten, da gibt es sicher noch 
Potential für Verbesserungen. Aber es funktioniert prinzipiell...

[Friedhelm Altmann (Gast)]

Hallo Assembler Cracks,

Bräuchte mal nen Tip wie ich es machen könnte das der Bootloader mit 
einem Max 485 zusammenarbeitet.

Im Anhang ist mein Versuch die uart.inc anzupassen aber es klappt 
einfach nicht :(

SCS_PORT und SCS sind in m16.asm definiert und sollen Senden und 
Empfangen entsprechend umschalten.

Aber der SCS Pin bekommt einfach keine 5 Volt

Ich habe in C ein Testprogramm geschrieben das die Daten vom RS485 
abholt und auf einen Disolay ausgibt. Und es werden Peda+0xFF empfangen 
sodas der Bootloader ja eigentlich antworten sollte.

Kann da bitte mal jemand mit Assembler Erfahrung schauen woran es liegen 
könnte.

;----------------------------------------------------------------------- 
--
;                               Port definitions
;----------------------------------------------------------------------- 
--
.equ    STX_PORT        = PORTD    ;TX
.equ    STX_DDR         = DDRD
.equ    STX             = PD1

.equ    SRX_PIN         = PIND    ;RX
.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0

.equ    SCS_PORT        = PORTD    ;RS485 Steuerpin
.equ    SCS_DDR         = DDRD
.equ    SCS             = PD2
;----------------------------------------------------------------------- 
--
.include "fastload.inc"
;----------------------------------------------------------------------- 
--

Vielen Dank

Fred

[Ludger (Gast)]

Hallo *,

weiss jemand, warum beim Versuch den Bootloader fuer den ATMega1281 zu 
assemblieren folgender Fehler ausgegeben wird, obwohl nach einem ersten 
Dateivergleich von m1281def.inc und m2561def.inc kein Fehler 
offensichtlich ist ?

--AUSGABE beim Assemblieren:
AVRASM: AVR macro assembler 2.1.2 (build 99 Nov  4 2005 09:35:05)
Copyright (C) 1995-2005 ATMEL Corporation

bootload.asm(38): Including file 'C:\Programme\Atmel\AVR 
Tools\AvrAssembler2\Appnotes\m1281mdef.inc'
bootload.asm(62): Including file 'fastload.inc'
fastload.inc(9): Including file 'fastload.h'
fastload.h(2): Including file 'compat.h'
fastload.h(3): Including file 'protocol.h'
FATAL ERROR: Too deeply nested macro calls(16)

Assembly failed, 0 errors, 0 warnings
--Ende der Ausgabe:


Gruss,
Ludger

[Peter D. (peda)]

Ludger wrote:
> weiss jemand, warum beim Versuch den Bootloader fuer den ATMega1281 zu
> assemblieren folgender Fehler ausgegeben wird, obwohl nach einem ersten
> Dateivergleich von m1281def.inc und m2561def.inc kein Fehler
> offensichtlich ist ?

Probiers mal mit der Datei im Anhang.


Peter

[Andreas K. (andie)]

Friedhelm Altmann wrote:
>
> Aber der SCS Pin bekommt einfach keine 5 Volt
>

Hast du den Pin als Ausgang gesetzt?
z.B.: im File FASTLOAD.H im macro IOPortInit die Zeile

sbi SCS_DDR, SCS

einfügen.

Gruß andie.

[Ludger (Gast)]

@Peter

Danke fuer die prompte Antwort. Assemblieren tuts es jetzt einwandfrei. 
Allerdings habe ich bei meinem 1281er noch nicht geschafft den 
Bootloader zur Kommunikation mit dem PC zu bringen. Beim Testen habe ich 
dann vermutlich versehentlich die Fuses verstellt und nachdem ich sie 
mit externem Takt wieder auf die Defaultwerte gesetzt habe, tut sich gar 
nichts mehr. Aber das ist eine andere Baustelle.

Bei meinem 644er funktioniert alles tadellos.

Gruss,
Ludger

[Friedhelm Altmann (Gast)]

@ Andreas Kasper

macro  IOPortInit
  sbi  SRX_PORT, SRX
  sbi  STX_PORT, STX
  sbi  STX_DDR, STX
  cbi  SCS_PORT, SCS
  sbi  SCS_DDR, SCS
.endmacro

Ja das habe ich.

Jedoch nicht bei ONEWIRE weil habe ja 2 bzw. 3 Leitungen und mir auch 
nicht ganz klar ist wie ONEWIRE funktioniert

Sind den die Ändrungen in der uart.inc so OK?

Bin mir nicht so sicher ob nicht eine kleine Pause zwischen dem 
Umschalten von RX -> TX erfolgen muss?

Die Übertragungsrate ist momentan noch auf 19200 Baud eingestellt und 
ist wohl unkritisch.

Vieleicht noch eine Idee?

Viel Grüße

Fred

[Peter D. (peda)]

Friedhelm Altmann wrote:

> Jedoch nicht bei ONEWIRE weil habe ja 2 bzw. 3 Leitungen und mir auch
> nicht ganz klar ist wie ONEWIRE funktioniert

Das ist ein Wired-OR (verdrahtetes Oder).
Der High-Pegel ist dominant, d.h. high wird immer gelesene, wenn der PC 
high sendet "ODER" der AVR.

Dabei sendet der PC über einen Widerstand, damit der AVR das 
überschreiben kann. Der AVR simuliert einen open-drain Ausgang, d.h. 
kann nur high senden.
Damit nun die Quittung gelesen kann, muß der AVR sich auf die 
Startflanke des 0xFF vom PC synchronisieren und dort sein Byte einfügen. 
Solche Timings sind natürlich bei RS-485 nicht möglich.


Bei RS-485 brauchst Du eine spezielle Treiber-DLL, die das Signal für 
die Richtungsumschaltung exakt synchron zum Senden erzeugt.

Das Byte 0xFF nach dem Paßwort darf nicht gesendet werden, sondern es 
muß dann für 2 Bytezeiten auf Empfang umgeschaltet werden, ehe der 
nächste Versuch gestartet wird.

Du mußt also in jedem Fall die PC-Software umschreiben, die kann 
definitiv nicht mit RS-485 zusammmenarbeiten!


Peter

[Friedhelm Altmann (Gast)]

Hallo Peter,
hallo Andi

erstmal vielen Dank für die Antwoten.

habe meinen Fehler nun gefunden die Sendefunktion war zu langsam für den 
Bootloader weil ich jedes Zeichen einzeln gesendet habe und immer 
zwischen TX und RX umgeschaltet habe.

Jetzt bekomme ich die gewünschte 0xA6 als Antwort.

Mit der PC Software das war mir klar. Mein Ziel ist es einen RS-485 Bus 
mit mehreren Mega 16 und einem Mega 162 als Bindeglied zwischen PC und 
RS-485 Bus zu realisieren.

Der Mega 162 soll dann quasi die PC Software beinhalten um die Mega 16 
mit den Updates zu versorgen.

Hoffe mal das ich den Rest dann auch noch hinbekomme.

Viele Grüße

Fred

[Andreas (Gast)]

Hat das jemand bereits auf einen ATmega als >Programmer< umgesetzt ?
Mir schwebt da ein Mega mit einem SD-Kartenslot vor, in einem Gehäuse 
ähnlich einem Tastkopf; so dass man den Code später mit einem sehr 
portablen Programmer lokal injizieren kann.

[Andreas K. (andie)]

Peter Dannegger wrote:
>
> Du mußt also in jedem Fall die PC-Software umschreiben, die kann
> definitiv nicht mit RS-485 zusammmenarbeiten!
>

Hallo Peter,

könntest du nicht eine Version der PC-Software für RS-485 kompilieren?
Es wären dir sicher einige dafür dankbar ;-)
Auf der µP-Seite sollte es dann kein Problem mehr sein, da der Treiber 
immer auf Empfang ist und nur zum Senden kurz umgeschaltet werden muss.

Gruß andie.

[Peter D. (peda)]

Andreas Kasper wrote:

> könntest du nicht eine Version der PC-Software für RS-485 kompilieren?

Ich habe ja keine RS-485 Karte an meinem PC und auch nicht die 
notwendige Treiber-DLL.

Ich habe nur die ganz normale RS-232 (COM), wie jeder PC.

Ich weiß also nicht, wie man es machen müßte und kann es auch nicht 
testen.


Peter

[gast (Gast)]

für 485 müsste es doch auch gehen.....

die meisten 485-USB machen doch das automatisch und verhalten sich wie 
eine 232 schnittstelle , oder??
auf ATmegaseite brauch er ja nur auf empfang stehen

[Ludger (Gast)]

@Peter

nachdem ich meinen 1281'er wieder zum Leben erweckt habe funktioniert 
der Bootloader nun auch dort.
Herzlichen Dank fuer die neue FASTLOAD.H

Ludger

[Karsten D. (karstendonat)]

@Ludger

Ich versuch mich auch gerade an nem 128er. Kannst du bitte mal deine 
m128.asm posten? Irgendwie will der noch nicht so wie ich.

Danke.

Karsten

[Karsten D. (karstendonat)]

Hat sich erledigt. Hatte beim löten nen Draht in der TX Leitung gelötet 
weil ich dachte da is was nicht richtig angeschlossen. Hatte aber nur am 
flaschen Pin des FT232RL geklingelt. Draht weg und es geht g

Aber man lernt ja aus seinen Fehlern.

Karsten

[Ludger (Gast)]

Hallo *,

ich habe den fboot18 von Peter mal nach WinAVR uebersetzt.

@Peter
Ich wollte zunaechst das ganze Projekt konvertieren, bin jedoch mangels 
WinAVR Assembler Kenntnissen an der Universalitaet deines Bootloaders 
gescheitert. Dann habe ich alles, was mein 1281'er benoetigt in eine 
Datei kopiert und das dann konvertiert. Ich hoffe Du bist nicht allzu 
veraergert :-)

Herzliche Gruesse,
Ludger

[Bootloaderneuling (Gast)]

Hi, für vollwertigen ISP-Ersatz müsste mir das Teil auch den EEPROM mit 
meinen Daten beschreiben können! Ist diese Funktion vielleicht geplant?

[Karsten D. (karstendonat)]

Also bis zur Version 17 hat die Hilfe noch die Möglichkeit für EEProm 
angezeigt. Probiers mal, wenn du hinter den Flash mit Komma getrennt den 
EEProm schreibst.

Sonst wäre es ja noch möglich, erst ein Dummy Programm rüber zuladen das 
den EEprom schreibt. Notfalls wäre es auch möglich diese Kombination in 
der IDE einzubaun.

Der Bottloader Support ist grad in der Testfase in der IDE (noch mit 
Version 17). Wenn mein aktuelles Projekt fertig hab gibts in den 
nächsten Tagen dann ne Version die nach dem compilieren automatisch die 
Software über den Bootloader brennt. (und auch den entsprechenden 
Bootöoader erzeugen kann)

Karsten

[Falk B. (falk)]

@ Peter Dannegger (peda)

>> könntest du nicht eine Version der PC-Software für RS-485 kompilieren?

>Ich habe ja keine RS-485 Karte an meinem PC und auch nicht die
>notwendige Treiber-DLL.

>Ich habe nur die ganz normale RS-232 (COM), wie jeder PC.

>Ich weiß also nicht, wie man es machen müßte und kann es auch nicht
>testen.

Doch, nimm einen FTDI232RL. Gibt billig bei Angelika und der hat das 
gesuchte TXEN Signal standardmässig dabei, muss nix speziell 
programmiert werden, einfach nur über virtuellen COM-Port Daten senden.

MfG
Falk

[Bingo (Gast)]

@Peter D

Hier ist einer source im TurboC , für 9bit kommunikation.

mfg
Bingo

[Peter D. (peda)]

Falk Brunner wrote:

> Doch, nimm einen FTDI232RL.

Hab ich nicht.

Würde ja nichts nützen, hab auch kein AVR-Board mit RS-485.


> Gibt billig bei Angelika

Schön.

Codesammlung heißt doch nur: "ich hab mal was programmiert und stelle es 
rein, so wie es ist."

Wer RS-485 benutzt, kann gerne Bootloader und PC-Programm abändern und 
hier reinstellen.



Peter

[Ludger (Gast)]

Hallo *,

ich besitze weder den Borland noch den Dev-C++. Habe aber schon lange 
ein cygwin mit GCC und MINGW. Damit habe ich Bingos fboot17a uebersetzt.
Sourcen, Executable und makefile liegen bei.

Gruss,
Ludger

[Raik A. (raik)]

Hi,

erst einmal auch von mir vielen Dank für das schöne Projekt.

Auch ich habe Probleme in der Programmversion 1.8 bei der Übertrageung 
von eep- Dateien in den EEProm.
In der Version 1.7 konnten diese Dateien beispielsweise mit
fboot17 /C1 /PFtest.hex,Etest.eep
übertragen werden.
Leider habe ich in der Version 1.8 trotz veränderter Syntax keinen 
Erfolg damit:
fboot18 /C1 /Ptest.hex,test.eep

Wurde die Übertragung der eep- Dateien aus dem Code entfernt?

Grüße
Raik

[Peter D. (peda)]

Raik A. wrote:

> Wurde die Übertragung der eep- Dateien aus dem Code entfernt?

Sie war nie drin, ist nur ein Fehler im Hilfetext gewesen.

Ich habs noch nie gebraucht.

Den EEPROM benutzt man ja dazu, Werte zu speichern, die noch nicht zur 
Programmierzeit bekannt sind.

Wenn ich den EEPROM benutze, dann mache ich einen Gültigkeitstest über 
die Daten und schreibe bei nem Fehler default Werte rein.

Oder es ist eine Kalibration nötig, dann ergibt es keinen Sinn, 
irgendwas reinzuschreiben.


Peter

[Bootloaderneuling (Gast)]

"Den EEPROM benutzt man ja dazu, Werte zu speichern, die noch nicht zur
Programmierzeit bekannt sind"

Nun dem muß ich mal ganz entschieden widersprechen. Mein EEPROM dient 
z.B. der Initialisierung des RAMs durch ein einfaches Copy und so wäre 
es durchaus sinnvoll den EEPROM auch vorab beschreiben zu können. Nun 
gut, ist halt nicht drin- aber eben deshalb ist es leider auch kein 
vollwertiger ISP-Ersatz.

[Peter D. (peda)]

Bootloaderneuling wrote:
> Nun dem muß ich mal ganz entschieden widersprechen. Mein EEPROM dient
> z.B. der Initialisierung des RAMs durch ein einfaches Copy

Den RAM initialisiert man üblicher Weise aus dem Flash, macht zumindest 
jeder C-Compiler so.

Und das Copy Flash->RAM geht auch viel einfacher und schneller, 2 
Pointerregister mit Autoincrement ("LPM r16,Z+", "ST Y+,r16").


> aber eben deshalb ist es leider auch kein
> vollwertiger ISP-Ersatz.

Du vergleichst Äpfel mit Birnen.

Es ist ein Bootloader, d.h. er kann auch keine Fuses ändern.
Dafür kann er aber noch bei abgeschaltetem Resetpin flashen, was ISP 
nicht kann.


Peter

[JojoS (Gast)]

hat hier vielleicht schon jemand eine Portierung des FBoot nach .NET 
probiert? Ich möchte einen Bootloader in ein kleines 
Applikationsframework integrieren und da ungern ein externes Tool für 
aufrufen. Bisher hatte ich mit dem Fleury Bootloader gearbeitet, aber 
dieser hier ist schön kompakt. Gibts zu dem Protokoll evtl. etwas Prosa 
oder muß ich alles aus dem Quelltext rauslesen?

[Peter D. (peda)]

JojoS wrote:
> dieser hier ist schön kompakt. Gibts zu dem Protokoll evtl. etwas Prosa
> oder muß ich alles aus dem Quelltext rauslesen?

http://www.mikrocontroller.net/attachment/27570/Bootloaderprotokoll.txt


Peter

[JojoS (Gast)]

Danke, das habe ich in den wenigen hunderten Beiträgen übersehen... Der 
Link könnte auch in den Wiki Beitrag zu deinem Bootloader rein.

[Dirk S. (disc)]

Hallo JoJoS,
ich hab den fboot nach C# konvertiert. Bein Interesse kurze PM an mich, 
ich könnte Dir den Code dann zusenden. Ist allerdings direkt aus der 
Anwendung "herausgerissen" und mäßig kommentiert. Ich denke aber, man 
sollte damit zurechkommen können.

Gruß

Dirk

[Thomas V. (thomas_v)]

@Dirk:

Könntest Du den Code bzw. das Projekt evtl. hier posten - ich wäre 
nämlich auch an einer Umsetzung in c# interessiert.

Gruß, Thomas

[Dirk S. (disc)]

Hallo Leute,
ich habe grade mal eben den Bootloader Code aus meiner Anwendung 
herauskopiert und eine eigene kleine Anwendung daraus gemacht.

Der Aufruf des Bootloaders müsste aus dem Code vom OK-Button ersichtlich 
sein.

Der Bootloader ist von mir nur mit einem MEGA644 im Zweidrahtmodus 
getestet. Kleinere Probleme gab es mit der ersten CRC-Prüfung beim 
Anmeldevorgang.

Über Resonanz dazu, Erfolgs-, Fehlermeldungen, Testergebnisse oder 
Fragen würde ich mich freuen.

Gruß

Dirk

[Jojo S. (Gast)]

danke, das sieht doch sehr brauchbar aus.

[Dirk S. (disc)]

Hallo Leute,
ein kleiner Nachtrag zum C#/.NET Bootloader.

Es gab noch ein kleines Problem mit eingebauten Warteschleifen. Das 
konnte unter Umständen zum Blockieren der Anwendung führen. Auf meinem 
Entwicklungsrechner (mit Zweikernprozessor) trat dieses Problem nicht 
auf.

Das Projekt benötigt .NET Framework 2.0 und Visual C# 2008. Für die 2005 
Version einfach ein neues Projekt anlegen und die Source-Dateien manuell 
hinzufügen.

Gruß

Dirk

[Jojo S. (Gast)]

das Performanceproblem konnte ich nachvollziehen, es hat mir mein 
Notebook zum Glühen gebracht :-) Mit dem Sleep ist es aber ok und der 
Upload liegt im Sekunden Bereich.
Das Senden geht nochmal doppelt so schnell wenn man die Zeichen 
Blockweise sammelt und sendet. Ich verstehe nur noch nicht das 
Echo-Lesen in der Send-Methode, ist das für die one-wire Lösung? Das 
macht dann Probleme beim blockweisen Senden.
Gegenüber dem Original von Dirk habe ich noch den Buffer aus der Send 
Methode genommen damit der nur einmal alloziert wird.

       private byte[] acBuffer = new byte[1];

       private void Send(System.Byte vcByte)
       {
            if(this.Echocount != 0)
            {
                if(this.Echocount > 1)
                    this.Receive(0);    // remove echo
                this.Echocount++;
            }
            acBuffer[0] = vcByte;
            this.MySerialPort.Write(acBuffer, 0, 1);
            this.UpdateCrc(vcByte);      // calculate transmit CRC
       }

[Dirk S. (disc)]

Hallo Johannes,
das mit dem Herausziehen der Puffer-Allokierung wird glaube ich nicht 
wirklich messbar etwas bringen. Das serielle Senden wird wohl 
verhältnismäßig viel mehr Zeit brauchen.

Die meisten Funktionen der Laderoutinen hab ich mehr oder weniger direkt 
vom fboot übernommen. Wenn da Unklarheiten sind, kannst Du auch zum 
Vergleich einen Blick in den Original-Sourcecode werfen. Das ist die 
Datei fboot18.c in der Bootloader Distribution.

Gruß

Dirk

[Jojo S. (Gast)]

ok, das Bufferallozieren im Send brachte wirklich nichts messbares. Aber 
das blockweise Senden bringt hier schon bei knapp 6kB 3,3s gegenüber 
8,9s (@115200 BPS, incl. Verify, wo die Daten ja nochmal 
rübergeschaufelt werden). Die Änderungen sind minimal, pappe ich mal 
hierdran. Nur die Sache mit Echo ist noch nicht ganz klar. Wenn es nur 
für one-wire gebraucht wird könnte mit man 'if (onewire)' zwischen den 
Send Versionen umschalten. Oder kann man trotzdem erst alles am Stück 
senden und danach mit einem Receive über Blocksize die Echos wegwerfen?

Änderung in ProcessFile():

        byte[] tmpbuffer = new byte[Buffersize*2];      // tem. 
Sendbuffer, size = max for data+ESC
        int n=0;
         for(i = this.Buffersize, addr = 0; ; addr++)
         {
            switch(d1 = this.Data[addr])
            {
               case ESCAPE:
                  goto case 0x13;
               case 0x13:
                  //this.Send(AVRBootLoader.ESCAPE);
                  tmpbuffer[n++] = AVRBootLoader.ESCAPE;
                  UpdateCrc(AVRBootLoader.ESCAPE);      // calculate 
transmit CRC
                  d1 += ESC_SHIFT;
                  goto default;
               default:
                  //this.Send(d1);
                  tmpbuffer[n++] = d1;
                  UpdateCrc(d1);      // calculate transmit CRC
                  break;
            }

            if(--i == 0)
            {
                if (n > 0)
                {
                    MySerialPort.Write(tmpbuffer, 0, n);
                    n = 0;
                }

                if (!bVerify && this.Receive(TIMEOUTP) != 
AVRBootLoader.CONTINUE)
               {
                  this._ErrorMessage = String.Format("Programmieren bei 
Adresse {0} fehlgeschlagen", addr);
                  return 1;
               }
               i = this.Buffersize;
            }

            if(addr == lastaddr)
            {
                if (n > 0)
                {
                    MySerialPort.Write(tmpbuffer, 0, n);
                    n = 0;
                }


Die Zeitmessung habe ich in das frmBootloader integriert:

      private DateTime ProgrammingStartTime;

      private void ProgrammingThread()
         {
         .....
         // Programmieren
            ProgrammingStartTime = DateTime.Now;

         // Progress-Event anmelden

....
      private void ProgrammingThreadFinished()
         {
         if(this.InvokeRequired)
            {
            this.Invoke(new 
ProgrammingThreadFinishedHandler(this.ProgrammingThreadFinished));
            }
         else
            {
                TimeSpan elapsedTime = DateTime.Now - 
ProgrammingStartTime;

            this.txtDateiname.Enabled = true;
            this.cmdDatei.Enabled = true;
            this.cmdOK.Visible = true;
            this.cmdCancel.Visible = false;
            this.cmdSchliessen.Enabled = true;
            this.Cursor = Cursors.Default;

            if(this.MyAVRBootloader.Success)
               Util.MyUtils.MessageInfo(String.Format("{0} Bytes 
erfolgreich geschrieben in {1:F1} s!",
                   this.MyAVRBootloader.BytesWritten,
                   elapsedTime.TotalMilliseconds/1000));
            }
         }

[Jojo S. (Gast)]

an PeDa:
der Assembler hatte gemeckert beim includieren der m32def.inc für den 
ATMega32. Die Option Watchdog benutzt das Register WDCE das der m32 
nicht kennt. Habe ich die Option erstmal deaktiviert damit, läuft es 
durch.

[Jojo S. (Gast)]

ich habe in die compat.h folgendes eingetragen:

.ifndef WDCE
.equ  WDCE  = WDTOE
.endif

damit klappt der Watchdog für den Mega32 (und andere hoffentlich auch).

[Jojo S. (Gast)]

muss nochmal nerven und zurückrudern: die Watchdog Option klappt noch 
nicht: es lässt sich jetzt übersetzen aber funktioniert nicht (verwende 
das fboot18.zip).

erstmal in Watchdog.inc:

;------------------------------  check, if watchdog active ----------------
  wdr
  xin  a0, WDTCR
  ori  a0, 1<<WDCE^1<<WDP2^1<<WDP1^1<<WDP0  ; change enable
  xout  WDTCR, a0
  andi  a1, ~(1<<WDE^1<<WDP2^1<<WDP1^1<<WDP0)  ; 2s
  xout  WDTCR, a0
;-------------------------------------------------------------------------

wird erst Register a0 eingelesen und ausgegeben, dann mit andi a1 
bearbeitet aber wieder a0 ausgegeben -> effektiv wird als nur zweimal 
der gleiche Wert in WDTCR geschrieben.
Aber zum WD einschalten müsste doch zuerst WDE gesetzt werden? Und wenn 
der WD aktiv ist müsste der Bootloader endlos warten statt die Zeit 
'BootDelay' abzuwarten? Fragen über Fragen...

[David H. (davherrmann)]

Hallo,
ich hab noch ein paar Fragen zum Protokoll.
Ich hab die Kommunikation zwischen einem Atmega8 mit dem Bootloader 
Version 18 und dem PC-Programm fboot18 mehrmals mitgeloggt.
Ja, wenn das PC-Programm peda + FF zum Verbinden sendet, und ich dann 
den MC anschalte, sendet dieser ein FF 03 08 FF 03 0B FE..
Warum ? Muss ich das im PC-Programm beachten ?

Danach sendet das PC-Programm weiter die Kennung, bis der MC mit A6 
antwortet. Allerdings sendet er das A6 über 100 mal, dann sendet er AA 
(also SUCCESS) und erst dann sendet das PC-Programm wieder Befehle. Muss 
ich jetzt auf das AA warten oder kann ich schon nach dem ersten A6 
Befehle senden ?

Ok, dann kommen die Befehle CHECK_CRC, REVISION, SIGNATURE, BUFFSIZE, 
USERFLASH, CHECK_CRC und PROGRAM. Nach dem Programmieren nochmal ein 
CHECK_CRC.

Jetzt sendet das PC-Programm nochmal ein A5 80 A5 A5 A5..den Befehl gibt 
es ja eigentlich nicht. Der MC antwortet auch mit A7 FF 01 F9 00, also 
BADCOMMAND. Ich muss diesen Befehl aber nicht senden, oder ?

Vielen Dank :-)

Grüße
David

[Peter D. (peda)]

Johannes Stratmann wrote:

>   andi  a1, ~(1<<WDE^1<<WDP2^1<<WDP1^1<<WDP0)  ; 2s

Ja, das muß natürlich a0 heißen.
Beim 2. Schreiben muß ja das WDCE gelöscht sein.


Peter

[Peter D. (peda)]

David Herrmann wrote:
> Hallo,
> ich hab noch ein paar Fragen zum Protokoll.
> Ich hab die Kommunikation zwischen einem Atmega8 mit dem Bootloader
> Version 18 und dem PC-Programm fboot18 mehrmals mitgeloggt.
> Ja, wenn das PC-Programm peda + FF zum Verbinden sendet, und ich dann
> den MC anschalte, sendet dieser ein FF 03 08 FF 03 0B FE..
> Warum ? Muss ich das im PC-Programm beachten ?

Ich hab das Programm ohne Logger entwickelt, daher sind mir die 
zusätzlichen Zeichen nicht aufgefallen.
Ich hab jetzt keine Idee, wo die herkommen.
Wichtig ist ja nur, daß irgendwann das A6 kommt.
Welchen AVR benutzt Du?


> Allerdings sendet er das A6 über 100 mal

Ja, das liegt an Windows, das puffert die UART-Ausgabe (4096 Byte).

D.h. das Bytesenden kommt zurück, aber in Wirklichkeit wird das Byte 
erst viel später gesendet.
Der Windowspuffer wird quasi mit Paßwörtern geflutet und dann muß er 
erst leer gesendet werden.
Für echte Windowsprogrammierung sollte es aber eine Flush Funktion 
geben, die erst zurückkommt, wenn das letzte Byte wirklich gesendet 
wurde.


>, dann sendet er AA
> (also SUCCESS) und erst dann sendet das PC-Programm wieder Befehle. Muss
> ich jetzt auf das AA warten

Ja.


> Jetzt sendet das PC-Programm nochmal ein A5 80 A5 A5 A5.

Das dient nur dazu, falls sich die Kommunikation verhakt und der AVR 
noch in der Flashschreiberoutine stecken sollte, diese abzubrechen 
(A5,80).


Peter

[Jojo S. (Gast)]

ist immer noch unklar: der WD ist doch nur aktiv wen WDE gesetzt ist? 
Vielleicht habe ich den Sinn der WD Option nicht verstanden. Ich denke 
es soll nach der WD Zeit ein Reset ausgeführt werden, aber der kommt so 
ja vorher durch das Timeout von 0,3s ?

[David H. (davherrmann)]

Hallo,
ich verwende einen Atmega8, hab ich im Post eigentlich schon geschrieben 
;-)
Danke, Deine Antworten helfen mir aber schon weiter.

Grüße
David

[Peter D. (peda)]

Johannes Stratmann wrote:
> ist immer noch unklar: der WD ist doch nur aktiv wen WDE gesetzt ist?
> Vielleicht habe ich den Sinn der WD Option nicht verstanden. Ich denke
> es soll nach der WD Zeit ein Reset ausgeführt werden, aber der kommt so
> ja vorher durch das Timeout von 0,3s ?

Der Bootloader braucht den Watchdog nicht, er soll nur den Watchdog 
unterstützen,

D.h. wenn die Applikation ihn verwendet, trotzdem noch ein Flashen 
ermöglichen.

Oder die Applikation startet den Bootloader von sich aus per 
Watchdogreset.


Peter

[Jojo S. (Gast)]

Peter Dannegger wrote:
> Der Bootloader braucht den Watchdog nicht, er soll nur den Watchdog
> unterstützen,

danke, dann ist das klar.

> Oder die Applikation startet den Bootloader von sich aus per
> Watchdogreset.

so mache ich das jetzt auch, ich hatte zuerst den Proz. Takt nicht 
angepasst, bei default 8Mhz und vorhandenen 12Mhz war die Wartezeit nach 
dem Reset zu kurz. Jetzt läuft alles wie im Kino, auch mit der .Net 
Version von D. Schmidt.

[Thomas (Gast)]

Hallo,
ich hab das mal nach dem PDF versucht für einen ATMEGA8 zu komplilieren, 
bekomme aber Massen an Fehlern heraus. Ich hab die Originaldateien aus 
dem ZIP verwendet ohne etwas zu ändern, dann die include und die 
Assembler EXE dazu und heraus kommt:

C:\temp>avrasm32 -fI m8.asm
AVRASM: AVR macro assembler version 1.74  (Dec 16 2003 11:49:32)
Copyright (C) 1995-2003 ATMEL Corporation

Creating   'm8.hex'

Assembling 'm8.asm'
Including  'm8def.inc'
Including  'fastload.inc'
Including  'compat.h'
Including  'fastload.h'
Including  'abaud.inc'
abaud.inc(25) : error : Unknown instruction opcode
abaud.inc(32) : error : Unknown instruction opcode
Including  'password.inc'
Including  'checkcrc.inc'
Including  'verify.inc'
Including  'message.inc'
Including  'progmega.inc'
Including  'uartcrc.inc'
uartcrc.inc(7) : error : Unknown instruction opcode
uartcrc.inc(10) : error : Unknown instruction opcode
uartcrc.inc(21) : error : Unknown instruction opcode
uartcrc.inc(46) : error : Unknown instruction opcode
uartcrc.inc(57) : error : Unknown instruction opcode
uartcrc.inc(60) : error : Unknown instruction opcode
m8.asm(119): warning: A .db segment with an odd number of bytes is 
detected. A z
ero byte is added.
m8.asm(14) : error : Symbol is already defined by the .EQU directive
fastload.h(81) : error : Undefined variable referenced
fastload.h(88) : error : Syntax error
fastload.h(90) : error : Syntax error
fastload.h(92) : error : Syntax error
fastload.h(94) : error : Syntax error
fastload.inc(17) : error : Relative branch out of reach
fastload.inc(74) : error : Relative branch out of reach
fastload.inc(120) : error : Syntax error
fastload.inc(121) : error : Syntax error
fastload.inc(122) : error : Syntax error
fastload.inc(123) : error : Syntax error

Assembly complete with 20 errors

Deleting   'm8.hex'
Kennt jemand das Problem? Bin nicht sooo firm mit Assembler.
Danke sehr vorab, Gruss
Thomas

[Peter D. (peda)]

Thomas wrote:
> C:\temp>avrasm32 -fI m8.asm
> AVRASM: AVR macro assembler version 1.74  (Dec 16 2003 11:49:32)

2003 is schon ne Weile her,

AVRASM2 nehmen.


Peter

[gamecounter (Gast)]

Hallo!

Ich wollte nun auch endlich mal nen bootloader verwenden, weil ich auf 
meinem neuen PC nur eine RS232 hab, und mir das umstecken zwischen isp 
und seriellem port mittlerweile etwas lästig ist.

Ich hab mich an die toll geschriebene Anleitung von Karsten gehalten. 
(nur das hex hab ich mit pony prog geflasht)

Hat auch alles geklappt, nur der mikrocontroller antwortet einfach 
nicht.
fboot.exe mit meinem hex als parameter ausgeführt, und das "kreuz" dreht 
sich. contoller aus und wieder an, doch es tut sich nix.

Das Programm is definitiv im Flash.

Ich hab keine Ahnung wo ich den Fehler suchen soll. Ich weiß, is nicht 
grad ne tolle fehlerbeschreibung, aber ... vielleicht hat ja jemand ne 
idee

vielen dank bereits im voraus

gamecounter

[David H. (davherrmann)]

Hallo,
mit meinem VB-Programm bin ich jetzt schon so weit, dass die Verbindung 
mit dem Atmega8 aufgebaut wird, die Checksumme initialisiert wird, 
Signatur, Buffsize und Userflash ausgelesen werden und dann eine 
CRC-Prüfung gemacht wird.
Jetzt gehts ans Programmieren, da hab ich noch eine Frage:
Ich hab jetzt die BufferSize ausgelesen, bei mir kam da der Wert 960 
raus. Sind das Byte ? Oder Bit ? Oder was sonst ?
Soll ich dann nach 960 Byte/Bit auf ein CONTINUE (A9) warten ?

Grüße
David

[Peter D. (peda)]

David Herrmann wrote:

> Ich hab jetzt die BufferSize ausgelesen, bei mir kam da der Wert 960
> raus. Sind das Byte ? Oder Bit ? Oder was sonst ?

Was für nen Sinn sollte denn eine Bitangabe haben?

Die UART (8,N,1) arbeitet immer byteweise.


> Soll ich dann nach 960 Byte/Bit auf ein CONTINUE (A9) warten ?

Ja.


Peter

[David H. (davherrmann)]

Peter Dannegger wrote:

> Was für nen Sinn sollte denn eine Bitangabe haben?
>
> Die UART (8,N,1) arbeitet immer byteweise.

Ehrlich gesagt, keinen :-)
Sorry, aber ich wusste es einfach nicht, ob es jetzt 960 Byte oder 120 
Byte (960 Bit sind).
>
>
>> Soll ich dann nach 960 Byte/Bit auf ein CONTINUE (A9) warten ?
>
> Ja.

Ok, vielen Dank.

Grüße
David

[Markus B. (wolframator)]

Mal eine ganz dumme Frage... Nachdem ich 2x direkt nacheinander meine 
AtMega644 mit PonyProg gekillt hatte und nur 1 gerettet werden konnte 
will ich nun einen Bootloader nutzen.

Wenn ich den Thread hier richtig verstanden habe, dann muss ich nur die 
Hex-Datei aus dem Projekt compilieren und auf den µC laden und dann mit 
der fboot17a.exe meine eigenen Projekte übertragen, richtig?

Beziehe mich auf dieses Zip-Archiv:
>Autor: Ludger (Gast)
>Datum: 28.01.2008 15:05
>Dateianhang: fboot17a_20080128_1458.zip (18 KB, 35 Downloads)

[Malte _. (malte)]

Markus B. wrote:
> Wenn ich den Thread hier richtig verstanden habe, dann muss ich nur die
> Hex-Datei aus dem Projekt compilieren und auf den µC laden und dann mit
> der fboot17a.exe meine eigenen Projekte übertragen, richtig?
Du musst zusätzlich noch die Fuses so einstellen dass von der richtigen 
Adresse gestartet wird, sonst passiert nichts.

[Sven (Gast)]

@Peda:

Vielen Dank für diesen Bootloader. Habe diesen auch ohne Probleme
auf einem Mega16 zum Laufen gebracht.
(kleine Änderung wegen dem nicht vorhandenen WDCE bit)

@Dirk Schmidt:

Habe mir die Mühe gemacht und noch ein paar Features hinzugefügt:

1. Auswahl des Comports
2. Texteingabe des Passwortes möglich

(kann man alles noch erweitern, für mich langte es erst mal ;-) ,
bin trotzdem für konstruktive Hinweise zu haben)

(getestet nur mit COM1 bis COM4;
hatte die FTDI-Wandler gerade nicht zur Hand)

Viel Spass

Gruß Sven

[TobyTetzi (Gast)]

Hallo Sven,

habe grade deine Programmdateien in VS2005 importiert.
Obwohl ich mich noch nicht mit VS2005 auskenne, versuche es erst noch zu 
lernen,
geht alles einwandfrei, sogar auf Com5 mit einem USB->RS232 Kabel.

Gruß Toby

[Sven (Gast)]

Überarbeitung der Version Bootloader_CSharp_adv.zip:

Neue Version: Bootloader_CSharp_adv_v2.zip

1.  Auswahl des Comports
1.1 Comport wird jetzt automatisch vom System ermittelt
2.  Texteingabe des Passwortes möglich
3.  Baudrate einstellbar
    (Standard Baudraten vorbelegt;
     keine automatische Ermittlung)

(getestet mit Hardware COM1 bis COM2;
 Prolific 2303 USB-Seriell Adapter funktioniert;
 FTDI-Wandler gerade nicht zur Hand)

Viel Spass

Gruß Sven

[Sven (Gast)]

> Prolific 2303 USB-Seriell Adapter funktioniert;

Ports COM 14 + COM 15 funktionieren auch ;-)

Gruß Sven

[Hagen R. (hagen)]

Hi Peter,

ich versuche deine ABaud Routine zu kapieren.

abaud:
  ldi  a0, byte3(BootDelay / 6)
_aba1:
  movw  zh:zl, zeroh:zerol  ; cause first try invalid
_aba2:
  movw  yh:yl, zh:zl
  movw  zh:zl, zeroh:zerol  ; z = 0x0000
_aba3:
  sbiw  twh:twl, 1    ;2
  sbci  a0, 0      ;1
  SKIP_RXD_0      ;1  wait until RXD = 0
  brne  _aba3      ;2 = 6
  breq  timeout
_aba4:
  sbiw  yh:yl, 1    ;2
  adiw  zh:zl, 4    ;2  count bit time
  brcs  timeout      ;1  time to long
  SKIP_RXD_1      ;1   wait until RXD = 1
  rjmp  _aba4      ;2 = 8
;------------------------------ correction for USB dongle !!! ------------
  mov  r0, zh
_aba5:
  asr  yl      ; shift signed !
  lsr  r0
  brne  _aba5
;-------------------------------------------------------------------------
  sbiw  yh:yl, TOLERANCE
  adiw  yh:yl, 2 * TOLERANCE
  brcc  _aba2      ; outside tolerance
  cpi  zl, MINTIME
  cpc  zh, zerol
  brcs  _aba2      ; time to short
  sbiw  zh:zl, 2*UartLoop-1  ; rounding, -loop time
  lsr  zh      ; /2
  ror  zl
  movw  baudh:baudl, zh:zl

1.) das Label _aba1: wird nicht benutzt und kann doch sicherlich 
entfernt werden

2.) das

  sbiw  yh:yl, TOLERANCE
  adiw  yh:yl, 2 * TOLERANCE

verstehe ich nicht. Könnte man nicht auf das sbiw verzichten und statt 
dessen "adiw yh:yl, TOLERANCE" benutzen ? Das würde 1 Opcode sparen.


3.) der Vergleich mit anschließender Rundung könnte vereinfacht werden, 
aus

  cpi  zl, MINTIME
  cpc  zh, zerol
  brcs  _aba2      ; time to short
  sbiw  zh:zl, 2*UartLoop-1  ; rounding, -loop time

wird eventuell so:

  sbiw    zh:zl, MINTIME
  brcs  _aba2      ; time to short
  adiw  zh:zl, MINTIME - 2*UartLoop-1  ; rounding, -loop time

4.) wenn man die Baudrate Register baudh:baudl in den oberen 
Registerbereich verschieben würde so könnte man statt zh:zl direkt auf 
diese Register in ABaud zugreifen. Das würde wiederum das letzte MOVW 
eliminieren.

Insgesamt spart man so min. 6 Bytes an Code. Ich weiß das ist nicht viel 
aber wenn man schon eine so perfekte und kompakte ABaud Routine hat... 
;)

5.) mir ist aufgefallen das twh:twl nicht auf 0 initialisert wird. Ok, 
das dürfte bei einem echten Reset nicht das Problem sein, wenn aber aus 
der App in den Bootloader gesprungen wird dann könnten twh:twl schon 
Werte <> 0 enthalten. Dadurch dürfte sich das Timing leicht verändern. 
Ich weiß das dies im Grunde unwesentlich ist.

6.) könnte man das Kommandoprotokoll nicht vereinfachen ? Deine 4 
Messages werden zu einem kompletten Block zusammengefasst. Gleich mit 
der Bestätigung des CONNECT werden dann diese Infobytes mit übertragen, 
an einem Stück. Als reale Kommandos verbleiben dann nur noch das 
Programmieren, CheckCRC, Verify und Run App übrig. Man würde damit 
einige Bytes an Code für den Kommandointerpreter und bei den Messages 
einsparen.
Alternativ könnte man auch nur ein einzigstes Infokommando bauen.

7.) in putchar: folgt der Einsprungspunkt SyncPutChar für 1-Wire. Wenn 
man diesen dort entfernt wird ein "rjmp _tx2" elimiert. Dafür wird der 
Code von SyncPutchar vorgezogen und in FastLoad.inc -> connected: 
eingebaut. Denn nur dort wird ja SyncPutChar aufgerufen. So spart man 
nochmals 2 Bytes an Code.

Alles in allem düfte man so bei 1-Wire eine Flash-Page mindestens 
einsparen können.

Gruß Hagen

[Peter D. (peda)]

Hagen Re wrote:

> 1.) das Label _aba1: wird nicht benutzt und kann doch sicherlich
> entfernt werden

Ja

> 2.) das
>

>   sbiw  yh:yl, TOLERANCE
>   adiw  yh:yl, 2 * TOLERANCE
>

>
> verstehe ich nicht. Könnte man nicht auf das sbiw verzichten und statt
> dessen "adiw yh:yl, TOLERANCE" benutzen ? Das würde 1 Opcode sparen.

Nein, der Fehler kann ja positiv oder negativ sein.

> 3.) der Vergleich mit anschließender Rundung könnte vereinfacht werden,

>

>   sbiw    zh:zl, MINTIME
>   brcs  _aba2      ; time to short
>   adiw  zh:zl, MINTIME - 2*UartLoop-1  ; rounding, -loop time
> 
>

Gibt nen Error, Du kannst nur kleine Werte 16bittig addieren.


> 4.) wenn man die Baudrate Register baudh:baudl in den oberen
> Registerbereich verschieben würde so könnte man statt zh:zl direkt auf
> diese Register in ABaud zugreifen. Das würde wiederum das letzte MOVW
> eliminieren.

Da ist aber nichts mehr frei.

> 5.) mir ist aufgefallen das twh:twl nicht auf 0 initialisert wird.

Ist ja insgesamt ein 3-Byte Zähler, da reicht es, nur das höchstwertige 
Byte zu laden, ein Timeout muß ja nicht supergenau sein.

> 6.) könnte man das Kommandoprotokoll nicht vereinfachen ? Deine 4
> Messages werden zu einem kompletten Block zusammengefasst.

Es sollte ne universelle Zahlenausgaberoutine sein, falls man später mal 
noch andere Werte übertragen will (Fusebits).

> Alles in allem düfte man so bei 1-Wire eine Flash-Page mindestens
> einsparen können.

Mein Ziel war, beim ATtiny13 noch die Hälfte vefügbar zu haben.


Peter

[Hagen R. (hagen)]

>>   sbiw  yh:yl, TOLERANCE
>>   adiw  yh:yl, 2 * TOLERANCE

>> verstehe ich nicht. Könnte man nicht auf das sbiw verzichten und statt
>> dessen "adiw yh:yl, TOLERANCE" benutzen ? Das würde 1 Opcode sparen.

>Nein, der Fehler kann ja positiv oder negativ sein.

Also Tolerance ist definiert als 3.

Wir Subtrahieren  also  y -= 3 und danach addieren wir y += 6, da das 
Carry erst nach der Addition ausgewertet wird kann man y = y (-3 + 6) -> 
y += 3 rechnen. Ein Carry in SBIW wird im ADIW nicht berücksichtigt.

Irgendwas verstehe ich da nicht. Kannst du mir erklären worin der 
Unterschied bestünde zwischen

y -= 3;
y += 6;
if y < 0 then ..

zu

y+=3;
if y < 0 then ..


Gruß Hagen

[Hagen R. (hagen)]

  sbiw  yh:yl, TOLERANCE
  adiw  yh:yl, 2 * TOLERANCE
  brcc  _aba2      ; outside tolerance

kann es sein das zwischen sbiw und adiw noch ein Branchbefehl fehlt ? 
Das wäre das Einigste was aus meiner Sicht noch einen Sinn ergäbe. Wenn 
nicht dann müsste ein einfaches adiw  y,3 das gleiche Resultat ergeben.

Gruß Hagen

[Peter D. (peda)]

Um es mal in einer Hochsprache zu erläeutern:

Man kann schreiben:

  if( (i >= MIN) && i <= MAX )

Man spart sich aber einen Vergleich, wenn man es so macht:

  if( (i - MIN) <= (MAX - MIN) )

Simulier den Code einfach mal mit verchiedenen Werten.


Peter

[Hagen R. (hagen)]

@Peter,

Danke ich habs jetzt kapiert. Entscheidend ist ja die letzte Operation 
und es ist eben nicht egal op man 2*TOLERANCE addiert oder nur 
TOLERANCE. Ansonsten recht clever das Ganze und wieder mal was dazu 
gelernt.

Gruß Hagen

[Sven (Gast)]

Neue Version: Bootloader_CSharp_adv_v3.zip

1.  Speicherung der möglichen Einstellungen in
    "Applikationspfad\Settings.cfg";
    beim Starten der Anwendung werden die letzten
    Einstellungen aus Settings.cfg geladen !
2.  Auswahl des Comports
2.1 Comport wird jetzt automatisch vom System ermittelt
3.  Texteingabe des Passwortes möglich
    (Passwort wird mit in der Datei Settings.cfg (Klartext) abgelegt)
4.  Baudrate einstellbar
    (Standard Baudraten vorbelegt;
     keine automatische Ermittlung)

(erneut getestet mit Hardware Schnittstelle COM1 bis COM2)

So, dies war vorerst meine letzte Version.

Viel Spass

Gruß Sven

[chris (Gast)]

Hallo Peter,

habe den loader auf meinem m168 ausprobiert und funktioniert super.
Leider habe ich auch das problem das ich Variablen werte ins eeprom 
auslagere die ich seperat in den mega brennen muß.
Frage an dich Peter, ist angedacht, das du das eeprom schreiben noch 
implementierst? Das würde dann dein Programm vollenden.

vielen Dank

mfg.

chris

[Peter D. (peda)]

chris wrote:
> Leider habe ich auch das problem das ich Variablen werte ins eeprom
> auslagere die ich seperat in den mega brennen muß.

Kannst Du das irgendwie erklären, warum der EEPROM separat gebrannt 
werden muß ?


Peter

[chris (Gast)]

Hi,

z.b. habe ich hier ein funktranceiver den ich in verschiedenen Modes 
verwende. Also FSK, GMSK, MSK usw. Diese auch in verschiedenen speed 
modes und ISM Bändern. Habe dadurch einen Parametersatz von über 100 
Werten. Um Speicherplatz zu sparen lade ich einfach je mach mode den 
passenden Parametersatz aus dem EEPROM in ein array. Auch ein "default" 
Parametersatz ist vorhanden den ich nur lade wenn nix mehr geht. Also so 
ne Art "Werkseinstellung".
Wenn ich das alles mit #if's machen würde kostet das mehr Platz im 
flash.

Vieleicht hätte man es auch anders machen können, aber habs halt so 
gemacht :-)


BTW: kann man den onewire mode auch deaktivieren? Beißt sich irgendwie 
mit meiner Hardware wenn ich den Transceiver chip am M168 hängen habe. 
Ohne Transceiver chip flash er super im rs232 mode.

thx

mfg.
chris

[Peter D. (peda)]

chris wrote:

> Wenn ich das alles mit #if's machen würde kostet das mehr Platz im
> flash.

Nein, #if's kosten kein Byte Speicherplatz mehr, da sie bereits zur 
Compilezeit ausgewertet werden.
Sonst würde Dir ja auch der EEPROM schnell ausgehen.

> Vieleicht hätte man es auch anders machen können, aber habs halt so
> gemacht :-)

Hab leider keine Zeit, das einzubauen.
Bin aber grad dabei nen API-Call zu entwickeln, damit der Flash aus der 
Applikation heraus programmiert werden kann.
Brauche nämlich mehr Datenspeicher, als der EEPROM groß ist.


> BTW: kann man den onewire mode auch deaktivieren? Beißt sich irgendwie
> mit meiner Hardware wenn ich den Transceiver chip am M168 hängen habe.

Ein Deaktivieren ist nicht nötig, solange das Paßwort nicht reinkommt, 
ist der Bootloader muxmäuschenstill.
Er kann also die Applikation garnicht stören.
Man hat nur die 0,3s zusätzliche Resetzeit, das ist alles.

Du  mußt außerdem den Bootloader nicht mit auf die UART legen, jede 
anderen 1 oder 2 Pins gehen.


Peter

[Thomas S. (space)]

Ich möchte mich bei Peter für den Bootloader, insbsondere für den 
Singlewiremode, bedanken. Der Loader löst mein Problem, wie ich meinen 
Eigenbau RC-Empfänger, welcher tief in der engen Rumpfröhre steckt, 
zukünftig updaten kann.

Funzt super:
C:\TEMP>FBOOT18.EXE   /Vrx.hex
COM 1 at 115200 Baud: Connected (One wire)
Bootloader V1.8
Target: 1E930A ATmega88
Buffer: 960 Byte
Size available: 7680 Byte
Verify rx.hex: 00000 - 00B93 successful
CRC: o.k.
Elapsed time: 0.99 seconds

[chris (Gast)]

Hallo Peter,

eins noch dann bin ich still :-)

<Nein, #if's kosten kein Byte Speicherplatz mehr, da sie bereits zur
<Compilezeit ausgewertet werden.
<Sonst würde Dir ja auch der EEPROM schnell ausgehen.

das stimmt, aber ich will ja alle Parametersätze während der Laufzeit 
ändern und modifizieren können. Wenn die mir beim compilen entfernt 
werden bringt mir das leider nicht so viel.

<Ein Deaktivieren ist nicht nötig, solange das Paßwort nicht reinkommt,
<ist der Bootloader muxmäuschenstill.
<Er kann also die Applikation garnicht stören.
<Man hat nur die 0,3s zusätzliche Resetzeit, das ist alles.

jo, ist wohl ein Probelm mit meiner applikation. Wenn ich den Sender 
ausschalte, flasht er im normalen mode. Muß mal sehen woran das liegt.

vielen Dank für die schnelle Antwort

cu und mach weiter so

[Malte _. (malte)]

chris wrote:

> <Nein, #if's kosten kein Byte Speicherplatz mehr, da sie bereits zur
> <Compilezeit ausgewertet werden.
> <Sonst würde Dir ja auch der EEPROM schnell ausgehen.
>
> das stimmt, aber ich will ja alle Parametersätze während der Laufzeit
> ändern und modifizieren können. Wenn die mir beim compilen entfernt
> werden bringt mir das leider nicht so viel.

Du könntest in deine Applikation auch eine EEProm schreib Routine 
intengrieren, die die Daten per RS232 entgegen nimmt. Falls du dafür 
nicht mehr genügend Flash hast könntest du erst ein Program zum 
schreiben des EEProm hochladen, den EEProm damit schreiben und dann das 
eigentliche Program drüber spielen. Das ließe sich sicher auch 
automatisieren. Nur der Flash "altert" dann entsprechend schneller.

[JoJo (Gast)]

In den ersten Versionen von Pedas Bootloadern (April/Mai 2004) war die 
Funktion noch mit drin. Damals noch für Mega8/16.
Gruß JoJo

[chris (Gast)]

hallo  Malte,

ne das ist schon ok. Ich muß ja eh ein ISP dran hängen um den bootloader 
zu flashen. Dann kann ich ja acuh direkt das eeprom schreiben, also kein 
Problem.

[frans (Gast)]

Hallo Peter und anderen,


Ein hollander hat sehr intressiert das forum gelesen!
Die deutsche sprache bleibt swierig fur mich.....

Aber ist die atmega128 auch unterschutst oder nicht?

gruss frans

[Peter D. (peda)]

frans wrote:
> Aber ist die atmega128 auch unterschutst oder nicht?

Ja, alle AVRs ab dem ATtiny13.

Die aktuelle Version ist hier:

http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1008&item_type=project


Peter

[[e-mail] (Gast)]

was muss ich tun fur  unterschutzung atmega128?
Ich bin der erste???

edit
ins fboot18.def         1E 97 02 : atmega128
ins bootload.asm die atmega128 include selectieren

und dann offenen in avrstudio und assemblieren.


fur meine platine muss ich nog pin PE3 hoch machen und veileicht mehr...
Ist da ein specialer platz fur?


gruss Frans

[Peter D. (peda)]

[e-mail] wrote:

> ins fboot18.def         1E 97 02 : atmega128
> ins bootload.asm die atmega128 include selectieren
>
> und dann offenen in avrstudio und assemblieren.

Ja.
Und dann noch die beiden (oder einen) Pins für den Bootloader 
definieren.


> fur meine platine muss ich nog pin PE3 hoch machen und veileicht mehr...
> Ist da ein specialer platz fur?

Was meinst Du damit?


Peter

[[e-mail] (Gast)]

Hallo Peter,

Ich muss mehr io pins initialisieren fur power und levelconverter 
enable.

Dan die programmier io pins initialisieren in bootload.asm?
mein xtal ist 3686400 Hz muss anpassen ins fastload.h?
bootdelay = xtal/5
Will fboot sich anpassen mit die timing? (abaud?)


Gibt er ein adaptier handleidung (manual) ?

gruss, Frans

[chris (Gast)]

dear Frans,

please take a look at this page, which is automatical translated by 
google.

http://translate.google.com/translate?u=http%3A%2F%2Fwww.mikrocontroller.net%2Farticles%2FAVR_Bootloader_FastBoot_von_Peter_Dannegger&langpair=de%7Cen&hl=de&ie=UTF-8

cu

[Peter D. (peda)]

[e-mail] wrote:
> Ich muss mehr io pins initialisieren fur power und levelconverter
> enable.

Zusätzliche Initialisierungen mußt Du in der "fastload.inc" hinter das 
Label "init:" eintragen.


> Dan die programmier io pins initialisieren in bootload.asm?

ja.


> mein xtal ist 3686400 Hz muss anpassen ins fastload.h?

kann man, ist aber unkritisch.


> bootdelay = xtal/5

sollte eigentlich passen


> Will fboot sich anpassen mit die timing? (abaud?)

dazu ist ja der XTAL-Eintrag da.


> Gibt er ein adaptier handleidung (manual) ?

http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger


Peter

[Alexei V. (Firma: Universitaet Zurich) (vyssotski)]

Hi Peter,

vielen Dank fuer deinen Bootloader! Er ist toll!

Ich habe mit den hardware COM port and Aten UC-232 USB dongle probiert. 
Beide waren gut. Ich habe ATmega88 mit 7.3728MHz getaktet. Der gute 
baudrate war 19200. Ich habe nicht alle baudrates getestet, aber es 
scheint mir, dass nich alle funktionieren. Das ist aber kein Problem. 
Das richtige Problem war das ich nicht FTDI USB-serial Wandler zum Lauf 
mit dem bootloader bringen koennte. Ich weiss nicht warum. Mit meiner 
eigenen Software und dem gleichen Processor (ATmega88) FTDI laeuft gut. 
Ich habe mit FBOOT18.exe und bootloader_CSharp_adv_v3.zip probiert. 
Beide funktionieren mit FTDI nicht!

Du hast ein mal geschrieben, dass du den FTDI adapter benutzt. Wie hast 
du das gemacht? Was war fuer Treiber und Einstellungen? Welche Version 
ist mit FTDI getestet? Was hast du mit den nicht noetigen Leitungen 
gemacht? Bei mir sind sie frei. Mein FTDI Adapter heisst TTL-232R-3V3.

Noch eine Kleinigkeit. Ich habe den Kode vom bootloader ein bisschen 
geaendert. Auf meiner Platine koennte ich nur "debug wire" nutzen. 
Deswegen koennte ich nich FUSES aendern. Ich habe am Anfang des Kodes 
ueberal
.org 0
    rjmp  0x0f00
    reti
plaziert. Das soll keine Role spielen, while mit den normalen Ports 
alles  gut funktioniert.

Wer noch hat die Erfahrung mit FTDI?

Vielen Dank fuer die Hilfe im voraus!

Alexei

P.S. Ich bitte fuer mein Deutsch entschuldigen...

[Alexei V. (Firma: Universitaet Zurich) (vyssotski)]

Noch Information zu FTDI und anderen convertors. Nicht alle FTDI sind 
gleich. Ich habe gefunden dass FBOOT18.EXE mit FT232BM gut funktioniert. 
Aber FT232R im TTL-232R-3V3 Kabel - gar nicht. Natuerlich, ich habe den 
letzten Treiber 2.2.4 benutzt. Fuer Zuverlassigkeit habe ich zwei Stueck 
Kabel getestet. Zur Zeit habe ich die folgende Tabelle, wo ich markiert 
habe was funktioniert and was nicht:

PC program:             FBOOT18.EXE     "C# Ver.3"
Matherboard COM             +               +
Aten UC-232A                +               +
Keyspan USA-19HS            -(*)            +
FTDI FT232BM                +               -(**)
FTDI FT232R                 -               -

* "Transmit vom PC" LED ist OFF
** "Transmit vom PC" LED ist ON, aber keine Antwort vom ATmega88.
Leider habe ich FT232R in einem Kabel ohne LED and kann nichts ueber 
transmit/receive sagen.

Hat jemand die gute Erfahrung mit FT232R? Oder kennt jemand eine version 
vom PC Programm, die mit ihm funktioniert?

Alexei

[Sven (Gast)]

Hi Alexei,

ich kann Di oder Mi Tests mit FT232RL ATMega16 mit 7.3728Mhz 
durchführen.
OS: W2k SP4 oder XP SP2

Welches Betriebssystem benutzt Du ?
Welcher Modus genau beim Bootloader ? Einfach über TX/RX also seriell ?

Gruß Sven

[Peter D. (peda)]

Alexei Vyssotski wrote:

> Du hast ein mal geschrieben, dass du den FTDI adapter benutzt. Wie hast
> du das gemacht? Was war fuer Treiber und Einstellungen? Welche Version
> ist mit FTDI getestet? Was hast du mit den nicht noetigen Leitungen
> gemacht? Bei mir sind sie frei. Mein FTDI Adapter heisst TTL-232R-3V3.

Im Gerätemanager stehte nur FTDI, mehr weiß ich nicht.
Dann hab ich noch nen Prolific.
Beim Prolific mußte ich nen neueren Treiber installieren (25.07.2005).
Der FTDI hat noch den alten (25.02.2003).

Ich benutze Windows-XP.


Peter

[Alexei V. (Firma: Universitaet Zurich) (vyssotski)]

Hi Sven, Peter

vielen Dank fuer ihre Antworten.

Ich habe gefunden, dass alle Bytes zum Microkontroller gut kommen, ohne 
Muell, aber gibt es inzwischen die besstimte Loecher. Sie konnen im 
Anhang schauen wie es ist. Alle Daten sind mit FT232BM gesammlet. Die 
gute Sequenz war mit FBOOT18.EXE generiert, die schlechte - mit C# V.3. 
Theoretisch, alle Sequenzen sollen fuer einen seriellen Port gut sein, 
aber das Problem macht warschaenlich Autoboading. Sven, schickst du 
einen Byte nach dem anderen separat? Oder nutzst nur einen Befehl um 
array 'Peda',0xFF zu schicken? Das habe ich noch nicht geschaut.

Die wichtige Frage fuer mich, was ist eifacher zu aendern, das PC 
Programm oder den ATmega Teil? Ich wuerde zuerst versuchen zwei Sachen 
zu machen: a) die Loecher zwischen Bytes in der Sequenz eliminieren oder 
b) diese Loecher sehr gross zu machen. Zum Beispiel, kann man versuchen 
'Peda',0xFF jede Millisekunde zu schicken? Wie sie denken, bringt es 
etwas?

Theoretisch, man kann autobauding ausschalten, aber es ist keine schoene 
Losung. Die Taktfrequenz kann in dieser Anwendung nicht genau 7.3728Mhz 
sein. Das Hauptprogramm nutzt das 1pps Sygnal (vom anderen Teil) um 
inneren ATmega88 Generator von ca. 8MHz auf 7.3728MHz (+/-0.5%) zu 
stellen. Das ist am ersten Start gemacht, und danach immer, when 
moeglich, automatish korregiert. Aber falls das Geraet ganz neu ist, hat 
er nur ca. 8MHz mit einer hohen Fehler in der Frequenz. Deshalb braucht 
man autoboading.

Ich nutze Windows XP, aber Win 2000 hat das gleiche Problem, wie ich 
geschaut.

Gruss,

Alexei

[Alexei V. (Firma: Universitaet Zurich) (vyssotski)]

Jetzt versuche ich noch ein mal den Dateianhang zu schicken, der nicht 
gegangen ist. Jetzt ist er 352K gross.

Alexei

[Alexei V. (Firma: Universitaet Zurich) (vyssotski)]

Hi Sven, Peter

ich habe meine Problemen geloescht! Zeurst, die Frequenz des Procressors 
am Start war 7.3728/8 MHz und nicht 7.3728MHz, wie ich frueher gedacht 
habe. Das war der Gruend warum der Processor nur bis 19200bps 
programmiert werden koennte. Wenn ich die Frequenz acht mal vergroessert 
habe, alle baudrates waren gut. Das zweite Problem war, dass 
TTL-232R-3V3 Kabel von FTDI immer (am Start) die hohe Spannung auf TX 
Leitung hat. Wenn die Platine mit diesem Adapter verbunden war, und am 
Anfang der Strom auf dem Microcontroller aufgeschaltet war, koennte er 
nicht starten!!! Die Loesung war den Microkontriller zuerst starten und 
dann mit dem Adapter verbinden. Aber fuer  solchen Start 0.33 sec 
Startzeit ungenuegend ist. Zum glueck sollte ich diesen Konstant nicht 
aendern, while meine richtige Processorfrequenz mehr als acht mal 
niedriger als default war. Am Schluss habe ich  ca. 2.7 Sekunden 
Startzeit gehabt.

Das letzte Problem ist nur fuer TTL-232R-3V3 Kabel aktuell. Der Chip 
FT232R hat den Eingang, der die Spannung auf TX/RX Linien leiten kann. 
Aber im TTL-232R-3V3 Kabel giebt es leider keinen Zugang zu diesem Pin.

Ich hoffe, dass diese Information fuer den anderen Leute nuetzlich sein 
koennte.

Mit freundlichen Gruessen,

Alexei

[Hannes (Gast)]

Hallo zusammen,

kann man die Schaltung , wie in der bootloader.pdf beschrieben , direkt
an die R232 eines  PC anschliessen ?
Oder muss zwischen J8 und J9 noch ein MAX232 ?

Konnte hier im Thread und im Wiki nichts dazu finden.


Gruss und noch schöne Ostern
 Hannes

[Peter D. (peda)]

Hannes wrote:
> Hallo zusammen,
>
> kann man die Schaltung , wie in der bootloader.pdf beschrieben , direkt
> an die R232 eines  PC anschliessen ?

Ja.


Peter

[[e-mail] (Gast)]

Hallo peter,

Dar ist die hollander wieder.....
Die ATmega128 brennt einmal!
Das program lauft dan.

COM 1 at 9600 Baud: Connected
Bootloader V1.8
Target: 1E9702 ATmega128
Buffer: 1024 Byte
Size available: 130048 Byte
Program solo.hex: 00000 - 0F000 successful
CRC: o.k.
Elapsed time: 61.59 seconds

Die zweite mal geht es nicht mehr............

COM 1 at 9600 Baud: Connected      oder mit (OneWire)??
Bootloader VFFFFFFFF.FF
Error, wrong device informations

connected -> das pasword ist gut
und die baudrate ist auch gut fur das 4 char password
check_crc volgt dan
und dan readinfo gibt die falshe version aber kein signature???
auf das resultcode von readinfo wirt die Error, wrong usw. geprinted??


Ich hat das problem ins bootdelay gesucht....
das crystal sind 3.68 Mhz und bootdelay/5
(wie komt man von default 8Mhz und bootdelay/3 auf 0.33 sec?)
Die fuses sind correct wie das ORG ins die .lst file

Mein zu brennen program gebraucht die watchdog, kan das interferieren 
mit die watchdog von fboot18?
Muss ich noch etwas tun mit CRC, WDT, verify???
Ist der toleranz van die baudrate das problem??
Kan ich ein baudrate forcieren?
Kan ein tastedruck version mit fixed baud mein problem wegnemen?

in die anhang hat ich die anderte files mit gelievert (<- zu 
hollandisch?)

Mit freundlichen Gruessen,

Frans

[Sven (Gast)]

@Peter:

Ich habe jetzt eine Schaltung aufgebaut mit einem Mega8 und
FT232RL. Schaltung wird komplett durch den USB Bus versorgt.
(Bus-Powered)

Die Schaltung arbeitet einfach mit UART über RX/TX.
Jetzt besteht das Problem:

Voraussetzung:

- der Bootloader ist aufgespielt
- ein normales Programm läuft ebenso

Update Vorgang:

- man muss den USB Bus abziehen
- schnell wieder anstecken

Problem:

- virtueller Comport ist noch nicht bereit;
  oder vielmehr das Handle existiert ja nicht mehr,
  man kann also nicht vorher schon den Comport öffnen
  und innerhalb der 0,3s updaten


Mein Vorschlag:

Der Bootloader bekommt 2 Startzeiten:

1. Standardzeit festgelegt mit den 0,3s
2. Bootloader schaut auf die erste Stelle
   des internen EEProms und stellt entsprechend
   eine längere Wartezeit ein,
   danach startet die Firmware aber normal durch.
   Standard ist ja FF, dann ist es also möglich
   die Zeit von 0-254 zu stellen, 255 als Wert
   lässt also auch die 0.3s ablaufen

Über die normale Applikation kann man also diese
Speicherzelle beschreiben und vor einem Reset
die Startzeit verlängen.


Was hälst Du von der Idee ?

Gruß Sven

[Peter D. (peda)]

[e-mail] wrote:

> Mein zu brennen program gebraucht die watchdog, kan das interferieren
> mit die watchdog von fboot18?

Ja, kann sein.

Anbei ne korrigierte Version (werd sie auch in AVRFreaks updaten).

Es scheint so, daß zumindest bei neueren AVRs beim ersten Zugriff noch 
kein neuer Teilerwert geladen werden darf, sondern erst beim 2.Zugriff.


Peter

[Duri (Gast)]

Hallo alle fboot Nutzer (das sind in der Zwischenzeit ziemlich viele)

Ich wollte für meinen ATMega32 eine Bootdatei compilieren und habe die 
Felermeldung " WDCE unbekannter Wert" bekommen.

Beim M32 heisst dieses Registerbit WDTOE.

In der Datei X:\..\avrassembler2\Appnotes\m32def.inc ist definiert:
(AVR Studio 4 SP2)

.equ  WDDE  = WDTOE  ; For compatibility

Ich behaupte einfach mal, das ist ein Fehler von Atmel.

Richtig wäre:
.equ  WDCE  = WDTOE  ; For compatibility

Wenns jemanden hilft....

[Karsten D. (karstendonat)]

Sven wrote:
> - man muss den USB Bus abziehen
> - schnell wieder anstecken
>
> Problem:
>
> - virtueller Comport ist noch nicht bereit;
>   oder vielmehr das Handle existiert ja nicht mehr,
>   man kann also nicht vorher schon den Comport öffnen
>   und innerhalb der 0,3s updaten

Für das Problem gibts 3 einfache Lösungen:

1. Hardware Reset über Taste
--> Reset Pin auf Masse ziehen per Taster
(wenn die Schaltung schon fertig ist, nimm halt nen Draht)

2. Hardware Reset über Transistor
--> PNP an einen Pin hängen und mit 10k an den Reset. Nach em Reset ist 
der Pin Low und der PNP hat am Ausgang zum Reset High (invertierende 
Schaltung). Stzeuert man den Pin High, sperrt der Transistor und man 
zieht den Reset auf Masse.

3. Software-Reset

wdt_enable(WDTO_15MS);
while (true);

In der IDE wird ein Reset Signal gesendet. Danach wird das Programmer 
Tool von Peter gestartet. Dafür muss das Bootloader Delay auf 1s erhöht 
werden.

[Sven (Gast)]

> 3. Software-Reset

> wdt_enable(WDTO_15MS);
> while (true);

> In der IDE wird ein Reset Signal gesendet. Danach wird das Programmer
> Tool von Peter gestartet. Dafür muss das Bootloader Delay auf 1s erhöht
> werden.

Dieser Vorschlag hat aber genau das gleiche Problem,
das innerhalb des Befehls des wdt_enable aus der eigenen
Anwendung der Comport geschlossen und dann das Tool
zum Flashen gestartet werden muss. (auch wenn
man die Zeit auf 1 Sekunde stellt)

Meine Idee mit dem EEProm fand ich universeller, da kein
Zugang zum Reset Pin notwendig ist. Ebenso braucht
es keinen Taster und die "Standard" Flasher Tools funktionieren
weiterhin.

Vielleicht ist es jetzt verständlicher.

Tja, warum habe ich diese Frage eigentlich gestellt ?
Weil ich in Assembler dafür viel Zeit brauche um
die entsprechenden Routinen in Abaud.inc einzubauen.
In C bin ich in 10 Minuten damit fertig.
Deswegen wollte ich eigentlich das Feedback von Peter,
ob er denkt das es eine gute Idee ist und
er sich in 10 Minuten Assembler Know-How dafür begeistern
kann.
Ausserdem möchte ich den schönen präzisen Code
von Peter nicht versaubäuteln. ;-)

Gruß Sven

[Peter D. (peda)]

Sven wrote:
> Weil ich in Assembler dafür viel Zeit brauche um
> die entsprechenden Routinen in Abaud.inc einzubauen.
> In C bin ich in 10 Minuten damit fertig.

Na, so schlimm ist Assembler auch nicht.
Hier mal der Hack, ist aber nicht getestet.
Kannst ja mal berichten, obs funktioniert.
Für längeres Reset nen kleineren Wert als 0xFF speichern.

...
abaud:
        ldi     a0, 1                   ; additional boot delay at 0x0001
        out     EEARL, a0
        out     EEARH, zerol
        sbi     EECR, EERE
        in      a0, EEDR
        subi    a0, -(byte3(BootDelay / 6) + 1)
_aba1:
        movw    zh:zl, zeroh:zerol      ; cause first try invalid
...

Peter

[Karsten D. (karstendonat)]

Das mit dem EEPROM ist ne gute Idee. Die längere Wartezeit stört 
manchmal.

Aber prinzipiell funktionierts (benutze das ja schon einige Zeit so). 
Comport schließen und Tool starten schafft man in s, zur Not halt etwas 
länger, wenn das mit dem EEPROM geht kann man das ja sogar auf 3s oder 
länger ausbauen.

Karsten

[Sven (Gast)]

Hallo Peter,

vielen Dank erst mal für die Antwort und die Zeilen.
Natürlich berichte ich ob es funktioniert.
In diesem Fall funktioniert es leider nicht.

Zum Assembler: Ich versuche die Befehle zu verstehen.


...
abaud:
        ldi     a0, 1                   ; additional boot delay at 
0x0001
        out     EEARL, a0               ; EEprom LOW-Zeiger laden
        out     EEARH, zerol            ; EEProm High-Zieger laden
        sbi     EECR, EERE              ; lesen
        in      a0, EEDR                ; Wert nach a0
        subi    a0, -(byte3(BootDelay / 6) + 1)
_aba1:
        movw    zh:zl, zeroh:zerol      ; cause first try invalid
...

Habe einfach mal die Kommentare ergänzt.
Beim subi Befehk taucht jetzt aber eine Frage auf.
Ich habe den Befehl so verstanden, das man einen Wert von
a0 abzieht.

Aber das würde ja keine wesentliche Zeit verbraten.
Mein Verständnis hätte jetzt erwartet, das man über eine
Zeitschleife zB auch rekursiv eine Wartezeit einbauen muss
(rekursiv nops verbraten) .......

Habe ich da jetzt was Grundlegendes missverstanden ?

Gruß Sven

[Peter D. (peda)]

Sven wrote:
> In diesem Fall funktioniert es leider nicht.

Du weiß schon, daß man sowas nicht sagt.

Man sagt, was man getan hat, was man erwartet hat und was passiert ist.


> Beim subi Befehk taucht jetzt aber eine Frage auf.
> Ich habe den Befehl so verstanden, das man einen Wert von
> a0 abzieht.

Zum Addieren die negative Zahl, da es kein ADI gibt.


> Aber das würde ja keine wesentliche Zeit verbraten.

Soll es auch nicht, sondern es initialisiert nur den Wartezähler.
Bei 8MHz entspricht 6 ~0,3s.
Also lade mal in den EEPROM 100 für ~5s.


Peter

[Sven (Gast)]

Hallo Peter,

> Du weiß schon, daß man sowas nicht sagt.
> Man sagt, was man getan hat, was man erwartet hat und was passiert ist.

Na klar entschuldige.

1. also habe die Zeilen eingefügt in abaud.inc
2. alle *.hex Files aus dem Verzeichnis gelöscht
3. asm bootload - neuen bootloader erzeugt
4. flash bzw. atmega8 gelöscht
5. bootload.hex in den atmega8 geflasht
6. neues Programm welches 2 Leds startet aufgespielt
   (1.Led startet sofort nach Programm aufruf, 2. Led nach 1 sec
   danach in endlosschleife)

Mega 8 läuft mit 7,328 Mhz.

Dann habe ich den EEPRom an Stelle 0x01 verstellt.
Von 0x10 bis 0xFE.

Die 1. Led leuchtet immer nach ca. 0.3 Sekunden auf.

> Zum Addieren die negative Zahl, da es kein ADI gibt.

Ahh ok.

> Soll es auch nicht, sondern es initialisiert nur den Wartezähler.

Ok, initialisieren verstehe ich, ich sehe aber nicht wo
dann a0 weiter unten im Programm benutzt wird um die Zeit zu prüfen.

> Bei 8MHz entspricht 6 ~0,3s.
> Also lade mal in den EEPROM 100 für ~5s.

Habe ich versucht.
Werde aber morgen noch mal testen.

Gruß Sven

[Sven (Gast)]

> Die 1. Led leuchtet immer nach ca. 0.3 Sekunden auf.

Ohh man es war schon spät. Die Led 1 leuchtet natürlich nach ca. 1,3 
Sekunden auf. Eine Veränderung wäre ja mindestens 3 oder 4 Sekunden...
Aber dennoch verändert sich an der Zeit nichts, wenn ich den EEProm 
Inhalt verstelle.

Gruß Sven

[Sven (Gast)]

Hallo Peter,

nachdem ich jetzt erfolglos probiert habe das mit dem Eeprom ans laufen 
zu bringen, habe ich mal den konstanten Wert 0xFA vorgeladen.
Nun ändert sich ebenso nicht die Bootload-Zeit.

abaud:
    ldi     a0, 1                   ; additional boot delay at 0x0001
    out     EEARL, a0
    out     EEARH, zerol
    sbi     EECR, EERE
    in      a0, EEDR
    ldi     a0, 0xFA
    subi    a0, -(byte3(BootDelay / 6) + 1)

Natürlich habe ich diese Zeilen mal im AVRStudio im Simulator
gedebugged. Aber bei diesen Versuchen ist mir keine Stelle
aufgefallen, an der der a0 Wert für eine Wartezeit benutzt wird.
Ich bin gerade nach den Tests echt ratlos.

Gruß Sven

[Peter D. (peda)]

Sven wrote:
> nachdem ich jetzt erfolglos probiert habe das mit dem Eeprom ans laufen
> zu bringen, habe ich mal den konstanten Wert 0xFA vorgeladen.
> Nun ändert sich ebenso nicht die Bootload-Zeit.

So, ich hab mal folgendes Testprogramm in den ATtiny45 geladen:

#include <io.h>

int main( void )
{
  DDRB = 0x0C;                  // LED2, LED3 on

  EEARH = 0;
  EEARL = 1;                    // Address = 0x0001
  EECR |= 1>>EERE;              // read
  if( EEDR == 0xFF )
    EEDR = 100;                 // 255 -> 100
  else
    EEDR = 0xFF;                // 100 -> 255
  EECR |= (1<<EEMPE);
  EECR |= (1<<EEPE);            // write

  for(;;){
  }
}

Es funktioniert wie erwartet. Bei jedem 2. Reset gehen die LEDs erst 
nach 5,7s an.

Anbei die geänderte abaud.inc

Der Rest des Bootloaders entspricht der aktuellen Version V1.9:

http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1008&item_type=project


Peter

[Rumpel P. (rumpel)]

Vielen Dank Peter Dannegger für den Bootloader.
Ich konnte ihn problemlos auf dem ATmega162 meines aktuellen Projektes 
installieren.

Die Steuersoftware für das Projekt habe ich in Java (Max OSX 
Applikation) geschrieben, mit Hilfe der Java-Ansteuerung von Daniel M. 
konnte auch der Updater leicht in das Projekt eingebunden werden. Vielen 
dank auch Daniel M.!
Ich musste in Deiner FirmwareUpdater-Klasse die Timeout-Zeiten ein wenig 
erhöhen, da mein Steuerprogramm über Ehternet (XPort) mit dem mega162 
kommuniziert.

Aber jetzt kann ich gemütlich auf dem Sofa, mit dem Laptop auf den 
Beinen,  die Firmware weiterschreiben und alles per W-LAN updaten 
lassen... :D

Vielen Dank dafür!!!

der faule
Rumpel

[Sven (Gast)]

Hallo Peter,

vielen Dank für Deine Mühe.
Der Code in Abaud.inc

abaud:
    ldi     a0, 1                   ; additional boot delay at 0x0001
    out     EEARL, a0
    out     EEARH, zerol
    sbi     EECR, EERE
    in      a0, EEDR
    subi    a0, -(byte3(BootDelay / 6) + 1)

funktioniert natürlich.
Es gibt aber folgendes zu beachten (und das ist mir beim Testen zum 
Verhängnis geworden):

Wir benutzen mal den Wert 0xFA zum Testen, wie ich oben beschrieben 
hatte:

In Fastload.h ist folgendes definiert:

equ  XTAL    = 8000000  ; 8MHz, not critical
.equ  BootDelay  = XTAL / 3  ; 0.33s

In Abaud:

subi    a0, -(byte3(BootDelay / 6) + 1)

Damit erhalten wir bei der Rechnung:

BootDelay = 8000000/3;
BootDelay = 2666666.67

a0 = a0 -(-(byte3(444444.4)+1);
a0 = a0 -(-(byte3(0x6C81C)+1);
a0 = a0 -(-(0x6)+1);
a0 = a0 + 7;

Nehmen wir a0 mit EEProm-Wert von 0xFA an:

a0 = 0xFA + 7;
a0 = 250 + 7;  << byte überlauf
a0 = 1;

Damit habe ich immer eine kurze Zeit eingestellt und habe es nicht so
schnell gemerkt.

Ander herum ergibt sich der Maximale Wert:

a0 Max = 255 - 7;
a0 Max = 248;
a0 Max = 0xF8;

Somit funktioniert es in beiden Bootloader Versionen 1.8 + 1.9.
Ich hoffe, dies ist jemand anderem auch noch nützlich.

Gruß Sven

[Peter D. (peda)]

Sven wrote:
>> Also lade mal in den EEPROM 100 für ~5s.
>
> Habe ich versucht.
...
Sven wrote:
> Es gibt aber folgendes zu beachten (und das ist mir beim Testen zum
> Verhängnis geworden):
>
> Wir benutzen mal den Wert 0xFA zum Testen, wie ich oben beschrieben
> hatte:

Also hattest Du 100 doch nicht versucht.

Daß Werte nahe 255 nur geringe Änderungen bewirken, war mir schon klar, 
daher eben die Empfehlung mit 100.


Peter

P.S.:
Aber es schadet ja nichts, wenn Du jetzt auch ein bischen Assembler 
verstehst.

[Sven (Gast)]

Hallo Peter,

> Also hattest Du 100 doch nicht versucht.
> Daß Werte nahe 255 nur geringe Änderungen bewirken, war mir schon klar,
> daher eben die Empfehlung mit 100.

Ja, jetzt ist es klar. Die 100 habe ich aber auch versucht einzustellen.
Im Nachhinein ist man sehr viel schlauer.
Der Test mit den 100 ist aber durch einen Fehler von
mir immer auf EEProm Stelle 0x0000 getestet worden. (und nicht auf 
0x0001)

> P.S.:
> Aber es schadet ja nichts, wenn Du jetzt auch ein bischen Assembler
> verstehst.

Nein, ganz und gar nicht. Es macht sogar richtig Spass,
wenn es funktioniert. Herzlichen Dank noch mal für Deine Unterstützung.

Gruß Sven

[Sven (Gast)]

Neue Version: Bootloader_CSharp_adv_v4.zip

1.  Update Button
    Dieser dient zum Ermitteln der Comports, wenn man
    während der Laufzeit die USB-Seriell Wandler abgezogen
    hat und neue/andere Comports aufgetaucht sind
    (Anwendung muss nicht neu gestartet werden ;-), praktisch wenn man 
oft
    verschiedene FTDI Wandler ansteckt!)
2.  Versionsinformationen
2.1 Informationen über die Zielhardware


(erneut getestet mit Hardware Schnittstelle COM1 bis COM15)

Hoffe die Features machen auch dem einen oder anderen so viel
Freude wie mir.

Viel Spass

Gruß Sven

[Karsten D. (karstendonat)]

Hi Sven,

hab Dein Programm mangels Zeit noch nicht getestet. Aber Du schreibst 
Com1-Com15. Falls Du auch höhere Ports unter Windwos ansprechen willst, 
kannst Du dass über

\\.\COM120

für COM120 usw.

Ciao

Karsten

[Sven (Gast)]

> hab Dein Programm mangels Zeit noch nicht getestet. Aber Du schreibst
> Com1-Com15. Falls Du auch höhere Ports unter Windwos ansprechen willst,
> kannst Du dass über
> \\.\COM120

Dieses Problem tritt schon bei Comport 10 und höher auf.
Du beziehst Deine Informationen auf die Programmierung mit
CreateFile().....

Unter CSharp verhält sich das etwas anders, da die Net Laufzeitumgebung 
benutzt wird. Sei doch so nett und teste einfach mal das Programm....
Du wirst dann feststellen, das auch Port xx geht. ;-)

Gruß Sven

[Werner A. (homebrew)]

Hallo,
wenn ich im 1Wire Modus z.B. den INT0 als Eingang nehme und in meiner 
Software einen Reset auslöse, wenn auf dem Port was reinkommt, würde der 
Controller automatisch einen Reset ausführen, wenn ich fboot neu starte?

[Peter D. (peda)]

Werner A. wrote:
> Hallo,
> wenn ich im 1Wire Modus z.B. den INT0 als Eingang nehme und in meiner
> Software einen Reset auslöse, wenn auf dem Port was reinkommt, würde der
> Controller automatisch einen Reset ausführen, wenn ich fboot neu starte?

Ja, kann man machen.


Peter

[Peter D. (peda)]

Anbei die neue Version V2.0

Da bei den ATmega nur vom Bootloaderbereich geflasht werden kann, habe 
ich nun nen API-Call hinzugefügt.

Die Applikation kann diesen aufrufen, um eine Page im Flash zu 
beschreiben.
Das Überschreiben des Bootloaders wird abgewiesen.
Die Applikation muß aber selber drauf achten, daß sie sich nicht 
überschreibt.

Die Zieladresse ist 3 Byte lang, damit auch AVRs >64kB komplett genutzt 
werden können.
Die Zieladresse ist in Bytes anzugeben und muß auf dem Pageanfang 
liegen.
Werden weniger Daten als eine Page geschrieben, ist der Rest 
undefiniert.


Das File "apicall.c" enthält den Aufruf mit Parameterübergabe für den 
AVR-GCC (WINAVR).


Peter

[Bernhard (Gast)]

@PEDA

Hey Peter,

funktioniert 1a.

FRAGE: Wie sieht es mit der Lizenz aus?
Habe deinen Bootloader mal experimentell für mein Diplomarbeitsthema mir 
eingebunden, aber ist das überhaupt rechtens oder unter welcher Lizenz 
läuft er?

MfG Bernhard

[Peter D. (peda)]

Bernhard wrote:

> FRAGE: Wie sieht es mit der Lizenz aus?
> Habe deinen Bootloader mal experimentell für mein Diplomarbeitsthema mir
> eingebunden, aber ist das überhaupt rechtens oder unter welcher Lizenz
> läuft er?

Der Bootloader ist im Sinne der GPL frei verwendbar.

http://www.gnu.org/licenses/gpl.html


Peter

[Psiyou .. (Gast)]

Hallo,

verzweifel hier gerade etwas :(
Versuche den Bootloader auf einem Mega32 zu laufen zu bekommen. Haben 
hier ja auch schon mehrere geschafft, nur bei mir hakt es.

Habe die Version 2.
in fastload.h habe ich die Frequenz geändert.

.equ  XTAL = 16000000  ; 8MHz, not critical ->16MHz

in bootload.asm
.include "m32def.inc" als einziges include nicht auskommentiert
Pins (wie Hardware RS232):

.equ    STX_PORT        = PORTD
.equ    STX             = PD1
.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0

Kompiliert (avrasm2.exe und m32def.inc ins Bootloader Verzeichnis 
kopiert)

E:\fastload\BOOTLOAD>avrasm2.exe -fI BOOTLOAD.ASM
AVRASM: AVR macro assembler 2.1.17 (build 435 Apr 10 2008 09:27:55)
Copyright (C) 1995-2008 ATMEL Corporation

BOOTLOAD.ASM(32): Including file 'm32def.inc'
BOOTLOAD.ASM(64): Including file 'fastload.inc'
fastload.inc(8): Including file 'fastload.h'
fastload.h(2): Including file 'compat.h'
fastload.h(3): Including file 'protocol.h'
fastload.inc(23): Including file 'watchdog.inc'
fastload.inc(32): Including file 'abaud.inc'
fastload.inc(33): Including file 'password.inc'
fastload.inc(45): Including file 'command.inc'
command.inc(68): Including file 'message.inc'
command.inc(71): Including file 'verify.inc'
command.inc(75): Including file 'progmega.inc'
fastload.inc(46): Including file 'uart.inc'
fastload.inc(59): Including file 'apicall.inc'

ATmega32 memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x007c00 0x008000    472     20    492   32768   1.5%
[.dseg] 0x000060 0x000460      0   1024   1024    2048  50.0%
[.eseg] 0x000000 0x000000      0      0      0    1024   0.0%

Assembly complete, 0 errors. 0 warnings

Wenn ich das File mit PonyProg öffnen beginnt der Bootloader bei 0x7C00 
bis ungefähr 0x7DF0. Ansonsten sind alles 0xFF bis auf die letzten 
beiden Byte (0x7FFE-0x7FFF).

Fuse: BOOTSZ: 11 (256Words), BOOTRST: 0 so wie für Externen Quarz 
(16MHz) CKSEL:1111 SUT:11
Mit PonyProg also nur ein Haken bei BOOTRST
SPIEN ist auch 0 (Grau hinterlegt mit Haken, wohl durch JTAGEN:0)
OCDEN ist ebenso 0, restlichen fuse sind alle 1.

Spiele ich diese mit PonyProg auf und führe fboot aus, scheint auch 
alles zu klappen:

E:\fastload\FBOOT>FBOOT.EXE /C1 /tar.hex /b9600
COM 1 at 9600 Baud: Connected
Bootloader V2.0
Target: 1E9502 ATmega32
Buffer: 1024 Byte
Size available: 31744 Byte
CRC: o.k.
Elapsed time: 0.27 seconds

Das lässt sich beliebig oft wiederholen (kein warten auf Reset). Lese 
ich das Flash wieder aus ist da nur der Bootloader drin. Unterschiedet 
sich aber am Anfang und Ende (siehe Anhang).

Hat jemand eine Idee was ich da die ganze Zeit falsch mache?
RS232 funktioniert mit Testprogramm über ISP aufgespielt in beide 
Richtungen (Echo).

Was mich noch wundert ist, dass im Datenblatt in Tabelle 99 steht das 
die Bootloader Flash Section von 0x3F00-0x3FFF geht. Wie passt das den 
mit den 32k Flash zusammen ? (0x8000)

Gruß

[Peter D. (peda)]

Psiyou ... wrote:
>

> E:\fastload\FBOOT>FBOOT.EXE /C1 /tar.hex /b9600
>

Muß heißen:

E:\fastload\FBOOT>FBOOT.EXE /C1 /ptar.hex /vtar.hex /b9600


Peter

[Hagen R. (hagen)]

>die Bootloader Flash Section von 0x3F00-0x3FFF geht. Wie passt das den
>mit den 32k Flash zusammen ? (0x8000)

1 Word = 2 Bytes, der FLASH ist Word basiert, musst die Werte *2 nehmen.

Gruß Hagen

[Psiyou .. (Gast)]

Hi,

und erst mal vielen Danke !! Was für ein blöder Fehler, Sorry. Hab das P 
irgendwie immer zum filename zugezählt... :(

Leider klappt es immer noch nicht, jetzt schlägt die Validierung fehl. 
Lese ich das Flash aus ist da nur der Bootloader drin.

E:\fastload\FBOOT>FBOOT.EXE /c1 /ptar.hex /vtar.hex /b9600
COM 1 at 9600 Baud: Connected
Bootloader V2.0
Target: 1E9502 ATmega32
Buffer: 1024 Byte
Size available: 31744 Byte
Program tar.hex: 00000 - 002AA successful
Verify tar.hex: 00000 - 002AA failed!
Verify-Error

@ Hagen Re
Ah, danke. Dann kommt das ja genau hin :)

[Sven (Gast)]

Nimm doch bitte mal zum Test die Version 1.8 oder 1.9.

http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1008&item_type=project

Die sind bei mir beide auf ATMega16 gelaufen oder laufen ;-).
Zur neuen Version 2.0 kann ich leider nichts sagen,
da ich aus Zeitmangel noch keinen Aufbau mit Mega32 habe.

Gruß Sven

[Psiyou .. (Gast)]

Hallo,
auch mit 1.8 und 1.9 das Problem:

E:\fastload_v18>FBOOT18.EXE /c1 /ptar.hex /vtar.hex /b9600
COM 1 at 9600 Baud: Connected
Bootloader V1.8
Target: 1E9502 ATmega32
Buffer: 1024 Byte
Size available: 31744 Byte
Program tar.hex: 00000 - 002AA successful
Verify tar.hex: 00000 - 002AA failed!
Verify-Error

Habe mal mitgeschnitten was über die Schnittstelle geht (für V1.8).
Kommunikationsablauf (zusammengefasst, komplett im Anhang):

     > PC
       < Bootloader  
> Passwort senden (Mehrfach)
  < Connect Bestätigung (Mehrfach)
> CMD Check crc C5 71
  < FAIL
> CMD revision
  < Answer 18 ok
> CMD signature
  < Answer 01 1E 95 02 ok
> CMD buffersize
  < Answer 03 04 00 ok
> CMD userflash
  < Answer 04 00 7C 00 ok
> CMD Check crc F3 BE
  < ok
> CMD program [...data...] CMD escape_shift
  < ok
> CMD verify [...data...] CMD escape_shift
  < FAIL
> CMD esc_shift CMD CMD CMD start
  < badcommand

Hat jemand eine Idee was ich da falsch mache?

Was ist mit dem erstem CRC der fehlschlägt?
Signatur stimmt (mega32), Buffersize und Userflash kann ich leider nicht 
beurteilen, fehlt mir noch der Durchblick.
Dann werden die Daten gesendet, die Überprüfung schlägt aber fehlt. Lese 
ich das Flash per ISP aus, stehen keine Daten drin.
Die Befehle nach dem Fail sind mir leider auch nicht klar.


Gruß

[Peter D. (peda)]

Psiyou ... wrote:
> Leider klappt es immer noch nicht, jetzt schlägt die Validierung fehl.
> Lese ich das Flash aus ist da nur der Bootloader drin.

Tja, was soll ich sagen.
Der Mega16 klappt, der Mega644, der Mega168.

Aber der Mega32 nicht.

Ich meld mich dann wieder.


Peter

[Pier S. (bigpier)]

Hallo ,

ich habe gerade diesen tollen Bootloader ausprobiert und habe 
anscheinend einen bzw mehrere Fehler  gemacht , aber ich bin mir sicher 
das mir jemand helfen kann !
-Also ich verwende einen Atmega 8 und benutze orginale Uart pins !
-Das asm File habe ich soweit notwenig umkommentiert kompiliert und 
geflasht
-Fuse Bit gesetzt wie im Bild (Anhang)
-Habe ein kleines Programm geschrieben Blinkled (natürlich getestet)
-dieses Program wollte ich nun mit dem Bootloader flashen aber das 
Program leuft nicht auch nach mehreren resets !

Vielen Dank im voraus

Gruss

Pier

[Pier S. (bigpier)]

Mit dem Anhang hat es nicht richtig geklapt !!

[Pier S. (bigpier)]

Hallo vergesst meine letzten beiden Einträge ich Dussel hab das 
DosProgramm mit den falschen Parametern betrieben Fuktioniert wunderbar 
Danke trotzdem !!!

[Peter D. (peda)]

Pier S. wrote:
> Mit dem Anhang hat es nicht richtig geklapt !!

fboot /pfilename /vfilename


Peter

[Peter D. (peda)]

Peter Dannegger wrote:
> Aber der Mega32 nicht.
>
> Ich meld mich dann wieder.

Es hat ein = Zeichen in der fastload.h gefehlt und dadurch wurde die 
Startadresse beim Mega32 falsch berechnet.


Peter

[Psiyou .. (Gast)]

Vielen Dank Peter,

werde das gleich mal probiert.
Habe das vorhin auch mit einem mega8 probiert (V2) da ging es auch ohne 
Probleme.

[Psiyou .. (Gast)]

Danke noch mal für das tolle Programm Peter !! Und das Du hier so aktiv 
bei der Problemsuche mitmachst.
Ist echt super :)
Mit v2.1 lief es auf dem mega32 auch sofort :)

Gruß

[Kai (Gast)]

Hi,

toller Bootloader.
Hab den mal mit meinem ATmega8 probiert. Erste mal aufspielen ging ohne 
Probleme. Danach sagt er immer "COM 2 at 19200 Baud: Connected (One 
wire)" obwohl ich mit rs232 dran bin. Hab leider kein Flag für den 2 pin 
mode gefunden. Gibt es den? Bzw kann jemand sagen warum das nicht 
klappt?

Hab es mit Version 2.1 probiert.

greets

[GastABC (Gast)]

>Hab leider kein Flag für den 2 pin mode gefunden.
>Gibt es den? Bzw kann jemand sagen warum das nicht klappt?

Du musst in der Bootload.asm die Zeilen

.equ    STX_PORT        = PORTD
.equ    STX             = PD1

.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0

an deine gewünschten Ein- und Ausgabeports anpassen. Sind beide Pins 
gleich, so wird der OneWire-Modus aktiviert. Steht im Artikel [[AVR 
Bootloader FastBoot von Peter Dannegger]] besser beschrieben also von 
mir jetzt. :)

[Kai (Gast)]

@ GastABC
Ja, schon richtig. Habe ich auch so gemacht. Und wie ich oben schon 
geschrieben habe geht das auch. Allerdings nur beim ersten mal wenn der 
Flash noch leer ist (er also alleine in den Bootloader springt). Habe 
ich schon ein Programm mit dem Bootloader hineingeschrieben (läuft auch 
prima usw) und muss den uC reseten um  in den Bootloader zu kommen geht 
es halt nicht mehr mit oben genanntem Fehler.
Gehe mal davon aus das fboot aus irgendwelchen Gründen denkt es ist 
oneWire. Konnte die Stelle im Code nur leider nicht finden, bzw soweit 
interpretieren das ich das selbst beheben kann.

[Sven (Gast)]

@Kai (Gast):

Der ATmega8 läuft 100% mit Version 1.8 oder 1.9.
Habe beide ATMega8 ATMega8L und ATMega16 getestet.

1. Hast Du den Watchdog an ?
2. Normalerweise kommt der beschriebene Fehler wenn
   die Einstellungen für BOOTSZ nicht stimmen.

   BOOTSZ muss auf 10 gestellt werden für 256 Worte

   --> BOOTSZ0 = 0
   --> BOOTSZ1 = 1

Hoffe das hilft.

Gruß Sven

[Peter D. (peda)]

Kai wrote:
> @ GastABC
> Ja, schon richtig. Habe ich auch so gemacht. Und wie ich oben schon
> geschrieben habe geht das auch. Allerdings nur beim ersten mal wenn der
> Flash noch leer ist (er also alleine in den Bootloader springt).

BOOTRST nicht enabled?


Peter

[Andreas B. (andreasb)]

Hallo zusammen

Ich habe mal wieder versucht die aktuelle Version von FBOOT auf Linux zu 
portieren (Version 2.1), ich habe dafür einige Teile komplett neu 
geschrieben...

Mir ist das auch Teilweise schon gelungen:

./bootloader -v project.hex
=================================================
BOOTLOADER, Target: V2.1
=================================================
Device  : /dev/ttyS0
Baudrate: 115200
Verify  : project.hex
-------------------------------------------------
Waiting for device... Press CTRL+C to exit. -
Connected!
Bootloader V2.1
Target: 1E9403 ATmega16
Reading device information failed!
CRC enabled and OK
Reading project.hex... File read.
Verify project.hex: 00000 - 00BF3 failed!

Mein Problem: sendcommand(REVISION), bzw. sendcommand(SIGNATURE); 
funktionieren immer, sendcommand(BUFFSIZE); und sendcommand(USERFLASH); 
nie. Die Reihenfolge ist komplett egal, die beiden letzten geben immer 
einen Timeout.
Die Definitionen sind kopiert vom FBOOT.
Gibt es da irgend einen Unterschied der beachtet werden muss? Bei allen 
4 Commands erwarte ich 4Bytes als Antwort (long), habe ich auch kopiert 
vom FBOOT, und es funktioniert ja auch bei dem Device und der Version.

Der Bootloader FBOOT kriegt alle Informationen korrekt, Hardware Fehler 
ausgeschlossen.

ps. ich hänge den Code noch nicht an, da er nicht fertig ist und da der 
Fehler wahrscheinlich nicht offensichtlich ist, wenn jemand den Code 
haben will kann er kurz ein Benutzernachricht schreiben.


mfg Andreas

[L. S. (lschreyer)]

Ich habe auch den Fastboot im Einsatz, und bin echt begeistert. Super
einfach, lief auf Anhieb. Vielen Dank dafür!

Jetzt habe ich noch eine Frage: Gibt es eine Möglichkeit, die Software
die man darüber in den Controller lädt, zu schützen? Es würde schon
reichen zu verhindern, dass eine andere als meine Software da rauf
geladen wird.

Hintergrund ist: Das Gerät, um dass es geht, ist eine Bergungselektronik
für Modellraketen. Mit dem Bootloader könnte jeder seine eigene Software
dort reinladen. So kann man nie sicher sein, dass jemand mit dem
Original fliegt oder seine eigene Software, die evtl. nicht sicher ist,
damit testet. Abstürze gehen dann auf meine Kappe, was ich nicht möchte.
Ich müsste sicher stellen, dass niemand dort seine Software hineinlädt, 
aber trotzdem meine Updates laden kann. Ist das möglich?

Louis

[Peter D. (peda)]

Andreas B. wrote:

> Gibt es da irgend einen Unterschied der beachtet werden muss? Bei allen
> 4 Commands erwarte ich 4Bytes als Antwort (long), habe ich auch kopiert
> vom FBOOT, und es funktioniert ja auch bei dem Device und der Version.

Nein.

Das Byte nach "ANSWER" gibt die Länge-1 der Daten an.
3 = 2 Byte
4 = 3 Byte


Peter

[Peter D. (peda)]

L. Schreyer wrote:

> Jetzt habe ich noch eine Frage: Gibt es eine Möglichkeit, die Software
> die man darüber in den Controller lädt, zu schützen? Es würde schon
> reichen zu verhindern, dass eine andere als meine Software da rauf
> geladen wird.

Einfach das "Peda" durch ein nur Dir bekanntes Paßwort ersetzen.
Es kann auch länger sein, das abschließende 0-Byte bestimmt das Ende.
Es kann auch Sonderzeichen (1..255) beinhalten.


Peter

[L. S. (lschreyer)]

Hmm, dumm nur, dass ich keinen C-Compiler habe mit dem ich das Fboot neu 
compilieren kann. Irgendeinen Tipp wie ich das am einfachsten 
hinbekomme?

Louis

[Peter D. (peda)]

L. Schreyer wrote:
> Hmm, dumm nur, dass ich keinen C-Compiler habe mit dem ich das Fboot neu
> compilieren kann. Irgendeinen Tipp wie ich das am einfachsten
> hinbekomme?

z.B.:
fboot -iblablablub


Peter

[Frank (Gast)]

>>L. Schreyer wrote:

>> Jetzt habe ich noch eine Frage: Gibt es eine Möglichkeit, die Software
>> die man darüber in den Controller lädt, zu schützen? Es würde schon
>> reichen zu verhindern, dass eine andere als meine Software da rauf
>> geladen wird.

>Einfach das "Peda" durch ein nur Dir bekanntes Paßwort ersetzen.
>Es kann auch länger sein, das abschließende 0-Byte bestimmt das Ende.
>Es kann auch Sonderzeichen (1..255) beinhalten.

Damit musst du dann aber alle Updates auch persönlich machen.

>>Ich müsste sicher stellen, dass niemand dort seine Software hineinlädt,
>>aber trotzdem meine Updates laden kann. Ist das möglich?

Das geht nur wenn du das HEX File das du dem Anwender schickst 
verschlüsselst und dieses erst im Bootloader wieder entschlüsselt wird. 
Möglich ist das, siehe Beitrag "AVR-Bootloader mit Verschlüsselung"

ciu Frank

[L. S. (lschreyer)]

Super, danke!

Louis

[Tobi (Gast)]

Hallo Peter,

ich habe eine Frage zum One Wire.

Kann man die One Wire Verbindug auch für weitere Datenübertragungen 
nutzen.
Ich würde es gerne als RS232 ersatzt nehmen, da ich mir dabei eine 
Leitung spare.

Kennst Du dazu evtl. einen Code in C, oder hast Du selber einen?

Danke in voraus, Gruß Tobi

[Andreas B. (andreasb)]

Hier die neuste Version des Bootloaders für Linux. War ein Fehler in der 
Kommunikation drin, der zum Glück noch vom Benutzer "_ch_" erkannt und 
behoben wurde.


Ich habe das ganze nicht mehr wirklich getestet (Zeitgründe) aber es 
sollte funktionieren, zumindest mit einem ATMega 8.

mfg Andreas

[Martin (Gast)]

Funktioniert der Bootloader auch mit 32768Hz Systemtakt?

[Mark Schmitz (Gast)]

Hallo,

der Bootloader läuft auf mienem Mega8 einwandfrei. Habe jetzt mal mit 
den BOOTSZ Fuses gespielt. Egal wie ich diese Konfiguriere, der 
Bootloader läuft trotzdem wunderbar...wie kann das sein?!

Gruß, Mark

[Peter D. (peda)]

Mark Schmitz wrote:
> der Bootloader läuft auf mienem Mega8 einwandfrei. Habe jetzt mal mit
> den BOOTSZ Fuses gespielt. Egal wie ich diese Konfiguriere, der
> Bootloader läuft trotzdem wunderbar...wie kann das sein?!

Na dann lade mal ne Applikation rein, die bis kurz unter den Bootloader 
reicht, dann  merkst Du den Unterschied.

Leerer Flash enthält 0xFFFF und das wird als NOP ausgeführt.
Wählst Du den Bootbereich größer, werden einfach noch NOPs ausgeführt, 
bis Du den Bootloader erreichst.


Peter

[Mark Schmitz (Gast)]

Hi Peter,

erstmal ein großes Danke für den genialen Loader.

Bei meinem Mega8 habe ich den Loader geflashed. Wenn ich mir den Flash 
Dump ansehe dann erkenne ich, dass der Loader bei 0x1E00 beginnt und bei 
0x1FFF aufhört.

Wenn ich nun aber die Fuses auf eine bootsize von 128 worten einstelle 
dann müsste der AVR beim Booten ja irgendwo mitten im Bootloader Code 
beginnen zu arbeiten. Trotzdem funktioniert der Botloader in deisem Fall 
noch einwandfrei.
Das verstehe ich an der Sache nicht so ganz!? Vielleicht fehlt mir aber 
auch noch der nötige Durchblick :)
Wäre nett wenn du dazu noch was schreiben könntest.

Gruß, Mark

[Peter D. (peda)]

Mark Schmitz wrote:

> Wenn ich nun aber die Fuses auf eine bootsize von 128 worten einstelle
> dann müsste der AVR beim Booten ja irgendwo mitten im Bootloader Code
> beginnen zu arbeiten. Trotzdem funktioniert der Botloader in deisem Fall
> noch einwandfrei.

Ich habs mir nicht genau angesehen.
Vermutlich springst Du in ne Funktion hinein und deren RET holt 0x0000 
vom Stack (SRAM) und dann gehts mit NOP (0xFFFF) irgendwann richtig rein 
in den Bootloader.

Aber sobald ne Applikation drin is, is der Bootloader unerreichbar.


Peter

[Mark Schmitz (Gast)]

Hab mal bissjen mit Applikation experimentiert! Ist natürlich ne 
Applikation mit Endlosschleife :)

Wenn ich die Fuses auf ne Bootsize von 256 Wörtern setze dann 
funktioniert auch mit vorhandener Applikation der Bootloader noch. Wenn 
ich jedoch auf ne Bootsize von 128 Wörtern runtergehe(Bootsz Fuses beide 
unprogrammiert) dann macht der Mega8 keinen Muks mehr und ich muss den 
Bootloader neu Flashen.

Gruß, Mark

[Daniel R. (zerrome)]

hallo,

der "client" für linux von  Andreas B. ist sehr merkwürdig 
(Bootloader21_20080510.tar.gz). erstmal musste ich ihm beibringen, dass 
er mehr als einen atmega8 flashen kann. jetzt ist das problem, dass das 
irgendwie total langsam ist. das braucht fast 2 minuten für einen 
mega168...
hat sich das mal jemand genauer angesehen? ich komm da nicht recht 
weiter.

grüße daniel

[Matthias L. (matze88)]

Anbei mal eine "neue alte" Version der PC Software. Basierend auf der 
letzten Version für Dev-C++ aus diesem Thread habe ich einen Sendepuffer 
eingebaut, welcher bei Verwendung mit USB/RS232 bzw. Bluetooth/RS232 
Adaptern einen massiven Geschwindigkeitsschub bringt.
Wie immer bei mir alles quick&dirty implementiert, aber es funktioniert.

Laut Dateiname gehört das PC Programm zur Version 17 des Bootloaders, 
ich habe damit inzwischen etwa 100x auf einen Mega88 mit der neusten 
Bootloaderversion über Bluetooth geflasht.

Flashzeiten:
~3700 Bytes "Standardversion ohne Buffer" -> ~50-55 Sekunden
~3700 Bytes "Abgeänderte Version mit 64 Bytes Buffer" -> 2,0 Sekunden.

Das ganze bei 38400 bps über Bluetooth. Eventuell ist der Code noch für 
irgendjemanden nützlich. Eine Vergrößerung des Sendepuffers über 64 Byte 
bringt bei mir keinerlei Verbesserungen, ist aber in der fboot17.c ganz 
unten in der Funktion sendenb ganz leicht möglich.

An Peter: Vielen Dank für diesen Bootloader, ich bin wirklich sehr 
zufrieden :-) Noch schöner wäre, wenn er etwas weniger Speicherplatz 
brauchen würde, aber das wird schwer möglich.

[Sven (Gast)]

schau dir den mal an der ist schlanker
Beitrag "AVR-Bootloader mit Verschlüsselung"

gruß Sven

[Matthias L. (matze88)]

Oh, danke. Den behalt ich im Hinterkopf, wenn mein Flash voll ist. Denn 
eigentlich habe ich keine Lust, die ISP Pins nochmal an den blöden TQFP 
mega88 anzulöten (habe mir etwas zu dicken Kupferlackdraht geholt, 
0,3mm, der ist noch zu fest, zu groß, und reißt immer an den lötstellen 
ab). Warum achte ich eigentlich bei meiner µC Auswahl immer so stark auf 
den Preis, obwohl ich laufend das Problem des vollen Flashs habe? 
Ordentliches UserInterface, Uart interface, SD & einfaches Filesystem 
und schwups sind 5-6 kByte voll...

[Peter D. (peda)]

Sven wrote:
> schau dir den mal an der ist schlanker
> Beitrag "AVR-Bootloader mit Verschlüsselung"

Da steht aber das hier:

"je nach Konfiguration zwischen 344 bis 906 Bytes Codegröße, letzters
mit XTEA Entschlüsselungsfunktion"


Es ist völlig egal, ob Du 257 oder 512 Byte für den Bootloader brauchst, 
Du mußt immer volle 512 Byte Bootsektor beim ATmega88 reservieren.

Es macht also keinen Sinn, z.B. auf die Autobaudfunktion zu verzichten.


Peter

[Daniel R. (zerrome)]

hallo,

habe die linux pc version so geändert, dass nun atmegas größer 8kB 
geflasht werden können und das ganz schön schnell.

10kB bei einem mega168 dauert bei mir jetzt 0.97 sec.

grüße daniel

[link (Gast)]

letzte version

21

Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

[link (Gast)]

Ich möchte folgende Vorschläge machen:

"Error, wrong device informations"

sollte heißen

"Error, wrong device information" o.ä.


Mehr Informationen über den verfügbaren Speicherplatz und die Größe des 
Programms:

...
Device: ATxxxx
Available flash memory:  4096 Bytes
Bootloader size:       512 Bytes
Size available: 3582 Byte (wieso eigentlich nicht 3584?)
Program size:     1234 Bytes
Remaining:        4321 Bytes
Flash Usage: 60% total / 50% available

Dankeschön.

[link (Gast)]

So jetzt habe ich mich ausgesperrt - unter welchen Umständen startet bei 
einem ATtiny der bootloader nicht?

[C. H. (_ch_)]

evtl. Falsche Fuses, d.h. beim "Hochfahren" wird NICHT in den Bootloader 
gesprungen!?

Gruß
Christian

[Peter D. (peda)]

link wrote:
> So jetzt habe ich mich ausgesperrt - unter welchen Umständen startet bei
> einem ATtiny der bootloader nicht?

Versuch mal ne andere Baudrate, z.B. 19200 oder 9600.

Du mußt zuerst das PC-Programm starten und danach den AVR resetten bzw. 
einschalten.
Nur wenn noch keine Applikation drin ist, gehts auch andersrum.

Aussperren geht eigentlich nur, wenn die Applikation absichtlich per SPM 
den Bootloader zerstört (nur bei ATtiny / ATmega48 möglich).

Die Resetzeit-Fuses sollten auf die längste Zeit gesetzt sein, damit der 
RC-Oszillator schön stabil eingeschwungen ist.


Peter

[link (Gast)]

hoppla, ich glaube mein usb-seriell-konstrukt war schuld. da habe ich 
den IC wohl umsonst ausgetauscht... :-( danke für die hilfe, wenn's 
läuft ist das klasse. habe das heute zum ersten mal ausprobiert.

[link (Gast)]

nee wohl doch nicht.

Bootloader-Fuses gibt es bei tiny nicht.
Verschiedene Baudraten ausprobiert
AVR über USB (232-wandler) versorgt

8 MHz

.nolist
.include "tn45def.inc"
.equ    STX_PORT        = PORTB
.equ    STX             = PB1
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB0
.include "fastload.inc"

6 PB1 (MISO/DO/AIN1/OC0B/OC1A/PCINT1)
5 PB0 (MOSI/DI/SDA/AIN0/OC0A/OC1A/AREF/PCINT0)

Ich benutze

ISR(PCINT0_vect) und den power-down modus:

static void init(void)
{
PORTB = (1<<1 | 1<<2 | 1<<3 | 1<<4 | 1<<5 ); 
DDRB  = (1<<0);

ACSR  = (1<<ACD);
PRR  = (1<<PRUSI);
  
MCUCR  = (1<<SE) | (1<<SM1);

TCCR0B = (1<<CS02);
TIMSK |= (1<<OCIE0A); 

GIMSK = 1<<PCIE;
PCMSK = (1<<1 | 1<<2 | 1<<3 | 1<<4 | 1<<5 );
}

Mit Reset-Pin hat es (glaube ich) funktioniert.

Gute Nacht

[Sven K. (svenk)]

> Daniel Platte (zerrome)
> Datum: 02.08.2008 16:25
> Dateianhang: bl21.zip (8,2 KB, 21 Downloads)

> hallo,

> habe die linux pc version so geändert, dass nun atmegas größer 8kB
> geflasht werden können und das ganz schön schnell.

Danke, danke. Habe gerade einen Mega8 mit Linux 1Ghz P3 mit 
USB-FTDI232RL
mit 115200b geflasht.
Zeit: 0.4s

Wollte das als Feedback für Daniel geben.
Beim verify braucht er allerdings noch 6 Sekunden.
(werde jetzt aber mal in die sourcen schauen...)

Gruß Sven

[Daniel R. (zerrome)]

hallo,

ich hab höchstens 1 % zu dem linux pc programm beigetragen.
problem war nur das ungepufferte schreiben. das mag die serielle 
schnittstelle nicht, ob linux oder windows.
Matthias Larisch hatte da eine verblüffend einfache idee :)

das problem beim verify könnte warscheinlich noch schlimmer sein, da das 
wieder ungepuffert abläuft. bin da nicht in aller einzelheit 
durchgestiegen.

ungeprüft ist auch immer noch ob wirklich alles 100% genau geschriben 
wird. kann es sein dass wenn hier und da mal ein byte falsch ist, dass 
programm in einigen teilen noch richtig läuft?
den verify teil kann ich nicht richtig debugen...

grüße daniel

[Matthias L. (matze88)]

Ich melde mich nochmal, mit einer vielleicht für manche von euch 
sinnvollen Idee:

Wie rufe ich den Bootloader aus der Applikation auf?

Wie Peter selbst schon sagt, geht das am besten über den Watchdog.

Eine weitere Idee dazu ist: Wenn du den Uart in deinem Programm sowieso 
benutzt und die Möglichkeit hast, kommandobasiert zu arbeiten, lege ein 
Zeichen des Bootloaderpassworts als Kommando dafür fest.

Mein UART Protokoll funktioniert immer so, dass grundsätzlich jedes 
empfangene Zeichen überprüft wird, ob es ein Kommando ist, solange nicht 
bereits ein Kommando empfangen wurde. Dann wird je nach Kommando IMMER 
für jedes weitere Zeichen in den entsprechenden Funktionsblock 
gesprungen. Am Ende der ganzen Geschichte muss dieser Funktionsblock 
selbst dafür sorgen, das Kommando wieder zurückzusetzen.

Der Bootloader wird dann bei mir wie folgt aufgerufen:

#define SUART_CALL_BOOTLOADER     0x50  // First char of bootloader password so
                      // we can switch to bootloader mode with
                      // standard pc programming software

uint8_t suart_receive( void )
{
  uint8_t temp;
  static uint8_t command = 0;
  if(srx_done)  
  {
    temp = sgetchar();
    if(command == 0)
    {
      command = temp;
    }
    switch(command)
    {
      case SUART_CALL_BOOTLOADER:
      wdt_enable(WDTO_500MS);
      while(1){asm("nop");}    // loop here, else we will call this again and again... and nothing happens
      break;
    }
  }
}

suart_receive wird dabei regelmäßig im Mainloop aufgerufen. (Falls 
jemand diese Idee übernimmt: Darauf achten, dass die receive Funktion 
MINDESTENS 1x pro Zeit, die ein Byte im RX dauert, aufgerufen werden 
muss. Ansonsten bitte einen Receive Buffer einbauen.

Was bringt das nun?

Der Bootloader wird simpel durch starten der Programmiersoftware aus der 
laufenden Applikation aufgerufen. Ich benötige das, da mein µC in der 
derzeitigen Anwendung eigentlich niemals resetet wird und ein Power On 
Reset nur durch Entfernen der Batterien möglich sein wird.

Gut, die Idee ist jetzt nichts bahnbrechendes, aber vielleicht hatte sie 
ja irgendwer noch nicht ^^

Matze

[Gast (Gast)]

Ich habe eine Frage zur Verwendung des Bootloaders in einem 
kommerziellen Projekt:

Weiter oben in diesem Thread wird erwähnt, daß der Bootloader unter der 
GPL steht.

Die GPL basiert meines Wissens nach auf 4 Grundprinzipien, die die freie 
Kopier- und Modifizierbarkeit von Software sicherstellen sollen. Sie 
besitzt weiterhin ein Copyleft, d.h. modifizierte Versionen des 
ursprünglichen Quelltextes müssen ebenfalls wieder unter GPL gestellt 
werden. Dieses Copyleft gilt jedoch nicht, wenn ein von mir 
geschriebenes Programm ein GPL-Programm ausschließlich aufruft/verwendet 
(http://www.gnu.org/licenses/gpl-faq.html : „[...] in many cases you can 
distribute the GPL-covered software alongside your proprietary system. 
To do this validly, you must make sure that the free and non-free 
programs communicate at arms length, that they are not combined in a way 
that would make them effectively a single program [...] If the two 
programs remain well separated, like the compiler and the kernel, or 
like an editor and a shell, then you can treat them as two separat“).

Wie sieht die Sache nun bei der Verwendung des Fastboot-Bootloaders zum 
Aufspielen einer separaten, selbst entwickelten Anwendung auf einen AVR 
aus ?

Nach meinem Verständnis handelt es sich in einem solchen Fall um zwei 
separate Programm – den Bootloader und mein eigentliches 
Anwendungsprogramm. Sehe ich das soweit richtig und kann ich den 
Bootloader in dieser Konstellation in einem kommerziellen Projekt 
verwenden, ohne den Quelltext meines Programms offen legen zu müssen 
oder gegen die GPL zu verstoßen ?


Mit freundlichen Grüßen

Lars G.

[Peter D. (peda)]

Gast wrote:

> Nach meinem Verständnis handelt es sich in einem solchen Fall um zwei
> separate Programm – den Bootloader und mein eigentliches
> Anwendungsprogramm. Sehe ich das soweit richtig und kann ich den
> Bootloader in dieser Konstellation in einem kommerziellen Projekt
> verwenden, ohne den Quelltext meines Programms offen legen zu müssen
> oder gegen die GPL zu verstoßen ?

Ja, die Schutzrechte der Applikation sind durch den Bootloader in 
keinster Weise eingeschränkt.


Peter

[Matthias L. (matze88)]

Hallo!

Ich habe eine Frage: Hatte irgendjemand von euch bereits das Phänomen, 
dass der Bootloader sich selbst überschrieben hat? Eigentlich soll/darf 
das ja nicht passieren, bei mir ist es passiert.
Situation kann ich nicht exakt beschreiben, ich sehe aber am Flashdump 
folgendes:
Programm ist 6766 Bytes groß. (edit: es handelt sich um den Mega 88)
Im Flash beginnt ab dem darauffolgenden Byte (1A6E) eine Wiederholung ab 
dem Offset 16AE (Dezimal 5806). Dies geht exakt bis vor den Bootloader 
(Bootstart ist 1E00). Der Bootloader ist dann bis 1F3F korrekt, von 1F40 
bis 1F7F enthält das Flash nur 0xFF und ab 1F80 bis FLASHEND ist wieder 
alles korrekt.

Das Flash war soweit ich mich erinnern kann niemals voller als in dem 
jetzigen Zustand, d.h. diese Wiederholung im Flash kann nicht durch 
einen nicht gelöschten Bereich kommen sondern muss genau so programmiert 
worden sein.

Warum sind mitten im Bootloaderbereich zwei Pages (genau 64 Byte) 
gelöscht?

Ich kann nicht garantieren, dass die serielle Verbindung beim 
Programmieren immer 100% fehlerfrei war (Bluetooth), aber ich hatte NIE 
Programmierprobleme. Außerdem benutze ich die von mir gepostete 
abgeänderte PC Programmversion (außerdem für nen älteren Bootloader), 
was bisher keine Probleme machte, aber vielleicht kommt das ja jetzt 
doch daher?

Vielleicht habe ich auch im C-Code irgendnen Fehler, dass er wie auch 
immer an eine bestimmte Stelle im Bootloader gesprungen ist? (Eigentlich 
habe ich keine selbstimplementierten Sprungtabellen/Funktionszeiger oder 
so) Das würde 2 gelöschte Pages erklären können, niemals aber ein Abbild 
eines Teil des Flashs exakt am Ende der Applikation... (Die funktioniert 
übrigens 100%ig, bis auf noch vorhandene Bugs im Code, also man merkt 
nicht, dass im Flash was durcheinander ist)

Das Problem gemerkt habe ich, als ich eben das Flash neu programmieren 
wollte. Der Bootloader ist nicht mehr angesprungen.

Jemand ne Idee? Ich werde jetzt den Bootloader neu flashen und die 
Bootloader Lock Bits setzen, dann passiert das wenigstens nicht nochmal 
(Scheiss arbeit, die ISP Pins wieder anzulöten, muss dazu die halbe 
Schaltung auseinandernehmen)

cu
Matze

[Peter D. (peda)]

@Matze,

das PC-Programm kann senden, was es will, der Bootloader kann nicht 
überschrieben werden.
Der Bootloader prüft selber direkt vor dem Löschen, ob die Adresse > 
Bootstart ist.

Ich setzte sicherheitshalber immer auch das Brownout-Reset und hatte 
bisher keine Probleme.

Bei den Classic-AVRs weiß ich definitv, daß die gerne mal den EEPROM 
überschrieben hatten, wenn kein sauberes externes Reset gemacht wurde.
Die Classics hatten ja noch kein Brownout-Reset.


Peter

[Malte _. (malte)]

@Matze
Könnte es sein dass dein Programm Pointer Fehler oder einen 
Stacküberlauf hat? Dann könnten auf diese Weise ungültige 
Rücksprungadressen erzeugt werden, die dann zufällig irgendwo in den 
Bootloader verwiesen haben.

[Matthias L. (matze88)]

Malte: Da hab ich ebenfalls dran gedacht. Muss ich nochmal alles genau 
durchgehen.

Peter:
Den Brown Out verwende ich mit Absicht nicht, da ich desöfteren von 
Problemen in Bezug auf Mega88 und Brown Out gelesen hab. Theoretisch hat 
der AVR auch ne Superversorgung: Bisher nur von einer immer geladenen 
Liion hinterm 3,3V Wandler versorgt, Zusammenbruch nur bei Akkuentfernen 
(während dessen er eigtl. nie irgendwas gemacht hat was zur Flash 
veränderung hätte führen können).


Also für mich ist es wohl noch am wahrscheinlichsten, dass ich nen 
Fehler im Programm hab. Mal beobachten.

Matze

[Stefan (Gast)]

Hallo,

ich habe dem ATmega644 mit bereits geflashter Bootloader Version V1.4. 
basierend auf dem Projekt von 
http://www.ulrichradig.de/home/index.php/avr/avr-webmodule

Unter Windows XP funktioniert der Upload neuer Firmware, allerdings nur 
mit der alten Version 1.4 von fastboot (fboot.exe). Aber die fboot17.exe 
konnte keine Verbindung zum µC herstellen. Mir scheint das Version 1.4 
des Bootloaders inkompatibel ist zu neueren Versionen.

Nun habe ich ein ähnliches Problem mit Linux (Debian Etch mit gleicher 
Hardware wie die Versuche mit Windows XP), nur das die Version 1.4 hier 
auch nicht funktioniert.

Verschiedene Varianten habe ich bisher probiert, vielleicht gibt es ja 
einen hilfreichen Tipp von euch.

Versuch 1) Linux_Fast14: (fastbootLinux.tar.gz hier aus diesem Thread)

>> fboot -d/dev/ttyUSB0 -pFIFIsr08.hex
/dev/ttyUSB0 at 115200 Baud: -
Connected
Bootloader V1.4
Target: 1E9609 ATmega644
Buffer: 3584 Byte
Size available: 64512 Byte
reading file... Done.
Program FIFIsr08.hex: 0000 - 0E00 failed !
Elapsed time: 189.01 seconds

Soweit erstmal interessant. Eine Verbindung kommt unter Linux zustande, 
aber irgendetwas funktioniert beim Flashen nicht. Zudem ist die Zeit mit 
fast 190s weit über den 25s die es unter Windows XP braucht.

Versuch 2) Python von 
http://www.kreatives-chaos.com/artikel/fastboot17-frontend-python

>> python bootloader.py -b 9600 FIFIsr08.hex
/dev/ttyUSB0 at 9600 Baud

Es kommt niemals eine Verbindung zustande. Egal ob Reset oder nochmals 
die Spannungsversorgung anschließen...

Versuch 3) bootloader Version 2.1 (bl21.zip hier aus diesem Thread)
>> bootloader -d /dev/ttyUSB0  -p FIFIsr08.hex

=================================================
|           BOOTLOADER, Target: V2.1            |
=================================================
Device  : /dev/ttyUSB0
Baudrate: 115200
Programm: FIFIsr08.hex
-------------------------------------------------
Waiting for device...

Genau wie Versuch 2) denn auch hier kommt niemals eine Verbindung 
zustande.

Was mir als Idee bleibt ist
- neuen Bootloader flashen (da fehlt mir noch die Hardware)
- einen aktuellen Bootloader auf Kompatibilität zu 1.4 bringen (wo ist 
da der Unterschied im Protokoll?)
- wine/qemu etc einsetzen.

Any Comments?

Gruß
Stefan

[Sven K. (svenk)]

Hi,

wenn ich Dich jetzt richtig verstanden habe willst Du den Atmel
unter Linux neu flashen....

Bootloader unter Linux funktioniert mit V1.4. Das ist doch schon mal 
prima.
Die lange Zeit lässt sich damit erklären, das kein Buffer in
der Version V1.4 programmiert wurde. (in der Linux Version V2.1 schon)

Da Du jetzt die Version V1.4 im Atmel hast, würde
ich an Deiner Stelle mal die "Buffer" Stellen in Linux Version V2.1
suchen und in V1.4 ändern.

Dann müsste das programmieren ebenso flott gehen.
Habe leider keine Zeit das genauer zu studieren.

Gruß Sven

[mäxchen (Gast)]

Hallo zusammen.
Ich habe heute schon einige Stunden damit verbracht, indem ich den 
Bootloader zum laufen bringen wollte, aber ich schaff es einfach nicht.

Mein Problem sieht so aus:
Ich habe das Programm version 1.8 mit AVR-Studio compiliert, das ging 
auch fehlerlos. Dann die fuses gesetzt und das Hex-File mit Ponyprog auf 
einen ATmega8 geladen, was auch ging.
Wenn ich jetzt aber das Programm FBOOT 18 auf dem PC öffne, dann steht 
einfach:
COM1 at 115200Baud: /
und der Strich dreht sich.

Als ich dann die Datenkommunikation über die RS232-Schnittstelle mit 
einem RS232-Sniffer angeschaut habe, stellte ich fest, das der uc 
einfach keine Rückmeldung gibt.
Die serielle Schnittstelle ist aber in Ordnung, mit anderen Programmen 
auf dem uc funktionert sie.

Weiss jemand woran das liegen könnte oder kann mir vielleicht ein 
funktionierendes Hex-File für den ATmega8 posten, nur mal zum testen?

Und noch eine Frage: Hier wird überall geschrieben, dass nur 256Bytes 
Speicher gebraucht werden, aber bei mir beginnt das Programm im Flash 
bei 0xE00. Damit der uc bei einem reset nach 0xE00 speringt, muss laut 
Datenblatt 01 ins BOOTSZ-Register, und nicht 10, wie in der Anleitung 
steht?????

Im Anhang sind die Assebler- und Hexdatei und die Fusebiteinstellungen.

[Peter D. (peda)]

@mäxchen

versuch mal ne kleinere Baudrate (-b19200).
Der Bootloader benötigt 256 Words (=512Byte).


Peter

[mäxchen (Gast)]

Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x001e00 0x001fd8    452     20    472    8192   5.8%

Ja es sind nicht ganz 256 Words aber der Bootloader startet bei 0x1E00, 
und das ist laut Datenblatt die Startadresse für 512 Words!! Darum weiss 
ich auch nicht wie ich die Fuses stellen soll, denn bei eingestellten 
256 Words springt er bei einem Reset zu 0x1F00.

[mäxchen (Gast)]

Danke für die Hilfe mit weniger Baud geht es!
Aber woran kann das liegen? Schlecht geschirmtes Kabel?

[Matthias L. (matze88)]

zu langsamer µC? Schlecht geschirmtes Kabel ist unwahrscheinlich.
Ich habe hier 38400 bps auf 8 MHz laufen, aber es sollte noch mehr 
möglich sein. Die 115200 erreichst du eventuell auch erst über 8 MHz? 
Ich weiß es nicht.

[mäxchen (Gast)]

Aha, das kann gut sein. Mein up läuft nämlich auf 4 Mhz.
Vielen Dank für die Hilfe!

[Matthias L. (matze88)]

Das bedeutet dann, du hast nichteinmal 35 Takte pro Bit (4 000 000 MHz / 
115200 bps = 34,x cycles/bit)

Das wird garantiert etwas knapp, sollte theoretisch allerdings gehen.

Hier kommen wir an ein Problem: Der UART Code ist dafür nicht ausgelegt. 
In der abaud.inc wird MINTIME auf 90 definiert, das begrenzt die 
maximale UART Geschwindigkeit auf CLOCK / 90 baud, in deinem Fall also 
44444 baud. Meiner Meinung nach könnte MINTIME noch eine ganze Ecke 
weiter heruntergestellt werden, mit 115200 baud @ 4 MHz dürfte es aber 
in jedem Fall sehr knapp werden, ohne weitere Codeanpassung gar 
unmöglich sein. (Stichwort: Jitter akkumulation, sample Zeitpunkt. 
Spielt derzeit eine untergeordnete Rolle (bzw. ist von Peter ausreichend 
bedacht), aber wenn man wirklich so haarscharf an die Grenze geht muss 
man das exakt beachten).

cu
Matze

[Michael H* (Gast)]

Hallo,

kann es sein, dass der Bootloader eine Software-UART benutzt?
Wie würde es denn mit der Größe ausschaun, wenn man die Hardware-UART 
einsetzt - käme man vielleicht auf 128 Worte?

Danke scho mal,
Grüße, holli

[Peter D. (peda)]

Michael H* wrote:
> kann es sein, dass der Bootloader eine Software-UART benutzt?

Ja das tut er, sonst könnte man ja keinen ATtiny13 benutzen.
Und für die mit UART wollte ich mir nicht zusätzliche Arbeit machen.


> Wie würde es denn mit der Größe ausschaun, wenn man die Hardware-UART
> einsetzt - käme man vielleicht auf 128 Worte?

Ja, mit HW-UART und ohne Autobaud, sollte es möglich sein.

Ich sehe aber nur einen einzigen, wo das etwas bringt, den ATtiny2313.

Alle Megas sind ja bis mindestens 16k zu haben und da sind 1,5% mehr 
kaum der Rede wert.


Peter

[Michael H* (Gast)]

Stimmt eigentlich. Auch die 3% bei den 8k-AVRs sind alles andre als 
tragisch.
Danke für die schnelle Antwort!

Grüße, holli

[Newbie (Gast)]

Hallo,

nachdem nun schon so viele hier den Bootloader erfolgreich einsetzen. 
Vielleicht kann mir bitte einer sagen,

a) welche Fuses müssen wie gesetzt werden (am besten mit Bild ;o) )?
b) wie geschieht später beim Benutzen des Bootloaders hardwareseitig der 
Anschluss an den PC? Kommt da ein Max232 dazwischen, oder werden die 
beiden Pins sozusagen direkt mit der seriellen Schnittstelle des PC 
verbunden?
c) wie kann man damit Werte ins EEPROM schreiben?

Danke.

[Michael H* (Gast)]

Newbie wrote:
> a), b), c)
AVR Bootloader FastBoot von Peter Dannegger

> c) wie kann man damit Werte ins EEPROM schreiben?
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

[Newbie (Gast)]

@Michael H*

Danke für die schnelle Antwort, den Artikel hatte ncih noch nicht 
gesehen.

Aber die Frage c) bleibt trotzdem: WIE kann man damit Werte ins EEPROM 
schreiben? Ich hab's echt noch nicht gefunden/begriffen.

[Malte _. (malte)]

Newbie wrote:
> Aber die Frage c) bleibt trotzdem: WIE kann man damit Werte ins EEPROM
> schreiben? Ich hab's echt noch nicht gefunden/begriffen.
Nicht mit dem Bootloader. Aber es wäre möglich diese durch deine 
Applikation zu schreiben. Notfalls schreibst du zwei Programme das erste 
setzt die EEPROM Werte und dann lädst du dein Hauptprogramm rein. Ist 
zwar etwas umständlich, aber machbar.

[Jan (Gast)]

Ich schaffe es nicht den Loader mit einem 644P zum laufen zu bekommen.
Der ist doch kompatibel zum 644?
Leider kann ich im AVRStudio minimal 512 Worte für BOOTSZ einstellen.
ebenso ist mir nicht ganz klar ob BOOTRST mit oder ohne "Vögelchen" sein 
muss?

[Peter D. (peda)]

Jan wrote:
> Ich schaffe es nicht den Loader mit einem 644P zum laufen zu bekommen.

Setze mal die Baudrate runter, z.B. auf 9600

> Der ist doch kompatibel zum 644?

Includiere die "m644Pdef.inc".

> Leider kann ich im AVRStudio minimal 512 Worte für BOOTSZ einstellen.

Ist o.k.


Peter

[Raimund R. (raimund)]

moin Leute!
- es dreht sich um den atmega8
- Habe den Bootloader 
(http://www.mikrocontroller.net/attachment/24619/fastload_V14.zip) mit 
AVR-STUDIO assembliert (als bootloader und ohne Fehler) und mit PONYPROG 
in meinen atmega8 gebrannt. Ich habe keine Pins verändert oder Baudraten 
oder oder oder...
- FUSE bits gesetzt wie oben beschrieben.
- FBOOT.EXE liegt in
  C:\temp\
- 1.hex (die mit FBOOT zuladende hex) liegt in
  C:\temp\
- mit Befehl
fboot 1.hex

sollte doch eigentlich alles i.O. sein. ABER: es dreht sich die kleine 
Windmühle... das war's auch schon.
Spannungversorgung liegt an, RS232 ist i.O. (sonst hätte PONYPROG nichts 
gemacht)
- mit PONYPROG kann ich 1.hex ganz simpel in den atmega laden  - und das 
kleine program läuft dann auch wie gewünscht.

Peter schrieb zum Beitrag von mäxchen (Datum: 31.08.2008 21:01) die 
Baudrate zu ändern... aber wo?? Hat jemand ein HELP-File für FBOOT?? Ist 
das ein Kommandosatz für FBOOT???

Nach mehreren Stunden habe ich erst einmal aufgegeben...

[Malte _. (malte)]

Ja, der Bootloader ist super, nur die Doku etwas dürftig.
Der Bootloader auf dem AVR erkennt die Baudrate automatisch. Bei dem PC 
Programm wird die Baudrate per Parameter eingestellt (im genannten 
Beitrag angegeben).

[Matthias L. (matze88)]

Mensch Leute, ihr programmiert hier µCs und seid dann nicht in der Lage, 
die paar Codezeilen vom Bootloader mal zu überfliegen?

Bootloader Fastload.h: Bei XTAL ist die vorhandene Frequenz des Megas 
einzutragen. Diese muss nicht genau sein, aber wie genau die 
Auswirkungen sind wenn da 8 MHz steht und der µC nur mit 1 MHz läuft, 
weiß ich nicht.

Bootdelay: Hier kann eingestellt werden, wie lange der µC warten soll am 
Anfang, ob der Bootloader genutzt wird.

PC Software:

Switches: Das ding hat eine eingebaute Hilfe. fboot.exe /? ist der 
AUfruf dafür. Und wenn man das halt mal nicht weiß -> Der Quellcode 
liegt doch bei! Soooo schwierig ist das Prog. ja auch nicht aufgebaut. 
Zumindest die Parameter lassen sich noch ganz gut rauslesen.


Matze


Edit:
Glatt vergessen, was ich sagen wollte:

Wenn der Strich sich einfach nur dreht und sonst nichts passiert, dann 
hast du entweder nen falschen Com-Port ausgewählt, oder dein µC ist 
schon über den Bootloader hinaus. Bei sonst leerem Flash sollte er 
allerdings immer wieder zum Bootloader loopen.... Probier mal am PC ne 
niedrigere Baudrate.

[Raimund R. (raimund)]

Matthias Larisch wrote:
> Mensch Leute, ihr programmiert hier µCs und seid dann nicht in der Lage,
> die paar Codezeilen vom Bootloader mal zu überfliegen?
...
> Switches: Das ding hat eine eingebaute Hilfe. fboot.exe /? ist der
> AUfruf dafür. Und wenn man das halt mal nicht weiß -> Der Quellcode
> liegt doch bei! Soooo schwierig ist das Prog. ja auch nicht aufgebaut.
> Zumindest die Parameter lassen sich noch ganz gut rauslesen.
>
>
> Matze

jeder hat mal 'nen schlechten Montag und meint andere belehren zu 
müssen??
Sorry dass nicht alle sooo schlau sind wie Du!

>
>
> Edit:
> Glatt vergessen, was ich sagen wollte:
>
> Wenn der Strich sich einfach nur dreht und sonst nichts passiert, dann
> hast du entweder nen falschen Com-Port ausgewählt, oder dein µC ist
> schon über den Bootloader hinaus. Bei sonst leerem Flash sollte er
> allerdings immer wieder zum Bootloader loopen.... Probier mal am PC ne
> niedrigere Baudrate.

... ja, nur WIE DAS geht hast Du uns natürlich verschwiegen!!
Geht es auch mal sachlich???

[Matthias L. (matze88)]

Entschuldigung falls das zu mies rüberkam, aber meiner Meinung nach habe 
ich alle benötigten Informationen geliefert, um herauszufinden, was 
gefragt wurde. Geht im übrigen schneller, als hier einen Post 
abzusetzen... Aber dann noch mal vorgekaut:

E:\Projekte\danneger\bootloader\FBOOT>FBOOT.EXE /?
/?               Get this help message
/Bnnnn           Define baud rate
/Cn              Define serial port n = 1..4
/Pname           Perform Program
/Vname           Perform Verify
/Istring         Init string
Press any Key !

Für alle, die des englischen und/oder des denkens nicht fähig sind:

Fboot.exe /B9600 /C!!!!__PORT_DES_COMPUTERS__!!!! 
/P!!!!__EXAKTE_ANGABE_DER_HEX_DATEI__!!!!

dabei muss man !!!!__PORT_DES_COMPUTERS__!!!! noch durch den Com-Port 
des PCs ersetzen, an dem der Programmer hängt. Das ist eine Zahl 
zwischen 1 und 4, ist sie größer aufgrund z.B. eines USB<->RS232 
Adapters, so ist an dieser Stelle das Hobby zu wechseln, da der Aufwand 
(weiter oben im Thread gibts ne geänderte FBOOT die bis Com6 kann) 
vermutlich zu groß ist.

!!!!__EXAKTE_ANGABE_DER_HEX_DATEI__!!!! ist durch den Pfad (inklusive 
Laufwerksbuchstaben) samt Dateiname der Hex-Datei (bitte auch mit 
Dateiendung .hex) zu ersetzen.

Dann wird mit 9600 bps programmiert.

Hinweis: Der Bootloader muss natürlich auch aktiv sein, deshalb direkt 
!NACH! drücken der "Enter-Taste", welche das fboot Programm ausführt 
einmal den µC resetten (FBOOT versucht dauerhaft, den Bootloader zu 
erreichen, bis er Glück hat)


Bitte bitte macht mich jetzt nicht fertig, ich möchte hier niemanden 
persönlich angreifen, nur irgendwie finde ich ist diese Antwort hier 
absolut überflüssig da völlig selbstständig erreichbar (vermutlich geht 
das sogar schneller als das Lesen dieses Posts).

[Raimund R. (raimund)]

Saubere Antwort und super Aufbau! Danke Matthias!!

Werde es an meinem Testplatz heute Nachmittag prüfen!
Habe auch noch einmal das Datenblatt des atmega8 gezückt und werde den 
flash auslesen und prüfen, ob der RESET-Vector auch tatsächlich auf die 
richtige Adresse zeigt. Aus dem Stand heraus würde mir jetzt erst mal 
nichts weiteres einfallen.
Herzlichen Dank für die Beschreibung! (Quellcode guggen hätte mir selber 
einfallen müssen!)
Meine rsr232 geht via isp an den atmega8... und standard brutzeln funzt 
ja...

[Matthias L. (matze88)]

Eine Kleinigkeit ist mir noch eingefallen:

bootload.asm

.equ    STX_PORT        = PORTD
.equ    STX             = PD1

.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0

sind durch die von dir verwendeten Pins für die Bootloader Verbindung 
(Es wird KEIN Hardware Uart verwendet - du kannst zwar die Hardware Uart 
Pins nehmen, aber musst sie explizit hier angeben) zu ersetzen.
Dann dürften keine Probleme mehr auftreten

[Raimund R. (raimund)]

>Eine Kleinigkeit ist mir noch eingefallen:
>
>bootload.asm
>
>.equ    STX_PORT        = PORTD
>.equ    STX             = PD1
>
>.equ    SRX_PORT        = PORTD
>.equ    SRX             = PD0
>
>sind durch die von dir verwendeten Pins für die Bootloader Verbindung
>(Es wird KEIN Hardware Uart verwendet - du kannst zwar die Hardware Uart
>Pins nehmen, aber musst sie explizit hier angeben) zu ersetzen.
>Dann dürften keine Probleme mehr auftreten

also wird der Standard so erst mal nicht funktionieren??
Ich bin re-Einsteiger in asm. Werde die Pins prüfen gg. das Datenblatt!
Das Schaltbild meines Boards habe ich beigefügt.

[Michael H* (Gast)]

Raimund Reh wrote:
> also wird der Standard so erst mal nicht funktionieren??
für deinen mega8 sollten die genau stimmen.
mal ne ganz dumme frage: du löst schon einen reset aus, wenn du flashen 
willst, oder?
und es kommt mir n bisschen so vor, als wär dir der folgende artikel 
unbekannt: AVR Bootloader FastBoot von Peter Dannegger

> Ich bin re-Einsteiger in asm. Werde die Pins prüfen gg. das Datenblatt!
> Das Schaltbild meines Boards habe ich beigefügt.
aah, das schöne pollin-board =)

[Raimund R. (raimund)]

Michael H* wrote:
> Raimund Reh wrote:
>> also wird der Standard so erst mal nicht funktionieren??
> für deinen mega8 sollten die genau stimmen.
> mal ne ganz dumme frage: du löst schon einen reset aus, wenn du flashen
> willst, oder?
> und es kommt mir n bisschen so vor, als wär dir der folgende artikel
> unbekannt: AVR Bootloader FastBoot von Peter Dannegger
>
>> Ich bin re-Einsteiger in asm. Werde die Pins prüfen gg. das Datenblatt!
>> Das Schaltbild meines Boards habe ich beigefügt.
> aah, das schöne pollin-board =)

Grins!
(1) es funktioniert jetzt - hatte noch ein paar Probleme beim 
compilieren mit avr-studio, welche ich aber alleine lösen konnte und auf 
persönliche Dummheit zurückzuführen waren.
(2) es funktioniert mit dem FBOOT18 - mit den Vorgängern konnte ich es 
nicht hinbekommen
(3) POLLIN-Board - hm... ich habe eine Anwendung für dem atmega8 
entwickelt, die verhält sich auf dem PoBo anders als wenn ich den am8 
auf ein Breadboard stöpsel. Obwohl ich alle jumper gezogen.

herzlichen Dank für die kundige Unterstützung!

[Raimund R. (raimund)]

Peter Dannegger wrote:
> Michael H* wrote:
>> kann es sein, dass der Bootloader eine Software-UART benutzt?
>
> Ja das tut er, sonst könnte man ja keinen ATtiny13 benutzen.
> Und für die mit UART wollte ich mir nicht zusätzliche Arbeit machen.
>
>
>> Wie würde es denn mit der Größe ausschaun, wenn man die Hardware-UART
>> einsetzt - käme man vielleicht auf 128 Worte?
>
> Ja, mit HW-UART und ohne Autobaud, sollte es möglich sein.
>
> Ich sehe aber nur einen einzigen, wo das etwas bringt, den ATtiny2313.
>
> Alle Megas sind ja bis mindestens 16k zu haben und da sind 1,5% mehr
> kaum der Rede wert.
>
>
> Peter

die Watchdog Definition im include-file beim m32 scheint anders codiert 
zu sein als beim m64? Ist das beabsichtigt. Habe beim m32 einen 
Compilierungsfehler da er den wdce nicht findet beim m32, der aber z.B. 
beim m64 und m8 vorhanden ist. habe die entsprechende Zeile probehalber 
in der m32 Deklaration aufgenommen und das compilat kommt ohne fehler 
zum Ende. Ich bin mir nicht sicher, ob der m32 dann auch laufen wird. 
Habe auch derzeit keinen um das zu probieren...
Wäre nett eine Info zu bekommen!

[Peter D. (peda)]

Raimund Reh wrote:
> die Watchdog Definition im include-file beim m32 scheint anders codiert
> zu sein als beim m64? Ist das beabsichtigt.

Das mußt Du Atmel fragen.

Deshalb habe ich entsprechende Definitionen eingefügt:

;------------------------------------------------------
;                       redefinitions for compatibility
;------------------------------------------------------
.ifndef WDTCSR
.equ    WDTCSR  = WDTCR
.endif
;---------------------------
.ifndef WDCE
.equ    WDCE    = WDTOE
.endif
;---------------------------

Peter

[Ronny (Gast)]

Hallo zusammen,

zunächst erstmal ein Dankeschön an Peter für den tollen Bootloader. Hab 
ihn der Version 2.1 mit dem ATmega16 schon mehrfach erfolgreich 
eingesetzt und finde es echt praktisch auf dem Target keinen ISP-Header 
mehr auflöten zu müssen.

Leider konnte ich ihn heut morgen allerdings nicht dazu überreden einen 
ATtiny2313 zu beschreiben. Als Software hab ich die letzte hier 
gepostete Linux-Version von fboot verwendet.

Anscheinend befindet sich der Tiny im Dauer-Reset sobald der Bootloader 
geflasht ist. Wenn man dann fboot startet, erkennt es auch gleich den 
Bootloader und schreibt die Applikation anscheinend erfolgreich in den 
Chip.

Startet man anschließend fboot mit der Option -v (verify) dann startet 
SOFORT wieder der Auslesevorgang. Nachdem der Chip gelesen wurde wird
jedoch ein Fehler ausgegeben:

Verify test.elf.hex: 00000 - 000A9 failed!

Wenn man dann mit AVRDUDE den Chip ausliesst, steht auch nur 0xFF im 
Speicher.


Hat schonmal jemand hier erfolgreich einen ATtiny2313 unter Linux mit 
dem Bootloader geflasht?

Woran kann es liegen, dass der Linux-Client meldet dass die Software 
erfolgreich geflasht wurde, anscheinend aber nix geschrieben wurde?

[Bernhard M. (boregard)]

Hi,

welchen Linux-client hast Du verwendet? Two-wire modus?
Falls Interesse besteht, ich habe den Linux Client von Andreas Butti 
"erweitert" (ich glaube, es war nicht seine letzte Version...), im 
wesentlichen habe ich mir den one-wire mode eingebaut...

Im übrigen kannst Du unter Linux auch Peters original DOS-fboot unter 
DOSEMU benutzen... mal testen, obs damit läuft.

Gruß,
Bernhard

[Michael H* (Gast)]

Bernhard M. wrote:
> Falls Interesse besteht, ich habe den Linux Client von Andreas Butti
> "erweitert" (ich glaube, es war nicht seine letzte Version...), im
interessemeld ^^
ich suche noch nach einer möglichkeit, den bootloader schön in ein 
makefile zu packen. mit dosemu hatte ich keinen erfolg.

[Bernhard M. (boregard)]

Na ja, dosemu im Makefile kann ich mir auch nicht vorstellen...

Heute abend kann ich den posten, habe ihn nicht hier.
Ich hab ihn übrigens bei mir auch im Makefile

[Peter D. (peda)]

Ronny wrote:
> Verify test.elf.hex: 00000 - 000A9 failed!

Warscheinlich die SELFPRGEN Fuse.


Peter

[Ronny (Gast)]

Jap, es war tatsächlich die SELFPRGEN Fuse. Nachdem das korrigiert war, 
lief zumindest der Verify einwandfrei durch.

Merkwürdig ist allerdings, dass die Testapplikation (Port-Pin gewackel) 
in der Assembler-Version ordentlich läuft während die GGC-Variante davon 
weiter im Dauer-Reset hängt.

Am C-Programm kann es eigentlich (fast) nicht liegen, per ISP geflasht 
tut sie es nämlich wie erwartet.


Kann es sein dass der GCC irgendwelche Schweinereien mit der 
Interrupt-Vektor-Tabelle anstellt?

Ist halt nur sehr merkwürdig, dass beim Atmega16 auch C-Programme 
problemlos geladen werden...

[Bernhard M. (boregard)]

Hallo,

hier nun der oben erwähnte Linux client source für fboot21.
Ich habe den source von Andreas Butti etwas erweitert, so daß der 
one-wire Modus geht (ging zumindest in der Version die ich hatte nicht) 
und die Übertragungszeiten auch mit USB-Konverter entsprechend sind.
Ausserdem gibts einen Fortschrittsbalken...

Gruß,
Bernhard

[Michael H* (Gast)]

klasse, vielen dank!

[Ronny (Gast)]

Zum Problem mit den ATtiny2313 noch einmal...

Die C-Anwendung die nicht wollte basierte auf einem automatisch 
generiertem Makefile der Code::Blocks IDE. Nachdem ich hier noch einmal 
ein neues C-Projekt angelegt habe, lief das compilierte Programm auf 
einmal.

Sobald ich dazu komme vergleiche ich einmal die beiden Makefiles, 
anscheinend ist in einem eine Option drin welche dem Bootloader nicht 
gefällt bzw. ihn davon abhält in die Applikation zu springen.

Nochmal danke für die schnelle Hilfe und den schönen Bootloader :)

Gruß,

Ronny

[Bernhard M. (boregard)]

Hi,

im Linux-bootloader war noch eine uninitialisierte Variable für die 
Flash-size....
Hier die korrigierte Version.

Gruß,
Bernhard

[Martin Baumann (Gast)]

Hallo zusammen,

ich hoffe mir kann jemand helfen. Ich habe den Fastload V1.4 auf einen 
Mega8515 angepasst. Als grundlage habe ich den M8 genommen.

Das Problem ist jetzt nur, ich kann das Porgramm wunderbar übertragen, 
aber der Bootloader springt nicht in das Programm. Wenn ich dann den 
Reset Knopf drücke springt startet er sofort das Hauptprogramm.

Der Bootloader funktioniert wie erwartet, nach einen Reset ist er 
ansprechbar.

Gruß Martin

[Raimund R. (raimund)]

Martin Baumann wrote:
> Hallo zusammen,
>
> ich hoffe mir kann jemand helfen. Ich habe den Fastload V1.4 auf einen
> Mega8515 angepasst. Als grundlage habe ich den M8 genommen.
>
> Das Problem ist jetzt nur, ich kann das Porgramm wunderbar übertragen,
> aber der Bootloader springt nicht in das Programm. Wenn ich dann den
> Reset Knopf drücke springt startet er sofort das Hauptprogramm.
>
> Der Bootloader funktioniert wie erwartet, nach einen Reset ist er
> ansprechbar.
>
> Gruß Martin

FUSE-Bits richtig gesetzt??
http://www.atmel.com/dyn/resources/prod_documents/doc2512.pdf
hier findest Du alles notwendige, Seite 166, bzw.
Seite 196 für das Flag BOOTRST
Seite 177 für das FLag BOOTSZ0, BOOTSZ1

solltest du das Pferdchenprogramm verwenden sind die Bits jeweils zu 
invertieren

viel erfolg

1. nachtrag
- o.g. gilt natürlich nur für den Bootloader als solchen.

[Martin Baumann (Gast)]

Hallo Raimund,

danke für die Antwort. Die Fuses hatte ich richtig gesetzt. Mittlerweile 
habe ich herausgefunden das die Version 1.4 bei mir nur dann richtig 
funktioniert wenn ich für die Übertragung mit einen USB-zu-Seriell 
wandler benutze, bei einem festverbauten Com Anschluss Startet das 
Programm nicht.

Als Abhilfe benutze ich jetzt die Version 1.7 hier stehen zwar noch 
tests aus, aber erste Tests haben gezeigt das es funktioniert.

Was ich komisch fand, bei der Analyse meines Com Prots musste ich 
festellen, das bei den festverbauten Com Anschlüssen die Übertragung 
nicht mit "A6 05" Abschließt wie es das Protokoll erfordert sondern mit 
"FE".

Gruß Martin

[Dirk W. (bastelator)]

Hallo zusammen,

erst einmal vielen Dank für den genialen Bootloader -- bisher oft 
verwendet und nie ein Problem damit gehabt. Jetzt stehe ich allerdings 
vor einem Rätsel:

- Bootloader auf 10 Attiny25 geflasht, alle Fuses korrekt.
- Zwei Programme darüber installiert, das erste funktioniert wunderbar 
(Taktgeber mit mehreren Frequenzen), lässt sich mehrfach flashen und 
verifizieren.
- Das zweite Programm (Servotester) lässt sich zwar ein mal flashen, 
danach (bei /P und /V) erkennt fboot (Peters .21-er Version) immer 
fälschlicherweise den one-wire-Modus. Das Programm kann ich erst morgen 
testen, da alle verfügbaren Servos noch in der Schule liegen.

1. Frage: Kann man den Modus ausschalten oder könnte jemand das Programm 
mal kurz ohne die Auto-Erkennung kompilieren?

2. Frage: Kann das jemand nachvollziehen? (Hex s. Anhang, Tiny25, 8MHz 
intern, Bootloader-Fuse gesetzt)

Dankbar für Tipps und Anregungen grüßt
Dirk

p.s.: Nutze einen Pl2303-basierten USB-Wandler.
p.p.s.: Problem existiert bei allen Bitraten 1200, 4800, 9600, 19200, 
115200)

[Dirk W. (bastelator)]

Hier das Hex-File

[Dirk W. (bastelator)]

... und hier das .c-File

[Dirk W. (bastelator)]

Nachtrag: Das Programm funktioniert einwandfrei, aber neu flashen 
und/oder verifizieren kann ich über den Bootloader nicht mehr.

Frage(n): Womit kann ich mir denn FBoot für den Rechner sauber 
kompilieren, um die one-wire-Funktion testweise rauszuwerfen? Das Ganze 
wird ja irgendwie über die Variable echocount ermittelt, sehe ich das 
richtig?

Gruß,
Dirk

p.s.: Die Version Bootloader_CSharp_adv_v3 funktioniert problemlos. Bin 
aber leider großer Freund der Kommandozeile/Bash :(

[Peter D. (peda)]

Dirk W. wrote:
> Nachtrag: Das Programm funktioniert einwandfrei, aber neu flashen
> und/oder verifizieren kann ich über den Bootloader nicht mehr.


Es wird geprüft, ob das 1. Zeicehn des Paßworts (Peda), also 'P' 
empfangen wurde. Eventuell mal das P durch ein anderes Zeichen ersetzen, 
der EXE kann man das neue Paßwort auf der Kommandozeile übergeben.

Vielleicht reagiert Deine Applikation so, daß es wie ein Echo erscheint.
Welche Pins hast Du denn als RXD und TXD definiert?
Wie sind diese Pins in Deiner Applikation belegt?
Es sollten Eingänge sein oder nach dem Reset ne Weile inaktiv.


Peter

[Denis (Gast)]

Hallo Dirk,

bei mir erkennt er immer fälschlicherweise One-Wire, wenn ich statt 
einem USB-Adapter den echten  COM-Port mit Max232 verwende, Grund: Der 
Max232 ohne Spannung sendet mir irgendwelchen Müll zurück, solange der 
Bootloader das PW im Endlessloop sendet.

Abhilfe:
Versorgung Max232 und µC trennen, µC erst nach Max einschalten, oder 
Zeit auf 1 sec hochsetzen und direkt nach dem Anklemmen der Spannung das 
Updateprogramm starten.

Ich habe aber auch noch eine Frage an Peter:

Ich bin derzeit dabei mir ein Updateprogramm in VB zu schreiben, um 
längere Dateinamen nutzen zu können, etc.
Ich habe die Kommunikation zwischen deinem Kommandozeilenprogramm und 
dem µC mitgeloggt und versucht genau nachzubilden.
Ich kann auch syncen, Buffergröße, Revision etc. abfragen, aber nach dem 
Senden des ersten Blocks erhalte ich kein A9, woran kann das liegen?

Hier mal zwei Links zu meinen Logs:
Log zwischen Kommandozeilenprogramm und µC: 
http://www.modellbau-regler.de/Sitzung.htm
Log zwischen VB-Programm und µC: 
http://www.modellbau-regler.de/Sitzung_eigene.htm

Für Tipps wäre ich sehr dankbar, ist nämlich ein Klasse Bootloader :-)

Gruß Denis

[Matthias Larisch (Gast)]

Hi!
Bei deinem eigentlichen Problem kann ich dir leider nicht helfen. Aber 
die Kommandozeilenversion unterstützt auch ohne Probleme lange 
Dateinamen und co, eigentlich alles, was das Herz begehrt :-) Im 
Kommandozeilenfenster einfach die ersten 1-2 Buchstaben eingeben und 
dann "Tab" drücken. Dadurch wird der Rest automatisch ergänzt.

Um mehr Com-Ports ansprechen zu können, für eine Linux Version und für 
eine Version mit Schreibcache (-> Schnellerer Transfer bei USB-RS232 
Wandlern) siehe hier im Thread diverse Patches... Die "älteren" PC 
Versionen funktionieren auch problemlos mit neuem Bootloader.

[Denis (Gast)]

Hallo,

mein Problem lag scheinbar daran, dass der Computer zu schnell 
geantwortet hat. Mit einem Sleep() klappt es nun wunderbar.

Eine allerletzte Frage habe ich vor Weihnachten dann aber noch :-)
Wie berechnet sich die CRC?
In der Protokollbeschreibung steht mit dem 16-bit Polynom von A001, aber 
welche Daten/Zahlen nehme ich dafür als Grundlage?
Ich kenne das so, dass man Daten sendet und am Ende die Checksumme. Hier 
wird ja aber ganz am Anfang eine Checksumme gesendet, dann nach dem 
Infos holen nochmal und schlussendlich nach dem Überspielen der Daten 
erneut, darum weiß ich nicht, wie sich diese nun berechnen...

Gruß Denis

[Harry L. (mysth)]

Hallo zusammen,
erstmal ein grosses Lob an Peter!

Ich bin gestern auf dieses Projekt gestossen, weil ich eine 
Flash-write-Routine für die AVRs gesucht hab.

Runtergeladen - angepasst - assembliert - programmiert - LÄUFT!!!

aber was anderes:

Ich bin noch bischen neu bei den AVRs...daher:

Wie ermittel ich in C die erste bzw. letzte freie Adresse im Flash?

Ich wünsch allen frohe Weihnachten!

Harry

[Peter D. (peda)]

Denis wrote:
> Ich kenne das so, dass man Daten sendet und am Ende die Checksumme.

stimmt.

> Hier
> wird ja aber ganz am Anfang eine Checksumme gesendet,

Der Returnstatus wird aber ignoriert.
Das dient nur dazu, die CRC mit 0 zu initialisieren.

> dann nach dem
> Infos holen

damit nicht das alte Programm zerstört wird, wenn hier schon Fehler 
auftreten

> nochmal und schlussendlich nach dem Überspielen der Daten
> erneut,

Das ist der letzte Test.


Peter

[Sven S. (schwerminator)]

Hallo Peter,
ein super Bootloader hast du da geschaffen. Nach ein paar 
Anlaufschwierigkeiten läuft er jetzt perfekt auf einem ATMega644 @8MHz 
über einen FT232RL. Habe ihn auch direkt in mein Programmers Notepad 
integriert. Frohes Schaffen noch...

...und fröhliche Weihnachten :)

[Florian Berger (Gast)]

Hallo!

Komme mit dem Bootloader am Atmega48/48P leider nicht zum Laufen.

So hab ich das ASM File angepasst:

.include "m48def.inc" (hatte auch schon die "m48pdef.inc" verwendet, 
ohne Erfolg)

.equ    STX_PORT        = PORTB
.equ    STX             = PB5    ;MISO Port

.equ    SRX_PORT        = PORTB
.equ    SRX             = PB4     ;SCK Port

Fastload.h ist unverändert, 8Mhz, 333ms Wartezeit

Fuses sind am 48er richtig gesetzt, self program enable sowie interner 
/8 Teiler deaktiviert.

Konnte das Programm ohne Fehlermeldung assemblieren, Terminalverbindung 
wird auch hergestellt. Er überträgt mir jedoch keine Daten, sprich er 
flasht den Mega nicht. Bleibt permanent im Bootloader, und ich kann 
jederzeit über den Terminal wieder verbinden ohne Reset.

C:\DOKUME~1\fb\Desktop\ROBOT-~1\BOOTLO~1\fboot21\FBOOT>fboot /C1 
/b9600/test.hex

COM 1 at 9600 Baud: Connected
Bootloader V2.1
Target: 1E9205 ATmega48
Buffer: 64 Byte
Size available: 3582 Byte
CRC: o.k.
Elapsed time: 0.27 seconds

Flasht nicht :/ Habe einmal ein Programm im Bascom, und einmal mit 
AVR-Studio+WINGCC getestet. Beide Programme werden nicht geflasht.
Ich bin leider etwas ratlos im Moment, vielleicht hat jemand nen 
Denkanstoß für mich? Danke!

[Peter D. (peda)]

Florian Berger wrote:
> Flasht nicht :/

Weil Du ihm nicht sagst, daß er was flashen soll.
Das ist ein Kommandozeilenprogramm:

fboot -pFILENAME.HEX

Und FILENAME = max 8 Zeichen.

"fboot -?" zeigt die möglichen Optionen.


Peter

[Florian Berger (Gast)]

Hallo Peter!

Ich bin ein Idiot :D Danke! Hätt genauer lesen sollen.

[Raimund (Gast)]

Hast Du schon mal den ATMEGA644P-20 mit dem Bootloader betrieben?

[Peter D. (peda)]

Raimund wrote:
> Hast Du schon mal den ATMEGA644P-20 mit dem Bootloader betrieben?

Gibts denn Probleme?

Ich hab nur den ohne P.


Peter

[Raimund (Gast)]

... habe den gerade erst bekommen. Muss noch ein paar andere Dinge 
klären und melde mich, wenn ein erste Ergebnis vorliegt!

[Gast (Gast)]

Hallo,

ich habe mal das PC-Programm in Delphi umgesetzt. Die Bedienung sollte 
eigentlich selbsterklärend sein, deswegen verzichte ich mal auf eine 
weiterführende Beschreibung.

[Gast (Gast)]

Hier noch das Programm inkl. Quelltext und der benötigten ComPort-Lib.

Fehlermeldungen, Feedback etc. gerne auch per Mail, die Adresse steht im 
Quelltext.

[Paulchen (Gast)]

Hallo,

... wollte einmal fragen, wie die Fuses beim Tiny13 eingestellt werden 
müssen beim 1-Draht-Betrieb  (Programmer aus Bascom + STK200 an LPT1)

Danke !

[Peter D. (peda)]

Paulchen wrote:
> ... wollte einmal fragen, wie die Fuses beim Tiny13 eingestellt werden
> müssen beim 1-Draht-Betrieb  (Programmer aus Bascom + STK200 an LPT1)

Selfprog
Der Rest entsprechend Deiner Taktquelle.


Peter

[Abwasch K. (abwaschkoenig)]

Hallo,
im Anhang gibt es eine aktualisierte Version vom UpdateLoader.

Änderungen:
-Anzeige von .hex-Dateien beschleunigt, Sanduhr-Cursor eingebaut (Danke 
an R. Willkomm)
-Speicherüberlauf beim Einlesen von .hex Datein beseitigt (Danke an R. 
Willkomm)
-Fehler beim Auslesen der Signatur und Puffergrößen behoben 
(Kommandozeichen wurden einfach ignoriert, allerdings können diese 
Zeichen auch im Bezeichner der Puffergröße vorkommen, wo sie dann auch 
ignoriert wurden. Dadurch wurde die Größe falsch berechnet)
-Abbrech-Button zum Beenden des Verbindungs-, Programmier- und 
Verify-Modus eingefügt

Eine Bitte hätte ich noch: Selbst nach mehrmaligem Lesen des 
Original-Programms, komme ich nicht dahinter wie das zu verstehen ist:

>Es wird geprüft, ob das 1. Zeichen des Paßworts zurück kommt (Echo).

>Protokoll im Eindrahtmodus:
>In der PC-Software werden die gesendeten Bytes nach einem Kommando >gezählt.
>Erst wenn die gleiche Anzahl Bytes empfangen wurde, werden die >nachfolgenden
>Bytes als Antwort gewertet.
>Davor werden die Bytes ignoriert (nur gezählt).

Werden im 1-Draht Modus sämtliche Daten wieder zurück gesendet und das 
Programm soll dann zählen, ob wirklich alles wieder zurück kommt?
Bis jetzt ignoriere ich diesen Modus in meinem Programm weitestgehend, 
habe es aber auch noch nicht geschafft einen lauffähigen 
1-Wire-Test-Bootloader zu installieren um mir das näher anzusehen.

Vielen Dank & Gruß
vom Abwasch-König ;-)

[Bernhard M. (boregard)]

Leo-andres Hofmann wrote:
> Werden im 1-Draht Modus sämtliche Daten wieder zurück gesendet und das
> Programm soll dann zählen, ob wirklich alles wieder zurück kommt?
> Bis jetzt ignoriere ich diesen Modus in meinem Programm weitestgehend,
> habe es aber auch noch nicht geschafft einen lauffähigen
> 1-Wire-Test-Bootloader zu installieren um mir das näher anzusehen.

Im one-wire mode werden die gesendeten Daten wieder empfangen, da ja 
Sende- und Empfangsleitung miteinander verbunden sind.

Es wird geprüft, ob das erste Zeichen des Passwortes zurückkommt: ist 
dies der Fall, dann geht die PC-Software davon aus, daß der one-wire 
mode verwendet wird.
Im one-wire mode werden die gesendeten Bytes gezählt, der Zähler wird 
beim empfangen erniedrigt; damit wird erkannt, wann das Echo der 
gesendeten Bytes zu Ende ist und Daten vom Controller kommen. D.h. es 
wird nicht gezählt um festzustellen, ob wirklich alles zurückkommt, 
sondern um das Ende des Echos festzustellen..

Ein Trick von Peter für den one-wire mode ist noch, daß der PC am der 
Sequenz zur Baudratenerkennung (und gleichzeitig Passwort, default: 
"peda") ein 0xff sendet. Damit wird an den Controller nur ein Startbit 
gesendet, in das der Controller seine Antwort (0xA0 glaube ich) 
hineinsendet, d.h. der PC sendet 0xff aber auf der Leitung (und damit 
auch wieder im Receiver des PC) erscheint das 0xA0...

Gruß,
Bernhard

[Sascha (Gast)]

@Leo-andres Hofmann
Hi, erstmal fettes lob :)
Hab hier noch ein paar bugs und vorschläge:

- wenn bereits ein anderes prog die schnittstelle benutzt, dann zeigt 
der loader zwar ne fehlermeldung, haengt sich dann aber komplett auf und 
kann nur gewaltsam beendet werden.

- eine option um die hinweise(update wirklich durchfuehren..., schalten 
sie das geraet ...) zu deaktivieren. weil ich benutze den uploader 
hauptsaechlich fuer prototypen flash dann mal schnell hintereinander was 
drauf und da stoeren die meldungen. koennte ja auch ueber ein ini 
eintrag geloest werden.

- bei mir funktionniert die wahl der baudrate nicht?! auch im 
geraetemanager sind 57600 eingestellt, brauch aber fuers programmieren 
von 4kb ca 5min
mit dem c# loader der hier im thread angeboten wird warens nur wenige 
sekunden (der hat aber nen anderen bug). und original fboot laeuft net 
unter 64bit :(

gruss
Sascha

[Dominique G. (dgoersch)]

Hallo zusammen,

bitte habt Verständnis dafür, dass ich nicht den gesamten Thread gelesen 
habe. Ich beschäftige mich gerade zum ersten mal mit dem Thema 
Bootloader und bin auf Peters Bootloader gestossen. In [[AVR Bootloader 
FastBoot von Peter Dannegger]] steht, dass dieser nur COM1-4 
unterstützt. Ist das noch der aktuelle Stand?

Gibt es eine GUI-Alternative zu Peters "fboot"? Vielleicht sogar was im 
Quelltext, was man in eigene Applikationen integrieren kann?

Danke und Gruß
Dominique Görsch

[Sascha (Gast)]

@ Dominique
such hier im thread nach
Bootloader_release_adv_v4.zip oder UpdateLoader_2.1.9.zip (3 threads 
weiter oben ;) )

Sascha

[Dominique G. (dgoersch)]

Danke, werde ich mal testen.

[Michael H* (Gast)]

Dominique Görsch wrote:
> bitte habt Verständnis dafür, dass ich nicht den gesamten Thread gelesen
such doch nach dateianhängen, wenn du dateien suchst...
außerdem gibts noch AVR Bootloader FastBoot von Peter Dannegger

[Dominique G. (dgoersch)]

Michael H* wrote:
> außerdem gibts noch AVR Bootloader FastBoot von Peter Dannegger

Genau auf den Artikel hab ich mich doch bezogen ;)

[Leo-A. Hofmann (Gast)]

@Sascha & Rainer:

Ich schmeiß nur mal schnell eine Vermutung in den Raum, weil ich nicht 
viel Zeit habe. Vielleicht hilft dir das weiter, oder du könntest das 
mal nachprüfen.

Ich verwende die Komponente ComPort 4 (Beta), gibt es bei Sourceforge.
http://sourceforge.net/projects/comport/

Diese Komponente triggert ein Event, wenn der Sendepuffer leer ist.
Nach jedem Byte wartet das Programm, bis dieses Event ausgelöst wurde, 
oder geht nach einem Timeout in eine Fehlermeldung.

Allerdings hat die Komponente auch eigene Timeouts integriert. Ich 
konnte leider noch nicht nachvollziehen, wie das zusammen arbeitet.

Meine Vermutung ist daher, dass der RS232-Adapter entweder garkein Event 
auslöst oder nur sehr verzögert und daher die Wartezeiten zustande 
kommen.
Diese Situation konnte ich leider noch nicht nachvollziehen. Bei mir 
läuft das Programm fehlerfrei mit einem 5€-Logilink-Adapter. 
Programmieren + Verify von 20kb dauert grade mal 1:40 Minuten.

Könntest du mir vielleicht sagen, welchen Adapter du verwendest?
One- oder Two-Wire Modus wäre auch noch interessant, ersterer ist nicht 
bzw. fehlerhaft umgesetzt.

Die Feature-Wünsche werde ich in einer kommenden Version noch umsetzen, 
besten Dank für die Anregungen. Habe per Mail auch noch ein paar Ideen 
bekommen, davon werde ich in jedem Fall noch etwas umsetzen.

Grüße
Leo-Andres Hofmann

[Rainer (Gast)]

@Leo-Andres

Die Zeit von 60 ms/Zeichen wird in der SendChar-Routine verbraucht, d.h. 
gemessen von Rückkehr aus ComPort.WriteStr bis zum Aufruf von 
CalculateCRC. WriteStr beinhaltet eigentlich ja schon ein Timeout, d.h. 
die eigene Timeout-Routine wird nur gebraucht, wenn man auf eine Antwort 
vom Bootloader wartet. Hilft das?

Gruß Rainer

[Sven K. (Gast)]

Servus,

habe mal ein Proof-of Concept Buffer eingebaut und einige Dinge 
geändert:

@Leo-Andres schau es Dir doch mal an...


1. Flashen Mega8 in ca. 2s. (mit FDTI-Wandler)
2. Verify mit Puffer habe ich noch nicht angepasst...
   d.h. man sollte das Verify abschalten wenn es schnell
   gehen soll
3. Hex Datei wird automatisch vor dem nächsten Brennen
   neu von der Festplatte gelesen...
4. Unterstützte Bootloader Version zum Auswählen
   (einige Megas hatten noch die Firmware Version 1.9)
5. Dialog insgesamt verkleinert
   (es gibt noch Menschen die mit 1024x768 auf Bastelrechern arbeiten)
6. Hex Anzeige auf 2.Karteireiter verbannt
7. Stayontop ausgeschaltet; es war so nervig,
   da man auch noch andere Anwendungen unter Windows laufen lässt,
   die unmittelbar nach dem Flashvorgang bedient werden müssen
8. Comport öffnen Fehler beseitigt, falls dieser belegt ist....


Ihr könnt ja mal testen. Hatte jetzt nur ein Mega8 da.

Gruß Sven

[Jörg (Gast)]

Hallo,

ich bin auf der Suche  nach einem Bootloader für den atmega128. ICh habe 
grad den Bootloader von AvrFreaks geladen und wollte ihn ausprobieren. 
In der BOOTLOAD.ASM kann der Bootloader ja für den entspechenden AVR 
angepasst werden. Wo bekomme ich aber die dafür vorgesehene m128def.inc 
her? Wo kann man diese Datei laden bzw. kann sie mir jemand bitte 
schicken?

Vielen Dank für Eure Hilfe
Jörg

[Rainer (Gast)]

Hallo Jörg,

die Files mit den Devicedefinitionen sollten bei der Installation von 
AVR Studio in C:\Programme\Atmel\AVR Tools\AvrAssembler1\Appnotes bzw. 
in C:\Programme\Atmel\AVR Tools\AvrAssembler2\Appnotes abgelegt worden 
sein.

Gruß Rainer

[Dirk R. (mdiri)]

Hallo PeDa,

ich muß dir ein sehr,sehr großes Lob für den Bootloader 
aussprechen....einfach genial.
Hab mal den ganzen Beitrag durchgelesen und danach gleichmal 
ausprobiert...
Alles wunerbar.................so
Dann hät ich da mal noch neh frage....
Gibt es für das Fboot auch schon ein Windowsprogramm ???

super weiter so.

Gruß mdiri

[Dirk R. (mdiri)]

Hallo,

Sorry, hab doch nicht alles gelesen.....es gibt ja ein Windows Programm 
von Sven.

Dirk

[Sascha (Gast)]

@Leo-A. Hofmann
ich verwende keinen Adapter sondern die serielle Schnittstelle meines 
PCs. Bootloader im twowire.

Bisher hatte ich immer den "Bootloader_release_adv_v4" genutzt. Der hat 
aber auch noch nen doofen Bug.

Die UpdateLoader Version von Sven K. ist zwar schnell, dafuer tuts 
nacher aber net^^

Sascha

[Sascha (Gast)]

hab Fboot17-Dev-Cpp.zip von Bingo genommen mit fboot21 kombiniert und 
nen bug entfernt.
Ist jetzt halt 20mal so gross wie die Orginal, aber dafür tuts endlich 
unter 64Bit. Jippi

[Bingo (Gast)]

Nur einer info

Ich habe einer neues Linux / MAC-OSX implementierung von die PC-loader 
sehen hier.

http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_type=project&item_id=1927

mfg

Bingo

[Patrick S. (abaddon1979)]

Hallo,
ich versuche mich gerade mit dem Atmega32 und dem Bootloader aus dem 
Verzeichnis fboot21.zip.
Nun dies ist mein erster Versuch mit einem Bootloader und leider ist er 
auch gleich gescheitert.
Mein Vorgehen:
1. zip Datei entpackt
2. PDF Datei von Peter Dannegger gelesen
3. Aus meinem AVR-Verzeichnis die avrasm32.exe und die m32def.inc in das 
Bootloader Verzeichnis kopiert
4.Bootload.asm verändert:
4.1 Semikolon vor m32def.inc entfernt.
4.2 Pins deklariert(waren die gleichen Pins da ich den Hardware UART 
nutze)
5.CMD geöffnet (vorsichtshalber über eine .bat um die Fehler 
mitzuschreiben(avrasm32.exe -fI BOOTLOAD.asm > avrasm.txt))

Und leider waren in dieser Textdatei doch eine ganze Menge Fehler

Creating   'BOOTLOAD.hex'

Assembling 'BOOTLOAD.asm'
Including  'm32def.inc'
Including  'fastload.inc'
Including  'fastload.h'
Including  'compat.h'
Including  'protocol.h'
Including  'watchdog.inc'
Including  'abaud.inc'
Including  'password.inc'
Including  'command.inc'
Including  'message.inc'
Including  'verify.inc'
Including  'progtiny.inc'
Including  'uart.inc'

boatload.asm(52):warning: A .db segment with an odd numberof bytes is detected. A zero Byte is added.
protocol.h(1) : error : Syntax error
protocol.h(2) :  error : Syntax error
protocol.h(3) :  error : Syntax error
protocol.h(16) :  error : Syntax error
protocol.h(17) :  error : Syntax error
protocol.h(18) :  error : Syntax error
protocol.h(25) :  error : Syntax error
fastload.h(82) :  error : Symbol is already already defined by the .equ directive
fastload.h(112) : error : undefined variable referenced
fastload.inc(36) :  error : undefined variable referenced
command.inc(14) :  error : undefined variable referenced
command.inc(37) :  error : undefined variable referenced
command.inc(53) :  error : undefined variable referenced
message.inc(20) :  error : undefined variable referenced
verify.inc(25) :  error : undefined variable referenced
progtiny.inc(15) :   error : undefined variable referenced
progtiny.inc(55) : error : illegal argument type of count
progtiny.inc(56) : error : illegal argument type of count
progtiny.inc(85) :   error : undefined variable referenced
uart.inc(45) :   error : undefined variable referenced
fastload.inc(52) :  error : operand expected
fastload.inc(53) :  error : Syntax error
fastload.inc(54) :  error : Syntax error
fastload.inc(55) :  error : Syntax error
fastload.inc(56) :  error : Syntax error
Assembly complete with 25 errors

Deleting   'BOOTLOAD.hex'

Ich kann mir nur vorstellen das ich etwas vergessen habe, da diese 
Version hier im Forum mit einem Atmega32 schon erfolgreich getestet 
worden ist.

Über Hilfe würde ich mich sehr freuen.

[Peter D. (peda)]

Patrick Ries wrote:
> 3. Aus meinem AVR-Verzeichnis die avrasm32.exe und die m32def.inc in das
> Bootloader Verzeichnis kopiert

Das ist der alte, Du mußt avrasm2 nehmen.
Das Include nicht kopieren, das findet er selber (das alte löschen).


Peter

[Patrick S. (abaddon1979)]

Hmm... das finde ich merkwürdig, habe AVR-Studio ganz frisch runter 
geladen(vor zwei Tagen).....und da ist auch nur diese .exe drin......

[Patrick S. (abaddon1979)]

Peter Dannegger wrote:
> Patrick Ries wrote:
>> 3. Aus meinem AVR-Verzeichnis die avrasm32.exe und die m32def.inc in das
>> Bootloader Verzeichnis kopiert
>
> Das ist der alte, Du mußt avrasm2 nehmen.
> Das Include nicht kopieren, das findet er selber (das alte löschen).
>
>
> Peter

JAJA wie sagt man so schön:"Augen auf beim Eierkauf". Ich danke dir 
Peter, funktioniert jetzt bestens.....

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

BOOTLOAD.asm(32): Including file 'C:\Program Files\Atmel\AVR Tools\AvrAssembler2\Appnotes\m32def.inc'
BOOTLOAD.asm(64): Including file 'fastload.inc'
fastload.inc(8): Including file 'fastload.h'
fastload.h(2): Including file 'compat.h'
fastload.h(3): Including file 'protocol.h'
fastload.inc(23): Including file 'watchdog.inc'
fastload.inc(32): Including file 'abaud.inc'
fastload.inc(33): Including file 'password.inc'
fastload.inc(45): Including file 'command.inc'
command.inc(68): Including file 'message.inc'
command.inc(71): Including file 'verify.inc'
command.inc(75): Including file 'progmega.inc'
fastload.inc(46): Including file 'uart.inc'
fastload.inc(59): Including file 'apicall.inc'

ATmega32 memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x007e00 0x008000    472     20    492   32768   1.5%
[.dseg] 0x000060 0x000760      0   1792   1792    2048  87.5%
[.eseg] 0x000000 0x000000      0      0      0    1024   0.0%

Assembly complete, 0 errors. 0 warnings

Nachher, wenn ich zuhause bin, werde ich es gleich mal ausprobieren.

[Trax X. (trax)]

Hi,
habe versuch den bootloader zu benutzen leider funtzt da bei mir was 
nicht,
ich habe einen Atmega 644 auf einem Polim board mit 16 MHz.

Gibt es da irgendwo eine schritt für schritt anleitung wie man das 
benutzt?

have bis jetzt das file assembliert und von 8 auf 16 MHz im code 
geändert, leider hat das nicht geholfen, hier: 
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger 
sheht man soll 256 Worte für den bootloadre in den fuses einstellen, 
aber laut http://www.engbedded.com/fusecalc/ ist das kleinste bei dem 
644 sind 512 worte.

PS: zum progen benutze ich pony prog

Danke schon mal im vorras
Trax

[Rocken (Gast)]

Hi,
ich habe auch ein Problem mit dem Bootloader von Peter
Ich hatte ihn schon eine ganze Weile erfolgreich mit
dem  ATmega162 und anderen benutzt. Jetzt wollte ich ihn wieder
anpassen für den ATmega325...wieder ganz normal die
Ports geändert, die Taktfrequenz ist gleich geblieben,
und dann per ISP übertragen. Leider antwortet der
Bootloader nicht auf die Signale der fboot.exe.

Die Hardware funktioniert: in eigenen Programmen kann
ich per RS232 Daten zum PC übertragen.
Mit dem Oszi kann ich auch das Signal vom fboot abfangen
wie es zum ATmega geht.
Fuses sollten alle ordentlich gesetzt sein.

Hat jemand Ahnung warum es nicht funktionieren könnte?
ich musste ja die M325def.inc per Hand zur Bootload.h hinzufügen.
Kann es sein, dass der Bootloader den Chip nicht unterstützt?

Hab die Bootloader Versionen 1.7, 2.0 und 2.1 durchprobiert

Vielen Dank für die Hilfe

Rocken

[Peter D. (peda)]

Rocken wrote:

> und dann per ISP übertragen. Leider antwortet der
> Bootloader nicht auf die Signale der fboot.exe.

Welchen Takt hast Du eingestellt?
Probier mal ne kleinere Baudrate.
Stimmen die UART-Pins?

Das Assemblerlisting für den M325 sieht o.k. aus, aber ich hab keinen 
Chip zum Testen.


Peter

[Rocken (Gast)]

Ich habe XTAL auf 11059200 Hz gesetzt (entsprechend dem externen Quarz)

Baudraten habe ich schon sämtliche durchprobiert.
(mit 19200baud hatte ich sonst immer gute Ergebnisse)

Die UART Pins stimmen (PE0, PE1); ich hab mir ein echo-Programm 
geschrieben,
dass die UART konfiguriert und mir ein gesendetes Char vom Rechner
zurückschickt..und es funktioniert.

Hab jetzt den Bootloader von Hagen probiert (AVR-Bootloader v1.0)
auch dieser bekommt meinen ATmega nicht zum sprechen.
Es sollte also nicht direkt am Bootloader liegen.

Hab auch bei Hagens Bootloader mal die Baudraten-Detektion ausgeschaltet
und auf einen festen Wert gesetzt..nix.
Der Rechner schickt wie wild Signale die einfach nicht bearbeitet 
werden.

Vllt. doch irgendwelche Fuses falsch..obwohl, ich hab zig mal drüber
geguckt.

Danke für schnelle Reaktion Peter

Rocken

[Malte _. (malte)]

Hallo Peter,
bei mir funktioniert der Bootloader mit einem ATmega128 einwandfrei 
(Version 2.1). Aber stimmt die Information noch, dass das Schreiben 
oberhalb von 64KB bis auf weiteres nicht funktioniert? (Und er 
vermutlich auch davon noch fälschlicherweise die Größe der 
Bootloadersektion abziehen wird?).

Ich habe übrigens mal die Wiki Seite an die aktuelle Version angepasst.

[Peter D. (peda)]

Malte __ wrote:
> Hallo Peter,
> bei mir funktioniert der Bootloader mit einem ATmega128 einwandfrei
> (Version 2.1). Aber stimmt die Information noch, dass das Schreiben
> oberhalb von 64KB bis auf weiteres nicht funktioniert?

Nein, die Version 2.1. kann das.
Ich hab ihn bis zum ATmega2561 erweitert und getestet (256kB).


Peter

[Manuel (Gast)]

Ist der Wiki Artikel noch aktuell?
Ich nehme an dass mam jetzt statt m32.asm nur BOOTLOAD.asm asemblieren 
muss.
Hab extra unter Windows AVR Studio installiert, aber irgendwie kommen 
bei mir 500 Errors ala "Invalid redefinition of <blabla>".

Kennt jemand eine Lösung oder kann jemand die feritige HEX-Datei für 
einen 16NHz ATmega32 auf PortD hochladen?

mfg

[Malte _. (malte)]

Manuel wrote:
> Ist der Wiki Artikel noch aktuell?
Ja, ich hatte ihn gerade auf den aktuellen Stand gebracht.

> Ich nehme an dass mam jetzt statt m32.asm nur BOOTLOAD.asm asemblieren
> muss.
Ja, und vorher in dieser die richtige include auswählen und die 
betreffende Datei einfach in das gleiche Verzeichniss kopieren.

> Hab extra unter Windows AVR Studio installiert, aber irgendwie kommen
> bei mir 500 Errors ala "Invalid redefinition of <blabla>".
Poste doch mal den genauen Assemberaufruf und die Ausgabe.

[Rocken (Gast)]

Ich konnte das Problem mit meinem nicht funktionierenden Bootloader 
etwas eingrenzen:
Ich kann den Bootloader zwar per ISP/JTAG überspielen...er antwortet 
aber nie auf einkommende Signale über die RS232.
Wenn ich jedoch den Bootloader im Debugmodus (Dragon Board über JTAG) 
durchlaufen lasse funktiert er und kann einwandfrei kommunizieren und
Programme übertragen.
Ich kann sogar während des Debugbetriebes den JTAG-Adapter abziehen und 
habe danach einen funktionierenden Bootloader.

Wie ist das zu erklären? Ich kann ja nicht immer erst in den Debugmodus 
und dann, eigentlich unzulässiger Weise, den Adapter abziehen um mein 
Bootloader zu bekommen.

Kennt jemand ds Problem und kann mir ggf. helfen?

Rocken

[Trax X. (trax)]

Wo kannman den die version neuen versionen laden hier ist ja nur die 
alten 1.7 velinked :/

[Patrick (Gast)]

So,habe nun die ältere Version des Bootloaders draufgeflashed. (die 
neuere bekomme ich einfach nicht assembliert...), und laut dem 
angehängten Bild scheint die Übertragung ja zu funktionieren.

Mein Problem ist aber, dass die Anwendung danach einfach nicht startet.

Meine fusebits für einen 16 MHz ATmega32 lauten:
hfuse: 8E
lfuse: FF
(Calc siehe http://www.engbedded.com/cgi-bin/fc.cgi )

Liegt mein Fehler an den Fuses, oder kann jemand sonst irgendwie helfen?

Grüße
Patrick

[Malte _. (malte)]

Trax Xavier wrote:
> Wo kannman den die version neuen versionen laden hier ist ja nur die
> alten 1.7 velinked :/
Einfach nach "fboot21" suchen. Oder Link aus dem Wiki Artikel nehmen.

[Patrick (Gast)]

Kann mir denn keiner helfen? Ich muss morgen das STK500 wieder 
zurückgeben, und da wäre es schön bis dahin meine ATmegas mit dem 
Bootloader geflashed zu haben.

Ich würde mich über ein fertiges Intel-HEX-File für den ATmega32 @16Mhz 
@ PD0,PD1 oder auch über jegliche Hilfe sehr freuen.
Ebenso über die richtigen hfuse und lfuse Werte, dies würde mir die 
Verwendung von avrdude sehr erleichtern.

Meine Ersten Versuche habe ich bereits hier gepostet:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Ich wäre sehr dankbar dafür wenn mir hierbei jemand helfen kann. Vielen 
Dank!

Patrick

[Malte _. (malte)]

Patrick wrote:
> Kann mir denn keiner helfen? Ich muss morgen das STK500 wieder
> zurückgeben, und da wäre es schön bis dahin meine ATmegas mit dem
> Bootloader geflashed zu haben.
Dann poste doch mal die komplette Fehlerausgabe mit dem genauem 
Assembleraufruf. Programmieren lässt sich ein AVR auch ohne STK mit 
einem LPT Adapter auf einem Steckbrett.

[Patrick (Gast)]

So, assemblieren hat nun geklappt. Fehler lag darin, dass ich zwar 
mega32def.inc einkommentiert, aber mega16?def.inc nicht auskommentiert 
habe.
siehe: 
http://s1.image.gd/o/fe/fe514023f91afa9c5af99569ec104de9625fd697.jpg

Doch nun bekomme ich beim Übertragen keine Verbindung (auch Reset wurde 
versucht).
siehe: 
http://s1.image.gd/o/eb/ebd404ec046e5ebfc5fe18538f3a8c8761a89f3d.jpg

Fusebits sind folgendermaßen gesetzt: 
http://s1.image.gd/o/c6/c6d155783739bfddd0f5759ce3f1265df0bd08c7.jpg

MfG Patrick

[Malte _. (malte)]

Patrick wrote:
> So, assemblieren hat nun geklappt. Fehler lag darin, dass ich zwar
> mega32def.inc einkommentiert, aber mega16?def.inc nicht auskommentiert
> habe.
Na also :-)

> Doch nun bekomme ich beim Übertragen keine Verbindung (auch Reset wurde
> versucht).
> siehe:
> http://s1.image.gd/o/eb/ebd404ec046e5ebfc5fe18538f3a8c8761a89f3d.jpg
Ich hatte manchmal das Problem, dass nur höhere Geschwindigkeiten 
richtig funktionierten (19200 baud). Außerdem brauchte ich manchmal 
folgene Reihnfolge:
1. AVR Power off 2. PC Programm starten, 3. AVR Power on.
Außerdem machten manche USB->RS232 Konverter bei mir Probleme.

> Fusebits sind folgendermaßen gesetzt:
> http://s1.image.gd/o/c6/c6d155783739bfddd0f5759ce3f1265df0bd08c7.jpg
Keine Ahnung, ob BOOTRST richitg ist, ist ja mit dem 0/1 
programmed/unprogrammed immer etwas verwirrend.

[Patrick (Gast)]

Mit der Alten Version 1.4 funktioniert der Bootloader bei mir bereits, 
nur mit der neuen Version 2.1 konnte ich diesen Effekt noch nicht 
erzielen.
Fuses sollten also ok sein.

Schon mal vielen Dank an Malte für deine Hilfe. Ob ich jetzt die Version 
1.4 oder 2.1 verwende wird für mich wohl kaum einen Unterschied machen, 
also bin ich damit schon glücklich, danke.

MfG Patrick

[Patrick (Gast)]

weiß jemand, wie man die fboot.exe in DOSBOX unter Linux verwendet, wenn 
die Schnittstelle /dev/ttyUSB0 lautet?
Und lässt sich das irgendwie vereinfachen, dass man nicht zuerst DOSBOX 
und dann das programm in DOSBOX starten muss, dort natürlich eine 
Partition mounten usw...

am besten wäre ein befehl ala "dosboxxyz -<befehl, der in dosbox 
ausgeführt wird>", so dass ich es dann ggf. auch in ein Makefile 
einfügen kann.

MfG Patrick

[Matthias L. (matze88)]

Hier ist doch irgendwo ne Linuxversion von dem Code gepostet, warum 
nicht die benutzen?

[Patrick (Gast)]

Ich habs mit Linux_Fast14 aus 
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"
versucht, aber das Programm kann nach dem Flashen leider nicht gestartet 
werden...
Ansonsten sieht es so aus als wäre der Flashvorgang erfolgreich gewesen.

patrick@patrick-laptop:~/Desktop/Linux_Fast14$ ./fboot /?

   /?                 Get this help message
   /Bnnnn             Define baud rate
   /Ddevice           Define serial port
   /PFname,Ename      Perform Program
   /VFname,Ename      Perform Verify


patrick@patrick-laptop:~/Desktop/Linux_Fast14$ ./fboot /D/dev/ttyUSB0 /Pblink1.hex
/dev/ttyUSB0 at 115200 Baud: /
Connected
 readval: 
 a8 val        0    j 257 
 03 val        0    j 256 
 01 val        0    j   3 
 04 val        1    j   2 
 aa val      260    j   1 
Bootloader V1.4
 readval: 
 a8 val        0    j 257 
 04 val        0    j 256 
 1e val        0    j   4 
 95 val       30    j   3 
 02 val     7829    j   2 
 aa val  2004226    j   1 
Target: 1E9502 ATmega32
 readval: 
 a8 val        0    j 257 
 03 val        0    j 256 
 07 val        0    j   3 
 00 val        7    j   2 
 aa val     1792    j   1 
Buffer: 1792 Byte
 readval: 
 a8 val        0    j 257 
 04 val        0    j 256 
 00 val        0    j   4 
 7e val        0    j   3 
 00 val      126    j   2 
 aa val    32256    j   1 
Size available: 32256 Byte
reading file... Done.
Program blink1.hex: 0000 - 00B9 successful
CRC: o.k.
Elapsed time: 0.15 seconds
patrick@patrick-laptop:~/Desktop/Linux_Fast14$

daher dachte ich mir mit DOSBOX könnte man es ja noch versuchen, wenns 
im Wiki schon steht.

MfG Patrick

[Peter D. (peda)]

Patrick wrote:
> weiß jemand, wie man die fboot.exe in DOSBOX unter Linux verwendet

Linuxversion:

http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1927&item_type=project

Kann aber wohl kein 1-draht Modus.


Peter

[Gerd A. (inputsammler)]

Hallo ALLE zUSAMMEN;

Also irgendwie glaube ich geht die Übersicht völlig verloren.

Welcher Update Loader geht nun
64bit 32bit mit gui ohne gui oder Linux 32 /64 bit
Welcher Bootloader ist der aktuell

Könnte mann nicht hier eine WIKI machen wo man das alles zusammenfasst 
und immer die Aktuellen Versione reinstellt.


Also es gibt BootloaderFlashTool für
GUI:
Windows 32 bit
Beitrag "UART Bootloader ATtiny13 - ATmega644"

CMD:
Windows 64/32BIT
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

LINUX:
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=1927&item_type=project

Bootloader selbst???
Beitrag "UART Bootloader ATtiny13 - ATmega644"

Gruß Gerd

[Matthias L. (matze88)]

Wer sich nicht extra anmelden möchte bei AVRFreaks: Ich habe soeben die 
Linuxsoftware hier im Thread vom 3.12.2008 erfolgreich ausprobiert. 
Dabei kann ich die txblocksize nur auf max. 43 stellen, ansonsten treten 
Übertragungsfehler auf (Grund ist mir egal, Mega88 @ 230400 @ 0,77 
Sekunden reicht mir).

[Bingo (Gast)]

Hier ist einer kleine script line für avrasm2.exe unter linux (wine)

Kopiere die avrassembler dateis von einer windows pc mit avrstudio 
instaliert.

wine ~/avr/AvrAssembler2/avrasm2.exe -I ~/avr/AvrAssembler2/Appnotes $1

mfg
Bingo

[Rainer J. (kutscher)]

Nur eine kurze Rückmeldung.
Läuft problemlos auf Atmega8, 1Wire Modus an PB0, AVR Studio 4.16.
Respekt und ein Dankeschön an Peter Dannegger.

[Dominique G. (dgoersch)]

Hallo zusammen,

ich habe soeben das erste mal den Bootloader getestet.

Bootloader V2.1
UpdateLoader v 2.1.9.106

Muss dazu sagen, ich habe absolut keine Erfahrung mit Assembler. Ich bin 
wie folgt vorgegangen:
- neues ASM-Projekt in AVR-Studio angelegt
- Dateien aus dem Archiv darein gezogen
- .inc für meinen AVR (mega16) dazu kopiert
- mit avrasm2 -fI Bootload.asm übersetzt
- mit avrdude in den AVR geflasht.
- die Fuse entsprechend gesetzt

Wenn ich nun mit dem Updater ein Hex-File in den AVR schreiben will, 
passiert folgendes:
,---
| Verbunden: 2-Draht-Modus
| CRC-Check: aktiviert
| Bootloader-Version: 2.1
| Baustein: ATmega16
| Buffergröße: 512 Byte
| Flash: 15872 Byte
| CRC-Prüfsumme OK
| Programmiere 3917 von 15872 Bytes Flash
| Gesamtdauer: 00:01:04
`---

Im unteren Fenster steht:
,---
| Programmdatei "C:\Dokumente und Einstellungen\Administrator\Deskto
| \Mixercontrol\Firmware\R2_001.HEX" geladen
| Kommando "$6" fehlgeschlagen
| Programmiere 3917 von 15872 Bytes Flash
| Baustein reagiert nicht
`---

Was mache ich falsch?

Gruß
Dominique Görsch

PS: Der AVR ist über einen FT232RL über USB mit dem PC verbunden.

[Peter D. (peda)]

Dominique Görsch wrote:

> UpdateLoader v 2.1.9.106

Ist das ein Linuxprogramm?


> | Baustein reagiert nicht

Bei Verbindungsproblemen mal ne andere Baudrate probieren.


Peter

[Dominique G. (dgoersch)]

Hallo Peter,

nein, dass ist ein Windowsprogramm hier aus dem Thread. Mehrere 
Baudraten habe ich schon durchprobiert.

Woran könnte es sonst noch liegen? Die Schaltung an sich funktioniert, 
flashe ich über ISP meine eigentlich Firmware läuft alles wie es soll.

Gruß
Dominique Görsch

[Dominique G. (dgoersch)]

Hmm... habe nun den Bootleader erneut assembliert und geflashed und 
danach mal mit dem original fboot.exe getestet, das klappte problemlos.

Danke, tolles Ding ;)

[Sascha (Gast)]

Hi,
warum benötige ich beim Tiny2313 kein RJMP zum Bootloader????

bin grad total verwirrt?!

[Christian J. (stormracer)]

Hi,

ich habe gerade das gleiche Problem, wie schon ein paar andere.

Ich versuche nun schon seit ein paar Tagen die Version 2.1 mit einem 
Atmega8 zu verwenden.
Kompeliert und geflasht bekomme ich es. Nur reagiert der µC dann nicht 
mehr auf die fboot.exe. Egal welche Baudrate ich verwende. Die Kabel 
sind auch richtig, einen Max benutze ich auch.
Fuses habe ich wie folgt eingestellt: lfuse:0xbf hfuse:0xdc
Benutze einen externen 8MHZ Keramik Resonator / Filter

Habe das ganze schon am Rechner mit echter RS232, sowie am Notebook mit 
RS232-USB ausprobiert. Beides gleicher Effekt.

Habe euch noch ein Bild mit dem ausgelesenem Flash Teil in PonyProg 
angehängt.

Habe echt keine Ahnung mehr, wo's noch drann hängen kann. Ein Oszi hab 
ich leider nicht.

[Bernhard M. (boregard)]

Eigentlich müsste sich im HEX File, wenn es richtig ist, der String 
"Peda" (das Passwort) finden lassen, finde ich aber nicht... also könnte 
das angehängte  HEX falsch sein...

[Christian J. (stormracer)]

Moin,
@Bernhard M. das Passwort "Peda" steht an Stelle 1FBE.
Aber trotzdem schon mal danke, dass du es dir angeguckt hast.

Ich habe in den Dateien auch nichts geändert. Für den ATmega8L @ 8Mhz 
passt das doch alles schon, oder hab ich da doch noch etwas übersehen?

Sind die Fuses denn in Ordnung?

[roboter (Gast)]

Ich habe COM2.

wenn ich die EXE starte , wird geschrieben COM1 ist nicht da.

Wie kann ich die EXE auf Com2 umstellen?

[Dominique G. (dgoersch)]

Schau doch einfach mal in die Hilfe...

,---
| C:\FBOOT>fboot /?
| /?               Get this help message
| /Bnnnn           Define baud rate
| /Cn              Define serial port n = 1..4
| /Pname           Perform Program
| /Vname           Perform Verify
| /Istring         Init string
`---

War das nu so schwer?

[Torsten L. (lit)]

Hallo,

ich versuche gerade eine Java Software zu schreiben die den Bootloader 
benutzt. Leider scheitere ich schon beim ersten check_crc().

Nachdem der Connect zustandegekommen ist wird geprüft ob der Bootloader 
crc unterstützt. Vor diesem ersten Aufruf  von check_crc() ist die 
Variable crc=0.
Dann schicke ich das cmd CHECK_CRC an den Bootloader und bekomme SUCCESS 
zurück. Jetzt sende ich den ersten CRC Wert an den BootLoader. Dieser 
ist 53FB also FB und dann 53. Daraufhin bekomme ich FAIL zurück.

Ich weiss einfach nicht mehr wo ich noch suchen könnte.

Anbei der relevante Code:


private CRC_STATUS check_crc() throws IOException, InterruptedException, 
NoAnswerException {
  int i;

  sendcommand(BL_CHECK_CRC);
  Thread.sleep(50);

  if (isAnswerArrived) {
    if (answer[0] == BL_BADCOMMAND) {
      return CRC_STATUS.NO_CRC;
    }
  }

  int tmpCrc = crc;
  System.out.println(Integer.toHexString(tmpCrc));

  send(tmpCrc & 0xff);
  send(tmpCrc >> 8);

  waitForAnswer();

  i = answer[0];
  switch (i) {
  case BL_SUCCESS:
    return CRC_STATUS.CRC_OK;

  default:
    return CRC_STATUS.CRC_FAIL;
  }
}

private void get_crc(int d) {
  int tmpCrc = crc ^ d;

  for (int i = 0; i<8; i++) {
    if ((tmpCrc & 0x1) != 0) {
      tmpCrc = (tmpCrc >> 1) ^ 0xA001;
    } else {
      tmpCrc = tmpCrc >> 1;
    }

  }
  crc = tmpCrc & 0xffff;
}

private void send(int c) throws IOException {
  isAnswerArrived = false;
  out.write((char) c);
  get_crc(c); // calculate transmit CRC
}


private void sendcommand(int cmd) throws IOException {
  send(BL_COMMAND);
  send(cmd);
}

[Harry L. (mysth)]

Hallo zusammen,
wäre es nicht mal an der zeit, dem Bootloader in AVRDude zu integrieren?
Hielte ich zumindest in Verbindung mit Eclipse für extrem praktisch.

Gruss

Harry

[Dominique G. (dgoersch)]

Geniale Idee, dem kann ich nur beipflichten.

[Harry L. (mysth)]

Ach ja...eins wollte ich noch loswerden:
Ich verwende diesen genialen Bootloader bereits seit einigen Monaten, 
auch, wenn ich mich hier selten zu Wort melde..
Mein Dank gilt allen, die das möglich gemacht haben!

Gruss

Harry

[Alfred N. (alfred-n)]

Hallo,

ja als erstes "Vielen Dank an Peter Dannegger" für den Bootloader und 
allen andern die das hier möglich gemacht haben!

Habe FBOOT um wenige Zeilen (Programm Zeilen) erweitert.
Neu ist :

  - Portiert auf C++Builder 2007 Kommando-Zeile (sollte aber auch mit
    DevCpp laufen).
  - Für Win32 XP und auch Vista.
  - 1Wire laeuft nun auch unter windows XP / Vista;
  - Mit USB auf RS232 Adapter(nicht TTL) und dann "PEDA 1Wire 
Interface".
  - Getestet mit Prolific USB auf RS232 Adapter (Quelle Glyn) wurde von
    Vista sofort ohne Treiber Inst. erkannt.
  - Vista mit RS232 konnte ich nicht testen da mein Laptop nur USB hat;

So und nun zu den Baudraten Max. bei mir :

  - PC mit XP mit on Board RS232 (com1) weitere gibt es NICHT -> 57600
    Baud.
  - Gleicher PC mit PCI Multi-RS232-Card 8x -> 38400 Baud.
  - Laptop mit USB auf RS232 Adapter(nicht TTL) und dann "PEDA 1Wire
    Interface"-> 115200 Baud " ein Wunder !" NEIN , trotzdem ist die
    UPLOAD-ZEIT 3 mal so lang statt 2 Sek. > 6 Sek ist halt USB mit 
Vista.


Vielleicht hat mal einer die Zeit ein Interface von TTL auf 1Wire zu 
basteln.

Gruss  Alfred

[Alfred N. (alfred-n)]

Hab den Dateianhang nicht ........
Aber und so ....

Gruss Alfred

[Meisterlampe (Gast)]

Hallöchen

Ich wollte nun auch mal den Bootloader ausprobieren, und bin leider noch 
zu keinem Ergebnis gekommen :(

Mein Vorgehen wie folgt:

-Version 2.1 runtergeladen
-Bootload: xtal = 12000000
-fastload: m32 auskommentiert, m8 aktiviert
-avrasm2 -fi bootload.asm
-avrdude -p m8 -c ponyser -P com1 -U 
flash:w:"C:\fboot21\BOOTLOAD\bootload.hex":i -U 
flash:v:"C:\fboot21\BOOTLOAD\bootload.hex":i -y
-avrdude -p m8 -c ponyser -P com1 -U lfuse:w:0xee:m -U hfuse:w:0x9c:m

Wenn ich nun fboot starte passiert nichts, egal wie oft ichs probiere 
oder wie oft ich den m8 resete. Ebenso hilft es nicht die Baudrate 
runterzusetzen. Jemand eine Idee?

Gruß

[Meisterlampe (Gast)]

Ohje... dabei wollte ich den Beitrag nicht abschicken sondern löschen 
-.-

Vergessts einfach, für die anderen die auch so ein Problem haben, 
benutzt die fboot version von Alfred über mir

Gruß...

[Christian J. (stormracer)]

Hallo

@ Alfred N. RIESEN DANKESCHÖN für deine FBOOT Version. Ich habe es nun 
auch endlich geschafft meinen Asuro per Bluetooth zu flashen. Dank 
deinem Programm klappt es nun endlich. Zum einen ist die Erweiterung auf 
bis zu 16 Com Ports richtig gut (Mein Bluetooth Dongle verbindet sich 
immer auf Port5) und die Verbesserte Unterstützung von USB 
Wandlern/Bluetooth ist einfach genial. Aber das Problem mit dem 
langsamen flahen habe ich auch. Für 7,6kb brauche ich über 40s, mit 
einer echten RS232 habe ich nur 2-3s gebraucht.

Christian

[Tim (Gast)]

Moin moin,

fange gerade erst an mit Bootloader zu arbeiten.
Und da habe ich mal eine Frage:
Ich habe in das Programm eine Funktion eingebaut, dass zum Bootloader 
springt (entspricht ja einem Reset), wenn über die serielle 
Schnittstelle "res\r" empfangen wird. Dachte, dass fboot.exe ... /I[..] 
dann den String incl. carriage return sendet und somit der Bootloader 
über die rs232 aktiviert wird. Nur: Wie schreibe ich das \r bzw. den 
gesamten String in die Kommandozeile? /Ires\r hat nicht funktioniert.
Hardware: ATmega644P. Das erste flashen funktioniert problemlos, der 
Bootloader funktioniert prinzipiell also.

Vielen Dank schonmal!
Tim

[Dominique G. (dgoersch)]

Das Tool sendet 0xff zum resetten, der String ("peda" als Default) ist 
eine Art Passwort was erst später übermittelt wird.

[Christian J. (stormracer)]

Moin,
ich versuche auch gerade auf das gesendete 0xFF zu reagieren, habe da 
aber noch so meine Probleme. Wenn ich ein einfaches 0xFF per 
HyperTerminal (als Textdatei) sende funktioniert es, aber mit der 
FBOOT.exe klappt es nicht.

Ich benutze die UART Libary von Peter Fleury auf einem ATmgea8.
Habe es erstmal so probiert:

while(1)
{
   c = uart_getc();  
   if(c==0xff)
      uart_puts("Reset");
}

Habe ich da noch einen Denkfehler drin?

Christian

[Peter D. (peda)]

Wenn Du den Bootloader aus der Applikation aufrufen willst, mußt Du die 
UART vorher wieder abschalten.
Er weiß ja nicht, ob der Chip (ATtiny13..ATmega2561) überhaupt ne UART 
hat.

Am besten ist es, den Bootloader aus der Applikation per Watchdogreset 
zu starten.


Peter

[Dominique G. (dgoersch)]

Ja so mache ich es bei mir und es klappt einwandfrei. Allerdings nutze 
ich momentan Bascom und kein C.

Ich prüfe in der UART ISR einfach ob das Zeichen besagtes 0xff (255 
binär) ist, und starte dann den Watchdog:

Urxc_isr:
   Key = Inkey()
   If Key = 13 Then
      Flag = True
   Elseif Key = 255 Then
      Start Watchdog
   Else
      Inputstr = Inputstr + Chr(key)
   End If
Return

Ist es 13 (Return) setze ich ein Flag was ich in der Mainloop auswerte, 
bei jedem anderen Zeichen wird es einfach an einen String angeängt (für 
ankommende Befehle die ich in der Mainloop dann ausführe). Da ich aber 
nach jetzigem Stand mit 254 Befehlen auskommen werde, werde ich das bei 
Gelegenheit noch umstellen und die Klartext-Kommandos verwerfen.

Gruß
Dominique Görsch

[Christian J. (stormracer)]

Ich habe es jetzt mit dem Reset hinbekommen, hatte die Variable als int 
deklariert...

Jetzt connected er aber immer im One Wire Mode, meldet dann aber die 
Falschen Device Informationen. Ich habe den Controller aber über eine 
Bluetooth Verbindung angebunden. Wenn ich den ATmega erst anschalte wenn 
er sich connecten soll geht es.
Welche Bedingunggen braucht die Fboot.exe um den One Wire Mode zu 
nehmen?

[Andreas B. (andreasb)]

@Harald L.
>Hielte ich zumindest in Verbindung mit Eclipse für extrem praktisch.


Oder ein Eclipse Plugin, das wie beim starten einer Java Applikation das 
Flashen ermöglicht. (siehe Screenshot)

Leider funktioniert das ganze noch nicht, aber zumindest steht die GUI 
und RS232 ist per rxtxSerial auch vorhanden...

Wenn jemand mitentwickelt will kann er sich bei mir melden;-)

Ich werde das ganze hier online stellen wenn ich es irgendwann mal 
fertig kriegen sollte;-)


mfg Andreas

[Stormracer (Gast)]

Habe auch das Problem mit dem OneWire Mode behoben. Allerdings nur 
wirklich nur behoben, nicht gelöst. Habe einfach in der Fboot.exe die 
OneWire Erkennung auskommentiert und neu übersetzt...
Nu gehts jdf. schon mal.

[Peter (Gast)]

Hallo,
ich habe den Bootload leider ohne erfolg ausprobiert.
Bei mir kommt folgendes:

D:\FBOOT>fboot /C1 /B9600  /Pmain.hex
COM 1 at 9600 Baud: /
Aborted

D:\FBOOT>fboot /C1 /B19200  /Pmain.hex
COM 1 at 19200 Baud: \
Aborted

D:\FBOOT>fboot /C1 /pmain.hex
COM 1 at 115200 Baud: Connected

Nach dem ich die Spannung beim letzten Versuch weggenommen habe kam das 
hier:

Bootloader VFFFFFFFF.FF
Error, wrong device informations

Kann das an der Hardware liegen?
Ich nutzen an einen ATMega8 mit internen RC-Oszillator auf 8MHz.
.equ    STX_PORT        = PORTD
.equ    STX             = PD5

.equ    SRX_PORT        = PORTB
.equ    SRX             = PB7
Das hier sind meine Portkonfigurationen. Was mache ich Falsch? geht das 
Programm evt nicht mit einem XTAL Pin?
Danke Schonmal.
Peter

[Torsten L. (lit)]

@andreasb

Hallo,
ich habe eine Implemntierung in Java als Eclipse Plugin.
Zum ausprobieren die Class TestBootloader anschauen.

Der OneWire Modus ist nicht implementiert zur zeit.

[Peter (Gast)]

Hallo,
mein Problem hat sich erledigt. Es war ein 
Harwarefehler(Stützkondensatoren des MAX232 für +/- 10 vergessen an 
Masse anzulöten. arg
Gruß
Peter

[Tim (Gast)]

Hallo alle ;)

Ich habe seit ewigen Zeiten keine Probleme mit dem hier genannten
Bootloader gehabt, lief auf Anhieb und tut an sich das, was er soll.

Allerdings habe ich "nur" die Version 1.4 in das Gerät gebrannt.

Da der Bootloader eine "Selbstzerstörung" verhindert, kann ich ja leider
nicht das Feature "Bootloader ersetzen" nutzen, das der hier zum Einsatz
kommende mega32 ja grundsätzlich unterstützen sollte (ausser ich 
verstehe
das Datenblatt in dieser Hinsicht falsch).

Um den Schutzmechanismus "zu Umgehen", habe ich mir nun gedacht 
"verschiebe
doch einfach das Bootloader-Programm von "BootStart" nach "0x0030" und
springe entsprechend dorthin. Damit hab ich ja zunächst mal ein 
App-Space
Programm, das natürlich kein SPM durchführen kann.
In diesem Programm hab ich dann die Adressenabfrage auskommentiert und
so ja zunächst einmal verhindert, das ich nicht in den BLS schreiben 
darf.

Ein kurzer Blick aufs Map-File des Original-Bootloaders (und nach ersten
Problemen auch einn Blick auf einen Hexdump einer MCU) hat sich für die
Subroutine "do_spm" die Adresse 0x3FA5 ergeben.

Nun habe ich versucht, anstelle RCALL do_spm einen CALL 0x3FA5 
auszuführen,
für die "App-Space-do_spm" ein JMP 0x3FA5 anstelle "do_spm:" bis zum
zugehörigen "RET". (Das RET hab ich wegen der do_spm_rerww stehen 
lassen,
selbst wenn es nie genutzt würde, würde es ja auch nicht stören.)

Zum Testen habe ich eine Schaltung hier, wo ich auch SPI-Zugriff habe,
habe mir also den Fastboot 1.4 (der beim Start eine LED anmacht) aufge-
spielt (die Sprungadresse fürs SPM ist dabei gleich geblieben). Der BL
funktioniert auch einwandfrei, praktisch habe ich hier den Zustand, den
auch die Geräte haben, bei denen ich keinen Zugriff mehr auf SPI habe.

Spiele ich nun per fboot.exe (1.4) meine "Bootloader-im-App-Space" 
Version
auf (hier hab ich die LED "ausgeschaltet", zum Unterscheiden), kriegt
fboot.exe auch eine Verbindung zu diesem AppSpace-Loader, zeigt alle
Daten der MCU an und versucht, ein Hex-File zu flashen..

Dummerweise klappt es schon beim ersten Block nicht, es wird "failed"
angezeigt, nachdem eine längere Zeit gar nichts passierte. 
Interessanter-
weise geht die LED an, was mir sagt, das die MCU irgendwo hinspringt, wo
die LED eingeschaltet wird. Nach dem "App-Space"-Bootloader-Versuch ist
ab dem leuchten der LED wieder der "ursprüngliche" im BLS befindliche
Bootloader aktiv, der App-Space-Loader springt nicht an.


Gibt es eine Möglichkeit, den Bootloader von 1.4 auf eine höhere Version
upzudaten, ohne Zugriff auf die SPI-Schittstelle zu haben ? 
Grundsätzlich
sollte ja der Weg schonmal richtig sein, sich eine App-Space-Anwendung
zu schreiben, die wie ein Bootloader den Flash neuschreiben kann, nur
das ein SPM halt im BLS liegen muss, um ausgeführt zu werden. Auch wenn
in der 1.4 das SPM nicht "allein" steht, sollte man doch (da die Sprung-
adresse bekannt ist und später ein "RET", kein "JMP PC-????" oder auch
"JMP PC+????" folgt) das Problem lösen können ?

Ich hoffe hier auf weitere Anregungen, zugegeben habe ich "nur" 2 
Stunden
an dem Problem gesessen, aber mir will kein Fehler mehr auffallen.

Grüsse,
Tim

[Peter D. (peda)]

Tim schrieb:
> Gibt es eine Möglichkeit, den Bootloader von 1.4 auf eine höhere Version
> upzudaten, ohne Zugriff auf die SPI-Schittstelle zu haben ?

Ich habe nichts vorgesehen, um ein Update zu ermöglichen.

Ich weiß jetzt nicht, wieviel im Bootbereich des ATMega32 noch frei ist.
Du brauchst mindestens eine Page, wohin Du ein neues do_spm schreiben 
kannst, da ja das alte gelöscht wird.

Und dann muß natürlich alles klappen. Ist irgendwas im 1.Bootloader 
verändert, hast Du keinen 2.Versuch.


Peter

[Tim (Gast)]

Hallo Peter.

Ja, das leuchtet mir nun ein mit dem Überschreiben - scheinbar
ist genau das auch das Problem.

Daran hatte ich zunächst gar nicht gedacht, das ich das do_spm ja
überschreiben würde/werde.. hat was von den Wald vor lauter Bäumen
nicht sehen ..

Gruss,
Tim

[Fabian S. (jacky2k)]

Hallo an alle.
Habe von einem Kollegen von dem Thread und dem Projekt hier gehört und 
muss sagen: Respekt!
Also ist nen super Projekt und so, aber einen Kritiktpunkt muss ich ja 
nochmal los werden: Das ist hier verdammt unübersichtlich und ich bin 
als Neueinsteiger eindeutig nicht bereit mir hier alles durchzulesen, 
denn das sind inzwischen über 120 Seiten Text!
Also gibts irgendwo ne Seite/Beitrag wo alles mal zusammengefasst ist, 
alle Software, die inzwischen zu diesem Projekt gehört etc? Vor allem wo 
es jetzt die aktuellste Version des Bootloaders gibt.

[Alex H. (hoal)]

@Fabian S.:

Dass man die hier typischen 100-seitigen Artikel nicht lesen will, kann 
ich absolut nachvollziehen. Aber dass man zu faul ist, 10 Sekunden lang 
in die Artikelübersicht zu schauen, ist mir nicht verständlich...

http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger

[Fabian S. (jacky2k)]

Ahh, ich hatte nur das PDF: 
http://www.mikrocontroller.net/attachment/25392/Bootloader_FastBoot_von_Peter_Dannegger.pdf
Im Artikel sind wohl noch ein paar Downloads, danke!
Ein großes Problem bleibt aber. Ich habe das Teil inzwischen kompiliert 
bekommen, aber ich weiß nicht genau wie ich es in die Karre 
Programmieren muss. Ich habe kein avrdude und avrdude unterstütz meinen 
Dongle auch nicht (soweit ich weiß). Ich habe den AVR ISP mkII. Daher 
programmiere ich immer über das Tool von AVR Studio.
Ich habe die Hex einfach mal normal programmiert, die Fuses gesetzt und 
probiert, geht nicht. Dann hab ich gesehen, dass bei den 
Fuse-Einstellungen steht, dass er Bootloader an stelle 0x0F00 stehen 
muss. Wie bekomm ich den da hin?

[Alex H. (hoal)]

Fabian S. schrieb:
> Ich habe kein avrdude und avrdude unterstütz meinen
> Dongle auch nicht (soweit ich weiß). Ich habe den AVR ISP mkII.

Ist ja nicht zu fassen, wie suchfaul du bist!
http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#SEC4

[Fabian S. (jacky2k)]

Alex H. schrieb:
> Ist ja nicht zu fassen, wie suchfaul du bist!
> http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#SEC4

So schlau war ich auch schon mal!
> avrdude -p m8 -P usb -c avrispmkII -U flash:w:m8.hex:i -U flash:v:m8.hex:i -y
> avrdude: usbdev_open(): did not find any USB device "usb"

For the JTAG ICE mkII, if AVRDUDE has been built with libusb support, 
port may alternatively be specified as usb[:serialno]. In that case, the 
JTAG ICE mkII will be looked up on USB. If serialno is also specified, 
it will be matched against the serial number read from any JTAG ICE mkII 
found on USB. The match is done after stripping any existing colons from 
the given serial number, and right-to-left, so only the least 
significant bytes from the serial number need to be given. For a trick 
how to find out the serial numbers of all JTAG ICEs attached to USB, see 
Example Command Line Invocations.

As the AVRISP mkII device can only be talked to over USB, the very same 
method of specifying the port is required there.


Darauf hin habe ich damals versucht Avrdude mit libusb zu bauen, hat 
jedoch absolut nicht funktioniert, habe mir Tagelang dabei die Zähne 
dran ausgebissen, und hier konnte mir auch niemand helfen.
Dann bin auf das mitgelieferte Tool umgestiegen, da es wunderbar 
funktioniert.
Also nochmals meine Frage: Geht das auch mit dem was ich habe?

[Fabian S. (jacky2k)]

Ich habe mir mal mit dem hex File ganz allgemein beschäftigt und musste 
feststellen, dass da ja absolute Adressen drin stehen, dachte das wäre 
nur ein "Hex-Dump".
So, interessant ist jetzt, dass in meinem hex File steht, dass die 
ganzen Daten an die Stelle 0x1E00 kommen:
:101E0000F8940FE50DBF04E00EBF22243324909A0E
Warum? Und kann ich das von vornerein korrigieren?
Bin grade Dabei ein kleines Programm zu schreiben was mir das Hexfile 
umschiebt und die neuen Hash Werte berechnet, sauber ist das aber nicht 
wirklich :(
Jemand eine Idee?

[Peter D. (peda)]

Fabian S. schrieb:
> Ich habe mir mal mit dem hex File ganz allgemein beschäftigt und musste
> feststellen, dass da ja absolute Adressen drin stehen, dachte das wäre
> nur ein "Hex-Dump".

Das Hex enthält Adressinformationen, damit man unprogrammierten Ballast 
nicht mitschleppen muß. Ist doch clever.


> So, interessant ist jetzt, dass in meinem hex File steht, dass die
> ganzen Daten an die Stelle 0x1E00 kommen:

Das ist abhängig von dem AVR, den Du auswählst.
Die Adresse wird auf die höchstmögliche im Bootbereich gelegt, damit 
maximal Flash für die Applikation übrig ist.


> Bin grade Dabei ein kleines Programm zu schreiben was mir das Hexfile
> umschiebt und die neuen Hash Werte berechnet, sauber ist das aber nicht
> wirklich :(

???
Das ist Unsinn.
Was bezweckst Du damit?


Peter

[Fabian S. (jacky2k)]

Ich bezwecke damit das Teil zum laufen zu bekommen ;)
Ich darf nochmal auf das Bild hinweisen: 
http://www.mikrocontroller.net/attachment/55440/fuses_mega8.png
Da steht, dass der Bootloader an Adresse 0x0F00 liegen muss, warum steht 
dann im Hex-File, dass er an 0x1E00 liegt?

Kann ich irgendwie ein Lebenszeichen aus dem Bootloader bekommen? Also 
die Daten vom Programm kommen zum µC und auch an den richtigen 
Anschluss, aber der µC reagiert nicht.

[Christian (Gast)]

Hallo,

ich habe eine Schaltung mit einem ATTiny45 ohne Quarz bei der zwei 
Eingänge über einen Optokopter (HCPL0603 - invertierend) nach außen 
geführt sind.

Gibt es eine Möglichkeit den uC von außen zu flashen, obwohl ich über 
den Optokopler keine Rückmeldung realisieren kann

Gruß Christian

[Christian (Gast)]

Anbei noch ein Ausschnitt aus meiner Schaltung. Könnte ich vielleicht 
ein ONEWIRE Interface realisieren, indem ich einen Pin des ISP Steckers 
mit Strobe1_24V verbinde? Vielleicht über eine Diode oder einen 
Hochohmigen Widerstand?

Gruß Christian

[Fabian S. (jacky2k)]

Mhh wie ist das denn mit dem kompilieren des Bootloaders? In der 
Anleitung steht, dass ich die m8.asm nehmen soll, die gibt es aber nicht 
(in der Version 2.1). Dann habe ich die BOOTLOAD.ASM genommen, 
kompilierte ohne Probleme. War das denn richtig?

[Dominique G. (dgoersch)]

Ja

[Peter D. (peda)]

Fabian S. schrieb:
> (in der Version 2.1). Dann habe ich die BOOTLOAD.ASM genommen,

Ja.
Die ist für alle möglichen AVRs. Du mußt daher das richtige Headerfile 
aktiveren (Kommentarzeichen entfernen), dann stimmt auch die Adresse.

Und dann die Fuses für den Bootstart setzen, bzw. Die Selfprogrammfuse.

Wenn die Verbindung nicht klappt, ne kleinere Baudrate probieren, 
insbesondere, wenn Du die Fuses auf 1MHz läßt.


Peter

[Fabian S. (jacky2k)]

Muss ich das Selfprogrammfuse beim Atmega8 setzen? Dachte der hat keins?
Baud ist schon auf 19200 runter.
Habe inzwischen den Laptop rausgeholt und da nen USBSeriall Wandler 
angeschlossen um das ganze mal mit Windows XP 32Bit zu probieren (Hab 
sonst Vista64), geht aber auch nicht. Dann auch nicht mit dem original 
Tool.
Habe die richtige Zeile in der bootload.asm einkommentiert und das was 
schon einkommentiert war, wieder auskommentiert. Ich habe die Pins so 
gelassen wie sie waren, also sind die Pins wie die Hardware-UART Pins.
Für die Bootflags verweise ich nochmals auf den Screenshot: 
http://www.mikrocontroller.net/attachment/55440/fuses_mega8.png
Noch ne Idee?

[Fabian S. (jacky2k)]

Hat hier schon mal jemand den Bootloader für nen Atmega8 kompiliert und 
auch zum laufen bekommen? Könnte derjenige mir bitte die hex File 
zukommen lassen, damit ich das Problem der Kompilation schon mal 
ausschließen kann?
Vielen Dank.

Edit: Ich habe grade etwas interessantes rausgefunden. Wenn ich den 
Bootloader programmiere und überprüfe meint AVR Studio, dass alles OK 
ist. Wenn ich den Flash dann aber auslese in ein anderes Hex-File steht 
der Bootloader nicht drin! Da ist überall nur FFFFFF...

[Dominique G. (dgoersch)]

Hast du mal nen zweiten mega8 zum Testen hergenommen?

[Fabian S. (jacky2k)]

Jop, ist genau das gleiche Problem.

[Fabian S. (jacky2k)]

So, große Erlösung!
Es lag an dem Programm für den AVR ISP mkII des AVR Studio 4.16. Habe 
auf 4.17 aktualisiert und alles geht! Scheinbar war da irgendwie ein Bug 
beim interpretieren des Hex-Files.

[Dominique G. (dgoersch)]

Glückwunsch, da muss man erstmal drauf kommen.

[Fabian S. (jacky2k)]

Joa die Tatsache, dass er aus dem ATMega nur lauter FF gelesen hat und 
auch meinte, dass das mit dem hex-file übereinstimmt war schon etwas 
verdächtig. Habe das Hex-File dann nem Kollegen geschickt, der hats aufn 
mega8 gebrannt, wieder ausgelesen und das ausgelesene mir zurück 
geschickt, das konnte ich dann ohne Probleme brennen. :P Also alles sehr 
seltsam.

[Hagen R. (hagen)]

Das neuste AVRStuido hat da einen Bug. Kompiliert man ein HEX File das 
erst mitten im FLASH beginnt so steht im HEX File keine Daten für die 
Adresse 0x0000 im AVR. AVRStudio lädt dieses HEX File und wenn dort 
drinnen auch die Adresse 0x0000 mit Daten steht, egal was, wird es den 
AVR auch korrekt programmieren. Das erklärt auch warum das HEX deines 
Kollegen bei dir geht. Denn beim Auslesen des FLASHs wird ein HEX File 
erzeugt das alle Adressen umfasst und somit auch Adresse 0x0000. Lösung 
ist softwaretechnisch simpel: an org 0x0000 ein db 0xFF,0xFF einfügen. 
Auf dieses Problem bin ich hier gestoßen 
Beitrag "Re: AVR-Bootloader mit Verschlüsselung"
Das Fatale daran ist das der AVRStudio Programmer selbst beim Verify 
meint alles wäre ok. Stimmt aus seiner SIcht auch, denn wenn der Parser 
des HEX Files meint der FLASH müsste komplett mit 0xFF gefüllt werden 
dann wird beim Verify auch kein Fehler auftreten wenn alles mit 0xFF 
gefüllt ist.
Es liegt also definitiv am HEX File Parser des Programmers der HEX Files 
die nicht bei .Org 0 beginnen einfach alles mit 0xFF parst.

Füge also in Peters Source folgendes ein

.org 0
.db  0xFF,0xFF

Gruß Hagen

[Fabian S. (jacky2k)]

Sehr interessant. Du hast Recht, das steht in dem Hex-File nicht, aber 
GRADE in der aktuellen Version (4.17) gehts ja und in der alten (4.16) 
ging es nicht. :-/

[Hagen R. (hagen)]

Ich habe den Bug in Version 4.16 entdeckt, das es Version 4.17 schon 
gibt war mir garnicht bewusst. Schätze mal das dort der Bug schon wieder 
gefixt wurde. Dh. anscheinend ist nur Version 4.16 betroffen.

Gruß Hagen

[Hagen R. (hagen)]

Auszug aus Release Notes 4.16 SP1

>Bug Fixes
>9473 Programming dialog - Empty Flash's .hex file read-back after programming and 
verification
>9510 Programming dialog - Cannot program a bootloader

Der Fix mit .org 0 hilft aber.

Gruß Hagen

[Fabian S. (jacky2k)]

Hallo nochmal ;)
Da das ganze bei mir ja nun endlich funktioniert wollte ich eine Stufe 
weiter gehen und das ganze über ein Bluetooth Modul "tunneln".
Ich verwende dafür den UpdateLoader 2.1.9.106, da er unter Vista 64Bit 
läuft. So, wie sollte es anders sein, es geht nicht. Das seltsame ist, 
dass das Bluetooth Modul garnicht mitbekommt, dass das Programm sich 
verbunden hat. Wenn ich mit hterm rauf gehe, kommt sofort ein CONNECT, 
aber beim UpdateLoader nicht.
Woran kann das liegen? Nutzt das Programm den COM-Port in irgend einer 
abnormalen Weise oder so?

[Alfred N. (alfred-n)]

Hallo,

@ Fabian S.


vielleicht hilft es Dir einwening weiter.
Mein Upload ist 3 Beiträge weiter oben.

Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Gruß Alfred

[Fabian S. (jacky2k)]

3 Beiträger weiter oben ist was von Hagen, ohne Anhang :(
Selbst wenn, 16 Ports hilft mir 0. Der Bluetooth Port ist COM40!
Und das er so lange braucht hatte ich auch bislang immer. Sowohl mit 
PCI-Seriell Erweiterung als auch mit USB-Seriell Adapter.

[Alfred N. (alfred-n)]

also dann so

Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Die Ports kannst Du aufbohren .... ist die Source bei.

Gruß Alfred ( soviel Zeit muß sein)

[Fabian S. (jacky2k)]

Und warum geht der Source nur bis Port 16?
Da ist ja die Sonderbehandlung für Ports > 9 drin, geht das dann wieder 
nur bis 16 oder wie?

  // Open the serial port
  if (port > 9)
  sprintf(str,"\\\\.\\COM%d",port);
  else
    sprintf(str,"COM%d",port);

[Alfred N. (alfred-n)]

// Open the serial port
  if (port > 9)
  sprintf(str,"\\\\.\\COM%d",port);
  else
    sprintf(str,"COM%d",port);

IST nicht WICHTIG !


In fboot.cpp

#define COMPORTMAX  16

setze auf .... 40,41..


UND

int serial_connect (void)

{



  char WAITSTRING[] = { '|', '/', '-', '\\' };

  int i = 1;

  int echo = 0;

  char *s;

  int j = 0;

  clock_t t = clock();



  readargs( ALONG, 'b', &Baud );

  if( Baud < 2 )

    Baud = 2;

  if( Baud > 115200 )

    Baud = 115200;

  readargs( AINT, 'c', &ComPort );    // serial port

  if( ComPort > COMPORTMAX ){

  ComPort = 1;

  printf("\nCOMport > 16 -> COMport = 1 !\n");

  }


und hier


printf("\nCOMport > 41 -> COMport = 1 !\n");


so sollte es Laufen.


Gruß Alfred

[Fabian S. (jacky2k)]

Cool, danke!

Hatte noch ein paar Fehler:
...\Proj>g++ -o fboot.exe fboot.cpp serial.cpp
fboot.cpp: In function `int readhex(FILE*, long unsigned int*, unsigned 
char*)':

fboot.cpp:423: error: invalid conversion from `char*' to `unsigned 
char*'
fboot.cpp:423: error:   initializing argument 1 of `int 
sscanhex(unsigned char*,
 unsigned int*, int)'
fboot.cpp:426: error: invalid conversion from `char*' to `unsigned 
char*'
fboot.cpp:426: error:   initializing argument 1 of `int 
sscanhex(unsigned char*,
 unsigned int*, int)'
fboot.cpp:431: error: invalid conversion from `char*' to `unsigned 
char*'
fboot.cpp:431: error:   initializing argument 1 of `int 
sscanhex(unsigned char*,
 unsigned int*, int)'
fboot.cpp:435: error: invalid conversion from `char*' to `unsigned 
char*'
fboot.cpp:435: error:   initializing argument 1 of `int 
sscanhex(unsigned char*,
 unsigned int*, int)'
fboot.cpp:446: error: invalid conversion from `char*' to `unsigned 
char*'
fboot.cpp:446: error:   initializing argument 1 of `int 
sscanhex(unsigned char*,
 unsigned int*, int)'


Habe die einfach durch ein paar casts hingebogen, ist vermutlich OK.
Habe die Software nun noch nicht getestet. Wer zu faul ist, im Anhang 
ist die exe ;)
Womit hast die denn original kompiliert? Visual Studio? Die Warnings im 
g++ sind ja gresslich, solltest du dir mal ansehen.

[Alfred N. (alfred-n)]

Portiert auf C++Builder 2007 Kommando-Zeile


Gruß Alfred

[Fabian S. (jacky2k)]

OK.
Hier mal die ganzen Warnings, falls du Lust hast dir das mal anzusehen:

fboot.cpp:15: warning: ignoring #pragma hdrstop
fboot.cpp:113: warning: ignoring #pragma argsused
fboot.cpp: In function `int readargs(int, char, void*)':
fboot.cpp:140: warning: conversion lacks type at end of format
fboot.cpp:140: warning: too many arguments for format
fboot.cpp: In function `int main(int, char**)':
fboot.cpp:218: warning: double format, different type arg (arg 2)
fboot.cpp:170: warning: unused variable 's'
fboot.cpp: In function `int program(char*, int)':
fboot.cpp:323: warning: comparison between signed and unsigned integer 
expressions
fboot.cpp: In function `int read_info()':
fboot.cpp:537: warning: comparison between signed and unsigned integer 
expressions
fboot.cpp: In function `void getpasswd()':
fboot.cpp:565: warning: unused variable 'j'
serial.cpp: In function `void ShowLastError()':
serial.cpp:231: warning: char format, void arg (arg 2)
serial.cpp: In function `BOOL SerialIsChar()':
serial.cpp:452: warning: unused variable 'str'

[Alfred N. (alfred-n)]

Hier mein ORGINAL POST !!!

*****************************

Hallo,

ja als erstes "Vielen Dank an Peter Dannegger" für den Bootloader und
allen andern die das hier möglich gemacht haben!

Habe FBOOT um wenige Zeilen (Programm Zeilen) erweitert.
Neu ist :

  - Portiert auf C++Builder 2007 Kommando-Zeile (sollte aber auch mit
    DevCpp laufen).
  - Für Win32 XP und auch Vista.
  - 1Wire laeuft nun auch unter windows XP / Vista;
  - Mit USB auf RS232 Adapter(nicht TTL) und dann "PEDA 1Wire
Interface".
  - Getestet mit Prolific USB auf RS232 Adapter (Quelle Glyn) wurde von
    Vista sofort ohne Treiber Inst. erkannt.
  - Vista mit RS232 konnte ich nicht testen da mein Laptop nur USB hat;

So und nun zu den Baudraten Max. bei mir :

  - PC mit XP mit on Board RS232 (com1) weitere gibt es NICHT -> 57600
    Baud.
  - Gleicher PC mit PCI Multi-RS232-Card 8x -> 38400 Baud.
  - Laptop mit USB auf RS232 Adapter(nicht TTL) und dann "PEDA 1Wire
    Interface"-> 115200 Baud " ein Wunder !" NEIN , trotzdem ist die
    UPLOAD-ZEIT 3 mal so lang statt 2 Sek. > 6 Sek ist halt USB mit
Vista.

*********************************

Aber ich kann ja morgen bzw (heute neu Compilieren)
und uploaden.


Gruss  Alfred

[Fabian S. (jacky2k)]

So, bin nun grade mal dazu gekommen das ganze zu testen.
Es funktioniert natürlich nicht. Gehe ich richtig in der Annahme, dass 
ich beim Parameter /I das Passwort angeben muss?
Des weiteren habe ich es bisher so mitbekommen, dass das Protokoll zum 
Anfang das Passwort sendet. Das Programm macht das auch, aber scheinbar 
denkt der mega8, dass es falsch ist, denn er wartet nach dem Reset keine 
0,33 Sekunden sondern startet sofort das Programm.
Des weiteren ist mit aufgefallen, dass der UploadLoader und das Original 
Tool nach dem Passwort immer noch ein Zeichen senden. Glaube es war ein 
0xFF. Dies passiert bei Programm von Alfred nicht. Warum?

[Paul P. (dorpreuss)]

Hallo Peter,

ich habe deinen Bootloader mittlerweile schon mehrfach benutzt. Ich habe 
ihn in Controller geflasht die internen Takt haben und auch in Welche 
mit Quarz. Bei denen die den internen Taktgenerator verwenden habe ich 
immer eine externe Schaltung mit MAX232 verwendet, da bei diesen 
Projekten sonst kein RS232 vorgesehen ist.

Ich habe ein paar Feststellungen gemacht und es würde mich freuen, wenn 
du was dazu erklären könntest.

1. Der Bootloader V1.4 schafft bei mir immer nur 9600 Baud, sonst 
startet er gar nicht erst.

2. Der Bootloader V2.1 geht erst unter 4800, aber am besten unter 2400 
Baud, sonst kommt ein CRC-Error

3. Wenn ich Version 1.4 in den µC flashe, dauert das bestimmt 1 Minute 
(STK500, AVR-Studio, "richtiger" RS-232 Port), bei Version 2.1 geht es 
ca. 1-2 Sekunden

4. Im Grenzbereich der Baudrate also irgendwo zwischen 4800 und 9600 
Baud kommt es vor, dass die Übertragung der Firmware fehlerfrei ist, 
aber dennoch das Programm nicht startet. Einmal startete es sogar, 
jedoch funktionierten bestimmte Sachen nicht.

Wenn ich mit unter 2400 Baud Übertrage geht es immer problemlos.

Diese Fuses habe ich z.B. bei einem Atmega8515 gesetzt:
BOOTSZ: 256 Words
BOOTRST: gesetzt

Ich will wirklich nicht an deinem Bootloader herumkritisieren, denn er 
funktioniert ja sonst wunderbar. Ich würde nur gerne wissen, was ich 
falsch mache.

MfG

Paul

[Alfred N. (alfred-n)]

Hallo,

@ Fabian S.

das Passwort ist "Peda"

und ohne Passwort geht es NICHT !

char Passwd[130] = "Peda";

Fabian S. worte

Des weiteren ist mit aufgefallen, dass der UploadLoader und das Original
Tool nach dem Passwort immer noch ein Zeichen senden. Glaube es war ein
0xFF. Dies passiert bei Programm von Alfred nicht. Warum?

flasch !


 for(;;){



  if( (clock() - t) > 90 ){

    t += 80;

      printf( "\b%c", WAITSTRING[++j&3] );

  }

    if( kbhit() ){

   // getch();

    return 1;

  }

  s = Passwd;

    do{

      if( *s )

  senden( *s );

      else

  senden( 0xFF );

Hier wird es gesendet !


Gruss Alfred

[Fabian S. (jacky2k)]

Ähhh, seltsam. Schau ich mir heute abend noch mal an. Auf jeden Fall hab 
ich mein PC mal ran gehalten und da kam nur das PeDa an und nicht das 
0xff.

[Alfred N. (alfred-n)]

das Passwort ist "Peda" und NICHT PeDa !!!

[Daniel (Gast)]

Klasse Sache, bei meinem ATMega8 läuft der Bootloader auch prima!

Mir ist nur aufgefallen, dass man das hex-File vom Bootloader nicht mit 
AVRStudio "brennen" kann, warum auch immer jedenfalls ist der Chip immer 
leer. Dann habe ich es mit AVRDude + STK500 gemacht und schwups lief 
alles. Ich vermute mal es gibt irgendwo ne Funktion im AVRStudio um 
Bootloader zu schreiben oder ka.

Ja jedenfalls Super Sache. Bin gerade dabei eine USB Steckdose zu bauen 
und da ist es ganz nett wenn ich den µC direkt über die USB Verbindung 
(FT232) beschreiben kann.


Gruß Daniel
http://itse.homeip.net

[Dominique G. (dgoersch)]

Das ist ein Bug in einer bestimmten Version von AVRStudio. Schau mal ein 
paar Posts weiter oben, da wurde das bereits Thematisiert.

[Wirr (Gast)]

Aus bootload.asm:
;set the SecondBootStart fuse

Für m168 - um welche Fuse handelt es sich dabei, ich finde nichts im 
Datenblatt.
Ist damit gemeint:
"Boot Flash section size=256 words Boot start address=$1F00; 
[BOOTSZ=10]"

(http://www.engbedded.com/fusecalc/ )

Aha: m168def.inc
.equ  SECONDBOOTSTART  = 0x1f00

[Klaus B. (kcx650)]

Hallöle :)

Ich möchte mich an dieser Stelle mal für den tollen
Bootloader bedanken !

Ich habe das Fboot und die Änderungen von Andreas N.
in eine GUI verpackt und den Installer hier angehängt.
Evtl. kann es ja jemand gebrauchen... :)

Das Toolfenster verkleinert sich durch "X" in die Tray Leiste.
Klicken auf das kleine IC- Symbol öffnet das Toolfenster wieder.
Sollte der gewünschte Port nicht in der Liste erscheinen,
kann er direkt eingegeben werden...


Gruss

kb

[Alfred N. (alfred-n)]

Hallo,

@  Klaus Brandt (kcx650)

Find ich gut das jemand da weiter gemacht hat wo ich aufgehört habe.
Habe deinen Bootloader getestet und er läuft auch ganz gut nach dem
ich mir die fehlende "BDERTL60.BPL" aus dem Netz geholt habe.

Habe da doch einen Punkt der in das Programm einfliesen sollte.
Das Passwort sollte (müßte ) frei wählbar sein.
Dein Programm läuft aus dem Ruder wenn das falsche Passwort von
der Hardware kommt.

Auch ja da habe ich noch eine Kleinigkeit, Alfred.N und nicht Andreas.N.

Kannst Du den Source-Code hier einstellen ?

Gruss Alfred

[Klaus B. (kcx650)]

Hallo Alfred,

sorry für den "Andreas" ;) .

Die fehlende Datei ist nun mit im Installer.

Weiterhin ist die Eingabe des Passworts möglich.
Wird dieses Feld leer belassen, wird automatisch
"Peda" angenommen.

Leider kommt vom Bootloader keinerlei Rückmeldung
bei einem evtl. falschen Passwort.
Erst wenn ein Teilstring des übertragenen Passworts
mit dem "wirklichen" Passwort als übereinstimmend
erkannt wird, antwortet der Bootloader mit einem
"CONNECT". Hierdurch läuft das Flashtool, bei
falschem Passwort, bis zum Timeout...



Gruss


Klaus

[Alfred N. (alfred-n)]

Hallo Klaus,

Habe das Programm noch mal kurz getestet, alles läuft problemlos und 
fehlerfrei.

Gute Arbeit !

Kannst Du den Source-Code (das Projekt ,nehme an C++Builder)hier 
einstellen ?

Gruss Alfred

[mcfloppy (Gast)]

Hi,
habe nun einiges probiert, aber der Mega88 bleibt stumm. Ich habn Oszi 
an RX TX um gleich zu sehen wenn antwort kommt, doch diese bleibt aus. 
Also im Bootloader
   sbi  DDRD, 5
  sbi  PORTD, 5
direkt nach dem .org BootStart in der fastload.inc ergänzt....... LED 
bleibt auch dunkel.
Dann ein eigenes Testprogram geschrieben:

.include "m88def.inc"
   sbi  DDRD, 6
  sbi  PORTD, 6
ende:    rjmp ende
   .org  FirstBootStart
   sbi  DDRD, 5
  sbi  PORTD, 5

Das Funktioniert, schalt ich den bootvektor aus, geht eine led an. 
Schalt ich den bootvektor ein, gehen beide LEDs an. Dann nochmal mit 
SecondBootStart probiert. Funktioniert auch.

Habt ihr ne Idee wieso es nicht geht?
Der Mega scheint ja in Ordnung.

LG Floppy

[Paul (Gast)]

Hallo.
Kann ich für OneWire auch den Reset-Pin (eines Tiny25) nutzen? Also 
Bootloader aufspielen, anschließend das Häkchen bei RSTDISBL in 
AVRStudio setzen und dann mit Onewire an PB2 (ehemals "Reset-Pin" bzw. 
"Reset-Nicht") Programme in den Speicher laden?
Mit ISP lässt er sich anschließend nicht mehr ansprechen, das sehe ich 
schon ein. Ginge dann nur noch mit dem STK500.
Daher wäre ich euch dankbar, wenn ich vorher eine Rückmeldung bekommen 
könnte. Auch für den Fall, dass meine Sorgen unbegründet sind.
Viele Grüße
Paul

[Paul (Gast)]

Gemeint ist oben natürlich PB5, also Pin 1 (Reset), nicht PB2. 
Entschuldigung.

[Dominique G. (dgoersch)]

Ich habs noch nicht getestet, aber nach dem Umfusen ist der Reset-Pin ja 
normaler I/O. Daher sollte es gehen.

[Robert Z. (robertz)]

Hallo Bootloader,
ich würde es gerne auch mit einem AtTiny25 versuchen.

Die BOOTLOAD.ASM habe ich folgendermaßen angepasst:

.equ    STX_PORT        = PORTB
.equ    STX             = PB3

.equ    SRX_PORT        = PORTB
.equ    SRX             = PB4

Die FASTLOAD.H so:

.equ  XTAL    = 8000000  ; 8MHz, not critical
.equ  BootDelay  = XTAL / 3  ; 0.33s

alternativ auch mal XTAL = 1000000


Alles entsprechend verdrahtet, kompilieren hat auch prima funktioniert. 
Anschließen über AVR Studio flashen ging auch noch. SELFPRGEN ist 
enabled. Brown-out Detection auch.

Leider folgt dann auf /fboot /C1 /b9600 /pMain.hex nur
COM 1 at 9600 Baud: -

Den Tiny starte ich auch erst anschließend, wie beschrieben.
Leider komme ich dann aber nicht weiter. Es passiert nichts mehr, außer, 
dass sich der Strich dreht.

Ich nutze den internen Oscillator, mal 8 Mhz, mal 8/8 Mhz und den MAX232 
von TI. Getestet mit echter RS232 Schnittstelle unter Windows ME und 
alternativ mit Prolific 2303 USB zu RS232 Konverter unter Vista. 
Baudrate und COM Port jeweils mit dem Bootloader abgeglichen.

Würde mich freuen, wenn jemand wüsste, woran es scheitern könnte, und wo 
vielleicht die Lösung liegen könnte.

Und ist es schon mal jemandem gelungen, mit dem interen Oscillator den 
Bootloader zu nutzen?

Viele Grüße
Robert

[Dominique G. (dgoersch)]

Robert Zimmermann schrieb:
> Würde mich freuen, wenn jemand wüsste, woran es scheitern könnte, und wo
> vielleicht die Lösung liegen könnte.

Dabei kann ich dir leider nicht weiterhelfen, aber:

> Und ist es schon mal jemandem gelungen, mit dem interen Oscillator den
> Bootloader zu nutzen?

Ja, ich nutze den Bootloader ausschliesslich ohne Quarz nur mit internem 
Taktgeber, allerdings auf einem mega16.

[Alfred N. (alfred-n)]

Hallo,

Robert Zimmermann schrieb:

>Leider folgt dann auf /fboot /C1 /b9600 /pMain.hex nur
>COM 1 at 9600 Baud: -

Teste mal:  fboot /b9600 /c1 /pMain.hex /vMain.hex /iPeda

Das Passwort ist "Peda" !

Gruß Alfred

[Robert Z. (robertz)]

Danke Alfred. Leider kommt auch hier die gleiche Ausgabe. "COM 1 at 9600 
Baud: - " und keine Möglichkeit zur Eingabe des Passworts.

Kann ich vielleicht den Oszillator des Tinys kallibrieren? Aber soweit 
ich es verstanden habe, ist das schon Bestandteil des Bootloaders. 
Andererseits hätte ich ja noch das Oscillator Calibration Byte aus dem 
AVR Studio Programmierinterface. Könnte das dem Bootloader helfen?

Und Danke für die Zuversicht, Dominique :) Vermutlich hast du beim Mega 
aber Hardware UART genutzt, oder?

Viele Grüße
Robert

[Dominique G. (dgoersch)]

Robert Zimmermann schrieb:
> Und Danke für die Zuversicht, Dominique :) Vermutlich hast du beim Mega
> aber Hardware UART genutzt, oder?

Ja, normal tue ich das. Aber ich meine ich habs auch schonmal auf einem 
anderen Pin genutzt.

[Robert Z. (robertz)]

Hallo,
ich hab es jetzt auch mit dem Mega8 an den Pins C1 und C2 getestet, also 
Software UART. Echte RS232 Schnittstelle unter Windows ME. Fuses wie in 
der Pdf gesetzt.

Das führt bei mir zu

COM 1 at 9600 Baud: Connected
Bootloader V2.1
Target 1E9307 ATmega8
Buffer: 960 Byte
Size available: 7600 Byte
Program TEST.hex: 00000 - 00091 successful
Verify TEST.hex: 00000 - 00091 failed!
Verify-Error

Ich hab auch beim Gerätemanager unterschiedliche Handshakes eingestellt 
und es mit unterschiedlichen Baudraten versucht. Jeweils mit dem 
Bootloader abgeglichen.
Ebenso mit 1Mhz und 8 MHz.
Bei manchen Baudraten kommt stattdessen auch "CRC: failed!" oder 
"Program ... failed"

Mit dem Bascom Terminal unter Windows ME funktioniert der Datenfluss in 
beide Richtungen.

Könnte mein serielles Kabel zu lang sein? Das misst 3 Meter.
Ist der Bootloader da empfindlicher als das Bascom Terminal?

Viele Grüße
Robert

[Peter D. (peda)]

Versuch mal ne höhere Baudrate (19,2k oder 38,4k), vielleicht ist der 
Timeout etwas knapp.


Peter

[Robert Z. (robertz)]

Danke, damit wäre ich jetzt kurz vor dem Ziel.
Es funktioniert nun auch beim Attiny25. Leider aber nicht mit OneWire an 
PB5, dem nun deaktivierten RESET-Pin.

fboot kommt über "COM 1 at 19200 Baud: / " nicht hinaus.

Das Multimeter meldet währenddessen zwischen PB5 und GND 2,7 Volt.
Läuft fboot nicht, zeigt es 0 V an.


An PB3 funktioniert es tadellos, mit OneWire. Natürlich mit entsprechend 
geändertem Bootloader.

Ich habe den Bootloader mit AVR Studio geflasht. Anschließend das 
Häkchen bei SELFPRGEN gesetzt und das Häkchen bei CKDIV8 entfernt, weil 
er ja mit 8 MHz laufen soll. Brown-out bei 4,3 V.
So stehts auch in der Fastload.h.
Und in der Bootload.asm steht

.equ    STX_PORT        = PORTB
.equ    STX             = PB5

.equ    SRX_PORT        = PORTB
.equ    SRX             = PB5

und .include "tn25def.inc"

Wurde auch fehlerfrei kompiliert.

Um sicher zu gehen, habe ich erst danach auch das Häkchen bei RSTDISBL 
gesetzt.

Int RC Osc. 8 MHz ...+64ms, also Standard. Man soll ja wohl den höchsten 
Wert nehmen.

Ich hab allerdings statt der N4148 Dioden N4001 eingestezt. 
Reset-Versuch erfolgt An und Ausschlaten des Netzgeräts. Jumper bzw. 
Schalter sind nicht eingebaut.
Könnte der Ex-Reset Pin damit Probleme haben? Bei PB3 hat es doch aber 
auch funktioniert. Ist PB5, wenn man Reset deaktiviert nicht ein 
vollwertiger I/O-Pin, oder gibt es da Besonderes zu beachten?
Kann mir vielleicht jemand einen Vorwiderstand empfehlen. Gefunden hab 
ich dazu leider nichts.

Oder muss ich vielleicht noch das Häkchen bei SPIEN entfernen. Ist mit 
meinem USB MKII erst mal nicht zu machen. Und hier steht ja auch bisher 
nichts dazu, scheint also auch unwahrscheinlich zu sein.

Viele Grüße
Robert

[Robert Z. (robertz)]

kleiner Nachtrag: Die Verbindung zwischen PB5 und 10 kOhm Widerstand -> 
GND besteht auch nicht mehr. Es führt nur eine Leitung wischen Diode und 
4,7k Ohm Widerstand.

Beitrag editieren funktioniert gerade nicht. Entschuldigung.

[Christian (Gast)]

Hallo,

gibt es eigentlich eine Möglichkeit im Bootloader ein paar Bytes an 
Userdata zu schreiben und auch wieder auszulesen.

Hindergrund:

Das wäre eine sehr komfortable Möglichkeit die Versionsnummer des 
geflashten Programms abzulegen und auszulesen.

Natürlich könnte ich das auch in meinem Programm selbst machen, aber 
dann muss ich mich um die Schnittstelle und das Protokoll kümmern. Und 
das alles nur für eine Versionsnummer. Der Bootloader hat die 
grundsätzlichen Funktionen dafür ja schon...

Gruß Christian

[Robert Z. (robertz)]

Funktioniert leider immer noch nicht (wie oben beschrieben).
Ich würde es ja nun gerne mal mit dem Watchdog testen. Da hab ich 
allerdings, wie mir gerade auffiel, noch ein Verständnisproblem:

Dazu müsste ich doch über die serielle Schnittstelle, bei mir an PB5 des 
Tiny25 auf den Speicher zugreifen können.
Ich müsste also in das eigentliche Programm, also die "main.hex" eine 
Software UART Schnittstelle integrieren.

Da es mir aber nicht gelingt, über mit dem Bootloader die main.hex in 
den Controller zu schreiben, komme ich so nicht weiter, oder?

Könnte mich bitte mal jemand in die richtige Richtung schubsen? Würde 
mich freuen.

Viele Grüße
Robert

[Christian J. (stormracer)]

Moin,

bei mir läuft der Bootloader jetzt schon seit ca. einem halben Jahr auf 
meinem Asuro. Jetzt suche ich nur noch eine Möglichkeit, den Bootloader 
mit einer GUI zu benutzen. Hier sind ja schon ein paar aufgetaucht, aber 
soweit ich das gesehen hab alle in Delphi geschrieben. Gibt es auch 
schon welche die in C geschrieben sind? Oder in Java, dass will ich 
sowieso noch lernen ...

Christian

[lit (Gast)]

Hallo Christian,

weiter oben habe ich schon mal java Code attached der den Bootloader 
steuert,
aber noch ohne GUI drüber.
Der Code von damals funktioniert ist aber noch nicht schön.
Ich denke aber das ich in den nächsten 1-2 Monaten daran weiter arbeiten 
werde. Wenn er fertig ist werde ich ihn wieder hier einstellen.

[Philipp D. (arcon)]

Hallo,
ich versuche nun seit mehr als 10Std den Bootloader von Peter zum Laufen 
zu bringen.
Mir ist klar, dass das eine triviale Sache sein müsste, jedoch bin ich 
neu im AVR Sektor!

Nun zu den Fakten:
--------------------
> Pollin Funk AVR Board
> USB-RS232 Adapter
> Atmega8
> PonnyProg für den Upload (Serial: SI Prog API # Com4 # keine Hackerln gesetzt)
> avrasm zum compilieren der ASM

Ich habe schon ein kleines Programm via PonyProg raufgeladen und das hat 
funktioniert (LED aufleuchten).

Nun zum Problem:
-------------------
* ich habe in der Bootloader.asm (oder m8.asm wie ich sie nenne" das 
"m8def" für den Atmega8 entkommentiert und "m168def.inc" kommentiert.
* Kompilation mittels avrasm (generic -fG, da PonnyProg sonst nur FF 
Werte anzeigt) zu einer HEX
* Den Bootloader habe ich mittels PonnyProg

versucht

 auf den Atmel zu laden, jedoch (nach 50min #Write-Verify#) "Write 
failed" !?

Nun zu meinen weiterführenden Fragen:
-------------------------------------
> Wenn ich den Bootloader auf den Chip geladen habe, wie kann ich dann Programme 
auf den > Chip laden: ISP(Rs232) oder Seriell (RS232)?
> Wie müssen die Fuses gesetzt werden (externer Quarz )
> Mit welchem Programm müssen die Fuses gesetzt werden?

Ich habe nun schon annähernd alle eure Tutorials für diese Themen 
gelesen und auch schon das Forum durchstöbert -> Kein Uploaderfolg =(

Könnt ihr mir helfen?

Lg
Tobias

[Benedikt K. (benedikt)]

Mal eine allgemeine Frage:
Wie funktioniert eigentlich der Bootloader für die Tinys? Bei den megas 
ist es klar: Durch die BootReset Fuse wird zuerst der Bootloader 
angesprungen, der dann an die Adresse 0 zurückspringt. Aber wie geht das 
bei den AVRs ohne die Fuse?
Wird da der Befehl an Adresse 0 manipuliert? Und woher weiß der 
Bootloader wie er dann die eigentliche Software starten soll?

[Tobias T. (Firma: codes4web) (roverfreak)]

Startet der Bootloader bei irgendjemandem auch ständig neu?
Habe ich eine Fuse vergessen?

Lg
Tobias

[Hagen R. (hagen)]

@Benedikt:

Ja der RESET Vektor wird manipuliert. Dessen originaler Inhalt wird in 
den letzten 2 Bytes vor dem Bootloader als RJMP/JMP gespeichert.

Wichtig ist dabei die Vorgehensweise aus Löschen, Patchen, Neuschreiben 
dieser zwei FLASH Pages im laufenden Bootloader Betrieb. Wenn man es 
richtig macht geht das ziemlich problemlos und sicher.

Gruß Hagen

[Benedikt K. (benedikt)]

Danke für die Erklärung.
Das hatte ich schon vermutet, nur hatte ich mich gefragt wie vor allem 
der Rücksprung geht, denn den führt ja der Bootloader aus, aber der kann 
nicht verändert werden.
Diese Adresse direkt vor den Bootloader zu packen ist natürlich sehr 
geschickt...

[Peter D. (peda)]

Wobei im Unterschied zu Hagens Bootloader mein Bootloader alles nötige 
selber macht.
Über die UART kann also der größte Stuß reinkommen, der Bootloader wird 
nie unerreichbar.
Man müßte schon eine Applikation reinladen, die absichtlich den 
Bootloader löscht.

Bei Hagen ist das PC-Programm voll verantwortlich, daß Sprungberechnung 
und Reihenfolge stimmen. Daher ist auch die CRC unbedingt nötig, um 
fehlerhafte Aktionen abzuweisen.


Peter

[Hagen R. (hagen)]

Das ist eine Frage der Wahrscheinlichkeiten, hatten wir schonmal kurz 
diskutiert ;) Wenn die PC Software die 1. und letzte FLASH Page 
gesondert behandelt, dann sinken die Wahrscheinlichkeiten für einen 
Deadlock. Zb. zuert letzte Page löschen, damit vorherigen RJMP MAIN 
löschen. Dann alle Pages ab der 2. schreiben und erst am Schluß die 1. 
und letzte Page mit den neuen Werten. Da die CRC von Hause aus drinnen 
ist es nicht zwangsläufig eine Begründung für ihre Existenz.

Es hat eben einen entscheidenden Vorteil. In den meisten Fälle nutzt man 
eh ATmegas und da trifft dieses Problem nicht zu. Im Fall des ATTinys 
lagert es aber zusätzliche Komplexität in die PC-Software aus und das 
führt dann dazu das mein Bootloader in diesem Fall bei gleicher 
Funkionalität bis zu 20% kleiner ist als deiner. Das war auch der 
Hauptgrund für meine Entscheidung da ich für Tinys möglichst jedes Byte 
an FLASH sparen wollte.

Nungut, wer das I-Tüpfelchen Sicherheit mehr haben möchte dem rate ich 
natürlich zu Peters Bootloader ;)

Gruß Hagen

PS:
>Über die UART kann also der größte Stuß reinkommen, der Bootloader wird
>nie unerreichbar.

Gewagte Aussage übrigens ;) Wenn ausgerechnet dieser JMP falsch 
reinkommt und ohne CRC abgesichert wurde dann wirds auch bei deinem 
Bootloader krachen.  Selbst eine CRC deckt nicht alle Fehler ab, das 
weist du. Auch wenn gerade beim Programmieren dieser FLASH Page ein 
Spannungseinbruch erfolgt wird es einen Deadlock geben. Nie, zu 
behaupten ist also sehr gewagt.

[Hagen R. (hagen)]

Übrigens, das was ich an FLASH Sepicher sparen konnte durch mein 
Vorgehen habe ich teilweise verwndet um für das FLASH und EEPROM 
Schreiben ein implizites Verify einzubauen. Dh. jede FLASH page wird 
sofort nach dem Schreiben auch überprüft. Das verhindert natürlich keine 
Kommunikationsfehler aber falls dochmal das Schreiben fehlschlägt 
versucht es die PC-Software bis zu dreimal und bricht dann ab. Bei Tinys 
lässte es den RJMP Bootloader im RESET Vektor stehen und die letzte 
FLASH Page in der normalerweise der RJMP MAIN steht bleibt weiterhin 
gelöscht. So denke ich verhindere ich mit hoher aber nicht absoluter 
Wahrscheinlichkeit eines Deadlocks bei Schreibfehlern ins FLASH.

Auf alle Fälle stimme ich mit Peter darin überein das man sehr genau 
vorgehen sollte und sich über den Programfluß 100% sicher sein sollte 
bei diesem Vorgehen. Ansich ist also die Implementierung der Berechnung 
dieser Sprungvektoren im AVR Bootloader zu machen eine gute Idee. Denoch 
schützt auch sie nicht zu 100% vor einem Deadlock. Also bei meinen Tiny 
Projekten hatte ich mit solchen Deadlocks noch nie Probleme.

Gruß Hagen

[Robert Z. (robertz)]

Dominique Görsch schrieb:
> Ja so mache ich es bei mir und es klappt einwandfrei. Allerdings nutze
> ich momentan Bascom und kein C.
>
> Ich prüfe in der UART ISR einfach ob das Zeichen besagtes 0xff (255
> binär) ist, und starte dann den Watchdog:
>
>

Urxc_isr:
>    Key = Inkey()
>    If Key = 13 Then
>       Flag = True
>    Elseif Key = 255 Then
>       Start Watchdog
>    Else
>       Inputstr = Inputstr + Chr(key)
>    End If
> Return

>
> Ist es 13 (Return) setze ich ein Flag was ich in der Mainloop auswerte,
> bei jedem anderen Zeichen wird es einfach an einen String angeängt (für
> ankommende Befehle die ich in der Mainloop dann ausführe). Da ich aber
> nach jetzigem Stand mit 254 Befehlen auskommen werde, werde ich das bei
> Gelegenheit noch umstellen und die Klartext-Kommandos verwerfen.
>
> Gruß
> Dominique Görsch

Hallo Dominique, hallo Bootloader.
Ich hätte ein paar Fragen zu diesem Schnipsel, wenn du erlaubst.

1)Habe ich es richtig verstaden, dass du Urcx_isr in der Mainloop bei 
jedem Programmdurchlauf aufrufst?

2) Wenn du keine Taste drückst, startet der Controller neu. Richtig?

3) Wenn ich nun wollte, dass der Controller bei Tastencode 65 
neustartet, wo müsste ich denn das A (65) denn nun eingeben? In das 
Bascom-Terminal?

Damit wäre doch aber der COM Port belegt, über den der Controller 
anschließend das Programm empfangen könnte.
Oder sendest du das Programm auch gleich über das Bascom Terminal? Geht 
das?

Würde mich freuen wenn du, oder jemand mir das erklären könnte(st).

Viele Grüße
Robertz

[Timo S. (kaffeetas)]

Hallo Robertz,
1. Die der RXC Interrupt wird immer dann angesprungen wenn dieser 
aktiviert ist und ein Zeichen vom Uart empfangen wurde.

2. Die 0xff werden vom PC-Programm gesendet, wenn du das ändern willst 
dann mußt du das PC Programm anfassen. Dadurch führt der µC einen Reset 
aus, so braucht keine Reset Taste gedrückt zu werden um in den 
Bootloader zu kommen.

@Peter
Ich hab es schon mehrfach geschafft den Bootloader zu killen. In einem 
Projekt mit dem Tiny2313 verwende ich alle I/O einschließlich Reset. 
UART ist nicht vorgesehen. Als einzige Möglichkeit einen Reset 
durchzuführen bleibt IMHO der Power-On Reset. Diesen Erzeuge ich manuell 
durch anhalten von Batteriehalter Klipsen. Nun kann es halt passieren 
dass die Spannungsversorgung nicht so ganz auf Anhieb klappt, der 
Bootloader aber schon am updaten ist, danach ist Sense.
Komischerweise ist das Hexfile das ich danach vom µC auslesen kann im 
Bootloader Bereich korrumpiert. Gibt es hierzu eine einfache 
Erklärung/Abhilfe?

Ich habe mal 2 files angehängt:
Bootload.hex --> Bootloader wie ich ihn flashe und auch sehr gut 
funktioniert
BL_def.hex --> µC Inhalt nach fehlgeschlagenem Flashversuch.

Das soll in keinster Weise eine Kritik an dem hervorragend 
funktionierenden Bootloader sein.
Leider hat das kleine Projekt mit der Zeit alle I/O`s gefressen, bis 
auch der Reset Pin weg war.So ist das eigentliche Problem hier zu 
suchen.
Auch die Verbindung mit der Betriebspannung ist etwas tricky da sich der 
Tiny gern parasitär aus den Bootloaderleitungen versorgt. Am besten 
funktioniert es wenn ich den Bootloader und VCC verbinde, danach das PC 
Programm starte und dann erst GND verbinde. Mich wundert es echt dass 
ich dabei noch keinen µC komplett getötet habe es funktionieren alle 
noch prima. Auch das bei Fehlschlägen notwendige Auslöten der µC im 
SOIC20 Gehäuse haben bisher alle überstanden.


Grüße
 Timo

[Robert Z. (robertz)]

Danke Timo! Ein paar Unklarheiten bleiben noch

Timo S. schrieb:

> 1. Die der RXC Interrupt wird immer dann angesprungen wenn dieser
> aktiviert ist und ein Zeichen vom Uart empfangen wurde.

Das funktioniert nicht bei der Software UART von Attinys, oder? Bascom 
sagt zumindest es sei eine "unknown interrupt source [URXC_ISR]"

Gibts also bei Software UART gar keine Lösung, ein Programm zu laden, 
ohne den Strom abzuklemmen oder einen Reset-Knopf einzubauen?
Leider hab ich auch nur einen Pin zur Verfügung und lade das Programm 
über den deaktivierten RESET-Pin.


> 2. Die 0xff werden vom PC-Programm gesendet, wenn du das ändern willst
> dann mußt du das PC Programm anfassen. Dadurch führt der µC einen Reset
> aus, so braucht keine Reset Taste gedrückt zu werden um in den
> Bootloader zu kommen.

Welches PC Programm sendet die 0xff (255)? Die cmd.exe, sobald ich fboot 
/c4 /b9600 /pmain.hex eingebe? Ich müsste also außer dieser Zeile nichts 
anderes senden, und der Upload würde sofort starten?


Viele Grüße
Robert

[Timo S. (kaffeetas)]

naja die UART Funktion mußt du Dir in Bascom basteln habe keine Ahnung 
wie das bei Bascom/SoftUART aussieht.
Den Reset löst man üblicherweise mit dem Watchdog aus. Man muss dann 
darauf achten dass der Watchdog sofort bei Programmstart deaktiviert 
wird!

>Welches PC Programm sendet die 0xff (255)? Die cmd.exe, sobald ich fboot
>/c4 /b9600 /pmain.hex eingebe? Ich müsste also außer dieser Zeile nichts
>anderes senden, und der Upload würde sofort starten?

Richtig erkannt aber eigenlich ist es die fboot.exe! Damit ist es sehr 
komfortabel zu arbeiten.

Grüße
 Timo

[Robert Z. (robertz)]

Timo S. schrieb:
> naja die UART Funktion mußt du Dir in Bascom basteln habe keine Ahnung
> wie das bei Bascom/SoftUART aussieht.

SoftUART geht ja so

Open "comb.3:9600,8,n,1" For Output As #1

Meintestdu das mit SoftUART basteln?

Wenn ich aber

On Urxc_isr
Enable Urxc_isr

Enable Interrupts

eingebe, kommt beim Syntax-Check die Fehlermeldung "unknown interrupt 
source [URXC_ISR]"

Oder muss ich mir die Urxc_isr auch selbst basteln? Meine Frage ging ja 
in die Richtung, ob ich es dieses Interrupt bei SoftUART überhaupt gibt, 
da es ja kein "richtiges" UART ist.


> Den Reset löst man üblicherweise mit dem Watchdog aus. Man muss dann
> darauf achten dass der Watchdog sofort bei Programmstart deaktiviert
> wird!

Kann ich den Watchdog nicht einfach erst mit "Start Watchdog" dann 
starten, sobald 0xff reinkommt? Ist es nicht das, was Dominique macht?

Grüße
Robert

[Dominique G. (dgoersch)]

Öhm ja, im Grunde wurde alles gesagt. Ich nutze Hardware-UART (auf einem 
ATmega16) und die Funktion "URXC_ISR" ist der UART-Interrupt (ich dachte 
immer ISR deutet generell auf eine Interruptroutine hin?!?). Das 0xff 
wird von fboot.exe oder auch anderen hier im Thread verlinkten 
Updateclients vor dem Verbindungsaufbau gesendet und sorgt in meiner 
Firmware mittels Watchdog für einen Reset des AVR. So braucht die 
Zielschaltung keinen Reset-Taster (der bei mir wegen Einbau ohnehin 
nicht zugänglich wäre).

Bisher hatte ich noch keine Zeit dazu, aber die Update-Routinen sollen 
bei mir in die PC-Software einfliessen, mit der die Zielschaltung 
(I/O-Interface für ein Mischpult) auch konfiguriert wird. So braucht der 
Anwender nur eine Software mit der er auch die Firmware updaten kann, 
wenn ich mal eine neue Version rausbringe.

Gruß
Dominique Görsch

[Dominique G. (dgoersch)]

Ergänzend, nachdem sich das Schreiben der Beiträge überschnitt:

Robert Zimmermann schrieb:
> Wenn ich aber
>
>

On Urxc_isr
> Enable Urxc_isr
> 
> Enable Interrupts

>
> eingebe, kommt beim Syntax-Check die Fehlermeldung "unknown interrupt
> source [URXC_ISR]"

Richtig, nachdem der ATtiny (außer dem ATtiny2313) kein UART hat, hat er 
natürlich auch keinen Interrupt dafür.

>> Den Reset löst man üblicherweise mit dem Watchdog aus. Man muss dann
>> darauf achten dass der Watchdog sofort bei Programmstart deaktiviert
>> wird!
>
> Kann ich den Watchdog nicht einfach erst mit "Start Watchdog" dann
> starten, sobald 0xff reinkommt? Ist es nicht das, was Dominique macht?

Genau das mache ich. Der Watchdog ist vorkonfiguriert auf die kürzeste 
Wartezeit aber nicht gestartet. Somit führt er quasi direkt nach dem 
Start (weiß grad ned auswendig wieviel ms er wartet) einen Reset aus.

[Robert Z. (robertz)]

Hallo Dominique

Dominique Görsch schrieb:
> Öhm ja, im Grunde wurde alles gesagt. Ich nutze Hardware-UART (auf einem
> ATmega16) und die Funktion "URXC_ISR" ist der UART-Interrupt (ich dachte
> immer ISR deutet generell auf eine Interruptroutine hin?!?).

Da haben sich die Beiträge wieder überschnitten. Daher 1x edit damit es 
nicht zu verwirrend wird:

Dein Programmschnipsel funktioniert also nur mit Hardware UART.
Habe ich mit einem kleinen Attiny25 also keine Chance, ohne Strom 
abklemmen oder Reset-Button ein Programm hochzuladen? Gibts dafür keine 
Software Variante?

Gruß
Robert

[Timo S. (kaffeetas)]

es funktioniert so: wenn deine Softwareuart ein Zeichen empfangen hat, 
dann prüft das Programm ob es 0xff ist wenn ja dann reset sonst.....

Wie du das konkret in Bascom mit der dort verfügbaren Software Uart 
umsetzen kannst weiß ich nicht.

Wenn du da nicht weiterkommst mach aber am besten einen neuen Thread 
auf, denn in der Codesammlung hat das nichts zu suchen. Der Thread hier 
ist schon verwirrend lang genug!

Grüße
 Timo

[Peter V. (pemimu)]

Hallo Peter,

vielen Dank für eines deiner zuverlässigen Programme. Die Software des 
Bootloaders funktioniert sehr zufriedenstellend. Ich benutze zum 
kabellosen programmieren das Bluetoothmodul BTM222. Das serielle Signal 
muss zum programmieren invertiert werden, wenn man kein klassisches 
RS232 Protokoll benutzt. An welcher Stelle in Deinem Bootloaderprogramm 
kann ich die Signale RXD und TXD invertieren. Hagen Re hat in seinem 
Bootloader dafür eine Variable eingebaut.

Vielen Dank für Deine Bemühungen
pemimu

[Peter D. (peda)]

Ich hab die Umpolung mit dem Eindrahtmodus kombiniert.
Es sind diese Macros in der fastload.h:

  .macro  TXD_0
  sbi  STX_DDR, SRX    ; strong pullup = 0
  .endmacro
  .macro  TXD_1
  cbi  STX_DDR, SRX    ; weak pullup = 1
  .endmacro
  .macro  SKIP_RXD_0
  sbis  SRX_PIN, SRX    ; low = 1
  .endmacro
  .macro  SKIP_RXD_1
  sbic  SRX_PIN, SRX    ; high = 0
  .endmacro

Peter

[Peter V. (pemimu)]

Hallo Peter,

vielen Dank für Deine Hilfe. Werde es gleich mal ausprobieren. Respekt 
für Deine Mühen und Deine Zeit, die Du hier im Forum rein steckst und 
dadurch vielen bei ihren kleineren Problemen hilfst.
Eine besinnliche Weihnachtszeit wünscht Dir ein Fan Deiner eingestellten 
und zuverlässigen Codes :-)
Nochmals vielen Dank dafür.

pemimu

[Peter V. (pemimu)]

Hallo Peter,

Sorry das ich noch mal stören muß. Ich habe Deinen Code folgendermaßen 
abgeändert.

 .macro  TXD_0
  cbi  STX_DDR, SRX    ; strong pullup = 0
  .endmacro
  .macro  TXD_1
  sbi  STX_DDR, SRX    ; weak pullup = 1
  .endmacro
  .macro  SKIP_RXD_0
  sbic  SRX_PIN, SRX    ; low = 1
  .endmacro
  .macro  SKIP_RXD_1
  sbis  SRX_PIN, SRX    ; high = 0
  .endmacro


Nach dem Starten des Flashers fboot.exe und dem Resetten des Chips wird 
versucht, eine Kommunikation aufzubauen. (ich vermute mal, das das 
innerhalb der BootDelay – Zeit ist)Ich habe einen mal einen Oszzi am 
Onewirepin angeschlossen. Nach kurzer Zeit  wird dieser Pin auf High 
durch den Chip gezogen während der Flasher weiterin versucht, eine 
Verbindung auf zu bauen. Gemessen jeweils an den Anschlüssen des R2 
Widerstands. Irgendwo in der Routiene müßte noch was umgestellt werden. 
Könntest Du mir nochmal helfen? Vielen Dank dafür.

pemimu

[Slevin (Gast)]

Hallo Leute,

ich habe den Bootloader auf meinem Mega32 drauf und es funktioniert 
einwandfrei (habe die fertige M32 Datei verwendet)! Allerdings habe ich 
ein kleines Problem, wenn ich den Controler starte oder resete (ohne ein 
Programm drauf zu spielen), dann schalten sich ein paar Pins vom Port C 
kurzzeitig (ca. 0.5s) an. Danach werden sie wieder von meim Programm auf 
LOW gesetzt.
Könnte man dies irgendwie vermeiden, da es für meine Verwendung eher 
störend wirkt?

Gruß
Slevin

[Peter D. (peda)]

Der Bootloader prüft, ob das Paßwort angelegt wird. Dazu schaltet er den 
Pullup am RXD ein, damit der nicht floatet und den TXD als Ausgang, 
damit kein Mist gesendet wird.

Wenn das stört, definiere einfach irgendwelche 2 anderen Pins als SRX 
und STX und assembliere dann neu.


Peter

[Slevin (Gast)]

Hi,

also ich hab noch mal nach geschaut und in der M32.asm werden die Pins 
vom Port D für STX und SRX verwendet.
Noch eine andere Idee?

Gruß
Slevin

[Max (Gast)]

das Teil geht iwie bei mir nich avrasm geht so als DOS-Box auf und 
sofort wieder weg (bevor man was lesen kann).
Ich hoff jemand kann mir armen Anfänger helfen :).
PS: sry falls ich Unvollständiges/nicht Brauchbares erzähl aber ich bin 
wie gesagt neu (2 Wochen) und weiss nicht genau worauf es bei so ner 
fehlererklärung ankommt...sagt bitte wenn ihr noch i-welche infos dazu 
braucht.
Ich hoff jemand weiss rat für mich.

[Bernd O. (bitshifter)]

Max schrieb:
> das Teil geht iwie bei mir nich avrasm geht so als DOS-Box auf und
> sofort wieder weg (bevor man was lesen kann).
> Ich hoff jemand kann mir armen Anfänger helfen :).
> PS: sry falls ich Unvollständiges/nicht Brauchbares erzähl aber ich bin
> wie gesagt neu (2 Wochen) und weiss nicht genau worauf es bei so ner
> fehlererklärung ankommt...sagt bitte wenn ihr noch i-welche infos dazu
> braucht.
> Ich hoff jemand weiss rat für mich.
Das sind ja ganz fundamentale Probleme im Umgang mit den Tools. Ich habe 
zwar kein Windows mehr hier, aber Du solltest avrasm nicht direkt im 
Explorer anklicken, sondern im Startmenü unter "Ausführen" erst mal cmd 
aufrufen, dann bekommst Du eine Dos-Box. Dort kannst Du dann in den 
Ordner wechseln, in dem die Dateien liegen und dann den Assembler 
aufrufen. Dann gibt's auch Output zu sehen.

Ich will Dir jetzt nicht zu nahe treten, aber brauchst Du wirklich einen 
Bootloader? Vielleicht besser erst mal mit "normalem" Flashen 
Erfahrungen sammeln und erst bei wirklichem Bedarf einen Bootloader 
verwenden.

Gruß,
Bernd

[Vincent G. (Gast)]

Moin allerseits!

Zuersteinmal vielen Dank für den Bootloader und die rege Diskussion. Auf 
einem STK500 hab ich den Bootloader problemlos ausprobieren können, mit 
einem Prolific USB/Seriell Konverter gabs keine Probleme. Nun schaffe 
ich es aber partout nicht, das ganze an einem anderen Gerät zum laufen 
zu bekommen. Dieses ist per USB angeschlossen. Auf dem Board wird von 
einem FTDI232RL auf den UART/RS232 übersetzt wird. Der FTDI wird nicht 
zur Versorgung dieses Boards genutzt.
Die Hardware funktioniert ( "normal" geflashtes Programm läuft, 
Kommunikation in beide Richtungen getestet ).
Allerdings schaffe ich es nicht, das fboot über den Wartestatus 
hinauskommt. Eine Verlängerung der Wartezeit im Bootloader habe ich 
bereits eingebaut und ebenfalls erfolgreich auf dem STK500 getestet.
Gibt es mit dem FTDI eine bestimmte Reihenfolge oder irgendwelche 
Tricks? Habe schon allerlei ausprobiert aber bis jetzt noch keinen 
Erfolg gehabt.

Grüße Vincent

[Bernd O. (bitshifter)]

Vincent G. schrieb:
> Moin allerseits!
>
> Zuersteinmal vielen Dank für den Bootloader und die rege Diskussion. Auf
> einem STK500 hab ich den Bootloader problemlos ausprobieren können, mit
> einem Prolific USB/Seriell Konverter gabs keine Probleme. Nun schaffe
> ich es aber partout nicht, das ganze an einem anderen Gerät zum laufen
> zu bekommen. Dieses ist per USB angeschlossen. Auf dem Board wird von
> einem FTDI232RL auf den UART/RS232 übersetzt wird. Der FTDI wird nicht
> zur Versorgung dieses Boards genutzt.
> Die Hardware funktioniert ( "normal" geflashtes Programm läuft,
> Kommunikation in beide Richtungen getestet ).
Vermutlich fehlt Dir noch eine Invertierung dazwischen. Der Bootloader 
ist per Default (zumindest für One-Wire) darauf ausgelegt, die Pegel zu 
erzeugen, wie sie auf RS232 direkt nötig sind (Startbit ist high, 15V). 
Der FTDI wird für das Startbit vermutlich low erwarten.

Das lässt sich aber im Bootloader durch die Änderung der Markos für die 
Pins leicht anpassen.

Gruß,
Bernd

[Vincent G. (Gast)]

Das ganze läuft im 2-wire, aber vielleicht ists da ja auch so, werd ich 
am Donnerstag mal durchmessen. Vielen Dank für den Tipp :)

[Michael (Gast)]

Hallo Peter,

warum bekomme ich CRC-Errors wie im angehängten Bild? Ich habe die XTAL 
auf meinen 5MHz-Quarz geändert. Gibt es noch eine weitere Einstellung, 
die ich ändern muß?
Auch das Setzen von .equ CRC = 0 bringt nichts. Wo liegt mein Fehler?
Gruß
Michael

[Sven K. (Gast)]

Hi Michael,

1. fboot.exe mal in ein Verzeichnis c:\fboot kopieren.
1.1 Start-Ausführen -> cmd eingeben
1.2 ins Verzeichnis c:\fboot wechseln -> cd c:\fboot

2. Parameter für den Aufruf sind dann

 fboot /C1 /Pmain.hex

vorausgesetzt main.hex befindet sich auch in C:\fboot.

Dann wird das auch funktionieren.

Gruß Sven

[Sven K. (Gast)]

Achso vergessen:

supername_hex_was_weissichwietollername.hex mal in main.hex umbenennen.

-> kurze Dateinamen

Steht aber alles weiter oben im Thread.

Gruß Sven

[Michael (Gast)]

Hallo Sven,

hast natürlich Recht mit den kurzen Namen (hatte dann später auch 
gelesen, dass sie DOS-Konform sein sollten.)...
!! Aber: CRC-Error besteht trotzdem.-->siehe Anhang !!

fboot /C1 /main.hex,  fboot /C1 /Pmain.hex, fboot.exe /C1 /main.hex 
funktioniert alles nicht.

Der Bootloader meldet sich ja richtig, nur bricht er eben mit der o.g. 
Fehlermeldung ab.

Gruß
Michael

[Michael (Gast)]

Hallo,

mit "fboot /b9600 /c1 /pMain.hex /vMain.hex /iPeda" (irgendwo aus diesem 
Thread) hat das flashen funktioniert.
Merkwürdig ist allerdings, dass das Original-Hexfile, das mit dem 
Bootloader eingespielt wird, fast dreimal kleiner ist, als das, das im 
AtMega gespeichert wird.

Dateianhang (bei beiden habe ich den Bootloaderanteil zum besseren 
Vergleich heraus genommen):
- Originaldatei main.hex
- im AVR gespeicherte Datei: main_boot.hex

...trotzdem funktioniert das Programm wie gewohnt...

Gruß
Michael

[Michael (Gast)]

hier auch der "Anhang" ..sorry

[Michael (Gast)]

Kann es sein, dass es bei jedem Brennen über den Bootloader ein gewisser 
"Overhead" mitgebrannt wird?
Im Anhang habe ich den Teil herausgefiltert, der bei jedem Programm 
(verschiedene Applikationen) mit geflashed wird.
Was hat es damit auf sich?

[Malte _. (malte)]

> Merkwürdig ist allerdings, dass das Original-Hexfile, das mit dem
> Bootloader eingespielt wird, fast dreimal kleiner ist,
Das muss so sein. Was will der der AVR schließlich mit einer ASCII 
Repräsentation des Binärcodes?

[Peter D. (peda)]

Hast Du vielleicht vorher schon ein größeres File geflasht?
Der Bootloader löscht nur die benötigten Pages.

Was zeigt denn der Bootloader als Endadresse an?


Peter

[Michael (Gast)]

Hallo Peter,

der Bootloaders liegt zwischen 3E00 - 3FE9.
Bei 3FFE - 3FFF steht noch EA CF. (s. Anhang)

Der Overhead stört ja nicht weiter, solange man genügend Platz hat. Ich 
hatte mich bloß gewundert, wo plötzlich der zusätzliche Code herkommt 
und wodurch er produziert wird. Wird übrigens auch gebrannt, wenn der 
AVR  komplett gelöscht wurde (alles 'FF')

Mit der Angabe bis fboot /b19200..funktioniert der Loader hervorragend.
Danke nochmal für die Programmierung.
Gruß
Michael

[Axel R. (Gast)]

Robert Zimmermann schrieb:
> Danke, damit wäre ich jetzt kurz vor dem Ziel.
>
> Es funktioniert nun auch beim Attiny25. Leider aber nicht mit OneWire an
>
> PB5, dem nun deaktivierten RESET-Pin.

Hallo zusammen,
bin auch dabei, den Bootloader am deaktivierten RESET Pin eines Tiny 45 
auszutesten. Geht definitiv nicht. An allen anderen Pins ja.
Das sogar sehr gut -dankeschön-
Ich habe mal mein Oszi drangehalten. Die Messergebnisse betsätigen das. 
H-Pegel liegt bei ca 3Volt seitens Tiny45, was bei 4K7 Pullup (ca.1mA 
bei 5V)auch hinkommt. Also der PB5 scheint das nicht zu schaffen, 
zumindest bei mir nicht.
Auf Seite 190 im Datenblatt Abschn. 22.6 sieht man das im Diagramm auch 
sehr schön. Komisch ist nur, das im pdf, wo ich die Schaltung her habe,
http://www.mikrocontroller.net/attachment/preview/24979/page_snapshots/001.png
 der PB5 mit eben jenen 4K7 beschaltet ist. Der Widerstand zwischen PIN2 
und PIN3 der Sub-D Buchse ist denn dann wohl auch zu klein???

Es sind ja schon eininge Wochen ins Lang gegangen, seit dem Post von 
Robert. Kann jemand meine  Erfahrungen bestätigen?

Danke

viele Grüße Axelr.

[Robert Z. (robertz)]

Hallo Axelr.
Bootloader über ehemaligen RESET-Pin funktioniert bei mir mittlerweile 
am Tiny25, manchmal, aber noch nicht zuverlässig. Ein paar mal kann ich 
uploaden, dann geht gar nix mehr, auch das Programm im Controller 
scheint kaputt zu sein, oder der Controller selbst. Ich hab die anderen 
4 Pins mit einem l293d verbunden, an dem ein Schrittmotor hängt. Ich bin 
mir noch nicht ganz sicher, ob es daran liegen könnte, oder ob der 
Leiterbahnabstand zu gering ist, und sich durch mehrmaliges Flashen 
durch das Pulsieren am Bootloader Pin Ströme entladen, die die Schaltung 
zerstören. Entstehen dadurch vielleicht Kriechströme?
Aber "grundsätzlich" hat es mal funktioniert bzw. es funktioniert immer 
wieder, wenn ich einen neuen Controller einsetze.
Würde mich auch freuen, wenn jemand eine Idee hätte, wie man das etwas 
robuster gestalten könnte.

Grüße, robertz

[Axel R. (Gast)]

Im Sub D Stecker zwischen 2 und 3 (R2) habe ich jetzt 8K2 drinnen.
http://www.mikrocontroller.net/attachment/24979/bootloader.pdf

D2 kann mal testhalberweise weglassen. Den Tiny habe ich mit 5Volt 
betrieben. funktioniert nun zuverlässig. Ich empfehle, bei den 
Basteleien ein Oszilloskop zur Kontrolle am PB5 mit anzuschliessen. Dann 
sieht man gut, wie der 4K7 Pullup und der (jetzt)8K2 den Low Pegel etwas 
hochziehen und wie sich Änderungen von R2 auf den High Pegel auswirken.
Atmel sollte im Datenblatt sollte nochmals betonen, das es sich um 
tatsächlich einen "weak IO" handelt. Gut haben se ja gemacht :))

Peter: sehr gute Arbeit, vielen Dank einstweilen

viele Grüße auch an die anderen Löter

Axelr.

[Timo S. (kaffeetas)]

Hallo Robert,

wie führst du den Reset aus?
Wenn es nur per PowerON Reset geht hab ich Die Erfahrung gemacht dass es 
etwas zuverlässiger funktioniert wenn zuerst VCC und danach erst GND 
verbunden wird. Die Atmels versorgen sich sonst quasi parasitär aus dem 
Bootloader Pin (Beim ehemaligen Resetpin sollte das aber IMHO nicht so 
sein). Dadurch kann dem Bootloader beim Flashen der Saft abgedreht 
werden was dann zu irgenwas undefiniertem führt. Ich habe weiter oben 
eine Hex gepostet da sieht man schön, dass eine Page mitten im 
Bootloader gelöscht wurde.

Grüße
 Timo

[Robert Z. (robertz)]

Hallo Timo,
den Reset habe ich bisher durch 2 Varianten ausgelöst.
a) indem ich das Netzteil aus- und wieder einschalte, an dem sowohl die 
separate Bootloader Schaltung mit eigenem L7805 hängt, als auch die 
Platine Mit Tiny25, L293D und Schrittmotor

oder
b) indem ich zunächst ein Programm lade, das eine Software UART an PB5 
erzeugt und bei jedem durchlauf fragt, ob irgend ein Zeichen empfangen 
wurde. Falls dem so ist, wird der Watchdog gestartet und löst einen 
Reset aus.

Erst VCC und dann GND zu verbinden wäre in meinem Fall schon 
umständlich, da es fest verkabelt ist. Der Hinweis, dass es daran liegen 
könnte, ist aber schon mal ganz hilfreich. Danke.
Ich dachte jetzt erst, man könnte dem vielleicht mit einer Schutzdiode 
entgegnen. Aber der Strom muss ja schon durch den Reset-Pin in den 
Controller, damit das Flashen funktioniert.

Grüße, Robert

[Malte _. (malte)]

Nur mal nachgefragt,
am Ende des Flashens gib das PC Programm "CRC: o.k." aus. Wird dabei nur 
die Korrektheit der Datenübertragung geprüft, oder auch ob die Daten 
richtig im Flash gelandet sind (also noch mal ausgelesen, so dass 
Bitfehler erkannt werden würden)?

[Peter D. (peda)]

Malte __ schrieb:
> Nur mal nachgefragt,
> am Ende des Flashens gib das PC Programm "CRC: o.k." aus. Wird dabei nur
> die Korrektheit der Datenübertragung geprüft

Ja.

> oder auch ob die Daten
> richtig im Flash gelandet sind (also noch mal ausgelesen, so dass
> Bitfehler erkannt werden würden)?

Das kann man mit dem Verify machen.


Peter

[Florian (Gast)]

Hallo,
ich habe auch mal diesen Bootloader ausprobiert. Leider scheint dadurch 
mein Programm beeinflusst, sodass es nicht mehr funktioniert. Mein 
Programm nimmt einfach Zeichen von UART entgegen und schreibt sie dann 
auf ein LCD. Da ich den Bootloader gut finde, wollte ich wissen warum 
mein Programm beeinflusst wird. Meiner Meinung nach scheint es, dass der 
Controller sich immer resettet, habe auch schon den WDT deaktiviert aber 
keine Besserung. Ich hinterlege mal mein Programm hier, damit ihr 
vielleicht schauen könnt.

Danke im Voraus!

[Uli (Gast)]

Hallo zusammen,

ich hätte eine kurze Frage:
Mit welchem Tool (Woher? Link?) kann man das FBOOT von Alfred N. für Win 
XP Konsole kompilieren? :)

Ich würde das ganze ein wenig erweitern wollen.. ;-)

Danke & Schöne Grüße,
Uli

[Alfred N. (alfred-n)]

Hallo,

@Uli

> Mit welchem Tool (Woher? Link?) kann man das FBOOT von Alfred N. für Win
> XP Konsole kompilieren? :)

Mit dem C++Builder 2007 Kommando-Zeile (sollte aber auch mit DevCpp 
laufen).

>Ich würde das ganze ein wenig erweitern wollen.. ;-)

Der geänderte Code sollte aber wieder hier eingestellt werden.

Gruß Alfred

[Uli (Gast)]

Hi,

gibt es das irgendwo frei zum Downloaden?
Oder muß man das kaufen?

Gruß,
Uli

[Uli (Gast)]

Hat sich erledigt: Nutze DevCpp :)

[Robert Z. (robertz)]

Hallo.
Kann es sein, dass der Bootloader nicht oder nicht zuverlässig 
funktioniert, wenn man das Fusebit bei EESAVE setzt, also EESAVE 
aktivert?
Schreibt sich der Bootloader in den EEPROM und hat so Probleme mit 
meiner Einstellung?
Ich wollte den EEPROM nur sichern, um dort später Werte ablegen zu 
können, die nicht jedes mal überschrieben werde, wenn ich über den 
Bootloader ein neues Programm aufspiele.

Ich nutze einen Tiny25, OneWire an deaktivertem RESET-Pin.

Teilweise kann ich den Controller mit dem Bootloader ein paar mal 
flashen, bei einem ging es überhaupt nicht. Teilweise scheint das 
Programm auch zerstört zu sein. Der angeschlossene Schrittmotor macht 
willkürliche Bewegungen.

Bei einem Controller kommt auch die Meldung

COM 1 at 9600 Baud: Connected
Bootloader VFFFFFFFF.FF
Error, wrong device informations

Da geht gar nichts mehr.

Liege ich mit meiner Vermutung richtig, oder ist das abwegig?


Grüße, Robert

[Willi (Gast)]

Ich nutze FBoot für einen Mega8 mit 1-Wire.
Das Ganze hat einige Zeit tadellos funktioniert. Seit kurzem kann ich 
aber den Bootloader nur 1x benutzen, danach startet er nicht mehr.

Da mein Program etwas angewachsen ist, vermute ich es liegt an der 
Grösse.
- Wenn ich das Projekt (ohne Bootloader) lade, ist der Speicher bis 
x1B87 gefüllt.
-Lade ich erst ausschliesslich den Bootloader, kann ich 1x mein Programm 
nachladen. Das Programm funktioniert dann auch aber der Bootloader 
reagiert dann nie wieder.
- Wenn ich jetzt mit Ponyprog auslese, ist der gesamte(!) Speicher 
gefüllt.

Wie gesagt, ohne Fboot ist alles io und auch nach Programmstart bleibt 
der Speicher nur bis x1B87 gefüllt. Mein Programm schreibt den Speicher 
also nicht voll (schreibt garnicht ins FRAM)

Habt ihr irgendwelche Tipps - ich bin mit meinem Latain am Ende :(
Das Programm ist mit AVR_GCC compiliert.

[Peter D. (peda)]

Vermutllich die Bootfuses falsch gesetzt. Sie müssen auf 512 Byte 
stehen.


Peter

[Willi (Gast)]

Fuses sollten passen, wenn ich nix übersehen habe (0x0E00) - siehe Bild 
von PonyP.

Wenn nicht, könnte das zwar erklähren, warum der Loader ab dem zweiten 
Versuch nicht mehr startet nur warum schreibt FBoot den Speicher 
komplett voll ?

[Willi (Gast)]

Gelöst:

Fusebits waren falsch BOOTZ0 und BOOTZ1 anderherum programmiert.

Im Datenblatt auf Seite 217 steht bei dieser Einstellung
"Bootsize 256 WORDS"

Gleichzeitig steht für diese Einstellung aber auch
"Start Bootloader Section 0xF00"

Das wären nur 256 Byte !!
Deshalb hatte ich die falschen Bits gesetzt.
-> Fehler im Datenblatt oder falsches Verständnis ?

Das der Speicher von FBoot vollgeschrieben wird, liegt vermutlich daran, 
dass Seitenweise geschrieben wird und die Seite im RAM vor dem erneuten 
Laden nicht gelöscht wird. Es stehen also noch die restlichen Werte der 
vorherigen Seite drin - richtig Peter?

btw: Vielen Dank für das Programm !


PS: kann man das Bild in meinem letzten Beitrag löschen, es würde 
vermutlich Verwirren, wenn jemand anderes nach den Fuseeinstellungen 
sucht ?

[F. S. (franke)]

Peter Dannegger schrieb:
> Malte __ wrote:
>> Hallo Peter,
>> bei mir funktioniert der Bootloader mit einem ATmega128 einwandfrei
>> (Version 2.1). Aber stimmt die Information noch, dass das Schreiben
>> oberhalb von 64KB bis auf weiteres nicht funktioniert?
>
> Nein, die Version 2.1. kann das.
> Ich hab ihn bis zum ATmega2561 erweitert und getestet (256kB).
>
> Peter

Hallo zusammen,

ich habe das Problem, dass Applications >64k auf einem ATmega2561 nicht 
programmiert werden können (<64k ohne Probleme). Ich verwende momentan 
den Bootloader v2.1 aufm AVR - programmiert wird von einem externen 
Master gem. Protokoll - d.h. es wird nicht ein PC-Prog zum programmieren 
verwendet.
Die Programmierung >64k mit ISP und avrdude oder AVR Studio ist ohne 
Probleme möglich.

@Peter. Du schreibst oben, dass du in v2.1 Anpassungen vorgenommen hast. 
Kannst du mir vieleicht einen Tip geben wo und wie im Bootloader diese 
Problematik gehandelt wird?

Vielen Dank schon mal im Voraus.

mit Bootloader programmiert:

:10FFE0009F4F2817390739F481E08093AA084957B1
:10FFF0004093E110089550913310952F52FF0BC09C
:020000021000EC
:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0

mit AVR Studio programmiert:

:10FFE0009F4F2817390739F481E08093AA084957B1
:10FFF0004093E110089550913310952F52FF0BC09C
:020000021000EC
:100000008091E50F873639F481E08093AA0887E470
:100010008093E210089593FF0BC08091E60F873222

[Alex (Gast)]

Hallo Peter,
versuche gerade deinen Bootloader für einen ATmega1284P zu compilieren 
und bekomme dabei folgende Fehlermeldung:

FATAL ERROR: Too deeply nested macro calls(16)

Hab weiter oben gesehen das dieses Problem schon einer hatte, mit einer 
damals anderer Version von dir war es behoben.
Was mache ich falsch ?

[Nicolas (Gast)]

Hallo Peter,

habe auch gerade Deinen Bootloader für einen Mega88 benutzt (im 
OneWire-Modus) - super klasse, vielen Dank!

Gruß

Nicolas

[Aik Brands (Gast)]

Hast du bedacht das das evtl ein endian problem sein könnte
willst du es auf einer sun linux kiste machen oder einene x86 oder IA64

[Bernd O. (bitshifter)]

Hallo zusammen,

ich verwende den Bootloader mit Erfolg auf ATtiny[248]5 und ATmega32 
sowohl als One-Wire über den "freigefusten" Reset-Pin als auch über 
normale UART-Kommunikation. Wirklich ein genialer Bootloader! Vielen 
Dank Peter!

Hier noch ein Tip zur Komfortsteigerung:

Wenn der Rx-Pin entweder nicht benötigt wird bzw. wenn sichergestellt 
ist, dass während des normalen Programmablaufs nicht das "Passwort" 
(Default: Peda) empfangen wird, dann kann man den Komfort beim 
Entwickeln steigern, indem man im Empfangs-Interrupt des UARTS den 
Empfang des Passworts überprüft und danach einen Reset auslöst. Man kann 
so ohne dass man am Bootloader oder am PC-"Downloader" etwas ändern 
müsste jederzeit eine neue Version einspielen ohne erst die 
Spannungsversorgung des Targets zu unterbrechen oder einen manuellen 
Reset auszulösen.
Das PC-Tool sendet das Passwort ohnehin bis es "schwarz" wird - da stört 
es nicht, wenn man eines der vielen gesendeten Passwörter zum Reset 
nutzt.

Hier mal mein Code:

/* UART receiver interrupt */
ISR(USART_RXC_vect)
{
    static uint8_t numCharReceived = 0;
    uint8_t Resetpassword[] = "Peda";

    /* Check if passord is being sent */
    if (UDR == Resetpassword[numCharReceived]) {
        numCharReceived++;
    } else {
        numCharReceived = 0;
    }
    /* Password completely received? */
    if (Resetpassword[numCharReceived] == '\0') {
        numCharReceived = 0; /* avoid reading outside buffer in case reset isn't executed */

#       if NONPRODUCTIVE
            /* Start WDT with shortest timtout to trigger a reset */
            WDTCR = ((0<<WDTOE) | (1<<WDE)| (0<<WDP2) | (0<<WDP1) | (0<<WDP0));
            cli(); /* disable interrupts */
#       endif
    }
}

Noch ein Hinweis:
Bitte absolut sicherstellen, dass das Passwort niemals im "normalen" 
Betrieb (== Nicht-Bootloader-Betrieb) empfangen wird, da das Target 
sonst stur einen Reset auslöst - ob das Passwort vom PC-Tool des 
Bootloaders oder einem Terminal kam spielt keine Rolle. Man sucht ggf. 
sehr lange, bis man den Grund für den Reset gefunden hat weil 
beispielsweise der Meßwert binär dem Passwort entspricht. Wenn der 
Bootloader erst mal läuft, denkt man meist nicht mehr daran...

Man kann die Sicherheit gegen unerwünschte Resets (etwas) steigern, 
indem man den mehrmaligen Empfang des Passworts überprüft, also 
"PedaPedaPeda" - aber absolut sicher ist das nicht...

Für Produktivbetrieb "NONPRODUCTIVE" in jedem Fall abschalten, dann hat 
man für die Serie mit Sicherheit keine Resetprobleme (zumindest nicht 
wegen des Bootloaders ;-)

Vielen Dank nochmals an Peter Dannegger für den tollen Bootloader und an 
Bernhard Michler und Andreas Butti für das Linux-Tool!

Gruß,
Bernd

[Uhu U. (uhu)]

Wie wäre es denn, wenn der Code mal hier in subversion eingescheckt 
würde?

[Michael M. (Gast)]

dass es einen artikel mit link zum download gibt, weißt du?

[Uhu U. (uhu)]

Ja, aber ein Subversion-Repository ist doch viel handlicher. Vor allem 
kann man sehr schnell sehen, wodurch sich die einzelnen Versionen 
unterscheiden.

[Dieter R. (drei)]

Ich würde mich gerne auch mal mit der Sache beschäftigen und ein paar 
Änderungen/Ergänzungen vornehmen.

Gibt es vom aktuellen AVRFLASH21.EXE die Sources, oder muss ich jetzt 
das Rad von Neuem erfinden?

Oder hat jemand anders ein vernünftiges kleines Loader-Tool mit GUI? 
(Für Windows).

Karsten Donat hat in seinem Beitrag ja noch eine ganze Reihe von 
Ergänzungen angekündigt, Fertigstellung im September. Weiß jemand, ob 
was daraus wurde, vielleicht an anderer Stelle? Ich habe jetzt SEHR 
ausführlich gesucht, aber nichts gefunden.

[Vlad T. (vlad_tepesch)]

Hi,
Ich hab das File runtergeladen, das im Artikel verlinkt ist 
Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain"  (Artikel sagt 
Version 1.21, Dateiname sagt 1.26), die Isntruktionen in der README 
befolgt:

- m168def.inc kopiert
- make-file angepasst (MCU = atmega168, ATMEL_INC = m168def.inc,
F_CPU = 16000000)
- bootload.asm angepasst (.include "m168def.inc")
- leeres winavr-Project angelegt mit external Makefile

beim Versuch eines Builds kommen folgende Fehlermeldungen:

Build started 8.7.2010 at 21:28:26
avr-gcc -c -Wa,-adhlns=bootload.lst -mmcu=atmega168 -DF_CPU=16000000  -I . -I ./added -I ./converted -I/usr/local/avr/include  -ffreestanding -gstabs+ -L,-gstabs+ -DRAM_START=0x0100 -DSRAM_SIZE=1024 -DSTX_PORT=PORTD -DSTX=PD1 -DSRX_PORT=PORTD -DSRX=PD0 add
ed/bootload.S -o bootload.o

m168def.inc: Assembler messages:
m168def.inc:47: Error: unknown pseudo-op: `.device'
m168def.inc:49: Error: expected comma after "SIGNATURE_000"
m168def.inc:50: Error: expected comma after "SIGNATURE_001"
m168def.inc:51: Error: expected comma after "SIGNATURE_002"
[...]

hundert weitere - eine für jedes .equ ...  in inc-file

Im Anhang mal das Projekt-verzeichnis

danke im voraus,
Vlad

[Vlad T. (vlad_tepesch)]

ah, ich habs - hätte die bootload.asm wohl doch nicht anpassen dürfen.

jetzt scheints zu gehen.
das delphi-Upload-Tool redet zumindest mit dem bootloader, leider kennt 
er die Version nicht.

[Vlad T. (vlad_tepesch)]

seh ich das richtig, das der bootloader kein EEPROM schreiben kann?

[Bernhard M. (boregard)]

Vlad Tepesch schrieb:
> seh ich das richtig, das der bootloader kein EEPROM schreiben kann?

Mal den thread durchlesen:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

-> nein, geht nicht.

[Vlad T. (vlad_tepesch)]

Bernhard M. schrieb:
> Mal den thread durchlesen:

naja, der ist recht groß und der Artikel passt nicht zur Software, warum 
sollte man dann annehmen, dass der alte Beitrag noch zutrifft?

[Michael H. (michael_h45)]

Vlad Tepesch schrieb:
> naja, der ist recht groß und der Artikel passt nicht zur Software, warum
> sollte man dann annehmen, dass der alte Beitrag noch zutrifft?
Du weißt aber schon, dass du nicht Peters Bootloader, sondern eine
Weiterentwicklung verwendest?
Du hast auch in deinem ersten Post hier auf einen ganz anderen Thread
verlinkt.

[Vlad T. (vlad_tepesch)]

Michael H. schrieb:
> Vlad Tepesch schrieb:
>> naja, der ist recht groß und der Artikel passt nicht zur Software, warum
>> sollte man dann annehmen, dass der alte Beitrag noch zutrifft?
> Du weißt aber schon, dass du nicht Peters Bootloader, sondern eine
> Weiterentwicklung verwendest?
> Du hast auch in deinem ersten Post hier auf einen ganz anderen Thread
> verlinkt.

uff, das ist mir in der Tat nicht aufgefallen.
Ich bin stillschweigend davon ausgegangen, dass die Links zu den 
Downloads in den richtigen Thread zeigen.

Ich hab mich immer nur über die Links in den Artikeln durchgehangelt.
Das erklärt zumindest die Diskrepanz zw. Artikel und README

Eine Frage hätte ich noch:
wird denn der Watchdog am systemstart deactiviert?

sprich kann ich per Application den Watchdog starten um ein Reset 
auszulösen und den bootloader zu starten?
Dieser müsste dann natürlich den WDT disablen

[Michael H. (michael_h45)]

Vlad Tepesch schrieb:
> Eine Frage hätte ich noch:
> wird denn der Watchdog am systemstart deactiviert?
Peters Version bietet ein Flag dazu an:

aus bootload.asm:
;remove comment sign to exclude Watchdog trigger:
;.equ   WDTRIGGER       = 0

[Paul P. (dorpreuss)]

Hallo,

ich habe diesen tollen Bootloader schon mehrmals problemlos 
verwendet(m8, m88, m644), aber diesmal habe ich Probleme damit. Ich habe 
den Bootloader heute für m1281 erstellt, geflasht und getestet. Hat beim 
ersten mal funktioniert. Plötzlich ging er nicht mehr, dann ging er 
wieder usw. Ich benutze fboot21 (ist das die aktuelle Version?) für die 
Kommunikation mit dem PC und es kommt folgender Fehler:

COM1 at 38400 Baud: Connected <One Wire>
Bootloader VFFFFFFFF.FF
Error, wrong device informations

Das komische ist nur, dass ich den Prozessor gar nicht one wire 
angeschlossen habe.
Mit niedrigeren Baudraten habe ich schon experimentiert - nützt nichts.

Dann habe ich festgestellt, dass ich das .def file vergessen hatte, 
welches im gleichen Verzeichnis wie die fboot.exe liegen muss und meinte 
den Fehler damit behoben zu haben. Leider hat das nichts genützt. In dem 
File steht der Atmega 1281 aber nicht drin.
Die Fuses habe ich mit AVR-Studio über STK500 eingestellt. Ich habe 
Bootreset und Boot Flash Size 512 words - 0xFE00 eingestellt. Der 
Prozessor ist auf einem Adapter von Paktek montiert. Als Pegelwandler 
habe ich ein RS232-TTL-Wandler von Pollin (Kabel ist kurz ~10cm).

Ich würde mich sehr über eine Idee von euch freuen!

MfG

Paul

[Michael H. (michael_h45)]

Klingt nach einem Übertragungsproblem.
Klappt denn die UART mit den gleichen Parametern wie beim Bootloaden 
problemlos im normalen Betrieb?

[Paul P. (dorpreuss)]

Hallo,

ja, der Code den ich gerade für den Mega1281 schreibe ist für die USART 
und der funktioniert tadellos. (wenn der  Code einmal im Controller ist)

[Paul P. (dorpreuss)]

Hallo nochmal,

ich habe eben noch ein wenig herumprobiert. Wenn ich den Bootloader neu 
flashe, geht er danach genau ein mal. Sehr selten auch mehrmals, aber 
ein mal geht er immer.

[Michael H. (michael_h45)]

Fuses richtig gesetzt?
Wie resettest du den Atmega? Vielleicht läuft dein Atmel nicht sauber 
an.

[Paul P. (dorpreuss)]

Hier ein Bild der Fuses die gesetzt sind. Den Reset löse ich über einen 
Taster aus.

[Paul P. (dorpreuss)]

Hallo,

ich habe immer noch das Problem mit der Fehlerhaften Erkennung des 
Onewire.
Den Bootloader auf GCC Toolchain habe ich auch schon probiert. Gestern 
habe ich mehrmals ohne Probleme mit dem Bootloader programmiert, heute 
geht es nicht mehr. Ich habe Version 1.7 und 2.1 getestet. Ohne Erfolg. 
Wie gesagt, nach dem Flashen des Bootloaders geht es immer.

Ich glaube nicht, dass es an der Verbindung liegt, denn wenn das 
Programm einmal im Controller ist, funktioniert die Schnittstelle 
tadellos.

Hat jemand eine Idee woran das liegen könnte?

Gruß Paul

[MartinS (Gast)]

Abend!

Erstmal Danke für diesen tollen Bootloader! Hab ihn schon eine Weile im 
2-wire Betrieb, jetzt wollte ich für eine andere Schaltung (RC-BLC 
Regler) den 1-wire Modus nutzen, so kann über den normalen BEC/PPM 
Anschluß eine neue Firmware geflashed werden.

Nur leider klappt das mit One-Wire nicht.

2-Wire funktioniert in der Schaltung (mega8, externer 16mhz quarz) mit 
der Version 2.1. Verbindung über ein FTDI Breakout - also 5V TTL Pegel 
vom PC.

1-Wire funktioniert nicht, dazu hab ich mittlerweile ein paar Dinge 
einzeln und in jeglicher Kombination probiert:
- kein Pullup (d.h. TTL-RX, TTL-TX und Bootloader-Pin direkt verbunden)
- Pullup auf 5V am Bootloader-Bin mit 4k7
- komplette Schaltung wie in diesem Thread (2x dioden, 2x 4k7)
- Änderung im Code (TX/RX Pegel in den Macros TXD_0, TXD_1, SKIP_RXD_0, 
SKIP_RXD_1) genau invertiert.

Und jetzt bin ich am Ende meiner Ideen.

2-wire ist leider keine Option, das geht zum testen solange der Regler 
offen ist.

Am PC verwende ich bisher immer die bootloader_CSharp_adv_v4.zip, kann 
die eventuell kein OneWire...?
Mit der Fboot.exe hab ich auf meinen PCs probleme mit COM-Ports, kann ja 
"nur" com1-4, aber da bekomme ich mit den ftdi breakouts generell keine 
kommunikation hin - alle com-ports sind belegt, win7 sagt mir nicht mit 
was (hab nur 1x com fix eingebaut, kein bluetooth), und so läufts leider 
nicht mit der fboot.exe.

Daher im wesentlichen 2 Fragen:
- Com23, Win7 -> mit welchem Programm sollte hier onewire funktionieren?
- TTL Pegel & OneWire - welche Beschaltung habt ihr im diesem Fall?

Danke für die Infos & lG, Martin.

[Peter D. (peda)]

MartinS schrieb:
> - kein Pullup (d.h. TTL-RX, TTL-TX und Bootloader-Pin direkt verbunden)

kann nicht gehen.

> - Pullup auf 5V am Bootloader-Bin mit 4k7

?

> - komplette Schaltung wie in diesem Thread (2x dioden, 2x 4k7)

Diese hier?
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

> - Änderung im Code (TX/RX Pegel in den Macros TXD_0, TXD_1, SKIP_RXD_0,
> SKIP_RXD_1) genau invertiert.

reicht nicht.
Der Sender muß beim 0-Bit nicht nach VCC, sondern auf GND ziehen.


Peter

[Peter D. (peda)]

Paul P. schrieb:
> Wie gesagt, nach dem Flashen des Bootloaders geht es immer.

Kann eigentlich nur sein, daß der Bootreset nicht der Adresse des 
Bootloaders entspricht.
Schau mal ins Listing, ob der Code wirklich bei 0xFE00 anfängt, d.h. daß 
Du das richtige Include eingebunden hast.


Peter

[Paul P. (dorpreuss)]

Hallo,

ich habe nur m1281def.inc inkludiert. Das kommt beim Assemblieren raus.

ATmega1281 memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x01fc00 0x020000    504     20    524  131072   0.4%
[.dseg] 0x000200 0x000600      0   1024   1024    8192  12.5%
[.eseg] 0x000000 0x000000      0      0      0    4096   0.0%

Die Adresse 0x01fc00 ist doch eine Byteadresse und 0xfe00 eine 
Wortadresse oder? Dann müsste das doch stimmen.

Ich habe in meinem PC jetzt eine zweite serielle Schnittstelle 
eingebaut, weil der Bootloader nicht funktioniert. So kann ich ohne 
Umstöpseln per ISP programmieren, aber mit Bootloader würde es mir schon 
besser gefallen.

Ich habe den Bootloader auch schon oft benutzt und hatte nie Probleme 
damit. Nur einmal bei einem Mega8515 konnte ich nur mit sehr niedriger 
Baudrate übertragen, was ich aber nicht schlimm fand.

Dennoch vielen Dank an Dich das du ihn zur Verfügung gestellt hast.

MfG Paul

[MartinS (Gast)]

>> - Pullup auf 5V am Bootloader-Bin mit 4k7
>?
Bin sollte Pin lauten... und von dort einen 4k7 Pullup auf die +5V vom 
AVR.

>> - komplette Schaltung wie in diesem Thread (2x dioden, 2x 4k7)
>Diese hier?
>Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"
Ja - sollte das mit der klappen?

>> - Änderung im Code (TX/RX Pegel in den Macros TXD_0, TXD_1, SKIP_RXD_0,
>> SKIP_RXD_1) genau invertiert.
>reicht nicht.
>Der Sender muß beim 0-Bit nicht nach VCC, sondern auf GND ziehen.
ok, dann schau ich mir das morgen an - wenn den die Schaltung oben die 
richtige ist...?

Danke für die Tipps!

[Stefan G. (sgm)]

Da ich seit kurzem sehr erfolgreich den Bootloader einsetze, hatte ich 
den Bedarf nach einer platformübergreifenden, universellen Lösung das 
Programm zu laden. Ich dachte mir daher es wäre gut, wenn man avrdude 
entsprechend erweitern würde.

Ich habe das mal gemacht und den Patch gegenüber der Version 5.10 
angehängt. Er funktioniert bei mir sowohl unter Windows als auch Linux 
bis jetzt sehr gut. Momentan fehlt mir noch die One-Wire Betriebsart, da 
ich gerade keine Hardware zu Hand habe. Die Idee ist, den Patch dann an 
den avrdude Maintainer zu senden, so dass er hoffentlich standardmässig 
integriert wird.

Nach dem Patchen und dem Kompilieren ist der Aufruf dann wie folgt:

avrdude -c pedabl -p m8 -P /dev/ttyUSB0 -b 57600 -U flash:w:main.hex -x "reset_cmd=\nR\n" -x "reset_baud=9600"

Wobei die beiden erweiterten Kommandos optional sind. Wenn nicht 
angegeben, muss ein manueller Reset ausgelöst werden. Wenn reset_cmd 
gesetzt ist, wird entweder mit der Programmierbaudrate oder mit der 
Baudrate von reset_baud der angegebene String gesendet, der den 
Controller zurücksetzen soll.

Mit

-U flash:v:main.hex

 kann auch ein Verify durchgeführt werden.

[Bernhard M. (boregard)]

Hi Stefan,

ist Dein diff wirklich nur ein diff bezüglich der Änderungen die Du für 
den Bootloader eingebaut hast?
Es sieht mir so aus, als wäre das ein diff einer avrdude 2.10 mit Deinen 
Änderungen gegen eine älter avrdude Version...

Gruß,
Bernhard

[Stefan G. (Gast)]

Bernhard M. schrieb:
> ist Dein diff wirklich nur ein diff bezüglich der Änderungen die Du für
> den Bootloader eingebaut hast?
> Es sieht mir so aus, als wäre das ein diff einer avrdude 2.10 mit Deinen
> Änderungen gegen eine älter avrdude Version...

Eigentlich bin ich relativ sicher, da ich den Patch auch nochmal selbst 
bei einem frischen 5.10-Code ausprobiert habe. Auch im Patch selbst 
stimmt der Pfad... Es sind allerdings einige Dateien mit im Patch die 
von autoconf/automake generiert worden sind.

Wie kommst du eigentlich darauf?

Stefan

[Wichtel (Gast)]

Stefan G. schrieb:
> Wie kommst du eigentlich darauf?

Hallo Stefan, ich bin zwar nicht Bernhard aber kam auch schon so ein 
Verdacht:

Beim Lesen des udiff-Files per Editor sind viele Zeilen zu entdecken in 
denen z.B. die Copyright-Informationen aktualisiert werden. Insgesamt 
ist es auch auffällig viel an gepatchtem Code.

Schau doch einfach mal rein, würde mich halt wundern wenn du das alles 
geändert hast "nur" wegen der Anpassung an den Bootloader.

Find ich übrigens eine super Initiative den Bootloader auf diese Weise 
um einiges universeller zu machen! Danke dir dafür, und natürlich Peter 
selbst auch für seine Grundlage!

[Stefan G. (Gast)]

Wichtel schrieb:
> Beim Lesen des udiff-Files per Editor sind viele Zeilen zu entdecken in
> denen z.B. die Copyright-Informationen aktualisiert werden. Insgesamt
> ist es auch auffällig viel an gepatchtem Code.
>
> Schau doch einfach mal rein, würde mich halt wundern wenn du das alles
> geändert hast "nur" wegen der Anpassung an den Bootloader.

Um einen neuen Programmer hinzufügen müssen natürlich die Makefiles, 
Configuration und der Lexer angepasst werden. Das bedingt dass man 
autoconf/automake neu ausführen muss, das wieder die von dir erwähnten 
Dateien erzeugt (und sei es nur der Copyright, weil es eine neue 
autoconf/automake Version ist). Ich dachte so wäre der Patch leichter 
anzuwenden, da sonst nocht autoconf/automake ausgeführt werden müsste 
und natürlich auch noch vorhanden sein muss.

Ich habe ändern müssen:

 * avr.c/avr.h
 * avrdude.conf
 * config_gram.y
 * main.c
 * Makefile.am
 * pedabl.c/pedabl.h
 * pgm.h
 * serial.h/ser_posix.c/ser_win32.c
 * update.c

Das sind dann doch ziemlich viel. Ich musste aber das Verfiy etwas 
anpassen damit der Verfiy auf dem Programmer und nicht im avrdude 
stattfindet. Ausserdem war es notwendig noch die serielle Abstraktion zu 
erweitern.

[Wichtel (Gast)]

Stefan G. schrieb:
> Das bedingt dass man
> autoconf/automake neu ausführen muss, das wieder die von dir erwähnten
> Dateien erzeugt (und sei es nur der Copyright, weil es eine neue
> autoconf/automake Version ist).

Danke, das leuchtet ein. Soweit hatte ich nicht gedacht dass die 
Automake-Version über die Jahresangaben der Copyright-Infos entscheidet.

[Steffen N. (bummibaer)]

Hallo,

ich versuche fboot21 für den ATMEGA128RFA1 zu übersetzen.
Ich habe :
 FASTCALL.H ersetzt ( wegen nested includes)
 .include "m128RFA1def.inc" eihschl. File

Zuerst bekam ich :
fastload.h(170): error: .macro: Redefinition of 'xlpm'
Habe das XLMP Macro auskommentiert.

Jetzt bekomme ich folgendes Log:

 AVRASM: AVR macro assembler 2.1.42 (build 1796 Sep 15 2009 10:48:36)
Copyright (C) 1995-2009 ATMEL Corporation

BOOTLOAD.ASM(38): Including file 'm128RFA1def.inc'
BOOTLOAD.ASM(64): Including file 'fastload.inc'
fastload.inc(8): Including file 'fastload.h'
fastload.h(2): Including file 'compat.h'
fastload.h(3): Including file 'protocol.h'
fastload.inc(23): Including file 'watchdog.inc'
fastload.inc(32): Including file 'abaud.inc'
fastload.inc(33): Including file 'password.inc'
fastload.inc(45): Including file 'command.inc'
command.inc(68): Including file 'message.inc'
command.inc(71): Including file 'verify.inc'
command.inc(75): Including file 'progmega.inc'
fastload.inc(46): Including file 'uart.inc'
fastload.inc(58): error: Illegal use of undefined or forward referenced symbol 'APICALL' in conditional
BOOTLOAD.ASM(64): info: 'fastload.inc' included from here

Assembly failed, 1 errors, 0 warnings

Wie ist die korrekte Syntax mit den Defines?

Vielen Dank,

Steffen

[Namen (Gast)]

Steffen Netz schrieb:
> Ich habe :
>  FASTCALL.H ersetzt ( wegen nested includes)
>  .include "m128RFA1def.inc" eihschl. File
Nested includes?
Warum funktioniert es dann bei alles andren so problemlos?

> Habe das XLMP Macro auskommentiert.
Noch ein schlauer schritt...

Du wunderst dich also, dann deine API nicht gecallt werden kann und hast 
FASTCALL rausgenommen. Woran mag es nur liegen, woran nur...

[Steffen N. (bummibaer)]

Namen schrieb:
> Steffen Netz schrieb:
>> Ich habe :
>>  FASTCALL.H ersetzt ( wegen nested includes)
>>  .include "m128RFA1def.inc" eihschl. File
> Nested includes?
> Warum funktioniert es dann bei alles andren so problemlos?
>
Weiss ich nicht, deshalb frage ich ja.
Sorry, FASTCALL soll natürlich FASTLOAD heissen.
Forumpost von Ludger + Antwort darauf.

Mit Original-FASTLOAD.H:

BOOTLOAD.ASM(38): Including file 'm128RFA1def.inc'
BOOTLOAD.ASM(64): Including file 'fastload.inc'
fastload.inc(8): Including file 'fastload.h'
fastload.h(2): Including file 'compat.h'
fastload.h(3): Including file 'protocol.h'
FATAL ERROR: Too deeply nested macro calls(16)

>> Habe das XLMP Macro auskommentiert.
> Noch ein schlauer schritt...
Danke für die Blumen. Was macht man denn dann?

> Du wunderst dich also, dann deine API nicht gecallt werden kann und hast
> FASTCALL rausgenommen. Woran mag es nur liegen, woran nur...
He? In BOOTLOAD.ASM steht:

;      remove comment sign to exclude API-Call:
;      only on ATmega >= 8kB supported
;.equ  APICALL    = 0

APICALL wird also garnicht definiert. Deshalb(?) wirft der Assembler
einen Error.

Danke für die schnelle Antwort, bitte aber noch um Ideen.


Steffen

[Michael H. (michael_h45)]

Versuch doch mal Folgendes: AVR-Studio oder IDE deines Vertrauens 
öffnen, BOOTLOAD.ASM öffnen, m168def.inc auskommentieren, m128def.inc 
einkommentieren, XTAL und BootDelay in FASTLOAD.H anpassen und 
compilieren lassen.
Grad probiert, klappt problemlos.

[Steffen N. (bummibaer)]

So,

die FASTLOAD.H fuer Ludger ist offensichtlich zu alt.
Jetzt versuche ich es mit der aktuellen, bekomme hier aber die nested
includes:

  ;----------------------------  max possible buffer size -----------------
  .set  BufferSize  = SRAM_SIZE / 2 - PAGESIZE
  .macro testpage
    .if    BootStart % BufferSize
      .set  BufferSize = BufferSize - PAGESIZE
      .if  BootStart % BufferSize
        .set    BufferSize = BufferSize - PAGESIZE
        testpage
      .endif
    .endif
  .endmacro
  testpage  ; calculate Buffersize to fit into BootStart

testpage ruft sich recursiv auf.

Der ATmega128RFA1 hat 16384 Bytes SRAM(!), und damit gibt es statt 5 
Rekursionen derer 28.

Lt Datenblatt ist die BufferSize einfach
.equ PAGESIZEB=PAGESIZE*2 ;PAGESIZEB is page in BYTES, not words
Kann man das so machen.
Mit einem C-File kommen in beiden Fällen 512 raus. Ist das richtig?

Gruß,

Steffen

[Daniel Held (Gast)]

Hallo,

In meiner Anwendung müsste ich ATMega168 über RS485 updaten können. 
Jetzt meine Frage, ist es möglich in den Bootloader noch ein PIN 
"TXD_enable" mit einzubauen? Dies wird bei RS485 Transceivern verwendet 
um die Senderichtung freizugebem. Ich hab leider von Assembler keine 
Ahnung, würde aber testen.

Danke schonmal
Daniel

[Tobias S. (tryan)]

Hallo,

ich würde gerne den Bootloader von Peter Dannegger verwenden.
Ich bin nach der Anleitung gegangen.

Leider tritt beim Assemblieren des Bootloaders folgender Fehler auf:

D:\Bootloader>avrasm2 -fi bootload.asm
AVRASM: AVR macro assembler 2.1.42 (build 1796 Sep 15 2009 10:48:36)
Copyright (C) 1995-2009 ATMEL Corporation

bootload.asm(32): Including file 'C:\Program Files\Atmel\AVR 
Tools\AvrAssembler2
\Appnotes\m64def.inc'
bootload.asm(61): Including file 'fastload.inc'
fastload.inc(22): Including file 'fastload.h'
fastload.h(15): Including file 'compat.h'
fastload.h(16): Including file 'protocol.h'
fastload.h(154): error: Invalid directive: '.section'
fastload.inc(22): info: 'fastload.h' included from here
bootload.asm(61): info: 'fastload.inc' included from here

Assembly failed, 1 errors, 0 warnings

Leider ergab die Suche nach dem Fehler weder hier im Forum noch bei 
google eine lösung.

Vielleicht hat jemand von euch einen Tipp für mich.

Vielen Dank Tobias

[Michael H. (michael_h45)]

Verwendest du denn auch Peters Bootloader und nicht irgendeine 
"Weiterentwicklung"?
In der FASTLOAD.H, die ich aus der aktuellen Version 2.1 hab, taucht 
kein .section auf...

[Tobias S. (tryan)]

Hallo, danke für die Antwort.

Ich verwende Version 2.1 des Bootloaders für AVR-GCC-Toolchain.

Die Version die man hier:
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger
downloaden kann.

Viele Grüße Tobias

[Michael H. (michael_h45)]

Dann verwendest du eine alte Version und schreibst im falschen Thread =)
Aktuell ist 2.8, der Thread mit Download ist hier zu finden: 
Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain"

[Tobias S. (tryan)]

Oh...Danke für die Info. Ich werde es mal mit der neuen Version Testen.

Danke

Tobias

[Basti (Gast)]

Hallo,

wollte nur bescheid geben...

hab den Bootloader jetzt auf einem Atmega48 getestet... geht super...

Danke dafür!

[Stephan W. (stephanw)]

Paul P. schrieb:
> Hallo,
>
> ich habe diesen tollen Bootloader schon mehrmals problemlos
> verwendet(m8, m88, m644), aber diesmal habe ich Probleme damit. Ich habe
> den Bootloader heute für m1281 erstellt, geflasht und getestet. Hat beim
> ersten mal funktioniert. Plötzlich ging er nicht mehr, dann ging er
> wieder usw. Ich benutze fboot21 (ist das die aktuelle Version?) für die
> Kommunikation mit dem PC und es kommt folgender Fehler:
>
> COM1 at 38400 Baud: Connected <One Wire>
> Bootloader VFFFFFFFF.FF
> Error, wrong device informations
>
> Das komische ist nur, dass ich den Prozessor gar nicht one wire
> angeschlossen habe.
> Mit niedrigeren Baudraten habe ich schon experimentiert - nützt nichts.

Hallo,

ich habe anscheinend das gleiche Problem wie Paul P. aber mit einem 
Mega8.
Beim ersten flashen mit fboot, wenn der Speicher noch leer ist, 
funktioniert alles wie es soll.
Verwende ich fboot ein zweites Mal, wenn sich schon ein Programm im 
flash befindet, erhalte ich diese Fehlermeldung:

COM 1 at 19200 Baud: Connected (One wire)
Bootloader VFFFFFFFF.FF
Error, wrong device informations

Der Bootloader steht bei mir von 0x1E00 bis 0x1FFF im flash.
Fuse BOOTSZ: Boot Flash size=256 words Boot address=$0F00

Hat jemand eine Idee, was das sein kann?

[Malte P. (maltep87)]

Hallo,

zuerst mal vielen Dank für den super Bootloader.

Ich flashe während meiner Entwicklung hauptsächlich unter Linux und 
benutze ein einzelnes Zeichen um den Controller zu resetten. Im 
Bootloader wird dann wie gewohnt ja auch noch das Passwort "abgefragt".
Das Linux Tool bietet die Möglichkeit diese Reset Sequenz mit dem 
Parameter -r zu übergeben.
Unter Windows allerdings habe ich kein Konsolen Tool gefunden was das 
kann. Ich habe somit jetzt die Windows Version von Alfred N. 
entsprechend verändert und mit dev-cpp compiliert. Sourcen im Anhang. 
Die Projektdateien sind auch dabei, wer noch etwas verändern möchte kann 
mit dem Inhalt des ZIP Files direkt loslegen ;-)


Und dann habe ich unabhängig davon noch eine Frage. Ich möchte mit einem 
Jumper oder Taster den Bootloader dauerhaft im Bootloadermodus halten. 
Das hat den Sinn das Gerät durch festhalten eines Tasters in eine Art 
Emergency Flash Modus zu versetzen falls mal eine defekte Firmware 
hochgeladen wurde. Der Reset ist nicht nach außen geführt, und das 
möchte ich auch nicht tun.

Sprich genauer, an der Stelle wo der Bootloader nach der Wartezeit ins 
eigentliche Programm springt eine Abfrage, Port LOW -> zurückspringen 
zum Anfang des Bootloaders, Port HIGH -> Programm wie gewohnt ausführen.

Bin in ASM nicht so fit, währe über entsprechende Tips dankbar.

Gruß
Malte

[Michael H. (michael_h45)]

Malte Pöggel schrieb:
> Unter Windows allerdings habe ich kein Konsolen Tool gefunden was das
echo lalala > COM1
Vorher mit MODE parametrieren.

Passt wunderbar ins makefile.

[Uwe (de0508)]

Hallo!

ich möchte nur kurz einen Bericht abliefern.

Bootloader interessieren mich auch schon länger und ich habe bisher mit 
dem "USBaspLoader" erfolgreich arbeiten können.

Da ich heute den Bootloader "fastboot_build28.tar.gz" testen wollte, ich 
ich ihn für eine ATmega32 Entwicklungsboard mit Q=14.745 mit RS232 
(MAX232) übersetzt.

Dann über den 10-pol ISP mit usbasp und avrdude programmiert.

avrdude -c usbasp -P usb -p m32 -U flash:w:bootload.hex:i -U flash:v:bootload.hex:i -y

Die Fuse-Bits habe ich wie folgt festgelegt:

avrdude -c usbasp -P usb -p m32 -U lfuse:w:0x3f:m -U hfuse:w:0xde:m

Das schon fertige Bascom Programm ist dann unter Linux mit:

Bootloader21_20080510.tar.gz

aufgespielt worden.

RS232 wird über einen FT232RL auf eine von mir entwickelten Schaltung 
zur Verfügung gestellt und mit 57600 Baudrate dauert eine Überprüfung 
5,02 Sek.

Frage: habe ich aktuellen Software-Module verwendet ?

[Uwe (de0508)]

Hallo !

für meine Zwecke habe ich das Bootloader Programm 
"Bootloader21_20080510.tar.gz" noch etwas erweitert, so dass 
"devices.txt" auch unter {".","/etc","/etc/avr-bootloader"} gesucht 
wird.
Somit kann ich das kleine Programm unter "/usr/bin" installieren und 
ohne Fehlermeldung systemweit nutzen.

   const char * cp_devices_path[] = {".","/etc","/etc/avr-bootloader",""};
   int k = 0;
   int b_read = 0;

   while(cp_devices_path[k][0] != '\0' && !b_read)
   {
     char c_buffer[256] ;
     sprintf(c_buffer, "%s/devices.txt", cp_devices_path[k++]);

     if((fp = fopen(c_buffer, "r")) != NULL) 
     {
    b_read = 1;
        while(fgets(s, 256, fp)) {
           if(sscanf(s, "%lX : %s", &j, s) == 2){ // valid entry
              if(i == j) {
                 break;
              }
           }
           *s = 0;
        }
        fclose(fp);
     } 
   }

   if (!b_read)
   {
        sscanf ("(?)" , "%s", s);
        printf("File \"devices.txt\" not found!\n");
   }

[Malte P. (maltep87)]

Hi,

habe nun einen Kumpel gefragt, der mir die Routine entsprechend 
angepasst hat um bei gedrücktem Taster den Bootloader nicht zu 
verlassen. Der Taster hat einen externen Pullup Widerstand.

Patch im Anhang, vielleicht kann sowas ja noch mal jemand gebrauchen.


Gruß
Malte

[eku (Gast)]

Hallo Peter!

Wollte mir gerade eine Version für den ATMEGA1284P generieren:

AVRASM: AVR macro assembler 2.1.42 (build 1796 Sep 15 2009 10:48:36)
Copyright (C) 1995-2009 ATMEL Corporation

bootload.asm(36): Including file '..\..\avrasm2\defs\m1284pdef.inc'
bootload.asm(66): Including file 'fastload.inc'
fastload.inc(8): Including file 'fastload.h'
fastload.h(2): Including file 'compat.h'
fastload.h(3): Including file 'protocol.h'
FATAL ERROR: Too deeply nested macro calls(16)

Assembly failed, 1 errors, 0 warnings

Für andere MCUs funktioniert es.

[Jens K. (jens_k56)]

Such mal in diesem Thread nach deinem Fehler, z.B. nach "nested macro 
calls", dann findest du z.B. hier einen Beitrag mit dem gleichen Fehler:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Direkt darunter findest du die Antwort von Peter mit Anhang.

Gruß,
Jens

[eku (Gast)]

Hallo Hens,

Jens K. schrieb:
> Direkt darunter findest du die Antwort von Peter mit Anhang.

Du meinst also, Version 1.8 ist besser als 2.1? Ich kann es nicht 
glauben.

[Bernhard M. (boregard)]

eku schrieb:
> Hallo Hens,
>
> Jens K. schrieb:
>> Direkt darunter findest du die Antwort von Peter mit Anhang.
>
> Du meinst also, Version 1.8 ist besser als 2.1? Ich kann es nicht
> glauben.

Du musst es auch verstehen...
In fastload.h:

  .set    BufferSize    = SRAM_SIZE / 2 - PAGESIZE
  .macro testpage
    .if        BootStart % BufferSize
      .set    BufferSize = BufferSize - PAGESIZE
      .if    BootStart % BufferSize
        .set    BufferSize = BufferSize - PAGESIZE
        testpage
      .endif
    .endif
  .endmacro
    testpage    ; calculate Buffersize to fit into BootStart

ersetzen durch:

.set    BufferSize      = SRAM_SIZE / 2 - PAGESIZE

.macro  testpage    ; calculate Buffersize to fit into BootStart
.if     BootStart % BufferSize
.set    BufferSize = BufferSize - PAGESIZE
.endif
.endmacro
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage
  testpage

...damit ist das Macro nicht mehr rekursiv...

[eku (Gast)]

Hallo Bernhard,

danke für die Erklärung.

Bernhard M. schrieb:
> testpage
> testpage

Jetzt muss ich nur noch verstehen, warum gerade 28x testpage.

[Bernhard M. (boregard)]

eku schrieb:
> Hallo Bernhard,
>
> danke für die Erklärung.
>
> Bernhard M. schrieb:
>> testpage
>> testpage
>
> Jetzt muss ich nur noch verstehen, warum gerade 28x testpage.

Es ginge auch 500 mal, das wäre aber übertrieben...
...irgendwann ist

.if     BootStart % BufferSize

nicht mehr erfüllt, dann ist es egal wie oft das Macro noch kommt...

Edit: 42mal wäre die Antwort aller Fragen....

[Guido (Gast)]

Hallo,
habe den Bootloader bisher erfolgreich eingesetzt und bin sehr 
zufrieden.
Gestern habe ich den Bootloader f. einen ATMega128 (128kB Rom) gebaut,
alles hat funktioniert. Der Bootloader nimmt mit fboot die Kommunikation 
auf,
die Daten werden übertragen mit 155200 Baud und der CRC-Check is ok.
NUR: Es steht aber anschließend das Programm nicht im MC. Da steht brav 
überall 0xff.
Kann es sein das der Bottloader oder fboot mit Speicherbereichen > 64 kB 
nicht zurechtkommt ?
Ich fahre Windows, das Programm ist schon auf einem ATMega64 gelaufen 
und deutlich
kleiner als 64 kB. Konventionell übertragen läuft es auch auf dem M128.
Irgend eine Ahnung was das sein könnte ? Für eine Antwort wäre ich sehr
dankbar.
Schöne Grüsse
  Guido

[Mario G. (mario)]

Wen das Thema Bootloader interessiert, schaut euch mal den Artikel
AVR Bootloader in C - eine einfache Anleitung an!

[Ralf K. (elral)]

Hallo Martin, hallo Peter,

MartinS schrieb:
>>> - Pullup auf 5V am Bootloader-Bin mit 4k7
>>?
> Bin sollte Pin lauten... und von dort einen 4k7 Pullup auf die +5V vom
> AVR.
>
>>> - komplette Schaltung wie in diesem Thread (2x dioden, 2x 4k7)
>>Diese hier?
>>Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"
> Ja - sollte das mit der klappen?
>
>>> - Änderung im Code (TX/RX Pegel in den Macros TXD_0, TXD_1, SKIP_RXD_0,
>>> SKIP_RXD_1) genau invertiert.
>>reicht nicht.
>>Der Sender muß beim 0-Bit nicht nach VCC, sondern auf GND ziehen.
> ok, dann schau ich mir das morgen an - wenn den die Schaltung oben die
> richtige ist...?
>
> Danke für die Tipps!

ich stehe gerade vor der gleichen Heruasforderung, dass ich bei einer 
Anwendung nur einen Pin zur Verfügung habe. Martin, hast Du den 
Bootloader mittlerweile im 1Wire mittels USB-TTL Wandler zum laufen 
bekommen? Wenn ja, könntest Du mir bitte sagen, was geändert werden 
soll. Ich muss leider gestehen, dass ich die Tips nicht so richtig 
nachvollziehen konnte.

Mein Ansatz wäre auch dieser gewesen (FASTLOAD.H):
  .if INVERTED
    .macro  SKIP_RXD_0
    sbic  SRX_PIN, SRX  ; low = 0
    .endmacro
    .macro  SKIP_RXD_1
    sbis  SRX_PIN, SRX  ; high = 1
    .endmacro
  .else
    .macro  SKIP_RXD_0
    sbis  SRX_PIN, SRX  ; low = 1
    .endmacro
    .macro  SKIP_RXD_1
    sbic  SRX_PIN, SRX  ; high = 0
    .endmacro
  .endif

TX über 2,7k auf RX, RX auf Pin des ATmega geschaltet.
Masse USB-TTL Wandler und Masse Schaltung verbunden.

Scheint aber nicht zu reichen.
Peter, Deinen letzten Kommentar verstehe ich nicht. Da der USB-TTL 
Wandler genau negierte Spannungspegel liefert wie die RS232, hätte ich 
eigentlich gedacht dieses würde ausreichend sein.

Könnt Ihr mir ggf. noch einen Tipp geben?


Danke und Grüße

Ralf

[eku (Gast)]

Hallo Peter,

bislang habe ich Deinen Bootloader auf älteren ATMegas mit WDTRIGGER=0 
erfolgreich im Einsatz. Bei neueren ATmegas ist der Watchdog auch nach 
dem Auslösen (=Sprung in Bootloader) aktiv, wird aber von Deinem 
Bootloader nicht deaktiviert. Gibt es noch eine andere Lösung als 
WDTRIGGER=1 zu setzen? Für den Fall WDTRIGGER=0 sollte Dein Bootloader 
den Watchdog deaktivieren. Würdest Du das bitte implementieren?


Gruß,

[Martin J. (bluematrix)]

Frage an die Bootloader Gemeinde:

Ich möchte für ein Projekt einen Bootloader verwenden, um 
Softwareupdates zu ermöglichen.
Jedoch sind die bisher verwendeten Möglichkeiten um den Bootloader in 
den Updatemodus zu versetzen bei mir nicht möglich. Ich kann also nicht 
den Taster oder die typischen 2 Warte sekunden bei einbauen.

momentan habe ich folgendes umgesetzt:

Nach dem Start checkt der Bootloader wie er gestartet wurde, in dem er 
das Reset Register ausliest.
Wurde der Controller normal gestartet, so wird das bisherige Programm 
aus dem EEProm geladen.
Wurde der Controller durch einen Hardwarereset neu gestartet, so 
bedeutet es, dass eine neue Firmware als update kommt. Der Hardwarereset 
wird durch die aktuelle Firmware ausgelöst, meist über einen Befehl von 
der RS232 Schnittstelle.
Funktioniert so auch richtig gut.

Jedoch kann ich so keinen Watchdog benutzen (da der Bootloader sonst 
jedesmal eine neue Firmware erwarten würde) was mir auch nicht recht 
ist, da ich den Controller in einer relativ kritischen Anwendung nutze.

Ist folgendes möglich?

Kann ich zum speichern der Updateinformation auch ein Byte im EEprom des 
Controllers nutzen? Es muss dabei garantiert sein, dass der Bootloader 
und die Firmware auf die selbe SPeicherzelle zugreifen.
ist dsa möglich?

schon mal Vielen Dank

[Bernhard M. (boregard)]

Hallo,

hier mal einen aktuellen Stand meines Linux-clients.

Wesentliche Änderungen:
- wenn man die UART auch für debugging Ausgaben benutzt, kann man den 
Bootloader nun auch mit der Zusatzoption -T starten, dann bleibt das 
Programm in einem primitiven Terminal-Mode, bei dem alle Eingaben auf 
der Tastatur über die UART rausgeschickt werden, und alles was über die 
UART rein kommt angezeigt wird. So kann man den Bootloader immer offen 
lassen, während man entwickelt (Download kann mit Ctrl-D gestartet 
werden...).

- Verbesserung der One-Wire detection, so daß sie nicht irrtümlich im 
Two-Wire Modus anspringt, wenn Controller noch nicht resettet ist und 
Zeichen sendet.

Gruß,
Bernhard

[Dominique G. (dgoersch)]

Hallo Bernhard,

Bernhard M. schrieb:
> dann bleibt das
> Programm in einem primitiven Terminal-Mode, bei dem alle Eingaben auf
> der Tastatur über die UART rausgeschickt werden, und alles was über die
> UART rein kommt angezeigt wird. So kann man den Bootloader immer offen
> lassen, während man entwickelt (Download kann mit Ctrl-D gestartet
> werden...).

da Ctrl-D bei vielen Linuxanwendungen mit interaktiver Shell ("ftp", 
"mysql", "bc", jede Login-Shell, ...) ein Kommando zum verlassen dieser 
ist, würde ich hier eher einen anderen nehmen.

Ansonsten klingen deine Erweiterungen sehr interessant.

[Bernhard M. (boregard)]

Dominique Görsch schrieb:
> Hallo Bernhard,
>
> Bernhard M. schrieb:
>> dann bleibt das
>> Programm in einem primitiven Terminal-Mode, bei dem alle Eingaben auf
>> der Tastatur über die UART rausgeschickt werden, und alles was über die
>> UART rein kommt angezeigt wird. So kann man den Bootloader immer offen
>> lassen, während man entwickelt (Download kann mit Ctrl-D gestartet
>> werden...).
>
> da Ctrl-D bei vielen Linuxanwendungen mit interaktiver Shell ("ftp",
> "mysql", "bc", jede Login-Shell, ...) ein Kommando zum verlassen dieser
> ist, würde ich hier eher einen anderen nehmen.
>
> Ansonsten klingen deine Erweiterungen sehr interessant.

Ich Idiot, beim Schreiben sollte man nachdenken....
es ist Ctrl-P (mit Ctrl-V macht man einen verify usw...)

[Dominique G. (dgoersch)]

Dann hab ich nix gesagt :)

[Komori S. (Firma: Home office) (comop)]

Hallo, 'kon niti ha!' Ich habe dieses Forum aus Japan.

Ich bin jetzt, ATtiny85-SSU, mit 1 x1 cm Zentimeter macht einen 
Baseboard. Klare Trennung im Ausdruck und Ausstrahlung, kann verwendet 
werden, um PB5 freuen uns auf Ihre Anmeldung.

Was dies in der japanischen Fboot ändern?
Darüber hinaus MacOSX  Windows  Linux für, GUI-Anwendung zu machen, 
denke ich.

HEX-Datei zu erzeugen Arduino.

Danke für ein tolles Programm.

Fragen

Kann ich diese kostenlos Bootloader?

Schrieb in der automatischen Übersetzung von Google. Bitte entschuldigen 
Sie unhöflich Sätzen.

Satoru Komori
Yokohama, Japan

[... (Gast)]

Komori Satoru schrieb:
> Schrieb in der automatischen Übersetzung von Google.

Its better you speak english here.

[Peter D. (peda)]

Komori Satoru schrieb:
> Kann ich diese kostenlos Bootloader?

Der Bootloader und die Sourcen sind uneingeschränkt benutzbar.


Peter

[Komori S. (Firma: Home office) (comop)]

Thank you. Peter

I searched and experimented with Tiny85 Bootloader for many.
However, most good Fastboot.

I understand even less for yet, let me learn.

[Michael H. (michael_h45)]

Hallo,

ich würde gerne eine LED anschalten, während der Bootloader aktiv ist.
Dazu hab ich Folgendes gemacht:
- in der BOOTLOAD.ASM diese Zeile eingefügt:

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
;      set both lines equal for inverted onewire mode:

.equ    STX_PORT        = PORTB
.equ    STX             = PB3

.equ    SRX_PORT        = PORTB
.equ    SRX             = PB2
;------------------------------------------------------------------------- <
.include "pinset.inc"                                                      < NEU
;------------------------------------------------------------------------- <
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

- in dieser pinset.inc steht genau das hier:

; debug led ge
sbi  PORTA, PA1
sbi  DDRA, DDA1

Der Bootloader sollte 1s lang nach dem Reset warten:

.equ  BootDelay  = XTAL * 1  ; 1s

Das Ergebnis: Flasht man den Bootloader per SPI auf einen leeren 
Controller, leuchte die LED dauerhaft wie gewollt.
Lädt man allerdings eine Applikation in den Controller und zieht die 
Reset-Leitung danach kurz auf Masse, geht die LED nicht an.


Was mache ich falsch?

[Sebastian M. (compressed)]

Hallo,
nach 3 Stunden rumprobieren hat es dann doch funktioniert.

Habe das Problem mal als Bild angefügt, vielleicht weiß jemand eine 
Erklärung?
Konnte diese Eingabe jedenfalls noch in keiner Diskussion/Tutorial 
finden.


OS: WinXP
myAVR ISP MKII
Atmega8
WINAVR

danke für die tolle Software.

[Sven S. (schwerminator)]

Moin Moin. Ich versuche gerade den Bootloader unter Linux zum laufen zu 
bekommen.Ich benutze den Uploader aus dem folgenden Post:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"
Ich habe an meinem Notebook keinen nativen COM-Port, bin also auf einen 
Konverter angewiesen. dmesg gibt folgendes: FTDI USB Serial Device 
converter now attached to ttyUSB0. Also habe ich den Uploader so 
gestartet: ./bootloader -d ttyUSB0 -p test.hex. Jedoch kommt folgende 
Meldung: Opening com port "ttyUSB0" failed (No such file or directory)!

Was kann ich tun? Gruß!

[Uwe (de0508)]

Hallo,

ich habe den selben chip, es geht, aber nur so:

mit /dev/ttyUSB0

schau mal mit

$ ls -la /dev/ttyUSB0

nach.

Ich muss noch in meinem System Mitglied der Gruppe "dialout" sein.

[Tobias (Gast)]

Hi

Ich versuche auch gerade den Bootloader zu installieren.

Benutze einen ATmega32. Hab den Bootloader auch installiert bekommen und 
versuche nun ein Programm auf den ATmega32 zu übertragen.

Das Übertragungstool meldet:
COM 1 at 9600 Baud: Connected
Bootloader V2.1
Target: 1E9502 ATmega32
Buffer 1024 Byte
Size available: 31744 Byte
CRC: o.k.
Elapsed time: 0.31 seconds

Klingt ja so weit super. Nur danach läuft das Programm nicht auf dem 
Prozessor! Es läuft stattdessen nur der Bootloader. Ich kann also sofort 
und ohne drücken des Reset-Tasterts das "nächste" Programm raufspielen, 
immer wieder und immer wieder ohne Drücken des Tasters. Mein gewünschtes 
Programm wird dagegen nicht ausgeführt. Was mach ich falsch?

Gruß Tobias

[Michael H. (michael_h45)]

Fuses falsch?

[Tobias (Gast)]

Laut AVR Studio 4 hab ich Boot Flash size auf 256 words stehen und den 
Boot reset vector enabled (Also Haken gesetzt was einer 0 entsprechen 
müsste)

oder anders gesagt: Die kompletten Fuses: High steht auf 0xCE, Low auf 
0xEE

[Tobias (Gast)]

Fehler gefunden! Der Buchstabe "P" vor dem Namen des zu schreibenden 
Hex-Files fehlte!

[Sven S. (schwerminator)]

Uwe S. schrieb:
> Hallo,
>
> ich habe den selben chip, es geht, aber nur so:
>
> mit /dev/ttyUSB0
>
> schau mal mit$ ls -la /dev/ttyUSB0nach.
>
> Ich muss noch in meinem System Mitglied der Gruppe "dialout" sein.

Besten Dank! Das half.

[Chris L. (kingkernel)]

Ich versuche seit einiger Zeit einen mega16 mit Bootloader zum Laufen zu 
bekommen. Leider ohne erfolg.
Den Bootloader kann ich compilieren und auch Flashen. Das Programmieren 
der eigentlichen Nutzsoftware schlägt allerdings fehl. Der 
Programmiervorgang bricht nach einien Byte stets mit der meldung 
"failed" ab. Manschmal bleibt er bei 00200 stehen, teilweise packt er 
auch 01800
Einen mage644 in der selben schaltung kann ich ohne probleme 
programmieren.
nach erstellen des bootloaders für den 644 habe ich die ide geupdated, 
vielleicht liegt es daran.
kann mir einer seine funktionierende version für den mega16 bei 16Mhz 
posten?

Und nocoh etwas, ist es möglich, den bootloader auf einem mega1284P zum 
laufen zu bekommen?

[Uwe (de0508)]

Hallo Christian,

gerne, wenn Du mir noch bestätigst:

mega16 bei 16Mhz

TX Pin ?
RX Pin ?

Oder

1-Wire Pin ?

[Chris L. (kingkernel)]

Hardware-USART
16MHz

Wäre es möglich, dass mir da der Watchdog reinhagelt? Ich finde keine 
Fuse zum abschalten desselben.

[Uwe (de0508)]

Hallo,

der WDT hat keine FuseBits, geht also nur per Software.

Welche Bits sind es nun, ich schaue jetzt nicht ins Datenblatt.

[Chris L. (kingkernel)]

War das ne Frage?
Willste von mir die bits wissen?
Oder war das nur ein Hinweis darauf, dass der m16 keine fuses, sondern 
nur regsiter zur steuerung des WDT hat

[Chris L. (kingkernel)]

Ich hab jetzt noch ein wenig experimentiert. wenn ich in der 
watchdog.asm den watchdog ausschalte funktioniert es auch nicht. An 
meinem USB-RS232-Wandler liegt es auch nicht. Habe es mit einem echten 
RS232-Port probiert, das gleiche Problem.
wenn ich die m16def.h durch eine m644def.h ersetzte und den Bootloader 
für einen mega644 assembliere, kann ich diesen Wunderbar per Bootloader 
programmieren. Nur der m16 will nicht.
Woher nimmt das Bootloader programm eigentlich die Infos wie Pagesize 
und Buffersize, vielleicht ist da was im Argen

Ich bin hier langsam echt am verzweifeln

[Dominique G. (dgoersch)]

Also ich hab den Fastload schon auf etlichen m16 benutzt und dort 
funktionierte er immer bestens.

[Chris L. (kingkernel)]

Ich häng hier mal meine Hex-Datei an. Kann die mal jemand testen?
16MHz, Hardware-USART
Ich verwende diesen Bootloader 
(Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain") mit dieser 
Software (Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"). Müsste so 
eigentlich passen, da der 644 ohne probleme geht

[Chris L. (kingkernel)]

Ich habs eben nochmal getestet. Irgendwas stimmt da nicht bei der 
übertragung. Ich bekomme teilweise nen CRC error schon beim Abfragen des 
Bootloaders. Die Quarzfrequenz hab ich im Makefile richtig angegeben und 
auch den richtigen Quarz bestückt.
ein mega644 geht ohne probleme. einfach "m16def" durch "m644def" im 
makefile ersetzt und sonst alles haargenau so gemacht wie auch beim m16. 
auch andere m16 und auch ein m32 wollen nicht.
ich bin langsam am verzweifeln. ich schau mir das später mal mit nem 
logicanalyzer an, was da genau übertragen wird

[Uwe (de0508)]

Hallo Christian,

wie "alt" ist die m16def ?  - steht in der Datei.

Hast Du vor jedem neuen Compilieren auch die
Zeilen angepasst ?

MCU = atmega16
ATMEL_INC = ./atmel/m16def.inc
F_CPU = 16000000

# Define the Tx and Rx lines here.  Set both groups to the same for
# one wire mode:
STX_PORT = PORTD
STX = PD1

SRX_PORT = PORTD
SRX = PD0

dann erst

$make clean

aufrufen und erst jetzt werden die Datei mit

$make

alle neu compiliert !

[Chris L. (kingkernel)]

Meie Makefile
[quote]
MCU = atmega16

ATMEL_INC = m16def.inc

F_CPU = 16000000

DEBUG = dwarf-2
#DEBUG = stabs+

STX_PORT = PORTD
STX = PD1

SRX_PORT = PORTD
SRX = PD0
[/quote]

Auszug aus der m16def.inc
;* Date              : 2010-08-20
;* Version           : 2.35
;* Target MCU        : ATmega16

wenn ich das MCU und ATMEL_INC an den m644 anpasse und dann auf clean 
und make klicke, kann ich mit dem 644 wunderbar arbeiten. der m16 und 
m32 wollen nicht

[Uwe (de0508)]

Hallo Christian,

deine Makefile Anpassungen sehen für mich richtig aus.

Warum es dann doch nicht klappt weiss ich jetzt auch nicht.

Ich hatte bisher damit keinerlei Probleme bei der Verwendung für 
atTiny85, atMega48, atMega88, atMega168 und atMega32.

[Uwe (de0508)]

Hallo Christian,

ich habe mal mein Makefile für den atmega32 angepasst und eine HEX-Datei 
für Dich erzeugt.

Hier die Meldungen des Compilerlaufs:

*** Note: set BOOTSZ fuses to the word address 0x1f00 ***
arch=avr5
LOADER_START=0x3e00
STUB_OFFSET=0x1fe

Ich würde dann diese Fusebits mit avrdude setzen:

avrdude -c usbtiny -p m16 -P usb -v -U lfuse:w:0x3e:m -U hfuse:w:0xdc:m

[Chris L. (kingkernel)]

Leider das gleiche Problem. Ich habe auch mal einen anderen atmega16 
ausprobiert. den quarz und alle kondensatoren gewechselt. sonstige 
beschaltung des avr ist nur der AVR-Dragon
Das Programmieren bleibt immer an unterschiedlichen Stellen stehen. 
Gestern hat es sogar einmal funktioniert, danach leider nicht mehr.

[Uwe (de0508)]

achja Christian,

das ist schlecht.
Hast du einen Schaltplan von deiner Anwendung und wie schnell Baudrate 
wird der Bootloader benutzt?

Teste doch mal 19200, 9600 etc...

[Chris L. (kingkernel)]

Hab schon verschiedene Baudraten versucht. Leider das selbe, erst 
schreibt er und mittendrin kommt dann ne pause mit einem anschließenden 
"failed"
Schaltplan hab ich keinen. Der AVR steckt im Prototypenbereich des 
Dragon. Zusätzlich noch nen 100nF Kerko an den Versorgungsspannungspins
einen 16MHz quarz mit 33pF gegen masse an jedem pin
die ISP-Leitungen
Angebunden an den Computer ist das ganze über die RX und TX-Leitung des 
AVR mittels meines TTL-RS232 umsetzers über einen USB-RS232-dongle. Aber 
auch ein "echter" RS232 Port hat nicht geholfen. a TTL-RS232-Umsetzer 
liegt es auch nicht, ich habe probehalber einen anderen ausgeliehen und 
es damit getestet.

[Jörg E. (jackfritt)]

@sgm
Ist zwar schön älter aber wurden deine Bootloader Änderungen
in AVRDUDE übernommen ?

Joerg

[Niklas G. (erlkoenig)]

Hallo zusammen,
ich habe mit einem Selfmade-ISP Adapter den Bootloader auf einen ATmega8 
geschrieben, mit folgenden Einstellungen:
.equ  XTAL    = 1000000  ; 1MHz, not critical
.equ  BootDelay  = XTAL  ; 1s
Der uC läuft mit dem internen Oszillator auf 1MHz; das wird später noch 
geändert.
ich habe dann über ded FTDI USB->RS232 Konverters eines Arduino's mit 
dem Programm von Alfred N. ( 
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" ) ein Programm von 
mir aufgespielt. Das hat ganz wunderbar funktioniert, aber jetzt startet 
sofort nach anschließen der Spannungsversorgung (oder nach Reset des 
mega8) mein Programm, und es ist unmöglich den Bootloader vorher zu 
"erwischen" und ein neues Programm aufzuspielen. Kann mir jemand 
verraten, was ich falsch gemacht habe? Habe diesen Thread auch schon 
durchsucht, aber der ist etwas unübersichtlich...

[Chris L. (kingkernel)]

Hast du auch dran gedacht, die Fuses einzustellen?
auf dem mega8 muss die BOOTRST-Fuse aktiv sein

[Niklas G. (erlkoenig)]

Autsch. Steht sogar im Wikiartikel. Da war ich mal wieder zu voreilig. 
Danke für den Tipp :)

[Kai E. (kai20)]

Hallo,

ich weiss, es gibt eine neuere Version dieses Bootloaders,
leider aber kein passendes fboot fuer einen Windows PC.

Deshalb nutze ich diese 2.1 version.

Leider habe ich es mit allen Hilfen in diesem Thread nicht geschafft,
einen Bootloader fuer einen ATMega1284P zu erstellen.

Kannm mir jemand ein funktionierendes FASTLOAD.H und ein inc file fuer
dem 1284 hochladen ?

Waere klasse,
Danke,
Kai

[Rene Z. (renezimmermann)]

Hallo,

ich benutze Version 2.1 des Bootloaders. Jetzt mal die Sache die mir 
aufgefallen ist. Ich lösche den M8 und Flash den Bootloader. Dann ist 
der Flashinhalt folgender:

:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0

. . . . . . . . .

:101DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03
:101DF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3
:101E0000F8946FE56DBF64E06EBF22243324A8957B
:101E100061B560617FE061BD63FD71BD909A919A8B
:101E2000899A21E030EA63E0F101EF01F1010197C5
:101E300060408099E1F7D9F121973496C0F1809BF9
:101E4000FBCF0F2EC5950694E9F72397269668F7E2
:101E5000EA35F20550F3F797F695E7952F01CAE0BA
:101E6000EEEBFFE10590002031F074D00616D1F3BF
:101E7000CA95E9F0F5CF66EA87D06CD0E1F76AEA57
:101E800083D068D0F1F766D0F1F3F101E8946430C3
:101E900088F051F1653059F06730E9F067EA80F772
:101EA00059D058D0672859F331016BEAE9CF21BAEC
:101EB00022BAA6C0E4ECFFE1C0E0EC0FF21DC49131
:101EC0006150D8F768EA60D06591C150E0F7D7CF8C
:101ED0000590061268943ED0D9F73CD06058C1F7FF
:101EE00026F3CDCF69EA50D06894A0E6B0E0D4E004
:101EF00031D031F42FD0605819F48EF0689405C0B9
:101F0000E8946D93A032BD0799F7A0E6B0E008D041
:101F100060F6E05CFF4FA032BD07C9F71EF7AFCFF8
:101F2000E0306EE1F607A8F40D901D9061E00BD053
:101F300032966E2F6E73C1F7E054F04063E003D029
:101F400065E001D061E167BFE89567B760FDFDCF4F
:101F500008940895A895809BFDCF8099FECF78E0E6
:101F6000C2019695879523D021D0669580996068A7
:101F700067FD62267694679408F4622608F4732657
:101F80007A9591F7653A089511D09198749179E016
:101F9000609500C000C00AD0669518F400009198C2
:101FA00002C0919A00C07A95A1F70895C2010497E2
:101FB000F0F78D3F18F011F08F3F01F00895506554
:101FC000646100000302010303C0041E93070400C0
:101FD0001E007FB7F894613860EF21F4A1DF60E85C
:101FE00008F061EF7FBF0895FFFFFFFFFFFFFFFFD6
:101FF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFE9CF37
:00000001FF

Klar logisch, alles leer bis auf den Bootloader.

Jetzt schreibe ich folgendes Hexfile:

:10000000F2C1F9C1F8C1F7C1F6C1F5C1F4C1F3C13C
:00000001FF

also 16 Bytes und gut ist. Das ganze erledige ich mit FBoot.

C:\FastBoot\FBOOT>fboot /B9600 /C1 /Ptest.hex
COM 1 at 9600 Baud: Connected
Bootloader V2.1
Target: 1E9307 ATmega8
Buffer: 960 Byte
Size available: 7680 Byte
Program test.hex: 00000 - 0000F successful
CRC: o.k.
Elapsed time: 0.44 seconds

Wenn ich jetzt den M8 wieder auslese erhalte ich folgendes:

:10000000F2C1F9C1F8C1F7C1F6C1F5C1F4C1F3C13C
:1000100078828C96A00A141E28323C46505A646E90
:1000200078828C96A011241FBECFE5D4E0DEBFCD30
:10003000BF02D004C004CE80E090E00895F894FFA1
:10004000CF78828C96A00A141E28323C46505A64FF
:100050006E78828C96A00A141E28323C46505A6450
:100060006E78828C96A00A141E28323C46505A6440
:100070006E78828C96A00A141E28323C46505A6430
:100080006E78828C96A00A141E28323C46505A6420
:100090006E78828C96A00A141E28323C46505A6410
:1000A0006E78828C96A00A141E28323C46505A6400
:1000B0006E78828C96A00A141E28323C46505A64F0
:1000C0006E78828C96A00A141E28323C46505A64E0
:1000D0006E78828C96A00A141E28323C46505A64D0
:1000E0006E78828C96A00A141E28323C46505A64C0
:1000F0006E78828C96A00A141E28323C46505A64B0
:100100006E78828C96A00A141E28323C46505A649F
:100110006E78828C96A00A141E28323C46505A648F
:100120006E78828C96A00A141E28323C46505A647F
:100130006E78828C96A00A141E28323C46505A646F
:100140006E78828C96A00A141E28323C46505A645F
:100150006E78828C96A00A141E28323C46505A644F
:100160006E78828C96A00A141E28323C46505A643F
:100170006E78828C96A00A141E28323C46505A642F
:100180006E78828C96A00A141E28323C46505A641F
:100190006E78828C96A00A141E28323C46505A640F
:1001A0006E78828C96A00A141E28323C46505A64FF
:1001B0006E78828C96A00A141E28323C46505A64EF
:1001C0006E78828C96A00A141E28323C46505A64DF
:1001D0006E78828C96A00A141E28323C46505A64CF
:1001E0006E78828C96A00A141E28323C46505A64BF
:1001F0006E78828C96A00A141E28323C46505A64AF
:100200006E78828C96A00A141E28323C46505A649E
:100210006E78828C96A00A141E28323C46505A648E
:100220006E78828C96A00A141E28323C46505A647E
:100230006E78828C96A00A141E28323C46505A646E
:100240006E78828C96A00A141E28323C46505A645E
:100250006E78828C96A00A141E28323C46505A644E
:100260006E78828C96A00A141E28323C46505A643E
:100270006E78828C96A00A141E28323C46505A642E
:100280006E78828C96A00A141E28323C46505A641E
:100290006E78828C96A00A141E28323C46505A640E
:1002A0006E78828C96A00A141E28323C46505A64FE
:1002B0006E78828C96A00A141E28323C46505A64EE
:1002C0006E78828C96A00A141E28323C46505A64DE
:1002D0006E78828C96A00A141E28323C46505A64CE
:1002E0006E78828C96A00A141E28323C46505A64BE
:1002F0006E78828C96A00A141E28323C46505A64AE
:100300006E78828C96A00A141E28323C46505A649D
:100310006E78828C96A00A141E28323C46505A648D
:100320006E78828C96A00A141E28323C46505A647D
:100330006E78828C96A00A141E28323C46505A646D
:100340006E78828C96A00A141E28323C46505A645D
:100350006E78828C96A00A141E28323C46505A644D
:100360006E78828C96A00A141E28323C46505A643D
:100370006E78828C96A00A141E28323C46505A642D
:100380006E78828C96A00A141E28323C46505A641D
:100390006E78828C96A00A141E28323C46505A640D
:1003A0006E78828C96A00A141E28323C46505A64FD
:1003B0006E78828C96A00A141E28323C46505A64ED
:1003C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D
:1003D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2D
:1003E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1D

. . . . . . . . .

:101DD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF13
:101DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03
:101DF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3
:101E0000F8946FE56DBF64E06EBF22243324A8957B
:101E100061B560617FE061BD63FD71BD909A919A8B
:101E2000899A21E030EA63E0F101EF01F1010197C5
:101E300060408099E1F7D9F121973496C0F1809BF9
:101E4000FBCF0F2EC5950694E9F72397269668F7E2
:101E5000EA35F20550F3F797F695E7952F01CAE0BA
:101E6000EEEBFFE10590002031F074D00616D1F3BF
:101E7000CA95E9F0F5CF66EA87D06CD0E1F76AEA57
:101E800083D068D0F1F766D0F1F3F101E8946430C3
:101E900088F051F1653059F06730E9F067EA80F772
:101EA00059D058D0672859F331016BEAE9CF21BAEC
:101EB00022BAA6C0E4ECFFE1C0E0EC0FF21DC49131
:101EC0006150D8F768EA60D06591C150E0F7D7CF8C
:101ED0000590061268943ED0D9F73CD06058C1F7FF
:101EE00026F3CDCF69EA50D06894A0E6B0E0D4E004
:101EF00031D031F42FD0605819F48EF0689405C0B9
:101F0000E8946D93A032BD0799F7A0E6B0E008D041
:101F100060F6E05CFF4FA032BD07C9F71EF7AFCFF8
:101F2000E0306EE1F607A8F40D901D9061E00BD053
:101F300032966E2F6E73C1F7E054F04063E003D029
:101F400065E001D061E167BFE89567B760FDFDCF4F
:101F500008940895A895809BFDCF8099FECF78E0E6
:101F6000C2019695879523D021D0669580996068A7
:101F700067FD62267694679408F4622608F4732657
:101F80007A9591F7653A089511D09198749179E016
:101F9000609500C000C00AD0669518F400009198C2
:101FA00002C0919A00C07A95A1F70895C2010497E2
:101FB000F0F78D3F18F011F08F3F01F00895506554
:101FC000646100000302010303C0041E93070400C0
:101FD0001E007FB7F894613860EF21F4A1DF60E85C
:101FE00008F061EF7FBF0895FFFFFFFFFFFFFFFFD6
:101FF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFE9CF37
:00000001FF

Es wurden zu viele Daten geschrieben und noch dazu habe ich keine Ahnung 
welche. Über die serielle Schnittstelle sind diese nicht gegangen 
(SerialPortMonitor Log):

Port geöffnet durch Vorgang "ntvdm.exe" (PID: 2564)

 50 65 64 61 FF 50 65 64 61 FF 50 65 64 61 FF 50   PedaÿPedaÿPedaÿP
 65 64 61 FF 50 65 64 61 FF 50 65 64 61 FF 50 65   edaÿPedaÿPedaÿPe
 64 61 FF 50 65 64 A5 A5 A5 06 5D B4 A5 00 A5 02   daÿPed¥¥¥.]´¥.¥.
 A5 01 A5 03 A5 06 F3 BE A5 04 F2 C1 F9 C1 F8 C1   ¥.¥.¥.ó¾¥.òÁùÁøÁ
 F7 C1 F6 C1 F5 C1 F4 C1 F3 C1 A5 80 A5 06 D4 E8   ÷ÁöÁõÁôÁóÁ¥€¥.Ôè
 A5 80 A5 A5 A5 05                                 ¥€¥¥¥.          

Port geschlossen

Es werden aber Daten von 0 - 03BF geschrieben. Also genau 960 Bytes. Nun 
hat der M8 mit diesem Bottloader genau 960 Bytes Buffer. Das lässt ja 
vermuten das immer der gesamte Buffer geschrieben wird.

Ist das so richtig, gewollt?

Gruß Rene

[Peter D. (peda)]

Ja, es wird immer ein kompletter Puffer geschrieben.
Bei den ATtiny wird der gesamte Flash geschrieben und am Ende der Sprung 
zum Init umgeleitet.



Peter

[Rene Z. (rzimmermann)]

Ahh,

deshalb muß der gesamte mögliche beschreibbare Flash ein vielfaches von 
der Buffergrösse sein. Jetzt habe ich es.

Das mit dem CRC habe ich noch nicht ganz verstanden. Am Anfang soll man 
es einmal Aufrufen um alles zu initialisieren. OK. Und dann noch mal 
nach Abfrage der Informationen. Aber über welche Daten den? Und dann 
noch mal am Ende über den gesamten Flash oder über den gesamten 
möglichen beschreibbaren Flash oder über die übertragenen Daten?

Gruß Rene

[da1l6 (Gast)]

@Bernhard M.
Hier ist ein Patch für lboot um den DTR Pin der seriellen Schnittstelle 
zum automatischen reset des AVRs nutzen zu können.

Die nötige Schaltung ist ein einfacher nicht-invertierender 
Pegelwandler.

z.B. für 3.3V VCC:

                  VCC
RS232              |          AVR
------+            -       +--------
      |           10k      |
  ...              -         ...
      |            |       |
DTR o-+---|R 1k|---+-------+-o ~RESET
      |            |       |
GND o-+---->|------+         ...
      |  Z-3,6V            |
------+                    +--------

da1l6

[Bernhard M. (boregard)]

@da1l6

ich werds am WE mal ausprobieren und dann einbauen.

Ich wollte eh mal eine neue Version hochladen, die auch ohne tcflush() 
arbeitet und damit (hoffentlich) die Bluetooth-Adapter Probleme 
beseitigt (bzw. das krude Warten von 1ms eliminiert).

[Bernhard M. (boregard)]

Hallo,

hier mal ein aktueller Stand des Linux-Loaders.

Er kennt jetzt folgende Optionen:
-d /dev/ttynn
das Device, z.B. /dev/ttyS0 oder /dev/ttyUSB0

-b nn
Baudrate

-t nn
TxD Blocksize, default ist 16. Das ist die Azahl der Bytes die am Stück 
(ohne warten auf Übertragung der Bytes) geschrieben werden. Dies kann 
USB Adapter beschleunigen, da an diese sonst jedes Byte einzeln per USB 
verschickt wird (was dann auf 1000 Bytes pro Sekunde herauskommt...)

-w nn
Wartezeit, bis Bytes übertragen sind. Normalerweise wird per tcdrain() 
gewartet, bis der Treiber alles übertragen hat. Dies (scheint) aber 
nicht immer zu funktionieren (z.B. bei Bluetooth?). Mit dieser Option 
wird direkt gewartet, d.h. es wird ausgerechnet, wie lange ein Byte 
braucht und dies wird mit dem bei -w angegeben Faktor multipliziert.
-w 5 bedeuted dann also das für jedes Byte die fünfache Üertragungszeit 
gewartet wird, allerdings nur nach jedem Block (siehe -t). Bei 
Blockgröße von 16 wird also nach jedem 16. Byte 5  16  die 
Übertragungszeit eines Bytes gewartet.

-r
Reset per DTR auslösen, siehe Posting von da1l6.

-R
wie -r, allerding umgekehrte Pegel

-v
Verify

-p
Program

-e
Erase, zusammen mit -p löscht es den Controller, zusammen mit -v prüft 
es, ob der Controller leer (0xff) ist.

-P pwd
Password

-T
terminal mode

Falls es Fragen gibt....einfach melden.

Gruß,
Bernhard

[devluz (Gast)]

Hallo ihr.

Danke für den Bootloader. Er hat mir sehr geholfen ;)


Da die Windowsversion von fboot2.1 auf neueren Windowssystemen nicht 
lief, habe ich eine abgeänderte Version geschrieben. Bisher wurde sie 
nur unter Windows 7 64Bit + Atmega32 getestet! Gut möglich das ich ein 
paar features versehentlich entfernt hab ...^^

Quellcode und Binäre version findet ihr unter folgender Adresse:
http://derluz.de/fboot64

evtl. kann es ja jemand gebrauchen :)

Wenn ich mit der Veröffentlichung gegen irgendwelche (Lizenz-)Rechte 
verstoßen sollte, sagt mir bitte bescheid. Ich werde die Dateien dann 
soffort offline nehmen!

Grüße

devluz

[M. P. (phpmysqlfreak)]

Hallo,
es hat zwar ganz schön gedauert, bis ich alles gelesen habe, aber nun 
bin ich durch.

Alle meine Versuche mit dem Kommando-Zeilen-Programm schlugen fehl. Den 
Fehler konnte ich bis jetzt nicht herausfinden - leider. Aber ich werde 
dran bleiben.

Was mir bei meinen Attiny13 letztendlich geholfen hat, war folgende 
Anleitung:
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger/Tutorial_ATtiny13

Vielen Dank an Peter für den Bootloader, vielen Dank an alle Anderen, 
für die fleißige Beteiligung an diesem Thema. Und auch vielen Dank an 
den Autor des Tutorials.

Natürlich werde ich ebenfalls meinen Fehlerbericht sowie die Behebung 
preisgeben, sobald ich den oben weiter beschriebenen Fehler genauer 
bezeichnen kann. - Nur so viel: Nach "COM3 at 9600 Baud: /" passiert 
nichts mehr (es stürzt aber auch nicht ab).

Gruß,
Marcel

[Thomas Ilnseher (Gast)]

Hallo Bootloader-Freaks,

Ich habe auch einen Bootloader gebraucht, aber nicht den hier verwendet, 
weil der nicht in c war, aber egal.

Das Problem bei bootloadern ist, dass ich erst über ISP den bootloader 
flashen muss, dann mittels bootloader mein Programm 'reinladen. Das ist 
natürlich für die Fertigung scheiße. Man kann jetzt natürlich den Flash 
per ISP auslesen, aber dann besteht das Problem, dass man bei zB 'nem 
can128 128 kB Flash programmieren muss, auch wenn das Hauptprogramm  nur 
ein paar kB hat (für die Fertigung auch nicht ideal).

Ich habe hier ein kleines Tool geschrieben, um den bootloader mit dem 
Hauptprogramm zu "linken" (mittels ihex).

Läuft zumindest unter Linux, aber ich habe eigentlich nur std. C 
verwendet.

Würde mich freuen, wenn jmd. der das brauchen kann, hier feedback gibt. 
Ich überlege im mom. noch, ob ich das ding auf google code schmeiße.

lg,

Tom

[NurEinGast (Gast)]

@Thomas Ilnseher

Danke. Kann ich gut brauchen.

Es gibt zwar schon ein paar Lösungsansätze mit Linbkerscript oder awk, 
aber es ist immer hilfreich eine ausführbares Programm zu haben, dass 
die Aufgabe mal schnell erledigt.

Andere Lösungsansätze - siehe

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=33291

[Sebastian (Gast)]

Hi,

ich versuche gerade den Bootloader auf einem Atmega324p zum laufen zu 
bekommen (müsste ja kompatibel sein zum Atmega32). Leider startet der 
Bootloader nicht (Er verbindedt sich nicht mit dem PC, es kommt nur der 
sich drehende Balken, Die Serielle Schnittstelle funktioniert mit der 
Applikation)
woran kann es liegen dass das Codesegment (.cseg) bei 0x0 anfängt ?
FIRSTBOOTSTART ist im m32def.inc als 0x3f00 deklariert.

[Michael H. (michael_h45)]

Du musst schon das include nehmen, das zu deinem Controller passt. Wenn 
der 324p Pin- UND Codecompatibel zum 32 wäre, wäre es der selbe Baustein 
=)

[Sebastian (Gast)]

Ok ich probiers mal aus. Allerdings ist es ja der Nachfolger und 
Pinkompatibel, gleiches RAM, Flash, Peripherie und dergleichen....

[Michael H. (michael_h45)]

Sebastian schrieb:
> gleiches RAM, Flash, Peripherie
Genau das ist falsch! Eben nicht die gleiche Peripherie! Und auch wenn 
die noch so gleich wäre, hieße das noch lange nicht, dass sie an den 
gleichen Adressen läge wie beim Vorgänger.
http://www.atmel.com/dyn/resources/prod_documents/doc8001.pdf

[Sebastian (Gast)]

Ok, vielleicht hab ichs doch nicht so im Detail verglichen. Trotzdem, 
hab das m324pdef.inc includiert. Gleiches Ergebnis...
Sonst noch ne Idee ?

[Uwe (de0508)]

make clean gemacht ?

zeige doch bitte auch deinen gesamten code und das Makefile.

[Sebastian (Gast)]

Hab jetzt mal das file fasload.inc angepasst:

.listmac
.list
  .org  0x3f00;0x0000
.if FlashEnd > 0xFFF
  jmp  init
.else
  rjmp  init
.endif
  ;.org  BootStart
init:
  cli
  ldi  a0, low (RamEnd)

Die Adresse stimmt jetzt (siehe bild) abeer es funktioniert nioch 
nicht...

[Sebastian (Gast)]

Ich bins wieder...

Der Bootloader scheint wohl zu anzulaufen. Allerdings springt er mir bei 
der Baudratenerkennung zum Timeoutlabel.. Hab schon die Maximale 
Wartezeit eingestellt. Woran kann das liegen ?

[Tueftler (Gast)]

Hallo werte Forumsmitglieder,

Seit kurzem benutze ich auch Peters grandiosen Bootloader! und ich bin 
begeistert!

Meistens klappt das auch ganz gut, ein Problem bleibt jedoch:
Da ich keinen Resetknopf habe, läuft das momentan bei mir so ab, dass 
ich auf Computerseite den Bootloader starte, dann die Stromzufuhr des 
MCs unterbreche und anschließend nach diesem Reset die Firmware 
geupdated wird.
Problem dabei:
Meist "Prellt" die Stromversorgung bein Einschalten, sprich der MC läuft 
an, Bootloader startet, dann sinkt die Spannung kurzzeitig zu weit ab 
und der Mikrocontroller kann nicht weider loaden. Wenn die 
Betriebsspannung wieder da ist, hat der Bootloader auf PC-Seite den 
Prozess abgebrochen und der Mikrocontroller kann kein Programm laden.
Daher nun meine Idee:
Bevor der MC den Bootloader startet, sollte er erst eine halbe Sekunde 
warten und gar nichts tun. sodass sich während dieser Zeit die 
Versorgung stabilisieren kann. Anschließend startet der Bootloader.
Mein Problem:
Habe noch nicht die passende Stelle gefunden, an der die Wartezeit in 
das Bootloaderprogramm eingefügt werden muss.
Mir fehlt leider etwas der Überblick über die einzelnen Dateien. Eine 
Wartezeit zu programmieren in ASM ist nicht das Problem, nur halt wo ich 
sie einfügen müsste. Es ist auch nicht weiter schlimm, wenn der 
Bootloader im Endeffekt größer als 512Byte ist, Flash habe ich im 
"Überfluss" übrig.

Vielleicht kann mir einer von euch helfen,
mit freundlichen Grüßen,
Tueftler

[Tueftler (Gast)]

push

[Sven K. (Gast)]

Hi,

hättest Du den Thread mal durchgelesen,
dann hättest Du folgendes entdecken können:

Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Dort habe ich eine Verzögerungszeit für den Bootloader getestet.

Gruß Sven

[Fred S. (sonnibs)]

Ich möchte fastboot verwenden, um einen ATmega2561 zu flashen. Als Host 
verwende ich einen PC mit WinXP. Mit fboot21.exe klappt auch alles 
bestens, aber das ich das Projekt auch mit anderen teile wollte ich auch 
eine GUI "anbieten".

Alle Versionen von "UpdateLoader___.exe", die ich hier finde, melden 
einen Prüfsummen-Fehler beim Laden der HEX-Datei.

Ich vermute, dass dies daran liegt, dass "Segment-Adressierung" im 
HEX-File für mehr als 64kByte Programmcode nicht korrekt erkannt wird.

Hat bereits jemand eine entsprechend verbesserte Version erstellt? Oder 
liege ich falsch?

Danke,

Fred

[Franz (Gast)]

devluz schrieb:
> Da die Windowsversion von fboot2.1 auf neueren Windowssystemen nicht
> lief, habe ich eine abgeänderte Version geschrieben. Bisher wurde sie
> nur unter Windows 7 64Bit + Atmega32 getestet! Gut möglich das ich ein
> paar features versehentlich entfernt hab ...^^
>
> Quellcode und Binäre version findet ihr unter folgender Adresse:
> http://derluz.de/fboot64

Läuft im Prinzip auch unter Win7 32 bit .. ABER .. bereits geöffnete 
Ports oder das Abziehen eines USB-UART (Silabs) führt zu BSOD oder 
sofortigem Stillstand.. Trotzdem danke für das Teilen

[Dietmar (Gast)]

Hallo

Ich verwende einen ATMEGA168A
der Bootloader läuft auf der CPU
ich kann auch das Hexfile laden aber das Programm startet nicht
was könnte ich da falsch gemacht haben ?

D:\AVR\FBOOT>fboot /kompass.hex /b9600 /c2
COM 2 at 9600 Baud: Connected
Bootloader V2.1
Target: 1E9406 ATmega168
Buffer: 512 Byte
Size available: 15872 Byte
CRC: o.k.
Elapsed time: 0.27 seconds

vielen Dank  & lg Dietmar

[Michael H. (michael_h45)]

Fuses falsch gesetzt?
BOOTSZ1 nicht gestzt, BOOTSZ0 gesetzt und BOOTRST gesetzt. Ergibt Boot 
size von 256 words und gesetzten Bootloader-Resetvektor.

[Dietmar (Gast)]

Hallo Michael

vielen Dank für die rasche Antwort
Fuse bits habe ich richtig gesetzt hab beim hex file den Parameter /P
vergessen und dann ladet das fboot kein file. Hab mich schon gewundert
dass das File in "Elapsed time: 0.27 seconds" fertig war.
Jetzt bekomme ich einen CRC Fehler.

D:\AVR\FBOOT>fboot /C2 /B1200 /Pkompass.hex
COM 2 at 1200 Baud: Connected
Bootloader V2.1
Target: 1E9406 ATmega168
Buffer: 512 Byte
Size available: 15872 Byte
CRC-Error

[Guri (Gast)]

Wer den Bootloader direkt an RS-232 betreiben möchte (2-wire), sollte 
neben der Invertierung der Pins auch an die Initialisierung denken 
(sonst gibt es für die 300 ms Wartezeit ein High auf TX). Ganz unten in 
FASTLOAD.H.
Serienwiderstände 4.7 reichen aus (eigentlich nur bei RX erforderlich), 
ein Pull-Up ist m.W. nicht notwendig. Für meinen USB<->RS-232-Wandler 
brauche ich etwa 4 V Versorgungsspannung, damit er die Daten erkennt 
(noname mit PL-23xx IC).

[Leo H. (Gast)]

Hallo,

heute ist eine aktualisierte Version vom UpdateLoader fertig geworden!
Screenshot & mehr Infos: 
http://www.leo-andres.de/2012/09/updateloader-benutzeroberflache-fur-avr-bootloader/

Das Programm wurde mit Lazarus bzw. Free Pascal erstellt. Getestet habe 
ich es unter Windows 7 32- und 64-Bit. Auf beiden System läuft es 
problemlos, Administrator-Rechte werden auch nicht mehr benötigt.
Über einen FT232 lassen sich damit 12kB Flash in ca. 10 Sekunden 
programmieren und überprüfen.

Beim ersten Compilieren mit Lazarus muss eventuell der Pfad zur 
SynaSer-Bibliothek angepasst werden.

[Hendrik L. (lbd)]

Franz schrieb:
> devluz schrieb:
>> Da die Windowsversion von fboot2.1 auf neueren Windowssystemen nicht
>> lief, habe ich eine abgeänderte Version geschrieben. Bisher wurde sie
>> nur unter Windows 7 64Bit + Atmega32 getestet! Gut möglich das ich ein
>> paar features versehentlich entfernt hab ...^^
>>
>> Quellcode und Binäre version findet ihr unter folgender Adresse:
>> http://derluz.de/fboot64
>
> Läuft im Prinzip auch unter Win7 32 bit .. ABER .. bereits geöffnete
> Ports oder das Abziehen eines USB-UART (Silabs) führt zu BSOD oder
> sofortigem Stillstand.. Trotzdem danke für das Teilen

Hallo zusammen, hallo lieber Peter Danneger,

ich bin ziemlich verzweifelt, habe (leider) einen 64 bit Rechner kaufen 
müssen, wo natürlich FBOOT (32bit) nicht mehr läuft ...!

Habe darauf meine Hoffnungen auf diese URL http://derluz.de/fboot64 
gesetzt

Arbeitet aber nicht mit MEGA 2561 zusammen - es sei denn jemand hat hier 
andere Erfahrungen gemacht ?!

Verzweifelt arbeite ich momentan mit einer 32 bit DosBox Emulation - 
aber das ist ein totaler Krampf.

@Peter Danneger: Sicherlich ist es ein Anliegen von vielen, wenn Du Dein 
Orginal FBOOT auch für windows 64 Rechner bereitstellen würdests - 
bitte!

Vielen Dank!

[Hendrik L. (lbd)]

Franz schrieb:
> devluz schrieb:
>> Da die Windowsversion von fboot2.1 auf neueren Windowssystemen nicht
>> lief, habe ich eine abgeänderte Version geschrieben. Bisher wurde sie
>> nur unter Windows 7 64Bit + Atmega32 getestet! Gut möglich das ich ein
>> paar features versehentlich entfernt hab ...^^
>>
>> Quellcode und Binäre version findet ihr unter folgender Adresse:
>> http://derluz.de/fboot64
>
> Läuft im Prinzip auch unter Win7 32 bit .. ABER .. bereits geöffnete
> Ports oder das Abziehen eines USB-UART (Silabs) führt zu BSOD oder
> sofortigem Stillstand.. Trotzdem danke für das Teilen

Hallo zusammen, hallo lieber Peter Danneger,

ich bin ziemlich verzweifelt, habe (leider) einen 64 bit Rechner kaufen 
müssen, wo natürlich FBOOT (32bit) nicht mehr läuft ...!

Habe darauf meine Hoffnungen auf diese URL http://derluz.de/fboot64 
gesetzt

Arbeitet aber nicht mit MEGA 2561 zusammen - es sei denn jemand hat hier 
andere Erfahrungen gemacht ?!

Verzweifelt arbeite ich momentan mit einer 32 bit DosBox Emulation - 
aber das ist ein totaler Krampf.

@Peter Danneger: Sicherlich ist es ein Anliegen von vielen, wenn Du Dein 
Orginal FBOOT auch für windows 64 Rechner bereitstellen würdests - 
bitte!

Vielen Dank!

[Hendrik L. (lbd)]

*** Kleiner Reminder ***

[N2 (Gast)]

Hi,

Ich brauche mal Hilfe bei dem Bootloader...

Mein Setup:
* ATTiny2313 (int. 8Mhz / CLKDIV8 aktiviert) im STK500
* Bootloader V2.1 default bis auf XTAL auf 1MHz angepasst
* STK500 RS232 Spare über FTDI-Dongle am Win7 x64 PC
* PD0 und PD1 an RS232 Spare Pins (hab verdreht / nicht verdreht 
getestet)
* fboot64

Bootloader kompiliert und mit AVR Studio auf den Tiny geflashed.

Wenn ich nun "fboot63 /c3 /pbootest.hex" eingebe, dreht sich halt nur 
das "Rad" (|/\-)...
Egal ob ich RESET drücke, erst fboot starte oder wie rum auch immer...

Der FTDI-Dongle blinkt fleissig auf der TX zum Tiny..RX nischt.

Mit dem Scope PD0 und PD1 ohne RS232 angeschaut...gehen beide auf High, 
einer treibt der andere ist wohl PullUp/Input. In den Code kommt er scho
n mal.

Jemand ne Idee ?

Gruß N2

[Hendrik L. (lbd)]

Hallo N2,

 Du meinst fboot64 - oder ?

fboot64 funzt bei mir auch nicht - beim ATMega2561. Ich denke, der 
Source Code ist wohl nicht mehr Orginal - der Author gibt ja selbst an, 
dass er nicht sicher ist, dass die Änderungen erfolgreich sind.

Gruß

[N2 (Gast)]

Alles zurück...

ich habs jetzt mit 8MHz versucht und es geht....

Gruß N2

[Malte P. (maltep87)]

Hendrik L. schrieb:
> FBOOT auch für windows 64 Rechner [...]

Also ich verwende die DEV-CPP Variante erfolgreich auf 32 und 64 bit 
Windows Systemen mit dem 2.1er Bootloader.
(Beitrag "Re: UART Bootloader ATtiny13 - ATmega644")

Hab die .exe mal mit angehangen, hoffe das hilft weiter. Sourcecode 
siehe Link. ;-)

[Hendrik L. (lbd)]

Malte Pöggel schrieb:
> Hendrik L. schrieb:
>> FBOOT auch für windows 64 Rechner [...]
>
> Also ich verwende die DEV-CPP Variante erfolgreich auf 32 und 64 bit
> Windows Systemen mit dem 2.1er Bootloader.
> (Beitrag "Re: UART Bootloader ATtiny13 - ATmega644")
>
> Hab die .exe mal mit angehangen, hoffe das hilft weiter. Sourcecode
> siehe Link. ;-)

Hallo Malte,

Spitze - werde ich morgen sofort austesten! Vielen Dank

Gruß vom Hendrik

[Michael H. (michael_h45)]

Wäre übrigens auch im Artikel gestanden...

[Hendrik L. (lbd)]

Hallo Michael,

MEIN Problem ist:

Kenne mich in der windows Welt was COM-Schnittstellen angeht nicht gut 
aus. So ist mir auch nicht klar, wann ein 32 bit Programm noch unter 64 
bit funzt und wann nicht mehr. Dass COM Schnittstellen besonders 
sensibel sind, kann ich mir vorstellen ...!

Insofern dachte ich mir, fboot64 ist (von Namen her) die Lösung ...!

Irgendwann gibt man auf - schliesslich ist diese BootLoader Geschichte 
nicht mein Primärinteresse, sondern nur das Hilfsmittel. Um zielsicher 
zur Lösung zu kommen ist dieser Thread ein wenig lang geraten ...!

Ansonsten hast Du sicher Recht - aber es ist wie so oft, wenn man etwas 
weiß, ist es ganz einfach und logisch, wenn nicht, ist man häufig 
verloren ...!

Danke!

[Michael H. (michael_h45)]

Moment, moment! Ich rede von diesem Artikel hier: [[AVR Bootloader 
FastBoot von Peter Dannegger#Downloads]]

[Hendrik L. (lbd)]

Sorry, Michael, aber genau dort steht nix von windows7 64bit!

Da habe ich zuerst geschaut. Wie gesagt - ich habe gar nicht daran 
gedacht, dass fboot nur unter 32 bit in der Dos Box läuft. Und jetzt war 
das Problem für mich, wo bekomme ich ein Executable fboot für 64 bit her 
...!

Gruß Hendrik

[Michael H. (michael_h45)]

Links 7, 8, 9 und das python Implement laufen doch unter 64 bit 
Systemen.

[Hendrik L. (lbd)]

Michael H. schrieb:
> Links 7, 8, 9 und das python Implement laufen doch unter 64 bit
> Systemen.

Hallo Michael - jetzt sind wir beim Kern:

Link 7 hat definitiv nicht gefunzt (Asus Zen Ultrabook, windows 7 - 64)! 
Von einem Freundzusätzlich verifiziert, dass sie nicht funzt. Der Author 
weist selbst auf den Umstand hin. Daher meine ursprüngliche Anfrage!

Link 8 un 9 habe ich wohl übersehen - vielen Dank für den Hinweis, werde 
ich nun testen!

Python (als Umgebung) wollte ich mir eigentlich nicht erst auf den 
Rechner installieren ...!

Zu den ganzen Modifikationen von Peter Danneger's Original Bootloader:

Grundsätzlich finde ich es toll- wenn ich die Chance bekomme, davon zu 
profitieren.

Am liebsten greife ich aber IMMER auf Original Software von Peter zurück 
... die funktioniert in der ersten Version, die er veröffentlicht, immer 
schon fehlerfrei! Das ist so sicher wie das Amen in der Kirche!

Eine absolute Seltenheit in der heutigen Zeit! Noch einmal vielen Dank 
an Peter - auch an die anderen, die mir (hoffentlich) helfen konnten.

Gruß vom Hendrik.

[Mebus I. (mebus)]

Hallo,

könnte man den Quellcode des Bootloaders bei

http://github.com

veröffentlichen? Das würde es etwas einfacher machen, weil man nicht 
immer diesen langen Thread durchforsten müsste und sich Updates leicht 
herunterladen könnte.

Danke

Gruß

Mebus

[Michael H. (michael_h45)]

...
AVR Bootloader FastBoot von Peter Dannegger: Downloads

[Bernhard M. (boregard)]

Hallo,

der Sourcecode meiner Linux Host-SW ist jetzt in GitHub unter 
https://github.com/Boregard/FBoot-Linux zu finden.

Veränderungen gegenüber der zuletzt veröffentlichen Version sind:
- es wird das Abziehen eines USB-serial converters vom USB Bus erkannt
- DTR zum Reset wird getoggelt, bis ein Reset erfolgt

Gruß,
Bernhard

[Jürgen (Gast)]

Hallo zusammen,

ich sammele meine ersten Erfahrungen mit Peters Bootloader. Er läuft im 
2-Draht-Mode auf einem ATTiny85. Allerdings muss meine Applikation 
sofort nach dem Start als I2C-Slave kommunizieren und kann somit die 
Wartezeit des Bootloaders nicht gebrauchen. Als Lösung möchte ich den 
Bootloader nur Starten wenn beim Einschalten ein Eingang des ATTiny auf 
Low gelegt wurde.

Hat das evtl. schon mal jemand gemacht? (Dann muss ich mich nicht selbst 
durch den Code wühlen ;-)    )

Vorab Danke für eure Antworten.

Gruß
Jürgen

[Michael H. (michael_h45)]

Jürgen schrieb:
> Allerdings muss meine Applikation
> sofort nach dem Start als I2C-Slave kommunizieren und kann somit die
> Wartezeit des Bootloaders nicht gebrauchen.
Klingt nicht nach einem sinnvollen Gesamtkonzept...

[Jürgen (Gast)]

Hallo Michael,

Michael H. schrieb:
> Klingt nicht nach einem sinnvollen Gesamtkonzept...

Warum, im Normalbetrieb soll der ATTiny sein Programm sofort abarbeiten, 
zum Flashen wird die Schaltung standalone verwendet und die I2C 
Schnittstelle (Versorgung + CLK + Data) als TTL Seriell verwendet, wobei 
dies nur bei einem Low-Pegel auf einem IO-PIN starten soll?!

Gruß
Jürgen

[B. G. (smarti)]

Hallo Zusammen,

für eine kleine Anwendung habe ich mir einen ATTiny45 ausgesucht. Um 
diesen auch später noch Programmieren zu können möchte ich einen 
Bootloader drauf haben. Da hat mir der Bootloader von gut gefallen.

Leider bekomme ich ihn nicht zum laufen:

- Also Assemblieren mit AVR Studio 4, ok.
- Fuses mit AVRISP mkII (SELFPRGEN checked, BODLEVEL 2,7V checked, CKDIV 
disabeld, SUT_CKSEL default)
- 2-Wire auf: PB3 und PB4.

- VCC ist 3,1V
- Serielles Kabel USB - 3,3V

Ich habe den V1.4 und V2.1 getestet. Scheint eig. alles ok zu sein. Aber 
FBoot wartet und kann keine Verbindung aufbauen.

Gibt es eine möglichkeit über ein z.B. Terminal Prog. zu testen?

Ich hab mir den Artikel zum Bootloader zu Gemüte geführt, aber ich komme 
einfach nicht mehr weiter: 
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger

Über Ideen wäre ich echt Dankbar...

[Steffen H. (stef_fen)]

Wo kann man denn die aktuelle Version V2.1 downloaden?

Gruß Steffen

[Michael H. (michael_h45)]

hier.

[Steffen H. (stef_fen)]

Leider kommt bei dem hier nichts.

Gruß Steffen

[B. G. (smarti)]

Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

[Der K. (der_k)]

Hi,
ich wollte den Bootloader für mein mega2560 compilieren und bekomme 
diese Fehlermeldungen (Anhang).
Kann mir da vielleicht jemand weiterhelfen? Wäre toll, wenn ich das für 
mein Projekt benutzen könnte

Mfg Kai

[SE (Gast)]

Hallo,

ich hatte ähnliche Fehlermeldungen.
Bei mir war urplötzlich die include Datei von Atmel nur noch 1/3 der 
ursprünglichen Dateigröße groß.

Probier mal, alle Originaldateien inkl. der Atmel Include Datei über die 
aktuelle drüber zu kopieren. (Alle bis auf das Makefile)

Gruß! se

[Der K. (der_k)]

Ich habe es gerade mal mit den Standard PORTD für die UART Verbindung 
probiert. Da funktioniert alles. Da ich jedoch den zweiten UART vom 2560 
verwende, also PORTH, habe ich diese Fehlermeldungen nach dem Ändern in 
der BOOTLOAD.ASM.
Eine Idee wie ich das Problem beheben kann?

Danke schon mal für die Antwort davor!

[SE (Gast)]

Der K. schrieb:
> [...] nach dem Ändern in
> der BOOTLOAD.ASM.

Änderungen musst du nur in dem Makefile machen.
Dort nur die Ports und Pins ändern.

Das klappt auch beim 2560. Hab da zufällig vergessen die Pins zu ändern 
und hatte den Bootloader auf auf dem falschen Port.

[Der K. (der_k)]

Super! Hat funktioniert :)
Nur eine Frage noch..
Wie muss ich die Fuses und die Lock Bits einstellen, damit der 
Bootloader erhalten bleibt?
Bei mir hat es nur einmal funktioniert und nachdem das Programm 
aufgespielt wurde konnte ich nach einem Reset den Bootloader nicht mehr 
starten.
Ich benutze ARVStudio um die Einstellungen vorzunehmen und habe auch die 
bootloader.hex so aufgespielt.
Konnte mit avrdude keine Verbindung herstellen mit meinem mkii.

Vielen Dank noch einmal!

[Der K. (der_k)]

Beantworte mich mal selber.
Mit den Einstellungen aus dem Bild hat es geklappt. Das wären dann die 
Fuses Einstellungen über AVR Studio, damit man AVRDude komplett umgehen 
kann. Vielleicht interessant für den ein oder anderen.

Ein Problem habe ich jedoch noch.
Sobald ich den PORTH PH1 und PH0 in der BOOTLOAD.ASM eintrage kommen die 
Fehlermeldungen aus der Textdatei im Anhang.
Ich verwende bei meinem Layout die UART2 und würde das so auch gern 
beibehalten. Kann mir jemand dabei helfen, was ich zu tun habe?

[Bastian S. (bastl)]

Nabend zusammen,

Habe leider ein kleines Problem beim assemblieren.

error: invalid redefinition of 'BOOTSTART'

Versuche das ganze für einen Mega32 zu assemblieren und habe mich an 
diese Anleitung gehalten: 
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger

Evtl. weis ja jemand was ich falsch mache.
Die includes habe ich direkt aus der AVR 000 Appnote

Grüße Basti

[Steffen H. (stef_fen)]

Hallo Zusammen,

zum Bootloader gibt es ja noch das Gegenstück für den PC (Fboot). 
Funktioniert das Programm auch unter Windows 7 64Bit? Irgendwie bekomme 
ich da eine Fehlermeldung. Gibt es noch eine andere Möglichkeit?

Vielen Dank. Gruß Steffen

[SE (Gast)]

Steffen Ha schrieb:
> Funktioniert das Programm auch unter Windows 7 64Bit?

Ja!
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Hab das nun schon auf mehreren Rechnern eingesetzt.
Der rebuild unterstützt aber auch nur COM1 bis COM4 am PC.
Aber die 8.3 Dateilänge ist aufgehoben.

[Sebastian E. (s-engel)]

Hallo,

ich nutze PeDas Fastboot auf einem Arduino Mega 2560 und einem Arduino 
Nano.

Um bequemer mit fboot.exe zu flashen, habe ich mir eine GUI in C# 
gebastelt, welche fboot.exe mit den entsprechenden Parametern aufruft.
Zusätzlich ist noch ein miniterminal für ASCII Zeichen eingebaut.

Das kleine Programm ist bei mir nebenher entstanden und es ist noch als 
Beta anzusehen.
Aber villeicht kann es noch jemand brauchen ;-)

Um das Programm nutzen zu können, muss die fboot.exe im gleichen 
verzeichnis liegen, wie die fboot_gui.exe.
Compiliert ist die Anwendung für .NET 3.5.

[Uwe (de0508)]

Hallo Sebastian,

super, danke.

Bitte hänge noch fboot.exe an.

[Sebastian E. (s-engel)]

Da kann die Originale von PaDa genutzt werden oder die von Sascha:
Fboot21-Dev-Cpp.zip ( Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" 
)

Angehängt habe ich die aus dem ZIP-File von Sascha.

[Dirk R. (mdiri)]

Hallo Peter,

Ich setze deinen Bootloader in verschieden Atmegas erfolgreich ein. Dein 
Bootloader finde ich einfach genial. Mein neues Projekt enthält den 
Atmega 1284p....nun wollte ich das hexfile erzeugen (m1284Pdef) vorher 
eingebunden...und bekam ein error "FATAL ERROR: Too deeply nested macro 
calls(16)". Dann wieder ins Forum um nachzulesen aber igendwie bekomme 
ich keine richtige Antwort. Kann ich vielleicht auch den 1281er nehmen, 
der hat den gleichen Speicher. Kann mir jemand helfen oder hat mir einer 
eine Idee.Ich würde gerne bei dem Bootloader bleiben.

Gruß Dirk

[Conny G. (conny_g)]

Hallo Peter,

ich denke darüber nach, ob ich den Bootloader für entfernte Schaltungen 
einsetzen kann, die per Funk (868 Mhz RFM12) angebunden sind.
Muss die bisher immer einsammeln und updaten oder zu den Schaltungen 
hingehen. Kein supergrosses Problem, aber natürlich nervig.

Hätte dazu folgenden Aufbau im Kopf:
diese Schaltungen haben einen extra Flash-Speicher der ausreicht das 
Image aufzunehmen. Ich schicke in kleinen Datenpaketen à ... 20-30 
Bytes? ... das HEX mit CRC und allem drum und dran, Pakete werden 
wiederholt, wenn nicht bestätigt oder CRC falsch.
Die "Satellitenschaltung" (die entfernte per Funk angebundene) speichert 
die Pakete im Flash.
Nach Übertragung des HEX resettet sich der AVR selbst (Watchdog) und der 
Bootloader holt sich das HEX vom Flash.
Wahrscheinlich bräuchte es noch einen AVR, der dem Bootloader die Daten 
beim Boot per SPI zuspielt, wenn im Flash welche vorhanden sind? Der 
würde dann loslegen

Könnte das so klappen? Müsste man den Boadloader dazu stark 
modifizieren?
Hab den Eindruck, das spielt sich dann wenn eine AVR/Flash-Kombi dem zu 
flashenden AVR die Daten per SPI geben, nur in der Funkempfangsroutine 
ab (Flash füllen) und bei dem separaten AVR mit seinem Flash - d.h. dann 
wäre der Bootloader gar nicht betroffen?

(Bevor mich jemand darauf hinweist:
Das wäre zwar nicht ganz korrekt in Bezug auf die Regeln des 868 
Mhz-Bereichs, aber das Update fände ja höchstens alle paar Tage statt.)

Vg,
Konrad

[Conny G. (conny_g)]

Ist der Thread noch aktiv?
Peter noch da?
:-)

[Bernd O. (bitshifter)]

Hallo Konrad,

warum so kompliziert mit externem SPI-Flash und/oder zweitem Atmel? Du 
wirst so oder so nicht darum herumkommen, tief in den Bootloader und 
Assembler einzusteigen - und dann kannst Du es auch gleich "richtig" 
machen:

Such' Dir einen Atmega, der ca. doppelt so viel Flash hat wie Du für 
Dein Programm (== ein "Image") brauchst und modifiziere den Bootloader 
(sofern er weiterhin nötig ist) und Dein Programm so, dass Du den 
Funk-Download immer auf das jeweils andere "Image" schreibst, das gerade 
nicht aktiv ist. So kannst Du in aller Ruhe warten bis das Image 
geschrieben und verfiziert ist (und wenn es Tage dauert...). Und wenn 
dann alles passt, aktivierst Du das zweite Image, führst einen Reset aus 
und startest so das neue Image.

Das geht auch ganz ohne Bootloader. Du brauchst nur ein zentrales 
Stückchen Code, das bewertet welches Image komplett und neuer ist und 
das dann nach dem Reset startet. Du kannst Dir auch noch weitere 
Sicherheitsmechanismen überlegen wie z.B. dass die neue Anwendung den 
erfolgreichen Start ebenfalls im Flash dokumentieren muß. Wenn sie das 
nicht tut wird nach dem x. Reset ohne positive Quittierung wieder der 
"alte" Code gestartet und Du hast die Chance auf einen neuen Download 
(ohne ISP-Schnittstelle ;-).

Nicht ganz einfach, aber in Summe vermutlich doch einfacher als das 
Zusammenspiel von externem Flash und zweitem Controller mit 
modifiziertem Bootloader.

Bei diesen ganzen "Umschaltereien" solltest Du Dir die Eigenschaften des 
Flash zu Nutze machen, dass man meist problemlos einzelne Bits löschen 
kann ohne gleich eine ganze Page schreiben zu müssen. Quasi wie bei 
einer Mehrfahrtenkarte immer neue Löcher zu stanzen. Alternativ gibt's 
ja auch noch den EEPROM, den man für das Umschalten nutzen könnte (würde 
ich aber erst mal vermeiden wenn möglich).

Gruß,
Bernd

[peterle (Gast)]

Guten Abend,
habe gerade die Gui aus dem Beitrag 
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" probiert aber leider 
funktioniert die nicht.
Kann es daran liegen das mein PC 64Bit hat.
Vielen Dank

Peter

[Michael H. (michael_h45)]

nein.
versuchs mal mit "als adminstrator ausführen".

[peterle (Gast)]

Ich Habe einen Screnprint mit dem Fehler gemacht!
Danke für Eure Hilfe
Peter

[Chris R. (hownottobeseen)]

Hi,

die Meldung in Visual Studio zeigt dir schon ziemlich genau das Problem.

Dein Event kommt in einem anderen Thread als deine GUI ist. Damit das 
Setzen des Textes threadübergreifend geht, musst du einen Invoke machen.

Auf http://stackoverflow.com/questions/14703698/c-invokedelegate ist in 
der obersten Lösung (die mit dem Häkchen) ein relativ eleganter Weg 
aufgezeigt, wie man das behandeln kann.

Warum das das .NET-Framework nicht von sich aus macht - frag mich bitte 
nicht, hab mich damit auch schon genug herumgeärgert...

Schönen Sonntag,

Chris

[Michael H. (michael_h45)]

in dem link von oben ist ein build drin. du musst es nicht selber 
compilieren.

[peterle (Gast)]

Chris R. schrieb:
> Auf http://stackoverflow.com/questions/14703698/c-invokedelegate ist in
> der obersten Lösung (die mit dem Häkchen) ein relativ eleganter Weg
> aufgezeigt, wie man das behandeln kann.

Also ich bin kein Pc Programmierer aber ich werde es mir ansehen!
Vielen Dank



Michael H. schrieb:
> in dem link von oben ist ein build drin. du musst es nicht selber
> compilieren.
Ich hoffe das der Angehängte Quelltext der selbe vom Build ist!
Werde es trotzdem mit dem Build versuchen.

Danke

peter

[peterle (Gast)]

Noch eine Frage warum habe nur ich diese Problem?

Peter

[Michael H. (michael_h45)]

peterle schrieb:
> Noch eine Frage warum habe nur ich diese Problem?
weil du eine andere build-umgebung (compiler-version, framework-version, 
etc) als der autor hast.

geht denn das binary?

[peterle (Gast)]

Michael H. schrieb:
>> Noch eine Frage warum habe nur ich diese Problem?
> weil du eine andere build-umgebung (compiler-version, framework-version,
> etc) als der autor hast.
>
> geht denn das binary?

Nein das Build funktioniert auch nicht!
Das Programm macht nichts (keine Fehlermeldung).
Ich habe das Build mit dem Datum 06.04.2008 ausprobiert.

Leider komme ich mit der Fehlermeldung oben "INVOKE" auch nicht weiter.
Ich habe mit C# noch nie gearbeitet.

Wäre nett wenn mir jemand helfen könnte

LG

Peter

[peterle (Gast)]

Nachtrag mit dem Kommandozeilenprogramm auf einem XP Rechner 
funktioniert der Bootloader.
Also sollte der Bootloader auf dem Atmel richtig erstellt sein.

Peter

[Michael H. (michael_h45)]

peterle schrieb:
> Nein das Build funktioniert auch nicht!
> Ich habe das Build mit dem Datum 06.04.2008 ausprobiert.
dito - 6.4.08 01:42 uhr. funktioniert hier tadellos.
bei mir ist allerdings der ganze uac-kram aus. als administrator 
ausgeführt?

[peterle (Gast)]

Ich habe den Build auch mit Admin Rechten ausgeführt!

Währe super
wenn mir jemand den Fehler mit "invoke"fixen könnte!

Vielen Dank für Eure Hilfe!

[Steffen H. (stef_fen)]

Hallo Zusammen,

ich würde gerne den Bootloader auf einem Atmega2560 nutzen. Dabei sollen 
die UART Pins PJ0 und PJ1 (UART3) genutzt werden. Beim compilieren 
bekomme ich jedoch 13 Fehlermeldungen mit "Operand out of range". Was 
kann ich dagegen tun? Wenn ich jedoch PE0 und PE1 (UART1) nehme und dann 
compiliere treten keine Fehler auf. Welche Bootsize muss ich bei dem 
2560 einstellen?

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
;      set both lines equal for inverted onewire mode:

.equ    STX_PORT        = PORTJ
.equ    STX             = PJ1

.equ    SRX_PORT        = PORTJ
.equ    SRX             = PJ0
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

Vielen Dank.
Gruß Steffen

[Michael (Gast)]

Hallo Steffen,

ich hatte auch dieses Problem. Beim Zugriff auf den genannten PORTJ 
können nicht mehr die von Peter verwendeten Zugriffe auf die 
"I/O-Register im Bereich 0x00-0x1F" verwendet werden. Ersetzt man diese 
durch "Dataspace"-Zugriffe, verändert man u.a. das Timing und die 
automatische Baudratenerkennung schlägt fehl.

Bei mir läuft z.Z. der anghängte "patch". Ich habe weitestgehend alles 
wie beim Peter gelassen. Bei Zugriffen auf Portregister über $1F 
schaltet sich alles auf Dataspace-Adressierung um.

Einige Sachen, wie z.B. die "Korrektur für das USB-Dongle" konnte ich 
aber nicht richtig nachvollziehen - vielleicht klappen daher nicht alle 
Takt-Baudrate-Kombinationen?

Wenn Tips kommen und ich Zeit habe, kann ich ja noch mal drüberschauen.

Gruß
Michael

[Michael H. (hoffm)]

So, das Timing wurde besser angepaßt: uC mit 16 und 22 bit PC (bei mehr 
als 128 Byte ROM) bekommen jetzt jeweils ihre eigene Korrektur; die 
Baudraten halten sich im Praxistest sehr eng an die Theoriewerte; der 
"onewire mode" funktioniert aber noch nicht.

[Andreas (Gast)]

Hallo

Ich hoffe der Thread lebt noch und jemand kann mir helfen.
Ich nutze den Mega8 und habe den Bootloader 2.1 geflasht.
Zum testen habe ich direkt an die COM Schnittstelle des PC den Atmel 
gehangen.
Ich kann jetzt problemlos die hex Files mit dem Bootloader programieren.
Mit Baudraten von > 2400 Baud.
Wenn ich jetzt den PC und den Atmel mit 2 ZigBee Modulen verbinde 
(Telegesis ETRX3) und in den Datamode gehe (direkte Verbindung zwischen 
zwei Modulen)
bekomme ich beim starten des uploaders nur die Meldung


C:\fboot21\FBOOT>fboot /Pmain.hex /b19200 /c3
COM 3 at 19200 Baud: Connected (One wire)
Bootloader VFFFFFFFF.FF
Error, wrong device informations

Tippe ich zum testen einfach ein par Zeichen in ein Terminal, sehe ich 
wie die Zeichen auch auf der Gegenseite ankommen.

Hat da jemand eine Idee?

[Michael H. (hoffm)]

Hallo Andreas,

Michael schrieb:
> Ich habe weitestgehend alles wie beim Peter gelassen. Bei
> Zugriffen auf Portregister über $1F schaltet sich alles auf
> Dataspace-Adressierung um.

... und bei Zugriffen unter $1F sollte alles wie beim Peter laufen - tut 
es aber nicht. Ich hatte hier noch nicht die ansonsten nur bei der neuen
Routine benötigten "Trampolinsprünge" wieder entfernt. Deshalb ist meine 
Version bei den "kleinen" Prozessoren um zwei Instruktionen größer als 
Peters.

Das reicht wahrscheinlich noch nicht aus, um beim ATMega8 die 
beschriebenen Probleme zu verursachen, aber ich nutze die Gelegenheit, 
die Fehlersuche zu vereinfachen: Hier kommt die Version P03.

Gruß
Michael

[Yves (Gast)]

Hallo zusammen,

ich nutze die fboot21 und kriege Ihn auf einem Mega644PA einfach nicht 
zum laufen.

Um den 644PA zu unterstützen habe ich die m644PAdef.inc inkludiert.

In der Fastboot.h habe ich folgendes eingestellt, da ich einen 16Mhz 
Quarz am Mega habe.

 .equ  VERSION    = 0x0201

.equ  XTAL    = 16000000  ; 8MHz, not critical 
.equ  BootDelay  = XTAL / 3  ; 0.XXs

Ich habe als Pins folgendes eingestellt:

.equ    STX_PORT        = PORTD
.equ    STX             = PD1

.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0

Den Bootloader habe ich mit dem AVR-Studio auf den uC geladen. Scheint 
auch funktioniert zu haben. Dies habe ich verifiziert indem ich den 
Speicher ausgelesen habe und am Ende des Speichers erscheint der 
Assemblierte Code des Bootloaders.  Die HEX Datei ist 1442 Byte groß. 
Angehängt habe ich den ausgelesenen Speicher des Megas.

Die Fuses sind wie folgt eingestellt:

 Bootsz: 512
Bootrst: X

Habe auch nochmal ein Bild angehangen der ausgelesenen Fuses.

Da der Speicher des ATMegas sonst leer ist müsste er ja immer in den 
Bootloader laufen. Dennoch resette ich den uC sobald aufgefordert indem 
ich die Stromzufuhr trenne und wieder verbinde.

Die fboot.exe habe ich mit 9200 Baud auf COM4 aufgerufen. Jedoch dreht 
sich dort nur die "Uhr".

Als Hinweis noch: Die TX Led meines USB TTL-Wandlers blinkt, die RX Led 
bleibt jedoch dauerhaft an. (Blinken = Datentransfer)


Hat irgendjemand eine Idee was ich falsch gemacht habe oder wie ich es 
hinbekommen kann?

Danke und Gruß,
Yves

[Michael H. (michael_h45)]

rx und tx gekreuzt? nicht gekreuzt?

[Yves (Gast)]

Gekreuzt.... Also:
TTL RX - Mega TX
TTL TX - Mega RX

Habe es aber auch schonmal nicht gekreuzt probiert.... War mein erster 
verdacht

[Yves (Gast)]

Hat keiner weitere Ideen?

Gruß,
Yves

[Michael H. (hoffm)]

Hallo Yves,

der Thread ist wahrscheinlich für Deine Frage nicht der richtige. aber 
trotzdem mein Vorschlag:

Da PD0 und PD1 ja zur Hardware-USART des Controllers gehören, wäre es 
leicht, die Kommunikation mit dem PC zu testen. Klappt denn ein 
"Hallo-Welt" in Richtung PC? (Die avrlibc bietet sich an) Wenn ja, 
klappt der Empfang?

Gruß
Michael

[Yves (Gast)]

Hi Michael,

in welchen Thread gehören denn Fragen zum Bootloader von Peter? Dann 
kann ich es da ggf. auch noch einmal versuchen.

Ich werde es morgen nochmal mit dem Hallo-Welt versuchen aber ich habe 
schon eine stehende Verbindung zur UART1 gehabt.

Ich berichte morgen.

Gruß,
Yves

[Bernd O. (bitshifter)]

Hallo Yves,

hast Du schon mal verschiedene Baudrates ausprobiert. Ich erinnere mich, 
dass ich in der Vergangenheit Probleme mit einigen Baudates hatte - 
insbesondere die kleinen wie 9600. Mit höheren wie z.B. 115200 hat es 
dann klaglos funktioniert.

Keine Ahnung woran es letztlich lag, ob am Bootloader, an den billigen 
USB->Seriell-Adaptern (CP2102) oder etwas anderem - aber ich hatte 
definitiv Baudrates da hat es schlecht bis nie funktioniert (und es 
waren nicht die hohen was mich ja nicht so sehr gewundert hätte).

Gruß,
Bernd

[Yves (Gast)]

Hallo,

also die serielle Hello World verbindung funktioniert. Sende ich im ein 
"a" sendet er mir ein "b" zurück ^^

guter Hinweis Bernd. Ich habe meist extra mit kleinen Baudraten wie 9600 
gearbeitet weil ich auch einen "NoName" TTL-USB Adapter habe und dachte 
vielleicht hat er Probleme mit den schnellen Geschwindigkeiten. Werde es 
morgen mal mit einigen Baudraten testen.

Gruß,
Yves

[Tim . (cpldcpu)]

Dieser Thread macht mich etwas kirre - es gibt hier zig Versionen des 
Bootloaders, teilweise zerfleddert in Patches. Wo gibt es die aktuelle 
Version? Welche Varianten der Host-Software gibt es?

Auch die Wiki-Eintrage scheinen teilweise veraltet zu sein:
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger/Tutorial_ATtiny13

[Michael H. (hoffm)]

Hallo Tim,

es ist, nicht ganz ohne meine Schuld, etwas unübersichtlich geworden. 
Hier eine Übersicht:

* Peter Dannegger hatte mit dem "UART Bootloader ATtiny13 - ATmega644" 
angefangen. Seine letzte Version war

==> fboot21.zip.

* Einige wollten damit auch die größeren AVRs mit mehr Port-Pins 
flashen, z.B. den ATmega1280, was aber nicht funktionierte.

* Ich fand den Loader einfach genial, konnte ihn aber wegen dieser 
Einschränkung leider nicht durchwegs einsetzen. Weil ich das nicht 
akzeptieren wollte, hatte ich einen "Patch" geschrieben, der jetzt auch 
die "großen" Controller unterstützt:

==> fboot21-p01.zip

Die in [[Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"]] genannten 
Timing-Probleme sind mir auch schon häufig aufgefallen. Ich hatte zuerst 
den Loader in Verdacht und daher dessen Zeitverhalten optimiert:

==> fboot21-p02.zip

Auch Peter hatte damit schon angefangen, deshalb mußte ich nur ein paar 
seiner Konstanten besser abstimmen.

(Allerdings liegt das Problem bei der PC-Software: Peter benutzt noch 
die alten "inportb/outportb"-Befehle, um mit der Seriellen Schnittstelle 
zu kommunizieren. Das klappt gut unter DOS und alten Windows-Versionen. 
Bei mir gab es schon unter XP Probleme, unter Windows 7 64-bit klappte 
es gar nicht mehr. Ich habe eine alpha-Version geschrieben, die hierfür 
Win32/Win64 benutzt und sich unter dem freien Compiler-Paket "Dev-C++" 
übersetzen läßt. Aber von anderen gibt es schon fertige Lösungen ...)

Falls andere daran Interesse haben sollten, könnte ja mal ein Mod ein 
wenig aufräumen?

Gruß
Michael

[Jörg E. (jackfritt)]

Wenn man den Wiki Eintrag aktuell hält würden doch alle wichtigen
Info drin stehen und man müßte bei "normalen Fragen" nur darauf 
verlinken.
Mann könnte sogar noch eine FAQ dranhängen mit den größten Probleme 
hier...
Warum soll hier ein Mod Zeit investieren wo er vielleicht nichts über 
dieses Thema weiss?
Ich finde hier sind dann interessierte User gefragt.
So kenne ich das auch aus anderen Foren etc.

Gruss,

Jörg

[Tim . (cpldcpu)]

Hallo Michael,

vielen Dank für die Klarstellung. Ich habe fboot21 inzwischen zum laufen 
bekommen. Dass das Archiv ohne Readme und mit DOS Filenamen kommt war 
schon gewöhnungsbedürftig. Inzwischen läuft aber alles. Mit gefällt der 
Bootloader sehr gut.

Die Wiki-Artikel waren dabei sehr hilfreich. Allerdings sind sie auf 
einem sehr alten Stand.

[Frank H. (huene)]

Hallo,
ich versuche gerade fboot  auf der PC-Seite mit DEV-C++ zu kompilieren. 
Ich habe leider wenig Ahnung von C-Programmierung auf PC-Ebene. Ich lade 
die Datei fboot.dev in die Entwicklungsumgebung von Dev-C++.

Wenn ich das Projekt dann kompiliere bekomme immer Fehlermeldungen mit 
undefined reference to `_argv‘ und `_argc‘

Hat jemand eine Idee, was ich falsch mache? Ich vermute ich muss noch 
etwas an Optionen in der Entwicklungsumgebung einstellen. Versucht habe 
ich es mit den folgenden Quellen:
Fboot21-Dev-Cpp.zip von Sascha
fboot-win-devcpp-mod.zip von Malte Pöggel
pc_dev-cpp.zip von Matthias Larisch

Bevor ich mich mit dem Code auseinandersetze würde ich gern das 
bestehende Projekt erst einmal übersetzt bekommen.

Gruß
 Frank

[Matthias I. (matze5)]

Wie ist den das beim ATTiny 2213 kann da der Bootcode geschützt werden 
gegen Überflashen ? das geht doch nur beim ATMega oder ?

Grüße Matze

[Lars M. (lars_m65)]

Peters Schaltplan für 1-Draht-Betrieb ist funktioniert direkt mit einer 
Com Schnittstelle:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Ich habe das mal auf TTL-Pegel UART, z. B. für einen FTDI umgesetzt. Die 
Pegel sind invers zum oben genannten Schatplan. Der FTDI muss mit 
FT_Prog auf inverse Pegel für RX und TX eingestellt werden. Bei dem 
Widerstand sollten auch größere Werte funktionieren. Ich habe 
Atmegaseitig den Hardware-Seriel-TX-Pin genommen. Das bietet sich an, 
weil man darüber im eigentlichen Programm noch einen Debug-Output hat.

Kann man die Pegel evtl im Bootloader invertieren? Dann muss man nicht 
ständig den FTDI umprogrammieren.


Getestet habe ich das ganze erfolgreich mit einem Arduino pro mini 5V 16 
MHz (Atmega 328p) per UpdateLoader 2.2.4.

[Lars M. (lars_m65)]

Ich habe die Wikiseite nochmal komplett überarbeitet. Die alte Anleitung 
behandelte nur die Ursprüngliche Version von Peter Dannegger. Ich habe 
eine Anleitung zur AVR-GCC Version verfasst und Erklährungen zum 
One-Wire Modus und weiteren Flashmethoden ergänzt. Auch auf die 
Problematik mit dem get_avr_arch.sh Script bin ich eingegangen.

http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger

[rakete (Gast)]

Hallo,

bei mir ist das get_avr_arch.sh gebrochen mit avr-gcc (GCC) 4.7.2. Ich 
habe versucht ein Refactoring zu machen -- also es zu vereinfachen und 
weniger anfällig zu machen.
Leider konnte ich es nur mit obigen Compiler testen. Leider hat es den 
Anschein, dass die Compiler-Bauer immer an dem Interface rumspielen 
(zumindest was ich bisher in Erfahrung bringen konnte). Vielleicht kann 
einer es mit dem aktuellsten avr-gcc testen. Über Kritik und Anregungen 
freue ich mich natürlich.

Salute,
Alex

[Chris K. (christopher_k25)]

Malte Pöggel schrieb:
> Patch im Anhang, vielleicht kann sowas ja noch mal jemand gebrauchen.

Hi,
Entschuldigt wenn ich jetzt so blöd frage, aber...
Wie wende ich denn diesen Patch auf das Projekt an?

Chrissi

[Lars M. (lars_m65)]

Die brauchs du zum Assemblieren des Bootloaders. Wenn du make eingibst 
und das Script nicht zu deiner avr-gcc Version passt gibts einen Fehler. 
Also Script runterladen und vorhandenes Script aus 
(Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain") ersetzen.

Hier steht es genauer:
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger#Assemblieren_des_Bootloaders_.28Angepasste_Version_f.C3.BCr_AVR-GCC-Toolchain.29

Lars

[Michael (Gast)]

Hallo zusammen!
Ich würde den Bootloader von Peter gerne über RS485 benutzen und brauche 
dafür ein RTS Signal. Jetzt bin ich in Assembler nicht wirklich fit und 
muss raten :-)

In der uart.inc würde ich den code wie folgt ändern - siehe Zeilen 
"???":

putchar:
  sbi  RTS_PORT, TRS           ; set RTS pin ???
  rcall  wait_bit_time
  TXD_0
.if ONEWIRE
  rjmp  _tx2
syncputchar:        ; start with 1->0 from master
  SKIP_RXD_1
  rjmp  syncputchar
_tx1:
  SKIP_RXD_0
  rjmp  _tx1
_tx2:
.else
  lpm  a1, z      ;3
.endif
  ldi  a1, 9      ;1
  com  a0      ;1 = 5
_tx3:
.if CRC
  rjmp  pc+1      ;2
  rjmp  pc+1      ;2
.endif
  rcall  wait_bit_time    ;14 + tw
  lsr  a0      ;1
  brcc  _tx4      ;1/2
  nop        ;1
  TXD_0        ;2
  rjmp  _tx5      ;2
_tx4:
  TXD_1        ;2
  rjmp  _tx5      ;2
_tx5:
  dec  a1      ;1
  brne  _tx3      ;2 = 24 + tw
  cbi  RTS_PORT, TRS           ; clear RTS pin ???
  ret
;-------------------------------------------------------------------------
;  Wait 14 cycle + tw
;
wait_bit_time:
  movw  twh:twl, baudh:baudl  ;1
wait_time:
  sbiw  twh:twl, 4    ;2
  brcc  wait_time    ;2/1
  cpi  twl, 0xFD    ;1
  brcs  _wt1      ;2/1 (2)
  breq  _wt1      ;2/1 (3)
  cpi  twl, 0xFF    ;1
  breq  _wt1      ;2/1 (4/5)
_wt1:
  ret        ;4 + 3 (rcall) = 14
;-------------------------------------------------------------------------

Habe ich mit den Änderungen eine Chance? Seht ihr noch andere Probleme?

Danke,
Michael

[Michael H. (hoffm)]

Hallo Michael,

ohne es zu testen, ist es für mich nicht leicht zu durchschauen, aber 
ich vermute, dass das nicht funktioniert. Hast Du nur in der 
UART.INC-Datei diese beiden Einträge vorgenommen:

sbi  RTS_PORT, TRS           ; set RTS pin ???
cbi  RTS_PORT, TRS           ; clear RTS pin ???

Da sollte dann aber zuvor der RTS-Pin irgendwo auf Ausgang gesetzt 
worden sein. Dafür könnte z.B. in der Datei FASTLOAD.H das zweite Makro 
"IOPortInit" erweitert werden.

Zudem würde ich empfehlen, für das Setzen und Löschen dieses Pins ein 
eigenes Makro zu schreiben. Dein Ansatz wird bei den "kleinen" 
Prozessoren immer funktionieren, denn bei denen kann man AFAIK auf alle 
Pins mit sbi/cbi zugreifen, weil sie als "lower 32 I/O Registers" 
ausgelegt wurden.

Bei den "dicken" 100-Pin AVRs geht das nicht bei allen Pins; in die 
oberen Speicherbereiche müßte man mit "sts" ran. Schau mal bei der 
"fboot21-03.zip"-Version unter FASTLOAD.H bei den Makros für TXD_0/TXD_1 
nach: Falls die PORT-Adresse unter 1fh liegt, nehme ich sbi/cbi, 
ansonsten wie gezeigt.

Gruß
Michael

[Gerhard (Gast)]

Nach nun vielen Stunden Lesen und Suchen immer noch Chaos :-)

Habe den Bootlader schon bei vielen Sachen eingesetzt und funktioniert 
problemlos.

Das aktuelle Thema ist der 1wire-Modus und invertieren der Signale am 
TTL-Adapter. Mit Umprogrammieren der Rx/Tx-Polarität bei FTDI-Chip 
klappt es auch, aber das ist ziemlich lästig. Wie geht es ohne Änderung 
der Polarität?

In der Anwendung wird über die normale UART kommuniziert, auch als 1wire 
(Busleitung beidseitig an Rx, pullup nach Vcc, Tx über Dioden an den 
Bus, das funktioniert problemlos). Nun möchte ich auch über diese 
Leitung den Bootlader ansprechen können, ohne den FTDI jedesmal 
umprogrammieren zu müssen.
Der Pin wäre also PD0 (ATMega168)
.equ    STX_PORT        = PORTD
.equ    STX             = PD0

.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0
In der fastload.h (ohne Ahnung von Assembler)
.if ONEWIRE
  .macro  IOPortInit
  sbi  STX_PORT, SRX    ; weak pullup on
  cbi  STX_DDR, SRX    ; as input
  .endmacro
  .macro  TXD_0
  ;Original sbi
  cbi  STX_DDR, SRX    ; strong pullup = 0
  .endmacro
  .macro  TXD_1
  ;original cbi
  sbi  STX_DDR, SRX    ; weak pullup = 1
  .endmacro
  .macro  SKIP_RXD_0
  ;original sbis
  sbic    SRX_PIN, SRX    ; low = 1
  .endmacro
  .macro  SKIP_RXD_1
  ;original sbic
  sbiS  SRX_PIN, SRX    ; high = 0
  .endmacro

Funktioniert aber nicht :-(
Habe ich was vergessen?

[Basti (Gast)]

Für OneWire unter Windows habe ich Stunden und viele Versuche 
gebraucht...
Dafür habe ich das mal dokumentiert, damit es bei euch dann schneller 
geht:

https://sebastianfoerster86.wordpress.com/2016/05/22/attiny-atmega-uart-bootloader/

[Andy W. (gastandy)]

Hallo zusammen,

ich habe Peter´s Bootloader erfolgreich getestet - soweit alle fein.

Peter schrieb in einem älteren Beitrag, daß zur korrekten 
Baudraten-Erkennung im Passwort zwei aufeianderfolgende Pausenzeiten im 
Verhältnis 1:4 vorkommen müssen.

"Peda"  ist als ASCII codiert hex 50 65 64 61 also
01010000 01100101 01100100 0110001

An welcher Stelle trifft hier das Verhältnis 1:4 zu?
Desweiteren warnte er, daß die Folge 0x20, 0x80 nicht erlaubt wäre, da 
nur die halbe Baudrate erkannt würde. Hier gleiches Problem :-(
00100000 10000000
Wo steckt hier das Verhältnis 2:8, welches zur halben Baudrate führt?

Mein eigentliches Ziel war - in Remineszenz an Peters Bootloader - die 
Passworte entsprechend der Nummer des Busmoduls "Peda1", "Peda2" usw. zu 
vergeben. Da ich die Restriktionen aber gerne verstehen würde, meine 
Frage:

Wäre jemand so nett und könnte das kurz & verständlich erklären?
Ich stehe hier gerade echt auf dem Schlauch...

MFG
Andy

[Michael H. (hoffm)]

Hallo Andy,

die Antwort basiert auf Peters Erklärung aus seiner Assembler Datei 
"ABAUD.INC":

                      ____    __    __ __             ____
e.g. recognize 0x0D:      |__|  |__|  |  |__|__|__|__|
                          0  1  2  3     5           9
                                1*T               4*T
                     LEER  S "1  0  1  1" "0  0  0  0" STOP

S steht hier für START; 0x0D wäre "0000" "1101", aber RS-232 überträgt 
die Bits rückwärts.

Tatsächlich muss mit "1*T" die Länge eines einzigen Bits vorgegeben 
werden.

Gruß
Michael

[Andy W. (Gast)]

Hallo Michael,

Danke für die Erklärung, jetzt ist alles klar - die Sendereihenfolge der 
Bits war es :-)

Wenn ich den Code richtig verstehe, steht meinem Vorhaben Peda1, Peda2 
usw. für die einzelnen Module als Bootloaderpasswort zu verwenden, 
nichts im Wege.
Durch das "a" in Peda erfolgt die Erkennung der Baudrate, so dass die 
nachfolgende Zahl keinen Einfluss mehr haben sollte und das Passwort 
wird ja darauf als Ganzes abgefragt.

MFG
Andy

[Bernhard M. (boregard)]

Hi,

das 'a' zum erkennen braucht man nicht im Passwort zu haben.
Ich sende vom PC aus immer mit 0x0d, also carriage return vor dem 
Passwort, das geht nämlich auch zum erkennen.
Dann kann das Passwort beliebig sein...

Gruß,
Bernhard

[Andy W. (Gast)]

Hallo Bernhard,

Danke für das Feedback, da werde ich das mit den verschiedenen 
Passworten  umsetzen können - Prinzip verstanden :-)

MFG
Andy

[Karl M. (Gast)]

Meisterlampe schrieb:
> avrasm2 -fi bootload.asm

was ist denn das für ein Mist ?

Es gibt doch ein Makefile, dass alle Abhängigkeiten beachtet und den 
Bootloader sicher übersetzt !

[Frankl (Gast)]

Funktioniert das Upload Programm auch mit Fastload_V14 ?
Habe ich nur die Info mit 8Mhz kein Problem, funktioniert es auch mit 
>14 Mhz?

[H.Joachim S. (crazyhorse)]

Nachdem der bootloader eigentlich immer und überall funktioniert hat und 
ich den auch sehr oft einsetze - mit dem Tiny441 gehts nicht.
Blöderweise gibts schon keine "offizielle" tn441def.inc (nur noch den 
xml-Kram), aber ich denke ich habe die halbwegs richtig erstellt, werde 
das aber noch mal überprüfen.
Ich habs für PA2 im one-wire modus erstellt, aber keine Verbindung 
(Hardware/Com-Port definitiv i.O., selfprog fuse gesetzt).

Eh ich mich jetzt durchs Assemblerprogramm quäle: hat sich schon mal 
jemand damit befasst. Könnte es an der leicht veränderten Portstruktur 
mit dem PUE-Register liegen?

Angepasst habe ich folgendes:

; ***** DATA MEMORY DECLARATIONS 
*****************************************
.equ  FLASHEND  = 0x07ff  ; Note: Word address
.equ  IOEND  = 0x003f
.equ  SRAM_START  = 0x0100
.equ  SRAM_SIZE  = 256
.equ  RAMEND  = 0x01ff
.equ  XRAMEND  = 0x0000
.equ  E2END  = 0x00ff
.equ  EEPROMEND  = 0x00ff
.equ  EEADRBITS  = 8
#pragma AVRPART MEMORY PROG_FLASH 4096
#pragma AVRPART MEMORY EEPROM 256
#pragma AVRPART MEMORY INT_SRAM SIZE 256
#pragma AVRPART MEMORY INT_SRAM START_ADDR 0x100



; ***** BOOTLOADER DECLARATIONS 
******************************************
.equ  NRWW_START_ADDR  = 0x0
.equ  NRWW_STOP_ADDR  = 0x7ff
.equ  RWW_START_ADDR  = 0x0
.equ  RWW_STOP_ADDR  = 0x0
.equ  PAGESIZE  = 32


Wenn ich das richtig verstanden habe, benutzt der bootlader mehr oder 
weniger nur den Kern, den RAM und die entsprechenden Ports (die liegen 
auch beim 441 im normalen I/O-Bereich). Der RAM beginnt wegen extended 
I/O erst bei 0x100.
Benutzt der bootlader diese Informationen über den RAM oder geht der 
stur von 0x60 Startadresse + RAM-Grösse aus?

[H.Joachim S. (crazyhorse)]

Das stimmt jedenfalls schon mal nicht. Dem stack dürfte das noch rel. 
egal sein, das Problem dürfte dann aber im Bereich 0x60...0xff zu finden 
sein.
Bzw. was ich falsch gemacht habe mit den Speicherangaben.

[H.Joachim S. (crazyhorse)]

Ok, das mit dem Speicher war Quatsch, man sollte die Änderungen auch 
speichern...RAM stimm jetzt.

[H.Joachim S. (crazyhorse)]

So, nun antwortet er wenigstens, und beginnt das update auch.
Die ersten 16 Bytes werden auch korrekt geschrieben, incl. gepatchtem 
Reset-Sprung auf den Bootlader.
Dessen erste 32 Byte werden allerdings gelöscht (ursprünglich begann der 
auf 0x710)
Damit beginnt mein Testprogramm:
:0400000046C0FECF29
:10000400CCC0FCCFFBCFFACFF9CFF8CFFFC0EDC007
:10001400EDC0F4CFF3CFF2CFF1CFF0CFEFCFEECFEF
:10002400EDCFECCFEBCFEACF5EC0E8CF91C0E6CF07
:10003400E5CFE4CFE3CFE2CFE1CF2B37513C4E6A9B


Naja, werde mal weiter suchen.

[H.Joachim S. (crazyhorse)]

Das wirds wohl sein: 4-page erase, d.h. SPM löscht direkt 4 
aufeianderfolgende pages. Anschleissend müssen 4 einzelne pages 
geschrieben werden (bzw. evtl vorher gesichert werden). Das wird mehr 
Aufwand als ich dachte.

[H.Joachim S. (crazyhorse)]

Hm, Assembler ist nicht mehr mein Ding....

In der tn441def.inc:

.equ  PAGESIZE  = 8
.equ    PAGESIZE_ERASE = 4*PAGESIZE

in der fastload.h
.else
  .ifndef PAGESIZE_ERASE
    .equ  BootStart  = ((FlashEnd - BootSize) / PageSize * PageSize)
  .else
     .equ  BootStart  = ((FlashEnd - BootSize) / PageSize_Erase * 
PageSize_Erase)
   .endif
.equ  BufferSize  = PageSize
  .equ  UserFlash  = (2*BootStart - 2)
  .equ  Application  = BootStart - 1
.endif

und in der progtiny:

.else
  .ifndef PAGESIZE_ERASE
          subi    zl, low (2*PageSize)
    sbci    zh, high(2*PageSize)
        .else
          subi    zl, low (2*PageSize_Erase)
    sbci    zh, high(2*PageSize_Erase)
        .endif
.endif

Damit landet die Bootlader-Startadresse schon mal auf einer passenden 
Startadresse und das Löschen funktioniert ohne Teile des Bootladers zu 
löschen.
Aber das Neuschreiben funktioniert nur auf der ersten page, ab Adresse 
0x010 meckert er.

Irgendwo da müsste ein Fehler stecken, ich seh aber keinen:

;---------------------- Next Page 
----------------------------------------
.if PageSize < 32
  adiw  zh:zl, 2*PageSize
.else
  subi  zl, low (-PageSize * 2)
  sbci  zh, high(-PageSize * 2)  ; point to next page
.endif
  brts  _pro8
  ldi  a0, CONTINUE
  rcall  putchar
_pro8:
  cpi  zl, low( 2*BootStart)
  ldi  a0, high(2*BootStart)
  cpc  zh, a0                  ; last page reached ?
  brcs  Program
  brts  _pro9
  rjmp  main_error    ; error, size exceeded
_pro9:
  rjmp  main_ok

Gibts noch andere Typen, die auch nur 8 word pagesize haben?

Fehlermeldung vom UpdateLoader 2.2:
Firmware-Update gestartet (3kiB)
Achtung: Kleiner Sendepuffer!
Zeitüberschreitung (0x000010)
Fehler beim Firmware-Update, Ausführung abgebrochen

[H.Joachim S. (crazyhorse)]

So klappts, könnte man noch ausbauen.


tn441def.inc:
PageSize = 8

fastload.h:
  .equ  UserFlash  = (2*BootStart)
  .equ  Application  = 0
.else
     #ifndef TN441DEF_INC
      .equ  BootStart  = ((FlashEnd - BootSize) / PageSize * PageSize)
     #else
      .equ  BootStart  = ((FlashEnd - BootSize) / (PageSize*4) * 
(4*PageSize))
     #endif
.equ  BufferSize  = PageSize
  .equ  UserFlash  = (2*BootStart - 2)
  .equ  Application  = BootStart - 1
.endif

damit der Bootlader auf einer passenden Adresse beginnt.

progtiny.inc:

_pro4:
#ifndef  TN441DEF_INC
 .if PageSize < 32
  sbiw  zh:zl, 2*PageSize
 .else
    subi    zl, low (2*PageSize)
    sbci    zh, high(2*PageSize)
 .endif
#else
    subi    zl, low (2*PageSize*4)
    sbci    zh, high(2*PageSize*4)
#endif
  ldi  a0, 1<<PGERS^1<<SPMEN
  out     SPMCSR, a0
  SPM                             ; CPU halted until erase done
  brne    _pro4      ; until Z = 0x0000


Eigentlich ganz einfach :-) Nun könnte man noch das Verhältnis 
page_erase/page_write angeben, mir reicht erstmal dieser eine 
Spezialfall.

[IsDochEgal (Gast)]

Original-Bootloader fboot21

onewire an t85 @ 8Mhz via USB-UART (also "TTL" Pegel, nicht RS-232!) 
erfordert die Invertierung

in fastload.h

.if ONEWIRE
  .macro  IOPortInit
  sbi  STX_PORT, SRX    ; weak pullup on
  cbi  STX_DDR, SRX    ; as input
  sbi  STX_DDR, PB0    ; debug
  sbi  STX_PORT, PB0    ; debug
  .endmacro
  .macro  TXD_0
  ; sbi  STX_DDR, SRX    ; strong pullup = 0
  sbi  STX_DDR, SRX    ; output
  cbi  STX_PORT, SRX    ; low
  .endmacro
  .macro  TXD_1
  ; cbi  STX_DDR, SRX    ; weak pullup = 1
  cbi  STX_DDR, SRX    ; input
  sbi  STX_PORT, SRX    ; high (pullup)
  .endmacro
  .macro  SKIP_RXD_0
  ; sbis  SRX_PIN, SRX    ; low = 1
  sbic  SRX_PIN, SRX    ; low = 0
  .endmacro
  .macro  SKIP_RXD_1
  ; sbic  SRX_PIN, SRX    ; high = 0
  sbis  SRX_PIN, SRX    ; high = 1
  .endmacro
.else

Das beeinflusst sehr wahrscheinlich das Timing!

"Gebaut" unter Windows:

    rem copy "C:\Program Files 
(x86)\Atmel\Studio\7.0\packs\atmel\ATtiny_DFP\1.3.229\avrasm\inc\tn85def 
.inc"  tn85def.inc
    "C:\Program Files 
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\avrasm2.exe" -fI 
BOOTLOAD.ASM

Geflasht mit

    avrdude.exe -vv -P USB -c usbasp -B 10 -p t85 -U 
flash:w:BOOTLOAD.hex:i -U lfuse:w:0xE2:m -U hfuse:w:0xdf:m -U 
efuse:w:0xfe:m

Eigentliches Programm dann übertragen mit fboot-win-devcpp-mod, gebaut 
mit mingw (gcc)

    fboot-win-devcpp-mod>g++ fboot.cpp serial.cpp

Parameter:

a /?
/?               Get this help message
/Bnnnn           Define baud rate
/Cn              Define serial port n = 1..16
/Pname           Perform Program
/Vname           Perform Verify
/Rstring         Reset string
/Istring         Init string

Und dann

a /Pfirmware.hex

******* Push Reset Botton *******

COM 3 at 57600 Baud: Connected (One wire)
Bootloader V2.1
Target: 1E930B F
Buffer: 64 Byte
Size available: 7678 Byte
Program firmware.hex: 00000 - 003C3 successful
CRC: o.k.
Elapsed time: 0.00 seconds

[IsDochEgal (Gast)]

Bei 1MHz XTAL (F_CPU) geht es immerhin mit 19200 baud.

[IsDochEgal (Gast)]

Gibt es eine Möglichkeit, den Bootloader per Bootloader zu ersetzen (ich 
habe Reset deaktiviert und keinen HV-Programmer)?

[Malte _. (malte)]

Du müsstest ein Programm schreiben, welches den Bootloader überschreibt 
und das mit dem ersten Bootloader flashen. Allerdings vermute ich, dass 
du damit nicht die Fuses ändern kannst. Der neue dürfte also nicht 
größer sein.
Falls es sich um einen Tiny im DIL Gehäuse mit serieller HV 
Programmiermöglichkeit (zb TinyX4, TinyX5) handelt, kann man auch auf 
dem Steckbrett einen HV Programmer zusammen stecken. Braucht eigentlich 
nur einen weiteren AVR, 12V Netzteil und zwei Transistoren.

[IsDochEgal (Gast)]

Ja danke, siehe auch Beitrag "AVR bootloader per bootloader überschreiben (fastboot)?"