UART Bootloader ATtiny13 - ATmega644

[Uwe S. (de0508)]

Hallo Sebastian,

super, danke.

Bitte hänge noch fboot.exe an.

[Sebastian E. (s-engel)]

Da kann die Originale von PaDa genutzt werden oder die von Sascha:
Fboot21-Dev-Cpp.zip ( Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" 
)

Angehängt habe ich die aus dem ZIP-File von Sascha.

[Dirk R. (mdiri)]

Hallo Peter,

Ich setze deinen Bootloader in verschieden Atmegas erfolgreich ein. Dein 
Bootloader finde ich einfach genial. Mein neues Projekt enthält den 
Atmega 1284p....nun wollte ich das hexfile erzeugen (m1284Pdef) vorher 
eingebunden...und bekam ein error "FATAL ERROR: Too deeply nested macro 
calls(16)". Dann wieder ins Forum um nachzulesen aber igendwie bekomme 
ich keine richtige Antwort. Kann ich vielleicht auch den 1281er nehmen, 
der hat den gleichen Speicher. Kann mir jemand helfen oder hat mir einer 
eine Idee.Ich würde gerne bei dem Bootloader bleiben.

Gruß Dirk

[Conny G. (conny_g)]

Hallo Peter,

ich denke darüber nach, ob ich den Bootloader für entfernte Schaltungen 
einsetzen kann, die per Funk (868 Mhz RFM12) angebunden sind.
Muss die bisher immer einsammeln und updaten oder zu den Schaltungen 
hingehen. Kein supergrosses Problem, aber natürlich nervig.

Hätte dazu folgenden Aufbau im Kopf:
diese Schaltungen haben einen extra Flash-Speicher der ausreicht das 
Image aufzunehmen. Ich schicke in kleinen Datenpaketen à ... 20-30 
Bytes? ... das HEX mit CRC und allem drum und dran, Pakete werden 
wiederholt, wenn nicht bestätigt oder CRC falsch.
Die "Satellitenschaltung" (die entfernte per Funk angebundene) speichert 
die Pakete im Flash.
Nach Übertragung des HEX resettet sich der AVR selbst (Watchdog) und der 
Bootloader holt sich das HEX vom Flash.
Wahrscheinlich bräuchte es noch einen AVR, der dem Bootloader die Daten 
beim Boot per SPI zuspielt, wenn im Flash welche vorhanden sind? Der 
würde dann loslegen

Könnte das so klappen? Müsste man den Boadloader dazu stark 
modifizieren?
Hab den Eindruck, das spielt sich dann wenn eine AVR/Flash-Kombi dem zu 
flashenden AVR die Daten per SPI geben, nur in der Funkempfangsroutine 
ab (Flash füllen) und bei dem separaten AVR mit seinem Flash - d.h. dann 
wäre der Bootloader gar nicht betroffen?

(Bevor mich jemand darauf hinweist:
Das wäre zwar nicht ganz korrekt in Bezug auf die Regeln des 868 
Mhz-Bereichs, aber das Update fände ja höchstens alle paar Tage statt.)

Vg,
Konrad

[Conny G. (conny_g)]

Ist der Thread noch aktiv?
Peter noch da?
:-)

[Bernd O. (bitshifter)]

Hallo Konrad,

warum so kompliziert mit externem SPI-Flash und/oder zweitem Atmel? Du 
wirst so oder so nicht darum herumkommen, tief in den Bootloader und 
Assembler einzusteigen - und dann kannst Du es auch gleich "richtig" 
machen:

Such' Dir einen Atmega, der ca. doppelt so viel Flash hat wie Du für 
Dein Programm (== ein "Image") brauchst und modifiziere den Bootloader 
(sofern er weiterhin nötig ist) und Dein Programm so, dass Du den 
Funk-Download immer auf das jeweils andere "Image" schreibst, das gerade 
nicht aktiv ist. So kannst Du in aller Ruhe warten bis das Image 
geschrieben und verfiziert ist (und wenn es Tage dauert...). Und wenn 
dann alles passt, aktivierst Du das zweite Image, führst einen Reset aus 
und startest so das neue Image.

Das geht auch ganz ohne Bootloader. Du brauchst nur ein zentrales 
Stückchen Code, das bewertet welches Image komplett und neuer ist und 
das dann nach dem Reset startet. Du kannst Dir auch noch weitere 
Sicherheitsmechanismen überlegen wie z.B. dass die neue Anwendung den 
erfolgreichen Start ebenfalls im Flash dokumentieren muß. Wenn sie das 
nicht tut wird nach dem x. Reset ohne positive Quittierung wieder der 
"alte" Code gestartet und Du hast die Chance auf einen neuen Download 
(ohne ISP-Schnittstelle ;-).

Nicht ganz einfach, aber in Summe vermutlich doch einfacher als das 
Zusammenspiel von externem Flash und zweitem Controller mit 
modifiziertem Bootloader.

Bei diesen ganzen "Umschaltereien" solltest Du Dir die Eigenschaften des 
Flash zu Nutze machen, dass man meist problemlos einzelne Bits löschen 
kann ohne gleich eine ganze Page schreiben zu müssen. Quasi wie bei 
einer Mehrfahrtenkarte immer neue Löcher zu stanzen. Alternativ gibt's 
ja auch noch den EEPROM, den man für das Umschalten nutzen könnte (würde 
ich aber erst mal vermeiden wenn möglich).

Gruß,
Bernd

[peterle (Gast)]

Guten Abend,
habe gerade die Gui aus dem Beitrag 
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644" probiert aber leider 
funktioniert die nicht.
Kann es daran liegen das mein PC 64Bit hat.
Vielen Dank

Peter

[Michael H. (michael_h45)]

nein.
versuchs mal mit "als adminstrator ausführen".

[peterle (Gast)]

Ich Habe einen Screnprint mit dem Fehler gemacht!
Danke für Eure Hilfe
Peter

