When we start a Jetson Nano Production module on our custom carrier board, we are unable to bring the device out of sleep mode. We are able to confirm that we have followed the turn-on procedure as written in the Jetson Nano Product Design Guide (First apply 5V, then EN, then wait for SYS_RESET). We have also tried every configuration of setting/flipping the SLEEP/WAKE line from a MicroController, with no results. The only time we were presented with the desktop environment was after flashing in recovery mode, when it automatically rebooted. We are using the standard Pinmux table.
To add further information: When trying to debug the problem through the UART debug port, we were unable to receive any data. This makes it seem like the Jetson Module is getting stuck before the UART debug port would send out information.
did you mean you cannot wake-up your customize Nano enter it’s entering SC7 deep sleep mode?
please see Jetson Nano Product Design Guide,
could you please check [Figure 5-1.] and check you’re having correct pin connections for pin#240,
you may also refer to chapter [11.3 UART] to review the pin connections for your console logs.
I mean that when the system starts up it seems to be in a sleep state and no amount of toggling on the SLEEP/WAKE* line will wake it up. I also have confirmed that the SLEEP/WAKE* line is connected to pin 240.
I have copied a good portion of the Jetson Design from the the carrier board, and have ensured that the pinout is correct. We used an oscilloscope to probe each of the three UART ports and saw no activity on the line. In other words, it seems like the UART logs never start.
how you determine your device starts-up?
did you setup display monitor to show the ubuntu-desktop, or, you’re having ethernet to
ssh to the rootfs?
We have been able to determine whether or not the device starts up by monitoring the power draw of the Jetson module and the states of various I/O lines. When power in our setup, the Jetson module never uses more than 1.5W. On the Nvidia P3450 carrier board, the same Jetson module pulls at least double that. Both Ethernet and Displayport are available on our custom carrier PCB, but neither are sending data.
Here is a scope capture of the 5V power (Yellow), Jetson Enable (Light Blue), SYS_RESET (Pink), and MOD_SLEEP (Dark Blue).
As you can see MOD_SLEEP line never goes high, meaning the Jetson seems to be stuck in some sort of sleep mode or something else that is preventing it from starting up.
I probed these same lines on the Nvidia P3450 carrier board with the following results:
The MOD_SLEEP line does go high on this module, and the power draw after about 5 seconds is at least 5W, instead of the 1.5W on our carrier board.
I would suggest you review the product design guide to examine your power-on sequence,
I have extensively reviewed the hardware design guide, the Jetson Nano datasheet, and the Nvidia P3450 breakout board schematic and layout files. Me and my engineering team have looked extensively on this forum to try and determine why our custom board design is different than the board design you give, and have found nothing. I expected a more intuitive answer as to what could be wrong after showing a scope capture proving that our startup sequence is near identical to yours.
Hi, did you check the carrier power supplies? They should be power on after module supply.
Hi Trumany, yes we did. We even went to far as to prevent the power supplies from turning on at all just to ensure that they weren’t there.
We ended up discovering that the solution was to remove a pull-up resistor that we had tied to FORCE_RECOVERY. When the line was floating instead of pulled high, the Jetson started up without issue. I imagine that this is because FORCE_RECOVERY is considered another I/O on the Tegra chip. Pulling it high would therefore also screw up the boot process like any other line.