reading only 3 messages. Maybe rx buffers are full? can't find function to clear out rx buffers

[MatiasJHZ]

Hello,

I am using the the CAN write and CAN read examples provided with this library, using an Arduino UNO in both ends. The transmitter is continously sending a constant message, and the receiver is able to just receive 3 messages and then nothing.

Is the CAN read example code incomplete? do I need to clear the buffers to receive more messages?

The datasheet of the MCP2515 says the following:

When a message is moved into either of the receive
buffers, the appropriate RXnIF bit (CANINTF) is set.
This bit must be cleared by the MCU in order to allow a
new message to be received into the buffer. This bit
provides a positive lockout to ensure that the MCU has
finished with the message before the MCP2515
attempts to load a new message into the receive buffer.

I try to clear that bit by using the function: mcp2515.clearInterrupts();, however that doesn' work.

Here is my code inside the void loop:

`
void loop() {
if (mcp2515.readMessage(&canMsg) == MCP2515::ERROR_OK) {
Serial.print(canMsg.can_id, HEX); // print ID
Serial.print(" ");
Serial.print(canMsg.can_dlc, HEX); // print DLC
Serial.print(" ");

for (int i = 0; i<canMsg.can_dlc; i++)  {  // print the data
  Serial.print(canMsg.data[i],HEX);
  Serial.print(" ");
}

Serial.println();      

}
else if(mcp2515.readMessage(&canMsg) == MCP2515::ERROR_FAIL){
Serial.println("Error reading CAN message");
}
else if(mcp2515.readMessage(&canMsg) == MCP2515::ERROR_NOMSG){
Serial.println("NO MSG");
mcp2515.clearInterrupts();
delay(1000);
}
else{
uint8_t stat = mcp2515.getStatus();
Serial.println(stat);
delay(1000);
}
}

`

Thanks for your help,

[PhilippeArdit]

Hi MatiasJHZ,
I'm having the same problem using an isolated CAN bus (the same code with a non isolated one receives many messages... )
Have you find any solution / explanation ?

[MatiasJHZ]

Hi PhilippeArdit, No, I haven't.

Indeed I am using an isolated CAN bus in the receiver's side. It is a custom board though. It has a discrete transceiver that converts CANH and CANL to RX and TX, and these RX and TX signals go through a digital isolator and then they go to a MCP2515 CAN controller connected to an arduino.

I will check whether the RX and TX signals are arriving to the MCP2515 controller after the isolator, using an oscilloscope.

I also used this CAN library: https://github.com/sandeepmistry/arduino-CAN, and I get the same issue, with the slight difference of only getting 2 messages instead of 3.

I thought the problem was with the firmware and libraries, that maybe somehow one had to clear out the buffers manually, but now that you tell me that the problem doesn't show for non-isolated bus, it seems that it could be a hardware problem.

Are you also using a custom PCB CAN bus? how did you implement your isolated CAN bus?

[PhilippeArdit]