[Chris R. (hownottobeseen)]

Hi,

die Meldung in Visual Studio zeigt dir schon ziemlich genau das Problem.

Dein Event kommt in einem anderen Thread als deine GUI ist. Damit das 
Setzen des Textes threadübergreifend geht, musst du einen Invoke machen.

Auf http://stackoverflow.com/questions/14703698/c-invokedelegate ist in 
der obersten Lösung (die mit dem Häkchen) ein relativ eleganter Weg 
aufgezeigt, wie man das behandeln kann.

Warum das das .NET-Framework nicht von sich aus macht - frag mich bitte 
nicht, hab mich damit auch schon genug herumgeärgert...

Schönen Sonntag,

Chris

[Michael H. (michael_h45)]

in dem link von oben ist ein build drin. du musst es nicht selber 
compilieren.

[peterle (Gast)]

Chris R. schrieb:
> Auf http://stackoverflow.com/questions/14703698/c-invokedelegate ist in
> der obersten Lösung (die mit dem Häkchen) ein relativ eleganter Weg
> aufgezeigt, wie man das behandeln kann.

Also ich bin kein Pc Programmierer aber ich werde es mir ansehen!
Vielen Dank



Michael H. schrieb:
> in dem link von oben ist ein build drin. du musst es nicht selber
> compilieren.
Ich hoffe das der Angehängte Quelltext der selbe vom Build ist!
Werde es trotzdem mit dem Build versuchen.

Danke

peter

[peterle (Gast)]

Noch eine Frage warum habe nur ich diese Problem?

Peter

[Michael H. (michael_h45)]

peterle schrieb:
> Noch eine Frage warum habe nur ich diese Problem?
weil du eine andere build-umgebung (compiler-version, framework-version, 
etc) als der autor hast.

geht denn das binary?

[peterle (Gast)]

Michael H. schrieb:
>> Noch eine Frage warum habe nur ich diese Problem?
> weil du eine andere build-umgebung (compiler-version, framework-version,
> etc) als der autor hast.
>
> geht denn das binary?

Nein das Build funktioniert auch nicht!
Das Programm macht nichts (keine Fehlermeldung).
Ich habe das Build mit dem Datum 06.04.2008 ausprobiert.

Leider komme ich mit der Fehlermeldung oben "INVOKE" auch nicht weiter.
Ich habe mit C# noch nie gearbeitet.

Wäre nett wenn mir jemand helfen könnte

LG

Peter

[peterle (Gast)]

Nachtrag mit dem Kommandozeilenprogramm auf einem XP Rechner 
funktioniert der Bootloader.
Also sollte der Bootloader auf dem Atmel richtig erstellt sein.

Peter

[Michael H. (michael_h45)]

peterle schrieb:
> Nein das Build funktioniert auch nicht!
> Ich habe das Build mit dem Datum 06.04.2008 ausprobiert.
dito - 6.4.08 01:42 uhr. funktioniert hier tadellos.
bei mir ist allerdings der ganze uac-kram aus. als administrator 
ausgeführt?

[peterle (Gast)]

Ich habe den Build auch mit Admin Rechten ausgeführt!

Währe super
wenn mir jemand den Fehler mit "invoke"fixen könnte!

Vielen Dank für Eure Hilfe!

[Steffen H. (stef_fen)]

Hallo Zusammen,

ich würde gerne den Bootloader auf einem Atmega2560 nutzen. Dabei sollen 
die UART Pins PJ0 und PJ1 (UART3) genutzt werden. Beim compilieren 
bekomme ich jedoch 13 Fehlermeldungen mit "Operand out of range". Was 
kann ich dagegen tun? Wenn ich jedoch PE0 und PE1 (UART1) nehme und dann 
compiliere treten keine Fehler auf. Welche Bootsize muss ich bei dem 
2560 einstellen?

;-------------------------------------------------------------------------
;                               Port definitions
;-------------------------------------------------------------------------
;      set both lines equal for inverted onewire mode:

.equ    STX_PORT        = PORTJ
.equ    STX             = PJ1

.equ    SRX_PORT        = PORTJ
.equ    SRX             = PJ0
;-------------------------------------------------------------------------
.include "fastload.inc"
;-------------------------------------------------------------------------

Vielen Dank.
Gruß Steffen

[Michael (Gast)]

Hallo Steffen,

ich hatte auch dieses Problem. Beim Zugriff auf den genannten PORTJ 
können nicht mehr die von Peter verwendeten Zugriffe auf die 
"I/O-Register im Bereich 0x00-0x1F" verwendet werden. Ersetzt man diese 
durch "Dataspace"-Zugriffe, verändert man u.a. das Timing und die 
automatische Baudratenerkennung schlägt fehl.

Bei mir läuft z.Z. der anghängte "patch". Ich habe weitestgehend alles 
wie beim Peter gelassen. Bei Zugriffen auf Portregister über $1F 
schaltet sich alles auf Dataspace-Adressierung um.

Einige Sachen, wie z.B. die "Korrektur für das USB-Dongle" konnte ich 
aber nicht richtig nachvollziehen - vielleicht klappen daher nicht alle 
Takt-Baudrate-Kombinationen?

Wenn Tips kommen und ich Zeit habe, kann ich ja noch mal drüberschauen.

Gruß
Michael

[Michael H. (hoffm)]

So, das Timing wurde besser angepaßt: uC mit 16 und 22 bit PC (bei mehr 
als 128 Byte ROM) bekommen jetzt jeweils ihre eigene Korrektur; die 
Baudraten halten sich im Praxistest sehr eng an die Theoriewerte; der 
"onewire mode" funktioniert aber noch nicht.

[Andreas (Gast)]

Hallo

