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.
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”
Hi WayneWWW
The command also does not work.
Does the VCC_RTC supply anything else than the RTC?
A correction from our side, the signal stays at 1.5 V and not 1.8 V for 40 ms.
Thank you.
Hi,
Could you tell us what is “this command does not work” mean? An error message? Or fail to format?
Hi WayneWWW
It gives the following output:
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”
Traceback (most recent call last):
File “./tegraflash.py”, line 1222, in
chip = chip.replace(’ ', ’ ')
AttributeError: ‘NoneType’ object has no attribute ‘replace’
erase: command not found
mts_preboot: command not found
mts_mce: command not found
mts_proper: command not found
bpmp_fw: command not found
bpmp_fw_dtb: command not found
spe_fw: command not found
Command ‘tlk’ not found, did you mean:
command ‘tlf’ from deb tlf
command ‘elk’ from deb elk
command ‘talk’ from deb inetutils-talk
command ‘talk’ from deb talk
command ‘talk’ from deb ytalk
command ‘tla’ from deb tla
command ‘tlp’ from deb tlp
Try: apt install
Command ‘eks’ not found, did you mean:
command ‘eos’ from deb elk-lapw
command ‘sks’ from deb sks
command ‘ecs’ from deb ecere-dev
Try: apt install
We have to use it on the x86 host, right?
Hi sevm89,
I just checked. The command is correct. Your error is due to the forum system automatically change " to ”. These are different symbol.
command.txt (1.3 KB)
And VCC_RTC only supply RTC part.
We still get an error:
[ 35.5172 ] Sending bct_mb1
[ 35.5197 ] […] 100%
[ 35.5271 ] 000000001d1d0f18: E> LOADER: Failed to verify SHA2 of binary mb1bct.
[ 35.5459 ]
[ 35.5460 ]
Error: Return value 24
Command tegrarcm_v2 --download bct_bootrom br_bct_BR.bct --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt --download bct_mem mem_rcm_sigheader.bct.encrypt
