TPS25751: configuration issue with BQ25756

Hi Tobias,

The TPS25751 I2C interface follows the SMBUS protocol. The first "data" byte indicates the byte count to read from the register. In your case, it is indicating that the Status(0x1A) register has up to 5 readable bytes. You are not required to read all of the bytes (i.e. if you only need plug connect, you can choose to just read the first byte)

Regarding the charge current, can you share the json you are using?

Also, could you obtain an I2C log of the TPS25751 I2Cc bus on power up? We need to confirm if the TPS25751 is communicating with the EEPROM and BQ25756 properly on start up.

How are you verifying that the charge current is incorrect?

Thanks and Regards,

Chris

Hi Chris,

thanks for your response.

• The json we used:

{
  "questionnaire": {
    "device": "TPS25751",
    "toolBuildVersion": "1.0.2",
    "answers": [
      null,
      4,
      4,
      3,
      1,
      0,
      3,
      0,
      1,
      1,
      1,
      3,
      1,
      0,
      1.566,
      2,
      0.25,
      0.5,
      0
    ],
    "vendorId": "0000",
    "productId": "0000",
    "version": "1.0.0.2"
  }
}

• Sadly I can not log I2C communication on I2Cc bus. But I can access BQ25756 with I2Cr and I2Cw 4CC-Commands.
• "How are you verifying that the charge current is incorrect?" --> After boot up I connect via I2Ct with PD and readout BQ25756 registers with I2Cr and I2Cw 4CC-Commands.

Thanks,

Tobias

Hi Tobias,

How are you powering the TPS25751? From VIN3V3 or from the type-C connector?

To confirm that the image is being loaded properly from the EEPROM, can you try the following:

1. Generate a new image
   1. In the new image, modify the "customer use word" (0x06) to have some non-zero value (1234, abcd, just non-zero). You will need to enter Advanced config
   2. 
2. Load it to your design
3. Read register 0x06 and confirm it is updated properly.

Without an I2C log, it may be difficult to debug. If the image on the EEPROM matches what you are using on the EVM, the TPS25751 should be programming the BQ25756 properly as long as it boots properly. We would expect to see some I2C traffic on power up that programs the BQ with the values you have set.

Because the image is working properly on EVMs, I'm thinking there might be some difference in schematic or boot that is affecting the I2C.

Because the I2Cw and I2Cr seem to work, we can assume the I2C is connected properly and the issue may be with the boot  sequence.

Let me know if you can read back the correct value in 0x06.

Thanks and Regards,

Chris

Hi Chris,

• Power comes from VIN3V3
• I put 0x1234 and 0xabcd into customer use word and after updating eeprom and reset tps register 0x06 is (RAW) 0x34120000cdab0000 (which is correct because byte order is little!?)

Or do I have to reverse the binary (per Byte) when flashing?

Regards,

Tobias

Hi Chris,

thanks again for your help.

Content of BQ register in different States:

Without flashed EEPROM:

Charge Voltage Limit: 1.504 V
Charge Current Limit: 6.400 A
Termination Current Limit : 6.600 A

With flashed EEPROM (without usb-c plugged in):

Charge Voltage Limit: 1.566 V
Charge Current Limit: 0.400 A
Termination Current Limit : 0.250 A

With flashed EEPROM and plugged in usb-c:

Charge Voltage Limit: 1.504 V
Charge Current Limit: 0.000 A
Termination Current Limit : 0.000 A

Power Good Status Flags stays "Not Power Good" in all three scenarios.

Thanks,

Tobias

Tobias,

Without Flashed EEPROM: Probably fine? This might just be the default setting. I mainly support the PD controller ICs, so cannot comment too much on the BQ.

With Flashed EEPROM: Looks correct, Charge voltage and Current match the json. On initial boot we program the 

With Flashed EEPROM and plugged in usb-c: Not sure what is happening here, I don't expect the TPS25751 to ever zero the registers you are reading, which is what the values you are reading seem to indicate. Are you sure that the reads are happening properly? Do you have any way to probe the I2C lines to confirm the reads are valid?

How are you powering the system? On part 3, when USB-C is plugged in, is the BQ25756 losing power for any reason?

How are you reading the registers? Using I2Cr/I2Cw? Reading directly from the BQ?

The TPS25751 should never program a value of 0 to the termination current, and I would expect the BQ device to set default values on power cycling, not zeroes, so this behavior seems strange.

The best way to confirm at this point would be too hook up some I2C decoder.

This is what the I2C should look like on power up. You can see the writes to the charge voltage, termination current, and charge current registers, which match what you are seeing when you read the registers in the "With Flashed EEPROM" case.

I'm checking with the BQ team to confirm the register behavior on the side.

Thanks and Regards,

Chris

Hi Chris,

we managed to get an I2C Decoder now. The I2C signal I get during power up looks pretty much the same like in your image, expect the only read of the charger after first contact:

0x6B(W) 0x33
0x6B(R) 0x72 19

- System is powered by battery, so TPS uses VIN_3V3.

- I read/write charger registers with I2Cr & I2Cw. With I2Cw I experienced a deviation from manual. If I want to send 0xdc to register 0x17 of the charger from manual I would place 0x6B 0x01 0x00 0x17 0xDC into the TPS data register. Doing so I see the TPS sending 0x6B(W) 0x00 17. I think length must be only one byte and register offset is included in payload. By putting 0x6B 0x02 0x17 0xDC into TPS data register I managed to save 0xdc into register 0x17. The I2Cw command always ACK even when no I2C message is leaving TPS.

When usb-c is plugged I see the TPS sending periodically

0x6B(W) 0x19 21.
0x6B(W) 0x33
0x6B(R) 0x0E 1B

Regards,

Tobias

Hi Tobias,

The initial read should be fine. If the writes look similar, then you should be good, and the image seems to be loading properly.

Tobias said:

- I read/write charger registers with I2Cr & I2Cw. With I2Cw I experienced a deviation from manual. If I want to send 0xdc to register 0x17 of the charger from manual I would place 0x6B 0x01 0x00 0x17 0xDC into the TPS data register. Doing so I see the TPS sending 0x6B(W) 0x00 17. I think length must be only one byte and register offset is included in payload. By putting 0x6B 0x02 0x17 0xDC into TPS data register I managed to save 0xdc into register 0x17. The I2Cw command always ACK even when no I2C message is leaving TPS.

Yes, you are correct here, there is a typo in the TRM we are working on fixing. See below for the correct formatting.

Tobias said:

When usb-c is plugged I see the TPS sending periodically

This is fine, on unplug, some "safe config" writes are sent to put the BQ into a known state for the next reconnect.

Are there any open questions on this thread? Let me know if I missed anything or if you have any other questions.

Thanks and Regards,

Chris

Hi Chris,

our  PD+Charger+BMS system still do not charge our batteries.

I just looked at VBUS when I plug-in usb-c. It stays 0V.

We are wondering right now if we need PP_5V to power CCx pins?

In our understanding VBUS powers everything when usb-c is connected so that the tps can configure the power supply. Are we wrong?

Regards,

Tobias