Diamex EXA-Prog mit avrdude unter Linux

[N. G. (newgeneration)]

Hallo zusammen,

eben liegt ein neuer [Diamex EXA-Prog Programmer]. Dieser soll laut 
Herstellerseite unter anderem die typischen AVRs über ISP programmieren 
können. Dafür ist laut Dokumentation und auch laut diesem 
Beitrag "Re: Diamex EXA-PROG mit AVRDUDE uter Linux (Mint)" das 
STK500-Protokoll zu verwenden.

Stecke ich den Programmer an, meldet sich dieser brav als solcher an

Okt 02 22:32:03 infinitypro kernel: usb 3-3.2: new full-speed USB device number 17 using xhci_hcd
Okt 02 22:32:03 infinitypro kernel: usb 3-3.2: New USB device found, idVendor=16c0, idProduct=2a9b, bcdDevice=45.80
Okt 02 22:32:03 infinitypro kernel: usb 3-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Okt 02 22:32:03 infinitypro kernel: usb 3-3.2: Product: EXA-PROG
Okt 02 22:32:03 infinitypro kernel: usb 3-3.2: Manufacturer: ERFOS
Okt 02 22:32:03 infinitypro kernel: usb 3-3.2: SerialNumber: 58466-86580-826
Okt 02 22:32:03 infinitypro kernel: cdc_acm 3-3.2:1.0: ttyACM0: USB ACM device

Es erscheint natürlich auch die Datei _/dev/ttyACM0_, die von 
Mitgliedern der Gruppe uucp schreib- und lesbar ist (ich bin Mitglied 
dieser Gruppe):

$ ls -l /dev/ttyACM0
crw-rw---- 1 root uucp 166, 0  2. Okt 22:32 /dev/ttyACM0
$ groups
power adbusers users uucp wheel

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:

$ avrdude -c stk500v2 -P /dev/ttyACM0
OS error: cannot open port /dev/ttyACM0: Input/output error
Error: unable to open port /dev/ttyACM0 for programmer stk500v2

Avrdude done.  Thank you.
$ journalctl -e | tail -9
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: reset full-speed USB device number 20 using xhci_hcd
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: USB disconnect, device number 20
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: new full-speed USB device number 21 using xhci_hcd
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: New USB device found, idVendor=16c0, idProduct=2a9b, bcdDevice=45.80
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: Product: EXA-PROG
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: Manufacturer: ERFOS
Okt 02 22:37:37 infinitypro kernel: usb 3-3.2: SerialNumber: 58466-86580-826
Okt 02 22:37:37 infinitypro kernel: cdc_acm 3-3.2:1.0: ttyACM0: USB ACM device

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.

Kennt jemand diesen Fehlerfall und weiß Rat?

Vielen Dank im Voraus!

[Diamex EXA-Prog Programmer]: 
https://www.diamex.de/dxshop/EXA-PROG-AVR-ISP-und-UPDI-STM32-NXP-ESP

[Frank K. (fchk)]

Das deutet auf einen Fehler in der Firmware hin. Der Controller stürzt 
ab und startet neu.

Ich habe mit den Herstellertools immer die besseren Erfahrungen gemacht. 
Auch wenn diese meist teurer sind.

fchk

[Dieter S. (ds1)]

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.

[Harald K. (kirnbichler)]

Manchmal ist das Problem viel banaler - wenn das verwendete USB-Kabel 
nicht das beste ist, kann das auch lustige Nebeneffekte produzieren.

[N. G. (newgeneration)]

Hallo zusammen und danke für eure Beiträge!

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?

Viele Grüße!

[Stephan S. (uxdx)]

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.

[Dieter S. (ds1)]

Warum "-c stk500v2" und nicht "-c stk500", das könnte eventuell das 
Problem sein.

[N. G. (newgeneration)]

Hallo und danke für eure Beiträge!

Stephan S. schrieb:
> 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).

OS error: cannot open port /dev/ttyACM0: Permission denied
Error: unable to open port /dev/ttyACM0 for programmer stk500v2

Avrdude done.  Thank you.

Dieter S. schrieb:
> 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):

OS error: cannot open port /dev/ttyACM0: Input/output error
OS error: cannot open port /dev/ttyACM0: Input/output error
Error: probing stk500v2 failed, as did stk500v1; perhaps try -c stk500v1
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.

[Dieter S. (ds1)]

Hier hat es unter Linux funktioniert:

Beitrag "Re: Diamex EXA-PROG mit AVRDUDE uter Linux (Mint)"

[Stephan S. (uxdx)]

N. G. schrieb:
> 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

weiteres unter https://wiki.archlinux.org/title/Sudo

[Norbert (der_norbert)]

Stephan S. schrieb:
> Für den Zugriff auf /dev/tty... brauchst Du root-Rechte.

UNSINN!

crw-rw---- 1 root dialout 166, 0  5. Okt 20:17 /dev/ttyACM0
root darf lesen und schreiben, alle in dialout dürfen lesen und schreiben

crw-rw-rw- 1 root dialout 166, 0  5. Okt 20:17 /dev/ttyACM0
*Alle* dürfen lesen und schreiben

[N. G. (newgeneration)]

Hallo zusammen,

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

[Norbert (der_norbert)]

N. G. schrieb:
> Hallo zusammen,
>
> 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.

[Stephan S. (uxdx)]

Norbert schrieb:
> Stephan S. schrieb:
>> Für den Zugriff auf /dev/tty... brauchst Du root-Rechte.
>
> UNSINN!
> crw-rw---- 1 root dialout 166, 0  5. Okt 20:17 /dev/ttyACM0
> root darf lesen und schreiben, alle in dialout dürfen lesen und
> schreiben

genau, deswegen schrieb ich ja "Root-Rechte oder Gruppen-Rechte"

> crw-rw-rw- 1 root dialout 166, 0  5. Okt 20:17 /dev/ttyACM0
> Alle dürfen lesen und schreiben

Das hat N.G. aber nicht geschrieben, da ist nur crw-rw----

Ich habe vermutet, dass per udev-Regel evtl ein falsches Subsystem 
aufgerufen wird, deshalb die Frage nach der udev-Regel.

[Norbert (der_norbert)]

Stephan S. schrieb:
> 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?

[Stephan S. (uxdx)]

Zeig doch mal /dev/udev/rules.d

[N. G. (newgeneration)]

Hallo zusammen,

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.

[Mario M. (thelonging)]

Teilweise wird das Ausschalten von USB-Autosuspend als Lösung genannt.

https://wiki.archlinux.org/title/TLP#USB_autosuspend

[N. G. (newgeneration)]

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:

$ grep 16c0:2a9b /etc/laptop-mode/conf.d/runtime-pm.conf
AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST="<snip> 16c0:2a9b"

Danke an alle, die sich beteiligt haben!

[Norbert (der_norbert)]

Mario M. schrieb:
> Teilweise wird das Ausschalten von USB-Autosuspend als Lösung genannt.

N. G. schrieb:
> 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.