https://e2e.ti.com/support/interface-group/interface/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1695884/ds90ub941as-q1-ds90ub941as-q1-ds90ub928-q1-not-working/6538358Fri, 13 Nov 2026 08:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:16ece7e0-e477-4477-bca3-fcd944efeb24Yuan JiHi Miguel, First, answering your PATGEN question directly: yes — we now boot fully end-to-end with a single config pass while the DSI stream is already live, PATGEN never enabled at boot. Our firmware now: (1) powers the DSI board mux only, (2) leaves the 941AS at strap defaults until the DSI stream is up, (3) then register-resets it (0x01=0x02, step 1 of your reference script) and runs the full config table exactly once. Log-verified single link bring-up (strap state captured: CFG2=0x00, no PCLK, dead FPD until stream), recovery completes with GEN_STS=0x07 / DUAL_STS=0xD9 / DSI_FREQ=0x43 (67MHz), remote 0x11 writes ACK. Result: still black. So the internal→external switching theory is excluded in our case. Since the first post we have also done the following (details below): Byte-exact replication of the PG-winning timing through the DSI path. The internal PG lights the panel at 1340&#215;792 (HSW=40/HBP=16/VSW=5/VBP=5) @ 66.7 MHz. We reprogrammed the SoC DSI output to exactly this timing (pixel rate verified at both the 941 and the 928: DSI_FREQ=67 MHz, 928 frequency counter matches the PG-mode reading within 1 count). Result: still black. So the difference between working PG and black DSI is no longer timing/rate — only the internal video source. Verified continuous pixel-packet arrival. Using DSI_CONFIG_0 VC_ENABLE=0 as a probe: INV_VC errors recur continuously after every read-clear → RGB888 long packets are arriving at the serializer at all times. Protocol layer completely clean after enabling EoTp generation at the source (Cadence DSI TX hostEotGen — it defaults to OFF and our first post&#39;s EOT_ERR was exactly this). Now: DSI_STATUS=0x00, DSI_ERR_RPT_0/1/2=0, zero lane errors, GEN_STS=0x05 (the &quot;normal display&quot; value per ZHCAEW4). Register sweep with no effect (each verified by readback): HS/VS polarity (all 4), DE polarity (DATAPATH_CTL 0x12[5]) , reconstructed control-signal min-pulse filter (0x03[4] on/off), TSKIP per Eq.14 (0x2A @ 399.6MHz), BRIDGE_CFG2 all 3 clock modes, M/N auto+manual, DSI_BYTES_PER_PIXEL verified =3, BLLP LP vs blanking packets, 928 backward-compat mode. Question (sharpened): For 941AS→928 DSI pass-through at ≤85 MHz single-link (&#167;8.4.6.1): is there any known condition where the reconstructed DPI timing/video is rejected by a Gen1.5 deserializer+panel while PG-generated video at the identical pixel rate and frame geometry passes? SNLA356 &#167;2.4 notes DSI packet pacing must match DPI timing and recommends an analyzer — we have no analyzer available. What no-instrument debug methodology do you recommend next? (e.g., specific registers that expose the reconstructed HS/VS/DE widths, or a known-good register dump of a working 2-lane RGB888 @~67MHz pass-through config for diffing.) Our UB941 &amp; UB925 configuration table is shown as below: uint8_t Ub941Ub925Config[][4] = { {0x16, 0x01, 0x0A, 0x5}, {0x16, 0x03, 0x9A, 0x5}, {0x16, 0x17, 0x9E, 0x5}, {0x16, 0x07, 0x58, 0x5}, {0x16, 0x08, 0x22, 0x5}, {0x16, 0x70, 0x80, 0x5}, {0x16, 0x77, 0x24, 0x5}, {0x16, 0x01, 0x08, 0x5}, {0x16, 0x1E, 0x01, 0x5}, {0x16, 0x03, 0x9A, 0x5}, {0x16, 0x03, 0x9A, 0x5}, {0x16, 0x03, 0x9A, 0x5}, {0x16, 0x40, 0x04, 0x5}, {0x16, 0x40, 0x05, 0x5}, {0x16, 0x41, 0x21, 0x5}, {0x16, 0x42, 0x60, 0x5}, {0x16, 0x40, 0x09, 0x5}, {0x16, 0x40, 0x09, 0x5}, {0x16, 0x41, 0x21, 0x5}, {0x16, 0x42, 0x60, 0x5}, {0x16, 0x5b, 0x81, 0x5}, {0x16, 0x4f, 0x84, 0x5}, {0x16, 0x12, 0x20, 0x5}, {0x16, 0x4f, 0x84, 0x5}, {0x16, 0x40, 0x05, 0x5}, {0x16, 0x40, 0x04, 0x5}, {0x16, 0x41, 0x05, 0x5}, {0x16, 0x42, 0x2A, 0x5}, {0x16, 0x40, 0x08, 0x5}, {0x16, 0x40, 0x08, 0x5}, {0x16, 0x41, 0x05, 0x5}, {0x16, 0x42, 0x0c, 0x5}, {0x16, 0x40, 0x10, 0x5}, {0x16, 0x41, 0x86, 0x5}, {0x16, 0x42, 0x0A, 0x5}, {0x16, 0x41, 0x94, 0x5}, {0x16, 0x42, 0x0A, 0x5}, {0x16, 0x01, 0x00, 0x5}, {0x16, 0x66, 0x03, 0x5}, {0x16, 0x67, 0x03, 0x5}, {0x16, 0x65, 0x01, 0x5}, {0x16, 0x64, 0x00, 0x5}, {0x16, 0x64, 0x04, 0x5}, {0x16, 0x56, 0x00, 0x5}, {0x16, 0x40, 0x04, 0x5}, {0x16, 0x41, 0x21, 0x5}, {0x16, 0x42, 0x00, 0x5}, {0x16, 0x64, 0x00, 0x5}, {0x16, 0x66, 0x03, 0x5}, {0x16, 0x67, 0x03, 0x5}, {0x16, 0x66, 0x04, 0x5}, {0x16, 0x67, 0x72, 0x5}, {0x16, 0x66, 0x05, 0x5}, {0x16, 0x67, 0xE6, 0x5}, {0x16, 0x66, 0x06, 0x5}, {0x16, 0x67, 0x2E, 0x5}, {0x16, 0x66, 0x07, 0x5}, {0x16, 0x67, 0x00, 0x5}, {0x16, 0x66, 0x08, 0x5}, {0x16, 0x67, 0x05, 0x5}, {0x16, 0x66, 0x09, 0x5}, {0x16, 0x67, 0x2D, 0x5}, {0x16, 0x66, 0x0A, 0x5}, {0x16, 0x67, 0x28, 0x5}, {0x16, 0x66, 0x0B, 0x5}, {0x16, 0x67, 0x05, 0x5}, {0x16, 0x66, 0x0C, 0x5}, {0x16, 0x67, 0xDC, 0x5}, {0x16, 0x66, 0x0D, 0x5}, {0x16, 0x67, 0x14, 0x5}, {0x16, 0x66, 0x0E, 0x5}, {0x16, 0x67, 0x00, 0x5}, {0x16, 0x65, 0x04, 0x5}, {0x16, 0x64, 0x00, 0x5}, {0x11, 0x01, 0x06, 0x5}, {0x11, 0x01, 0x04, 0x5}, {0x11, 0x03, 0xf0, 0x5}, {0x11, 0x03, 0xf0, 0x5}, {0x11, 0x03, 0xf8, 0x5}, {0x11, 0x29, 0x00, 0x5}, {0x11, 0x29, 0x00, 0x5}, {0x11, 0x65, 0x00, 0x5}, {0x11, 0x65, 0x00, 0x5} };https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697531/thvd1500-replacement-for-sn65hvd3082e-newer-genFri, 13 Nov 2026 07:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6edce3dc-aa01-418f-96d5-debf28d8baabJade HanPart Number: THVD1500 Other Parts Discussed in Thread: SN65HVD3082E , , THVD1550 Hello team, Currently my customer is using our SN65HVD3082E for their HVAC indoor &amp; outdoor units, and they are insisting on a lower price (or they will use competitor), so we hope to move them to our THVD devices. In this case, I think THVD1500 would be suitable &amp; most cost competitive, but are there any other devices that would be better in this case? (ex. THVD1550, THVD14xx) Customer spec: data rate : 9,600bps max number of nodes (connected Indoor units to 1 outdoor unit) : 80 max distance : 1.2km Thank you.THVD1500SN65HVD3082ETHVD1550https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697516/am26c32-questions-regarding-am26c32-operation-at-3-3-v-and-am26lv32-input-bias-voltageFri, 13 Nov 2026 06:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:07e79596-fe1c-4bda-a0e6-adfb4c2f8a82? ?Part Number: AM26C32 Other Parts Discussed in Thread: AM26LV32 Hello, I have two questions I would like to consult you about: (1) I used an AM26C32 on a circuit board. The datasheet specifies a supply voltage of 4.5 V to 5.5 V, but I mistakenly powered it from 3.3 V. The chip still appears to work normally, and the single-ended output level is approximately 3.1 V. I would like to ask why this is possible. (2) I am using an AM26LV32. The datasheet states that only a 120 R termination/matching resistor is required. When the signal inputs are open, the internal bias circuit should still guarantee a differential voltage greater than 200 mV at the input, thereby placing the receiver output in a defined state (normally high) in the absence of an input signal. However, on my actual circuit board, I measured only about 2 mV differential voltage between the two input pins. Could you please explain why this is happening? Thank you.AM26C32AM26LV32Roboticshttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1693755/tusb2e221-eusb2-0-host-data-eye-test-fail-due-to-eop-width/6538285Fri, 13 Nov 2026 06:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4b6c5e4b-19ba-4d68-993a-f52cf197fea3LoganHi Ryan The relevant tests have been completed and no other issues were found. Thank you very much.https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697491/tcan1057a-q1-robustness-against-54-v-short-to-battery-on-tcan1057av-can-bus-h-lFri, 13 Nov 2026 03:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:422b5f4f-4f7a-4798-8347-a3ebdcb06f03Jiahui GaoPart Number: TCAN1057A-Q1 Hi team, I would like to inquire about the robustness of the TCAN1057AV against a 54 V short-to-battery condition on the CANH/CANL lines. According to the datasheet, the absolute maximum rating for the CANH and CANL pins is specified as 58 V. We applied 54 V to the CANH/CANL lines for 60 seconds and confirmed that the device operated normally after the test. Based on these results and the absolute maximum rating, is the TCAN1057AV guaranteed to withstand these test conditions without any issues? Best regards, Jiahui48V in automotiveTCAN1057A-Q1https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697359/sn65hvd71-sn65hvd71dr-continuous-output-to-gnd-short-circuit-protection-confirmation/6538169Fri, 13 Nov 2026 03:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0f91b01e-57b8-4554-9051-0ffec9ccb127Durga Srinivasu JarajapuThank you for the clarification Ethan White. We would like to clarify whether the specified &#177;150 mA short-circuit output current (IOS) is an internally enforced current limit or a datasheet rating/characterization value. In our application, each output (Y and Z) is connected to a 3.3 V supply through the transceiver output stage and a 10 Ω series resistor. If either output is shorted to GND, the theoretical current based on the external resistor alone is 330 mA. Could you please clarify the following: Will the internal current-limiting circuit restrict the output current to a maximum of &#177;150 mA, even if the external circuit could theoretically allow 330 mA? If the output current attempts to exceed 150 mA, will the internal protection limit it before the output stage is damaged? Does the thermal shutdown circuit provide sufficient protection against permanent damage during a continuous short circuit, including simultaneous short circuits on both outputs? We need to confirm that the SN65HVD71DR can safely withstand this fault condition without permanent damage. -Srinivashttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1695907/sn65dsi84-q1-sn65dsi84tpaprq1-ibis-model/6538148Fri, 13 Nov 2026 02:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3b1434ea-912a-41c0-9ac7-b0c60f490765Cameron Hoholik-CarlsonHi Wang, I will review this and get back to you tomorrow. BR, Cameronhttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697486/tca9617a-distortion-on-the-outputFri, 13 Nov 2026 02:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c9933825-8388-45c3-be87-6a5665754742Diane EakerPart Number: TCA9617A Hello, I am using the TCA9617ADGKR to drive an I2C signal from an STM32F427 processor to an I2C IO expander (the IO expander is off the board and attached via a 3 foot cable). I&#39;m attaching a snippet from the schematic showing how we set up the TCA9617A part. Also, as a note, in the datasheet I see you show 240 and 820 ohm pullups which do not make any sense to me because those would be strong pull-ups. As you see on my schematic, we are using 10K pull-ups. In addition to the schematic snippet, I am posting 2 scope snapshots. They are both the same, but one is an overlayed version of the clk and data signals to better show the voltage offset this part introduces and the distortion of the signals. I&#39;ve annotated the scope snapshots, but I&#39;ll say just a few words here. The input to the TCA9617A looks nice, the output is very distorted and has a voltage offset which is causing the downstream IO expander to not understand the message. Why is the signal so distorted? Also, please note there are NO series resistors between the micro and the TCA9617A.TCA9617Ahttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1696092/sn75lvds83b-overshoot-and-undershoot-on-lvds-clock-and-data-signals/6538134Fri, 13 Nov 2026 01:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0b845185-c583-4fb7-90fa-0833b526cde7kadam shahHello Ikram, Sorry for late reply. We are using Display driver IC NV3051F-L. There is external 100 ohm resistor placed at display panel. I have measured voltage and it still shows overshoot and undershoot but some what lesser than SN75LVDS83BDGGR end. We have also placed Common Mode Choke and ESD diode between SN75LVDS83BDGGR and connector. LCD cable length is 10cm. Below are part numbers for CMC and ESD diode CMC : KCZ1210AH900HRTD25 ESD : ESD204DQAR Could you please guide us how we can resolve our issue or please suggest us if we can use another CMC part which can help to reduce overshoot and undershoot? We are performing hardware validation at this moment. In next month we will go for pre-compliance test. Our goal is to resolve issue before going into pre-compliance test. LVDS clock waveform at 100 ohm resistor on LCD panel. Thankshttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697181/tcan1145-q1-tcan-1145-can-not-pull-down-rxd-pin-when-then-wukp-frame-recived/6538135Fri, 13 Nov 2026 01:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:cb899b98-226d-40c4-86c2-a8f986af460cyixiao hanhi Ethan: You mean the VCC and VIO need to be supplied,if the VCC is not pull to 5V it will only PULL UP the INH pin but the RXD can not be PULL down right? if the Vcc was pull to the 5V ,when the TCAN1145 enter the sleep mode will is cost more currents,do you have the data for the difference between the VCC is pull to 5V and without pull?https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1696092/sn75lvds83b-overshoot-and-undershoot-on-lvds-clock-and-data-signals/6538136Fri, 13 Nov 2026 01:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:133e146b-ce91-43ba-b93f-55be14af6b8dkadam shahHello Ikram, Sorry for late reply. We are using Display driver IC NV3051F-L. There is external 100 ohm resistor placed at display panel. I have measured voltage and it still shows overshoot and undershoot but some what lesser than SN75LVDS83BDGGR end. We have also placed Common Mode Choke and ESD diode between SN75LVDS83BDGGR and connector. LCD cable length is 10cm. Below are part numbers for CMC and ESD diode CMC : KCZ1210AH900HRTD25 ESD : ESD204DQAR Could you please guide us how we can resolve our issue or please suggest us if we can use another CMC part which can help to reduce overshoot and undershoot? We are performing hardware validation at this moment. In next month we will go for pre-compliance test. Our goal is to resolve issue before going into pre-compliance test. LVDS clock waveform at 100 ohm resistor on LCD panel. Thankshttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1693442/ds90ub960-q1-mipi-csi/6538119Fri, 13 Nov 2026 01:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a13d1e63-c826-495e-a6f0-d5ef73d4f626Yue LeiHi Juan, Thank you for sharing the detailed CQS290 specifications. This information helps us assess the physical interface and transmission bandwidth compatibility. Please find our responses below. 1. Delivering four aggregated streams to one CQS290 CSI-2 interface The FPD-Link IV solution has sufficient bandwidth potential, subject to confirming the cameras’ actual output formats and timing. In the proposed architecture, the uplink DS90UB971-Q1 supports four CSI-2 data lanes at up to 1.5 Gbps per lane, giving 6 Gbps in total. Its FPD-Link video payload capacity is approximately 6 Gbps. This uplink must accommodate the combined traffic from all four cameras. For four 1080p30 streams, the active-pixel data alone requires approximately: RAW8: 1.99 Gbps. RAW10: 2.49 Gbps. RAW12: 2.99 Gbps. YUV422 at 16 bits/pixel: 3.98 Gbps. These figures support continuing the evaluation of the FPD-Link IV architecture. Packet overhead, embedded data and actual transmission timing must also be included. The calculation should use the cameras’ CSI-2 output traffic, rather than the compressed recording bitrate. The CQS290’s 10-Gbps interface capability provides receiving bandwidth, but simultaneous capture still depends on Cavli confirming multi-VC support and the required processing capability. 2. Distributing the four cameras across two CQS290 CSI-2 interfaces With the current single-uplink topology, the central DS90UB9702-Q1 cannot directly split four VCs arriving through one RX port into two groups assigned to separate CSI-2 outputs. The DS90UB9702-Q1 routes video to its CSI-2 outputs at RX-port granularity. After aggregation and transmission through the uplink serializer, all four streams enter the same central RX port. VC remapping changes the channel identifiers; it does not provide this two-plus-two output routing. One direct implementation would use both CSI-2 outputs of the external deserializer, each connected to a separate uplink serializer. Two FPD-Link connections would then feed two RX ports of the central deserializer, which could be assigned to separate CSI-2 outputs. This would require changes to the uplink hardware. Another option to discuss is replicating the complete aggregated stream onto both CSI-2 outputs and having each CQS290 receiver select the required VCs. This requires Cavli to confirm receiver-side VC filtering, and each CSI-2 interface must accommodate the complete aggregated stream. In either case, receiving two independent streams simultaneously on each interface still requires the corresponding multi-VC capture support. 3. DS90UB940N-Q1 and alternative FPD-Link III solutions The DS90UB940N-Q1 is not a direct replacement for the proposed DS90UB971-Q1 camera link. The DS90UB940N-Q1 pairs with serializers such as the DS90UB949-Q1, DS90UB947-Q1 and DS90UB929-Q1. Although its 1.2-V and 3.3-V supplies match your previously stated voltage requirements, it is not compatible with the proposed DS90UB971-Q1 cascaded camera link. For an FPD-Link III camera solution, compatible combinations such as DS90UB953-Q1 and DS90UB960-Q1 can be evaluated, but the aggregated uplink bandwidth must be recalculated. For example, one DS90UB953-Q1 supports up to approximately 3.328 Gbps across its four CSI-2 input lanes. Four 1080p30 YUV422 streams exceed this limit even before packet overhead is included. Therefore, FPD-Link III is not an equivalent replacement under all the formats and operating conditions discussed. Also, the CQS290’s maximum lane rate of 2.5 Gbps does not require the deserializer to transmit at that rate. A lower rate supported by both devices can be used, subject to Cavli confirming the corresponding driver configuration. 4. Pixel formats, Virtual Channels and simultaneous operation RAW8, RAW10 and RAW12 can be transported through the proposed camera SerDes link. The receiver must still be configured for the actual data types, VCs and image-processing requirements. The meaning of NV12, NV21 and JPEG in Cavli’s list needs clarification: NV12/NV21 normally describe YUV memory layouts. Please confirm whether the list refers to CSI-2 input formats or formats produced after ISP processing. Support for generating JPEG snapshots does not necessarily mean that the CSI-2 input accepts externally generated JPEG data. The SerDes devices do not perform JPEG encoding, decoding or RAW-to-YUV conversion. Similarly, support for single-stream 1080p30 recording does not establish support for capturing and recording four 1080p30 streams simultaneously. In addition to multi-VC support, Cavli needs to confirm the corresponding capture, ISP and encoding capabilities. The 21-MP snapshot specification should not be used to infer continuous multi-camera recording capability. 5. Architecture and device-selection direction Based on the information available, we recommend retaining DS90UB971-Q1 and DS90UB9702-Q1 as the evaluation baseline for the FPD-Link IV cascade. These are automotive-qualified devices, and their transmission capacity provides more room for four-camera aggregation. Individual camera selection can be implemented through forwarding control in the external deserializer while keeping all four cameras connected. Simultaneous forwarding can use the same hardware if it is designed for four-camera operation, but simultaneous capture remains subject to Cavli’s confirmation. For power, the DS90UB9702-Q1 still requires 1.1 V and 1.8 V, with VDDIO selectable as 1.8 V or 3.3 V. If only 1.2-V and 3.3-V rails are available, additional regulation is required. The DS90UB940N-Q1 cannot be used to avoid this supply requirement while retaining the proposed link. Once Cavli clarifies multi-VC support, simultaneous processing capability and whether the format list describes CSI-2 inputs or processed outputs, we can further narrow down the final device combination and configuration. Best regards, Yuehttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1696870/tusb4020bi-q1-tusb4020bi-q1-technical-inquiry-downstream-port-communication-failure-signal-conditioning-on-usb-hub/6538103Fri, 13 Nov 2026 00:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:726f246b-8b6c-4b53-b779-12ab287f795axiangling yeHello Zhou, Thank you for your suggestion. I will try adjusting the resistor value accordingly. Additionally, regarding U0011 , it is an automotive USB D+/D- short-to-battery and IEC ESD protection device. Since the maximum allowable high-level voltage on the USB Hub&#39;s D+/D- pins is 3.8V—and a standard discrete TVS diode cannot clamp the voltage below 3.8V—we adopted this integrated protection solution. Could you please help double-check the circuit around this component as well to ensure it will not negatively affect USB signal integrity or communication? Best regards, Xianglinghttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1695884/ds90ub941as-q1-ds90ub941as-q1-ds90ub928-q1-not-working/6538064Thu, 12 Nov 2026 23:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:671fd1a8-2317-4cc8-9f9e-46cdfc6c1ebaMiguel BolanteHi Yuan, [quote userid=&quot;722542&quot; url=&quot;~/support/interface-group/interface/f/interface-forum/1695884/ds90ub941as-q1-ds90ub941as-q1-ds90ub928-q1-not-working&quot;] What fails: selecting the DSI input (PG off) → panel stays black. 941AS DSI_STATUS (0x28) = 0x05: FPD3_ERR (bit4) persistent + EOT_ERR (bit2, sticky from early bring-up). FPD3_ERR never clears while DSI input is active.[/quote] Have you tried starting up without PATGEN enabled, with the reference script above for example? My guess here is that whenever switching from internal PATGEN mode to external clock source, we have the external clock (in this case DSI clock) driving the FPD-Link. I wonder if the same error will propagate if starting fully end-to-end instead of switching from the internal mechanism. Best, Miguelhttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697145/dp83869hm-dp83869-mdio-returning-constant-value/6538048Thu, 12 Nov 2026 23:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1c53c7ea-c352-4a18-bc0a-00b8fbf19ee0Gregory KobyakovHi Benjamin, Is it possible to share a schematic of the PHY implementation? Perhaps some PHY-strapping issue is causing this. Best regards, Greghttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1694110/dp83867ir-does-dp83867irrgzr-support-ieee-1588-ptp-v1-v2/6538044Thu, 12 Nov 2026 23:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7586e57f-2395-4bd5-a941-4222adb26c0dGregory KobyakovHi Shota-san, I will have to check on this question, and will get back to you as soon as possible. Best regards, Greghttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697238/tpd4s480-tpd4s480-protecting-the-vbus-pin-63-v-abs-max-on-a-48-v-epr-port/6538029Thu, 12 Nov 2026 22:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2ca11b7c-5586-42eb-a19e-b8b79aeaa7f0Aya KhedrHi Lee, Thank you for reaching out! I will review and get back to you with feedback by end of week. Best Regards, Aya Khedrhttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1694123/sn65dsi86-non-continuous-dsi-clock-with-refclk-causes-unstable-m-n-mn-change-on-dp-monitor-at-rbr/6538024Thu, 12 Nov 2026 22:41:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8df808f4-3a00-4c57-918c-acc0a86eee2aCameron Hoholik-CarlsonHi Zhou, Thanks for the extra info! I will review this while you complete the DSI testing. BR, Cameronhttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697467/tdp20mb421-simulation-support-for-tdp20mb421Thu, 12 Nov 2026 21:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:039ef701-6ee6-49b8-a186-5d76f41a4bf4Jay SkenderPart Number: TDP20MB421 Do any simulation models exist that are useful to simulate the TDP20MB421?TDP20MB421Medical &amp; healthcarehttps://e2e.ti.com/support/interface-group/interface/f/interface-forum/1697466/tps25983-latch-off-operation-issueThu, 12 Nov 2026 21:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:132f9abd-ca53-45ff-b599-d52e95a28fbcKushagra UpadhyayPart Number: TPS25983 Hi, Our current design unable to latch off during fault. It keeps continuous operation in on off mode (I believe Thermal Mode). Our current design set up the current limit of 4A on 3.3V rail. When we connect the load higher than 4A at instance efuse trigger and shut off output. But the same incident happen during start up, keep connected 4A+ load and start up, the efuse gets extreme hot and continue the output of 2.5V-3V. We have RETRY_DLY pin short to ground and NRETRY is open. Kindly let me know how to force the part in latch off mode. Thank youdata storageTPS25983