TPS38700S-Q1: Invalid I2C address

Part Number: TPS38700S-Q1

Tool/software:

Dear all,

I am using the TPS38700S-Q1 and I was wondering why the sequencer address is not correct?

In the datasheet it is written 0x3C and it answers at the address 0x07.
Could you tell me why? Is there any impact on this?

I have another situation; could you tell me what's the behavior if an I2C communication is interrupted?

Whenever I have an i2c interruption, I observe SCL at 1 and SDA at 0.

I am trying to do a bus clear generating 9 clocks pulses to unblock the i2c slave but i has no effect.

Do you have a solution for this ?

Best regards,

Tom LEVISSE

  • Hi Tom,

    Thanks for your question!

    Just to confirm, could you please let me know the full part number of the device you are using?

    Also to confirm, are you able to read the value in register 0xF9 as described below:

    When you mention an interrupted I2C communication, could you please clarify what happens in these situations? Does this mean that the I2C communication stops midway through? It would be helpful to have a scope capture of the SCL/SDA lines in this situation.

    Best Regards,

    Andrew Li

  • Hello Andrew,


    The full part number is TPS38700603SRGERQ1.
    I confirm that I read 0x07 in the 0xF9 register.

    Could you tell me if this address which is normally a reserved I2C address can have an impact?
    Why do I have this peculiar address?


    For the second problem, I have solved it by generating SCLK pulses to unlock the i2c slaves.

    Best regards,
    Tom LEVISSE

  • Hi Tom,

    Thanks for the update!

    That is definitely a bit strange as the I2C address should be 0x3C as per the datasheet.

    I am double checking with the team, but in the meantime, does this issue persist across multiple devices, or is it only for 1 device?

    I will get back to you by this week.

    Best Regards,

    Andrew Li

  • Hi Tom,

    Thanks for your patience.

    I just double checked with the team, and the correct I2C address for this device is actually 0x07. 

    The datasheet has a mistake which I will work with the team to fix.

    Best Regards,

    Andrew Li