CAN bus confusion - bus disconnected bad behavior...

It is normal that when a CAN node doesn't receive any acknowledgment for a packet it has sent, it will keep trying to send it forever, hence clogging the bus.

--
Fletto i muscoli e sono nel vuoto.

Good point. The Bosch CAN IP differentiates between a "Not Acknowledged" error and a collision, but it looks like the PCAN unit (or at least its PC SW) does not differentiate, and reports "BusHeavy" in case of *any* error.

I thought I had a common problem with PCAN and the isolator, but that looks wrong. Lets ignore the PCAN behavior and concentrate on the main problem...

The isolator box uses a TI ISO1050 to interface to the secondary bus. With secondary bus hooked up, everything works great. Even when the secondary bus is disconnected, all CAN messages on the primary bus are ACK'd by other nodes on the primary. Yet when the secondary is unplugged, the primary gets hosed.

I haven't yet tried adding additional bias/termination to the ISO1050 bus has internal biasing that looks like it should be adequate...

Any ideas? Thanks! Best Regards, Dave

I'm not sure to understand your bus topology. The ISO1050 is not a CAN hub, it is just an isolated transceiver. On one side it provides the isolated CANH and CANL signals, on the other it provides the RX and TX signals to be directly connected to the CAN controller. What do you mean with "primary bus"?

--
Fletto i muscoli e sono nel vuoto.

What difference do you mean when you say "secondary disconnected" and "secondary unplugged"? The ISO1050 is just a bus transceiver. What else is in the isolator box? Something has to be pulling the CAN messages off the primary and then sending the bit stream through the ISO1050 transceiver to the secondary. If that "something" sees a valid CAN message on the primary side it will provide the ack bit to the primary bus.

--
Chisolm 
Republic of Texas

I suspect you've missed the point. BusHeavy is indeed an accurate description of the state of the bus when there's only a single node on it, and that node tries to transmit anything. That gets you an error frame storm at close to 100% bus load.

That must be due to some unfornuate design decision regarding the relation between those two busses, or the characteristics (e.g.: baud rate, choice of can PHY layer) of the frames you trasmit to the primary bus. For all you've told us, you might be trying to hook up a low-speed-fault-tolerant 100 kBit/s node onto a 500 kBit/s high-speed-differential bus.

You won't find out what "hosed" the primary bus without putting a CAN logger onto it that can decipher error frames, baud rates, etc.

Forget about "looks like it should be". Time to replace speculation by experimentation. So: break out the 'scope and look at the actual bus signals. That'll tell you for sure whether you have adequate termination or not.

Apologies for being less than clear, and getting side-tracked by PCAN diagnostic tool behavior...

First, symptoms:

- primary bus with isolator not connected, works AOK

- isolator plugged into primary and secondary, AOK

- isolator plugged into primary but secondary disconnected, primary gets hosed

Isolator box is can repeater chip AMIS-42770 (with feedback suppression):

- one CAN port connected to primary

- one digital port (with feedback suppression) connected to TI ISO1050 (which then is connected to secondary).

Hope I explained better! Thanks in advance, Best Regards, Dave

PS: PCAN *does* report that it is unhappy because of no ACK, but it is a bit hidden (and irrelevant to the real problem above)...

Got it, just got sidetracked as the missing-ACK cause was obscured in the tool's UI...

When both buses are plugged into the isolator, CAN messages flow across the isolator and no errors are raised.

Can you recommend a tool that can do that? I'm afraid my little PCAN is not so able...

Thanks! Best Regards, Dave

Take a look at the Intronix logic analyzer. Among other capabilities, it includes a CAN interpreter so you can look at the logic levels of the traffic along with a decoded bitstream.

It's a capable and fairly inexpensive USB logic analyzer. If you're banging bits around and aren't using an LA yet, this will fill that need as well.

You can download the user interface software for a demo run without purchasing the unit.

Thanks Rich, this unit looks really good, I'll check out what signal level interfacing might be required, Best Regards, Dave

This can cause a very dangerous situation, if the node is controlling something critical.

Assuming the cable is disconnected for some reason, the controlled machine does not work anymore, someone goes to troubleshoot the machine. An other person notices that "hey, the cable is disconnected" and plugs it in, the stored message(s) in the Tx chip and transmission queue are sent and sooner or later the controlled machine starts to execute these commands, possibly causing harm to the person inspecting the machine.

If this risk exists, the transmission side should have a transmit timeout routine, which after a few seconds of failed transmission, _first_ clears the software Tx-queue and then resets the CAN controller, removing the message that is currently being actively transmitted.

Even if the controlled node should have various checks before executing commands, such as monitoring link condition e.g. by heart beat messages, there might be several heartbeat and command messages in the Tx-queue, making it look like valid link connection has been established, when messages are again flooded after bus reconnect. Thus, the controlled node should in addition to the timeout between heartbeats also contain checks against too frequent heartbeat messages (flooded from the Tx-queue).

True, but not relevant to the real problem with the isolator. Sorry again for the silly distraction with un-connected PCAN tool...

Thanks, Best Regards, Dave

Usually in critical automotive applications the receiving nodes check the time intervals between messages, and if they're outside from the expected range for too many times they switch to a recovery mode. This happens for example with messages from the ABS node to the body computer. Most car manufacturers in their "specifications for compliance" (sorry but I don't know how the italian word "capitolato" translates in english :-)) mandate the maximum number of missing messages that a compliant node can skip in a certain time. The order of magnitude is few messages per hour.

Actually the CAN bus protocol is able to handle situations like these by itself; there are RX and TX error counters and after a certain number of errors the controller switches itself to passive mode, and after another amount of errors it completely disconnects itself from the bus. The behavior I was describing is common for many devices where the higher layers (e.g. the MCU/CPU software) keep resetting the controller errors and aggressively retry to transmit forever.

--
Fletto i muscoli e sono nel vuoto.

Found it, needs a slight tug on the ISO1050 output to help it return to recessive, otherwise ISO1050 echoes apparent bus contention as RX lags TX excessively...

Works with 56k "terminator", used 33k for some margin. Has no appreciable effect on the nominal bus 60 ohm bus impedance when connected and doesn't misbehave when disconnected. Anyone see anything wrong with this?

Thanks for the suggestions (and pointing me back from silliness with PCAN tool)! Best Regards, Dave