4 Configuring the TUSB1044 Redriver Through I2C3

The TUSB1044 is responsible for routing and conditioning the high-speed signals (USB3 SuperSpeed lanes and optionally DisplayPort lanes) based on the Type-C cable orientation and the Alternate Mode state. Normally, the TUSB1044 can operate in a pin-controlled (GPIO) mode, but in this design we use I2C control mode to have fine-grained, dynamic control through the PD controller. Through the TPS65992S I2C controller, the TUSB1044 is configured at various events: port power-on, cable attach (with orientation), and DisplayPort mode entry. All TUSB1044-related I2C commands are assigned to Address Index 1 (peripheral address 0x12) and occupy event indices 9–28 in the PD controller table.

Key registers of the TUSB1044 used in our configuration include:

• General_1 (Register 0x0A): This register controls the TUSB1044 operating mode and certain overrides. Important fields in 0x0A:
  • Bits [1:0] CTLSEL – Select the data mode: 0 = All channels disabled, 1 = USB3 only enabled, 2 = four lanes of DisplayPort (DP only) enabled, 3 = USB3 + two lanes of DP enabled.
  • Bit [2] FLIP_SEL – Sets the orientation (flip) of the high-speed mux: 0 = normal orientation, 1 = flipped orientation.
  • Bit [4] EQ_OVERRIDE – When set to 1, enables use of EQ settings from I2C registers (overriding the pin-strapped EQ levels). We enable this to allow programming the EQ through I2C.
  • Bit [5] SWAP_SEL – Globally swaps direction of channels (DFP versus UFP) if set. In a source device, we typically leave this at 0 (no swap) unless the design needs to invert the direction (for instance, for sink applications). Our configuration as a DP source keeps SWAP_SEL = 0 (the default).
  • Bit [3] HPD_IN_OVERRIDE – Not used in our flow (controls HPD input override, used in sink applications).

• General_3 (Register 0x0C): Controls the VOD (Voltage Output Differential) and DC gain settings for the redriver, as well as a field for setting the port data role (Dir) in I2C mode. Fields of interest:

  • Bit [6] VOD_DCGAIN_OVERRIDE – 1 to override VOD/DC gain pins and use register settings. We set this to 1 to program the amplitude via I2C.

  • Bits [5:2] VOD_DCGAIN_SEL – 4-bit composite field that selects the VOD linearity and DC gain setting for all channels. This essentially encodes the two 2-bit pin settings (CFG1 and CFG0) that otherwise set EQ gain. In our design, we choose a setting that provides appropriate signal amplitude for the expected cable lengths. (In the provided configuration, the value written corresponds to a specific pin setting combination – see below).

  • Bits [1:0] DIR_SEL – Sets the device data role: 0 = USB and DP Alt Mode Source, 1 = USB and DP Alt Mode Sink, 2 = USB + Custom Alt Mode Source, 3 = USB + Custom Alt Mode Sink. Our design is a source (for example, a laptop or dock outputting DisplayPort), so we use DIR_SEL = 0.

• EQ Control Registers (0x10, 0x11, 0x20, 0x21): These registers configure the equalization settings for each high-speed channel. The TUSB1044 has four high-speed differential pairs (which we can think of as two upstream-facing channels and two downstream-facing channels, each with a TX and RX direction). In I2C mode:

  • 0x10: UFP1_EQ – Bits 7:4 set the TX EQ for the Upstream Port Channel1 (UTx1), bits 3:0 set the RX EQ for Upstream Channel1 (URx1).

  • 0x11: UFP2_EQ – Similarly, for Upstream Channel2 (UTx2 and URx2).

  • 0x20: DFP1_EQ – Bits 7:4 for Downstream Port Channel1 (DTx1, going to the connector), and 3:0 for Downstream RX1 (DRx1).

  • 0x21: DFP2_EQ – EQ settings for Downstream Channel2 (DTx2/DRx2).

By writing to these, we can fine-tune the signal integrity for each lane. In our use case, we program certain EQ values recommended for USB3 and DP signals (the values 0x66 and 0x33 that appear in our configuration correspond to particular EQ gain settings).

Now, here is how the TPS65992S is configured to control the TUSB1044 at various events:

