I am currently setting up a CAN network of 16 nodes. For future extension of the network, the nodes are distributed on 4 different branches. These branches are bonded together by two CAN bus extenders (more specifically, two AMIS42700 chips) and supervised by a master CAN node (even if there is no such a thing in CAN). The AMIS42700 acts as both a CAN extender and transceiver for the master node. The schematic of the CAN bus extender part is showed below:

enter image description here

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 does not occur when transmitting messages between slave nodes (I checked this on the oscilloscope).

Where this is not a problem in itself when broadcasting messages from master to slaves, the CAN nodes receive multiple replicas of the same message, and eventually the network becomes saturated with messages from the master node. This affects the overall quality of the communication and is rather problematic in my case.

Can anybody shed some light on this peculiar behavior? Is it specific to CAN bus extenders?

For completeness, here is a list of things that I already tested:

  • Modify the value of the termination resistor on all branches (from 0 to 170 ohm)
  • Change the broadcast message. I could see the change at the oscilloscope, therefore I am assuming that this is not an error frame, but rather a replica of my message. Is it a reasonable assumption?
  • Remove the termination resistors: in this case, the CAN nodes could not communicate with each other anymore, and the behavior was similar to the one experienced with the AMIS42700 (they were trying to re-send the message, and the internal buffers could never be emptied).
  • Check the transmit buffers of the CAN controller on the master node: they are never full. It seems that the CAN controller on the master is insensitive to the value of the termination resistor.
  • 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.

All advices on the testing method and on the CAN bus extenders and CAN in general will be more than appreciated!

  • 2
    \$\begingroup\$ First you should identify if the repeat signal you are seeing is an error frame or not, you should use a CAN sniffer (or take a scope picture and decode by hand) to do so. If you are getting errors then your intended receiver is not pulling down the ak bit when expected and the transmitter is trying again. \$\endgroup\$
    – crasic
    Commented Aug 13, 2015 at 0:34
  • 1
    \$\begingroup\$ Secondly, I am more familiar with dnet and not pure CAN so excuse my ignorance, but how are you broadcasting to all receivers? CAN is also address based no? \$\endgroup\$
    – crasic
    Commented Aug 13, 2015 at 0:36
  • \$\begingroup\$ @crasic Interesting! I will decode it by hand then since I don't have a CAN sniffer for now. I apologize for the confusion: in my case, I can broadcast a message to all slave nodes by setting appropriate RX filters in each of them. \$\endgroup\$
    – Ant2N
    Commented Aug 13, 2015 at 8:27

1 Answer 1


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.

  • \$\begingroup\$ Thank you sir! I will try these out. I ruled out an improper TX/RX connection (just checked it on the PCB file and on the chips pinouts) as well as the signal grounds problem (they are on the same PCB), but this was definitely worth trying. In addition, the CAN_EN1&2 signals also look stable. There seems to be error frames on the bus (I get trains of 5 dominant and 1 recessive somewhere in the frame) but I have to admit that by looking at the Bosch specification I can't be quite sure of what I am seeing... \$\endgroup\$
    – Ant2N
    Commented Aug 14, 2015 at 7:56
  • \$\begingroup\$ Another thing comes to my mind: Could it be that the CAN controller of the master and the ones of the slave nodes are not configured at the same speed? (they should be, but who knows...) Would they still be able to communicate with each other (even poorly) if this was the case? \$\endgroup\$
    – Ant2N
    Commented Aug 14, 2015 at 8:15
  • 2
    \$\begingroup\$ @Ant2N My description of an error frame out of memory was quite an over-simplification, it turns out. I've added details of its format to the answer. Error frames are distinct from data frames, they use different formats. "5 dominant and 1 recessive somewhere in the frame" is not an error frame. For professionals, I'd strongly recommend to get a CAN listener tool, or you can't really work with CAN bus projects at all. Such tools will detect, list and log error frames, among other things. \$\endgroup\$
    – Lundin
    Commented Aug 14, 2015 at 8:32
  • 2
    \$\begingroup\$ @Ant2N If you have different baudrates, you would quite easily be able to detect that with an oscilloscope. Measure bit length from a frame sent by the master and compare it to the bit length from a frame sent by a slave. They would certainly not be able to communicate with each other if baudrates are wrong. The only thing CAN is picky about is bus timing. The usual recommendation is to not have a baudrate deviation larger than 1% of the intended baudrate. You must consider this when designing the clock for the CAN controller: pick a frequency that the controller's pre-scaler can handle. \$\endgroup\$
    – Lundin
    Commented Aug 14, 2015 at 8:34
  • \$\begingroup\$ You were completely right: not all nodes were in normal mode, and there probably was an inconsistency between the master CAN library and slave CAN library, and the nodes were not configured at the same speed. Now there is still one problem remaining: the slaves seem to receive each message twice. I will borrow a PCAN to check if the problem is on the master side or on the slave side. Thanks a lot anyway for the check list! \$\endgroup\$
    – Ant2N
    Commented Aug 18, 2015 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.