UART Bootloader ATtiny13 - ATmega644

[Peter D. (peda)]

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

Probiers mal mit der Datei im Anhang.


Peter

[Andreas K. (andie)]

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

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

sbi SCS_DDR, SCS

einfügen.

Gruß andie.

[Ludger (Gast)]

@Peter

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

Bei meinem 644er funktioniert alles tadellos.

Gruss,
Ludger

[Friedhelm Altmann (Gast)]

@ Andreas Kasper

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

Ja das habe ich.

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

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

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

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

Vieleicht noch eine Idee?

Viel Grüße

Fred

[Peter D. (peda)]

Friedhelm Altmann wrote:

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

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

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


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

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

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


Peter

[Friedhelm Altmann (Gast)]

Hallo Peter,
hallo Andi

erstmal vielen Dank für die Antwoten.

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

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

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

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

Hoffe mal das ich den Rest dann auch noch hinbekomme.

Viele Grüße

Fred

[Andreas (Gast)]

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

[Andreas K. (andie)]

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

Hallo Peter,

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

Gruß andie.

[Peter D. (peda)]

Andreas Kasper wrote:

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

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

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

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


Peter

[gast (Gast)]

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

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

[Ludger (Gast)]

@Peter

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

Ludger

[Karsten D. (karstendonat)]

@Ludger

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

Danke.

Karsten

[Karsten D. (karstendonat)]

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

Aber man lernt ja aus seinen Fehlern.

Karsten

[Ludger (Gast)]

Hallo *,

ich habe den fboot18 von Peter mal nach WinAVR uebersetzt.

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

Herzliche Gruesse,
Ludger

[Bootloaderneuling (Gast)]

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

[Karsten D. (karstendonat)]

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

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

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

Karsten

[Falk B. (falk)]

@ Peter Dannegger (peda)

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

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

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

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

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

MfG
Falk

[Bingo (Gast)]

@Peter D

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

mfg
Bingo

[Peter D. (peda)]

Falk Brunner wrote:

> Doch, nimm einen FTDI232RL.

Hab ich nicht.

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


> Gibt billig bei Angelika

Schön.

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

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



Peter

[Ludger (Gast)]

Hallo *,

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

Gruss,
Ludger

[Raik A. (raik)]

Hi,

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

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

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

Grüße
Raik

[Peter D. (peda)]

Raik A. wrote:

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

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

Ich habs noch nie gebraucht.

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

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

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


Peter

[Bootloaderneuling (Gast)]

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

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

[Peter D. (peda)]

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

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

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


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

Du vergleichst Äpfel mit Birnen.

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


Peter

[JojoS (Gast)]

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

[Peter D. (peda)]

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

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


Peter

[JojoS (Gast)]

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

[Dirk S. (disc)]

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

Gruß

Dirk

[Thomas V. (thomas_v)]

@Dirk:

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

Gruß, Thomas

[Dirk S. (disc)]

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

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

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

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

Gruß

Dirk

[Jojo S. (Gast)]

danke, das sieht doch sehr brauchbar aus.

[Dirk S. (disc)]

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

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

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

Gruß

Dirk

[Jojo S. (Gast)]

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

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

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

[Dirk S. (disc)]

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

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

Gruß

Dirk

[Jojo S. (Gast)]

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

Änderung in ProcessFile():

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

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

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

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


Die Zeitmessung habe ich in das frmBootloader integriert:

      private DateTime ProgrammingStartTime;

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

         // Progress-Event anmelden

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

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

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

[Jojo S. (Gast)]

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

[Jojo S. (Gast)]

ich habe in die compat.h folgendes eingetragen:

.ifndef WDCE
.equ  WDCE  = WDTOE
.endif

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

[Jojo S. (Gast)]

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

erstmal in Watchdog.inc:

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

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

[David H. (davherrmann)]

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

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

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

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

Vielen Dank :-)

Grüße
David

[Peter D. (peda)]

Johannes Stratmann wrote:

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

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


Peter

[Peter D. (peda)]

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

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


> Allerdings sendet er das A6 über 100 mal

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

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


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

Ja.


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

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


Peter

[Jojo S. (Gast)]

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

[David H. (davherrmann)]

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

Grüße
David

[Peter D. (peda)]

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

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

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

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


Peter

[Jojo S. (Gast)]

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

danke, dann ist das klar.

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

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

[Thomas (Gast)]

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

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

Creating   'm8.hex'

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

Assembly complete with 20 errors

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

[Peter D. (peda)]

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

2003 is schon ne Weile her,

AVRASM2 nehmen.


Peter

[gamecounter (Gast)]

Hallo!

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

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

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

Das Programm is definitiv im Flash.

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

vielen dank bereits im voraus

gamecounter

[David H. (davherrmann)]

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

Grüße
David

[Peter D. (peda)]

David Herrmann wrote:

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

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

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


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

Ja.


Peter

[David H. (davherrmann)]

Peter Dannegger wrote:

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

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

Ok, vielen Dank.

Grüße
David

[Markus B. (wolframator)]

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

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

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

[Malte _. (malte)]

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

[Sven (Gast)]

@Peda:

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

@Dirk Schmidt:

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

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

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

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

Viel Spass

Gruß Sven

[TobyTetzi (Gast)]

Hallo Sven,

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

Gruß Toby

[Sven (Gast)]

Überarbeitung der Version Bootloader_CSharp_adv.zip:

Neue Version: Bootloader_CSharp_adv_v2.zip

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

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

Viel Spass

Gruß Sven

[Sven (Gast)]

> Prolific 2303 USB-Seriell Adapter funktioniert;

Ports COM 14 + COM 15 funktionieren auch ;-)

Gruß Sven

[Hagen R. (hagen)]

Hi Peter,

ich versuche deine ABaud Routine zu kapieren.

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

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

2.) das

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

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


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

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

wird eventuell so:

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

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

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

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

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

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

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

Gruß Hagen

[Peter D. (peda)]

Hagen Re wrote:

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

Ja

> 2.) das
>

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

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

Nein, der Fehler kann ja positiv oder negativ sein.

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

>

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

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


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

Da ist aber nichts mehr frei.

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

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

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

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

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

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


Peter

[Hagen R. (hagen)]

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

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

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

Also Tolerance ist definiert als 3.

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

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

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

zu

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


Gruß Hagen

[Hagen R. (hagen)]

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

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

Gruß Hagen

[Peter D. (peda)]

Um es mal in einer Hochsprache zu erläeutern:

Man kann schreiben:

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

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

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

Simulier den Code einfach mal mit verchiedenen Werten.


Peter

[Hagen R. (hagen)]

@Peter,

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

Gruß Hagen

[Sven (Gast)]

Neue Version: Bootloader_CSharp_adv_v3.zip

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

(erneut getestet mit Hardware Schnittstelle COM1 bis COM2)

So, dies war vorerst meine letzte Version.

Viel Spass

Gruß Sven

[chris (Gast)]

Hallo Peter,

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

vielen Dank

mfg.

chris

[Peter D. (peda)]

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

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


Peter

[chris (Gast)]

Hi,

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

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


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

thx

mfg.
chris

[Peter D. (peda)]

chris wrote:

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

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

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

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


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

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

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


Peter

[Thomas S. (space)]

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

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

[chris (Gast)]

Hallo Peter,

eins noch dann bin ich still :-)

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

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

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

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

vielen Dank für die schnelle Antwort

cu und mach weiter so

[Malte _. (malte)]

chris wrote:

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

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

[JoJo (Gast)]

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

[chris (Gast)]

hallo  Malte,

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

[frans (Gast)]

Hallo Peter und anderen,


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

Aber ist die atmega128 auch unterschutst oder nicht?

gruss frans

[Peter D. (peda)]

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

Ja, alle AVRs ab dem ATtiny13.

Die aktuelle Version ist hier:

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


Peter

[[e-mail] (Gast)]

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

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

und dann offenen in avrstudio und assemblieren.


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


gruss Frans

[Peter D. (peda)]

[e-mail] wrote:

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

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


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

Was meinst Du damit?


Peter

[[e-mail] (Gast)]

Hallo Peter,

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

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


Gibt er ein adaptier handleidung (manual) ?

gruss, Frans

[chris (Gast)]

dear Frans,

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

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

cu

[Peter D. (peda)]

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

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


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

ja.


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

kann man, ist aber unkritisch.


> bootdelay = xtal/5

sollte eigentlich passen


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

dazu ist ja der XTAL-Eintrag da.


> Gibt er ein adaptier handleidung (manual) ?

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


Peter

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

Hi Peter,

vielen Dank fuer deinen Bootloader! Er ist toll!

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

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

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

Wer noch hat die Erfahrung mit FTDI?

Vielen Dank fuer die Hilfe im voraus!

Alexei

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

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

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

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

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

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

Alexei

[Sven (Gast)]

Hi Alexei,

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

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

Gruß Sven

[Peter D. (peda)]

Alexei Vyssotski wrote:

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

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

Ich benutze Windows-XP.


Peter

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

Hi Sven, Peter

vielen Dank fuer ihre Antworten.

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

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

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

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

Gruss,

Alexei

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

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

Alexei

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

Hi Sven, Peter

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

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

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

Mit freundlichen Gruessen,

Alexei

[Hannes (Gast)]

Hallo zusammen,

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

Konnte hier im Thread und im Wiki nichts dazu finden.


Gruss und noch schöne Ostern
 Hannes

[Peter D. (peda)]

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

Ja.


Peter

[[e-mail] (Gast)]

Hallo peter,

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

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

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

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

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


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

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

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

Mit freundlichen Gruessen,

Frans

[Sven (Gast)]

@Peter:

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

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

Voraussetzung:

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

Update Vorgang:

- man muss den USB Bus abziehen
- schnell wieder anstecken

Problem:

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


Mein Vorschlag:

Der Bootloader bekommt 2 Startzeiten:

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

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


Was hälst Du von der Idee ?

Gruß Sven

[Peter D. (peda)]

[e-mail] wrote:

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

Ja, kann sein.

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

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


Peter

[Duri (Gast)]

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

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

Beim M32 heisst dieses Registerbit WDTOE.

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

.equ  WDDE  = WDTOE  ; For compatibility

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

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

Wenns jemanden hilft....

[Karsten D. (karstendonat)]

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

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

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

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

3. Software-Reset

wdt_enable(WDTO_15MS);
while (true);

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

[Sven (Gast)]

> 3. Software-Reset

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

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

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

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

Vielleicht ist es jetzt verständlicher.

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

Gruß Sven

[Peter D. (peda)]

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

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

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

Peter

