Interface forum - Recent Threads

TUSB8041A: TDA4VH-based, 2x USB-C 3.1 Camera + 1x USB-A 2.0

Brian Wang0928 — Sat, 08 Aug 2026 09:07:59 GMT

Part Number: TUSB8041A

Hi Team,

Industrial Customer are designing the USB interface for a 6-axis industrial robotics controller based on the TDA4VH SoC, and would like your confirmation on our proposed architecture before customer finalize the schematic and PCB layout.

== Requirements ==

- 2x USB 3.1 Type-C ports, each connecting to a 2K USB camera (data + power, no display/alt-mode needed)

- 1x USB 2.0 Type-A port for a general host peripheral

- Single USB0 controller on TDA4VH (2.0 data + SuperSpeed TX/RX, ID, VBUS) as the only upstream source

- Camera ports need correct SuperSpeed lane orientation handling for cable flip (Type-C reversibility)

- 5V/up to 3A per camera port is sufficient; full USB-PD voltage negotiation (9V/12V/20V) is not required

Current proposed architecture :

We would appreciate your review and any recommended reference design or application note that matches this use case.

DS90UB947-Q1EVM: DS90UB947-Q1EVM: How t configre Dual OLDI mode (Continued)

user4779049 — Sat, 25 Jul 2026 04:27:50 GMT

Part Number: DS90UB947-Q1EVM

Nikolas-san,

I previously posted under the same subject line, but it seems the thread
was full and would not accept a reply.
Therefore, I am posting again with the same subject line, adding "(continued)"
to the title.

You commented that the connection between the FPGA and the UB947 is not OLDI.
I would li

Thank you for your reply.

The UB947 uses a Dual OLDI input.
Inside the FPGA, data lanes D0–D3 and D4–D7 are sampled using a single clock.
Consequently, the skew between these data groups is properly managed, and the
data represents the same timing instance.

The clock used within the FPGA is copied and output to each OLDI port.
On the UB947 side, the clock from the second OLDI input is ignored; however,
since the skew of data lanes D0–D7 is managed, they can be sampled using a
single clock.

Mita

RE: DS90UB947-Q1EVM: DS90UB947-Q1EVM: How t configre Dual OLDI mode (Continued)

user4779049 — Fri, 07 Aug 2026 23:34:19 GMT

Esther-san,

Thank you for your reply.
I truly appreciate the sincere way you answered my
persistent questions.
I, too, look forward to working with you.
Have a wonderful day.

Mita

RE: DP83815: Initialization sequence for DP83T815

David Creger — Fri, 07 Aug 2026 22:47:00 GMT

Hi Annwesa,

Yes, sequence looks good.

MDI master/slave and RMII master/slave are two different topics. Both can be independently chosen by strap selection, shown in section 7.5 of the datasheet.

Thanks,

David

DP83815: Initialization sequence for DP83T815

Joao Goncalves — Tue, 28 Jul 2026 08:56:01 GMT

Part Number: DP83815

Hello Team,

We have integrated the Master and Slave Mode configurations exactly as defined in the application note Configuring for Open Alliance Specification Compliance (excluding the optional emission reduction steps).In addition to the baseline configuration, we write to several registers to configure custom hardware requirements like Duplex Mode, RMII, and Autonomous Mode.Our Questions for Verification:

1- Could you please review our attached initialization sequence (registers and values) and confirm if the overall sequence is correct?

2- We understand that enabling features like RMII Master (via Register 0initSequence 1.xlsx x0648) and Managed Mode (via Register 0x018C) requires writing to these specific registers in addition to the standard baseline register sets outlined in Table 3-1 and Table 3-2 of the application note. Is this understanding correct, and are there any specific sequence constraints we should observe when blending these additional writes with the baseline sequence?

Thank you for your support.

Best Regards

DP83867CS: Issue accessing MDIO registers

William John — Tue, 07 Jul 2026 17:05:52 GMT

Part Number: DP83867CS

