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).
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?
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.
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.
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;
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;
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.
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.
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.