Hallo,
bei meinem Linux (Debian) PC mit eHajo's aTeVaL-Board liefert avrdude
(oder besser libusb) nur an einer USB-Buchse keinen Fehler. An den vier
anderen USB-Buchsen erhalte ich von avrdude den Fehler:
1
avrdude: usbdev_send(): wrote 0 out of 1 bytes, err = could not detach kernel driver from interface 0: No data available
2
avrdude: stk500_send_mk2(): failed to send command to serial port
Dabei wird das aTeVal mit ATmega328 prinzipiell erkannt:
1
Using Port : usb
2
Using Programmer : avrispmkII
3
avrdude: usbdev_open(): Found AVRISP mkII, serno: 0002002xxxxxx
4
AVR Part : ATmega328
lsusb meldet vier USB-Hubs
1
$> lsusb
2
...
3
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
4
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
5
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
6
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Wenn das aTeVaL an Bus 003 angeschlossen ist, kommt die Fehlermeldung.
1
Bus 003 Device 007: ID 03eb:2104 Atmel Corp. AVR ISP mkII
Nur wenn das aTeVaL an Bus 001 angeschlossen ist, kommt keine
Fehlermeldung
1
Bus 001 Device 007: ID 03eb:2104 Atmel Corp. AVR ISP mkII
2
...
3
~# avrdude -c avrispmkII -P usb -p m328 -v
4
...
5
Using Port : usb
6
Using Programmer : avrispmkII
7
avrdude: usbdev_open(): Found AVRISP mkII, serno: 0002002xxxxx
8
AVR Part : ATmega328
9
...
10
avrdude: AVR device initialized and ready to accept instructions
avrdude: usbdev_send(): wrote 0 out of 1 bytes, err = could not detach kernel driver from interface 0: No data available
23
avrdude: stk500_send_mk2(): failed to send command to serial port
24
avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
25
avrdude: safemode: To protect your AVR the programming will be aborted
26
avrdude: usbdev_send(): wrote 0 out of 1 bytes, err = could not detach kernel driver from interface 0: No data available
27
avrdude: stk500_send_mk2(): failed to send command to serial port
Ich habe mehrmals die USB-Buchsen gewechselt, bisher tritt der Fehler
reproduzierbar nur an der einen Buchse nicht auf.
Kann ich daraus folgern, dass avrdude (oder besser libusb) mit EHCI
funktioniert und mit xHCI nicht? Oder hat es mit USB 1.1, 2.0 oder 3.0
zu tun?
Noch zur Info
1
Linux deb10 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) x86_64 GNU/Linux
Alexander S. schrieb:> bei meinem Linux (Debian) PC mit eHajo's aTeVaL-Board liefert avrdude> (oder besser libusb) nur an einer USB-Buchse keinen Fehler. An den vier> anderen USB-Buchsen erhalte ich von avrdude den Fehler:
Über externen USB-Hub probieren (mache ich inzwischen auch so, da es
mal klappt, mal nicht klappt).
Karl M. schrieb:> wurden für das USB Device die Benutzerrechte angepasst?
Ja, habe ich angepasst. Die gezeigten Tests habe ich
vorsichtshalber als root gemacht, ich kann avrdude aber
auch als normaler user nutzen.
Marc V. schrieb:> Über externen USB-Hub probieren
Ein Anschluss (der im SD-Card-Reader) funktioniert ja bei mir.
Trotzdem Danke.
Ich würde einfach mal ein Windows auf der Maschine installieren
(notfalls auf einer anderen Platte) und dann nochmal versuchen. avrdude
und libusb gibts auch für Windows, und das Windows brauchst Du ja nicht
unbedingt zu aktivieren, wenn es nur zum Testen ist. 30 Tage hast Du ja
Zeit, dafür musst Du keine Lizenz verbrauchen.
Dann weißt Du, ob es ein Linux- oder ein Hardwareproblem ist.
Die nächste Stufe wäre, einen anderen Programmer auszuprobieren.
Vielleicht kannst Du Dir ja von irgendwem in Deiner Nähe einen anderen
ausleihen.
Noch eine Idee: Wird der Programmer vom USB-Bus versorgt oder von einem
externen Netzteil? Ich denke da an irgendwelche Masseschleifen.
fchk
Alexander S. schrieb:> Karl M. schrieb:>> wurden für das USB Device die Benutzerrechte angepasst?>> Ja, habe ich angepasst. Die gezeigten Tests habe ich> vorsichtshalber als root gemacht, ich kann avrdude aber> auch als normaler user nutzen.>> Marc V. schrieb:>> Über externen USB-Hub probieren>> Ein Anschluss (der im SD-Card-Reader) funktioniert ja bei mir.>> Trotzdem Danke.
Was liefert den /var/log/syslog für Fehlermeldungen.
Wie wurden die Rechte unter /etc/udev/rules.d eingestellt?
Frank K. schrieb:> Ich würde einfach mal ein Windows auf der Maschine installieren
Windows habe ich schon seit 15 Jahren nicht mehr auf meinen
Rechnern. Selbst wenn es unter Windows funktioniert, werde ich bei
Linux bleiben.
Frank K. schrieb:> Die nächste Stufe wäre, einen anderen Programmer auszuprobieren.
Ich habe u.a. einen originalen Atmel AVRISP Mk2. Der hat, soweit
ich mich erinnere, an den beiden Front-Buchsen, die jetzt mit dem
aTeVaL nicht funktionieren, schon mal funktioniert. Das werde
ich nochmal ausprobieren. Einen AVR Dragon hätte ich auch noch.
Das Atmel STK500 über die serielle Schnitttstelle funktioniert auch,
aber
hier geht es um USB.
Frank K. schrieb:> Wird der Programmer vom USB-Bus versorgt
Ja, der aTeVaL wird über USB versorgt. Auf dem ATmega328 auf dem aTeVaL
ist momentan ein LED-Blink Programm. Die LEDs blinken bei Anschluss
an alle USB-Anschlüsse.
Alexander S. schrieb:> Frank K. schrieb:>> Ich würde einfach mal ein Windows auf der Maschine installieren>> Windows habe ich schon seit 15 Jahren nicht mehr auf meinen> Rechnern. Selbst wenn es unter Windows funktioniert, werde ich bei> Linux bleiben.
Darfst Du ja auch. Die Fehlersuche wird aber einfacher, wenn Du weißt,
dass es definitiv ein Linux-Problem ist - oder eben definitiv keines.
Das könntest Du dann dem entsprechenden Maintainer des Treibers oder dem
eHaJo melden. Wenn sich niemand beschwert, gibts auch keine Bugfixes.
Und wenn die Linux-Leute wissen, dass es auf der identischen Hardware
unter Windows funktioniert aber unter Linux nicht, ist das für die auch
eine hilfreiche Information. Dann wissen die nämlich, dass sie bei sich
selber suchen müssen.
fchk
Frank K. schrieb:>>> Ich würde einfach mal ein Windows auf der Maschine installieren
Das "einfach' meinst Du nicht wirklich ernst, oder?
Linux Platten mit SW-RAID neu partitionieren, Windows besorgen,
Windows (ohne Windows Kenntnisse) installieren, viele Tage oder
Wochen später wissen, dass es mit Win 7 funktioniert mit Win 10
aber evtl. nicht, ..., obwohl ich es nur unter Linux brauche.
Frank K. schrieb:> Wenn sich niemand beschwert, gibts auch keine Bugfixes.> Und wenn die Linux-Leute wissen, dass es auf der identischen Hardware> unter Windows funktioniert aber unter Linux nicht, ist das für die auch> eine hilfreiche Information.
Prinzipiell hast Du Recht. Bei Debian melde ich gelegentlich auch
Bugs. Und hier versuche ich, soweit mit vertretbarem Aufwand möglich,
möglichst viele Zusatzinfos zu liefern und weitere Tests zu machen.
Aber eigentlich wollte ich den ATmega auf dem aTeVaL programmieren
und kein Buch über die Unterschiede bei USB zw. Linux und Windows
schreiben.
:-)
Alexander S. schrieb:> Frank K. schrieb:>>>> Ich würde einfach mal ein Windows auf der Maschine installieren>> Das "einfach' meinst Du nicht wirklich ernst, oder?> Linux Platten mit SW-RAID neu partitionieren, Windows besorgen,> Windows (ohne Windows Kenntnisse) installieren, viele Tage oder> Wochen später wissen, dass es mit Win 7 funktioniert mit Win 10> aber evtl. nicht, ..., obwohl ich es nur unter Linux brauche.
Ich hätte die vorhandenen Platten abgeklemmt, eine leere angeklemmt,
Windows drauf, libusb drauf, avrdude drauf und schauen.
Windows bekommst Du hier her:
https://www.chip.de/downloads/Windows-ISO-Downloader_95133731.html
ok, das ist jetzt ein Huhn-Ei-Problem, weil das selber ein
Windows-Binary ist, aber irgendeinen Windows-User wirst Du ja wohl
kennen. So selten sind die nicht. Aber Du brauchst kein Geld und keine
Lizenz und keine Seriennummer, und dass das ganze nach 30 Tagen abläuft
(nicht wirklich, es kommt nur eine "bitte kauf mich" Meldung, und der
Hintergrund wird schwarz), stört dich auch nicht.
Du könntest auch ein FreeBSD nehmen, wenn Dir das sympatischer ist.
Hauptsache etwas, wo 0% Linux drin ist.
Nur so wirst Du jemals erfahren, ob es ein Linux-Bug ist.
> Frank K. schrieb:>> Wenn sich niemand beschwert, gibts auch keine Bugfixes.>> Und wenn die Linux-Leute wissen, dass es auf der identischen Hardware>> unter Windows funktioniert aber unter Linux nicht, ist das für die auch>> eine hilfreiche Information.>> Prinzipiell hast Du Recht. Bei Debian melde ich gelegentlich auch> Bugs. Und hier versuche ich, soweit mit vertretbarem Aufwand möglich,> möglichst viele Zusatzinfos zu liefern und weitere Tests zu machen.>> Aber eigentlich wollte ich den ATmega auf dem aTeVaL programmieren> und kein Buch über die Unterschiede bei USB zw. Linux und Windows> schreiben.> :-)
Etwas Debugging gehört halt bei freier Software dazu. Du kannst eben
nicht deinen FAE anrufen und ein Ticket aufmachen wie bei kommerzieller
Software.
Oder Du gibts Dich eben mit dem einen funktionierenden USB-Port
zufrieden und schließt diesen Thread. Das geht auch.
fchk
Frank K. schrieb:> Du kannst eben> nicht deinen FAE anrufen und ein Ticket aufmachen wie bei kommerzieller> Software.
Da ich nicht möchte, dass das hier zum Windows vs. Linux Thread mutiert,
schreibe ich dazu nur noch:
Einen FAE anrufen und ein Ticket aufmachen können die privaten Nutzer
mit ihren Problemen z.B. bei Atmel-Studio unter Windows 10 doch auch
nicht bzw. das würde wenig bringen.
Hier soll es jetzt um die Frage gehen, warum unter Linux scheinbar
USB-Anschlüsse mit EHCI Controller funktionieren und mit xHCI nicht.
Hallo,
mit dem Original Atmel AVRISP MkII funktioniert es scheinbar an "allen"
USB-Anschlüssen.
Bisher war der Aufbau mit aTeVaL:
aTeVaL mit ATmega328 an USB; Spannung ATmega328 über USB und aTeVaL.
USB1 (Bus 001) kein Fehler.
USB3 (Bus 003) Fehler
1
avrdude: usbdev_send(): wrote 0 out of 1 bytes, err = could not detach kernel driver from interface 0: No data available
2
avrdude: stk500_send_mk2(): failed to send command to serial port
Jetzt neuer Aufbau mit Atmel AVRISP MkII (und STK500):
Das STK500 nutze ich nur, um einen Sockel und eine Spannung für den
ATmega328P zu haben. Der AVRISP MkII liefert keine Spannung zur
Versorgung. Eine serielle Verbindung an das STK500 ist nicht
angeschlossen. Der ATmega328 wird über USB und den AVRISP MkII und den
6-Pin ISP Header (SPROG2) auf dem STK500 angesprochen. Der Reset-Jumper
auf dem STK500 ist offen.
1) AVRISP MkII an USB1 (Bus 001) kein Fehler
1
$> tail /var/log/syslog
2
Jul 29 21:18:20 deb10 kernel: [36745.136080] usb 1-1.3: new full-speed USB device number 13 using ehci-pci
3
Jul 29 21:18:20 deb10 kernel: [36745.246098] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=2104
4
Jul 29 21:18:20 deb10 kernel: [36745.246101] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Demnach tritt das Problem scheinbar nur mit dem aTeVaL "clone" auf.
Hannes Jochriem von eHajo und Jörg Wunsch (avrdude) lesen hier ja ab und
zu mit. Vielleicht kommt da noch ein Kommentar.
Hat das Gerät von eHajo einen "richtigen" USB Chip oder emuliert er USB
nur über gewöhnliche I/O Pins?
Nachtrag: hat er, hätte ich mal vorher selbst nachschauen sollen.
Hallo,
zusätzlich zum aTeVaL von eHajo und AVRISP MkII von Atmel habe ich jetzt
noch den AVR-ISP-Stick von eHajo getestet. Aufbau mit STK500 wie beim
Test mit dem AVRISP MkII (s. o.), allerdings kommen die 5 V vom
AVR-ISP-Stick.
Der AVR-ISP-Stick von eHajo funktioniert soweit auch an beiden USB
Anschlüssen.
1. Test an USB1 (Bus 001):
1
# tail /var/log/syslog
2
Jul 30 17:09:47 deb10 kernel: [ 8265.568852] usb 3-1: USB disconnect, device number 3
3
Jul 30 17:10:41 deb10 kernel: [ 8319.654760] usb 1-1.3: new low-speed USB device number 5 using ehci-pci
4
Jul 30 17:10:41 deb10 kernel: [ 8319.768206] usb 1-1.3: New USB device found, idVendor=1781, idProduct=0c9f
5
Jul 30 17:10:41 deb10 kernel: [ 8319.768210] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
Hallo,
einen habe ich noch...
zusätzlich zum aTeVaL von eHajo, AVRISP MkII von Atmel und AVR-ISP-Stick
von eHajo habe ich jetzt noch den USP-mkII, auch von eHajo, getestet.
https://www.ehajo.de/boards/151/usp-mkii-avr-programmerhttp://dokuwiki.ehajo.de/bausaetze:usp-mkii:anleitung
Aufbau mit STK500 wie beim Test mit dem AVR-ISP-Stick (s. o.) und 5 V
vom USP-mkII.
An USB1 (Bus 001) zeigt der USP-mkII nur sporadisch eine Fehlermeldung.
1. Test an USB1 (Bus 001):
1
# tail /var/log/syslog
2
Jul 31 22:52:41 deb10 kernel: [14167.114434] usb 1-2: new full-speed USB device number 2 using xhci_hcd
3
Jul 31 22:52:41 deb10 kernel: [14167.256018] usb 1-2: New USB device found, idVendor=03eb, idProduct=2104
4
Jul 31 22:52:41 deb10 kernel: [14167.256021] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sieht so aus, als ob an meinem PC das aTeVaL und der USP-mkII am USB1
(Bus 001) in einigen Fällen einen Fehler / eine Warnung liefern und an
USB3 (Bus 003) nicht. Der AVR-ISP-Stick und der Atmel AVRISP MkII
scheinen an beiden USB-Anschlüssen einwandfrei zu funktionieren.
Verallgemeinern kann man das sicher nicht, evtl. ist es ein spezielles
Problem bei meinem USB1-Anschluss. Außerdem konnte ich die Tests nur
wenige Male wiederholen.
Hallo,
um die Tests etwas aussagekräftiger zu machen, habe ich per Bash-Skript
für jeden USB-Programmierer und beide Arten von USB-Buchse avrdude je
100 Mal aufgerufen. Zwischen den avrdude Aufrufen wurde mit "sleep .5"
eine halbe Sekunde gewartet.
Zusätzlich zum Atmel AVRISP MkII, aTeVaL, AVR-ISP-Stick, USP-mkII (alle
eHajo) habe ich noch den USBtinyISP von lady ada und den mySmartUSB MK2
von myAVR probiert.
Die Tabelle gibt an wie oft die Meldung
1
avrdude: usbdev_send(): wrote 0 out of 1 bytes, err = could not detach kernel driver from interface 0: No data available
2
avrdude: stk500_send_mk2(): failed to send command to serial port
erschienen ist.
1
USB-card USB-front
2
ehci-pci xhci_hcd
3
----------------------------------------------
4
AVRISP MkII 0 0
5
AVR-ISP-Stick 0 0
6
USP-mkII 0 48
7
aTeVaL 0 100
8
USBtinyISP 0 0
9
mySmartUSB MK2 0 0
Die Ergebnisse gelten nur für meinen speziellen Aufbau und PC und
sollten nicht verallgemeinert werden.
Vielleicht liegt es auch einfach an der max. Strombelastbarkeit der
USB-Anschlüsse in der PC-Front.
> Vielleicht liegt es auch einfach an der max. Strombelastbarkeit
Bist du den sicher, dass USP-mkII und aTeVaL mehr Strom aufnehmen? Auf
den Fotos beider Produkte sehe ich keine Bauteile, bei denen ich eine
besonder hohe Stromaufnahme erwarten würde. Die sind doch beide
vermutlich weit unter 100mA.
Wenn du Recht hast, müsste das Problem verschwinden, wenn du zusätzlich
ein Netzteil anschließt. Falls das klappt, könnte folgende Erklärung
aufschlussreich sein:
Ich habe mal gelesen, dass Polyfuses nach dem ersten Auslösen einen
erhöhten Innenwiderstand bekommen und dass diese Dinger zum Schutz gegen
Kurzschlüsse oft in USB Ports verbaut sind.
Alexander S. schrieb:> Vielleicht liegt es auch einfach an der max. Strombelastbarkeit der> USB-Anschlüsse in der PC-Front.
Ich hatte schon sehr grafflige Front-USB in "preiswerten" Gehäusen, die
auf dem Oszi erkenbar schlechteres Signal liefern.
Eventuell hilft ein zwischengeschalteter USB 2.0 Hub. USB high Speed hat
ein paar HF Tricks im Ärmel.
Übrigens würde ich auch mal einfach die 5V Spannung messen - ältere
Netzteile hatten hier öfters mal ein Problem und liefen aus der Toleranz
raus. Beim aTeVaL Board sollte man da problemlos mit 'nem Multimeter ran
kommen.
Stefanus F. schrieb:> Bist du den sicher, dass USP-mkII und aTeVaL mehr Strom aufnehmen?
Nein, deswegen hatte ich "vielleicht" geschrieben. :-)
Ich dachte auch eher an einen kurzen Stromimpuls beim Start und nicht an
einen Dauerstrom.
Jim M. schrieb:> Ich hatte schon sehr grafflige Front-USB in "preiswerten" Gehäusen, die> auf dem Oszi erkenbar schlechteres Signal liefern.
Das will ich nicht ausschließen. Allerdings scheinen die anderen
Programmer ja kein Problem mit dem USB-Anschluss zu haben.
Jim M. schrieb:> Übrigens würde ich auch mal einfach die 5V Spannung messen
_ aTeVaL an USB-SD-card-reader: 4,94 V, an USB-PC-Front: 4,95 V
USP-MkII an USB-SD-card-reader: 5,02 V, an USB-PC-Front: 5,03 V
Sieht also erstmal ok aus. Allerdings sind die Spannungen am aTeVal
etwas niedriger.
S. R. schrieb:> Hast du mal versucht, den xHCI-Treiber zu entladen und die betroffenen> Ports im OHCI/EHCI-Modus zu betreiben?
Mit den Interna von USB habe ich mich noch nie näher beschäftigt.
Da müsste ich mich erstmal etwas informieren. Wie ich unter Linux
den Port im OHCI/EHCI-Modus betreiben kann, muss ich erst recherchieren.
S. R. schrieb:> Hast du mal versucht, den xHCI-Treiber zu entladen und die betroffenen> Ports im OHCI/EHCI-Modus zu betreiben?
Der Trick dürfte für die internen USB Ports im Skylake (und folgenden)
nicht mehr funktionieren. Ohne xHCI sind die Ports tot.
Alexander S. schrieb:> Mit den Interna von USB habe ich mich noch nie näher beschäftigt.
Für USB 2.0 (EHCI) brauchte man immer einen Companion Controller (also
einen USB 1.1-Controller (OHCI oder UHCI), der die langsamen
Geschwindigkeiten konnte. Also hat ein "rmmod ehci" ausgereicht, um USB
2.0 komplett abzuschalten - und Betriebssysteme ohne EHCI-Treiber
konnten trotzdem USB sprechen.
Auf die gleiche Weise kriegt man auch den USB 3-Controller (xHCI) tot.
Aber:
Jim M. schrieb:> Der Trick dürfte für die internen USB Ports im Skylake (und folgenden)> nicht mehr funktionieren. Ohne xHCI sind die Ports tot.
Das scheint zu stimmen. Ohne xHCI-Treiber gibt es garkein USB mehr.
