Keep on getting shutdown req* in unbuntu 20.04 but this is not happening in unbuntu 18

malakondareddy · August 9, 2024, 1:41pm

Hi All,
I using my own (Custom) carrier board with Jetson NX xavier for my application. In the custom carrier i have a STM32 micro controller to take care of power sequence and shutdown REQ* command action. However I have not faced any issue with same STM32 firmware and with unbuntu 18 but I am getting shutdown REQ* from the jeston without issuing anything from command (user). At this condition all other parameters are with in limits (Temp, load average, voltage level).
Also I did not see any folders in /opt/ati with unbunt 20 but it is showing many folders with unbuntu 18 (attached image).

Please kindly let know where the problem.

KevinFFF · August 12, 2024, 2:38am

Hi malakondareddy,

What’s your Jetpack version in use?
Please share the result of the following commands on your board.

$ cat /etc/nv_tegra_release
$ cat /etc/nv_boot_control.conf

Could you elaborate what’s your issue now?
Do you mean that your Jetson always send Shutdown REQ unexpectedly?

malakondareddy · August 12, 2024, 5:40am

The output of the cat /etc/nv_tegra_release is

R35 (release), REVISION: 3.1, GCID: 32827747, BOARD: t186ref, EABI: aarch64, DATE: Sun Mar 19 15:19:21 UTC 2023

The output of the cat /etc/nv_boot_control.conf is
TNSPEC 3668-300-0001-B.0-1-2-ati-carrier-p3668-v1-
COMPATIBLE_SPEC 3668-100—1–ati-carrier-p3668-v1-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE mmcblk0
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x19
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0

We have designed a custom carrier board based on Nvidia’s reference design files and have successfully used it for the past six years without issues. Our carrier board incorporates an STM32 microcontroller to manage the Jetson power on/off sequence with precise timing. Recently, we upgraded from Ubuntu 18.04 to 20.04 and modified the STM32 code to handle USB resets and other peripheral power states based on Jetson UART messages.

While the updated STM32 code functions correctly with Ubuntu 18.04, we are encountering the following issues with Ubuntu 20.04:

Issue 1: The Jetson NX Xavier unexpectedly sending the shutdown REQ* signal to the STM32, causing the board to repeatedly restart. This was verified by probing the shutdown REQ* pin and monitoring through the UART debug port.
Issue 2: The folders in directory “/opt/ati” were not there, and it did not reappear after pressing ctrl+Z. This was confirmed using the “ls” command in the terminal.

Note: I main difference updated STM32 and older version is enabled the UART and added few lines to handle USB RESET and other peripherals ON /OFF. Our suspects is not STM32 new code, since it is working with unbuntu 18.04 without any issues.

KevinFFF · August 12, 2024, 9:51am

I have to clarify that we use L4T rather than Ubuntu even if it is based on Ubuntu release.

Would you hit the similar issue on the devkit board?

Is there any serial console showing at this moment?

They are using different release so that the rootfs may change. May I know what’s your use case to get this folder?

malakondareddy · August 14, 2024, 6:29pm

Hi Kevin
Thanks for your information.
I was able to solve the that issue by writing proper power UP and down sequence. But I am facing one issue which is when I do SW sudo shutdown from command terminal I did not see corresponding GPIO going LOW. This I observed in oscillation scope on that GPIO pin.
Can you suggest where to see this GPIO enable code in NX Xavier code?
Also it would be helpful if you provide a code that you written in DEVkit board for power sequence. This is only for my reference to avoid mistakes. Atleast flow chart or timing diagrams. I couldn’t understand this properly that is given in NX Xavier design guide pdf properly.
Thanks with regards,
B Malakondareddy

KevinFFF · August 15, 2024, 9:58am

Which GPIO would you expect to pull LOW during shutdown? Shutdown REQ?!

malakondareddy · August 16, 2024, 5:33am

As per NX XAVIER design document under SW sudo shutdown now the PIN 233 should go LOW. This signal read micro controller and do the necessary action (Attached figure that is given in deign document).
Also it would be helpful if you provide a code that you written in DEVkit board for power sequence.

KevinFFF · August 16, 2024, 9:07am

Do you mean that this pin not pulled to LOW during shutdown in your case?

If so, do you have the devkit to reproduce the same issue?

malakondareddy · August 19, 2024, 5:19pm

Yes, I also tried using the DEVkit, but I’m encountering the same issue. I might need to flash an older version of the code; I will check and update you on that.

I have a few questions regarding the NX Xavier design document and datasheet:

The datasheet mentions that the module has three states: ON, OFF, and SLEEP. Can you clarify the following?

