Seltsam ist dass letzte Woche alles i.O war, selber Board, selber
Netzteil, selber USBasp es ging alles! aber das beste kommt, ich habe
gerade mit einem AVRISPmkII probiert und funktioniert fehlerfrei.
Den USBasp hat die letzte Firmware
Hat jemand eine idee?
Ist der Takt zu hoch eingestellt?
Den kann man per Kommandozeile ändern:
-B X
X ist Zeit in us
versuch mal -B 2.0
Wenn das nicht geht, nimm größere Zeiten.
Gruß Oliver
spess53 schrieb:
> Controller vor dem Flashen gelöscht?
Ja, das macht AVRDUDE, wollte nicht das ganze kopieren
Oliver J. schrieb:
> -B X>> X ist Zeit in us>> versuch mal -B 2.0
ich hatte schon probiert hatte B 10 aber leider das gleiche
Ich kann Fuse lesen und ändern nur beim flashen kommt das mit dem
verification error, wie gesagt es ging alles einwandfrei, verstehe ich
wirklich nicht.
Martin e. C. schrieb:> ich hatte schon probiert hatte B 10 aber leider das gleiche
Probier mal -B 50 und achte drauf, ob avrdude das bemängelt. Manchmal
kommt eine Meldung, die etwa so aussieht: "cannot change ISP frequency"
- oder so ähnlich.
Beim USBasp gibt es zwei Sachen, die man in diesem Fall probieren
sollte
1. Den slow STK Jumper setzen
2. Den Kontroller extern speisen (nicht über die USB)
Hans Peter
Markus W. schrieb:
> Probier mal -B 50 und achte drauf, ob avrdude das bemängelt. Manchmal> kommt eine Meldung, die etwa so aussieht: "cannot change ISP frequency"> - oder so ähnlich.
Bringt leider auch nichts, die ISP frequency setz das USBasp problemlos
runter, Device signature wird auch gelesen aber flashen wird nicht:
Hans Peter B. schrieb:
> 1. Den slow STK Jumper setzen> 2. Den Kontroller extern speisen (nicht über die USB)
1. Wird gemacht
2. Board wird extern mit einem 9V Netzteil
Martin e. C. schrieb:> avrdude.exe: reading input file "D:\Microkontroller\Programas\> avrdude.exe: input file D:\Microkontroller\Programas\
Das macht mich grad stutzig... Hier hätte ich komplette Pfade mit
Dateiname erwartet. Bin mir jetzt nicht sicher, ob das normal ist, aber
es sieht seltsam aus. Enthält der Dateiname vielleicht ungewöhnliche
Zeichen, so dass avrdude damit durcheinanderkommt?
Halunke schrieb:
>> \OTROS Ejemplos de AVRStudio\AVRStudio 5\> Mag er vielleicht die Leerzeichen nicht?
Aber warum geht dann mit dem AVRISPmkII? vor allem letzte Woche ging
problemlos.
Nein habe ich nicht gemacht, mache ich nachher nun wenn so wäre dass er
defekte Flash Zellen an der Adresse 0x0040 hat, sollte meine Meinung
nach mit einem AVRISPmkII auch nicht gehen oder?
Ist aber nicht so mit dem AVRISPmkII gibt es kein Problem :-)
dummschwaetzer schrieb:
> hast du mal einen anderen zielchip getestet?
So, ich hab jetzt mit andere Chips probiert (Atmega32, Atmega8) und
kommt das gleiche Fehler!
Irgendwas ist an meinem USBasp nicht mehr in Ordnung.
Für nicht STK500v2-Programmer, wie der USBasp, ist meiner Meinung nach
die Clockverzögerungs-Option nicht -B sondern -i, z.B. -i 10. (siehe
avrdude --help)
Hans Peter
Hallo Peter,
danke für den Hinweis habe gerade probiert bringt leider auch nichts.
Hab gesehen dass ich nicht allein mit dem Problem bin, gibt es
zahlreiche Thread wo es auch um das gleiche geht allerdings keine
Lösung.
In zwischen habe ich in andere Maschine mit Windows XP probiert und da
funktionert also von heute auf morgen meine Win7 64 Bit (Ultimate)
Masichne Probleme mach? glaube ich nicht, naja ich verstehe wircklich
nicht und weiß es nicht wo ich suchen muß.
Update (Falls jemad interessiert):
Habe gestern hier was gefunden:
http://savannah.nongnu.org/bugs/?35590
Habe dann mit eine alte Version von AVRDUDE probiert also 5.10 und ging
auf Anhiebt.
Gruß
Martin
Martin e. C. schrieb:> Update (Falls jemad interessiert):>> Habe gestern hier was gefunden:>> http://savannah.nongnu.org/bugs/?35590
Sein zweiter Fehler dort ist übrigens einfach nur ein Benutzerfehler:
die Erweiterung der Tilde (~) als alias für $HOME muss durch die
Shell erfolgen, AVRDUDE kümmert sich nicht um sowas. Die Shell
erweitert die Tilde aber nur, wenn davor ein Leerzeichen steht.
Daher funktioniert das Programmieren mit -U ~/path/to/file, aber
das Zurücklesen nach -U flash:r:~/path/to/file:i klappt natürlich
nicht. (-U flash:r:$HOME/path/to/file:i würde gehen.)
Zum ersten Fehler: Martin, kannst du mal bitte die stderr-Logs
mit -vvvv von sowohl dem aktuellen AVRDUDE als auch der Version,
in der es noch funktioniert, an den Bugreport anhängen? Ich habe
selbst kein USBasp zur Hand, um das zu testen. ¡muchas gracias!
Hallo Jörg,
hmm... wollte gerade den Fehler wieder reproduzieren und habe die
AVRDUDE Verson an meine WinAVR wieder kopiert (wo es nicht ging) aber
jetzt geht wieder! Ich verstehe jetzt nicht mehr.
Ich kann jetzt leider kein Fehler reproduzieren.
Martin e. C. schrieb:> Ich kann jetzt leider kein Fehler reproduzieren.
mierd* :-( Irgendein Problem muss es ja aber damit geben, schließlich
haben es nun schon zwei Leute voneinander unabhängig gesehen.
USBasp einmal neu an den USB anstecken?
Jörg Wunsch schrieb:
> mierd*
Genau das habe ich gesagt!
USBasp anstecken bringt auch leider nichts, naja sollte noch mal
vorkommen melde mich noch Mal.
@ Jörg Wunsch
Vielleicht haben einfach nur zwei Leute den selben Fehler gemacht ...
kommt vor.
Seit dem ich meinen USBasp habe kann ich Probleme mit dem ISP-Programmer
ausschließen :)
B.A. schrieb:
> @ Jörg Wunsch> Vielleicht haben einfach nur zwei Leute den selben Fehler gemacht ...> kommt vor.
Ich habe kein Fehler gemacht, es ging einfach von heute auf morgen nicht
mehr, du solltest eventuell alles von oben nach unten lesen da habe ich
darüber alles berichtet.
Der Thread ist zwar schon älter, ich hatte aber gerade so ziemlich das
gleiche Problem:
Ich versuche, über einen USBasp einen ATmega48 aus der Arduino-Umgebung
heraus zu flashen ("Upload mit Programmer").
Ich verwende die AVRdude Version 5.11svn-20111019 (Oct 19 2011).
AVRdude meldet jedoch:
verification error, first mismatch at byte 0x0040 0xff != 0x00
(siehe Logfile avrdude_logfile_error.txt)
Wenn man dann den Flashinhalt mit einem unabhängigen Programmer (AVR
Dragon) über das AVR Studio ausliest, sieht man, dass sich ab 0x0040
(also genau die Pagegröße von 64 Bytes) die Daten im Flash zyklisch
wiederholen, so als ob jede Page mit dem gleichen Inhalt programmiert
worden wäre (siehe verify_flash.hex).
Ab 0x0400 ist 0xFF drin, was dann wieder korrekt wäre, da das Hexfile
nur den Bereich bis 0x3FF benutzt.
Wenn ich jedoch die Version 5.11 (Sep 2 2011) verwende, funktioniert
das Flashen inkl. Verify problemlos (siehe Logfile
avrdude_logfile_ok_5_11.txt).
Bug in der SVN-Version?
M. G. schrieb:> Bug in der SVN-Version?
Kann man natürlich nicht ausschließen, aber die ist ja auch nicht
gerade taufrisch. Du kannst ja wenigstens mal die 6.0rc1 probieren
stattdessen.
Jörg Wunsch schrieb:> M. G. schrieb:>> Bug in der SVN-Version?>> Kann man natürlich nicht ausschließen, aber die ist ja auch nicht> gerade taufrisch. Du kannst ja wenigstens mal die 6.0rc1 probieren> stattdessen.
Die 6.0rc1 gibt es nicht zufällig schon irgendwo als exe für Windows, so
wie die 5.11svn-20111019? Dann würde ich es natürlich ausprobieren :)
Mir fehlen die Tools und das Know-How, um "mal eben" eine exe erzeugen
zu können.
M. G. schrieb:> ab 0x0040> (also genau die Pagegröße von 64 Bytes) die Daten im Flash zyklisch> wiederholen, so als ob jede Page mit dem gleichen Inhalt programmiert> worden wäre
Was hier noch nicht bedacht wurde: Koennten nich auch einfach die
Lockbits ein weiteres Auslesen und damit den verify stoeren?
Eine zyklische Ausgabe aller ASCII Zeichen schein mir ein harter
Indikator, dass der Chip Lesegeschuetzt ist.
In diesem Fall hilft nur der Chiperase (ACHTUNG: Loescht Flash + ggf.
EEPROM) und anschliessendes um- bzw. nichtprogrammieren der LOCKBits.
MfG
Stephan B. schrieb:> Was hier noch nicht bedacht wurde: Koennten nich auch einfach die> Lockbits ein weiteres Auslesen und damit den verify stoeren?
Die verschiedenen AVRdude Versionen wurden jeweils mit genau gleicher
Befehlszeile aufgerufen. Sollte somit nicht an den Lockbits liegen.
Thread beobachten
Seitenaufteilung abschalten