CY7C65632 USB-Hub Issues in Linux

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
MiCh_3303231
Level 1
Level 1

Hello,

I'm having a very strange problem with my USB hub in Linux (Debian 9, Kernel 4.14). I started with the CY7C65631 chip, then changed to the CY7C65632 hoping the problem would go away since this seems to be the 'preferred' chip. Initially, the problem was solved, but now it's back as we're trying to go into production, naturally. The problem occurs with one peripheral in particular - the Omron Microscan MV-30. It's a USB 2.0 device that mounts as a network interface. There are also 2 FTDI chips permanently connected on the PCB that always work fine. The camera also works fine under Windows, but the device fails to enumerate when using the CY7C65632 hub in Linux. The strangest part is that I can add any other non-powered USB hub after the CY7C65632 hub, and everything works fine... I don't really know where to start with debugging that issue, so hoping someone can point me in the right direction. dmesg capture below from failure and success. There seem to be errors in both cases, but one manages to actually work.

Failure:

usb_fail.png

Success:

usb_good.png

0 Likes
1 Solution

Hello,

Apologies for the delay in response. So to summarize, the issue occurs only when you have the FTDI chips connected to ports 1 and 2 and the camera (or any other device) on either port 3 or 4. Resetting the hub after enumeration or disconnecting the FTDI chips solves the issue.

-Could you kindly share the traces captured on a hardware analyzer such as LeCroy on the upstream port when you see the issue? This would allow us to check if proper enumeration commands are being sent from the host to the camera.

-Would it also be possible to check if the same device combination causes the issue when connected to a HX2VL DVK? 

Best Regards,

Sananya

View solution in original post

0 Likes
10 Replies
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

-Please send us the USB traces between the hub and PC for us to check the descriptor errors.

-Could you try connecting any other USB device such as another FTDI chip on the same port instead of the camera?

-Does the same configuration without the second hub work under Windows?

Best Regards,

Sananya

0 Likes

Thanks for your reply. Sorry, I should've mentioned that I can connect any other device I can think of - such as USB Drive, and it works. The camera also works fine with the hub under Windows. Also worth noting is that the Debian 9 Linux system is a Beaglebone Black SBC.

I have captures from linux usbmon. Let me know if you need some other kind of capture.

Failure Trace

Working Trace

Update: Sorry these links were previously not shared correctly They are available now.

Thanks,

-Mike

0 Likes

Not sure if this clears anything up, but it appears that Linux always manages to mount the camera if I reconnect the upstream connector after the camera is powered on (possible since the hub is self-powered). It almost always fails if I reconnect the downstream port to the camera and allow the camera to go through its normal boot process. Unfortunately, I can't just connect in that order since this goes in a piece of equipment.

As before, any combination of reconnecting works in Windows, and adding any cheap junk hub in between my hub and the camera makes it work fine regardless of the connection order.

0 Likes

Hello Mike,

Since it occurs only with the particular camera and both hub and device are self powered, I think the issue may be in the power system. It could be possibly due to excess inrush current from connecting both device and hub together, which may be causing a dip in the power supplies.Kindly mention if you have done the compliance test for the same?

The same configuration may be working fine on Windows due to recovery mechanisms in the latest OS version.

Please try separating the power supplies for hub and the device, that might help isolate the issue.

Best Regards,

Sananya

0 Likes

Hi Sananya,

  After further work, it appears to happen to many different Full-Speed devices on Linux - the camera, as well as a Logitech Wireless Keyboard receiver, and a USB-Serial Converter etc. As a workaround, I used libusb to write a program that sends a reset command to the Cypress hub. Once reset, everything seems to work fine... After unplugging and re-plugging the device, another reset is usually required (but not always).

Another thing I've noticed is that the hub chip gets fairly hot - not enough to burn, but about 58C. I'm using the internal regulator. Is this normal? According to the datasheet, the chip could draw 100mA with 4 devices connected. So that 0.5W dissipation would get pretty hot. Schematic is pretty straightforward datasheet design.

usb_hub.png

0 Likes

Hi Mike,

Assuming everything is working fine after the Reset, please check the exact power consumed by the hub chip. Please refer to the DC Electrical Characteristics in the datasheet to check the supply current for your configuration. You could then check the expected temperature using thermal resistance values in the datasheet and see if there is an anomaly. Could you also tell us how you checked the current value to be 58C?

Best Regards,

Sananya

0 Likes

Hello,

Sorry we've been fairly busy and I haven't had a chance to work on this issue in a while. I have cut the trace on the PCB and inserted a current meter going directly to the CY7C65632 chip. Disconnected it draws 4mA, but when connected up-stream it draws over 120mA. That dissipation would make sense with the high temperatures I'm seeing. However, the datasheet implies it should never draw that much - especially since there are only 2 full-speed devices (FT230X chips) connected on the PCB. The temperature was measured with a small thermocouple on top of the package. That's about the temperature I'd expect for 5V*120mA=0.6W.

0 Likes

Update: The excessive current draw appears to come from the Suspend/Gang pin (39). I had this pin pulled hard to GND. It should be connected through a 100k resistor per the datasheet. After cutting the trace to this pin, current draw dropped to 61mA.

Unfortunately, this didn't magically fix my Linux Enumeration issue. The device still requires a hub reset to properly enumerate on Linux.

0 Likes

I think I've tracked the issue down to the FTDI chips. If I cut power to these chips, the camera device enumerates successfully when first connected. This occurs with my built-in power supply as well as with an external supply. Not sure where to go from here yet since the FTDI chips have always been working, but something to do with disconnecting them allows the hub to work correctly in linux...

These chips are connected to Ports 1 and 2 with the FIXED_PORT pins pulled high. Ports 3 and 4 are removable with the camera connecting to either one.

0 Likes

Hello,

Apologies for the delay in response. So to summarize, the issue occurs only when you have the FTDI chips connected to ports 1 and 2 and the camera (or any other device) on either port 3 or 4. Resetting the hub after enumeration or disconnecting the FTDI chips solves the issue.

-Could you kindly share the traces captured on a hardware analyzer such as LeCroy on the upstream port when you see the issue? This would allow us to check if proper enumeration commands are being sent from the host to the camera.

-Would it also be possible to check if the same device combination causes the issue when connected to a HX2VL DVK? 

Best Regards,

Sananya

0 Likes