USB-PD-CHG-EVM-01: USB-PD-CHG-EVM-01-Different Current Results with Different Adapters

Hi L,

Can you share the .json you are using? I can't retrieve config settings from the bin file.

How are you testing this system? Are the batteries fully charged? Are you keeping them in the fast charge window of the charge profile? If you get too close to the max battery/charge voltage, the charger may hit the termination current window and limit charging speed.

Do you have the ability to capture USB-C PD logs?

If yes, please provide a PD log of all 3 adapters at 20-V contracts

Do you have a way to read registers from the PD controller?

If yes, please read and report the active RDO register on the PD controller

Can you sniff I2C?

If yes, please read and report the I2C communication between the PD controller and BQ device when each adapter is plugged in (for the 20-V case).

Thanks and Regards,

Chris

Hi L,

I removed the previous responses and we can continue correspondence here. If you need to share anything confidential, we can share it through the "private message" function of E2E

Here is a summary of what is missing:

Testing process: Windows platform writes bin via FT232H, after writing battery is reinserted to make sure PD reads newly flashed settings. During charging, a USB ammeter is used to observe current, setup is left idle for 10-15 seconds.

Battery voltage is around 6.9V during testing, battery model is INR21700M50T.

Main difference between JSON are sink voltage and charging current values. Chart was generated by same CHG-EVM, only difference being the charger.

Current measurement is taken at the charger.

Thanks and Regards,

Chris

Hi L,

From the chart, the projects do appear to be working properly, and it seems like you are having issues with specific charger. With the clarification that the measured current is from the wall adapter (not the charge current), it does appear like you are drawing current and voltages respective of the settings in the project. This is primarily seen in the data from the first wall adapter (Apple 61W)

For the other two, is the 20-V contract negotiating properly? I see you can only draw .08-A or it is only drawing load at .08-A. Can you measure the VBUS voltage and report it's exact value? Do you see a stable VBUS, or do you see any disconnecting? It seems like you do see the 20-V contract working properly in one case, but not for the other adapters, so we need to determine how/why the behavior is different for those adapters.

Sniffing I2C will allow us to see if the PD controller is programming the BQ to limit input or charge current, which would limit the input type-C current.

Reading registers over I2C could provide information on the PD contract negotiated and confirm or deny if the issue is adapter related.

A PD log provides similar information to the registers.

Thanks and Regards,

Chris

Hi Chris

Thank you very much for your help, and I sincerely apologize for any inconvenience caused by my carelessness.

Regarding the VBUS you mentioned, are you referring to the VBUS pin on the RQ25798 , or the VBUS pin on the 25751?
If it is the VBUS from the RQ25798, the voltage I measured at TP1 is approximately 20V.
However, if it is the VBUS pin on the 25751, the circuit diagram does not show any pin for measurement.

Below is a photo showing the USB voltage and current readings during charging.

As for the other methods(I2C signal) , my colleagues and I are already working on how to proceed with the operation and analysis.

Today is our last working day before the holiday, so if you reply, we will not be able to see your message until after February 3rd

Thanks and best Regards

L

HI L,

The BQ25798 VBUS and the USB Voltage should be enough, the USB voltage should reflect VBUS on the TPS25751.

Thanks, looking forward to the I2C results.

To outline the system, where things might break down, and what we are looking for:

On boot, the PD controller will program some initial configuration values to the BQ device like charge current, term current, and some operating configuration.

When a sink contract is negotiated on the PD port, the PD controller should program some information regarding the input current limit that should reflect the negotiated contract on the PD port. There may be a couple reasons why things are failing:

1. The PD contract is not negotiating full power -> check the active RDO register on the PD controller to see what current was negotiated

2. The PD controller did not program the right charge current or input current to the BQ and the BQ is limiting power draw -> check I2C traffic between ICs during connection to adapter to confirm

3. other reasons may include, battery is fully charged, issue with adapter and limiting power draw

Thanks and Regards,

Chris

Hi Chris

Thank you for explaining the workflow between the PD controller and the BQ device, as well as the key points to check.

I currently have a few questions that I would like to ask:

1. Can the I2C signals between the PD controller and the BQ device be captured through J5 or J7?
   Today, I obtained a logic analyzer: Saleae Logic16, and I used the Logic 2 software to capture some signals. These signals were collected from Pin 1 and Pin 3 of J5. I have attached the captured data for reference.

   PD and BQ i2c.zip
   
   

2. A colleague suggested another approach: capturing CC1/CC2 signals using Saleae Logic16 for decoding. I have seen some relevant discussions about this extension on the Saleae forum, but I am not sure if you have any experience with this method.

3. Regarding reading the RDO register, I am using an Aardvark along with the official Control Center software, but I am not getting any response. I believe I might be doing something wrong. Do you have any recommended forum posts I can refer to, or could you share your experience with this?

Thanks and best Regards

L

Hi L,

L MX said:

Can the I2C signals between the PD controller and the BQ device be captured through J5 or J7?

