Go Down

Topic: Can not receive CAN DATA from Arduino UNO with MCP2515 Module. (Read 42085 times) previous topic - next topic

coryjfowler

Yes, I would say that voltage definitely needs fixed.  It should be much closer to 5.0 than that.
"Taking the time to make a proper, punctuated, post is a mark of courtesy and respect."  http://forum.arduino.cc/index.php?topic=149022.0

reynard80

The (first) module I used may actually be faulty. I have acquired a second module, which gives normal values on the VCC voltages and I actually am receiving messages now!

However, with your code, I'm receiving messages, but the sending of the message keeps failing, like below. The CAN_receive example gives me just the Standard ID messages, so that seems to work now.

Code: [Select]
Entering Configuration Mode Successful!
Setting Baudrate Successful!
MCP2515 Initialized Successfully!
Starting to Set Mask!
Setting Mask Successful!
Starting to Set Filter!
Setting Filter Successfull!
Starting to Set Filter!
Setting Filter Successfull!
Starting to Set Mask!
Setting Mask Successful!
Starting to Set Filter!
Setting Filter Successfull!
Starting to Set Filter!
Setting Filter Successfull!
Starting to Set Filter!
Setting Filter Successfull!
Starting to Set Filter!
Setting Filter Successfull!
Simple CAN OBD-II PID Request
Standard ID: 0x2F5       DLC: 3  Data: 0x5E 0x00 0x80
Error Sending Message...
Standard ID: 0x2F5       DLC: 3  Data: 0x4F 0x00 0x80
Error Sending Message...
Standard ID: 0x488       DLC: 8  Data: 0x3D 0x00 0x70 0x00 0x1E 0x3C 0xFF 0x3D
Error Sending Message...
Standard ID: 0x612       DLC: 5  Data: 0x73 0x20 0x01 0x36 0x00
Error Sending Message...
Standard ID: 0x38D       DLC: 7  Data: 0x00 0x00 0x00 0x00 0xAF 0xD1 0x00
Error Sending Message...
Standard ID: 0x432       DLC: 6  Data: 0x81 0x59 0x48 0xFE 0x00 0x00
Error Sending Message...
Error Sending Message...
Standard ID: 0x348       DLC: 8  Data: 0x00 0x4F 0x2D 0x44 0xC0 0x01 0x00 0x40
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Standard ID: 0x412       DLC: 8  Data: 0x18 0x00 0x00 0x00 0x00 0x3C 0x0A 0x00
Error Sending Message...
Standard ID: 0x072       DLC: 5  Data: 0x02 0x00 0x00 0x00 0x00
Error Sending Message...
Standard ID: 0x208       DLC: 8  Data: 0x00 0x00 0x21 0x00 0x0C 0xFF 0xFF 0x4F
Error Sending Message...
Standard ID: 0x2F5       DLC: 3  Data: 0xC7 0x00 0x80
Error Sending Message...
Standard ID: 0x348       DLC: 8  Data: 0x00 0x4F 0x2D 0x44 0xC0 0x01 0x00 0x40
Error Sending Message...
Standard ID: 0x2F5       DLC: 3  Data: 0x4F 0x00 0x80
Error Sending Message...
Standard ID: 0x208       DLC: 8  Data: 0x00 0x00 0x21 0x00 0x0C 0xFF 0xFF 0x4F
Error Sending Message...
Standard ID: 0x2F5       DLC: 3  Data: 0x03 0x00 0x80
Error Sending Message...
Standard ID: 0x2F5       DLC: 3  Data: 0x7C 0x00 0x80
Error Sending Message...
Standard ID: 0x2F5       DLC: 3  Data: 0x6D 0x00 0x80
Error Sending Message...
Standard ID: 0x348       DLC: 8  Data: 0x00 0x4F 0x2D 0x44 0xC0 0x01 0x00 0x40
Error Sending Message...
Standard ID: 0x30D       DLC: 8  Data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Error Sending Message...
Error Sending Message...
Standard ID: 0x30D       DLC: 8  Data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Error Sending Message...
Standard ID: 0x30D       DLC: 8  Data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Error Sending Message...
Standard ID: 0x348       DLC: 8  Data: 0x00 0x4F 0x2D 0x44 0xC0 0x01 0x00 0x40
Error Sending Message...
Standard ID: 0x2F5       DLC: 3  Data: 0xC7 0x00 0x80
Error Sending Message...
Standard ID: 0x38D       DLC: 7  Data: 0x00 0x00 0x00 0x00 0xAF 0x1D 0x00
Error Sending Message...
Standard ID: 0x592       DLC: 3  Data: 0x00 0x00 0x00
Error Sending Message...
Standard ID: 0x2F5       DLC: 3  Data: 0x4F 0x00 0x80
Error Sending Message...
Error Sending Message...