Power-On Reset (Initial Configuration)

On PD controller Power-On Reset, we want the TUSB1044 to start in a safe, disabled state with I2C control enabled. The firmware triggers:

• Write 0x10 to TUSB1044 register 0x0A. The data 0x10 (hex) corresponds to binary 0001_0000. Looking at the bit definitions: this sets bit4 (EQ_OVERRIDE) = 1, and all other lower bits 2:0 = 0 (CTLSEL = 000b, which means all high-speed channels disabled). In other words, we are enabling I2C EQ override but keeping the redriver TX/RX paths off. This is a good default at reset – the redriver does not forward any high-speed signals until we configure the redriver further, and the redriver relies on registers for EQ settings rather than pins. Essentially, 0x10 puts the TUSB1044 into an idle state under software control. (At reset, the TUSB1044 default can also have channels disabled, but writing 0x10 explicitly verifies the correct mode and override bit.)

This command maintains the TUSB1044 is not driving any signals and is ready to be configured for whatever comes next (USB or Alt Mode). This is analogous to holding the redriver in a reset or standby until a cable attach is detected. We also use this same value for other events as needed (like detach) to return to this baseline.

Figure 4-1 Power On Reset Event On Register 0x0A

On a Detach (cable unplug) event, the PD controller sends 0x10 to register 0x0A of the TUSB1044 again. This writes the same value as at power-on: EQ_OVERRIDE = 1, CTLSEL = 0 (channels off). Doing so at detach effectively shuts down the redriver lane switching and returns to default state. Any alternate mode configuration that was in effect is cleared, and the device is ready for a fresh attach sequence next time. In essence, both at initial power and on detach, the TUSB1044 is instructed to disable the switching (no USB3 or DP lanes active) and rely on I2C for further config. This prevents unwanted signal passing or latching of a previous configuration when no device is connected.

(Note: Some designs can also toggle a TUSB1044 hardware reset pin on detach. Using I2C commands as shown can achieve a similar result without extra GPIO toggling, by writing the control registers to a known safe state.)

Figure 4-2 Detach Event On Register 0x0A

Attach Event – Cable Orientation Handling

When a USB-C cable is attached, the TPS65992S detects the orientation (through the CC pins) and also starts USB-PD negotiation. Before even getting to Alternate Mode, the immediate task is to configure the SuperSpeed mux inside TUSB1044 for the correct orientation so that USB3 signals (and future DP signals) route correctly. The TPS65992S firmware distinguishes two orientation cases, often labeled ATTACH_UU and ATTACH_UD (these labels come from the PD controller event definitions – which essentially refer to the Upstream Facing Port Up versus Upstream Facing Port Down orientations, or equivalently cable not flipped versus cable flipped). In simpler terms:

• ATTACH_UU corresponds to orientation where the connector A-side is up (one specific mapping of lanes),
• ATTACH_UD corresponds to the connector rotated 180º (the opposite lane mapping).

For each orientation, we define a sequence of I2C writes to the TUSB1044 to set up for normal USB3 operation (and prepare for potential DP mode):

Attach_UU sequence: (Cable in default orientation) The PD controller issues the following writes in quick succession:

1. 0x11 to register 0x0A: This sets the General_1 register to 0x11 hex (0001_0001 binary). Compared to 0x10, this now has bit0 = 1 (CTLSEL = 001b) while keeping bit4 = 1 and bit2 = 0. CTLSEL = 1 means USB3.1-only mode enabled. So 0x11 turns on the USB3 path through the redriver for the given orientation. Bit2 (FLIP_SEL) is 0 here, meaning assume normal orientation (since this is the UU case). Thus, 0x11 configures the TUSB1044 for USB3 mode, not flipped.

Interpretation: The TUSB1044 connects the SuperSpeed transmit and receive lanes from the host side to the appropriate TX/RX pins on the connector corresponding to a non-flipped plug insertion. DP lanes (if any) remain disabled at this point (because CTLSEL=1 selects USB3-only). EQ_OVERRIDE remains 1, so we use our programmed EQ settings (set in next steps).

