TPS65950 RTC Battery Backup - Configuration required?

Hi Josh,

You would need settings only for charging the battery and not for using the way you explain.

Please probe BKBAT pin for any glitch when there is loss of power or when you shutdown. It may be because of short period of loss of power the RTC contents are lost.

Regards,

Gandhar.

As soon as I am able, I will test for a glitch in the BKBAT input, but I have before tried to see such an event and I don't recall finding anything unusual.

I just noticed that section 5.4.2.4.3 of the TPS65950 TRM (page 249) states: "To stay in BACKUP state, main batter and backup battery > VBNPR (= 1.8 V typ)." Does this mean that if I completely remove power from the board (except directly and only to BKBAT), I will lose the BACKUP state?

I just ran a test with the battery connected and an o-scope watching BKBAT, set to trigger on falling edge at 1.8Vdc: Through a full power cycle it never triggered.

For the setup, I have the battery connected by wire clips, with the o-scope measuring directly at the battery's pins. Could there be an issue with the length of wire between the BKBAT pad and battery positive?

Hi Josh,

The RTC should be active even with a valid (>1.8V) BACKUP battery. The main battery supply is not necessary. The information in the document is incorrect. I will have to fix that typo.

The backup domain is supplied by the main battery when the main battery is above 2.1V. So, you may want to try the main battery on the o-scope as well. 

I dont think wire length will be an issue on your setup. You can check the drop, it will be minimal.

I dont have your schematic, you can check the schematics with the schematics check list - http://focus.ti.com/lit/an/swca073a/swca073a.pdf

 We have seen some strange behavior when the TEST.RESET pin is not connected to ground. Please check this pin and other power related pins.

Regards,

Gandhar.

Apologies for reviving this thread after so long. I've finally gotten back to this part of the project and I'm still have trouble getting the real-time clock to work properly.

Thinking that we must have some weird issue w/ our layout or schematic, I tried to see if the real-time clock on our two evaluation boards worked. I tried the BeagleBoard with our own modified Linux kernel, and LogicPD's OMAP35xx Torpedo dev kit running both Windows and Linux. In all three cases, despite having a good back-up battery attached, the RTC in the TPS65950 was reset to Jan 1st 2000 after losing main power.

I've checked all power related pins, and everything is properly terminated as listed in the documentation. I've watched the BKBAT pin on my 100MHz scope and it never dips below 2.8V. What else could cause the RTC to be reset?

Hi,

This is very strange. This is a simple interface and shouldnt have so much problem. Did you check TEST.RESET pin on your board. Is it grounded?

What is the MSECURE pad connection on the PMIC? Is it connected to 1.8V? Please connect it to 1.8V and let me know if this resolves the problem.

Yes, TEST.RESET is tied directly to ground, and MSECURE to 1.8V through a 10k resistor.

Hi Josh,

This may sound silly but I though of asking. Is the battery charged to its max level? 

What backup battery are you using, what voltage level? Are you using backup charger setting on the PMIC?

To isolate battery issues I would recommend connecting the BKBAT pin to an external stable 3V and then read the RTC.

We are using a Panasonic VL1220, currently charged to 2.993V according to my meter. Normally I have the BCI enabled, but have also tried not enabling it with the same results. Just attempted using a 3.3v supply with the same result.

Recently I was able to get the MADC driver to work, and I see that I can observe VBKP on channel 9, which shows that VBKP is definitely connected electrically (in addition to the fact that the charging interface was working previously).

Interestingly, I've been able to prove that the TPS65950 on a BeagleBoard Rev C4 does work using the pre-compiled uImage/modules from Angstrom (Linux 2.6.32 with a few patches). Looking at the difference between 2.6.32 and our own 2.6.37r4, there's no difference in the RTC driver, and no apparent difference in the rest of the TWL4030 code.

Are there any settings or other peripherals that may alter the functionality/state of the backup circuitry? I know there is a register to set for low-power/accuracy RTC during backup, but I don't recall seeing anything else.

I encountered a similar problem on the LogicPD Torpedo dev kit that I am working with.  I too looked though the driver and was puzzled as to why things weren't working.  Eventually I tracked down the problem to my init.d/settime script.  I don't have a copy of the original handy, but it was smashing the time.  Here is how it looks now:

#!/bin/sh

if [ ! -x /sbin/hwclock ]
then
    exit 0
fi

if [ "$1" = "stop" -o "$1" = "restart" ]
then
    if [ -x /sbin/hwclock ]
    then
        echo "Syncing hardware clock to system time"
        /sbin/hwclock -w
    fi
fi

if [ "$1" = "start" -o "$1" = "restart" ]
then
    if [ -x /sbin/hwclock ]
    then
        echo "Setting system time from hardware clock"
        /sbin/hwclock -s
    fi
fi

With this change my RTC worked the way I wanted/expected.  Perhaps you are encountering the same problem?

My rootfs has a slightly more complex script for using hwclock at start/stop. That said, I have altered the script to exit out and not execute hwclock at all. I then used this same rootfs on both the BeagleBoard and our board, the difference only being the Linux kernel booted and modules loaded. Just to be sure, I will completely remove the hwclock scripts from my init.d folder, relocate the hwclock executable, and give it another go.

Nope, hwclock still reports the same default time even when the init scripts are completely removed from start up. (And sanity check: The RTC clock does keep accurate time while power stays applied: Running for about 1 hour and both the kernel's SW time and the RTC's HW time indicate an hour has passed)

Hi all,

I have a questions here. As i know, TPS65950 doesn't have a battery backup for RTC function. So that, when i power off, it can't continue to count the time. When i turn on my board, what is the value in RTC register? Does it lose all value????

For example: i power off at 16:46:52 21-10-2014. Tomorrow, i turn on. Is the value still 16:46:52 21-10-2014 in RTC register or another value? If it is another number, what is it?

If I recall correctly, without battery backup the RTC memory is volatile: it should reset to register defaults which should be listed in tge datasheet.

FYI as long as power is maintained RTC remains on and its content is not lost. By the way a backup battery may be attached to prevent loss of RTC registers in case of main supply going away; see pin name BKBAT, ball M14.

Best regards, Alain.

Thanks for your replies. So, all the value of time and date i set before will lose when i power off without battery backup.

If i use ioctl() to open /dev/rtc0, the value i read from registers is the initial value in the datasheet. Is that right??

Hi, if power supply is removed then yes RTC registers content will be lost without backup battery. About the question concerning the driver I'm sorry I'm not accountable for it; please post it into OMAP forum.

Best regards, Alain.

Thank you for your support, Alain :D