coryjfowler

Does it send okay in loopback mode?  I'd fault the module again if so, since it sounds like the TX CAN connection between the protocol controller and the transceiver might be open or shorted to something.

Glad to see that you're seeing messages from your vehicle though.
"Taking the time to make a proper, punctuated, post is a mark of courtesy and respect."  http://forum.arduino.cc/index.php?topic=149022.0

reynard80

I have been working on it a bit more, but I am getting such strange results.

Does it send okay in loopback mode?  I'd fault the module again if so, since it sounds like the TX CAN connection between the protocol controller and the transceiver might be open or shorted to something.

Glad to see that you're seeing messages from your vehicle though.
Sending of the message in loopback mode does actually work. But it is also working when I just connect two modules with terminators. A 'local' CAN bus with two modules and two arduinos does seem to work just fine. I can send and receive messages on both modules. The voltages on the modules also seem in order.

Radio and steering wheel controls
As mentioned above, I finally got messages on the ODB2 port. However, they don't contain the data I'm looking for, namely the steering wheel controls for the radio (as my project is trying to use the steering wheel buttons to control some media players in the car).

To my understanding, the steering wheel controls work via CAN bus. This can also be seen when looking for commercially available adapters and in this specification of peugeot CAN bus messages.

So I tried connecting a module to the CAN bus wires of the radio (per this schematic, for example). But this gave some strange results;
  • First, I measured the voltages of these wires, and they are actually the other way around from the schematics. Connecting by the schematics resulted in random dashboard errors. Connecting the other way around gave no errors, but also not one message. I tried different baud rates, 125k, 250k and 500k
  • The voltage difference in the radio CAN bus wires is much higher than on the ODB2 port. On the radio I'm measuring 4.58V vs 0.34V. On the ODB2 port I'm measuring 3.13V vs 2.36V. So apparently this is not the same CAN bus.

I'm actually quite lost now on what is happening here, and how to proceed :smiley-confuse:



PS. Sorry to the original poster for 'hijacking' your topic a bit  :smiley-roll-sweat:



coryjfowler

So I tried connecting a module to the CAN bus wires of the radio (per this schematic, for example). But this gave some strange results;
Did those wires appear to be twisted together by chance?  That's usually a good indicator of some type of digital bus.  Also, its not unheard of for extra CAN buses to be populated on the OBD-II manufacture's discretion pins.  My old Escape had two and my new Jeep has three on the port.  (I found them via trial and error.)

At this point, I'd say you'd need an oscilloscope to see what is actually going on between your car and the CAN module.  Something just isn't right and its interesting that they work fine together, but not with your car.
"Taking the time to make a proper, punctuated, post is a mark of courtesy and respect."  http://forum.arduino.cc/index.php?topic=149022.0

reynard80

#20
Apr 12, 2017, 12:06 pm Last Edit: Apr 12, 2017, 10:25 pm by reynard80 Reason: Found out about the different workings of low speed CAN bus
I have managed to get hold of the electrical schemas of the car and this explains a lot. There are indeed multiple CAN buses in the car. The radio is on a seperate comfort CAN bus, which runs on 125kbps. So that explains quite a bit.

I've also read a bit more into CAN bus specifications and this clears things up quite a bit. The radio CAN bus signals actually are typical for a Low speed or Fault tolerant CAN bus. High speed transceivers are not compatible with such a bus, so I'll have to find a suitable fault tolerant CAN bus transceiver. Maybe build my own PCB.

Quote from: Wikipedia
Low speed/Fault tolerant CAN signaling drives the CAN high wire towards 5V and the CAN low wire towards 0V when transmitting a dominant (0), and does not drive either wire when transmitting a recessive (1). The dominant differential voltage must be greater than 2.3V (with a 5V Vcc) and the recessive differential voltage must be less than 0.6V The termination resistors passively return the CAN low wire to RTH where RTH is a minimum of 4.7V (Vcc-0.3V where Vcc is 5V nominal) and the CAN high wire to RTL where RTL is a maximum of 0.3V. Both wires must be able to handle -27 to 40V without damage.

