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
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
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.
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
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
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
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
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
Achso vergessen:
supername_hex_was_weissichwietollername.hex mal in main.hex umbenennen.
-> kurze Dateinamen
Steht aber alles weiter oben im Thread.
Gruß Sven
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
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
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?
> 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 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
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.
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
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.
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,
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!
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
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
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.
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 ?
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 ?
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 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 ?
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 */
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
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:
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.
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
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
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.
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
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.
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
>> - 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!
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:
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
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
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
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!
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.
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.
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:
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...
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
;removecommentsigntoexcludeAPI-Call:
2
;onlyonATmega>=8kBsupported
3
;.equAPICALL=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,
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
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...
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.
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.
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
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.
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
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.
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:
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
.ifBootStart%BufferSize
nicht mehr erfüllt, dann ist es egal wie oft das Macro noch kommt...
Edit: 42mal wäre die Antwort aller Fragen....
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
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
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ß,
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...)
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
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:
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ß!
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
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
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?
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
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
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.
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.
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...
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
:100090006E78828C96A00A141E28323C46505A6410
11
:1000A0006E78828C96A00A141E28323C46505A6400
12
:1000B0006E78828C96A00A141E28323C46505A64F0
13
:1000C0006E78828C96A00A141E28323C46505A64E0
14
:1000D0006E78828C96A00A141E28323C46505A64D0
15
:1000E0006E78828C96A00A141E28323C46505A64C0
16
:1000F0006E78828C96A00A141E28323C46505A64B0
17
:100100006E78828C96A00A141E28323C46505A649F
18
:100110006E78828C96A00A141E28323C46505A648F
19
:100120006E78828C96A00A141E28323C46505A647F
20
:100130006E78828C96A00A141E28323C46505A646F
21
:100140006E78828C96A00A141E28323C46505A645F
22
:100150006E78828C96A00A141E28323C46505A644F
23
:100160006E78828C96A00A141E28323C46505A643F
24
:100170006E78828C96A00A141E28323C46505A642F
25
:100180006E78828C96A00A141E28323C46505A641F
26
:100190006E78828C96A00A141E28323C46505A640F
27
:1001A0006E78828C96A00A141E28323C46505A64FF
28
:1001B0006E78828C96A00A141E28323C46505A64EF
29
:1001C0006E78828C96A00A141E28323C46505A64DF
30
:1001D0006E78828C96A00A141E28323C46505A64CF
31
:1001E0006E78828C96A00A141E28323C46505A64BF
32
:1001F0006E78828C96A00A141E28323C46505A64AF
33
:100200006E78828C96A00A141E28323C46505A649E
34
:100210006E78828C96A00A141E28323C46505A648E
35
:100220006E78828C96A00A141E28323C46505A647E
36
:100230006E78828C96A00A141E28323C46505A646E
37
:100240006E78828C96A00A141E28323C46505A645E
38
:100250006E78828C96A00A141E28323C46505A644E
39
:100260006E78828C96A00A141E28323C46505A643E
40
:100270006E78828C96A00A141E28323C46505A642E
41
:100280006E78828C96A00A141E28323C46505A641E
42
:100290006E78828C96A00A141E28323C46505A640E
43
:1002A0006E78828C96A00A141E28323C46505A64FE
44
:1002B0006E78828C96A00A141E28323C46505A64EE
45
:1002C0006E78828C96A00A141E28323C46505A64DE
46
:1002D0006E78828C96A00A141E28323C46505A64CE
47
:1002E0006E78828C96A00A141E28323C46505A64BE
48
:1002F0006E78828C96A00A141E28323C46505A64AE
49
:100300006E78828C96A00A141E28323C46505A649D
50
:100310006E78828C96A00A141E28323C46505A648D
51
:100320006E78828C96A00A141E28323C46505A647D
52
:100330006E78828C96A00A141E28323C46505A646D
53
:100340006E78828C96A00A141E28323C46505A645D
54
:100350006E78828C96A00A141E28323C46505A644D
55
:100360006E78828C96A00A141E28323C46505A643D
56
:100370006E78828C96A00A141E28323C46505A642D
57
:100380006E78828C96A00A141E28323C46505A641D
58
:100390006E78828C96A00A141E28323C46505A640D
59
:1003A0006E78828C96A00A141E28323C46505A64FD
60
:1003B0006E78828C96A00A141E28323C46505A64ED
61
:1003C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D
62
:1003D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2D
63
:1003E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1D
64
65
. . . . . . . . .
66
67
:101DD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF13
68
:101DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03
69
:101DF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3
70
:101E0000F8946FE56DBF64E06EBF22243324A8957B
71
:101E100061B560617FE061BD63FD71BD909A919A8B
72
:101E2000899A21E030EA63E0F101EF01F1010197C5
73
:101E300060408099E1F7D9F121973496C0F1809BF9
74
:101E4000FBCF0F2EC5950694E9F72397269668F7E2
75
:101E5000EA35F20550F3F797F695E7952F01CAE0BA
76
:101E6000EEEBFFE10590002031F074D00616D1F3BF
77
:101E7000CA95E9F0F5CF66EA87D06CD0E1F76AEA57
78
:101E800083D068D0F1F766D0F1F3F101E8946430C3
79
:101E900088F051F1653059F06730E9F067EA80F772
80
:101EA00059D058D0672859F331016BEAE9CF21BAEC
81
:101EB00022BAA6C0E4ECFFE1C0E0EC0FF21DC49131
82
:101EC0006150D8F768EA60D06591C150E0F7D7CF8C
83
:101ED0000590061268943ED0D9F73CD06058C1F7FF
84
:101EE00026F3CDCF69EA50D06894A0E6B0E0D4E004
85
:101EF00031D031F42FD0605819F48EF0689405C0B9
86
:101F0000E8946D93A032BD0799F7A0E6B0E008D041
87
:101F100060F6E05CFF4FA032BD07C9F71EF7AFCFF8
88
:101F2000E0306EE1F607A8F40D901D9061E00BD053
89
:101F300032966E2F6E73C1F7E054F04063E003D029
90
:101F400065E001D061E167BFE89567B760FDFDCF4F
91
:101F500008940895A895809BFDCF8099FECF78E0E6
92
:101F6000C2019695879523D021D0669580996068A7
93
:101F700067FD62267694679408F4622608F4732657
94
:101F80007A9591F7653A089511D09198749179E016
95
:101F9000609500C000C00AD0669518F400009198C2
96
:101FA00002C0919A00C07A95A1F70895C2010497E2
97
:101FB000F0F78D3F18F011F08F3F01F00895506554
98
:101FC000646100000302010303C0041E93070400C0
99
:101FD0001E007FB7F894613860EF21F4A1DF60E85C
100
:101FE00008F061EF7FBF0895FFFFFFFFFFFFFFFFD6
101
:101FF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFE9CF37
102
: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):
1
Port geöffnet durch Vorgang "ntvdm.exe" (PID: 2564)
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
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
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
@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
@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).
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
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
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
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
@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
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.
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 ?
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
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
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
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
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
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
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).
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.
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!
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!
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
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ß
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. ;-)
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
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!
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. 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.
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
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
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
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...
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
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...
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
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
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!
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.
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!
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?
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
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.
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.