We have a number of products that use USB hubs , but the one we have been using has become unavailable. I found that the XR22414 hub IC is available, so re designed one of out boards to use it. The product has a USB audio CODEC and another USB embedded controller set up as a keyboard. I am attempting to get the first prototype boards to work - Windows is reporting Unknown USB Device (Device Descriptor Request Failed)
I’ve got power, 12MHz, etc. connected. I could use a few hints as to what to check to find the problem.
I have the XR22414 demo board, it shows up in device manager as generic USB hub.
I have also inquired via the Maxlinear web site, but have not had a reply yet.
Can you provide a photo of your current USB device setup? I took a look at the product brief and I didn’t note any audio CODECs in the MaxLinear USB hub.
Oh, the demo board is only a hub, with external ports. My PCB has the hub, and the 2 other USB devices I mentioned above connected to it.
I also just finished going through comparing my schematic to the demo board schematic pin by pin, figuring maybe I mixed up a pin or something similar… But no, I don’t find anything like a mixed up pin.
I do not have enough information to help with troubleshooting; can you provide the ICs and possible schematic that you are using?
That a device is being detected and reported as unknown suggests to me that the two devices can hear each other, but can’t understand what the other is saying.
Matching the reference design implementation logically (pin A to pin B) is a good start, but at USB speeds physical implementation matters; take a good critical look at the layout from a signal integrity standpoint and see if something presents itself there.
Sometimes the hardware and schematic don’t match; solder bridges, cracked caps, tombstones, cold joints, missing parts, wrong parts… they happen. Especially during development, and ++ if there’s hand work involved. A good visual inspection has much to recommend it.
And though you mentioned having compared yours with the reference schematic favorably, a sanity check/less familiar set of eyeballs on that might reveal something.
Failing all that, it wouldn’t hurt to drag out the 'scope and check eye diagrams. If they’re open and blinking as instructed it would seem like a software problem.
Comp side J-727 Rev 04a.pdf (111.1 KB)
Schematic J-727 Rev 04a.pdf (827.2 KB)
Here is the schematic, and component side of the PCB, since most of the signal wiring is on the CS. The hub is the square IC toward the lower right of the PCB.
We have built 4 copies of this PCB. Our assembly person usually does a good job with this kind of thing. All 4 boards are behaving the same way, so it’s not a random stand alone / one - off error.
There is no custom software involved at all as far as getting the hub to work goes. The USB CODEC we use uses default windows drivers. The PSoC is configured as an add on keyboard, and hooks to the windows drivers for those.
For what it’s worth, the hub chip we have been using for years is a microchip technology USB2514B/M2.
How is this eye pattern check done? We have been building similar composite USB devices for years, and fortunately rarely have mystery problems.
ON’s AND9075 may prove helpful, with “usb eye diagram” summoning additional resources from most search engines.
OK… the equipment needed to try to get an eye diagram for USB 2 looks like around $20,000.00! Just for the oscilloscope. We have nothing near that. Are there consultants or something that can do an evaluation?
Just to be sure the 2 downstream devices were not causing trouble, I disconnected the 2 USB traces from each of them. Still get the same error for the hub.
Our list of 3rd party design/mfg partners is here. Fair chance there’s one not too far from ya who’s got a fancy scope…
On closer inspection it appears that the CM choke listed on your schematic for the upstream port is shown as having quite a bit more differential impedance than the one shown on the eval platform. That’s presumably something that’s consistent across all your example boards, and could plausibly mess things up.
Ok, that’s good to know. I noticed the demo board has a place for that common mode choke, but doesn’t have one. I’ll remove the one from my board, and jumper the traces, see what happens.
Ok, I jumpered out the common mode choke. Still had the same error. I decided to remove the TVS diodes from the USB line, and that error has gone, the hub shows up ok. Now the problem is that the 2 devices connected to the hub are not showing up at all. They ae powered on, but no recognition or errors show in windows.
I have to add an update - the downstream devices are not powering on, the PP1 pin is not going high, but the hub does show in windows correctly.
I have also found that if I bypass the high side switches that the hub controls, the downstream devices become active, and show up in device manager. So this is now down to figuring out why the hub isn’t turning on the PP1 pin.
What’s the status of pin 48/OVC1#/(OC1)? The U3 datasheet makes mention of supply sequencing with respect to that pin. If that net got stuck low for some reason, it would seem likely to have the effect you’re describing.
What I figured out - the PP1 pin is active low. I had not realized that from the beginning. The data sheet has not truth table or anything that indicates this. Except possibly the # in the signal names? I never saw that used to indicate this before, and I’ve designed a lot of stuff… Partially confirmed this when I connected the dots - when the hub wasn’t coming up due to the ESD parts, the PP1 pin was high, turning on the power to the downstream devices. Once I got the hub to work, the PP1 pin went low, turning off the switches. When I bypass the switches, so the downstream devices get power, everything works.
Yet another case of things hiding in plain sight… Use of the # character to indicate active-low logic would be a convention dating prior to the modern word processing era, when some of the notations more preferred today would’ve been less convenient to get on paper. If it makes you feel any better, I missed it too…