Study of the operation of USB 3.0 controllers with high current loads. A brief description of the situation - there are machines on mother

[VictorVG]

Study of the operation of USB 3.0 controllers with high current loads.

A brief description of the situation - there are machines on motherboards built on the Intel z68 chipset that do not have a built-in USB 3.0 controller. While the boards worked with the Flash drive, there were no problems - the load was within the permissible limits, but when USB 3.0 HDD appeared on the farm, the current consumption could reach 1.0A, problems with the network and OS started. With the network, problems were expressed in a significant delay in building a network map using the SMB protocol, which reached 10-15 minutes or more. I checked the distribution of interrupts, including hidden ISAs - on the interrupt map I saw that the xCHI controllers use the same IRQs as the NICs. I found a part of the circuit diagrams of the board and the chipset - such a distribution of interruptions is laid down in the chipset circuitry. He began to understand what was happening?und of the HDD, it was audible that they periodically jerked their heads - there is not enough power, but since USB 3.0 ports can give currents up to 0.9A to the load, then there was a suspicion of weak buffers in the controller chips. And this is easy to check with a voltmeter by measuring the voltage between the +5VUSB and GND contacts in the USB connector. USB 3.0 connectors could not be bought, I had to look at USB 2.0 and measurements showed that under a load of more than 0.5A the line “sags” - the power transistors in the ports are either not fully open or have high saturation resistance. There is no other option, the circuit is designed for lower load currents.

I ordered at the factory measuring instruments suitable for the measurement data, performed them, and here is the report (part in the form of photographs):

USB 3.0 tester Ruideng AT35 - launch time:



STLabs U-750 PCIe 1x USB 3.0 controller chip NEC/Renesas uPD720201F:

STLabs U-750 KCX-017 Icc=6,5 mA



STLabs U-750 all port not loaded



STLabs U-750 and JET Flash wait command



STLabs U-750 and WDC Elements read data



STLabs U-750 and WDC Elements take off



STLabs U-750 and WDC Elements wait command



STLabs U-750 port 2 off, port 1 WDC Elements wait command



Integrated on m/b GA Z69AP-D3 v2.0 xCHI Etron Technology EJ168A + HDD WDC Element



HP USB 3.0 2x2 port Super Speed PCIe x1 Card, chip TI TUSB7340, free port:



when connecting the HDD to it, a "drawdown" of 1mV,

the solution was to transfer the HDD from the port of the controller integrated on m/b to the active USB 3.0 port of the hub 2 USB 2.0 + 4 USB 3.0 with the GL3510 chip connected to the internal port of HP USB 3.0 2x2 port Super Speed PCIe x1 Card - this chip at load current 0,9A produces 4.998V voltage on the +5VUSB line, without a load of 5.078V and this solved the problem. After switching the HDD, the write speed to it increased to 65 Mb/s, the OS and application freezes stopped.

An active USB 3.0 hub Ruipoo model 303 is connected to the output of the STLabs U-750 controller on a Genesys Logic GL3510 chip (China):

WD Elements 25A2 USB Device, 1 Tb, NTFS (current consumption: off 0.18A, standby 0.35A, read/write 0.5A)

File type Read speed Write speed

Small files (32,0 Kb): 70,30 MB/s 23,34 MB/s
Medium files (3,0 Mb): 44,97 MB/s 46,36 MB/s
Big files (100,0 МБ): 90,84 MB/s 59,15 MB/s

Transcend JetFlash 700 32Gb, FAT32 (current consumption: off <0.5 mA, standby ~ 78 mA, read/write ~ 180 mA)

File type Read speed Write speed

Small files (32,0 Kb): 22,38 MB/s 1,90 MB/s
Medium files (3,0 Mb): 90,68 MB/s 30,14 MB/s
Big files (100,0 МБ): 94,42 MB/s 42,81 MB/s

+5VUSB line power control:

USB 3.0 tester RD AT35 0,0065А - 5,2075V
Transcend JetFlash 700 32Gb 0,0775A - 5,186V
HDD WD Elements 25A2 R/W 0,5000A - 5,182V
HDD WD Elements 25A2 Pause 0,3500A - 5,184V

Test tools used:

Check use RD AT35, firmware v1.7 (±0,01% +2)
B7-38 Voltmeter universal digital (±0,07% +7)
Crystal Rich Ltd. Zentimo xStorage Manager v2.2.1.1278

The polling time of the SMB 2.0/3.0 network in Far 3.0.5545 is less than 1.3 seconds, without a USB 3.0 Hub to which the USB HDD on the second machine is connected 25 - 30 seconds.

General conclusion:

Connecting a USB HDD/SSD to the ports of the Etron EJ-168A, NEC uPD72020x chip controllers is not advisable because they have high key saturation resistance, which leads to a decrease in the voltage on the +5VUSB port line with an allowable load current. At the same time, connecting USB flash drives or card readers to them will not cause problems. These devices consume currents up to 0.3A, which does not cause a strong voltage drop on the +5VUSB line.

 

[VictorVG]

Yes, I almost forgot:

For the correct operation of any USB 3.0 controllers with high current loads (>= 0.3A), it is necessary to connect an additional power supply from the PSU to the board! Otherwise, the internal protection against short circuit in the controller chip will work. During the assembly of the machines, all the controllers under study were connected to the 650VA - 750VA power supply units, which have 30% of the peak load current in each channel in these machines.

 

[VictorVG]

Continue test - try move USB 3.0 HDD in to HP USB 3.0 controller (based on chip TI TUSB7340) on to 5,25" USB Hub based on Genisys Logic GL3510 chip (power on Chieftec GDP-750C (A-90 Series) power supply) - result's:

1) Chieftec GDP-750C (A-90 Series) +5V channel (Vcc) - +5,021V±0,07% (B3-38, power supply unit maximum summary load 514VA of 750VA);
2) current 0,467A, power is 4,861V (tested use RD AT35 and B7-38 multimeter);
3) OS detect HDD ~ 65 - 70 sec, then kernel panics and restart.

Conclusion:

Connecting more than two high-current loads of the HDD / SSD type to the GL3510 chip at the same time is not desirable since even if the power supply provides sufficient currents and a small internal resistance of the output stage to operate such loads, the chip logic in some cases will not be able to ensure the correct interaction of the devices with the host machine, which will lead to a panic kernel OS.

Experiments with connecting 2 HDD and 1 - 2 Falsh drives revealed that such a connection is possible, but the parallel use of the channel "host device" for two or more simultaneous I / O operations are not desirable and can lead to data corruption if one of the devices writes them.

The probability of an error increases significantly for file systems of the FAT family (ExFAT) and to reduce it, if it is necessary to overwrite the data, you must first delete the old copy and then write a new one to the same directory.

 

[PiersJH]

Connecting more than two high-current loads of the HDD / SSD type to the GL3510 chip at the same time is not desirable

Didn't expect to find the information on here, but thank you for all the results of your testing. I've been looking in to the GL3510 which is seeing wider use.

 

[madvillain]

Old thread but great read. Applaud your effort to and detail documenting. Even without suffering from issues I learned a lot.

Do you think this issue is related to other known SM Bus and USB problems? Namely some RGB devices failing to reliably sync with various software and items like the Oculus Quest's known USB issues where the hub shows as 2.0 despite the correct cable and hardware in place? These are among the holy grail(s) of difficult to troubleshoot issues on the intenet today and I happen to suffer from both.

I've had some success mitigating problems by overlooking the SM Bus by as much as 100mhz but nobody seems to have any other clues.

Cheers.