Ich hoffe der Thread lebt noch und jemand kann mir helfen.
Ich nutze den Mega8 und habe den Bootloader 2.1 geflasht.
Zum testen habe ich direkt an die COM Schnittstelle des PC den Atmel 
gehangen.
Ich kann jetzt problemlos die hex Files mit dem Bootloader programieren.
Mit Baudraten von > 2400 Baud.
Wenn ich jetzt den PC und den Atmel mit 2 ZigBee Modulen verbinde 
(Telegesis ETRX3) und in den Datamode gehe (direkte Verbindung zwischen 
zwei Modulen)
bekomme ich beim starten des uploaders nur die Meldung


C:\fboot21\FBOOT>fboot /Pmain.hex /b19200 /c3
COM 3 at 19200 Baud: Connected (One wire)
Bootloader VFFFFFFFF.FF
Error, wrong device informations

Tippe ich zum testen einfach ein par Zeichen in ein Terminal, sehe ich 
wie die Zeichen auch auf der Gegenseite ankommen.

Hat da jemand eine Idee?

[Michael H. (hoffm)]

Hallo Andreas,

Michael schrieb:
> Ich habe weitestgehend alles wie beim Peter gelassen. Bei
> Zugriffen auf Portregister über $1F schaltet sich alles auf
> Dataspace-Adressierung um.

... und bei Zugriffen unter $1F sollte alles wie beim Peter laufen - tut 
es aber nicht. Ich hatte hier noch nicht die ansonsten nur bei der neuen
Routine benötigten "Trampolinsprünge" wieder entfernt. Deshalb ist meine 
Version bei den "kleinen" Prozessoren um zwei Instruktionen größer als 
Peters.

Das reicht wahrscheinlich noch nicht aus, um beim ATMega8 die 
beschriebenen Probleme zu verursachen, aber ich nutze die Gelegenheit, 
die Fehlersuche zu vereinfachen: Hier kommt die Version P03.

Gruß
Michael

[Yves (Gast)]

Hallo zusammen,

ich nutze die fboot21 und kriege Ihn auf einem Mega644PA einfach nicht 
zum laufen.

Um den 644PA zu unterstützen habe ich die m644PAdef.inc inkludiert.

In der Fastboot.h habe ich folgendes eingestellt, da ich einen 16Mhz 
Quarz am Mega habe.

 .equ  VERSION    = 0x0201

.equ  XTAL    = 16000000  ; 8MHz, not critical 
.equ  BootDelay  = XTAL / 3  ; 0.XXs

Ich habe als Pins folgendes eingestellt:

.equ    STX_PORT        = PORTD
.equ    STX             = PD1

.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0

Den Bootloader habe ich mit dem AVR-Studio auf den uC geladen. Scheint 
auch funktioniert zu haben. Dies habe ich verifiziert indem ich den 
Speicher ausgelesen habe und am Ende des Speichers erscheint der 
Assemblierte Code des Bootloaders.  Die HEX Datei ist 1442 Byte groß. 
Angehängt habe ich den ausgelesenen Speicher des Megas.

Die Fuses sind wie folgt eingestellt:

 Bootsz: 512
Bootrst: X

Habe auch nochmal ein Bild angehangen der ausgelesenen Fuses.

Da der Speicher des ATMegas sonst leer ist müsste er ja immer in den 
Bootloader laufen. Dennoch resette ich den uC sobald aufgefordert indem 
ich die Stromzufuhr trenne und wieder verbinde.

Die fboot.exe habe ich mit 9200 Baud auf COM4 aufgerufen. Jedoch dreht 
sich dort nur die "Uhr".

Als Hinweis noch: Die TX Led meines USB TTL-Wandlers blinkt, die RX Led 
bleibt jedoch dauerhaft an. (Blinken = Datentransfer)


Hat irgendjemand eine Idee was ich falsch gemacht habe oder wie ich es 
hinbekommen kann?

Danke und Gruß,
Yves

[Michael H. (michael_h45)]

rx und tx gekreuzt? nicht gekreuzt?

[Yves (Gast)]

Gekreuzt.... Also:
TTL RX - Mega TX
TTL TX - Mega RX

Habe es aber auch schonmal nicht gekreuzt probiert.... War mein erster 
verdacht

[Yves (Gast)]

Hat keiner weitere Ideen?

Gruß,
Yves

[Michael H. (hoffm)]

Hallo Yves,

der Thread ist wahrscheinlich für Deine Frage nicht der richtige. aber 
trotzdem mein Vorschlag:

Da PD0 und PD1 ja zur Hardware-USART des Controllers gehören, wäre es 
leicht, die Kommunikation mit dem PC zu testen. Klappt denn ein 
"Hallo-Welt" in Richtung PC? (Die avrlibc bietet sich an) Wenn ja, 
klappt der Empfang?

Gruß
Michael

[Yves (Gast)]

Hi Michael,

in welchen Thread gehören denn Fragen zum Bootloader von Peter? Dann 
kann ich es da ggf. auch noch einmal versuchen.

Ich werde es morgen nochmal mit dem Hallo-Welt versuchen aber ich habe 
schon eine stehende Verbindung zur UART1 gehabt.

Ich berichte morgen.

Gruß,
Yves

[Bernd O. (bitshifter)]

Hallo Yves,

hast Du schon mal verschiedene Baudrates ausprobiert. Ich erinnere mich, 
dass ich in der Vergangenheit Probleme mit einigen Baudates hatte - 
insbesondere die kleinen wie 9600. Mit höheren wie z.B. 115200 hat es 
dann klaglos funktioniert.

Keine Ahnung woran es letztlich lag, ob am Bootloader, an den billigen 
USB->Seriell-Adaptern (CP2102) oder etwas anderem - aber ich hatte 
definitiv Baudrates da hat es schlecht bis nie funktioniert (und es 
waren nicht die hohen was mich ja nicht so sehr gewundert hätte).

Gruß,
Bernd

[Yves (Gast)]

Hallo,