[Karsten D. (karstendonat)]

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

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

Karsten

[Sven (Gast)]

Hallo Peter,

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

Zum Assembler: Ich versuche die Befehle zu verstehen.


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

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

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

Habe ich da jetzt was Grundlegendes missverstanden ?

Gruß Sven

[Peter D. (peda)]

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

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

Man sagt, was man getan hat, was man erwartet hat und was passiert ist.


> Beim subi Befehk taucht jetzt aber eine Frage auf.
> Ich habe den Befehl so verstanden, das man einen Wert von
> a0 abzieht.

Zum Addieren die negative Zahl, da es kein ADI gibt.


> Aber das würde ja keine wesentliche Zeit verbraten.

Soll es auch nicht, sondern es initialisiert nur den Wartezähler.
Bei 8MHz entspricht 6 ~0,3s.
Also lade mal in den EEPROM 100 für ~5s.


Peter

[Sven (Gast)]

Hallo Peter,

> Du weiß schon, daß man sowas nicht sagt.
> Man sagt, was man getan hat, was man erwartet hat und was passiert ist.

Na klar entschuldige.

1. also habe die Zeilen eingefügt in abaud.inc
2. alle *.hex Files aus dem Verzeichnis gelöscht
3. asm bootload - neuen bootloader erzeugt
4. flash bzw. atmega8 gelöscht
5. bootload.hex in den atmega8 geflasht
6. neues Programm welches 2 Leds startet aufgespielt
   (1.Led startet sofort nach Programm aufruf, 2. Led nach 1 sec
   danach in endlosschleife)

Mega 8 läuft mit 7,328 Mhz.

Dann habe ich den EEPRom an Stelle 0x01 verstellt.
Von 0x10 bis 0xFE.

Die 1. Led leuchtet immer nach ca. 0.3 Sekunden auf.

> Zum Addieren die negative Zahl, da es kein ADI gibt.

Ahh ok.

> Soll es auch nicht, sondern es initialisiert nur den Wartezähler.

Ok, initialisieren verstehe ich, ich sehe aber nicht wo
dann a0 weiter unten im Programm benutzt wird um die Zeit zu prüfen.

> Bei 8MHz entspricht 6 ~0,3s.
> Also lade mal in den EEPROM 100 für ~5s.

Habe ich versucht.
Werde aber morgen noch mal testen.

Gruß Sven

[Sven (Gast)]

> Die 1. Led leuchtet immer nach ca. 0.3 Sekunden auf.

Ohh man es war schon spät. Die Led 1 leuchtet natürlich nach ca. 1,3 
Sekunden auf. Eine Veränderung wäre ja mindestens 3 oder 4 Sekunden...
Aber dennoch verändert sich an der Zeit nichts, wenn ich den EEProm 
Inhalt verstelle.

Gruß Sven

[Sven (Gast)]

Hallo Peter,

nachdem ich jetzt erfolglos probiert habe das mit dem Eeprom ans laufen 
zu bringen, habe ich mal den konstanten Wert 0xFA vorgeladen.
Nun ändert sich ebenso nicht die Bootload-Zeit.

abaud:
    ldi     a0, 1                   ; additional boot delay at 0x0001
    out     EEARL, a0
    out     EEARH, zerol
    sbi     EECR, EERE
    in      a0, EEDR
    ldi     a0, 0xFA
    subi    a0, -(byte3(BootDelay / 6) + 1)

Natürlich habe ich diese Zeilen mal im AVRStudio im Simulator
gedebugged. Aber bei diesen Versuchen ist mir keine Stelle
aufgefallen, an der der a0 Wert für eine Wartezeit benutzt wird.
Ich bin gerade nach den Tests echt ratlos.

Gruß Sven

[Peter D. (peda)]

Sven wrote:
> nachdem ich jetzt erfolglos probiert habe das mit dem Eeprom ans laufen
> zu bringen, habe ich mal den konstanten Wert 0xFA vorgeladen.
> Nun ändert sich ebenso nicht die Bootload-Zeit.

So, ich hab mal folgendes Testprogramm in den ATtiny45 geladen:

#include <io.h>

int main( void )
{
  DDRB = 0x0C;                  // LED2, LED3 on

  EEARH = 0;
  EEARL = 1;                    // Address = 0x0001
  EECR |= 1>>EERE;              // read
  if( EEDR == 0xFF )
    EEDR = 100;                 // 255 -> 100
  else
    EEDR = 0xFF;                // 100 -> 255
  EECR |= (1<<EEMPE);
  EECR |= (1<<EEPE);            // write

  for(;;){
  }
}

Es funktioniert wie erwartet. Bei jedem 2. Reset gehen die LEDs erst 
nach 5,7s an.

Anbei die geänderte abaud.inc

Der Rest des Bootloaders entspricht der aktuellen Version V1.9:

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


Peter

[Rumpel P. (rumpel)]

Vielen Dank Peter Dannegger für den Bootloader.
Ich konnte ihn problemlos auf dem ATmega162 meines aktuellen Projektes 
installieren.

Die Steuersoftware für das Projekt habe ich in Java (Max OSX 
Applikation) geschrieben, mit Hilfe der Java-Ansteuerung von Daniel M. 
konnte auch der Updater leicht in das Projekt eingebunden werden. Vielen 
dank auch Daniel M.!
Ich musste in Deiner FirmwareUpdater-Klasse die Timeout-Zeiten ein wenig 
erhöhen, da mein Steuerprogramm über Ehternet (XPort) mit dem mega162 
kommuniziert.

Aber jetzt kann ich gemütlich auf dem Sofa, mit dem Laptop auf den 
Beinen,  die Firmware weiterschreiben und alles per W-LAN updaten 
lassen... :D

Vielen Dank dafür!!!

der faule
Rumpel

[Sven (Gast)]

Hallo Peter,

vielen Dank für Deine Mühe.
Der Code in Abaud.inc

abaud:
    ldi     a0, 1                   ; additional boot delay at 0x0001
    out     EEARL, a0
    out     EEARH, zerol
    sbi     EECR, EERE
    in      a0, EEDR
    subi    a0, -(byte3(BootDelay / 6) + 1)

funktioniert natürlich.
Es gibt aber folgendes zu beachten (und das ist mir beim Testen zum 
Verhängnis geworden):

Wir benutzen mal den Wert 0xFA zum Testen, wie ich oben beschrieben 
hatte:

In Fastload.h ist folgendes definiert:

equ  XTAL    = 8000000  ; 8MHz, not critical
.equ  BootDelay  = XTAL / 3  ; 0.33s

In Abaud:

subi    a0, -(byte3(BootDelay / 6) + 1)

Damit erhalten wir bei der Rechnung:

BootDelay = 8000000/3;
BootDelay = 2666666.67

a0 = a0 -(-(byte3(444444.4)+1);
a0 = a0 -(-(byte3(0x6C81C)+1);
a0 = a0 -(-(0x6)+1);
a0 = a0 + 7;

Nehmen wir a0 mit EEProm-Wert von 0xFA an:

a0 = 0xFA + 7;
a0 = 250 + 7;  << byte überlauf
a0 = 1;

Damit habe ich immer eine kurze Zeit eingestellt und habe es nicht so
schnell gemerkt.

Ander herum ergibt sich der Maximale Wert:

a0 Max = 255 - 7;
a0 Max = 248;
a0 Max = 0xF8;

Somit funktioniert es in beiden Bootloader Versionen 1.8 + 1.9.
Ich hoffe, dies ist jemand anderem auch noch nützlich.

Gruß Sven

[Peter D. (peda)]

Sven wrote:
>> Also lade mal in den EEPROM 100 für ~5s.
>
> Habe ich versucht.
...
Sven wrote:
> Es gibt aber folgendes zu beachten (und das ist mir beim Testen zum
> Verhängnis geworden):
>
> Wir benutzen mal den Wert 0xFA zum Testen, wie ich oben beschrieben
> hatte:

Also hattest Du 100 doch nicht versucht.

Daß Werte nahe 255 nur geringe Änderungen bewirken, war mir schon klar, 
daher eben die Empfehlung mit 100.


Peter

P.S.:
Aber es schadet ja nichts, wenn Du jetzt auch ein bischen Assembler 
verstehst.

[Sven (Gast)]

Hallo Peter,

> Also hattest Du 100 doch nicht versucht.
> Daß Werte nahe 255 nur geringe Änderungen bewirken, war mir schon klar,
> daher eben die Empfehlung mit 100.

Ja, jetzt ist es klar. Die 100 habe ich aber auch versucht einzustellen.
Im Nachhinein ist man sehr viel schlauer.
Der Test mit den 100 ist aber durch einen Fehler von
mir immer auf EEProm Stelle 0x0000 getestet worden. (und nicht auf 
0x0001)

> P.S.:
> Aber es schadet ja nichts, wenn Du jetzt auch ein bischen Assembler
> verstehst.

Nein, ganz und gar nicht. Es macht sogar richtig Spass,
wenn es funktioniert. Herzlichen Dank noch mal für Deine Unterstützung.

Gruß Sven

[Sven (Gast)]

Neue Version: Bootloader_CSharp_adv_v4.zip

1.  Update Button
    Dieser dient zum Ermitteln der Comports, wenn man
    während der Laufzeit die USB-Seriell Wandler abgezogen
    hat und neue/andere Comports aufgetaucht sind
    (Anwendung muss nicht neu gestartet werden ;-), praktisch wenn man 
oft
    verschiedene FTDI Wandler ansteckt!)
2.  Versionsinformationen
2.1 Informationen über die Zielhardware


(erneut getestet mit Hardware Schnittstelle COM1 bis COM15)

Hoffe die Features machen auch dem einen oder anderen so viel
Freude wie mir.

Viel Spass

Gruß Sven

[Karsten D. (karstendonat)]

Hi Sven,

hab Dein Programm mangels Zeit noch nicht getestet. Aber Du schreibst 
Com1-Com15. Falls Du auch höhere Ports unter Windwos ansprechen willst, 
kannst Du dass über

\\.\COM120

für COM120 usw.

Ciao

Karsten

[Sven (Gast)]

> hab Dein Programm mangels Zeit noch nicht getestet. Aber Du schreibst
> Com1-Com15. Falls Du auch höhere Ports unter Windwos ansprechen willst,
> kannst Du dass über
> \\.\COM120

Dieses Problem tritt schon bei Comport 10 und höher auf.
Du beziehst Deine Informationen auf die Programmierung mit
CreateFile().....

Unter CSharp verhält sich das etwas anders, da die Net Laufzeitumgebung 
benutzt wird. Sei doch so nett und teste einfach mal das Programm....
Du wirst dann feststellen, das auch Port xx geht. ;-)

