Supercap is not working

We’re facing with a problem with clock on the Jetson Xavier.

Every time we power off the device, its system time after rebooting becomes somewhere around 2000-01-01 23:12:49. No internet syncronization (like ntp) is possible, so I believe the issue is critical.

I started digging and found out that Jetson Xavier has a supercap on board, but it is disabled by default.
The topic https://devtalk.nvidia.com/default/topic/1044985/jetson-agx-xavier/rtc-current-consumption-in-xavier-som-/post/5341906/#5341906 says that I need to modify device tree in order to enable this feature.

The name of the file stated in that topic is ./galen/kernel-dts/common/tegra194-spmic-p2888-0001.dtsi, and there’s no such a file on my Jetson of course.
I found some *.dtb files in /boot directory:

tegra186-quill-p3310-1000-a00-00-base.dtb
tegra186-quill-p3310-1000-as-0888.dtb
tegra186-quill-p3310-1000-c03-00-base.dtb
tegra186-quill-p3310-1000-c03-00-dsi-hdmi-dp.dtb
tegra186-quill-p3489-0888-a00-00-base.dtb
tegra186-quill-p3489-1000-a00-00-ucm1.dtb
tegra186-quill-p3489-1000-a00-00-ucm2.dtb
tegra194-p2888-0001-p2822-0000.dtb
tegra194-p2888-0001-p2822-0000-maxn.dtb

Which of the files should I modify and how to do it properly?

You need to download the kernel source to find it.

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fkernel_custom.html%23

So, when I download, change and build the kernel, what will be the next steps?

Could I use NVIDIA SDK manager to flash the new kernel on my device?

You can replace the dtb file at …/JetPack_4.3_Linux_P3310/Linux_for_Tegra/kernel/dtb/tegra194-p2888-0001-p2822-0000.dtb and the …/JetPack_4.3_Linux_P3310/Linux_for_Tegra/kernel/Image

Then issue the command.
Flash dtb by
sudo ./flash.sh -r -k kernel-dtb jetson-xavier mmcblk0p1
Flash kernel Image by
sudo ./flash.sh -r -k kernel jetson-xavier mmcblk0p1

Have a reference to below link
https://developer.ridgerun.com/wiki/index.php?title=DS90UB953/960_IMX390RCM_Linux_driver_for_Jetson_Xavier

Hello. I’ve done modifying and replacing of the .dtb file successfully.

After that, I rebooted Jetson and checked if the changes are there by command:

$ dtc -I fs -O dts /sys/firmware/devicetree/base

…and I see there

backup-battery {
				backup-battery-output-resister = <0x64>;
				status = "okay";
				backup-battery-charging-current = <0x64>;
				backup-battery-charging-voltage = <0x2dc6c0>;
			};

Seems that all is OK, but after ~4 hours of shutdown I found that the clock is in January 2018, as it was before, so the problem persists.

Should I edit *.dtb for maxn too? Or should I change any other parameters for backup battery block?

Thanks for the response.

Could you confirm /proc/device-tree are the same with /sys/firmware/devicetree/base
Also could you probe to make sure the voltage is corect.

sudo dtc -I fs -O dts /proc/device-tree

Also you may need to program the pmic REG as below.

Low-Power Mode (PWR_MD_32K[1:0] = 0b00)

Hello there, ShaneCCC, thak you in advance for the response.

  1. I checked the /proc/device-tree and it says: status = "okay"
  2. Where should I probe the voltage and what shold it be? 0x64 means 100, so… 1V?
  3. Sorry, again, I didn’t quite get it, where can pmic REG be programmed?

lAgain, I appreciate your help so much!

supercap should work by default. Are you setting the time and date after boot and then how long you are unplugging the power supply before you plug in again?

Hello bbasu,

Supercap is definetely not working. Yes, I do set the time after boot and then after, say, 2-4h of unplugging I plug it again and the time is in January, 2018.

Device tree modifications are also not working.

Hi,

How long you have charged? And can you charge for an hr and then do the test for 5 minutes of unplugging to see if rtc is keeping the data?
Meanwhile checking locally about the exact time and capacity of supercap.

thanks
Bibek

Hi,

How long you have charged? And can you charge for an hr and then do the test for 5 minutes of unplugging to see if rtc is keeping the data?
Meanwhile checking locally about the exact time and capacity of supercap.

thanks
Bibek

Hello,

I tested with the following:

  • Worked for many hours on jetson
  • Left Jetson powered off but plugged in for an hour
  • Unplugged Jetson for 5 minutes
  • Plugged Jetson in and checked if time persists.

The answer is: no,

Before unplugging:

Local time: 2020-04-16 15:39:21 MSK
Universal time: 2020-04-16 12:39:21 UTC
RTC time: Чт 2020-04-16 12:39:21

After replugging:

Local time: 2018-01-28 18:58:42 MSK
Universal time: 2018-01-28 15:58:42 UTC
RTC time: 2000-01-01 01:00:46

This is the result we had by default, and it remains the same after kernel-dtb flashing.

@ShaneCCC @Bibek, bubbling this up to get an answer, thank you!

Hi,
Please check the voltage of supercap across its terminals using Mutli-meter. After an hour charging, voltage should be close to 3V. The supercap can be located near 40-pin connector. You can refer attached picture to find +ve and -ve terminals of supercap.

Hello,

we repeated the test as described above, measuring voltage. The results are as follows:

  • Voltage when working: 2.997V
  • Voltage after an hour of powered off but plugged in: 2.623V
  • Voltage after 5 mins of unplugging: 0.03V

Is that a correct behaviour? What else can we do to make the supercap work?

Thank you in advance.

@rkasirajan, @ShaneCCC, looks like notification of replies is not working here. I’tt tag you each time I answer the questions in the future.

So, what are next steps to a solution?

What is the supercap voltage when power supply is unplugged immediately after one hour charging? I try to understand whether supercap quickly drains out within 5 mins or it is not all charged.

Hi @rkasirajan

We are experiencing the same problem as @jetsonxvr and can report that the current consumption draw from the supercap is abnormal.

We are measuring (with a Fluke 189) that the supercap is fully charged, then we issue poweroff and remove our power supply.

We observe/measure that the super cap is discharging rapidly.
Furthermore we have also verified it with an oscilloscope.

Hence there’s a problem internally in the TX2 module causing the capacitor to discharge.

Regards
Lasse

@rkasirajan Looks like it quickly drains, confirmed 0.03V right after unplugging.