CAN FD interfaces communicating correctly with each other on Thor

[KD7]

How to achieve normal communication between CAN FD interfaces, and what commands need to be input?

Previously, the CAN FD loopback test commands provided by NV were used, and the test passed.

However, when two CAN FD interfaces are interconnected, low-speed communication with 8-byte data can be achieved successfully. But high-speed communication at 8 Mbps with 64-byte data cannot be performed normally.

For example, when CAN0 and CAN1 are connected to each other, and CAN0 sends the command

“cansend can0 123#1122334455667788”

CAN1 can correctly receive the 8-byte data.

But when CAN0 sends the command

“ cansend can0 123##3112233445566778899AABBCCDDEEFF00112233445566778899AABBCCDD00112233445566778899AABBCCDD00112233445566778899AABBCCDD”

which contains 64 bytes of data, CAN1 fails to receive the data properly, and the bus enters the BUS-OFF state.

[KevinFFF]

Hi KD7,

Are you using the devkit or custom board for Thor?

How do you connect them between CAN0 and CAN1 to verify?
Please share the detailed commands to setup CAN and send the CAN-FD data.

Is you current issue specific to 8M CAN-FD?

[KD7]

Hello, (KevinFFF).

I’m developing functions using self - developed boards equipped with the Thor module. The CAN FD signals output by the module are converted into differential signals through a transceiver. The differential signals of CAN 1 and CAN 0 can ensure that there is no problem with the hardware connection because the low - speed communication between CAN 0 and CAN 1 is normal.

When CAN 0 sends 8 - byte data, CAN 1 can receive it normally, but the measured differential signal waveform has a maximum rate of only 1 Mbps. When CAN 0 sends 64 - byte data, CAN 1 cannot receive it normally, and the bus enters the BUS - OFF state. The specific commands for setting CAN are as follows:

Open the terminal window and enter:

ip link set down can0
ip link set down can1
ip link set can0 up type can bitrate 1000000 dbitrate 8000000 berr - reporting on fd on
ip link set can1 up type can bitrate 1000000 dbitrate 8000000 berr - reporting on fd on

At this time, CAN 0 and CAN 1 are configured. Enter

#ip - details link show can0and ip - details link show can1

to check the working status of the two CAN interfaces, which are operating normally. Open another terminal window and enter

#candump can1

and then CAN 1 enters the receiving mode. In the original working input, enter

#cansend can0 123#1122334455667788.

At this time, CAN 1 can display the normal reception of 8 - byte data, but the measured waveform transmission rate is only 1 Mbps.

When entering

# cansend can0 123##3112233445566778899AABBCCDDEEFF00112233445566778899AABBCCDD00112233445566778899AABBCCDD00112233445566778899AABBCCDD00112233445566778899AABBCCDD

on the CAN 0 side, CAN 1 cannot receive the data normally. Checking the status with

#ip - details link show can0

shows that the bus has entered the BUS - OFF state.

However, with the same rear - end CAN transceiver hardware, when using the SPI - to - CAN - FD solution on the RK platform and inputting the same operation instructions and adopting the same operation method, CAN 1 can receive 64 - byte data normally, and the measured waveform transmission rate can reach more than 5 Mbps.

Since these operation instructions come from the official RK technical document for testing CAN FD, they may not be applicable to the NV platform. This phenomenon is not specific to 8M CAN - FD; the same problem exists for 5M. I think that normal transmission of 64 - byte data is required to achieve high - speed CAN FD, while 8 - byte data transmission is low - speed CAN communication.

[KevinFFF]

@KD7

converted into differential signals through a transceiver.

Which CAN transceiver is used in your setup?
Have you confirmed it supporting upto 8M bitrate?

@KD7

This phenomenon is not specific to 8M CAN - FD; the same problem exists for 5M.

Is there the issue with 1M CAN-FD?

# ip link set can0 up type can bitrate 1000000 dbitrate 1000000 berr - reporting on fd on
# ip link set can1 up type can bitrate 1000000 dbitrate 1000000 berr - reporting on fd on

@KD7

shows that the bus has entered the BUS - OFF state.

Please share the full dmesg and device tree for further check.

[KD7]

When CAN FD is configured at 3 Mbps:​​

• CAN0 and CAN1 communicate normally.

• The TX and CAN differential signal waveforms are normal, as shown in the figure below.

• Even when CAN0 and CAN1 are disconnected, the TX and CAN differential signal waveforms remain normal.

• 
  

​When CAN FD is configured at 5 Mbps:​​

• CAN0 and CAN1 fail to communicate normally.

• The TX and CAN differential signal waveforms are abnormal, as shown in the figure below.

• Even when CAN0 and CAN1 are disconnected, the TX and CAN differential signal waveforms remain abnormal.

• 
  

​Additional observation on the NV THOR platform development board:​​

