HP Forum Archive 19

[ Return to Index | Top of Index ]

hp20b hacking: SW reset problem Message #1 Posted by hugh steers on 12 Apr 2010, 9:50 a.m. Hi, so i finally got around to repurposing a 20b to play chess. everything was going swimmingly, until i get about 3 moves in and then the unit software resets! im using the hp20sdk (latest i think). at the start of main, it figures out the startup state and displays it (if you enable the lcd) and i get "SW Reset" when i press ON again. so i get rid of everything i can find that does this. im disabling the watchdog (damn good idea!) and also various logic to deliberately perform "cpureset". when i do this, instead of software reset, i get a power reset. when i press on i get "Power Up" and not "Normal Wakeup". this says to me that there is power down. could it be that my batteries are low and cant sustain the output. i notice ServiceBOD handles this, but it performs an Off which should correspond to normal wakeup (or does it?). Getting rid of ServiceBOD does not change anything either. so im wondering if maybe the unit cant handle it. im running flat out at 36Mhz for say 5 seconds. unfortunately, i haven't got a new set of batteries to test. are there any other sneaky timers, i might have missed that might do this? disabling the RTC 5 minute timer makes no difference either. any ideas?

Re: hp20b hacking: SW reset problem Message #2 Posted by Katie Wasserman on 12 Apr 2010, 2:36 p.m., in response to message #1 by hugh steers I've seen similar problems with all the HP ARM-based calculators, the CR2032 cells can't deliver the needed current at high clock speeds for prolonged time. The BOD level doens't seem to matter much either. Always using new batteries and/or lowering the clock speed is really the only solution. The cells are in parallel with no blocking diodes which helps handle the peak current draw but stinks as far as battery life goes. -Katie

Re: hp20b hacking: SW reset problem Message #3 Posted by hugh steers on 12 Apr 2010, 3:35 p.m., in response to message #2 by Katie Wasserman thanks. im going to try decreasing the cpu speed slightly. WIP here, http://www.wiki4hp.com/doku.php?id=20b:hpvchess i'll post an update, if i upload a binary that works :-)

Re: hp20b hacking: SW reset problem Message #4 Posted by hugh steers on 12 Apr 2010, 5:01 p.m., in response to message #2 by Katie Wasserman I have discovered that my batteries are knackered! i think it must be that i've drained them too much with this experiment. reducing the CPU speed to 24MHz made no real difference in this case, and the original problem of power dropout happens now right away. i found just one good battery in the back of a drawer and it seems to work, ie i dont get the drop outs, but one battery isnt going to work very well. so what i dont know is how long before new batteries suffer this problem. it looks like the ServiceBOD code tries to handle power drop, but isnt doing a great job. anyway, i compiled a new version and uploaded it on the wiki. this one identifies itself as version "1.0". happy hacking!

Re: hp20b hacking: SW reset problem Message #5 Posted by Tim Wessman on 12 Apr 2010, 10:49 p.m., in response to message #4 by hugh steers If you are running at full speed, you can drain the batteries really quickly. I'd do development with power going in on your cable and that should solve a lot of the problem. TW

Re: hp20b hacking: SW reset problem Message #6 Posted by Walter B on 13 Apr 2010, 1:19 a.m., in response to message #5 by Tim Wessman Quote: If you are running at full speed, you can drain the batteries really quickly. Please, does this mean days, hours or minutes?? Remember being an engineer ... d;-)

Re: hp20b hacking: SW reset problem Message #7 Posted by hugh steers on 13 Apr 2010, 4:51 a.m., in response to message #6 by Walter B i would be interested to know the curve of cpu speed vs power drain and whether it is linear. for example, the points 18, 24, 30, 36 (Mhz). I guess i could test this myself if not known. If the curve is linear, then clearly the same amount of energy is used for a given calculation. however, if the higher speeds are progressively more power hungry, then there is a win to using a slower speed (unless too slow to be useful).

Re: hp20b hacking: SW reset problem Message #8 Posted by Paul Dale on 13 Apr 2010, 5:09 a.m., in response to message #7 by hugh steers The CPU specifications from ATMEL has plenty of power details in section 35.3.2. The consumption looks worse than linear but only a little. e.g. From table 35.10 at VDD=3V, 25 degrees: 8MHz 5.37 16MHz 10.37 20MHz 12.13 24MHz 14.24 30MHz 19.55 36MHz 22.63 Not sure of the units in the second column but I'm sure it is explained in the PDF. - Pauli Edited: 13 Apr 2010, 5:13 a.m.

