Actions
Forum Thread Details
  • State Not Answered
  • Replies 21 replies
  • Subscribers 172 subscribers
  • Views 1945 views
  • Users 0 members are here
Related

PicoZed USB host mode not working

ejubenville

I working with a custom board built with a PicoZed 7030 module.  The USB host circuitry was modeled after the PicoZed carrier card.  USB memory gadgets work, but no attached slave devices work (no hubs, no mice, etc.)

 

When the USB driver tries to enumerate the devices, it reports the following errors repeatedly, with ascending device numbers until it gives up.

usb 1-1: new full-speed USB device number 2 using ci_hdrc
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/all, error -71

Is this a hardware design issue or a driver configuration issue?  We believe we have the USB port configured properly to force "host" mode as opposed to slave or OTG modes.

 

I'm using the Xilinx Linux kernel v2018.3, built identically to a different custom board that used the same PicoZed SOM and was successful at using host mode.  The difference is that the previous design had an onboard hub circuit connected to the PicoZed, and the outside world was connected to the hub.

  • 0

    Hi there,

     

    Can you try a powered hub?  The PicoZed cannot supply a lot of power over the USB.  That would explain the low power flash drives working, but something like a mouse not.

     

    --Dan

  • 0 in reply to drozwood90

    I am working with Ed on the same new hardware platform.  As he stated we are using a custom carrier card with the USB port implemented using the Carrier Card reference design as shown below:

     

    image

     

    The one difference is that we use a type A connector and we force the ID pin low for host mode.  Since the last post from Ed we have found that if we replace our newest PoicoZed SOM [AES-Z7PZ-7Z030-SOM-I-G Rev E)  with what I believe is a date code of 20 20 with an older identical part number SOM with a date code of 22 18, the host port works and can read a memory stick or loop-back to a console USB port.  This difference in behavior is seen with the same kernel/FW build

     

    When the newer SOM is installed we see no port power and the CPEN output from the USB3320C transceiver is low. .  It is as if the detection of the installed device is not happening and this no power is enable to the port.

     

    Are there any known issues with recent AES-Z7PZ-7Z030-SOM-I-G Rev E SOMs that could explain this apparent anomaly?

     

    Thanks,

     

    Craig

  • 0 in reply to craigjavid

    Hi Craig,

     

    There is a sticker on the back of the board.  This will indicate the different revisions of the SOMs.  Can you take a look at that and let me know?

    It should say something like "BD-Z7PZP-7Z030-G REVC04"

    If your sticker does not match that format, then it is likely the new 4 line format, which is a sticker that has to be decoded.

    • Product code
    • CM Code
    • Batch Serial Number
    • YYww (2 digit year and calendar week code)

     

    From this, I think we can start to isolate any board changes that might be there.

     

    I'd also like to note that all the errata is posted here:

    PicoZed

     

    If that link does not take you directly to the Technical Documents, you can click the same named tab.  Then at the bottom of the page, all of the errata is listed.  Take a look through.  There are good summary documents of product changes on that page.

     

    --Dan

  • 0 in reply to drozwood90

    Hi Dan:

     

    Thanks for quick response.  We are a bit stumped by what we are seeing so appreciate the help.  The new cards must have the new for,at so I have taken a picture as shown below.

     

    I read some other Xilinx posts that seem to elude to similar problems with USB PHY transceivers not providing VBUS and there was an indication that the PHY chip (USB3320C)  was being held in a reset state and never able to detect a USB device insertion so that power could be applied.  I am not confident that s the correct sequencing so please clarify.

     

    image

     

    Best,

     

    Craig

  • 0 in reply to craigjavid

    Craig,

     

    No problem!

     

    Can you post a picture of each?

    A working one and the one that is having issues?

     

    Thanks!

     

    --Dan

  • 0 in reply to drozwood90

    Hi Dan:

     

    Below is a picture of an older PicoZed SOM that seems to be working and supports USB host port operation in the same platform/firmware that the newer SOM pictured in my last reply does not.  The date code is 18 38

     

    By the way, I mistakenly stated the date code of the newer SOM that as an issue with USB was 20 20 but it is actually 20 24.  We have tried a second SOM with a date code of 20 24 and USB does not operate as expected either.

     

    image

  • 0 in reply to craigjavid

    One change we made between Rev C and Rev E was the depopulation of capacitors C190, C191, and C192. You can see a description for this in Item 3.9 of the Rev C Errata. I see the correct Host-setting caps on your schematic above, so I wouldn't think this should be a problem. However, it may be worth an experiment to see if having those caps installed makes a difference. That's the only thing that I've been able to think of so far related to USB that changed between the two revisions.

    Bryan

  • 0 in reply to bhfletcher

    Hi Bryan:

     

    Ok, the forced host mode option is worth pursuing but I might try adding the VBUS capacitors on the new revision PicoZed SOM just to see what happens.   I don't quite understand how the USB arbitrates external power control?  Does the transceiver recognize a USB device by using differential resistance changes to detect the insertion and the operating speed and then elect to turn on external power by enabling CPEN?  If not, how is the detection and power control done?

     

    Could added inductance in the trace wiring between the SOM USB_VBUS_OTG and the VBUS capacitors on my baseboard/carrier card make a difference?

     

    Thanks for the support,

     

    Craig