Interface forum - Recent Threads

MAX3223: Transmitter section failure of MAX3223IPW

Anurag Bajpai — Sat, 13 Jun 2026 14:57:10 GMT

Part Number: MAX3223

Hi in one application for MAX3223IPW , the force on is connected with invalid bar pin with zero ohm resistor. By mistake the force on is also connected with ground using zero ohm resistor. Initially the ic was working fine, now the tranmit section on RS 232 is sending garbage while the recive section of rs232 of ic is working fine. Can you tell due the invalid bar pin is connected to ground has done the damage to the IC?

Thank you.

DS90UB983-Q1: Compatibility Inquiry: DS90UB983-Q1 with DS90UB948-Q1 for DP to Dual LVDS Display Application

Madhan Kumar — Sat, 13 Jun 2026 12:37:13 GMT

Part Number: DS90UB983-Q1

I am evaluating a display architecture and would like to confirm the compatibility of the selected devices.

System Architecture:

Board 1:

Mini Display Port (mDP) input from host system
DS90UB983-Q1 serializer
Coaxial cable output

Board 2:

Coaxial cable input
DS90UB948-Q1 deserializer
Dual LVDS output to display panel(s)

The intended signal path is:

mDP Source → DS90UB983-Q1 → Coaxial Cable → DS90UB948-Q1 → Dual LVDS Display

I would like to know:

Is DS90UB983-Q1 compatible with DS90UB948-Q1 in this configuration?
Can the DS90UB983-Q1 establish a valid link with the DS90UB948-Q1 over a coaxial cable?
If they are not directly compatible, could you please recommend the appropriate serializer/deserializer pair for converting a Mini Display Port source to Dual LVDS displays over a coaxial cable?
Are there any reference designs, application notes, or design considerations relevant to this implementation?

Display requirements:

Interface: Mini Display Port input
Transmission medium: Coaxial cable
Display interface: Dual LVDS
Resolution: 1920 * 1080
Refresh rate: 60Hz

Thank you for your support. I look forward to your guidance.

XIO2001EVM: PCI card detection

vara prasad — Sat, 13 Jun 2026 07:16:08 GMT

Part Number: XIO2001EVM

I inserted a PCI card into the EVM slot. When used together, the EVM is detected but the PCI card is not — however, both cards work fine individually in their respective slots on both Linux and Windows.

RE: DP83869HM: Request for Schematic Pre-Check and Ethernet PHY Design Validation – AM2634 + DP83869

phanendra beella — Sat, 13 Jun 2026 04:53:47 GMT

Dear Gregory,
Thank for your response . we are eagerly waiting for your confirmation

DP83869HM: Request for Schematic Pre-Check and Ethernet PHY Design Validation – AM2634 + DP83869

phanendra beella — Tue, 26 May 2026 06:53:41 GMT

Part Number: DP83869HM

Hello TI Team,

I have designed a custom industrial board based on the AM2634COLFHAZCZR (Sitara™ Real-Time MCU) along with the DP83869 Gigabit Ethernet PHY.

Before proceeding with Ethernet bring-up, PHY initialization, and continuous ping stability testing, I would like to request a detailed schematic pre-check and design validation from the TI team to ensure the hardware implementation follows TI recommended guidelines and reference designs.

Our intention is to validate the schematic thoroughly before PCB fabrication/board bring-up to avoid any Ethernet stability.

Processor : AM2634COLFHAZCZR (Sitara™ Real-Time MCU)

Ethernet PHY: DP83869 Gigabit Ethernet PHY

Ethernet Interface: RGMII interface between AM2634 and DP83869

Target Validation:

Ethernet PHY bring-up
MDIO communication verification
PHY link detection
Continuous ping stability testing
Long-duration Ethernet communication validation

Please review the RGMII interface between AM2634 and DP83869.

