SuperSpeed communication fails due to FX3 internal noise issues?

Hi RSKV,

I created this topic after I had contacted tech support first time.

Yes, I contacted tech support again by reopening the case. And they promised to explore the issue more.

Hopefully any feedback here could help me, tech support and whole developer community.

Thanks,

kalev

Hi  MPL,

USB2 seems to work well, though I have not tested it as exhaustively as I test USB3.

> Maybe the FX3 has some Problem with its USB3 tranceiver and its PLL ?

We have found that FX3 USB3 is very sensitive to clock signal quality. We succeeded to suppress PHY errors significantly on our custom board by filtering clock chip power and shortening clock signal routes. Test results with FX3GPIFNoise.img:

Cypress FX3 DVK rev3 board - over 100 PHY errors/min.

Our custom board - about 0...1 PHY errors/min.

Clearly a noise on clock signal affects PHY errors count (and I guess because it affects PLL).

Why the USB3 communication breaks? I can only guess. Either it's HW issue, for example PLL output becomes so bad that USB3 state machine fails. Or, FX3 firmware just resets USB3 if it counts too much PHY errors. I really hope it to be a firmware issue because it seems to be in correlation with PHY errors rate. Note, according SDK version 1.2.2 FX3ReleaseNotes.pdf, similar issue was already fixed:

...

2) Fixed a USB driver issue which could cause the device to re-enumerate occasionally due to
USB 3.0 link errors that accumulate over a long period of time.

...

According my tests, USB3 may break even if there is still 0 link errors even after device re-enumeration.

kalev

 Hi,

One more observation. Similar PHY errors and USB3 break effect can be achieved just by lengthening the USB cable. Therefore it seems that there is no direct relationship between FX3 external/internal noise and USB3 break, i.e. it's not PLL issue. Could it be that disconnecting USB3 causes "unkown packets"? If yes, then it's most probably software issue that just resets/disconnects USB3 when there appears enough PHY errors.

Let's see what the tech support will find.

Thanks,

kalev

Hi,

There is little progress. Related to this SuperSpeed breaking issue, tech support reported that maybe they have found something unexpected happening on LINK layer and they are discussing issue with design team.

Anyway. There are two problems involved:
1) FX3 noise sensitivity that causes PHY errors. You can increase the number of PHY errors dramatically on Cypress FX3 Kit just with outputting data onto GPIF pins.
2) Possible FX3 (or hosts) issue that breaks SuperSpeed connection when PHY errors appear.

According USB 3.0 standard, SuperSpeed physical layer bit error rate is expected to be less than one in 1e12 bits (according my computations, 1 error in 200 seconds). So, anyway, if you want to build reliable device, you have to design a hardware where basically no PHY errors appear. And as you see, you must build better hardware that FX3 kit.

Cypress is kindly agreed to review users PCB layouts, but I would appreciate if they could review FX3 kit first and tell what the users should pay attention in their designs to get less PHY errors compared to Cypress kit. I assume that Cypress has followed all their FX3 Hardware Design Guidelines but still the kit seems to be far from perfect.
 

Thanks,
kalev
 

Hi,

I have a bit of information to share.

Tech support said that this is host that gives up and breaks the communication. To reduce noise, tech support suggested to try using of metallic shield over the FX3 (and use more realistic data pattern).

It's clear that using GPIF increases noise and affects SuperSpeed communication. For users the biggest concern is probably that FX3 enumerates initially at SuperSpeed, but when the actual data transfer over GPIF starts, the communication with device may break. So, my suggestion is to check always for PHY/LINK errors, especially in your own hardware designs (NB! see my comments below about CyU3PUsbGetErrorCounts).

Anyway, for those who are interested in playing with FX3, I attached updated FX3GPIFNoise2.zip. The changes are:

1) I found that CyU3PUsbGetErrorCounts function may return incorrect error counter values, i.e. hide errors. As a work-around, I wrote my own GetErrorCounts implementation and changed a way it gets called. Unfortunately it's not possible to get 100% true counter values until Cypress does not fix the API. More comments in source.

2) I replaced three separate host utilities with one single FX3USBtest - easier to use. Type

FX3USBtest -help

for help on its command line options.

Below are screenshots from my tests with Renesas USB3.0 add-on adapter (bases on NEC D720200F1 chip):

1) 1m USB3.0 cable is used for connecting FX3 DVK rev 3 to host Renesas adapter:

C:\test>FX3USBtest
FX3USBtest version. 1.2
Press ESC for exit
00:00:28 Read/Write=196.2/108.5MB/s Errors PHY/LNK=5/0
Read from device failed (GetOverlappedResult error code=31)
A device attached to the system is not functioning.

2) 1.8m cable. My 1.8m cable seems to be better than 1m cable, worked 9 minutes:

C:\test>FX3USBtest
FX3USBtest version. 1.2
Press ESC for exit
00:09:42 Read/Write=199.2/ 99.1MB/s Errors PHY/LNK=62/0
Write to device failed (GetOverlappedResult error code=31)
A device attached to the system is not functioning.

3) same 1m cable + 1.8m extension, total 2.8m cable. Data pattern all zeros. Has worked for now over 16 hours without errors:

C:\test>FX3USBtest -data=0x0,0x0
FX3USBtest version. 1.2
Data pattern = 0x00000000,0x00000000
Press ESC for exit
16:40:51 Read/Write=200.0/109.0MB/s Errors PHY/LNK=0/0

Br,
kalev

Hi,

On FX3 kit, to reduce noise, lower the VIO voltage. Set VIO1...VIO3 to 1.8V and you will get significantly less PHY errors. You can experiment also by removing VIO1...VIO3 jumpers at all after powering up and loading the program image into FX3. This way it's possible to reduce PHY errors rate to a level that is comparable with rates when processing data FX3 internally.

But when there appear PHY errors (with rate about 10 errors per minute) then you can be sure that at some point the SuperSpeed communication will break. I think, this is characteristic to USB3.0 (I can't understand why the host should give up so easily and not retry until it succeeds?). Anyway, keep the cable as short as possible. I have achieved to build a device that works with about 1...1.8m cable (tested with hosts I have available).

br,
kalev

Hi,

I attached FX3USBnoise3.zip that includes sources/images updated to FX3 SDK 1.3.0.

As Cypress published API sources then I finally got a chance to fix HW/SW concurrency while updating "Error Count Register". Now the program displays the exact count of PHY/LINK errors as FX3 HW detects them.

Of course, program works also when linked with original Cypress API libraries, but error counters displayed are then just less accurate.

BTW, I fixed also CyU3PBusyWait function that was optimized out while compiling with gcc options -O2,-O3, -Os, etc. Prebuilt FX3GPIFnoise.img, provided in zip is linked with library compiled with -Os option.

Modified API library sources are provided in FX3_lib_1.3.0.118_sources_updated directory.

Br,
Kalev