TPS25751: Issue with the communication between TPS25751 and BQ25798

Hi,

I restarted the system and now the TPS25751 is able to read the image from EEPROM but the communication with BQ25798 is not working. Please find the log below.

TPS_BQ_I2C.log:

write to 0x50 ack data ...

write to 0x50 ack data: 0x47 0xC0
read to 0x50 ack data: 0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x09 0x20 0x00 0x00 0x09 0x01 0x00 0x00
write to 0x6B ack data: 0x01
read to 0x6B ack data: 0x03
write to 0x6B ack data: 0x10 0x00
write to 0x6B ack data: 0x10 0x00
write to 0x6B ack data: 0x14 0x1C
write to 0x6B ack data: 0x11 0x00
write to 0x6B ack data: 0x12 0x80
write to 0x6B ack data: 0x08 0x0A
write to 0x6B ack data: 0x09 0x01
write to 0x6B ack data: 0x01 0x03 0x48
write to 0x6B ack data: 0x03 0x00 0x64
write to 0x6B ack data: 0x0F 0x00
write to 0x6B ack data: 0x12 0x80
write to 0x6B ack data: 0x0F 0x00
write to 0x6B ack data: 0x0B 0x00
write to 0x6B ack data: 0x06 0x00
write to 0x6B ack data: 0x03 0x00
write to 0x6B ack data: 0x48
read to 0x6B ack data: 0x19
write to 0x6B ack data: 0x10
read to 0x6B ack data: 0x00
write to 0x6B ack data: 0x00 0x10
write to 0x6B ack data: 0x2E
read to 0x6B ack data: 0x30
write to 0x6B ack data: 0x00 0x2E
write to 0x6B ack data: 0x0F
read to 0x6B ack data: 0x00
write to 0x6B ack data: 0x00 0x0F
write to 0x6B ack data: 0x10
read to 0x6B ack data: 0x00
write to 0x6B ack data: 0x00 0x10
write to 0x6B ack data: 0x1C
read to 0x6B ack data: 0x00
write to 0x6B ack data: 0x14
read to 0x6B ack data: 0x1C
write to 0x6B ack data: 0x00 0x14
write to 0x6B ack data: 0x3B
read to 0x6B ack data: 0x00 0x00

As you can see in the last transaction, even when the battery is connected, on Reg_0x3B, the VBAT-ADC value is 0.

Hi Sai,

I primarily support the TPS25751, but have some experience with the BQ aprts.

Could you also check registers 0x2E and 0x2F. The ADC monitors on the BQ device need to be enabled for a proper reading. Specifically the EN bits for the ADC and the VBAT_ADC.

The TPS25751 currently does not modify these registers, so any modification would need to be done by an external mcu.

Thanks and Regards,

Chris

Hi Chris,

Thank you for your response.

Yes, I am enabling ADC_EN and ADC_SAMPLE to 15bit effective resolution in Register 0x2E and am not modifying Register 0x2F since the default setting for every parameter is enable.

Thanks and regards,
Sai

Hi Chris,

I created the I2C Write transaction function according to TPS25750 Technical Reference Manual (Rev. A) page 60.

Below, you can find the data transaction between the TPS25750 & BQ25798 using saleae 

write to 0x6B ack data: 0x48
read to 0x6B ack data: 0x19
write to 0x6B ack data: 0x10
read to 0x6B ack data: 0x80
write to 0x6B ack data: 0x10 0x80
write to 0x6B ack data: 0x2E
read to 0x6B ack data: 0xB0
write to 0x6B ack data: 0x2E 0xB0

But using the same code, since there is no change in the TPS25751 Technical Reference Manual (Rev. A) page 77, the data transaction between the TPS25751 & BQ25798

write to 0x6B ack data: 0x48
read to 0x6B ack data: 0x19
write to 0x6B ack data: 0x10
read to 0x6B ack data: 0x00
write to 0x6B ack data: 0x00 0x10
write to 0x6B ack data: 0x10
read to 0x6B ack data: 0x00
write to 0x6B ack data: 0x00 0x2E 

