Jetson Nano reboot failures

Hi,

I have a custom carrier board that utilizes the jetson nano. The power on circuit and timing for power_enable to turn on the nano appears to be working as intended (similar to dev kit power_en circuit), however after a couple power cycles the nano is not able to boot.

There is no discharge circuit like the dev kit but I have even removed large capacitors to improve the discharge of the carrier board. I have looked through all reference documents but cannot find exactly the shutdown circuit timing for the nano and what the carrier board needs to do. Is cutting power to the board effecting the power off/on cycle causing the reboot to fail (cannot boot linux).

Thank you.

Hi rene23,

Could you provide the serial console log for further check?

Hi, as you can see in nano Design Guide, there are below power down requests. Have you checked the power down sequence on your board before?

Hi,

I have checked the power down sequence in figure 5-6 is fulfilled so that the device power enable is triggered low of a minimum10ms before the voltage input reached 3V. We do not have power down’s initiated by shutdown req*.

I would like to add that this does not happen on all the nano modules I have, however the few nano modules that have this problem boot fine on the dev kit. For more context, when the nano is powered with our carrier board and it fails to boot, I have turned off the carrier board, placed that nano into a brand new carrier board (never been turned on) and the nano fails to boot. It looks like the nano has its own discharge as there is voltage present after its powered off and isolated, or a state that is not being addressed when being turned off that causes it to fail on the next turn on. Do you have more information that could cause this behaviour?

Thank you, Rene.

Hi,

Since the nano does not boot, i cannot capture the serial log, is this a file on the nano as well?

Thanks

I am not sure if your were able to see my previous reply, however to confirm the figure 5-6 i am sharing images of the shutdown timing. From the scope blue is the POWER_EN and yellow is the VDD_IN. You can see 3V is supplied for ~39ms.


Is there no any serial logs output after powered up?
Log file could be found in /var/log/syslog

If it can’t repro with devkit, then should be your carrier board design issue. You can compare the sequence to devkit to find out difference. The key point is to let carrier rails of shared I/O off earlier than module.

Can you be specific of what shared I/O’s would cause boot up problems, does this include all signals (i2c, serial, usb/hdmi/gpio)?

Hi Trumany,

After testing with 30 of our carrier boards and nano modules, 3 of the 30 experience this issue whereas the other 27 work every time across our carrier boards. Here are the serial numbers of the failing nanos;

1423321072978,48B02D3E8745,699-13448-0002-401
1423321074515,48B02D3E9772,699-13448-0002-401
1423321073511,48B02D3E96FC,699-13448-0002-401

Thank you, Rene.

Hi KevinFFF,

In the syslog i do not see any text about failure to boot. I had the device running on initial boot around 9:30. When i restarted the device i had nothing and had to wait a couple hours before i could try again. Attached us the file of the log.
nvidia-fail-syslog.txt (40.8 KB)

After testing with 30 of our carrier boards and nano modules, 3 of the 30 experience this issue whereas the other 27 work every time across our carrier boards. Here are the serial numbers of the failing nanos;

1423321072978,48B02D3E8745,699-13448-0002-401
1423321074515,48B02D3E9772,699-13448-0002-401
1423321073511,48B02D3E96FC,699-13448-0002-401

Thank you, Rene.

Can all three modules boot with devkit carrier board? If yes, it is not module issue then. It looks more like your robust issue of your custom board.

Yes, all interfaces are shared b/w module and carrier. For carrier power rails, it mainly means 3.3V and 1.8V.

Hi Trumany,

I have a discharge circuit pulling down the 3V3 and 1V8 rails as seen below, and yet these 3 Nano S/N’s I shared above are unable to reboot after a certain period of time. The module’s power (5V0) is discharging slowly and is last off, which can also be seen from these images.

Does this point to an issue with the Nano Modules.

(Blue is Power_Enable, Yellow is Voltage Rails)
1V8 Discharge
3V3 Discharge
5V0 Discharge to 2V

Rene.

Would you share your power ON/OFF logic circuit?

Hi, as you can see in the power down sequence in Design Guide, T<1.5ms for 3.3V and <4ms for 1.8v.

Hi mhd0425,

Please see the attached for the logic on/off Circuit. First picture is the power_enable turning on 400ms after 5V is asserted high. Second image there is ~20ms when power_en is asserted low for 5V to drop to 3V3. The last two images is Sys_Reset for ON and OFF situations. We do not initiate shutdown with shutdown_req, we just have sudden power loss.
Logic_ON
Logic_OFF
Sys_Reset_ON
Sys_Reset_OFF

Thank you, Rene.

Hi Trumany, I have modified the discharge circuit so that the 3V34 rail is discharging in that time. Unfortunately there is still a reboot issue.


Thank you, Rene.

do you think you don’t need shutdown_req*

Sorry I am not sure what you mean, shutdown_req* is an output from the nano used when the device has to shutdown. I do not see any timing requirement held to shutdown req that results in preventing the OS to boot.

Do you have shutdown_req* high?