I'm having trouble bringing up a custom board using the DP83867, no matter what register I read from over MDIO the PHY always responds with 0xB305.

Any suggestions what might cause this?

Oscilloscope trace:

RE: DP83867CS: Issue accessing MDIO registers

Shane Hauser — Fri, 07 Aug 2026 22:13:21 GMT

Hi Will,

Apologies for the delay. Here are my thoughts based on the test results of your DUT:

1. Having to toggle the PWDN, RESET, and Standby modes of the PHY should not be necessary to get MDIO/MDC or SGMII communication. The EVM communicates without this procedure, so something in the design itself seems to be causing this.

2. This does not seem unit-specific since you see the same behavior on all of your boards/PHYs. An ABA swap between the PHY on the EVM and the PHY on the DUT would be the sure-fire way to show this.

3. I can think of the following discrepancies between the EVM and the DUT PHYs that may contribute to this:

Power up timings/stability of power rails
Clocking
Strapping/component implementations
- Schematic looks ok, though it may be good to measure the voltage level of the strap pins on startup to ensure all straps are correct. You could compare these with the strap voltages on the EVM as a reference.
MDIO controller/connection

4. If MDIO/MDC was the only symptom of the issue I would suspect the MDIO controller. What interests me further is that the SGMII interface does not operate after powerup as well. Typically when two seemingly unrelated functions of the PHY are not operating, particularly the MDIO bus, it suggests an initialization issue on the PHY. This is my thought process for digging into the power up and clocking.

5. Since there is a similar setup working with the EVM it would be good to compare the two to see what difference would lead to this behavior. For instance I see the MDC plot shows an odd starting waveform at the powerup of the PHY on the DUT. I am curious if you see the same waveform with your powerup test on the EVM + FPGA setup. I remember you mentioned using a similar MDC/MDIO connection between the EVM+FPGA and the DUT, however if there is some way to use the same FPGA on the DUT PHY it would be more 1:1.

6. It is certainly a good observation that the register access and the SGMII begin working in standby mode. To me this seems to be a symptom of some larger issue in the initialization of the PHY. Rather than investigating the symptom, I would prefer to look at what difference between the EVM and the DUT could cause these discrepancies.

Best,

Shane

SN65C3221-Q1: bsolescence report for the components listed below.

Hardware Intern — Fri, 07 Aug 2026 09:24:46 GMT

Part Number: SN65C3221-Q1

I am writing to request an Moisture sensitivity level (MSL) , Electrostatic disharge(ESD), Grade(Automotive/Industrial/Military) , Storing Tempreture and obsolescence report for the components listed below. Our goal is to ensure long-term availability for a minimum of 10 years.

To assist with our internal tracking, could you please categorize each component according to the following criteria:

Category A: EOL > 10 years
Category B: EOL > 5 years
Category C: NRFD (Not Recommended for New Designs) / Obsolete
Category D:OL not confirmed by manufacturer

Components for Review:

SN65C3221IPWRQ1

RE: SN65C3221-Q1: bsolescence report for the components listed below.

Ethan Sempsrott — Fri, 07 Aug 2026 21:36:23 GMT

MSL: Level-2-260C-1 YEAR

ESD: Please reference the datasheet "ESD Protection" section.

Grade: Auto

Storage temp: -65C to 150C

No obsolescence plan: Category A

SN65LBC179: Storage tempreture of components

Hardware Intern — Fri, 07 Aug 2026 04:59:11 GMT

Part Number: SN65LBC179

I am writing to request an Storing Tempreture and obsolescence report for the components listed below. Our goal is to ensure long-term availability for a minimum of 10 years.

To assist with our internal tracking, could you please categorize each component according to the following criteria:

Category A: EOL > 10 years
Category B: EOL > 5 years
Category C: NRFD (Not Recommended for New Designs) / Obsolete
Category D:OL not confirmed by manufacturer

Components for Review:
SN65LBC179QDR

RE: SN65LBC179: Storage tempreture of components

Ethan Sempsrott — Fri, 07 Aug 2026 21:33:47 GMT

