Hallo, ich habe hier ein paar kleine Roboter der Firma qfix (www.qfix.de) mit einem sogenannten MiniBoard. Auf dem Board ist ein ATMEGA32 Chip, der über eine USB-Schnittstelle programmiert wird (C/C++ mit dem Programmers Notepad). Bei 2 Robotern habe ich jetzt das Problem, dass ich sie nicht mehr flashen kann. Laut Fehlermeldung (siehe Ende des Beitrags) scheint das Programm in den Speicher geschrieben zu werden und anschließend wird beim Verifizieren festgestellt, dass im Speicher das falsche Programm steht. Ich glaube, dass das Programm aber gar nicht in den Speicher geschrieben wird. Wenn ich den Roboter starte nachdem er geflasht wurde fängt er nämlich an rückwärts zu fahren (obwohl ich in meinem Programm nur eine LED anschalte), das alte Programm scheint also noch zu laufen. Das Programm an sich ist in Ordnung (es funktioniert auch mit anderen Programmen die einwandfrei sind nicht). Meine Vermutung ist, dass während eines Flashvorgangs mal das Kabel rausgezogen wurde oder ähnliches. Kann mir jemand sagen was ich da machen kann? Habe auch schon der Herstellerfirma geschrieben aber bisher keine Antwort erhalten. Falls noch weitere Angaben gebraucht werden kann ich die gerne nachreichen. MfG, Mike. Hier die entsprechende Fehlermeldung: > "C:\qfix\bin\download-mega32.bat" BoardTest Found programmer: Id = "qFix B0"; type = S Software Version = 1.0; Hardware Version = 1.0 Programmer supports auto addr increment. Programmer supports the following devices: Device code: 0x72 = ATMEGA32 avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9502 avrdude: erasing chip avrdude: reading input file "BoardTest.bin" avrdude: input file BoardTest.bin auto detected as raw binary avrdude: writing flash (1332 bytes): Writing | ################################################## | 100% 1.02s avrdude: 1332 bytes of flash written avrdude: verifying flash memory against BoardTest.bin: avrdude: load data flash data from input file BoardTest.bin: avrdude: input file BoardTest.bin auto detected as raw binary avrdude: input file BoardTest.bin contains 1332 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 0.47s avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x0054 0x8c != 0x3a avrdude: verification error; content mismatch avrdude done. Thank you. > Process Exit Code: 1 > Time Taken: 00:03
Keiner eine Idee? Es muss doch irgendeine Möglichkeit geben solche Chips zu "resetten". Die können ja nicht kaputt gehen wenn man einmal das Kabel zieht oder so.. ist halt recht wichtig weil ich die Roboter in der Schule benutze und wenn eine Gruppe keinen Roboter hat weil der kaputt ist ist das sehr ärgerlich..
Gibt es vielleicht die Datei BoardTest.bin mehrmals in verschiedenen Verzeichnissen, so das versehentlich die Falsche benutzt wird? Erstell doch mal eine neue bin-Datei mit anderem Namen und flashe diese....
Hi, nee das funktioniert auch nicht. Habe eine neue Datei angelegt, ein anderes Verzeichnis ausprobiert und und und..
Gibt es in der bat Datei eine reine Lösch- und Rücklesefunktion? Wenn ja, werden immer die gleichen Werte zurückgelesen?
Hier mal der Text aus der bat-Datei: :: download-mega32.bat for USB download :: This file is written by the the qfix portSwitch tool :: Please do not alter the command line @echo off set TARGET=%1 set CONTROLLER=atmega32 avrdude -p %CONTROLLER% -P COM4 -b 115200 -c avr910 -e -U flash:w:"%TARGET%.bin"
Vielleicht solltest Du den Programmer etwas ausbremsen. Wenn ich das richtig sehe sollten die Parameter -B oder -i in der avrdude Zeile dafür verantwortlich sein. probier erst mal ein:avrdude ... -B 10 ... einzufügen. Ist aber für JTAG. Wenn es nicht geht versuchen wir noch -i
hp-freund schrieb: > Vielleicht solltest Du den Programmer etwas ausbremsen. > Wenn ich das richtig sehe sollten die Parameter -B oder -i in der > avrdude Zeile dafür verantwortlich sein. > > probier erst mal ein:avrdude ... -B 10 ... > einzufügen. Ist aber für JTAG. Wenn es nicht geht versuchen wir noch -i Also ich habe mal folgendes probiert: avrdude -p atmega32 -P COM4 -B 10 -b 115200 -c avr910 -e -U flash:w:"C:\Users\Simon\Desktop\tmp.bin":w Dann mal mit -i 10 100 1000 mit und ohne -B Hat alles nicht funktioniert.. noch eine Idee oder muss ich noch ein Parameter variieren? Ich werde mir die Doku morgen mal genauer anschauen.. bin aber auch ein bißchen ratlos weil ich sowas bisher noch nie gemacht habe.
Ist das:
avrdude: verification error, first mismatch at byte 0x0054
0x8c != 0x3a
immer das Gleiche?
Wie ist es wenn Du -b 115200 kleiner machst?
z.B. -b 38400
Ja das ist immer das gleiche. Andere Baudraten akzeptiert er gar nicht erst. Da kommt nach ein paar Sekunden die Meldung selected device is not supported by programmer. So jetzt kann ich erst morgen weiter ausprobieren.
Ich habe mir jetzt mal die Doku zu Avrdude angeschaut und noch folgendes ausprobiert: - Avrdude im Terminal-Modus gestartet - Fehlerhafte Stelle ausgelesen (ergab 0x93 wie in der Fehlermeldung angegeben) - Chip erase durchgeführt - Fehlerhafte Stelle ausgelesen --> wieder 0x93. Das kann doch eigentlich nicht sein, oder? Ich nehme mal an bei einem Erase schreibt er nur 0en in den Speicher?! Irgendwie sehe ich da schwarz :-( edit: Ok ich habe es jetzt mal mit einem funktionierenden Board ausprobiert und da kommt nach dem erase auch der gleiche Wert wie vorher raus. Was macht denn dann der Befehl eigentlich? Jedenfalls kann ich das Board im Gegensatz zu den zwei anderen ohne Probleme mit den gleichen Befehlen flashen (auch ohne -B oder -i)..
Hast Du den EEPROM auch schon mal programmiert? Was hälst Du vom -Y Parameter?
Was mir auch noch aufgefallen ist: in allen Doku Versionen von avrdude wird immer -p m32 für den ATMega32 angegeben, in deiner bat aber atmega32 ...
Mit "avrdude" -p m32 -c avr910 -P com4 -U
eeprom:w:"C:\Users\Simon\Desktop\tmp.bin":a -e -b 115200 erhalte ich
auch eine Fehlermeldung mit einem Bytemismatch.. das selbe Problem also
(allerdings schon an Speicherstelle 0x0000). HFuse, LFuse, Lock und
Calibration stimmen beim defekten und funktionierenden Board überein.
Was soll mir -Y bringen? Damit kann man ja den Erase-Counter
manipulieren, den man dann mit -y auslesen kann, oder? Nach -Y 1000
erhalte ich mit -y -e wieder 1 für den Counter. Im Terminalmode gibt mir
"d eeprom 0x0000 64000" nach -Y 1000 nur FF zurück. Eigentlich sollte da
in den letzten 4 Bytes 1000 stehen, oder?
In der conf-Datei steht folgendes:
id = "m32";
desc = "ATMEGA32";
ich denke es funktioniert beides. Ich arbeite ja momentan gar nicht mit
der bat-Datei sondern gebe die Befehle selber ein und da benutze ich
immer m32..
Ich folgere, dass auf Deinen ATMegas ein bootloader einprogrammiert ist. Sonst würde die Programmierung über die serielle Schnittstelle nicht funktionieren. Jetzt können zwei Dinge passiert sein: 1) Der Flash/EEPROM ist einfach durch häufiges Schreiben kaputt (eher unwahrscheinlich, im Datenblatt ist irgendwas >> 1000 angegeben. Da hilft nur neuen Chip einlöten (und vorher mit einem Bootloader versehen). 2) Der Bootloader hat einen Defekt oder wurde unabsichtlich beschädigt. Vorschlag: Mach einen chip-erase (löscht alles, bis auf den Booloader) bei einem funktionierendem und einem nicht-funktionierendem Roboter. Dann les den ganzen Chip aus. ( -U flash:r:flash.hex:i ) und vergleiche das Ergebnis zwischen beiden Robotern. Wenn die Fuses "freundlich" gesetzt sind kann man damit auch den Flashbereich des Bootloaders auslesen (am Ende des Flashes) Ich hatte mal einen Bootloader, der einige Zeit funktioniert hat und ab irgendeinem Punkt nur noch Müll geliefert hat. Insbesondere habe ich beobachtet, dass nach dem Chip erase etwas anderes als 0xff zurück gelesen wurde. Ein neuer Bootloader per ISP reinzuprogrammieren hat funktioniert. Viel Erfolg!
Also der Hexeditor zeigt mir folgendes an: 610 Unterschiede im Bereich 0x00000 bis 0x00FFF 1259 Unterschiede im Bereich 0x01000 bis 0x01FFF 0 Unterschiede im Bereich 0x02000 bis 0x12DB0 Wenn der Bootloader wirklich Am Ende steht scheinen die beiden also übereinzustimmen, oder? der wird ja nicht 90% des Speichers belegen und schon bei 0x01000 oder so beginnen.
1) "... im Bereich bis 0x12DB0" ??? Ich würde maximal 0x7fff erwarten, da der Chip 32 KiByte Flash hat. Die Datei, die avrdude mit der Option :i speichert, ist eine menschenlesbare Hex-Datei im Intel Hex Format. Der Hexeditor vergleicht die Hex-Werte der Ascii-Datei. Dort sind die Adressangaben wenig sinnvoll. Guck mal mit einem Texteditor in die Datei hinein. Wenn Du eine Binärdatei haben möchtest: -U flash:r:flash.bin:r Dann kannst Du mit dem Hexeditor sinnvoll arbeiten. Ab wo unterscheiden sich jetzt die beiden Dateien? 2) Der bootloader kann je nach Fuse-Einstellung bei 0x3f00, 0x3e00, 0x3c00 oder 0x3800 beginnen (siehe ATmega32 Datasheet, Seite 255, Tabelle 99) (Je nach Zählweise [Bytes/Words] ist da noch ein Faktor 2 drin. Das hier sind glaube ich Word Adressen [0x3fff + 1 sind 16Ki words = 32 KiByte). Wie sind denn die Fuses gesetzt? Die Bits BOOTSZ1, BOOTSZ2 geben an, ab wo der Bootloader beginnen soll. Hast Du auch wirklich was vom Bootloader zu sehen bekommen oder wird da nur 0xff gelesen? Nur wenn Du natürlich den Bootloader ausgelesen bekommst ist es sinnvoll die Inhalte zu vergleichen. Beim Lesen in geschützten Bereichen kommt glaube ich nur 0xff oder 0x00 zurück, jedoch keine Fehlermeldung. 3) Wenn Du nach dem Chip Erase in den ersten Bytes was anderes als 0xff zurück bekommst (und die Kommunikation an sonsten zuverlässig funktioniert) würde ich sagen: bootloader kaputt oder Chip kaputt. Vielleicht ist auch die Versorgungsspannung schwach/verdreckt, so dass der Chip Erase nicht ordentlich funktioniert. Auch wenn der Bootloader evtl. urheberrechtlich geschützt ist, könntest Du trotzdem vom funktionierenden und kaputten Roboter den nach dem Chip erase zurückgelesenen Flashdump hier mal posten. Ich würd mir gerne mal ansehen, was da für Bytes im unteren Bereich zurückgelesen werden. Das ganze kommt mir nämlich sehr bekannt vor ...
Dave schrieb: > 1) "... im Bereich bis 0x12DB0" ??? > Ich würde maximal 0x7fff erwarten, da der Chip 32 KiByte Flash hat. > > Die Datei, die avrdude mit der Option :i speichert, ist eine > menschenlesbare Hex-Datei im Intel Hex Format. Der Hexeditor vergleicht > die Hex-Werte der Ascii-Datei. Dort sind die Adressangaben wenig > sinnvoll. > Guck mal mit einem Texteditor in die Datei hinein. > > Wenn Du eine Binärdatei haben möchtest: > > -U flash:r:flash.bin:r > > Dann kannst Du mit dem Hexeditor sinnvoll arbeiten. > > Ab wo unterscheiden sich jetzt die beiden Dateien? > > 418 Unterschiede im Bereich 0x00 bis 0xFFF und sonst keine Unterschiede. Angezeigt über die beiden raw-Dateien durch einen Hex-Editor. Ich bin allerdings gerade verwirrt, weil am Anfang von beiden Dateien keine FFs stehen, sondern das alte Programm. Auch bei dem funktionierenden Chip ist das so. Gelöscht habe ich es einmal über "avrdude" -p m32 -c avr910 -P com4 -e -v -b 115200 und einmal über das Terminal mit erase. Jeweils mit dem gleichen Ergebnis. Ich habe einfach mal die beiden Binärdateien angehängt hier. > 2) Der bootloader kann je nach Fuse-Einstellung bei > > 0x3f00, > 0x3e00, > 0x3c00 oder > 0x3800 > > beginnen (siehe ATmega32 Datasheet, Seite 255, Tabelle 99) > (Je nach Zählweise [Bytes/Words] ist da noch ein Faktor 2 drin. Das hier > sind glaube ich Word Adressen [0x3fff + 1 sind 16Ki words = 32 KiByte). > > Wie sind denn die Fuses gesetzt? > Die Bits BOOTSZ1, BOOTSZ2 geben an, ab wo der Bootloader beginnen soll. Sind beide aktiviert. Sollte also bei 0x3F00 beginnen. > > Hast Du auch wirklich was vom Bootloader zu sehen bekommen oder wird da > nur 0xff gelesen? Nur wenn Du natürlich den Bootloader ausgelesen > bekommst ist es sinnvoll die Inhalte zu vergleichen. Beim Lesen in > geschützten Bereichen kommt glaube ich nur 0xff oder 0x00 zurück, jedoch > keine Fehlermeldung. > > 3) Wenn Du nach dem Chip Erase in den ersten Bytes was anderes als 0xff > zurück bekommst (und die Kommunikation an sonsten zuverlässig > funktioniert) würde ich sagen: bootloader kaputt oder Chip kaputt. > > Vielleicht ist auch die Versorgungsspannung schwach/verdreckt, so dass > der Chip Erase nicht ordentlich funktioniert. > > Auch wenn der Bootloader evtl. urheberrechtlich geschützt ist, könntest > Du trotzdem vom funktionierenden und kaputten Roboter den nach dem Chip > erase zurückgelesenen Flashdump hier mal posten. > Ich würd mir gerne mal ansehen, was da für Bytes im unteren Bereich > zurückgelesen werden. Das ganze kommt mir nämlich sehr bekannt vor ... Siehe zweiter Punkt..
Mike Modano schrieb: > Gelöscht habe ich es einmal über "avrdude" -p m32 -c avr910 > -P com4 -e -v -b 115200 und einmal über das Terminal mit erase. Jeweils > mit dem gleichen Ergebnis. Beides teilt dem Bootloader über das in Appnote 910 definierte Protokoll nur mit, dass er bitte den Chip löschen möchte. Beide Aufrufe sind also identisch. Ohne den Booloader zu disassemblieren weiß ich natürlich nicht, was genau dieser Bootloader (ist ja nicht unbedingt ein vorgefertigter des Chipherstellers, sondern einer des Roboterherstellers. Der kann dann z.B. auch gar nichts tun.) macht. Unter der Annahme, dass er sich "gefälligst benimmt", wundert es mich sehr, dass beide (!) Chips nach dem Chip erase so aussehen:
1 | alphamac:tmp user$ hexdump -C ok.bin | head |
2 | 00000000 0c 94 2b 00 0c 94 53 00 0c 94 53 00 0c 94 53 00 |..+...S...S...S.| |
3 | 00000010 0c 94 53 00 0c 94 53 00 0c 94 53 00 0c 94 53 00 |..S...S...S...S.| |
4 | 00000020 0c 94 53 00 0c 94 53 00 0c 94 53 00 0c 94 55 00 |..S...S...S...U.| |
5 | 00000030 0c 94 53 00 0c 94 53 00 0c 94 53 00 0c 94 53 00 |..S...S...S...S.| |
6 | * |
7 | 00000050 0c 94 53 00 8c 02 11 24 1f be cf e5 d8 e0 de bf |..S....$........| |
Das ist noch der Interrupt-Table des (alten) Programms (jmp 0x56; jmp 0xa6; ...) Wäre der Flash kaputt, würde da evtl. nur einzelne Bits gekippt sein. Der Bootloader löscht einfach nicht den ganzen Chip. Ich habe sogar den Eindruck, dass das beabsichtigt ist und ein gewisser Teil im AVR immer gleich bleiben soll. Interessant finde ich, dass in dem ersten Teil ein paar kleine Abweichungen zwischen den Chips sind. Im disassembly Adresse 0x68 wird eine 64 statt einer 50 geladen. Bei 0x94 und 0xa2, wo in den 'hinteren' Teil des Programms gesprungen wird, unterscheiden sich die Zieladressen. Evtl. ist der erste Teil fix (und stellt sowas wie das Betriebssystem dar) und das Userprogramm wird in den hinteren Teil geflasht. Da sich die "Betriebsysteme" des Chip "OK" und "Defekt" unterscheiden, gibt es natürlich ein Problem, wenn avrdude das verifizieren will. 1) Wie wird die Datei, die Du flasht, erzeugt? Kannst Du alle Schritte vom Sourcecode bis zur Datei %TARGET%.bin nachvollziehen? Kannst Du die %TARGET%.bin mal posten? 2) Was passiert, wenn Du a) den Chip löschst b) eine Hex-Datei, die nur aus 32 KiByte 0xff besteht hineinschreibst (Verify wird eine Fehlermeldung ausspucken, da der bootloader nicht überschrieben werden kann. Aber Verify passiert nach dem Schreiben.) c) Dann den Flash wieder ausliest? Das ganze für Chip "OK" und "Defekt" und auch mit nur "32 KiByte 0x00" machen. 3) Verhält sich (danach) der Chip "OK" denn einwandfrei, d.h. wenn Du ein Programm schreibst "LED" an: geht dann auch nur die LED an? 4) Hast Du denn Zugriff auf einen ISP Programmer und hat das Board einen entsprechenden Anschluss? 5) Wenn der Hersteller sich nicht meldet muss man da leider selbst etwas reverse engineering betreiben, was die sich da eigentlich gedacht haben. Ich tipp mal auf nen Bug im bootloader. Wie gesagt: soetwas hatte ich auch einmal bei einem, den ich hier im Forum oder sonstwo übernommen habe: ab irgendeinem Punkt löschte er den Flash nicht mehr. Ich habe das durch Einprogrammieren eines neuen bootloaders per ISP gefixt.
Hi, danke schon mal für die ausführliche Antwort. Ich werde mir das morgen genauer anschauen und dann noch einmal antworten. Den bat-Code des Compileraufrufs kann ich dir aber schon mal geben: @echo off set TARGET=%1 set CONTROLLER=atmega32 echo compiling ... avr-c++ -g -O2 -Wall -I"%QFIX_DIR%\avr\include" -mmcu=%CONTROLLER% -o %TARGET%.elf %TARGET%.cc avr-objcopy -j .text -j .data -O binary %TARGET%.elf %TARGET%.bin if exist %TARGET%.$$$ del %TARGET%.$$$ if exist %TARGET%.elf del %TARGET%.elf echo OK
Gern geschehen.
Mike Modano schrieb:
Sehr simpel gestrickt, noch nicht einmal ein Makefile ... :-O1 | avr-c++ -g -O2 -Wall -I"%QFIX_DIR%\avr\include" -mmcu=%CONTROLLER% -o %TARGET%.elf %TARGET%.cc |
Meine Vermutung, dass da irgend etwas zu Deinem Programm fest an den Anfang des Flash dazugelinkt wird, wird hier erstmal nicht bestätigt. Ich kenn zwar Dein %TARGET%.cc nicht, aber Du erzeugst ja das komplette *.bin aus Deinem %TARGET%.cc Code. Ich bin immer mehr der Meinung, dass der Bootloader einen Bug hat. Probier die beschriebenen Sachen mal aus, damit kannst Du das dann recht genau eingrenzen, dass der Bug im Bootloader liegt ... und dann Qfix auf die Füße treten ... Alternativ halt selbst einen bugfreien Bootloader (gibt's hier im Forum) reinladen. Bis morgen!
> > Evtl. ist der erste Teil fix (und stellt sowas wie das Betriebssystem > dar) und das Userprogramm wird in den hinteren Teil geflasht. > > Da sich die "Betriebsysteme" des Chip "OK" und "Defekt" unterscheiden, > gibt es natürlich ein Problem, wenn avrdude das verifizieren will. > > 1) > Wie wird die Datei, die Du flasht, erzeugt? Kannst Du alle Schritte vom > Sourcecode bis zur Datei %TARGET%.bin nachvollziehen? > Kannst Du die %TARGET%.bin mal posten? > Ich glaube irgendwie, dass der Chip erase überhaupt nichts macht. Auch beim funktionierenden Board läuft das Programm nach dem "Löschvorgang" genauso ab wie vorher. Dafür spricht auch, dass der Löschvorgang quasi keine Zeit in Anspruch nimmt. > 2) > Was passiert, wenn Du > b) eine Hex-Datei, die nur aus 32 KiByte 0xff besteht hineinschreibst > (Verify wird eine Fehlermeldung ausspucken, da der bootloader nicht > überschrieben werden kann. Aber Verify passiert nach dem Schreiben.) > c) Dann den Flash wieder ausliest? > > Das ganze für Chip "OK" und "Defekt" und auch mit nur "32 KiByte 0x00" > machen. Wenn die Datei so groß ist wird gar nichts auf den Chip geschrieben. Man erhält nur die Meldung, dass 0 Bytes geschrieben wurden und danach 0 Bytes verifiziert wurden (beim defekten und funktionierenden Board). Könnte sein, dass der keine Programme annimmt die so groß sind, dass sie den Bootloader überschreiben würden. Nachdem ich 00en reingeschrieben habe und das Programm drüber geflasht habe stehen auch mitten in der Binary noch 00en drin. Wird also alles wohl nur bei Bedarf überschrieben. > > 3) Verhält sich (danach) der Chip "OK" denn einwandfrei, d.h. wenn Du > ein Programm schreibst "LED" an: geht dann auch nur die LED an? > Jupp. > 4) > Hast Du denn Zugriff auf einen ISP Programmer und hat das Board einen > entsprechenden Anschluss? > > 5) > Wenn der Hersteller sich nicht meldet muss man da leider selbst etwas > reverse engineering betreiben, was die sich da eigentlich gedacht haben. > Ich tipp mal auf nen Bug im bootloader. Wie gesagt: soetwas hatte ich > auch einmal bei einem, den ich hier im Forum oder sonstwo übernommen > habe: ab irgendeinem Punkt löschte er den Flash nicht mehr. Ich habe das > durch Einprogrammieren eines neuen bootloaders per ISP gefixt. Habe leider keinen ISP Programmer. Das Board hat einen USB- und einen I2C-Anschluss. Leider kann ich den I2C-Anschluss nicht testen weil ich hier keinen Stecker/Port/usw dafür habe. Wenn jetzt hier niemand mehr eine Idee hat werde ich glaube ich jetzt erstmal denjenigen der die Dinger bestellt hat fragen ob er noch die Rechnung hat (wegen Gewährleistung) und die Dinger einschicken. Soll sich der Hersteller damit rumärgern. Ansonsten bestelle ich einfach zwei neue Boards..
Mike Modano schrieb: > Dafür spricht auch, dass der Löschvorgang quasi > keine Zeit in Anspruch nimmt. Das Löschen dauert sonst auch weniger als eine Sekunde, das ist nicht beunruhigend. > Wenn die Datei so groß ist wird gar nichts auf den Chip geschrieben. Man > erhält nur die Meldung, dass 0 Bytes geschrieben wurden und danach 0 > Bytes verifiziert wurden (beim defekten und funktionierenden Board). Dann mach die Datei gerade so groß, dass sie bis zum Bootloader geht. Du schriebst, dass der Fuses so gesetzt sind, dass der Bootloader bei 0x3F00 beginnt. Also 0x0000 bis 0x3eff ist Platz für Dein Programm. > Könnte sein, dass der keine Programme annimmt die so groß sind, dass sie > den Bootloader überschreiben würden. Vielleicht dieser Bootloader. Sonst kümmert sich die Hardware darum dadurch, dass die entsprechenden Lock-Fuses gesetzt sind. Ein Schreibvorgang auf geschützte Adressen gibt meiner Meinung nach noch nicht mal einen Fehler von der Hardware, erst beim Verify merkt man es. > Nachdem ich 00en reingeschrieben habe und das Programm drüber geflasht > habe stehen auch mitten in der Binary noch 00en drin. Wird also alles > wohl nur bei Bedarf überschrieben. Eigentlich sollte ein chip-erase den ganzen Chip löschen. Ich glaub, der bootloader hat da einen ganz miesen Bug beim Löschen. Denn beim Schreiben von Flash werden quasi aus den Einsen (0xff) nur die Nullen geschrieben. Aus 11101101 kann man noch 01101101 machen, aber nicht 11111101 (nur durch zwischenzeitliches Löschen. Der ATmega kann aber nicht automatisch beim Schreiben vorher löschen. Daher braucht man zwei Schritte [avrdude macht aber den Löschschritt extra vorher]). >> 3) Verhält sich (danach) der Chip "OK" denn einwandfrei, d.h. wenn Du >> ein Programm schreibst "LED" an: geht dann auch nur die LED an? > Jupp. Ich würd ja tippen: Zufall :-) >> Hast Du denn Zugriff auf einen ISP Programmer und hat das Board einen >> entsprechenden Anschluss? > Habe leider keinen ISP Programmer. Das Board hat einen USB- und einen > I2C-Anschluss. Leider kann ich den I2C-Anschluss nicht testen weil ich > hier keinen Stecker/Port/usw dafür habe. I2C ist was anderes als ISP. Ich mein der ISP hat die gleichen Pins wie der SPI Port. > Wenn jetzt hier niemand mehr > eine Idee hat werde ich glaube ich jetzt erstmal denjenigen der die > Dinger bestellt hat fragen ob er noch die Rechnung hat (wegen > Gewährleistung) und die Dinger einschicken. Soll sich der Hersteller > damit rumärgern. Ansonsten bestelle ich einfach zwei neue Boards.. Vielleicht gibt's wen in der Nähe, der einen solchen Programmer hat. Sonst hört sich Dein Projekt ja nach Uni/Forschung an. Da gibt's bestimmt irgendwo jemanden, der soetwas hat. Sonst sind die Programmer inzwischen sehr günstig zu bekommen (z.B. hier im Shop) oder auch leicht selbst zu bauen. Während eines Auslandsaufenthalts mussten es 4 Widerstände a 100 Ohm am Parallelport tun. Hat auch geklappt ;-) Hast Du mal ein Foto von der Platine? Grüße Dave
> Dann mach die Datei gerade so groß, dass sie bis zum Bootloader geht. Du > schriebst, dass der Fuses so gesetzt sind, dass der Bootloader bei > 0x3F00 beginnt. Also 0x0000 bis 0x3eff ist Platz für Dein Programm. > Probiere ich morgen nochmal aus.. > I2C ist was anderes als ISP. Ich mein der ISP hat die gleichen Pins wie > der SPI Port. > Ja das war mir klar aber ich meinte, dass es über den I2C-Port ja vielleicht funktionieren würde (und nicht über USB). Weiß ja nicht wie das ganze da implementiert ist. Vermutlich greifen aber beide Ports ja auf die gleiche Schnittstelle bzw den Bootloader zu und deswegen wirds da auch nicht gehen. > > Vielleicht gibt's wen in der Nähe, der einen solchen Programmer hat. > Sonst hört sich Dein Projekt ja nach Uni/Forschung an. Da gibt's > bestimmt irgendwo jemanden, der soetwas hat. Sonst sind die Programmer > inzwischen sehr günstig zu bekommen (z.B. hier im Shop) oder auch leicht > selbst zu bauen. Während eines Auslandsaufenthalts mussten es 4 > Widerstände a 100 Ohm am Parallelport tun. Hat auch geklappt ;-) > > Hast Du mal ein Foto von der Platine? > Hier ist mal das Datenblatt vom MiniBoard: http://qfix-shop.de/downloads/Datenblatt-MiniBoard.pdf Ich bin Student, aber ich betreue an einer Schule eine Roboter AG. Da grad Semesterferien sind bin ich nicht an der Uni. Dort hätte ich am Fachgebiet bestimmt Zugriff auf einen Programmer, ist aber derzeit halt nicht möglich. MfG, Mike.
> Hier ist mal das Datenblatt vom MiniBoard: > http://qfix-shop.de/downloads/Datenblatt-MiniBoard.pdf Ich würd X3 mal ausmessen, ob der an die Pins 1 (MOSI), 2 (MISO), 3 (SCK) und 4 (/RESET) gehen. Das ist dann die Möglichkeit den Bootloader neu zu programmieren. > Ich bin Student, aber ich betreue an einer Schule eine Roboter AG. Vorbildlich! > Da > grad Semesterferien sind bin ich nicht an der Uni. arghh Vorlesungsfreie Zeit heißt das! Ich schreib seit Wochen non-stop Klausruen ... :-) > Fachgebiet bestimmt Zugriff auf einen Programmer, ist aber derzeit halt > nicht möglich. Bei uns sind die Profs und Assistenten auch in der vorlesungsfreien Zeit da. Haben dann meist sogar mehr Zeit als im Semester. Meld Dich mal, wenn Du da weiter gekommen bist. Grüße Dave
Dave schrieb: >> Hier ist mal das Datenblatt vom MiniBoard: >> http://qfix-shop.de/downloads/Datenblatt-MiniBoard.pdf > Ich würd X3 mal ausmessen, ob der an die Pins 1 (MOSI), 2 (MISO), 3 > (SCK) und 4 (/RESET) gehen. Das ist dann die Möglichkeit den Bootloader > neu zu programmieren. > Ich sehe gerade bei meinen Boards fehlt X3, es sind nur die Bohrungen vorhanden aber es wurde nichts eingesteckt. Mein Messgerät fliegt auch gerade bei meinem Bruder rum, also kann ich da auch nichts machen ^^. > arghh Vorlesungsfreie Zeit heißt das! Ich schreib seit Wochen non-stop > Klausruen ... :-) > So war das bei mir bisher auch immer. Glücklicherweise ist es das erste Semester bei dem ich jetzt doch mal Ferien habe ;-) > Bei uns sind die Profs und Assistenten auch in der vorlesungsfreien Zeit > da. Haben dann meist sogar mehr Zeit als im Semester. > Ja das ist normal, aber ich bin ja nicht an der Uni also bringt mir das auch nix wenn die Profs und Assis dort sind ^^. Jedenfalls danke für deine Hilfe. Ich werde die Boards morgen einschicken. Jemand hat erzählt er hatte die gleichen Probleme und sein Board wurde von qfix anstandslos ersetzt. Schauen wir mal..
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.