ON state: The module is fully operational.
OFF state: This state how module OFF because 5V0 is not disconnected from VDD1. Is there any internal regulators to cut off power ?Could you explain this state in more detail?
SLEEP state: The module is in a low-power mode but still operational to some extent.

What happens when I set POWER_EN to LOW on the Jetson NX Xavier? Does it enter Internal Power Off mode or Sleep mode?
What mode does the Jetson NX Xavier enter when executing sudo reboot now? Does it enter Internal Power Off mode and then reboot?
Are there internal regulators to convert VDD1 (5V0) to 3.3V and 1.8V? If so, who controls these regulators? In the OFF state, are these internal regulators turned off?

Thank you for your assistance.

Trumany · August 20, 2024, 6:35am

ON/OFF is controlled by PMIC on module. SLEEP status is SC7.
POWER_EN is for ON/OFF of module.
Reboot will restart module ON → OFF → ON.
Yes as #1 said.

malakondareddy · August 20, 2024, 2:27pm

Thanks Turmany for detailed information,
Today I conducted a test and observed a low signal from the Jetson Xavier NX module when executing the sudo shutdown -h now command in the terminal. However, the signal displayed a V shape on both the devkit and my carrier board, indicating a 20 microsecond ramp-down followed by a 20 microsecond ramp-up. This brief signal transition is causing issues with GPIO readings.

Is it possible to adjust the duration of this signal to be more like a pulse? I’ve attached images for your reference.
In the below link they are getting proper square pulse

Note : Using interrupts in the code can address the issue, but it would require bringing all the boards to our location and re-flashing the code. Instead, it would be more convenient and efficient if you could provide guidance on how to increase the signal duration directly through the command terminal. This approach would simplify the process and avoid the need for extensive reconfiguration.

Thanks and regards,

KevinFFF · August 21, 2024, 6:17am

Do you know that why you get different behavior of “SHUTDOWN REQ” with the link you shared?

Have you also verified with the latest R35.5.0 on the devkit?

Trumany · August 21, 2024, 6:59am

The voltage drop should be like the one in the topic you shared Question for Jetson Xavier NX's HW and SW shutdown - #4. Can you use 20us/div to trigger/capture the drop? It looks like your scope setting issue.

malakondareddy · August 21, 2024, 7:44am

Hi Trumany,
The oscilloscope setting i will do and perform the test. If the signal is like Question for Jetson Xavier NX's HW and SW shutdown
why my STM32 GPIO is unable to read the signal please refer the attached code.

Also is there way to increase that Low signal duration in DTS file ? This will help us more than the changing STM32 code.

STM32 Code:

void TIM3_IRQHandler()
{
	if (micros < 1000){
		micros += 40;		// Interrupt set at 40 microseconds
	}
	else{
		millis++;
		micros = 0;
	}
	if(!GPIO_ReadInputDataBit(SHUTDOWN_REQ_PORT, SHUTDOWN_REQ)){
		GPIO_WriteBit(SYS_ON_PORT, SYS_ON, Bit_RESET);
	}
	TIM_ClearITPendingBit(TIM3, TIM_IT_Update);	// Clear interrupt flag
}
	case On_2_Off:
		if (!powerOnTimer && !GPIO_ReadInputDataBit(SHUTDOWN_REQ_PORT, SHUTDOWN_REQ)){
			powerOnTimer = microSec();
			
			
		}
		else if ((microSec() - powerOnTimer >= 10) && !GPIO_ReadInputDataBit(SHUTDOWN_REQ_PORT, SHUTDOWN_REQ)){
			powerOnTimer = 0;
			GPIO_WriteBit(SYS_ON_PORT, SYS_ON, Bit_RESET);
			GPIO_WriteBit(V3_3_EN_PORT, V3_3_EN, Bit_RESET);
			GPIO_WriteBit(USB_EN_PORT, USB_EN, Bit_RESET);
			GPIO_WriteBit(LIDAR_EN_PORT, LIDAR_EN, Bit_SET);
			GPIO_WriteBit(AMP_EN_PORT, AMP_EN, Bit_SET);
			GPIO_WriteBit(CHG_EN_PORT, CHG_EN, Bit_SET);
			GPIO_WriteBit(MLTE_EN_PORT, MLTE_EN, Bit_RESET);
			GPIO_WriteBit(MLTE_RST_PORT, MLTE_RST, Bit_RESET);
			GPIO_WriteBit(IND_ON_PORT,IND_ON, Bit_RESET);
			state = Off;
		}
		break;

It is coming to Interrupt section but not going into the “case On_2_Off”. This may execute if shutdown signal has enough low time period.
Thanks.

malakondareddy · August 21, 2024, 10:33am

Hi Trumany,
I measured as per your inputs but still is coming only 12 micro sec Low, however that link it is low upto 90 micro sec.
Please check below attached image.