Gruß Sven

[Werner A. (homebrew)]

Hallo,
wenn ich im 1Wire Modus z.B. den INT0 als Eingang nehme und in meiner 
Software einen Reset auslöse, wenn auf dem Port was reinkommt, würde der 
Controller automatisch einen Reset ausführen, wenn ich fboot neu starte?

[Peter D. (peda)]

Werner A. wrote:
> Hallo,
> wenn ich im 1Wire Modus z.B. den INT0 als Eingang nehme und in meiner
> Software einen Reset auslöse, wenn auf dem Port was reinkommt, würde der
> Controller automatisch einen Reset ausführen, wenn ich fboot neu starte?

Ja, kann man machen.


Peter

[Peter D. (peda)]

Anbei die neue Version V2.0

Da bei den ATmega nur vom Bootloaderbereich geflasht werden kann, habe 
ich nun nen API-Call hinzugefügt.

Die Applikation kann diesen aufrufen, um eine Page im Flash zu 
beschreiben.
Das Überschreiben des Bootloaders wird abgewiesen.
Die Applikation muß aber selber drauf achten, daß sie sich nicht 
überschreibt.

Die Zieladresse ist 3 Byte lang, damit auch AVRs >64kB komplett genutzt 
werden können.
Die Zieladresse ist in Bytes anzugeben und muß auf dem Pageanfang 
liegen.
Werden weniger Daten als eine Page geschrieben, ist der Rest 
undefiniert.


Das File "apicall.c" enthält den Aufruf mit Parameterübergabe für den 
AVR-GCC (WINAVR).


Peter

[Bernhard (Gast)]

@PEDA

Hey Peter,

funktioniert 1a.

FRAGE: Wie sieht es mit der Lizenz aus?
Habe deinen Bootloader mal experimentell für mein Diplomarbeitsthema mir 
eingebunden, aber ist das überhaupt rechtens oder unter welcher Lizenz 
läuft er?

MfG Bernhard

[Peter D. (peda)]

Bernhard wrote:

> FRAGE: Wie sieht es mit der Lizenz aus?
> Habe deinen Bootloader mal experimentell für mein Diplomarbeitsthema mir
> eingebunden, aber ist das überhaupt rechtens oder unter welcher Lizenz
> läuft er?

Der Bootloader ist im Sinne der GPL frei verwendbar.

http://www.gnu.org/licenses/gpl.html


Peter

[Psiyou .. (Gast)]

Hallo,

verzweifel hier gerade etwas :(
Versuche den Bootloader auf einem Mega32 zu laufen zu bekommen. Haben 
hier ja auch schon mehrere geschafft, nur bei mir hakt es.

Habe die Version 2.
in fastload.h habe ich die Frequenz geändert.

.equ  XTAL = 16000000  ; 8MHz, not critical ->16MHz

in bootload.asm
.include "m32def.inc" als einziges include nicht auskommentiert
Pins (wie Hardware RS232):

.equ    STX_PORT        = PORTD
.equ    STX             = PD1
.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0

Kompiliert (avrasm2.exe und m32def.inc ins Bootloader Verzeichnis 
kopiert)

E:\fastload\BOOTLOAD>avrasm2.exe -fI BOOTLOAD.ASM
AVRASM: AVR macro assembler 2.1.17 (build 435 Apr 10 2008 09:27:55)
Copyright (C) 1995-2008 ATMEL Corporation

BOOTLOAD.ASM(32): Including file 'm32def.inc'
BOOTLOAD.ASM(64): Including file 'fastload.inc'
fastload.inc(8): Including file 'fastload.h'
fastload.h(2): Including file 'compat.h'
fastload.h(3): Including file 'protocol.h'
fastload.inc(23): Including file 'watchdog.inc'
fastload.inc(32): Including file 'abaud.inc'
fastload.inc(33): Including file 'password.inc'
fastload.inc(45): Including file 'command.inc'
command.inc(68): Including file 'message.inc'
command.inc(71): Including file 'verify.inc'
command.inc(75): Including file 'progmega.inc'
fastload.inc(46): Including file 'uart.inc'
fastload.inc(59): Including file 'apicall.inc'

ATmega32 memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x007c00 0x008000    472     20    492   32768   1.5%
[.dseg] 0x000060 0x000460      0   1024   1024    2048  50.0%
[.eseg] 0x000000 0x000000      0      0      0    1024   0.0%

Assembly complete, 0 errors. 0 warnings

Wenn ich das File mit PonyProg öffnen beginnt der Bootloader bei 0x7C00 
bis ungefähr 0x7DF0. Ansonsten sind alles 0xFF bis auf die letzten 
beiden Byte (0x7FFE-0x7FFF).

Fuse: BOOTSZ: 11 (256Words), BOOTRST: 0 so wie für Externen Quarz 
(16MHz) CKSEL:1111 SUT:11
Mit PonyProg also nur ein Haken bei BOOTRST
SPIEN ist auch 0 (Grau hinterlegt mit Haken, wohl durch JTAGEN:0)
OCDEN ist ebenso 0, restlichen fuse sind alle 1.

Spiele ich diese mit PonyProg auf und führe fboot aus, scheint auch 
alles zu klappen:

E:\fastload\FBOOT>FBOOT.EXE /C1 /tar.hex /b9600
COM 1 at 9600 Baud: Connected
Bootloader V2.0
Target: 1E9502 ATmega32
Buffer: 1024 Byte
Size available: 31744 Byte
CRC: o.k.
Elapsed time: 0.27 seconds

Das lässt sich beliebig oft wiederholen (kein warten auf Reset). Lese 
ich das Flash wieder aus ist da nur der Bootloader drin. Unterschiedet 
sich aber am Anfang und Ende (siehe Anhang).

Hat jemand eine Idee was ich da die ganze Zeit falsch mache?
RS232 funktioniert mit Testprogramm über ISP aufgespielt in beide 
Richtungen (Echo).

Was mich noch wundert ist, dass im Datenblatt in Tabelle 99 steht das 
die Bootloader Flash Section von 0x3F00-0x3FFF geht. Wie passt das den 
mit den 32k Flash zusammen ? (0x8000)

Gruß

[Peter D. (peda)]

Psiyou ... wrote:
>

> E:\fastload\FBOOT>FBOOT.EXE /C1 /tar.hex /b9600
>

Muß heißen:

E:\fastload\FBOOT>FBOOT.EXE /C1 /ptar.hex /vtar.hex /b9600


Peter

[Hagen R. (hagen)]

>die Bootloader Flash Section von 0x3F00-0x3FFF geht. Wie passt das den
>mit den 32k Flash zusammen ? (0x8000)

1 Word = 2 Bytes, der FLASH ist Word basiert, musst die Werte *2 nehmen.

Gruß Hagen

[Psiyou .. (Gast)]

Hi,

und erst mal vielen Danke !! Was für ein blöder Fehler, Sorry. Hab das P 
irgendwie immer zum filename zugezählt... :(

Leider klappt es immer noch nicht, jetzt schlägt die Validierung fehl. 
Lese ich das Flash aus ist da nur der Bootloader drin.

E:\fastload\FBOOT>FBOOT.EXE /c1 /ptar.hex /vtar.hex /b9600
COM 1 at 9600 Baud: Connected
Bootloader V2.0
Target: 1E9502 ATmega32
Buffer: 1024 Byte
Size available: 31744 Byte
Program tar.hex: 00000 - 002AA successful
Verify tar.hex: 00000 - 002AA failed!
Verify-Error

@ Hagen Re
Ah, danke. Dann kommt das ja genau hin :)

[Sven (Gast)]

Nimm doch bitte mal zum Test die Version 1.8 oder 1.9.

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

Die sind bei mir beide auf ATMega16 gelaufen oder laufen ;-).
Zur neuen Version 2.0 kann ich leider nichts sagen,
da ich aus Zeitmangel noch keinen Aufbau mit Mega32 habe.

Gruß Sven

[Psiyou .. (Gast)]

Hallo,
auch mit 1.8 und 1.9 das Problem:

E:\fastload_v18>FBOOT18.EXE /c1 /ptar.hex /vtar.hex /b9600
COM 1 at 9600 Baud: Connected
Bootloader V1.8
Target: 1E9502 ATmega32
Buffer: 1024 Byte
Size available: 31744 Byte
Program tar.hex: 00000 - 002AA successful
Verify tar.hex: 00000 - 002AA failed!
Verify-Error

Habe mal mitgeschnitten was über die Schnittstelle geht (für V1.8).
Kommunikationsablauf (zusammengefasst, komplett im Anhang):

     > PC
       < Bootloader  
> Passwort senden (Mehrfach)
  < Connect Bestätigung (Mehrfach)
> CMD Check crc C5 71
  < FAIL
> CMD revision
  < Answer 18 ok
> CMD signature
  < Answer 01 1E 95 02 ok
> CMD buffersize
  < Answer 03 04 00 ok
> CMD userflash
  < Answer 04 00 7C 00 ok
> CMD Check crc F3 BE
  < ok
> CMD program [...data...] CMD escape_shift
  < ok
> CMD verify [...data...] CMD escape_shift
  < FAIL
> CMD esc_shift CMD CMD CMD start
  < badcommand

Hat jemand eine Idee was ich da falsch mache?

Was ist mit dem erstem CRC der fehlschlägt?
Signatur stimmt (mega32), Buffersize und Userflash kann ich leider nicht 
beurteilen, fehlt mir noch der Durchblick.
Dann werden die Daten gesendet, die Überprüfung schlägt aber fehlt. Lese 
ich das Flash per ISP aus, stehen keine Daten drin.
Die Befehle nach dem Fail sind mir leider auch nicht klar.


Gruß

[Peter D. (peda)]

Psiyou ... wrote:
> Leider klappt es immer noch nicht, jetzt schlägt die Validierung fehl.
> Lese ich das Flash aus ist da nur der Bootloader drin.

Tja, was soll ich sagen.
Der Mega16 klappt, der Mega644, der Mega168.

Aber der Mega32 nicht.

Ich meld mich dann wieder.


Peter

[Pier S. (bigpier)]

Hallo ,

ich habe gerade diesen tollen Bootloader ausprobiert und habe 
anscheinend einen bzw mehrere Fehler  gemacht , aber ich bin mir sicher 
das mir jemand helfen kann !
-Also ich verwende einen Atmega 8 und benutze orginale Uart pins !
-Das asm File habe ich soweit notwenig umkommentiert kompiliert und 
geflasht
-Fuse Bit gesetzt wie im Bild (Anhang)
-Habe ein kleines Programm geschrieben Blinkled (natürlich getestet)
-dieses Program wollte ich nun mit dem Bootloader flashen aber das 
Program leuft nicht auch nach mehreren resets !

