Hallo zusammen, Versuche zur Zeit, den Bootloader von http://jump.to/fleury zu verstehen. Er funktioniert auch so weit sehr gut. Was mich jedoch wundert: Der Pullup für den Bootloaderpin wird nicht gesetzt. Daher springt der Controller ab und zu beim Reset in den Bootloader (v.a. wenn die neugierigen Fingerchen über das Testboard huschen... ;-) Hab auch schon diverse Änderungen getestet - nie funktioniert der Pullup von Anfang an... Meine Umgebung: WinAVR (Januar und April 06) ATMEGA128 und ATMEGA16 Vielleicht hat ja jemand schon Erfahrungen mit dem Code sammeln können... Gruß, Thomas
>>Der Pullup für den Bootloaderpin wird nicht gesetzt
Das define #define REMOVE_PROG_PIN_PULLUP muss kommentiert sein, um den
internen PullUp zu verwenden.
Das habe ich probiert - habe auch den Pullup direkt in den Quelltext eingetragen. Er wird jedoch nicht aktiviert! Weder auf dem M16 noch auf dem M128.
ich versuche mich auch gerade an diesem Loader, klappt aber noch nicht. Habe einen mega32 und als Startadresse 3E00 eingetragen. Auch die Fuses und Lockbits wie im Quellfile angegeben gesetzt. Eine LED für den Bootloadermode ist auch dran, die geht nicht an. Es sieht also so aus das der Bootloader gar nicht ausgeführt wird. Der Eingangspin ist fest auf Masse gelegt. Gibt es nochwas was im Code/Makefile angepasst werden muss?
Hurra, Fehler gefunden: Startadresse 3E00*2=7C00 musste ins makefile. Dann habe ich einen noch 'krummen' 12Mhz Takt und musste noch den U2X Modus setzen, damit wird der Code 2 Bytes zu gross die ich an der Bootloader-LED wieder eingespart habe. Der 'Erase Device' Befehl liefert einen Fehler, ist das richtig? Sollte der Code nicht durch die Lockbits geschützt sein? Dann möchte das neue AVR Studio noch die Version 2.07 sehen, kann ich das einfach rückmelden lassen oder gibt es signifikante Änderungen zw. 2.04 und 2.07 für den Bootloader?? Ja und das Problem von Thomas V. kann ich hier auch nachvollziehen, von ca. 10 Resets landet einer im Bootloader wenn die Program-Leitung in der Luft hängt.
und noch eine Antwort für mich: die Version 2.07 enthält nur weitere Prozessortypen, die Änderung mit Rückmeldung von 2.07 funktioniert. Aus der Hilfedatei avrisp.chm: March 17th, 2006 - FW v02.07 Added ISP support for ATmega165P and ATmega169P February 24th, 2006 - FW v02.07 Added ISP support for ATmega164P and ATmega324P Added ISP support for ATtiny85 Firmware fix: Made ISP programming more robust to handle skew on ISP lines
ich habe noch ein kleines Problem mit dem Bootloader: Zuerst muss ein 'Erase Device' ausgelöst werden, sonst klappt die Programmierung nicht. Das Erase Device liefert aber einen Fehler zurück und ich muss den Bootloader ein zweites Mal starten für die Programmierung. Die Programmierung ist dann ok, aber es ist lästig immer zweimal den Reset auszulösen. Im Bootloader wird der Erase Befehl verarbeitet und lässt auch den Bootloader in Ruhe. Macht der STK500 programmer evtl. ein Verify um zu prüfen ob der Speicher gelöscht wurde?
Hi Johannes, kannst du genauer sagen, wie du das mit der Baudrate geändert hast? Ich möchte den Bootloader mit dem Atmega16 (16Mhz) verwenden und hab es leider noch nicht zur Funktion gebracht. Gruß, Dominik
@Dominik:
für 12Mhz passte das so:
<c>
// #define UART_BAUD_SELECT(baudRate,xtalCpu)
((xtalCpu)/((baudRate)*16L)-1)
#define UART_BAUD_SELECT(baudRate,xtalCpu)
((xtalCpu)/((baudRate)*8L)-1)
</c>
und in der Initialisierung
<c>
/*
* Init UART
* set baudrate and enable USART receiver and transmiter
without interrupts
*/
UART_STATUS_REG |= _BV(U2X);
UART_BAUD_RATE_LOW = UART_BAUD_SELECT(BAUDRATE,F_CPU);
UART_CONTROL_REG = (1 << UART_ENABLE_RECEIVER) | (1 <<
UART_ENABLE_TRANSMITTER);
</c>
Es ändern sich Bitraten Berechnung und das U2X Bit muss gesetzt werden,
dann wird der Wert für 115200 Bit/s bei 12 Mhz ziemlich genau erreicht.
Bei 16 Mhz sieht es aber schlechter aus, lt. Datenblatt hast du -3,5% /
+2,1% Fehler, ich weiss nicht ob das noch toleriert wird.
Durch die zusätzliche Zeile mit dem U2X Bit wird der Code zu lang, ich
habe deshalb die Bootloader-LED deaktiviert. Man könnte aber auch den
Bootloader auf 1k Worte vergrössern wenn das Hauptprogramm nicht zu
gross ist.
Das Problem mit dem 'Erase Device' habe ich immer noch, benutzt hier
keiner diesen Bootloader?
Ich habe nun einen etwas baudraten-freundlicheren Quarz eingelötet (11,059 Mhz). Laut Datenblatt gibts dort keine Fehler und das U2X Bit muss auch nicht gesetzt werden. Leider funktioniert der Bootloader immernoch nicht. Die Hardware sollte soweit in Ordnung sein. Jedenfalls sehe ich auf dem Oscar, dass am RXD Pin des Controllers Daten ankommen, wenn ich versuche mit AVRISP zu connecten. Der Controller gibt jedoch keine Antwort - TXD ist dauerhabt auf 5V. Flashe ich ein ganz normales Anwenderprogramm auf den Controller funktioniert dieser. Die Fusebits für den Bootloader habe ich wie im Sourcecode dokumentiert gesetzt. Die Bootloaderadresse im Makefile habe ich wie folgt für den Atmega16 angepasst: BOOTLOADER_ADDRESS = 3C00
Die Bootloader Adresse sollte richtig sein. Funktioniert die serielle Schnittstelle denn auch soweit das ein Programm etwas ein/ausgeben kann? Bei meinem Problem habe ich noch herausgefunden: - wenn ich die Zeilen im 'Chip Erase' Kommando auskommentiere liefert es ein ok zurück, der AVR Programmer meckert nicht. - ok ist es auch wenn ich statt der Konstanten APP_END z.B. 0x2000 eintrage - wenn ich das Debuglogging in der Registry aktiviere wird angezeigt das 5 Bytes zuwenig kommen nach 1000ms Wartezeit. Aber die Applikation zeit kein Timeout an sondern Fehler, komisch. Ich weiss nicht wielange das Löschen braucht, aber 1s Timeout scheint mir etwas kurz. Habe aber noch nichts gefunden das zu verlängern. Es gibt eine xml Konfig je Device, aber Änderungen in der STK500_2 Sektion haben auch nichts gebracht.
so, das Timeout hat sich bestätigt. Das STK500 wartet nur 1000ms und das Löschen dauert fast genauso lange (240 Pages * ca.4ms = 960ms). Im STK500 Logfile sieht man dann auch das die Antwort vom Erase-Kommando zu spät ankommt. Ich habe das STK500 Plugin nur noch nicht dazu bewegen können mit einem längeren Timeout zu arbeiten. Weiss jemand ob es so eine Einstellung gibt? Das Problem hier müssten eigentlich alle bekommen die diesen Bootloader mit mega32 oder grösser einsetzen. Aus dem Logfile (erzeugen ist in AVR068 am Ende beschrieben): Sending packet 06/07/2006 17:38:49.556 (1000ms) > 1B 0A 00 07 0E (1000ms) > 12 28 00 AC 80 00 00 (1000ms) > 0E Sequence number 10, message size 7, checksum 14 CMD_CHIP_ERASE_ISP Receiving packet 06/07/2006 17:38:49.556 (1000ms) (expected 5 more bytes but timed out) Sequence number n/a, message size n/a, checksum n/a No data in packet Returned status: Client: Total timeout exceeded (PC side gave up) Sending packet 06/07/2006 17:38:50.557 (1000ms) > 1B 0B 00 03 0E (1000ms) > 11 01 01 (1000ms) > 0C Sequence number 11, message size 3, checksum 12 CMD_LEAVE_PROGMODE_ISP Receiving packet 06/07/2006 17:38:50.557 (1000ms) < 1B 0A 00 02 0E ( 970ms) < 12 00 0F Sequence number 10, message size 2, checksum 15 CMD_CHIP_ERASE_ISP Returned status: Client: Packet sequence number unexpected Port closed Returned status: Command succeeded
Ich bekomme den Bootloader immernoch nicht zur Funktion. Ich habe zum Testen der seriellen Verbindung ein normales Programm geschrieben und es hat alles normal funktioniert. Es liegt also definitiv nicht an der Hardware. Die Bootloader LED geht soweit an, wenn ich den Taster betätige. Auch, wenn ich die Taster nach dem Reset betätige. Hat jemand noch ne Idee wwarum der Bootloader überhaupt nicht anspringt? Anbei mein angepasstes Makefile und gleich die C-Datei. Vielleicht ist ja irgendwo ein Fehler den ich übersehe. Gruß, Dominik
Ich habe den Fehler nun gefunden. Ich habe einfach mal UART_BAUD_SELECT(BAUDRATE,F_CPU); direkt durch 5 ersetzt und seitdem funktioniert es problemlos. Wahrscheinlich liegt es am Rundungsfehler, denn: 11059000 / (16*115200) = 5,99989 Vielleicht wird das zu 5 und dann -1 macht 4, das ist natürlich falsch. @Johannes: Ich werde den Bootloader entgültig auch auf dem Mega32 verwenden und es auch noch ausgiebig testen. Gruß, Dominik
ich habe noch folgendes geändert:
/*
* Calculate the address where the bootloader starts
* from FLASHEND and BOOTSIZE
*/
#define BOOTSIZE (uint16_t)512
#define APP_END ((uint16_t)FLASHEND+1 - (2*BOOTSIZE))
die typecasts verhindern die 2 Warnungen die der Compiler ausspuckt,
ändert aber nichts am Code.
und hier ist die kritische Stelle:
case CMD_CHIP_ERASE_ISP:
address = 0;
while (address < APP_END)
Wenn beim Mega32 bis APP_END gelöscht wird dauert es einen Tick zu
lange, wenn ich APP_END z.B. durch 0x7000 ersetzte ist es noch ok. Die
Grenze ist ca. 0x7380, hängt aber sicher auch vom Mega32 und Temperatur
ab, das Löschen einer Page dauert lt. Datenblatt 3,7 .. 4,5 ms.
Immerhin habe ich jetzt ganz gut verstanden wie das Ding
funktioniert...
Teste den Bootloader gerad auf dem Mega32 mit 11,059 Mhz und habe die gleichen Probleme. Das löschen funktioniert nicht korrekt. Ist die Dauer die zum löschen einer Seite benötigt wird von der Taktfrequenz abhängig?
Lt. Datenblatt wird zum Löschen der interne Oszi benutzt und das Löschen einer 128 Byte Page dauert 3,7 .. 4,5 ms. Damit ist man bei 32k nahe an der 1000ms Timeout Grenze. Ich habe an einigen Einstellungen, auch in dem XML Devicefile änderungen probiert, ohne Erfolg, das Timeout scheint fest zu sein. Als Workaround bleibt also erstmal nur weniger als 32k zu Löschen, bei mir war es bis 0x7000 immer ok. Ist natürlich gefährlich wenn der Code an diese Grenze kommt... Von Peter F. habe ich noch den Tipp bekommen den AVRDude zu benutzen, der hätte das Timeout nicht drin. Aber das Smarte an diesem Bootloader ist ja das man das AVRStudio ohne zusätzliche Werkzeuge benutzen kann.
Genau, ich verwende diesen Bootloader auch eben genau deswegen, weil man nur das AVR-Studio benötigt. Wwas macht denn das STK500 anders beim löschen?
das macht nichts anders, aber das Device wird ja per ISP programmiert/gelöscht, und das geht viel viel schneller.
Ach, stimmt ja... Naja, dann werde ich das mal mit AVR-Dude testen oder ggf. das wie du modifizieren, dass es nur bis 0x7000 gelöscht wird...
Da ich nur max 16K AVR habe, ist mir dieses Timeout-Problem beim Testen nie aufgetreten. Dieser Timeout müsste im AVRStudio erhöht werden. Wenn man trotzdem AVRStudio benutzen will, bleibt nur folgenden Workaround: Häckchen "Erase Device before Programming" in AVRISP GUI entfernen. - Bootloader starten - AVRISP GUI starten - "Erase Device" Button klicken, dann Fehlermeldung-Box wegklicken und AVRISP Fenster schliessen - Bootloader starten - AVRISP GUI starten und "Programm" Button anklicken
so habe ich es anfangs auch gemacht, aber das wurde mir zu lästig, deshalb habe ich das näher untersucht. Ich bin sogar zu faul die Reset Taste zu drücken, deshalb möchte ich noch den Einsprung in den den Bootloader von der Applikation aus machen (über die serielle Schnittstelle getriggert). Es gibt noch einen ähnlichen Bootloader mit STK500 Protokoll von Pascal Stang. Diesen Bootloader habe ich noch nicht ausprobiert, den gab es nur als fertiges Hexfile ohne Source und es gab keine passende Version für meine krummen 12 Mhz. Habe jetzt aber noch frische M32 und probiere das auch mal. Hier noch der Link zur Konkurenz: http://hubbard.engr.scu.edu/embedded/avr/bootloader/index.html
Neue Version auf meiner Homepage: http://homepage.hispeed.ch/peterfleury/avr-software.html -> AVR Studio compatible Boot Loader Ich habe meinen Bootlader nun erweitert, nun können auch AVR > 16K mittels AVRStudio programmiert werden in einem Durchgang. Mein oben erwähnter Workaround gilt nun nicht mehr.
Habe eben mal die neue Verison auf einem Mega32 mit 14,7456Mhz getestet. Bekomme nach dem programmieren immer einen Fehler und die AVRISP mode Error Meldung. Reading FLASH input file.. OK Setting mode and device parameters.. OK! Entering programming mode.. OK! Erasing device.. OK! Programming FLASH .. OK! Reading FLASH .. OK! WARNING: FLASH byte address 0x0000 is 0xFF (should be 0x0C).. FAILED! Leaving programming mode.. OK! Woran könnte das noch liegen?
Ich habe jetzt mal nach dem Programmieren mit dem Bootloader den kompletten Flash ausgelesen und mit dem ursprünglichen HEX-File verglichen. Die ersten 64 Bytes sind alle FF, dann 64 Byte korrekt, dann wieder 64 Byte FF und wieder 64 korrekt.... so geht das dann weiter... @ Johannes: Konntest du die neue Version schon erfolgreich testen?
@Dominik Kannst du mir eine AVRStudio Trace schicken vom obigen Programmiervorgang ? Siehe AVR068 AppNote, Section 7.3 STK500 Communication Logging ?
Aus obiger Beschreibung von Dominik habe ich den Verdacht, dass AVRStudio nur max 64 Bytes schickt pro FLASH command, anstelle der Mega32 Pagesize von 128 Bytes. Nun habe ich separate Address-Counter für Erase und Write implementiert. Jetzt sollte es gehen, ich kann es allerdings mangels Mega32 nicht selber testen. Bitte neue Version von meiner Homepage laden, cvs version 1.9
Hallo Peter, ich werde die neue Version sofort testen.
Es tritt unverändert das gleiche Problem auf. Anbei das Log-File.
Ja das kann nicht gehen, die entscheidende Variable hatte ich nicht angepasst. Ist nun korrigiert, auf meiner Homepage, cvs version 1.10
Nun funktioniert es prima. Danke für die schnelle Reaktion!
Hi, ich habe einen ATmega168 und Probleme mit dem Bootloader. Nachdem ich den bootloader kompiliert und ihn mit ISP draufgespielt habe, kann ich mich bei AVR Studio per STK500v2 Protokoll mit dem Controller verbinden und auch über RS232 die Fusebits und die SignatueBytes auslesen. Beim programmen bekomme ich jedoch folgenden Fehler: " Reading FLASH input file.. OK Setting mode and device parameters.. OK! Entering programming mode.. OK! Erasing device.. OK! Programming FLASH .. OK! Reading FLASH .. OK! WARNING: FLASH byte address 0x0000 is 0xFF (should be 0x0C).. FAILED! Leaving programming mode.. OK! " Ich habe sowohl UART_BAUDRATE_DOUBLE_SPEED = 0 als auch = 1 ausprobiert. Die Ports für die LED & PROG_PORT habe ich richtig ausgewählt. In der Makefile habe ich den MCU_name = atmega168 und die F_CPU auf 20000000 gesetzt. Die BOOTLOADER_ADDRESS habe ich bei 0x1C00 geändert. Als Anhang habe ich mal die hex-Datei getan, die ich bekomme, wenn ich die hexfile vom controller per AVRStudio auslese. Der Fehler scheint ja dem Fehler von "Dominik Tewiele (dom) Datum: 18.06.2006 14:50" zu entsprechen. Ich habe mir heute den Quellcode von jump.to/fleury heruntergeladen, ich sollte also wohl die neuse Version haben. Hat jemand eine Idee, woran das liegen kann?
Hi, ich würde den Bootloader von Peter Fleury gern auf dem NET-AVR-IO Board von Pollin mit einem MEGA644 verwenden... Hab mir den Bootloader auch entsprechen konfiguriert (Quarz 14,7Mhz, Signaturbyte, Taster für in den Bootloader zu springen,...) und die Kommunikation mit dem AVR Studio klappt auch soweit! Allerdings tritt bei mir auch, wie bei den beiden oberen Poster das gleich Problem auf: " Reading FLASH input file.. OK Setting mode and device parameters.. OK! Entering programming mode.. OK! Erasing device.. OK! Programming FLASH .. OK! Reading FLASH .. OK! WARNING: FLASH byte address 0x0000 is 0xFF (should be 0x0C).. FAILED! Leaving programming mode.. OK! " Hatte zuerst gedacht die Pagesize wäre eventuell nich korrekt, aber die dürfte soweit stimmen... Was nun? Kann jemand das Problem repoduzierren bzw. mir ein paar heiße Tipps geben, das Problem gabs ja schon öfters... Wenn Infos fehlen meldet euch! Schon mal danke!
Ok, nach längerem Hin- und Her, lag wohl der Fehlerteufel bei mir in der Berechnung der Bootloader_Adresse.... Der richtige Eintrag für Makefile ist: " 0xFFFF-0xFC00*2=0xF801 for ATmega644 1024 words Boot Size BOOTLOADER_ADDRESS = 0xF801 " Ich entschuldige mich für die gemachten Umstände! Einen schönen Samstag euch allen!
Hi, ich beobachte bei mir ein sehr merkwürdiges verhalten. ich bekomme bei bestimmten hex files verifikation errors:
1 | avrdude: AVR device initialized and ready to accept instructions |
2 | |
3 | Reading | ################################################## | 100% 0.01s |
4 | |
5 | avrdude: Device signature = 0x1e9502 |
6 | avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed |
7 | To disable this feature, specify the -D option. |
8 | avrdude: erasing chip |
9 | avrdude: reading input file "main.hex" |
10 | avrdude: input file main.hex auto detected as Intel Hex |
11 | avrdude: writing flash (14470 bytes): |
12 | |
13 | Writing | ################################################## | 100% 2.74s |
14 | |
15 | avrdude: 14470 bytes of flash written |
16 | avrdude: verifying flash memory against main.hex: |
17 | avrdude: load data flash data from input file main.hex: |
18 | avrdude: input file main.hex auto detected as Intel Hex |
19 | avrdude: input file main.hex contains 14470 bytes |
20 | avrdude: reading on-chip flash data: |
21 | |
22 | Reading | ################################################## | 100% 1.59s |
23 | |
24 | avrdude: verifying ... |
25 | avrdude: verification error, first mismatch at byte 0x1028 |
26 | 0x00 != 0xff |
27 | avrdude: verification error; content mismatch |
28 | |
29 | avrdude: safemode: Fuses OK |
30 | |
31 | avrdude done. Thank you. |
die stelle im hexfile sieht so aus:
1 | :10100000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0 |
2 | :10101000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0 |
3 | :10102000FFFFFFFFFFFFFFFF0000000000000000C8 |
4 | :1010300000000000000000000000000000000000B0 |
5 | :1010400000000000000000000000000000000000A0 |
Es handelt sich an der Stelle um ein Bitmap, wenn ich die includes verschiebe passiert das gleiche, nur halt an einer anderen Adresse. Das passiert reproduzierbar. Wenn ich aber zuerst normal mit
1 | avrdude -pm32 -cstk500v2 -P /dev/ttyUSB0 -U flash:w:main.hex |
programmiere bekomme ich den Fehler, und dann nochmal mit
1 | avrdude -pm32 -cstk500v2 -P /dev/ttyUSB0 -U flash:w:main.hex -D |
also ohne Erase dann läuft er durch ohne Fehler Es sieht manchmal so aus als ob der Balken beim ersten Aufruf kurz springt. Hat einer ne Idee was das sein kann? Ich bin am verzweifeln. Gruß Peter
Hallo Ich habe ein Problem mit dem Bootloader. Versuche verzweifelt über die RS232 Schnittstelle zu programmieren nur leider bekomme ich keine Antwort von meinem Mega16L8PU wenn ich versuche mit AVR Studio zu verbinden. Ich habe meinen AVR wie hier mit dem MAX232 geschaltet. http://www.mikrocontroller.net/articles/Datei:AVR-RS232.png Ich habe soweit ich das als logisch gesehen habe auch die makefile und den Bootloader angepasst (siehe Anhang). Ich kann den Bootloader starten (LED-leuchtet) und ich messe auch an RXD ca. 2,4V. doch auf TXD bleiben unverändert ca. 5V :( Hat jemand vielleicht eine Idee welchen Fehler ich gemacht habe? Grüße
Hallo hänge immer noch am selben Problem. Da sich aber noch keiner über die Schaltungsweise beschwert hat, geh ich davon aus das die soweit in Ordnung ist. Hat vielleicht schon jemand Erfahrung mit dem Bootloader sammeln können und könnte mir vielleicht die Werte für die Fusebits und Lockbits geben? Oder sonst einen Rat? :)
Angehängte Dateien:
-
Lockbits.PNG
34 KB -
Fuses.PNG
34 KB
Vielleicht hängts ja auch an den Lock und Fusebits. Hier mal meine Einstellungen (Anhang). Oder braucht jemand vielleicht noch Infos? Mir fällt nichts mehr ein was ich anpassen kann. Grüße
Erst mal: ein toller Bootloader und der Einzige, den ich ohne komplett umschreiben auf einem ATmega und mit avrdude zum laufen gebracht habe. Bei mir will dieser Bootloader aber nicht so recht. Das heisst, 95% der Zeit funktioniert er super, doch manchmal eben nicht. Leute ohne Programmer - und bei denen passiert das vorzugsweise - sind dann angeschmiert. Der derzeit häufigste Fall ist, dass sich Leute ein Board selbst löten, um dann den mitgelieferten ATmega644 einzusetzen. Der ATmega hat diesen Bootloader schon drauf. Der ATmega hat auch ein kleines Testprogramm, vor Auslieferung mit eben diesem Bootloader über die Arduino IDE hochgeladen, das einwandfrei über die serielle Schnittstelle kommuniziert. Nur Firmware flashen geht nicht. avrdude läuft dann zwar durch, beendet sich aber mit dieser Fehlermeldung:
1 | avrdude: verification error, first mismatch at byte 0x0000 |
2 | 0x0c != 0x14 |
3 | avrdude: verification error; content mismatch |
So ist es dann auch, die alte Firmware bleibt, als ob nichts passiert wäre. Es sind immer genau die gleichen 0x0c != 0x14. Wie kann es sein, dass sich der Bootloader durch programmieren des ATmega, ausstecken und eine Woche später anderswo wieder einstecken zerschiesst? Den angepassten Quellcode gibt's hier: https://github.com/Traumflug/Generation_7_Electronics/tree/master/arduino%20support/stk500v2bootloader Ist übrigens eine Community von Hobbyisten, auch wenn ich das Wort "Auslieferung" verwendet habe.
Ich hab's befürchtet. Heute habe ich so ein Board bekommen, das sich nicht mehr über den Bootloader programmieren lässt. Ein auslesen der Firmware über einen Programmer hat ergeben, dass der Bootloader unverändert ist. Jetzt ist die Preisfrage, was sich an einem ATmega durch herum liegen oder einstecken ändern kann, so dass der Bootloader streikt. Hat jemand eine Idee?
Noch ein Update: das EEPROM hatte ein paar wirre Daten drin. Zurücksetzen auf lauter 0xFF hat aber auch nichts genutzt.
Markus H. schrieb: > das EEPROM hatte ein paar wirre Daten drin Das könnte ein Hinweis darauf sein, dass der MC Amok gelaufen ist. Ist die Brownout Fuse richtig gesetzt?
Der Brownout-Detektor ist abgeschaltet, d.h. kein Bit programmiert, die Extended Fuse auf 0xFF. Was sollte er denn haben?
Hmm. Ich habe ihn mal auf 4,3 V gestellt, also den höchsten Wert. Scheint auch geholfen zu haben oder auch nicht, das wird erst die Zeit zeigen. Als Dankeschön für die rege zwinker Hilfe anbei ein kleiner Patch, der den Bootloader um 60 Bytes verkleinert, ohne Funktionalität oder Geschwindigkeit aufzugeben.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.