On the next version of our robot, we would like to use the Jetson Orin AGX industrial.
The power sequencing, however, seems very complex (compared to the Jetson Orin NX), probably partly so because the design guide mainly focus on the version with power button with a MCU to handle all the complex power logic. The schematics of the developer kit are even more complex.
For my use case, there is no need for a power button : the Jetson Orin AGX industrial should be powered on as soon as power is present, and powered off when power is removed (during development, there might be some power off commands from command line, having to power cycle to power on again is fine).
Do you have any minimalist schematics for the power on/off circuitry of the Jetson Orin AGX industrial?
Or if not, any minimal set of constraints that have to be respected?
In case it helps for your answer :
main power supply is unregulated (and unstable) 22-44VDC. I also have a high current regulated 24V power rail which can also serve as primary power source. Lower voltage rails (probably 12, 5, 3.3 and 1.8V) will probably also be needed in my design (current requirements not yet determined, but they could be made high current if needed by the Jetson). I’m also OK to generate dedicated voltage rails for the Jetson from the unregulated 22-24VDC (probably the best option to generate SYS_VIN_HV, and maybe also SYS_VIN_MV/SYS_VIN_SV)
Hi, you should refer to the Jetson AGX Orin Series Design Guide (including AGX Orin Industrial) to make design, not that of Orin NX.
There is no “minialist schematics” for the power on/off circuitry. Your custom design should meet below requirements listed in DG if you want to implement auto-power-on without MCU:
5.3.1 Auto Power-on
If the system does not require a power button or equivalent, and should power on when the main power source is connected, the following requirements should be met:
SYS_VIN_HV, SYS_VIN_MV, and SYS_VIN_SV (JAOi only) should be powered on. These can be optionally gated and a signal used to enable them when the module is detected mounted correctly using PRSNT[1:0].
VDDIN_PWR_BAD_N should be de-asserted (high) once the SYS_VIN_HV/MV supplies are enabled and stable.
MODULE_POWER_ON should be asserted (high)
Note: The design should de-assert (low) MODULE_POWER_ON if VDDIN_PWR_BAD_N is asserted (low), CARRIER_POWER_ON is de-asserted (low), or MODULE_SHDN_N is asserted (low).
Hi,
Thanks for your answer.
The comparison with the Jetson Orin NX was just because we use it in another product.
Based on the quote of the design guide you provided, the sequencing is the following :
Supply SYS_VIN_HV, SYS_VIN_MV and SYS_VIN_SV in ANY order (potentially simultanously) : do you confirm (I was under the impression that there are some additionnal requirements not listed in your list)
de-assert VDDIN_PWR_BAD_N (ie get it high) (no timing requirements, just making sure all 3 input voltages are present and stable)
Should MODULE_POWER_ON be asserted (ie put to high) systematically, or only if (VDDIN_PWR_BAD_N=high AND CARRIER_POWER_ON=high AND MODULE_SHDN_N=high)? Any timing constraints?
Is that all?
And for power off, is the only requirement that
4) If VDDIN_PWR_BAD_N=low OR CARRIER_POWER_ON=low OR MODULE_SHDN_N=low then I need to put MODULE_POWER_ON to low
No other requirements nor timing requirements?
On the power-on diagram (figure 5-9 of Design Guide), CARRIER_POWER_ON is still low when MODULE_POWER_ON goes high : isn’t this a deadlock? (as CARRIER_POWER_ON=low should cause MODULE_POWER_ON to be low)?
Could you please provide the diagrams for the no button no-MCU auto power on and power off sequencing? The design guide only provide the versions with MCU, which add signals that I don’t expect to exist without MCU (like ACOK). It would be nice to also add them in the design guide itself (if the MCU is not required, then the design guide shouldn’t be assuming it’s always present ; if it is required, why not to move it into the module?)
So for powering on, MODULE_POWER_ON should go high before CARRIER_POWER_ON, but once both are high, if CARRIER_POWER_ON goes low, MODULE_POWER_ON should also go low as fast as possible?