Jetson Orin AGX Industrial Booting Problem

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

Hey Everyone,

We received our custom carriers, and they are now built. We have all power supplies working and are trying to get the Jetson to turn on now with our Embedded controller. We are following the sequence on the Jetson page, but the module is not powering on. Is there anything we are missing? We measured everything and are getting the correct signal values, as shown in Figure 5.2 of the Jetson design guide.

image
image682×465 51.8 KB

2

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I’ll try to help you troubleshoot the issue with your custom carrier and Jetson module.

Firstly, congratulations on receiving your custom carriers and successfully building them. It’s great that you have all power supplies working, and now you’re trying to get the Jetson module to turn on.

Since you’re following the sequence on the Jetson page (Figure 6-8. Power-Off to On Sequence Power Button Case), let’s review the key steps:

  1. POWER_EN: This signal should be asserted (high) to enable the power supply to the Jetson module.
  2. SLEEP/WAKE*: This signal should be de-asserted (low) to wake up the module from sleep mode.
  3. SYS_RESET*: This signal should be asserted (high) to reset the module.
  4. ACOK: This signal should be asserted (high) to indicate that the power supply is stable.
  5. VDD_DCIN: This signal should be asserted (high) to enable the power supply to the Jetson module.
  6. SHUTDOWN_REQ*: This signal should be de-asserted (low) to prevent the module from shutting down.
  7. T_PE_RST: This signal should be asserted (high) to reset the power sequencer.
  8. Carrier Board 1.8V/3.3V Supplies: These supplies should be enabled and stable.

You mentioned that you measured everything and are getting the correct signal values as shown in Figure 6-8. However, the Jetson module is not powering on.

Here are a few potential issues to investigate:

  1. Power supply voltage: Double-check that the power supply voltage (VDD_IN) is within the recommended range of 5.0V to 20V. Also, ensure that the voltage is stable and not fluctuating.
  2. Power sequencing: Verify that the power sequencing is correct. The power supplies should be enabled in the correct order, and the POWER_EN signal should be asserted after the power supplies are stable.
  3. Module sleep mode: Ensure that the SLEEP/WAKE* signal is de-asserted (low) to wake up the module from sleep mode.
  4. Reset signals: Verify that the SYS_RESET* and T_PE_RST signals are asserted (high) to reset the module and power sequencer, respectively.
  5. Carrier board supplies: Ensure that the carrier board 1.8V and 3.3V supplies are enabled and stable.
  6. Jetson module configuration: Check the Jetson module configuration, such as the module ID strap (GND or 1.8V), to ensure that it is set correctly.
  7. Power button control: If you’re using the EFM8SB10F2G-A-QFN20 MPU for power button control, ensure that the circuitry is replicated exactly as shown on the latest P3768 carrier board.

To further troubleshoot the issue, you can try:

  1. Checking the Jetson module’s power rails: Use a multimeter to measure the voltage on the Jetson module’s power rails (VDD_IN, VDD_CORE, etc.) to ensure that they are within the recommended range.
  2. Monitoring the POWER_EN signal: Use a logic analyzer or oscilloscope to monitor the POWER_EN signal and ensure that it is asserted (high) correctly.
  3. Checking the module’s sleep mode: Use a logic analyzer or oscilloscope to monitor the SLEEP/WAKE* signal and ensure that it is de-asserted (low) correctly.

If none of these troubleshooting steps resolve the issue, it may be helpful to provide more information about your custom carrier design, such as the schematic and layout files, to further assist in debugging the problem.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

Hi woods.little,

What’s the Jetpack version in use?

Is there any log output from serial console?
If so, please share them with us for further check.
If not, please share the waveform of power on sequence in your case.

6

We don’t have anything loaded currently. We are just wanting to see some power draw on our 12V rail which powers the module to see if the module is attempting to boot. Currently we are only seeing around 90mA being pulled.

Is the ACOK an optional signal?

7

Is the figure right being called out? Cannot find 6.8 in the specification.

Sleep/Wake: sleep request should it be asserted high? Since it is Sleep_req_n signal.

ACOK: this is only relevant to the dev kit right?

Shutdown_req: is this Module_shdn_n? If so this is an output from the module not a input so we cannot drive this signal.

9

We did take some scope captures of the timing diagram to help debug. Does the timing diagram look correct? For some reason, we are seeing a random high; maybe the module is doing it for the pink channel, which is the MODULE_POWER_ON signal. This blip also coincides with the CARRIER_POWER_ON signal going high, then randomly going back low, and then our embedded controller drives the signal again (that is the blue signal).

Yellow - Power_BTN_N

Cyan - VDDIN_PWR_BAD_N

Pink - MODULE_POWER_ON

Blue - CARRIER_POWER_ON

DS1Z_QuickPrint2
DS1Z_QuickPrint2800×480 12.8 KB

10

MODULE_POWER_ON and CARRIER_POWER_ON are not expected to go high-low-high like your capture.

MODULE_POWER_ON is an input to Jetson AGX Orin so is your embedded controller driving it high, then low, then high? This is not expected.

CARRIER_POWER_ON is an output from Jetson AGX Orin, not an input or bidirectional. So the EC should not drive it.

If your probe can handle the 12V level, can you move the CARRIER_POWER_ON to your VDD_IN and re-capture, triggering on the same PWR_BTN falling edge? Also please zoom out further to check for other behavior on the MODULE_POWER_ON.

Your screen capture of Figure 5-2 from the Jetson AGX Orin Design Guide is an older one. Please refer to the latest, which is v1.8 released about a month ago.

11

Hey Chris, so we were able to get something close to working on the module. Currently, our VDDIN_PWR_BAD is getting pulled low and is causing our CARRIER_POWER_ON to go low and stay low. This happens when we drive PERIPHERAL_RESET_N high. We keep PERIPHERAL_RESET_N low during the power sequence till the very end. We have been trying to take parts off to make sure we don’t have any type of back feeding or inrush, but that isn’t getting us anywhere. Our 5V, 3V3, and 12V rails are steady and stable.

Yellow - VDDIN_PWR_BAD_N

Cyan - MODULE_SHDN_N

Pink - 5V (SYS_VIN_MV)

Blue - 12V (SYS_VIN_HV)

DS1Z_QuickPrint1
DS1Z_QuickPrint1800×480 13.9 KB

YELLOW - POWER_BTN_N

CYAN - VDDIN_PWR_BAD_N

PINK - MODULE_POWER_ON

BLUE - CARRIER_POWER_ON

DS1Z_QuickPrint2
DS1Z_QuickPrint2800×480 13 KB

12

The MODULE_SHDN_N signal glitching low (coinciding with glitch on VDDIN_PWR_BAD_N since they are essentially tied together) at the ~7th time division is concerning. This means a shutdown request from the Orin module due to thermal occurred. That is why the MODULE_SHDN_N and CARRIER_POWER_ON outputs go low shortly after the glitch.

Could you do a sanity check for HV or MV shorted to ground with and without the Orin module?

Do you have a way to monitor the current on your input voltages to check for a large current spike that coincides with the glitch?

13

Hey Chris,

Is there a reason I would see 3.3V on the thermal_alert_n pin of the industrial module? I plugged in a Jetson Orin AGX 64GB non-industrial module and was seeing 1.8V on that pin instead?

14

Yes that is expected on the THERM_ALERT_N pin. The industrial module has a pull up to 3.3V (SYS_VIN_SV rail) and the 64GB commercial module pulls to 1.8V. The pin on Orin is a 1.8V open drain that gets level shifted to the SV rail on the industrial module.

15

Is this the only signal the industrial module does this on or are there other signals?