You can see that the register address location is changed and this shows that I'm writing to Register 0x00 & the data is 0x2E


So I removed the Byte 3 (Length) , 15:8 Reserved value, and then flashed the firmware and voila, the communication worked.

write to 0x6B ack data: 0x48
read to 0x6B ack data: 0x19
write to 0x6B ack data: 0x10
read to 0x6B ack data: 0x00
write to 0x6B ack data: 0x10 0x00
write to 0x6B ack data: 0x10
read to 0x6B ack data: 0x00
write to 0x6B ack data: 0x2E 0x80 

** Now the issue is with the BQ25798 configuration, the same config.json was used to generate the image for TPS25750 and TPS25751, the initialization of BQ25798, when TPS25750 used, is working but the initialization of BQ15798, when TPS25751 used,  is not working.

Hi Sai,

sai bandaru said:

So I removed the Byte 3 (Length) , 15:8 Reserved value, and then flashed the firmware and voila, the communication worked.

Yes, It was recently found that there is an issue with the "I2CW" command description in the TRM, and the documentation is currently being updated.

sai bandaru said:

** Now the issue is with the BQ25798 configuration, the same config.json was used to generate the image for TPS25750 and TPS25751, the initialization of BQ25798, when TPS25750 used, is working but the initialization of BQ15798, when TPS25751 used,  is not working.

Can you share an I2C log of the TPS25750 -> BQ25798 and TPS25751 -> BQ25798 to compare any differences. What do you mean by "not working". When you say you use the same config, what do you mean? Are you using the 0.6.0 GUI with the same config and only changing the project type?

Thanks and Regards,

Chris

Hi Chris,

The communication between TPS25750 - BQ25798, when I started my board, is as follows:

#TPS25750 implicitly sends data to BQ25798
write to 0x6B ack data: 0x10 0x80
write to 0x6B ack data: 0x14 0x1C
write to 0x6B ack data: 0x11 0x00
write to 0x6B ack data: 0x12 0x00
write to 0x6B ack data: 0x08 0x0A
write to 0x6B ack data: 0x09 0x01
write to 0x6B ack data: 0x01 0x03 0x48
write to 0x6B ack data: 0x03 0x00 0x64

# MCU explicity asks TPS25750 to send data to BQ25798 from here
write to 0x6B ack data: 0x48
read to 0x6B ack data: 0x19
write to 0x6B ack data: 0x10
read to 0x6B ack data: 0x80
write to 0x6B ack data: 0x10 0x80
write to 0x6B ack data: 0x2E
read to 0x6B ack data: 0x30
write to 0x6B ack data: 0x2E 0xB0

I replaced the TPS25750 on my board with TPS25751 and the communication between TPS25751 - BQ25798, when I start the board, is as folllows:

#TPS25751 implicitly sends data to BQ25798
write to 0x6B ack data: 0x01
read to 0x6B ack data: 0x03
write to 0x6B ack data: 0x10 0x00
write to 0x6B ack data: 0x10 0x00
write to 0x6B ack data: 0x14 0x1C
write to 0x6B ack data: 0x11 0x00
write to 0x6B ack data: 0x12 0x80
write to 0x6B ack data: 0x08 0x0A
write to 0x6B ack data: 0x09 0x01
write to 0x6B ack data: 0x01 0x03 0x48
write to 0x6B ack data: 0x03 0x00 0x82
write to 0x6B ack data: 0x0F 0x00
write to 0x6B ack data: 0x12 0x80
write to 0x6B ack data: 0x0F 0x00
write to 0x6B ack data: 0x0B 0x00
write to 0x6B ack data: 0x06 0x00
write to 0x6B ack data: 0x03 0x00