Vielen Dank im voraus

Gruss

Pier

[Pier S. (bigpier)]

Mit dem Anhang hat es nicht richtig geklapt !!

[Pier S. (bigpier)]

Hallo vergesst meine letzten beiden Einträge ich Dussel hab das 
DosProgramm mit den falschen Parametern betrieben Fuktioniert wunderbar 
Danke trotzdem !!!

[Peter D. (peda)]

Pier S. wrote:
> Mit dem Anhang hat es nicht richtig geklapt !!

fboot /pfilename /vfilename


Peter

[Peter D. (peda)]

Peter Dannegger wrote:
> Aber der Mega32 nicht.
>
> Ich meld mich dann wieder.

Es hat ein = Zeichen in der fastload.h gefehlt und dadurch wurde die 
Startadresse beim Mega32 falsch berechnet.


Peter

[Psiyou .. (Gast)]

Vielen Dank Peter,

werde das gleich mal probiert.
Habe das vorhin auch mit einem mega8 probiert (V2) da ging es auch ohne 
Probleme.

[Psiyou .. (Gast)]

Danke noch mal für das tolle Programm Peter !! Und das Du hier so aktiv 
bei der Problemsuche mitmachst.
Ist echt super :)
Mit v2.1 lief es auf dem mega32 auch sofort :)

Gruß

[Kai (Gast)]

Hi,

toller Bootloader.
Hab den mal mit meinem ATmega8 probiert. Erste mal aufspielen ging ohne 
Probleme. Danach sagt er immer "COM 2 at 19200 Baud: Connected (One 
wire)" obwohl ich mit rs232 dran bin. Hab leider kein Flag für den 2 pin 
mode gefunden. Gibt es den? Bzw kann jemand sagen warum das nicht 
klappt?

Hab es mit Version 2.1 probiert.

greets

[GastABC (Gast)]

>Hab leider kein Flag für den 2 pin mode gefunden.
>Gibt es den? Bzw kann jemand sagen warum das nicht klappt?

Du musst in der Bootload.asm die Zeilen

.equ    STX_PORT        = PORTD
.equ    STX             = PD1

.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0

an deine gewünschten Ein- und Ausgabeports anpassen. Sind beide Pins 
gleich, so wird der OneWire-Modus aktiviert. Steht im Artikel [[AVR 
Bootloader FastBoot von Peter Dannegger]] besser beschrieben also von 
mir jetzt. :)

[Kai (Gast)]

@ GastABC
Ja, schon richtig. Habe ich auch so gemacht. Und wie ich oben schon 
geschrieben habe geht das auch. Allerdings nur beim ersten mal wenn der 
Flash noch leer ist (er also alleine in den Bootloader springt). Habe 
ich schon ein Programm mit dem Bootloader hineingeschrieben (läuft auch 
prima usw) und muss den uC reseten um  in den Bootloader zu kommen geht 
es halt nicht mehr mit oben genanntem Fehler.
Gehe mal davon aus das fboot aus irgendwelchen Gründen denkt es ist 
oneWire. Konnte die Stelle im Code nur leider nicht finden, bzw soweit 
interpretieren das ich das selbst beheben kann.

[Sven (Gast)]

@Kai (Gast):

Der ATmega8 läuft 100% mit Version 1.8 oder 1.9.
Habe beide ATMega8 ATMega8L und ATMega16 getestet.

1. Hast Du den Watchdog an ?
2. Normalerweise kommt der beschriebene Fehler wenn
   die Einstellungen für BOOTSZ nicht stimmen.

   BOOTSZ muss auf 10 gestellt werden für 256 Worte

   --> BOOTSZ0 = 0
   --> BOOTSZ1 = 1

Hoffe das hilft.

Gruß Sven

[Peter D. (peda)]

Kai wrote:
> @ GastABC
> Ja, schon richtig. Habe ich auch so gemacht. Und wie ich oben schon
> geschrieben habe geht das auch. Allerdings nur beim ersten mal wenn der
> Flash noch leer ist (er also alleine in den Bootloader springt).

BOOTRST nicht enabled?


Peter

[Andreas B. (andreasb)]

Hallo zusammen

Ich habe mal wieder versucht die aktuelle Version von FBOOT auf Linux zu 
portieren (Version 2.1), ich habe dafür einige Teile komplett neu 
geschrieben...

Mir ist das auch Teilweise schon gelungen:

./bootloader -v project.hex
=================================================
BOOTLOADER, Target: V2.1
=================================================
Device  : /dev/ttyS0
Baudrate: 115200
Verify  : project.hex
-------------------------------------------------
Waiting for device... Press CTRL+C to exit. -
Connected!
Bootloader V2.1
Target: 1E9403 ATmega16
Reading device information failed!
CRC enabled and OK
Reading project.hex... File read.
Verify project.hex: 00000 - 00BF3 failed!

Mein Problem: sendcommand(REVISION), bzw. sendcommand(SIGNATURE); 
funktionieren immer, sendcommand(BUFFSIZE); und sendcommand(USERFLASH); 
nie. Die Reihenfolge ist komplett egal, die beiden letzten geben immer 
einen Timeout.
Die Definitionen sind kopiert vom FBOOT.
Gibt es da irgend einen Unterschied der beachtet werden muss? Bei allen 
4 Commands erwarte ich 4Bytes als Antwort (long), habe ich auch kopiert 
vom FBOOT, und es funktioniert ja auch bei dem Device und der Version.

Der Bootloader FBOOT kriegt alle Informationen korrekt, Hardware Fehler 
ausgeschlossen.

ps. ich hänge den Code noch nicht an, da er nicht fertig ist und da der 
Fehler wahrscheinlich nicht offensichtlich ist, wenn jemand den Code 
haben will kann er kurz ein Benutzernachricht schreiben.


mfg Andreas

[L. S. (lschreyer)]

Ich habe auch den Fastboot im Einsatz, und bin echt begeistert. Super
einfach, lief auf Anhieb. Vielen Dank dafür!

Jetzt habe ich noch eine Frage: Gibt es eine Möglichkeit, die Software
die man darüber in den Controller lädt, zu schützen? Es würde schon
reichen zu verhindern, dass eine andere als meine Software da rauf
geladen wird.

Hintergrund ist: Das Gerät, um dass es geht, ist eine Bergungselektronik
für Modellraketen. Mit dem Bootloader könnte jeder seine eigene Software
dort reinladen. So kann man nie sicher sein, dass jemand mit dem
Original fliegt oder seine eigene Software, die evtl. nicht sicher ist,
damit testet. Abstürze gehen dann auf meine Kappe, was ich nicht möchte.
Ich müsste sicher stellen, dass niemand dort seine Software hineinlädt, 
aber trotzdem meine Updates laden kann. Ist das möglich?

Louis

[Peter D. (peda)]

Andreas B. wrote:

> Gibt es da irgend einen Unterschied der beachtet werden muss? Bei allen
> 4 Commands erwarte ich 4Bytes als Antwort (long), habe ich auch kopiert
> vom FBOOT, und es funktioniert ja auch bei dem Device und der Version.

Nein.

Das Byte nach "ANSWER" gibt die Länge-1 der Daten an.
3 = 2 Byte
4 = 3 Byte


Peter

[Peter D. (peda)]

L. Schreyer wrote:

> Jetzt habe ich noch eine Frage: Gibt es eine Möglichkeit, die Software
> die man darüber in den Controller lädt, zu schützen? Es würde schon
> reichen zu verhindern, dass eine andere als meine Software da rauf
> geladen wird.

Einfach das "Peda" durch ein nur Dir bekanntes Paßwort ersetzen.
Es kann auch länger sein, das abschließende 0-Byte bestimmt das Ende.
Es kann auch Sonderzeichen (1..255) beinhalten.


Peter

[L. S. (lschreyer)]

Hmm, dumm nur, dass ich keinen C-Compiler habe mit dem ich das Fboot neu 
compilieren kann. Irgendeinen Tipp wie ich das am einfachsten 
hinbekomme?

Louis

[Peter D. (peda)]

L. Schreyer wrote:
> Hmm, dumm nur, dass ich keinen C-Compiler habe mit dem ich das Fboot neu
> compilieren kann. Irgendeinen Tipp wie ich das am einfachsten
> hinbekomme?

z.B.:
fboot -iblablablub


Peter

[Frank (Gast)]

>>L. Schreyer wrote:

>> Jetzt habe ich noch eine Frage: Gibt es eine Möglichkeit, die Software
>> die man darüber in den Controller lädt, zu schützen? Es würde schon
>> reichen zu verhindern, dass eine andere als meine Software da rauf
>> geladen wird.

>Einfach das "Peda" durch ein nur Dir bekanntes Paßwort ersetzen.
>Es kann auch länger sein, das abschließende 0-Byte bestimmt das Ende.
>Es kann auch Sonderzeichen (1..255) beinhalten.

Damit musst du dann aber alle Updates auch persönlich machen.

>>Ich müsste sicher stellen, dass niemand dort seine Software hineinlädt,
>>aber trotzdem meine Updates laden kann. Ist das möglich?

Das geht nur wenn du das HEX File das du dem Anwender schickst 
verschlüsselst und dieses erst im Bootloader wieder entschlüsselt wird. 
Möglich ist das, siehe Beitrag "AVR-Bootloader mit Verschlüsselung"

ciu Frank

[L. S. (lschreyer)]

Super, danke!

Louis

[Tobi (Gast)]

Hallo Peter,

ich habe eine Frage zum One Wire.

Kann man die One Wire Verbindug auch für weitere Datenübertragungen 
nutzen.
Ich würde es gerne als RS232 ersatzt nehmen, da ich mir dabei eine 
Leitung spare.

Kennst Du dazu evtl. einen Code in C, oder hast Du selber einen?

Danke in voraus, Gruß Tobi

[Andreas B. (andreasb)]

Hier die neuste Version des Bootloaders für Linux. War ein Fehler in der 
Kommunikation drin, der zum Glück noch vom Benutzer "_ch_" erkannt und 
behoben wurde.


Ich habe das ganze nicht mehr wirklich getestet (Zeitgründe) aber es 
sollte funktionieren, zumindest mit einem ATMega 8.

mfg Andreas

[Martin (Gast)]

Funktioniert der Bootloader auch mit 32768Hz Systemtakt?

