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.

TPS65987D: ADCIN2 not reading correctly

Part Number: TPS65987D


Tool/software:

This is a follow-up to the indicated related question.

Quick Summary: I have a 100k pull-up to LDO_3V3 on ADCIN2. This follows the design guidelines to set the I2C address to 0x23. We built several boards with this design, and most are coming up correctly as 0x23. However, some are coming up with address 0x20, as if it's not correctly reading the ADCIN2 voltage correctly. 

On the boards that are coming up 0x20, I have tried a few changes:

  1. I changed the 100k pullup to 10k, and then to 0 ohm. Neither of the changes had any affect and boards still came incorrectly up as 0x20.
  2. I tied the 100k pull-up to VIN_3V3, and not LDO_3V3. This was to eliminate the possibility that LDO_3V3 was coming up too slow or not stable when ADCIN2 was sampled. This change had no effect and boards still came incorrectly up as 0x20.
  3. In addition to the 100k pullup to LDO_3V3, I added a 0.1uF cap from ADCIN2 to GND. This actually did "fix" the boards and all came up as 0x23 as expected. This result is surprising since it slows the rise time on ADCIN2.
  4. I created a divider with the 100k pullup to LDO_3V3 and a 511k resistor to GND. The divider ratio is 0.84 which is "centered nominally between listed MIN and MAX values." This did also "fix" the boards and all came up as 0x23 as expected. 

I'm going to move forward with implementing the change described in #4. However, I'm still unsure why the divider would be necessary, and directly connecting to LDO_3V3 (with 100k) would not work. 

Thanks

  • Hi Kevin,

    This is a somewhat known issue for the TPS65987D. When a resistor divider is not used, but the ADCIN pins are tied directly to 3V3, there are times when the device does not decode this properly. We recommend using some kind of resistor divider to ensures the ADCIN value is decoded correctly. Change #4 is a valid fix, and we recommend this change. It seems like you are seeing the issue consistently without the resistor divider. We have not investigated the issue further because it was a rare occurrence and adding the divider is a workaround. Please let us know if boards start coming up with an incorrect I2C address after the fix.

    Best,

    Alex