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.
*** 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:
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:
To further troubleshoot the issue, you can try:
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. ***
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.
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?
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.
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
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.
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)
YELLOW - POWER_BTN_N
CYAN - VDDIN_PWR_BAD_N
PINK - MODULE_POWER_ON
BLUE - CARRIER_POWER_ON
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?
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?
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.
Is this the only signal the industrial module does this on or are there other signals?
@ChrisB_NV Is there any update on this? We can get the commercial module to boot fine on our carrier, but we are having issues with the industrial module. We do have 3.3 going to the SV rail, and the SV rail is first to come up.
What is the timing of your SYS_VIN_SV rail to the SYS_VIN_MV rail?
No other signals are pulled to SYS_VIN_SV.
Hey Chris,
SYS_VIN_SV comes up 25ms before SYS_VIN_MV.
Were you able to check for HV or MV shorted to ground with and without the Orin module?
Do you still see the glitch on VDDIN_PWR_BAD_N like your most recent scope shots? That signal should stay high and not glitch like that, so the cause of it may be the key. Could it be related to something else on your carrier board powering on after CARRIER_POWER_ON went high and causing the signal to go low? VDDIN_PWR_BAD_N is an input pulled up to SYS_VIN_MV inside the module. Does the glitch still happen if the Orin module is removed?
Hey Chris,
HV and MV are not shorted together.
Most recently, I removed the translator between our embedded controller and the module on the VDDIN_PWR_BAD_N signal and tied a 1k resistor to our 5V_SB rail, which comes up as soon as power is applied to the board. The pull up was tied to VDDIN_PWR_BAD_N on the module side of the translator. The MV is generated from a switch that is powered by the 5V_SB rail. This seems to clean up the issue about 50-70% of the time. I’m able to get a solid high signal and a solid high on the shutdown pin. At this time, the board starts to draw about 2A from a 12V supply, and then it immediately dips down to around 1A and stays there until I power off the board. I did check to see if the recovery line is pulled low, but it is currently high and the module isn’t in recovery mode.
I did try and flash the industrial module on our Dev Kit using the industrial module configuration, but that didn’t help at all. I’m not seeing anything out of the serial console port either. I did confirm that a commercial module still boots fine on this setup, and the serial console is working fully on the commercial module. I have tried about 3 different industrial modules, and all are showing the same symptoms.
The SYS_VIN_SV rail is the primary difference between the commercial and industrial modules on the board design side.
Is the PERIPHERAL_RESET_N signal (input to the module) high (1.8V)? The signal being driven low by the carrier would reset Orin.
If you assert FORCE_RECOVERY_N on the industrial module on your carrier board, are you able to see it in recovery mode and flash it?
Is there any activity on the THERM_ALERT_N signal? Normally it should be always high (1.8V)
As a sanity check - do you have pull up resistors populated on the NVJTAG_SEL and NVDBG_SEL signals? For normal operation they should not be present and I suppose they are not on your board since the commercial module boots but at this point it is good to double check. Another user recently had a problem caused by populating the pull up on NVJTAG_SEL. JTAG_TRST_N should also be left disconnected from any signals by default.
Hey Chris,
Peripheral_reset_n is being driven high from our embedded controller after all rails are good, module_power_on is high, and carrier_power_on is seen as high from the module
I’m not able to execute the recovery mode at all. Every once in a while, I’m able to see a USB error in Windows when I hold down the recovery button when I’m using the industrial module.
Therm_alert_n signal is always high. I’m seeing 3.3V on our carrier board. From earlier messages looks like it is supposed to be 3.3V on the industrial module.
All pull-ups are not present on the JTAG for the module.
Additionally, we have tried holding VDDIN_PWR_BAD_N low until we bring MV up, and then releasing it so that the internal module pull-up takes over. Then we bring up HV and wait for a certain amount of time, and then bring up MODULE_POWER_ON, but both module_power_on and vddin_pwr_bad_n turn on at the same time when we are doing scope captures.
