BQ25798: BQ25798

HI Aditya,

Regarding 1, If you can read the status and fault registers in REG0x1B through REG0x27, the charger will report the fault.  The fault flags clear after being read but if you have a steady 1Hz blinking, the status registers report the sustained fault.

Regarding 2 and 3, I will move this post to the PD controller team for response.

Regarding 4, V(TS) =2.5V ~=1/2*V(REGN) is nominal battery temp for max charging.

Regards,

Jeff 

Hi Aditya,

Aditya Patil said:

Are there any initialization steps required after patch download before the charger becomes fully functional?

No there should not be any initialization steps. Once the patch download has occurred, the PD controller should transition from "PTCH" mode to "APP " mode. you should then see some I2C traffic on the I2C bus between the PD controller and the BQ that configures the BQ automatically for usage.

Aditya Patil said:

Any possible configuration issues in the generated patch (e.g., IINDPM, VINDPM, charge current/voltage)?

Issues are always possible. Can you share the .json file used with the GUI? I can give it a quick review to see if anything is wrong.

Aditya Patil said:

Any recommended checklist or diagnostics procedure would be greatly appreciated to help debug this issue.

• Make sure the PD controller enters APP mode. (seems fine from what you have said so far, but just ensure it is)
• Capture I2C between the PD in the following situations
  • Right after patching the TPS25751
  • During the type-c connection to the USB Port
• Do you have a PD analyzer? A tool that captures and decodes the CC line communication. If you do have one, collect logs on the connection event.

Thanks and Regards,

Chris

Hello,

Thank you for the response.

After downloading the patch file to the PD controller, I can confirm that it transitions from ‘PTCH’ to ‘APP’ mode as expected.

If possible, could you please review the I²C logs I captured during the patch download process? I would also appreciate it if you could check whether the patch download sequence appears correct.

I’m attaching the following for your reference:

• The JSON file logs generated using the USBCPD Application Customization Tool v1.1.0

• The schematic/circuit diagram of the PD controller

Here are some key register observations:

• REG10_Charger_Control_1 (0x10) = 0x00

• REG1B_Charger_Status_0 (0x1B) = 0x0F

• REG26_FAULT_Flag_0 (0x26) = 0x00

• REG27_FAULT_Flag_1 (0x27) = 0x00

I suspect the BQ25798 is not entering HOST mode.

For reference, below are the details of the battery used:

Battery: ULIN401021 (Li-Ion Rechargeable)

• Nominal Voltage: 14.8V

• Nominal Capacity: 3200mAh

• Max Charging Current: 2000mA

• Max Charging Voltage: 16.8V

• Continuous Discharge Current: 3200mA

• Battery Energy: 47.36Wh

• Life Expectancy: >300 cycles with minimum 80% capacity retention (0.2C charge/discharge rate)

JSON File Logs:

{
"questionnaire": {
"device": "TPS25751",
"toolBuildVersion": "1.1.0",
"answers": [
null,
4,
4,
2,
1,
1,
2,
3,
1,
1,
1,
0,
1,
1,
16.8,
1,
0.12,
0.12,
0
],
"vendorId": "0000",
"productId": "0000",
"version": "1.0.0.2"
}

Please let me know if you notice anything unusual in the configuration or schematic. I can provide additional logs or clarification if needed.

Regards,
Aditya

Hi Aditya,a

The PBM flow looks fine.

Config also looks good.

I didn't see anything obvious wrong with the schematic.

Christopher Lim1 said:

Capture I2C between the PD in the following situations

• Right after patching the TPS25751
• During the type-c connection to the USB Port

A typo on my part, but could you capture the I2C between the PD controller and the BQ device during the two situations mentioned above? We should expect to see some I2C writes from the PD controller to the BQ device that configure certain operational modes during these two states. I need to confirm if they are happening or not.

I tested your json on the CHG-EVM, and it seems to be working properly. I was able to see precharge(.119-A) and charge current(1-A) being drawn when a Type-C PD source was attached at the port. I tested using both a 4 quadrant supply (battery emulator) and a Constant voltage e-load, both seem to work fine. Here is what we are expecting to see in the logs I am asking you to capture.

Is your battery attached to the Bat ports during this time?

Initial power up:

Some configuration of the BQ, some writes that are easy to verify are ones regarding the charging currents. These should match the config settings. It is also important that the watchdog timer gets disabled during this step. Ignore the large burst at the beginning and the writes to 0x50. This is just the Device booting from the EEPROM. 

Source is connected:

CHG mode should be enabled

INDPM and VINDPM should be programmed to values that reflect the negotiated PD contract (this is not easy to verify without a PD analyzer, but you should at least see writes to these registers).

The easiest way to confirm the patch burst process occurs properly is to read some PD controller registers to see if they match what has been set. A common recommendation we have is for customers to add specific data to the customer use register(1234, abcd etc), and read the register to confirm it matches. You need to unlock advanced config at the top to modify these registers in the GUI.

Aditya Patil said:

I suspect the BQ25798 is not entering HOST mode.

I'm not too familiar with Host mode, but what is important is that the EN CHG bit is set when the type-c source is attached. The BQ should be configured in to charge with the settings set in the PD controller GUI.

Thanks and Regards,

Chris

Hello, 

Thanks for your support earlier.

I’ve attached the I2C logs captured during:

• Patch download to the PD controller

• USB Type-C source connection

I updated the patch to set charging current to 2A (previously 1A). The patch loads correctly—verified using Customer Use Registers (0x00001234, 0x0000ABCD), which I was able to read back.

Despite this, charging doesn’t start, and the STAT LED blinks at 1Hz. I manually wrote 0x87 to REG05 (VINDPM), but the board starts pulling current from the battery instead of charging it.

Fault and Mask Registers (0x20–0x2D): All values read as 0x00, indicating no system-level fault latched and no fault/mask condition active. This hints at a temperature or VBUS qualification issue blocking charging.

I tried changing: USB Highest Speed? → No,  Legacy Charging (BC1.2)? → No. But no effect on charging.

Notes:

• TS pin is configured via REGN → 5.23kΩ → TS → 30.1kΩ → GND (as per JEITA guidance).

• Battery used: 14.8V / 3200mAh Li-Ion (ULIN401021), charging at 16.8V / 2A

• On EVM, I used the default binary did not flash my config setup. But with same USB source on the USB-PD-CHG-EVM-01 battery starts charging, but not on my custom board. 

Also, could you please help me with the following regarding EVM programming?

I currently do not have a flash programmer (e.g., Aardvark/Total Phase) for programming the EEPROM on the EVM.
→ Do you have any reference script or method to flash the EEPROM over I2C, directly from a Linux or Python setup?

In my working custom setup, I'm bypassing EEPROM and sending the patch binary directly to the PD controller after reset.
→ Is there a way to do something similar with the EVM, bypassing EEPROM?

I attempted to use the same script I’ve used to read BQ25798 registers via the PD controller, but it fails on the EVM.
I suspect the EEPROM continuously communicates with the PD controller, possibly overriding or interfering with host-initiated reads.

Would really appreciate your guidance on, any futher recommended diagnostics

Thanks

Aditya

HI Aditya,

Regarding the non qualified adapter, the D+/D- auto detect didn't find a matching adapter so the charger's input current limit (IINDPM) is the lower of 3A or ILIM_HIZ resistor divider clamp.

Regarding the charger's TS COLD fault, if there is no 10kohm thermistor or resistor from TS to GND and the charger's IGNORE TS remains at default = 0, the charger thinks the battery is too cold to charger.  You can also hardware disable TS by changing the TS pin resistor divider to have matched resistors.

Regards,

Jeff

Hi Aditya,

The I2C for sink connection looks correct and matches what I see on a working EVM. From the PD controller side, it looks like everything is working as expected.

Aditya Patil said:

I tried changing: USB Highest Speed? → No,  Legacy Charging (BC1.2)? → No. But no effect on charging.

Yes, these would have no effect on the charging.

Aditya Patil said:

On EVM, I used the default binary did not flash my config setup. But with same USB source on the USB-PD-CHG-EVM-01 battery starts charging, but not on my custom board. 

Do you use the same battery with the EVM?

If the same source and battery work with the EVM, there may be a schematic issue with your board.

Could you send the BQ portion of the schematic as well?

Aditya Patil said:

I currently do not have a flash programmer (e.g., Aardvark/Total Phase) for programming the EEPROM on the EVM.
→ Do you have any reference script or method to flash the EEPROM over I2C, directly from a Linux or Python setup?

No, we do not have any reference scripts for this. We also do not recommend flashing the EEPROM through the PD controller over I2C if this is what you are asking.

Aditya Patil said:

In my working custom setup, I'm bypassing EEPROM and sending the patch binary directly to the PD controller after reset.
→ Is there a way to do something similar with the EVM, bypassing EEPROM?

Potentially.

Can you try erasing the EEPROM so there is no valid image? The PD controller will attempt to read the EEPROM, but after realizing it does not have a good image, it should wait in PTCH mode.

Once in PTCH mode, you should be able to access the PD controller through the I2Ct lines on the J3 header, and use the PBMx sequence there. I have not tried this myself, but it should work.

Aditya Patil said:

I attempted to use the same script I’ve used to read BQ25798 registers via the PD controller, but it fails on the EVM.
I suspect the EEPROM continuously communicates with the PD controller, possibly overriding or interfering with host-initiated reads.

No, this should not be a problem. The EEPROM is only checked on initial boot, so once the EVM is powered, it should not interfere with host initiated reads.

 I would make sure you are using the correct I2Ct TPS25751 address. If that fails, send me an I2C log of both I2C busses when you attempt to do the host initiated reads, and we might be able to determine what is going wrong.

Thanks and Regards,

Chris

Hello all,

Thanks again for your support.

Today I tested by setting TS_IGNORE = 1, after which battery charging started. The battery now charges at around 400–450 mA, but it does not go beyond that. This is despite setting the battery charging current to 2 A, and using a 5 V/2 A adapter.

The battery used is ULIN401021 with a maximum charging current of 2000 mA and charging voltage of 16.8 V.

After charging starts, I observe the following:

• REG1B_Charger_Status_0 = 0x0F → Power Good, VBUS/VAC present

• REG1C_Charger_Status_1 = 0x70 in one case (Fast Charge, Unknown Adapter), and 0x90 in another (Taper Charge, Not Qualified Adapter) — possibly due to different sources (USB from laptop vs mobile charger)

• REG22 = 0x9F and REG23 = 0x90

After charging starts, I read REG11 = 0x00, and then follow the HVDCP detection steps from section "9.3.4.5.2 HVDCP Detection Procedure" of the datasheet. I set HVDCP_EN = 1 and EN_9V = 1, but still do not observe any increase in current.

As per your suggestion, we are also planning to reduce the 30 kΩ TS pin resistor to 10 kΩ to simulate the thermistor behavior and remove the cold fault properly in hardware.

I also tested all options under the GUI question “What is the supported USB Highest Speed?”, but none seemed to change the charging behavior.

Current USBCPD Tool Configuration Used to Generate Binary:
{
"device": "TPS25751",
"toolBuildVersion": "1.0.3",
"answers": [
null,
4,
4,
2,
1,
3,
2,
3,
1,
1,
1,
0,
0,
0,
16.8,
2,
0.12,
0.12,
0
],
"vendorId": "0000",
"productId": "0000",
"version": "1.0.0.2"
}

Could you please review the attached schematics for the battery charger and PD controller, and help me with the below questions ?

1. Schematics of the BQ25798 + TPS25751 setup – attached.

2. Whether any hardware limitations are causing the low charging current.

3. Correct software flow or recommended settings to enable higher current draw from a DCP/HVDCP adapter.

4. Whether the BQ is stuck in a fallback IINDPM limit (e.g., due to ILIM_HIZ pin).

5. Any mismatch between adapter type detection and actual current allowed.

Let me know if there’s anything else I should probe or measure to help narrow this down.

Thanks again for your support.

Regards,

Aditya 

Hi Aditya,

IINDPM and VINDPM are reported in REG0x1B.  Based on your I2C reads above, the charger is in fast charge and current is not being limited by either IINDPM or VINDPM.  The only other charge current reducing states are TREG, reported in REG0x1D, or TS WARM/COOL reported in REG0x1F.  Charge current regulation accuracy is very PCB layout dependent.  Does your PCB follow the recommended layout from the datasheet, especially the 0.1uF capacitors for SYS and PMID, circled in purple?

Regards,

Jeff

Hi Team,

Thank you for the clarification.

I’ve confirmed with our electronics team that the PCB layout follows the datasheet recommendations, including the placement of the 0.1µF capacitors for SYS and PMID (circled in purple). Additionally, the register values now appear correct:

• REG1D_Charger_Status_2 = 0x01 → VBAT_PRESENT_STAT

• REG1F_Charger_Status_4 = 0x00 → No thermal limit or TS WARM/COOL fault

To cross-verify the behavior, I attempted to charge the battery using the USB-PD-CHG-EVM-01 board. As mentioned earlier, I had written 0xFF to the EEPROM, so the PD controller is now in PTCH mode.

I reused the same patch download script (used successfully on our custom board) and confirmed that:

• The patch binary is the Low Region Binary

• The I2C download sequence completed without byte loss or corruption

However, with the EVM board, the patch process is failing at Step 10 as per the "Common TPS25751 Use Cases and Settings Using EC" document.

I’ve attached the I2C logs for your review. Could you please help evaluate what might be going wrong in this case?

Regards, 

Aditya

Hi Aditya,

If you are reading the value correctly, that return value indicates that the fw you are using is incompatible with the part. What GUI are you using to generate the image, and can you confirm the part being used?

Can you share the .C file and a full flash you generated, so that I can test the image you generated on hardware on my end?

Thanks and Regards,

Chris

Hello,

I’m using the USBPCD Application Tool v1.1.0 to generate the firmware image. I’ve selected TPS25751D and BQ25798 in the tool configuration. The EVM being used is USB-PD-CHG-EVM-01, though I'm not fully sure which specific part variant is mounted on it.

I’ve attached the .c source files:

• battery_charger.c: Full region binary source

• battery_charger1.c: Low region binary source

Unfortunately, I’m unable to upload the .bin files here may be due to platform limitations. Please let me know if there’s an alternate way I can share the generated binary files with you.

Also, I’d appreciate your help in understanding Table 8-6: Device Configuration using ADCIN1 and ADCIN2 (DEAD BATTERY CONFIGURATION) from the TPS25751 datasheet.

Specifically:

• Do the decoded values of ADCIN1 and ADCIN2 determine configurations such as AlwaysEnableSink, NegotiateHighVoltage, or SafeMode?

• Or are these ADC values only used for determining the I²C address of the device?

battery_charger.cbattery_charger1.c

Thanks again for your support.

Best regards,
Aditya

Hi Aditya,

Aditya Patil said:

• Do the decoded values of ADCIN1 and ADCIN2 determine configurations such as AlwaysEnableSink, NegotiateHighVoltage, or SafeMode?

• Or are these ADC values only used for determining the I²C address of the device?

They are used for setting both.

If you have the CHG-EVM, there should be a marking on the U4 IC. It may be difficult to see, but I have found magnifying glasses and taking pictures with a phone camera helpful. If the board has the TPS25750 (which is possible as the old version had the TPS25750, the update to TPS25751 only happened within the last couple months).

Thanks and Regards,

Chris

Hi Aditya,

Just to realign as this thread has been fairly busy recently, could you restate the core issue and the current state on it?

Did adjusting the TS resistors improve the stat behavior?

What is still missing on your custom board? I don't want to focus too much on the CHG-EVM, especially if it has the TPS25750.

Thanks and Regards,

Chris

Hi Chris,

Yes, we resolved the TS issue by adding a 10kΩ resistor in parallel, which corrected the STAT behavior. Thanks for pointing us in the right direction there.

You were also right—we realized the current EVM we have is populated with the TPS25750 instead of the TPS25751. We've placed an order for the correct EVM, but in the meantime, is it possible to replace the TPS25750 with a TPS25751 on the same board for evaluation?

Most issues seem resolved, and we’ll confirm once we receive and test with the correct PD controller.

Really appreciate all your support so far. Just let us know your thoughts on the controller swap, and we’ll consider this thread ready to close.

Regards,

Aditya