High speed transceivers are not compatible with such a bus, so I'll have to find a suitable fault tolerant CAN bus transceiver. Maybe build my own PCB. My question now is, will the MCP2515 controller and library work with such a transceiver?

My question now is, will the MCP2515 controller and library work with such a transceiver?

coryjfowler

My question now is, will the MCP2515 controller and library work with such a transceiver?
The transceiver and physical bus are independent of the protocol controller and the library wouldn't even notice the difference.

From a quick look, it appears that all low-speed transceivers are larger than a SOIC8 package due to the extra pins required for the termination resistors among other features, so a board would need to be made for this.  Looking at how each device is terminated, it seems to me that a good confirmation of your thought about the bus being low-speed fault-tolerant would be to disconnect the battery and measure the resistance between the CAN High and CAN Low of that bus to see if it reads around 60 ohms or not.  From what I'm seeing, I would expect a higher resistance or an open to be read when they are unpowered, but I could be wrong as I've not messed with this physical specification yet.  Its also worthy to note that a low-speed fault-tolerant bus is designed for a specific number of nodes in mind since each device has a termination resistance.  Hopefully the vendor thought about future proofing and the total line resistance is greater than 100 ohms allowing for an additional device or so.

Now I'm suddenly skeptical about my Jeep's 125k bus even though the high speed transceivers in the CAN adapter I was using was reading the data fine.
"Taking the time to make a proper, punctuated, post is a mark of courtesy and respect."  http://forum.arduino.cc/index.php?topic=149022.0

reynard80

#22
Apr 18, 2017, 10:29 pm Last Edit: Apr 22, 2017, 02:08 pm by reynard80 Reason: Managed to get it working
The transceiver and physical bus are independent of the protocol controller and the library wouldn't even notice the difference.
I thought and hoped so already. so that's good to hear..

From a quick look, it appears that all low-speed transceivers are larger than a SOIC8 package due to the extra pins required for the termination resistors among other features, so a board would need to be made for this.  Looking at how each device is terminated, it seems to me that a good confirmation of your thought about the bus being low-speed fault-tolerant would be to disconnect the battery and measure the resistance between the CAN High and CAN Low of that bus to see if it reads around 60 ohms or not.  From what I'm seeing, I would expect a higher resistance or an open to be read when they are unpowered, but I could be wrong as I've not messed with this physical specification yet.  Its also worthy to note that a low-speed fault-tolerant bus is designed for a specific number of nodes in mind since each device has a termination resistance.  Hopefully the vendor thought about future proofing and the total line resistance is greater than 100 ohms allowing for an additional device or so.

Now I'm suddenly skeptical about my Jeep's 125k bus even though the high speed transceivers in the CAN adapter I was using was reading the data fine.

I want to make my own board indeed, soldering a PCB is not a real problem. I have looked in to some circuit diagrams and it seems pretty easy to do.

The termination is good point though, I also read about this. I think the manufacturer thought about at least one more device, as there is a connection to a CD changer available on the radio with CANL and CANH. Also, there is an option for a handsfree set, which I don't have. I'm thinking of using the CD changer connection (this way I'll also have a neat solution for connecting my device).

Determining the value of the termination resistors is one thing I'll have to solve indeed. But I'm not sure how to do this exactly. I have included a (crude, sorry for that) diagram of the ECU's, as found in the official technical documentation of the car. So it seems I have six nodes on this bus, but I am not sure how to find the value for the termination resistors for my project. I'm not sure how to measure the termination resistance of each node, as measuring over CANH and CANL is not correct in this case I think. CANH and CANL don't seem to be connected by the termination resistance.



Update for future searchers:

I managed to receive messages on the comfort/fault tolerant/low speed CAN bus of my Peugeot 207, via the RD4 radio. I finally got it working with the circuit as described in this paper. Comparable designs and more information can also be found on a few German and Russian forums. Google Translate is my friend  :)

I still have to develop a refined 'production' board, as I now only have a breadboard prototype. Also, I haven't tested sending messages yet.

reynard80

While I have a working board now, I'm still running into some trouble. I'm receiving messages, but after a short while, this stops. It seems the MCP2515 does not give an interupt anymore, as there is some error situation.

The error does not seem to be with the transceiver, as it does not signal an error on its error-pin.

Is it possible to see the errors the MCP2515 encounters, with the library? When I read the datasheet, it seems that error flags can be read from the chip register? How can this be done?

coryjfowler

