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.

ISOW1044: Random CAN Errors

Part Number: ISOW1044

Tool/software:

Hi,

We are using the ISOW1044 as indicated in the datasheet Figure 11-1, including the 47uF caps recommended in 11.2.1. 

Some exceptions to the application circuit are:

  1. The 4.7k resistor between EN/FLT and V_IO is a 10k.
  2. pin 2 "IN" is not connected
  3. pin 4 "STB" is connected to ground (open triangle ground in application circuit)
  4. FB is a 742792641, 300R @ 100MHz

We did not include optional termination or bus protection.

The network is a Vector VN1630A and the DUT containing the ISOW1044.  120Ω each end.  CAN ground wired both ends, TSP.
Terminators are on the bus as 120Ω from CAN_H to CAN_L.  We are not using split terminators.

What I'm seeing during operation of the DUT is CAN Errors (about 0.3% error rate) that look to be caused by "bumps" in the CAN trace.  This bump occurs at various stages of the message, resulting in various bit positions.  

We're at a loss for how this is occurring.  We have tried various changes to grounds (CAN ground, Chassis, etc..) with no change in behavior.  The DUT is an electromechanical servo actuator that does operate in regenerative modes.  The occurrence of CAN errors while in regen mode increases.

We're looking for ideas to try so we can identify the root cause to these CAN Errors.

Thanks!

  • These bumps are ACK bits, where all other devices on the bus indicate that they have received the message. The voltage is higher because multiple drivers are active at the same time. This is not a problem.

    I do not know why your oscilloscope's decoder shows an error. Does this error also happen with real receivers? Do they have any indication what the error is?

  • Hi Tim,

    Thanks for reaching out and details provided.

    Some exceptions to the application circuit are:

    All of these connections are related to VDD and VISOUT pf the device and should not result in the error that you've mentioned above

    As Clemens suggested, do you have multiple drivers on the CAN bus side?

    Regards
    Varun

  • Clemens-  if they are ACK, they're in the wrong place which is what is causing the error.  

    Varun - the network is just two nodes.  A Vector VN1630A and the DUT.  I agree the deviations of the DUT to the application circuit should not create the errors we're seeing.  My first thought was in another node transmitting at the wrong time, but this seems unlikely.  What's weird is the bump seems quite intentional. 

    I see this error occur when the DUT is transmitting and when the Vector VN1630A is transmitting.

    The DUT is an electromechanical servo actuator and these errors occur much more frequently when the DUT is being backdriven (regenerative mode) indicating there may be an interaction with noise or other voltage changes?

  • How does the GPIO work?  Is there a chance the unconnected IN pin is picking up noise that could result in a CAN output?

  • Hi Tim,

    Thanks for the detailed inputs.

    I see this error occur when the DUT is transmitting and when the Vector VN1630A is transmitting.

    Just to confirm that here DUT means the electromechanical servo actuator right?


    The DUT is an electromechanical servo actuator and these errors occur much more frequently when the DUT is being backdriven (regenerative mode) indicating there may be an interaction with noise or other voltage changes?

    This is an interesting observation and might give us probable cause. Can you explain more on regenerative mode?


    How does the GPIO work?  Is there a chance the unconnected IN pin is picking up noise that could result in a CAN output?

    This is highly unlikely, because IN->OUT is a separate Isolated channel. Even if there were some noise pickup at IN, it will reflect on OUT and not CANH/CANL.

    From all the information you have provided till now, this looks to be a system noise issue since it is Random in Nature and also dependent upon specific mode of operation of external actuator DUT and also occurs only when the external Vector and DUT are transmitting. I don't see a reason or observation on how this could be a ISOW1044 Driver issue.

    Regards
    Varun