Signals include:
- TXD[3:0]
- RXD[3:0]
- TX_CTL / RX_CTL
- TX_CLK / RX_CLK
- MDC / MDIO
Please verify:
- Signal connectivity correctness
- IO voltage compatibility
- Pull-up/pull-down requirements
- Trace matching recommendations
- RGMII timing/skew implementation
Specific Questions:
- Should DP83869 be configured with internal delay mode or external PCB delay?
- Are series termination resistors recommended on RGMII signals?
- Are there any layout-critical timing considerations?
  1. Clock Network Verification
  Please review:
  - 25MHz crystal circuit connected to DP83869
  - Crystal load capacitor values
  - Clock routing recommendations
  - Oscillator stability requirements
  Questions:
  - Is the crystal implementation correct as per TI recommendations?
  - Are the load capacitor values appropriate?
    1. PHY Strap Pin Configuration
    Please verify:
    - PHY address strap configuration
    - RGMII mode strap settings
    - Bootstrap resistor values
    - Auto-negotiation configuration
    - LED strap functionality
    Questions:
    - Is the PHY correctly configured for RGMII operation?
    - Is Auto-negotiation enabled correctly by default?
    - Any strap timing or resistor concerns?
      1. Reset Circuit Verification
      Please review:
      - Reset topology for AM2634 and DP83869
      - Reset timing implementation
      - Reset dependency between MCU and PHY
      - Power-on reset behavior
      Questions:
      - Is the reset timing correct?
      - Is the reset sequence proper for reliable PHY initialization?
        
        Request
        
        Kindly review the attached schematic and provide feedback on whether the design is ready for PCB fabrication and hardware bring-up.
        
        Please let us know if:
        
        Any schematic corrections are required
        
        Any layout recommendations should be followed
        
        Any Ethernet timing or PHY configuration changes are needed before fabrication
        CUSTOM_BRD_REV03.pdf

DP83TC815-Q1: DP83TC815-Q1 can not be detected on MDIO bus

gavin zhang — Fri, 12 Jun 2026 04:20:51 GMT

Part Number: DP83TC815-Q1

Hi, TI experts.

On my board, DP83TC815-Q1 can not be detected on MDIO bus. I test the power and reset waveform:

1)3V3(VDDIO,VDDMAC,VDDA3P3,VSLEEP) and 1V0(VDD1P0)waveform:

(yellow is 3.3V ,green is 1.0V)

2)VDD1P0 and reset waveform:

(yellow: reset,green:1V0)

3) test the clock, it is also ok.

schematic is as follows:

DP83TC815 schematic.pdf

Do you have any comments for this issue?

Thanks

Gavin

RE: DP83TC815-Q1: DP83TC815-Q1 can not be detected on MDIO bus

gavin zhang — Sat, 13 Jun 2026 02:26:05 GMT

Hi, Drew

Yes, you are correct, INH is low, this chip is in sleep state.

on my board ,there is no fanout of wake pin, so can I change the DP83TC815 to DP83TC814, they are pin to pin compatible and DP83TC814 do not support TC10. I think I can change bom only, is it correct?

RE: DP83TC815-Q1: DP83TC815-Q1 can not be detected on MDIO bus

Drew Miller1 — Sat, 13 Jun 2026 01:50:55 GMT

Hi Gavin,

I apologize, I mixed up RX_CTRL and RX_CLK. You are correct regarding RX_CTRL.

With RX_CLK floating, TC10 is enabled. PHY may be asleep. You can check INH pin to confirm. INH is high-Z when PHY is asleep, so it would be pulled down by 3.3kOhm in your design. To wake up PHY, pull WAKE pin to VSLEEP.

Thanks,

Drew

RE: DP83TC815-Q1: DP83TC815-Q1 can not be detected on MDIO bus

gavin zhang — Sat, 13 Jun 2026 01:45:51 GMT

Hi, Drew

1. clk_out waveform:

2. For RX_CTRL pin, it is defined as 3-level strap pin on datasheet:

so is it correct?

Thanks

Gavin

RE: TUSB2E221: sch review

Charles (KAT) Zhang — Sat, 13 Jun 2026 01:28:59 GMT

Thank you Ryan!

TUSB2E221: sch review

Charles (KAT) Zhang — Fri, 12 Jun 2026 06:49:42 GMT

Part Number: TUSB2E221

Dear team,

