USBasp mit AVR Burn-O-Mat - Problem

Hallo,

Hast Du die Spannungen am atTiny nachgemessen ?

Sind die Steuerleitungen (GND, MISO, MOSI, SCK, RESET) vom USBASP per 
Hand verlegt worden ?
Oder über einen ISP-Stecker verbunden worden ?

Wie hoch ist der Takt des atTiny?

Dann müsstest Du noch mit -B 10 oder höher noch eine Versuch starten.

1

Usage: avrdude [options]

2

Options:

3

  -p <partno>                Required. Specify AVR device.

4

  -b <baudrate>              Override RS-232 baud rate.

5

  -B <bitclock>              Specify JTAG/STK500v2 bit clock period (us).

6

  -C <config-file>           Specify location of configuration file.

7

  -c <programmer>            Specify programmer type.

8

  -D                         Disable auto erase for flash memory

9

  -i <delay>                 ISP Clock Delay [in microseconds]

10

  -P <port>                  Specify connection port.

11

  -F                         Override invalid signature check.

12

  -e                         Perform a chip erase.

13

  -O                         Perform RC oscillator calibration (see AVR053). 

14

  -U <memtype>:r|w|v:<filename>[:format]

15

                             Memory operation specification.

16

                             Multiple -U options are allowed, each request

17

                             is performed in the order specified.

18

  -n                         Do not write anything to the device.

19

  -V                         Do not verify.

20

  -u                         Disable safemode, default when running from a script.

21

  -s                         Silent safemode operation, will not ask you if

22

                             fuses should be changed back.

23

  -t                         Enter terminal mode.

24

  -E <exitspec>[,<exitspec>] List programmer exit specifications.

25

  -x <extended_param>        Pass <extended_param> to programmer.

26

  -y                         Count # erase cycles in EEPROM.

27

  -Y <number>                Initialize erase cycle # in EEPROM.

28

  -v                         Verbose output. -v -v for more.

29

  -q                         Quell progress output. -q -q for less.

30

  -?                         Display this usage.

Die 5er Reihen auf dem Steckbrett sind doch immer verbunden.
Von deinem 10-poligen Stecker sind also 8 Pins GND und 2 Pins VCC.

Nino K. schrieb:
> Wird der ATTiny13V überhaupt unterstützt?
Ja das wird er.

> Habe ich falsch verkabelt?
Das wirst du selbst überprüfen müssen.

> Oder hat jemand eine Idee woran es liegen könnte?
Moderne USBasp Firmwares unterstützen die softwaremäßige 
Takteinstellung. Bei avrdude geht das mit dem Schalter -B. Könnte sein, 
das sich der Takt bei diesen Firmwares nicht mehr per Jumper einstellen 
lässt.

Versuch mal -B20

Gruß Oliver

WTF?

Erstmal musste hier nich sone Riesenbilder hochladen für das bissel 
Info.

Und jetzt guck dir mal die Belegungen von sonem Steckbrett an:
Josef D. schrieb:
> Die 5er Reihen auf dem Steckbrett sind doch immer verbunden.
> Von deinem 10-poligen Stecker sind also 8 Pins GND und 2 Pins VCC.

Josef D. schrieb:
> Die 5er Reihen auf dem Steckbrett sind doch immer verbunden.
> Von deinem 10-poligen Stecker sind also 8 Pins GND und 2 Pins VCC.

Ach bin ich ein Hirsch. Das kann ja gar nicht gehen, wenn ich den 10 
poligen Stecker so stecke. Danke für den Hinweis. Ich werde ihn gleich 
mal richtig positionieren und euch dann eine Rückmeldung geben.

Danke für die Hilfe.

Richtig verkabelt sieht das ganze besser aus.

Aber ich habe noch einen kleinen Fehler. Sagt der euch was? Muss ich da 
noch irgendwas an den Fuses machen? Oder habe ich einen Fehler im C 
Code? Der Parameter -B20 oder -B10 bringt auch nichts.

C:\WinAVR-20090313\bin\avrdude.exe -C 
C:\WinAVR-20090313\bin\avrdude.conf -p t13 -P usb -c usbasp -D -B20 -U 
flash:v:C:\Atmel 
Studio\Attiny13V_blinked\Attiny13V_blinked\Debug\Attiny13V_blinked.hex:a
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 
0.02s

Reading | ################################################## | 100% 
0.53s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x09 != 0xff
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

Habe nun etwas recherchiert. Dies Problem scheint oft in Kombination mit 
zu schnellem CPU Takt beim flashen auf. Der dafür verantwortliche Jumper 
am usbasp ist gesetzt.

Hat noch jemand eine Idee?

olf schrieb:
> Vielleicht an deinen unpassend großen Bilddateien?

Oha, die sind mit 2 MB wirklich extrem groß. In Zukunft bitte vorher 
verkleinern.

Um falsch eingestellte CPU-Takte komplett auszuschließen, füge bitte die 
Option -B600 mit an. Der besagte Jumper wirkt zwar auch, stellt die 
Frequenz aber nur auf einen mittelhohen Wert ein. Mit der Option bist du 
flexibler, neuere USBasp besitzen den Jumper oft gar nicht mehr, weil 
seine Funktion durch die Option -B ersetzt wurde.

