TPS25751: Discharging of PPHV Net During Fast USB PD Reconnects

Hi Brian, 

Thank you for reaching out!

I will look into this an get back to you with feedback early next week. 

Best Regards, 

Aya Khedr

Hi Aya,

Thank you very much! Have a great weekend!

Best,
Brian

Hi Brian, 

Are you configuring the BQ via MCU or using the integrated I2C support from the TPS25751? 

Best Regards, 

Aya Khedr

Hi Aya,

great timing as I'm just figuring out the capabilities to use the TPS25751 as a I²C proxy. Because I have the requirement to discharge the battery at 5.5 A to be able to provide the required power envelope for the buck boosting stage. And from what I know the BQ25792 is configured to limit to 5 A in source mode (REG14[4:3] IBAT_REG). Therefore, I have to temporarily remove the 5 A discharge clamp when in source mode.
At this time modifying this IBAT limit and transitioning the BQ into Shutdown Mode is the only dynamic BQ configuration by the MCU. I think to make this happen I have to disable the discharge current limit, right (`IBAT_REG` = disable)? BQ257929 specs allow up to 6 A continuous discharging (IBAT) but the discharge current limit (REG14[4:3] IBAT_REG) of max 5 A prevents this. Do you agree with this and the solution to temporarily disable the discharge 5 A limit?

