We have tried adding the parameters you recommended, and we still have the same issue. But we have more information that may help resolve the problem.
We set up an oscilloscope on the CAN high and low lines and set it to trigger on each individual CAN frame. I will attach to this post two images: one of traffic when the Jetson is not connected (normal, no errors), and one when the Jetson is connected (periodic errors).
Without the Jetson connected, the CAN frames look fine, with one frame appearing per second containing the heartbeat message from our CANOpen devices.
With the Jetson connected, some of the traffic looks normal. But every few seconds, we see this error frame in the picture: the message looks identical, but the final bit at the end of the frame lasts much longer. I believe this is the acknowledge bit, and while it looks like the Jetson is trying to send an ACK, it doesn’t “latch” properly.
Thus, having not received an acknowledgement, our CANOpen devices repeat their message over and over again, completely tying up the bus and preventing other traffic from getting through.
We tried connecting the same exact CAN network to another Linux device (the Texas Instruments BeagleBone), and we do not see these error frame with long final bit. So we know it is the Jetson that is causing these to appear.
Hopefully this gives some insight into the problem. We greatly appreciate your support.
EDIT - Also, we see the following log messages every time the CAN errors occur:
[ 6877.813760] mttcan c320000.mttcan can1: IR 0x8400000 PSR 0x4752
[ 6877.819741] mttcan c320000.mttcan can1: entered error passive state
[ 6877.826008] mttcan c320000.mttcan can1: Format Error Detected
[ 6877.831761] mttcan c320000.mttcan can1: IR 0x8c00000 PSR 0x476a
[ 6878.804553] mttcan c320000.mttcan can1: Format Error Detected
[ 6878.810316] mttcan c320000.mttcan can1: IR 0x8400000 PSR 0x4752
[ 6878.816296] mttcan c320000.mttcan can1: entered error passive state
[ 6878.822562] mttcan c320000.mttcan can1: Format Error Detected