search

collin80 / due_can

Object oriented canbus library for Arduino Due compatible boards
GNU Lesser General Public License v2.1
251 stars 95 forks source link

CAN received with wrong ID #62

Open jonbhanson opened 2 months ago

jonbhanson commented 2 months ago

Thank you for this package. I really appreciate it!

I am transmitting a message on the CAN bus with the ID 0xFF0400. I have a CAN monitor on the line and it confirms that the message is sent out with that ID, and the extended ID flag set to true.

However, when I receive the frame from due_can, the frame->id is 0xFC0000. That is to say, I don't receive the 0xFF0400 frame, but I do receive a 0xFC0000 which I am not sending and is not seen on the CAN bus monitor.

Any ideas why my CAN bus ID is changing?

jeroenveer commented 2 months ago

I have the same issue.

Message 0x17F0000F is received as 0x17F00000

jonbhanson commented 1 month ago

I have the same issue.

Message 0x17F0000F is received as 0x17F0000

@jeroenveer that's good to know. To confirm, your address doesn't become 0x17F00000 (with the least significant byte being zeroed out), but becomes 0x17F0000_ (with the least significant byte being completely removed)?

jeroenveer commented 1 month ago

Sorry it is receiving 0x17F00000

collin80 commented 1 month ago

Well, I'm not sure why that is happening. I hooked up an EVTV CANDue board (one CAN bus) to an EVTV ESP32 CAN board (2 CAN buses, one native to ESP32 chip, second from an MCP2517FD module).

Here is the output of GVRET on the SAM3X based board:

218853899 - FF0400 X 0 4 1 14 28 40 273981673 - FF0400 X 0 4 1 14 28 40 Sending frame with id: 0xFF0400 len: 4 330473349 - 17F0000F X 0 4 1 14 28 40 Sending frame with id: 0x17F0000F len: 6

The timestamped lines are receive, the other two are transmission (as I tried each of your IDs both directions just to be sure).

Here is the output of ESP32RET on the ESP32 board:

Sending frame with id: 0xFF0400 len: 4 Sending frame with id: 0xFF0400 len: 4 152736451 - ff0400 X 0 4 1 14 28 40 Sending frame with id: 0x17F0000F len: 4 235436510 - 17f0000f X 0 6 1 14 28 40 aa c

You'll note that it's the exact inverse of the sending pattern from the SAM3X side. Also, I find that the IDs reported are exactly the ones being sent. So, unfortunately this gives me no clues why it is corrupting the ID for both of you.

One might argue that I'm using two boards I made with libraries I made and programs I made so I'm kind of eating my own dogfood here and not testing with anything I didn't make. So, maybe my stuff just all happens to happily coexist and work. I tried to find cables to connect a Kvaser or PeakCAN adapter but while I could find the adapters, I couldn't quickly find cables to connect either of them to the SAM3X board. Still, I doubt it would make a difference. But, in the off chance it does, what are the two of you using on the other side of the connection to send these frames?

jonbhanson commented 1 month ago

@collin80 thanks so much for your testing efforts on our behalf! In my case, I am using a Danfoss PLUS+1 MC050 controller to transmit the frames.

jeroenveer commented 1 month ago

In my case the car is sending 0x17F0000F which i see with my Vehicle Spy tool. The DUE does not receive it on Can0 as 0x17F0000F but as 0x17F00000 transmit with the DUE of 0x17F0000F is working good