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.

TCAN1042HV-Q1: In idle mode, the output waveform of TCAN1042 will be deformed,

Part Number: TCAN1042HV-Q1

TCAN1042 encountered problems in use: in idle mode, the output waveform of TCAN1042 will be deformed, and NXP can receive data normally, resulting in customers using TCAN1042 products need to modify the program; affect the follow-up dosage, hope TI confirm the reasons for waveform deformation;

  • Garin,

    By idle mode do you mean sleep/standby mode? There are slight timing differences in the TCAN1042 and TJA1042 that could affect software timing. Is there any way you can provide oscilloscope screenshots of the deformed waveform and elaborate a bit more on the condition when it occurs?

    Regards,
  • Hi Garin,

    Do you have any updates on this? If this is still an issue for you, then following up on Eric's questions above can help us to better understand what is happening so that we can resolve it.

    By the way, there are a couple of ways in which data could be deformed in standby mode:

    If you mean the CANH/CANL signals, this is generally expected since the recessive levels will be biased towards ground rather than to VCC/2 as a way of saving power. (This is common to both TCAN1042 and TJA1042, and the level of distortion would depend on how many transceivers are in standby mode versus normal mode. Typically a CAN bus does not operate with a mix of standby and active nodes, though, unless partial networking is implemented.)

    If you mean the RXD signal, then there are some differences in the implementation of the wake-up functionality between TCAN1042 and TJA1042 that could cause the data to look different between these devices when in standby mode. (The TCAN1042 has been designed to hold RXD high until a wake-up pattern as defined by ISO 11898-2:2016 has been received, and then apply a hold-off period to each subsequent dominant bit.)

    If the issue is RXD distortion as described above, the solution should be to pull the STB pin low. Typically a node is held in standby mode only until a wake-up request is signaled via an initial high-to-low transition on RXD. After this, the controlling MCU should transition the node into normal mode by pulling STB low. It is not recommended to keep a node in standby mode even if it can continue to receive data, since this mode disables the transmitter circuitry and prevents the node from acknowledging messages or flagging errors.

    Max