We have recently developed a custom carrier board for a camera system based around the Nano or TX2 NX. Our Jetson modules boot fine when using the Auvidea JN30 carrier board but not when plugged into ours.
Probing shows that power is getting to the module, but current draw is very low (sub 35mA for the whole board). We have also checked that the MCU is toggling the power enable line high when we press the power button. I’m really struggling to see what we are doing differently to the reference designs.
Would anyone be able to take a glance at the attached schematic and tell me if I have made a mistake in the board design or perhaps got the GPIO boot sequence wrong?
I’ve had a look at your design, and there is nothing that I can point my finger to immediately.
However, I’ve got an idea. You are using a MOSFET with pullups for the TX uart lines and a resistor devider in the RX lines. My approach has always been to use a proper dual-voltage level shifter like these
in order to have a better isolation and a higher driver strength in both directions.
The SOC uses pull-ups and pull-downs as configuration straps on various pins, and the resistor divider may trigger a wrong boot configuration. The 74AVC-T are high-impedance at the input and don’t trigger this behaviour.
BTW. I find your way of generating 1.8V with an OpAmp amusing. Never seen this before.
We have tried removing R84, R85, R86, R87, R138, R139, R140, R141, R189, R190, Q12, Q14 to completely open circuit the UART pins. Unfortunately this does not appear to have had an impact and the system still fails to boot.
Holding down the force_recovery pin also makes no difference.
We have tried open circuiting the sys_reset pin, would we b better off connecting this pin directly to 1V8?
Is there any UART terminal output during boot? I’m curious just how far boot gets, but you’d need at least some UART console output. One reason I ask is that if the RX line is in the wrong position, then it would drop into the boot console. If the the TX line works, then you could at least see that. In fact, if you could put an oscilloscope on the TX line and verify if there is activity, then that would help. This of course depends on having designed serial console in for boot logs, and having it configured correctly.
An interesting consequence of an incorrect device tree configuration for serial console is that an unexpected UART with activity on the RX line (even if it is just pulled incorrectly to the wrong logic level) is that this could also drop into serial console, plus the expected console, when not being the actual console, would never show activity. Is your device tree correct relative to serial console, regardless of whether you want it enabled or not enabled?
The UARTs are using a 1.8V to 3.3V level converter MOSFET. Can you provide the same RX/TX/rail oscilloscope images for the 1.8V side? I’m curious if perhaps the signal works on the other side of the level converter.
Hi all, I’m one of Colin’s coworkers. He’s not at work for a few days so I’ll reply in his stead.
@linuxdev
We’ve removed all UART circuitry so each UART is an open circuit now (see Colin’s message on Feb 6 for a list of components removed). The oscilloscope images above are actually the 1.8V side, these are the raw Jetson pins with no associated pull ups or level shifters.
@mhd0425
To my understanding the SYS_RESET* pin is used to enable downstream power supplies after the initial boot sequence has completed, we’re thinking of using it to enable a USB hub we have on the board but weren’t sure yet hence we put a no-fit 0R resistor. I’ve monitored the SYS_RESET* pin during startup and it remains low, and considering the Jetson’s power draw doesn’t rise above ~35mA this makes sense to me as I doubt any booting/power up has occured whatsover.
The pin we’re using to trigger boot/power up of the Jetson is the power enable pin, activated by an onboard MCU. Is this incorrect and we should be doing something with the SYS_RESET* pin as well?
Based on the Product Design Guide 5.1.1 “Power Handshake Signals”, Once Power_EN is driven high and Power-ON sequence is finished, SYS_RESET* is pulled high. This is used by the carrier to enable USB for example.
But, see the Note:
The carrier board cannot drive high or pull high any signals that are associated with the
module when the module rails are off. If the designer cannot guarantee a signal will not be
driven or pulled high, then either the power rail related to that signal should be left off, or the
signals would need to be buffered to isolate them from the module pins. The buffers should only
be enabled towards the module when SYS_RESET* goes high.
So, I see you activate Power_EN with an MCU which is also connected to SOM UART, right? This could be a problem.
I think you can also monitor SHUTDOWN_REQ* during power-on.
SHUTDOWN_REQ* is not driven during power-on. It is pulled up to the 5V supply, so stays
inactive.
I don’t know if the 1.8V side requires or allows any kind of pull-up or pull-down. Just for the sake of being thorough though, I’ll suggest double checking that.
The device tree is also related to UART operation defaults. You might want to post the “serial@<hex address>” entries (I couldn’t tell you though which address goes to which UART, but someone knowing that particular Nano could answer). You might also compare it to the stock Nano with respect to flow control and “compatible”. The “compatible” part is how drivers are marked as usable at that address, and flow control can cause a seemingly perfect setup to fail send or receive. Check the CTS and RTS pins on the oscilloscope to see if they are doing as you expect. The “status” should also be “okay” in the device tree if the UART is enabled.
When you flash the board, do so on command line and log it so you can verify where/how device tree is added.
Hi all, thanks for your replies. I’ve managed to source the problem and get the system to boot. Turns out for some reason the PWR_EN line needs to go high as 5V power is delivered to the board (i.e. to within a very small time frame). In the reference carrier boards this is done by some gate logic, but in our design we used an MCU. When a user pressed a button the MCU would turn on the Jetson by pulling the PWR_EN line high. This led to a long delay between power being delivered and PWR_EN going high and it now seems this means it doesn’t work. To boot, it seems the PWR_EN line must coincide with power being delivered to the board. This seems strange to me as I don’t know why you’d even have a PWR_EN line if it needs to coincide with power being applied, I wonder if anyone has thoughts on why that might occur?
Also our UART circuitry works as I’ve managed to get a debug console and write to it so the method we’ve used is good.
PWR_EN line needs to go high as 5V power is delivered to the board (i.e. to within a very small time frame)
I don’t think this is necessarily true. See 5.1.2 Power Sequencing. You can disable auto power on with a jumper and boot by grounding power button on the dev kit even
