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.

TPIC1021: Difficulty with hardware troubleshooting of LIN interface module

Part Number: TPIC1021

Support Path: /Product/Development and troubleshooting/

Hi TI,

I am having trouble with troubleshooting the hardware of the TPIC1021 LIN bus interface module in an automotive environment.

My configuration for the 1 master device and 2 slave devices are as follows:

  • LIN wire connected directly to the LIN pin of the TPIC1021;
  • MASTER DEVICE ONLY - LIN wire pulled high via 1k resistor and series diode; 
  • Vsupply connected to 12V supply voltage;
  • GND connected to common ground;
  • INH not connected;
  • NWake not connected;
  • EN pin directly connected to 3.3V;
  • RXD pin directly connected to MCU UART RX;
  • TXD pin directly connected to MCU UART TX;

The MCU for all three devices is the STM8S103F3, which uses the normal UART protocol to for transmit and receive.  Both the TX and RX are internally pulled high and communication is commenced by a logic low on the TX pin, followed by the address of the slave and the command.  Communication is detected on the RX by a falling edge trigger.

The communication between the two MCUs works fine on the workbench when the two TPIC1021s (master & slave) are removed.  However, when the two interface modules are included between the two MCUs, there appears to be no communication on the LIN wire.  Unfortunately I don't have a scope, only a Saleae Logic analyser which is not 12V tolerant.  As such, instead of dynamically testing the communication, I tried to perform static tests as follow:

  • Provide power to the MCU (3.3V) and the TPIC1021 (12V);
  • Initial state - EN=3.3V, RXD and TXD pulled high from MCU;
  • Alternatively pulling the LIN wire and the TX of the MCU low;

The results were not quite as helpful as I had hoped.  Pulling the TX low had no effect on the LIN IO pin; however pulling the LIN wire low resulted in a logic low on the RXD pin as expected.  I am uncertain as how to proceed with the troubleshooting.  The situation would've been mitigated if I had an oscilloscope or a 12V tolerant logic analyser, but alas, that is not possible at the time being.

My questions are:

  • Does the LIN interface module initially enter low power or standby mode and waits for a wake up condition?
  • There is constant 3.3V on the EN pin, so does the module wait for an explicit EN low to high for wake up after power up?
  • Does the NWAKE pin being not connected affect the TPIC1021?
  • Is there a specific logic condition on the TXD pin that has to be met before the LIN pin follows the TXD pin?

I have uploaded the schematic involving the LIN-MCU connections.  Due to company intellectual property, I cannot upload the entire schematic.

Any help with the above will be greatly appreciated.  Thank you in advance.

