Suspiciously rapid SYS_RESET Shutdown board

Robotics & Edge Computing Jetson Systems Jetson TX2
1

Hi,

We’ve been designing a custom carrier board for a Jetson TX2/Jetson Nano which has a dedicated MCU to control and interface with the Jetson. One function we have the MCU do is to monitor the voltage rails for power loss detection, and then subsequently command the Jetson to shut down by deasserting the PWR_EN pin, in order to give the Jetson a heads-up warning. We’ve captured this process on an oscilloscope, please see the attached image.

As can be seen, the MCU detects the loss of voltage and deasserts the PWR_EN pin correctly. We’re also monitoring the SYS_RESET pin of the Jetson (which in the image is incorrectly labelled as SYS_WAKE, sorry) as an indicator that the Jetson has shutdown.

In the scope capture the SYS_RESET pin goes low about 50us after the PWN_EN pin is pulled low by the MCU. This seems incredibly fast for a shutdown - especially considering that the product design guide states that SYS_RESET takes ~82ms during startup after PWR_EN. Is such a rapid response considered normal behaviour?

Thanks.

Sudden Test
Sudden Test1024×829 30.7 KB

4

Is it for TX2 or nano? They are different on some parts as you can see in TX2 and nano Design Guide.

And as said in nano DG: SYS_RESET* is not asserted externally during the power-down sequence. When POWER_EN is de-asserted, the PMIC performs a power down sequence that includes asserting SYS_RESET*.

There is no strict timing request on that. You can compare to the timing on devkit with same module.

5

This capture was done with a TX2.

6

Then which signal do you mean about “PWR_EN”? There is no such signal in TX2 reference design.

7

Apologies, POWER_EN.
Pin 237.

8

There is no pin 237 on TX2 design. Do you mean TX2 NX? If TX2 NX, it is same to nano. And so as said: SYS_RESET* is not asserted externally during the power-down sequence. When POWER_EN is de-asserted, the PMIC performs a power down sequence that includes asserting SYS_RESET*.

There is no strict timing request on that. You can compare to the timing on devkit with same module.