# MCU explicity asks TPS25751 to send data to BQ25798 from here
write to 0x6B ack data: 0x48
read to 0x6B ack data: 0x19
write to 0x6B ack data: 0x10
read to 0x6B ack data: 0x00
write to 0x6B ack data: 0x10 0x00
write to 0x6B ack data: 0x2E
read to 0x6B ack data: 0x30
write to 0x6B ack data: 0x2E 0x80


I generated the images for TPS25750 & TPS25751 using the USBCPD web tool and the configuartion json file, which is same for both, was posted above when I created this issue.

I also found out that the image generated from the Web application is different from the Desktop application. 

Best, Sai

Hi Sai,

Could you clarify what you determine to be "not working"? I want to try to test on an EVM on my end to see if I can replicate the behavior.

Thanks and Regards,

Chris

Hi Chris,

Thanks for your message.

I’m trying to charge a 7V 3.5Ah battery using the PCB I designed, which contains the TPS25751 and BQ25798. I generated the configuration using the USBCPD Tool with the config.json file (provided below), and I’m initializing the BQ registers with the following values:

config.json :
{
"questionnaire": {
"device": "TPS25751",
"answers": [
null,
0,
0,
0,
0,
1,
3,
0,
1,
1,
1,
0,
0,
0,
8.4,
1,
0.04,
0.4,
0
],
"vendorId": "0000",
"productId": "0000",
"version": "1.0.0.2"
}
}

BQ25798 register values:

IPRECHG = 10 (since step size is 40mA)
ITERM = 1 (since step size is 40mA)
ICHG = 200 (since step size is 10mA)
VINDPM = 190 (since step size is 100mV)
IINDPM = 70 (since step size is 10mA)

In my previous design, I used the TPS25750, and with the above register values & image generated using USBCPD Tool, I was able to charge the battery without any issues. However, after switching to the TPS25751, the system is not working with these configurations.

Let me know if you need more details to assist in replicating the behavior.

Thanks and regards, Sai

Hi Chris,

Just one more note, we have noticed that the TPS25751 is disabling the ACDRVx and that's why the BQ25798 is not detecting any input from the USB. We have tried to explicitly enabling it but the TPS25751 is disabling it frequently.

We are using the ACDRV because the BQ25798 has two input sources. And we are following the design from the EVM. Like is said previously, this design is working perfectly with TPS25750.

Thanks and regards, Sai

Hi Chris,


Yes, we are able to confirm that forcing Reg_0x12 to 0x00, i.e. enabling the ACDRV, is solving the issue. Along with this, we are also forcing Reg_0x10 to 0x80 and  Reg_0x0F to 0x82.

By forcing these 3 registers, we are atleast able to charge the battery using two input sources. But we are not sure how this, i.e. forcing these registers, will effect the BQ25798 working in long run.

In order to not let TPS25751 configure the BQ25798, we generated an image with the following configuration and did the experiment by forcing the above three registers, i.e. Reg_0x12, Reg_0x10, and Reg_0x0F.

config_noBQ.json:

{
"questionnaire": {
"device": "TPS25751",
"answers": [
null,
1,
0,
0,
0,
1,
3,
0,
1,
1,
1,
0,
0,
0,
8.4,
1,
0.04,
0.4,
0
],
"vendorId": "0000",
"productId": "0000",
"version": "1.0.0.2"
}
}

And,

The working PCB that has TPS25750 with BQ25798 configured, is only writing the following values to BQ25798 during initial start-up;

write to 0x6B ack data: 0x10 0x80
write to 0x6B ack data: 0x14 0x1C
write to 0x6B ack data: 0x11 0x00
write to 0x6B ack data: 0x12 0x00
write to 0x6B ack data: 0x08 0x0A
write to 0x6B ack data: 0x09 0x01
write to 0x6B ack data: 0x01 0x03 0x48
write to 0x6B ack data: 0x03 0x00 0x64

Whereas the new PCB that has the TPS25751 with BQ25798 configured, is writing the following values to BQ25798 during the initial start-up;

