We have developed a custom board for Jetson AGX Xavier, and are having some issues with starting the module.
When following the power-on sequence, the total current draw for the board reaches around 350 mA @ 12V, but there is no kernel log on the module afterwards, and none of the I/O is functional.
Comparing to the development kit, the development kit reaches the same current draw temporarily, but rises afterwards as the OS is booting.
The current powering sequence we are using is the one described within the OEM guide, on page 25, Figure 5-9.
We have verified that the signals sent are correct.
Hope you have any idea to what might cause this issue
Hi, does it enter recovery mode? In addition, as said in OEM DG, “NVJTAG_SEL and JTAG_TRST_N must be low for normal operation and pulled to 1.8V for Boundary Scan Mode.”
It does not appear to enter recovery mode, as there is no valid USB signal on port 0. The positive data line rises to 3.3V, but when connecting a protocol error arises.
NVJTAG_SEL and JTAG_TRST_N are not connected on the board, but they are pulled down on module.
The module pulls carrier power on high, but does not seem to do anything afterwards.
If CARRIER_POWER_ON is high, then the module should be in power on status. It might be some components on carrier board powered up before module and so cause pin status issue.
What pins could cause pin status issue?
The strapping pins, but are there any others?
Shouldn’t the modules power draw also spike when the module is powering on?
The power draw should be around 10W, right?
The carrier board should power up later than module so that all shared interface pins of module would be affected during power on.
That seemed to do it - now we’re at least able to enter recovery mode and the module creates kernel logs.
When connecting to the devkit through the J501 port, how much of the communication is running on UART2?
Is it possible to route the UART terminal through UART2, for debugging further issues?
What’s root cause of can’t enter recovery mode? UART3 is for debug, better to follow that as stated in DG.
A problem with our ethernet tranceiver pulled some of the RGMII pins, which interfered with the powering sequence. Removing the issue, and powering after carrier_power_on has been asserted fixed that issue.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.