From the schematic, the two look connected and have the same signals, so either should be good.

For reference, all of the writes to address 0x6B are writes to the battery charger from the PD controller. I'm a bit concerned about the logs you have shared with me. I only expect I2C writes on that bus to addresses 0x50(EEPROM) or 0x6B(BQ device). 

• All of them have some writes to 0x00 and stuff that looks like noise. I'm a little hesitant to provide too much feedback on these logs as I'm not sure if they are correct, but here are some comments
  • APPLE 61W - There do seem to be some writes to 0x6B, which is good. Still a lot of random looking writes.
  • Apple 67W - I see some writes to 0x6B which is good, but a lot of other writes as well. There is a write to the IINDPM register that looks too large, and may be causing issues.
  • Gan_65W - Nothing conclusive here
• Could you try retaking the captures to see if they can be improved in any way?
  • Could you also add a capture of VBUS during this time? If you are going up to 20-V, you might want to halve the signal. This will help with understanding plug timing
• I attached an example log from the CHG-EVM. It looks cleaner with only writes to 0x50 and 0x6B and captures the power up I2C sequence of the EVM.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/Example-Power-up.sal

Also, could you re-share the json? I deleted it earlier in the thread and forgot to save it.

L MX said:

A colleague suggested another approach: capturing CC1/CC2 signals using Saleae Logic16 for decoding. I have seen some relevant discussions about this extension on the Saleae forum, but I am not sure if you have any experience with this method.

I have not used the Saleae CC-line decoder in the past, so cannot comment here. It may be worth trying, but I am not sure how good the tool is.

L MX said:

Regarding reading the RDO register, I am using an Aardvark along with the official Control Center software, but I am not getting any response. I believe I might be doing something wrong. Do you have any recommended forum posts I can refer to, or could you share your experience with this?

For I2C reading from the PD controller, you need to connect to the I2Ct pins, which come from the J3 jumper.

See the TPS25751 TRM section 1.3.1 for specifics on the I2Cw and I2Cr format.

Here is an example of what an I2Cw and I2Crmight look like from the Control Center view.

Make sure you have the correct slave Address set. It should be 0x21

when you use the I2Cr, the second byte is the num data bytes, so if you want to read a register with data size 4, you need to set the "Number of Data Bytes" in control center to 5 (data byte + data size).

Thanks and Regards,

Chris

Hi Chris

Thank you for providing the example and the explanation for using Aardvark. I will provide the JSON again.

4745.json.zip

I’ve reviewed the example you provided, and there seems to be a significant difference in the results for both SDA and SCL. It might be that there’s an issue with the way the capture was performed.

I will reattempt the signal capture. Just to clarify, here’s the process I followed during the first I2C signal capture:

1. Opened Logic2 software and started the capture.
2. Waited for 2-3 seconds before powering on the adapter.
3. After about 7 seconds, I stopped the capture (while the adapter remained power on).

Could you let me know if you think any adjustments are needed to this process? If so, I will apply them during the next capture.

I will continue working on the VBUS and RDO measurements as well, but it may take a few more days.

Thank you again for your assistance!

Thanks and best Regards

L

And I performed a simple additional test with the TPS25730EVM today.

The settings were as follows:

• Minimum voltage: 5V
• Maximum voltage: 20V
• Operating current: 1.5A
• Maximum current: 3A

The electronic load was set to CRH mode with a resistance of 10Ω.

As a result, the system operated normally.

Hi Chris

Thank you for your setup suggestions. I followed the first and third recommendations and made the adjustments accordingly. The final current value now matches expectations, and everything seems to be functioning normally.

However, I have a question I’d like to clarify:

If the issue was due to the 20V->3A current being too close to the BQ25798’s maximum limit, causing the register write to fail, why is it that changing to 60W (20V) allows the write to succeed, but 100W (20V) results in failure? Is it because the theoretical maximum current for 60W (20V) is 3A (60W / 20V), and even with IINDPM set to 5%, it will never exceed 3.3A, which is why the write succeeds?

If that’s the case, then when selecting 100W (20V), IINDPM is set to 0%, and it should also succeed. How should we understand this behavior?

I’m sharing the updated JSON files: one for 60W (20V) / IINDPM -5%, and another for 100W (20V) / IINDPM 0%

update json.zip


Thanks and best Regards

L

Hi Chris

I checked the advanced settings (Transmit Sink Capabilities) for both 100W (INDPM 0%) and 100W (INDPM 5%), and I found that Sink PDO4 is set to 5A by default.I have never changed this setting.

Does this mean that even if my charger and battery support higher power(ex 100W、140W、240W), the USB-PD-CHG-EVM-01 cannot sink 5A (100W/20V) and is limited to 3A (60W/20V) due to the BQ25798’s maximum input current of 3.3A?

I will continue running additional experiments and will post again if I encounter any further issues.

Thank you for your detailed explanations and assistance over the past few days!

Thanks and best Regards

L