Markus Weber schrieb:
> Um falsch eingestellte CPU-Takte komplett auszuschließen, füge bitte die
> Option -B600 mit an.

Leider ist auch hier noch der gleiche Fehler:

C:\WinAVR-20090313\bin\avrdude.exe -C 
C:\WinAVR-20090313\bin\avrdude.conf -p t13 -P usb -c usbasp -D -B600 -U 
flash:v:C:\Users\El Nino\Documents\Atmel 
Studio\Attiny13V_blinked\Attiny13V_blinked\Debug\Attiny13V_blinked.hex:a

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

Reading | ################################################## | 100% 
0.02s

avrdude.exe: Device signature = 0x1e9007
avrdude.exe: verifying flash memory against C:\Users\El 
Nino\Documents\Atmel 
Studio\Attiny13V_blinked\Attiny13V_blinked\Debug\Attiny13V_blinked.hex:
avrdude.exe: load data flash data from input file C:\Users\El 
Nino\Documents\Atmel 
Studio\Attiny13V_blinked\Attiny13V_blinked\Debug\Attiny13V_blinked.hex:
avrdude.exe: input file C:\Users\El Nino\Documents\Atmel 
Studio\Attiny13V_blinked\Attiny13V_blinked\Debug\Attiny13V_blinked.hex 
auto detected as Intel Hex
avrdude.exe: input file C:\Users\El Nino\Documents\Atmel 
Studio\Attiny13V_blinked\Attiny13V_blinked\Debug\Attiny13V_blinked.hex 
contains 122 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 
0.53s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x09 != 0xff
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

Mein Code sieht so aus:

1

// Attiny13V_blinked.c

2

3

#define F_CPU 1000000UL

4

5

#include <avr/io.h>

6

#include <util/delay.h>

7

8

int main(void)

9

{

10

     DDRB = (1 << PB4);

11

12

    while(1)

13

    {

14

        PORTB |= (1 << PB4);

15

        _delay_ms(500); 

16

17

        PORTB &= ~(1 << PB4);

18

        _delay_ms(500);

19

    }

20

}

P.s.: Habe nun kleine Bilder verwendet. Die Bilder des vorherigen Posts 
tausche ich gleich aus.

Auf dem Bild sieht es so aus, als ob die LED keinen Vorwiderstand hat. 
Das macht sie bestimmt nicht lange mit.

Gruß Carsten...

Wenn ich gleiches über command line mit avrdude mache, dann klappt es 
ohne Probleme. Ich schreibe das hex file wie folgt in den mcu:

avrdude -c usbasp -p t13 -e
avrdude -c usbasp -p t13 -U flash:w:Attiny13V_blinked.hex

Fuses habe ich keine gemacht.

Warum klappt es so und mit Burn-O-Mat nicht?

Das Ergebnis sieht so aus wie es aussehen sollte:


Reading | ################################

avrdude: verifying ...
avrdude: 122 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Habe gerade gesehen, daß bei Burn-O-Mat offensichtlich nur ein Verify 
gemacht wird.

Im Befehl steht:

... flash:v:C:\Users\El Nino\Documents\Atmel....    ->Verify

anstatt:

... flash:w:C:\Users\El Nino\Documents\Atmel....    ->write

Irgendwas stimmt mit Burn-O-Mat nicht


Gruß Carsten...

Nino K. schrieb:
> Leider ist auch hier noch der gleiche Fehler:
>
> C:\WinAVR-20090313\bin\avrdude.exe -C
> C:\WinAVR-20090313\bin\avrdude.conf -p t13 -P usb -c usbasp -D -B600 -U
> flash:v:C:\Users\El Nino\Documents\Atmel
> Studio\Attiny13V_blinked\Attiny13V_blinked\Debug\Attiny13V_blinked.hex:a
>
> avrdude.exe: AVR device initialized and ready to accept instructions
>
> Reading | ################################################## | 100%
> 0.02s

Irgendwas stimmt da nicht. Hast du den avrdude-Befehl über die 
Kommandozeile eingegeben? Falls nicht, mach das bitte mal – ohne 
Burn-O-Mat.

Die Option -B 600 hätte eigentlich eine solche Ausgabe erzeugen müssen:

1

avrdude: set SCK frequency to 1000 Hz

Ist die Version von avrdude veraltet, so dass sie die Frequenz-Option 
gar nicht kennt?

Weil ich das grad sehe... warum hast du -D mit übergeben?

Markus Weber schrieb:
> Weil ich das grad sehe... warum hast du -D mit übergeben?

Hi Markus,

danke für deine Rückmeldung. Die Option -D war bei mir standardmäßig 
nach der Installation der Applikation gesetzt. Ich habe nun diesen Haken 
entfernt und siehe da es funktioniert.

Vielen Dank für die Hilfe.

Heinz Döpkemeier schrieb:
> Bei den USBasp Jumper slow Programming setzen

Ja, kannst du machen, wenn dein USBasp einen solchen Jumper hat. Viele 
neuere haben keinen solchen, beherrschen aber stattdessen die 
Geschwindigkeitseinstellung per Kommandozeilenoption "-B", wie schon 
oben geschrieben.

Solche zusätzlichen Kommandozeilenoptionen kannst du auch in Burn-O-Mat 
verwenden:

Settings->AVRDUDE, Zeile "additional options".