Orin Nano Module goes to Recovery mode after 30-40s of Power up?

Hi Nvidia Team,
Hope you are doing Well !

We are facing Orin Nano Module going into recovery mode after 30-40s after power On in our new developed Integrated motherboard(IMB)** using Orin Nano. I need Nvidia support in understanding and resolving this issue.
Sharing some basic details which we are following:

  1. VDD_IN to orin nano 5V.
  2. Module ID pin is floating in our IMB. Also checked it with Pull down but no improvement.
  3. We are suspecting SSD is not working with Orin Nano module but same SSD is working with the Devlopment Kit of Orin nano. SSD which we are using is MTFDHBK064TDP-1AT12AIYY.
  4. I also followed Booting sequence provided in design guide. Screenshot of waveforms captured and attached.
  5. Carrier Board Supplies 5V, 3.3V and 1.8V is generating using System Rest pin, Which enables PIMIC IC used to generate them. Also all these volatges comes after system Reset is high from Orin nano Module power up.
  6. Sutdown pin if pull up to VDD using 4.7K resistance. Tried it with 100K as well but no improvement.

Adding SSD Schematic for reference.

Please share full UART/Boot logs. Did you try with one of the NVMe on the SCL

Hi,

  1. UART logs are not coming and we didn’t made any option for SCL to connect with NVMe.

Need clarification on below points as well:
We are facing issues while booting the Orin Nano.
We need assistance with the following checkpoints to ensure everything is set up correctly:

  1. How can we confirm through the command line or any other method that the Orin Nano is reading the image from NVMe?
  2. Could the issue (30-40s recovery mode) be caused by the NVMe not being connected to the Orin Nano?

Hi,

Just to clarify. If your board is really booting up, then no matter what case, there would be at least bootloader log coming out on UART. That log will print even without a NVMe connected. Bootloader is coming from the QSPI flash memory on the module itself. It is not on the NVMe. We don’t need to care about whether your board is reading things from NVMe at all.

Thus, unless you are actually not dumping log from uart, it is not possible “UART logs are not coming”.

If UART log is truly not coming, it means your hardware side has problem. In this situation, there is no software running on the board. It is pointless to “check Orin Nano is reading image from NVMe”…

In brief, I think it is a total hardware problem.

Some observations from the scope shot provided. VDD_IN seems to have around 1Vpp noise superimposed. Is the output voltage set around 5.5V? Is that actual noise or something getting captured maybe due to long ground on the probe? Similar noise on C2 and C4 channel signals. Any reason why the C2(SHUTDOWN_REQ*) signal is Clipping? Amplitude seems to be 6.4V? If module is powered by 5V, then from where this 6.4V signal level is coming?

Hi,
I am able to log UART, earlier I am checking it on different UART other then Debug.
Attaching the logs.
After analysing the logs I am suspecting Orin Nano is searching for EEPROM which is mounted in Dev. Kit and I haven’t added it in my circuit.
Kindly suggest next actions after verifing the logs.
IMB_WITHOUT_NVME.docx (35.3 KB)

What did you change now and then? I mean you couldn’t even get a log yesterday but now you could get a log.

Please read software document. You need to disable CVB eeprom so that you could bypass this error. This is common for every custom board.

Also, just to clarify. this error and your “module keeps going into recovery mode” could be different error. You should test more after you apply above software patch.

We are able to boot the Orin Nano through our custom board after adding EEPROM at required I2C, but the problem is that we want to bypass the EEPROM reading process. We made the necessary changes as mentioned, but it is still trying to read the EEPROM.

What we did:
We searched for the file named “tegra234-mb2-bct-misc-p3767-0000.dts”, which is specific to our board. We verified this through the SDK and then made the following change

- cvb_eeprom_read_size = <0x100>   
+ cvb_eeprom_read_size = <0x0>  

Could you assist in checking if we missed something or if there is anything else we need to verify?

There is no update from you for a period, assuming this is not an issue anymore.
Hence, we are closing this topic. If need further support, please open a new one.
Thanks
~0409

Is this still an issue to support? Any result can be shared?