also die serielle Hello World verbindung funktioniert. Sende ich im ein 
"a" sendet er mir ein "b" zurück ^^

guter Hinweis Bernd. Ich habe meist extra mit kleinen Baudraten wie 9600 
gearbeitet weil ich auch einen "NoName" TTL-USB Adapter habe und dachte 
vielleicht hat er Probleme mit den schnellen Geschwindigkeiten. Werde es 
morgen mal mit einigen Baudraten testen.

Gruß,
Yves

[Tim . (cpldcpu)]

Dieser Thread macht mich etwas kirre - es gibt hier zig Versionen des 
Bootloaders, teilweise zerfleddert in Patches. Wo gibt es die aktuelle 
Version? Welche Varianten der Host-Software gibt es?

Auch die Wiki-Eintrage scheinen teilweise veraltet zu sein:
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger/Tutorial_ATtiny13

[Michael H. (hoffm)]

Hallo Tim,

es ist, nicht ganz ohne meine Schuld, etwas unübersichtlich geworden. 
Hier eine Übersicht:

* Peter Dannegger hatte mit dem "UART Bootloader ATtiny13 - ATmega644" 
angefangen. Seine letzte Version war

==> fboot21.zip.

* Einige wollten damit auch die größeren AVRs mit mehr Port-Pins 
flashen, z.B. den ATmega1280, was aber nicht funktionierte.

* Ich fand den Loader einfach genial, konnte ihn aber wegen dieser 
Einschränkung leider nicht durchwegs einsetzen. Weil ich das nicht 
akzeptieren wollte, hatte ich einen "Patch" geschrieben, der jetzt auch 
die "großen" Controller unterstützt:

==> fboot21-p01.zip

