Actions
Forum Thread Details
  • Replies 14 replies
  • Subscribers 59 subscribers
  • Views 1652 views
  • Users 0 members are here
Related

USB3 powering device, but not enumeration

garengllc

I have an Ettus USRP (B205mini) that I can get to work fine with the usb2 project.  When I switches projects to compute (to take advantage of the USRP's USB3 capabilities), I cannot seem to get it to work.

 

When I plug the USRP into the middle USB port on the MotoMod, it powers it up, but I don't see the standard Android pop-up that a USB device was detected (which it does when I use the USBC port on the bottom of the phone).  I started adding debug statements into the fusb302.c file and can see the MotoMod recognizing a device being plugged in. 

 

I believe the issue is that in the decode_cc_termination function, it checks if (fusb302_regs.status0 & FUSB302_STATUS0_VBUSOK_MASK) (which is VBUS Valid), and it is coming up 0.  According to the FUSB302 datasheet, that bit it is checking is bit 7 of the status0 register and it describes it as going high (and interrupt occuring) when VBUS transitions through vVBUSthr. It also says that that bit typically is used to recognize port partner during startup.

 

So any idea what is going on here?  Any idea of further debug that I could try?

Parents

  • BTW, when the check gets done on status0 above, it has a value of 1 supposedly.  According to the datasheet (https://www.fairchildsemi.com/datasheets/FU/FUSB302B.pdf ), that means (among other things) that the device is drawing >200mA and <660mA.

  • in reply to garengllc

    Hi Jason,

     

    Did you verify your A1 and A2 dip switch is set to "On, On" to enable USB3.1 support? Also, you may want to verify you are using a USB OTG(on the go) cable plugged into the MDK to ensure the device is properly recognized as a USB slave.

  • in reply to dpwinkler

    Sadly, i quadruple checked thise things!

  • in reply to garengllc

    Have you been able to enumerate any other devices? I've had USB flash drives be recognized via the MDK using compute firmware in the past. I'm wondering if there is something specific to the device you are trying to connect which is causing an issue.

  • in reply to dpwinkler

    Funny you should say that, that was this morning mission.  Unfortunately, I haven't been able to find something here at work that is USB3 (besides other power hungry SDRs).  I was hoping to come up with a thumbdrive (or something simple like that), so I could prove to myself that the firmware is indeed OK.

     

    I also was on the hunt for a powered USB3 hub to rule out power supply issues to the device, but came up empty there as well.

  • in reply to garengllc

    A little more info on what my debugging has turned up.  It sees my device get plugged in and reports a togss of 0x02 which means toggle functionality has "settled on SRCon CC2", VBUSOK ==1 which means that a port partner was recognized (this was not working earlier but is now), and comp == 0 which means that the measured CC* input is lower than than reference level driven by MDAC.

     

    All that boils down to the MotoMod detecting USB ISR trigger for a USB 3.1 device on CC2B (and if I flip the USBC connector around that changes like it is supposed to).  I end up getting a "src -> src" in the fusb302_update_state function (meaning that when in the USB_STATE_ATTACHED_SRC state, we have a ATTACH_TYPE_SRC new attachment). 

     

    I can't for the life of me figure out where this is going wrong though. 

     

    Has anyone connected a USB3 device to the compute firmware for something more complicated than a thumbdrive (and I mean a direct-connect, not through a powered USB hub)?

  • in reply to garengllc

    Anybody?  I am really stuck at this point.  Looking at the firmware and adding debug it looks like it is setting things up OK, so I don't understand why it isn't enumerating.

     

    It works perfectly fine when plugged into the USB-C connector on the bottom of the phone, but I cannot get it to work on the middle USB-C no the side to save my life......

     

    <<EDIT>>

    BTW, the debug pretty much looks the same when I set A1 and A2 = OFF.  That doesn't make any sense to me as the paths should be off.  Is there anyway to probe and see what the system thinks the dip switch is set to?

  • in reply to garengllc

    Hi Jason,

     

    For clarification, is the MDK attached to the Moto Z when you are plugging in your USB device? I've heard of cases where the enumeration fails if the MDK is not attached to the phone and it gives up. Try plugging in your USB device after the MDK is attached to the phone.

     

    If this doesn't help, be aware that Moto Mods USB3 support is really just the super speed lines only, i.e. there is no d+, d-. Without knowing more about how your device works, it's possible it needs the D+,D- present to enumerate and that could be the reason it is failing here.

  • in reply to dpwinkler

    David,

     

    I attach my MotoMod onto the phone, then once I see that the phone notices it and reports the battery voltage on the MotoMod, I then plug in my USB3 device.  I tried all sort of permutations of this (boot with device and MotoMod already attached, attach device to MotoMod, the attach MotoMod to phone, etc.) to no avail.

     

    Interesting comment on the D+/D- lines.  Looking at the schematic for the part (sheet 5 https://files.ettus.com/schematics/b200mini/b200mini.pdf ), those lines are there, but that isn't a surprise since this device can run on USB2 protocol as well.  I will try to ping the company (ettus) to see if they know whether those lines do anything when in USB 3 mode.

  • in reply to dpwinkler

    Well, I heard back from someone, but it doesn't give me a definitive answer (but you certainly got me going on the right track again).  Their comment was that "the FX3 comes up in USB-2.0 mode, and switches later on in the process."  This would mean that there is no way that it would work with the MotoMod as is due to the lack of d+/- lines like you pointed out.

     

    I attempted to verify this, but cam up short.  I found the section "USB 3.0 and USB 2.0 Function Coordination" on page 94 of the tech reference manual for the USB part on the B200mini board (http://www.cypress.com/file/134661/download).

     

    It looks like it tries to come up in 3.0 mode, then falls back to a 2.0 state if it didn't work, and retries for 2.0 and 3.0.  I am not sure if there is a way to figure out what the B200mini is really doing to try to follow the flow that the FX3 firmware is supposed to follow (I am looking into that now).

     

    Here are the steps from the PDF:

    1. Wait for a valid VBus voltage (GCTL_IOPWR interrupt).

    2. Turn on the USB 3.0 PHY to start 3.0 receiver detection.

        a. If receiver detection succeeds, the LNK_LTSSM_CONNECT interrupt will be received. If this interrupt is received, the device will proceed with enumeration in USB 3.0 mode.

    3. If receiver detection fails, the LNK_LTSSM_DISCONNECT interrupt will be received. If this interrupt is received:

        a. Turn off USB 3.0 PHY and turn on USB 2.0 PHY.

        b. A USB 2.0 bus reset will be received as part of USB 2.0 connection startup.

        c. The 3.0 PHY should be re-enabled on receiving the URESET interrupt that is triggered on a 2.0 bus reset. Both the 2.0 and 3.0 PHYs will be active at this time.

        d. If the 3.0 receiver detection succeeds (LNK_LTSSM_CONNECT):

            i.Turn off the USB 2.0 PHY.

            ii.Proceed with enumeration as a USB 3.0 device.

        e. If the 3.0 receiver detection fails (LNK_LTSSM_DISCONNECT):

            i.Turn off the USB 3.0 PHY.

            ii.Check number of times that 3.0 receiver detection has failed. If this count is greater than 3:

    4. Proceed with enumeration as a USB 2.0 device.

    5. There is no need to attempt 3.0 enumeration on any further bus resets.

     

    So, I guess the question would be, when the B200mini is plugged into the MotoMod, is it getting a the LNK_LTSSM_CONNECT or LNK_LTSSM_DISCONNECT interrupt.  If it is the latter, then when the FX3 drops down to the USB 2.0 PHY, the MotoMod won't be able to do anything about it because of the lack of D+/- lines.

     

    That is where I stand right now.  It is probably more likely than not that the lack of d+/- lines is keeping the device from enumerating properly, but I haven't been able to prove it out yet.

Reply
  • in reply to dpwinkler

    Well, I heard back from someone, but it doesn't give me a definitive answer (but you certainly got me going on the right track again).  Their comment was that "the FX3 comes up in USB-2.0 mode, and switches later on in the process."  This would mean that there is no way that it would work with the MotoMod as is due to the lack of d+/- lines like you pointed out.

     

    I attempted to verify this, but cam up short.  I found the section "USB 3.0 and USB 2.0 Function Coordination" on page 94 of the tech reference manual for the USB part on the B200mini board (http://www.cypress.com/file/134661/download).

     

    It looks like it tries to come up in 3.0 mode, then falls back to a 2.0 state if it didn't work, and retries for 2.0 and 3.0.  I am not sure if there is a way to figure out what the B200mini is really doing to try to follow the flow that the FX3 firmware is supposed to follow (I am looking into that now).

     

    Here are the steps from the PDF:

    1. Wait for a valid VBus voltage (GCTL_IOPWR interrupt).

    2. Turn on the USB 3.0 PHY to start 3.0 receiver detection.

        a. If receiver detection succeeds, the LNK_LTSSM_CONNECT interrupt will be received. If this interrupt is received, the device will proceed with enumeration in USB 3.0 mode.

    3. If receiver detection fails, the LNK_LTSSM_DISCONNECT interrupt will be received. If this interrupt is received:

        a. Turn off USB 3.0 PHY and turn on USB 2.0 PHY.

        b. A USB 2.0 bus reset will be received as part of USB 2.0 connection startup.

        c. The 3.0 PHY should be re-enabled on receiving the URESET interrupt that is triggered on a 2.0 bus reset. Both the 2.0 and 3.0 PHYs will be active at this time.

        d. If the 3.0 receiver detection succeeds (LNK_LTSSM_CONNECT):

            i.Turn off the USB 2.0 PHY.

            ii.Proceed with enumeration as a USB 3.0 device.

        e. If the 3.0 receiver detection fails (LNK_LTSSM_DISCONNECT):

            i.Turn off the USB 3.0 PHY.

            ii.Check number of times that 3.0 receiver detection has failed. If this count is greater than 3:

    4. Proceed with enumeration as a USB 2.0 device.

    5. There is no need to attempt 3.0 enumeration on any further bus resets.

     

    So, I guess the question would be, when the B200mini is plugged into the MotoMod, is it getting a the LNK_LTSSM_CONNECT or LNK_LTSSM_DISCONNECT interrupt.  If it is the latter, then when the FX3 drops down to the USB 2.0 PHY, the MotoMod won't be able to do anything about it because of the lack of D+/- lines.

     

    That is where I stand right now.  It is probably more likely than not that the lack of d+/- lines is keeping the device from enumerating properly, but I haven't been able to prove it out yet.

Children
No Data