The device detected traffic on the bus that does not match expected protocols.

Possible Causes:

• Improper SmBus read
  • A valid read from a PmBus device requires first sending a start, then address+write, then the command code, and then a repeated start (without a stop), before reading bytes from the slave
  • A common error for people familiar with I2C is to issue a stop, and then a new start with the address+read bit.  This is invalid and PmBus devices are required to pull ALERTB low and set this fault to signal to the host that it is communicating improperly
• Poor signal integrity on the bus
• Other unexpected protocol.
• One some devices, if the device sees an empty start/stop sequence will trigger this fault.
  • Clock remains high while data goes low (start) then high (stop)
  • Some devices (like DC1613A, FPGAs or other logic) may issue such sequences from time to time
  • For devices that flag this fault, if you are unable to avoid creating it, you can mask this fault from pulling ALERTB low by using the SMB_ALERT_MASK feature

Remedies and Workarounds

Here are some experiments you can try to narrow things down:

• Decrease the bus speed (View > Preferences) and see if the problem goes away
• Clear the fault and see if it returns / is recurrent
• Disable any other masters that may be conflicting with LTpowerPlay
  • Only one master should be communicating with the system at a time.  If you wish, you can disable LTpowerPlay by 'going offline'

Other Debugging Tips

There are a number of scenarios which can create a CML_OTHER_COM_FAULT.  If you have an oscilloscope, perhaps the fastest way to insight is to:

• Trigger the scope on the falling edge of the ALERTB signal, and 
• Look at SCL/SDA signals
  
  

The ALERTB signal will be pulled low by the IC at the time of the fault, indicating the time of the fault.  Look at SCL/SDA immediately preceding this for clues.