Could you help to review customer TUSB2E221 sch as below?

Thank you~

Charles

AM6442: Ospi flash through UART uniflash

ganesh d — Mon, 08 Jun 2026 15:14:21 GMT

Part Number: AM6442

Hi TI Team,

We are working on a custom AM6442 board using Processor SDK Linux 9.x and would like to boot completely from OSPI flash without using an SD card.

We plan to flash the following images using UART UniFlash:

* tiboot3.bin
* tispl.bin
* u-boot.img
* k3-am642-evm.dtb
* am6-sdk-tiny-fs.ubi

We would like clarification on the following points:

1. Does UART UniFlash support directly flashing a UBIFS image (root.ubifs) to a UBI volume, or does it only support flashing a UBI image (root.ubi)?
2. If root.ubifs is supported, how are the UBI volume creation and UBI attach operations handled during flashing?
3. Is it recommended to generate and flash a root.ubi image instead of root.ubifs for production programming?
4. Could you provide an example UART UniFlash configuration file for flashing the above images to OSPI flash?
5. After flashing, what are the required bootargs and partition settings to ensure the kernel automatically attaches the UBI partition and mounts the UBIFS root filesystem?

Any guidance or reference documentation would be appreciated.

Thanks,

Ganesh D

RE: AM6442: Ospi flash through UART uniflash

Bin Liu — Sat, 13 Jun 2026 01:03:13 GMT

Hi Ganesh,

I will review this later next week and get back to you.

THVD2452V-EP: DE and RE# Tied Together?

Filipe Rubinstein — Fri, 12 Jun 2026 12:55:47 GMT

Part Number: THVD2452V-EP

Hi Team,

I am investigating the THVD2452-EP and whether or not this device can be configured as a half-duplex. However, one question that came up is whether the signal pins DE & RE# be tied together so a single source can be used? In addition, I'm not sure whether the logic levels internal to the part will dictate whether to enable DE or RE#.

Is the team able to provide any guidance here on how to achieve this with the THVD2452-SP?

Thank you,

Filipe Rubinstein

RE: THVD2452V-EP: DE and RE# Tied Together?

Ethan Sempsrott — Sat, 13 Jun 2026 00:22:49 GMT

Hi Filipe,

Yes, they can short the bus pins to achieve half-duplex. They can also short /RE and DE together so only one GPIO is needed to control the mode. This is a very common implementation. When they driver the line high, the driver will be enabled and the receiver will be disabled, and vice versa.

Best,

Ethan

RE: THVD1424:Question about IEC ESD/EFT rating acceptance criteria for THVD1424

Ethan Sempsrott — Sat, 13 Jun 2026 00:19:59 GMT

No, the resistor does not need an ESD rating. The transceiver will still achieve its ESD rating regardless.

THVD1424:Question about IEC ESD/EFT rating acceptance criteria for THVD1424

kz_sk — Wed, 10 Jun 2026 06:20:36 GMT

Part Number: THVD1424

Regarding the THVD1424 datasheet, Section 6.3 "ESD Ratings [IEC]", the device is specified as:

IEC 61000-4-2 Contact Discharge: ±8 kV
IEC 61000-4-4 EFT: ±4 kV

Could you clarify what acceptance criterion was used to determine these ratings?

For example, are these ratings intended to indicate:

No permanent damage to the transceiver (device survives the test), or
Compliance with a specific IEC performance criterion (A, B, C, or D)?

In other words, during the IEC 61000-4-2 and IEC 61000-4-4 tests, was normal communication operation maintained, or was the criterion simply that the device remained functional after the test?

Thank you.

Quoted from "slva711.pdf"　↓

Results of the surge test should be classified according to the loss of function and degradation. From most protected systems to the least, the classes in the IEC 61000-4-5 are:

(A) Normal performance within the limits specified by the manufacturer, requester or purchaser.

(B) Temporary loss of function or temporary degradation of performance not requiring an operator.

(D) Loss of function or degradation of performance which is not recoverable, owing to damage of the hardware or software, or loss of data. Class A is for the most reliable applications. Class D is usually not acceptable to the manufacturers.

