TUSB4041 Enumeration

Rebecca Tom

Hello,

I have a customer with the following problem. Could somebody please advise?

Thanks,

Rebecca

" The design I am working on has 5 TUSB4041 chips per board. The schematic was reviewed by TI and nothing terrible was found. We are having intermittent problems where sometimes the TUSB4041 can not be enumerated. We have an architecture such that the first USB hub goes to a Gumstix computer module USB port. Then we have 4 more TUSB40401s connecting to the first one. Sometimes it finds the first one, sometimes none, sometimes all. I checked the clock, power, reset timing and everything looks OK. The only thing I am doing differently that I can see is that I am using one voltage divider for the VBUS input and sharing this with the other devices."

over 8 years ago

0 Elias Villegas M. over 8 years ago

TI__Guru* 76130 points

Hello,
It could be a problem.
Is it coming from the upstream VBUS?
What is the measured voltage on all the USB_VBUS terminals?
Is VBUS always on?
What are the resistor values for the voltage divider?

It could also be a power on reset issue, can you provide scope captures showing GRST#, VDD33, VDD11 and XI of all the hubs?

Regards

0 Rebecca Tom over 8 years ago in reply to Elias Villegas M.

TI__Intellectual 1790 points

Elias,

Please see internal email thread for schematic.

Thanks,
Rebecca

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

Elias:

OK so I tried to connect the Vbus of Hub #2 to its own divider and it made no difference. I did notice that when the hubs share one divider that the voltage changes significantly which implies it's not a high input impedance on that pin. I will send screen shots of all the rails and GRST. I am driving the 24MHz clock from an external clock source as can be seen in the schematic. Any other ideas, please let me know because right now the project is stuck!

BTW my GRST comes up a few hundred ms after power comes up.

Mike

0 Elias Villegas M. over 8 years ago in reply to Michael Gambuzza

TI__Guru* 76130 points

Hello,

I recommend you to leave terminals AUTOENz floating, you are not implementing battery charging anyway.

It does looks like a problem with the USB_VBUS and/or GRST# sharing.

It will be helpful to see the scope captures.

Which ones are the hubs that are not being enumerated?

Are you able to take some USB protocol traces?

We need to make sure that:

1) USB_VBUS is around 0.5V in all the terminals

2) GRST# is not being de-asserted before the power rials are stable.

3) XI is active and valid before GRST# is de-asserted.

Is the SUSPEND output high?

Regards

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

Elias:

Please see the attached waveforms. First one is clock to TUSB.

The second one shows 3.3V coming up first, then 1.1V, then, reset de-asserts. Clock comes on immediately after power up in yellow.

Note that the "noise" on the 1.1V picture isn't really there. Supplies are pretty clean.

Initial glitch on power on is my external supply I believe.

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

Elias:

Just sent the waveforms. Sometimes the first hub enumerates. sometimes all. sometimes none. If it is GRST, maybe I can just use a cap instead of my POR circuit? The voltage on VBUS definitely changes when you add more hubs.

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

Elias:

Interesting behavior on the suspend pin. Sometimes when I power up, it is immediately 0V, other times it is about 0.8V! I have 2 hubs installed on board and they both behave differently on power up. Could the 4.7K be causing a problem?

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

I removed the resistor. Same issue. Suspend is 0V now. Also, I have seen this problem with just the first hub installed. I have one complete system working but I don't know why.

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

Hmmm. If you look at the waveforms, the reset looks to be driven only to 2V or so from my 3.3V driver. I wonder if I hit a fan-out limitation and the TUSB is not coming out of reset...sometimes!

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

Reset. I used a cap on the rest line instead of my circuit and it made no difference. This is a tough problem!

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

Elias:

I'm starting to suspect the reset circuit. We are driving reset with ADG3380. When we disconnect the output of the ADG the reset looks fine but when we connect to the IC, we get a 1V step and then it goes to 3V after about 300ms. Do you see anything in the way we're driving that could be a problem? In hindsight, I should have used all the outputs to drive individual devices (rev 2?). Anyway, please let me know what you think. Also, if I put a 1uf cap to ground on the reset pin that may not work since my 3.3V comes up a little sooner than the 1.1V according to the data sheet that would be a problem. Please confirm.

0 Elias Villegas M. over 8 years ago in reply to Michael Gambuzza

TI__Guru* 76130 points

Hello,

1) GRST# being driven to 2V is indeed very tight, can you fix that?

2) The cap on GRST# is only valid when VDD33 comes after VDD11, otherwise you have to use an active reset signal.

3) Another option is to see if the TUSB4041 is going to Suspend, the datasheet specifies a 3ms delay on the de-assertion of GRST#, this is because per the USB Spec. a USB device must be able to respond to the Host within 100ms after it was detected by the Host, if the Hub does not responds within 100ms the Host may be sending it to suspend.

4) Are you using a 1.8V oscillator? The XI input is not 3.3V tolerant.

Regards

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

Hi,

1. I am driving with the ADG3308 which has a 3.3V output. I am wondering why I am only getting 2V. Could be fanout limitation so I am going to use an individual buffer instead of grouping to a single line. I think that should work.

2. Not going to use the cap.

3. Last I checked, suspend was 0 but I'll check again.

4. 1.8V clock source per the waveforms I sent.

Do you see any fundamental problem in the way I am doing reset?

0 Elias Villegas M. over 8 years ago in reply to Michael Gambuzza

TI__Guru* 76130 points

I can't see the waveforms, can you re-attache them?
Regards

0 Michael Gambuzza over 8 years ago in reply to Elias Villegas M.

Prodigy 170 points

Do you have a private e-mail and I will send them?

Did you look at the schematic of the reset circuit?

0 Elias Villegas M. over 8 years ago in reply to Michael Gambuzza

TI__Guru* 76130 points

Please send the files to elias.villegas@ti.com

0 Nicolas Schmidt over 8 years ago in reply to Elias Villegas M.

Prodigy 70 points

Have you guys found the problem? I'm trying to do a similar project, but with 3 TUSB4041I. The first one works great (2 external USB ports, the two other ports are for the other two TUSB4041I), but the others don't respond.

0 Michael Gambuzza over 8 years ago in reply to Nicolas Schmidt

Prodigy 170 points

Nicholas:

We did find it. The problem was insufficient solder application on the ground PAD. The solder pad must have a homogeneous flow of solder to the paid with minimal voids and air bubbles. We struggled for weeks but now, with the proper solder process, everything works. I would XRAY the boards to see how the solder pad connection looks.

Mike Gambuzza

0 Nicolas Schmidt over 8 years ago in reply to Michael Gambuzza

Prodigy 70 points

thank you for the information!

Interface

Interface forum

TUSB4041 Enumeration