Die in [[Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"]] genannten 
Timing-Probleme sind mir auch schon häufig aufgefallen. Ich hatte zuerst 
den Loader in Verdacht und daher dessen Zeitverhalten optimiert:

==> fboot21-p02.zip

Auch Peter hatte damit schon angefangen, deshalb mußte ich nur ein paar 
seiner Konstanten besser abstimmen.

(Allerdings liegt das Problem bei der PC-Software: Peter benutzt noch 
die alten "inportb/outportb"-Befehle, um mit der Seriellen Schnittstelle 
zu kommunizieren. Das klappt gut unter DOS und alten Windows-Versionen. 
Bei mir gab es schon unter XP Probleme, unter Windows 7 64-bit klappte 
es gar nicht mehr. Ich habe eine alpha-Version geschrieben, die hierfür 
Win32/Win64 benutzt und sich unter dem freien Compiler-Paket "Dev-C++" 
übersetzen läßt. Aber von anderen gibt es schon fertige Lösungen ...)

Falls andere daran Interesse haben sollten, könnte ja mal ein Mod ein 
wenig aufräumen?

Gruß
Michael

[Jörg E. (jackfritt)]

Wenn man den Wiki Eintrag aktuell hält würden doch alle wichtigen
Info drin stehen und man müßte bei "normalen Fragen" nur darauf 
verlinken.
Mann könnte sogar noch eine FAQ dranhängen mit den größten Probleme 
hier...
Warum soll hier ein Mod Zeit investieren wo er vielleicht nichts über 
dieses Thema weiss?
Ich finde hier sind dann interessierte User gefragt.
So kenne ich das auch aus anderen Foren etc.

Gruss,

Jörg

[Tim . (cpldcpu)]

Hallo Michael,

vielen Dank für die Klarstellung. Ich habe fboot21 inzwischen zum laufen 
bekommen. Dass das Archiv ohne Readme und mit DOS Filenamen kommt war 
schon gewöhnungsbedürftig. Inzwischen läuft aber alles. Mit gefällt der 
Bootloader sehr gut.

Die Wiki-Artikel waren dabei sehr hilfreich. Allerdings sind sie auf 
einem sehr alten Stand.

[Frank H. (huene)]

Hallo,
ich versuche gerade fboot  auf der PC-Seite mit DEV-C++ zu kompilieren. 
Ich habe leider wenig Ahnung von C-Programmierung auf PC-Ebene. Ich lade 
die Datei fboot.dev in die Entwicklungsumgebung von Dev-C++.

Wenn ich das Projekt dann kompiliere bekomme immer Fehlermeldungen mit 
undefined reference to `_argv‘ und `_argc‘

Hat jemand eine Idee, was ich falsch mache? Ich vermute ich muss noch 
etwas an Optionen in der Entwicklungsumgebung einstellen. Versucht habe 
ich es mit den folgenden Quellen:
Fboot21-Dev-Cpp.zip von Sascha
fboot-win-devcpp-mod.zip von Malte Pöggel
pc_dev-cpp.zip von Matthias Larisch

Bevor ich mich mit dem Code auseinandersetze würde ich gern das 
bestehende Projekt erst einmal übersetzt bekommen.

Gruß
 Frank

[Matthias I. (matze5)]

Wie ist den das beim ATTiny 2213 kann da der Bootcode geschützt werden 
gegen Überflashen ? das geht doch nur beim ATMega oder ?

Grüße Matze

[Lars M. (lars_m65)]

Peters Schaltplan für 1-Draht-Betrieb ist funktioniert direkt mit einer 
Com Schnittstelle:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"

Ich habe das mal auf TTL-Pegel UART, z. B. für einen FTDI umgesetzt. Die 
Pegel sind invers zum oben genannten Schatplan. Der FTDI muss mit 
FT_Prog auf inverse Pegel für RX und TX eingestellt werden. Bei dem 
Widerstand sollten auch größere Werte funktionieren. Ich habe 
Atmegaseitig den Hardware-Seriel-TX-Pin genommen. Das bietet sich an, 
weil man darüber im eigentlichen Programm noch einen Debug-Output hat.

Kann man die Pegel evtl im Bootloader invertieren? Dann muss man nicht 
ständig den FTDI umprogrammieren.


Getestet habe ich das ganze erfolgreich mit einem Arduino pro mini 5V 16 
MHz (Atmega 328p) per UpdateLoader 2.2.4.

[Lars M. (lars_m65)]

Ich habe die Wikiseite nochmal komplett überarbeitet. Die alte Anleitung 
behandelte nur die Ursprüngliche Version von Peter Dannegger. Ich habe 
eine Anleitung zur AVR-GCC Version verfasst und Erklährungen zum 
One-Wire Modus und weiteren Flashmethoden ergänzt. Auch auf die 
Problematik mit dem get_avr_arch.sh Script bin ich eingegangen.

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

[rakete (Gast)]

Hallo,

bei mir ist das get_avr_arch.sh gebrochen mit avr-gcc (GCC) 4.7.2. Ich 
habe versucht ein Refactoring zu machen -- also es zu vereinfachen und 
weniger anfällig zu machen.
Leider konnte ich es nur mit obigen Compiler testen. Leider hat es den 
Anschein, dass die Compiler-Bauer immer an dem Interface rumspielen 
(zumindest was ich bisher in Erfahrung bringen konnte). Vielleicht kann 
einer es mit dem aktuellsten avr-gcc testen. Über Kritik und Anregungen 
freue ich mich natürlich.

Salute,
Alex

[Chris K. (christopher_k25)]

Malte Pöggel schrieb:
> Patch im Anhang, vielleicht kann sowas ja noch mal jemand gebrauchen.

Hi,
Entschuldigt wenn ich jetzt so blöd frage, aber...
Wie wende ich denn diesen Patch auf das Projekt an?

Chrissi

[Lars M. (lars_m65)]

Die brauchs du zum Assemblieren des Bootloaders. Wenn du make eingibst 
und das Script nicht zu deiner avr-gcc Version passt gibts einen Fehler. 
Also Script runterladen und vorhandenes Script aus 
(Beitrag "Re: Peter Danneggers Bootloader (fastboot) für AVR-GCC-Toolchain") ersetzen.

Hier steht es genauer:
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger#Assemblieren_des_Bootloaders_.28Angepasste_Version_f.C3.BCr_AVR-GCC-Toolchain.29

Lars

[Michael (Gast)]

Hallo zusammen!
Ich würde den Bootloader von Peter gerne über RS485 benutzen und brauche 
dafür ein RTS Signal. Jetzt bin ich in Assembler nicht wirklich fit und 
muss raten :-)

In der uart.inc würde ich den code wie folgt ändern - siehe Zeilen 
"???":

putchar:
  sbi  RTS_PORT, TRS           ; set RTS pin ???
  rcall  wait_bit_time
  TXD_0
.if ONEWIRE
  rjmp  _tx2
syncputchar:        ; start with 1->0 from master
  SKIP_RXD_1
  rjmp  syncputchar
_tx1:
  SKIP_RXD_0
  rjmp  _tx1
_tx2:
.else
  lpm  a1, z      ;3
.endif
  ldi  a1, 9      ;1
  com  a0      ;1 = 5
_tx3:
.if CRC
  rjmp  pc+1      ;2
  rjmp  pc+1      ;2
.endif
  rcall  wait_bit_time    ;14 + tw
  lsr  a0      ;1
  brcc  _tx4      ;1/2
  nop        ;1
  TXD_0        ;2
  rjmp  _tx5      ;2
_tx4:
  TXD_1        ;2
  rjmp  _tx5      ;2
_tx5:
  dec  a1      ;1
  brne  _tx3      ;2 = 24 + tw
  cbi  RTS_PORT, TRS           ; clear RTS pin ???
  ret
;-------------------------------------------------------------------------
;  Wait 14 cycle + tw
;
wait_bit_time:
  movw  twh:twl, baudh:baudl  ;1
wait_time:
  sbiw  twh:twl, 4    ;2
  brcc  wait_time    ;2/1
  cpi  twl, 0xFD    ;1
  brcs  _wt1      ;2/1 (2)
  breq  _wt1      ;2/1 (3)
  cpi  twl, 0xFF    ;1
  breq  _wt1      ;2/1 (4/5)
_wt1:
  ret        ;4 + 3 (rcall) = 14
;-------------------------------------------------------------------------

Habe ich mit den Änderungen eine Chance? Seht ihr noch andere Probleme?

Danke,
Michael

[Michael H. (hoffm)]

Hallo Michael,

ohne es zu testen, ist es für mich nicht leicht zu durchschauen, aber 
ich vermute, dass das nicht funktioniert. Hast Du nur in der 
UART.INC-Datei diese beiden Einträge vorgenommen:

sbi  RTS_PORT, TRS           ; set RTS pin ???
cbi  RTS_PORT, TRS           ; clear RTS pin ???

Da sollte dann aber zuvor der RTS-Pin irgendwo auf Ausgang gesetzt 
worden sein. Dafür könnte z.B. in der Datei FASTLOAD.H das zweite Makro 
"IOPortInit" erweitert werden.

Zudem würde ich empfehlen, für das Setzen und Löschen dieses Pins ein 
eigenes Makro zu schreiben. Dein Ansatz wird bei den "kleinen" 
Prozessoren immer funktionieren, denn bei denen kann man AFAIK auf alle 
Pins mit sbi/cbi zugreifen, weil sie als "lower 32 I/O Registers" 
ausgelegt wurden.

Bei den "dicken" 100-Pin AVRs geht das nicht bei allen Pins; in die 
oberen Speicherbereiche müßte man mit "sts" ran. Schau mal bei der 
"fboot21-03.zip"-Version unter FASTLOAD.H bei den Makros für TXD_0/TXD_1 
nach: Falls die PORT-Adresse unter 1fh liegt, nehme ich sbi/cbi, 
ansonsten wie gezeigt.

Gruß
Michael

[Gerhard (Gast)]

Nach nun vielen Stunden Lesen und Suchen immer noch Chaos :-)

