Jetson Nano power up issues over temperature

We have designed a custom carrier board for a Jetson Nano. We have wicked power up problem that occurs, typical at high or low temperatures, although we have seen this problem at room temperature on certain units.

Below is a bad boot:
image

Below is a good boot:
image

We followed the Jetson Nano carrier board power sequence design. In most cases we used the same components. From what we can tell we are meeting the requirements of the Jetson Nano Product Design Guide V2.2 page 13 and on.

In the screen shots, 5V0_Ride is a super cap/mains power line. 5V0_SOM is the 5V0_Ride signal that goes through a FET. NANO_EN is POWER_EN (Nano), REG_EN is SYS_RESET (Nano), SHDN_REQ is SHUTDOWN_REQ (Nano).

The only think I can think of that would cause this issue is a brown out on the PMIC on the Jetson. But we don’t see the power supply dip when we apply power to the Jetson or raise POWER_EN high on the SOM.

The plot thickens. We soldered a bunch of wires onto various power rails directly on the Jetson Nano. Below is a capture of a failed boot at room temperature.

PGOOD is an indicator that external power has been applied to the carrier board. There is a (roughly) 0.9V core voltage that fails to come up. Zooming in on the power up sequence:

The 5V SOM comes up nice and clean, we generate the SET pulse (just like the NANO Dev kit). We then drive NANO_EN (POWER_EN) high which should bring the supplies up and boot the Nano. You can see the various power supplies come up, but it never boots.

Below is a good boot. There is not much difference, other than the 0.9V rail comes up (core voltage???) and the unit boots.

This appears to be a flaw in the Jetson Nano. We are running Jetpack 32.4.2 (using meta-tegra GitHub - OE4T/meta-tegra at dunfell-l4t-r32.4.2). I don’t see any release note changes to Tegraboot that would improve this issue.

Below is a picture of the power rails on the Nano and how we labeled them.

Hi, I don’t think you should consider the rails of PMIC. For custom carrier design, customer only needs to follow the design guide and reference schematic of devkit carrier board. The key point is to let module power on first and then the rails of carrier. After power rails are stable, to assert POWER_EN will power on system correctly.

I totally agree. We shouldn’t have to worry about the PMIC rails on the Jetson. But every single unit we have built (50+) exhibits this problem at different temperatures. We are trying to launch our product into production, but we obviously can’t do that if the Jetson will not power up. We need help to figure out what we might be doing wrong. We have followed ALL guidance in the design guide and Jetson dev kits. We have talked with FAE’s and had those FAE’s review our schematic. We even drove changes to the design guide to include times between various edges in the power up section.

Per your info, it is a random issue that could happen in high, low or even room temperature. Did you test with devkit in same settings? If no such issue with devkit, then the module is proved no problem. And then since it is random, it looks more like a component related issue on your custom board. In addition, can you use an oscilloscope to observe the details of 5V rails and POWER_EN signal?

The 5V rail and POWER_EN signals are shown in the scope plots above. It has been a while since we measured the signals on the dev kit. We can re-check that. What would happen if a signal was back fed into the Jetson before the 5V main rail is up or the POWER_EN signal? We are in the process of verifying we are not back feeding anything, but could that cause a problem like this?

Module should power on earlier than carrier so that the shared pins status won’t be affected.

Hi, please update your re-check result, is there any power rail on carrier board that will be on earlier than module’s? And what is the delay value between 5V stable and POWER_EN? It is not clear in your sequence.

Also how many modules have you tested? What’s the failure rate?

We compared the Jetson Nano Dev Kit 5V input to POWER_EN signal and compared it to our design.

The Jetson Nano devkit asserts POWER_EN 334 ms after application of 5V. Our design asserts POWER_EN 268 ms after application of 5V.

We don’t believe that is an issue. Per the Jetson Nano Product Design Guide v2.2:

We also tried increasing the delay and were still able to get the unit in a bad state.

We then power cycled the Jetson Nano Dev kit 50 times each at room temperature, +65 deg C and -25 deg C. In all cases the Jetson Nano booted. The Jetson Nano was programmed with our code, kernel, file system (based on Jetpack 32.4.2).

We did fine a path for 1.8V to leak back into the Jetson via the SYS_RESET signal. We fixed that and are still able to replicate the problem.

We then used Kapton tape to tape off all signals other than 5V, POWER_EN, SYS_RESET, and SHUTDOWN_REQ. We were still able to replicate the problem. So it appears to have something to do with our 5V power supply.

Below is a capture with the Kapton tape and the 1.8V (SYS_RESET) feedback fixed.

The unit successfully booted once, then was shut down and would not boot up for the second power cycle. At this point we think it has something to do with a quick transient droop in the 5V VDD_IN.

We have gotten every unit we have built to fail. So over 30-40 units now.

Hi, in your sequence why are there multi drops on PGOOD, 5V0_SOM and NANO_EN? It should be only one rising only during power on. For module power-on, it only needs stable 5V and then asserting POWER_EN.

Per your info, the issue can’t repro on devkit, and can repro on all your units, right? The power supply design should be checked and compared to devkit carefully. The 5V should be ON along after plug in.

Those images show multiple power cycles.

This looks like some component broken. How many modules have you tested? If the module are all good now, then it should be the carrier board component.

The power sequence looks good since it is multiple power cycles. If the module is good too, it might indicate something on carrier board cause this issue. Is there any log info output? That may be helpful.

Still suggest to compare your design to P3449 board to eliminate the difference, also there is a checklist table in product design guide that might be helpful too.