Mity CPU Platforms » MitySOM-5CSX Altera Cyclone V

I think there was a hardware issue on that version of the board to begin with, but similar problems on a new board revision that includes a TI TUSB2046BIRHBR hub:

-grounded USB1_ID via 330 ohm resistor
-267 ohm resistor between +USB1_VBUS pin and 5v rail (I did also separate pin 278 and 280 on the JAE connector, in case I shouldn't have)
-USB1_FAULT_N and USB1_PS_ON pins left floating
Otherwise following TUSB2046BIRHBR application in its datasheet using TPS2044D 4-channel switch.

clues that dmesg is giving are:

[ 2.857918] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 2.863423] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.869321] usb usb1: Product: DWC OTG Controller
[ 2.872712] usb usb1: Manufacturer: Linux 4.9.78-ltsi-g818b616 dwc2_hsotg
[ 2.878197] usb usb1: SerialNumber: ffb40000.usb
[ 2.882227] hub 1-0:1.0: USB hub found
[ 2.884783] hub 1-0:1.0: 1 port detected
[ 2.888290] usbcore: registered new interface driver usb-storage
[ 2.893101] usbcore: registered new interface driver usbserial
[ 2.897712] usbcore: registered new interface driver usbserial_generic

[ 3.305702] usbcore: registered new interface driver usbhid
[ 3.309955] usbhid: USB HID core driver

[ 3.378802] usb 1-1: new full-speed USB device number 2 using dwc2
[ 3.383792] dwc2 ffb40000.usb: XactErr
[ 3.386435] dwc2 ffb40000.usb: XactErr
[ 3.389004] dwc2 ffb40000.usb: XactErr

[ 3.713396] dwc2 ffb40000.usb: XactErr
[ 3.715985] dwc2 ffb40000.usb: XactErr
[ 3.718618] dwc2 ffb40000.usb: XactErr
[ 3.923333] usb 1-1: device descriptor read/64, error -71
[ 4.253335] usb 1-1: new full-speed USB device number 3 using dwc2
[ 4.258355] dwc2 ffb40000.usb: XactErr
[ 4.261351] dwc2 ffb40000.usb: XactErr
[ 4.264285] dwc2 ffb40000.usb: XactErr
[ 4.278217] udevd⁷⁹: starting version 3.2.2
[ 4.349867] udevd⁸⁰: starting eudev-3.2.2
[ 4.473380] usb 1-1: device descriptor read/64, error -71
[ 4.593548] dwc2 ffb40000.usb: XactErr
[ 4.596148] dwc2 ffb40000.usb: XactErr
[ 4.598759] dwc2 ffb40000.usb: XactErr
[ 4.803355] usb 1-1: device descriptor read/64, error -71
[ 4.923375] usb usb1-port1: attempt power cycle

Hopefully a matter of Kernel tweaks?

Hi Lucas,

Have you tried using an unaltered version of our development SD Card on your baseboard to see if it behaves the same way? This might be helpful in narrowing down on a software/kernel issue.
The images can be found here: https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki#Variant-Specific

Looking at your board does see the hub:

usb 1-1: new full-speed USB device number 2 using dwc2

But looks to error out trying to actually communicate with it.

Could you post the following:
1) The snipped of your schematic that has the USB connectors/hub
2) The serial number/part number of the SOM you are using

Dan

USB section schematic.

And the relevant section of SOM connector:

The Model number is: 80-000705RC-9
The Serial number is: 19032369

I attached the dmesg results below. It appears that it is doing the same thing with the base image.

Hi Travis and Lucas,

Thank you for the info!

I've compared your schematic with a USB 2 hub(TUSB4020BIPHP) that we've used with the 5CSx SOM before and the big standout difference to me is the series resistors/pull-ups/caps on USB1_D_P and USB1_D_N. Looking through the datasheet for TUSB2046BIRHBR I do see their reference design has them but seeing as it looks like you are getting transaction errors on those lines I would recommend trying to removing/bypassing them to see if it behaves differently.

Here is the snippet of the schematic for the TUSB4020BIPHP:

USB SOM connections:

Thanks Dan!

I'll try the modifications as soon as I can.

Dan-

I shorted R19, R31, and R34 in the above schematic and removed R30, C7, and C15.

After a USB storage drive didn't mount again I modified the USB lines:

-C54 has been missing all along on USB1_4, but otherwise no modifications made
-USB1_3 is still as described in the schematic
-USB1_2 I removed C43, C44, R36, and R33 but left R35 and R32
-USB1_1 I removed C39, C16, R26, and R29 and shorted R25 and R28

There appears to be no change. I've attached the dmesg output after all those modifications.

Lucas,

I have found a design that we've used that has the same USB hub that you're using. And after comparing it with your original design, the caps and resisters on the data signals you had originally were correct, sorry about my last post.

I did find two differences, which I think at least one is causing the issue you are seeing:

1. We are toggling the reset on the hub at start up from the ARM. Looking through the datasheet for the hub it sounds like this must be done in order for it initialize.
Note from the datasheet:

2. We are using an oscillator instead of crystal, which I don't think has any significants.