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.

TCAN4551-Q1: CAN problem

Part Number: TCAN4551-Q1
Other Parts Discussed in Thread: TCAN4550,

Tool/software:

We are using several TCAN4550 chips, and most of them work fine. However, one of the units is behaving abnormally.

Please help us investigate the possible cause.

At power-on, the CAN communication works normally. But after a period of operation, it stops transmitting CAN messages.

We traced the SPI communication:

  • MISO continues to provide normal output.

  • MOSI, when the CAN transmission fails, shows two different behaviors:

    • At first, it still responds normally to SPI communication — no abnormalities observed.

    • Later, even the SPI responses become abnormal, with MOSI returning 0xA0 or 0x40.

normal:

abnormal:

Could you also help confirm whether my interpretation of the SPI response is correct?

When decoding the response from MOSI, it appears to represent 0x0820, as shown in the image below.

From the TCAN4550 datasheet, 0xA0 indicates SPIERR | M_CAN_INT | VTWD.

Under what conditions would such a response be triggered?

  • Hello Hsinyu,

    I am unable to understand your SPI logic analyzer plots and make sense of the data.  The byte values don't make sense and I can't find the read/write Op Codes of 0x41 or 0x61 in the byte listing.  Also, the time scale does not allow me to see the individual clock and data bits, so I can't make sense of the plots.

    I also want to clarify MISO and MOSI signals because I think you have them reversed.

    MOSI is data that is transmitted From the MCU To the TCAN4550.

    MISO is data that is transmitted From the TCAN4550 to the MCU.

    Generally speaking SPI Errors are related to either an error in the SPI driver creating an incorrect format of the 4 signals or an incorrect number of clock edges while Chip Select (Enable) is Low.

    Assuming the SPI driver has the correct protocol to format the signals, most SPI errors come down to some form of clock related error.  The TCAN4551-Q1 uses a FIFO on the SPI interface to handle the frequency domain boundary crossing between the SPI Clock frequency used for the MCU data, and the high speed clock provided on the OSC1/2 pins (either a crystal or single-ended clock) that is used by the TCAN4551-Q1 digital core.

    If either the SPI clock or the high speed clock is disrupted, there will be error getting the exact amount of data through the FIFO resulting in one of the various SPI errors.

    Based on your description that the device operates normally for a period of time before the errors occur, I expect that there may be some issue with the stability of the high speed clock.  Because the device supports both a crystal and a single-ended clock on the OSC1/2 pins, this circuit needs to be optimized to ensure the device doesn't switch clock modes during operation.

    For example when using a crystal, the voltage on the OSC2 pin must remain above 150mV to avoid the device thinking the pin is "grounded" and switch to single-ended clock mode.  If the crystal circuit is not optimized, the voltage amplitude of the oscillation waveform can become large enough that the lowest portion of the waveform can trigger a mode switch, and if this occurs, the high speed clock will be disrupted and any SPI and CAN communication during this disruption will have errors. 

    You may need to adjust the components on your clock circuit if this is the case.  You can find more information in the TCAN455x Clock Optimization and Design Guidelines Application Report (Link).  The solution to clock related issues is to add a series resistance between the OSC1 pin and the crystal, or to increase the value of the load capacitors on the crystal.

    Can you share a schematic for review?

    Regards,

    Jonathan

  • Hi Jonathan,

    After swapping the two TCAN4551 chips, both units are working properly now.
    It’s likely that there was an issue during the factory installation of the TCAN4551.
    The problem has now been resolved.

    Thank you for your support. The issue has been resolved after further inspection.

    Hsinyu

  • Hi Hsinyu,

    Thanks for letting me know this issue was resolved and likely an assembly issue wit these specific boards.

    Regards,

    Jonathan