Hi Chris,

I've used the 621 battery before, as well as it's smaller cousin, and I have to say I have not been impressed by it's retention time with a 'real' RTC (DS1307); I'd be curious to hear your results with the Overo.


Robert Vogt IV
CEO
IOSiX, LLC
2375 Parkwood Ave
Ypsilanti, MI  48198
robert@iosix.com
P: 734-730-9690
F: 734-482-2337


On Fri, Dec 24, 2010 at 1:56 AM, Chris MacDonald <chris@fourthandvine.com> wrote:
On Thu, Dec 23, 2010 at 7:09 PM, Bob Cochran <bcochran13@verizon.net> wrote:
> Chris,
>
> What size and type of battery are you using?
>
> Thanks
>
> Bob Cochran
>

Hi Bob,

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=728-1057-ND

It's the closest I've been able find that matches the 3.1V/25uA
characteristics of the charger... it's nominal charge current is only
15uA (the max discharge is 25uA, so I might have to sort something out
there.

Chris

>
> On 12/23/2010 02:59 PM, Chris MacDonald wrote:
>> Hi All,
>>
>> I've got an Overo Water on a Tobi expansion board and I'm attempting
>> to use a battery to keep the RTC going in the event the device is
>> powered down. I've been reading through manuals and I've established
>> that the BB_CFG register must be changed to allow for charging of the
>> backup battery, and BOOT_CFG can be changed to save some power by
>> putting a 32kHz clock in low power mode (this is all from
>> http://focus.ti.com.cn/cn/general/docs/lit/getliterature.tsp?literatureNumber=swca025&fileType=pdf).
>>
>> I'm running in to problems actually writing values using I2C. I'm
>> using i2cget/i2cset from the command line to read and write registers,
>> and as a test, I can run
>>
>> root@overo:~# i2cget -y -f 1 0x4a 0xee
>> 0x33
>> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x00
>> root@overo:~# i2cget -y -f 1 0x4a 0xee
>> 0x00
>> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x33
>> root@overo:~# i2cget -y -f 1 0x4a 0xee
>> 0x33
>>
>> and all appears well; the power LED turns off and back on as expected.
>> However, when I attempt to change the values of BB_CFG, as far as I
>> can tell, nothing happens
>>
>> root@overo:~# i2cget -y -f 1 0x4a 0x6d
>> 0x00
>> root@overo:~# i2cset -y -f 1 0x4a 0x6d 0x14
>> root@overo:~# i2cget -y -f 1 0x4a 0x6d
>> 0x00
>>
>> and this should enable charging at 25uA, stopping at 3.1V; I'm not
>> sure if it's supposed to return 0x00 or not (I'm assuming not though).
>> The same is true when I try to set BOOT_CFG (always returns 0x00). In
>> the reference manual for the TPS65950 both registers are said to be
>> write-protected using KEY_CFG, and as far as I can understand from the
>> TRM to enable writing I need to send 0xc0 then 0x0c to PROTECT_KEY and
>> reading from PROTECT_KEY will return values indicating whether writing
>> to protected registers is enabled. I've tried this and PROTECT_KEY
>> always returns 0x00.
>>
>> It seems to me that I'm doing something wrong here, but I don't know
>> what. Does anyone see a problem with this approach? Has anyone done
>> this before, who might be able to shed some light on either what I'm
>> doing wrong, or what they've done to enable this functionality?
>>
>> Thanks in advance,
>> Chris
>>
>> ------------------------------------------------------------------------------
>> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
>> to consolidate database storage, standardize their database environment, and,
>> should the need arise, upgrade to a full multi-node Oracle RAC database
>> without downtime or disruption
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users