Electronic – CAN data transmission

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.

Since this method brings the bus near 100% utilization, we'll assume that these 3 nodes are the only ones on the bus. Based on your delay time of 10µs, we also assume that the bus speed is 500kbps (i.e. 5 bits of delay, or 1 bit short of the post-arbitration wait between messages).

Whether the method will work or not depends largely on the implementation details of your CAN driver. A more reliable way to accomplish this would be to have node B and C waiting to read each other's message before sending (with node B initially transmitting without waiting). I.E.:

1. Wakeup
2. Node C waits on message B
3. Node B transmits
4. Node B waits on message C
5. Node C transmits
6. Node C waits on message B
7. Etc.

To account for desynchronization, each waiting period should have a timeout, after which the node transmits regardless of whether it's received the other node's message.

This will even out the bus utilization and leave each controller able to accomplish other tasks while waiting for the message (instead of continually trying to transmit in the event of an arbitration loss).

Note that this is an unconventional use of CAN. You may be better served with a simpler protocol, such as SPI (node A would have to poll B and C, but there would need to be no arbitration, and everything could be DMA and/or interrupt-driven).