• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 342 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TCAN1043-Q1: nFault returned Analysis QEM-CCR-2312-00886 CPR231092014

Kevin Horn
Prodigy 10 points
Part Number: TCAN1043-Q1
Other Parts Discussed in Thread: TCAN1043, STRIKE

I work in the automotive industry and one of our design includes the TCAN1043A network wake CAN transciever. We're experiencing failures of the devices frequently throughout environmental testing. 

Originally in our dual µController design, we used two transceivers. For the INH output of both transceivers we chose 10kΩ (effectively 5kΩ in parallel) as pulldowns. This enabled each transciever to wake both power supply chips (PMIC). 

We opened a failure analysis with your quality team with the numbers provided below:

QEM-CCR-2312-00886  CPR231092014

The failure analysis came back with a very much damaged trace to pin (8) nFAULT. 

We looked at our design again and the value of the pulldowns drove current higher than the recommended operating conditions of 1mA from the INH pin, but did not exceed the absolute maximum value of 6mA. Regardless, we updated our design by increasing the pulldown resistance on the INH pin to effectively 50k and reducing the maximum current draw to less than 1mA. 

Before receiving the results of the FA, we hypothesized that we INH was the likely cause of the failed IC, but the FA results don't specifically support that. Internally to the chip, the INH pin looks like it runs very close to the nFAULT damage and am looking for someone to discuss if there is a link to our design flaw and the failed nFAULT pin.

I tried to add an image of our design and failure analysis, but the resolution made it semi-illegible. 

  • 0
    TI__Guru 53575 points

    Hi Kevin,

    I was not able to find this QEM ID in our system. The format you have may be different than how we store them internally. Could you share the creation date of the ticket? If there is a title associated with the name, that would help as well. 

    I have not seen failures on the nFAULT pin as a result of INH stress before, so this would be a new fail-case to me. Typically such failures would see some change in the INH pin characteristics if this were the root cause - even if the damage propagated to another pin. 

    Can you share more information on the environmental testing you are conducting? Is this EMC immunity testing or something similar? Are you directly applying fault voltages anywhere in the system that could impact digital signal voltages? Is it possible to share a schematic and/or layout of the current implementation of TCAN1043?

    Regards, 
    Eric Schott 

  • 0 in reply to Eric Schott1
    Prodigy 10 points

    Try CS2084878 for the case number. The QA contains a powerpoint with some scope images and more information on what we were testing when we saw the failure.

  • 0 in reply to Kevin Horn
    TI__Guru 53575 points

    Hi Kevin,

    Thanks for sharing the additional documents. 

    It looks like the primary failure that was identified here is on the nFAULT signal. The optical analysis shows EIPD on the metal trace for this signal on either the protection diode or driving FET. This would most likely be caused by a transient on this signal line such as an ESD strike or an overcurrent condition where more than the absolute maximum IO current (8mA) was drawn from the pin. Can you share what else exists on the CAN1_ERR_MCU1 net that might cause such an event to occur? Does this signal have any off-board connectors or external biasing components? Is it possible that this pin could have been shorted to another signal during assembly or test? 

    When EOS occurs on the die of an IC, there can be a propagation of failures in other functions of the device due to this damage. In this case, we can see some of the discoloration of the nFAULT EIPD creep onto a trace that leads to the INH pin. While I don't think that this metal layer observation can explain the change in behavior of the INH pin, it is quite possible and likely that damage to the nFAULT pin has impacted some of the digital logic of the device. Among other things this could impact the startup behavior as the state machine logic could be damaged, so the fact that the INH signal is not observed to activate on power on is not too surprising given this damage. 

    I hope this background helps. Let me know if there is any information I can help provide in terms of finding a solution to the nFAULT damage in this system. 

    Regards, 
    Eric Schott 

  • 0 in reply to Eric Schott1
    Prodigy 10 points

    There's no supporting circuitry on that pin from the CAN IC nFAULT output and the diagnostic input to our microcontroller. It's a simple trace.