TUSB2E11: USB 2.0 Repeater/retimer/signal conditioner

Hello Yaroslav,

Can you clarify which device you are using?  They serve two different purposes.

TUSB211 - USB 2.0 redriver
TUSB2E11 - eUSB Repeater

I'm making the assumption based on your description that you want to use the TUSB211.  This is a USB 2.0 redriver, and we have a whole line of them with various features.

TUSB211
TUSB212
TUSB214
TUSB216
TUSB217

The TUSB2E11 has a very specific use case, and as you said it does have logic inside.  The eUSB standard can be found on the USB-IF online document library and it defines a digital state machine for eUSB repeaters.  Our device is compliant to that specification.

I am not aware of any USB 2.0 retimers on the market.  The USB 2.0 signal frequency is relatively low compared to USB 3.2, and often doesn't require as much signal conditioning.  Retimers are meant for a greater level of signal conditioning than is typically needed for USB 2.0 applications.

You are trying to attenuate, as in lessen in amplitude, the USB 2.0 signal?  I think your design would benefit in cost savings if we focused on why you're not seeing significant signal improvements and what your design need is.

Regards,

Nicholaus

Hello Nicholaus!

At this moment I trying to configure TUSB2E11 as described in topic title.

The goal is increase DC levels of signal because of signal path attenuation (long cables and multiplexers). 

As I mention: TUSB21x family can't help with that. It only helps with pre-emphasis AC part of eye-diagram. Slightly. (If we count on TUSB211 for example)

So I looking for USB 2.0 retimer IC. It should receive packet and transmit to the next node. 

Not necessary "a data packet", maybe just USB 2.0 bus states and levels, but it should repeat it, not just assist as TUSB211.

So the question is - is TUSB2E11  able to work back to back with such goal? How it should be configured? 

P.S. My next try is TUSB216, because it has DC levels gain. But if it won't help, I don't see any TI products for this. Maybe NXP PTN3222 will helps, it has forced HOST/DEVICE mode, what I'm looking for in TUSB2E11.

Hi Yaroslav,

To answer your question.  Yes, the TUSB2E11 COULD be used back-to-back, but I am not recommending it.  You will need to have an eUSB host, and an eUSB device for it to work.  Do you have one?   They are pretty difficult to find on the market.  You would not be able to use USB 2.0 devices with this setup.  

The product I recommend for you is the newly released TUSB211A!  It has DC boost, and cost savings compared to the TUSB216.

Regards,

Nicholaus

Hello Nicholaus!

Right now I have all the chips of the TUSB21x family at hand. I've tried them all. There are two problems with them:

-- The specifics of the device are such that I need to restore the signal several times, since the devices are connected in a chain. After two chips, the signal deteriorates too much.
-- TUSB21x  chips do not work with Low Speed and Full Speed, which I also need to restore.

That's why I need a redriver (retimer) which will completely regenerate the signal on each device.
There is one working solution that I found: USB galvanic isolator. It does exactly what I need with the signal, but I don't need galvanic isolation, it's redundant for us.

Therefore, I considering TUSB2E11 as a cheaper solution. I wanted to configure one chip as a peripheral, and the second as a host. By connecting them via their eUSB lines together, I would get a redriver. The question is how to make the chip have a static configuration: one ONLY host, and the second ONLY peripheral. It looks like NXP chips allow you to do this. But I don't want NXP, I want TI

Hi Yaroslav,

I appreciate your commitment to TI.  I will do everything I can to help.

It seems like you have a really long USB channel if you are seeing issues at USB Low Speed and Full speed.  So much so, that I would say your system is not USB compliant and this is not something that IC vendors typically design for.  Which could be why it's difficult to find a product that works for you.

The maximum cable length between two USB points is 5 meters (16 feet, 5 inches).  If that were the case here, I wouldn't expect the issue.  Can you tell me more about your design and how long your channel is?  

I will consult with my team here and confirm if your proposed solution with back-to-back TUSB2E11 will work, and if there is any way to force host and peripheral.  Have you confirmed that the NXP repeater will work this way?