Re: hp20b hacking: SW reset problem Message #9 Posted by hugh steers on 13 Apr 2010, 6:57 a.m., in response to message #8 by Paul Dale Intersting. from this table, the best speed to power ratio is at 24Mhz. This would be the speed to run at (from a consumption view), unless full-out performance is needed. Also, it would be sensible to back off as battery output drops.

Re: hp20b hacking: SW reset problem Message #10 Posted by Paul Dale on 13 Apr 2010, 7:05 a.m., in response to message #9 by hugh steers The units are mA. Check out the document for lots more details. Google doc6257.pdf to find it. There are lots of options for bits that can be powered down. - Pauli

Re: hp20b hacking: SW reset problem Message #11 Posted by Katie Wasserman on 13 Apr 2010, 8:36 a.m., in response to message #10 by Paul Dale While the speed vs power consumption for the this chip might be close to linear the current draw vs cell capacity is very far from linear. They don't even spec these cells beyond 2ma current draw and even at that level the capacity is half of nominal. At 20ma draw (10 ma per cell) you can probably expect on the order of a couple of hours (maybe less) of useful life from these cells. CR2032 spec sheet These ARM-based calculators really need to be powered from AAA cells or a rechargeable prismatic lithium cell. When running long programs on these calculators you really need to have a large supply of CR2032's handy. Fortunately you can buy the best quality ones in quantity for about $0.25 each. -Katie Edited: 13 Apr 2010, 8:39 a.m.

Re: hp20b hacking: SW reset problem Message #12 Posted by DaveJ on 15 Apr 2010, 2:50 a.m., in response to message #11 by Katie Wasserman Or you just run the calculator at a sensibly slower speed and live with the extra processing time. I mean really, how many people run long programs on such a calc that warrants 30MHz processing speed? Dave.

Re: hp20b hacking: SW reset problem Message #13 Posted by Katie Wasserman on 15 Apr 2010, 12:49 p.m., in response to message #12 by DaveJ Quote: I mean really, how many people run long programs on such a calc that warrants 30MHz processing speed? Just some of us here, playing with silly ways to factor 10 digit numbers. I agree, lowering the clock speed is the way to go with this platform. -Katie

Re: hp20b hacking: SW reset problem Message #14 Posted by DaveJ on 13 Apr 2010, 8:21 a.m., in response to message #7 by hugh steers Quote: i would be interested to know the curve of cpu speed vs power drain and whether it is linear. for example, the points 18, 24, 30, 36 (Mhz). I guess i could test this myself if not known. If the curve is linear, then clearly the same amount of energy is used for a given calculation. however, if the higher speeds are progressively more power hungry, then there is a win to using a slower speed (unless too slow to be useful). Correct, running at lower speed is better for consumption. I've discussed this at length here before, and I've done a blog episode on the exact issue: http://www.eevblog.com/2009/04/16/eevblog-4-low-power-calculator-design-and-fpgas/ The processor consumption is essentially linear with speed, as it is with most CMOS processors. But in the case of this design it is the battery series resistance that causes a non-linear issue that gets worse as the battery life drops. So it is IMO a poor design choice to operate the calc at 30MHz off CR2032 batteries. Cyrille eventually admitted this and said he would be more cautious of using that high a speed in subsequent designs. I don't believe he has, the newer calcs do the same thing I believe. Dave.

Re: hp20b hacking: SW reset problem Message #15 Posted by cyrille de Brébisson on 14 Apr 2010, 8:43 a.m., in response to message #14 by DaveJ Hello, Quote: Cyrille eventually admitted this and said he would be more cautious of using that high a speed in subsequent designs. I don't believe he has, the newer calcs do the same thing I believe. The latest version of the SW only uses high speed when needed, and only for a short period, after that, it drops back to more manageable levels for the battery. since most calculation that will finish in any resonable time will finish before the speed drops, it seems to work well. regards, cyrille

Re: hp20b hacking: SW reset problem Message #16 Posted by DaveJ on 13 Apr 2010, 8:14 a.m., in response to message #6 by Walter B Quote: Please, does this mean days, hours or minutes?? Remember being an engineer ... d;-) IIRC the processor is speced at nominally 0.5mA/MHz So for two paralleled CR2032 batteries at 240mAH @ 30MHz, ignoring losses like the series resistance and the low batt cutoff point. The best case battery life at full speed would be 480mA/15mA = 32hours. So realistically you'd be lucky to get say 24 hours. Dave.

