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

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

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

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

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

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.

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

Kann mir einer verraten wie ich den sourcecode kopilieren kann?

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

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

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

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

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

Ist es viel Aufwand, den ATM128 noch mit einzubauen?

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

Hallo Peter,

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

Schöne Grüße,
Techniker

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

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

so vielleicht?

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


Peter

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>

LED_mega32.hex

der dateiname ist immer noch 10 buchstaben lang ;)

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.

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

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

Beides.

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?

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

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

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

http://mikrocontroller.cco-ev.de/php/counter/count...


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

Danke im voraus.

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.

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

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.

@Andreas Kasper

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

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 ?

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

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

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


---

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

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

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

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

Daher gibts kein Secondbootstart.

Nimm daher das T45.ASM als Vorlage.


Peter

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

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

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

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

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

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

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


Peter

Danke!
Das wars!


mfg Andreas

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

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

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

> 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) {}

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

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

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#

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

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>

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

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#

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

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