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.
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.
Sadly, i quadruple checked thise things!
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.
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.
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)?
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......
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?
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.
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.
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.
I'm am also looking for help on the same issue. I was hoping that my project would be a direct plug and play into the usb ports on the back. I have not pulled out my old laptop with linux. I was hoping to figure out exactly what I needed before that.
So I am watching this post, to see if it gets resolved.
My device also works directly with the bottom usbC device using an app called "SerialTerminal" and usb OTG. But no enumeration when plugged into usb on side in any configuration.
I'm sure it's because I haven't installed usb2 project, but it would be nice if these ports would work out of the box (ie bypassing the mot mod dev board).
There is limited RAM and Flash space, we cannot make the base firmware support absolutely everything. So until you actually flash firmware with USB support, it isn't going to work. And you'll need to differentiate whether that's USB2.0 or USB3.1, and be aware that only one set of data lines is valid. Ultimately you'll want to write your firmware properly, usb2 in particular simply reports an external device as always attached which causes additional current drain on the Moto Z side keeping that transceiver running.
Not sure what you mean by bypassing the MDK, since that's the same as just plugging into the Z's TypeC port right? On the MDK, make sure you're plugging into the proper port with the Dips set appropriately. At this moment, I don't know that you have the same issue as Jason. Please update this with:
1. firmware running
2. USB2.0 or USB3.1?
3. MDK USB Port 2 or 3?
4. Dip switch configuration
Sounds like you're using an OTG cable, that's good since it flips the data lines for you. If you're using the TypeC, also note the previous comment that orientation actually matters. Please provide more details of your configuration so we can assist.
Thanks for your reply,
I've got a device using cp210x usb to uart bridge. When the device is plugged into a USB3.0 type A to type C OTG connector and connected directly to the bottom port of the motoz I can use a serial terminal app to connect. The device itself is USB 2.0..
The firmware that was running when I tried to plug stuff into the mdk was the developer firmware which was selected from the MDK Utility app (as opposed to blinky firmware).
I also have a USB type A to micro OTG adapter which I tried on the USB Port 3.
With Switch 1A and 2A ON; and 3A and 4A in each of the 4 possible configurations (all switch B off), I tried USB port 3 with "default" MDK-POWERED firmware and OTG type micro adapter.
With Switch 1A and 2A ON; and 3A and 4A in each of the 4 possible configurations (all switch B off), I tried USB port 2 with "default" MDK-POWERED firmware and OTG type C adapter.
But again, I haven't had a chance to install anything like USB2 into the moto mod mdk.
Ultimately, I'd like to use the device that we've already built, but just take advantage of the USB port on the 16 pin connector on the back of the MotoZ (is this out of the question?).
You're on the right track, but the 'Developer' firmware knows how to handle the battery/charging but that's it. It has no USB support, you need to build and flash the usb2 firmware. Since your cable and device work properly when plugged into the Moto Z's TypeC, we know it should enumerate properly through the Moto Mod.
So, with the TypeC cable, you'll want to use USB #2 on the MDK. You WILL need the OTG cable to flip the lines since you're a device.
Switch A1 and A2 should be OFF, you're using USB2.0.
Switch A3 OFF and A4 ON will assign USB2.0 to the USB #2 connector.
The B switches are largely Don't Cares, I would recommend them all OFF. If you are using OpenOCD to flash the usb2 firmware once you build it, you will want to flip B4 ON for flashing.
Again, you need to build and flash the usb2 firmware after you've switched to the developer bootloader. Please check out the walkthrough we put together.
Moto Mods Developer
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?