Our ADAS Controller is based on Renesas RH850/U2A16 Microcontrollers.  We are using Infineon TLE9255WSK Partial Network CAN Transceivers.  We are using Vector CANoe Professional.

When a CAN message is transmitted on CAN Channel 2 from our controller to Vector CANoe, there is Bit Stuffing Error.  Please see attached filename Bit_Stuffing_error_CAN_Trace.PNG.

Also, attached are files that show our Vector CANoe tool configuration.  

We are using 120 Ohms termination resistor.

What might be the problem?  Is the problem in Vector CANoe Tool configuration?  Or is this problem in CAN Driver source code in our controller?Bit_Stuffing_error_CAN_Trace.PNGVector_CANoe_Pro_Configuration.PNGVector_CANoe_Pro_NW_HW_Configuration.PNG

I don't think it's likely to be an error in the Vector tools.

Equally I'd be suprised if there is any software control over the bit stuffing in the Renesas Micro.

I think you should take the issue up with Renesas.

Before you do that try and pin it down to the least activity that will provoke it. It would be worth checking the hardware with a scope with CAN decoding.

MK

I emphatically agree with MichaelKellet's great answer. Definitely have a look at CANbus activity using a scope with CANbus serial decode capability. You can learn a lot from this, in particular you can spot analog signal issues in the context of a particular data frame of interest. There are scope options with CANbus decode available from companies like Rigol and Siglent, and USB scope options from companies like Pico that are very affordable.

The fact that some of your frames appear to be properly received and others produce errors hints at a potential bus signal issue. You should have two 120 ohm terminations, one at each end of the bus.

Your bit timing configuration looks very reasonable but it might be interesting to see if changes to it affect your error problem, and you might also try running at 250kbps or 100kbps and see if that gets rid of the errors.

When I encounter this kind of problem I simply make sure all participants on the bus have identical mode (classic/fd-long/fd-long-fast/iso), bitrates, tsegs, sjw and number of samples.  Scope decode (at least in my experience) has limited utility here.

Try to cancel transmissions that error - babbling idiots make it hard to debug.

-rob

Why multiple senders might cause this problem?  

Assuming senders are causing this problem, how to debug  it?

The problem occurs with Two specific CAN Ids.  One is transmitted on CAN 1 to Vector CANoe tool and the other is transmitted on CAN 2 by Vector CANoe tool.

There is typo in above comment:

The problem occurs with Two specific CAN Ids.  One is transmitted on CAN 1 to Vector CANoe tool and the other is transmitted on CAN 2 to Vector CANoe tool.

CAN is cooperative.  Receivers will cause an error if the message they receive is malformed.  I don't have enough information about your system to be much help.  Having a solid understanding of the bus and what causes errors is critical.

>>  Having a solid understanding of the bus and what causes errors is critical.

Any resources for gaining solid understanding.

Plenty of resources if you search online for CAN bus error.  I suspect your problem might be elsewhere but again I don't know what you are trying to do or your level of experience.  CAN usually 'just-works' if all participants are identically configured and the physical layer is correct.