[Mark Schmitz (Gast)]

Hallo,

der Bootloader läuft auf mienem Mega8 einwandfrei. Habe jetzt mal mit 
den BOOTSZ Fuses gespielt. Egal wie ich diese Konfiguriere, der 
Bootloader läuft trotzdem wunderbar...wie kann das sein?!

Gruß, Mark

[Peter D. (peda)]

Mark Schmitz wrote:
> der Bootloader läuft auf mienem Mega8 einwandfrei. Habe jetzt mal mit
> den BOOTSZ Fuses gespielt. Egal wie ich diese Konfiguriere, der
> Bootloader läuft trotzdem wunderbar...wie kann das sein?!

Na dann lade mal ne Applikation rein, die bis kurz unter den Bootloader 
reicht, dann  merkst Du den Unterschied.

Leerer Flash enthält 0xFFFF und das wird als NOP ausgeführt.
Wählst Du den Bootbereich größer, werden einfach noch NOPs ausgeführt, 
bis Du den Bootloader erreichst.


Peter

[Mark Schmitz (Gast)]

Hi Peter,

erstmal ein großes Danke für den genialen Loader.

Bei meinem Mega8 habe ich den Loader geflashed. Wenn ich mir den Flash 
Dump ansehe dann erkenne ich, dass der Loader bei 0x1E00 beginnt und bei 
0x1FFF aufhört.

Wenn ich nun aber die Fuses auf eine bootsize von 128 worten einstelle 
dann müsste der AVR beim Booten ja irgendwo mitten im Bootloader Code 
beginnen zu arbeiten. Trotzdem funktioniert der Botloader in deisem Fall 
noch einwandfrei.
Das verstehe ich an der Sache nicht so ganz!? Vielleicht fehlt mir aber 
auch noch der nötige Durchblick :)
Wäre nett wenn du dazu noch was schreiben könntest.

Gruß, Mark

[Peter D. (peda)]

Mark Schmitz wrote:

> Wenn ich nun aber die Fuses auf eine bootsize von 128 worten einstelle
> dann müsste der AVR beim Booten ja irgendwo mitten im Bootloader Code
> beginnen zu arbeiten. Trotzdem funktioniert der Botloader in deisem Fall
> noch einwandfrei.

Ich habs mir nicht genau angesehen.
Vermutlich springst Du in ne Funktion hinein und deren RET holt 0x0000 
vom Stack (SRAM) und dann gehts mit NOP (0xFFFF) irgendwann richtig rein 
in den Bootloader.

Aber sobald ne Applikation drin is, is der Bootloader unerreichbar.


Peter

[Mark Schmitz (Gast)]

Hab mal bissjen mit Applikation experimentiert! Ist natürlich ne 
Applikation mit Endlosschleife :)

Wenn ich die Fuses auf ne Bootsize von 256 Wörtern setze dann 
funktioniert auch mit vorhandener Applikation der Bootloader noch. Wenn 
ich jedoch auf ne Bootsize von 128 Wörtern runtergehe(Bootsz Fuses beide 
unprogrammiert) dann macht der Mega8 keinen Muks mehr und ich muss den 
Bootloader neu Flashen.

Gruß, Mark

[Daniel R. (zerrome)]

hallo,

der "client" für linux von  Andreas B. ist sehr merkwürdig 
(Bootloader21_20080510.tar.gz). erstmal musste ich ihm beibringen, dass 
er mehr als einen atmega8 flashen kann. jetzt ist das problem, dass das 
irgendwie total langsam ist. das braucht fast 2 minuten für einen 
mega168...
hat sich das mal jemand genauer angesehen? ich komm da nicht recht 
weiter.

grüße daniel

[Matthias L. (matze88)]

Anbei mal eine "neue alte" Version der PC Software. Basierend auf der 
letzten Version für Dev-C++ aus diesem Thread habe ich einen Sendepuffer 
eingebaut, welcher bei Verwendung mit USB/RS232 bzw. Bluetooth/RS232 
Adaptern einen massiven Geschwindigkeitsschub bringt.
Wie immer bei mir alles quick&dirty implementiert, aber es funktioniert.

Laut Dateiname gehört das PC Programm zur Version 17 des Bootloaders, 
ich habe damit inzwischen etwa 100x auf einen Mega88 mit der neusten 
Bootloaderversion über Bluetooth geflasht.

Flashzeiten:
~3700 Bytes "Standardversion ohne Buffer" -> ~50-55 Sekunden
~3700 Bytes "Abgeänderte Version mit 64 Bytes Buffer" -> 2,0 Sekunden.

Das ganze bei 38400 bps über Bluetooth. Eventuell ist der Code noch für 
irgendjemanden nützlich. Eine Vergrößerung des Sendepuffers über 64 Byte 
bringt bei mir keinerlei Verbesserungen, ist aber in der fboot17.c ganz 
unten in der Funktion sendenb ganz leicht möglich.

An Peter: Vielen Dank für diesen Bootloader, ich bin wirklich sehr 
zufrieden :-) Noch schöner wäre, wenn er etwas weniger Speicherplatz 
brauchen würde, aber das wird schwer möglich.

[Sven (Gast)]

schau dir den mal an der ist schlanker
Beitrag "AVR-Bootloader mit Verschlüsselung"

gruß Sven

[Matthias L. (matze88)]

Oh, danke. Den behalt ich im Hinterkopf, wenn mein Flash voll ist. Denn 
eigentlich habe ich keine Lust, die ISP Pins nochmal an den blöden TQFP 
mega88 anzulöten (habe mir etwas zu dicken Kupferlackdraht geholt, 
0,3mm, der ist noch zu fest, zu groß, und reißt immer an den lötstellen 
ab). Warum achte ich eigentlich bei meiner µC Auswahl immer so stark auf 
den Preis, obwohl ich laufend das Problem des vollen Flashs habe? 
Ordentliches UserInterface, Uart interface, SD & einfaches Filesystem 
und schwups sind 5-6 kByte voll...

[Peter D. (peda)]

Sven wrote:
> schau dir den mal an der ist schlanker
> Beitrag "AVR-Bootloader mit Verschlüsselung"

Da steht aber das hier:

"je nach Konfiguration zwischen 344 bis 906 Bytes Codegröße, letzters
mit XTEA Entschlüsselungsfunktion"


Es ist völlig egal, ob Du 257 oder 512 Byte für den Bootloader brauchst, 
Du mußt immer volle 512 Byte Bootsektor beim ATmega88 reservieren.

Es macht also keinen Sinn, z.B. auf die Autobaudfunktion zu verzichten.


Peter

[Daniel R. (zerrome)]

hallo,

habe die linux pc version so geändert, dass nun atmegas größer 8kB 
geflasht werden können und das ganz schön schnell.

10kB bei einem mega168 dauert bei mir jetzt 0.97 sec.

grüße daniel

[link (Gast)]

letzte version

21

Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

[link (Gast)]

Ich möchte folgende Vorschläge machen:

"Error, wrong device informations"

sollte heißen

"Error, wrong device information" o.ä.


Mehr Informationen über den verfügbaren Speicherplatz und die Größe des 
Programms:

...
Device: ATxxxx
Available flash memory:  4096 Bytes
Bootloader size:       512 Bytes
Size available: 3582 Byte (wieso eigentlich nicht 3584?)
Program size:     1234 Bytes
Remaining:        4321 Bytes
Flash Usage: 60% total / 50% available

Dankeschön.

[link (Gast)]

So jetzt habe ich mich ausgesperrt - unter welchen Umständen startet bei 
einem ATtiny der bootloader nicht?

[C. H. (_ch_)]

evtl. Falsche Fuses, d.h. beim "Hochfahren" wird NICHT in den Bootloader 
gesprungen!?

Gruß
Christian

[Peter D. (peda)]

link wrote:
> So jetzt habe ich mich ausgesperrt - unter welchen Umständen startet bei
> einem ATtiny der bootloader nicht?

Versuch mal ne andere Baudrate, z.B. 19200 oder 9600.

Du mußt zuerst das PC-Programm starten und danach den AVR resetten bzw. 
einschalten.
Nur wenn noch keine Applikation drin ist, gehts auch andersrum.

Aussperren geht eigentlich nur, wenn die Applikation absichtlich per SPM 
den Bootloader zerstört (nur bei ATtiny / ATmega48 möglich).

Die Resetzeit-Fuses sollten auf die längste Zeit gesetzt sein, damit der 
RC-Oszillator schön stabil eingeschwungen ist.


Peter

[link (Gast)]

hoppla, ich glaube mein usb-seriell-konstrukt war schuld. da habe ich 
den IC wohl umsonst ausgetauscht... :-( danke für die hilfe, wenn's 
läuft ist das klasse. habe das heute zum ersten mal ausprobiert.

[link (Gast)]

nee wohl doch nicht.

Bootloader-Fuses gibt es bei tiny nicht.
Verschiedene Baudraten ausprobiert
AVR über USB (232-wandler) versorgt

8 MHz

.nolist
.include "tn45def.inc"
.equ    STX_PORT        = PORTB
.equ    STX             = PB1
.equ    SRX_PORT        = PORTB
.equ    SRX             = PB0
.include "fastload.inc"

6 PB1 (MISO/DO/AIN1/OC0B/OC1A/PCINT1)
5 PB0 (MOSI/DI/SDA/AIN0/OC0A/OC1A/AREF/PCINT0)

Ich benutze

ISR(PCINT0_vect) und den power-down modus:

static void init(void)
{
PORTB = (1<<1 | 1<<2 | 1<<3 | 1<<4 | 1<<5 ); 
DDRB  = (1<<0);

ACSR  = (1<<ACD);
PRR  = (1<<PRUSI);
  
MCUCR  = (1<<SE) | (1<<SM1);

TCCR0B = (1<<CS02);
TIMSK |= (1<<OCIE0A); 

GIMSK = 1<<PCIE;
PCMSK = (1<<1 | 1<<2 | 1<<3 | 1<<4 | 1<<5 );
}

Mit Reset-Pin hat es (glaube ich) funktioniert.

Gute Nacht

[Sven K. (svenk)]

> Daniel Platte (zerrome)
> Datum: 02.08.2008 16:25
> Dateianhang: bl21.zip (8,2 KB, 21 Downloads)

> hallo,

> habe die linux pc version so geändert, dass nun atmegas größer 8kB
> geflasht werden können und das ganz schön schnell.

Danke, danke. Habe gerade einen Mega8 mit Linux 1Ghz P3 mit 
USB-FTDI232RL
mit 115200b geflasht.
Zeit: 0.4s

Wollte das als Feedback für Daniel geben.
Beim verify braucht er allerdings noch 6 Sekunden.
(werde jetzt aber mal in die sourcen schauen...)

Gruß Sven

[Daniel R. (zerrome)]

hallo,

ich hab höchstens 1 % zu dem linux pc programm beigetragen.
problem war nur das ungepufferte schreiben. das mag die serielle 
schnittstelle nicht, ob linux oder windows.
Matthias Larisch hatte da eine verblüffend einfache idee :)