Habe den Bootlader schon bei vielen Sachen eingesetzt und funktioniert 
problemlos.

Das aktuelle Thema ist der 1wire-Modus und invertieren der Signale am 
TTL-Adapter. Mit Umprogrammieren der Rx/Tx-Polarität bei FTDI-Chip 
klappt es auch, aber das ist ziemlich lästig. Wie geht es ohne Änderung 
der Polarität?

In der Anwendung wird über die normale UART kommuniziert, auch als 1wire 
(Busleitung beidseitig an Rx, pullup nach Vcc, Tx über Dioden an den 
Bus, das funktioniert problemlos). Nun möchte ich auch über diese 
Leitung den Bootlader ansprechen können, ohne den FTDI jedesmal 
umprogrammieren zu müssen.
Der Pin wäre also PD0 (ATMega168)
.equ    STX_PORT        = PORTD
.equ    STX             = PD0

.equ    SRX_PORT        = PORTD
.equ    SRX             = PD0
In der fastload.h (ohne Ahnung von Assembler)
.if ONEWIRE
  .macro  IOPortInit
  sbi  STX_PORT, SRX    ; weak pullup on
  cbi  STX_DDR, SRX    ; as input
  .endmacro
  .macro  TXD_0
  ;Original sbi
  cbi  STX_DDR, SRX    ; strong pullup = 0
  .endmacro
  .macro  TXD_1
  ;original cbi
  sbi  STX_DDR, SRX    ; weak pullup = 1
  .endmacro
  .macro  SKIP_RXD_0
  ;original sbis
  sbic    SRX_PIN, SRX    ; low = 1
  .endmacro
  .macro  SKIP_RXD_1
  ;original sbic
  sbiS  SRX_PIN, SRX    ; high = 0
  .endmacro

Funktioniert aber nicht :-(
Habe ich was vergessen?

[Basti (Gast)]

Für OneWire unter Windows habe ich Stunden und viele Versuche 
gebraucht...
Dafür habe ich das mal dokumentiert, damit es bei euch dann schneller 
geht:

https://sebastianfoerster86.wordpress.com/2016/05/22/attiny-atmega-uart-bootloader/

[Andy W. (gastandy)]

Hallo zusammen,

ich habe Peter´s Bootloader erfolgreich getestet - soweit alle fein.

Peter schrieb in einem älteren Beitrag, daß zur korrekten 
Baudraten-Erkennung im Passwort zwei aufeianderfolgende Pausenzeiten im 
Verhältnis 1:4 vorkommen müssen.

"Peda"  ist als ASCII codiert hex 50 65 64 61 also
01010000 01100101 01100100 0110001

An welcher Stelle trifft hier das Verhältnis 1:4 zu?
Desweiteren warnte er, daß die Folge 0x20, 0x80 nicht erlaubt wäre, da 
nur die halbe Baudrate erkannt würde. Hier gleiches Problem :-(
00100000 10000000
Wo steckt hier das Verhältnis 2:8, welches zur halben Baudrate führt?

Mein eigentliches Ziel war - in Remineszenz an Peters Bootloader - die 
Passworte entsprechend der Nummer des Busmoduls "Peda1", "Peda2" usw. zu 
vergeben. Da ich die Restriktionen aber gerne verstehen würde, meine 
Frage:

Wäre jemand so nett und könnte das kurz & verständlich erklären?
Ich stehe hier gerade echt auf dem Schlauch...

MFG
Andy

[Michael H. (hoffm)]

Hallo Andy,

die Antwort basiert auf Peters Erklärung aus seiner Assembler Datei 
"ABAUD.INC":

                      ____    __    __ __             ____
e.g. recognize 0x0D:      |__|  |__|  |  |__|__|__|__|
                          0  1  2  3     5           9
                                1*T               4*T
                     LEER  S "1  0  1  1" "0  0  0  0" STOP

S steht hier für START; 0x0D wäre "0000" "1101", aber RS-232 überträgt 
die Bits rückwärts.

Tatsächlich muss mit "1*T" die Länge eines einzigen Bits vorgegeben 
werden.

Gruß
Michael

[Andy W. (Gast)]

Hallo Michael,

Danke für die Erklärung, jetzt ist alles klar - die Sendereihenfolge der 
Bits war es :-)

Wenn ich den Code richtig verstehe, steht meinem Vorhaben Peda1, Peda2 
usw. für die einzelnen Module als Bootloaderpasswort zu verwenden, 
nichts im Wege.
Durch das "a" in Peda erfolgt die Erkennung der Baudrate, so dass die 
nachfolgende Zahl keinen Einfluss mehr haben sollte und das Passwort 
wird ja darauf als Ganzes abgefragt.

MFG
Andy

[Bernhard M. (boregard)]

Hi,

das 'a' zum erkennen braucht man nicht im Passwort zu haben.
Ich sende vom PC aus immer mit 0x0d, also carriage return vor dem 
Passwort, das geht nämlich auch zum erkennen.
Dann kann das Passwort beliebig sein...

Gruß,
Bernhard

[Andy W. (Gast)]

Hallo Bernhard,

Danke für das Feedback, da werde ich das mit den verschiedenen 
Passworten  umsetzen können - Prinzip verstanden :-)

MFG
Andy

[Karl M. (Gast)]

Meisterlampe schrieb:
> avrasm2 -fi bootload.asm

was ist denn das für ein Mist ?

Es gibt doch ein Makefile, dass alle Abhängigkeiten beachtet und den 
Bootloader sicher übersetzt !

[Frankl (Gast)]

Funktioniert das Upload Programm auch mit Fastload_V14 ?
Habe ich nur die Info mit 8Mhz kein Problem, funktioniert es auch mit 
>14 Mhz?

