• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1190 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.

TLIN1022-Q1: Short Circuit to Battery Test ISSUE

CHO SR
Genius 3415 points
Part Number: TLIN1022-Q1

Hi

The customer had a problem during the Short Circuit to Battery test.

The waveform is described below.

1. LIN Communication -> OK

2. Short Circuit to Battery @LIN Bus Line / over 10sec

 a. LIN Rx & Tx Port output is lost.

 b. LIN Transceiver, It is judged that it has entered sleep mode.

3. Wakeup Request

 a. LIN Rx & Tx Initialization

4. LIN Communication -> OK

a. Output normal on LIN Rx & Tx Port. -> LIN Transceiver, Wake Up Mode

Questions.

1. Condition : Short Circuit to Battery @LIN Bus Line / over 10 sec

Is LIN Transceiver designed to enter slip mode or specific protection mode?

2. LIN communication is not working when LIN BUS Enable Pin (Blue) is high as shown in the waveform.

 a. Did you enter Sleep Mode with Enable Pin low?

 b. Is LIN communication stopped by certain protection?

Additional questions.

The protection features supported by TLIN1022-Q1 are specified in Datasheet as shown below.

Does TLIN1022-Q1 have other protection features & diagnostics?

  • 0
    TI__Guru 53515 points

    Hi Cho,

    I don't believe this is a result of device modes or protection. TLIN1022-Q1 will only enter sleep mode when the EN pin input is low. As long as the enable pin remains high, the device will remain in normal mode (as long as there is no undervoltage condition). There is no specific mode to handle a bus fault event. As this device can tolerate 36V (recommended) at the bus pin, a battery fault would not trigger any active or passive protection. 

    It seems that LIN communication fails during the bus fault and then is able to resume when the fault is removed. This is expected; when the bus fault is applied and the LIN1 line has a low-impedance path to battery voltage, most LIN drivers will not be capable of driving a valid dominant (low signal) on the bus. This would be indicated by the TX low-periods not appearing on the RX signal line. The figure you shared also shows that the driver is unable to change the state of the LIN line when TX is toggled. As a result, the bus will remain in a recessive (high) state and all receiving nodes will perceive an idle bus (RX remains high as shown in the figure you shared). 

    During your tests, once the bus fault is removed, does a wake request need to be sent before communication can be reestablished? Or will the transceiver resume normal operation for any bit sequence once the fault is removed? If the latter is true, then the device has remained in normal mode bus was unable to drive the bus through the duration of the fault. 

    Let me know if this makes sense and if you have any other questions.

    Regards,
    Eric

  • 0 in reply to Eric Schott1
    Genius 3415 points

    Hi Eric

    Sorry for the late reply.

    If the bus fault is removed, communication cannot be restored.

    Communication will be restored only when a wake request is sent.

  • 0 in reply to CHO SR
    TI__Guru 53515 points

    Hi Cho,

    It appears in the image that no communication is attempted before the wake request is sent. Is the controller (or any controller on the bus) attempting to drive the bus at this time? Could you zoom in to the point where the first signal is sent on the TX line after the fault has been cleared? This would show if TLIN1022-Q1 is able to drive the bus in this state before the wake request is sent.

    Another thing to note is that when the controller sees that the RX line does not go low when it drives the TX line, it may register an error and will likely stop attempting to communicate. This exception will have to be handled by the node either by re-attempting the communication after some time to see if the fault has cleared, or by waiting for the other node to send a wake signal to retry communication (this case would likely appear similar to what you are experiencing).

    Regards,
    Eric

  • 0 in reply to Eric Schott1
    TI__Guru 53515 points

    Hi Cho,

    Have you been able to identify the cause of the apparent sleep behavior in TLIN1022-Q1? I'm interested to know if this is the result of the device state or some other system interaction.

    Regards,
    Eric Schott

  • 0 in reply to Eric Schott1
    Genius 3415 points

    Hi Eric

    The customer is delaying the answer to the question.

    I'm sorry, but please wait.