mikrocontroller.net

Forum: Projekte & Code STK500v2-Bootloader von Peter Fleury


Autor: Thomas V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Fleury (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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.

Autor: Thomas V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik T. (dom) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik T. (dom) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier die C-Datei.

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das macht nichts anders, aber das Device wird ja per ISP
programmiert/gelöscht, und das geht viel viel schneller.

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Peter Fleury (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/bootloade...

Autor: Peter Fleury (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so gehts natürlich auch...

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter Fleury (pfleury)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dominik
Kannst du mir eine AVRStudio Trace schicken vom obigen
Programmiervorgang ?

Siehe AVR068 AppNote, Section 7.3 STK500 Communication Logging ?

Autor: Peter Fleury (pfleury)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter, ich werde die neue Version sofort testen.

Autor: Dominik T. (dom) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Es tritt unverändert das gleiche Problem auf.

Anbei das Log-File.

Autor: Peter Fleury (pfleury)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das kann nicht gehen, die entscheidende Variable hatte ich nicht
angepasst.

Ist nun korrigiert, auf meiner Homepage, cvs version 1.10

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun funktioniert es prima. Danke für die schnelle Reaktion!

Autor: Mirko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann man den bootloader für ATmega8 und 8MHz modifizieren?

Autor: cauboy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Felix Welsch (lixelator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Felix Welsch (lixelator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich beobachte bei mir ein sehr merkwürdiges verhalten.

ich bekomme bei bestimmten hex files verifikation errors:
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (14470 bytes):

Writing | ################################################## | 100% 2.74s

avrdude: 14470 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 14470 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.59s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x1028
         0x00 != 0xff
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


die stelle im hexfile sieht so aus:
:10100000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10101000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:10102000FFFFFFFFFFFFFFFF0000000000000000C8
:1010300000000000000000000000000000000000B0
: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
avrdude -pm32 -cstk500v2 -P /dev/ttyUSB0 -U flash:w:main.hex 
programmiere bekomme ich den Fehler, und dann nochmal mit
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

Autor: lala (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: lala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? :)

Autor: lala (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus H. (traumflug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0x14
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_Electron...

Ist übrigens eine Community von Hobbyisten, auch wenn ich das Wort 
"Auslieferung" verwendet habe.

Autor: Markus H. (traumflug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Markus H. (traumflug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Update: das EEPROM hatte ein paar wirre Daten drin. 
Zurücksetzen auf lauter 0xFF hat aber auch nichts genutzt.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Markus H. (traumflug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Brownout-Detektor ist abgeschaltet, d.h. kein Bit programmiert, die 
Extended Fuse auf 0xFF.

Was sollte er denn haben?

Autor: Markus H. (traumflug)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.