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.

TCAN1042HGV-Q1: DC/DC Control Can Transceiver Recommendation

Part Number: TCAN1042HGV-Q1
Other Parts Discussed in Thread: LM5160, ISO7742

Hi Team,

The customer is using the TCAN1042HGV-Q1 for the electric compressor inverter.

Even if the secondary circuit enters Sleep mode and does not consume electricity, 20 mA is consumed continuously switching the Transformers in the Fly-buck circuit on the primary side.

The customer wants to enable/disable the LM5160 IC using CAN Transceiver with wake-up function.

Q1: Is there any way to enable/disable LM5160 IC using CAN Transceiver with wake-up function?

Q2. Please recommend a product that can enable/disable LM5160.

  • Hi Cho,

    Have you considered the use of a transceiver with an INH function such as TCAN1043? Such a device has a dedicated battery-level output designed to control the enable of a local voltage regulator to allow the entire node to be powered down during sleep mode. It looks like such an implementation may be tricky here due to the isolation, but relaying such a control signal across the isolation barrier seems unavoidable if the intent is to have the transceiver control the regulator. 

    Does this sound like a desired solution for this system? Or would you prefer to stick with TCAN1042 and build some external logic to detect the transceiver's mode?

    Regards,
    Eric Schott

  • Hi Eric,

    Please advise if there is a way to stick to TCAN1042 and build external logic.

    The customer wants to choose the better one out of the two.

  • Hi Cho,

    This is possible, but I would recommend the integrated solution for simplicity. The trouble with the TCAN1043 solution would be how to transfer the INH signal across the isolation barrier. If 5V is used for Vsup (reference for INH output), this signal could be transferred using a spare isolator channel (swap U13 for ISO7742). The STB pin function could remain the same and EN be tied high (only needed for listen mode and manual use of standby mode). 

    For external logic using the TCAN1042, a possible solution would be a sort of timing circuit that's sensitive to a dominant (low) signal on the RXD line. TCAN1042 will indicate a bus wake event by driving the RXD line dominant for some time after a WUP is received (time held low is dependant on WUP signal on the CAN bus). The timing circuit would need to recognize this pulse on RXD and enable the local voltage regulator to turn on the node. During normal operation, this circuit would need to be disabled or overwritten to prevent normal CAN data on the RXD line from interfering with the voltage regulator while the node is active. I don't know of any such circuit design to be used discretely for this purpose, which is why I'd recommend the integrated solution offered by TCAN1043. If the customer decides to design such a timing circuit, I would be happy to review it and evaluate it's compatibility with TCAN1042 and the system.

    Regards,
    Eric Schott

  • Hi Eric,

    Thank you for your support.

    I will recommend using TCAN1043 to the customer.

    Please review additional questions and schematics.

    Q1 : Should I connect TCAN1043 INH pin and LM5160 EN pin directly?

    Q2 : Is it correct to connect R88 and R89 to GND on the TCAN10439 pin (WAKE)?

          - 3ch digital isolator is used due to customer controller isolation structure.

          - Tx, Rx and STB were connected to the MCU, but additional isolation connections between the EN pin and FAULT pin of TCAN1043 were not controlled by the MCU.

          - MCU is on the 2nd side, so MCU will be shut down when INH is off.

    Q3 : What is the EN pin and FAULT pin treatment for TCAN1043?

  • Hi Cho,

    Please see my responses below. 

    Q1 : Should I connect TCAN1043 INH pin and LM5160 EN pin directly?

    Typically this is the recommended configuration. However, it looks like the transceiver and voltage regulator do not share a common ground. I would double check with both devices that TCAN1043 (driving battery potential) is capable of driving the correct input voltage on the regulator with this ground configuration. A pull-down resistor should also be included on the INH line to bias the line low when INH is disabled (output is open-source). 

    Q2 : Is it correct to connect R88 and R89 to GND on the TCAN10439 pin (WAKE)?

    If the WAKE function is not used, this pin can be tied to GND or Vbat. The resistor network is recommended to bias the input for physical switch implementations. 

    Tx, Rx and STB were connected to the MCU, but additional isolation connections between the EN pin and FAULT pin of TCAN1043 were not controlled by the MCU.

    EN is only used for silent mode and manually entering standby mode (see Figure 9-4). Wake-up via the INH enable will work without the FAULT pin. This output would carry extra information that can be inferred by the MCU in this system (distinction between CAN bus and local WAKE not needed as local WAKE is not used). 

    Q3 : What is the EN pin and FAULT pin treatment for TCAN1043?

    EN should be tied to Vio if unused. The FAULT output can be left floating. 

    Regards,
    Eric Schott

  • Hi Eric,

    I have a question while checking the [Figure 9-4. State Diagram].

    Enable pin is connected to the Vio. So the enable pin is always high.

    I think the current system configuration only works in the two situations below.

    The customer's operating sequence cannot be standby mode.

    The system does not meet the EN:L & STB:L conditions.

    Is EN:L a prerequisite for entering Standby Mode from Sleep Mode to CAN wake source?

  • Hi Cho,

    With EN tied to Vio, you will not be able to enter standby mode manually from any other mode. However, if the device is put into sleep mode (nSTB: L, EN: H for t > tGO-TO-SLEEP), then any wake request from the CAN bus or WAKE pin will place the device into standby mode (far right arrow Figure 9-4). This transition from sleep to standby is dependant on the WAKERQ flag and will enable the INH line to wake up the local node. This standby state can be seen in at the bottom of the second box you created on Table 9-3. 

    Typically the manual transition into Standby is not used unless some intermediate low-power state is needed. Such a state leaves the transceiver in a lower power mode, but leaves INH enabled so the node remains active. In contrast, sleep mode puts the entire node into a low-power state. Silent mode is a similar intermediate low-power state. Based on your initial description it didn't sound like such states were required. If these sound desirable, it may be worth considering how to get an additional signal across the isolation barrier to drive the EN line. 

    Regards,
    Eric Schott

  • Hi Eric,

    Please support our customer's additional questions.

    Q1. After entering Sleep mode, when a CAN wake-up request occurs, the EN pin is always in a high state.

    If it is impossible to enter Standby mode, are you sure you want to enter Go-to-sleep mode?

    Q2. When entering Go-to-sleep mode according to the first condition, if the nSTB signal does not change from low to high within 5us, will it return to Sleep mode again?

    How can I use tgo_to_sleep holdtime on Max 50us?

    Q3. Please let me know the pattern information of [Wake-up Event:CAN bus] for wake-up test.

  • Hi Cho,

    With EN tied high, the device cannot be manually put into Standby mode. However, when the device wake from sleep, it will still enter standby mode due to the internal wake flag being set. This is true even if the EN remains tied high. View the state diagram in FIgure 9-4 for more info.

    Yes, the nSTB pin will have to be held low for at least tGO-TO-SLEEP in order to enter sleep mode. If the nSTB pin is driven high again before this timer expires, the device will return to Normal mode. This time is meant to give the system a bit of buffer time during a transition to sleep mode before the INH line is disabled and power is removed from the node. 

    The details and timing requirements for the wake up pulse (WUP) can be seen in datasheet section 9.4.6.1. Note that the way this WUP is defined will allow any valid CAN frame to meet these requirements, essentially making any CAN frame a valid WUP event. 

    Regards,
    Eric Schott

  • Hi Eric,

    Thank you for your support.

    We had a problem during the system operation review.

    It takes at min 50ms for the nSTB signal from the MCU to be high output after power on.

    - Power on -> Standby mode -> EN:H, nSTB:L -> Go-to-Sleep mode -> INH:H -> LM5160 Enable -> MCU start -> nSTB:H => Total 50ms

    We expect that it will be changed to slip mode due to t>tGO-TO-SLEEP condition and will be INH:L again.

    Q1. I think it will be impossible to operate with the circuit configuration currently under review. Is it correct?

    So, added EN pin control by applying 4ch digital isolator.

    Please review the schematic.

    Q2. Please check if the operating scenario we think is normal.

    - Power on -> Standby mode(EN:L, nSTB:L) -> INH:H -> LM5160 Enable -> MCU start -> EN:H & nSTB:H -> Normal mode -> MCU EN:H, nSTB:L -> Sleep mode -> INH:L -> LM5160 Disable -> MCU shutdown

  • Hi Cho,

    Thanks for your explanation of the startup sequence. You're correct that with the 50ms delay between when EN becomes high to when nSTB can also be driven high would normally be a valid condition to put the device to sleep. However, after initial power-up (Vsup initially supplied) an internal flag will be set that will prevent the device from going into sleep mode. This flag is cleared the first time the device transitions into normal mode. This means that the startup sequence here can be valid without risking the device going into sleep mode before the MCU can respond. See Table 9-1 for more info on the PWRON flag. 

    The second scenario also looks good. This more closely follows the state diagram of the device which doesn't take the PWRON flag into account. 

    In short, both of these implementations are valid. The option with EN controlled will give the system more options in terms of control and device modes. With this design already done, it seems to be a question of prefered ISO device. 

    Let me know if you have any questions on option 1 or the internal flags for TCAN1043.

    Regards,
    Eric Schott

  • Hi Eric,

    Thank you for your support.

    The initial Power on Start judged that there was no problem.

    In addition, TCAN1043 waits in slip mode after MCU shutdown.

    - Operating system -> MCU shutdown -> EN:H, NSTB:L -> Go-to-Sleep mode -> Sleep mode -> INH-off -> LM5160 shutdown -> CAN Wake-up Event -> Standby mode -> EN:H, NSTB:L -> WAKERQ Cleared -> Go-to-Sleep mode, INH:H -> LM5160 Enable -> MCU wake-up -> EN:H, NSTB:H ->  Normal mode or Sleep mode

    Q1 : In the operating scenario, the time from MCU to NSTB:H in the yellow part is 50ms. I think tGO-TO-SLEEP will be in sleep mode again. Is it right that I can't keep coming out of sleep mode?

    Q2 : In the current scenario, is there a way to enter normal mode?

    Q3 : What is the maximum time for the red?(Standby mode -> EN:H, NSTB:L -> WAKERQ Cleared -> Go-to-Sleep mode, INH:H)

  • Hi Cho,

    When TCAN1043 receives a wake up event and transitions to standby mode from sleep mode, an internal wake request (WAKERQ) flag is set. This flag will prevent the device from going back into sleep mode until it is cleared, so the system is not required to respond within tGO-TO-SLEEP of INH becoming active. On the state diagram, this is depicted by "WAKERQ Cleared" as a needed condition to transition to Go-to-sleep mode from standby mode. The wake request flag is cleared once the device enters normal mode (or an undervoltage event occurs). 

    Regards,
    Eric Schott

  • Hi Eric,

    Thank you for the explanation.

    I have completed the explanation to the customer.

    The customer will proceed with the EVM test as option number 1 and choose between the 2 options.