• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 64 subscribers
  • Views 239 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TPS25750EVM: Wrong Address

Eric Castle
Intellectual 710 points
Part Number: TPS25750EVM
Other Parts Discussed in Thread: TPS25750

Hello,

On one of our custom boards (that is replicating the EVM), we have a TPS25750 that is responding on address 0x23 instead of 0x21. I found the decoder ring over here finally (https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1160350/tps25750-how-the-adcinx-pins-are-decoded), and we have our ADCIN1 and ADCIN2 both tied to LDO1V5. Any idea what could be going on here? I don't see this happening on other boards. 

Thanks,

-Eric

  • 0
    TI__Genius 15275 points

    Hi Eric,

    Can you confirm LDO1V5 output voltage with oscope? If all boards were built the same and have same HW configuration most likely it could be damaged IC where the LDO1V5 is not coming online or ADCINx is damaged.

    Regards,

    Brandon

  • 0 in reply to Brandon Beader
    Intellectual 710 points

    Hi Brandon,

    I did confirm 1.6V on LDO1V5, which seems like it should be well within range to qualify as a "5". It's a tiny part, but I think I managed to measure 1.6V on ADCINx pins.

    It's entirely feasible that somehow the part has been damaged somehow. Have you seen anything like this before? Any other ways I might confirm that? (is there any way to see what the ADC thinks it's seeing?)

    Thanks,

    -Eric

  • 0 in reply to Eric Castle
    TI__Genius 15275 points

    Hi Eric,

    I have never seen a device be damaged that responds with another slave address. An indication the device is damaged is if the powertree is not functioning correctly (LDO's) which they seem to be functioning fine. Does all other functionality of the device behave as expected besides I2C slave address? If all behavior is normal, the ADC's could be damaged on the device returning a false value from what is expected.

    Regards,

    Brandon

  • 0 in reply to Brandon Beader
    Intellectual 710 points

    No, the part isn't loading its configuration at power-up (no attempt to talk to the EEPROM on address 0x50). It appears to be in PTCH mode. 

  • 0 in reply to Eric Castle
    TI__Genius 15275 points

    Hi Eric,

    There seems to be issue with your ADCINx pins on the defect boards. 

    Your dead battery configuration needs to be in SafeMode when trying to load configuration from EEPROM. 

    Regards,

    Brandon

  • 0 in reply to Brandon Beader
    Intellectual 710 points

    Hi Brandon,

    Are you saying that if I want the part to default to loading its configuration from the EEPROM upon boot, I'd want to have it start in SafeMode then? So, if I don't care about its I2C address, I could use any of those 4 combinations (like ADCIN1 to LDO_3V3, and ADCIN2 to ground?)

    Any idea why some of our boards are working then, if they're starting in "AwaysEnableSink"? Is that an incorrect hardware configuration?

    Thanks,

    -Eric

  • 0 in reply to Eric Castle
    TI__Genius 15275 points

    Hi Eric,

    Yes that is correct, you can use any combination of the decoded ADCINx values that would put you into SafeMode upon boot. 

    We have seen this issue with AlwaysEnableSink, it is buggy and not inteneded to be used when loading config from EEPROM. 

    Regards,

    Brandon

  • 0 in reply to Brandon Beader
    Intellectual 710 points

    Brandon,

    Great, thanks for clarifying this.

    It sounds like the EVM design is somewhat incorrect then, as it has both of the ADCINx pins tied to LDO_1V5, when (as far as I can tell) the method for loading it is to flash the EEPROM and have the part load its configuration from that at startup.

    Anyway, thanks again for the help,

    -Eric