So weit sieht erst einmal alles richtig aus. Nun das eigentliche Problem:
Nutze ich ein avrdude aus meinen Paketquellen (Arch Linux, Version 8.0), so wird meistens beim Aufruf sofort das USB-Gerät ab- und wieder angemeldet, was avrdude entsprechend quittiert:
1
$ avrdude -c stk500v2 -P /dev/ttyACM0
2
OS error: cannot open port /dev/ttyACM0: Input/output error
3
Error: unable to open port /dev/ttyACM0 for programmer stk500v2
4
5
Avrdude done. Thank you.
6
$ journalctl -e | tail -9
7
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: reset full-speed USB device number 20 using xhci_hcd
8
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: USB disconnect, device number 20
9
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: new full-speed USB device number 21 using xhci_hcd
10
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: New USB device found, idVendor=16c0, idProduct=2a9b, bcdDevice=45.80
11
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
12
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: Product: EXA-PROG
13
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: Manufacturer: ERFOS
14
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: SerialNumber: 58466-86580-826
Man erkennt, dass das USB-Gerät einen Reset durchläuft und als neues Gerät (Nummer 21 statt 20) auftaucht. Dass avrdude das nicht mag, ist nachvollziehbar.
Ich kenne den Diamex EXA-PROG unter Windows. Nur um sicher zu sein, das Testprogramm (Exa_Tool_135.exe oder ähnlich) funktioniert?
Und die DIP Schalter stehen auf den richtigen Positionen? Je nach Einstellung verwendet der EXA-PROG unterschiedliche Protokolle zur Kommunikation mit dem PC.
ich habe auf Anraten das Ganze einmal unter Windows probiert. Dafür habe ich zwei Tests durchgeführt:
Zuerst einmal habe ich das mitgelieferte Self-Test-Programm ausgeführt, welches augenscheinlich alle Pins auf Funktion überprüft. Dabei wurden keine Fehler gefunden. Das Programm zeigt auch an, dass die aktuellste Firmware installiert sei.
Anschließend habe ich das gute alte AVR Studio 4.19 installiert, welches ja eine native Unterstützung des STK500 (den der Programmer emuliert) bietet. Damit kann ich ohne Probleme die Signatur/Fueses/etc auslesen und den Controller programmieren (in der gleichen Schaltung wie beim Versuch unter Linux, daran liegt es also nicht). Die DIP-Schalter passen demnach auch (1 oben, 2-4 unten: entspricht 5V-Programmierung mittels STK500-ISP-Protokoll). Auch das Kabel sollte demnach ausgeschlossen werden.
Kann sich jemand vorstellen, warum das unter Windows geht, unter Linux aber nicht?
Merkwürdig, dass /dev/ttyACM0 bei Dir in der Gruppe uucp ist. Bei mir (sowohl Ubuntu als auch LinuxMint als auch Debian) sind die (und /dev/ttyUSBx) immer in der Gruppe dialout. Der input/output-error würde dazu passen.
Wie wird das denn aktiviert: mittels udev-Regel?
Edit: Sehe gerade, Du nutzt Arch, da kann das anders sein. Schau Dir trotzdem mal die udev-Regel an, falls da eine genutzt wird.
Edit: Sehe gerade, Du nutzt Arch, da kann das anders sein. Schau Dir
trotzdem mal die udev-Regel an, falls da eine genutzt wird.
Tatsächlich ist es korrekt; Arch nutzt die Gruppe uucp (wobei mir weder Grund noch Histroie dafür bekannt sind). Siehe https://wiki.archlinux.org/title/Users_and_groups#User_groups. Probiere ich das Ganze ohne Mitglied der Gruppe zu sein, dann kommt auch ein anderer Fehler (permission denied statt Input/output error).
1
OS error: cannot open port /dev/ttyACM0: Permission denied
2
Error: unable to open port /dev/ttyACM0 for programmer stk500v2
Warum "-c stk500v2" und nicht "-c stk500", das könnte eventuell das
Problem sein.
Anscheinend führt ein "stk500" dazu, dass er zuerst das STK500v2-Protokoll versucht und, falls das nicht zum Erfolg führt, auch das STK500v1-Protokoll (zumindest erkläre ich es mir selbst anhand der Ausgaben so, ich habe nicht in den Code geschaut):
1
OS error: cannot open port /dev/ttyACM0: Input/output error
2
OS error: cannot open port /dev/ttyACM0: Input/output error
3
Error: probing stk500v2 failed, as did stk500v1; perhaps try -c stk500v1
4
Error: unable to open port /dev/ttyACM0 for programmer stk500
Auch ein Test mit "stk500v1" brachte den gleichen Fehler und natürlich damit auch keinen Erfolg.
Probiere
ich das Ganze ohne Mitglied der Gruppe zu sein, dann kommt auch ein
anderer Fehler (permission denied statt Input/output error).
Für den Zugriff auf /dev/tty... brauchst Du root-Rechte oder Gruppen-Rechte. Du kannst avrdude also als root starten oder als User mit sudo avrdude ... , sudo musst Du aber vorher als root mit pacman -S sudo installieren und Dich in die Gruppe sudo eintragen
bezüglich der letzten beiden Beiträge: die Berechtigungen auf die serielle Schnittstelle sind kein Problem. Ich wollte oben nur klar machen, dass ein anderer Fehler kommt, falls keine Berechtigungen bestehen. Ob die Gruppe jetzt dialout oder uucp heißt, spielt dabei keine Rolle. Auch mit root-Rechten zeigt sich (wie vermutet) das gleich Verhalten.
bezüglich der letzten beiden Beiträge: die Berechtigungen auf die
serielle Schnittstelle sind kein Problem. Ich wollte oben nur klar
machen, dass ein anderer Fehler kommt, falls keine Berechtigungen
bestehen. Ob die Gruppe jetzt dialout oder uucp heißt, spielt dabei
keine Rolle. Auch mit root-Rechten zeigt sich (wie vermutet) das gleich
Verhalten.
Viele Grüße
War schon klar. Wollte nur den Unsinn nicht unkommentiert stehen lassen.
Und dann noch die Empfehlung den Programmer als root laufen zu lassen… Unfassbar.
Im Übrigen ist die Tatsache, dass der Programmer das Gerät über die simulierte serielle Schnittstelle zum Abstürzen bringt, schon eigenartig. An der Stelle hat das System nämlich gar nicht genug Rechte um so etwas von sich aus auszulösen.
Es könnte sich also um eine Command-Sequenz handeln welche im Programmer falsch und ohne Fehlerprüfung ausgeführt wird und das Ding crasht.
Das hat N.G. aber nicht geschrieben, da ist nur crw-rw----
Ja, korrekt. Direkt im Eröffnungsbeitrag.
rw sowohl für root als auch für uucp. Und das er der Gruppe uucp angehört.
Damit wurde alles Notwendige gesagt.
Ich habe vermutet, dass per udev-Regel evtl ein falsches Subsystem
aufgerufen wird, deshalb die Frage nach der udev-Regel.
Was hätte das mit den korrekt zugewiesenen Rechten zu tun?
im eben gelöschten Beitrag schrieb ich, dass es jetzt gehen würde, nachdem ich eine udev-Regel gelöscht habe (https://probe.rs/docs/getting-started/probe-setup/#linux%3A-udev-rules). Was soll ich sagen: es geht jetzt manchmal, etwa jeden dritten Versuch. Ob es an den probe.rs-Regeln lag, weiß ich spontan nicht. Eigentlich trifft keine davon zu.
Man könnte jetzt sagen, dass es "immerhin" manchmal geht, aber wirklich zufrieden bin ich damit nicht.
Danke für den Tipp! Das war der Hinweis, der zur Lösung geführt hat. Ich habe die laptop-mode-tools auf dem Rechner aktiviert gehabt, welche den Programmer in den Schlaf geschickt haben.
Zur Behebung musste ich nur "16c0:2a9b" in die Liste der AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST (in der Datei /etc/laptop-mode/conf.d/runtime-pm.conf) aufnehmen:
Danke für den Tipp! Das war der Hinweis, der zur Lösung geführt hat.
Zunächst einmal: Gut zu hören.
Das sollte aber unbedingt an den Hersteller gemeldet werden, der USB suspend Mechanismus ist eigentlich recht gut in den Standards fest gekopft und der Hersteller sollte sich auch daran halten.
