CAN received with wrong ID

[jonbhanson]

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]

I have the same issue.

Message 0x17F0000F is received as 0x17F00000

[jonbhanson]

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]

Sorry it is receiving 0x17F00000

[collin80]

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]

@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]

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

[jonbhanson]

@collin80 I think I made some progress in figuring this out. I stepped through the code and discovered that the extended CAN messages were being delivered to Mailbox 0, even though it was initialized as a standard CAN message mailbox.

The mailbox initialization occurs in can_common:
https://github.com/collin80/can_common/blob/8585f9dc807ebbeedeb509d74159f40f538d2d65/src/can_common.cpp#L333-L337

I was able to resolve my problem by switching the extended and standard boxes on initialization:

	setRXFilter(0, 0, true);
	return setRXFilter(0, 0, false);

This sets up mailbox 0 for extended can bus messages (and mailbox 1 for standard), which causes them to be parsed correctly.

I haven't dug deeply into the SAM3X datasheet to understand the finer points of the mailboxes, but this change was the fix for me and may be a good fix to add to the package.