We are trying to backup graceful shutdown in our carrier board. During process, we observed that shutdown_req pin is not getting asserted when “shutdown-h” command is given. We confirmed the observation in eval board too.
To further look into issue, we set GPIO_01 high in eval board when internal shutdown command is given. This pin remains high for approx 8 sec & goes low. Looks like Jetson shutdowns completely (GPIO_01 goes low) but shutdown_req pin is not asserted.
Could you please advise what could be the issue or we miss some configuration as shutdown_req pin should go low (after FW shutdown command) CH1-shutdwn req CH2-GPIO.bmp (1.8 MB)
as per attached figure from product design guide.
Hi, SHUTDOWN_REQ* is driven active (low) by the module if the system must be shut down, due to a software shutdown request, over-temperature event, undervoltage event, or other faults. The power control logic on the carrier board must drive POWER_EN inactive (low) if SHUTDOWN_REQ* is asserted.
Have you probe it correctly? Also have you probe the POWER_EN? If SHUTDOWN_REQ* is not asserted, POWER_EN will not be asserted either and system won’t power off.
Reconfirmed & looks like we are using correct probing, please find attached here. Apart from this we do get power down message from UART, so Jetson shuts down but shutdown_req not getting asserted. CH1-PWR EN & CH2-GPIO In EVL Board.bmp (1.7 MB)
Attached is screen shot of Power_EN Vs GPIO_01. Here GPIO_01 gets high after internal shutdown command but you can see Power_EN doesn’t go low. However, before both Power_EN/ GPIO_01 go low we get power down message on console.
Have you zoom in the waveform as it might be a ~10us drop on shutdown_req and then the latch will be cleared by power_en? And which pin do you mean the GPIO_01?
After sudo shutdown, we noticed ~18us dip in shutdown_req but just before module power off. The product design guide looks like using shutdown instead of module OFF in section 5.1 which led to the confusion. Due to this, we looked to shutdown_req just when internal shutdown command was given.
However, actually it is after shutdown command, there is time period of 7-8 sec after which shutdown_req goes low & module turns OFF. I have attached few waveforms in different time bases. Please check & advise if we understand correct.
I don’t understand what your question is. The sw shutdown command will let shutdown_req go low as you can see a ~18us drop, right? Are you testing on devkit or custom board?
Yes, we are testing on eval board. Questions is we see shutdown_req going low (for ~18us) after time period of 7-8 sec of shutdown command initiated in SW. So is this correct & expected behavior? We were under impression that shutdown_req should go low instantly when shutdown command is initiated in SW but actually it goes low after 7-8 sec.
I hope things are clear. Awaiting your response to confirm our observation.
No system is in process of shutting down after initiating software shutdown command but shutdown_req signal appears after 7-8 second of initiating shutdown command. It looks like shutdown_req goes low after finishing process of shutdown. Also after shutdown_req goes low, module is powered OFF.
I hope you get my question & I just want to confirm the behavior we observe. Also you/ your team can check is on dev. kit & then let us know. Awaiting your response.
It looks fine as sw shutdown indeed will print some log on the console first before shutdown. So “sudo shutdown -h” does not immediately shutdown the device.
