• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 101 subscribers
  • Views 2947 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM335x MUSB problem with USB audio device connected through a hub controller

Piero Pezzin
Intellectual 315 points

Hello,

I'm working on my custom board and I'm experiencing a strange problem when using a very specific usb chain. If I connect a USB Audio device (code: SiLabs CP2114) directly to a port of the MUSB controller, the device works correctly and I can play audio files properly.

When I connect the same audio device to a port of a USB hub (code: SMSC USB2512BI) connected to a port of the MUSB controller, I can't play audio files correctly (I get crackling noise and distorsion). If I connect the same hub to different USB host controllers (on different hardware platform), the USB Audio device works correctly.

Working on this issue, I've found a quick workaround: if I force full speed connection between the MUSB controller and the hub (removing the MUSB_POWER_HSENAB option in the musb_start() function of the drivers/usb/musb/musb_core.c file), I get the USB Audio device working

So I suspect there is something not working as expected in the

MUSB host controller + USB Hub + USB audio

chain when the connection between the MUSB host controller and the USB Hub is configured for High Speed. After further investigation (increasing debug level with the /proc/driver/musb_hdrc.x parameter and enabling usbmon) I've seen some differences in the USB transactions in the two cases:

Case 1: MUSB host controller <--> Full Speed <--> USB Hub

In this case, using usbmon I can see Isochronous USB transfers in both directions (marked as Zi and Zo) in the attached usb-fs-hub.mon.out file.

Case 2: MUSB host controller <--> High Speed <--> USB Hub

In this case, using usbmon I can see Isochronous USB transfers only in one direction (Zo) in the attached usb-hs-hub.mon.out file.

This behavior is confirmed by the USB subsystem log messages: in fact, comparing the attached usb-hs-hub-syslog.log and usb-fs-hub-syslog.log, I see that only in the full speed case I receive interrupts from the USB device.

Since I'm not a USB expert, I hope that someone can give me some hints on how to solve this issue or, at least, on how to proceed with the analysis.


Thanks for your help and best regards.

Piero Pezzin

P.S. I've run the same tests both on the AM335x and the DM814x processors, obtaining the same results (as expected, since the MUSB controller is the same). Moreover, I've also tried with the Beaglebone, running the 3.13 kernel to search for some driver upgrades that can help me, but again with no luck.

usb-logs.zip
  • 0
    TI__Guru**** 393215 points
    Hi Piero,
    I will escalate this to the factory team.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 315 points

    Dear Bisev,


    thanks for your help.

    I've downloaded the AM37X Errata document (http://www.ti.com/lit/er/sprz318e/sprz318e.pdf) and I've read the advisories for to the USB subsystem, but honestly I can't see how they relate to the problem I've reported. Moreover, the USB subsystem of the AM37x has some differences if compared to the AM335x and DM814x (for example, the AM37x hasn't the integrated PHYs).

    Can you kindly give me some suggestions? 

    Thanks again and best regards.

    Piero Pezzin

  • 0 in reply to Piero Pezzin
    TI__Mastermind 27720 points

    Piero,

    I apologize for the confusion here. I asked Biser to respond with the information you received but accidentally linked your thread instead of the thread it was intended for.

    Now back to your issue: have you observed this behavior on hubs other than the SMSC?

  • 0 in reply to -DK-
    Intellectual 315 points

    Dear DK,


    I've tried with a couple of consumer hubs (both with and without external power), connected to the AM335x and the DM814x, and they worked as expected. Moreover, the SMSC hub work properly when attached to different hardware (i.e. a PC).


    Thanks for your help and best regards.

    Piero

  • 0 in reply to Piero Pezzin
    TI__Mastermind 27720 points

    Piero,

    This issue hasn't been reported before for our device. Have you tried engaging with SMSC for their opinion on the matter? As you pointed out, this issue appears to be restricted to this particular hub.

  • 0 in reply to -DK-
    Intellectual 315 points

    Dear DK,

    I've contacted the SMSC/Microchip support, and they think the problem is related to how the USB host stack manages the split transactions that are routed to the hub.

    Could you please check this with your USB experts? Have you any other suggestions? Any help will be greatly appreciated, since our customer is really pushing for a solution.

    Thanks for your help and best regards.


    Piero

  • 0 in reply to Piero Pezzin
    TI__Mastermind 27720 points

    Do you have any further details from SMSC? "how the USB host stack manages split transactions" is a very generic response and doesn't offer enough information to move forward. Since we don't have access to this SMSC hub, at minimum I would suggest you forward passing and failing USB protocol analyzer traces for review.

  • 0 in reply to -DK-
    Intellectual 315 points

    Dear DK,

    please find below the full answer from SMSC/Microchip:

    The physical layer of USB2.0 host controller, most likely will have ehci and uhci (ehci handles High speed USB protocol and uhci handles the FS/LS). I believe the audio device is a full speed device, then:


    1) Normal case, the host must handle the FS device using special split transaction that will be routed to TT (transaction translator) inside the USB2512Bi hub.  These transactions will generate FS packets downstream towards the audio device
    2) Failing case, the host failed to produce split transactions.  Thus the host now might using high speed (HS) packets  ...no HS is connected downstream. Thus, no response, or the timeout will occurs or unexpected events occur.

    When the audio connect directly to the host, it is directly and transparently communicate with uhci controller bypassing ehci as full speed device.  In other case when USB2512Bi (a HS hub), host will connect the hub via ehci controller and must communicate with FS device connected at hub's downstream port with split transaction. That is why when you configured the hub as full speed hub, which will not needed TT, the audio device works fine.

    I believe this is a case of (TI) host driver stack issue.

    I hope this helps.

    Best Regards,

    Piero