Electronic – Does it matter which 2 nodes on a CAN bus you terminate

Background Information

I have used CAN a few times now for multiple devices distributed over a physically small area, like within a few 10s of meters. In each case, the CAN bus was internal to the system and we could specify exactly what the protocol over CAN would be. None of these systems had to, for example, interface with OBDII, NMEA2000, etc, where a specific protocol was already defined. One case was a large industrial machine that required lots of distributed sensors and actuators. The outside world interface just dealt with the overall operation of the machine. How the controller got the sensor information and caused the actuators to do stuff was a internal implementation choice that we happened to use CAN for. In another case, a company needed a good way for their customers to control multiple (up to a few dozen) of the gizmos they make within a single larger system. In this case we specified CAN as one communication means and documented the protocol. This protocol would be implemented by the controller of this system, but not surfaced to the end customer which bought this system as a whole and communicated with it thru different means at a higher level.

The EmCan solution

I have converged on a way of dealing with this over several implementations. I am now in the middle of two more such implementations, and this time I decided to use the previous experience to create a formal spec for a infrastructure layer immediately above CAN. CAN is a well designed protocol as far as it goes, and is directly implemented in a number of microcontrollers nowadays. It seems a natural way to connect multiple little devices over a limited physical distance as long as the data rate isn't too high. Basically, it can do everything you probably would have used RS-485 for 20 years ago, except that more protocol layers are specified, the specification makes sense, and hardware implementations are available built into low cost microcontrollers.

The result of this is what I call EmCan (EMbed CAN). I am slowly filling out the formal protocol specification as I migrate code from the previous implementations, generalize the concepts a bit, and make re-usable firmware modules where the EmCan protocol code can be used without change accross a variety of projects. I'm not really ready to officially publish the spec yet and provide the reference implementations, but you can look at what is there to see where things are heading. The current document is a work in progress, as it itself says.

So far I have PIC 18 and dsPIC 33 implementations of the EmCan device side, a stripped down host implementation for PIC 18, and a more full (more things handled locally) implementation for the dsPIC 33. Everything documented in the current version is implemented and seems to be working. I am working on the byte stream interface right now. I did this before in one of the previous systems, but it was more tied into the application and not a nice separable layer like EmCan.

The issue with a switched load

I think trying to switch the CAN bus with FETs or analog switches is a really bad idea. The main reason for the bit rate versus length tradeoff is not the total resistance of the cable, but the round trip propagation. Look at how CAN detects collisions, and you will see this mechanism assumes signal propagation from one end to the other within a fraction of a bit time. The CAN bus needs to be kept a transmission line. For most implementations, such as when using the common MCP2551 bus driver, the characteristic impedance should be close to 120 Ω. That means a 120 Ω resistor at each end of the bus, so any point on the bus looks like a 60 Ω load.

How EmCan fixes this

EmCan solves the node address problem without requiring special hardware. For details, see the EmCan spec, but basically, each node has a globally unique 7 byte ID. Each node periodically requests a bus address and sends this ID. The collision detection mechanism will guarantee that the bus master sees only one of these requests even if multiple nodes send a address request at the same time. The bus master sends a address assignment message that includes the 7 byte ID and the assigned address, so at most one single node is assigned a new address at a time.

If you are interested in this concept and are willing to discuss details of your system, talk to me. My biggest fear right now is specifying something that will be awkward later or prohibit certain usage that I hadn't considered. Having another implementation in progress as the spec is being finalized would be good for spec development and to test out the reference implemenation if you plan to implement it on Microchip PICs.

The issue with the AMIS42700 chip is that when trying to broadcast a message to all nodes, it seems to keep sending the same message repeatedly

This implies that the problem could as well be on the CAN controller level. There must be at least one CAN controller present who will acknowledge the reception of the message, or otherwise the controller will keep trying 128 times. Some troubleshooting to check:

• Check for error or bus off flags from the transmitting CAN controller. Ensure that no CAN controllers are set to filter out certain identifiers. Ensure that they aren't in "listen-only" mode where they won't ack received frames. Ensure that no controller is in loopback mode (only talking with itself).

• Do you get error frames on the bus or actual data? If you look for error frames with a plain oscilloscope, they look like small, single pulses. While data frames look like a train of binary ones and zeroes.

(For an error frame, it should start with 6 bits, which are either dominant or recessive depending on what error state the sending node is in: active error state=dominant bits, passive error state=recessive bits. A node is in active error state until after 128 attempts, when it reverts to passive and can no longer mess up bus arbitration. No matter if active or passive, this part of the frame violates the "bit stuffing" rule on purpose. CAN usually only tolerates up to 5 bits of equal level before using bit stuffing. So the only time when you should encounter 6 bits with same level in a row is during the error frame.)

• What does the enable signals EN1 and EN2 look like on the master? Are they stable?

• Same problem when you disconnect the second "slave" AMIS from the bus?

• I will always suspect the most classic serial bus problem: what is tx and what is rx? (As a rule of thumb/Murphy, you always get these wrong no matter what you do :) ) It would seem that the AMIS circuit will act as a data communication "modem" in this case, or if you will just as any other plain CAN tranceiver. In that case you'll have to ensure that CAN controller Tx goes to AMIS Tx. Your schematic looks correct, but I would always double-check this.

• I doubt the terminator resistors have much to do with the problem, since termination-related problems either have no notable effect on the communication (the bus may work fine without proper termination, especially on lower baudrates) or they cause the whole bus to go down, ie they work or they don't. In case they don't, no slave would be able to send anything either.

  However, in the datasheet application example of AMIS-42700 (p4), they seem to prefer 60 Ohm, which implies that each of the individual buses should have the normal 120 Ohm termination in each end. As in: add two more 120 terminators on each bus and treat them as two buses not one.

• Probably needless to say, but signal grounds need to be the same for both buses. So if they are located on physically different locations, it is not enough to just connect the Text and Rint signals, you must also connect signal grounds.

Strangely, when disconnecting one of the CAN lines (CANH or CANL) at a time, the communication could be established between nodes. In that case though I did not check CANH and CANL at the oscilloscope.

CAN is very rugged, so even when you do such evil things to it, it may still be able to "limp home" if you are lucky.