This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ISO1050 problem when not connected to CAN bus

Other Parts Discussed in Thread: ISO1050

Summary: I built a CAN-repeater module with isolation to connect two buses, labeled F and W in this application. The W side has an ISO1050 whereas the F side is connected directly to the CAN-repeater chip. With both buses connected and everything powered up, the repeater works fine. However, when I disconnect the W side CAN bus from the repeater, the F bus gets heavy errors or locks up. In this application, the secondary W bus will sometimes be disconnected and I can't clobber the F bus!

Suspected problem: Without other nodes on the bus pulling towards recessive, perhaps the ISO1050 is not returning promptly to recessive. That causes the repeater to echo effectively a bus collision onto the F side – killing the F bus.

Other details:
1) Plugging an un-powered node with terminator into the W side shows the same problem (the node must be powered up to avoid clobbering the F side)
2) Both sides have protection diodes and a common-mode choke for noise immunity.

Any suggestions ?
Thanks!
Best Regards, Dave

Schematic below (note no terminator installed on W side)

  • Sorry, your web site lost the schematic; I'll try again...

  • Hi Dave,

    Most of the "driving" force that brings the bus back to recessive from a dominant state is through the termination resistors, and not the other nodes on the bus. A typical CAN transceiver will have a differential input resistance of around 10-15kΩ, where a single termination will typically be 120Ω and two terminations will results in 60Ω.

    So the fact that under some states this node become unterminated, this could be causing slow transitions from dominant to recessive and be causing issues. Can you take some oscilloscope screen shots of the CANH, CANL, TXD and RXD signals of the ISO1050? Does the problem go away when 60Ω is applied to CANH and CANL of bus W?

    Also, I am no applications expert on the AMIS-42770, but on page 5 of the datasheet it states that "For correct operation, it is necessary to terminate the open bus by the proper termination resistor." Also why are you floating the second EN pin (/EN2), as opposed to actively holding it high? Noise can couple onto this high impedance node and cause false transitions.

    Thanks,

    John

  • Hi John - Answers a bit out of order...

    Adding termination resistor to unused bus W: no change (F bus still locks up). I tried with 120 (should have tried 60 ohm).

    Enable pin for unused bus is floated, should be OK: Page 5 datasheet "All digital input pins, including ENBx, have an internal pull−up resistor to ensure a recessive state when the input is not connected or is accidentally interrupted."

    "For correct operation, it is necessary to terminate the open bus by the proper termination resistor." - This applies to only buses connected to AMIS-42770 enabled CAN ports, right? Shouldn't apply to digital port connected to ISO1050, right?

    I can try get some scope pictures this later afternoon but I only have a 2-channel handy. Best to look at the digital side only to see if there's a change in TX>RX delay when bus dis-connected?

    Thanks for the help!
    Best Regards, Dave

  • Hi Dave,

    Adding termination resistor to unused bus W: no change (F bus still locks up). I tried with 120 (should have tried 60 ohm). Depending on the speed you are operating the bus at this may make a difference. The ACK delimeter bit inside a data frame is always a recessive level that follows a dominant level. Therefore, the bus needs to decay from a dominant level (~2.0 volts), to a recessive level (under 500mV) in less than one bit time. 1 time constant (τ) will cause the bus to decay from 2.0 volts to about 0.736 volts (not enough). So dependng on the capacitance on the bus line, and the bit rate, you could be missing the ACK delimiter.

    Enable pin for unused bus is floated, should be OK: Page 5 datasheet "All digital input pins, including ENBx, have an internal pull−up resistor to ensure a recessive state when the input is not connected or is accidentally interrupted." I agree, I was just stating that it is safer to externally tie these pins to the desired state as well. Should be fine.

    "For correct operation, it is necessary to terminate the open bus by the proper termination resistor." - This applies to only buses connected to AMIS-42770 enabled CAN ports, right? Shouldn't apply to digital port connected to ISO1050, right? I am not familiar with the device, but I thought it referred to both CAN1 and CAN2 bus lines on the AMIS-42770. You should check with On-Semi.

    I can try get some scope pictures this later afternoon but I only have a 2-channel handy. Best to look at the digital side only to see if there's a change in TX>RX delay when bus dis-connected? Look forward to see the scope shots.

    Thanks,

    John

  • Finally got back to this problem today.

    I tested termination incorrectly above. Adding a weak terminator (56k) solves the problem; I'll use 33k to give a bit of margin.

    Apparently, the ISO1050 does not promptly return to recessive without some load, which causes RX to lag TX on recessive transition, which is interpreted as bus contention...

    The weak terminator shouldn't have any noticeable effect on the CAN bus when connected (parallels 60 ohm bus impedance with 33k, reducing bus impedance negligibly to 59.9 ohms)..

    Sound OK to you?

    Thanks for the help!
    Best Regards, Dave

  • Hi Dave,

    Adding a high resistance like 33kΩ is about the equivalent of adding another node in the network (since input differential resistance, RID, is a min of 30kΩ and a maximum of 80kΩ).

    Also I have seen partial terminations used in networks with long stubs or in configurations like stars. This should not cause any problems, there is margin built into the output differential voltage of the driver.

    Thanks for following up,

    John