1. 0x58 to register 0x0C: We write 0x58 to General_3. In binary 0x58 = 0101_1000. Breaking down:
   • Bit6 = 0x40 is set (0x58 contains 0x40), so VOD_DCGAIN_OVERRIDE = 1 (use register for VOD/DC settings).

   • Bits5:2 = 0b0110. According to the data sheet, this field [5:2] encodes the equivalent of the CFG1 and CFG0 pin settings. 0b0110 corresponds to CFG1=01 (R) and CFG0=10 (F). In other words, we chose a particular VOD/DC gain level (one that can correspond to a medium EQ setting—R and F likely denote resistor and float combinations). This is likely determined from the TUSB1044 data sheet recommendations or lab tuning.

   • Bits1:0 = 0b00, which sets DIR_SEL = 0, indicating Source mode (USB + DP Source). This matches our system role (the TUSB1044 treats the upstream side as the host side and downstream side as the connector side).

So, 0x58 essentially says: use I2C-provided VOD/DC gain, apply a specific gain setting (R-F configuration), and confirm the device is a Source. We write this at attach to maintain that the redriver’s output levels are configured properly for the upcoming signals.

1. 0x66 0x66 to register 0x10: This is a two-byte write to the UFP1_EQ register (0x10). The data 0x66 0x66 sets both the high and low nibbles of UFP1_EQ to 0x6. Specifically, 0x10 controls UFP TX/RX EQ for one pair:
   • 0x66 as a single byte means TX EQ = 0x6 and RX EQ = 0x6 for UFP Channel1. We send two bytes of 0x66, which likely means we intended to also target the next register (0x11) in a single multi-byte sequence (0x10 followed by data for 0x10 and 0x11). However, the configuration listing shows 0x66 0x66 to 0x10, which can actually load 0x10=0x66 and 0x11=0x66 in one go (depending on how the PD tool frames multi-byte writes).

In essence, we are setting all Upstream-facing EQ (both channels) to a mid-level value (0 × 6 is a mid-range setting) for both TX and RX. This can be the recommended EQ setting for the host controller side of the redriver when running USB3 or DP. By doing this, we override the default pin-based EQ and verify signal quality (compensating for board trace loss, and so on).

1. 0x33 0x33 to register 0x20: Another two-byte write, this time to DFP1_EQ (0x20). 0x33 0x33 similarly sets the Downstream-facing (connector side) Channel1 (and possibly Channel2 if two bytes) EQ settings to 0x3 for both TX and RX. A value of 0x3 is a bit lower gain than 0x6 – this can reflect that the connection from the redriver to the connector is shorter or the default requirement for the cable. Essentially, we program the Downstream (USB-C connector) EQ for both channels as well.

The combination of the above EQ settings (0x6 on UFP side, 0x3 on DFP side) is likely determined by TI’s guidelines or lab tuning to pass the USB3 signal integrity and compliance tests for the given PCB and connector.

These four writes (0x0A, 0x0C, 0x10, 0x20) complete the Attach_UU configuration. At this point, for a non-flipped cable insertion, the TUSB1044 is set to active USB3 mode: the correct high-speed lanes are connected, and the EQ/gain is tuned.

Attach_UD sequence: (Cable flipped orientation) When the cable is inverted, the PD controller instead triggers the ATTACH_UD events. The sequence is very similar, but with differences where orientation matters:

1. 0x15 to register 0x0A: 0x15 hex = 0001_0101 binary. Comparing to 0x11 (0001_0001):

   • Bit2 (FLIP_SEL) is now 1 (since 0x15 has bit2 set, as 0x15 = 21 decimal, which includes 0x04).
   • Bits1:0 are still 01 (CTLSEL = 1, USB3-only mode).

   • Bit4 remains 1 (EQ_OVERRIDE on).

     So 0x15 configures USB3-only enabled, but with the orientation flipped. This tells the TUSB1044 to route the lanes accordingly (the A-port and B-port lanes are swapped relative to the device internal mux). Essentially, the device connects the USB3 signals to the opposite set of high-speed pins compared to the UU case, to account for the flipped cable.

