TCAN4550-Q1: TCAN throughput

Hello Tanushree,

I'm not a Linux expert and my expertise is with the TCAN4550-Q1 device itself, but these appear to be associated with CRC errors in the CAN messages.  If so, this implies the receiving nodes are sampling bits incorrectly resulting in an incorrect CRC calculation that is performed on each CAN message by the device.  These errors can come from the bit timing and sample point configuration, or from noise coupling into the line resulting a signal integrity type of failure, or from some sort of clock tolerance or stability issue.  

Logs of the device level register information of the interrupts, error counters, and protocol status registers would be needed to determine the cause.

Regards,

Jonathan 

Hello Jonathan,

Thank you for the reply.

After running for several days, the device sometimes stops receiving CAN messages.

• On the device side, we checked errors such as CRC, FIFO errors, RX packets, and RX dropped, but no errors were observed.

• CPU load is also low.

• When the issue occurs, if we bring the interface down and up again, we see the following register values:

root@imx8dxl-iwg41:~#
root@imx8dxl-iwg41:~# ip link set can3 up type can bitrate 500000
[53004.353653] M_CAN_ECR
[53004.355951] 0000 0000 0000 0000 0000 0000 0000 0000
[53004.362443] tcan4x5x spi2.0 can3: Failed to init module
[53004.383894] M_CAN_ECR
[53004.386518] 0000 0000 0001 1100 1111 1111 0000 0000
[53004.400535] IPv6: ADDRCONF(NETDEV_CHANGE): can3: link becomes ready
[53004.413891] M_CAN_ECR
[53004.416449] 0000 0000 0000 0000 1111 1111 0000 0000

And below is the dts configuration.

&lpspi3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lpspi3>;
fsl,spi-num-chipselects = <1>;
assigned-clock-rates = <80000000>;
cs-gpios = <&lsio_gpio0 16 GPIO_ACTIVE_HIGH>;
status = "okay";

tcan4x5x1: tcan4x5x@0 {
compatible = "ti,tcan4x5x";
reg = <0>;
pinctrl-names = "default";
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <16000000>;
bosch,mram-cfg = <0x0 3 2 32 10 0 20 10>;
clocks = <&hclk>, <&cclk>;
clock-names = "hclk", "cclk";
interrupt-parent = <&lsio_gpio3>;
interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
data-ready-gpios = <&lsio_gpio3 18 GPIO_ACTIVE_HIGH>;
reset-gpios = <&exp2 11 GPIO_ACTIVE_HIGH>;
iw-tcan-prop;
wakeup-source;
status = "okay";

};
};

&lpspi2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lpspi2>;
fsl,spi-num-chipselects = <1>;
assigned-clock-rates = <80000000>;
cs-gpios = <&lsio_gpio4 22 GPIO_ACTIVE_HIGH>;
status = "okay";

tcan4x5x0: tcan4x5x@0 {
compatible = "ti,tcan4x5x";
reg = <0>;
pinctrl-names = "default";
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <16000000>;
bosch,mram-cfg = <0x0 3 2 32 10 0 20 10>;
clocks = <&hclk>, <&cclk>;
clock-names = "hclk", "cclk";
interrupt-parent = <&lsio_gpio3>;
interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
data-ready-gpios = <&lsio_gpio3 12 GPIO_ACTIVE_HIGH>;
reset-gpios= <&exp2 12 GPIO_ACTIVE_HIGH>;
iw-tcan-prop;
wakeup-source;
status = "okay";

};
};

My Question:
Since this error only occurs after several days, is there any userspace command or tool that can directly access and read TCAN registers (e.g., CCCR, ECR, etc.)?

This would allow us to dump the registers manually when the issue occurs, instead of relying on continuous kernel log printing. 

Hi Tanushree,

Jonathan is currently out of office as of this time. Please help give until next week for some feedback, thanks.

Best Regards,

Michael.

Hello Tanushree,

My expertise is with the TCAN4550 device itself and not with Linux, so I'm not sure what userspace commands or tools are available.  Reading and monitoring the various registers such as you have mentioned, would be helpful in determining the cause of any errors.

In frequent errors over a long duration of time can also be from environmental conditions such as power fluctuations, or EMI noise sources from nearby equipment, etc.  Monitoring for supply and noise fluctuations, or any other correlating information such as the time of day the errors occur may also point to less obvious sources of error that re not related to the device configuration. 

My personal experience is that CRC errors usually indicate corrupted bits in the message during the data phase which is usually associated with some sort of noise or signal integrity issue.

You might also try to adjust the bit timing configuration to change the sample point % to see if sampling the bit earlier or later in the bit period improves the results.

Regards,

Jonathan