das problem beim verify könnte warscheinlich noch schlimmer sein, da das 
wieder ungepuffert abläuft. bin da nicht in aller einzelheit 
durchgestiegen.

ungeprüft ist auch immer noch ob wirklich alles 100% genau geschriben 
wird. kann es sein dass wenn hier und da mal ein byte falsch ist, dass 
programm in einigen teilen noch richtig läuft?
den verify teil kann ich nicht richtig debugen...

grüße daniel

[Matthias L. (matze88)]

Ich melde mich nochmal, mit einer vielleicht für manche von euch 
sinnvollen Idee:

Wie rufe ich den Bootloader aus der Applikation auf?

Wie Peter selbst schon sagt, geht das am besten über den Watchdog.

Eine weitere Idee dazu ist: Wenn du den Uart in deinem Programm sowieso 
benutzt und die Möglichkeit hast, kommandobasiert zu arbeiten, lege ein 
Zeichen des Bootloaderpassworts als Kommando dafür fest.

Mein UART Protokoll funktioniert immer so, dass grundsätzlich jedes 
empfangene Zeichen überprüft wird, ob es ein Kommando ist, solange nicht 
bereits ein Kommando empfangen wurde. Dann wird je nach Kommando IMMER 
für jedes weitere Zeichen in den entsprechenden Funktionsblock 
gesprungen. Am Ende der ganzen Geschichte muss dieser Funktionsblock 
selbst dafür sorgen, das Kommando wieder zurückzusetzen.

Der Bootloader wird dann bei mir wie folgt aufgerufen:

#define SUART_CALL_BOOTLOADER     0x50  // First char of bootloader password so
                      // we can switch to bootloader mode with
                      // standard pc programming software

uint8_t suart_receive( void )
{
  uint8_t temp;
  static uint8_t command = 0;
  if(srx_done)  
  {
    temp = sgetchar();
    if(command == 0)
    {
      command = temp;
    }
    switch(command)
    {
      case SUART_CALL_BOOTLOADER:
      wdt_enable(WDTO_500MS);
      while(1){asm("nop");}    // loop here, else we will call this again and again... and nothing happens
      break;
    }
  }
}

suart_receive wird dabei regelmäßig im Mainloop aufgerufen. (Falls 
jemand diese Idee übernimmt: Darauf achten, dass die receive Funktion 
MINDESTENS 1x pro Zeit, die ein Byte im RX dauert, aufgerufen werden 
muss. Ansonsten bitte einen Receive Buffer einbauen.

Was bringt das nun?

Der Bootloader wird simpel durch starten der Programmiersoftware aus der 
laufenden Applikation aufgerufen. Ich benötige das, da mein µC in der 
derzeitigen Anwendung eigentlich niemals resetet wird und ein Power On 
Reset nur durch Entfernen der Batterien möglich sein wird.

Gut, die Idee ist jetzt nichts bahnbrechendes, aber vielleicht hatte sie 
ja irgendwer noch nicht ^^

Matze

[Gast (Gast)]

Ich habe eine Frage zur Verwendung des Bootloaders in einem 
kommerziellen Projekt:

Weiter oben in diesem Thread wird erwähnt, daß der Bootloader unter der 
GPL steht.

Die GPL basiert meines Wissens nach auf 4 Grundprinzipien, die die freie 
Kopier- und Modifizierbarkeit von Software sicherstellen sollen. Sie 
besitzt weiterhin ein Copyleft, d.h. modifizierte Versionen des 
ursprünglichen Quelltextes müssen ebenfalls wieder unter GPL gestellt 
werden. Dieses Copyleft gilt jedoch nicht, wenn ein von mir 
geschriebenes Programm ein GPL-Programm ausschließlich aufruft/verwendet 
(http://www.gnu.org/licenses/gpl-faq.html : „[...] in many cases you can 
distribute the GPL-covered software alongside your proprietary system. 
To do this validly, you must make sure that the free and non-free 
programs communicate at arms length, that they are not combined in a way 
that would make them effectively a single program [...] If the two 
programs remain well separated, like the compiler and the kernel, or 
like an editor and a shell, then you can treat them as two separat“).

Wie sieht die Sache nun bei der Verwendung des Fastboot-Bootloaders zum 
Aufspielen einer separaten, selbst entwickelten Anwendung auf einen AVR 
aus ?

Nach meinem Verständnis handelt es sich in einem solchen Fall um zwei 
separate Programm – den Bootloader und mein eigentliches 
Anwendungsprogramm. Sehe ich das soweit richtig und kann ich den 
Bootloader in dieser Konstellation in einem kommerziellen Projekt 
verwenden, ohne den Quelltext meines Programms offen legen zu müssen 
oder gegen die GPL zu verstoßen ?


Mit freundlichen Grüßen

Lars G.

[Peter D. (peda)]

Gast wrote:

> Nach meinem Verständnis handelt es sich in einem solchen Fall um zwei
> separate Programm – den Bootloader und mein eigentliches
> Anwendungsprogramm. Sehe ich das soweit richtig und kann ich den
> Bootloader in dieser Konstellation in einem kommerziellen Projekt
> verwenden, ohne den Quelltext meines Programms offen legen zu müssen
> oder gegen die GPL zu verstoßen ?

Ja, die Schutzrechte der Applikation sind durch den Bootloader in 
keinster Weise eingeschränkt.


Peter

[Matthias L. (matze88)]

Hallo!

Ich habe eine Frage: Hatte irgendjemand von euch bereits das Phänomen, 
dass der Bootloader sich selbst überschrieben hat? Eigentlich soll/darf 
das ja nicht passieren, bei mir ist es passiert.
Situation kann ich nicht exakt beschreiben, ich sehe aber am Flashdump 
folgendes:
Programm ist 6766 Bytes groß. (edit: es handelt sich um den Mega 88)
Im Flash beginnt ab dem darauffolgenden Byte (1A6E) eine Wiederholung ab 
dem Offset 16AE (Dezimal 5806). Dies geht exakt bis vor den Bootloader 
(Bootstart ist 1E00). Der Bootloader ist dann bis 1F3F korrekt, von 1F40 
bis 1F7F enthält das Flash nur 0xFF und ab 1F80 bis FLASHEND ist wieder 
alles korrekt.

Das Flash war soweit ich mich erinnern kann niemals voller als in dem 
jetzigen Zustand, d.h. diese Wiederholung im Flash kann nicht durch 
einen nicht gelöschten Bereich kommen sondern muss genau so programmiert 
worden sein.

Warum sind mitten im Bootloaderbereich zwei Pages (genau 64 Byte) 
gelöscht?

Ich kann nicht garantieren, dass die serielle Verbindung beim 
Programmieren immer 100% fehlerfrei war (Bluetooth), aber ich hatte NIE 
Programmierprobleme. Außerdem benutze ich die von mir gepostete 
abgeänderte PC Programmversion (außerdem für nen älteren Bootloader), 
was bisher keine Probleme machte, aber vielleicht kommt das ja jetzt 
doch daher?

Vielleicht habe ich auch im C-Code irgendnen Fehler, dass er wie auch 
immer an eine bestimmte Stelle im Bootloader gesprungen ist? (Eigentlich 
habe ich keine selbstimplementierten Sprungtabellen/Funktionszeiger oder 
so) Das würde 2 gelöschte Pages erklären können, niemals aber ein Abbild 
eines Teil des Flashs exakt am Ende der Applikation... (Die funktioniert 
übrigens 100%ig, bis auf noch vorhandene Bugs im Code, also man merkt 
nicht, dass im Flash was durcheinander ist)

Das Problem gemerkt habe ich, als ich eben das Flash neu programmieren 
wollte. Der Bootloader ist nicht mehr angesprungen.

Jemand ne Idee? Ich werde jetzt den Bootloader neu flashen und die 
Bootloader Lock Bits setzen, dann passiert das wenigstens nicht nochmal 
(Scheiss arbeit, die ISP Pins wieder anzulöten, muss dazu die halbe 
Schaltung auseinandernehmen)

cu
Matze

[Peter D. (peda)]

@Matze,

das PC-Programm kann senden, was es will, der Bootloader kann nicht 
überschrieben werden.
Der Bootloader prüft selber direkt vor dem Löschen, ob die Adresse > 
Bootstart ist.

Ich setzte sicherheitshalber immer auch das Brownout-Reset und hatte 
bisher keine Probleme.

Bei den Classic-AVRs weiß ich definitv, daß die gerne mal den EEPROM 
überschrieben hatten, wenn kein sauberes externes Reset gemacht wurde.
Die Classics hatten ja noch kein Brownout-Reset.


Peter

[Malte _. (malte)]

@Matze
Könnte es sein dass dein Programm Pointer Fehler oder einen 
Stacküberlauf hat? Dann könnten auf diese Weise ungültige 
Rücksprungadressen erzeugt werden, die dann zufällig irgendwo in den 
Bootloader verwiesen haben.

[Matthias L. (matze88)]

Malte: Da hab ich ebenfalls dran gedacht. Muss ich nochmal alles genau 
durchgehen.

Peter:
Den Brown Out verwende ich mit Absicht nicht, da ich desöfteren von 
Problemen in Bezug auf Mega88 und Brown Out gelesen hab. Theoretisch hat 
der AVR auch ne Superversorgung: Bisher nur von einer immer geladenen 
Liion hinterm 3,3V Wandler versorgt, Zusammenbruch nur bei Akkuentfernen 
(während dessen er eigtl. nie irgendwas gemacht hat was zur Flash 
veränderung hätte führen können).


Also für mich ist es wohl noch am wahrscheinlichsten, dass ich nen 
Fehler im Programm hab. Mal beobachten.

Matze

[Stefan (Gast)]

Hallo,

ich habe dem ATmega644 mit bereits geflashter Bootloader Version V1.4. 
basierend auf dem Projekt von 
http://www.ulrichradig.de/home/index.php/avr/avr-webmodule

Unter Windows XP funktioniert der Upload neuer Firmware, allerdings nur 
mit der alten Version 1.4 von fastboot (fboot.exe). Aber die fboot17.exe 
konnte keine Verbindung zum µC herstellen. Mir scheint das Version 1.4 
des Bootloaders inkompatibel ist zu neueren Versionen.

Nun habe ich ein ähnliches Problem mit Linux (Debian Etch mit gleicher 
Hardware wie die Versuche mit Windows XP), nur das die Version 1.4 hier 
auch nicht funktioniert.

Verschiedene Varianten habe ich bisher probiert, vielleicht gibt es ja 
einen hilfreichen Tipp von euch.

Versuch 1) Linux_Fast14: (fastbootLinux.tar.gz hier aus diesem Thread)