write to 0x6B ack data: 0x01
read to 0x6B ack data: 0x03
write to 0x6B ack data: 0x10 0x00
write to 0x6B ack data: 0x10 0x00
write to 0x6B ack data: 0x14 0x1C
write to 0x6B ack data: 0x11 0x00
write to 0x6B ack data: 0x12 0x80
write to 0x6B ack data: 0x08 0x0A
write to 0x6B ack data: 0x09 0x01
write to 0x6B ack data: 0x01 0x03 0x48
write to 0x6B ack data: 0x03 0x00 0x82
write to 0x6B ack data: 0x0F 0x00
write to 0x6B ack data: 0x12 0x80
write to 0x6B ack data: 0x0F 0x00
write to 0x6B ack data: 0x0B 0x00
write to 0x6B ack data: 0x06 0x00
write to 0x6B ack data: 0x03 0x00

As you can see the highlighted values above; the TPS25751, flashed with the image using the config.json, is disabling the ACDRV in Reg_0x12 and also resetting the Reg_0x10 and Reg_0x0F.

Now, we are questioning what other registers are initialized differently between TPS25750 and TPS25751.

Also, please send me the ".C" file instead of binary.

Thanks and regards, Sai 
 

Hi Sai,

See the attached .C file.

config_ACDRV_DIS_off.c

The PD controller will overwrite registers 10 and 0F so your writes may not work. The included .C file mainly disables the ACDRV_DIS assertion.

Thanks and Regards,

Chris

Hi Chris,

The "config_ACDRV_DIS_off.c" is not working as required.

Like I said in the previous thread,

we generated an image with the following configuration and did the experiment by forcing the three registers, Reg_0x12, Reg_0x10, and Reg_0x0F to 0x00, 0x80 and 0x82 respectively. Then we were able to use two input sources to charge the battery.

config_noBQ.json:

{
"questionnaire": {
"device": "TPS25751",
"answers": [
null,
1,
0,
0,
0,
1,
3,
0,
1,
1,
1,
0,
0,
0,
8.4,
1,
0.04,
0.4,
0
],
"vendorId": "0000",
"productId": "0000",
"version": "1.0.0.2"
}
}

Thanks and regards, Sai

Hi Sai,

Can you provide a block diagram of your system, specifically the charging architecture? I think I am confused about how you have set up your system and your expectations for the PD controller I2C configuration.

When you are testing the charging, where is power coming from? Is there a USB-C PD source attached to the TPS25751?

When you say "two input sources to charge the battery", what are the two sources? How do you manage which one provides power?

The PD controller configuration provided in the GUI is designed to control the Battery charger with respect to the PD negotiation on the port. Some of the register writes you are asking for contradict our expectations of the system and can't easily be modified.

Specifically, the ENCHG and ENOTG bits are controlled by the PD controller depending on the USB-C PD state(power source or power sink), and does not take a second BQ supply into account. Depending on your requirements for your system, we may not be able to support a second source with our I2C events and may require that the MCU manages all of the I2C communication in the system.

Reg 0x12: currently set to 0x80, but the latest .c file that I shared should not be setting bit 7(DIS ADC_DRV) anymore.

 - We primarily control the ENOTG bit in this mode and it is dependent on the USB-C Source/Sink state.

Reg 0x10: currently being set to 0x00, you are using 0x80.

 - This would set the backup mode ot 80% VINDPM which should not affect charging.

Reg 0x0F: Defaults to 0x00, you are writing 0x82

 - By default we disable this register, when the USB-C device detects a source is attached and enters sink mode, we will progarm this register to enable charge. I'm not sure how a write of 0x82 would enable CHG mode though.

Let me know about your system and it's requirements and we can see how to proceed from there.

Thanks and Regards,

Chris

Hi Chris,

Please change the post to private before sharing the design.

Thanks and regards, Sai

Hi Sai,

I sent you a friend request, please accept and share the design over private messages. I can't convert this thread to a private one unfortunately.

Thanks and Regards,

Chris