Is it possible to see the errors the MCP2515 encounters, with the library? When I read the datasheet, it seems that error flags can be read from the chip register? How can this be done?
Add the below to your main loop someplace.  When an error occurs, it will flood your terminal window.
With this piece of code in the main loop of my J1939 test application connected to my bench bus that has an ECM on it, I eventually get a receive buffer 0 overflow error which I expect to get on occasion since the ECM transmits cyclic messages at some high rates.

Code: [Select]
if(CAN0.checkError() == CAN_CTRLERROR){
    Serial.print("Error register value: ");
    byte tempErr = CAN0.getError() & MCP_EFLG_ERRORMASK; // We are only interested in errors, not warnings.
    Serial.println(tempErr, BIN);
   
    Serial.print("Transmit error counter register value: ");
    tempErr = CAN0.errorCountTX();
    Serial.println(tempErr, DEC);
   
    Serial.print("Receive error counter register value: ");
    tempErr = CAN0.errorCountRX();
    Serial.println(tempErr, DEC);
   
    //I do not have a function that clears errors and that has been added to my todo list. 04/26/17 CJF
  }
"Taking the time to make a proper, punctuated, post is a mark of courtesy and respect."  http://forum.arduino.cc/index.php?topic=149022.0

reynard80

Add the below to your main loop someplace.  When an error occurs, it will flood your terminal window.
With this piece of code in the main loop of my J1939 test application connected to my bench bus that has an ECM on it, I eventually get a receive buffer 0 overflow error which I expect to get on occasion since the ECM transmits cyclic messages at some high rates.
...
Thanks, is there an overview of the error codes somewhere? I can't find it in the datasheet, or am I overlooking it? I am receiving errors like this, where the counter is counting down:

Code: [Select]

Error register value: 1000000
Transmit error counter register value: 0
Receive error counter register value: 65

coryjfowler

The error bits are read from the EFLG (ERROR FLAG) register of the MCP2515.  Looks like the 6th bit is set which the datasheet says is RX0 overflow which is expected on a busy CAN bus.  What concerns me is the 65 receive errors...
"Taking the time to make a proper, punctuated, post is a mark of courtesy and respect."  http://forum.arduino.cc/index.php?topic=149022.0

reynard80

The error bits are read from the EFLG (ERROR FLAG) register of the MCP2515.  Looks like the 6th bit is set which the datasheet says is RX0 overflow which is expected on a busy CAN bus.  What concerns me is the 65 receive errors...
This may be a rather stupid question, but how do you see the 6th bit is set? Because there are 6 zeroes?
I think it is a busy CAN bus indeed, but does this mean the controller just hasn't got enough capacity to handle this busy bus? Or can something be done about it? Will setting a mask/filter help keeping the RX buffer from overflowing?

coryjfowler

I have the serial output formatted to binary in the error code snippet, just need to see a 1 and its zero-based position.

As for overflow, its not typically an issue unless RX1 also overflowed since I have the BUKT bit set by default.  BUKT being set moves the packet from RX0 to RX1 when a received message is destined for RX0. Filtering for only the CAN IDs you are interested in would definitely alleviate any overflows.  Anything to increase the microcontroller's ability to read from the CAN controller would also help, like increasing the SPI clock speed, removing/fixing blocking functions, limiting unnecessary serial writes and/or increasing the serial speed, etc.

As for the SPI clock speed, Arduino added some new SPI features that I've not had time to incorporate into the library and test out which has been on the todo list.  Something like SPISettings(10000000, MSBFIRST, SPI_MODE0) added below the CAN0.begin(...) function would help maximize the SPI clock.
"Taking the time to make a proper, punctuated, post is a mark of courtesy and respect."  http://forum.arduino.cc/index.php?topic=149022.0

muekno

have similar problems than above. I use the sketch from post #11. I use the Nirem CAN interface. If I set it to 500 kbs and 8 MHz and LOOPBACK Mode I get initialized OK, and send message OK, but do not receive anything. If I set it to 125 kbs I get an iitialization error.
As some wrote low baudrates are not working fine with 8 MHz cristal. I bulld up a circuit with original MCP2515 DILand 16 Mhz cristal. Here I get and send message error with the same sketch. I think it is clear that I changed the initializtions string acording the cristal. Adrduino board isoriginal Arduino UNO with the SMD Arduino.
connections are CS=10, SO =12, SI=11,SCK=13,INT=2
Thanks for any help or hint

Go Up