Re: hp20b hacking: SW reset problem Message #17 Posted by Bart (UK) on 13 Apr 2010, 11:00 a.m., in response to message #16 by DaveJ Quote: So realistically you'd be lucky to get say 24 hours. At 7.5mA per cell continuous you'd be lucky to get 15 hours. Quote: ignoring losses like the series resistance and the low batt cutoff point That's exactly where the problem lies at high drain. The internal resistance causes loss of output voltage and very high drains could cause it to drop below the equipment drop-out voltage almost immediately. Of course this does not mean that you've used up all the energy of the cell, you can still "use it up" by using the cells in low drain devices. Edited: 13 Apr 2010, 11:07 a.m.

Re: hp20b hacking: SW reset problem Message #18 Posted by Bill (Smithville, NJ) on 13 Apr 2010, 1:14 p.m., in response to message #17 by Bart (UK) Quote: That's exactly where the problem lies at high drain. The internal resistance causes loss of output voltage and very high drains could cause it to drop below the equipment drop-out voltage almost immediately. I used to see that exact thing happen on a HP-200LX with Duracell AA's when using an IBM 10 Volt PCMCIA flash memory card. With Duracell's, you would see the battery low message instantly whenever you turned on the 200LX. With Everyready batteries, that didn't occur. I remember someone telling me that was because of the initial high current drain the card caused and that Duracell's had a higher internal resistance than the Everyready's. Bill

Re: hp20b hacking: SW reset problem Message #19 Posted by cyrille de Brébisson on 13 Apr 2010, 8:31 a.m., in response to message #4 by hugh steers Hello, Did you try putting breakpoints on the abort and other FIQ handler in order to see if that was not what was causing your reset? you might be filling your stack for example. This would cause a reset... You can run the CPU at 36MHZ on battery power for as long as the battery will last with no reset. When you put a normal 20b in Test System Mode, it does run at 36Mhz continuously. At that speed, you get less than 24h of battery life however. This is why I always run the calculator on AA battery for testing... The cpu speed vs power consumption is fairly linear in the 0.6mA/Mhz range. of course, the battery life is not linear as the internal battery resistance play a more and more preeminent role as the power drain increases. Also, the actual mips is not linear as you have to put 1 wait state once you get over 15Mhz.... This can cause a slow down of the actual CPU instruction throughput. Depending on your program. Cyrille

Re: hp20b hacking: SW reset problem Message #20 Posted by hugh steers on 13 Apr 2010, 11:08 a.m., in response to message #19 by cyrille de Brébisson I'll try those breakpoints later and report. At first, i suspected the stack, the usual suspect of random crashes :-) but i think that's ok. i've actually increased the default stack size to be sure. since powering off a brand new cell, it is working fine (until i drain it that is!). so im still suspecting the power problem. im wondering whether to get the ServiceBOD code to reduce the fast speed that is used when processing an operation (a move in this case!). it might be a good way to prevent power outage. also, do you know what happens to the battery backed RAM when power drops below operation - does this get kept or is there no guarantee. thanks,

Re: hp20b hacking: SW reset problem Message #21 Posted by David Hayden on 13 Apr 2010, 10:31 p.m., in response to message #1 by hugh steers I'm not familiar with the 20b, but when doing low-level programming, one cause of crashes can be writing to the wrong side of the stack pointer. Since an interrupt service routine can change the contents of the free memory that the stack grows into, you have to always allocate space on the stack before using it. Basically, you have to pretend that memory on the "wrong side" of the stack pointer contains random bits that constantly change. Dave

Re: hp20b hacking: SW reset problem Message #22 Posted by hugh steers on 14 Apr 2010, 8:08 a.m., in response to message #21 by David Hayden Hello, I have found out the source of all my problems! confession: my game variables were not located in battery backed ram. turns out that many of them don't need to be because they are initialised each time, but a few are important. Like, er, the board state. However, it looks like you get away with this quite a lot. maybe the non-backed ram works for a while but is unreliable. this is likely between different units. i have uploaded a new binary (V1.1) that has a, very small, opening book. http://www.wiki4hp.com/doku.php?id=20b:hpvchess It was the opening book that revealed the problem. i couldnt understand why the program worked fine on everything except the actual calculator (annoying huh). It would play the book and then make an illegal move. what was happening is that the `inBook' state was not being properly reset. This variable and others are now in the 2K backed ram, which handily gives me more space for other stuff :-) The original power problem still persists. basically if your batteries cant cut it, you get a power outage and it powers down, losing all state.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall