So – I’ve got the Jetson Nano new out of the box today – Opened by me. I downloaded the SDHC formatter, ran it. I downloaded the image and loaded it with Etcher. Then, when complete, I put the card into the spot on the Nano.
Connected ethernet cable to RJ45 jack. Connected HDMI to computer monitor. Plugged in a logitech receiver for a wireless USB/Mouse Combo
I tried powering it with a 5V 2.5 A power supply via USB-mini port – green led came. But no video output.
Tried two different HDMI cables on two different computer monitors. Restarting each time. Nothing.
Reading that power supplies might be an issue – I upgraded to a 5V 40A Mean-Well power supply and a DC Barrel Jack connector. Connected the jumper near the DC Barrel jack, and powered it up. Still nothing.
I’ve reformatted and reloaded the image twice. Am using known good cables on known good monitors, and I’m monitoring the power on startup with an oscilloscope. Upon plugging in the power box, and monitoring a 5V pin on a header – it shows a steady rise from 0V to 5V over the course of about 12 ms.
Other than the green-led lighting up, I’m not really seeing any other signs of life from the board. The RJ-45 magjack has integrated LEDs that are not active.
What other trouble-shooting steps can I do? What might I have missed?
Hi, the schematic and board files are not released yet. You can check the user guide first for the setup steps and especially for the configuration of connector J40. If still fail with correct settings, the board might need RMA.
[url]https://developer.nvidia.com/embedded/dlc/jetson-nano-dev-kit-user-guide[/url]
What size uSD card are you using? If it is greater than 32GB such as 64GB, then you need to format it as ExFAT before burning the image on the card.
Also, if you are using Etcher on Ubuntu x64, then run GParted against the device instance of the uSD and click Ok when prompted to allocate the remaining space on the card. Then eject the card and place it in the Nano.
If you have a FTDI to USB cable, then plug to J44 and see if anything shows on the console output.
Another Jetson Nano is coming today – so I should be able to determine pretty quickly if the problem lies with me or with the board. If it is with the board, I’d still like to know what’s going on.
@Trumany,
That’s a shame about the board files – I’d love to learn more about the design. Do you happen to know if the boards are individually tested after fabrication and again after assembly? That information might
The issue persists despite J40 settings. (J40.7 & J40.8 jumper/shorted while J40.1 & J40.2 temporarily connected via momentary SPST switch as well as auto-power on with no connections)
@jonnymovo,
I used as 16 GB SDHC class 1 as suggested – but that information is good to know should I ever upgrade. I used Etcher on Windows 10. I wasn’t aware that etcher existed for Ubuntu – I suppose that’s much safer than the old school dd from the CLI.
I have an FTDI to USB cable – but I don’t know the baudrate – so I yanked out the old trusty Tek MDO3104 scope – and on about every third boot I see a few bytes of data.
Here’s another weird thing that may or may not be related – I connected the recommended fan (Noctua something or other) during one of the power on tests, and it did not immediately spin up. It would pulse every moment or two, but wouldn’t spin until I gave it a finger-start. All the while, the power supply into the board shows a rock-steady 5.01 V DC with negligible ripple. 5V and 3.3V lines on the header seem fine as well.
Like I said – I’ve got another one coming a bit later today. Once it arrives I’ll know more. Thanks again to both of you for your time!
It’s taking it’s sweet time scanning it. Anyways, while I wait for the new board to arrive sometime today, without schematic and board files, I’m limited to optical inspection.
The image I’m attempting to attach shows the lower left quadrant of the top side of the PCB. Approximately one centimeter above the upper left edge of the display port and HDMI connector. It’s not unique – but it shows that the annular rings were allowed to be dangerously close to other nets. I wouldn’t be surprised for those nets to connect during the manufacturing of some of your boards.
I’m going to keep looking to see if I can visually identify a short on my board.
NOTE: The minicom setup is :
“Connection speed is 115200, with 8 bits, no parity, and 1 stop bit (115200 8N1). For these three wire cables, the correct setting is software control, no hardware control. If you choose a 5 wire setup with RTS and CTS lines, then select hardware control, and no software control”
I’m having this same problem. I’ve noticed I’m not getting power to the USB ports, does this mean there’s a hardware issue or is the USB brought up during boot (indicating it could be a boot image problem)?
wjxxwh & mwt2sfek,
After reading the forums when my problems first started – the overall advice from the forums (and from myself) seems to be this:
Use a 5V 2.5A+ power supply on the USB port (2.5 A or greater). If that does not work, place a 2.54mm jumper across J48.1-J48.2 and use a 5V 2.5A+ power supply on the DC Barrel Jack connector (You might be able to temporarily steal it from your cable modem / wireless router)
a) Monitor the voltage with an oscilloscope during startup. The voltage should not dip. If it does, your power supply is insufficient for the task at hand.
b) Your power supply is likely a switch-mode power supply. There should not be excessive output ripple.
Try a different SDHC card.
Hook up a UART-USB converter to the debug header (J44) and monitor the boot sequence via a terminal program such as Putty. 115200 baud. If you get data, it should tell you what errors exist and give you a place to start. If you get no data – it’s likely a power supply/power delivery problem.
The problem I identified in the pictures above is likely unrelated to the problem I have with that board. I brought it to NVIDIAs attention because it might cause them to reject more boards than necessary during fabrication. The trace/space violation would cause short-circuits that can be identified after fabrication but before assembly. AOI & flying-probe would catch those sorts of things (if those tests are performed). Where things get interesting is in the intermediate layers of the board. A short circuit there wouldn’t be seen by AOI – and flying-probes occasionally (it’s rare, but it happens) fail to identify short-circuits.
Alternatively, it could be an assembly problem – Sometimes things happen during assembly that affect the performance of a board – insufficient solder causes open circuit and intermittent errors. Too much solder can cause parts to float and create open-circuits.
I’m probably going to have to stop investigating the issue for now. Arrow sent me out a new board (it worked), and without the schematic/board files, there’s only so much I can look for. I’ve got a buddy with an x-ray – maybe the next time we grab lunch I’ll put the board in and take a closer look.
Nvidia guys,
Arrow sent me a new board, and it works. Should we close this ticket out?
Two other quick things:
My apologies to the EE who did the layout for the board, whose week I may have ruined.
Is there a manufacturing equivalent of a bug-bounty? 'cause there’s a university team I help advise on the rover challenge http://urc.marssociety.org/ – they use the NVIDIA Jetson TX2. I don’t think the students would say no to say a 15-20 minute phone call with an NVIDIA engineer on how to better utilize the device for their specific task.
Thanks,
Mark
Someone at work also had a nano, so I borrowed it, swapped over my monitor, SD card and power, and the new one booted right up. Should I just return it to amazon or is there an RMA process through NVIDIA I should use?
Trumany, there is a slight problem. Arrow told me I didn’t need to return it, and you guys didn’t ask me to RMA it, so I passed it off to a buddy that has access to X-ray inspection equipment at a PCB assembly house in Denver. He was going to have it gone over to see if the problem can be identified and corrected. I’m pretty sure its already in transit.