[H.Joachim S. (crazyhorse)]

Nachdem der bootloader eigentlich immer und überall funktioniert hat und 
ich den auch sehr oft einsetze - mit dem Tiny441 gehts nicht.
Blöderweise gibts schon keine "offizielle" tn441def.inc (nur noch den 
xml-Kram), aber ich denke ich habe die halbwegs richtig erstellt, werde 
das aber noch mal überprüfen.
Ich habs für PA2 im one-wire modus erstellt, aber keine Verbindung 
(Hardware/Com-Port definitiv i.O., selfprog fuse gesetzt).

Eh ich mich jetzt durchs Assemblerprogramm quäle: hat sich schon mal 
jemand damit befasst. Könnte es an der leicht veränderten Portstruktur 
mit dem PUE-Register liegen?

Angepasst habe ich folgendes:

; ***** DATA MEMORY DECLARATIONS 
*****************************************
.equ  FLASHEND  = 0x07ff  ; Note: Word address
.equ  IOEND  = 0x003f
.equ  SRAM_START  = 0x0100
.equ  SRAM_SIZE  = 256
.equ  RAMEND  = 0x01ff
.equ  XRAMEND  = 0x0000
.equ  E2END  = 0x00ff
.equ  EEPROMEND  = 0x00ff
.equ  EEADRBITS  = 8
#pragma AVRPART MEMORY PROG_FLASH 4096
#pragma AVRPART MEMORY EEPROM 256
#pragma AVRPART MEMORY INT_SRAM SIZE 256
#pragma AVRPART MEMORY INT_SRAM START_ADDR 0x100



; ***** BOOTLOADER DECLARATIONS 
******************************************
.equ  NRWW_START_ADDR  = 0x0
.equ  NRWW_STOP_ADDR  = 0x7ff
.equ  RWW_START_ADDR  = 0x0
.equ  RWW_STOP_ADDR  = 0x0
.equ  PAGESIZE  = 32


Wenn ich das richtig verstanden habe, benutzt der bootlader mehr oder 
weniger nur den Kern, den RAM und die entsprechenden Ports (die liegen 
auch beim 441 im normalen I/O-Bereich). Der RAM beginnt wegen extended 
I/O erst bei 0x100.
Benutzt der bootlader diese Informationen über den RAM oder geht der 
stur von 0x60 Startadresse + RAM-Grösse aus?

[H.Joachim S. (crazyhorse)]

Das stimmt jedenfalls schon mal nicht. Dem stack dürfte das noch rel. 
egal sein, das Problem dürfte dann aber im Bereich 0x60...0xff zu finden 
sein.
Bzw. was ich falsch gemacht habe mit den Speicherangaben.

[H.Joachim S. (crazyhorse)]

Ok, das mit dem Speicher war Quatsch, man sollte die Änderungen auch 
speichern...RAM stimm jetzt.

[H.Joachim S. (crazyhorse)]

So, nun antwortet er wenigstens, und beginnt das update auch.
Die ersten 16 Bytes werden auch korrekt geschrieben, incl. gepatchtem 
Reset-Sprung auf den Bootlader.
Dessen erste 32 Byte werden allerdings gelöscht (ursprünglich begann der 
auf 0x710)
Damit beginnt mein Testprogramm:
:0400000046C0FECF29
:10000400CCC0FCCFFBCFFACFF9CFF8CFFFC0EDC007
:10001400EDC0F4CFF3CFF2CFF1CFF0CFEFCFEECFEF
:10002400EDCFECCFEBCFEACF5EC0E8CF91C0E6CF07
:10003400E5CFE4CFE3CFE2CFE1CF2B37513C4E6A9B


Naja, werde mal weiter suchen.

[H.Joachim S. (crazyhorse)]

Das wirds wohl sein: 4-page erase, d.h. SPM löscht direkt 4 
aufeianderfolgende pages. Anschleissend müssen 4 einzelne pages 
geschrieben werden (bzw. evtl vorher gesichert werden). Das wird mehr 
Aufwand als ich dachte.

[H.Joachim S. (crazyhorse)]

Hm, Assembler ist nicht mehr mein Ding....

In der tn441def.inc:

.equ  PAGESIZE  = 8
.equ    PAGESIZE_ERASE = 4*PAGESIZE

in der fastload.h
.else
  .ifndef PAGESIZE_ERASE
    .equ  BootStart  = ((FlashEnd - BootSize) / PageSize * PageSize)
  .else
     .equ  BootStart  = ((FlashEnd - BootSize) / PageSize_Erase * 
PageSize_Erase)
   .endif
.equ  BufferSize  = PageSize
  .equ  UserFlash  = (2*BootStart - 2)
  .equ  Application  = BootStart - 1
.endif

und in der progtiny:

.else
  .ifndef PAGESIZE_ERASE
          subi    zl, low (2*PageSize)
    sbci    zh, high(2*PageSize)
        .else
          subi    zl, low (2*PageSize_Erase)
    sbci    zh, high(2*PageSize_Erase)
        .endif
.endif

Damit landet die Bootlader-Startadresse schon mal auf einer passenden 
Startadresse und das Löschen funktioniert ohne Teile des Bootladers zu 
löschen.
Aber das Neuschreiben funktioniert nur auf der ersten page, ab Adresse 
0x010 meckert er.

Irgendwo da müsste ein Fehler stecken, ich seh aber keinen:

;---------------------- Next Page 
----------------------------------------
.if PageSize < 32
  adiw  zh:zl, 2*PageSize
.else
  subi  zl, low (-PageSize * 2)
  sbci  zh, high(-PageSize * 2)  ; point to next page
.endif
  brts  _pro8
  ldi  a0, CONTINUE
  rcall  putchar
_pro8:
  cpi  zl, low( 2*BootStart)
  ldi  a0, high(2*BootStart)
  cpc  zh, a0                  ; last page reached ?
  brcs  Program
  brts  _pro9
  rjmp  main_error    ; error, size exceeded
