Forum: Projekte & Code UART Bootloader ATtiny13 - ATmega644

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

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

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

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

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

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

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

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

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

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

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

Vermutllich die Bootfuses falsch gesetzt. Sie müssen auf 512 Byte 
stehen.


Peter

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

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:

1

/* UART receiver interrupt */

2

ISR(USART_RXC_vect)

3

{

4

    static uint8_t numCharReceived = 0;

5

    uint8_t Resetpassword[] = "Peda";

6

7

    /* Check if passord is being sent */

8

    if (UDR == Resetpassword[numCharReceived]) {

9

        numCharReceived++;

10

    } else {

11

        numCharReceived = 0;

12

    }

13

    /* Password completely received? */

14

    if (Resetpassword[numCharReceived] == '\0') {

15

        numCharReceived = 0; /* avoid reading outside buffer in case reset isn't executed */

16

17

#       if NONPRODUCTIVE

18

            /* Start WDT with shortest timtout to trigger a reset */

19

            WDTCR = ((0<<WDTOE) | (1<<WDE)| (0<<WDP2) | (0<<WDP1) | (0<<WDP0));

20

            cli(); /* disable interrupts */

21

#       endif

22

    }

23

}

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

Wie wäre es denn, wenn der Code mal hier in subversion eingescheckt 
würde?

Ja, aber ein Subversion-Repository ist doch viel handlicher. Vor allem 
kann man sehr schnell sehen, wodurch sich die einzelnen Versionen 
unterscheiden.

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.

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:

1

Build started 8.7.2010 at 21:28:26

2

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

3

ed/bootload.S -o bootload.o

4

5

m168def.inc: Assembler messages:

6

