• State
  • Replies 3 replies
  • Subscribers 46 subscribers
  • Views 52 views
  • Users 0 members are here
Support feedback
Options
Options
Related

DAC63202: Persistent I2C errors and bus lockup using DAC63202

Tracy Wynn
Prodigy 20 points

Part Number: DAC63202

I am using DAC 63202 in a high-voltage generation system controlled by a small I2C bus (controller, DAC, ADC). The DAC is responsible for setting the input voltage to the DC-DC conversion that generates the HV output and is confined to the low-voltage domain of the circuit. I find that my I2C bus is experiencing persistent errors, and that these errors are often unrecoverable, leading to a situation in which SDA is being held down by one of the components on the bus. I was able to isolate this to the DAC by removing its power source while the SDA line was being held down. Disabling the DAC in this way resulted in the release of the SDA line.

I am not sure that the DAC is the root cause of the problem - there is some evidence that noise on the HV side of the circuit could be affecting the ADC's I2C integrity - but it is certainly a major factor, as it is clearly holding the SDA line low and crashing the bus. What sort of conditions might lead to this sort of behavior and how might it be addressed?

  • 0
    TI__Guru** 100725 points

    Tracy,


    There are many different problems that can cause problems in the I2C communication. As you mentioned noise is one possible problem. I think you should take an oscilloscope shot of the I2C communication to just check the waveforms and see if there are problems.

    I would note that this device does have a timeout feature. In the INTERFACE-CONFIG register you can enable the timeout with Bit 12. I think that if the I2C bus is stuck, you can stop communications for 25ms (I think) and the device will release the bus. This is a feature similar to SM-Bus/PM-Bus.


    Joseph Wu

  • 0
    Prodigy 20 points

    Thank you, Joseph,

    I have looked a the device with an o-scope and so far have not been able to detect any signal I would classify as noise, per se. I am really using that word as a catch-all term in this context to mean "some signal that should not be present." What is actually happening is that at the end of a certain I2C sequence the SDA is being pulled low at an inappropriate time, and held there, by something on the bus. Fortunately, there are only three devices on the bus: the master, the DAC, and an I2C bridge that isolates between a low-voltage domain and a high-voltage domain. Fortunately, that bridge employs a slightly higher than typical voltage of 0.7V for a LOW (an anti-latching feature), so I can distinguish a LOW from that device from all the others. In this case the inappropriate LOW is very near GND potential, so it must be coming from the DAC or the controller. The controller seems unlikely, or at least less likely than the DAC, since all of its signaling is SW-controlled. So, we are looking for a reason why the DAC might do that.

    Regarding the timeout watchdog: it sounds as though if this is enabled, then there is a timer that resets every time the DAC is addressed and if 25msec (or so) elapses, the DAC releases the bus. Is that a correct understanding (it's not really described in the data sheet)? Does the device simply open the internal FET and allow the SDA line to go HIGH, or does it do anything else (like, perhaps, briefly bring SDA LOW)?

    Regards,

    Tracy

  • 0 in reply to Tracy Wynn
    TI__Guru** 100725 points

    Tracy,


    It might be easiest to post a picture of the I2C signaling here. It would be best to show the start/stop in the byte transmissions, and maybe a picture of the signal when the bus is locked. I might notice something in the communication.

    When the timeout of the DAC63202 is enabled, the timeout detects the when the bus is locked for a time period of 25ms. If this is the case, the device aborts the communication transaction and is forced to recognize a new START condition. The timeout should release the SDA/SCL pulldown and wait for a new communication.


    Joseph Wu