Armadilloフォーラム

USBシリアル通信のデバイス(CH340)を複数接続した際、通信開始時に「failed to submit interrupt urb: -28」エラー

hidekichi

2023年7月21日 11時32分

お世話になります。
現在Armadillo-640にUSBハブ経由でCH340を持つデバイス(ArduinoNano互換機)を接続し、その先に複数のセンサーを接続してセンサーデータを収集しようとしています。

環境:$ uname -a
Linux SWRWEI01 4.4.0-170-generic #199-Ubuntu SMP Thu Nov 14 01:45:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

カーネルモジュールでCH340を有効化しており、OSからはデバイスはすべて正常に認識されています。
(/dev/ttyUSB[0-9] でデバイスパスが見えていることと、dmesgでエラーなく認識されていることを確認)

自作アプリケーションから接続されたデバイスに対して通信を行おうとしたところ、
一部のデバイスでttyUSB[0-9]に対して open failed が返ってきて、
dmesgでは「ch341-uart ttyUSB7: ch341_open - failed to submit interrupt urb: -28」が出力されます。

同じ環境下で、問題なく通信できているデバイスがあることと、
USBハブ配下を別のPCに接続して同じプログラムを動かした際には、上記のようなエラーが返ってきていないことから、
USBハブ配下のハードウェア的な問題では無いと考えています。

このような状況なのですが、
エラーの理由や対策について、どの様に調査対応するべきか、アドバイスいただけないでしょうか?

お手数をおかけしますが、何卒よろしくおねがいします。

ファイル ファイルの説明
dmesg出力.png
デバイス認識状況とuname出力.png
コメント

溝渕です。

> エラーの理由や対策について、どの様に調査対応するべきか、アドバイスいただけないでしょうか?

CH340のUSB descriptorを確認してもらえますか?

というのも、i.MX6ULLのUSB coreの最大endpoint数が8個であり、これに引掛っているのではないかと推測しています。

> Up to 8 bidirectional endpoints

[armadillo]# lsusb

で、BUS/DEVICEを確認して、

[armadillo]# lsusb -v -s[BUS]:[DEVICE]

のようにdescriptorを表示できます。

i.MX6ULLのUSB coreのendpoint数が最大8個。。。というのは、Armadillo-640のUSB配下に接続できるデバイス数(USBホスト含む)が、最大8台ということでしょうか?

取り急ぎ、lsusbとCH340デバイスのdescriptorを出力させたコンソール出力を添付します。
ご確認いただけますと幸いです。

ファイル ファイルの説明
ttg@SWRWEI12~$ lsusb.txt

溝渕です。

> i.MX6ULLのUSB coreのendpoint数が最大8個。。。というのは、Armadillo-640のUSB配下に接続できるデバイス数(USBホスト含む)が、最大8台ということでしょうか?

いえ、違います。9個以上のendpointを作るusb deviceが使えないという意味です。

今回はそもそもHub経由ですし、各deviceは、

bEndpointAddress 0x82 EP 2 IN
bEndpointAddress 0x02 EP 2 OUT
bEndpointAddress 0x81 EP 1 IN

と3つなので関係ありませんね。すみません。

接続構成を変えつつ問題の切り分けを行う事は可能ですか?

例えば、

- USB Hostに直接CH340を接続した場合
- USB Hub経由で1個だけCH340を接続した場合
- USB Hub経由で2個だけCH340を接続した場合
- USB Hub経由でn個だけCH340を接続した場合
- 異なるUSB Hubを利用した場合

など、どのような構成で問題が発生するかの最小構成を調べる事は可能ですか?

例えば、そもそもCH340が利用できない場合は、mainlineのkernelに含まれている"drivers/usb/serial/ch341.c"から、bug fixのcommitを探す等が考えられます。

溝渕です。

すでに本件には関係無い事はわかっていますが、情報に誤りがあったので訂正させてください。

i.MX6ULLの最大endpoint数は8個とお伝えしましたが、

https://www.nxp.com/docs/en/data-sheet/IMX6ULLCEC.pdf
> Support eight Transmit (TX) and eight Receive (Rx) endpoints, including endpoint 0
と、Tx/Rxそれぞれに8個持つことができます。

実際に合計9個のendpointを持つデバイスをArmadillo-640に接続してみましたが、正しく認識/利用することができました。

ありがとうございます。
接続構成を変えての切り分けは後日実施させていただきます。(物理的に離れたところに居るので、今日対応できず。。。)
ちなみに、CH340とは問題なく通信できています(10台接続して、8台は通信できてる)。

これまでに試したところでいうと、
- USB Hostに直接CH340を接続した場合 →問題なし
- USB Hub経由で1個だけCH340を接続した場合 →問題なし
- USB Hub経由でn個だけCH340を接続した場合 →上記の通り接続エラーする個体が発生する
という状況です。
続報お待ちください。

溝渕です。

合わせて以下も確認してみてください。

> ちなみに、CH340とは問題なく通信できています(10台接続して、8台は通信できてる)。

- その8台は、最初に接続した8台ですが、接続順は関係ありませんか?
- 8台接続した状態で起動すると、必ず全数通信可能ですか?
- 8台接続した状態で起動し、起動後に1台接続するとコンソールにどのようなメッセージが出力されますか?

ご返信遅くなり申し訳ございません。
その後色々試していて、わかったこともあるのですが、解決はできておりませんでした。
取り急ぎ、頂いたご質問への回答は以下のとおりです。

- USB Hostに直接CH340を接続した場合 →問題なし
- USB Hub経由で1個だけCH340を接続した場合 →問題なし
- USB Hub経由で2個だけCH340を接続した場合 →上記と同じく、接続エラーが発生する個体がある
- USB Hub経由でn個だけCH340を接続した場合 →上記と同じく、接続エラーが発生する個体がある
- 異なるUSB Hubを利用した場合 →上記と同じく、接続エラーが発生する個体がある

> ちなみに、CH340とは問題なく通信できています(10台接続して、8台は通信できてる)。
- その8台は、最初に接続した8台ですが、接続順は関係ありませんか? →ttyUSB0でも発生しているのと、抜き差しして再認識した後にも同現象が発生しているので、接続順ではないと考えています。

- 8台接続した状態で起動すると、必ず全数通信可能ですか? →いいえ。8台は1事象でしかありませんでした。台数が少ない(3台)でも同現象が発生することがありました。

- 8台接続した状態で起動し、起動後に1台接続するとコンソールにどのようなメッセージが出力されますか?
```
[ 348.673350] ch341-uart ttyUSB8: ch341-uart converter now disconnected from ttyUSB8
[ 348.681672] ch341 2-1.2.3:1.0: device disconnected
[ 354.848820] usb 2-1.2.3: new full-speed USB device number 16 using ci_hdrc
[ 355.005171] ch341 2-1.2.3:1.0: ch341-uart converter detected
[ 355.018411] usb 2-1.2.3: ch341-uart converter now attached to ttyUSB8
```
こんな感じで、問題なく認識されているように見えるのです。。。

溝渕です。

> - USB Hostに直接CH340を接続した場合 →問題なし
> - USB Hub経由で1個だけCH340を接続した場合 →問題なし
> - USB Hub経由で2個だけCH340を接続した場合 →上記と同じく、接続エラーが発生する個体がある
> - USB Hub経由でn個だけCH340を接続した場合 →上記と同じく、接続エラーが発生する個体がある
> - 異なるUSB Hubを利用した場合 →上記と同じく、接続エラーが発生する個体がある

上記結果を元に考察するとCH340の個体不良のように思えるのですが、特定の個体で接続エラーが発生していませんか?

お世話になっております。
個体不良の可能性、ということですが、
ホストPCをArmadillo以外のLinuxPC(x86系)に変えて、同じプログラムを動作させている場合は、上記のような接続エラーは発生してません。
なので、個体不良ではないと考えています。
Armadilloとの組み合わせにおいてのみ発現する個体不良(というか組み合わせの相性?)だと思えば、そういうことなのかもしれないですが。。。。

溝渕です。

> なので、個体不良ではないと考えています。

了解です。

> Armadilloとの組み合わせにおいてのみ発現する個体不良(というか組み合わせの相性?)だと思えば、そういうことなのかもしれないですが。。。。

私が現状を良く把握できていないので、もう少し教えてください。

具体的には、ArmadilloとCH340の間に動作する/しないの依存関係があるか、また、(組み合わせに応じて)挙動が安定する(接続できる組み合わせはいつも接続でき、接続できない組み合わせはいつも接続できない)かどうかを教えて欲しいです。

Armadilloが2台あり、それぞれ"A","B"とします。また、CH340が4台あり、それぞれ"a","b","c","d"とします。

1. USB Hostに直接CH340を接続した場合に問題が発生しない件について
これは、"A","B"それぞれに、"a","b","c","d"を接続する組み合わせ(計8通り)で問題が発生しないという理解で当っていますか?

2. USB Hub経由で1個だけCH340を接続した場合に問題が発生しない件について
"1."同様に全ての組み合わせで問題が発生しませんか?

3. USB Hub経由で2個だけCH340を接続した場合に問題が発生する件について
A -- [USB Hub] -- "a"
'- "b"
という接続構成で、"a"が利用できない状態であったと仮定します。この状態だと、毎回"a"が利用できませんか?

また、以下の構成だとどうなりますか?
A -- [USB Hub] -- "c"
'- "d"
B -- [USB Hub] -- "a"
'- "b"

お世話になってます。返信遅くなりました。
Armadilloを2台準備し、いずれも改めて確認し直しました。

> Armadilloが2台あり、それぞれ"A","B"とします。また、CH340が4台あり、それぞれ"a","b","c","d"とします。
> 1. USB Hostに直接CH340を接続した場合に問題が発生しない件について
> これは、"A","B"それぞれに、"a","b","c","d"を接続する組み合わせ(計8通り)で問題が発生しないという理解で当っていますか?

はい。8通りいずれも問題発生しませんでした。

> 2. USB Hub経由で1個だけCH340を接続した場合に問題が発生しない件について
> "1."同様に全ての組み合わせで問題が発生しませんか?

はい。USBハブ経由になっても問題発生しませんでした。

> 3. USB Hub経由で2個だけCH340を接続した場合に問題が発生する件について
> A -- [USB Hub] -- "a"
> '- "b"
> という接続構成で、"a"が利用できない状態であったと仮定します。この状態だと、毎回"a"が利用できませんか?

いいえ。毎回決まったデバイスで問題が発生しているわけではありません。
今回の実験では、問題の発生させやすさで、Aに対してabcdのデバイスを接続した状態で確認しました。
5回実施し、4回はadのデバイスでエラー発生していましたが、5回目はabのデバイスで発生しました。

> また、以下の構成だとどうなりますか?
> A -- [USB Hub] -- "c"
> '- "d"
> B -- [USB Hub] -- "a"
> '- "b"

Aにabを接続してエラーが起こる状態になったあと、Bにabを接続した際に、
接続しただけでコンソールに
 [ 3270.501424] ch341-uart ttyUSB0: ch341_open - failed to submit interrupt urb: -28
 [ 3270.549303] ch341-uart ttyUSB3: ch341_open - failed to submit interrupt urb: -28
のメッセージが流れ、これまでできていたscreenコマンドを利用したデバイスオープンもできなくなりました。

これらのデバイスは、別端末のLinuxPC(Ubuntu 16.04)とWindows端末にそれぞれ接続し、ターミナルで開くことで問題なく動作することが確認できました。
その後、Bに接続し直しscreenコマンドから接続確認したところ、
なぜか元のUSBハブのポートで接続させた時には、
 Cannot open line '/dev/ttyUSB0' for R/W: a?\a??/a?oa??a?¨a?ca??a?§a??
 Sorry, could not find a PTY or TTY.
というメッセージを表示し接続できなくなっていました。

同じデバイスをBのUSBハブの別のポートに接続したところ、接続できるようになり、その後元のポートに接続し直しても問題なく動作しました。

以上から、Armadilloとデバイスの組み合わせの問題ではない、と考えます。

一連の実験をしている時に気になったのが、デバイスのリセット動作です。
接続しているデバイスはArduino Nanoの互換機で、シリアル接続する際にリセットする挙動が標準動作と認識しています。
Armadillo でscreenで接続した場合、Arduino Nano の初期処理で出力されるメッセージが出てこないことがありました。
これは、他PCで利用していた場合には起こっていない症状です。
ArduinoNanoがシリアル通信時にリセット動作するのは、DTRがLOWに落ちる必要があるとのことなので、Armadilloのハードウェアフロー制御が何かしら影響していないか気になっています。
知見あれば教えて下さい。

ファイル ファイルの説明
スクリーンショット 2023-09-13 221918.png

溝渕です。

ご確認ありがとうございます。また、返信が遅くなり申し訳ございません。

> Aにabを接続してエラーが起こる状態になったあと、Bにabを接続した際に、
> 接続しただけでコンソールに
>  [ 3270.501424] ch341-uart ttyUSB0: ch341_open - failed to submit interrupt urb: -28
>  [ 3270.549303] ch341-uart ttyUSB3: ch341_open - failed to submit interrupt urb: -28
> のメッセージが流れ、これまでできていたscreenコマンドを利用したデバイスオープンもできなくなりました。
:(省略)
> 一連の実験をしている時に気になったのが、デバイスのリセット動作です。
> 接続しているデバイスはArduino Nanoの互換機で、シリアル接続する際にリセットする挙動が標準動作と認識しています。
> Armadillo でscreenで接続した場合、Arduino Nano の初期処理で出力されるメッセージが出てこないことがありました。
> これは、他PCで利用していた場合には起こっていない症状です。
> ArduinoNanoがシリアル通信時にリセット動作するのは、DTRがLOWに落ちる必要があるとのことなので、Armadilloのハードウェアフロー制御が何かしら影響していないか気になっています。
> 知見あれば教えて下さい。

以上より、CH340はArmadillo(のUSBコネクタ)から抜いても電源が落ちず、状態が保持されるのですね。

リセットにはDTRの状態変化が必要との事で、デバイスファイルのopen時に、DTRをトグルするようにしたパッチを作ってみました。
# こちらに同等のデバイスが無かったので動作は未確認です。

DTRによるリセットの有無が、今回の現象に関係しているかご確認いただけますか?

ファイル ファイルの説明
linux-4.14-at60_ch341-toggle-dtr.patch

パッチのご提案ありがとうございます!
試して改めてご報告させていただきます。

溝渕様

ご返信遅くなり申し訳ございません。
頂いたパッチを適用してuImageとarmadillo-640.dtbを作り直して動作確認を行いました。

結果改善せずでした。

ドライバをアップデートしたあとのdmesgの出力では
> current DTR: clear
が各デバイスに対して行われており、
ドライバに修正を加えた内容は正しく反映されていると考えられます。

残念ながら、結果的に下記メッセージをsyslogに出力しており、改善しませんでした。。。。

> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.127343] ch341-uart ttyUSB0: current DTR: clear
> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.138275] ch341-uart ttyUSB7: current DTR: clear
> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.157202] ch341-uart ttyUSB9: current DTR: clear
> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.167967] ch341-uart ttyUSB5: current DTR: clear
> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.179098] ch341-uart ttyUSB2: current DTR: clear
> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.189781] ch341-uart ttyUSB3: current DTR: clear
> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.205187] ch341-uart ttyUSB4: current DTR: clear
> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.215638] ch341-uart ttyUSB1: current DTR: clear
> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.225318] ch341-uart ttyUSB8: current DTR: clear
> Oct 6 12:43:26 SWRWEI20 kernel: [ 21.235810] ch341-uart ttyUSB6: current DTR: clear
> Oct 6 12:43:27 SWRWEI20 kernel: [ 21.804234] ch341-uart ttyUSB0: ch341_open - failed to submit interrupt urb: -28
> Oct 6 12:43:27 SWRWEI20 kernel: [ 21.816628] ch341-uart ttyUSB1: ch341_open - failed to submit interrupt urb: -28
> Oct 6 12:43:27 SWRWEI20 kernel: [ 21.835143] ch341-uart ttyUSB5: ch341_open - failed to submit interrupt urb: -28
> Oct 6 12:43:27 SWRWEI20 kernel: [ 21.846710] ch341-uart ttyUSB8: ch341_open - failed to submit interrupt urb: -28
> Oct 6 12:43:27 SWRWEI20 root: /dev/ttyUSB006: Input/output error
> Oct 6 12:43:27 SWRWEI20 root: /dev/ttyUSB005: Input/output error
> Oct 6 12:43:27 SWRWEI20 root: /dev/ttyUSB001: Input/output error
> Oct 6 12:43:27 SWRWEI20 root: /dev/ttyUSB000: Input/output error

ファイル ファイルの説明
スクリーンショット 2023-10-06 215842.png

溝渕です。

Linuxカーネルコンフィギュレーションで、
CONFIG_USB_EHCI_TT_NEWSCHED
を有効にすると解決できると思います。

この変更は、次回アップデート時(linux-4.14-at63)に取り込みたいと思います。