Storage temp: We do not have a rated temp for this. You can put down -40C to 165C (this is the operating air temp and the max junction temp).

No obsolescence plan: Category A

THVD2452V-EP: obsolescence report for the components listed below

Hardware Intern — Fri, 07 Aug 2026 06:09:51 GMT

Part Number: THVD2452V-EP

I am writing to request an Grade(Automotive/Industrial/Military) , Storing Tempreture and obsolescence report for the components listed below. Our goal is to ensure long-term availability for a minimum of 10 years.

To assist with our internal tracking, could you please categorize each component according to the following criteria:

Category A: EOL > 10 years
Category B: EOL > 5 years
Category C: NRFD (Not Recommended for New Designs) / Obsolete
Category D:OL not confirmed by manufacturer

Components for Review:
THVD2452VDREP

RE: THVD2452V-EP: obsolescence report for the components listed below

Ethan Sempsrott — Fri, 07 Aug 2026 21:30:56 GMT

Grade: HiRel Enhanced Product (closest to Industrial)

Storage temp: -65 to 170C

No obsolescence plan: Category A

RE: TCAN1145-Q1: Question regarding TCAN1145 Fail-safe Exit Behavior and Wake Event Retention

Ethan Sempsrott — Fri, 07 Aug 2026 21:28:31 GMT

Thanks for reaching out on E2E. I was recently out of office so I am catching up on E2E questions. You can expect a response from me early next week.

TCAN1145-Q1: Question regarding TCAN1145 Fail-safe Exit Behavior and Wake Event Retention

Vishva Vijenayake — Fri, 07 Aug 2026 06:29:27 GMT

Part Number: TCAN1145-Q1

While reviewing the TCAN1145-Q1 datasheet, I noticed that the device can enter Fail-safe mode due to faults such as UVIO or UVCC and can subsequently exit Fail-safe mode after faults are cleared and a wake event occurs.

I would like clarification on the intended handling of wake events during the fault period:

If a valid wake event (WUP, WUF, or LWU) is detected while the device is in Fail-safe mode or while UVIO/UVCC fault conditions are active, is that wake event internally retained/latched and acted upon once the faults clear?

Alternatively,

Are wake events that occur during the fault condition disregarded, requiring a new wake event after fault recovery before the device is allowed to transition to Standby mode?

I could not find explicit guidance in the datasheet regarding whether wake requests are preserved across fault recovery or whether a wake event must occur only after all relevant faults have been cleared.

Any clarification on the intended TCAN1145 behavior would be appreciated.

THVD2410V: Request for conducted or radiated emissions measurements comparing 250kbps & 1Mbps operation

George Tzanatos52 — Tue, 04 Aug 2026 03:14:00 GMT

Part Number: THVD2410V

Hi,

Are emissions (conducted or radiated) measurements available for the THVD2410V operating on unshielded cable and comparing the difference between 250kbps and 1Mbps operation?

Kind regards,

George Tzanatos.

RE: THVD2410V: Request for conducted or radiated emissions measurements comparing 250kbps & 1Mbps operation

Ethan Sempsrott — Fri, 07 Aug 2026 21:26:21 GMT

[quote userid="300459" url="~/support/interface-group/interface/f/interface-forum/1670039/thvd2410v-request-for-conducted-or-radiated-emissions-measurements-comparing-250kbps-1mbps-operation/6443334"]Across the TI RS485 portfolio, do you have any comparison data between 250kbps limited drivers and related family members operating in the 500kbps...5Mbps rates?[/quote]

Are you asking if we have any emissions data at those data rates? If so, the answer is still a no unfortunately.

We don't have much data in this area because RS-485 rarely (if ever) needs emissions testing, at least from a supplier perspective. It is up to the designer to follow/meet their particular standards.

Best,

Ethan

TPS4816-Q1: schematic check

GARETH OU — Mon, 29 Jun 2026 16:53:38 GMT

Part Number: TPS4816-Q1

