Interface forum - Recent Threads

SN65DSI83-Q1: Display panel flickering with sn65dsi83 + external clock source

Vojtech Bubela — Fri, 20 Mar 2026 16:13:40 GMT

Part Number: SN65DSI83-Q1

Hello everyone,

We are using SN65DSI83 to convert DSI signal (produces by cm4) to LVDS signal for our display panel. We use 75 MHz external clock source to produce the lvds signal from the DSI. The problem is that with this setup we get vertical jumping/flickering ocassionally on the display panel - about every couple of seconds, not periodical.

We also tried to source the clock from the DSI signal, but we have had similar issue where the screen would sometimes start jumping where the device started (about 25 % of our devices show this behaviour in 1 - 2 % of the starts - pointing possibly to a hardware problem). We tried to solve this by using external clock.

We have tried the following:
sn65dsi83 test pattern displays correctly without jumping
different timing values in linux kernel - did help, but have not solved problem completely.
matching the pixel clock and the lvds clock to the external clock (75mhz) - did not help.

Technial specs:
chip: ti-sn65dsi83-Q1
DSI signal source: raspberrypi compute module 4
3 dsi lanes
display: AM-1280800WGTZQW-00H - lvds input frequency needs to be between 70.0 - 76.6 MHz
linux kernel version 5.15.40.

current panel timing settings:

.clock = 75000,

.hdisplay = 1280,

.hsync_start = 1280 + 80,

.hsync_end = 1280 + 80 + 32,

.htotal = 1440,

.vdisplay = 800,

.vsync_start = 800 + 20,

.vsync_end = 800 + 20 + 6,

.vtotal = 835,

.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,

sn65dsi83 register dump:
0x00: 0x35
0x01: 0x38
0x02: 0x49
0x03: 0x53
0x04: 0x44
0x05: 0x20
0x06: 0x20
0x07: 0x20
0x09: 0x00
0x0a: 0x84
0x0b: 0x00
0x0d: 0x01
0x10: 0x2e
0x11: 0xcc
0x12: 0x3c
0x18: 0x18
0x19: 0x4c
0x1a: 0x03
0x1b: 0x20
0x20: 0x00
0x21: 0x05
0x24: 0x20
0x25: 0x03
0x28: 0x40
0x29: 0x00
0x2c: 0x28
0x2d: 0x00
0x30: 0x0a
0x31: 0x00
0x34: 0x3c
0x36: 0x00
0x38: 0x50
0x3a: 0x1e
0x3c: 0x00
0x3d: 0x00
0xe0: 0x01
0xe1: 0xfd
0xe5: 0x00

Is using the external clock like this viable approach? If yes is there anything wrong with our approach?

Thanks,
Vojtech Bubela

RE: SN65DSI83-Q1: Display panel flickering with sn65dsi83 + external clock source

Ikram Haque — Fri, 10 Apr 2026 02:12:00 GMT

Hi Vojtech, please give me 1-2 days to look further into this issue.

TDP2044: DisplayPort compatible USB-C port using TDP2044 and TPS26750?

Yu Sato — Fri, 10 Apr 2026 01:38:34 GMT

Part Number: TDP2044

Hi team,

Is it possible to build a DP alt mode compliant USB-C port w/ PD using TDP2044 and TPS26750?

I understand that there are no catalog part that supports DP alt mode currently, so I was wondering if this was an option.

Best,

DP83TD510E-EVM: Request for Worst-Case Power Consumption Data for DP83TD510ERHBR and DP83822HRHBT

Shreyas Patil — Thu, 09 Apr 2026 11:25:04 GMT

Part Number: DP83TD510E-EVM

Hello,

We are currently using a Texas Instruments reference design for an Ethernet-to-SPE converter, where a 25 MHz crystal (ABM8AIG-25.000MHZ-12-2Z-T3) is used as the reference clock for the DP83TD510ERHBR SPE PHY.

In our design, the SPE PHY internally generates a 50 MHz RMII reference clock using its PLL and provides this clock to the DP83822HRHBT Ethernet PHY. Since our system supports bidirectional communication over RMII, accurate estimation of power consumption is critical for power supply sizing and thermal analysis.

We would like to highlight that in our implementation, we are using a 3.3V supply for all relevant rails (VDDIO, VDDA, and AVD) for both devices:

DP83TD510ERHBR (SPE PHY)
DP83822HRHBT (Ethernet PHY)

With this configuration, we request your guidance on the following:

The maximum supply current for each device across the full operating temperature range (–40°C to +85°C), considering process, voltage, and temperature variations.
The worst-case total current consumption when all 3.3V rails (VDDIO, VDDA, AVD) are powered from the same supply.
Any peak or transient current requirements during:
- Startup
- Link establishment
- Continuous RMII operation at 50 MHz
Recommendations for power budgeting and margining for a robust design.

We would like to confirm whether these assumptions are appropriate for worst-case analysis, or if more accurate values should be used.

RE: DP83TD510E-EVM: Request for Worst-Case Power Consumption Data for DP83TD510ERHBR and DP83822HRHBT

Vivaan Jaiswal — Fri, 10 Apr 2026 01:37:37 GMT

Shreyas,

Power consumption information for the 510 can be found on page 9 of the datasheet

Similarly, Power consumption information for the 822 can be found on page 11 of the datasheet

You can also find the power supply recommended operating conditions in the same section of the datasheet.

Best,

Vivaan

DP83867IR: Regarding communication errors when using the DP83867IR in combination with a switching hub whose IFG is less than 96ns.

mitsuda Kenji — Tue, 07 Apr 2026 05:23:55 GMT

Part Number: DP83867IR

I am using a 1000base-T board equipped with a DP83867IR in combination with a switching hub from a certain manufacturer. In frames output from the hub, the IFG sometimes falls below the specified minimum value (96ns), resulting in a communication error. When I changed the DP83867IR register (VTM-CGF address 0x0053) from its default value of 0x5 to 0x3, a different error occurred. I would like to know the cause of this error and how to resolve it.

Also, does the DP83867IR have an EEE (Energy Efficient Ethernet) function? If so, please tell me how to disable this function.

RE: DP83867IR: Regarding communication errors when using the DP83867IR in combination with a switching hub whose IFG is less than 96ns.

mitsuda Kenji — Fri, 10 Apr 2026 01:27:31 GMT

Hi J-san,

Which registers should I check to find out the details of the error?

The information regarding EEE mode is based on AI-generated research, and it is unclear whether the system actually operated in EEE mode.

Best regards

RE: DP83TD510E-EVM: Clarification on Replacing 25 MHz Crystal with Oscillator in Ethernet-to-SPE Design

Vivaan Jaiswal — Fri, 10 Apr 2026 01:18:29 GMT

Shreyas,

[quote userid="692947" url="~/support/interface-group/interface/f/interface-forum/1634824/dp83td510e-evm-clarification-on-replacing-25-mhz-crystal-with-oscillator-in-ethernet-to-spe-design"]Does the DP83TD510ERHBR support external clock input mode on the XI pin?[/quote]

Yes

Input clock amplitude and logic levels
Duty cycle and jitter limits
XO pin termination or configuration

[/quote]

Here is the link to the page of the datasheet which contains the input clock requirements.

[quote userid="692947" url="~/support/interface-group/interface/f/interface-forum/1634824/dp83td510e-evm-clarification-on-replacing-25-mhz-crystal-with-oscillator-in-ethernet-to-spe-design"]Would replacing the crystal with the ECS oscillator have any impact on RMII timing or synchronization with the DP83822HRHBT?[/quote]

As long as the input clock requirements are met, there should be no functional difference between crystal or oscillator configurations

[quote userid="692947" url="~/support/interface-group/interface/f/interface-forum/1634824/dp83td510e-evm-clarification-on-replacing-25-mhz-crystal-with-oscillator-in-ethernet-to-spe-design"]Are there any recommended reference designs or application notes for using an external oscillator with this PHY?[/quote]

While there aren't any app notes for using oscillators, it should be a straightforward setup where the XO pin is left floating and the XI pin is connected to the oscillator output.

Best,

Vivaan

DP83TD510E-EVM: Clarification on Replacing 25 MHz Crystal with Oscillator in Ethernet-to-SPE Design

Shreyas Patil — Thu, 09 Apr 2026 11:08:40 GMT

Part Number: DP83TD510E-EVM

Hello,

