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.

TLIN1024-Q1: parallel input

Part Number: TLIN1024-Q1

Hi team,

Can we use TLIN102x like this? Shared TX and RX input, but with dedicating EN pin to select one of the devices to work.

I checked the block diagram, it looks that will be ok. 

How about for TCAN device? Will it work? Because it's TX and RX structure is different, i just put one of the CAN into standby mode and use a parallel one.

Dongbao

  • Dongbao,

    This would work for CAN and LIN, except in the case where a wake-up signal is received on the bus. In that condition, the RXD would toggle on the disabled device, and collide with the RXD of the enabled device. With CAN and LIN traffic on the bus of the disabled device, it is very likely that a wake-up signal would trigger a wake up on the transceiver. Is bus data expected on the buses while the transceivers are disabled?

    Regards,
  • Dongbao,

    Also, for the CAN case the unused transceiver would need to be powered off rather than merely disabled. This is because the RXD output uses a push-pull architecture that would remain active even in standby mode (since it is needed in order to communicate wake-up requests to the MCU/controller).

    Max
  • Hi Max, Eric

    So that's to say, customer need power off the unused CAN or LIN if bus datas are expected on the CAN/LIN bus.
    For TLIN1024, if there is a wakeup signal while EN keeps low, will device stay in the standby mode and waiting for the MCU to change the EN?

    Dongbao
  • Dongbao,

    That is correct, even if the devices are in sleep/standby mode, the RXD will indicate a wake up event on the bus. There is a high probability that LIN/CAN data frames will trigger a wake up event, causing the RXD for both devices to interfere with each other.

    Yes, the TLIN1024 will stay in standby mode after a wake up event until EN is switched to a high state for longer than tmode_change, which is at most 15us.

    Regards,