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: Error Generation during communication session

Part Number: ISO1050

Hello every one,

I'm wondering if you know a solution for this issue below,

I'm working in CAN Bus Implementation, and I've designed this bus to be isolated using ISO1050 and isolated 5V DC-DC Converter.
The issue is when I connect the bus together it works fine for all nodes and the bus is perfect, and after some time I find that one or more nodes generate errors when I try to communicate with them. Does any one faced this issue before?? 

Please note that: 
1- I'm working in 100 Kbps speed
2- I'm using 120 Ohm resistance in two points first one at the start of bus "On a board" and the other at my CAN-USB Connector. 

  • Hello,

    Thanks for posting and welcome to E2E! I'm sorry to hear you're having trouble with your isolated CAN system. I hope to help you find a resolution and get your project back on track.

    It's good to hear that the system initially appears operational. It seems that since the errors only generate after some operational time, there may be some edge cases or inconsistent behaviors that cause system upsets. I'd like to know more about the CAN bus in your implementation to try and identify the sources of these issues.

    1. How many CAN nodes are present on the Bus?
    2. How long are the cables on the bus and what is the bus topology (how are the nodes connected)?
    3. How long does the system appear to operate before errors occur? Is it on the order of seconds? minutes? hours?

    If possible, it would be very helpful to see scope-shots of the CANH and CANL lines during operation. If you're able to capture these lines during an error, that's even better. I would like to see what levels are being driven on the bus during operation and what kind of noise is present. Please includes shots that clearly indicate the dominant and recessive levels of both bus lines (high and low levels), a close-up of a dominant-to-recessive transition (CANH high-to-low, CANL low-to-high), and a shot that shows an entire CAN frame to check data-standard adherence. 

    I look forward to your response for more information. Let me know if you have any other questions in the meantime.

    Regards,
    Eric

  • Hello Eric, 

    According to your questions, 
    1- There are 7 nodes and CAN-USB Device for sniffing 
    2- The total lengthen is about 1 meter wiring with bus topology , Start (Terminated) - Node 2 - ....... - Node 7 - CAN_USB (Terminated) 
    The nodes are connected as (In-Out); I mean for each node there are two shorted connectors for CAN-In and Can-Out 
    3- it's independent of time, but it's in order of minutes from 10 to 60 mins

    I can't get a screen shot right now for the scope, but it was in standard CANH and CANL voltages (about 3.75 and 1.25 V) according to CAN GND (isolated). Should I connect the isolated GNDs, nut I fear from bad GND loops !!?

    Another important note that the errors is in type of Form errors.

  • Hi,

    Thanks for the extra information. The small number of nodes in the system along with the daisy-chained connections definitely narrows down potential issues. I'm not as happy to hear that the error can take so long to recreate - this will make debugging difficult. 

    It's good to hear that the bus voltages are within typical CAN ranges, though I would like to check the immediate values during communication with an oscilloscope. These measurements should indeed be in reference to CAN GND (GND2 on ISO1050). I would not advise connecting GND1 and GND2 to test here. 

    I see you noted previously that nodes are reporting CRC errors (subset of Form errors). This would indicate faulty data or a flipped bit somewhere. This is typically caused by one or more of the following: an invalid dominant voltage, slow dominant-to-recessive transition, or ringing from reflections on the bus. Each of these causes is identifiable by viewing CANH and CANL on a scope - then we could narrow down possible sources of these problems. 

    So far, the system you describe sounds good and I don't have initial concerns regarding node-count, bus length/topology, termination (2 X 120-Ohm), or data rate (100 kbps). With the errors being as infrequent as they are, I doubt they are due to a critical hardware design flaw. Even so, if you would be able to share a schematic, I can review it to make sure I'm not forgetting something (if the schematic is sensitive, please feel free to email me directly by clicking my E2E name). 

    Please let me know when you are able to take further measurements or can find a way to recreate the errors more consistently (does anything appear to make it worse/better?).

    Regards,
    Eric 

  • Hello Eric,

    Thanks a lot for your support. I will send shots from the scope within 4 hours from now.
    I would like to clear something, I've connected the GND2 for each node with each other. The system now works better, but the error still be generated when I increase any extra node even I connect its GND2. 

    Anyway I will send you the requested data ASAP. and thank you one more time for your support.

  • Hello Eric, 

    Actually; When I connected all GND2 together, the bus worked well. Do you have any explanation to this ??! 
    Thank you.

  • Hi,

    It's interesting to hear that connecting all GND2s seems to help the problem. Typically when using differential signal protocols such as CAN, the ground connection between nodes does not directly impact signal integrity. Some things this connection may help with is lowering ground potential differences (gpd) between nodes or decreasing common-mode noise in the system by providing more stable grounding. If the errors are a result of these types of factors, that would explain why the GND2 connections reducing the frequency of error. 

    If possible, I am still interested in viewing any available scope shots of the bus. Even if the system appears more reliable now, it's still a good idea to identify the root cause so we may eliminate it completely and make sure other design changes will not make the problem reappear. Please capture waveforms with and without the GND2 connection so we can see what difference these connections make on CANH and CANL voltages.

    Regards,
    Eric

  • Would it be possible to also provide a schematic of your system so we could check the ground connections? This could be a high level drawing or detailed schematic depending on what's available and possible to share.

    Regards,
    Eric

  • Hello,

    I wanted to check in and see if you have been able to make any progress identifying the source of the CRC errors you were encountering. Are you still experiencing the same problem in your testing? 

    Regards,
    Eric

  • Hello Eric, 

    I'm so sorry not replying for this long time. Actually My system went to QC Department for more testing and ensuring that every thing works well. I don't know if I could send you shots from oscilloscope; but if any problem appeared in the system again, I could capture shots and send to you.
    Any way here's the isolated CAN schematic for your review

    Please note that termination resistors are connected only to start and end of the bus

  • Thanks for the update. We'll be available to review any waveforms you're able to capture. 

    I'm not able to see the image you shared. Could you try to post it again?

    Regards,
    Eric

  • Hi,

    Thanks for sharing. Everything in the schematic looks good - nothing here would indicate intermittent interruptions. Also, thank you for clarifying how the termination is configured - this indeed should only be done at the endpoints of the CAN line.

    Best of luck with the testings. We will await the results and potential scope shots if aquireable. 

    Regards,
    Eric 

  • Hi,

    I'm going to mark this thread as closed for now. If you'd like to share any updates, please reply to them here and the thread will automatically re-open. You may also click the yellow "Ask a related question" button if you believe the topic has changed from the original posting.

    Thanks and regards,
    Eric