Datum: 08.07.2007 18:22
Angehängte Dateien:Hier ist nun mein neuer Bootloader V1.4 Die Programmierzeiten sind z.B.: ATtiny13: 0,8s ATmega8: 1,8s ATmega644: 8,2s Hinzugekommen ist ein CRC-Check und eine Verify-Funktion. Bei den ATtinys kann man sie deaktivieren, bringt bis zu 64Byte mehr Flash für die Applikation. Peter
Datum: 09.07.2007 09:35
Hallo Peter, eine Frage: Was genau bedeutet die "BufferSize", bzw. was meinst Du mit "Attention: BufferSize must fit perfectly into BootStart!"? Beim ATmega8 z.B. ist BufferSize = 15*PageSize = 15*32 = 480 = 0x1E0 (warum dieser Wert?). Beim ATmega168: BufferSize = 4*PageSize = 4*64 = 256 = 0x100 Ich Frage, da ich den Bootloader mit einem ATmega88 verwende, der eine PageSize von 32 hat. Ergo müsste ich bei BufferSize "8*PageSize" bei Verwendung der BOOTSTART-Adresse 0x0F00 eintragen, oder? Meine Feststellung ist nämlich, dass jeder Multiplikator zwischen 2 und 12 funktioniert (weiter hab ich´s nicht getestet). Ich wäre Dir für eine kurze Erklärung sehr dankbar! ciao Michael
Datum: 09.07.2007 15:19
Windows mag es nicht, wenn man immer nur ein Byte über die UART sendet. Man sollte also möglichst große Blöcke senden, dann geht es wesentlich schneller. Daher richte ich im SRAM einen Puffer ein und sage der PC-Software, wie groß dieser Puffer ist. Diese Puffergröße muß natürlich ein Vielfaches der Pagegröße sein. Um den Bootloader klein zu halten, programmiert er immer komplette Puffer. Daher muß die Puffergröße exakt, d.h. ohne Rest in den Userbereich passen. Oder anders gesagt: n * Puffergröße = Bootstart. Peter
Datum: 11.07.2007 16:23
Hallo Peter, in dem anderen Thread schreibst Du, "die Programmierpins sind frei wählbar"... Kannst Du evtl. für die Noobs (wie ich ;-) ) ein paar Zeilen zum Einstieg schreiben, welche Pins jetzt benutzt werden, wie und wo man diese ändert, wie das Programmieren funktioniert usw. Also eine kurze Anleitung? Wäre echt prima und sicher für viele sehr hilfreich. Vielen Dank Andreas
Datum: 11.07.2007 16:32
Hallo Andreas, wie Peter schon schrieb, die Programmierpins sind frei wählbar, da die serielle Schnittstelle als Softwarelösung implementiert ist. Die Konfiguration der beiden Pins kannst Du in dem Deinem Mikrocontroller entsprechenden *.asm-File abändern und dann mit z.B. AVR-Studio das Hex-File für den Controller erzeugen. Auf dem Weg nochmal Danke Peter für Deine Antwort. Jetzt habe ich verstanden dass Du mit Bootstart die Bootstart-Adresse meinst. ciao Michael
Datum: 11.07.2007 17:31
Hallo Peter, super Teil dein Bootloader. Hab ihn gerade auf ATMega64 und RS-485 Schnittstelle angepasst und er läuft! Jetzt muss ich nur noch das PC-Programm auf Dev-C++ portieren, da ich kein Borland C++ habe. Vielen Dank andie.
Datum: 11.07.2007 21:55
Andreas wrote: > Kannst Du evtl. für die Noobs (wie ich ;-) ) ein paar Zeilen zum > Einstieg schreiben, welche Pins jetzt benutzt werden, wie und wo man > diese ändert, wie das Programmieren funktioniert usw. Also eine _kurze_ > Anleitung? Die Pins können in folgenden Zeilen geändert werden
; Sendepin: .equ STX_PORT = PORTB .equ STX_DDR = DDRB .equ STX = PB1 ;Empfangspin: .equ SRX_PIN = PINB .equ SRX_PORT = PORTB .equ SRX = PB0 |
Peter
Datum: 15.07.2007 14:43
Kann mir einer verraten wie ich den sourcecode kopilieren kann? Habe es mit AVR Studio versucht ... kriege es aber leider nicht hin :-(
Datum: 15.07.2007 14:51
Diese Fehlermeldung bekomme ich: AVRASM: AVR macro assembler 2.1.12 (build 87 Feb 28 2007 07:31:13) Copyright (C) 1995-2006 ATMEL Corporation C:\Documents and Settings\Admin\My Documents\AVR Projects\fastload_V14\ABAUD.INC(18): error: zl: Unknown instruction or macro C:\Documents and Settings\Admin\My Documents\AVR Projects\fastload_V14\ABAUD.INC(18): error: syntax error, unexpected ',' Assembly failed, 2 errors, 0 warnings
Datum: 15.07.2007 15:25
Sehe ich das richtig, dass AVRs mit mehr als 64k Flash (z. B. ATm128) nicht unterstützt werden?
Datum: 15.07.2007 16:15
Richard wrote: > Kann mir einer verraten wie ich den sourcecode kopilieren kann? > > Habe es mit AVR Studio versucht ... kriege es aber leider nicht hin :-( Du öffnest die Datei, die Du assemblieren willst, z.B. t13.asm. Die anderen (*.inc, *.h) müssen sich im gleichen Verzeichnis befinden. Peter
Datum: 15.07.2007 16:19
Uwe wrote: > Sehe ich das richtig, dass AVRs mit mehr als 64k Flash (z. B. ATm128) > nicht unterstützt werden? Ja, der ATMega644 ist mein größter, größere habe ich nicht. Hab ihn aber auch nur aus Interesse gekauft, weiß noch nicht, womit ich ihn vollkriegen kann. Peter
Datum: 15.07.2007 16:21
Ist es viel Aufwand, den ATM128 noch mit einzubauen?
Datum: 15.07.2007 16:56
Uwe wrote: > Ist es viel Aufwand, den ATM128 noch mit einzubauen? Im Prinzip nicht. Die meisten Änderungen sind am PC Programm. Ich müßte mir ansehen, wie ein Segmentrecord funktioniert (bisher ignoriere ich ihn) und alle Pointer, Adreßzähler auf long umstellen und ein farmemset selber schreiben. Auf dem AVR muß ich RAMPZ mitzählen und ESPM, ELPM benutzen, sollte max 10 Worte kosten. Ich kanns aber nicht testen. Peter
Datum: 15.07.2007 17:15
Hallo Peter, kann man den alten Borland C-Compiler legal irgendwo runterladen? Oder ist der immer noch kostenpflichtig? Schöne Grüße, Techniker
Datum: 15.07.2007 19:11
Kann mir einer sagen was ich falsch mache?
C:\AVR_programm>FBOOT.EXE /PLED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds
C:\AVR_PR~1>FBOOT.EXE /PC:\AVR_programm\LED_mega32.hex
COM 1 at 115200 Baud: Connected
Bootloader V1.4
Target: 1E9502 ATmega32
Buffer: 1792 Byte
Size available: 32256 Byte
File C:\AVR_programm\LED_mega32.hex open failed !
CRC: o.k.
Elapsed time: 0.00 seconds
C:\AVR_PR~1>
Die Datein liegen so:
C:\AVR_PR~1>dir
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: 1819-D039
Verzeichnis von C:\AVR_PR~1
15.07.2007 19:08 <DIR> .
15.07.2007 19:08 <DIR> ..
07.07.2007 16:20 16.441 FBOOT.EXE
15.07.2007 19:05 1.036 LED_mega32.hex
2 Datei(en) 17.477 Bytes
2 Verzeichnis(se), 66.330.902.528 Bytes frei
C:\AVR_PR~1>
Danke
Datum: 15.07.2007 19:23
FBOOT.EXE /PC:\AVR_PR~1\LED_mega32.hex |
so vielleicht?
Datum: 15.07.2007 19:35
Diese DOS-Anwendung kann leider keine langen Pfad- und Dateinamen (max 8.3). Peter
Datum: 15.07.2007 20:00
Geht aber auch nicht :-( C:\AVR>FBOOT.EXE /PLED_mega32.hex COM 1 at 115200 Baud: Connected Bootloader V1.4 Target: 1E9502 ATmega32 Buffer: 1792 Byte Size available: 32256 Byte File LED_mega32.hex open failed ! CRC: o.k. Elapsed time: 0.00 seconds C:\AVR>FBOOT.EXE /PC:\AVR\LED_mega32.hex COM 1 at 115200 Baud: Connected Bootloader V1.4 Target: 1E9502 ATmega32 Buffer: 1792 Byte Size available: 32256 Byte File C:\AVR\LED_mega32.hex open failed ! CRC: o.k. Elapsed time: 0.00 seconds C:\AVR>
Datum: 15.07.2007 20:15
LED_mega32.hex der dateiname ist immer noch 10 buchstaben lang ;)
Datum: 15.07.2007 20:23
Stimmt!
BOOT.EXE /PLED_me~1.hex |
PS: Dann war obige Antwort auch nicht richtig. Da ist nur der Pfadname korrekt, der Dateiname aber immernoch zu lang.
Datum: 15.07.2007 21:00
Asoo, Dateiname ... ich dachte Pfad^^. Danke jetzt geht es. Hab aber folgendes Problem: Habe erfolgreich folgendes Programm draufgespielt:
#include <avr/io.h> // Sollte normalerweise schon im Makefile definiert sein. // In dem Fall hier einfach löschen. #define F_CPU 11059200 #define BAUD 2400UL #define UBRR_BAUD ((F_CPU/(16UL*BAUD))-1) void ioinit(void); void delay_ms(unsigned int ms); void uart_init(void); // USART initialisieren void uart_init(void) { // Baudrate einstellen (Normaler Modus) UBRRH = (uint8_t) (UBRR_BAUD>>8); UBRRL = (uint8_t) (UBRR_BAUD & 0x0ff); // Aktivieren von receiver und transmitter UCSRB = (1<<RXEN)|(1<<TXEN); // Einstellen des Datenformats: 8 Datenbits, 1 Stoppbit UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); } // Hauptprogramm int main(void) { unsigned char i; ioinit(); uint8_t buffer; // USART initialisieren // uart_init(); // Endlosschleife while (1) { PORTD ^= (1 << PD7); // Eine Sekunde warten delay_ms(1000); } return 0; } // Initialisierung void ioinit(void) { DDRD = 0xff; // PortB als Ausgang deklarieren PORTD = 0x00; // Ports auf LOW schalten } // Warteschleife void delay_ms(unsigned int ms) { unsigned int zaehler; while (ms) { zaehler = F_CPU / 5000; while (zaehler) { asm volatile("nop"); zaehler--; } ms--; } } |
Das Programm funktioniert auch ... aber jetzt kann ich kein neues
Programm brauchspielen .. er kann sich nicht mehr connecten.
Liegt es daran weil ich komplett die Ports D:
DDRD = 0xff; // PortB als Ausgang deklarieren
PORTD = 0x00; // Ports auf LOW schalten
als ausgang geschaltet habe und meine Pins beim Bootloader sind auch die
von PortD:;------------------------------------------------------------------------- ; Port definitions ;------------------------------------------------------------------------- .equ STX_PORT = PORTD .equ STX_DDR = DDRD .equ STX = PD1 .equ SRX_PIN = PIND .equ SRX_PORT = PORTD .equ SRX = PD0 ;------------------------------------------------------------------------- .include "fastload.inc" ;------------------------------------------------------------------------- |
Datum: 15.07.2007 21:15
Richard wrote:
> Asoo, Dateiname ... ich dachte Pfad^^. Danke jetzt geht es.
Beides.
Datum: 15.07.2007 21:38
Ich habe ein bisschen rumprobiert ... habe jetzt andere pins benutzt ... das komische ist aber .. ich kann nur einfach eine hex draufspielen.
C:\AVR>FBOOT.EXE /PLED.hex COM 1 at 115200 Baud: Connected Bootloader V1.4 Target: 1E9502 ATmega32 Buffer: 1792 Byte Size available: 32256 Byte Program LED.hex: 0000 - 016B successful CRC: o.k. Elapsed time: 0.33 seconds C:\AVR>FBOOT.EXE /PLED.hex COM 1 at 115200 Baud: / Aborted C:\AVR>FBOOT.EXE /PLED.hex COM 1 at 115200 Baud: - Aborted C:\AVR>FBOOT.EXE /PLED.hex COM 1 at 115200 Baud: | |
Bei allen anderen versuchen geht es nicht, wenn ich schon einmal gebrannt habe. ;-( Muss ich irgendwas an den Security bits umstellen?
Datum: 15.07.2007 21:50
Der Startet sofort das Programm ... nicht den Bootloader. Wieso? Wie muss ich mein Programm ändern ... damit es immer funktioniert?
Datum: 15.07.2007 22:13
Richard wrote:
> Muss ich irgendwas an den Security bits umstellen?
Die Fuses: firstboot und boot reset
sonst kann er ja den Bootloader nicht finden.
Bei nem leeren MC rauscht er durch die 0xFFFF durch bis zum Bootloader.
Peter
Datum: 15.07.2007 23:01
Ahhh danke für die Info. Welche Bits sind es in PonyProg sprache? http://mikrocontroller.cco-ev.de/php/counter/count... Heißt das ich muss bei BootLock01 ein häckchen machen und bei BOOTRST ?? Danke im voraus.
Datum: 16.07.2007 11:42
Hallo PeDa, ist in der Abaud Funktion noch ein Bug enthalten? Wenn RxD immer High bleibt kommt es nie zum Timeout, da die Prüfung nach dem SKIP_RXD_O stattfindet. Bei der TinyLoad 1v3 wurde vorher geprüft. Vielleicht habe ich aber auf das ganze noch nicht richtig durchschaut.
Datum: 16.07.2007 23:50
Gasti wrote:
> Vielleicht habe ich aber auf das ganze noch nicht richtig durchschaut.
Stimmt
Auf das SKIP folgt kein RJMP, d.h. auch bei einem Timeout wird nicht
mehr zum Schleifenanfang gesprungen.
Peter
Datum: 17.07.2007 10:52
Hat jemand von euch schon das FBoot Programm von Peter auf Dev-C++ portiert? Habe keine inportb() und outportb() Funktionen zur Verfügung. Würde mich über jede Hilfe freuen. andie.
Datum: 17.07.2007 11:13
@Andreas Kasper Ich bin dabei eine Win32 Anwendung zu machen mit GUI etc.
Datum: 17.07.2007 12:15
Ich hab das ganze gerade auf VC++ umgeschrieben, da ich das ganze an einem USB-RS232 Wandler betreibe. Im Prinzip muss man nur noch einige casts hinzufügen und die seriellen Schnittstellenroutinen ändern. Hat jemand eine Idee wie man den Bootloader starten könnte, wenn es keinen Reset Knopf gibt, der AVR über USB versorgt wird, und ebenso der FT232, der COM-Port also nicht vor dem Einschalten des AVRs geöffnet sein kann ?
Datum: 17.07.2007 12:58
Im controller eine resetfunktion implementieren? Also, irgend ein zeichen bzw steuercode über rs232 der dann den watchdog einschaltet und wartet?
Datum: 17.07.2007 13:18
Benedikt K. wrote: > Hat jemand eine Idee wie man den Bootloader starten könnte, wenn es > keinen Reset Knopf gibt, der AVR über USB versorgt wird, und ebenso der > FT232, der COM-Port also nicht vor dem Einschalten des AVRs geöffnet > sein kann ? Nimmste eben eins von den Handshakesignalen (RTS, DTR) und knallst es an den Resetpin. Und im PC-Programm wird es dann kurz gepulst. Peter
Datum: 21.07.2007 10:44
Wirklich grossartig... Ist denn auch eine Halb-Duplex-Kommunikation auf einem Pin konfigurierbar ? Gerade auf den 8-Pin-Prozessoren wäre das ungemein hilfreich... dafür würde ich gern auch noch ein wenig Speicher opfern; denn da ist man bei den neuen Tinys ja recht flexibel :) Vielen Dank noch einmal ! Gruß, Stefan ---
Datum: 21.07.2007 15:55
Angehängte Dateien:Stefan wrote: > Ist denn auch eine Halb-Duplex-Kommunikation auf einem Pin > konfigurierbar ? > Gerade auf den 8-Pin-Prozessoren wäre das ungemein hilfreich... dafür > würde ich gern auch noch ein wenig Speicher opfern; denn da ist man bei > den neuen Tinys ja recht flexibel :) Ist gerade in Arbeit, anbei schonmal der Schaltplan. Die Dioden sind nur zum Schutz, wer Lust hat, kanns auch ohne probieren. 6 IO-Pins zu haben und trotzdem neu brennen zu können (ohne Fuses !), hat schon was. Es sieht auch ganz gut aus, fehlt noch der Feinschliff. Die Prolific-Dongle haben das viele RX-Traffic nicht ausgehalten und Bytes verschluckt und vertauscht (!), wenn einige Bytes 0x13 waren. Ich bin fast verrückt geworden beim Debuggen. Bis ich dann den FTDI benutzt habe, da lief alles. Dann habe ich den neuen Profilic-Treiber installiert und dann gings auch. Der Treiber muß von 2005 sein (der alte war von 2003). Allerdings sinkt die Downloadrate auf 25%, wenn die Bytes 0x13 sind. Für das 1-wire mußte ich auch noch das Protokoll etwas umstellen. Ich muß mal das 2-wire überprüfen, ob das noch geht. Die PC-Software erkennt den Modus automatisch und schmeißt dann alle Echos weg, so daß nur die echten Antworten übrig bleiben. Damit die Paßworterkennung funktioniert, sendet der PC noch ein 0xFF dahinter und der AVR wartet auf das Starbit und hängt das Antwortbyte daran an. Falls das fehlschlägt, macht es der AVR immer wieder, daher sollte das Paßwort eine gerade Anzahl Zeichen haben. Daß das Zeichen 'a' im Paßwort vorkommen muß, hat vielleicht schon jemand gemerkt. Die Baudratenerkennung akzeptiert nur bestimmte Zeichen, um eine Fehlerkennung (doppelte Bitzeit) zu vermeiden. Peter
Datum: 21.07.2007 19:56
Das klingt ja vielversprechend ! Wenn ich das richtig interpretiert habe, läuft die Flußsteuerung dann komplett via Software, der entsprechende Port wird also umgeschaltet ..? Das sollte für den Hausgebrauch auch ausreichend sein; wenn es dann mal via RS485, also mit externer Treiberumschaltung sein soll, kann man das ja nach Belieben selbst reinfriemeln ;) Vielen Dank für Deine Anstrengungen...
Datum: 23.07.2007 16:30
Ich habe hier ein ATMega 48 und möchte gerne den Bootloader zum laufen kriegen, habe daher die Ports und Includes angepasst (ich hoffe mal richtig, habe noch nie mit Assembler gearbeitet):
;************************************************************************* ;* * ;* ATmega8 Bootloader * ;* * ;* Author: Peter Dannegger * ;* * ;************************************************************************* .nolist .include "m48def.inc" ;please burn this BootStart Fuse: .equ BootStart = SecondBootStart ;Attention: BufferSize must fit perfectly into BootStart ! ;e.g. BufferSize * 8 = BootStart .equ BufferSize = (15*PageSize) ;------------------------------------------------------------------------- ; Port definitions ;------------------------------------------------------------------------- .equ STX_PORT = PORTD .equ STX_DDR = DDRD .equ STX = PD0 .equ SRX_PIN = PIND .equ SRX_PORT = PORTD .equ SRX = PD1 ;------------------------------------------------------------------------- .include "fastload.inc" ;------------------------------------------------------------------------- |
Und kriege dann beim kompilieren folgende Fehler:
AVRASM: AVR macro assembler 2.1.2 (build 99 Nov 4 2005 09:35:05) Copyright (C) 1995-2005 ATMEL Corporation C:\avr\bootloader\bootloader.asm(9): Including file 'C:\Programme\Atmel\AVR Tools\AvrAssembler2\Appnotes\m48def.inc' C:\avr\bootloader\bootloader.asm(14): warning: Use of undefined or forward referenced symbol 'SecondBootStart' in .equ/.set C:\avr\bootloader\bootloader.asm(33): Including file 'C:\avr\bootloader\fastload.inc' C:\avr\bootloader\fastload.inc(9): Including file 'C:\avr\bootloader\compat.h' C:\avr\bootloader\fastload.inc(10): Including file 'C:\avr\bootloader\fastload.h' C:\avr\bootloader\fastload.inc(21): error: Overlap in .cseg: addr=0x0 conflicts with 0x0:0x1 C:\avr\bootloader\bootloader.asm(33): info: 'C:\avr\bootloader\fastload.inc' included from here C:\avr\bootloader\fastload.inc(38): Including file 'C:\avr\bootloader\abaud.inc' C:\avr\bootloader\fastload.inc(39): Including file 'C:\avr\bootloader\password.inc' C:\avr\bootloader\fastload.inc(83): Including file 'C:\avr\bootloader\checkcrc.inc' C:\avr\bootloader\fastload.inc(90): Including file 'C:\avr\bootloader\verify.inc' C:\avr\bootloader\fastload.inc(101): Including file 'C:\avr\bootloader\message.inc' C:\avr\bootloader\fastload.inc(104): Including file 'C:\avr\bootloader\progmega.inc' C:\avr\bootloader\fastload.inc(110): Including file 'C:\avr\bootloader\uartcrc.inc' C:\avr\bootloader\bootloader.asm(35): warning: end of .dseg at 0x4c0 is beyond end of memory at 0x2ff Assembly failed, 1 errors, 2 warnings |
Und wenn ich sowieso schon schreibe, hat jemand den Bootloader für Linux auf den aktuellen Stand gebracht? (war ja im vorhergehenden Thread mal dabei). Danke. mfg Andreas
Datum: 23.07.2007 18:37
Der ATmega48 gehört bezüglich Bootfunktion zu den ATtinys. Daher gibts kein Secondbootstart. Nimm daher das T45.ASM als Vorlage. Peter
Datum: 23.07.2007 20:22
Ok, Danke! Der Bootloader ist drauf, nur wartet der unendlich lange? Ich konnte mein Programm aufspielen, aber es wurde nicht gestartet. Selbst wenn ich über eine Minute warte kann ich immer noch das Flash bespielen. Wie muss ich mein Programm starten, bzw. wenn wird es gestartet? (da ich den vorherigen Thread auch gelesen habe gehe ich mal davon aus das dein Bootloader auf 0x00 eine rjmp zur Adresse in der der Bootloader ist geschrieben hat, und dann von dort auf zurück auf 0x01 springt wo das Programm beginnt, oder so ähnlich?) Wie schon genannt, ATMega 8, und ich kann immer noch kein Assembler;-) mfg Andreas
Datum: 23.07.2007 21:57
Die Applikation startet, sobald das PC-Programm fertig ist bzw. etwa 0,3s nach einem Reset. Bei den AVRs ohne Bootstartfuses muß der erste Befehl ein RJMP sein, sonst geht es nicht. Und die Applikation muß lauffähig sein, d.h. eine Mainloop haben. Peter
Datum: 23.07.2007 22:00
Die Applikation hat eine Hauptschleife, es ist in C geschrieben, wie muss ich das realisieren? Es ist so das mein Programm definitiv nicht startet, weder nach einem Reset noch nach dem Flashen. mfg Andreas
Datum: 23.07.2007 22:12
Andreas B. wrote: > Es ist so das mein Programm definitiv nicht startet, weder nach einem > Reset noch nach dem Flashen. Verify und CRC sind o.k. ? Wenn Du überzeugt bist, daß Dein Programm funktioniert, dann lade es mal direkt, ohne Bootloader. Peter
Datum: 23.07.2007 22:26
Ohne Bootloader läuft es, und CRC habe ich nicht drauf, zumindest wird ausgegeben das CRC nicht implementiert ist. Auch wenn ich .crc = 17 auskommentiere erscheint dies. Ich benutze den Internen Oszi, habe Datenübertragung mit 9600 Baud klappt bei meinem Programm, ich habe beim Flashen auch 9600 Baud angegeben (wobei das wahrscheinlich eh nichts bringt da du sowieso das ganze per Software machst). Ist es möglich das ich den Bootloader falsch geflasht habe, also das der auf 0x00 steht und mein Programm hintendran oder so? Ich habe einfach das .hex File mit AVR Studio aufgespielt. mfg Andreas
Datum: 23.07.2007 22:33
Ich muss natürlich nicht CRC auskommentiern sonder VERIFY einkommentieren. Und dann erscheint auch "fail" warum weiss ich noch nicht... Aber demfall wurde mein Programm nicht augespielt, oder zumindest nicht richtig aufgespielt... Danke für die Antworten und ich hoffe mal ich kriege das noch selbst raus, oder du hast nochmals einen Vorschlag... mfg Andreas
Datum: 23.07.2007 23:05
Schau mal bei den Fuses nach, der ATmega48 hat noch ne Self-Programming-Enable Fuse, die muß man setzen. Peter
Datum: 24.07.2007 12:37
Angehängte Dateien:So, hier mein Linuxport des Bootloader Programmers. (Basiert auf dem Original und dem Port von Sascha Biedermann vom vorherigen Thread) Leider nicht ganz so schnell wie das original, und mit ein paar unschönen Hacks drin...:
/dev/ttyS0 at 115200 Baud: / Connected Bootloader V1.4 Target: 1E9205 ATmega48 Buffer: 64 Byte Size available: 3582 Byte reading file... Done. Program project.hex: 0000 - 0D25 successful CRC: o.k. Elapsed time: 28 seconds andreas@andreas:~/avr/bootloader_linux$ ./main /Vproject.hex /dev/ttyS0 at 115200 Baud: \ Connected Bootloader V1.4 Target: 1E9205 ATmega48 Buffer: 64 Byte Size available: 3582 Byte reading file... Done. Verify project.hex: 0000 - 0D25 successful CRC: o.k. Elapsed time: 41 seconds |
Trotzdem möglicherweise nützlich für Linuxuser ;-) mfg Andreas
Datum: 27.07.2007 00:23
Angehängte Dateien:Hier eine neue Linuxversion, nun klappt das Programmieren innert Sekunden (bei meinem ATMega48 sinds sogar nur 0.44 Sekunden) und einige Bugs behoben. Und noch eine Frage, kann der Bootloader aus C gestartet werden? Ich habes versucht mit
cli(); asm volatile ("rjmp 0"); |
das klappt aber nicht, da hängt sich alles auf. ps. ich habe versucht einen Pin mit dem Resetpin zu verkabeln, da hängt sich aber alles auf wenn ich den auf LOW setzte, irgendwie funktioniert das nicht... bzw. ich mache was falsch. mfg Andreas
Datum: 27.07.2007 06:43
Du musst natürlich an den Anfang des Bootloader springen, nicht nach Null.
Datum: 27.07.2007 06:49
> ich habe versucht einen Pin mit dem Resetpin zu verkabeln, da hängt
sich aber alles auf wenn ich den auf LOW setzte
Mach das am besten über den Watchdog.
Pseudocode
cli();
WdtEnable(WDT_1MS);
while(!0) {}
Datum: 27.07.2007 11:10
Werner B. wrote: > Du musst natürlich an den Anfang des Bootloader springen, nicht nach > Null. Das stimmt, aber ich weiss nicht wo der Bootloader beginnt, und ich habe gelesen das der an erster Addresse ein Jump zum Bootloader drin ist. Ich versuchs mal noch mit dem Watchdog. mfg Andreas
Datum: 27.07.2007 14:36
Ich bin mir nicht sicher ob ich ein Problem mit dem Bootloader oder sonst etwas habe, hier mal die Beschreibung: Ich mache einen Reset per Watchdog:
void reset(void) { uint8_t i; uart_puts("reset\r\n"); for(i = 30; i > 0; i--) { uart_puti(i); uart_puts("\r\n"); _sleep(); } //Interrups deaktivieren cli(); //Watchdog einschalten WDTCSR = (1 << WDE); for(i = 0;1; i++) { uart_puti(i); uart_puts("\r\nw"); } } |
Aufem Treminal kriege ich:
... 2 1 0 w1 w2 w3 |
Daher kann ich davon ausgehen das er einen Reset macht. Aber danach wird mein Programm nicht mehr gestartet. Wenn ich versuche ein Programm aufzuspielen erscheint gerade noch (ich beende natürlich das Terminal, sonst würde es ja meine serielle Schnittstelle blockieren)
/dev/ttyS0 at 115200 Baud: - Connected |
da das Laden des Bootloaders sonst klappt gehe ich davon aus das irgendetwas nicht richtig initialisiert wird beim Reset mit Watchdog, oder was könnte es sonst sein? Hat noch keiner den Bootloader per C gestartet? mfg Andreas
Datum: 28.07.2007 22:34
Hallo, bei mir zeigt der Linux-Client seltsame Buffergrößen an... hängt das mit den Compilerwarnings zusammen? Ansonsten danke an Peter für den tollen Bootloader und an Andreas für den Linux-Client. Grüsse Tobias
vm-debian-testing:~/tmp# make gcc -Wall -g -c main.c -o main.o main.c: In function 'readhex': main.c:327: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness main.c:330: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness main.c:333: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness main.c:339: warning: pointer targets in passing argument 1 of 'sscanhex' differ in signedness gcc -Wall -g -c readargs.c -o readargs.o readargs.c: In function 'readargs': readargs.c:46: warning: conversion lacks type at end of format readargs.c:46: warning: too many arguments for format gcc -Wall -g main.o readargs.o -o main vm-debian-testing:~/tmp# ./main /dev/ttyS0 at 115200 Baud: \ Connected Bootloader V1.4 Target: 1E9307 ATmega8 Buffer: -2 Byte Size available: -2 Byte CRC: o.k. Elapsed time: 0.03 seconds vm-debian-testing:~/tmp# |
Datum: 28.07.2007 22:42
Angehängte Dateien:Die Warnungen kannst du ignorieren, diese sind unwichtig, jedoch das Problem mit der Grösse hatte ich auch, ich habe darum etwas einfach so "gebastelt" das es bei mir funktioniert, warum das es bei dir nicht funktioniert kann ich so nicht sagen, was hast du für ein Controller? (Vor allem wie viel Speicher hast du) Ich habe hier mal eine "Debugversion" angehängt, diese schreibt die entscheidenden Zahlen auf die Konsole, einfach die Ausgabe kopieren, ich hoffe ich kann damit zumindest feststellen was schief läuft. Ich habs bis jetzt nur mit einem Mega48 probiert, und einfach alles so angepasst das es damit funktioniert, was mir nicht klar war warum das ich einmal falsche Zahlen empfangen habe (mir wird die Länge der Zahl übertragen, in Byte, die war jedoch bei zwei Werten immer um eins zu hoch). mfg Andreas
Datum: 29.07.2007 22:07
Hallo, danke für Die schnelle Antwort, ich hab nen Atmega8. Und hier die Debug-Daten. Grüsse Tobias
vm-debian-testing:~/tmp2/debug# ./main /dev/ttyS0 at 115200 Baud: | Connected ->-------------- ->168 ->3 ->1 ->4 ->170 Bootloader V1.4 ->-------------- ->168 ->4 ->30 ->147 ->7 ->170 Target: 1E9307 ATmega8 ->-------------- ->168 ->3 ->3 ->192 Buffer: -2 Byte ->-------------- ->170 ->168 ->4 ->30 ->170 ->-1 Size available: -2 Byte CRC: o.k. Elapsed time: 0.00 seconds vm-debian-testing:~/tmp2/debug# |
Das sagt Peters Programm:
E:\avr\fastboot1.4>fboot COM 1 at 115200 Baud: Connected Bootloader V1.4 Target: 1E9307 ATmega8 Buffer: 960 Byte Size available: 7680 Byte CRC: o.k. Elapsed time: 0.11 seconds E:\avr\FASTBO~1.4> |
Datum: 29.07.2007 22:28
Angehängte Dateien:Versuch mal diese Version. Bei ich musste ein paar Änderungen machen, damit der Bootloader Programmer bei mir lief, ich denke aber für den ATMega 8 scheinen diese nicht nötig zu sein (der ATMega 48 war ja auch nicht in der Liste, darum hats wahrscheinlich auch nicht funktioniert.) Ich warte auf dein Ergebnis und werde hoffentlich dann eine Finale Version machen können die mit allen Controllern funktioniert... mfg Andreas
Datum: 29.07.2007 22:48
fast...
vm-debian-testing:~/tmp3# ./main /dev/ttyS0 at 115200 Baud: \ Connected Bootloader V1.4 Target: 1E9307 ATmega8 Buffer: 960 Byte Size available: -2 Byte CRC: o.k. Elapsed time: 0.01 seconds vm-debian-testing:~/tmp3# |
Datum: 29.07.2007 23:01
Irgendwo ist beim portieren ein Fehler passiert, denn das ist 1:1 die Funktion die auch in der Windowsversion eingesetzt wird. Ich werde das ganze morgen nochmals vergleichen, und vielleicht komme ich auf einen Fehler. Ich kann dir auf jeden Fall mal sagen wo das es schief läuft (in der Hoffnung ein mitdenkender Forumuser könnte mir die Lösung sagen;-)): ATMega 48: er sagt er sendet mir 2Bytes, sendet aber nur eines (Buffer: 64Byte, 64 passt in ein Byte), dann beim Speicher sagt er er Sendet 3Bytes, sendet aber zwei, usw. Dein Controller sagt auch er Sendet zwei Byte beim Buffer, sendet aber zwei... Ich weiss (noch) nicht wo der Fehler liegt. mfg Andreas
Datum: 30.07.2007 11:54
Super!!! Vielen Dank an Peter Dannegger ! Hab den File auf meinen ATmega8 geflasht und konnte mit dem beigefügten Tool (fboot.exe) sofort meine hex-Files in den uC kopieren. Sehr geil... und auch noch dazu superschnell! mfg Christian
Datum: 01.08.2007 16:06
Wirklich super der Bootloader! Hab ihn bei meinen RS485 Bussen mittlerweile auf jedes Device gebracht und bin wirklich sehr zufrieden! Warte jetzt nur noch auf eine Weiterentwicklung des FBOOT.EXE Tools, die auch unter Vista läuft.
Datum: 02.08.2007 12:28
hast Du bidirektionale RS-485 oder unidirektionale mit Umschaltung der Sende- / Empfangsrichtung ?
Datum: 03.08.2007 17:22
Angehängte Dateien:Ich habe mir nochmal die Linux-Version von fboot.c vorgenommen, nachdem ich auch den Fehler mit der negativen Buffergroesse usw. hatte. Der Fehler lag wohl in "com_getc()". horst.
Datum: 04.08.2007 09:38
Hallo Peter, hast du für deine Bootloader mal eine Dokumentation gemacht. Leider muß man sich alles aus den 3 Threads mit so vielen Beiträgen zusammen suchen :-( Außerdem bi ich recht neu im Bereich der Mikrocotroller. Mich würde eine genaue Bescreibung des AVR Programms und eine genaue Beschreibng des PC Programms interessieren. Gruß Tobias
Datum: 04.08.2007 11:30
Es wäre sinnvoll dafür einen Artikel im Wiki zu erstellen: Anleitung: Artikel erstellen
Datum: 05.08.2007 13:56
Angehängte Dateien:Hi, hab jetzt nach über einem Tag intensivem probieren meine ganzen Fehler rausgekriegt und der Bootloader läuft ;-) Da der ein oder andere Anfänger sicher ähnliche Probleme hat, hab ich mal ne kleine Anleitung geschrieben. Seh auch grad die Frage nach dem Wiki. Wenn Ihr nichts dagegen habt schreib ich die Anleitung auch noch ins Wiki. Am Support durch die ATMega IDE schreib ich gerade. Sollte also heute oder morgen dann downloadbar sein. Die Geschwindigkeit ist echt der Hammer. Ich hab für ein Programm im 168er mit dem ISP immer so 1,5 Minuten gebraucht. (inkl. Verify) Jetzt brennt er das in nur 3 Sekunden rein (ohne Verify). Echt toll ;-) Ciao Karsten
Datum: 05.08.2007 14:55
So Wiki ist drin. http://www.mikrocontroller.net/articles/AVR_Bootlo... Ciao Karsten
Datum: 07.08.2007 21:24
Hallo, ich würde das PC-Programm gerne in VB schreiben. Allerdings ist Java und C nicht gerade meine Stärke ;-) Gibt es irgendwo eine ausführliche Dokumentation zum Protokoll zwischen MC und PC ? Viele Grüße David Herrmann
Datum: 07.08.2007 23:44
Angehängte Dateien:So, ich hab mich in Unkosten gestürzt und nen ATmega2561 gekauft. Über 64kB brennen geht jetzt. Allerdings ist noch irgendwo der Wurm drin, dauert sehr lange. Daher hier erstmal ne Vorabversion. Das Protokoll ist geändert, betrifft aber nur den Verbindungsaufbau (extra Zeichen nach Paßworterkennung), wurde für den Eindrahtmodus nötig. David Herrmann wrote: > Gibt es irgendwo eine ausführliche Dokumentation zum Protokoll zwischen > MC und PC ? Bisher noch nicht. Mal sehen, wann ich dazu komme. Peter
Datum: 14.08.2007 08:09
Hallo... nachdem Halb-Duplex ja mittlerweile implementiert ist, -vielen Dank dafür- habe ich den Code mal überflogen. Wenn ich's richtig verstanden habe, dient der C-Code hauptsächlich dem strukturierteren Aufbau; der eigentliche Bootloader ist jedoch in Assembler geschrieben !? Jetzt bin ich in C nicht eben die Leuchte und möchte den Loader gern mit meinem bestehenden Assembler-Source verbinden, bzw. der Einfachkeit halber, den Assembler-Teil nachladen. Muss ich den Assembler-Code an eine bestimmte Adresse legen, damit's möglichst reibungslos funktioniert ? µC wäre ein Tiny45... Gruß, Stefan ---
Datum: 14.08.2007 08:46
Der Bootloader ist pure Assembler. Nur das PC-Programm ist in C geschrieben, muß man aber nicht neu übersetzen, die EXE ist ja schon dabei. Ist nur für die, die es modifizieren (GUI) oder an Linux usw. anpassen wollen. Manche mögen ja keine automatischen Programme, sie wollen lieber jedesmal umständlich umherklicken müssen. Peter
Datum: 14.08.2007 11:59
Das macht die Angelegenheit doch schon viel transparenter ;) Ich dachte ursprünglich, dass es jetzt ein Flag gibt, das zwischen uni- oder bidirektionale Kommunikation selektiert und dass noch Definitionen für den Pin für's Umschalten zwischen Senden und Empfangen, bei RS-485 Treibern dazu gekommen sind. Aber es sieht so aus, als ob man in der jeweiligen controller.asm einfach nur Senden und Empfangen auf den gleichen Pin legt und eventuelle Konflikte mit den Widerständen begrenzt !? Demzufolge müsste für aktive Treiber, deren Umschaltung noch von Hand reingefrickelt werden !? Wäre an sich kein Problem, wollte nur fragen, bevor ich den Source nach den TxD/RxD-Geschichten durchsuche... Stefan ---
Datum: 18.08.2007 22:45
Hallo, ich habe gerade versucht den bootloader mit einem mega8535 ans laufen zu bekommen. Habe dazu einfach das m8.asm file kopiert, und oben den include geändert (mega8535 hat auch 8kbyte flash). Grundsätzlich scheint es auch zu laufen, er sagt das alles wunderbar ist:
COM 2 at 4800 Baud: Connected Bootloader V1.6 Target: 1E9308 Buffer: 960 Byte Size available: 7680 Byte Program test.hex: 00000 - 0022F successful CRC: o.k. Elapsed time: 1.65 seconds |
Das eigentliche Programm startet dann aber nicht. Ich habe dann das Flash wieder per ISP ausgelesen, dabei stellte sich heraus das die erste 48 Bytes komplett verschieden sind. Die ist .hex Datei (per ISP ausgelesen):
:10000000EC0102C02196E8DF88818823D9F7DF91CF :10001000CF910895CF93DF93EC0101C0DDDFFE01A6 :10002000219684918823D1F7DF91CF910895FFCF56 :10003000D2E0DEBFCDBF10E0A0E6B0E0E0E3F2E04A |
Die soll .hex Datei (compiliert):
:1000000014C02EC02DC02CC05BC02AC029C028C07F :1000100027C026C025C05FC088C022C021C020C024 :100020001FC01EC01DC01CC01BC011241FBECFE5B9 :10003000D2E0DEBFCDBF10E0A0E6B0E0E0E3F2E04A |
Erst ab der 4ten Zeile sind sie wieder identisch Was ist da passiert? PS:
case 0x1e9308: s = "ATmega8535"; break; |
für die fboot.c ;)
Datum: 18.08.2007 23:08
Ein Mega8535 ist nun mal kein Maga8. z.B. die Interruptvektoren ganz am Anfang sind unterschiedlich. Da musst du die Datenblätter vergleichen.
Datum: 19.08.2007 17:24
Tom wrote: > Ich habe dann das Flash wieder per ISP ausgelesen, dabei stellte sich > heraus das die erste 48 Bytes komplett verschieden sind. Hab ich jetzt auch keine Erklärung dafür. Versuch mal ganz oben Version 1.4, die sollte eigentlich laufen. Die Version 1.6. hab ich nur ganz kurz getestet und noch nicht weiter verwendet. Peter
Datum: 21.08.2007 11:10
Hallo, ich versuche schon seit einiger Zeit den Bootloader (v1.4) zum laufen zu bekommen - leider ohne Erfolg. Versucht hab ichs mit einem M32 und einem M8. Als RX/TX benutze ich die Hardware Schnittstelle: M32.asm: ;------------------------------------------------------------------------- ; Port definitions ;------------------------------------------------------------------------- .equ STX_PORT = PORTD .equ STX_DDR = DDRD .equ STX = PD1 .equ SRX_PIN = PIND .equ SRX_PORT = PORTD .equ SRX = PD0 ;------------------------------------------------------------------------- .include "fastload.inc" ;------------------------------------------------------------------------- Habe das Programm mit AVRASM2 compiliert und anscließend mit dem AVR-Burn-o-mat in den COntroller geladen. Was mir sehr seltsam vorkommt, ist dass insgesamt 32722 Bytes in den Controller geladen werden (beim M32). Damit ist der Flash doch voll...? Die Fuses sind auch gesetzt(nach Anleitung)... Wenn ich jetzt fboot mit COM4 im Verzeichnis mit der Zielfirmware starte, kommt das Programm nicht weiter als "COM4 at 115200 Baud". Zu erwähnen ist noch, dass ich den M32 mit einem Quarz 16MHz betreibe(ist auch in Fastload.h eingestellt. Beim M8 gibts genau das gleiche Problem, der läuft aber mit 7,37MHz. Die Bootzeit habe ich wegen der höheren Frequenz etwas erhöht, mehrer Werte von 3-16 ausprobiert, funktioniert trotzdem nicht... Was mache ich falsch?? Könnt ihr mir weiterhelfen? Gruß Johannes
Datum: 21.08.2007 11:31
In der Anleitung steht das man die Fuses auf 256 words setzen soll, in meinem Fall bin ich aber auf 512 gekommen.
Datum: 21.08.2007 16:30
hab das mit den 512Byte mal ausprobiert, hilft aber leider auch nix... Wo kann ich denn nachgucken, wieviel Bytes das compilierte Programm hat? Ist das der Wert, der nach dem Compilieren bei "Summery ... USED Memory" steht? (bei mir 470Bytes. Kann das vielleicht auch mit dem USB- Seriell Adapter zusammenhängen? Aber eigentlich läuft alles Andere wie geschmiert mit dem Adapter... danke für den Tipp!
Datum: 21.08.2007 16:55
Am besten machst du mal ein Chip Erase, brennst den bootloader und liest dann mal den Flash aus, wenn ich mich recht entsinne (bin gerade nicht am richtigen Rechner) fängt der Bootloader mit der Standard Config bei :101E0000 (Intel Hex) an.
Datum: 21.08.2007 17:08
Habe es nun mit dem 1.4er versucht, jetzt brennter garnichts mehr ;) Immer failed...
COM 2 at 4800 Baud: Connected Bootloader V1.4 Target: 1E9308 Buffer: 64 Byte Size available: 7680 Byte Program test.hex: 0000 - 1300 failed ! Elapsed time: 21.59 seconds |
Das /D lässt fboot anscheinend auch nur festfahren.
Datum: 26.08.2007 19:59
@Johannes der Bootloader sitzt am oberen Ende im Flash. Der brennt praktisch erstmal ein leeres Programm und oben den Bootloader. Der Bootloader legt danach das eigentliche Programm wieder an der richtigen Stelle (weiter unten) ab. Frequenz sollte nicht stören. Ich hab den M8 mit der 3,68er und den M168 mit 8,000MHz benutzt. Die Wartezeit hat bei mir bisher keine Probleme gemacht. Ich benutze auch die Hardware-Pins da ich da eh schon ne RS232 dran hab. Größe ermitteln: avr-size -A m8.hex @Kriewitz 256 Worte = 512 Bytes. und der Bootloader hat weniger als 512 Bytes (zumindest V1.4, 1.6 hab ich noch nciht getestet weil ich im Urlaub war).
Datum: 26.08.2007 20:57
Hab jetzt mal die Version 1.6 genauer getestet, die ist Schrott.
Mein Borland-C 3.0 weigert sich standhaft, Felder über 64kB zuzugreifen.
Also erstmal Version 1.4 verwenden.
Wenn da oft Bytes 0x13 vorkommen, geht die Geschwindigkeit über USB
drastisch in die Knie.
Wird in Version 1.7 abgestellt (muß aber erstmal nen funktionierenden
Compiler besorgen).
Wenn gar nichts geht, kann das an speziellen LPT-Treibern für direkte
IO-Zugriffe (ISP) liegen, die können sich mit der COM im DOS-Fenster
beißen. Also diesen mal deaktivieren.
> Program test.hex: 0000 - 1300 failed !
könnte das nicht aktivierte SELFPRGEN-Fusebit sein.
Peter
P.S.:
Ein kompletter ATmega2561 dauert ~33s.
Datum: 26.08.2007 22:58
Mit dem C-Builder von Borland (jetzt CodeGear) gehen auch Konsolenanwendungen. Die haben auf der Homepage auch eine Testversion zum Download. An sonsten könnte ich was mit Delphi schreiben. Da kommt das je eh in die ATMega IDE rein. Karsten
Datum: 26.08.2007 23:42
Angehängte Dateien:Anbei die neueste Version. Wie es scheint, muß ich bei meinem uralt BC3.0 die Segment/Offset-Rechnung zu Fuß machen. Jedenfalls geht es jetzt. Können sich die Windowsprogrammierer mal einen ablachen, was früher so für Verrenkungen notwendig waren. Peter
Datum: 27.08.2007 00:16
Bin aber eher froh das ich mich mit sowas nicht mehr rumplagen muss. Wenn ich da so an Overlay Dateien usw. denk. Oder die selbstgeschriebne XMS Unit ;-) Karsten
Datum: 27.08.2007 08:48
Angehängte Dateien:Sorry, natürlich 256 words, nicht 512! @Tom Im Anhang ist eine funktionierende M8535.ASM, der mega8535 hat im Gegensatz zum mega8 nur 512kByte SRAM, BufferSize muss also auch angepasst werden. @Peter Du kannst die Datei gerne mit reinnehmen. Hier nochmal die device id vom mega8535
case 0x1e9308: s = "ATmega8535"; break; |
Kompletter flash (7680 Byte) hat bei mir 2,3 Sekunden gedauert :) Getestet mit 115200 BAUD @ 14318180 Hz und FBOOT V1.7
Datum: 29.08.2007 15:06
Hat sich schon mal jemnad die Mühe gemacht, den PC-Teil in Delphi umzusetzten ?
Datum: 29.08.2007 21:28
Angehängte Dateien:Anbei das PC-Programm mit einigen Typen hinzugefügt. Die Typenliste sollte man wohl besser auslagern. Werde mal noch 8051-er hinzufügen, das Flip ist mir zu langsam und zu umständlich. Den ATtiny44 hab ich noch getestet. Der Eindrahtmodus funktioniert bei mir auch sehr gut bei 115200 Baud, geht also auch ohne MAX232. Das Abzählen der Echobytes funktioniert zuverlässig. Die Programmierzeiten sind gleich. Peter
Datum: 08.09.2007 07:26
Hallo, super bootloader! Mich würde noch interessieren was es mit der password.inc auf sich hat, kann man damit den Bootloader Zugriff beschränken? Falls ja, wie? Und wie verhält sich der booloader wenn man etwas in den booloader Bereich flashen will (wenn man keine LockFuses programmiert hat)? Bin mir gerade nicht sicher, aber kann man eigentlich auch per Booloader Fuses ändern, fände eine Möglichkeit die RSTDISBL Fuse zu ändern noch sehr praktisch.
Datum: 08.09.2007 11:32
Tom wrote: > Mich würde noch interessieren was es mit der password.inc auf sich hat, > kann man damit den Bootloader Zugriff beschränken? Falls ja, wie? Das ist nur die Auswerteroutine für das Paßwort. Du kannst auch ein anderes und auch längeres Paßwort als "PeDa" definieren, es muß bloß ein für die Baudratenerkennung geeignetes Zeichen enthalten, z.B. 'a'. Und dann natürlich mit: fboot17 -ineues_Passwort ... dem PC-Programm übergeben (sehe gerade, das fehlt im Hilftext). Ohne das Paßwort kommt keiner in den Bootloader. Man kann also ruhig Geräte an die UART anschließen, die schon beim Einschalten sehr gesprächig sind. > Und wie verhält sich der booloader wenn man etwas in den booloader > Bereich flashen will (wenn man keine LockFuses programmiert hat)? Die Programmierroutine macht immer einen Adreßcheck und verweigert die Selbstzerstörung. Aber auch schon das PC-Programm bricht ab, wenn die höchste Adresse über dem Applikationsbereich liegt. > Bin mir gerade nicht sicher, aber kann man eigentlich auch per Booloader > Fuses ändern, fände eine Möglichkeit die RSTDISBL Fuse zu ändern noch > sehr praktisch. Die Fuses kann der AVR nicht selber ändern. Peter
Datum: 08.09.2007 12:13
Danke! >Du kannst auch ein anderes und auch längeres Passwort als "PeDa" >definieren, es muß bloß ein für die Baudratenerkennung geeignetes >Zeichen enthalten, z.B. 'a'. Was macht das 'a' so gut tauglich für die Baudratenerkennung?
Datum: 08.09.2007 15:25
Nun, das Paßwort enthält ja verschiedene Bytes, die Low-Impulse von 1..9 Bitzeiten enthalten können. Damit nun die Baudratenerkennung nicht austillt, prüft sie das Verhältnis zweier aufeinanderfolgender Low-Pulse, ob es 1:4 beträgt. Das ist z.B. beim 'a' der Fall. Man könnte sie in die Irre führen, indem man die Bytefolge 0x20,0x80 sendet, dann hat man 2 Bitzeiten gefolgt von 8 Bitzeiten, was auch 1:4 ist. Dann steht die Baudratenerkennung aber auf der halbe Baudrate. Daher dürfen derartige Bytefolgen nicht im Paßwort vorkommen. Peter
Datum: 08.09.2007 16:35
Zuerst einmal Respekt! :) Habe jedoch mit dem FBOOT17 hin und wieder ein Problem. Manchmal reagiert die DOS-Box, in der ich das Programm starte nicht mehr (Keine Rückmeldung). Aber wie gesagt nicht immer. (so ca. bei jedem 10. Mal) Als System hab ich ein aktuelles WinXP Home. Hast du eine Idee, woran das liegen könnte? Deshalb die Frage: Ist ein Windows-Tool geplant bzw. in Arbeit? :) Falls nein: Könntest du bitte Details zum Protokoll veröffentlichen, dann werd ich vorr. übernächste Woche (kommende Woche bin ich im Urlaub - juhu) mal mit VB ein Windows-Tool zusammenstricken.. Falls ja: Wann (ca.) und wo kann es downloaden? Ist dann hoffentlich Freeware? Gruß, Techniker
Datum: 08.09.2007 16:59
Der Techniker wrote: > Habe jedoch mit dem FBOOT17 hin und wieder ein Problem. Manchmal > reagiert die DOS-Box, in der ich das Programm starte nicht mehr (Keine > Rückmeldung). Hast Du USB/RS232 oder ne echte RS232 ? Hast Du nen LPT-Treiber installiert, z.B für SPI ? Bei USB mal den neuesten Treiber installieren. Bei LPT mal den Treiber deaktivieren. Drauf achten, daß keine andere Anwendung die gleiche COM belegt. Das Protokoll werd ich demnächst aufschreiben. Peter P.S.: Ich hab ja kürzlich mal den ATtiny13 programmiert, da hab ich mich über den Bootloader geärgert :-) Und zwar, warum ich ihn nicht früher entwickelt habe. Es macht jetzt richtig Spaß. Besonders der 1-Drahtmodus bei den 8-Pinnern ist goil. Und man kann endlich alle 6 IOs benutzen ohne nur einen einzigen Schuß zu haben.
Datum: 08.09.2007 17:02
Ich arbeite an meinem alten Desktop -> also echte RS232..
Datum: 08.09.2007 17:12
Also das "nicht reagieren" kenne ich auch nur wenn der Port bereits von einem anderen Programm verwendet wird. Eventuell irgend ein Programm im Hintergrund was von Zeit zu Zeit alle Ports abklappert?
Datum: 08.09.2007 17:25
..hmm.. Sollte eigendlich nichts laufen, was die RS232 stören könnte.. Alle anderen Anwendungen, die RS232 benuten laufen ja problemlos.. (..davon läuft aber keins im Hintergrund..) PS: Auch ein wechsel der Schnittstelle auf COM2 bringt keine wesentliche Verbesserung.. :-/
Datum: 13.09.2007 09:52
Hallo Leute, ich habe in den letzten Tagen versucht, den Bootloader (V1.7) bei mir ans Laufen zu bekommen. Leider nur mit wenig Erfolg :-(. Zunächst mal meine Konfiguration: ATMEGA644, TXD auf PD1, RXD auf PD0 (Standard-UART vom 644) Ich bin dann nach der Wiki-Anleitung vorgegangen: - fastload.h angepasst :".equ XTAL = 20000000 ; 20MHz, not critical" - in m644.asm die Ports auf Port D angepasst - übersetzt mit "avrasm2 -fI m644.asm" - gebrannt mit "avrdude -p m644 -c stk200 -P lpt1 -U flash:w:"m644.hex":i -U flash:v:"m644.hex":i -y" - Fuses gesetzt: BOOTRST programmiert, BOOTSZ0 und BOOTSZ1 nicht programmiert. Das heißt allerdings beim 644 "Boot size=512 Words" (kleinster möglicher Wert). In der Wiki steht etwas von 256 Worte. Ist das ein mögliches Problem??? - Wenn ich jetzt fboot17 aufrufe, kommt folgende Ausgabe: D:\Daten\AVR\BOOTLO~1>fboot17 /C1 /Pflash.hex COM 1 at 115200 Baud: Connected Bootloader VFFFFFFFF.FF Error, wrong device informations D:\Daten\AVR\BOOTLO~1> Wenn ich beim fboot ein anderes Passwort setze, z.B. "fboot17 /ifoo" kommt es nicht zum Connect. Ich nehme daher mal an, dass zumindest die Passwortabfrage funktioniert!?! Die Version 1.4 hab ich auch schon mal kurz probiert, hier kommt es noch nicht mal zum Connect. Vielleicht fällt einem von Euch noch etwas dazu ein oder hat Tipps dazu. Gruß Dirk
Datum: 13.09.2007 09:59
Versuchs mal mit einer niedrigeren BAUD rate (/B9600)
Datum: 13.09.2007 10:02
@freddy436 Danke für den Tip. Hab´s gleich probiert. Funktioniert aber leider auch nicht :-(.
Datum: 21.09.2007 18:37
Angehängte Dateien:Hallo Habe probiert Peters PC program Fboot17.exe zum portieren aus DEV-Cpp , ich glaube ich habe success. Ich kann programmiere mit 57600 , aber 115200 geht nicht , vielleicht ob die uart routinen optimiert bist. Aber da ist support von Com 1..5 , ind source ist inkludiert. Installiere Dev-Cpp http://www.bloodshed.net/dev/devcpp.html Download http://prdownloads.sourceforge.net/dev-cpp/devcpp-... Und extract die Fboot source , dan "Klik" am fboot.dev file. Zum die projekt loaden. Selektiere im Dev-Cpp select : Execute->Rebuild All Danke an Peter , und hoffe diser program ist brauchbar. Ps: Die program hast sources von Peter-D , und snippets von Peter Fleury , und die linux programmer von diser thread. Pps: Ich habe nur die program kurtzes testet. Das ist nur einer schnell C program mit serial I/O usv im C ... und kein C++ braucht. Grüsse aus Dänemark /Bingo Hoffe meiner "Schule Deutch" ist verstehbar
Datum: 21.09.2007 18:40
Nur einer kleine dinge mehr Die program unterstutzt auch lange dateinahme /Bingo
Datum: 21.09.2007 21:11
@Peter Ich bin nicht 100% sicher , das ich habe die timeout implementiert korrekt. Im Dev-Cpp bist 1000 clock() ticks pro sekunde , vie viel ist im Borland ?? mfg /Bingo
Datum: 21.09.2007 21:27
Bingo wrote: > Im Dev-Cpp bist 1000 clock() ticks pro sekunde , vie viel ist im Borland > ?? Das ist der DOS-Timertakt:
#define CLOCKS_PER_SEC 18.2 #define CLK_TCK 18.2 |
Peter
Datum: 21.09.2007 22:29
Einer kleine verbesserung
Im serial_connect (void) routine
Erszatz die linie
if (--i > 6)
mit
if (--i >= (sizeof(devtab)/sizeof(devtab[0])))
Dann passt mehre comports im diser linie automatisch
char *devtab[] = { "COM1", "COM2", "COM3", "COM4", "COM5", "COM6" };
/Bingo
Datum: 21.09.2007 23:31
... und ab Com9 muss es "\\.\Com9" heißen. Bei Com1..Com8 stört der Präfix auch "\\.\" nicht.
Datum: 22.09.2007 06:27
@Gast "... und ab Com9 muss es "\\.\Com9" heißen." ........ Bist du sicher ??? Ich habe nur diser syntax sehen , im die com-bridge das lady-aya brauchst im eure, Atmel USB programmer. Und ich glaube die prefix war im die driver. Nicht im einer standard Windows /Bingo
Datum: 23.09.2007 12:05
@Gast Du hast recht , das ist einer Native Windows dinge /Bingo
Datum: 23.09.2007 17:07
Hat denn jemand von Euch wirklich so viele RS232-USB Adapter gleichzeitig in Betrieb, daß er so hohe COMs braucht ? Ich habe am Notebook nur 2 USB-Anschlüsse und die habe ich als COM1 und COM2 konfiguriert. Und am Desktop habe ich ne interne COM1 und die 2 USB an der Frontseite sind dann COM2 und COM3. Peter
Datum: 23.09.2007 22:24
@Peter Ich habe COM1 .. COM6 (2x eingebaut und 2x2 von PCI karte), und das ist ohne die viele FTDI virtual Comadapters , ich glaube meiner höheste comport ist 9 /Bingo Ps: Hast jemand die Dev-Cpp program probiert ??
Datum: 25.09.2007 10:36
So, jetzt muss ich diesen genialen Bootloader auch mal probieren... scheint ja meine Probleme lösen zu können ;-) will ihn für den ATtiny85 verwenden, da ich den reset-pin als io verwenden muss und daher ISP nicht mehr nutzen kann. habe mit jetzt eine datei T85.asm mit folgendem Inhalt angelegt:
.nolist .include "tn85def.inc" .equ CRC = 17 .equ VERIFY = 15 .equ ONEWIRE = 3 ;------------------------------------------------------------------------- ; Port definitions ;------------------------------------------------------------------------- .equ STX_PORT = PORTB .equ STX_DDR = DDRB .equ STX = PB2 .equ SRX_PIN = PINB .equ SRX_DDR = DDRB .equ SRX_PORT = PORTB .equ SRX = PB2 ;------------------------------------------------------------------------- .include "fastload.inc" ;------------------------------------------------------------------------- |
soweit so gut... kompilieren ging auch alles sehr einfach von der Hand. -> der Bootloader wurde auf Adress 0x1E00 gelegt. Ein paar Dinge sind mir aber noch unklar. Der ATtiny85 hat ja keinen Bootblock... wie wir er nun aufgerufen. normalerweise wird der bootloader ja zuerst gestarte... und wenn die die definierte Bootloader-Bedinging (was auch immer) erfüllt ist, dann bleibt er im Bootloader und wenn nicht, dann wird das Hauptprogramm gestartet. Wie funktioniert das jetzt hier? Denn der Chip startet ja immer auf 0x0000. Aber hier liegt ja mein Hauptprogram. Oder muss ich die Bedingung in meinem Hauptprogramm einbauen und dann nach 0x1E00 springen um den Bootloader zu aktivieren? Habe einen 12MHz Quarz. und BootDelay auf XTAL / 10 gesetzt... was bedeutet das jetzt? Danke und liebe Grüsse Jörg
Datum: 25.09.2007 14:43
Joerg wrote: > Ein paar Dinge sind mir aber noch unklar. > Der ATtiny85 hat ja keinen Bootblock... wie wir er nun aufgerufen. > normalerweise wird der bootloader ja zuerst gestarte... und wenn die die > definierte Bootloader-Bedinging (was auch immer) erfüllt ist, dann > bleibt er im Bootloader und wenn nicht, dann wird das Hauptprogramm > gestartet. Wie funktioniert das jetzt hier? Denn der Chip startet ja > immer auf 0x0000. Aber hier liegt ja mein Hauptprogram. Oder muss ich > die Bedingung in meinem Hauptprogramm einbauen und dann nach 0x1E00 > springen um den Bootloader zu aktivieren? Der Bootloader leitet den ersten Sprungbefehl (RJMP) Deiner Applikation um. Du brauchst also auf den Bootloader keinerlei Rücksicht zu nehmen. > Habe einen 12MHz Quarz. und BootDelay auf XTAL / 10 gesetzt... was > bedeutet das jetzt? Das ist die Zeit, in der der Bootloader die Baudrate und das Paßwort erkennt. 1/10s = 100ms, könnte etwas knapp werden. Ich nehme lieber 1/3 = 333ms. Peter
Datum: 25.09.2007 14:45
Der Bootloader "patcht" quasi bei Upload einer neuen Anwendung den RESET Vektor so das er immer aufgerufen wird. Gruß Hagen
Datum: 25.09.2007 16:19
hmmm... habe jetzt ewig gesucht und nicht verstanden, warum auf 0x0000 kein Code steht... kann sein, dass die Datei "fastload.inc" auf folgendes geändert gehört:
.nolist .include "fastload.h" .listmac .list .ifndef BootFuse .org 0x0000 rjmp init .endif .org BootStart init: |
oder habe ich was übersehen, wo der "rjmp init" sonst gemacht gehört?
Datum: 25.09.2007 21:45
Joerg wrote: > hmmm... habe jetzt ewig gesucht und nicht verstanden, warum auf 0x0000 > kein Code steht... Ein leerer Flash enthält ja 0xFFFF. Es ist zwar nicht offiziell, aber dieser Befehl wirkt wie ein NOP, der Code läuft also das erste mal durch bis zum Bootloader. Kannst natürlich auch nen Sprung eintragen. Peter
Datum: 25.09.2007 23:38
habe das ganze jetzt probiert und es funktioniert SUPER!!!! ich mich niederknien und verbeugen tu habe mir mit einem Pogo-Pin einen Adapter zum 1wire programmieren gemacht... und unglaublicherweise hat es gleich funktioniert. pogo-pin auf SMD-Widerstand gedrückt, und ab ging die Post hut ab
Datum: 04.10.2007 09:12
@Karsten Gibt's denn schon was Neues in bezug auf Deine Delphi-Portierung ?
Datum: 04.10.2007 18:01
..und ich warte immer noch auf die Protokoll-Doku.. ;)
Datum: 05.10.2007 15:01
Habe gestern den Bootloader auf einem ATmega88 mit der Onewire probiert -> GENIAL. also der One-Wire mode ist schon ein nettes Feature. Versorgung und Pogo-Pin und ab geht die Post
Datum: 05.10.2007 16:30
Dein letzter Bootloader war schon super, aber dieser ist noch besser. Ich hatte damals überlegt ob es möglich wäre den alten Bootloader auch in 512 Byte zu quetschen, hatte aber keinen Weg gefunden, der neue hat mehr Funktionen und erfüllt den 512 Byte Wunsch :-) EEProm schreiben war aber bei den 470 Byte nicht mehr möglich, oder?
Datum: 14.10.2007 21:08
Was muß man zur Benutzung des „Eindrahtmodus“ an den Port-Pins ändern? ;------------------------------------------------------------------------- ; Port definitions ;------------------------------------------------------------------------- .equ STX_PORT = PORTB .equ STX_DDR = DDRB .equ STX = PB1 .equ SRX_PIN = PINB .equ SRX_PORT = PORTB .equ SRX = PB0 Mit einem MAX232 mit zwei Drähten läuft alles super, nur der „Eindrahtmudus“ aus Peters 1wire.pdf will noch nicht so, wie ich es will… Würde gern ohne MAX232 auskommen.
Datum: 15.10.2007 09:47
also meine Einstellungen für einen ATtiny85 1-wire schaut so aus:
.nolist .include "tn85def.inc" .equ CRC = 17 ; 17 = additional code size .equ VERIFY = 15 .equ ONEWIRE = 3 ;------------------------------------------------------------------------- ; Port definitions ;------------------------------------------------------------------------- .equ STX_PORT = PORTB .equ STX_DDR = DDRB .equ STX = PB2 .equ SRX_PIN = PINB .equ SRX_DDR = DDRB .equ SRX_PORT = PORTB .equ SRX = PB2 ;------------------------------------------------------------------------- .include "fastload.inc" ;------------------------------------------------------------------------- |
Datum: 15.10.2007 22:30
Angehängte Dateien:Kann sich bitte jemand meinen Schematischen Schaltplan für den „Eindraht-Betrieb“ ansehen, ob dort ein Fehler in der Schaltung ist… Ich hoffe, ich habe Peters Schaltplan richtig aufgebaut. Leider habe ich den Eindrahtmodus am ATmega8 noch nicht zum laufen gebracht. Mit zwei Drähten und einen MAX232 klappt es sofort. Würde gern den MAX232 einsparen. Hier meine Porteinstellungen für den Eindrahtmodus ;------------------------------------------------------------------------- ; Port definitions ;------------------------------------------------------------------------- .equ STX_PORT = PORTB .equ STX_DDR = DDRB .equ STX = PB1 .equ SRX_PIN = PINB .equ SRX_PORT = PORTB .equ SRX = PB1 ;-------------------------------------------------------------------------
Datum: 16.10.2007 21:35
Der Eindrahtmodus funktioniert jetzt :-) Es lag an: .equ ONEWIRE = 3 Danke für Eure Hilfe
Datum: 25.10.2007 21:16
Ich verfolge jetzt schon eine Zeitlang diesen super threat. Nun plane ich einen mega8 mit dem "ONEWIRE" zu flashen. Dazu habe ich mir tinyload3.zip heruntergeladen, in m8.asm die Ports angepasst und mit dem AVR-Studio ein Hexfile erzeugt - aber wo finde ich .equ CRC = 17 ; 17 = additional code size .equ VERIFY = 15 .equ ONEWIRE = 3 Werde mir Morgen noch das Kabel schnitzen Vielen Dank die Info
Datum: 26.10.2007 10:25
Ähm, den Bootloader finde ich klasse und um so bedauerlicher ist es, dass die Kokumentation des Protokolls immer noch "fehlt". Das "fehlt" deshalb in Anführungszeichen, da wir ja nicht wirklich einen Anspruch darauf haben. Aber einige -mich eingeschlossen- möchten gern die PC-Seite in andere Sprachen umsetzen oder gleich ganz in eine Applikation einbinden. Wäre doch schade, wenn so eine feine Applikation über die ersten, wenn auch sehr erfolgreichen, Schritte nicht hinaus kommt... Haben wir da noch Chancen ? Gruß, Stefan ---
Datum: 26.10.2007 11:31
Angehängte Dateien:Stefan wrote: > Ähm, den Bootloader finde ich klasse und um so bedauerlicher ist es, > dass die Kokumentation des Protokolls immer noch "fehlt". Das "fehlt" > deshalb in Anführungszeichen, da wir ja nicht wirklich einen Anspruch > darauf haben. Aber einige -mich eingeschlossen- möchten gern die > PC-Seite in andere Sprachen umsetzen oder gleich ganz in eine > Applikation einbinden. Wäre doch schade, wenn so eine feine Applikation > über die ersten, wenn auch sehr erfolgreichen, Schritte nicht hinaus > kommt... > Haben wir da noch Chancen ? O.k., hier isses. Peter
Datum: 26.10.2007 11:36
Und schon den ersten Fehler gefunden: ... 5. Abfrage Useflashgrö0e: Senden: COMMAND, USERFLASH Antwort: ANSWER, 0x04, Flash_high, Flash_mid, Flash_low, SUCCESS ... Peter
Datum: 26.10.2007 12:02
Angehängte Dateien:CRC vergessen. Peter
Datum: 26.10.2007 13:04
Nochmal Wo bitte finde ich die Defines .equ CRC = 17 ; 17 = additional code size .equ VERIFY = 15 .equ ONEWIRE = 3 Ich kann die Defines in der Source nicht finden - gibt es eine neuere Version von Loader als tinyload3.zip
Datum: 26.10.2007 13:12
Danke für das Protokoll ;-) Ich war leider mehrere Wochen ohne Internet (warum gibts sowas eigentlich nich im Krankenhaus?). Aber jetzt code ich wieder weiter an der IDE und auch nem Tool für den Bootloader mit klicki bunti g Ciao Karsten
Datum: 26.10.2007 13:32
Kurt wrote: > Ich kann die Defines in der Source nicht finden - gibt es eine neuere > Version von Loader als tinyload3.zip http://www.mikrocontroller.net/attachment/25943/fboot17.zip Peter
Datum: 26.10.2007 14:07
Falls es jemanden interessiert: Ich hab den Bootloader in nen ATtiny45 gebrannt und danach Reset disabled. Dann hab ich per Bootloader ein Programm reingeschrieben, welches PB5 toggled und es läuft. Peter
Datum: 26.10.2007 19:36
Hallo Peter, das interessiert schon. Vielen Dank! Ich muss im nächsten Bastelprojekt einen Tiny45 ausreizen. Da kommt es natürlich gut, wenn man alle Pins belegen kann. Da werde ich es ausprobieren. Gruß Gerd G.
Datum: 27.10.2007 15:27
Hallo Peter
Vielen Dank für den Hinweis.
Ich habe den mega8-Loader zunächst mal für Bidirektional angepasst.
Die Sende und Empfangspins
.equ STX_PORT = PORTD
.equ STX_DDR = DDRD
.equ STX = PD1
.equ SRX_PIN = PIND
.equ SRX_PORT = PORTD
.equ SRX = PD0
-------------------------------
Ich verwende einen 16Mhz Quarz
.equ XTAL = 16000000 ; 8MHz, not critical
.equ BootDelay = XTAL / 3 ; 0.33s
Fusebits BOOTSZ0=0
BOOTSZ1=1
BOOTRST=0
Wenn ich Fboot17.exe mit /Pxy.hex starte (das Programm xy.hex lief mit
ISP Programmierung), kann ich mit dem Skope an PD0 (RX) wildes Zappeln
zwischen -0,9 und +6V sehen. An PD1 (TX) sehe ich einen 4V Pegel und
alle 8ms für 240µs 0V. Am PC sehe ich "Com 1 at 115000 Baud: |" das
letzte Zeichen dreht sich bis zun St. Nimmerleinstag. Warum kann der PC
die Baudrate nicht finden? Liegt es an meinen 16MHz?
Datum: 27.10.2007 17:49
Kurt wrote: > Wenn ich Fboot17.exe mit /Pxy.hex starte (das Programm xy.hex lief mit > ISP Programmierung), kann ich mit dem Skope an PD0 (RX) wildes Zappeln > zwischen -0,9 und +6V sehen. Ohne MAX232 habe ich nur den 1-Drahtmodus vorgesehen (geht ja auch nicht anders). Im 2-Drahtmodus mußt Du noch die Bitmacros invertieren, wenn Du keinen MAX232 benutzt. Peter
Datum: 27.10.2007 23:39
Hey Peter....... Der Wahnsinn. Der Loader läuft jetzt mit ONEWIRE und das auch noch super schnell!!!! Vielen Dank für deine Geduld.
Datum: 04.11.2007 22:04
Hallo Peter, Da ich leider der Assembler-Sprache nicht so mächtig bin (g) wollte ich dich fragen, ob es ein großer Aufwand für dich wäre wenn du mir einen kurzen Tipp gibst, was ich für 3 zusäzlich abfragbare Variablen am Bootloader ändern muss.. (Im Prinzip so, wie die Versionsabfrage des Bootloaders..) Ich möchte gerne zwei 16Bit-Zahlen (für Software-, und Hardwarestand) hinzufügen. Zusätzlich bräuchte ich noch eine 16Byte breite Variable für die "Softwarebeschreibung". (Damit man nicht beim Gerät x die Firmware für Gerät y aufspielen kann; zur Not reicht hier auch eine 16Bit-Zahl - falls es einfacher zu realisieren ist..) Das ändern der PC-seitigen Software ist kein Thema.. Problematisch ist für mich nur der Assembler-Code. :( Danke schonmal im Vorraus! :) Gruß, Techniker PS: Der Bootloader ist echt absolute spitze! ;-)
Datum: 05.11.2007 21:13
Angehängte Dateien:Der Techniker wrote: > Da ich leider der Assembler-Sprache nicht so mächtig bin (g) wollte > ich dich fragen, ob es ein großer Aufwand für dich wäre wenn du mir > einen kurzen Tipp gibst, was ich für 3 zusäzlich abfragbare Variablen am > Bootloader ändern muss.. (Im Prinzip so, wie die Versionsabfrage des > Bootloaders..) Anbei die Routine. Abgefragt werden die 3 Parameter mit den Codes 253,254,255. Die Definitionen sind zwischen den =============-Zeilen. Peter
Datum: 05.11.2007 21:31
Angehängte Dateien:Hallo Peter! Zuersteinmal vielen dank! :) Leider ist mir gerade vorhin aufgefallen, dass es ja ein taktischer Blödsinn ist, wenn der Softwarestand im Bootloader hinterlegt ist.. dummguck Naja.. Hardwarestand und Software-ID werd ich aber auf jedenfall dort hinterlegen.. Zum Assembler-Code: Mittlerweile hab ich auch schon ein bischen rumexperimentiert.. ;-) (..habs aber noch nicht getestet..) Du schreibst:
;===================================================================== .equ user_no_253 = 0x1234 .equ user_no_254 = 0x5678 .equ user_no_255 = 0x9ABC ;===================================================================== subi a0, -3 ; add 3 messages (253,254,255) cpi a0, 7 brcs sendmessage ; 0 ... 6 subi a0, 3 ;===================================================================== |
Könnte ich auch das so formulieren: (?) In FASTLOAD.H hinzufügen:
.equ hwVER = 0xabcd .equ swID = 0x1234 |
FASTLOAD.INC siehe Anhang Gruß, Techniker
Datum: 05.11.2007 22:31
Hallo ich hab da auch mal eine frage. Ich möchte über die DTR leitung, einen Transistor ansteuern der mir dann reset kurz aktiviert. Dieses möchte ich mit der Option "/R" aktivieren können. Leider macht die DTR-Leitung jedoch bei jedem Init für etwa 625ms einen 12V-Impuls. Warum? Kann ich diesen irgendwie unterdrücken?
outportb(ComPort+4, 0x00); |
..macht keinen Unterschied zu..
outportb(ComPort+4, 0x01); |
Grüsse, Jochen
Datum: 06.11.2007 08:53
Der Techniker wrote: > Mittlerweile hab ich auch schon ein bischen rumexperimentiert.. ;-) > (..habs aber noch nicht getestet..) Dadurch verschieben sich aber auch alle bisher definierten Funktionen. Peter
Datum: 06.11.2007 16:45
>Leider macht die DTR-Leitung jedoch bei jedem Init für etwa 625ms einen >12V-Impuls. Warum? Kann ich diesen irgendwie unterdrücken? Hallo, koennte das wie beim USB FTDI CHIP die Enumaration ?
Datum: 06.11.2007 19:00
@Peter: Ja - das habe ich aber auch berücksichtigt. Mittlerweile läuft er wunderbar.. ;) - Danke! Die Idee mit der DTR-Leitung von "J.L." gefällt mir, jedoch habe ich das selbe "Problem".. :-/ Gibt es dafür eine Lösung? @Dirk: Wer oder was ist eine "Enumaration"? Kann man das essen? :o) Gruß, Techniker
Datum: 06.11.2007 20:46
@Dirk: Jetzt hab ich verstanden, was du meinst! ;) Auf gut deutsch: Mir funkt XP dazwischen.. :( Hab das ganze auf einem Win98-Rechner ausprobiert -> funktioniert einwandfrei! :) Auf einer XP-Kiste kommen immer noch ein paar Impulse zusätzlich.. :( Gibts da einen Workaraound? Gibts sowas wie MS Visual C++ als kostenlose Open-Source, damit man das DOS-Proggi XP-tauglich bekommt? Kennt da zufällig jemand etwas in der Richtung? Gruß, Techniker
Datum: 10.11.2007 20:10
Angehängte Dateien:Einer update von meiner dev-cpp (Windows 32) port von Peters bootloader Exe datei ist inkludiert. Ich habe nur probiert mit einer kleiner hexdatei , und ich brauche 57600 bps nicht 115200 (gibts probleme bei mir) grusse von Dänemark Bingo
Datum: 11.11.2007 20:17
Hallo PeDa, kleine OT-Nachfrage an den Praktiker: Wie bekommst Du den Bootloader das erste mal in den AVR? Nicht beim Labormuster sondern bei der Produktion? Bei DIL/DIP kein Thema, aber was ist bei den SMD-Typen? a) Erst einlöten - dann werden aber die ISP-Pins trotzdem benötigt und kosten Platz/Stecker. b) Spezielle Programmierfassung - sehr (Sau) teuer. c) Beim Distributer progammieren lassen - unflexibel weil Fusebits bekannt sein müssen (Takt Startup Brownout...) Gruß Jogi
Datum: 13.11.2007 11:03
Hallo zusammen, ich würde gerne den Bootloader von Peter für mein Gerät mit RS485 Schnittstelle verwenden. Ich schalte nun in der putchar-Routine zu Beginn den RS485-Treiber auf Senden und vor dem Verlassen der Routine wieder auf Empfangen. Diese Änderung funktioniert nun nur leider nicht sehr zuverlässig. Ich bekomme sehr oft einen CRC-Error. Ich habe es schon mit diversen Pausen vor und nach der Umschaltung versucht, doch ich bekomme das Timing nicht 100% in den Griff. Hat vielleicht von euch schon einer in dieser Richtung Erfahrungen gemacht? Wäre über jeden Tipp dankbar. Schöne Grüße andie.
Datum: 13.11.2007 20:44
Hallo, ich versuche gerade den bootloader auf meinem mega644 zum laufen zu bringen. Klappt jedoch nicht so richtig. Ich habe genau das gleiche Problem wie es schon Dirk Schmidt (disc) am 13.09.2007 weiter oben geschildert hat. Nur leider gab es damals keine Antwort... Ich bin beim flashen nach der wiki Anleitung vorgegangen. meine Einstellungen: TX und RX auf PortD, XTAL=18432000, bootdelay=xtal/3 ->mit "avrasm2 -fI m644.asm" übersetzt und mit ponyprog (lpt1) gebrannt ->fuses gesetzt: bootrst=0,bootsz1=1,bootsz0=0 beim Start von fboot.exe erscheint nun folgender fehler für V1.4
C:\boot>fboot /C1 /Pmain.hex COM 1 at 115200 Baud: Connected Bootloader VFFFFFFFF.FF Target: FFFFFFFF Buffer: -1 Byte Size available: -1 Byte CRC: error ! Elapsed time: 0.55 seconds |
und für V1.7
C:\boot>fboot17 /C1 /Pmain.hex COM 1 at 115200 Baud: Connected Bootloader VFFFFFFFF.FF Error, wrong device informations |
Ich habs auch schon mit einer geringeren Baudrate (wie oben empfohlen) probiert, leider ohne Erfolg. Dumme Frage: Könnte es an meinem Kabel liegen? Ich verwende in normales Nullmodemkabel. ´Hat jemand das selbe Problem gehabt und/oder kann mir helfen? Patrick
Datum: 13.11.2007 20:59
@Jogi: Würde mich auch mal interessieren.. ;) Den einzigen Vorteil von einem Bootloader (den ich sehe) ist, dass der Kunde ohne große Kenntnisse eine neue Firmware selber aufspielen kann.. Ich mache das schon seit einiger Zeit so, dass ich mir ein spezielles Footprint angelegt habe welches 3 Bohrungen und die ISP-Pins als kl. Kontaktflächen besitzt. Dann habe ich mir einen Handadapter aus Pertinax gebaut, der die 3 Bohrungen als Fixierung verwendet und die Kontakte mittels feinen Prüfnadeln herstellt. Das programmieren geht so recht einfach und fix - ohne große Plazverschwendung und Bauteilkosten. Sollte dann die Baugruppe in Serie gehen , werden die Kontakte dann mittels einer Prüflingsaufnahme kontaktiert.. Mit einem Bootloader wird das programmieren nur noch ein einziges mal gemacht und der Rest läuft über die RS232 oder einer "Programmierbuchse".. :) Gruß, Techniker
Datum: 13.11.2007 22:19
Patrick wrote: > Ich habs auch schon mit einer geringeren Baudrate (wie oben empfohlen) > probiert, leider ohne Erfolg. In Deinen Screenshots sinds aber immer nur 115200Baud, versuche mal /b19200. Die Versionen 1.4 und 1.7 sind zueinander inkompatibel, kann also nicht gehen. Die Version 1.7 ist besser, benutze diese (Assemblerprogramm und fboot17.exe). Peter
Datum: 13.11.2007 22:21
Jogi wrote: > Wie bekommst Du den Bootloader das erste mal in den AVR? > Nicht beim Labormuster sondern bei der Produktion? > > Bei DIL/DIP kein Thema, aber was ist bei den SMD-Typen? Ich habe keine Platzprobleme, benutze bisher nur DIP (gesockelt). Und die Serienproduktion lassen wir extern machen. Peter
Datum: 14.11.2007 09:02
Angehängte Dateien:@Peter Danke erstmal für die schnelle Antwort. Ich habe alles nochmal neu heruntergeladen (V1.7) und kompiliert. Es funktioniert aber trotzdem nicht. Hier kurz der Nachweis:
D:\fboot17>fboot17 /C1 /Ptest.hex COM 1 at 115200 Baud: Connected Bootloader VFFFFFFFF.FF Error, wrong device informations D:\fboot17>fboot17 /C1 /B19200 /Ptest.hex COM 1 at 19200 Baud: Connected Bootloader VFFFFFFFF.FF Error, wrong device informations D:\fboot17>fboot17 /C1 /B9600 /Ptest.hex COM 1 at 9600 Baud: Connected Bootloader VFFFFFFFF.FF Error, wrong device informations |
Ich habe jetzt mal die fastload.h, m644.asm und die m644.hex angehangen. Vielleicht hab ich dort irgendwo was verpeilt. Grüße, Patrick
Datum: 14.11.2007 09:44
@Patrick, muß irgendwie an Deinem PC liegen, das Connect wird noch empfangen und ab da nichts mehr. Hast Du irgendwelche Treiber für COM/LPT installiert? Erzähl mal was über Deinen PC (CPU, RAM, MHz, OS, COM, CPU-Auslastung usw.). Ich könnte mal ne Version mit nem längeren Timeout machen. Peter
Datum: 14.11.2007 10:12
@Peter Ich hab hier einen "alten" sony vario notebook: intel P2, 64mb ram, Windows2000 SP4, eine Com Schnittstelle, CPU Auslastung nach start von fboot geht auf 30%, über MHZ konnte ich nichts rausbekommen (wird irgendwie nicht angezeigt). Gestern hab ich es auch schon auf einem Acer notebook (winXP, 1.5GHz, 512MB ram, intel centrino) probiert. -> gleiches Problem... dabei muss ich aber sagen, dass bis gestern abend noch die version 1.4 auf dem µC war und der comport über einen usb2rs232 dongel emuliert wurde... Es wäre eigentlich wichtig, dass der loader auch über den vario läuft. Da ich hier keinen anderen pc zur Verfügung habe. Patrick
Datum: 14.11.2007 10:15
ups meinte natürlich sony vaio.... Patrick
Datum: 14.11.2007 14:16
Ich hatte das Problem auch mal, ich glaube ich musste den Watchdog per fuse abschalten damit es richtig klappte. Müsste aber nochmal nachsehen ob es das war.
Datum: 14.11.2007 14:40
@Tino Ich habs gleich mal probiert. Das Problem besteht jedoch weiterhin... Grüße, Patrick
Datum: 14.11.2007 15:55
Angehängte Dateien:Hier mal ein Screenshot der Fusebits, damit hat es bei mir funktioniert.
Datum: 14.11.2007 21:56
Tino wrote: > Ich hatte das Problem auch mal, ich glaube ich musste den Watchdog per > fuse abschalten damit es richtig klappte. Müsste aber nochmal nachsehen > ob es das war. Mein Bootloader unterstützt keinen Watchdog. Der Watchdog muß abgeschaltet sein! Man sollte den Watchdog nicht überschätzen. Er ist ein völlig ungeeignetes Mittel, um seine eigenen Programmierfehler zu verschleiern. Wer den Watchdog benutzt, sollte ihn ja leicht in den Bootloader einfügen können. Peter
Datum: 15.11.2007 10:44
@Tino + Peter Es klappt, super! Es lag wirklich am Wotchdog. Danke für die schnelle Hilfe. Das einzige was noch komisch ist, ist dass ich ab dem 2ten mal den Rest manuell machen muss. Woran könnte das liegen? Patrick
Datum: 15.11.2007 16:07
Ok, möchte mich für die dumme Frage entschuldigen. Wer lesen kann ist klar im Vorteil. Also vielen Dank nochmal für die Lösungsvorschläge!! Patrick
Datum: 15.11.2007 16:09
Ich weiß gerade nicht was du meinst, was musst du manuell machen?
Datum: 20.11.2007 17:09
Hi Peter. Wonderfull product! I'd tested it on Tiny45 with great success. Now I designed DS2450 ADC emulator based on Tiny45 and 1wire bootloading is especially interesting for me. But in your 1wire variant you excluded TTL-RS232 level converter, so the data is inverted for 1wire case. It is not quite suitable. What I need to correct in the bootloader code to make it work with, say max232? Thanks in advance, Vladimir.
Datum: 21.11.2007 13:52
Hallo Peter, ich war schon von deinem ersten Bootloader fasziniert. Nutze diesen schon lange auf dem ATmega8. Den aktuellen Bootloader würde ich gerne nutzen, da dieser noch kleiner geworden ist. Zum aktuellen Bootloader habe ich allerdings eine Frage. Wie kann es sein, das der neue Bootloader erst nach einem Reset funktioniert, wo doch der alte Bootloader nach einem Reset und einem Power on funktioniert? Danke für deine Hilfe, Gruß Tobi
Datum: 21.11.2007 14:51
Tobi wrote: > Wie kann es sein, das der neue Bootloader erst nach einem Reset > funktioniert, wo doch der alte Bootloader nach einem Reset und einem > Power on funktioniert? Jedes Reset startet den Bootloader für ~0,3s Ist der Resetpin aber als IO definiert, geht nur noch das Poweronreset. Peter
Datum: 29.11.2007 13:10
Angehängte Dateien:Hallo, ich versuche im Moment vergeblich den Bootloader auf einem Mega32 zum laufen zu bekommen. Im Anahng ist meine Konfiguration. Ich habe eigentlich nur die Frequenz auf 16000000 umgestellt und die Schnittstellen Pins auf die der Hardware UART gelegt. Das BOOTRST Fuse-Bit habe ich auf 0 gesetzt und die BOOTSZ Fuses auf 11 für 256 Words. 10 für 512 Words habe ich auch schon getestet, weil ich da verschiedene aussagen gelesen habe. Das FBoot Tool bleibt mit diesem Output stehen 'COM 1 at 115200 Baud:'. Dahinter dreht sich dann der Balken. Am RX-Pin vom Controller kann ich dann die eingehenden Daten mit dem Oszi sehen. Jedoch Antwortet der Controller nicht. Der Controller ist über einen MAX232 mit dem PC verbunden. woran könnte das liegen? Ich habe alles anhand des Artikels gemacht. Ich habe das Gefühl als würde der Bootloader nicht ausgeführt. Hat da Jemand noch eine Idee? Danke im Voraus! Gruß Benedikt
Datum: 29.11.2007 21:23
@Benedikt setz mal die Baudrate runter: fboot17 -b9600 Schwingt Dein Quarz? setz mal die Fuses auf internen Takt 8MHz Peter
Datum: 04.12.2007 19:43
Angehängte Dateien:Hallo Peter, vielen Dank für deine Antwort! Leider bin ich erst gerade zum testen gekommen. Ich habe sowohl die niedrigere Übertragungsrate als auch die 8MHz intern Quarzfrequenz getestet. beides funktioniert leider nicht. Der Bootloader Antwortet einfach nicht. Hast du vielleicht noch eine Idee? Im Anhang ist die Hex-Datei die ich aus dem Mega32 wieder ausgelesen habe. Das sieht eigentlich gut aus, die Bootloader Adresse stimmt. Gruß Benedikt
Datum: 04.12.2007 21:27
Hallo Peter, ich habe den (dummen) Fehler gefunden... Es hatte nix mit dem Bootloader oder den Fuses zu tun. Ich hatte einfach nur ein mini kleine Brücke von GND auf Reset gemacht. Dann kann der AVR natürlich nicht laufen ;-) Danke trotzdem für deine Antwort! Der Bootloader ist echt genial. Gruß Benedikt
Datum: 05.12.2007 16:32
Gibt es schon 'was Neues von der Delphi-Umsetzung des PC-Teils ?
Datum: 14.12.2007 00:28
habe jetzt auch mal den Bootloader ausprobiert, funktioniert bis auf ein größeres Problem einwandfrei: ich kann fboot.exe nur ein Mal verwenden, beim 2.Mal hängt es sich beim Versuch zu connecten auf (Ausgabe bis zum "Propeller", dieser wird aber nicht ein einziges Mal ausgegeben) wenn ich Windows98 neu starte geht es wieder ein einziges Mal. Wenn der Bootloader im AVR nicht aktiv ist und ich das Programm mit Tastendruck abbreche kann ich es immer wieder starten und es propellert Was tun?
Datum: 14.12.2007 09:54
@Walter Wie startest Du das Programm, DOS-Box oder im Explorer? Bei der DOS-box mal mit den erweiterten Einstellungen spielen. Hängt sich W98 richtig auf oder kannst Du die Task killen? Benutzt Du ne echte RS232 oder nen USB-RS232 Dongle? Welchen AVR benutzt Du? Probier mal nen kleineren AVR (<64k). Hast Du keinen Rechner mit XP drauf? Peter
Datum: 14.12.2007 19:08
Ich opere hier mit einem ATMEGA324P herum und komme nicht zu Stuhle. Mal eine Frage, was hat es mit mit folgenden Statement in m32.asm auf sich? ;Attention: BufferSize must fit perfectly into BootStart ! ;e.g. BufferSize * 18 = BootStart .equ BufferSize = (14*PageSize) Die Pagesize ist 64 Bytes, so das bei 256 Bytes von 3f00 bis 3fff da nur 4 hinen passen, also wie hängt das hier zusammen? 14*64 = 380 hex bzw. 896 dez Bytes.... ? Gruß, Holm
Datum: 14.12.2007 21:33
@Peter Hallo Peter, >Wie startest Du das Programm, DOS-Box oder im Explorer? ich hab eine Batchdatei mit dem Aufruf geschrieben die ich per Doppelklick starte. Jetzt habe ich es mal in der DOS Box probiert, da funktioniert es immer wenn ich den Aufruf per Hand eintippe, will ich aber die Batchdatei starten, kommt eine MSDOS Meldung: ON oder OFF muss angegeben werden, was soll uns das sagen? Hat zwar nix mit deinem Programm zu tun aber vielleicht kennst du die Meldung ja. Mit der DOS Box kann ich gut leben, würde mir aber wenn möglich die Tipparbeit sparen wollen ... >Hängt sich W98 richtig auf oder kannst Du die Task killen? nein, nur die Task hängt, lässt sich problemlos stoppen >Benutzt Du ne echte RS232 oder nen USB-RS232 Dongle? eine echte RS232 >Welchen AVR benutzt Du? mega8 >Probier mal nen kleineren AVR (<64k). >Hast Du keinen Rechner mit XP drauf? nein, und beim nächsten Rechner werde ich mich Mal mit Linux herumschlagen ... Grüße Walter
Datum: 15.12.2007 19:25
holm wrote: > Ich opere hier mit einem ATMEGA324P herum und komme nicht zu Stuhle. Nimm das File für den M32 und ändere Die Portpins und das Include. > Mal eine Frage, was hat es mit mit folgenden Statement in m32.asm auf > sich? > > ;Attention: BufferSize must fit perfectly into BootStart ! > ;e.g. BufferSize * 18 = BootStart Um die Schreibroutine einfach zu halten schreibt sie immer komplette Buffergrößen, auch wenn der letzte Buffer nur ein Word beinhaltet. Es ist ja auch egal, was noch hinter dem Programm steht, wird ja nie ausgeführt. Deshalb muß die Buffergröße ohne Rest in den Flash vor dem Bootloader passen. Wenn man das nicht beachtet, gibts ne Fehlermeldung, wenn man den Userflash komplett voll schreiben will. Die Buffergröße muß natürlich ein Vielfaches der Pagegröße sein und kleiner als der SRAM (in Words). Peter
Datum: 15.12.2007 19:28
Walter wrote: > ich hab eine Batchdatei mit dem Aufruf geschrieben die ich per > Doppelklick starte. Jetzt habe ich es mal in der DOS Box probiert, da > funktioniert es immer wenn ich den Aufruf per Hand eintippe, will ich > aber die Batchdatei starten, kommt eine MSDOS Meldung: > ON oder OFF muss angegeben werden, was soll uns das sagen? Zeig mal die Bat. Häng mal den Befehl Pause ans Ende, kann sein, daß dem Programm die UART weggezogen wird, befor es fertig ist. Peter
Datum: 16.12.2007 01:54
Das ON oder OFF kommt von sicher einem "ECHO" ohne Text. Muss man "ECHO." schreiben (echo<Punkt>). WIN9x macht eine DOS-Box die von einem BATCH geöffnet wird nicht automatisch zu. Da muss ein "EXIT" ans Ende.
Datum: 17.12.2007 14:32
die Batchdatei enthält z.B. für Verify nur eine Zeile: fboot /C1 /B2400 /Vdefault/hauszent.hex ich habe festgestellt dass es ja jetzt V1.7 statt 1.4 gibt, es bleibt aber beim gleichen Effekt. Komisch dass ich scheinbar der einzige bin ...?? Keiner mehr mit W98?? Pause bringt übrigens auch nix. Ich habe jetzt mal fboot.c für Visual C 6.0 angepasst, das funktioniert einwandfrei. Falls es jemand gebrauchen kann bitte melden ... Könnte auch V1.7 anpassen, aber da müsste ich dann die Segmentierung wieder zurückdefinieren :-( @Werner ECHO ist keins in der Batchdatei, nur der Aufruf von fboot.exe Walter
Datum: 17.12.2007 18:49
Ich habe auch kein W98 mehr aber operiere auf einem W2K herum wenn ich schon irgend eine Form Dos benutzen muß ... Ich weiß, das etwas mit dem fboot17 nicht stimmt, wenn ich das Help aufrufe steht da das ich die any key pressen soll, aber beenden kann ich das nur wenn ich den Task von CMD abschieße. Konsoleeingaben sind irgendwie blockert. Gruß, Holm
Datum: 26.12.2007 15:01
Angehängte Dateien:Ich habe mal den C Code des PC-Teils mal nach Python portiert (siehe Anhang), da ich ihn aus einer Python GUI verwenden will. Getestet bisher nur unter Ubuntu mit einem ATMega168, sollte aber auch unter Windows lauffähig sein. Leider gibt es noch ein Problem mit dem CRC Check, scheinbar wird da irgendwas nicht korrekt berechnet, der AVR meldet jedenfalls immer einen Fehler obwohl die Daten korrekt geschrieben werden. CRC ist daher im Moment deaktiviert. Grüße Fabian PS: Aktuellere Versionen gibt's dann unter folgender Adresse: http://www.kreatives-chaos.com/artikel/fastboot17-...
Datum: 28.12.2007 22:29
@Fabian super das es jetzt auch einen Client für Linux für die 1.7 Version gibt. Leider bekomme ich keinen connect. Der Bootloader futzt da es mit Fboot17.exe klappt. Ich verwende einen Mega162. Der Anschluss an den uC erfolgt über /dev/ttyS0 auf einen Max232. Habe alle Baudraten probiert. Daran sollte es auch nicht liegen da unter Win es mit 115k klappt. Python ist nicht so mein Ding aber mir ist aufgefallen das der Mega162 nicht bei den Targets in deinem Programm enthalten ist. Aber bis zu dieser Abfrage kommt er ja erst gar nicht. Wäre nett wenn Du eine Idee hast wie ich einen connect bekomme. @Peter Dannegger Vielen Dank für den tollen Bootloader Viele Grüße Fred
Datum: 29.12.2007 11:50
So bin nun schon 2 schritte weiter.
In deinem Programm habe ich hinter den Passwortstring noch ein 0x00
gehängt dann hatte ich den gewünschten connect.
# try to connect to the bootloader
echo = False
password += chr(0xff)
password += chr(0x00)
pos = 0
Und dann noch das target ergänzt so das dann auch die Daten übertragen
wurden. Leider funktioniert das Programm im uC noch nicht :(
targets = {
0x1e9007: "ATtiny13",
0x1e910A: "ATtiny2313",
0x1e9206: "ATtiny45",
0x1e9205: "ATmega48",
0x1e9307: "ATmega8",
0x1e9403: "ATmega16",
0x1e9406: "ATmega168",
0x1e9502: "ATmega32",
0x1e9609: "ATmega644",
0x1e9802: "ATmega2561",
0x1e9404: "ATmega162",
}
Viele Grüße
Fred
Datum: 29.12.2007 13:37
So ich hab mal die beiden HEX-Files mit Ponyprog ausgelesen und
verglichen
dabei habe ich festgestellt das der letzte Datenblock nicht mit
übertragen wurde.
Leider habe ich wie gesagt von Python nicht viel Ahnung aber der Fehler
liegt
zwischen den Zeilen 280-313. Vieleicht ist dies auch der Fehler warum
das CRC nicht funktioniert.
Könnte das bitte mal jemand checken der was von Python versteht.
Vielen Dank
Fred
Hier die Programmzeilen 280-313
while True:
# get one byte
byte = hex_data[addr]
# escape and send it
if byte == self.ESCAPE or byte == 0x13:
self.send(self.ESCAPE)
byte |= self.ESC_SHIFT
self.send(byte)
bufferpos -= 1
if bufferpos == 0:
print "\b\b\b\b\b\b%05x" % (addr + 1),
sys.stdout.flush()
if not verify and self.receive(10) != self.CONTINUE:
print " failed!"
return 1
bufferpos = self.buffersize
addr += 1
if addr == len(hex_data):
print "\b\b\b\b\b\b%05x" % addr,
# send the end-record (0xA5, 0x80)
self.send_command(self.PROGEND)
if self.receive(10) == self.SUCCESS:
print " successful"
return 0
else:
print " failed!"
return 1
Datum: 29.12.2007 16:18
Angehängte Dateien:Hallo Fabian, jetzt komm ich nicht mehr weiter da nicht nur am Ende sonder zwischendurch auch 3 Fehler aufgetreten sind. Zur veranschulichung gabe ich das Ergebniss von diff mal als Anhang beigefügt. Linke Spalte ist das HEX-File wenn ich mit fboot.exe übertrage und die rechte Spalte ist die Fehlerhafte. Ich hoffe es hilft um den Fehler zu finden. Viele Grüße Fred
Datum: 30.12.2007 22:21
Angehängte Dateien:So, hier nochmal ein paar kleine Verbesserungen: Es gibt jetzt nur noch ein Assemblerfile für alle AVRs. Einfach vor dem gewünschten Include das ; entfernen, die UART-Pins auswählen, fertig. Buffersize, Bootstart, Onewire werden nun automatisch ermittelt. Als neue Funktion ist die Watchdogunterstützung hinzugekommen. Der Watchdog wird auf 2s verlängert, wenn er enabled ist. Das PC-Programm muß also mindestens alle 2s ein Byte senden. Das sollte für das PC-Programm ausreichen. Die Liste mit den Signaturen ist jetzt als extra File ausgelagert. Man kann also dort noch neue AVRs eintragen. Das DEF-File muß im gleichen Verzeichnis wie die EXE stehen. Am Protokoll hat sich nichts geändert. Peter
Datum: 31.12.2007 14:35
Angehängte Dateien:Hallo Fabian, ich hoffe Du hast nichts dagegen das ich in deinem Programm rumgewurschtelt habe. Jetzt läuft es bei mir endlich einwandfrei. In Zeile 77 mußte ich ne kleine Pause einbauen sonst gibts kein connect. Den sys.stdout.flush() beim Bufferende musste ich bei mir auch rauswerfen da sonst Daten fehlen Der eigentliche Fehler ist jedoch in Zeile 285ff if (byte == self.ESCAPE) or (byte == 0x13): Da Peter mit einer unsigned char Variablen arbeitet kommt dann beim byte |= self.ESC_SHIFT unter Python ein ganz anderer Wert raus als unter C. Ich hoffe du entwickelst das Programm noch weiter da es wiklich Prima ist. so und nun einen guten Rutsch ins neue Jahr vom Fred
Datum: 31.12.2007 17:37
Hallo Peter, ich habe den Bootloader in v1.8 auf meinen Mega644 gespielt. Das hat auch alles so weit funktioniert, nur leider startet das Anwendungsprogramm nach dem flashen nicht. Hast du da einen Tipp für mich?
Datum: 06.01.2008 12:20
Hallo, ich habe ebenfalls grade den FBOOT18 auf einen ATmega8 gespielt. Funktioniert alles einwandfrei. Danke. Kann mir evtl. jemand mit den Look Bits weiterhelfen? Welche kann ich setzten, damit der Bootloader noch funktioniert? Welche dürfen auf keinen Fall gesetzt werden? Ich habe mir zwar das Datenblatt schon angesehen, steige aber nicht so ganz durch. Ich würde gerne den Bootloader und die Aplikation gegen Auslesen schützen. MfG Tobias
Datum: 07.01.2008 21:29
@Peter D Peter ich habe deiner version 18 und die version 17a von AvrFreaks compared. (Nur die teile vie lauft am Pc). Ich kan keiner differenz sehe. Ist das korrekt das die PC programm , ist die selber im 17a und 18 ?? Und das alle verbesserungen ist im die neye AVR target files layout ?? Dan funktioniert meiner devcpp port von 10.11.2007 auch (oder ??) Danke fur die bootloader mfg Bingo aus Dänemark
Datum: 07.01.2008 22:08
Bingo wrote: > Ist das korrekt das die PC programm , ist die selber im 17a und 18 ?? Ja, die Versionen sind gleich. > Und das alle verbesserungen ist im die neye AVR target files layout ?? Auch da ist alles gleich, nur die Watchdogunterstützung ist hinzugekommen. Und einige Vereinfachungen, um andere AVRs einzubinden. Peter
Datum: 09.01.2008 15:47
Ich hätte noch eine PC-Software in Java. Diese unterstützt KEIN OneWire und ist nur mit Version 1.7 getestet. Aber vielleicht ist das ja für den einen oder anderen interessant. Der Code findet sich in der PC-Software meines Motorcontrollers: http://www.matuschek.net/motorsteuerung-software/ Viele Sachen sind dort sehr einfach gehalten, da gibt es sicher noch Potential für Verbesserungen. Aber es funktioniert prinzipiell...
Datum: 10.01.2008 21:35
Angehängte Dateien:Hallo Assembler Cracks, Bräuchte mal nen Tip wie ich es machen könnte das der Bootloader mit einem Max 485 zusammenarbeitet. Im Anhang ist mein Versuch die uart.inc anzupassen aber es klappt einfach nicht :( SCS_PORT und SCS sind in m16.asm definiert und sollen Senden und Empfangen entsprechend umschalten. Aber der SCS Pin bekommt einfach keine 5 Volt Ich habe in C ein Testprogramm geschrieben das die Daten vom RS485 abholt und auf einen Disolay ausgibt. Und es werden Peda+0xFF empfangen sodas der Bootloader ja eigentlich antworten sollte. Kann da bitte mal jemand mit Assembler Erfahrung schauen woran es liegen könnte. ;------------------------------------------------------------------------- ; Port definitions ;------------------------------------------------------------------------- .equ STX_PORT = PORTD ;TX .equ STX_DDR = DDRD .equ STX = PD1 .equ SRX_PIN = PIND ;RX .equ SRX_PORT = PORTD .equ SRX = PD0 .equ SCS_PORT = PORTD ;RS485 Steuerpin .equ SCS_DDR = DDRD .equ SCS = PD2 ;------------------------------------------------------------------------- .include "fastload.inc" ;------------------------------------------------------------------------- Vielen Dank Fred
Datum: 10.01.2008 22:42
Hallo *, 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 ? --AUSGABE beim Assemblieren: AVRASM: AVR macro assembler 2.1.2 (build 99 Nov 4 2005 09:35:05) Copyright (C) 1995-2005 ATMEL Corporation bootload.asm(38): Including file 'C:\Programme\Atmel\AVR Tools\AvrAssembler2\Appnotes\m1281mdef.inc' bootload.asm(62): Including file 'fastload.inc' fastload.inc(9): Including file 'fastload.h' fastload.h(2): Including file 'compat.h' fastload.h(3): Including file 'protocol.h' FATAL ERROR: Too deeply nested macro calls(16) Assembly failed, 0 errors, 0 warnings --Ende der Ausgabe: Gruss, Ludger
Datum: 11.01.2008 00:01
Angehängte Dateien: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
Datum: 11.01.2008 08:59
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.
Datum: 11.01.2008 14:28
@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
Datum: 11.01.2008 17:48
@ 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
Datum: 12.01.2008 11:07
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
Datum: 12.01.2008 18:17
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
Datum: 14.01.2008 11:59
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.
Datum: 15.01.2008 14:59
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.
Datum: 15.01.2008 15:24
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
Datum: 16.01.2008 07:30
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
Datum: 18.01.2008 18:03
@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
Datum: 20.01.2008 02:32
@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
Datum: 20.01.2008 17:09
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
Datum: 23.01.2008 21:42
Angehängte Dateien: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
Datum: 27.01.2008 00:07
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?
Datum: 27.01.2008 00:18
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
Datum: 27.01.2008 00:30
@ 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
Datum: 27.01.2008 18:43
Angehängte Dateien:@Peter D Hier ist einer source im TurboC , für 9bit kommunikation. mfg Bingo
Datum: 27.01.2008 19:24
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
Datum: 28.01.2008 15:05
Angehängte Dateien: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
Datum: 03.02.2008 19:48
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
Datum: 03.02.2008 21:08
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
Datum: 03.02.2008 22:22
"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.
Datum: 04.02.2008 00:36
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
Datum: 04.02.2008 12:42
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?
Datum: 04.02.2008 13:14
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/Bo... Peter
Datum: 04.02.2008 13:35
Danke, das habe ich in den wenigen hunderten Beiträgen übersehen... Der Link könnte auch in den Wiki Beitrag zu deinem Bootloader rein.
Datum: 04.02.2008 13:47
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
Datum: 04.02.2008 13:56
@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
Datum: 04.02.2008 14:46
Angehängte Dateien: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
Datum: 04.02.2008 15:02
danke, das sieht doch sehr brauchbar aus.
Datum: 05.02.2008 09:56
Angehängte Dateien: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
Datum: 05.02.2008 11:36
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
}
Datum: 05.02.2008 12:14
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
Datum: 05.02.2008 12:30
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));
}
}
Datum: 05.02.2008 13:18
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.
Datum: 05.02.2008 14:50
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).
Datum: 06.02.2008 11:10
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...
Datum: 06.02.2008 12:16
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
Datum: 06.02.2008 12:52
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
Datum: 06.02.2008 13:08
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
Datum: 06.02.2008 13:11
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 ?
Datum: 06.02.2008 13:34
Hallo, ich verwende einen Atmega8, hab ich im Post eigentlich schon geschrieben ;-) Danke, Deine Antworten helfen mir aber schon weiter. Grüße David
Datum: 07.02.2008 10:53
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
Datum: 07.02.2008 12:55
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.
Datum: 15.02.2008 15:42
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
Datum: 15.02.2008 17:45
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
Datum: 15.02.2008 21:05
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
Datum: 16.02.2008 18:04
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
Datum: 17.02.2008 14:27
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
Datum: 17.02.2008 14:38
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
Datum: 21.02.2008 20:07
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)
Datum: 21.02.2008 20:16
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.
Datum: 03.03.2008 22:57
Angehängte Dateien:@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
Datum: 04.03.2008 09:39
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
Datum: 04.03.2008 13:39
Angehängte Dateien:Ü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
Datum: 04.03.2008 13:41
> Prolific 2303 USB-Seriell Adapter funktioniert;
Ports COM 14 + COM 15 funktionieren auch ;-)
Gruß Sven
Datum: 04.03.2008 15:24
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
Datum: 04.03.2008 21:05
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
Datum: 04.03.2008 21:21
>> 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
Datum: 04.03.2008 21:25
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
Datum: 05.03.2008 09:26
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
Datum: 05.03.2008 12:12
@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
Datum: 07.03.2008 08:50
Angehängte Dateien: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
Datum: 09.03.2008 14:18
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
Datum: 09.03.2008 16:26
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
Datum: 09.03.2008 19:41
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
Datum: 09.03.2008 19:56
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
Datum: 09.03.2008 20:23
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
Datum: 09.03.2008 20:23
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
Datum: 10.03.2008 09:43
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.
Datum: 10.03.2008 09:54
In den ersten Versionen von Pedas Bootloadern (April/Mai 2004) war die Funktion noch mit drin. Damals noch für Mega8/16. Gruß JoJo
Datum: 10.03.2008 18:35
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.
Datum: 12.03.2008 22:53
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
Datum: 13.03.2008 08:56
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%2... Peter
Datum: 13.03.2008 15:26
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
Datum: 13.03.2008 19:07
frans@seabed.nl 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
Datum: 14.03.2008 14:39
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
Datum: 16.03.2008 19:12
dear Frans, please take a look at this page, which is automatical translated by google. http://translate.google.com/translate?u=http%3A%2F... cu
Datum: 16.03.2008 19:49
frans@seabed.nl 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_Bootlo... Peter
Datum: 17.03.2008 13:58
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...
Datum: 17.03.2008 19:18
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
Datum: 17.03.2008 19:43
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
Datum: 17.03.2008 20:01
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
Datum: 18.03.2008 11:32
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
Datum: 18.03.2008 11:43
Angehängte Dateien:Jetzt versuche ich noch ein mal den Dateianhang zu schicken, der nicht gegangen ist. Jetzt ist er 352K gross. Alexei
Datum: 21.03.2008 02:06
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
Datum: 23.03.2008 18:45
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
Datum: 23.03.2008 20:55
Hannes wrote: > Hallo zusammen, > > kann man die Schaltung , wie in der bootloader.pdf beschrieben , direkt > an die R232 eines PC anschliessen ? Ja. Peter
Datum: 25.03.2008 18:19
Angehängte Dateien: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
Datum: 28.03.2008 20:42
@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
Datum: 28.03.2008 21:14
Angehängte Dateien:frans@seabed.nl 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
Datum: 29.03.2008 12:07
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....
Datum: 29.03.2008 14:27
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.
Datum: 29.03.2008 16:21
> 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
Datum: 29.03.2008 17:26
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
Datum: 30.03.2008 13:52
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
Datum: 01.04.2008 22:11
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
Datum: 01.04.2008 23:08
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
Datum: 01.04.2008 23:53
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
Datum: 02.04.2008 18:50
> 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
Datum: 03.04.2008 09:32
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
Datum: 03.04.2008 20:35
Angehängte Dateien: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%2... Peter
Datum: 03.04.2008 20:51
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
Datum: 05.04.2008 10:48
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
Datum: 05.04.2008 11:04
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.
Datum: 05.04.2008 17:46
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
Datum: 06.04.2008 01:24
Angehängte Dateien: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
Datum: 06.04.2008 19:25
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
Datum: 06.04.2008 20:19
> 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
Datum: 08.04.2008 10:44
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?
Datum: 08.04.2008 19:46
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
Datum: 15.04.2008 23:35
Angehängte Dateien: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
Datum: 21.04.2008 13:43
@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
Datum: 21.04.2008 14:16
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
Datum: 22.04.2008 22:55
Angehängte Dateien: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ß
Datum: 23.04.2008 00:01
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
Datum: 23.04.2008 01:59
>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
Datum: 23.04.2008 07:38
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 :)
Datum: 23.04.2008 10:45
Nimm doch bitte mal zum Test die Version 1.8 oder 1.9. http://www.avrfreaks.net/index.php?module=Freaks%2... 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
Datum: 23.04.2008 17:49
Angehängte Dateien: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ß
Datum: 23.04.2008 20:29
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
Datum: 23.04.2008 21:01
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
Datum: 23.04.2008 21:03
Angehängte Dateien:Mit dem Anhang hat es nicht richtig geklapt !!
Datum: 23.04.2008 21:21
Hallo vergesst meine letzten beiden Einträge ich Dussel hab das DosProgramm mit den falschen Parametern betrieben Fuktioniert wunderbar Danke trotzdem !!!
Datum: 23.04.2008 21:22
Pier S. wrote:
> Mit dem Anhang hat es nicht richtig geklapt !!
fboot /pfilename /vfilename
Peter
Datum: 23.04.2008 21:25
Angehängte Dateien: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
Datum: 23.04.2008 22:27
Vielen Dank Peter, werde das gleich mal probiert. Habe das vorhin auch mit einem mega8 probiert (V2) da ging es auch ohne Probleme.
Datum: 23.04.2008 22:46
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ß
Datum: 23.04.2008 23:42
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
Datum: 24.04.2008 00:32
>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. :)
Datum: 24.04.2008 10:01
@ 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.
Datum: 24.04.2008 10:13
@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
Datum: 24.04.2008 21:31
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
Datum: 02.05.2008 12:13
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
Datum: 06.05.2008 09:03
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
Datum: 06.05.2008 09:40
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
Datum: 06.05.2008 09:46
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
Datum: 06.05.2008 09:53
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
Datum: 06.05.2008 10:11
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
Datum: 06.05.2008 10:54
>>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
Datum: 14.05.2008 08:31
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
Datum: 27.05.2008 19:59
Angehängte Dateien: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
Datum: 02.06.2008 21:22
Funktioniert der Bootloader auch mit 32768Hz Systemtakt?
Datum: 12.07.2008 18:25
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
Datum: 12.07.2008 18:52
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
Datum: 12.07.2008 19:11
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
Datum: 12.07.2008 19:17
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
Datum: 12.07.2008 19:33
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
Datum: 29.07.2008 00:11
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
Datum: 01.08.2008 19:13
Angehängte Dateien: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.
Datum: 02.08.2008 01:57
schau dir den mal an der ist schlanker Beitrag "AVR-Bootloader mit Verschlüsselung" gruß Sven
Datum: 02.08.2008 12:12
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...
Datum: 02.08.2008 13:05
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
Datum: 02.08.2008 16:25
Angehängte Dateien: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
Datum: 03.08.2008 21:32
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.
Datum: 03.08.2008 22:23
So jetzt habe ich mich ausgesperrt - unter welchen Umständen startet bei einem ATtiny der bootloader nicht?
Datum: 03.08.2008 22:45
evtl. Falsche Fuses, d.h. beim "Hochfahren" wird NICHT in den Bootloader gesprungen!? Gruß Christian
Datum: 03.08.2008 23:00
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
Datum: 03.08.2008 23:14
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.
Datum: 04.08.2008 00:53
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
Datum: 04.08.2008 19:26
> 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
Datum: 06.08.2008 00:49
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
Datum: 07.08.2008 17:47
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
Datum: 09.08.2008 00:53
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.
Datum: 09.08.2008 14:57
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
Datum: 18.08.2008 14:32
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
Datum: 18.08.2008 18:16
@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
Datum: 18.08.2008 19:19
@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.
Datum: 18.08.2008 22:18
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
Datum: 26.08.2008 16:50
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-... >> 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
Datum: 26.08.2008 19:48
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
Datum: 31.08.2008 19:12
Angehängte Dateien: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.
Datum: 31.08.2008 21:01
@mäxchen versuch mal ne kleinere Baudrate (-b19200). Der Bootloader benötigt 256 Words (=512Byte). Peter
Datum: 31.08.2008 21:15
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.
Datum: 31.08.2008 21:34
Danke für die Hilfe mit weniger Baud geht es! Aber woran kann das liegen? Schlecht geschirmtes Kabel?
Datum: 01.09.2008 00:12
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.
Datum: 01.09.2008 13:01
Aha, das kann gut sein. Mein up läuft nämlich auf 4 Mhz. Vielen Dank für die Hilfe!
Datum: 14.09.2008 22:32
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
Datum: 25.09.2008 22:08
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
Datum: 25.09.2008 23:04
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
Datum: 25.09.2008 23:34
Stimmt eigentlich. Auch die 3% bei den 8k-AVRs sind alles andre als tragisch. Danke für die schnelle Antwort! Grüße, holli
Datum: 19.10.2008 21:59
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.
Datum: 19.10.2008 22:20
Newbie wrote: > a), b), c) AVR Bootloader FastBoot von Peter Dannegger > c) wie kann man damit Werte ins EEPROM schreiben? Beitrag "UART Bootloader ATtiny13 - ATmega644"
Datum: 19.10.2008 22:29
@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.
Datum: 19.10.2008 22:59
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.
Datum: 28.10.2008 02:13
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?
Datum: 28.10.2008 19:52
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
Datum: 10.11.2008 07:02
moin Leute! - es dreht sich um den atmega8 - Habe den Bootloader (http://www.mikrocontroller.net/attachment/24619/fa...) 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...
Datum: 10.11.2008 08:56
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).
Datum: 10.11.2008 09:42
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.
Datum: 10.11.2008 09:47
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???
Datum: 10.11.2008 10:18
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).
Datum: 10.11.2008 10:41
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...
Datum: 10.11.2008 11:00
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 d