TCAN1145-Q1: Problem with CAN transceiver TCAN1145-Q1

Jan Thorstensson — Fri, 12 Jun 2026 05:21:17 GMT

Part Number: TCAN1145-Q1

We have experienced a couple of TCAN1145-Q1 failing when exposed to a wiring short circuit between CANL and GND.
After failing, the DC-resistance between CANL and GND was found to be approx. 5ohm when non-powered. Similar on both IC:s, obviously EOS damage.

The TCAN1145-Q1 is used combined with a Murata DLW32SH101XF2 common-mode choke in this application.

Both simulations and bench tests indicate that the CM choke causes negative transients at the transceiver CANL port at the trailing edge of every CAN bit sent.
Those transients are being clamped to approx. -60V by internal transceiver TVS

However, the energy absorbed by the TVS during these pulses is very small, less than 700nJ per pulse.
Even when using extremely unfavourable conditions (such as 25V GND voltage offset), energy never exceeds 1.5uJ.

The datasheet for TCAN1145 indirectly suggest there are internal TVS diodes on CANL and CANH clamping at approx. ±60V. This has also been confirmed in bench tests.
The 8kV CD ESD-spec implies that these TVS diodes should be able to handle at least 83uJ
ISO 7637-2 pulse 1 appears to subject internal TVS diodes to approx. 5mJ, pulse 2 approx. 1mJ

TI Application Report “SLLA271 - January 2008”
This report suggests that a CM choke may cause dangerous transient voltages whenever the CAN bus is shorted to VBAT or GND
The recommended solution is to add external TVS diodes between CM-choke and transceiver.

Question 1: Is such external TVS diodes really necessary for TCAN1145-Q1, which apparently has internal TVS diodes able to clamp pulses with 1000x higher energy than typically caused by the CM choke. I.e. is it highly recommended to design according to the Application Report SLLA271 - January 2008?
Question 2: Is the transceivers ability to survive ± 58V fully tested in production? Could there be individuals that may fail before the internal clamping goes into action?
Question 3: Is the internal clamping function fully tested in production? Or could the clamping simply be missing on certain individuals?

Question 4: Is the indirect estimation of TVS energy limits, based on ESD and ISO7637-ratings, reasonable?

slla271.pdf

RE: TCAN1145-Q1: Problem with CAN transceiver TCAN1145-Q1

Ethan Sempsrott — Sat, 13 Jun 2026 00:16:28 GMT

Hi Jan,

Thanks for reaching out on E2E.

So you are saying that when CANL is shorted to GND, TCAN1145 is permanently damaged? Did you check to see if CANH is shorted to GND well?

Yes, shorting any supply at or above 12V to CANH/L can be a problem with a CMC as that app note shows. However, shorting CANL to GND with a CMC should not be a problem at all.

[quote userid="703723" url="~/support/interface-group/interface/f/interface-forum/1654794/tcan1145-q1-problem-with-can-transceiver-tcan1145-q1"]Both simulations and bench tests indicate that the CM choke causes negative transients at the transceiver CANL port at the trailing edge of every CAN bit sent.[/quote]

During those tests, was CANL shorted to GND? Or was CANH and CANL in normal operating conditions? Dose every trailing edge show this?

Q1. Yes, I would still recommend external ESD diodes (especially in between the CMC and the transceiver if you suspect that there is a potential issue). The main reason is the transient created by the CMC may not match the IEC 61000-4-2 or other ESD standards. The real-world ESD strikes can also be much higher than 8kV, and the internal diodes don't protect against any other forms of longer ESD strikes (like IEC 61000-4-5 surge). Our recommended diode is the ESD2CAN24, which supports up to 30kV IEC 61000-4-2 and ~5A of surge. This diode clamps at ~24V which will also help prevent voltage spikes from damaging the CAN transceiver pins (i.e. going above 58V). If those internal diodes clamp any higher than 60V (like in the case of a large surge event), they could potentially cause that EOS.

Q2. Yes, this is tested. However, this is not tested with a CMC. The issue of clamping does not apply below 58V. This is because the transceiver can sustain 58V indefinitely. This would not be a transient. Hence, why the internal diodes clamp just above 58V.

