BeagleBoard Battery test

I have a battery soldered to my BB. It was keeping the time and date correct while the BB was switched off. Now I notice that the time and date is reverting to 12.00am 2/1/1970 as it did before BB had a battery. :-(( I am wondering whether the battery is flat. Can I test it by putting a torch bulb across the terminals of the battery on the underside of the motherboard, or better a voltmeter, with the BB switched off?

Torch bulb, no. Meter, yes.

So what is wrong with a 2.5V/2.4V torch bulb? Is it that it would drain the battery?

A torch bulb would look like a short across the battery – you shouldn’t do that to a battery. In any case, the battery is very unlikely to have enough drive capability to light the bulb, so it would look to you as if the battery had failed, even if it was actually OK for its intended purpose.

Torch bulbs are intended to be powered by much larger batteries. Batteries the size of your BB clock battery are not intended to power torch bulbs.

Thanks for the quick response, Dave. I have seen a ‘multimeter’ on the Maplins web site that measures an amazing number of things apart from DC voltage like resistance, capacitance, temperature and even sexual attractiveness. Gosh, I’m impressed, and there was me talking about humble voltmeters. It’s the UT50C Digital Multimeter at GBP25. Do you have any tips as to what to look out for in multimeters? I would like a meter capable of measuring volts, amps and may be resistance in computer equipment. If it includes a breathalyser or even measures sexual attractiveness, I don’t mind.

It’s most likely that you will only ever want to measure volts, both DC (for your present investigation) and AC (for mains-related stuff, if you are confident that you can address the safety issues). Current is more difficult to measure, as it requires that you break the circuit to insert the meter; you must also be aware of the burden that the meter introduces (this is specific to measuring current). Resistance can occasionally be useful, mostly for checking fuses. I’ve yet to need to make my first capacitance measurement – and I’m an electronics engineer.

As for SA: beware of negative readings :-)

Basically, this probably means that the cheapest one will probably do the jobs you need.

For the record: I payed 4.99 for mine in Patel’s hardware store. Used it to make sure I got the polarity right when I did the wiring. You really won’t need anything more sophisticated!

I have seen a ‘multimeter’ on the Maplins web site that measures an amazing number of things apart from DC voltage like resistance, capacitance, temperature and even sexual attractiveness. Gosh, I’m impressed, and there was me talking about humble voltmeters. It’s the UT50C Digital Multimeter at GBP25.

Did you not notice on Maplin’s website that the very first bullet point for the UT50C is that it measures AC & DC voltage & current? :)

Apart from measuring the battery voltage yourself, it’s also possible to measure it in software on the BB. It’s something that’s been on my todo list for a while now (along with working out a safe & convenient way of storing the charging settings). I’ll try and knock together a quick program tonight.

Also, what capacity battery did you fit, and how long ago did you fit it? The 7mAh battery on my -xM has been fitted for just over a month now, and when I checked last night it had only dropped to 2.3V (although I haven’t checked the datasheet to see exactly how much charge that equates to). This is with the board spending 99% of the time turned off.

For reference, as long as the battery is above 1.8V it should be good to power the RTC.

Wow. This reminds me of an earlier topic about recharging batteries. Are we discovering that our BBs are not recharging our rechargeable batteries?

2.3 V on a 3 V battery suggests that it’s near its endpoint and therefore won’t supply the clock for much longer.

According to specifications on the Panasonic web site, the Vanadium Pentoxide Lithium VL-1220/VCN battery, as recommended by the BB manual, has capacity 7mAh and on continuous drain has a current of 0.03mA. Doesn’t that mean 7/0.03 = 233.33 hour battery life without recharging? Presumably, it doesn’t maintain the 3V over this timescale, but on the other hand it is being recharged while the BB is on? I have noticed that the date and time is retained for short periods of BB switched off from the mains side of the transfomer, but could this be due to the secondary coil still outputting for short periods? (Dave Lane trying to show that he is not completely ingnorant.)

Are we discovering that our BBs are not recharging our rechargeable batteries?

I’m not, because I know I still haven’t added the code to enable the charging circuit ;)

Doesn’t that mean 7/0.03 = 233.33 hour battery life without recharging?

Only if you’re using it with something which drains 0.03mA of current. I don’t think TI have released any figures for how much current the RTC uses, but it should be a lot less than 0.03mA (otherwise my battery would certainly be flat by now)

but on the other hand it is being recharged while the BB is on?

Not at the moment, no.

I’ll knock together a quick BASIC program tonight which will allow you to enable the RTC battery charger, and to check the battery voltage. Then if people would prefer to have the settings stored in the u-boot script instead of sticking an app in their boot sequence then I’ll look into updating everything so that all the ROM images get turned into uImages and you can set extra boot options in SDCreate.

This sounds great. At the moment, I don’t mind whether it’s in the boot sequence or in the u-boot script as long as it works.

I’ll knock together a quick BASIC program tonight which will allow you to enable the RTC battery charger, and to check the battery voltage. Then if people would prefer to have the settings stored in the u-boot script instead of sticking an app in their boot sequence then I’ll look into updating everything so that all the ROM images get turned into uImages and you can set extra boot options in SDCreate.

This could eventually become a plug-in for !Boot which could then allow a ‘CMOS’ bit to be set to enable/disable the charging circuit. In the meantime, thanks for the work so far Jeffrey.

