uno2iec USB killer ... de hogyan?

C/C++

Az uno2iec projectet próbálom életre lehelni. Ebben egy Arduino Nano kommunikálna a PC-n egy QtCreator-ban készült cpp kóddal.

Sajnos a kód nem működik megfelelően, de még a hibát sem tudom megkeresni, mivel a cpp kód indítása után egy kis idő elteltével eltűnik a /dev/ttyUSB0 eszköz. Ilyenkor hiába húzom ki, és dugom be újra, a /dev/ttyUSB* nem lesz többé. Az újraindítás után minden rendben működik.

A cpp kód normál felhasználó nevében fut, de a felhasználónak joga van használni a soros portot. Így gondolom elrontani is joga van.

A kérdésem: hogyan lehet annyira elrontani a soros port kezelését, hogy tönkrevágja az új eszközök felismerését, és mit lehet ilyenkor kezdeni az újraindításon kívül az USB-vel, hogy újra működjön?

  • 509 megtekintés

( azbest | 2022. 12. 28., sze – 13:46 )

nem csak elkezd dugdosás után nőni a sorszáma? 

 /dev/ttyUSB1 2 3 ...

( Zs | 2022. 12. 28., sze – 14:12 )

Bár régi történet, de vagy 15 éve USB kernel driverrel kellet küzdenem. Ha nem használtam az akkor még újnak számító devfs-t, akkor minden ment flottul, ha devfs-t használtam, akkor nem jól működött a driver és a modul eltávolítása kernel pánikot dobott... És akkor még nem volt virtualizáció... Szóval a hiba olyan helyen is lehet, ahol az ember elsőre nem is gondolná.
A témához kapcsolódóan:
- mindenképp reboot kell, vagy az usb modul kivétele/betöltése is megoldja a problémát? (Nem feltétlenül az USB modul, hanem pl. az usb-serial. Egy misét megérhet ennek vizsgálata: az rmmod/modprobe kombó gyorsabb mint a restart.)
- volt olyan eszköz, amely nem szabványos beállításokkal használta a sorosportot. (Még csak nem is USB-s sorosportot.) Kolléga programja jól inicializálta ugyan az eszközt, de ha a program leállt, akkor a sorosport konfigurálása többet nem volt elvégezhető, annak a masinának is kellett a reboot. (Sajnos a serial modul fixen be volt fordítva a kernelbe, így az rmmod serial, modprobe serial nem játszott. Nehezítés: a spéci HW csak az ügyfélnél...)

Köszönöm, ez jó iránynak tűnik. Amikor eltűnik a /dev/ttyUSB0, akkor a dmesg végén megjelenik:

[ 1182.727462] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 1182.727471] xhci_hcd 0000:00:14.0: USBSTS: 0x00000005 HCHalted HSE
[ 1182.727478] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 1182.727497] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 1182.727558] usb 2-3: USB disconnect, device number 2
[ 1182.727856] usb 2-3: failed to send control message: -110
[ 1182.727870] usb 2-3: failed to send control message: -19
[ 1182.727921] usb 2-3: failed to send control message: -19
[ 1182.728198] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 1182.728247] ch341 2-3:1.0: device disconnected

Kipróbáltam, hogy eltávolítom az xhci_hcd és xhci_pci modulokat, majd vissza. Ezután újra megy rendben. Gondolom, elég az egyik, majd még tesztelem. De persze ettől még az okát nem tudom, de legalább gyorsabb, mint a reboot.

A "failed ..." sorok alapján úgy tűnik hogy az arduino-s eszközöd nem ad választ ezekre a "control" üzenetekre. Az USB alrendszer pedig ezt úgy értékeli hogy nem sikerült a küldés. Szerintem az arduino-s eszközöd USB-s kódja hibás vagy hiányos. Vagy nem kezeli jól a hivatkozott control üzeneteket vagy pedig hiányzik az a kódrészlet ami az adott üzenet kezeléséért felel. A kernel modul meg egy idő után törli a nyilvántartásból a használhatatlan eszközt. Bár ott van valami hiba mert a törlés nem teljes és megáll az eszköz felismerés. Ezért nem "veszi észre" ha újracsatlakoztatod.

A "failed ..." sorok alapján úgy tűnik hogy az arduino-s eszközöd nem ad választ ezekre a "control" üzenetekre.

