# Problem in CAN transmission

I am working on a sensor based project using STM32 in which I do the following things,

1. Receive data from sensor
2. Transmit that data on the CAN bus.

The sensor will send data twice every minute and there is approx 250ms delay between those two data from the sensor. When a data is received from the sensor it is transmitted as a frame on the CAN bus. I also have a MCP2515 attached to a raspberry pi which logs all the data on the CAN bus. There is no other node on the CAN bus except the STM32 CAN and MCP2515. I also checked the termination resistors and they are ok. Initially I has the following settings

  hcan.Init.TTCM = DISABLE;
hcan.Init.ABOM = DISABLE;
hcan.Init.AWUM = DISABLE;
hcan.Init.NART = ENABLE;
hcan.Init.RFLM = DISABLE;
hcan.Init.TXFP = DISABLE;


When I used the above settings, my data log showed a lot of data missed in the CAN bus. So I changed the NART to DISABLE and tried again.

   hcan.Init.TTCM = DISABLE;
hcan.Init.ABOM = DISABLE;
hcan.Init.AWUM = DISABLE;
hcan.Init.NART = DISABLE;
hcan.Init.RFLM = DISABLE;
hcan.Init.TXFP = DISABLE;


This time I received many additional data in the CAN log. Why is this NART bit causing additional data on the CAN bus. As per my project, I need an exact data count from the sensor. I am pretty sure that the sensor is transmitting the data on regular interval using a oscilloscope.

NART is apparently "no automatic retransmission". That's a non-standard setting which shouldn't be used. Commonly, CAN nodes should alway attempt to re-send a frame if they fail to do so the first time. Because one reason for failing could be that they lost in the bus arbitration procedure, yielding to another node with higher priority. That's not an error, but part of the expected CAN functionality.

This "NART" bit is apparently used in Time-Triggered CAN solutions, which is unlikely something that you will or should ever use, it's a different network topology compared to classic CAN.

In your case it would seem that you only have one node on the bus, nobody sending ACK and therefore when "NART" is set the node will continue attempting until it goes into error passive mode then bus off and shuts down.

"There is no other node on the CAN bus"

That's not a CAN bus then, it's a CAN node. Unless your listener is set to ACK frames on the bus, nothing will work. You need at least 2 working nodes, see: What are the most common causes of CAN bus communication errors? Also study CAN bus arbitration, error frames, error modes and so on.

• Thank you for your reply. – Mark Dsylva May 25 at 2:54
• Thank you for your reply. So as you say, after I disabled the NART bit, the CAN module is trying to resend the frames just because there is no nodes on the CAN bus to ACK the frame. Did I get your answer correct?. – Mark Dsylva May 25 at 3:04
• @MarkDsylva Yes. You'll also get error frames. – Lundin May 25 at 6:28
• Ok. But doesnt the MCP2515 also act as a node. It receives the data and logs it. So the MCP2515 should send an ACK to the STM32. Plz correct if I am wrong. – Mark Dsylva May 25 at 7:42
• @MarkDsylva If you have one STM32 with built-in controller and some hobbyist board with the old MCP2515 then yeah you have 2 nodes if they are configured correctly to behave as active nodes rather than passive listeners, and use the same baudrate. You can often quite easily spot the ACK bits at the end of the CAN frame, because those often have slightly different voltage levels compared to the rest of the frame since they are filled in by another controller. – Lundin May 25 at 7:49