Hallo Sebastian, super, danke. Bitte hänge noch fboot.exe an.
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.
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
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
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
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
Angehängte Dateien:
-
Fehler.png
170 KB
Ich Habe einen Screnprint mit dem Fehler gemacht! Danke für Eure Hilfe Peter
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
in dem link von oben ist ein build drin. du musst es nicht selber compilieren.
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 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?
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
Nachtrag mit dem Kommandozeilenprogramm auf einem XP Rechner funktioniert der Bootloader. Also sollte der Bootloader auf dem Atmel richtig erstellt sein. Peter
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?
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!
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?
1 | ;------------------------------------------------------------------------- |
2 | ; Port definitions |
3 | ;------------------------------------------------------------------------- |
4 | ; set both lines equal for inverted onewire mode: |
5 | |
6 | .equ STX_PORT = PORTJ |
7 | .equ STX = PJ1 |
8 | |
9 | .equ SRX_PORT = PORTJ |
10 | .equ SRX = PJ0 |
11 | ;------------------------------------------------------------------------- |
12 | .include "fastload.inc" |
13 | ;------------------------------------------------------------------------- |
Vielen Dank. Gruß Steffen
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
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.
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?
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
Angehängte Dateien:
-
Fuses.jpg
120 KB
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.
1 | .equ VERSION = 0x0201 |
2 | |
3 | .equ XTAL = 16000000 ; 8MHz, not critical |
4 | .equ BootDelay = XTAL / 3 ; 0.XXs |
Ich habe als Pins folgendes eingestellt:
1 | .equ STX_PORT = PORTD |
2 | .equ STX = PD1 |
3 | |
4 | .equ SRX_PORT = PORTD |
5 | .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:
1 | Bootsz: 512 |
2 | 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
Gekreuzt.... Also: TTL RX - Mega TX TTL TX - Mega RX Habe es aber auch schonmal nicht gekreuzt probiert.... War mein erster verdacht
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
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
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
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
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
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
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
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.
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
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
Angehängte Dateien:
-
FastBoot_FTDI.png
5,5 KB
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.
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
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
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
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
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 "???":
1 | putchar: |
2 | sbi RTS_PORT, TRS ; set RTS pin ??? |
3 | rcall wait_bit_time |
4 | TXD_0 |
5 | .if ONEWIRE |
6 | rjmp _tx2 |
7 | syncputchar: ; start with 1->0 from master |
8 | SKIP_RXD_1 |
9 | rjmp syncputchar |
10 | _tx1: |
11 | SKIP_RXD_0 |
12 | rjmp _tx1 |
13 | _tx2: |
14 | .else |
15 | lpm a1, z ;3 |
16 | .endif |
17 | ldi a1, 9 ;1 |
18 | com a0 ;1 = 5 |
19 | _tx3: |
20 | .if CRC |
21 | rjmp pc+1 ;2 |
22 | rjmp pc+1 ;2 |
23 | .endif |
24 | rcall wait_bit_time ;14 + tw |
25 | lsr a0 ;1 |
26 | brcc _tx4 ;1/2 |
27 | nop ;1 |
28 | TXD_0 ;2 |
29 | rjmp _tx5 ;2 |
30 | _tx4: |
31 | TXD_1 ;2 |
32 | rjmp _tx5 ;2 |
33 | _tx5: |
34 | dec a1 ;1 |
35 | brne _tx3 ;2 = 24 + tw |
36 | cbi RTS_PORT, TRS ; clear RTS pin ??? |
37 | ret |
38 | ;------------------------------------------------------------------------- |
39 | ; Wait 14 cycle + tw |
40 | ; |
41 | wait_bit_time: |
42 | movw twh:twl, baudh:baudl ;1 |
43 | wait_time: |
44 | sbiw twh:twl, 4 ;2 |
45 | brcc wait_time ;2/1 |
46 | cpi twl, 0xFD ;1 |
47 | brcs _wt1 ;2/1 (2) |
48 | breq _wt1 ;2/1 (3) |
49 | cpi twl, 0xFF ;1 |
50 | breq _wt1 ;2/1 (4/5) |
51 | _wt1: |
52 | ret ;4 + 3 (rcall) = 14 |
53 | ;------------------------------------------------------------------------- |
Habe ich mit den Änderungen eine Chance? Seht ihr noch andere Probleme? Danke, Michael
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
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?
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/
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
Hallo Andy, die Antwort basiert auf Peters Erklärung aus seiner Assembler Datei "ABAUD.INC":
1 | ____ __ __ __ ____ |
2 | e.g. recognize 0x0D: |__| |__| | |__|__|__|__| |
3 | 0 1 2 3 5 9 |
4 | 1*T 4*T |
5 | 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
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
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
Hallo Bernhard, Danke für das Feedback, da werde ich das mit den verschiedenen Passworten umsetzen können - Prinzip verstanden :-) MFG Andy
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 !
Funktioniert das Upload Programm auch mit Fastload_V14 ?
Habe ich nur die Info mit 8Mhz kein Problem, funktioniert es auch mit
>14 Mhz?
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?
Angehängte Dateien:
-
fastboot441.PNG
21 KB
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.
Ok, das mit dem Speicher war Quatsch, man sollte die Änderungen auch speichern...RAM stimm jetzt.
Beitrag #5480104 wurde von einem Moderator gelöscht.
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.
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.
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
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.
Original-Bootloader fboot21 onewire an t85 @ 8Mhz via USB-UART (also "TTL" Pegel, nicht RS-232!) erfordert die Invertierung in fastload.h
1 | .if ONEWIRE |
2 | .macro IOPortInit |
3 | sbi STX_PORT, SRX ; weak pullup on |
4 | cbi STX_DDR, SRX ; as input |
5 | sbi STX_DDR, PB0 ; debug |
6 | sbi STX_PORT, PB0 ; debug |
7 | .endmacro |
8 | .macro TXD_0 |
9 | ; sbi STX_DDR, SRX ; strong pullup = 0 |
10 | sbi STX_DDR, SRX ; output |
11 | cbi STX_PORT, SRX ; low |
12 | .endmacro |
13 | .macro TXD_1 |
14 | ; cbi STX_DDR, SRX ; weak pullup = 1 |
15 | cbi STX_DDR, SRX ; input |
16 | sbi STX_PORT, SRX ; high (pullup) |
17 | .endmacro |
18 | .macro SKIP_RXD_0 |
19 | ; sbis SRX_PIN, SRX ; low = 1 |
20 | sbic SRX_PIN, SRX ; low = 0 |
21 | .endmacro |
22 | .macro SKIP_RXD_1 |
23 | ; sbic SRX_PIN, SRX ; high = 0 |
24 | sbis SRX_PIN, SRX ; high = 1 |
25 | .endmacro |
26 | .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:
1 | a /? |
2 | /? Get this help message |
3 | /Bnnnn Define baud rate |
4 | /Cn Define serial port n = 1..16 |
5 | /Pname Perform Program |
6 | /Vname Perform Verify |
7 | /Rstring Reset string |
8 | /Istring Init string |
Und dann
1 | a /Pfirmware.hex |
2 | |
3 | ******* Push Reset Botton ******* |
4 | |
5 | COM 3 at 57600 Baud: Connected (One wire) |
6 | Bootloader V2.1 |
7 | Target: 1E930B F |
8 | Buffer: 64 Byte |
9 | Size available: 7678 Byte |
10 | Program firmware.hex: 00000 - 003C3 successful |
11 | CRC: o.k. |
12 | Elapsed time: 0.00 seconds |
Gibt es eine Möglichkeit, den Bootloader per Bootloader zu ersetzen (ich habe Reset deaktiviert und keinen HV-Programmer)?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.