TPS25750: IIN Current regulation configuration sent to BQ25730/25731 is wrong

Hi Richard,

Can you share the GUI and json file you are using?

Could you also share a schematic or block diagram showing the I2C connections between the PD, BQ, and any other parts in the system connected over I2C?

If you are using the GUI with one of the BQ devices selected in the questionnaire, it will automatically configure the BQ device over I2C and does assume you are using the default/recommended current sense resistors.

Please provide a link to the GUI and JSON and I can take a closer look.

What is likely happening (but I will need to confirm with the JSON you are using) is that on negotiation of a PD contract, the TPS25750 will update the BQ register for IIN_HOST if they are connected over I2C. There are two options here.

1. Update the json to program the current assuming a 10-mohm sense resistor is there.

2. Remove the I2C write and assume another device will configure the BQ part properly.

Let me know which one you prefer.

Thanks and Regards,

Chris

Hi Chris,

Thank you for your answer. We don't generate the binary ourselves, because of a bug found in the TPS 25750 GUI release. You can find details there : TPS25750: I2C Transaction suddenly stops when plugging USB-C PD HUB adapter.

Here is our json :

{"questionnaire":{"version":"7.0.4.7","answers":[0,0,3,1,1,1,1,null,1,null,2,12.6,3.072,null,null],"options":{},"configID":"0000","vendorID":"0000"},"configuration":{"data":{"selected_ace":[{"register":6,"data":[4,0,0,0,0,0,0,0]},{"register":22,"data":[0,0,0,0,0,0,0,0,0,0,3]},{"register":50,"data":[1,168,42,44,145,1,38,44,209,2,0,44,177,4,0,244,65,6,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"register":51,"data":[4,44,145,1,16,44,209,2,0,44,177,4,0,44,65,6,0,69,65,6,0,0,0,0,0,0,0,0,0]},{"register":92,"data":[1,4,0,0,0,0,0,0,0,0,0,0,0,4,0,0,0,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,75,0,0,0,0,0,0,0,0,0,0,0,0]},{"register":117,"data":[0,0,0,0]}]}}}

Basically, our schematics is our SOM <-- I2Cs --> TPS25750 <-- I2Cm --> BQ25730

I concur with your supposition, this is the behavior I see when I run my tests. When I unplug the adapter, the IIN register resets to 3250mA as it should, then when I plug it back, the TPS rewrite it, assuming we are using the default/recommended current sense resistors. So it's set at 1500mA because the LSB is computed for 100mA step instead of 50mA.

Your first option is a nice and a cleaner option, that way we could keep the already implemented I²C write at the correct timing, but can we really do that in the json ? I guess the second option could give us more flexibility if we needed to change the current limitation value on the go, but I see no case where we would need to do that.

So I would be up to try the first option for now and see if it works and how.

Thank you for your reactivity,

Best regards,

Richard

Hi Richard,

I'm unfamiliar with the thread you shared, I'll need to reach out to Christian and Rohit to see what the fix was.

For now, please try these files:

/cfs-file/__key/communityserver-discussions-components-files/196/6A_5F00_ChargeCurrent.json

/cfs-file/__key/communityserver-discussions-components-files/196/6A_5F00_ChargeCurrent.bin

/cfs-file/__key/communityserver-discussions-components-files/196/6A_5F00_ChargeCurrent_5F00_FullFlash.bin

Attached are a JSON, low region, and full flash with the Charge current write updated to "6-A", which should be 3-A for your updated sense resistors.

Thanks and Regards,
Chris

Hi Chris,

Sorry for the late response, I was super busy on another subject this week.

I just reviewed and tested your patch. I can see in the json config there are a lot more registers than a standard generated config. What did you add ?

I noticed you increased the Battery charge current to 6A. That is a good idea, this can probably fool the TPS into writing the correct value for our new sense resistors. If this can work, that's a wonderful fix for us. Please note that we rewrite the charge_current register (0x02) every 30 seconds to keep the safety charge watchdog running. I don't think this can cause any problem, but I want to say it, just in case it causes side effects we don't know about.

I flashed the binary into our eeprom, rebooted and read the current through our BQ adc_ibat register (0x28/0x29). While in the "constant current"charge zone of the battery, it still doesn't seem to go over 1920mA and I still can read 1500mA into the iin_host register (0x0e), exactly same as before. Do you have another config for us to try ?

Can you also generate for me this config (full flash and low region), it's basically my last one with simply the charge current doubled, and the custuse word register increased (we use it to keep version of our binary).

{"questionnaire":{"version":"7.0.4.7","answers":[0,0,3,1,1,1,1,null,1,null,2,12.6,6.144,null,null],"options":{},"configID":"0000","vendorID":"0000"},"configuration":{"data":{"selected_ace":[{"register":6,"data":[5,0,0,0,0,0,0,0]},{"register":22,"data":[0,0,0,0,0,0,0,0,0,0,3]},{"register":50,"data":[1,168,42,44,145,1,38,44,209,2,0,44,177,4,0,244,65,6,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"register":51,"data":[4,44,145,1,16,44,209,2,0,44,177,4,0,44,65,6,0,69,65,6,0,0,0,0,0,0,0,0,0]},{"register":92,"data":[1,4,0,0,0,0,0,0,0,0,0,0,0,4,0,0,0,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,75,0,0,0,0,0,0,0,0,0,0,0,0]},{"register":117,"data":[0,0,0,0]}]}}}

I also noticed the USBCPD Application Customization Tool is now 0.6.0. Do you have an estimate when we will be able to use it with all the fixes found for the TPS25750 and hence stop bothering you when we when to test small config changes ?

Thanks and regards

Richard

Hi Field and Chris,

I come back to you. Did you have some time to read my last message ?

(sorry I resolved the issue by misclick.)

Thanks and regards,

Richard

Hi Richard,

Thanks for the ping, let me take a look and I'll get back to you early next week.

Richard TAUPIAC said:

I flashed the binary into our eeprom, rebooted and read the current through our BQ adc_ibat register (0x28/0x29). While in the "constant current"charge zone of the battery, it still doesn't seem to go over 1920mA and I still can read 1500mA into the iin_host register (0x0e), exactly same as before. Do you have another config for us to try ?

I need to look this over, there are a couple registers we may need to configure.

Richard TAUPIAC said:

I just reviewed and tested your patch. I can see in the json config there are a lot more registers than a standard generated config. What did you add ?

I just changed some of the BQ I2C write values.

Here are the binaries for your JSON file.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/6A_5F00_5F00_5F00_ChargeCurrent_5F00_V2_5F00_FullFlash.bin

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/6A_5F00_5F00_5F00_ChargeCurrent_5F00_V2_5F00_LowRegion.bin

Richard TAUPIAC said:

I also noticed the USBCPD Application Customization Tool is now 0.6.0. Do you have an estimate when we will be able to use it with all the fixes found for the TPS25750 and hence stop bothering you when we when to test small config changes ?

You should be able to start using it now, but I'm not sure when it will be "ready". Some fixes have already been added, but the main focus for the latest release of the GUI was for the TPS25751(successor part).

Thanks and Regards,

Chris 

Hi Chris,

Thank you ! I tried with the USBCPD 0.6.0 tool, it still generates a binary containing the bug we reported here, so we cannot use it yet.

The binaries from the config I requested don't seem to work neither, because when I'm plugged, I still can read 1500mA in the IIN_DPM register. So just changing the charging current in the TPS questionnaire isn't enough.

I still think this is a good idea to solve our problem, but we need a way to have the fix of our I²C bug + the registers you rewrote to set the charge current and limit at 6A so it becomes 3A with our RSNS config.

Thank you for your time,

Best regards,

Richard

Hi Chris,

Using the binary you just sent me, here what I read in the register 0x0F:

• When the USB-C power supply is plugged to the TPS25750 : 0x1E
• When the USB-C power supply is NOT plugged to the TPS25750 : 0x41

0x1E gives an interpreted value of 1500mA. This is my problem.
0x41 gives an interpreted value of 3250mA. This is what I would expect all the time.

Interpretation is following the datasheet : 50-mA resolution and 50-mA offset only applied at code 0.
Of course I disabled everything in my code that could change the value, so this is only what the TPS writes into the BQ.

Strangely enough, I can see a charging current up to 1920mA with the 1500mA IIN_HOST setting, but not sure this is relevant to our problem.

Indeed, having a parameter in the questionnaire to choose between 5mOhms and 10mOhms sensing resistors would be a really good thing to have.

Hoping my answer will help you,
Thanks and regards,
Richard

Hi Richard,

Richard TAUPIAC said:

Strangely enough, I can see a charging current up to 1920mA with the 1500mA IIN_HOST setting, but not sure this is relevant to our problem.

Charging current is separate from IIN_HOST, so this could be possible. The IIN_HOST sets the input current, so effectively limits the charging power that can be drawn.

Richard TAUPIAC said:

Using the binary you just sent me, here what I read in the register 0x0F:

• When the USB-C power supply is plugged to the TPS25750 : 0x1E
• When the USB-C power supply is NOT plugged to the TPS25750 : 0x41

0x1E gives an interpreted value of 1500mA. This is my problem.
0x41 gives an interpreted value of 3250mA. This is what I would expect all the time.

Does this behavior repeat when you plug and unplug the device? Would it be possible to capture I2C logs? The latest project should have been configured to program a value of 3F to register 0x0F on boot, so I'm surprised by (1) the fact that is is 0x1E when plugged and (2) it is 0x41, not 0x3F.

Thanks and Regards,

Chris

Hi Chris,

This behavior has a 100% repeatability.
Please find below the capture of the I2Cm bus between the TPS and the BQ
- on plug event:

reg 0x0F - data 0x1E
reg 0x0A - data 0x40 0x06
reg 0x0F - data 0x1E
reg 0x0A - data 0x40 0x3C

- on unplug event:

reg 0x35 - data 0x17

Additional info, if this can help: during my tests, I did comparative captures with our previous config and noticed on plug events the traces are really different. Instead of 2 writes of 2 registers separated by a few hundreds of µs, previous binary was writing 7 registers in a row (I don't join the screen captures to keep my answer light):
reg 0x02 - data 0x00 0x06
reg 0x00 - data 0x0A 0x05
reg 0x35 - data 0x17
reg 0x32 - data 0x37
reg 0x02 - data 0x00 0x06
reg 0x0F - data 0x1E
reg 0x0A - data 0x0x40 0x3C

Also, having the register 0x0F back to 0x41 on USB-C adapter removal is normal, reading the BQ25730 datasheet, "the input current limit is reset to the default value of 3.25 A.".

Does it work on your side? What should I expect to see? Do I have a problem on my board ?

Thanks and regards,

Richard

Hi Richard,

it just came to my attention that the I2C events for Sink behavior are baked into the firmware and require the 5mOhm resistor. The Source events are more configurable and can be updated in the GUI/.json, but the sink events have functionality that is not configurable through the GUI/.json.

Richard TAUPIAC said:

Does it work on your side? What should I expect to see? Do I have a problem on my board ?

I don't think there is a problem with your board. I was able to test it recently, and the message I added "works", but is immediately overwritten. 

The 0x0F 0x3C write was the fix added, but it get immediately overwritten by the 0x0F 0x1E write.

I tried a couple different writes to see if I could find a timing that overwrites the 0x0F 0x1E write, but the TPS25750 does not currently have any events that would fix this.

At this time, the team is not planning any major updates the the TPS25750 code, and it is unlikely that they will make an update to accommodate for the changed sense resistor..

The two options I can think of now are:

1. stick with the required 5mOhm sense resistors

3. Swap over to the TPS25751 (p2p, register, and feature compatible. Requires making a new JSON (very similar, but has small differences)

Apologies for the confusion here, and thanks for your patience with the debugging.

Thanks and Regards,

Chris