NX Custom Carrier Board Design

Hello, we are currently working on designing our custom carrier board for the Jetson NX, and had a few questions:

  1. There doesn’t seem to be any specified requirements for input capacitance. I see in the dev-kit design there is 3 x 330uF Tant-polys on the input. Is the only requirement to have >= 990uF capacitance?

  2. We are planning on using the power control circuit used in the Jetson Nano Dev-kit design, rather then an MCU, to control the power up/down sequence of the NX. There is a circuit that allows a button press to shutdown the Nano (attached below). My understanding is this is done by just setting the Power_EN signal low to the Nano. Is there a concern that doing this without waiting for the SHUTDOWN_REQ* sign from the NX could result in data loss on the EMMC or damage to the NX?

  1. If we don’t plan on connecting a super-cap or coin-cell the PMIC_BBAT pin on the NX, can we just leave that floating or should we connect to a power supply?

  2. For this requirement:

Do we need to have and active pull-down tied to the SOC 1.8V logic rail and the SoC 3.3V logic rail, or do we just need to ensure that our custom carrier board is not driving any I/O pins to 3.3V/1.8V after the NX has been shutdown?

  1. For the power-up sequence is there a min delay requirement between VDD_IN becoming stable, and setting Power_EN high:

Thank you

Hi, first of all, besides the Power chapter in design guide doc, you also should check the checklist sheet attached in the doc. There are some helpful items in it for your design reference.

  1. Regarding the capacitors, please refer to that in P3509 schematic in DLC.

  2. Better to follow reference to add the 10s power button circuit as other option is not fully validated.

  3. It can be left floating, but suggest to add unmounted pads in first build.

  4. That’s for module inside request, for carrier board, only need to power off shared interface pins earlier than module.

  5. There is no critical delay requirement on that as VDD_IN pass through a 5V DC/DC converter which will generate a pgood for usage.

Hi Trumany,

Thank you for the response I have been reviewing the checklist as well, and I had a couple follow-up questions:

  1. We are planning on implementing the same design, but without the delay. It will be toggled by an MCU, rather then button press

4.1 By shared interface pins, are you only referring to shared interface pins that are 3.3V and 1.8V logic, or do we need to ensure that any interface i.e. USB devices/UART/I2C are disabled as well prior to the NX powering off?
4.2 Is that the purpose of this circuit on the dev board, to ensure no peripherals are powered:

Thank you,

All shared pins should be powered off earlier on carrier board. You can check the reference schematic for detail. yes, the discharge circuit is to meet the power down sequence.

Can you point me to where this is discussed further in the design guide?
Does this still hold true for a sudden power loss condition? We have several highspeed interfaces, such as MIPI and PCIE devices connected to NX, do these devices need to be powered off prior to boot up and shutdown of the NX? This would require us to have a significant hold-up to ensure we can power all devices connected to the NX off on our carrier board and also maintain the 10ms requirement.

What is the timing between POWER_EN getting deasserted and the SYS_RESET* being asserted, as specified in this section:

Thank you,

You can refer to design guide of Xavier and TX2 in DLC for detail power sequence.

That timing is in module, and not so strict, you can take it as couple of ms.

Thansk for the info, I will take a look at the Xavier and TX2 DG as well, I’m assuming we can ignore the additional signals that are represented in the TX2 timing?

I also have a follow-up question regarding the timing sequence. I measured the power down sequence on the NX dev-kit for two condtions, a SW shutdown, and sudden power loss shutdown. In both cases they do not follow the timing diagrams:

For a SW shutdown, it looks like the timing does not meet the requirement of Power_EN falling within 10us of the Shutdown_REQ* signal being asserted.

For a Sudden Power loss (pulling the dc jack) Shutdown_REQ*, never asserts before Power_EN is de-asserted. While the plot is at 800us division, I confirmed that there is no smaller Shutdown _REQ* pulse prior to Power_EN. It looks like Power_EN is dependent on the Force_Off_N signal, however that does not come from the NX.

Is this expected? I would’ve expected it to follow closely with the timing specified in the NX DG.

Hi, not sure how do you get this sequence. In module, SHUTDOWN_REQ is toggled to VDD_IN and SW_SHUTDOWN_N directly, it can NOT be high without VDD_IN, you can probe VDD_IN too to make sure it is low.

Hi Trumany,
I’m probing those signals on the dev board directly.
For the sw shutdown condition, I sent “sudo shutdown now” from the terminal
For the sudden power loss, I removed the power by pulling out the DC Jack
VDD_IN is decaying in the sudden power loss condition, however there is no pulse on Shutdown_REQ* prior to Power_EN being de-asserted, it looks like the Force_Off_N signal detects the power removal faster then the NX and so it disables power without receiving the NX_Shutdown_REQ* signal first. Is this acceptable from a power sequencing perspective?


Hi, we are checking this internally, will update once available, thanks.

Hi, regarding your sudden power loss timing, on devkit, FORCE_OFF_N is SHUTDOWN_REQ, why do you have them separated in the timing figure?

I had them separated because FORCE_OFF_N can be pulled low by SHUTDOWN_REQ_N, but it can also be pulled low by the circuit boxed in blue.

OK, that more make sense. FORCE_OFF is toggled to VDD_DCIN, while SHUTDOWN_REQ is toggled to 5V in module. So it could be earlier on VDD_DCIN loss detection. We are checking the timing value which is marked as <10us in DG.

Thanks for the clarification. From the perspective of the NX, is there a difference in POWER_EN being asserted low due to FORCE_OFF*, vs SHUTDOWN_REQ*?

Users who implement an MCU control of this power on logic similar to our Button MCU on NX carrier board, don’t have to worry about this <10us because the timings are taken care off by the MCU.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.