m168def.inc:47: Error: unknown pseudo-op: `.device'

7

m168def.inc:49: Error: expected comma after "SIGNATURE_000"

8

m168def.inc:50: Error: expected comma after "SIGNATURE_001"

9

m168def.inc:51: Error: expected comma after "SIGNATURE_002"

10

[...]

hundert weitere - eine für jedes .equ ...  in inc-file

Im Anhang mal das Projekt-verzeichnis

danke im voraus,
Vlad

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.

seh ich das richtig, das der bootloader kein EEPROM schreiben kann?

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.

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?

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.

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

Vlad Tepesch schrieb:
> Eine Frage hätte ich noch:
> wird denn der Watchdog am systemstart deactiviert?
Peters Version bietet ein Flag dazu an:

1

aus bootload.asm:

2

;remove comment sign to exclude Watchdog trigger:

3

;.equ   WDTRIGGER       = 0

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

Klingt nach einem Übertragungsproblem.
Klappt denn die UART mit den gleichen Parametern wie beim Bootloaden 
problemlos im normalen Betrieb?

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)

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.

Fuses richtig gesetzt?
Wie resettest du den Atmega? Vielleicht läuft dein Atmel nicht sauber 
an.

Hier ein Bild der Fuses die gesetzt sind. Den Reset löse ich über einen 
Taster aus.

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

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

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

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:

1

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

1

-U flash:v:main.hex

 kann auch ein Verify durchgeführt werden.

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

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:

1

 AVRASM: AVR macro assembler 2.1.42 (build 1796 Sep 15 2009 10:48:36)

2

Copyright (C) 1995-2009 ATMEL Corporation

3

4

BOOTLOAD.ASM(38): Including file 'm128RFA1def.inc'

5

BOOTLOAD.ASM(64): Including file 'fastload.inc'

6

fastload.inc(8): Including file 'fastload.h'

7

fastload.h(2): Including file 'compat.h'

8

fastload.h(3): Including file 'protocol.h'

9

fastload.inc(23): Including file 'watchdog.inc'

10

fastload.inc(32): Including file 'abaud.inc'

11

fastload.inc(33): Including file 'password.inc'

12

fastload.inc(45): Including file 'command.inc'

13

command.inc(68): Including file 'message.inc'

14

command.inc(71): Including file 'verify.inc'

15

command.inc(75): Including file 'progmega.inc'

16

fastload.inc(46): Including file 'uart.inc'

17

fastload.inc(58): error: Illegal use of undefined or forward referenced symbol 'APICALL' in conditional

18

BOOTLOAD.ASM(64): info: 'fastload.inc' included from here

19

20

Assembly failed, 1 errors, 0 warnings

Wie ist die korrekte Syntax mit den Defines?

Vielen Dank,

Steffen

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:

1

BOOTLOAD.ASM(38): Including file 'm128RFA1def.inc'

2

BOOTLOAD.ASM(64): Including file 'fastload.inc'

3

fastload.inc(8): Including file 'fastload.h'

4

fastload.h(2): Including file 'compat.h'

5

fastload.h(3): Including file 'protocol.h'

6

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:

1

;      remove comment sign to exclude API-Call:

2

;      only on ATmega >= 8kB supported

3

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

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.

So,

die FASTLOAD.H fuer Ludger ist offensichtlich zu alt.
Jetzt versuche ich es mit der aktuellen, bekomme hier aber die nested
includes:

1

  ;----------------------------  max possible buffer size -----------------

2

  .set  BufferSize  = SRAM_SIZE / 2 - PAGESIZE

3

  .macro testpage

4

    .if    BootStart % BufferSize

5

      .set  BufferSize = BufferSize - PAGESIZE

6

      .if  BootStart % BufferSize

7

        .set    BufferSize = BufferSize - PAGESIZE

8

        testpage

9

      .endif

10

    .endif

11

  .endmacro

12

  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

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

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

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

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"

Oh...Danke für die Info. Ich werde es mal mit der neuen Version Testen.

Danke

Tobias

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?

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

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.

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.

1

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:

1

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 ?

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.

1

   const char * cp_devices_path[] = {".","/etc","/etc/avr-bootloader",""};

2

   int k = 0;

3

   int b_read = 0;

4

5

   while(cp_devices_path[k][0] != '\0' && !b_read)

6

   {

7

     char c_buffer[256] ;

8

     sprintf(c_buffer, "%s/devices.txt", cp_devices_path[k++]);

9

10

     if((fp = fopen(c_buffer, "r")) != NULL) 

11

     {

12

    b_read = 1;

13

        while(fgets(s, 256, fp)) {

14

           if(sscanf(s, "%lX : %s", &j, s) == 2){ // valid entry

15

              if(i == j) {

16

                 break;

17

              }

18

           }

19

           *s = 0;

20

        }

21

        fclose(fp);

22

     } 

23

   }

24

25

   if (!b_read)

26

   {

27

        sscanf ("(?)" , "%s", s);

28

        printf("File \"devices.txt\" not found!\n");

29

   }

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

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

1

  .set    BufferSize    = SRAM_SIZE / 2 - PAGESIZE

2

  .macro testpage

3

    .if        BootStart % BufferSize

4

      .set    BufferSize = BufferSize - PAGESIZE

5

      .if    BootStart % BufferSize

6

        .set    BufferSize = BufferSize - PAGESIZE

7

        testpage

8

      .endif

9

    .endif

10

  .endmacro

11

    testpage    ; calculate Buffersize to fit into BootStart

ersetzen durch:

1

.set    BufferSize      = SRAM_SIZE / 2 - PAGESIZE

2

3

.macro  testpage    ; calculate Buffersize to fit into BootStart

4

.if     BootStart % BufferSize

5

.set    BufferSize = BufferSize - PAGESIZE

6

.endif

7

.endmacro

8

  testpage

9

  testpage

10

  testpage

11

  testpage

12

  testpage

13

  testpage

14

  testpage

15

  testpage

16

  testpage

17

  testpage

18

  testpage

19

  testpage

20

  testpage

21

  testpage

22

  testpage

23

  testpage

24

  testpage

25

  testpage

26

  testpage

27

  testpage

28

  testpage

29

  testpage

30

  testpage

31

  testpage

32

  testpage

33

  testpage

34

  testpage

35

  testpage

...damit ist das Macro nicht mehr rekursiv...

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

1

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

Wen das Thema Bootloader interessiert, schaut euch mal den Artikel
AVR Bootloader in C - eine einfache Anleitung an!

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

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

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

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.

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

Dann hab ich nix gesagt :)

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

Komori Satoru schrieb:
> Kann ich diese kostenlos Bootloader?

Der Bootloader und die Sourcen sind uneingeschränkt benutzbar.


Peter

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.

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:

1

;-------------------------------------------------------------------------

2

;                               Port definitions

3

;-------------------------------------------------------------------------

4

;      set both lines equal for inverted onewire mode:

5

6

.equ    STX_PORT        = PORTB

7

.equ    STX             = PB3

8

9

.equ    SRX_PORT        = PORTB

10

.equ    SRX             = PB2

11

;------------------------------------------------------------------------- <

12

.include "pinset.inc"                                                      < NEU

13

;------------------------------------------------------------------------- <

14

;-------------------------------------------------------------------------

15

.include "fastload.inc"

16

;-------------------------------------------------------------------------

- in dieser pinset.inc steht genau das hier:

1

; debug led ge

2

sbi  PORTA, PA1

3

sbi  DDRA, DDA1

Der Bootloader sollte 1s lang nach dem Reset warten:

1

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

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.

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

Hallo,

ich habe den selben chip, es geht, aber nur so:

mit /dev/ttyUSB0

schau mal mit

1

$ ls -la /dev/ttyUSB0

nach.

Ich muss noch in meinem System Mitglied der Gruppe "dialout" sein.

Fuses falsch?

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.

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?

Hallo Christian,

gerne, wenn Du mir noch bestätigst:

mega16 bei 16Mhz

TX Pin ?
RX Pin ?

Oder

1-Wire Pin ?

Hardware-USART
16MHz

Wäre es möglich, dass mir da der Watchdog reinhagelt? Ich finde keine 
Fuse zum abschalten desselben.

Hallo,

der WDT hat keine FuseBits, geht also nur per Software.

Welche Bits sind es nun, ich schaue jetzt nicht ins Datenblatt.

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

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

Also ich hab den Fastload schon auf etlichen m16 benutzt und dort 
funktionierte er immer bestens.

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

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

Hallo Christian,

wie "alt" ist die m16def ?  - steht in der Datei.

Hast Du vor jedem neuen Compilieren auch die
Zeilen angepasst ?

1

MCU = atmega16

2

ATMEL_INC = ./atmel/m16def.inc

3

F_CPU = 16000000

4

5

# Define the Tx and Rx lines here.  Set both groups to the same for

6

# one wire mode:

7

STX_PORT = PORTD

8

STX = PD1

9

10

SRX_PORT = PORTD

11

SRX = PD0

dann erst

1

$make clean

aufrufen und erst jetzt werden die Datei mit

1

$make

alle neu compiliert !

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

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.

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:

1

*** Note: set BOOTSZ fuses to the word address 0x1f00 ***

2

arch=avr5

3

LOADER_START=0x3e00

4

STUB_OFFSET=0x1fe

Ich würde dann diese Fusebits mit avrdude setzen:

1

avrdude -c usbtiny -p m16 -P usb -v -U lfuse:w:0x3e:m -U hfuse:w:0xdc:m

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.

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

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.

@sgm
Ist zwar schön älter aber wurden deine Bootloader Änderungen
in AVRDUDE übernommen ?

Joerg

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

Hast du auch dran gedacht, die Fuses einzustellen?
auf dem mega8 muss die BOOTRST-Fuse aktiv sein

Autsch. Steht sogar im Wikiartikel. Da war ich mal wieder zu voreilig. 
Danke für den Tipp :)

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

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:

1

:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00

2

:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0

3

:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0

4

5

. . . . . . . . .

6

7

:101DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03

8

:101DF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3

9

:101E0000F8946FE56DBF64E06EBF22243324A8957B

10

:101E100061B560617FE061BD63FD71BD909A919A8B

11

:101E2000899A21E030EA63E0F101EF01F1010197C5

12

:101E300060408099E1F7D9F121973496C0F1809BF9

13

:101E4000FBCF0F2EC5950694E9F72397269668F7E2

14

:101E5000EA35F20550F3F797F695E7952F01CAE0BA

15

:101E6000EEEBFFE10590002031F074D00616D1F3BF

16

:101E7000CA95E9F0F5CF66EA87D06CD0E1F76AEA57

17

:101E800083D068D0F1F766D0F1F3F101E8946430C3

18

:101E900088F051F1653059F06730E9F067EA80F772

19

:101EA00059D058D0672859F331016BEAE9CF21BAEC

20

:101EB00022BAA6C0E4ECFFE1C0E0EC0FF21DC49131

21

:101EC0006150D8F768EA60D06591C150E0F7D7CF8C

22

:101ED0000590061268943ED0D9F73CD06058C1F7FF

23

:101EE00026F3CDCF69EA50D06894A0E6B0E0D4E004

24

:101EF00031D031F42FD0605819F48EF0689405C0B9

25

:101F0000E8946D93A032BD0799F7A0E6B0E008D041

26

:101F100060F6E05CFF4FA032BD07C9F71EF7AFCFF8

27

:101F2000E0306EE1F607A8F40D901D9061E00BD053

28

:101F300032966E2F6E73C1F7E054F04063E003D029

29

:101F400065E001D061E167BFE89567B760FDFDCF4F

30

:101F500008940895A895809BFDCF8099FECF78E0E6

31

:101F6000C2019695879523D021D0669580996068A7

32

:101F700067FD62267694679408F4622608F4732657

33

:101F80007A9591F7653A089511D09198749179E016

34

:101F9000609500C000C00AD0669518F400009198C2

35

:101FA00002C0919A00C07A95A1F70895C2010497E2

36

:101FB000F0F78D3F18F011F08F3F01F00895506554

37

:101FC000646100000302010303C0041E93070400C0

38

:101FD0001E007FB7F894613860EF21F4A1DF60E85C

39

:101FE00008F061EF7FBF0895FFFFFFFFFFFFFFFFD6

40

:101FF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFE9CF37

41

:00000001FF

Klar logisch, alles leer bis auf den Bootloader.

Jetzt schreibe ich folgendes Hexfile:

1

:10000000F2C1F9C1F8C1F7C1F6C1F5C1F4C1F3C13C

2

:00000001FF

also 16 Bytes und gut ist. Das ganze erledige ich mit FBoot.

1

C:\FastBoot\FBOOT>fboot /B9600 /C1 /Ptest.hex

2

COM 1 at 9600 Baud: Connected

3

Bootloader V2.1

4

Target: 1E9307 ATmega8

5

Buffer: 960 Byte

6

Size available: 7680 Byte

7

Program test.hex: 00000 - 0000F successful

8

CRC: o.k.

9

Elapsed time: 0.44 seconds

Wenn ich jetzt den M8 wieder auslese erhalte ich folgendes:

1

:10000000F2C1F9C1F8C1F7C1F6C1F5C1F4C1F3C13C

2

:1000100078828C96A00A141E28323C46505A646E90

3

:1000200078828C96A011241FBECFE5D4E0DEBFCD30

4

:10003000BF02D004C004CE80E090E00895F894FFA1

5

:10004000CF78828C96A00A141E28323C46505A64FF

6

:100050006E78828C96A00A141E28323C46505A6450

7

:100060006E78828C96A00A141E28323C46505A6440

8

:100070006E78828C96A00A141E28323C46505A6430

9

:100080006E78828C96A00A141E28323C46505A6420

10