Electronic – TXERR error in CAN communication

I've worked with the Microchip CAN controller with SPI bus interface, MCP2515. One of the most difficult parts of setting up CAN is making sure that all the baud rate registers are set properly for all of devices on the bus. I'm not sure if you have access to the registers on the sending device, but being able to read the exact baud rate register values from the sender may give you an idea as to which register you have configured incorrectly. Also knowing the type of error if any is being detected by the sender may help you solve your CAN bus problem.

Microchip has an application note, AN754, that provides a guide to setting the CAN bus timing. It's not specific to Microchip. There are a few basic timing parameters you must set properly in order for the CAN bus communication to work. They are:

• Tq = Time Quanta
• Nominal Bit Time
• Synchronization segment width
• Propagation segment width
• Phase segment 1 width
• Phase segment 2 width

Make sure these values all match in your sender and receiver.

Section 6.1 of the CAN spec:

BIT ERROR: A unit that is sending a bit on the bus also monitors the bus. A BIT ERROR has to be detected at that bit time, when the bit value that is monitored is different from the bit value that is sent. An exception is the sending of a ’recessive’ bit during the stuffed bit stream of the ARBITRATION FIELD or during the ACK SLOT.

So, the node which first transmits a '1' when the other is transmitting a '0' will note a Bit Error and then signal an error as normal - by transmitting an error-flag (see Section 3.1.3) , as described formally in Section 6.2.

Informally, if that node is error-active (which should be the usual case) it will transmit an error flag of 6 dominant bits, which all other nodes will also detect (as a stuff error). This has the effect of destroying that message completely:

• no-one will receive it
• none of the transmitters will think they have successfully transmitted anything.

Each transmitter will then attempt to retransmit - depending on the precise timing of the retransmissions, one may start sufficiently before the other the gain control of the bus. Otherwise, the same sequence may happen again. (Or another higher-priority message may put them both off for a while!)

Extended answer inspired by @clabbacchio's answer below.

You mention "nasty nodes", and clabbacchio makes the valid point that if two nodes transmit at different times, each receiver needs to decide what to do with its multiple receptions.

This was demonstrated by a hack last year. The paper discusses, in the section "PSCM specifics", how an attacker can synchronise to the regular messages on the bus and play their evil message just before the one that the "good" ECU is about to send. The receiving ECU accepts the earlier message, updates its message counter and then discards the "good" messages as erroneous, because its message counter has not incremented.