Trumany · August 22, 2024, 3:55am

Yours looks fine too. The timing is not so strict and it triggered POWER_EN successfully.

malakondareddy · August 22, 2024, 4:03am

Yes, But that is going into only timer section not into case condition due to that we couldn’t turn off the carrier board peripherals.
Shall we have live chat to clear all my doubts because it is taking more than 18 hrs to get reply?
Thanks

Trumany · August 22, 2024, 4:39am

Didn’t it trigger POWER_EN successfully? Then why can’t it turn off carrier board? I don’t understand. If POWER_EN is low, carrier power rails should be able to be turned off based on it.

malakondareddy · August 22, 2024, 5:05am

It did but see below that movement it enter into Case on-Off (highlighted with black) the shutdown signal is going high due to that we could not reset other peripherals.
void TIM3_IRQHandler()
{
if (micros < 1000){
micros += 40; // Interrupt set at 40 microseconds
}
else{
millis++;
micros = 0;
}
if(!GPIO_ReadInputDataBit(SHUTDOWN_REQ_PORT, SHUTDOWN_REQ)){
GPIO_WriteBit(SYS_ON_PORT, SYS_ON, Bit_RESET); \ This power enable
}
TIM_ClearITPendingBit(TIM3, TIM_IT_Update); // Clear interrupt flag
}
case On_2_Off:
** if (!powerOnTimer && !GPIO_ReadInputDataBit(SHUTDOWN_REQ_PORT, SHUTDOWN_REQ)){**
** powerOnTimer = microSec();**

** }**
** else if ((microSec() - powerOnTimer >= 10) && !GPIO_ReadInputDataBit(SHUTDOWN_REQ_PORT, SHUTDOWN_REQ)){**
** powerOnTimer = 0;**
** GPIO_WriteBit(SYS_ON_PORT, SYS_ON, Bit_RESET);**
** GPIO_WriteBit(V3_3_EN_PORT, V3_3_EN, Bit_RESET);**
** GPIO_WriteBit(USB_EN_PORT, USB_EN, Bit_RESET);**
** GPIO_WriteBit(LIDAR_EN_PORT, LIDAR_EN, Bit_SET);**
** GPIO_WriteBit(AMP_EN_PORT, AMP_EN, Bit_SET);**
** GPIO_WriteBit(CHG_EN_PORT, CHG_EN, Bit_SET);**
** GPIO_WriteBit(MLTE_EN_PORT, MLTE_EN, Bit_RESET);**
** GPIO_WriteBit(MLTE_RST_PORT, MLTE_RST, Bit_RESET);**
** GPIO_WriteBit(IND_ON_PORT,IND_ON, Bit_RESET);**
** state = Off;**
** }**
** break;**

Trumany · August 22, 2024, 5:27am

The output low signal duration of shutdown_req can not be tuned. The correct sequence is SHUTDOWN_REQ → POWER_EN → SYS_RESET → Carrier Board Supplies. That means in custom design, the carrier supplies should be controlled by SYS_RESET which guarantee carrier off before module supplies, as you can see in the power down sequence. Since your design can trigger POWER_EN, it should be no problem to turn off carrier supplies with SYS_RESET.

Topic		Replies	Views
NX Custom Carrier Board Design Jetson Xavier NX hw , board-design	15	2990	September 19, 2021
Assertion of shutdown_req pin with SW shutdown command Jetson Nano gpio , board-design	17	1692	March 2, 2022
TX2 NX and on-carrier mmc-socket Jetson TX2 gpio	17	2095	June 23, 2021
Xavier NX Module reboots after short period of time Jetson Xavier NX board-design , reboot	3	515	November 1, 2022
SLEEP/WAKE# pin functionality in Jetson TX2 NX Jetson TX2 gpio	22	897	January 16, 2024
Quick Power off - CARRIER_PWR_ON Signal at 1.8V for some time Jetson AGX Xavier hw , board-design , power-on	30	1884	October 18, 2021
Jetson Xavier NX GPU lib Report Error Jetson Xavier NX board-design , gpu	41	1487	July 13, 2022
Jetson Xavier NX Production module, SDMMC3, boot looping when insert SD Card Jetson Xavier NX board-design	52	2443	October 18, 2021
Board not booting up Jetson Xavier NX boot , board-design	14	1940	December 24, 2021
RS232 TXD signal glitch when system shut down Jetson Xavier NX uart	14	722	May 11, 2022

Keep on getting shutdown req* in unbuntu 20.04 but this is not happening in unbuntu 18

R35 (release), REVISION: 3.1, GCID: 32827747, BOARD: t186ref, EABI: aarch64, DATE: Sun Mar 19 15:19:21 UTC 2023

Related topics