cancel
Showing results for 
Search instead for 
Did you mean: 

USB EZ-PD™ Type-C

HoKa
New Contributor II

Hello Cypress-Team,

we want to change PDOs dynamically at runtime in our project via the HPI interface to get the best fitted power negotiation between sink and source. I think this should be possible, but I did not find any code examples or a detailed description of the HPOI interface.

Here my questions:

1. Is it possible to change PDOs dynamically at runtime?

2. Are there any existing code examples for this purpose?

3. Is there a more detailed HPI interface description?

 

BR Holger

0 Likes
1 Solution
ShifangZ_26
Moderator
Moderator

Hello Holger,

Please kindly refer my comments as below.

1. Is it possible to change PDOs dynamically at runtime?

>> Yes, it is possible. Not only by HPI interface, you could change it in firmware directly by adding a pieces of codes. And trigger the PDOs change as per your design. 

2. Are there any existing code examples for this purpose?

>> 1) HPI do not have example code could be shared. 

2) The example code for PDO change could be refer below:

void change_pdos(void)
{
pd_do_t SRC_PDO[2];

SRC_PDO[0].val = 0x0B0190F0;
SRC_PDO[1].val = 0x0002D0DE;
/* New 5V/2.4A(0B0190F0);9V/2.22A(0002D0DE) add PDO */
// SRC_PDO[2].val = 0x0004B064;
// SRC_PDO[3].val = 0xC0761E3C;
// SRC_PDO[4].val = 0xC0DC1E3C;

/**
* @brief This function updates the source PDOs at runtime thereby overriding
* the source PDOs in the configuration table.
* @param port Port index.
* @param count Count of PDOs.
* @param pdo Pointer to the PDO array.
* @return CCG_STAT_SUCCESS if operation is successful, CCG_STAT_BAD_PARAM
* otherwise.
*/
dpm_update_src_cap(0, 2, SRC_PDO);

/**
* @brief This function updates the source PDO mask at runtime thereby
* overriding the source PDO mask in the configuration table.
* @param port Port index.
* @param mask PDO mask.
* @return CCG_STAT_SUCCESS if operation is successful, CCG_STAT_BAD_PARAM
* otherwise.
*/
dpm_update_src_cap_mask (0, 0x03);

dpm_pd_command (0, DPM_CMD_SRC_CAP_CHNG, NULL,NULL); //Send PD command about the changes in source capabilities
}

3. Is there a more detailed HPI interface description?

>> The HPI specification could get it from local Cypress/Infineon FAE, please feel free to contact them.

 

Best Regards,

Lisa

View solution in original post

0 Likes
3 Replies
ShifangZ_26
Moderator
Moderator

Hello Holger,

Please kindly refer my comments as below.

1. Is it possible to change PDOs dynamically at runtime?

>> Yes, it is possible. Not only by HPI interface, you could change it in firmware directly by adding a pieces of codes. And trigger the PDOs change as per your design. 

2. Are there any existing code examples for this purpose?

>> 1) HPI do not have example code could be shared. 

2) The example code for PDO change could be refer below:

void change_pdos(void)
{
pd_do_t SRC_PDO[2];

SRC_PDO[0].val = 0x0B0190F0;
SRC_PDO[1].val = 0x0002D0DE;
/* New 5V/2.4A(0B0190F0);9V/2.22A(0002D0DE) add PDO */
// SRC_PDO[2].val = 0x0004B064;
// SRC_PDO[3].val = 0xC0761E3C;
// SRC_PDO[4].val = 0xC0DC1E3C;

/**
* @brief This function updates the source PDOs at runtime thereby overriding
* the source PDOs in the configuration table.
* @param port Port index.
* @param count Count of PDOs.
* @param pdo Pointer to the PDO array.
* @return CCG_STAT_SUCCESS if operation is successful, CCG_STAT_BAD_PARAM
* otherwise.
*/
dpm_update_src_cap(0, 2, SRC_PDO);

/**
* @brief This function updates the source PDO mask at runtime thereby
* overriding the source PDO mask in the configuration table.
* @param port Port index.
* @param mask PDO mask.
* @return CCG_STAT_SUCCESS if operation is successful, CCG_STAT_BAD_PARAM
* otherwise.
*/
dpm_update_src_cap_mask (0, 0x03);

dpm_pd_command (0, DPM_CMD_SRC_CAP_CHNG, NULL,NULL); //Send PD command about the changes in source capabilities
}

3. Is there a more detailed HPI interface description?

>> The HPI specification could get it from local Cypress/Infineon FAE, please feel free to contact them.

 

Best Regards,

Lisa

View solution in original post

0 Likes
HoKa
New Contributor II

Hi Lisa,

first of all, I want to thank the support regarding the really fast replies, this is really good!

Our system is built up as follows:

HoKa_0-1625735960306.png

 

So, in our system, the CCG3 controller acts as a slave, as in many systems. We thought to use the following workflow:

  1. Negotiation falls back to 5V/500mA (Fallback)
  2. Master gets this informaiton via I2C (Informed by I2C_INT line from SLAVE)
  3. MCU sends new PDOs to the SLAVE
  4. New negotiation should be started
  5. Negotiation OK (No "fallback" is taken)
  6. SLAVE informs MASTER about the negotiated power

Your suggestion is the following:

  1. Negotiation falls back to 5V/500mA (Fallback)
  2. Slave itself changes the PDO without any action from the MASTER
  3. New negotiation should be started
  4. Negotiation OK (No "fallback" is taken)
  5. SLAVE informs MASTER about the negotiated power

In our application it is enough to inform the MASTER regarding negotiated power, FW version on the CCG3, .... Also it should be possible to to an FW update via the I2C interface (HPI), am I right? 

So, which workflow should be better for us? I think it should be easier to handle the PDO change in this case directly in the CCG3-FW by loading new PDOs directly from new pre-defined PDOs. Also, the trigger could be directly given by the CCG3-FW itself, when the fallback PDO is taken.

 

0 Likes
ShifangZ_26
Moderator
Moderator

Hello Holger,

Your understand is correct.

This is not relates on which one is better, it is depends on which resource you could easy to get. If you are code player, the firmware changes will be suit for you easier. otherwise, you could try to find the HPIv2 specification from local sales/FAE to follow the documentation.

Best Regards,

Lisa

0 Likes