TPS25751: TPS25751: Patching from host controller: patch bundle is accepted and MODE remains PTCH instead of APP

Hi Carson, 

is the PD controller booting up from dead battery mode (VBUS comes up first instead of VIN_3V3)? If it's booting up from dead battery mode without the EC first clearing the DB flag, TPS25751 will power off once VBUS is removed even if 3.3V is present on VIN_3V3. When TPS25751 loses power it'll boot back up in PTCH mode again. 

Thanks and Regards,

Raymond Lin

Hi Raymond,
Thanks for your reply. Yes you are right PD booting up with dead battery mode. I try to clear the DB flag seems failed.
Can't that DB flag be cleared in PTCH mode?

[10:15:00.764]send→◇51 01 00 2D 05 □
[10:15:00.787]send←◆51 01 01 2D 05 34 03 62 02 C1
[10:15:06.985]send→◇51 01 00 26 05 □
[10:15:07.008]send←◆51 01 01 26 05 00 30 00 00 80
[10:15:10.580]send→◇51 02 00 08 04 44 42 66 67 □    （send DBfg to 0x08）
[10:15:11.114]send←◆51 02 01 08 04 00 00 00 00          (read from 0x08, 00 00 00 00 means excute DBfg completely, right ?)
[10:15:14.705]send→◇51 01 00 2D 05 □
[10:15:14.730]send←◆51 01 01 2D 05 34 03 62 02 C1
[10:15:17.577]send→◇51 01 00 26 05 □
[10:15:17.600]send←◆51 01 01 26 05 00 30 00 00 80

Raymond,

Seems that booting up with dead battery mode isn't the root cause to this issue.

Linked a battery without VBUS the 0x2D reg display as below:
[15:04:20.599]send→◇51 01 00 2D 05 □
[15:04:20.621]recv←◆51 01 01 2D 05 30 03 60 02 C1  

After patch loaded successfully from I2c still return back to PTCH from APP.

Hi Carson, 

DBfg can only be executed once TPS25751 enters APP mode, here is the flow for PBMx in a dead battery scenario (VBUS providing power to TPS25751): 

1. TPS25751 powers on through VBUS (DB flag is raised)

2. TPS25751 alerts EC through INT that it is ready for patch to be loaded

3. EC loads config via PBMx flow (check mode -> set up and send PBMs -> write binary config -> send PBMc -> check if config is loaded properly -> PBMe once process is complete) 

4. After TPS25751 enters APP mode, EC needs to send 'DBfg' in order to clear dead battery flag 

5. At this point after the DB flag is cleared and a steady 3.3V is provided to TPS25751 VIN_3V3 pin, TPS25751 is now powered from VIN_3V3 instead of VBUS. Removing the source connector at this point will not power off TPS25751. 

Can you try the process mentioned above and see if the behavior improves? In addition can you also provide a detailed summary of the boot-flow process that is currently implemented in the system? 

Thanks and Regards,
Raymond Lin

Thanks Raymond, we will have a try according to you detailed instruction.

One more question:

(check mode -> set up and send PBMs -> write binary config -> send PBMc -> check if config is loaded properly -> PBMe once process is complete) 

In this workflow, check the config if it is loaded properly, does the EC still need to trigger one 'PBMe' to TPS?

TRM mentioned that execute 'PBMe' only when the workflow in exception scenarios.

Table 4-14. 'PBMe' - Patch Burst Mode Exit
Description The 'PBMe' Task ends the patch loading sequence. This Task instructs the PD controller to complete the patch
loading process.
INPUT
DATAX None
OUTPUT
DATAX Byte 1: Standard Task Return Code.
Task
Completion
The 'PBMe' Task completes after it has ended the patch loading sequence. If MODE register (0x03) is equal to 'APP ', then
this Task will be rejected.
Side Effects When the 'PBMe' is successful, the second target address will be restored to the value configured by the ADCINx pins. The
PD controller leaves the MODE register (0x03) as 'PTCH' and will wait for the patching process to restart.
Additional
Information If the MODE register is 'APP ' indicating that the PD controller is in the APP mode, then it will reject the 'PBMe' Task.

Hi Carson, 

Apologies for the confusion, 'PBMc' is only used for error recovery during the PBMx flow if something fails. Once the patch is loaded successfully (mode=APP) you do not need to send 'PBMe'. 

Thanks and Regards,

Raymond Lin

Hi Raymond, thanks for your clarify.
Seems no any progress and still back to PTCH.

boot-flow:

1. ADCIN1: value 5 means #2. ADCIN2: value 5 means #2. 
2. Removal J16, once power on,  PD could't load any configuration from EEPROM and will enter PTCH mode.
3. Power on J3. Boot flag register: 05 30 03 60 02 C1
4. Update patch via IIC. Once become app mode. execute 'DBfg' 

Hi Carson, 

Can you capture I2C logs starting at the beginning when reading the PD mode (APP/PTCH), performing PBMx sequence and all the way to the ending of completing PBMx, reading the mode, and executing DBfg? 

carson yu said:

1. ADCIN1: value 5 means #2. ADCIN2: value 5 means #2. 
2. Removal J16, once power on,  PD could't load any configuration from EEPROM and will enter PTCH mode.
3. Power on J3. Boot flag register: 05 30 03 60 02 C1
4. Update patch via IIC. Once become app mode. execute 'DBfg' 

I assume after step 4 of executing DBfg is when the EC reads back PTCH mode from the PD? 

Thanks and Regards,

Raymond Lin