This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SN65HVD252: CS0700122- Failure analysis unresolved.

Part Number: SN65HVD252

Dear Sir/Madam,

Greeting of day..

We found  1 module faulty due to IC SN65HVD252DR (RMICSE0122SCO) failure at  Mitsubishi Electric Pvt. Ltd customer end.

IC pins 1 (TXD) not getting required voltage.

Please find below for more details.

we already raised  case to TI portal, but instead  of any analysis report  case was closed by TI.

since supplier-arrow not having any idea for further processing.

please look into this matter and reopen the case once again.

Thanks & Regards,

Muhammad Kazi

Sr. Quality Engg.

MEI- Pune (India)

 

MITSUBISHI ELECTRIC INDIA PRIVATE LIMITED     

Tel. No.: +91 20 40762112; (Mob. No.): +91 9765639591

Email: URL: www.mitsubishielectric.in

  • Hi Mahammad,

    Sorry to hear about the issue here. 

    We can help diagnose the problem here and point you to the correct resources to get the failed device returned if necessary.

    Can you share a bit more information about the failure condition? You stated that the TXD pin is not getting the required voltage. The TXD pin is an input to this device which is expected to be driven by a CAN controller or similar MCU. The transceiver only has a small internal pull-up to bias this signal internally if the input is left floating. Can you elaborate a bit on the failure and what data you've been able to collect that points towards SN65HVD252? This may be included in the report mentioned here. Is it possible to share that here? If there is any sensitive information not fit for this public forum, you can send this to me offline via email. Find my contact information on my E2E profile by clicking my name. 

    In the meantime, I will recommend a few tests as well to see what other information we can gather:

    • What is the status of the CAN controller or MCU once the failure has been recognized? Is the controller attempting to send CAN data? Is it able to receive CAN data? If it is reporting any errors, is it possible to know which errors (Bit err, stuff err, ack err, etc.)?
    • Please probe the TXD, RXD, CANH, and CANL signals around the transceiver while communication is being attempted. I would like to see if the transceiver is capable of receiving data from the CAN bus to RXD and if TXD is toggling. If so, I would also expect the CAN bus to be driven based on the TXD signal. 
    • Was there any stress applied to the transceiver before the failure was reported? Did this unit fail in the field, during assembly, or pre-production testing? Are there any signs of physical damage to the IC? 

    Let me know if you are able to find any new information or can share the report with me. 

    Regards,
    Eric Schott

  • Dear Eric,

    Greeting of day!!!

    Please find MEI comments.

    1.MCU found ok once change with new CAN controller IC.

    2. We observed issue in RXD signal and CANH,CANL signals.

    3.Problem reported from field.

    Please check below waveform,

    looking forward for your kind response.

    Thanks & regards,

    Muhammad Kazi

      

  • Hi Muhammad,

    Thank for sharing the waveforms and extra information. 

    It looks like in the faulty IC waveforms, the CAN bus is not responding when TXD is driven low. However, the CANH and CANL lines still rest at the propper recessive value (2.5V). In this setup, are there other transceivers connected to CANH and CANL? Or do CANH and CANL rest at 2.5V with only the faulty IC alone? 

    Please confirm that the input to pin 8 (S or Silent) is low during this test. If S is high, the transceiver is in Silent mode and the CAN driver is disabled. In this case, I would expect the driver to not respond to a low on TXD. If the S signal is low and there is no response to TXD on the CAN bus, this is likely caused by a damaged device. 

    Do you have any way of testing the individual failed IC outside of the system? Something like a TCAN1042EVM? I would like to see if we can validate the unresponsive behavior outside of the system. We can also conduct this testing in our office if we conclude that this is likely caused by device damage. 

    Does the current schematic include any protection devices on the bus such as a TVS diode? If available, please share the CAN portion of the schematic. This can be done offline if needed.

    Regards,
    Eric Schott

  • Dear Eric,

    In reference to below email, Please find the details as you requested.

    1. No other transceiver connected to CANH and CANL.
    2. Yes CANH & CANL rest at 2.5V with only the faulty IC.
    3. Yes pin number 8 is low during test/operation.
    4. We don't have any individual IC tester.
    5. We don't have any protection deceive at CAN bus driver.

    looking forward for your response.

    Thanks & regards,

    Muhammad Kazi

  • Hi Muhammad,

    Based on your description and the waveforms you provided from your testing, it seems like the CAN driver has been partially damaged and is no longer capable of driving a dominant (logic 0) state. Because this damage occured in the field, it is likely this failure is the result of electrical overstress to the device that exceeded its maximum specified tolerances. I suspect if we were to have this device returned to conduct failure analysis, we would only be able to confirm that this is the case or not. WIthout a secondary suspected failure mode, I don't think we would gain much knowledge from this process. 

    To address this issue from a system-level perspective, I would recommend considering the use of external protection circuitry on the CAN bus to protect the transceiver from such over-stress events. Such components would be TVS diodes, PTC fuses, bus capacitors, etc. I've linked a reference design below with some more information on these protection methods. 
    https://www.ti.com/tool/TIDA-00629 

    Let me know if there's any other information I can provide or if there some other action you would like to take regarding this issue. 

    Regards,
    Eric Schott