Jetson nano booting up issue when connected to UART and SPI interface

Hello,
I am using my jetson nano along with Arduino and a gimbal which are connected to the nano via the UART interface and SPI interface in the GPIO pins. When I try to power on jetson nano after I powered on the other components ie. the Arduino and the Gimbal, the jetson nano screen freezes to the nvidia logo and does not boot up. But when I power on Jetson nano first and then boot up the other component, jetson nano normally boots up.

I am not sure but i think when I boot the Arduino and the Gimbal before the jetson nano, they start sending the data to jetson nano via the UART and SPI which causes the jetson not to boot up but I am not sure ! could this be the problem or is it something else ???

Hello,

Could you please tell me how you managed to configure the SPI interface?
Do you use R32.2 or R32.1? Did you use the pinmux spreadsheet? with which parameters?
when I follow the procedure in the Header Configuration Application Note, at the end I only get the nvidia logo and it stops. However, unlike you, I have nothing connected to the header.
Any help would be appreciated,

thank you

If you are using the same UART as serial console, then I’d expect boot issues. See:
[url]https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/[/url]

Make sure that UART isn’t what you are using.

Is it not possible/advised to use UART1 on J44 header for interfacing to a UART sensor as one might do with UART2?

In my case, I need a second UART so I connected to J44 and had booting issues - which is how I found this post. Is there any way to disable this UART for serial console and just use it as a regular UART?

Edit: After further research, this post regarding the TX1 seems relevant: [url]Disable the default console serial port (ttyS0) - Jetson TX1 - NVIDIA Developer Forums. Would the process for the Nano be similar?

This is serial console on J44. See:
[url]https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/[/url]

Basically any communications is going to (or coming from) a bash console login prompt.

I have not changed this to a different port, but this (or disabling serial console entirely) is a possibility (usually involves flashing a new device tree, but I couldn’t tell you the specifics for this board).

One aspect of device tree is to set up port settings, addresses, that sort of thing. Newer L4T releases running on Jetsons also tend to provide the kernel command line information in the device tree, and part of this is to name a serial console port (or to not name a port).