Actions
Forum Thread Details
  • State Verified Answer
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 288 subscribers
  • Views 995 views
  • Users 0 members are here
Related

UZEV USB as host and custom carrier card, problem with USB_OTG_CPEN held low

buckd

Hi,

 

We are designing a custom carrier card for the UZEV and we have a problem with the USB interface with the USB_OTG_CPEN pin always held low. We want to use it as a host and we have the following setup:

 

1. Copied the hardware design from the Carrier Card in the starter kit and have this set-up

   * JP21: pins 1-2

   * JP12: ON

   * JP22: pins 2-3 (accidentally grounded our our board, see below)

   * JP23: pins 1-2

2. Our only change was to ground pin2 of JP22 (a mistake, see below)

   * To see if it mattered, we grounded pin 2 on the UZEV-CC, power cycled, and it still worked fine as a USB host.

3. Our Linux/bitstream boot from an SD card and works on both the UZEV-CC and our custom carrier card. It loads USB on the UZEV-CC which suggested to us a hardware problem.

 

In probing every aspect of the circuit we learned that USB_OTG_CPEN was always low. I put a 1.8K pullup on it to 3.3V to see if it would change, but it is actively held low.

 

What would cause USB_OTG_CPEN to be held low like this?

  • 0

    I forgot to add that we verified possible shorts and grounding and all is good. We also probed the USB0_RST_N pin to verify the chip isn't accidentally held in reset and it is properly held high.

  • 0 in reply to buckd

    Hi again,

     

    It turns out the solution was to drive the GTR_REFCLK2 input (B10/11) of the JX3 connector with an oscillator/balun - we had removed that thinking it wasn't needed because we didn't need USB 3.0. Turns out it is still needed for USB 2.0-only functionality - we think because the Linux kernel module would just fail to find the usb 3.0 interface for some reason.

  • 0 in reply to buckd

    Hi there,

     

    It seems you have a board to test this out, if so, and I've not tried this myself, but if you were to disable the USB3.0 capability in the PS configuration, hardware-wise there would be no requirement to put the clock into the GTR REFCLK.  I am checking to see if I can get a straight answer on this, but if it is easy, you might want to test that and see if that allows you to "skip" that clock requirement.

     

    I also cannot say if the software needs to be rebuilt or not.  That is, if you are leveraging the source we provide, the driver is certainly for a USB 3.0 setup that has fall back to USB 2.0.  That is the part that worries me and I'm working to get a straight answer.  However, in parallel, you might want to test that out as it is a quick change in the PS config menus, then I believe rebuilding PetaLinux it should get a fresh output from Vivado with the new hardware definition.  Yes, I do realize there is a LOT of recompiling, but hopefully the effort you need to put in is minimized through the use of our build scripting or similar.

     

    --Dan

  • 0 in reply to drozwood90

    Hi,

     

    We attempted all manners of FPGA configuration, including the modification to the MPSoC block in Vivado IPI, which should propagate to the PS when reconfiguring petalinux (all Xilinx tools were 2019.2). We started modifying device-tree overrides in petalinux (to no avail) when another revision of the carrier card with various other fixes was built. We just happened to add the oscillator as a possible solution - and it worked.

  • 0 in reply to buckd

    Hi there,

     

    Wow, sounds like you checked it all!  I am happy you were able to discover the issue!

     

    --Dan

  • 0 in reply to drozwood90

    I'd like to think that there is some device-tree or Linux module configuration solution, we just didn't find it. But now it's working, so we can move on.