Thanks,

Nicholaus

Hello Nicholaus!

Thank you for your support.

Actually, the length of the cable fits perfectly into the standard. The reason for the problems is that there are quite a lot (several dozen) USB multiplexers on the line, switching the signal from different hosts to single peripheral device. Logically, this is divided into blocks inside which there are several multiplexers, and there should be a redriver at the output. Several blocks can be connected in one line.

As for NXP, I haven't tested it yet, but their datasheet explicitly states the possibility of setting a static mode configuration via I2C. So I suppose it will work. 

Hi Yaroslav,

Ah, that makes sense.  Thanks for the clarification.

I'll let you know this week.

Regards,

Nicholaus

Hi Yaroslav,

I will need more information to say if it's possible.  

This is not an application we have tested, and it's considered it outside the normal use-case.  So, there are no guarantees it would work as stated in the datasheet.

Can you let me know what the Ron is for your multiplexers?  Maybe a diagram of your system would be good?  How many of these repeaters are you planning on using?  Each eUSB repeater will add some jitter, an eUSB repeater also will also consume a small amount of the SYNC bits in a USB packet, and so you can only use two in a single USB channel path.

Is using multiple redrivers an option?

Regards,

Nicholaus

Hello, Nicholaus!

I can roughly explain how it is connected. Here is a draft of one block:

LINE_IN >====[M]====[R]====> LINE_OUT
                           |
                          IN

LINE_OUT - the output of the block, can be connected to the LINE_IN of another of the same block or to a USB device.
LINE_IN and IN - inputs for hosts. LINE_IN differs from IN in that it is assumed to connect to another of the same block in order to increase the number of hosts connected to IN.
M - the USB multiplexers TS3USB221.
R - the USB redriver/retimer. This is where two TUSB2E11 was supposed to be used.

There is a short (~20-30cm) cable with USB connectors between LINE_IN and LINE_OUT.

The experiment showed that after passing 4 blocks (that is, 4 multiplexers), the signal deteriorates and the device (LINE_OUT) is not recognized by the host. Instead of using the R driver, I used every chip from the TUSB21x line, but nothing helped.

I also carefully checked the alignment of the tracks and the impedance, everything is normal and corresponds to the specifications (even more accurately). Presumably, due to the connectors between the blocks, signal losses and reflections occur. But this is part of the design, I can't remove the connectors. The error is cumulative in nature - the more blocks, the worse the signal. Therefore, I need something in place of R that would allow me to regenerate the signal completely.

Hi Yaroslav,

I do see your point, and you couldn't replace the M and R with a 2-port HUB like the TUSB8020 or TUSB4020 because you can't have more than 5 levels of hub. Unfortunately, I don't believe back-to-back eUSB repeaters will work here either.  Here is the reason why:

eUSB repeaters have squelch detection build into the design.  This means there is a very slight delay between the first bit received on the eUSB side, the transmitter is turned on, and the USB side starts transmitting.  What this causes is a "partial bit" on the SYNC portion of the USB backet.  You could say an eUSB repeater "consumes" SYNC bits.  This is one reason why there is a separate electrical compliance tab in the USBET software from USB-IF, because often it causes missing SYNC bits that would not pass typical USB compliance.  If there was a case where two blocks would be together (assuming back-to-back works) then it would consume even more SYNC bits.  This would cause any USB Rx to have difficulty locking onto the incoming USB signal clock and it likely would not detect the end device and enumerate.

This is a tough issue.  Let me know if all of this makes sense.

Regards,

Nicholaus

Hello Nicholaus,

At first, Thank you much for the help!

But it seems, unfortunately, there is no possible solution for my case. At this moment I will use USB hubs and upgrade USB MUX to newer model. 

Regards,

Yaroslav.

Hi Yaroslav, 

It was my pleasure.  Sorry we couldn't find an answer.  Best of luck!

Regards,

Nicholaus