2. 0x58 to 0x0C: The General_3 register gets the same 0x58 value as before. This is actually independent of orientation – the VOD/DC gain setting and DIR (source) remain the same regardless of flip. So we use the identical 0x58 configuration for both UU and UD. (This makes sense: flip orientation does not change the fact we are a source with certain EQ preferences; this only changes which physical channels carry the signals.)
3. 0x66 0x66 to 0x10: We again write the same EQ settings to the UFP EQ registers. Here we must consider: in flipped orientation, which TUSB1044 channels correspond to which physical connection? The device swaps the usage of the Channel1 versus Channel2 for the lanes, as indicated by FLIP_SEL. However, by writing the same values to both UFP channels (0x10 and 0x11 both = 0x66 via the two-byte sequence), we verify that regardless of which channel becomes the actual TX/RX for USB, the EQ is set to 0x6. In other words, both upstream channels have identical EQ in our configuration, so a flip does not require different values due to symmetry.
4. 0x33 0x33 to 0x20: Similarly, we set both downstream channels’ EQ to 0x3 (0x20 and 0x21 both get 0x33 via the multi-byte write). This symmetry means the UD case uses the same EQ strength on both possible connector orientations.

The result is that the UD sequence only differs in the 0x0A register value (0x15 versus 0x11). All other register writes (0x0C, 0x10, 0x20 and data) are identical between UU and UD attaches. This makes sense: the only thing that changes is the flip bit, which tells the redriver which way to route the lanes. By comparing the two, we see that 0x0A = 0x11 versus 0x15 is a difference of 0x04, which indeed corresponds to the FLIP_SEL bit. Everything else (EQ gains, and so on) remain constant, showing that our design does not require different gain settings for flipped versus unflipped – treating them the same electrically.

After an Attach event sequence (UU or UD), the TUSB1044 is configured for normal USB3 operation. If no Alternate Mode is initiated, the system continues to operate with USB3 traffic flowing through the redriver. The PD controller job at attach is essentially done: this maintains the high-speed paths are correctly oriented and optimized.

Figure 4-3 Attach Event On Register 0x0A

Figure 4-4 Attach Event On Register 0x0C

Figure 4-5 Attach Event On Register 0x10

Figure 4-6 Attach Event On Register 0x20

Figure 4-7 Attach Event On Register 0x0A

Figure 4-8 Attach Event On Register 0x0C

Figure 4-9 Attach Event On Register 0x10

Figure 4-10 Attach Event On Register 0x20

DisplayPort Alternate Mode Configuration

If the connected partner (sink device, for example, a monitor or docking station) supports DisplayPort Alternate Mode and the PD negotiation enters that mode, additional I2C events are triggered to reconfigure the TUSB1044 for DisplayPort operation. In our PD controller configuration, we have defined events corresponding to specific DisplayPort configuration steps, labeled for convenience as DP_CONFIG_ACE and DP_CONFIG_BDF, each with variants for orientation (UU or UD). These labels refer to the standard USB-C DisplayPort pin assignments – typically, pin assignments C and E versus B, D and F. In essence, the PD controller uses different configuration sequences depending on how the four high-speed lanes are going to be used for DisplayPort. One configuration can be for 4-lane DisplayPort (no USB3 data), and another for 2-lane DisplayPort + USB3 operation, which are common modes for DP Alt Mode. The exact naming (ACE, BDF) comes from the fact that a source can advertise support for certain pin maps (for example, pin assignment C or E for 4-lane, and pin assignment D or F for 2-lane+USB). Our configuration maintains that the TUSB1044 is properly set for the lane routing and EQ in each scenario.

We summarize the sequences:

• DP_CONFIG_ACE_UU: This event corresponds to entering a DisplayPort Alt Mode configuration that uses (A,C,E) mapping in a non-flipped orientation. In this mode, typically all four lanes are devoted to DP (USB3 is dropped). The PD controller writes:
  • 0x1A to 0x0A: 0x1A hex = 0001_1010 binary. Bits [1:0] = 10 (CTLSEL = 2), which per TUSB1044 means 4 lanes of DisplayPort enabled. Bit2 = 0 (UU orientation), Bit4 = 1 (EQ override still on). So 0x1A switches the redriver to DP mode (all lanes carry DP) in normal orientation.
  • 0x55 0x55 to 0x10: A two-byte write to UFP1_EQ (and UFP2_EQ). The data 55 55 sets the upstream EQ registers to 0x55 each. Breaking 0x55: that is 0x5 for TX and 0x5 for RX on each channel. So in DP mode, we are using a slightly different EQ setting for the upstream side: 0x5 (which is a bit lower than the 0x6 we used for USB). This can be to optimize DP signal quality (since DP signals can have different equalization needs or the DP source can do some EQ).

