BeagleBoard Battery test

Ok, so how do I read the UID on the BeagleBoard?

There isn’t a solution implemented right now. However, in principle, one may be available for the xM, because it has on board Ethernet, which requires a globally unique MAC address. So, if we can find that (not an insignificant challenge, perhaps), we have the basis of a unique machine ID.

Ah, ok. Thanks. In the meantime then, I’ll maybe hold fire on trying to link the charging setup to the UID!

Just thought, I can get the MAC address from the EtherUSB module, so maybe that’s a solution to a UID, assuming it gets its MAC address sensibly somehow?

Ok, a Beta version of the plug-in is now here Place it in !Boot.RO500Hook.Res.Configure and it will appear as a plug-in when you run !Boot as usual.

As far as I can test it should be ok, but if it blows up your battery, please don’t blame me!

At present, it still looks at the UID bytes from SWI_ReadSysInfo, just because I haven’t got round to taking that out and replacing it with the MAC address or some other UID value we can think of (particularly for non-networked BeagleBoards, which won’t have a MAC!). I’d welcome any feedback/suggestions/etc. anyone may have.

As far as I can test it should be ok, but if it blows up your battery, please don’t blame me!

I haven’t tried it yet, but it looks like it should be OK. Nice job! :)

At present, it still looks at the UID bytes from SWI_ReadSysInfo, just because I haven’t got round to taking that out and replacing it with the MAC address or some other UID value we can think of (particularly for non-networked BeagleBoards, which won’t have a MAC!).

Here’s some code that will read the real machine ID into the block pointed to by id%. The ID is 16 bytes long, which is one of the reasons why OS_ReadSysInfo currently doesn’t return it. (and the other reason is that the kernel’s been hardcoded to only pay attention to IDs that pass a certain checksum test – and the ID bits which the HAL currently returns won’t pass that test, because that checksum system isn’t used on the OMAP). So at some point soonish I’ll have to sort out a new OS_ReadSysInfo reason code to allow the full ID to be returned.

REM Read L4_DIE_ID into id%
DIM code% 256
P%=code%
[ OPT 2
MOV R0,#14
MOV R1,#&48000000
ORR R1,R1,#&300000
SWI "OS_Memory" 
SWI "OS_EnterOS" 
ADD R2,R2,#&A200
ADD R2,R2,#&18
LDMIA R2,{R0-R2,R5}
STMIA R4,{R0-R2,R5}
MSR CPSR_c,#16
MOV R0,#15
MOV R1,R3
SWI "OS_Memory" 
MOV PC,R14
]
DIM id% 16
E%=id%
CALL code%

REM Print it out
OSCLI("*memory "+STR$~(id%)+" + 10")

Thanks. Still a bit of ‘neatening up’ needs doing to the plug-in, but it seems to do the job!

The code you gave for reading the DIE_ID gives me an ‘Abort on data transfer at &000091CC’ when I try to run it :-(

Gah, I forgot the MOV PC,R14 at the end of the assembler block! Try again and it should work now.

Thanks, works now! I’ll put that into the plug-in so it really does tie the charging settings to the UID.

Ok, a new version of the plug-in is now here Place it in !Boot.RO500Hook.Res.Configure and it will appear as a plug-in when you run !Boot as usual. You’ll need to reconfigure the charging settings, as it now ties itself to the UID of the BeagleBoard.

Any/all feedback welcome!

Put a battery on the BB-xM and it works great and it loads the battery. One possible enhancement, you could update the battery voltage every 5 seconds or so. Because you give the voltage in 0.001 Volt you can see it move :-)

I couldn’t find the datasheet where you get the formula to calculate the voltage to check it but do you really have to divide by 1023 and not 1024 or 1000 to get the voltage?

Presumably the battery charging settings, including the machine ID, will have to go in the “CMOS RAM” at some point, then the BB can wake up and set the charger on automatically, on condition that the stored machine ID matches the ID found on the machine.

And if it doesn’t, then there ought to be some kind of alert to the user, who is otherwise going to blindly assume that the battery is being charged – and will eventually find the clock reset to 1970 or whatever.

So one small ingredient that we will need is an official assignment of “CMOS RAM” content. Does ROOL handle that?

When I eventually get my code going, the “CMOS RAM” will be 2 kiB, i.e. over 8 times the size of what we’re used to. I saw mention of new content being in key-value pairs; does that make sense rather than the binary we’re used to?

I use the key-value pairs a lot. It works great but it will take a lot of space because you have to store the key string too. 8 times more space may not be enough.

