TCAN4551-Q1: stuck in sleep mode

Hi Fanbin,

Fanbin Meng said:

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.

Regards,

Jonathan

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
iotuc@ubuntu:~$

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;
733
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         }
739
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         }
745
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         }
751
752         return work_done;
753 }

What does make tcan4551 enter these error states?

thank you!

Hi SHUANGLI,

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.

Regards,

Jonathan

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 ?

Regards,

Pingan

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.

Regards,

Jonathan

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.

Regards,

Jonathan

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:~$
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.
iotuc@ubuntu:~$

[ 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,

Pingan Ji said:

[ 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.

Regards,

Jonathan

Hi Jonathan,

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

Best regards,

Pingan