For the record, my BB-xM’s battery seems to be working happily so far, although the BB does spend 95% of it’s time powered up anyway!

This could eventually become a plug-in for !Boot

Ah, now that’s an idea that I like! For some reason it never occured to me that it’s a setting that could (or should) be managed by a Configure plug-in.

I think I’ll also build in an extra safety check for people who use the same boot sequence with multiple machines – tie the RTC battery settings to the machine ID, so that bad things won’t happen if you switch to a machine which could have a different battery type fitted. This check would also work well for when the setting gets migrated to the CMOS RAM file on the SD card (since people could conceivably use the same SD card with multiple machines too).

Would it make more sense long-term for the CMOS settings to be stored with UID values somehow so that each separate configure tool didn’t have to worry about this, but it was done at a system level instead?

I was about to volunteer to write the plug-in before you said that (if someone supplied the ‘magic codes’), but now I fear it’s getting a bit too complex for my simple BASIC skills!

Would it make more sense long-term for the CMOS settings to be stored with UID values somehow so that each separate configure tool didn’t have to worry about this, but it was done at a system level instead?

From a safety standpoint, I think the RTC battery settings are the only settings that need to be kept on a per-machine basis. So rather than overcomplicate the core CMOS code with something that it doesn’t need and will rarely ever get used, it’s probably better to just leave it down to the configure plugin.

I’ve now written a simple BASIC program to control the RTC battery charger and to report the current voltage – get it here. If you run it normally then you’ll be able to enable/disable the charger and change the settings. Or you can open it up and uncomment the right two lines near the start of the file in order to configure it to automatically set the charger settings – so you can just drop it into !Boot.Choices.Boot.PreDesk and have the charger enabled on startup. The code’s also smart enough to do nothing if it doesn’t think a battery is present, so it’s safe for people like me who have multiple machines but only one with a battery fitted.

This program doesn’t do anything to tie the charge settings down to the machine ID, so if you’ve got two machines which need differing charge settings then you’ll have to be careful of what you’re doing whenever you use the program.

Fair enough. In that case then, I’ll look at turning your code into a Configure plug-in soon, I hope.

Incidentally, how do we know what charge voltage and current to use? From the battery data sheet?

Yes, you’ll need to check the data sheet.

The TPS65950 datasheet gives a typical power consumption of 7.2 uW for the RTC. The BB-xM manual recommends the MS412FE-FL26E battery from Seiko with a 1 mAH capacity. At 3V it has 3mWH. This gives 3000/7.2 = 416 H or 17 days. I couldn’t find this battery but the MS621FE has a capacity of 5.5 mAH so will last 5.5 times longer. The charge current for the MS412FE and MS621FE are 0.01 and 0.015 mA.

The charge current for the MS412FE and MS621FE are 0.01 and 0.015 mA.

Doesn’t that mean that the lowest charge current selectable of 25uA is too large?

Doesn’t that mean that the lowest charge current selectable of 25uA is too large?

That’s what I first thought, but the graphs on page 2 suggest that the maximum charge current is 25uA (or 100uA for the MS621FE).

I’ve been charging my battery (a MS621FE - not the nonexistant 7mAh battery that I mentioned earlier) with 3.1V/25uA and so far it hasn’t exploded or started leaking. And after all, it would be a bit silly to recommend the use of a low-capacity rechargeable battery which isn’t suitable for recharging with the hardware present on the board.

The only thing which does worry me a little bit is the mention of 72 hours/96 hours – is that the time they left it charging for in order to arrive at the capacity figures shown on the graph, or is that the maximum time that the battery can be left to charge?

Fair enough. I’m not too sure what the 72/96hrs on the graph is, maybe time to reach full capacity. I don’t know what happens if you continue to charge after that time, I’d imagine it trickle charges and is ok, but don’t quote me on that when it explodes and burns your house down!

Not sure why I didn’t realise this earlier – if you were to charge at the max current of .1mA then it should in theory only take 55 hours to reach the full 5.5mAh capacity. So when you take into account the fact that the charging won’t be 100% efficient, 96 hours sounds reasonable for the time to reach full capacity. (And even if there is an upper limit of 96 hours, as long as it reaches the programmed voltage before that time the charger will cut off and everything will be OK)

The charge current for the MS412FE and MS621FE are 0.01 and 0.015 mA. Doesn’t that mean that the lowest charge current selectable of 25uA is too large?

Sorry, that was the standard charge, not the maximum.

I think the 72/92 hrs in the graph is that the time they left it charging for in order to arrive at the capacity figures shown on the graph. If you use 3.1V/25uA there shouldn’t be a problem. In the graphs you see CC/CV (Constant Current/Constant Voltage). With 3.1V/25uA it will first charge with 25uA until it reaches 3.1V. It will not go higher so there shouldn’t be a problem.

The only problem I find worrying is the Cycle Life Time. You can only discharge it 100% 100 times (1000 times discharge 20%).

I think I’ll also build in an extra safety check for people who use the same boot sequence with multiple machines – tie the RTC battery settings to the machine ID, so that bad things won’t happen if you switch to a machine which could have a different battery type fitted.

Ok, so how do I read the UID on the BeagleBoard? OS_ReadSysInfo,2 returns 0 for both bytes of the UID :-(