STUSB4500 Clarification on VBUS Discharge Default Configuration and NVM Address Details

[ashwinjali]

Dear STMicroelectronics Support Team,
 

We have observed a discrepancy between two STUSB documents regarding the default configuration of the VBUS discharge feature:

1. STUSB Datasheet / Online Document (Section 3.4.2 and 5.2) [Link: @STUSB4500.html]
   It states that the VBUS discharge feature is enabled by default in the NVM and can be disabled through NVM programming.
   • Parameter: VBUS_DISCH_DISABLE
   • Default Value: 0b (VBUS discharge enabled)
   • Description: Setting to 1b disables the discharge function.
2. Programming Guide (Section 3.23) [Link: @STUSB_programming_guide.pdf]
   It specifies that the VBUS_DISCHARGE_EN bit is disabled by default:
   • Address: STUSB_BLOCKBaseAddress + 0x26
   • Type: R/W
   • Reset: 0x00 (initialized by NVM)
   • Bit [7]: VBUS_DISCHARGE_EN
     • 0: Disable the forced assertion of VBUS discharge path
     • 1: Enable the forced assertion of VBUS discharge path

Due to this apparent contradiction - one document indicating that the VBUS discharge feature is enabled by default, while the other indicates it is disabled - we would like clarification on which information is correct.

We referred STUSB4500_NVM.pdf and couldn't see following configuration parameters.  Please provide additional information (specific NVM bank and bit locations) to configure these parameters

• VBUS_DISCH_DISABLE
• VBUS_DISCHARGE_EN

Note that we are not using GUI tool for programming, so software has been written to update parameters.

Best regards,
Ashwin

[Didier HERROUIN]

Dear Ashwin,

There is a confusion between I2C registers and NVM registers.

I2C registers are defined by the USB standard and are common to all USB devices. They can be read or modified by the application on the fly.
For instance, the VBUS_DISCHARGE_EN bit that you mentioned (accessible at address 0x26) can be written to "1" to force the discharge ( or to "0" to disable a discharge previously forced. So this event can only be driven by an external MCU.

The NVM contains the user-defined parameters. They are copied at power-up, or after a reset, from the NVM into I2C registers. The values copied in the I2C registers are used by the STUSB4500 during the system operation. They can be customized by NVM re-programming through the I2C interface : The new values override the initial default setting at next power-up or after a reset. 
The NVM re-programming is possible with a customer password (see document attached).
To avoid incorrect programming (for instance inconsistent parameters), we strongly recommended using ST provided tools such as STSW-STUSB002 GUI software to modify the parameters.

For your specific use case, VBUS_DISCH_DISABLE is located at address 0xC9 / bit 5 :
- 0xC9 register default value=0x40 (discharge will be automatically triggered when the relevant event occurs)
- if VBUS_DISCH_DISABLE is set, new value = 0x60 : no VBUS discharge will be triggered, except if the MCU forces it using I2C register as described above.

[ashwinjali]

Hi @Didier HERROUIN ,

Thanks for the information.

We observed when there is short power glitch (AC adopter turned OFF and ON within 1 second), Charging is not enabled and STUSB in invalid state basically we are not receiving any interrupts from STUSB.
This issue resolved by resetting STUSB but if the battery is not connected, there is no way for software to recover from this state. is there any suggestion we can debug this issue?

We tried by tuning the DISCHARGE_TIME_TO_0V value in the register 0x25, which is initialized by NVM from 0x9C (default) to 0xFC or 0x4C (We changed in NVM register 0xCA to take affect by default) and tested. but issue is not resolved.

Is this valid approach to resolve issue or any suggestion?

Regards,
Ashwin

[Didier HERROUIN]

Dear Ashwin,

Please confirm that you have implemented the discharge circuit as in our eval kit schematics (https://www.st.com/resource/en/schematic_pack/steval-isc005v1_schematic.pdf).

This circuit is recommended, especially if you expect Vbus drops.

If the problem is still there, please monitor VBUS with a scope on both sides of the MOS transistors.