Hallo,
nach einer Neuinstallation von Lubuntu kann ich den Atmega nicht mehr
flashen.
Der Atmega wird zwar ins Reset gezogen, antwortet aber laut
Fehlermeldung nicht. Auch als root das selbe Problem.
Verwendet werden:
-Lubuntu 20.4
-Geany
-avrdude
-gcc-avr
-usbasp
Fehlermeldung ist die Übliche:
avrdude: set SCK frequency to 16000 Hz
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Das gesamte System hat vor der Neuinstallation funktioniert, der Atmega
läuft auch und führt sein Programm aus was noch aus alten Zeiten im
Flash ist.
Hab mit den Rechten und der udev probiert, keine Änderung.
Was nun, was tun, wie kann ich den Fehler eingrenzen?
Jens
Gast
#6501528
Weil diese Frage öfter gestellt wird, habe ich dazu einen Artikel geschrieben, der die mögliche Ursache und Lösungsmöglichkeiten erklärt: http://stefanfrings.de/avr_verfused/index.html
Gast
#6501531
Hi, ich habe seit einem Update irgendwie das Problem, dass das USB Interface nicht ordentlich erkannt wird bzw der Name/ das handle zugeordnet wird. Mal an- und abstecken und über dmesg beobachten was passiert. Fehlermeldungen waren unterschiedliche, u.a auch die von Dir genannte, der Fehler dass USB gar nicht funktioniert war nich offensichtlich. //hufnala
Wie beobachtet man mit dmesg die USB Schnittstellen?
Gast
#6501543
Jens N. schrieb: > Wie beobachtet man mit dmesg die USB Schnittstellen? sudo dmesg -c USB Gerät anstecken, 3 Sekunden warten sudo dmesg -c Du siehst dann ob und wie der Kernel das Gerät erkannt hat.
Jens N. schrieb: > Was nun, was tun, wie kann ich den Fehler eingrenzen? mal langsamer laufen lassen: > avrdude -p m32 -c usbasp -B 100 Was gibt er jetzt aus? Stefan ⛄ F. schrieb: > Du siehst dann ob und wie der Kernel das Gerät erkannt hat. Hat er, sonst käme das nicht: Jens N. schrieb: > avrdude: error: program enable: target doesn't answer. 1
Hallo, mit der sudo dmesg -c Methode kann ich erkennen das der Programmer mit den richtigen IDs und der richtigen Bezeichnung erkannt wird. Wie gesagt: Der Programmer reagiert wenn ich flashen möchte, zieht den Atmega ins Reset, scheint aber nicht in der Laage zu sein die Rückantwort vom Atmega an den PC/avrdude zu senden. Ist es möglich das ich den USB-Port nicht lesen kann, auch als root nicht? Jens
? avrdude -p m32 -c usbasp -B 100
Gast
#6501570
Welche Programmer-Hardware verwendest du? Es hat mich mal einen halben Tag Fehlersuche gekostet, als ich ein 1:1 10-pol-Kabel am ATATMEL-ICE verwendet hab... Der ATATMEL-ICE braucht um 180° gedrehte Kabel, nicht 1:1. Darauf muß man auch erstmal kommen...
@Andreas: Nein, leider nützt auch eine niedrige ISP-Geschwinigkeit nichts. Der Atmega läuft ja auch mit seinem Quarz(14745600Hz). Ich vermute das Problem eher bei der Kommunikation zwichen Soft- und Hardware des PCs. Wie kann ich die Rechte an den USB-Anschlüssen testen/sehen? Jens
@Thosch: Ich habe inzwischen 2 Fischl USBASP probiert die beide fast Fehlerfrei bis zur Neuinstallation des PCs funktioniert haben. Jens
Gast
#6501576
Hast du meinen Tipp mit dem Dauer-Reset versucht?
Jens N. schrieb: > Hab mit den Rechten und der udev probiert, keine Änderung. Jens N. schrieb: > Wie kann ich die Rechte an den USB-Anschlüssen testen/sehen? Was genau hast Du probiert. Geht es als root? Gehörst du als normaler Nutzer zur Gruppe dialout und evtl. noch zu plugdev?
1 | |
2 | |
3 | |
4 | |
@Stafan: Nein, der Programmer hat ja sauber auf Reset gezogen und der Atmega hat treu und brav neu gestartet. Hab jetzt mal ein anderes Projekt/Steckboard angeschlossen und da funktioniert es!Allerdings kommt das Geany-Projekt in diesem Fall auch von einem angeschlossenem USB-Stick. Merkwürdig, merkwürdig...
Gast
#6501591
Stefan ⛄ F. schrieb: > Jens N. schrieb: >> Wie beobachtet man mit dmesg die USB Schnittstellen? > > sudo dmesg -c > > USB Gerät anstecken, 3 Sekunden warten > > sudo dmesg -c > > Du siehst dann ob und wie der Kernel das Gerät erkannt hat. Oder immer live zugucken, was passiert: sudo dmesg -w Am besten in einer zusätzlichen Konsole. Abbrechen kann man das dann mit Ctrl+C.
Jens N. schrieb: > Ich vermute das Problem eher bei der Kommunikation zwichen Soft- und > Hardware des PCs. Jens N. schrieb: > Merkwürdig, merkwürdig... Da ist nichts merkwürdig. Das Problem liegt nicht am PC oder dem USBASP. Diese Meldung: avrdude: error: program enable: target doesn't answer. 1 deutet darauf hin, daß er den uC nicht findet.
@ Alexander S: Ja, ich bin in der Gruppe dialout und plugdev. Jetzt mit einem anderen Projekt geht es auch. Jens
@Stefan: Schöne Funktion, kann deutlich sehen das der USBASP erkannt wird. Wie gesagt: Inzwischen kann ich ein anderes Projekt/Steckboard flashen! Danke, Jens
Gast
#6501639
Jens N. schrieb: > Nein, der Programmer hat ja sauber auf Reset gezogen und der Atmega hat > treu und brav neu gestartet. Manchmal reicht das nicht. Ein fehlerhaftes Programm kann den ISP Port so blockieren, dass er auch nach dem Reset noch hängt. Da werden gleich wieder einige Leute widersprechen, aber mir ist genau das passiert und mit diesem Tipp konnte ich mindestens einer weiteren Person helfen.
Gast
#6501682
Stefan ⛄ F. schrieb: > Manchmal reicht das nicht. Ein fehlerhaftes Programm kann den ISP Port > so blockieren, dass er auch nach dem Reset noch hängt. Nein, das ist nicht möglich. > Da werden gleich > wieder einige Leute widersprechen, aber mir ist genau das passiert Nein. Du hast nur nicht erkannt, was dir tatsächlich passiert ist. Nämlich: Ein fehlerhaftes Programm, welches das Taktsystem dermaßen verkonfiguriert hat, das mit "normalen" Mitteln kein Connect mehr möglich ist. Der ISP-Port ist dabei aber nicht "blockiert", sondern voll funktionsfähig, er will halt nur seeeehr langsam angesprochen werden. So langsam, dass praktisch kein normaler Programmer mehr in der Lage ist, mit dem Teil zu reden. Du kannst das jederzeit absichtlich herbeiführen, das ist trivial. Schnapp dir z.B. einen Tiny25/45/85 und konfiguriere den per Fuses auf die interne 128kHz-Taktquelle. In init() schaltest du dann per CLKPR auf 1/256. Damit beträgt der Systemtakt nur noch 512Hz, der maximale ISP-Takt also 128Hz. Das kann kein üblicher ISP-Programmer (meiner natürlich schon, selbstgemacht ist halt immer besser, nur dann hat man die volle Kontrolle...) Der Trick bei solcherart Problem ist: Das Target nach dem PowerOn im Reset halten, so dass init() nicht zum Zuge kommen kann, erst dann den Programmer anwerfen. Im worst case (CLKDIV8-Fuse gesetzt) muss er dann auf 128/(8*4)=4kHz runter. Das können alle brauchbaren problemlos, man muss es ihnen nur sagen...
Gast
#6501704
c-hater schrieb: > Nein, das ist nicht möglich. War ja klar. Deine Wahrheit ist die einzig wahre. Ich habe meine Antwort dazu wieder gelöscht, weil sie dem TO nicht hilft. Ein Versuch, mich dir gegenüber zu rechtfertigen, hilft niemandem, nicht einmal mir. Ich möchte lieber dem TO helfen. Interessant ist, dass du trotzdem meinen Lösungsvorschlag mit dem Dauer-Reset wiederholt hast.
Gast
#6501913
Stefan ⛄ F. schrieb: > Interessant ist, dass du trotzdem meinen Lösungsvorschlag mit dem > Dauer-Reset wiederholt hast. Nun, es besteht schon ein Unterschied, ob man das Problem tatsächlich sachlich korrekt beschreiben kann und deswegen die Lösung benutzt oder ob man nur zufällig auf einen Workaround um die eigene dramatische Unfähigkeit gestoßen ist...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.