TI_E2E_schematic_1.pdf

  • Hello Willie,

    From your description it sounds like you are using the TPIC1021 device correctly. To answer your questions:

    •Does the LIN interface module initially enter low power or standby mode and waits for a wake up condition? - While the low power mode is the default state for the TPIC1021 device (assuming Vsup > Vsup_undervoltage), a logic high on the EN pin will cause the device to immediately switch to normal mode from low power or standby mode.

    •There is constant 3.3V on the EN pin, so does the module wait for an explicit EN low to high for wake up after power up? - The EN pin is level triggered and not edge triggered. A constant 3.3V should force the part into normal mode.

    •Does the NWAKE pin being not connected affect the TPIC1021? - The NWAKE pin as an internal pull-up current that is 10uA, so leaving the pin floating will result in it defaulting high. This should not be a problem.

    •Is there a specific logic condition on the TXD pin that has to be met before the LIN pin follows the TXD pin? - Once the part is in normal mode (EN is high) then the LIN pin should follow the TXD pin. If TXD pin is logic high (TXD > 2V per the data sheet) then the LIN bus should be in recessive state and if TXD pin is logic low then the LIN bus should be pulled down into dominant state.

    One thing to check is the grounding of the TPIC1021 device. In your description you described GND being connected to the common GND while INH and NWAKE are not connected. However in the schematic you attached there is no connection shown for pin 5 GND (it looks the same as pin 3 NWAKE and pin 8 INH in the schematic).

    Assuming the grounding is correct the other thing to check is that the logic voltage on the EN pin is actually being achieved. The TPIC1021 part has an internal pull-down resistor that is nominally 350 kOhms, that could pull the voltage down slightly. However from your schematic it looks like the EN pin is directly connected to the 3.3V supply so this should be okay, but no harm in double checking.

    Please let me know if you continue to have issues with the TPIC1021 device after checking the grounding and EN pin voltage. If you have any more question feel free to ask.

    Best Regards,
    Richard Broughton
    Transceiver Interface - Applications Engineer
  • Hi Richard,

    Thank you for your speedy response, it is much appreciated.

    Yes, the TPIC1021 is correctly grounded even though the schematic does not indicate as such.  Please see attached photo of the IC mounted onto our PCB.  

    For the master device at start-up without the MCU inserted, the pins have the following voltages:

    • Pin1, RXD          = 10.3V (floating);
    • Pin2, EN             = 3.3V;
    • Pin3, NWAKE    = 9.9V (floating);
    • Pin4, TXD           = 9.8V (floating);
    • Pin5, GND          = 0V (common ground);
    • Pin6, LIN             = 11.6V (externally pulled high);
    • Pin7, Vsup          = 11.8V;
    • Pin8, INH            = 9.9V (floating);

    For the master device at start-up with the MCU inserted (UART initialised and pins internally pulled high), the TPIC1021 pins have the following voltages:

    • Pin1, RXD          = 3.8V (MCU internally pulled high);
    • Pin2, EN             = 3.3V;
    • Pin3, NWAKE    = 6.2V (floating);
    • Pin4, TXD           = 3.3V (MCU internally pulled high);
    • Pin5, GND          = 0V (common ground);
    • Pin6, LIN             = 10.9V (externally pulled high);
    • Pin7, Vsup          = 11.3V;
    • Pin8, INH            = 3.7V (floating);

    With the above configuration, i.e. MCU inserted, UART initialised and pins internally pulled high, the following tests are performed:

    • TPIC1021 LIN pin forced to ground    - RXD = 0.6V;  INH & NWAKE is slightly dipped;  All else remains the same as expected;
    • TPIC1021 TXD forced to ground         - LIN = 8.6V (from 11V);  unexpected behaviour of RXD = NWAKE = INH ~ 0.7V;

    As such, when a logic low is placed on the TXD pin, the LIN pin is not pulled down enough to register a dominant state on the signal wire and therefore no communication on the wire is taking place.

    One thing (among others) I am not 100% certain is whether or not the TPIC1021 is actually mounted onto the PCB with the correct alignment.  The datasheet indicates a notch at Pin1 (RXD), however I have not been able to see any notch or indication to any pin.  Can you please double check whether the chip is mounted correctly?  Also, can you suggest any further troubleshooting checks/tests?

    Thanks again in advance.

    Kind regards,

    Willie, Jnr. EETI_E2E_photo_1.pdf

  • Hello Willie,

    From the photo you attached it looks like the TPIC1021 is not mounted onto the PCB with the correct alignment. The horizontal lines on one side of the device top usually indicate the pin 1 side of the device. Try flipping the device around and everything should work normally, although you may new a fresh device as the one that was mounted in the incorrect alignment was exposed to some large voltage stresses on some of the pins due to the misalignment.

    The misalignment also explains the voltage measurements you took. In this scenario the GND pin of the device (pin 5) is connected to the RXD spot on your board. So in the first example without the MCU inserted the GND pin on the TPIC1021 device is floating and all the pins not connected directly to a voltage supply on the board float towards 12V.

    In the second example with the MCU inserted the ground pin of the device is connected to the RXD trace on the PCB which is at 3.3V and there for the measured voltage on a lot of the pins is closer to 3.3V.

    Please let me know if there are anymore issues once the device alignment is fixed.

    Best Regards,
    Richard Broughton
    Transceiver Interface - Applications Engineer
  • Hi Richard,

    After going through the datasheet yet again and specifically looking at the Mechanical Data (Section 13) information, I assumed the IC was mounted with the incorrect alignment.  I removed the old one and replaced it with a spare TPIC1021 with the correct alignment, i.e. Pin1 is to the left of the side with the horizontal lines.

    Having replaced the IC, I checked the pin voltages again after startup with MCU inserted and RX/TX pins internally pulled high:

    • Pin1, RXD          = 3.3V (MCU internally pulled high);
    • Pin2, EN             = 3.3V;
    • Pin3, NWAKE    = 9.8V (floating);
    • Pin4, TXD           = 3.3V (MCU internally pulled high);
    • Pin5, GND          = 0V (common ground);
    • Pin6, LIN             = 11.5V (externally pulled high);
    • Pin7, Vsup          = 11.4V;
    • Pin8, INH            = 11.4V (floating);

    Performing the previous tests again resulted in the following reading:

    • TPIC1021 LIN pin forced to ground    - RXD = 0.1V;  INH & NWAKE is slightly dipped again;  All else remains unchanged;
    • TPIC1021 TXD forced to ground         - LIN = 11.4V (from 11.5V);  RXD, NWAKE & INH remains unchanged;

    As such, the LIN pin still doesn't follow the TXD pin by manually forcing TXD to ground.  However, having thoroughly gone through the datasheet again I noticed that the LIN wire return to the recessive state (~12V) after the dominant state timeout (~9ms) which wouldn't be seen without an oscilloscope or logic analyser on the LIN wire.  That's why it looks to the eye that the LIN pin doesn't follow the TXD pin.

    Therefore, I tried establishing communication between master and slave again by simply sending several bytes to the slave device.  By means of the logic analyser, I monitored the Master's TXD pin and saw the several bytes being transmitted to the master's TPIC1021 TXD pin at 14400 baud.  I also monitored the Slave's TPIC1021 RXD pin and saw nothing.  No bytes were received on the RXD pin.  As such, I concluded that the communication is not placed on the LIN pin.

    Any further recommendations or suggestions?

    Kind regards,

    Willie, Jnr. EE

  • Willie,

    Did you replace the device on both the master and the slave side with the new / correct alignment?

    You monitored the Slave's TPIC1021 RXD pin when the 14400 baud traffic was being sent to the master's TXD pin and saw nothing, could you also check the master's side RXD pin (it should read it's own transmission in real time)? One thing you could try is disconnecting the master from the slave and just try getting the master side to work first.

    Based on your pin readings it looks like the TPIC1021 device is correctly in normal mode since both the RXD pin is a 3.3V and the INH pin is pulled high to 11.4V (exactly same voltage as Vsup). In standby mode RXD would be driven low and in low power mode the INH pin would be high impedance. One thing you could check is to use a resistor to ground to check that the INH pin is actually being pulled up instead of just HiZ and floating at 11.4V. This would confirm the device is in normal mode.

    Let me know if checking just the master side improves results. I will keep investigating this in the mean time.

    Best Regards,
    Richard Broughton
    Transceiver Interface - Applications Engineer
  • Richard,

    Yes, I replaced both TPICs of the master and the slave and soldered new spare ICs.

    Thank you for the additional troubleshooting suggestions.  Unfortunately, I am currently not at work anymore and will only be able to perform these checks tomorrow.

    So if I understand you correctly, the LIN pin follows the TXD and the RXD follows the LIN pin of the same TPIC1021 regardless of whether or not a slave device is connected to the LIN wire?  Therefore, if the slave is removed from Lin bus (as per your suggestion) and the master transmits the byte "0x0d" to the TXD it should receive the same byte "0x0d" from the RXD?

    Elaborating further on this understanding, if the master transmit the byte "0x0d" to the TPIC1021's TXD pin and the logic analyser sees no communication on the RXD (i.e. RXD remains high), then I can assume there's a problem either between the TXD & LIN, or between the LIN & RXD pins?

    Kind regards,

    Willie, Jnr. EE

  • Willie,

    Your understanding is correct. The LIN pin follows TXD and the RXD follows the LIN pin of the same TPIC1021 device regardless of whether or not the slave device connected to the LIN wire (assuming the device is in normal mode, which it looks to be from your voltage measurements). As you mentioned, if you transmit the byte "0x0d" on the master device, you should see the data show up on the RXD pin of the same master device (after a small propagation delay) even if the master device is completely disconnected form the LIN bus / slave nodes.

    From your schematic it looks like the pull-up resistor and diode are local to the master side PCB. Even if they are not local there is a weaker version of the pull-up resistor (30 kOhm) inside the TPIC1021 device so the RXD pin on the master device should still react to the bus when data is being transmitted on the TXD pin.

    You can repeat the experiment where you manually pull the LIN pin to ground on the master device to make sure the LIN pin to RXD path is working on the master side as well. After that you can use the logic analyzer to monitor the TXD and RXD pins of the master device during data transmission while the master node is disconnected from the bus.

    If you get the same results you have been getting where the RXD pin reacts to the bus being pulled down but not to data being sent to the TXD pin on the same master device with the master node being disconnected from the bus, then you know the issues is on the TXD to LIN path on the master device / PCB somewhere.

    If the problem goes away when the master node is on it's own, then something is going wrong on the slave node or the bus itself that is preventing the master side from pulling down fully. The pull down current on the LIN pin for the TXD to LIN path is limited to 150mA typically (250mA max), so if there is a low resistance short or something like that on the bus it can prevent the TPIC1021 from pulling the bus down far enough to reach the RXD path's threshold.

    Please let me know how the next steps of troubleshooting turn out and if you have any further questions.

    Best Regards,
    Richard Broughton
    Transceiver Interface - Application's Engineer
  • Hi Richard,

    The Lin bus communication between the master and each of the slaves respectively is working fine for both transmit and receive from and to each device!

    I followed your suggestions by removing each device from the Lin bus and other nodes and testing it's own TPIC1021 IC.  I supplied power and checked the voltage at each of the pins as before, forced the LIN pin to ground and checked that the RXD pin followed suit and were grounded as well.  Then I connected a logic analyser to both the TXD and RXD pins, transmitted several bytes from the MCU, monitored both pins and verified that the transmitted bytes and the received bytes were the same thereby confirming that the TPIC1021 is fully functional in normal mode.

    I repeated this test for each of the devices individually before connecting them to the Lin bus.  Once connected to the Lin bus, I monitored each of the devices' TXD and RXD pins respectively and confirmed stable communication on the Lin wire for both transmit and receive signals to and from each of the devices.

    In conclusion, the primary problem I was experiencing was the misalignment of the TPIC1021 on the PCB.

    Thank you again for your assistance and suggestions for troubleshooting the hardware of the TPIC1021 Lin interface module.

    Kind regards,

    Willie, Jnr. EE

  • Willie,

    You're welcome! I'm glad it worked out and you were able to establish LIN bus communication.

    Best Regards,
    Richard Broughton
    Transceiver Interface - Applications Engineer