We do not explicitly see a write to 0x20 in this event (suggesting possibly the downstream EQ remains as set, or is not needed to change for 4-lane DP UU). The assumption is that the downstream (connector-facing) EQ can remain at whatever was last set (0x33 from attach). This is plausible because whether carrying USB or DP, the physical channel characteristics to the connector do not change; however, one can also adjust them for DP frequency. In our configuration table, no new 0x20 write is listed for ACE_UU, so we keep the same 0x33 0x33 on DFP EQ as previously.

• DP_CONFIG_ACE_UD: This is the flipped orientation counterpart to the above:
  • 0x1E to 0x0A: 0x1E hex = 0001_1110. Bits [1:0] = 10 (CTLSEL = 2, still 4-lane DP), Bit2 = 1 (flip orientation), Bit4 = 1 (EQ override on). So 0x1E means DP 4-lane mode, flipped orientation.

  • 0x55 0x55 to 0x10: The same 55 55 data to the UFP EQ registers. We see again that the only difference between ACE_UU and ACE_UD is the 0x0A value (0x1A versus 0x1E). That 0x04 difference indicates the flip bit, exactly as with attach events. Register 0x10’s data remains 0x55 0x55 (no change due to flip, since again we set both channels to identical values).

As before, no new DFP EQ write is shown for ACE_UD either, implying the DFP side EQ is unchanged by this DP mode entry in our sequence.

• DP_CONFIG_BDF_UU: This corresponds to a different pin assignment scenario – likely 2 lanes of DP (B and D) + USB3 (F). In this case, the PD controller writes:

  • 0x1B to 0x0A: 0x1B hex = 0001_1011. Bits [1:0] = 11 (CTLSEL = 3), which means “USB3 + 2 lanes of DP” mode. Bit2 = 0 (no flip, UU), Bit4 = 1 (EQ override on). So 0x1B configures the TUSB1044 to route two of the four lanes for DP and keep one lane pair for USB3, in normal orientation. This corresponds to, for example, using two lanes for DP (HBR lanes) and leaving the other two lanes for the USB3 TX/RX.
  • 0x66 0x55 to 0x10: Here we have a two-byte sequence to UFP EQ registers with data 66 55. This is different from previous cases. Likely meaning: UFP1_EQ = 0x66, UFP2_EQ = 0x55 (since the first byte 0x66 goes to reg 0x10, second byte 0x55 to reg 0x11). In effect, we are setting one upstream channel EQ to 0x6 and the other to 0x5. Why? Because in the BDF scenario, one of the upstream channels is carrying USB3 (which we previously tuned to 0x6), and the other is carrying DP (for which we decided 0x5 was sufficient). So Channel1 (say, the one still for USB3) can use EQ = 6, while Channel2 (carrying DP lanes) uses EQ = 5. The ordering of 0x66 0x55 suggests: UFP1_EQ = 0x66 (for the USB3 channel), UFP2_EQ = 0x55 (for the DP channel).
  • 0x33 0x33 to 0x20: A two-byte write to DFP1_EQ (0x20) and DFP2_EQ (0x21) with 33 33. This sets both downstream channel EQ to 0x3 (same as before) regardless of the carried signals. Interestingly, the table suggests that in BDF_UU, 0x20 did not update (even though this is the same values as attach). Perhaps this is done just to maintain that the DP lane outputs (which now possibly occupy different physical lines) are set to known EQ. In any case, DFP1_EQ and DFP2_EQ are both 0x33, which is symmetric and unchanged from prior values.