Currently, power is not supplied; the FLT displays "low," and pins 16 and 13 are both "low." Please suggest where the schematic needs adjustment. Thanks

tps4816q1.pdf

RE: TPS4816-Q1: schematic check

Sarah Raines — Fri, 07 Aug 2026 21:23:43 GMT

Hi Gareth,

I am not finding precise explanation for FLT, but am seeing something odd here.

I assume your BST and SRC waveforms are mislabeled. If so it looks like the BST is charging before the EN pin actually reaches EN HIGH. Are you pre biasing the CBST?

Thanks,

Sarah

DS90UB960-Q1: Error injection mechanism for Deser DS90UB960-Q1 and Ser DS90UB935-Q1

Sachin Chandran — Fri, 07 Aug 2026 17:20:55 GMT

Part Number: DS90UB960-Q1

Hello Team,

As part of our project we are using Deser DS90UB960-Q1 and Ser DS90UB935-Q1 in our product.

We would like to get clarification of the error injection mechanisms to validate the below mentioned errors. This is essential for designing error monitoring and handling for our product.

Deser reported errors:

RX_PORT_STS1 Register (Address = 0x4D):
BCC_CRC_ERROR
BCC_ERROR
PARITY_ERROR
LOCK_STS
PORT_PASS

RX_PORT_STS2 Register (Address = 0x4E):
LINE_LEN_UNSTABLE
LINE_LEN_CHG
FPD3_ENCODE_ERROR
BUFFER_ERROR
FREQ_STABLE
NO_FPD3_CLK

CSI_RX_STS Register (Address = 0x7A):
LINE_CNT_CHG
LENGTH_ERR
CKSUM_ERR
ECC2_ERR
ECC1_ERR

Ser reported errors:

CSI errors reported via alarm:

CSI_ERR_DLANE01 (Address 0x5E):
SOT_ERROR_1
SOT_SYNC_ERROR_1
CNTRL_ERR_HSRQST_1
SOT_ERROR_0
SOT_SYNC_ERROR_0
CNTRL_ERR_HSRQST_0

CSI_ERR_CLK_LANE (Address 0x60)
CNTRL_ERR_HSRQST_CK0

Back channel errors reported via BC alarm:

GENERAL_STATUS (Address 0x52)
BC_CRC

RE: DS90UB960-Q1: Error injection mechanism for Deser DS90UB960-Q1 and Ser DS90UB935-Q1

Justin Phan — Fri, 07 Aug 2026 21:06:58 GMT

Hello Sachin,

To what level are you looking to inject errors?

For a majority of these, there is not a software solution to inject errors. For example, the CSI_ERR_DLANE01 register field would only flag errors if there is incoming MIPI packets with errors. To inject an error, you would either have to misprogram an image sensor so that it outputs faulty MIPI data. Or connect the MIPI TX from an imager to the MIPI RX of the 935 serializer, but intentionally do bad length matching or PCB routing, to get errors. Maybe even doing lab tests where you short some MIPI pin to GND during normal video transmission, to corrupt the MIPI data and get errors.

Are you looking for suggestions on how to trigger each error flag, whether its SW or HW test methodology?

Best,

Justin Phan

AFE1594EVM: AFE1594EVM daughter board pinout

Elettra Giacomin — Thu, 06 Aug 2026 14:49:47 GMT

Part Number: AFE1594EVM

I'm trying to drive the smaller daughter board of the AFE1594 evaluation board (the one housing the two AFE159RP4 chips) using my own MCU and I would like to ask for clarifications regarding the wiring on the four header strips on its underside:

Firstly, how are they oriented compared to the reference schematic in the manual? I want to avoid accidentally shorting the circuit.

Secondly, I'd like to ask for clarification regarding some of the listed pins:

What is the OUT 4M pin on J1.6?
On headers J3 and J4, some pairs of pins (such as J3.1 and J3.2) are wired together and marked with a zero-ohm (?) resistor between them and the external connection. Is this signaling that the user should take care to wire the two pins together and not put any resistance in front of them?
What is the VREF pin on J3.5?
What is the AFE VDD 1P8 (twin) pin on J4.8/J4.9?