Az már csak okozat, hogy nem tudja elküldeni az eszköz az üzeneteket, előtte látszik ennek az oka:

[ 1182.727462] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
[ 1182.727471] xhci_hcd 0000:00:14.0: USBSTS: 0x00000005 HCHalted HSE
[ 1182.727478] xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead
[ 1182.727497] xhci_hcd 0000:00:14.0: HC died; cleaning up
[ 1182.727558] usb 2-3: USB disconnect, device number 2

Dugj fel egy USB2 HUB -ot, és arra dugd az eszközt.

Ugyan az USB3 -at nem ismerem, de USB2 és USB1 viszonylatban a dolog úgy működött, hogy USB2 kezdett minden eszközzel beszélni és mikor felismerte, hogy az eszköz USB1, ment a handover az USB1 HW -nek. Ha feldugtál egy USB1 -es HUB -ot, akkor avval az USB1 HW beszélgetett, és így meg lehetett úszni a handover a HUB -ra dugott eszközökre.

De simán lehet, hogy ha az xhci driver -t "letiltod", a portok működni fognak USB2 -es portként.

( apal v | 2022. 12. 29., cs – 08:16 )

Nem lehet hogy a c/c++ kód valami gpio-muveleten keresztul tul nagy aramfelvetelt general? Es aztan emiatt leesik az usb illeszto tapfesze es elkezd ilyen brownout-reset jelleg dolgokat csinalni. Tapasztaltam mar en is teljesen hasonlot... Kulon bonusz lehet hogy meg papiron nem is kritikusan nagy az aramfelvetel, de egy vacakabb usb-kabelen es/vagy usb csatlakozon mar akkora feszultseg esik, hogy. 

Szoval elso korben merj ra multimeterrel es/vagy nezd at a programodat ilyen szemmel. 

Most ott tartok, hogy próbálom a kommunikációt tesztelni lépésről lépésre. Egyelőre a cpp programot kihagyva manuálisan küldöm el az adatokat az arduino felé, és konzolon nézem a válaszokat.

Így nincs USB halál.

Tehát szinte biztos, hogy a cpp program ront el valamit. De a gép egy laptop, az arduinoban is benne van az USBTTL konverter, és a kettő csak össze van dugva egy kábellel, így a túlterhelés nem tűnik valószínűnek.

A cpp kód azonban eléggé kezdő szintűnek tűnik. Egyelőre ott még nem látom, mit rontott el az USB kezelésében.

Egyelőre ott tartok, hogy két durva hibát találtam a kódban. Egyet a cpp részben, egyet az arduino kódjában.

Ezt a kettőt kijavítva működik a program. Amennyiben tud kapcsolódni a PC a Commodore-hoz az Arduinon keresztül, úgy a ttyUSB0 eszköz nem tűnik el, stabilan működik a kód. De ha nem tud kapcsolódni, akkor továbbra is kiöli az usb modult. Közben az is kiderült, hogy ilyenkor elég az xhci_pci modult törölni, és újra betölteni.

Az USB halálának konkrét okt még keresem.

Az ilyen "házi" usb drivernél futottam bele egy triviális leakadásba, bár ott mcu - windows volt  a felállás.

A tipikus / kötelezően lekérdezhető string descriptorok:

  • Lang ID
  • Manufacturer
  • Product
  • Serial

Akkor van a baj, ha a MS által kitálált (?) magasabb sorszámú descriptorra érkezik kérés és az nincs kezelve. A megoldás annyi, hogy vizsgálni kell a rendelkezésre álló descriptorok számát. Ha a kért descriptor nagyobb sorszámú, akkor  - a fenti listát kiegészítve - egy pót descriptorra kell irányítani a választ:

  • Unknown

Nekem is volt USB leakadási problémám Linuxon, amikor mikrokontroller USB stacket (device) kezdtem használni, jellemzően akkor, amikor nem lehúztam az eszközt, hanem a géphez csatlakozott állapotában újraprogramoztam.
Ha jól emlékszem, az volt a gondja, hogy nem észlelt a host az adatvonalon "reset-et", és valahogy ennek kapcsán került olyan állapotba, hogy a komplett USB-kezelés megállt.

...azóta nincs ilyen problémám vele...