On the other hand, when do you need a value in CMOS RAM that you can not read from a choices file. If I look at the list in the PRM they are all values for Boot Configuration. I would say, make it binary and we keep a list here in the forum. You allocate some space for testing. If a developer is ready to release a Boot Configuration he just claims some space.

One possible enhancement, you could update the battery voltage every 5 seconds or so. Because you give the voltage in 0.001 Volt you can see it move :-)

I did think about doing that, but didn’t get round to it. I’ll implement it in the next version.

I couldn’t find the datasheet where you get the formula to calculate the voltage to check it but do you really have to divide by 1023 and not 1024 or 1000 to get the voltage?

I noticed that, but assumed Jeffrey knew what he was doing!!

Presumably the battery charging settings, including the machine ID, will have to go in the “CMOS RAM” at some point, then the BB can wake up and set the charger on automatically, on condition that the stored machine ID matches the ID found on the machine.

Yes, I’d guess so. Just to complicate it, I guess there should be provision for several BB settings in there so each BB the SD card is put in can have its own charging settings.

I did wonder about maybe tieing the whole ‘CMOS RAM’ file to the UID, so that each BB looked for its own settings, and all CMOS settings could be specific to that BB? Easier said than implemented, I’m sure!

I use the key-value pairs a lot. It works great but it will take a lot of space because you have to store the key string too. 8 times more space may not be enough.

You could keep the size down a bit by limiting the key size to eg. 8 characters.

8 times more space may not be enough.

I’m surprised by this, given that 256 bytes have served us OK (yes, I know it has been a squeeze) for decades. Application non-volatile data don’t belong in the CMOS. I find it impossible to envisage uses for enough key-value pairs to use that lot up.

That having been said, it would be easy enough to extend the size to whatever reasonable length is required. The cache sits within the HAL’s RAM allocation.

640 kiB are enough for anyone, of course.

If we had to re-do the existing values contained in the original 240bytes, then maybe 2kb would be a bit short, but assuming that we’ll have to keep those as they are for compatibility, then there’s not going to be many more hardware configuration settings needed, I wouldn’t have thought, so 2kb should be fine for new settings to be contained in key-value pairs.

Thinking about it: “CMOS RAM” is only needed before booting, after this a config file can be read.

If you use a key string, you have to make sure it is unique so… it has to be registered somewhere, the same as a CMOS address. If you don’t the developer has to make sure it is unique so long key strings are used for example ‘battery_charger_maximum_voltage’ and ‘battery_charger_maximum_current’. Nice readable, probable unique but long.

My suggestion : use the address and limit it to 2 Kb. For registration use this forum.

Ok, new version of the configure plug-in here It now updates the battery voltage every 5secs whilst the window is open. It also has a more sensible WimpSlot, and a new icon!

Any/all feedback welcome!

For registration use this forum.

Or use !Allocate, which is what it’s for.

(ROOL will have to update it if we go down the key-value route, of course, but then again maybe while they’re at it they could remove the long list of obsolete features which are confusing the UI.)

The new version of the configure plug-in works great. I can see the voltage rise slowly. It will be turned off for the holidays so I can see how it will drain the battery.

Nobody has said what level of charging should be used out of the 4 given V/A settings. According to Digkey and Panasonic, the Panasonic VL-1220/VCN battery, i.e. the recommended battery, should be charged at 0.5mA or below with a charging voltage of 3.4V +/- 0.2V. The nearest setting to this in Configure is 3.1V and 0.5mA. So will that work or destroy my battery? What was the thinking behind deciding on the given 4 charging levels?

The settings available are the different charging voltages/currents that the BB can provide. You should find suitable charging voltages/currents from the spec sheet for the battery which you have fitted.

OK, I used 3.2V and 0.5mA in the configure application and, whoopee, I could see Beagle’s voltage gradually increase every 5 seconds until it reached 3 volts when I stopped the charging. This is a slight oversimplification in that the voltage usually took one step back to every 2 steps forward though Beagle wasn’t doing anything else. That was Christmas day and when I powered up Beagle this morning it had kept time correctly. Well done Jeffrey Lee and Andrew Conway. If one continues charging after it reaches 3V, what happens?

As I understand it, the charging circuit should stop full charging once full charge is reached, and then just trickle charge to keep it fully charged.

Oh, and it’s Andrew CONROY, by the way, not Conway! :-)

Sorry about that, it must be the Christmas drinks. I must have been drunk in charge of the keyboard. I hope the net police didn’t see me. ;-)

What is the best battery charging strategy for the longest battery life?