Q3. Yes, the clamping is always present since it is part of the TCAN1145 die. It is not a separate piece of silicon.

Q4. Your calculations are accurate, but they do not really apply as the issue you are experiencing likely does not line up with the exact ESD standard waveform. So the voltage, amperage, and time will be different.

Best,

Ethan

RE: DP83TG721S-Q1: Required Ferrite Beads

Drew Miller1 — Fri, 12 Jun 2026 22:31:17 GMT

Hi Katharina,

A) The Impedance at 100 MHz, DC resistance, and rated current are all parameters to consider when selecting a ferrite bead.

B) Typically, ferrite bead impedance is specified at 100 MHz.

There is a risk of negatively impacting EMC performance if separate ferrite beads are not used.

Thanks,

Drew

DP83TG721S-Q1: Required Ferrite Beads

Katharina Ehmke — Thu, 11 Jun 2026 08:08:40 GMT

Part Number: DP83TG721S-Q1

Hi team,

In the data sheet of the DP83TG721S Q1, different ferrite beads are recommended for the three supply rails VDDIO, VDDA and VDD1P1.Questions:
1.Can you please explain what criteria are used to select these ferrite beads?
A) Which parameters of the ferrite beads are decisive?
B) For example, at which frequency must the impedance be ensured?
2.What risk do we see in this case if the supply rails VDDIO, VDDA and VDD1P1 are not filtered via a separate ferrite bead?

Appreciate your feedback!

Katharina

RE: DP83TC815-Q1: DP83TC815-Q1 can not be detected on MDIO bus

Drew Miller1 — Fri, 12 Jun 2026 22:21:29 GMT

Hi Gavin,

Can you check clk_out signal?

Also, I noticed you have 4.53kOhm pullup resistor on RX_CTRL to disable TC-10 sleep. Can you switch to 2.49 kOhm? This a 2-level strap.

Thanks,

Drew

RE: DP83848Q-Q1: RTOS driver for DP83848Q-Q1

Gerome Cacho — Fri, 12 Jun 2026 22:14:06 GMT

Hi Ted,

My team is looking into this query. Please note that DP83848 is an older device and support is very limited.

Sincerely,

Gerome

DP83848Q-Q1: RTOS driver for DP83848Q-Q1

Ted Xu — Fri, 12 Jun 2026 06:14:41 GMT

Part Number: DP83848Q-Q1

Hi Team

Would you help provide the RTOS driver for DP83848Q-Q1? Only Linux driver can be found in below website link?

ETHERNET-SW Driver or library | TI.com

Thanks

DP83867IS: Inquiry on PHY Behavior and Required Handling When GMAC is Reset Without PHY Reset under SGMII

Yuuichi Asano — Fri, 29 May 2026 12:26:16 GMT

Part Number: DP83867IS

[Situation]
Please consider the case where the GMAC block is reset/restarted due to an external factor, while the PHY remains continuously powered and maintains link-up status.

In this scenario:

No power cycling is performed on the PHY
No cable unplug/replug occurs
No re-triggering of auto-negotiation is requested after the initial link is established

Under these conditions, we would like to continue using the PHY seamlessly before and after the GMAC reset, without changing the PHY state.

Could you please advise if there are any specific requirements, constraints, or recommended handling procedures to ensure correct operation in this use case?

[Background / Observed Behavior]
Currently, we are observing the following behavior in our prototype:

When the GMAC block is restarted without resetting the PHY, the PHY appears to maintain link-up status with the link partner.
However, it seems that data communication between the GMAC and upper layers is no longer functioning (i.e., TX/RX data does not appear to flow correctly through the GMAC interface).

[Questions]

Is this behavior expected as part of the specification for the PHY (especially under SGMII operation)?
Does the GMAC reset require any re-initialization or re-synchronization sequence on the PHY side (e.g., SGMII re-negotiation, reconfiguration, or register reprogramming)?
Are there any recommended workarounds or best practices to maintain normal data communication without resetting the PHY?

[Configuration / Scope]

Interface: SGMII