If this is possible (which I think it is) then I will control the BQ25782 via the TPS25751D I²C proxy?
Can I have the TPS25751 BQ auto-configuration enabled while controlling the BQ using the MCU or must I e.g. select a No-BQ configuration in the USBCPD Application Customization Tool to prevent the TPS firmware from auto-programming the charger (and therefore move all configuration to the MCU)? 
Would the TPS25751 monitor BQ register changes if BQ auto-configuration is enabled or is the configuration fire-and-forget? (Because I don't want the TPS25751 to revert any dynamic configuration overrides)

Unless you say my concept is not feasible or recommended or you have a reason to suggest a direct MCU-->BQ2575922 I²C connection instead of the proxy solution, I will use the integrated I²C support.

Thanks for coming back!

Best regards,
Brian

Hi Brian, 

Thank you for sharing additional details on the BQ discharge. I will loop in a BQ expert to comment on the best method to achieve your requirements. 

Brian Sampoh said:

If this is possible (which I think it is) then I will control the BQ25782 via the TPS25751D I²C proxy?
Can I have the TPS25751 BQ auto-configuration enabled while controlling the BQ using the MCU or must I e.g. select a No-BQ configuration in the USBCPD Application Customization Tool to prevent the TPS firmware from auto-programming the charger (and therefore move all configuration to the MCU)? 
Would the TPS25751 monitor BQ register changes if BQ auto-configuration is enabled or is the configuration fire-and-forget? (Because I don't want the TPS25751 to revert any dynamic configuration overrides)

Your understanding is correct. You could select the BQ option in the GUI and still have additional writes/reads via MCU through the PD I2C lines. Unfortunately, the PD controller will not monitor these changes, therefore, it may override particular registers that the PD writes to. 

It is also possible to select No-BQ and have the MCU fully control the BQ but this may add complexity to your design. 

Have you evaluated our integrated solution to see if it meets your discharge requirements? 

From a PD perspective, what are your Source and Sink capabilities? 

Best Regards, 

Aya Khedr 

Hello Bran,

I'm reviewing your questions and will provide feedback as soon as I gather more information.

Best Regards,

Christian.

Hello Christian,

Thank you for your help!

Best regards,
Brian

Hi Aya,

thanks for your clarifications. I just makes sense but I had to make sure I really understood the I²C behavior and capabilities correctly. The datasheets are good compared to other devices and manufacturers. But sometimes nuances got missed.

I'm using the full PD capabilities. Sink and Source (APDO and PD) is 3.3 V - 20 V at ≤ 3.3 A where the power envelope for the Sink mode is ~26 W and for the Source mode 18.5 W after conversion losses (where the BQ25 actually sees 23 W). It's just a 1S battery system using a single 10 Ah Li-Ion battery (rated for max 1C or 10 A continuous discharge). The charging path sees 5 A.

USB PD Negotiation

To negotiate a Sink APDO the TPS25751D will not calculate the max power envelope as it does for fixed PDOs, right (it will ignore the power targets for APDOs)?

Assuming auto-negotiation being enabled, the TPS25751D will only check whether the recived  APDO is valid based on it's defined Sink APDO and then negotiate the raw PPSOutputVoltage/ PPSOperatingCurrent values? 

It also won't verify that the APDO is either more or less efficient than an availbale PDO candidate and would then prioritizes one over the other (it will always prioritite APDOs and only use PDOs as fallback)?

Therefore, if I want

• to maximize and optimize the power envelope or
• prefer higher voltage over higher current to improve efficiency or
• discard an APDO in favor of a more efficient PDO

I must implement this behavior on my MCU?
We would need a hybrid solution, where the TPS25751D autonomously validates the APDOs but then needs external aid to select the best option?

In this scenario the MCU would monitor the TPS25751D and after a successful or failed negotiation the MCU would read the NoCapabilityMismatch bit and if it return 1 I can let the MCU do the calculations and update the PPSOutputVoltage / PPSOperatingCurrent bits accordingly (which will trigger the TPS25751D to negotiate a new contract based on the updated values).

Could please tell me if my understanding is correct?

Because I can't find any configuration to control the primitive APDO auto-negotiate behavior or policies e.g. forcing higher voltage over higher current or to dynamically select the optimal voltage/current combination inside the advertised APDOs voltage range.
The User Guide is very explicit about the PDO negotiation policies and flow, even giving multiple examples, but kind of sparse on the APDO flow.
That's why I believe that the autonomous mode is not that usefull for the USB PPS part and requires a hybrid solution.

Sorry for asking so much. I will not add more context or questions to this thread. I think these topics are the only insecurities I have.

While the APDO Sink negotiation is more firmware related, where adding redundant functionality won't hurt that much, the PPHV discharging issue is purely hardware related where redundancy does hurt.
I could just add my own discharge path, but I'm already low on PCB space. Avoiding the extra discharge path for the bulk capacitance on the PHHV path would help a lot.

I hope I did not scare yu away with my long texts. Sorry for that!

Best regards,
Brian

Hello Brian,

Brian Sampoh said:

great timing as I'm just figuring out the capabilities to use the TPS25751 as a I²C proxy. Because I have the requirement to discharge the battery at 5.5 A to be able to provide the required power envelope for the buck boosting stage. And from what I know the BQ25792 is configured to limit to 5 A in source mode (REG14[4:3] IBAT_REG). Therefore, I have to temporarily remove the 5 A discharge clamp when in source mode.

I'm the apps engineer for the BQ25798, so I'm going to focus on the discharge issue, then reassign it back to Aya.

Just to clarify, you need REG0x14[3:4]=11?, Occuring to the I2C write commands sent by the PD controller. This should already be done. Can you confirm by ready the BQ25798 registers?

Best Regards,

Christian.

Hello Christian,

I hope you had a great weekend!

Christian Moyer said:

Just to clarify, you need REG0x14[3:4]=11?, Occuring to the I2C write commands sent by the PD controller. This should already be done. Can you confirm by ready the BQ25798 registers?

I have to apologize, but I'm not sure I understand your question correctly.

Yes, I need to write REG0x14[3:4]=11 via I²C in order to disable the discharge limit when in Source mode. This is to compensate BQ25798's internal conversion losses, which enables to source true 5 A (the BQ25792 would otherwise clamp at 5 A resulting in ~92 % losses from the advertised power budget). 

Please note, I'm using the BQ25792 and not the BQ25798. It doesn't matter in this context. I'm just clarifying because you were referring to the wrong BQ25798 device.

Hello Brian,

Brian Sampoh said:

Please note, I'm using the BQ25792 and not the BQ25798. It doesn't matter in this context. I'm just clarifying because you were referring to the wrong BQ25798 device.

Thanks for the clarification, this should not make a difference since they have the registers.

Brian Sampoh said:

Yes, I need to write REG0x14[3:4]=11 via I²C in order to disable the discharge limit when in Source mode. This is to compensate BQ25798's internal conversion losses, which enables to source true 5 A (the BQ25792 would otherwise clamp at 5 A resulting in ~92 % losses from the advertised power budget). 

When you program the TPS25751 in the online GUI to support the BQ25792. The GUI generates a list of I2C writes that are written to the BQ25792 upon startup. One of the writes is to register REG0x14=9C. This should set the REG0x14[3:4]=11. So there should be no reason for you to set these bits, this should be done by default.

I want you to read the  REG0x14[3:4]=11 of the BQ25792 to confirm this has been done by default.

Best Regards,

Christian.

Oh, now I understand. Sorry. The idea was to keep the limit in place during Sink mode and only lift it during Source mode. Maybe this doesn't make sense? It's just a safety guard which is good to have and in Sink mode I'm fine with limiting discharge to 5 A (or even 3 A). Just want to dynamically (and temporarily) remove the limit to allow discharging up to 6 A (the battery happily allows that and  the BQ25792 too).

Christian Moyer said:

When you program the TPS25751 in the online GUI to support the BQ25792. The GUI generates a list of I2C writes that are written to the BQ25792 upon startup. One of the writes is to register REG0x14=9C. This should set the REG0x14[3:4]=11. So there should be no reason for you to set these bits, this should be done by default.

Are you telling me that my general understanding is wrong and therfore my idesign won't work? 
I think you are right and that the discharge current limit with the TPS25751 as front-end is redundant. On SYS side we have hardware layer current limiters in the buck-boost converters that provide the power rails. And  the MCU is already monitoring the current to add another software layer of protection to the application. You are right. The extra complexity of managing the discharge limit can be safely avoided. Yes, 0x9C disables the diacharge current limit by default.

Thanks for pointing this out!

May I also ask you to answer my original questions, please?

Brian Sampoh said:

• Is it correct that the internal discharge path of  the TPS257751D only discharges the VBUS side capacitance and not the PPHV side (basically the full internal VBUS <--> PPHV path) i.e. should we implement an external discharge path for the PPHV net instead? I would expect that the discharge path affects the full internal VBUS <--> PPHV path. But I have doubts as I also expect that PPHV is isolated from VBUS during the event when discharging must take place (between reconnects, during the disconnected state).
• Can you please clarify the behavior in terms of PPHV  management and overvoltage/overcurrent protection? Because in my understanding PPHV gets isolated during reconnects (cable and protocol level reconnects). Which mean the capacitor bank on PPHV will hold its voltage. Given the previous example and PPHV getting reattached to the power path after succesfull negotiation, will this trigger overvoltage/overcurrent protection of the TPS25751D (which now sees 20 V on a path configured for 3.3 V) and interrupt the PD delivery? This queustion is answered if the internal discharge path also discharges the PPHV side of the power path.

Best,
Brian

Hello Brian,

No, I still don't think you understand.

• You want to set REG0x14[3:4]=11 on the BQ25792 to allow discharging up to 6 A
• The TPS25751D writes REG0x14=9C to BQ25792 automatically (REG0x14[3:4]=11).
• This means there is no reason for you to write REG0x14[3:4]=11, because the TPS25751 should do this automatically.

Can you confirm that the TPS25751D is writing  REG0x14[3:4]=11 to BQ25792?

Best Regards,

Christian.

Hello Christian,

I really appreciate your patience — and I’m sorry if I made things frustrating on your side.

I think I have understood you very well so far. Let me summarize my understanding and my intentions so that you can correct it where you believe it is wrong:

1. In general, writing REG0x14[3:4]=11 disables the discharge limit
2. Discharge limit is disabled by default when selecting BQ25790, BQ25792 or BQ25798 in the Application Customization Tool because the firmware writes 0x9C to the register which consequently sets bits 4 and 3
3. You imply that changing the configuration dynamically is not needed

My original plan was a dynamic discharge limit control:

1. Explicitly enable discharge limit and set it to 5 A (or 3 A) during charging (Sink mode) or when VBUS is absent 
2. Explicitly disable discharge limit when transitioning to Source mode to enable discharging at > 5 A.
   
   

In this original context the firmware default doesn't matter as I would have to overwrite it in the wake of dynamic limit control based on the current role.

To clarify: the need to set REG0x14[3:4]=11 was based on the dynamic limit control and not on misconfiguration where the firmware defaults don't get applied properly.

I was then thinking about why your firmware disables the discharge limit by default (overriding the register default, which is a 5 A limit) and came to the conclusion that leaving the discharge limit disable for all operation modes (static) is pretty much acceptable.

I think the expectation for the autonomous mode is that the application (e.g. MCU) will not or must not interact with the BQ25792 other than reading data (at least configuration is not expected, hence the GUI does not offer related access).

Still I wonder why the EN_BATOC bit is not set by default. Maybe because this feature would require direct access to the BQ25792 and the autonomous design goal was to actively hide the BQ25792 details from the application. Just a guess.

This is what I understood and I politely ask you to correct me so that I can learn and we get on the same page. I sadly can't validate that your GUI tool generates the firmware correctly as I can't test such firmware details it at this time. I'm designing the hardware level of the prototype hence my original question about the scope of the discharge path.

By the way, is there a way to learn what defaults the firmware applies to the BQ25792?
And will the TPS25751 firmware (in autonomous mode) keep the watchdog of the BQ25792 alive?

Best,
Brian

Hello Brian,

Brian Sampoh said:

I think I have understood you very well so far. Let me summarize my understanding and my intentions so that you can correct it where you believe it is wrong:

1. In general, writing REG0x14[3:4]=11 disables the discharge limit
2. Discharge limit is disabled by default when selecting BQ25790, BQ25792 or BQ25798 in the Application Customization Tool because the firmware writes 0x9C to the register which consequently sets bits 4 and 3
3. You imply that changing the configuration dynamically is not needed

Yes, This is correct.

Brian Sampoh said:

And will the TPS25751 firmware (in autonomous mode) keep the watchdog of the BQ25792 alive?

Yes, The TPS25751 disables the watchdog timer.

Brian Sampoh said:

Would the TPS25751 monitor BQ register changes if BQ auto-configuration is enabled or is the configuration fire-and-forget?

The writes are fire and forget, it does not monitor BQ registers, so if you wait till after the TPS25751 writes to the BQ device, then set the values you want using the MCU, then it should be fine. The TPS25751 should only write to REG0x14 during first power up.

Brian Sampoh said:

By the way, is there a way to learn what defaults the firmware applies to the BQ25792?

I'm not sure if this is something that the TPS25751 team shares.

Please let me know if you have any question related to BQ25798, if not, I will reassign to aya.

Best Regards,

Christian

Hello Christian,

Thanks for your time and help. You have shared some very useful information.
 

Best regards,
Brian

TI USA is on holiday, please expect delays in response