Can CCG3PA be able to Disable PD communication, but still Use Rd pull down like type c functionalities ?

[BhargavGolla]

Hi cypress,

I am using CCG3PA as a sink for implementing  QC 3.0 functionalities where when I use QC 4.0+  which are backward compatible it is automatically starting PD Contract. I need to stop PD contract from happening and in the same time  i need  Rd pull up functionalities to achieve QC 3.0 functionalities. I  have used dpm_pe_stop() to stop PD protocol, as its description in the API guide  says   'This function stops the policy engine, used in fault scenario where in PD protocol need to be stopped but type c manager still runs'. It didn't worked  for me  where i connected DUT and passes API which has this function, is there any function which will fulfill my requirement   , how can I Disable PD communication and have Type c capabilities...??

Regards

@BhargavGolla

[Wang_Fred]

typec_assert_rd() should be called to manually assert Rd;

dpm_pe_stop() should be the correct one to disable PD protocol.

Can you please provide more details on how it didn't work? PD policy still working, or Rd not asserted any more?

[BhargavGolla]

Hi wang_fred,

so the procedure i am following is ,

i have connected DUT to the  CCG3PA, over I2C interface i am sending  API which execute dpm_pe_stop and in between ccg3pa and dut i have connected PD sniffer to see the vbus.  

1. After  executes dpm_pe_stop command there is no detach or vbus drop.

2. Is above way is correct way of execution ?

3. what is expected behaviour on the vbus when dpm_pe_stop command is passes to ccg3pa like how we know pd is  not happening. after passing the command if i detach and attach DUT in sniffer i am observing PD- negotiation being successful.

4. suggest me procedure for using this function for making PD negotiation fail when attach is observed.

below are the sniffer captures after and before passing the api. 

both the times PD contract has successfully  happened

[Wang_Fred]

5V VBUS would not be dropped though only type-c capabilities existing.

Note from your PD capture that there are 2 separate PD negotiation accomplished. Is there a unplug and re-plug between timestamp 27's and 48's? How did you recognized the PD contract always there along the whole timeline?

How could the 'over I2C interface i am sending  API which execute dpm_pe_stop' implement? That means the CCG3PA FW is triggered to execute the dpm_pe_stop upon a specified message is received from I2C master?

[BhargavGolla]

1.  In PD capture  those 2 successful  PD negotiation is due to unplug  and re-plug events which is the way i am getting to know that PD negotiation is happening successfully  even though passing dpm_pe_stop() command . 

2. I am passing api through Bridge control utility over I2C interface to execute dpm_pe_stop() command.

3. what is expected behavior on the vbus when dpm_pe_stop command is passes to ccg3pa like how we know pd is  not happening  ?

4. suggest me procedure for using this function for making PD negotiation fail when attach is observed

let me reiterate again

i am using qualcomm quick charge 4+ dut which is backward compatible , so i am testing QC 3.0 spec using this DUT, where CCG3PA is my sink, But while connecting this DUT PD negotiation is happening successfully where i need to stop it in order to test  QC 3.0 spec using This DUT.

so I am passing dpm_pe_stop() command to stop PD negotiation inorder to test QC 3.0 spec.

i am passing this command using Bridge control utility over i2c interface which passes api to ccg3pa which execute dpm_pe_stop() command.

after passing Command i am detaching DUT and re attaching it so that to observe whether PD contract is happening or not. I my case it is happening even though after passing dpm_pe_stop()

so, Suggest me a way to test and know PD negotiation is unsuccessful and i can test my QC spec implementation.  

[Wang_Fred · Accepted solution]

It probably your power sink device is powered off during the unpluging-pluging process and the dpm_pe_stop() is just executed after PD contract is established.

Once the FW is re-started, the PD contract would be re-negotiated. Therefore calling this API would have no effect on PD contract because no further interaction on CC line. 

The good practice is to call this API in firmware just before the while loop in main function. There would be no response to the source capability message from power source. Possible to modify your CCG3PA FW to add this API?

[BhargavGolla]

Yes , It worked PD contract didnot happened and i was able to test QC 3.0 spec.

Thankyou Wang