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: stuck in sleep mode

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

Hi team,

My customer has a design with TCAN4551  and they has trouble to wake up the device, could you help comments below questions:

1. device ID

The device ID the read out is not aligned with the datasheet, why?


2. the device is stuck in the sleep mode

When the customer has run the configuration code, they found the 0x800=0, which is sleep mode

strangely, the resister that the default value is not 0 still be read 0 out, like [31:30]

Could the team help comment on this case, below is the


initial code



  • Hi Fanbin,

    1. device ID

    The device ID the read out is not aligned with the datasheet, why?

    This is actually the value of the MCAN Core Release Register that has a register address of 0x1000 in the TCAN4551. 

    This means that there is an error in the firmware that is reading register 0x1000 instead of 0x0000. This is likely the issue with the other registers not having the correct values, and not being configured properly.

    It looks like the code was reused or based on a different design that directly used the MCAN controller. The TCAN4551 uses the MCAN IP and all of the MCAN registers have had their register address offset by 0x1000.  Therefore, MCAN register 0x00 is actually 0x1000 in the TCAN4551.

    I will also note that the TCAN4550 controls the MCAN Clock Stop Request (CSR) bit through hardware and the digital state machine.  Therefore, the CSR bits should never be directly written to. 

    The MODE_SEL bits in register 0x0800[7:6] should be used to change between the Standby, Normal, and Sleep modes in the TCAN4551.  The MCAN CCCR.INIT and CCE bits do need to be set to '1' before configuring the Protected bits, but this is different than a mode change in the TCAN4551.  I will note that a device mode change will automatically change the INIT bit value.

    I saw that the schematic shows OSC2 as an output based on the arrow indicator.  This is incorrect and OSC1 is the output of the amplifier that sources current to the crystal.  When the device is used with a single-ended clock signal, the OSC1 pin becomes an input pin.  Please see the TCAN455x Clock Optimization and Design Guidelines application note (Link) for more information about the clock circuit.



  • Hi, Jonathan!

    In SCH we use out arrow is because in datasheet Pin20 is defined “O”. And EVM also uses out arrow.

    Let’s ignore pin20 arrow direction because it won’t affect actual circuit. I see in EVM, it has the same connection.

    So, I don’t think it’s an issue. What do you think?

    Thank you!

  • this is massage from our BSP engineer:

    We could receive can messages with tool candump,but couldn't send can message. The error log:


    iotuc@ubuntu:~$ sudo ./cansend can0 123#DEADBEEF
    iotuc@ubuntu:~$ dmesg | grep entered
    [ 1155.027280] tcan4x5x spi1.0 can0: entered error warning state
    [ 1155.028107] tcan4x5x spi1.0 can0: entered error passive state


    The driver code:


    729 static int m_can_handle_state_errors(struct net_device *dev, u32 psr)
    730 {
    731         struct m_can_classdev *cdev = netdev_priv(dev);
    732         int work_done = 0;
    734         if (psr & PSR_EW && cdev->can.state != CAN_STATE_ERROR_WARNING) {
    735                 netdev_dbg(dev, "entered error warning state\n");
    736                 work_done += m_can_handle_state_change(dev,
    737                                                        CAN_STATE_ERROR_WARNING);
    738         }
    740         if (psr & PSR_EP && cdev->can.state != CAN_STATE_ERROR_PASSIVE) {
    741                 netdev_dbg(dev, "entered error passive state\n");
    742                 work_done += m_can_handle_state_change(dev,
    743                                                        CAN_STATE_ERROR_PASSIVE);
    744         }
    746         if (psr & PSR_BO && cdev->can.state != CAN_STATE_BUS_OFF) {
    747                 netdev_dbg(dev, "entered error bus off state\n");
    748                 work_done += m_can_handle_state_change(dev,
    749                                                        CAN_STATE_BUS_OFF);
    750         }
    752         return work_done;
    753 }


    What does make tcan4551 enter these error states?

    thank you!


    These errors typically come from incompatible Bit Timing configurations between the different devices on a CAN bus.  When the messages are transmitted with different settings, the other devices will sample the data based on a different set of bit timing parameters and detect bit errors which violate the CAN message protocol and cause CRC errors.  This causes those devices to throw and Error Flag/Frame on the CAN bus.

    Each error frame increases the TCAN4551's Transmit Error Counter and causes it to increase up through the various Error Warning and Error Passive states until it eventually enters the Bus Off state.  This is all defined in the CAN Standard Protocol.

    The Nominal and Data Bit Timing configurations for all devices on a CAN bus should match to prevent these types of errors.  Therefore, the TCAN4551's configuration may need to be changed to match the other devices on the CAN bus.



  • Hi Jonathan,

    Thanks for your help. As we mentioned, the tcan4551 can receive CAN messages. 

    some test:

    iotuc@ubuntu:~$ sudo ./candump can0
    can0 002 [8] 01 02 03 04 05 06 07 08
    can0 002 [8] 01 02 03 04 05 06 07 08

    Do the tcan4551 receiver and transmitter use different clock sources ? How to verify the tcan4551 Bit Timing configurations ? Is it possible for impedance matching or other hardware reasons ?



  • Hi Pingan,

    I can only tell you how to verify the TCAN4550 bit timings, and hopefully you can determine the timing configuration for other devices on your CAN bus.

    The Nominal and Data Bit Timing configurations are set in registers 0x101C and 0x100C.  If you are using CAN FD, then the Transmitter Delay Compensation register 0x1048 also needs to be set.

    If you are unfamiliar with CAN Bit timings, section 4.1 of the TCAN45xx Software User's Guide (Link) gives an overview and an example.

    Another good reference is the MCAN User's Manual (Link) published by Bosch.  The TCAN4550 uses this Bosch MCAN IP and not all of the information could be included in the TCAN4550 datasheet.  So you can think of the MCAN User's Manual as a supplemental document.  Just note that all of the MCAN registers have been given an offset of 0x1000 to their register address.  For example, the Control register in the MCAN document is address 0x18, but in the TCAN4550 it is address 0x1018.

    Other possible issues are impedance matching or hardware issues.  You should verify that the CAN bus has the proper termination at both end of the bus.  You could use a scope to monitor the CANH and CANL signals to check for any signal integrity issues or fault conditions such as a short or open condition on one of the signals which could result in an error.



  • Hi Pingan,

    Also, no, the transmitter and receiver use the same clock source. 

    One additional thought is that if you are able to receive messages from other CAN nodes, but not transmit them without generating an error, then you may need to adjust the Transmitter Delay Compensation value if this is a CAN FD message because the secondary sample point may not be correct.



  • Hi Jonathan,

    Thank for your help. The clock frequency is 20MHz. And I send a CAN not CAN FD message to test the timing configuration. Is the value correct ?

    bitrate 250000:

    iotuc@ubuntu:~$ sudo ip link set can0 down
    iotuc@ubuntu:~$ sudo ip link set can0 type can bitrate 250000
    iotuc@ubuntu:~$ sudo ip link set can0 up
    iotuc@ubuntu:~$ sudo ./cansend can0 123#DEADBEEF
    iotuc@ubuntu:~$ dmesg | grep tcan4x5x_show_reg
    [ 916.065655] tcan4x5x spi1.0: tcan4x5x_show_reg: 100c M_CAN_DBTP a33
    [ 916.065701] tcan4x5x spi1.0: tcan4x5x_show_reg: 1018 M_CAN_CCCR 0
    [ 916.065743] tcan4x5x spi1.0: tcan4x5x_show_reg: 101c M_CAN_NBTP 4409
    [ 916.065785] tcan4x5x spi1.0: tcan4x5x_show_reg: 1048 M_CAN_TDCR 0

    bitrate 50000:
    iotuc@ubuntu:~$ sudo ip link set can0 down
    iotuc@ubuntu:~$ sudo ip link set can0 type can bitrate 50000
    iotuc@ubuntu:~$ sudo ip link set can0 up
    iotuc@ubuntu:~$ sudo ./cansend can0 123#DEADBEEF

    [ 1131.126881] tcan4x5x spi1.0: tcan4x5x_show_reg: 100c M_CAN_DBTP a33
    [ 1131.126920] tcan4x5x spi1.0: tcan4x5x_show_reg: 1018 M_CAN_CCCR 0
    [ 1131.126960] tcan4x5x spi1.0: tcan4x5x_show_reg: 101c M_CAN_NBTP 1ad18
    [ 1131.126997] tcan4x5x spi1.0: tcan4x5x_show_reg: 1048 M_CAN_TDCR 0


  • And I also noticed that the  CAN receiver just received the data 0,

     root@am57xx-hs-evm:~# candump can0
    can0 000 [0]

    the captured CANH signal:


    And I trace the data:

    iotuc@ubuntu:~$ dmesg | grep m_can_tx_handler
    [ 70.029034] tcan4x5x spi1.0 can0: m_can_tx_handler:m_can_fifo_write M_CAN_FIFO_ID=0x48c0000 .
    [ 70.029045] tcan4x5x spi1.0 can0: m_can_tx_handler:m_can_fifo_write M_CAN_FIFO_DLC=0x880000 .
    [ 70.029234] tcan4x5x spi1.0 can0: m_can_tx_handler:Enable TX FIFO element to start transfer.
    [ 70.029239] tcan4x5x spi1.0 can0: m_can_tx_handler:M_CAN_TXBAR = 0x1.

    [ 70.029027] tcan4x5x spi1.0: tcan4x5x_write_fifo:addr=0x8908 val=0x48c0000
    [ 70.029040] tcan4x5x spi1.0: tcan4x5x_write_fifo:addr=0x890c val=0x880000
    [ 70.029050] tcan4x5x spi1.0: tcan4x5x_write_fifo:addr=0x8910 val=0x44332211
    [ 70.029055] tcan4x5x spi1.0: tcan4x5x_write_fifo:addr=0x8914 val=0x88776655

    so the addr 0x8908 is M_CAN_FIFO_ID, the 0x890c is M_CAN_FIFO_DLC, the 0x8910 and  0x8914  is data.

    In this case, I run the command: sudo ./cansend can0 123#1122334455667788 to test.

  • Hi Pingan,

    [ 916.065743] tcan4x5x spi1.0: tcan4x5x_show_reg: 101c M_CAN_NBTP 4409

    The 0x4409 value sets the correct number of time quanta to create a 250kbps Nominal (Arbitration) bit rate with an 80% sample point. 

    What is the Data bit rate you are wanting to configure?  It is also 250kbps?  I see you are using DBTP = 0xa33 for both the 250kbps and 50kbps configurations, and I don't think this is correct for either.  But I don't know what your intended bit rate is for the Data phase of the message.

    I would suggest reviewing the MCAN User's Manual (Link) published by Bosch for more information on the MCAN features and MRAM buffer elements. 

    I'm not sure your TX Buffer element is getting the data in the correct locations.  Address 0x8908 = 0x48c0000 should be word "T0" in the MCAN User's Manual Tx Buffer Element table.  If you are trying to send a message with ID = 0x123, then bits 28:0 of this word should be set to 0x123.  Also, because this is a 29-bit ID, the XTD bit (bit 30) should be set to "1".  You may want to verify the drivers are loading the data into the TX Buffer FIFO elements correctly.  CAN FD messages also need the FDF bit set as well as the BRS bit if you are doing Bit Rate Switching.



  • Hi Jonathan,

    Many thanks for your help. Now the tcan4551 works, it can send and receive CAN messages.

    Best regards,


  • Hi Pingan,

    You're welcome, I'm glad I could help.