Datum:
Guten Tag, ich versuche mit Avrdude eine Hex Datei auf einen Mega16 zu übertragen. Das Stk500 hängt an der Seriellen Schnittstelle ist eingeschalten und mit dem Rechner verbunden. Die Version des dudes ist 5.0-1. Ich nutzte Ubuntu 6.06.
/Avr# avrdude -p m16 -c stk500 -e -U flash:w:main.hex |
liefert
avrdude: stk500_recv(): programmer is not responding |
und
/Avr# avrdude -p m16 -c stk500v2 -e -U flash:w:main.hex |
bringt time out
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500_2_ReceiveMessage(): timeout |
In der Kurzanleitung für Avrdude im Tutorial steht das ein Hardware-Link eingerichtet werden muss. Wie muss ich diese Zeilen
mknod /dev/parport0 c 99 0 chmod a+rw /dev/parport0 |
abändern? bzw. was könnte ich sonst noch falsch machen?
Datum:
Ist mir nicht bekannt. Ich habe mir das Board gebraucht gekauft. Deshalb hab ich die Versionen Stk500 u. Stk500v2 getestet. Ich versuch mal Firmware zu Updaten.
Datum:
Kannst auch mal -vvvv angeben, dann wird die komplette Kommunikation geloggt.
Datum:
Firmware ist jetzt stand 2.04. Es ändert sich aber nicht an dem Fehler mit -vvvv:
ruebe@ruebe-desktop:~$ avrdude -p m16 -c stk500v2 -e -vvvv -U flash:w:main.hex avrdude: Version 5.0 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ System wide configuration file is "/etc/avrdude.conf" User configuration file is "/home/ruebe/.avrduderc" User configuration file does not exist or is not a regular file, skipping Using Port : /dev/ttyS0 Using Programmer : stk500v2 avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] avrdude: ser_recv(): programmer is not responding avrdude: stk500_2_ReceiveMessage(): timeout avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] avrdude: ser_recv(): programmer is not responding avrdude: stk500_2_ReceiveMessage(): timeout |
Datum:
Hängt er denn auch an /dev/ttyS0 dran? Schließe mal die TxD- und RxD-Leitung von ttyS0 kurz und wiederhole das Kommando. Dann müsstest du ja wenigstens das Echo sehen.
Datum:
Ich hab die Pins Kurzgeschlossen, es ändert sich aber nichts an der Ausgabe. Glaube mittlerweile das es an der seriellen Schnittstelle liegt. /ttyS0 stimmt meiner Meinung nach da ich nur eine hab. Ich Versuch mal mehr über die sS heraus zu finden. Vielen Dank Jörg, für deine Hilfe und für die vielen Beiträge die du im zusammenhang mit avrdude schon geleistet hast!
Datum:
> Glaube mittlerweile das es an der seriellen Schnittstelle liegt.
Ich auch. ;-)
Guck dir mal die Bootmeldungen an (sollten in /var/log/messages
mit aufgezeichnet werden), was er über die seriösen Schnittstellen
so alles sagt.
Datum:
Als User darfst du eventuell nicht auf die schnittstelle schreiben ?? Zumindest ist man wenn ich mich recht erinnere von hause aus in einer entsprechenden Gruppe. probier mal sudo avrdude -p m16 -c stk500v2 -e -vvvv -U flash:w:main.hex
Datum:
> In der Kurzanleitung für Avrdude im Tutorial steht das ein Hardware-Link > eingerichtet werden muss. Der parport hat damit mal garnichts zu tun. Und was Christian schreibt, ist korrekt. Am besten konfigurierst Du sudo so, dass Du kein Passwort benoetigst dann kannst Du es so z.B. in Makefiles verwenden, so mache ich es. Du kannst auch die Permission des devices aendern aber das empfehle ich eher weniger, das macht man eigentlich nicht. Michael
Datum:
Michael G. wrote: > Du kannst auch die Permission des > devices aendern aber das empfehle ich eher weniger, das macht man > eigentlich nicht. Warum ,,macht man das eigentlich nicht''? Es gab auch eine Welt vor sudo, und device permissions, insbesondere group permissions, sind für solche Dinge (u.a.) da. Für serielle Geräte hat sich die Gruppe uucp durchgesetzt, deren Mitglied man sein muss, um darauf zugreifen zu können. Für parport müsste man halt was Ähnliches machen oder auch gleich die Gruppe uucp mit benutzen. Im Gegenteil, das ist sogar der weit sauberere Weg als sudo: sudo lässt den Prozess (also avrdude) ja mit root-Rechten laufen, damit kann er viel mehr Unfug anstellen (insbesondere auch im Falle von Bugs) als mit einem auf den Nutzer gezielt eingerichteten device node und einem Prozess, der ansonsten mit normalen Nutzerrechten läuft.
Datum:
Hast Du an deinen Rechner eine SerielleSchnittstelle oder über USB-Adapter? Versuch einfach mal ein paar Devices durch (ttyS0, ttyS1...), die in Frage kommen mit: avrdude -p m16 -c stk500 -P /dev/tty.PL2303-0000207D tty.PL2303-0000207D ist mein USB-Adapter, die Bezeichnung wechselt aber wenn er an einem anderen USB-Port steckt. Wenn dein stk500 die Version 2 drauf hat, dann gibt dir avrdude einen hinweis, dass Du stk500v2 bitte benützen sollst. Wenn Du keine schreibrechte auf das Device hast, dann mit chmod ändern, sudo benützen oder gleich als root anmelden. viel erfolg
Datum:
Hallo! Ich habe ein ähnliches Problem mit AVRDude. Versuche momentan den AT90CAN64 mit dem STK500 + STK501 zu programmieren. AVRDude liefert jedoch immer die Meldung:
avrdude -p c64 -c avrisp -U flash:w:blink.hex -vvvv -P /dev/ttyUSB0 avrdude: Version 5.5, compiled on Feb 21 2008 at 14:24:21 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ System wide configuration file is "/etc/avrdude/avrdude.conf" User configuration file is "/home/Florian/.avrduderc" User configuration file does not exist or is not a regular file, skipping Using Port : /dev/ttyUSB0 Using Programmer : avrisp avrdude: Send: 0 [30] [20] avrdude: Send: 0 [30] [20] avrdude: Send: 0 [30] [20] avrdude: ser_recv(): programmer is not responding avrdude: stk500_recv(): programmer is not responding avrdude: Send: Q [51] [20] avrdude: ser_recv(): programmer is not responding avrdude: stk500_recv(): programmer is not responding make: *** [load] Fehler 1 |
Das STK500 hängt an einem USB-RS232 Adapter...RW-Zugriff auf die Schnittstelle habe ich, und wenn ich die Schnittstelle kurzschließe bekomm ich ein Echo. Kann mir vielleicht jemand weiterhelfen?! Benötige ich ein Firmware-Update für diesem uC bzw. das STK501?! "avrisp" mit "stk500" ersetzen bringt btw auch nix (das war mein erster Versuch) Gruß Florian
Datum:
Florian wrote:
> Das STK500 ...
...ist kein AVRISP.
Hast du mal stk500v2 probiert?
Was mich wundert ist, dass "stk500" eigentlich zuerst die
Protokollversion 1 und danach 2 probieren sollte.
Datum:
Hey! Danke für die schnelle Antwort. Wenn ich stk500v2 benutze, sieht es nicht viel anders aus:
avrdude -p c64 -c stk500v2 -U flash:w:blink.hex -vvvv -P /dev/ttyUSB0 avrdude: Version 5.5, compiled on Feb 21 2008 at 14:24:21 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ System wide configuration file is "/etc/avrdude/avrdude.conf" User configuration file is "/home/Florian/.avrduderc" User configuration file does not exist or is not a regular file, skipping Using Port : /dev/ttyUSB0 Using Programmer : stk500v2 avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] avrdude: ser_recv(): programmer is not responding avrdude: stk500_2_ReceiveMessage(): timeout avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] avrdude: ser_recv(): programmer is not responding avrdude: stk500_2_ReceiveMessage(): timeout |
Datum:
Hast du noch andere Programme offen, die auf deinen Seriellen Port zugreifen? -> alle schließen! Ich hatte gestern auch solche Timeouts bis ich gemerkt habe dass mein minicom noch lief... Danach gings ohne Probleme.
Datum:
ähmmm.....ned wirklich....habe das ganz neu, und das ist auch der erste uC, den ich damit versuche zu programmieren.... Hab nur mal mit dem Multimeter gemessen, ob auch Versorgungsspannung beim uC ankommt... Aber ob auch sonstige Leiterbahnen / ICs o.ä. ok sind, weiß i ned...
Datum:
Das hat nichts mit der Verbindung zwischen dem Programmierteil des STKs und dem Controller zu tun. Bereits die Kommunikation mit dem Programmierteil selbst funktioniert nicht, diese muss man aber selbst ganz ohne eingesteckten Controller (bzw. dem STK501) aufbauen können. Hast du noch irgendwo einen Hardware-RS-232-Port zur Verfügung? Nicht dass dein USB-Dongle keine 115200 Bd kann... Es wäre übrigens sinnvoller gewesen, dafür einen neuen Thread aufzumachen. Hat ja mit dem Originalthema kaum noch was gemein.
Datum:
Ok...dachte das passt noch zum Originalthema, weil es hier ja auch anfangs darum ging, dass man beim versuch mit AVRDude ein timeout bekommt....Sorry! Hab hier im Büro einen Rechner mit einer Hardware-RS232 Schnittstelle. Allerdings gibt es da keinen Unterschied. Habe auch schon geguckt, ob die Schnittstellen (Am STK und der USB-Adapter) die Pegel richtig setzen. Zumindest die Rx und Tx Pegel sind bei beiden richtig, die Handshakes konnte ich leider noch nicht überprüfen...
Datum:
Nur so: den richtigen RS-232-Stecker am STK hast du aber benutzt, ja?
Datum:
Jops. So schlau war ich ;) Hab auch schon mehrfach die ganzen Jumper überprüft, ob ich die alle richtig gesetzt habe...Kann ja immer mal sein, dass man sich da vertut... Es kommen auch definitiv Daten an, und auch mit der richtigen Bd-Rate. Hab das grad nochmal mit nem Scope überprüft. Werde mich jetz mal an Reichelt wenden und schauen, ob man es reklamieren kann...
Datum:
Florian wrote: > Es kommen auch definitiv Daten an, und auch mit der richtigen Bd-Rate. Gemessen wo? > Hab das grad nochmal mit nem Scope überprüft. Werde mich jetz mal an > Reichelt wenden und schauen, ob man es reklamieren kann... Wenn du vor dem Einschalten den PROGRAM-Taster drückst, kannst du dann den Bootloader ansprechen? Der hört auf avr910-Protokoll.
Datum:
Gemessen am RS232-Port des STK500 mit nem Tastkopf (Lötkontakte auf der Unterseite der Platine). An Tx sieht man jede Menge Daten mit 115,2 kBd ankommen, während Rx nichts von sich gibt... Zum Bootloader: Nein, den kann ich nicht ansprechen...selbes Problem: "programmer is not responding"...
Datum:
Miss nochmal an Pin 2/3 des ATtiny2313 bzw. Pin 9/10 des ATmega8535. Dort muss das RS-232-Signal auch noch ankommen.
Datum:
Hey! Die Pins der beiden ICs konnte ich leider nicht mehr testen...als ich das gelesen hab, war das Paket schon auf dem Weg zurück zu Reichelt... Hab jetzt ein neues STK500 und mir ist auch direkt ein Unterschied aufgefallen: Bei meinem alten hat die Status-LED nie geleuchtet...nun tut sies...
Datum:
Florian wrote:
> Bei meinem alten hat die Status-LED nie geleuchtet...nun tut sies...
Dann war wohl was grundlegend im Eimer, vermutlich die Takterzeugung.
Datum:
>stk500_2_ReceiveMessage(): timeout
hatte ähnliches Problem wie Thread-Ersteller.
Es lag am Rx/Rx - Tx/Tx Kabel. Echo testen bringt da nicht
weiter, das es ja ankommt. Es bleibt eigentlich Durchgangsmesser
zum Testen.
Gruß