Custom carrier board designed based on the Jetson Nano Developer Kit carrier board reference design.
Module: Jetson Nano production module, 16GB eMMC (no SD card).
Module boots successfully on the official NVIDIA Developer Kit carrier board P3541.
Module does not boot on our custom carrier board.
Custom carrier board input is 31V, stepped down on-board to 5V for the module.
Steps completed:
Confirmed 5V is present at the module’s SO-DIMM connector pins.
On the official dev kit, powered from a 5V bench supply, current draw shows fluctuation during boot. On the custom board, current draw was constant at 0.15A with no fluctuation.
Disabled auto power-on via jumper. POWER_EN is now asserted only via a manual pushbutton, well after 5V is stable.
Monitored POWER_EN and SYS_RESET* (module output) with an oscilloscope: SYS_RESET* goes high approximately 100ms after POWER_EN is asserted.
Confirmed FORCE_RECOVERY* is high. No NVIDIA APX/recovery USB device enumerates on a connected PC when the board is powered.
Connected a serial debug cable (same cable, USB-to-serial adapter, and terminal software previously used successfully with the dev kit) to the custom board’s debug UART2. The dev kit produces boot log output; the custom board produces no output at all.
Debug UART2 on the custom board routes through an NTB0102DP dual-supply level translator. OE is pulled up to 1.8V (VCCA rail). On the module side (A-side) there are no pull resistors on TX or RX. On the adapter side (B-side) there is a 100kΩ pull-up on RX only.
Bypassed the on-board 31V-to-5V regulator and fed the 5V rail directly from a bench supply (5V, 3A). The 5V rail is a single shared PCB power plane supplying the module as well as other on-board circuits; it cannot be isolated to measure module-only current.
With the bench supply, maximum current observed at power-up is 0.7A. When POWER_EN is triggered, current drops to 0.64A and remains constant, with no fluctuation.
Reconfirmed SYS_RESET* still transitions correctly (~100ms after POWER_EN) under this bench-supply configuration.
Scoped VDD_IN with an oscilloscope during power-up and POWER_EN assertion.
Measured MOD_SLEEP* (module pin 178): reads approximately 0.2V (not 0V) and stays low continuously. On our board, this pin is tied to the EN pin of an AP22804B load switch, with a 100kΩ pull-down resistor to ground.
Re-tested the same physical module on the official NVIDIA dev kit; it boots successfully, confirming the module itself is functional.
Current status:
POWER_EN → SYS_RESET* handshake completes correctly and consistently, including under a clean bench 5V supply.
No UART output is observed on the custom board with a proven-working debug cable/adapter/software combination.
Current draw remains flat/non-fluctuating after SYS_RESET* goes high, both on the original board power path and on the bypassed bench supply.
MOD_SLEEP* remains actively driven low.
Looking for guidance on what else could prevent the module from executing/booting under these conditions.
Thank you for your reply. I assume your question relates to whether I have a damaged board. Yes, I tested on a few PCBs that were produced from this batch. The results are the same. The custom board that I have is used to operate some process; thus, it has additional connections to relays and sensors. The HDMI, USB, Ethernet, and boot are the same as in the reference design. I am attaching images of the schematics for SO-DIMM connections.
Could you please confirm whether your custom carrier board follows the power-up sequence specified in the Design Guide, particularly the sequencing between SYS_RESET* and the carrier board supplies?
In your schematic, the enable pin of the VDD_3V3 regulator is not controlled by SYS_RESET*, which differ from the reference design.
I followed up on your recommendations and cut the EN trace of the VDD_3V3 regulator from Vin and connected it to GND (for initial test). I also noticed the HDMI 3.3V and 5V load switches were incorrect PNs with the EN pin enabled low. I depopulated these switches from the PCB.
The first few attempts to start the PCB showed variable current supply. In these cases, I saw the MOD_SLEEP pin go high for approx. 7-10 seconds and then go back low.
As my next steps, using a jumper wire, I connected the SYS_RESET_J signal (from S1, pin 4) to the EN pin of the VDD_3V3 regulator. When I press the Power button and get POWER_EN high, I see the VDD_3V3 output go high (visible indicator (ex. D186). However, the current remains constant, and the MOD_SLEEP signal is always low.
Please depopulate R918 and pull up the PWR_BTN signal to 5V through 10kΩ resistor, as implemented on the reference carrier board. Then, please test the board again.
Could you please depopulate the following components and then verify, using an oscilloscope, that the relevant signal and power-rail timings follow the power-up sequence specified in the Design Gude?
I removed the component and didn’t see any changes. I took measurements of the POWER_EN and SYS_RESET_J signals in both cases: the VDD_3V3 EN pin connected to GND and the VDD_3V3 EN pin connected to the SYS_RESET_J signal.
These are the POWER_EN and SYS_RESET_J signals when the VDD_3V3 EN pin is grounded:
SYS_RESET signal is open-drain and pulled up to 1.8V. Therefore, it should not be possible for this signal to swing between 2V and above 6V when connected to the enable pin of U526.
Could you please verify that the modification has been implemented correctly?
Also, with SYS_RESET connected to enable pin of U526, please capture the following waveforms:
I apologize for the delayed response. I was on vaction and was unable to continue testing.
Before the vacation I looked into the datasheet of the TPS54308 (U526). And the EN pin has a built-in pull-up current source. Based on your previous comment, the SYS_RESET signal is an open-drain signal that is pulled to 1.8V. I assume the PMIC on the SoM releases the gate of the NMOS, thus pulling SYS_RESET high to 1.8V. Since SYS_RESET is also connected to an internal pull-up of the U526, this can explain the 5V signal observed in previous measurements. To rectify this, I built a quick inverter using a cascade of NMOS FETs. Right now, I see the following situation where the POWER_EN pin goes high (I repurposed a SparkFun level shifter board).
Since POWER_EN drops low after SYS_RESET is deasserted, could you please capture the following four signals simultaneously on the same oscilloscope screen?
First, I would like to thank you again for your support. I really appreciate it.
Regarding your request to capture four signals on the same screen. Unfortunately, my oscilloscope is only a two-channel device. I captured all signals using the POWER_EN signal as a trigger. Also, one point to keep in mind: I shorted J172 on my board to prevent autoboot. Thus, the POWER_EN signal goes high only after the Power push button (S3) is pressed.
According to the captured wave form especially “SHUTDOWN_REQ (FORCE_OFF)”, POWRE_EN appears to go low because the module asserts SHUTDOWN_REQ after SYS_RESET is deasserted.
As described in the Design Guide, SHUTDOWN_REQ may be asserted due to a thermal shutdown, a power-bad condition, or a software shutdown. Since this issue occurs during the initial power-up sequence, we recommended investigating a possible power bad condition.
I assume that at this step, the only power-bad condition can be related to the 5V supply. In this custom carrier board, the 5V supply also feeds the 3.3V and 1.8V supplies: 5V(U525) => 3.3V (U526) => 1.8V (U524). Thus, as these supplies are turned on by the SYS_RESET signal, there might be a dip in the 5V supply at the SO_DIMM connector. Thus, I used CH1 as a trigger when 3.3V comes alive to see the effect on the 5V (CH2) at the connector. The coupling on CH2 is AC, and the range is 200mV/DEC.
The 5V bulk and local decoupling capacitor configuration differs significantly from the reference carrier-board schematic. The difference may be contributing to the observed 5V voltage drop.
Please review and optimize the 5V power-supply circuit, including the bulk and local decoupling capacitors, based on the reference design. We also recommend reviewing the other carrier-board power rails.
Based on the images, the power issue is resolved, but I still see that the MOD_SLEEP signal is low. I also captured the UART2_TXD_JET signal to see if there are any messages coming from the SoM. Since U168 was depopulated (based on your request on Aug 27), the probe was placed on a pad of the U168 (Pin A2).
