USB superspeed peripherals Forum Discussions

Hi all,

We have noticed that FX3 PHY errors count is in strong correlation with activity on GPIF interface. Until data is handled inside FX3, typically errors count stays 0. But if FX3 itself or external FPGA starts to output data to GPIF bus, PHY errors appear.

The actual errors rate depends on host chipset type, USB cable length, GPIF interface voltage, etc. Definitely the host plays significant role here - I have a PC with Intel USB chipset on motherboard where the tests can run weeks without any PHY error (if I use short cable and plug the device into right port).

But most important - with appearing PHY errors most probably sooner or later the SuperSpeed communication fails.

According our experience, also FX3 clock signal quality has significant impact on errors count. You have to keep clock traces on PCB as short as possible (do not even think to clock two chips with same clock!). Otherwise the effect is similar - PHY errors and communication failure.

Next is an excerpt from Cypress tech support response:

>>>

These errors are not part-part dependent, but channel, activity or noise dependent. A noisy set up will produce more of these errors compared to a quiet or less-noisy set up. More activity in the chip may lead to more noise and more of such errors. However, the layers of the communication protocol (USB) are designed to recover from such dynamic errors. IO toggling results in substrate noise. If you see there are 1336 PHY errors with 3.3V IO supply, 42 PHY errors with 1.8V IO supply. Lowering the supply voltage reduces the substrate noise.

<<<

I definitely agree with tech support. Few PHY errors can be considered natural at SuperSpeed rates. And USB protocol should recover from such errors. But my concern is that in practise USB communication with FX3 fails. Even with perfect host, if you lengthen the cable a bit so that PHY errors start to appear, also the communication starts to fail. I.e. in practise it does not recover from (FX3) PHY errors.

dreitz posted in "SuperSpeed interoperability with USB 3.0 controllers" topic:

>>>

We are using a LeCroy AdvisorT3 to look at the USB 3.0.  We are seeing what they call Interpacket Symbols - IPS, but we never see any bad CRCs or other data.  It only shows Unknown Packets as a problem.  It's like the FX3 starts spewing garbage.

When using our device and the data coming from the GPIF interface, it fails.  When we use our device and the USBBulkLoopAuto sample application, we do not see the garbage.

<<<

Taking all above into account, I start to doubt that FX3 itself fails USB communication due to its internal noise issues. 

I attached a test for exploring the issue with Cypress FX3 DVK Device board (CYUSB3KIT-001).

Test itself is quite simple - host sends 32-bit toggling (0x00000000/0xFFFFFFFF) data to FX3 and FX3 GPIF automata outputs this data to its pins, causing pins to toggle as well. 

FX3 software is built by modifying Cypress Synchronous Slave FIFO (slfifosync) example. The original GPIF state machine is replaced with new one and a Device Vendor Request is implemented for querying FX3 error counters. 

Designed GPIF state machine outputs all the host sent data to GPIF pins automatically, without any external control. Plus, it fills automatically IN pipe buffers for sending to host. As there is no external GPIF clock then the automata is modified to use FX3 internal clock. GPIF II project files are located in "FX3device\GPIF II" directory.

The most of FX3 source modifications are placed between EXPLORE_GPIF_NOISE defines. Source files are in FX3device subdirectory.

Three Windows command line utilities are supplied:

1) FX3USBwrite - sends toggling data to FX3 OUT bulk pipe 0x01.

2) FX3USBread  - can be used for reading data from FX3 IN bulk pipe 0x81.

3) FX3USBerrors - reads FX3 PHY and LINK errors via Control Pipe 0.

Utilities source codes are in relevant directories. 

Testing scenario:

1) On FX3 board, set VIO1..VIO5 to 3.3V (higher bank voltage causes more errors).

2) Load FX3GPIFNoise.img to FX3.

3) Run FX3USBerrors from command prompt with option "-clear".

      FX3USBerrors   -clear

This reads FX3 error counters and resets them to 0.

4) Read errors with FX3USBerrors several times without "-clear" option. Hopefully error counters stay 0.

5) Start sending data to FX3 by launching FX3USBwrite.

6) Read errors. Hopefully you will see errors appearing. Few errors per tens of minutes should guarantee USB failure. Leave FX3USBwrite running. After few minutes...days it will exit with error - USB communication has failed.

7) Optionally you can launch FX3USBread concurrently as well, this may increase the probability of USB failure.

 If there are no errors, try to lengthen the cable or plug FX3 into another USB port. For example, if your PC has USB3.0 ports also at front, try these.

 You can also test FX3 with quiet GPIF. For that send constant data 0 to FX3 with command

    FX3USBwrite -data=0

I expect that error counters remain 0, or at least there are significantly less errors. 

Note about Etron chipset/driver. Etron and FX3 just do not cooperate. USB Control Transfers fail randomly at heavy USB throughput and therefore FX3USBerrors may exit immediately with error code 31. Just retry (of course, if FX3USBwrite still runs).

Please, test your FX3 and host and give feedback. Especially if you have a set that works reliably with PHY errors. I have 4 different hosts and 2 Cypress FX3 DVK REV3 kits (+ several our own designed prototypes), but no one combination survives FX3 PHY errors.

Thanks,

kalev