Bei flashen AVRDUDE sagt: verification error - USBasp

OP #2699789
Lesenswert?

Hallo,
habe ein seltsames Fehler, beim flashen mit USBasp sagt AVRDUDE:
1
Reading | ################################################## | 100% 0.54s
2

3
avrdude.exe: verifying ...
4
avrdude.exe: verification error, first mismatch at byte 0x0040
5
             0xff != 0x02
6
avrdude.exe: verification error; content mismatch
7

8
avrdude.exe: safemode: Fuses OK

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?
OP #2700777
Lesenswert?

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:

1
avrdude.exe: set SCK frequency to 16000 Hz
2
avrdude.exe: AVR device initialized and ready to accept instructions
3

4
Reading | ################################################## | 100% 0.01s
5

6
avrdude.exe: Device signature = 0x1e9308
7
avrdude.exe: erasing chip
8
avrdude.exe: set SCK frequency to 16000 Hz
9
avrdude.exe: reading input file "D:\Microkontroller\Programas\
10
avrdude.exe: input file D:\Microkontroller\Programas\
11
avrdude.exe: writing flash (1202 bytes):
12

13
Writing | ################################################## | 100% 7.52s
14

15
avrdude.exe: 1202 bytes of flash written
16
avrdude.exe: verifying flash memory against D:\Microkontroller\Programas
17
avrdude.exe: load data flash data from input file D:\Microkontroller\Programas
18
avrdude.exe: input file D:\Microkontroller\Programas\
19
avrdude.exe: input file D:\Microkontroller\Programas\
20
avrdude.exe: reading on-chip flash data:
21

22
Reading | ################################################## | 100% 3.81s

aber dann:
1
avrdude.exe: verifying ...
2
avrdude.exe: verification error, first mismatch at byte 0x0040
3
             0xff != 0x02
4
avrdude.exe: verification error; content mismatch
5

6
avrdude.exe: safemode: Fuses OK
7

8
avrdude.exe done.  Thank you.

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
(Firma: guloshop.de) #2700827
Lesenswert?

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?
OP #2700853
Lesenswert?

Hallo Markus,

ja ja, das kommt schon ich habe es nur für "Copy & Paste" hier 
ausgeschnitten das ganze Pfade sieht so aus:
1
avrdude.exe: Device signature = 0x1e9308
2
avrdude.exe: erasing chip
3
avrdude.exe: reading input file "D:\Microkontroller\Programas\OTROS Ejemplos de AVRStudio\AVRStudio 5\LCD_M8535\LCD_M8535\Debug\LCD_M8535.hex"
4
avrdude.exe: input file D:\Microkontroller\Programas\OTROS Ejemplos de AVRStudio\AVRStudio 5\LCD_M8535\LCD_M8535\Debug\LCD_M8535.hex auto detected as Intel Hex
5
avrdude.exe: writing flash (1202 bytes):
6

7
Writing | ################################################## | 100% 0.87s

das passt schon.
OP #2700918
Lesenswert?

Halunke schrieb:
> Mag er vielleicht die Leerzeichen nicht?

ne, definitiv nicht! jetzt ohne Leerzeichen:

1
avrdude.exe: AVR device initialized and ready to accept instructions
2

3
Reading | ################################################## | 100% 0.00s
4

5
avrdude.exe: Device signature = 0x1e9308
6
avrdude.exe: erasing chip
7
avrdude.exe: reading input file "C:\LCD_M8535\LCD_M8535\Debug\LCD_M8535.hex"
8
avrdude.exe: input file C:\LCD_M8535\LCD_M8535\Debug\LCD_M8535.hex auto detected as Intel Hex
9
avrdude.exe: writing flash (1202 bytes):
10

11
Writing | ################################################## | 100% 0.80s
12

13
avrdude.exe: 1202 bytes of flash written
14
avrdude.exe: verifying flash memory against C:\LCD_M8535\LCD_M8535\Debug\LCD_M8535.hex:
15
avrdude.exe: load data flash data from input file C:\LCD_M8535\LCD_M8535\Debug\LCD_M8535.hex:
16
avrdude.exe: input file C:\LCD_M8535\LCD_M8535\Debug\LCD_M8535.hex auto detected as Intel Hex
17
avrdude.exe: input file C:\LCD_M8535\LCD_M8535\Debug\LCD_M8535.hex contains 1202 bytes
18
avrdude.exe: reading on-chip flash data:
19

20
Reading | ################################################## | 100% 0.50s
21

22
avrdude.exe: verifying ...
23
avrdude.exe: verification error, first mismatch at byte 0x0040
24
             0xff != 0x02
25
avrdude.exe: verification error; content mismatch
26

27
avrdude.exe: safemode: Fuses OK
28

29
avrdude.exe done.  Thank you.
OP #2701504
Lesenswert?

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ß.
Moderator Persönliche Seite #2707927
Lesenswert?

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!
#3297229
Lesenswert?

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?
Angehängte Dateien:
#3297301
Lesenswert?

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.
#3301086
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren