VBUS sensing and monitoring on AGX Thor Dev Kit carrier board

Robotics & Edge Computing Jetson Systems Jetson Thor
, ,
1

I am reviewing page 32 of the Jetson AGX Thor Developer Kit carrier board schematics and I have a question regarding the current sense implementation for the USB VBUS path. Specifically I am looking at VS36 VS37 VS38 and VS39 connected to VBUSx_P_PATH.

From the schematic it appears that:

  • VBUSx_P_PATH connects directly from the power source to the USB port

  • The shunt resistor has one side connected to VBUSx_P_PATH

  • The other side of the shunt connects only to CSP and CSN

  • There is no separate downstream net after the shunt

Schematic, P. 32.3C
Schematic, P. 32.3C1220×128 15.8 KB

In this configuration the load current does not flow through the shunt. Therefore no voltage drop proportional to USB port current can be generated across the resistor.

My questions are:

  1. Is this resistor intended for actual current measurement of the USB port

  2. If yes, where is the true series element in the VBUS path

  3. If no, what is the intended function of VS36 VS37 VS38 and VS39 in this design

  4. What is the rationale for implementing VBUS monitoring and control primarily via GPIO based signaling instead of using the dedicated VBUS related pins exposed by the module

I verified that VBUSx_P_PATH is common between source and port and I do not see a separate net segment that would place the shunt in series with the load. Clarification on both the measurement topology and the design decision regarding GPIO usage versus dedicated VBUS pins would be appreciated. Thanks!

3

I am checking on this with the design team.

4
  1. Is this resistor intended for actual current measurement of the USB port

As the schematic is, the PD will only measure voltage and not current. If you want to measure current, add a sense resistor between CSP and CSN, but note this is only for the provider paths on page 33.

  1. If yes, where is the true series element in the VBUS path

VBUS voltage sensing is implemented in the PD controller but not current sensing. Current sensing is already implemented in the voltage regulator. The PD controller can read VBUS current from the VBUS regulator over I2C.

  1. If no, what is the intended function of VS36 VS37 VS38 and VS39 in this design

They are just to have the same net on the schematic for better clarity when reviewing.

  1. What is the rationale for implementing VBUS monitoring and control primarily via GPIO based signaling instead of using the dedicated VBUS related pins exposed by the module

Since the regulator already reports current, adding another sense resistor for the PD controller to monitor is redundant. There is no harm in adding current sense on the PD controller if desired.

Using the PD controller to control VBUS with discrete MOSFETs needs complicated analog circuits to prevent reverse current. So GPIO is used for VBUS control instead.

5

Thanks for the clarification. The explanation about voltage sensing via the PD controller and current reporting from the regulator over I2C makes sense.

I would like to ask for a bit more detail regarding point 4.

Looking at the typical application diagram in the CCG8D datasheet each port normally uses:

  • CSN and CSP for current sensing
  • VBUS_IN_NGDO and VBUS_OUT_NGDO as the gate driver voltages
  • VBUS_IN_CTRL, VBUS_OUT_CTRL and VBUS_C_CTRL as the control signals
  • VBUS_C

C.f. Figure 5 in the CCG8D datasheet
C.f. Figure 5 in the CCG8D datasheet781×653 15.4 KB

CSN and CSP being unused here makes sense since the regulator already provides current sensing.

The remaining pins however appear to already implement the VBUS switching path. The datasheet describes an integrated load switch controller for driving back to back NFETs on the provider path including protections such as reverse current blocking, overcurrent and overvoltage protection. Section 2.4.5.2 also notes that reverse current protection is supported on the provider path but not on the consumer path.

Since the board can operate as both source and sink, using GPIO control for the consumer path makes sense. However for the provider path the dedicated VBUS control pins seem to already support the required switching and protection features.

Could you elaborate on why those dedicated pins were not used for the provider side?

If this is due to my misunderstanding of how the CCG8D implements the provider path control I am happy to revisit the datasheet. At the moment it appears to be a deliberate design choice and I would be interested in understanding the reasoning behind it.

6

From the board designer, who also provided the earlier responses:

Your logic is right. The reason the Dev Kit carrier uses the e-fuse method is not purely for technique reasons.

First, following your logic, a circuit for the consumer path with RCP (reverse current protection) is required. So the e-fuse with RCP, the AOZ13937 part, is selected.

Second, going back to the provider path, we have 2 choices:

  1. CCG8D + discrete FETs
  2. CCG8D + AOZ13937 (use the same e-fuse as on consumer path)

Both are good to use technically. If you compare PCB space, cost, and reliability, the integrated e-fuse would be a better option. For example, RCP with discrete FETs highly relies on good firmware. It’s easy to damage boards or host PCs connected to boards during firmware development.

In the end, with the CCG8D+AOZ13937 implemented on the Thor carrier, a GPIO is required instead of FET-gate drivers ports.