>> fboot -d/dev/ttyUSB0 -pFIFIsr08.hex
/dev/ttyUSB0 at 115200 Baud: -
Connected
Bootloader V1.4
Target: 1E9609 ATmega644
Buffer: 3584 Byte
Size available: 64512 Byte
reading file... Done.
Program FIFIsr08.hex: 0000 - 0E00 failed !
Elapsed time: 189.01 seconds

Soweit erstmal interessant. Eine Verbindung kommt unter Linux zustande, 
aber irgendetwas funktioniert beim Flashen nicht. Zudem ist die Zeit mit 
fast 190s weit über den 25s die es unter Windows XP braucht.

Versuch 2) Python von 
http://www.kreatives-chaos.com/artikel/fastboot17-frontend-python

>> python bootloader.py -b 9600 FIFIsr08.hex
/dev/ttyUSB0 at 9600 Baud

Es kommt niemals eine Verbindung zustande. Egal ob Reset oder nochmals 
die Spannungsversorgung anschließen...

Versuch 3) bootloader Version 2.1 (bl21.zip hier aus diesem Thread)
>> bootloader -d /dev/ttyUSB0  -p FIFIsr08.hex

=================================================
|           BOOTLOADER, Target: V2.1            |
=================================================
Device  : /dev/ttyUSB0
Baudrate: 115200
Programm: FIFIsr08.hex
-------------------------------------------------
Waiting for device...

Genau wie Versuch 2) denn auch hier kommt niemals eine Verbindung 
zustande.

Was mir als Idee bleibt ist
- neuen Bootloader flashen (da fehlt mir noch die Hardware)
- einen aktuellen Bootloader auf Kompatibilität zu 1.4 bringen (wo ist 
da der Unterschied im Protokoll?)
- wine/qemu etc einsetzen.

Any Comments?

Gruß
Stefan

[Sven K. (svenk)]

Hi,

wenn ich Dich jetzt richtig verstanden habe willst Du den Atmel
unter Linux neu flashen....

Bootloader unter Linux funktioniert mit V1.4. Das ist doch schon mal 
prima.
Die lange Zeit lässt sich damit erklären, das kein Buffer in
der Version V1.4 programmiert wurde. (in der Linux Version V2.1 schon)

Da Du jetzt die Version V1.4 im Atmel hast, würde
ich an Deiner Stelle mal die "Buffer" Stellen in Linux Version V2.1
suchen und in V1.4 ändern.

Dann müsste das programmieren ebenso flott gehen.
Habe leider keine Zeit das genauer zu studieren.

Gruß Sven

[mäxchen (Gast)]

Hallo zusammen.
Ich habe heute schon einige Stunden damit verbracht, indem ich den 
Bootloader zum laufen bringen wollte, aber ich schaff es einfach nicht.

Mein Problem sieht so aus:
Ich habe das Programm version 1.8 mit AVR-Studio compiliert, das ging 
auch fehlerlos. Dann die fuses gesetzt und das Hex-File mit Ponyprog auf 
einen ATmega8 geladen, was auch ging.
Wenn ich jetzt aber das Programm FBOOT 18 auf dem PC öffne, dann steht 
einfach:
COM1 at 115200Baud: /
und der Strich dreht sich.

Als ich dann die Datenkommunikation über die RS232-Schnittstelle mit 
einem RS232-Sniffer angeschaut habe, stellte ich fest, das der uc 
einfach keine Rückmeldung gibt.
Die serielle Schnittstelle ist aber in Ordnung, mit anderen Programmen 
auf dem uc funktionert sie.

Weiss jemand woran das liegen könnte oder kann mir vielleicht ein 
funktionierendes Hex-File für den ATmega8 posten, nur mal zum testen?

Und noch eine Frage: Hier wird überall geschrieben, dass nur 256Bytes 
Speicher gebraucht werden, aber bei mir beginnt das Programm im Flash 
bei 0xE00. Damit der uc bei einem reset nach 0xE00 speringt, muss laut 
Datenblatt 01 ins BOOTSZ-Register, und nicht 10, wie in der Anleitung 
steht?????

Im Anhang sind die Assebler- und Hexdatei und die Fusebiteinstellungen.

[Peter D. (peda)]

@mäxchen

versuch mal ne kleinere Baudrate (-b19200).
Der Bootloader benötigt 256 Words (=512Byte).


Peter

[mäxchen (Gast)]

Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x001e00 0x001fd8    452     20    472    8192   5.8%

Ja es sind nicht ganz 256 Words aber der Bootloader startet bei 0x1E00, 
und das ist laut Datenblatt die Startadresse für 512 Words!! Darum weiss 
ich auch nicht wie ich die Fuses stellen soll, denn bei eingestellten 
256 Words springt er bei einem Reset zu 0x1F00.

[mäxchen (Gast)]

Danke für die Hilfe mit weniger Baud geht es!
Aber woran kann das liegen? Schlecht geschirmtes Kabel?

[Matthias L. (matze88)]

zu langsamer µC? Schlecht geschirmtes Kabel ist unwahrscheinlich.
Ich habe hier 38400 bps auf 8 MHz laufen, aber es sollte noch mehr 
möglich sein. Die 115200 erreichst du eventuell auch erst über 8 MHz? 
Ich weiß es nicht.

[mäxchen (Gast)]

Aha, das kann gut sein. Mein up läuft nämlich auf 4 Mhz.
Vielen Dank für die Hilfe!

[Matthias L. (matze88)]

Das bedeutet dann, du hast nichteinmal 35 Takte pro Bit (4 000 000 MHz / 
115200 bps = 34,x cycles/bit)

Das wird garantiert etwas knapp, sollte theoretisch allerdings gehen.

Hier kommen wir an ein Problem: Der UART Code ist dafür nicht ausgelegt. 
In der abaud.inc wird MINTIME auf 90 definiert, das begrenzt die 
maximale UART Geschwindigkeit auf CLOCK / 90 baud, in deinem Fall also 
44444 baud. Meiner Meinung nach könnte MINTIME noch eine ganze Ecke 
weiter heruntergestellt werden, mit 115200 baud @ 4 MHz dürfte es aber 
in jedem Fall sehr knapp werden, ohne weitere Codeanpassung gar 
unmöglich sein. (Stichwort: Jitter akkumulation, sample Zeitpunkt. 
Spielt derzeit eine untergeordnete Rolle (bzw. ist von Peter ausreichend 
bedacht), aber wenn man wirklich so haarscharf an die Grenze geht muss 
man das exakt beachten).

cu
Matze

[Michael H* (Gast)]

Hallo,

kann es sein, dass der Bootloader eine Software-UART benutzt?
Wie würde es denn mit der Größe ausschaun, wenn man die Hardware-UART 
einsetzt - käme man vielleicht auf 128 Worte?

Danke scho mal,
Grüße, holli

[Peter D. (peda)]

Michael H* wrote:
> kann es sein, dass der Bootloader eine Software-UART benutzt?

Ja das tut er, sonst könnte man ja keinen ATtiny13 benutzen.
Und für die mit UART wollte ich mir nicht zusätzliche Arbeit machen.


> Wie würde es denn mit der Größe ausschaun, wenn man die Hardware-UART
> einsetzt - käme man vielleicht auf 128 Worte?

Ja, mit HW-UART und ohne Autobaud, sollte es möglich sein.

Ich sehe aber nur einen einzigen, wo das etwas bringt, den ATtiny2313.

Alle Megas sind ja bis mindestens 16k zu haben und da sind 1,5% mehr 
kaum der Rede wert.


Peter

[Michael H* (Gast)]

Stimmt eigentlich. Auch die 3% bei den 8k-AVRs sind alles andre als 
tragisch.
Danke für die schnelle Antwort!

Grüße, holli

[Newbie (Gast)]

Hallo,

nachdem nun schon so viele hier den Bootloader erfolgreich einsetzen. 
Vielleicht kann mir bitte einer sagen,

a) welche Fuses müssen wie gesetzt werden (am besten mit Bild ;o) )?
b) wie geschieht später beim Benutzen des Bootloaders hardwareseitig der 
Anschluss an den PC? Kommt da ein Max232 dazwischen, oder werden die 
beiden Pins sozusagen direkt mit der seriellen Schnittstelle des PC 
verbunden?
c) wie kann man damit Werte ins EEPROM schreiben?

Danke.

[Michael H* (Gast)]

Newbie wrote:
> a), b), c)
AVR Bootloader FastBoot von Peter Dannegger

> c) wie kann man damit Werte ins EEPROM schreiben?
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

[Newbie (Gast)]

@Michael H*

Danke für die schnelle Antwort, den Artikel hatte ncih noch nicht 
gesehen.

Aber die Frage c) bleibt trotzdem: WIE kann man damit Werte ins EEPROM 
schreiben? Ich hab's echt noch nicht gefunden/begriffen.

[Malte _. (malte)]

Newbie wrote:
> Aber die Frage c) bleibt trotzdem: WIE kann man damit Werte ins EEPROM
> schreiben? Ich hab's echt noch nicht gefunden/begriffen.
Nicht mit dem Bootloader. Aber es wäre möglich diese durch deine 
Applikation zu schreiben. Notfalls schreibst du zwei Programme das erste 
setzt die EEPROM Werte und dann lädst du dein Hauptprogramm rein. Ist 
zwar etwas umständlich, aber machbar.

[Jan (Gast)]

Ich schaffe es nicht den Loader mit einem 644P zum laufen zu bekommen.
Der ist doch kompatibel zum 644?
Leider kann ich im AVRStudio minimal 512 Worte für BOOTSZ einstellen.
ebenso ist mir nicht ganz klar ob BOOTRST mit oder ohne "Vögelchen" sein 
muss?

[Peter D. (peda)]

Jan wrote:
> Ich schaffe es nicht den Loader mit einem 644P zum laufen zu bekommen.

Setze mal die Baudrate runter, z.B. auf 9600

> Der ist doch kompatibel zum 644?

Includiere die "m644Pdef.inc".

> Leider kann ich im AVRStudio minimal 512 Worte für BOOTSZ einstellen.

