Unable to setup Headless Operation on Jetson Nano TX2 on Custom Carrier Board

Hi Trumany
Thanks for your response.
I believe your query relates to the version of the Jetson Nano Carrier board we’re using. We are actually using our own custom carrier board, so I think our answer would be immaterial.
The crux of my previous query…
“Could I please get an explanation why there is this dependency on the RX pin of UART2? Is this dependency documented?”
…has to do with the Jetson Nano TX2 module (not carrier board), and its requirements for booting consistently, and properly.
If you re-read my previous post, you may infer that I believe the Jetson Nano module’s Jetpack firmware (or even lower-level boot firmware) is not handling the UART2 RX pin properly. Or else I have not seen the documentation for the actual boot dependency in the Jetson Nano firmware on the status of the UART2 RX pin - which information would facilitate proper implementation onto any carrier board.
Or, are you saying that there are different versions of the Jetson Nano module that have different circuits on the UART2 RX pin? Are schematics available for these Jetson Nano module versions?
Thanks.

There are different nano modules, A02 and B01. You can search relevant topics in forum. The schematic of modules are not released.

BTW, what do you mean " Jetson Nano TX2 module"?

I don’t know. Here is the module we have:
https://www.arrow.com/en/products/900-13448-0020-000/nvidia
On the card, the model is identified on the PCB overlay: P3448 180-13448 DAAA-B01.

So if we have the B01 variant of the Jetson Nano module, then our carrier board (which has no pullup resistor on the UART2 RX line), is correct. However, in practice we note that the boot performance of these modules changes if there is no pullup resistor on the UART2 RX pin, with some modules not booting properly (ie. microUSB port is not opened to SSH sessions, as our primary symptom and the topic of this thread). When we add a 47kR pullup resistor to UART2 RX pin (to 1.8V), the boot performance on modules which do not boot properly becomes consistent, and proper, and we are able to host an SSH session over the microUSB port.
Please advise.

Do you mean with same B01 modules, some can boot correctly but some can’t, if add 47k pu on the UART2_RX pin of failed modules, they can boot correctly too? It’s strange since they are same version modules. Can you share your schematic of this part of your carrier board?

Yes, that’s what I mean.
Processor1.pdf (389.3 KB)
Please refer attached.

What’s the “D14” for? Did you try remove it and let UART2_RX/TX unconnected totally? If it still fail, you may need to run RMA for it.

D14 is Texas Instruments TPD4E1B06, for I/O pin protection. Reverse breakdown voltage is 5V (bi-dir), and this part is ultra-low leakage. Seems like a silly part to have there, however we’re just leveraging its inclusion elsewhere in the BOM, and this port is not actually exposed in our applications except for debug in controlled conditions. I have not tried removing the part.

An RMA may be appropriate if our Nano modules are faulty, but we think we have resolved the issue by tying the RX line up. I would suggest that an indeterminate pin state on the UART2 RX line could be overcome by coding in the JetPack or Nano boot firmware, and documentation or errata disclosing the dependency of proper boot on the UART2 RX pin.

But only some not all have such issue. Better to try removing D14 to check.

It would be good to see the schematic of the UART2 RX pin front end. Sounds like it has marginal behaviour.