_pro9:
  rjmp  main_ok

Gibts noch andere Typen, die auch nur 8 word pagesize haben?

Fehlermeldung vom UpdateLoader 2.2:
Firmware-Update gestartet (3kiB)
Achtung: Kleiner Sendepuffer!
Zeitüberschreitung (0x000010)
Fehler beim Firmware-Update, Ausführung abgebrochen

[H.Joachim S. (crazyhorse)]

So klappts, könnte man noch ausbauen.


tn441def.inc:
PageSize = 8

fastload.h:
  .equ  UserFlash  = (2*BootStart)
  .equ  Application  = 0
.else
     #ifndef TN441DEF_INC
      .equ  BootStart  = ((FlashEnd - BootSize) / PageSize * PageSize)
     #else
      .equ  BootStart  = ((FlashEnd - BootSize) / (PageSize*4) * 
(4*PageSize))
     #endif
.equ  BufferSize  = PageSize
  .equ  UserFlash  = (2*BootStart - 2)
  .equ  Application  = BootStart - 1
.endif

damit der Bootlader auf einer passenden Adresse beginnt.

progtiny.inc:

_pro4:
#ifndef  TN441DEF_INC
 .if PageSize < 32
  sbiw  zh:zl, 2*PageSize
 .else
    subi    zl, low (2*PageSize)
    sbci    zh, high(2*PageSize)
 .endif
#else
    subi    zl, low (2*PageSize*4)
    sbci    zh, high(2*PageSize*4)
#endif
  ldi  a0, 1<<PGERS^1<<SPMEN
  out     SPMCSR, a0
  SPM                             ; CPU halted until erase done
  brne    _pro4      ; until Z = 0x0000


Eigentlich ganz einfach :-) Nun könnte man noch das Verhältnis 
page_erase/page_write angeben, mir reicht erstmal dieser eine 
Spezialfall.

[IsDochEgal (Gast)]

Original-Bootloader fboot21

onewire an t85 @ 8Mhz via USB-UART (also "TTL" Pegel, nicht RS-232!) 
erfordert die Invertierung

in fastload.h

.if ONEWIRE
  .macro  IOPortInit
  sbi  STX_PORT, SRX    ; weak pullup on
  cbi  STX_DDR, SRX    ; as input
  sbi  STX_DDR, PB0    ; debug
  sbi  STX_PORT, PB0    ; debug
  .endmacro
  .macro  TXD_0
  ; sbi  STX_DDR, SRX    ; strong pullup = 0
  sbi  STX_DDR, SRX    ; output
  cbi  STX_PORT, SRX    ; low
  .endmacro
  .macro  TXD_1
  ; cbi  STX_DDR, SRX    ; weak pullup = 1
  cbi  STX_DDR, SRX    ; input
  sbi  STX_PORT, SRX    ; high (pullup)
  .endmacro
  .macro  SKIP_RXD_0
  ; sbis  SRX_PIN, SRX    ; low = 1
  sbic  SRX_PIN, SRX    ; low = 0
  .endmacro
  .macro  SKIP_RXD_1
  ; sbic  SRX_PIN, SRX    ; high = 0
  sbis  SRX_PIN, SRX    ; high = 1
  .endmacro
.else

Das beeinflusst sehr wahrscheinlich das Timing!

"Gebaut" unter Windows:

    rem copy "C:\Program Files 
(x86)\Atmel\Studio\7.0\packs\atmel\ATtiny_DFP\1.3.229\avrasm\inc\tn85def 
.inc"  tn85def.inc
    "C:\Program Files 
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\avrasm2.exe" -fI 
BOOTLOAD.ASM

Geflasht mit

    avrdude.exe -vv -P USB -c usbasp -B 10 -p t85 -U 
flash:w:BOOTLOAD.hex:i -U lfuse:w:0xE2:m -U hfuse:w:0xdf:m -U 
efuse:w:0xfe:m

Eigentliches Programm dann übertragen mit fboot-win-devcpp-mod, gebaut 
mit mingw (gcc)

    fboot-win-devcpp-mod>g++ fboot.cpp serial.cpp

Parameter:

a /?
/?               Get this help message
/Bnnnn           Define baud rate
/Cn              Define serial port n = 1..16
/Pname           Perform Program
/Vname           Perform Verify
/Rstring         Reset string
/Istring         Init string

Und dann

a /Pfirmware.hex

******* Push Reset Botton *******

COM 3 at 57600 Baud: Connected (One wire)
Bootloader V2.1
Target: 1E930B F
Buffer: 64 Byte
Size available: 7678 Byte
Program firmware.hex: 00000 - 003C3 successful
CRC: o.k.
Elapsed time: 0.00 seconds

[IsDochEgal (Gast)]

Bei 1MHz XTAL (F_CPU) geht es immerhin mit 19200 baud.

[IsDochEgal (Gast)]

Gibt es eine Möglichkeit, den Bootloader per Bootloader zu ersetzen (ich 
habe Reset deaktiviert und keinen HV-Programmer)?

[Malte _. (malte)]

Du müsstest ein Programm schreiben, welches den Bootloader überschreibt 
und das mit dem ersten Bootloader flashen. Allerdings vermute ich, dass 
du damit nicht die Fuses ändern kannst. Der neue dürfte also nicht 
größer sein.
Falls es sich um einen Tiny im DIL Gehäuse mit serieller HV 
Programmiermöglichkeit (zb TinyX4, TinyX5) handelt, kann man auch auf 
dem Steckbrett einen HV Programmer zusammen stecken. Braucht eigentlich 
nur einen weiteren AVR, 12V Netzteil und zwei Transistoren.

[IsDochEgal (Gast)]

Ja danke, siehe auch Beitrag "AVR bootloader per bootloader überschreiben (fastboot)?"