• When CAN0 and CAN1 are directly connected via their differential signal lines:

  • CAN FD at 3 Mbps works normally.

  • CAN FD at 5 Mbps causes the bus to enter the BUS-OFF state.

​Our custom mainboard shows the same behavior as the NV development board.​​

• This confirms that the backend hardware connection (including wiring and transceivers) is not the root cause, since 3 Mbps communication works fine.

• Moreover, the TX-side waveform remains abnormal even when the backend hardware is disconnected.

[KevinFFF]

@KD7

​Additional observation on the NV THOR platform development board:​

Could you try to apply the following 2 patches and verify on the devkit again?

1. prod-settings in device tree (nv-soc/tegra264-soc-prod.dtsi)

diff --git a/nv-soc/tegra264-soc-prod.dtsi b/nv-soc/tegra264-soc-prod.dtsi
index b4f5701..ad59242 100644
--- a/nv-soc/tegra264-soc-prod.dtsi
+++ b/nv-soc/tegra264-soc-prod.dtsi
@@ -671,7 +671,89 @@
 			};
 		};
 
-	
+		mttcan@81102f0000 {
+			prod-settings {
+				#prod-cells = <4>;
+				prod_c_can_2m_1m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00000000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000000>;            //M_TTCAN_CORE_TDCR_0
+				};
+				prod_c_can_5m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00800000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000600>;            //M_TTCAN_CORE_TDCR_0
+				};
+				prod_c_can_8m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00800000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000400>;            //M_TTCAN_CORE_TDCR_0
+				};
+			};
+		};
+
+		mttcan@8110300000 {
+			prod-settings {
+				#prod-cells = <4>;
+				prod_c_can_2m_1m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00000000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000000>;            //M_TTCAN_CORE_TDCR_0
+				};
+				prod_c_can_5m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00800000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000600>;            //M_TTCAN_CORE_TDCR_0
+				};
+				prod_c_can_8m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00800000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000400>;            //M_TTCAN_CORE_TDCR_0
+				};
+			};
+		};
+
+		mttcan@8110330000 {
+			prod-settings {
+				#prod-cells = <4>;
+				prod_c_can_2m_1m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00000000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000000>;            //M_TTCAN_CORE_TDCR_0
+				};
+				prod_c_can_5m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00800000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000600>;            //M_TTCAN_CORE_TDCR_0
+				};
+				prod_c_can_8m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00800000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000400>;            //M_TTCAN_CORE_TDCR_0
+				};
+			};
+		};
+
+		mttcan@8110340000 {
+			prod-settings {
+				#prod-cells = <4>;
+				prod_c_can_2m_1m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00000000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000000>;            //M_TTCAN_CORE_TDCR_0
+				};
+				prod_c_can_5m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00800000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000600>;            //M_TTCAN_CORE_TDCR_0
+				};
+				prod_c_can_8m {
+					prod = <
+						0 0x0000000c 0x00800000 0x00800000              //M_TTCAN_CORE_DBTP_0
+						0 0x00000048 0x00007f00 0x00000400>;            //M_TTCAN_CORE_TDCR_0
+				};
+			};
+		};
 
 		qspi@db50000 {
 			prod-settings {

2. mttcan driver

diff --git a/drivers/net/can/mttcan/hal/m_ttcan.c b/drivers/net/can/mttcan/hal/m_ttcan.c
index 0b4f01bd..cd8dce7b 100644
--- a/drivers/net/can/mttcan/hal/m_ttcan.c
+++ b/drivers/net/can/mttcan/hal/m_ttcan.c
@@ -10,7 +10,8 @@
 #define MTTCAN_INIT_TIMEOUT 1000
 
 #define MTTCAN_SPEED_5MBPS  5000000
-#define MTTCAN_SPEED_8MBPS  8333333
+#define MTTCAN_SPEED_8MBPS_40MHZ  8000000  /* Exact 8 Mbps for 40MHz clock */
+#define MTTCAN_SPEED_8MBPS_50MHZ  8333333  /* Closest to 8 Mbps for 50MHz clock */
 
 void ttcan_print_version(struct ttcan_controller *ttcan)
 {
@@ -302,7 +303,8 @@ static void tegra_mttcan_config_prod_settings(struct mttcan_priv *priv)
 	case MTTCAN_SPEED_5MBPS:
 		prod_name = "prod_c_can_5m";
 		break;
-	case MTTCAN_SPEED_8MBPS:
+	case MTTCAN_SPEED_8MBPS_40MHZ:
+	case MTTCAN_SPEED_8MBPS_50MHZ:
 		prod_name = "prod_c_can_8m";
 		break;
 	default:

If above patches can work with 8M CAN-FD on the devkit, please also verify on your custom carrier board.

[KD7]

Thank you. After applying these two patches, the CAN interface configured at 8Mbps can now successfully transmit 64 bytes of data. The issue has been resolved.