Lack of documentation and inconsistency in STUSB4500Q code example

[JulienD]

Hello,

I'm implementing the sink side of a usb-c PD system based on STUSB4500Q.

I had a look to documentation and to the example code.

It looks that the code was written by a first year intern. The ~25 global variables,

inconsistency in variable / constants casing, globals that are in fact locals, static locals that are in fact locals and an odd general architecture make It not very easy to understand.

As an example, I can read this:

if (Alert_Status.b.CC_DETECTION_STATUS_AL != 0) {
 connection_flag[Usb_Port] = 1;
 Status = I2C_Read_USB_PD(STUSB45DeviceConf[Usb_Port].I2cBus, STUSB45DeviceConf[Usb_Port].I2cDeviceID_7bit, PORT_STATUS_TRANS, &DataRW[0], 2);
 PD_status[Usb_Port].Port_Status.d8 = DataRW[1];
 if (PD_status[Usb_Port].Port_Status.b.CC_ATTACH_STATE != 0) {
 Status = I2C_Read_USB_PD(STUSB45DeviceConf[Usb_Port].I2cBus, STUSB45DeviceConf[Usb_Port].I2cDeviceID_7bit, CC_STATUS, &PD_status[Usb_Port].CC_status.d8, 1);
 } else /* Detached detected */
 {
 connection_flag[Usb_Port] = 1;
 PDO_FROM_SRC_Valid[Usb_Port] = 0;
 }
 }

Line 2 and 9 set the same variable to the same value. What should I understand? Best case: line 9 is useless, worse case: line 2 is a bug.

Line 3 reads 2 bytes but the first one DataRW[0] is never used. Should it be used somehow or should only the second byte be read?

In order to understand, I read the software programming manual but it is not more verbose and generally states "for further details see function xxxx in code".

If I have a look to chapter 3.6:

The fields are not documented. For example what are PORT_STATUS_AL and PRT_STATUS_AL?

You can also see that bit 2 is missing in the array and bit 3 is not consistent with the register drawing.

If I have a look to the code the corresponding structure is defined like this:

#define ALERT_STATUS_1 0x0B // Interrupt register
/*************************************************************************************************************
 * @brief 	STUSB_GEN1S ALERT_STATUS register Structure definition
 * @Address: 	0Bh
 * @Access: 	RC
 * @Note: 	This register indicates an Alert has occurred. 
 * (When a bit value change occurs on one of the mentioned transition register, it automatically 
 * sets the corresponding alert bit in ALERT_STATUS register. )
 ************************************************************************************************************/
typedef union
{
 uint8_t d8;
 struct
 {
 uint8_t PHY_STATUS_AL 		: 1; 
 uint8_t PRT_STATUS_AL 		: 1; 
 uint8_t _Reserved_2 		: 1; 
 uint8_t PD_TYPEC_STATUS_AL 		: 1; 
 uint8_t HW_FAULT_STATUS_AL 		: 1; 
 uint8_t MONITORING_STATUS_AL 	: 1; 
 uint8_t CC_DETECTION_STATUS_AL 	: 1; 
 uint8_t HARD_RESET_AL 		: 1;
 } b;
} STUSB_GEN1S_ALERT_STATUS_RegTypeDef;

To summarize both (I assumed that the bits description is wrong and used the register drawing):

• bit 0: reserved vs PHY_STATUS_AL
• bit 1: PRT_STATUS_AL vs PRT_STATUS_AL
• bit 2: Reserved vs Reserved
• bit 3: PD_TYPEC_STATUS_AL vs PD_TYPEC_STATUS_AL
• bit 4: CC_HW_FAULT_STATUS_AL vs HW_FAULT_STATUS_AL
• bit 5: TYPEC_MONITORING_STATUS_AL vs MONITORING_STATUS_AL
• bit 6 : PORT_STATUS_AL vs CC_DETECTION_STATUS_AL
• bit 7: Reserved vs HARD_RESET_AL

In bold are "understandable" differences, in bold italic are inconsistancies....

At least CC_HW_FAULT_STATUS_1 and CC_HW_FAULT_STATUS_0 share the same kind of issue.

So for now, my question is simple: Is there a real reference guide like we can have for a microcontroler for example?

Thanks

Julien

[Benoit FORET]

Hello Julien,

There is no additional User Manual unfortunately. But we are going to update UM2650 based on your feedback.

In the meantime, a few explanation:

• “DataRW[0] is never used�?:

==> it is used indeed as Clear on read of PORT_STATUS_ALARM bit in ALERT_STATUS register.

Similar mechanism are used for clearing PRT_STATUS_AL.

Please consider STUSB4500 is a standalone / Autorun PD controller. The software layer is optional, and sample code has been shared to illustrate additional features and fasten application set-up with limited software skills. We do agree the code is not production level, but this is not the original intent. This is why the code is open, and not compiled.

If any specific feature you would like to implement, please detail, and we will advise.

Rgds,

Benoit

[JulienD]

Bonjour Benoit,

On est presque voisins ! :D

Thanks for your answer.

Finally the NVM configuration will do the trick.

The documentation states the defaults startup for PDO3/2 are 20V and 15V.

My board does not support more than 12V. It is exclusively powered by the PD unit.

If I first plug a PD which can provide 20V. The negociation might succeed before I

have to opportunity to change the NVM to a single 9v PDO. So the board will be powered

with 20V and will blow up in many little parts.

Can you confirm?

If yes, the solution I imagine, is to first run the board with a simple 5V power supply

and setup NVM with it.

Is there another way which does not require this "pre launch" operation?

Thanks

Bonne journée

Julien

[Benoit FORET]

Bonjour Julien,

that's correct. The NVM contains a default setting that must be customized in 99% of time to meet a given application use case.

In customization mode, 5V can be applied on VSYS for instance, or if not possible, the 1st SOURCE that is connected to the USB-C port must be under control to ensure VBUS voltage does not exceed board specs.

Note that the new NVM parameters will be effective after the IC power down and a new power on reset cycle.

Rgds,

Benoit