hp20b hacking: SW reset problem



#23

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?


#24

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


#25

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 :-)

#26

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!


#27

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


#28

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;-)

#29

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).


#30

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.


#31

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.


#32

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


#33

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.


#34

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.


#35

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

#36

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.


#37

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

#38

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.


#39

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.


#40

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

#41

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


#42

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,

#43

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


#44

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime reset to factory state? BruceH 3 694 11-26-2013, 07:27 PM
Last Post: BruceH
  HP Prime - Reset methods bluesun08 3 402 11-21-2013, 09:49 AM
Last Post: Joe Horn
  HP-41 Clonix&NoV's SW Update. (For the non-Primer's guys out there... :-) Diego Diaz 21 1,196 11-13-2013, 09:00 AM
Last Post: Ángel Martin
  HP PRIME: How to change the column headers and reset data Joseph Ec 5 456 10-18-2013, 02:26 PM
Last Post: Joseph Ec
  Explaination on How to Reset Caculator in Users guie: error Harold A Climer 5 472 10-15-2013, 02:11 AM
Last Post: cyrille de Brébisson
  RESET App from a program. Joseph Ec 0 187 10-14-2013, 12:28 PM
Last Post: Joseph Ec
  HP Prime reset to factory settings bertopl 16 905 09-28-2013, 03:53 AM
Last Post: bertopl
  HP Prime -- app reset bug Han 0 191 09-26-2013, 01:54 PM
Last Post: Han
  Latest Clonix/NoV's SW update. Diego Diaz 5 433 02-15-2013, 12:12 PM
Last Post: Ángel Martin
  hacking the hp 17bii+ David Griffith 2 236 11-27-2012, 04:12 AM
Last Post: Walter B

Forum Jump: