• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 4401 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3352: "device descriptor read/64, error -110" after usb device reset.

Ben Edgar
Prodigy 150 points
Part Number: AM3352


Tool/software: Linux

Hello,

I am using a usb device that presents itself to the system as 5 virtual com ports, ttyACM0 through ttyACM4. If the device resets the virtual com ports will go down however when they are made available to the system again I am getting the folllowing dmesg output and the ttyACM ports are never visible.

[  556.991762] usb 2-1.4.1: new full-speed USB device number 10 using musb-hdrc
[  572.463756] usb 2-1.4.1: device descriptor read/64, error -110
[  588.079757] usb 2-1.4.1: device descriptor read/64, error -110
[  588.271760] usb 2-1.4.1: new full-speed USB device number 11 using musb-hdrc
[  603.695760] usb 2-1.4.1: device descriptor read/64, error -110

This issue can be resolved by either restarting the board, or restarting both the modules musb_dsps and musb_hdrc. 

For reference here is the dmesg output when the device connects successfully: 

[18035.171694] usb 2-1.2.1: new full-speed USB device number 37 using musb-hdrc
[18035.299241] usb 2-1.2.1: New USB device found, idVendor=03eb, idProduct=2426
[18035.306444] usb 2-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[18035.315900] usb 2-1.2.1: Product: CDC Virtual Com
[18035.320730] usb 2-1.2.1: Manufacturer: ATMEL ASF
[18035.333682] cdc_acm 2-1.2.1:1.0: ttyACM0: USB ACM device
[18035.348398] cdc_acm 2-1.2.1:1.2: ttyACM1: USB ACM device
[18035.365076] cdc_acm 2-1.2.1:1.4: ttyACM2: USB ACM device
[18035.381071] cdc_acm 2-1.2.1:1.6: ttyACM3: USB ACM device
[18035.396245] cdc_acm 2-1.2.1:1.8: ttyACM4: USB ACM device

Could you please advise on how to remedy this issue?

Thanks,

Ben

  • 0
    TI__Guru**** 393215 points
    Hi,

    Please post which Linux version you use.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 150 points
    Debian 8, tried kernels 3.12/4.4/4.14 all have the same error number.
  • 0 in reply to Ben Edgar
    TI__Guru**** 173921 points
    Hi Ben,

    Here more questions to help me understand your use case.

    - Are those 3.12/4.4/4.14 kernel from TI Processor SDK or community kernel from kernel.org?
    - Is this happening on any of the AM335x EVMs or your custom board? Which USB port is it?
    - Please provide the USB portion of the schematics if this is on your custom board.
    - You mentioned the issue happens after 'the device resets the virtual com ports'? Do you mean the USB device resets itself? or by USB bus reset?
  • 0 in reply to Bin Liu
    Prodigy 150 points

    I'm using this board from Olimex: www.olimex.com/.../open-source-hardware

    3.12 and 4.4 are built from the TI Linux git repo, the 4.14 kernel is from the beaglebone Git repo.

    The 3.12 and 4.4 are patched to build the Olimex DTB files for uboot, the beaglebone has one in its repo by default.

    The device itself will reset causing the virtual com ports to drop but they are then made available again as soon as the device restarts.

    It is plugged into the usb type A ports at the front of the board. These are USB1 in the DTB file etc.

    Thanks,

    Ben

  • 0 in reply to Ben Edgar
    TI__Guru**** 173921 points
    Hi Ben,

    I quickly checked the Olimex board schematics, the board designs USB0 in otg mode and USB1 in host mode. I assume you use the USB1 host port with your USB virtual com device, because the schematics show a USB hub on the USB1 port which seems match the kernel enumeration log you posted above.

    The first mistake I found in the schematics is that R21 resistance is too high (10k), it should be less than 100ohm, typically 0ohm. Since this is not a TI reference board, I will stop reviewing it from here.

    Please try to replicate the issue with any TI supported platforms, such as Beaglebone Black or AM335x GP EVM.
  • 0 in reply to Bin Liu
    TI__Guru**** 173921 points

    For the record, Ben confirmed a community kernel patch solves the issue. detail is here: e2e.ti.com/.../2941708

    The root cause is that musb driver doesn't handle hub TT clearing buffer.