• DP_CONFIG_BDF_UD: The flipped case for the 2-lane DP + USB scenario:

  • 0x1F to 0x0A: 0x1F hex = 0001_1111. Bits [1:0] = 11 (USB3 + 2DP), Bit2 = 1 (flipped), Bit4 = 1 (override on). So 0x1F is essentially 0x1B with the flip bit added (0x04), meaning “USB3 + 2DP in flipped orientation.”
  • 0x55 0x66 to 0x10: Data 55 66 is written starting at 0x10. This presumably sets UFP1_EQ = 0x55 and UFP2_EQ = 0x66. Why the swap of bytes compared to the UU case? Because when flipped, the role of the two upstream channels in terms of which carries USB versus DP can swap. In UU, we assumed Channel1 was USB, Channel2 was DP (leading to 66 for channel1, 55 for channel2). In UD orientation, the physical routing can cause the opposite assignment – Channel1 can end up carrying DP and Channel2 carrying USB3 (depending on how the lanes flip). The PD configuration anticipates this by swapping the EQ settings: now channel1 gets 0x5 and channel2 gets 0x6. This maintains that whichever channel is handling USB3 has the higher EQ (0x6) and the one handling DP has 0x5, even when flipped. The explicit difference between BDF_UU and BDF_UD configurations (66 55 versus 55 66) highlights how orientation flip can require swapping lane-specific settings.
  • 0x33 0x33 to 0x20: As with UU, we write 0x33 0x33 to DFP EQ registers. In BDF_UD, this is likely the same action: keep both downstream channels at EQ = 3. Since flip doesn’t really change the fact both connector lanes (two of them carrying DP, the others carrying USB and possibly one unused) have the same EQ, we leave them as is.

To summarize the DP configurations: The PD controller uses two sets of events corresponding to the two main DP Alt Mode configurations (4-lane versus 2-lane) and handles both orientations for each. In each case, this writes a new value to register 0x0A to switch the TUSB1044 mode (DP or DP+USB, and set the flip state), and adjusts the EQ registers 0x10/0x11 (and sometimes 0x20/0x21) to maintain signal integrity for the new mode. The values chosen (0x1A/1E, 0x1B/1F for reg0x0A, and the various EQ codes) are derived from the TUSB1044’s requirements:

• 0x0A values: Differ mostly in the low 3 bits. CTLSEL = 2 for DP-only, = 3 for DP+USB; FLIP=0 or 1 for orientation. Bit4 is always kept 1 (we always use EQ override mode).

• EQ values: We used 0x6 for USB3 channels and 0x5 for DP channels on the upstream side, and 0x3 universally on the downstream side. These specific codes come from either TI’s reference design or lab tuning to meet USB3 Gen2 and DP HBR2/HBR3 compliance. The important part is not the exact number, but that the PD controller can alter them as needed depending on scenario. For instance, if a particular design needed different EQ for a longer cable detected, the firmware potentially uses different values (though our example keeps them fixed per mode).

Once the DisplayPort configuration events have executed, the TUSB1044 is fully in Alt Mode configuration: lanes are routed to carry DisplayPort from the system’s GPU through the redriver to the USB-C connector, and (if in the BDF case) two of the lanes continue carrying the USB3 data. The PD controller active involvement ends here, and the system transmits DisplayPort AUX handshake etc. to set up monitors as usual. The TUSB1044, being protocol-agnostic, simply passes through the high-speed signals; we have effectively just controlled the switches and gains through I2C.

Figure 4-11 DP assignment ACE config event on register 0x0A

Figure 4-12 DP assignment ACE config event on register 0x10

Figure 4-13 DP assignment ACE config event on register 0x0A

Figure 4-14 DP assignment ACE config event on register 0x10

Figure 4-15 DP assignment BDF config event on register 0x0A

Figure 4-16 DP assignment BDF config event on register 0x10

Figure 4-17 DP assignment BDF config event on register 0x20

Figure 4-18 DP assignment BDF config event on register 0x0A

Figure 4-19 DP assignment BDF config event on register 0x10

Figure 4-20 DP assignment BDF config event on register 0x20

Through these attach and DP config event handlers, the TPS65992S maintains that the TUSB1044 is properly configured at every stage: initial attach (for USB 3.2 SuperSpeed or baseline operation) and during the transition into DisplayPort Alternate Mode. All necessary I2C writes are automated by the PD controller firmware once configured, eliminating the need for a dedicated EC or MCU to handle the redriver settings in real time.