Quick Power off - CARRIER_PWR_ON Signal at 1.8V for some time

Dear NVidia Team

We have systems, were we see that when we turn the power off and on again in a short time, that the CARRIER_PWR_ON signal stays for some time at 1.8V before going up to 3.3V as expected. When we wait for 10s after a power off and then turn on the Power, we do not see this behavior. On our custom carrier, nothing is driving the signal, so we think something of the Jetson AGX Xavier goes wrong in the case of a short power loss. Any idea what could be the problem? Thank you.

It seems that it has to do with the Battery Backup on VCC_RTC. When we have a battery connected to the Module Pin, we see this behavior, without the battery, the signal goes as expected from 0V to 3.3V and stays there. Any ideas what could be the problem?

There is discharging circuit design to meet the power down sequence.

Hi Trumany

We know about the discharging circuit and we have implemented it exactly as described in the OEM Design Guide and the reference schematic.


The first Picture is the CARRIER_PWR_ON Signal without a battery when the system starts, and the second one is with battery, where we can see a spike. On our carrier board, nothing is driving this signal, it is only used to turn on MOSFETs and regulators. What can cause this?
Thank you.

Can it repro on dev kit? What I see the spike in figure 2 is about 3.3V not 1.8V.

How can we connect a battery to the DevKit?
The CARRIER_PWR_ON Signal also looks like this after a short power off:

A cross-check is necessary to know if this only happens on your carrier board. Can it repro on devkit? What is the “battery” you mean?

Hi Trumany
On the DevKit, we were not able not reproduce it. We use the Powerbutton IC and not the Powermanager on our carrier board. We see the behaviour with 3x 1F GoldCaps (ELNA DHL-5R5D105T) and also with a Coin Cell Battery 3V (Retina CR2477N.SC). Any ideas?

It looks like 1.8V on your carrier board is discharged too slow since it can not repro on devkit. Seems the clue lies on the difference between your board and dev kit, you can check and try some changes based on the schematic of P2822.

Hi Trumany
We checked our 1.8V and it is discharged fast, so we do not think that this is the problem. Another point is that the VCC_RTC has nothing to do with the 1.8V, right? Is this backup voltage used for anything else than the RTC? Could it supply another power on the module?

When we take a new jetson agx xavier module (not yet flashed, factory status), the CARRIER_PWR_ON signal looks normal as in the very first plot we have uploaded. Once the module is flashed, the signal becomes as in the last plot we have uploaded (in both cases, the battery is inserted). Is there a way to do a factory reset to verify this?

Hi Trumany
Do you have any update for us? Can we do a factory reset of the module?
Thank you.

Hi,

I am not sure what is the default status from factory. It is probably in a status of erased emmc.
You can try to use below command to see if it can erase emmc.

./tegraflash.py --chip 0x19 --applet “/home/carol/nvidia/nvidia_sdk/JetPack_4.4.1_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/mb1_t194_prod.bin” --skipuid --soft_fuses tegra194-mb1-soft-fuses-l4t.cfg --bins “mb2_applet nvtboot_applet_t194.bin” --cmd “erase /sdmmc_boot/3/; erase/sdmmc_user/3/”

Sorry in advanced I am not a hardware guy so not pretty sure why you want to debug this issue in erased emmc state.

Hi WayneWWW

The command is not working. It has to be run on the host, right?
If with the erased eMMC the signal looks again like it should (plot 1), then we are sure that it has to do with the module configuration. Is there any mistake we can make in the configuration for our custom carrier board?
We cannot understand how the battery can change the carrier_power_on signal.
Thank you.

Hi sevm89,

You can try below command. But remember to modify each config to match what your board is using.

sudo ./tegraflash.py --bl nvtboot_recovery_cpu_t194.bin --sdram_config tegra194-mb1-bct-memcfg-p2888.cfg,tegra194-memcfg-sw-override.cfg --applet mb1_t194_prod.bin --cmd “erase /sdmmc_boot/3/; erase /sdmmc_user/3/” --soft_fuses tegra194-mb1-soft-fuses-l4t.cfg --cfg flash.xml --chip 0x19 --uphy_config tegra194-mb1-uphy-lane-p2888-0000-p2822-0000.cfg --device_config tegra19x-mb1-bct-device-sdmmc.cfg --misc_cold_boot_config tegra194-mb1-bct-misc-l4t.cfg --misc_config tegra194-mb1-bct-misc-flash.cfg --pinmux_config tegra19x-mb1-pinmux-p2888-0000-a04-p2822-0000-b01.cfg --gpioint_config tegra194-mb1-bct-gpioint-p2888-0000-p2822-0000.cfg --pmic_config tegra194-mb1-bct-pmic-p2888-0001-a04-p2822-0000.cfg --pmc_config tegra19x-mb1-padvoltage-p2888-0000-a00-p2822-0000-a00.cfg --prod_config tegra19x-mb1-prod-p2888-0000-p2822-0000.cfg --scr_config tegra194-mb1-bct-scr-cbb-mini.cfg --scr_cold_boot_config tegra194-mb1-bct-scr-cbb-mini.cfg --br_cmd_config tegra194-mb1-bct-reset-p2888-0000-p2822-0000.cfg --dev_params tegra194-br-bct-sdmmc.cfg --bin “mb2_bootloader nvtboot_recovery_t194.bin; mts_preboot preboot_c10_prod_cr.bin; mts_mce mce_c10_prod_cr.bin; mts_proper mts_c10_prod_cr.bin; bpmp_fw bpmp_t194.bin; bpmp_fw_dtb tegra194-a02-bpmp-p2888-a02.dtb; spe_fw spe_t194.bin; tlk tos-trusty_t194.img; eks eks.img; bootloader_dtb tegra194-p2888-0001-p2822-0000.dtb”