Hi Matias For the isolated CAN I’m using for now « ISOW1044 Isolated CAN Transceiver with Integrated DC-DC Converter Evaluation Module » For the non isolated one, I’m using module SBC-CAN01 Asking to Claude IA, here are the next points I’ll check :  " Okay, let's break down why you might be seeing this behavior with isolated vs. non-isolated CAN setups. It's likely due to signal integrity differences between the two setups. Here's a structured approach to troubleshooting: 1. **Grounding Issues (Most Likely Culprit)** - Non-Isolated CAN: In a non-isolated setup, the Arduino, MCP2515, and BMS usually share a common ground. This provides a direct return path for the CAN signals. - Isolated CAN: The isolation barrier **intentionally** breaks the direct ground connection. This is where things get tricky. The isolated CAN transceiver needs a way to establish a **common-mode voltage** between the two sides of the isolation barrier. If this common-mode voltage isn't properly established or maintained, the transceiver might not be able to reliably detect the CAN signals. **Testing Grounding:** - **Check for ground loops:**  Even with isolation, it's possible to inadvertently create ground loops through other connections (e.g., power supplies).  Make sure the only ground connection between the Arduino side and the BMS side is through the CAN transceiver. - **Verify Common-Mode Voltage:**  Use an oscilloscope to measure the common-mode voltage (the average voltage of CAN_H and CAN_L) on both sides of the isolation barrier. It should be within the specifications of the isolated CAN transceiver.  If there's a large difference or excessive noise, that's a problem. 2. **Termination Resistors** **Importance:** CAN bus requires proper termination resistors (typically 120 ohms) at **both ends** of the bus to prevent signal reflections. Reflections can distort the signal and cause errors. **Checking:** Verify that you have 120-ohm termination resistors at the BMS end **and** at the Arduino/MCP2515 end of the CAN bus. The isolated transceiver might be more sensitive to reflections if the termination isn't perfect. **Location:** The termination resistor should be as close as possible to the CAN transceiver. 5. **Signal Integrity and Noise** **Isolation Adds Complexity:** Isolated transceivers can sometimes introduce more signal distortion or be more susceptible to noise. **Cable Length:** The total length of the CAN bus cable can affect signal integrity. Longer cables increase the chance of reflections and noise pickup. Try shortening the cable if possible. **Cable Type:** Use a twisted-pair cable specifically designed for CAN bus (e.g., shielded twisted-pair). This helps to reduce noise. **Shielding:** If you're using a shielded cable, make sure the shield is properly grounded **at only one end** to avoid ground loops. **External Noise Sources:** Look for potential sources of noise near the CAN bus cable (e.g., motors, high-frequency power supplies). Try moving the cable away from these sources.** 4. **Transceiver Compatibility and Configuration** **Transceiver Specifications:**  Double-check the specifications of your isolated CAN transceiver.  Make sure it's compatible with the CAN standard being used by the BMS (e.g., CAN 2.0A, CAN 2.0B).  Also, verify that the common-mode voltage range of the transceiver is appropriate for your application. **Logic Levels:** Verify voltage levels of the isolated CAN transceiver are compatible with the rest of your circuit 5. **Bit Timing and Baud Rate** **Synchronization:** CAN nodes need to be synchronized to the same baud rate to communicate. **Library Configuration:** Double-check the baud rate setting in your `autowp/arduino-mcp2515` library. Make sure it matches the baud rate used by the BMS. Even a slight mismatch can lead to communication errors. **Clock Accuracy:** The MCP2515 relies on a crystal oscillator for timing. Verify that the crystal is operating at the correct frequency and that the oscillator circuit is stable. 6. **Code Considerations (Less Likely, but Possible)** **Interrupt Handling:** If you're using interrupts to handle CAN message reception, make sure the interrupt handler is fast and efficient. Long interrupt routines can interfere with CAN communication. **Buffer Overflow:** Check for potential buffer overflow issues in your code. If the Arduino can't process the CAN messages quickly enough, messages might be lost. Increase the buffer size or optimize your code. **Filtering:** In your code you might be enabling filtering that only allows a few messages to pass** **Troubleshooting Steps** 1.  **Start Simple:** Disconnect everything from the CAN bus except for the Arduino/MCP2515 and the BMS. 2. **Check Voltages:** Use a multimeter to verify that all power supply voltages are correct and stable. 3. **Oscilloscope is Key:** Use an oscilloscope to examine the CAN_H and CAN_L signals at both the Arduino/MCP2515 and the BMS. Look for signal distortion, noise, and reflections. Pay close attention to the common-mode voltage. 4. **Gradually Add Complexity:** If you can get communication working with just the Arduino and BMS, gradually add other devices or components to the CAN bus, one at a time, to see if any of them are causing problems "

[MatiasJHZ]

Hello, have you tried this? https://electronics.stackexchange.com/questions/461349/rx-buffer-overflow-in-mcp2515-can-controller?newreg=98b9547ec6bc455b916f9404d7284bf3

I don't know how to do it with SPI RTS command using this current library, maybe we have to override some functions or create our own functions?

I don't think it is a problem of hardware, since we are able to receive the first messages and they are correct. I also measured with my oscilloscope and the common mode voltages are correct.

[MatiasJHZ]

Hello,

I was able to fix my problem. It was a hardware problem of my custom board. In my custom board I have some voltage translators and they were disabled. I disabled them because I had a conflicting issue with the MOSI signal of the SPI bus when the translators were activated. The problem was that the CAN RX and TX signals also passed through their respective translators which were also subjected to this enable signal. I enabled the translators in my code only once to communicate with another device in the SPI bus before even reading on the CAN bus, that's why it only read the CAN message one time or few times.

Now it is working and the library is ok.

[PhilippeArdit]

I also managed to solve my problem. It was software/speed related: the device I'm communicating with (BMS) sends a series of CAN messages on request. One message is sent every 10 ms. So I had to:

• use interrupts
• buffer the received messages without doing anything else, otherwise I'd simply lose the sent messages (no printing, no complex manipulations that could take time)
• call the "clearInterrupts()" method after each message reading
• apply a modification to the library by using PR Fix messages are not read in correct order #46 opened on September 12, 2020 by jxltom: "Fix messages are not read in correct order"

My final code:
...
const uint8_t canCsPinBms = ...;
const uint8_t canIntPinBms = ...; // an interrupt pin
MCP2515 mcp2515Bms(canCsPinBms);
struct can_frame canMsg;
...
void setup() {
...
pinMode(canIntPinBms, INPUT);
digitalWrite(canCsPinBms, HIGH);
pinMode(canCsPinBms, OUTPUT);
attachInterrupt(digitalPinToInterrupt(canIntPinBms), readCanMsg, FALLING);
...
}

void readCanMsg()
{
while (((errVal = mcp2515Bms.readMessage(&canMsg)) == MCP2515::ERROR_OK))
{
// interpret or store data in canMsg
mcp2515.clearInterrupts();
}
}

void loop()
{
...
// Send a CAN msg to ask for information every 5 seconds...
...
}