Actions
Forum Thread Details
  • State Not Answered
  • Replies 21 replies
  • Subscribers 299 subscribers
  • Views 3295 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.

Parents
  • 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 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

  • 0 in reply to craigjavid

    I'm not sure how the USB3320 is doing it internally. I do know that another customer was trying to force DEVICE mode, so they removed all the caps on the Carrier as well. That ended up causing problems. We theorized that it was noisy power on VBUS since even when you are in DEVICE mode, you still need between 1uF and 10uF on VBUS. They populated a cap, and their board started working again.

     

    This case is different since you are trying to use HOST mode, which is what we use by default. The only other difference is that USB ID pin. We do not populate our pull-down on our Carrier, but you do. That is another experiment you could try -- remove your ID resistor. In theory, that shouldn't matter, but it is a difference.

     

    Bryan

  • 0 in reply to craigjavid

    Hi Bryan:

     

    I reviewed my PCB design and I see that I did not include a 100nF VBUS capacitor as was included in the previous revision SOM.  It is hard for me to believe that makes the difference as my two VBUS capacitors are very close to the USB pin 1 connector and there is an additional 2.2 uF right next to the power switch on my board.  I also noticed that my 5V bus trace widths only support 1.2A with a 10C rise.  Maybe I will beef up in the next revision but I doubt that is "the" issue since the port works fine with the older PicoZed SOM.

     

    Craig

  • 0 in reply to bhfletcher

    Hi Bryan:

     

    Yes, we tried floating the ID pin with no luck.

     

    Craig

  • 0 in reply to bhfletcher

    Hi Bryan:

     

    There is a separate shield net and that runs around the periphery of the card and connects via nine mounting holes to the aluminum chassis.   The shield net does tie to the main DGND planes through a 2.2nF 2.2kV capacitor on the card.

     

    Craig

  • 0 in reply to craigjavid

    Hi Bryan:

     

    Just to clarify - The shielding approach is identical to another product and we have used numerous PicoZed SOMs with success.  Also,  the baseboard in question does work correctly with the older PicoZed so I am nit sure this is a shielding issue?

     

    Thanks,

     

    Craig

  • 0 in reply to craigjavid

    That's definitely not my area of expertise, but I remember some heated discussions amongst our PCB people. In the end, the Avnet carrier put a 0-ohm resistor between the PCB ground and the shield on our Carrier, and I know that works with the newest SOMs. I thought I read some stuff online that seemed to indicate additional capacitance helped solve issues that people traced back to their connector shield (although I can't find it now). It was just one more thing trying to understand if/why the extra capacitance on the Rev C SOM is the difference. I see on Microchip's USB3320 Eval example that they connect Shield to Ground through a 0.1uF capacitor.

     

    If you can add those caps back onto Rev E, that would be a significant clue. However, like I said, the Avnet Carrier works successfully in Host mode without the extra caps on the Rev E SOM, so I think there is also some other difference between the Avnet Carrier and your carrier.

     

    Bryan

  • 0 in reply to bhfletcher

    Hi Bryan:

     

    No doubt that there are some differences and we just repeated more tests and are getting sporadic results where the newer card is now working.  So maybe we do have some kind of noise issue ?  The older card that we believed was the one that worked is also a rev E card and has no VBUS capacitors so we may have confused ourselves in debug with either changes in FW/kernel/device tree or we have an intermittent hardware issue.

     

    Will get back to posting when we sort more out.

     

    Craig

Reply
  • 0 in reply to bhfletcher

    Hi Bryan:

     

    No doubt that there are some differences and we just repeated more tests and are getting sporadic results where the newer card is now working.  So maybe we do have some kind of noise issue ?  The older card that we believed was the one that worked is also a rev E card and has no VBUS capacitors so we may have confused ourselves in debug with either changes in FW/kernel/device tree or we have an intermittent hardware issue.

     

    Will get back to posting when we sort more out.

     

    Craig

Children
  • 0 in reply to craigjavid

    Hi Craig,

     

    I was able to confirm that the two boards you have should be completely identical.

     

    --Dan

  • 0 in reply to drozwood90

    Hi Dan and Bryan:

     

    Yes, we came to a similar conclusion.

     

    It looks like Ed and I got tripped up in our debug and ended up testing the older date code PicoZed with a different SD card and image.  After more analysis, Ed found the following:

     

    "The working SD card has CONFIG_USB_PHY and CONFIG_NOP_USB_XCEIV enabled, while the broken SD card does not. That is a smoking gun. I am going to start a complete build with those two CONFIG options enabled. I am hopeful that it will solve the problem."

     

    I apologize for wasting your time but greatly appreciate your support.  Sometimes, in the heat of the battle debug mistakes get made that lead one down the wrong path.  I am hopeful that new build will fix the problem and we will have no issue with the Rev E SOMs.

     

    I won't mark this post closed until we know we have a new kernel build that supports USB host mode with all SOMs.

     

    Thank you both for your help and patience,

     

    Craig

  • 0 in reply to craigjavid

    Craig,

     

    No problem.  I hope that resolves it!  Also, don't consider this a waste of time.  Sometimes the best thing to do is slow down to go faster.  Having a sounding wall certainly makes that happen!

    Besides, if it really is as easy as a software fix, I'm sure much preferred vs. modding resistors or caps!

     

    --Dan