Ist o.k.


Peter

[Raimund R. (raimund)]

moin Leute!
- es dreht sich um den atmega8
- Habe den Bootloader 
(http://www.mikrocontroller.net/attachment/24619/fastload_V14.zip) mit 
AVR-STUDIO assembliert (als bootloader und ohne Fehler) und mit PONYPROG 
in meinen atmega8 gebrannt. Ich habe keine Pins verändert oder Baudraten 
oder oder oder...
- FUSE bits gesetzt wie oben beschrieben.
- FBOOT.EXE liegt in
  C:\temp\
- 1.hex (die mit FBOOT zuladende hex) liegt in
  C:\temp\
- mit Befehl
fboot 1.hex

sollte doch eigentlich alles i.O. sein. ABER: es dreht sich die kleine 
Windmühle... das war's auch schon.
Spannungversorgung liegt an, RS232 ist i.O. (sonst hätte PONYPROG nichts 
gemacht)
- mit PONYPROG kann ich 1.hex ganz simpel in den atmega laden  - und das 
kleine program läuft dann auch wie gewünscht.

Peter schrieb zum Beitrag von mäxchen (Datum: 31.08.2008 21:01) die 
Baudrate zu ändern... aber wo?? Hat jemand ein HELP-File für FBOOT?? Ist 
das ein Kommandosatz für FBOOT???

Nach mehreren Stunden habe ich erst einmal aufgegeben...

[Malte _. (malte)]

Ja, der Bootloader ist super, nur die Doku etwas dürftig.
Der Bootloader auf dem AVR erkennt die Baudrate automatisch. Bei dem PC 
Programm wird die Baudrate per Parameter eingestellt (im genannten 
Beitrag angegeben).

[Matthias L. (matze88)]

Mensch Leute, ihr programmiert hier µCs und seid dann nicht in der Lage, 
die paar Codezeilen vom Bootloader mal zu überfliegen?

Bootloader Fastload.h: Bei XTAL ist die vorhandene Frequenz des Megas 
einzutragen. Diese muss nicht genau sein, aber wie genau die 
Auswirkungen sind wenn da 8 MHz steht und der µC nur mit 1 MHz läuft, 
weiß ich nicht.

Bootdelay: Hier kann eingestellt werden, wie lange der µC warten soll am 
Anfang, ob der Bootloader genutzt wird.

PC Software:

Switches: Das ding hat eine eingebaute Hilfe. fboot.exe /? ist der 
AUfruf dafür. Und wenn man das halt mal nicht weiß -> Der Quellcode 
liegt doch bei! Soooo schwierig ist das Prog. ja auch nicht aufgebaut. 
Zumindest die Parameter lassen sich noch ganz gut rauslesen.


Matze


Edit:
Glatt vergessen, was ich sagen wollte:

Wenn der Strich sich einfach nur dreht und sonst nichts passiert, dann 
hast du entweder nen falschen Com-Port ausgewählt, oder dein µC ist 
schon über den Bootloader hinaus. Bei sonst leerem Flash sollte er 
allerdings immer wieder zum Bootloader loopen.... Probier mal am PC ne 
niedrigere Baudrate.

[Raimund R. (raimund)]

Matthias Larisch wrote:
> Mensch Leute, ihr programmiert hier µCs und seid dann nicht in der Lage,
> die paar Codezeilen vom Bootloader mal zu überfliegen?
...
> Switches: Das ding hat eine eingebaute Hilfe. fboot.exe /? ist der
> AUfruf dafür. Und wenn man das halt mal nicht weiß -> Der Quellcode
> liegt doch bei! Soooo schwierig ist das Prog. ja auch nicht aufgebaut.
> Zumindest die Parameter lassen sich noch ganz gut rauslesen.
>
>
> Matze

jeder hat mal 'nen schlechten Montag und meint andere belehren zu 
müssen??
Sorry dass nicht alle sooo schlau sind wie Du!

>
>
> Edit:
> Glatt vergessen, was ich sagen wollte:
>
> Wenn der Strich sich einfach nur dreht und sonst nichts passiert, dann
> hast du entweder nen falschen Com-Port ausgewählt, oder dein µC ist
> schon über den Bootloader hinaus. Bei sonst leerem Flash sollte er
> allerdings immer wieder zum Bootloader loopen.... Probier mal am PC ne
> niedrigere Baudrate.

... ja, nur WIE DAS geht hast Du uns natürlich verschwiegen!!
Geht es auch mal sachlich???

[Matthias L. (matze88)]

Entschuldigung falls das zu mies rüberkam, aber meiner Meinung nach habe 
ich alle benötigten Informationen geliefert, um herauszufinden, was 
gefragt wurde. Geht im übrigen schneller, als hier einen Post 
abzusetzen... Aber dann noch mal vorgekaut:

E:\Projekte\danneger\bootloader\FBOOT>FBOOT.EXE /?
/?               Get this help message
/Bnnnn           Define baud rate
/Cn              Define serial port n = 1..4
/Pname           Perform Program
/Vname           Perform Verify
/Istring         Init string
Press any Key !

Für alle, die des englischen und/oder des denkens nicht fähig sind:

Fboot.exe /B9600 /C!!!!__PORT_DES_COMPUTERS__!!!! 
/P!!!!__EXAKTE_ANGABE_DER_HEX_DATEI__!!!!

dabei muss man !!!!__PORT_DES_COMPUTERS__!!!! noch durch den Com-Port 
des PCs ersetzen, an dem der Programmer hängt. Das ist eine Zahl 
zwischen 1 und 4, ist sie größer aufgrund z.B. eines USB<->RS232 
Adapters, so ist an dieser Stelle das Hobby zu wechseln, da der Aufwand 
(weiter oben im Thread gibts ne geänderte FBOOT die bis Com6 kann) 
vermutlich zu groß ist.

!!!!__EXAKTE_ANGABE_DER_HEX_DATEI__!!!! ist durch den Pfad (inklusive 
Laufwerksbuchstaben) samt Dateiname der Hex-Datei (bitte auch mit 
Dateiendung .hex) zu ersetzen.

Dann wird mit 9600 bps programmiert.

Hinweis: Der Bootloader muss natürlich auch aktiv sein, deshalb direkt 
!NACH! drücken der "Enter-Taste", welche das fboot Programm ausführt 
einmal den µC resetten (FBOOT versucht dauerhaft, den Bootloader zu 
erreichen, bis er Glück hat)


Bitte bitte macht mich jetzt nicht fertig, ich möchte hier niemanden 
persönlich angreifen, nur irgendwie finde ich ist diese Antwort hier 
absolut überflüssig da völlig selbstständig erreichbar (vermutlich geht 
das sogar schneller als das Lesen dieses Posts).

[Raimund R. (raimund)]

Saubere Antwort und super Aufbau! Danke Matthias!!

Werde es an meinem Testplatz heute Nachmittag prüfen!
Habe auch noch einmal das Datenblatt des atmega8 gezückt und werde den 
flash auslesen und prüfen, ob der RESET-Vector auch tatsächlich auf die 
richtige Adresse zeigt. Aus dem Stand heraus würde mir jetzt erst mal 
nichts weiteres einfallen.
Herzlichen Dank für die Beschreibung! (Quellcode guggen hätte mir selber 
einfallen müssen!)
Meine rsr232 geht via isp an den atmega8... und standard brutzeln funzt 
ja...

[Matthias L. (matze88)]

Eine Kleinigkeit ist mir noch eingefallen:

bootload.asm

.equ    STX_PORT        = PORTD
.equ    STX             = PD1

.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0

sind durch die von dir verwendeten Pins für die Bootloader Verbindung 
(Es wird KEIN Hardware Uart verwendet - du kannst zwar die Hardware Uart 
Pins nehmen, aber musst sie explizit hier angeben) zu ersetzen.
Dann dürften keine Probleme mehr auftreten

[Raimund R. (raimund)]

>Eine Kleinigkeit ist mir noch eingefallen:
>
>bootload.asm
>
>.equ    STX_PORT        = PORTD
>.equ    STX             = PD1
>
>.equ    SRX_PORT        = PORTD
>.equ    SRX             = PD0
>
>sind durch die von dir verwendeten Pins für die Bootloader Verbindung
>(Es wird KEIN Hardware Uart verwendet - du kannst zwar die Hardware Uart
>Pins nehmen, aber musst sie explizit hier angeben) zu ersetzen.
>Dann dürften keine Probleme mehr auftreten

also wird der Standard so erst mal nicht funktionieren??
Ich bin re-Einsteiger in asm. Werde die Pins prüfen gg. das Datenblatt!
Das Schaltbild meines Boards habe ich beigefügt.

[Michael H* (Gast)]

Raimund Reh wrote:
> also wird der Standard so erst mal nicht funktionieren??
für deinen mega8 sollten die genau stimmen.
mal ne ganz dumme frage: du löst schon einen reset aus, wenn du flashen 
willst, oder?
und es kommt mir n bisschen so vor, als wär dir der folgende artikel 
unbekannt: AVR Bootloader FastBoot von Peter Dannegger

> Ich bin re-Einsteiger in asm. Werde die Pins prüfen gg. das Datenblatt!
> Das Schaltbild meines Boards habe ich beigefügt.
aah, das schöne pollin-board =)

[Raimund R. (raimund)]

Michael H* wrote:
> Raimund Reh wrote:
>> also wird der Standard so erst mal nicht funktionieren??
> für deinen mega8 sollten die genau stimmen.
> mal ne ganz dumme frage: du löst schon einen reset aus, wenn du flashen
> willst, oder?
> und es kommt mir n bisschen so vor, als wär dir der folgende artikel
> unbekannt: AVR Bootloader FastBoot von Peter Dannegger
>
>> Ich bin re-Einsteiger in asm. Werde die Pins prüfen gg. das Datenblatt!
>> Das Schaltbild meines Boards habe ich beigefügt.
> aah, das schöne pollin-board =)

Grins!
(1) es funktioniert jetzt - hatte noch ein paar Probleme beim 
compilieren mit avr-studio, welche ich aber alleine lösen konnte und auf 
persönliche Dummheit zurückzuführen waren.
(2) es funktioniert mit dem FBOOT18 - mit den Vorgängern konnte ich es 
nicht hinbekommen
(3) POLLIN-Board - hm... ich habe eine Anwendung für dem atmega8 
entwickelt, die verhält sich auf dem PoBo anders als wenn ich den am8 
auf ein Breadboard stöpsel. Obwohl ich alle jumper gezogen.

herzlichen Dank für die kundige Unterstützung!