I found the section "USB 3.0 and USB 2.0 Function Coordination" on page 94 of the tech reference manual for the part (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.
Does that about sound like the long and short of it?
1. First Disable the USB 2.0 connection using the API CyU3PUsbControlUsb2Support. Refer 18.104.22.168 CyU3PReturnStatus_t CyU3PUsbControlUsb2Support ( CyBool_t enable ) in FX3 API Guide.
2. Then use Connectstate API until the USB 3.0 connection success.
The code goes like this:
/*Disable the USB 2.0 connection*/
/* Connect the USB Pins with super speed operation enabled. */
apiRetStatus = CyU3PConnectState(CyTrue, CyTrue);
if (apiRetStatus != CY_U3P_SUCCESS)
CyU3PDebugPrint (4, "USB Connect failed, Error code = %d\n", apiRetStatus);
CyU3PDebugPrint (4, "USB Connect passed, Error code = %d\n", apiRetStatus);
}while(apiRetStatus != CY_U3P_SUCCESS);
This ensures that the device should make only USB 3.0 connection.
Give a try, it should work.
Thank you for the feedback!
I can give that a shot, but I am worried that it won't do anything in my current setup. The way the board was designed, the PMODE inputs are set as F1F. This configures the boot mode of the FX3 to: "I2C, On Failure, USB Boot is Enabled". The EEPROM on the board doesn't have the ARM hex image on it (it has things like the VID/PID), so it is going to fail and resort to booting off of the USB.
That said, someone at Cypress told me that when the FX3 boots off of the USB, it resorts to USB2 mode, which won't ever work in my case since I don't have the D+/- lines available. Do you agree?
Will the code changes allow a workaround?
If PMODE inputs are set for "FIF" and the EEPROM doesn't have valid image, it will fall back to USB 2.0 Bootloader device. Since the board doesn't have D+/-, the device can't be detected (not be seen in the device manger / control center application). Hence, programming the EEPROM or System RAM can't be possible.
Now, the possible option is programming the on board EEPROM using external device.
1. If you have any MCU, that is capable of programming FX3 image file on-board EEPROM
2. If you have a FX3 explorer kit, connect I2C SDA, SCL, ground pins of it to the I2C lines of on-board EEPROM. Lift the SCL and SDA pins of Explorer kit's EEPROM and program the on-board EEPROM through Explorer kit. if you don't lift the pins of Explorer kit, and the addresses of the both the EEPROMS are same, then there will be device address conflict.
This make sure that on-board EEPROM is loaded with valid image file, then it can enumerate as USB 3.0 device.
The next possible option is, revision of the board. This allows you to program the firmware to the System RAM. I2C EEPROM, or SPI Flash over USB.
Sadly the EEPROM is only 250kB and the image we are using is over 400kB, so I am stuck yet again. Thank you though for the potential work-around.