We are currently using the Texas Instruments reference design for an Ethernet-to-SPE converter, where a 25 MHz crystal (ABM8AIG-25.000MHZ-12-2Z-T3) is used as the reference clock source for the DP83TD510ERHBR SPE PHY.

This clock is internally multiplied using the PHY’s PLL to generate the 50 MHz RMII reference clock, which is then provided to the Ethernet PHY (DP83822HRHBT) for bidirectional communication.

We are evaluating the possibility of replacing the crystal with an external oscillator (ECS-3225SMVQ-250-DS-TR), which offers improved frequency stability (±20 ppm over –40°C to +125°C) compared to the existing crystal (±70 ppm).

However, based on our analysis, we understand the following:

The existing design uses a passive crystal connected to the XI/XO pins of the DP83TD510ERHBR, leveraging the internal oscillator circuit.
The proposed replacement is an active oscillator that provides a CMOS clock output.
Direct replacement of the crystal with an oscillator is not straightforward, as the PHY oscillator pins are designed for a crystal interface and not a driven clock input.
If an external oscillator is to be used, the PHY must support external clock input mode, where:
- The clock is applied to the XI pin
- The XO pin is left unconnected (or handled as per datasheet recommendations)

We would like to confirm the following:

Does the DP83TD510ERHBR support external clock input mode on the XI pin?
If yes, are there any specific requirements for:
- Input clock amplitude and logic levels
- Duty cycle and jitter limits
- XO pin termination or configuration
Would replacing the crystal with the ECS oscillator have any impact on RMII timing or synchronization with the DP83822HRHBT?
Are there any recommended reference designs or application notes for using an external oscillator with this PHY?

We would appreciate your guidance on whether this replacement is feasible and any design considerations we should account for.

AM625SIP: Request for Support on Camera View Development Issue (TI AM6254)

Paul Minh — Mon, 09 Mar 2026 08:24:02 GMT

Part Number: AM625SIP

Dear Expert,

We have encountered several issues and are currently stuck with our camera view development on TI AM6254.

Could you please help check and guide us on how to fix the issue below?

May we know, how to confirm CSI2Rx recieved data correctly and also its output?

The connection setup is as follows:

Camera (1, 2, 3, 4) → Video Decoder (TP2855) → AM62x CSI -> Framebuffer display on LCD

root@am62xx-evm:/tmp# gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,format=YUYV,width=1920,height=1080 ! videoconvert ! videoscale ! fbdevsink
WARNING: erroneous pipeline: could not link v4l2src0 to videoconvert0, neither element can handle caps video/x-raw, format=(string)YUYV, width=(int)1920, height=(int)1080
root@am62xx-evm:/tmp# gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! videoscale ! fbdevsink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
[ 9996.003008] cdns-csi2rx 30101000.csi-bridge: Failed to start streams 0x1 on subdev
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate required memory.
Additional debug info:
../gst-plugins-good-1.20.6/sys/v4l2/gstv4l2src.c(777): gst_v4l2src_decide_allocation (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Buffer pool activation failed
Execution ended after 0:00:00.109949575
Setting pipeline to NULL ...
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.
Additional debug info:
../gstreamer-1.20.6/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
Freeing pipeline ...
root@am62xx-evm:/tmp# dmesg | grep csi2rx
[ 0.256738] i2c 1-0044: Fixed dependency cycle(s) with /bus@f0000/ticsi2rx@30102000/csi-bridge@30101000
[ 0.351396] cdns-csi2rx 30101000.csi-bridge: Probed CSI2RX with 4/4 lanes, 4 streams, external D-PHY
[ 394.447682] cdns-csi2rx 30101000.csi-bridge: Failed to start streams 0x1 on subdev
[ 547.372966] cdns-csi2rx 30101000.csi-bridge: Failed to start streams 0x1 on subdev

root@am62xx-evm:/tmp# media-ctl -p
Media controller API version 6.1.33

Media device information
------------------------
driver j721e-csi2rx
model TI-CSI2RX
serial
bus info platform:30102000.ticsi2rx
hw revision 0x1
driver version 6.1.33

Device topology
- entity 1: 30102000.ticsi2rx (5 pads, 5 links, 1 route)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
routes:
0/0 -> 1/0 [ACTIVE]
pad0: Sink
[stream:0 fmt:YUYV8_1X16/1920x1080 field:none]
<- "cdns_csi2rx.30101000.csi-bridge":1 [ENABLED,IMMUTABLE]
pad1: Source
[stream:0 fmt:YUYV8_1X16/1920x1080 field:none]
-> "30102000.ticsi2rx context 0":0 [ENABLED,IMMUTABLE]

- entity 7: cdns_csi2rx.30101000.csi-bridge (5 pads, 2 links, 1 route)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
routes:
0/0 -> 1/0 [ACTIVE]
pad0: Sink
[stream:0 fmt:YUYV8_1X16/1920x1080 field:none]
<- "tp2855 1-0044":0 [ENABLED,IMMUTABLE]
pad1: Source
[stream:0 fmt:YUYV8_1X16/1920x1080 field:none]
-> "30102000.ticsi2rx":0 [ENABLED,IMMUTABLE]
pad2: Source
pad3: Source
pad4: Source

- entity 13: tp2855 1-0044 (4 pads, 1 link, 0 route)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev2
pad0: Source
[stream:0 fmt:YUYV8_1X16/1920x1080 field:none colorspace:srgb xfer:709 ycbcr:601 quantization:lim-range]

RE: AM625SIP: Request for Support on Camera View Development Issue (TI AM6254)

Paul Minh — Fri, 10 Apr 2026 00:53:52 GMT

Hi Luis & Jay

1. Below is the paremeters of DPHY-TX decoder side (HS Transmitter AC Characteristic)

2. The current symptom remains the same as reported in our previous comment dated April 8th.

We would like to share the results of a new test performed today on both cameras:

a) The initial frames are displayed abnormally.
b) The video then transitions into slow motion, etc.

