Possibly severe bug in AD5695 I2C interface?

Hi there,

I think that we have discovered a bug in the implementation of the I2C interface of the given device corrupting communication with other devices on the same bus.

In our application the DAC is on the same bus as a 4kBit EEPROM, occasionally (but reproduceable, depending on the data written) the DAC disturbs the I2C communication with the EEPROM.

There seem to be two cases:

  • Case 1:
    The address of the DAC (plus read bit) - 0x19 in our case - is the nineth byte in the data stream since the start condition, e. g.

    StartCondition,0xA2,0x90,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x19,0xFF

    In this case the AD5695 kicks in after the 0x19 and destroys the 0xFF byte.

  • Case 2:
    The address of the DAC is anywhere in the first eight bytes of the data stream, at byte 8 and 10 the address is repeated, but with a shift of one and two bits to the left, e. g.

    StartCondition,0xA2,0x90,0x19,0xFF,0xFF,0xFF,0xFF,0xFF,0x33,0xFE,0x67,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF

    In this case the AD5695 kicks in and sends an ACK at the bit 1 of the value 0x67 effectively changing this value to 0x65 or 0x64 (depending on the next transferred data byte by the AD5695).

In both cases the controller (an NXP 11C14) will detect an arbitration loss and stop the transmission after the corrupted byte without trying to send a stop condition.

When disconnecting the SDA line of the AD5695R the errors are no longer observed.

We have analyzed the bus regarding signal levels, setup/hold times, noise etc. without finding any deviations from the standard, and with a logic analyzer to get the full communication sequence.

As the results are reproducable by 100% we assume that there is a bug in the I2C implementation of the AD5695. It looks as if the state machine isn't deactivated after an address mismatch but still looking for matches. It looks as if some internal bitcounter produces an overrun which in combination with the still active state machine leads to the activation of the data transmission.

As a workaround we now transfer only small blocks of data, but we need some qualified statement if that really guarantees an error free commmunication.

For further analysis I have attached some Saleae logic analyzer traces (you need the latest version to view them). Please note that after triggering the bug our software times out (after 20ms from the start condition), then issues a single byte write to recover the I2C and then waits a bit before triggering the bug with the next test pattern. The granularity of this timeout timer is 10ms, so there is a corresponding jitter in the idle times.

With best regards,
Torsten Lang

attachments.zip
  • 0
    •  Analog Employees 
    on Jan 20, 2017 1:54 PM

    Hi Torsten,

    The bug described is genuine and has been officially communicated to direct customer and distributors. As you can imagine, we do not have access to disti customers but PCN is accessible directly in our web page,

    http://www.analog.com/media/en/PCN/ADI_PCN_16_0138_Rev_-_Form.pdf 

    The bug reported is already fixed in the latest silicon. To replace the bad units, could you contact your disti, please?

    Let me know if you have any problem, please.

    Regards,

    Miguel

  • Hi Miguel,

    nice to learn that such an important information is hidden in the "Samples" section and not published together with the other documents (like data sheet and IBIS model) for this part.

    We now have a batch of units we may have to rework which could have easily been avoided if the information would have been found in the place where I would expect it (and clearly marked as errata sheet). I have wasted several hours to find further information like some errata info...

    Regards,

    Torsten

  • 0
    •  Analog Employees 
    on Jan 23, 2017 9:21 AM

    Hi Torsten,

    I really apologies for this but let me explain how this theoretical works,

    Once we found the bug, we immediately inform our direct customers and distributors, emailing directly the PCN.

    We scrap old units, and fill the warehouse with fresh (bug free) samples. From our side, once we generate the PCN, we did not ship more units of this device until the fresh units are in the warehouse.

    If you bough the unit trough a disti, they should be contacted you offering a  replacement, and informing you about the bug... but as you can imagine, we do not have control over these actions.

    Answering your question, the PCN is not beside the DS as could be an erratasheet for two reasons,

    1- Once the PCN is generated we are working to remove ANY defective unit from the market, which meas that the PCN is not valid for the units that you can be in the future.

    2- the errata sheet report a problem that still is applicable for old units, in other words, the units that exhibit the problem has not been remove from the market.

    Let me know if you have more questions, please.

    Regards,

    Miguel