Thank you for your attention

RE: AFE1594EVM: AFE1594EVM daughter board pinout

Ryan Andrews — Fri, 07 Aug 2026 20:56:25 GMT

Hi Elettra,

If you look at the top side of the daughterboard, pin 1 of each row for J1-J4 is indicated by a square through-hole.

OUT_4M is an optional external clock input (see related nets throughout the schematic).

There are provisions on the J1-J4 headers which are specific to their use with the provided MCU capture card. The important thing is that the two AFEs receive the proper supply voltages (IOVDD, AFE_3.3V or AFE_5V, and AFE_VDD_1P8). You may use any header connections which are routed to those nets.

You do not need VREF. This is just an optional voltage rail brought to the AFE board for testing options.

Please read the AFE159RP4 datasheet for 1.8V supply connection and usage.

Regards,

Ryan

RE: THVD4411: Technical Inquiry: Unexpected RS232 Loopback Behavior

Ethan Sempsrott — Fri, 07 Aug 2026 20:48:16 GMT

Hi Ajmal,

Thanks for reaching out E2E, and thanks for your patience as I have been out of the office until now.

1. No, this device does not have a "loopback mode." Figure 7-2 shows the proper implementation when MODE1=0, MODE0=1.

2. Refer to 1. I would double check the MODE1 and MODE0 pin settings if you are able. I would also double check the exact part number. The THVD4431 does have loopback mode.

3. Yes, there is a chance. But likely there is a connection somewhere at the hardware level on the PCB.

4. I cannot help with your questions about the UART controller as I only support the THVD4411 transceiver.

[quote userid="711782" url="~/support/interface-group/interface/f/interface-forum/1670532/thvd4411-technical-inquiry-unexpected-rs232-loopback-behavior"]However, when we configured the same port in RS485 full-duplex or half-duplex mode and performed identical tests without any external wiring, we did not observe any data reception on the same port.[/quote]

This is odd. When in RS-485 half duplex mode, you should see the signal loopback. This is because in half duplex mode the pins are internally shorted together. Figure 7-3 shows this in the datasheet.

Best,

Ethan

THVD4411: Technical Inquiry: Unexpected RS232 Loopback Behavior

Ajmal A — Wed, 05 Aug 2026 07:24:54 GMT

Part Number: THVD4411

Dear Support Team,

We are currently evaluating Industrial Gateway and have encountered some behavior regarding the UART interfaces that we would like to clarify.

Environment:

Operating System: Linux
Interfaces: UART ports configured for RS232 and RS485 modes
Test Method: Simple read/write operations to the serial ports

Observed Behavior:

During our evaluation, we conducted a simple serial communication test where we configured a port in RS232 mode and performed write and read operations. We noticed that when no external wiring (loopback connection) was present between the TX and RX pins, data written to the port was still being received by a reading process on the same port.

However, when we configured the same port in RS485 full-duplex or half-duplex mode and performed identical tests without any external wiring, we did not observe any data reception on the same port.

Our Concerns:

Is the self-reception behavior observed in RS232 mode an intentional feature of the board's hardware design or the UART controller? Some UART implementations have internal loopback capabilities for diagnostic purposes.
If this is an intentional feature, is there a way to enable/disable it through hardware configuration or software control?
If this is not intentional, could this be due to signal coupling, ground path issues, or some other electrical phenomenon that might affect normal operation in a real-world application?
Does the UART controller or the interface circuitry have any built-in echo or loopback functionality that might be enabled by default in certain modes?

Context:

Our goal is to understand whether this behavior is expected and to determine if any configuration changes are needed to ensure reliable RS232 communication in our application. Since RS485 does not exhibit similar behavior, we want to confirm that both interfaces are functioning correctly.

Any insights or documentation references you can provide regarding this behavior would be greatly appreciated.

Thank you for your assistance.

Best regards,

Ajmal Aboobakar

Embedded Software Developer