SW setting: (We try to config diff values but it produces the same symptom )

- In tp2855 device driver:

static const struct tp2855_mode supported_modes[] = {

{

.bus_fmt = MEDIA_BUS_FMT_YUYV8_1X16,

.width = 1280,

.height = 720,

.max_fps = { .numerator = 1, .denominator = 25 }, // 25 or 30

.global_reg_list = common_setting_297_4ch_4lane_720p_30fps_regs,

.mipi_freq_idx = 0,

.bpp = 8, //8 or 16

};

tp2855->pixel_rate = v4l2_ctrl_new_std(handler, NULL, V4L2_CID_PIXEL_RATE, 0, 297000000, 1, 297000000); // or 148500000

- In DTS:

link-frequencies = /bits/ 64 <297000000>; // 297000000 or 594000000
data-lanes = <1 2 3 4>; /* data-lanes = < 1 2 3 4 > */

- View cmd ( as below, or add ", framerate=30/1", "framerate=25/1" produce the same result)

gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,format=YUY2,width=1280,height=720 ! videoconvert ! fbdevsink

TVI 702p 1280*720 Cam output:

e2e.ti.com/.../TVI_5F00_720p_5F00_Cam.mp4

AHD 702p 1280*720 Cam output:

e2e.ti.com/.../AHD_5F00_720p.mp4

TCAN5102-Q1: I would like to inquire about your CAN FD Light–related products.

Hiroki Matsumoto — Fri, 10 Apr 2026 00:27:39 GMT

Part Number: TCAN5102-Q1

I have the following questions:

Are you planning to expand your lineup of CAN FD Light responder ICs?

Do you have any microcontroller‑less responder ICs except CAN FD Light?

Does TCAN5102 also follow your product life cycle policy, with supply guaranteed for 10 to 15 years?

Any information you can share would be greatly appreciated.
Thank you for your time and support.
Best regards,

RE: DS90UB948-Q1: I would like to ask if there is a way to read the remote GPIO status of the DS90UB948-Q1.

KISUK LEE — Thu, 09 Apr 2026 23:52:09 GMT

Dear Aaron Heng

Please guide me on exactly which register to read.

Thank you.

DS90UB948-Q1: I would like to ask if there is a way to read the remote GPIO status of the DS90UB948-Q1.

KISUK LEE — Fri, 13 Mar 2026 01:35:32 GMT

Part Number: DS90UB948-Q1

Dear TI SerDes FAE

This is an inquiry about a different project from the ongoing inquiry regarding DS90UB941AS-Q1.

When the DS90UB941AS-Q1 Serializer and DS90UB948-Q1 DeSerializer are linked, is there a way for the Host CPU to know the status of the GPIO output value of the DS90UB948-Q1 through the I2C of the DS90UB941AS-Q1?

The example of the connection structure between SerDes is similar to what was mentioned in another question.

[DS90UB948] I want to check specific GPIO settings via I2C in the Deserializer.

I simply thought that I could check the output value of GPIO3 by reading the [0x1F] Register.
I checked, and the output always reads 0x05. After reviewing the datasheet, I found that this can only be checked when Local GPIO is enabled, as shown in [Table 5] below.

We want to use Remote GPIO Enable, so the above method doesn't seem to work.

Is there a way to check the GPIO output value while Remote GPIO Enable is enabled?

I am contacting you because I could not find a solution, so please check into this.

TPD4E001: VBUS line overshoot caused by adding a capacitor to TPD4E001

Yasuaki Sugimoto — Fri, 03 Apr 2026 02:33:42 GMT

Part Number: TPD4E001

Hi,

I'm using a TPD4E001 in the input stage of a USB-powered device. In this circuit, when connected via a USB cable from any Type-A adapter, an overshoot of 7-8V occurs in the VBUS power line depending on the cable used. This likely causes the TPS2116 used in the subsequent stage to exceed its absolute maximum rated voltage of 6V, resulting in failure. When I tried removing the 0.1uF capacitor connected to the TPD4E001's VCC, the overshoot subsided. I suspect it's resonating with the inductance component of the USB cable. The input stage of USB-powered devices is a common use case for the TPD4E001, but have there been other reported cases of this kind of trouble? The 0.1uF capacitor is strongly recommended according to the datasheet, and I suspect that removing it would result in insufficient ESD protection. What countermeasures can be considered for this overshoot? Any advice would be greatly appreciated.

Best reagards,

Yasuaki Sugimoto

RE: TPD4E001: VBUS line overshoot caused by adding a capacitor to TPD4E001

Yasuaki Sugimoto — Thu, 09 Apr 2026 23:18:46 GMT

Hi McKenzie,

It varies depending on the USB cable, but based on my testing with the 15 cables I currently own, the current is in the range of 0.4 to 1.5A. We cannot control the cables used by users, so it's possible that some cables might reach up to around 2.0A.

Best regards,

Yasuaki Sugimoto

RE: DS90UB936-Q1: DS90UB936 + DS90UB935: Lost frames during IEC 61000-4-4 burst testing

Ethan Woods — Thu, 09 Apr 2026 22:31:38 GMT

Hi Simon,

The schematic above looks okay and I don't see any major issues off of initial inspection.

Usually, failing burst testing due to lock drop is caused by two different things:

Failing power supply to the pins on the DES/SER causing a power-down state
Software malfunction during a burst event

To verify if the power supply is not being interrupted for the SerDes pair, could you take some voltage measurements on the VDD18 (1.8V) and VDDIO (3.3V) pins on the deserializer to confirm the device is not losing power during the burst event causing a link loss. Additionally, could you take some measurements to verify the voltage isn't dropping on pins 2 and 4 of the STP2 pins coming from RIN1P and RIN1N. Since I assume the 12V powers the camera with the attached Serializer, a possible voltage drop here could cause the Serializer to lose power, causing a link loss.

To verify if a software malfunction is happening, could you provide a register dump before burst testing with a stable link and after burst testing with a link loss on the Deserializer. This will allow us to see the AEQ values, S-Parameter values, and other values corresponding to a stable link. If there is a difference between them before/after the event, it might highlight that you should adjust these values for more stability.

Best,

Ethan Woods

DS90UB936-Q1: DS90UB936 + DS90UB935: Lost frames during IEC 61000-4-4 burst testing

G.G. — Thu, 02 Apr 2026 12:20:40 GMT

Part Number: DS90UB936-Q1

Hello,

We are using the DS90UB936 and DS90UB935 in combination to transmit images (not a video stream) form an image sensor every 100 ms.

Currently, we are experiencing errors on the FPD link during IEC 6100-4-4 burst testing on the 24 V input of the deserialiser board.
The 24 V input is filtered with a common mode choke and Y capacitors to the grounded metal housing. All the other components on the board (TI AM65xx with ADC, DDR4, eMMC, etc.) are working fine, even during positive/negative 3 kV burst pulses. Our goal is to achieve 2kV burst immunity without losing any frames (performance criterion A).

The cable length between the serialiser and the deserialiser is either 1 m or 5 m (there is no difference during testing), and it uses Leoni Dacar 535-2 and Rosenberger HSD connectors. Two wires of the cable are used for the FPD link differential pair, and the remaining two wires are used for the 12 V power supply to the sensor.
Therefore, there is no parasitic power on the data lines. We have checked that the star-quad cable is being used correctly, ensuring that the opposing wires form a pair.

We tried using common mode chokes (Murata DLW21SN900HQ2L) on both sides and on the deserialiser side only, but this had no effect.
The earth connection to the cable's shield was also varied (one side, both sides, etc.).

Do you have any idea how to pass the test?

TUSB8020B: USB SS TX/RX swapping

Andrew K — Thu, 09 Apr 2026 22:18:29 GMT

Part Number: TUSB8020B

Regarding USB SS RX/TX crossover, does the TUSB8020B act like a mux and map upstream RX to downstream RX, or does it map RX to TX?

My design uses a custom cable that does not swap RX/TX. How should I cross them on-board in my design? Is the below scheme correct?

RE: AM625SIP: Request for Support on Camera View Development Issue (TI AM6254)

Luis Parga — Thu, 09 Apr 2026 21:26:39 GMT

Hi Paul,

Please advise what the DPHY-TX side is configured to for the below parameters. I would like to confirm these are as per MIPI and fall within conformant values of the DPHY-RX side (AM62x).

TLPX
THS-PREPARE
THS-ZERO

Best regards,

Luis Parga

RE: DS90UB954-Q1: Need Register sequence for Camera bringup

Hamzeh Jaradat — Thu, 09 Apr 2026 21:21:36 GMT

Hello Reena,

[quote userid="680577" url="~/support/interface-group/interface/f/interface-forum/1633414/ds90ub954-q1-need-register-sequence-for-camera-bringup/6302066"]Based on our understanding, non-synchronous mode should be sufficient for this setup. Please let us know if synchronous mode is recommended instead for better performance or stability.[/quote]

That is correct. Both Modes do support same Datarates.

Only different is Sync mode the SER uses the clock coming from the DES over back channel, while in non-Sync each device has it's own CLK source.

[quote userid="680577" url="~/support/interface-group/interface/f/interface-forum/1633414/ds90ub954-q1-need-register-sequence-for-camera-bringup/6302066"]Are you using any GPIO from the DES to the SER to enable/disable the image sensor?
We are not using GPIO for sensor power or shutdown control.
Current connections:
Serializer GPIO1 → Camera sensor GPIO0 (reserved for future use)
SoC GPIO → Deserializer GPIO1 (reserved for future use)
At present, we have not configured forward channel or back channel GPIO.
Please advise if any GPIO configuration is required for proper operation or future flexibility.[/quote]

This is completely depending on your use case. If you are not requiring any GPIO that is fine.

[quote userid="680577" url="~/support/interface-group/interface/f/interface-forum/1633414/ds90ub954-q1-need-register-sequence-for-camera-bringup/6302066"]Are you sending Frame synch signal over the back channel to the image sensor?
Since our system uses only one camera, we are not using FrameSync.
Our understanding is that FrameSync is primarily required for multi-camera synchronization, so it is not needed in our case. Please confirm if this is correct.[/quote]

That is correct. Although in some cases, some people uses the Fsync signal to trigger the frame generation even on one camera. But this is use case dependent.

For the above configurations you really do not need any initialization script. The devices should be plug and play if your hardware settings (MODE and IDx pins) are correct and matching on both sides.

Here is an example for initializing your link:

# Deserializer Device Address = 0x60

# Disable RX Port forwarding on RX0 and RX1 first
board.WriteI2C(0x60, 0x20, 0x30)

# Write to FPD RX0 Port
board.WriteI2C(0x60, 0x4C, 0x01)

# Enable Back-Channel and I2C Pass-through
board.WriteI2C(0x60, 0x58, 0x5A) # 0x5A for non-Sync mode, 0x5E for Sync mode

# Set Serializer Alias, SlaveID, and SlaveAlias for RX0
board.WriteI2C(0x60, 0x5C, 0x) # Serializer Alias = 0x__
board.WriteI2C(0x60, 0x5d, 0x) # SlaveID[0] = 0x__
board.WriteI2C(0x60, 0x65, 0x) # SlaveAlias[0] = 0x__

# Ensure RX Ports are Enabled and Lock Status is Detected

# Once link is established, meaning 0x4D = 0x03 (LOCK and PASS are HIGH)

# ----- Image Sensor Configuration Placeholder ---

# Enable CSI Port 0, CSI Continuous Clock
board.WriteI2C(0x60, 0x33, 0x03)

# Enable CSI Round Robin forwarding
board.WriteI2C(0x60, 0x21, 0x01)

# Now forward RX port0 to CSI Port 0
board.WriteI2C(0x60, 0x20, 0x20)

DS90UB954-Q1: Need Register sequence for Camera bringup

Reena Patel — Mon, 06 Apr 2026 06:05:58 GMT

Part Number: DS90UB954-Q1

Hello TI Team,

Currently we are working on one project, where we are bringing up On Semi camera AR0544, connected using serializer and deserializer IC of TI.

Deserializer : DS90UB954-Q1
Serializer : DS90UB953-Q1

Camera : AR0544
Co-axial cable

PMIC : TPS65033000RGERQ1
SOC : QCS5430 Qualcomm.

We need register the sequence of both deserializer and serializer to write sensor XML in our Qualcomm QCS5430 soc. If you need any more information from our side, let us know.

Thank you,

Reena Patel

HD3SS3212: HD3SS3212 VBIAS

user4497266 — Wed, 08 Apr 2026 00:16:24 GMT

Part Number: HD3SS3212

Hi.

The datasheet for HD3SS3212 is a bit vague on the BIAS voltage requirements. My application uses LVDS. The LVDS is AC-coupled on both sides of the HD3SS3212, this is not something that I can change.

In the HD3SS3212's datasheet it says "VBIAS can be GND". The values for the VBIAS resistors are not mentioned.

Can you clarify that it is it ok to connect as Figure 6, with 100 kOhm resistors and using ground as VBIAS?

Regards, Jovnas

RE: HD3SS3212: HD3SS3212 VBIAS

user4497266 — Thu, 09 Apr 2026 21:19:49 GMT

Hi Nir.

You wrote "External voltage biasing is only needed to counter high common mode voltage". But the datasheet states "Because the switch requires a bias voltage, the designer must place the capacitors on one side of the switch. If they are placed on both sides of the switch, a biasing voltage should be provided".

I must disagree with your interpretation, I think the datasheet is quite clear when it states that a bias voltage is needed when using AC coupling capacitors on both sides.

Regards, Jovnas

RE: HD3SS3212: HD3SS3212 VBIAS

Nir Gilgur — Thu, 09 Apr 2026 21:02:22 GMT

Hello Jovans,

After reading the other responses and the datasheet, I retract the 1k pull up value suggestion, because that is way too strong of a pull.
I believe the RBIAS value in the datasheet is a typo, since such a pull up value doesn't really makes sense in high speed signaling.
Using a 100k to 200k resistors is more appropriate.

The "the switch requires a bias voltage" statement from the datasheet is misleading. It refers to a different kind of "biasing".
It talks about the Host/Controller biasing on the I/Os of the mux, or in other words just the signals it is sending to its inputs.
In the same paragraphs it mentions "the switch is biased by the system/host controller".

The VBIAS with a resistor pull up, is what we call external biasing.
This is something we strongly recommend when common mode voltage exceeds 2V for this part.
The point of this biasing is to make sure the mux sees a voltage level of 0V to 2V on the I/Os.
You can pull down the line to ground, so the mux sees 0V, or pull it up to a VBIAS of 0V to 2V.

External voltage biasing is only needed to counter high common mode voltage.
It is not needed when you AC couple both sides.
It is fine if you still do it, but it is not something we recommend.

Hopefully this clarifies your concerns.
If not, fill free to follow up with further questions.

Thanks,

Nir