Hi an alle, ich versuche gerade meinen ATTiny13V mit Hilfe des USBasp(fischl.de) und Burn-O-Mat zu flashen. Leider ohne Erfolg. Im AVR Studio wird das hex File ohne Fehler erzeugt. Der USBasp wird im Windows korrekt erkannt. Im Burn-O-Mat wähle ich den USBasp als Device aus und anschließend das zu flashende Hex File. Die Pfade zum den AVR Files sind korrekt gesetzt. Am USBasp sind folgende Jumper gesetzt: JP1 - Supply Target JP3 - Slow SCK Beim Versuch zu flashen kommt folgende Fehlermeldung: C:\WinAVR-20090313\bin\avrdude.exe -C C:\WinAVR-20090313\bin\avrdude.conf -p t13 -P usb -c usbasp -D -U flash:v:C:\Atmel Studio\Attiny13V_blinked\Attiny13V_blinked\Debug\Attiny13V_blinked.hex:a avrdude.exe: error: programm enable: target doesn't answer. 1 avrdude.exe: initialization failed, rc=-1 Double check connections and try again, or use -F to override this check. Wird der ATTiny13V überhaupt unterstützt? Oder hat jemand eine Idee woran es liegen könnte? Habe ich falsch verkabelt?
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?
Nino K. schrieb: > Oder hat jemand eine Idee woran es liegen könnte? Vielleicht an deinen unpassend großen Bilddateien? Wer bei dem einen unüberlegt handelt, macht das oft auch beim anderen.
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.
USBasp mit AVR Burn-O-Mat - Problem Die USB Taktfrequenz ist zu hoch.Mit bascom avr programmieren clock frequency 187,5 khz Wie kann die cock frequence bei Burn-o-mat geändert werden?
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".
Bitte 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.