▼
Posts: 125
Threads: 9
Joined: Oct 2011
A power management bug in the 15c LE calculator has been reported, here are some anomalies that I experienced. I have been using one of these calculators regularly for the last 5 months and it has shown some strange behaviour, which seems to be at least partly related to power supply and battery issues.
There have been two occasions in the last couple of months when the memory got corrupted. On the first occasion the program memory had a couple of lines here and there swapped that I was able to sort out through editing, but last week I had to re-enter all my programs as the program memory had become filled with many lines of garbage.
In the last 24 hours, rather than displaying a blinking * low battery indicator, the display numbers just turned from black to light grey whenever a key was pressed. I had several occasions when insufficient registers were indicated (incorrectly) to run the solve or integrate functions. Only a total of 50 instead of 65 registers were shown with the g MEM function (having all the matrices A..E set to size 0,0), meaning that the available free registers now fell below the number required for solve or integrate. I could get the calculator to display a total of 65 registers and be able to again use the advanced functions simply by running a program that did some basic arithmetic. This morning I got the Pr Error message in the middle of running the integration function and the calculator had lost the contents of all memory.
In my experience, the calculator with its present firmware (checksum: ChE--FFFFh, 2011-04-15, C 2008 hP) cannot be reliably counted upon to preserve the contents of memory. I would recommend committing all important programs to disk/paper as an external backup. I have each program I use entered in a text file on my computer together with test examples so that I can rapidly enter the programs and check that the code works as intended.
I like using calculator a lot, so I hope a firmware solution can be found by HP (or the user community). As things stand, I now always run a couple of test cases to check the integrity of a program before using it for important work.
Nick
Edited: 29 Mar 2012, 8:42 a.m. after one or more responses were posted
▼
Posts: 384
Threads: 18
Joined: Sep 2010
Quote:
In the last 24 hours, rather than displaying a blinking * low battery indicator, the display numbers just turned from black to light grey whenever a key was pressed.
Sounds line the brownout detector isn't functioning as intended.
Otherwise a dip in the battery rail during peak runtime current
consumption would be detected. Even without/in-conjunction to
the BOD a power-on CRC sweep of nonvolatile RWM would prevent
the device from attempting operation with corrupt data.
Quote:
I had several occasions when insufficient registers were indicated (incorrectly) to run the solve or integrate functions.
Random corruption which was apparent. The greater concern
of course is undetected RWM corruption.
Quote: This morning I got the Pr Error message in the middle of running the integration function and the calculator had lost the contents of all memory.
Perhaps the BOD threshold is set too low. The above
is what should happen if the battery rail dips out of tolerance
given no other recovery provisions exist. A more versatile
solution would have leveraged the addition of a 25-cent (+/-)
high endurance EEPROM to the board and maintained one or more
version shapshots of NV RWM state within it.
Quote: I would recommend committing all important programs to disk/paper as an external backup. I have each program I use entered in a text file on my computer together with test examples so that I can rapidly enter the programs and check that the code works as intended.
That's quite an ironic usage model in 2012. I don't know
where the emulator footprint space/speed tradeoff was struck
for this implementation, but I suspect it quite unlikely the
entire 128KB flash is consumed. Shuttling 2KB of state out/into
the device over a serial link shouldn't require in excess of
~1KB of code for a basic image dump, perhaps a bit more for
a fancier approach.
The existing programming interface is a bit of an awkward physical
connection as a general external interface but it is far
better than nothing. Beyond that a usb converter and mini usb
connector might have weighed in around US$3 to the BOM cost,
probably less. But to be fair the development budget for
support of such features was probably the actual reason for
their absence.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
The flash is writable from within the firmware. It would have been no big problem to create a key sequence that backs up RAM or restores it. I've done just this in the WP 34S.
The brown out detector on the Atmel chip is a single bit which indicates that a programmed threshold has been reached. Since the detection mechanism takes a few slow clock cycles to give an accurate reading it's necessary to sample the bit at regular intervals and modify the threshold until a change in the bit is detected. WP 34S has not problem doing this because a heartbeat interrupt is executed at about 50 times a second. The brown out detection is done in this interrupt and should therefore be adequately accurate. The HP firmware does an immediate deep sleep after a key press is executed so there is no time left for a regular interrupt. The BOD detection should go into the NUT processor emulator which must be executed in a relatively tight loop while the system is doing something. I'm afraid that this is not the case.
▼
Posts: 384
Threads: 18
Joined: Sep 2010
Quote:
The flash is writable from within the firmware. It would have been no big problem to create a key sequence that backs up RAM or restores it. I've done just this in the WP 34S.
Given the skeletal sam7 voyager design this would have been a
reasonable feature.
If I had a choice I'd opt for an external device from several
motivations. One being even inexpensive devices exist with
1M (vs. 10K) cycle endurance permitting automatic non-volatile
save to flash with each power off operation. In this service
the wearout of a 1M cycle device easily exceeds wearout of the
tactile domes so doing so arguably doesn't impact longevity
of the device.
Better yet given the scant 2KB of NV RWM and comparatively
large flash devices, rolling sequences of snapshots could be
maintained such that if the latest backup was corrupted (eg:
brownout condition during a backup write), the previous
version is available to the user for restoration. Speaking
of brownout during flash writes, I'd prefer that potential
scenario to unravel in a flash array other than that
containing the emulator firmware. This theoretically
shouldn't be an issue assuming a bug-free flash controller
implementation. However I've encountered enough "Low VDD"
flash write errata to make me want to push this elsewhere
if possible.
Another consideration to push this relatively low bandwidth
state save operation to slower non-executable external
flash, is to conserve the limited fast internal executable
flash for ARM code or access latency critical data.
Quote:
The HP firmware does an immediate deep sleep after a key press is
executed so there is no time left for a regular interrupt. The BOD
detection should go into the NUT processor emulator which must be
executed in a relatively tight loop while the system is doing something.
Agreed sampling the battery rail during the emulation cycle
should catch the worst case loading. However I'd expect a
periodic interrupt is likely active after a POWOFF instruction
emulation which is used to implement timed device shutdown.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
However I'd expect a periodic interrupt is likely active after a POWOFF instruction emulation which is used to implement timed device shutdown.
In the original HP 20b SDK there is no periodic interrupt for the timed shutdown and I assume that the 15C LE firmware is based on the same basic routines. HP uses the RTC alarm to cause a wake-up after some minutes. This wakes the processor just to turn off the display and the normal keyboard wakeup.
One problem with a periodic interrupt is that the time base for the PIT (periodic interval timer) varies with the CPU clock and needs to be updated with every speed change (which are quite common to conserve power). I'm using the LCD controller interrupt for the purpose. :-). I've implemented a short delay after the last key stroke before the device goes to deep sleep with just the LCD active. The wakeup for shutdown after the APD delay is done with the RTC alarm, as it is in HP's implementation.
Posts: 875
Threads: 37
Joined: Jul 2005
I believe it is pretty well established that the blinking * low-battery indication does not function with the 15c LE running the 2011-04-15 firmware. I never saw it in my battery life experiment. As you found, when the battery voltage drops below some threshold while the unit is in a high-current draw state, the processor shuts down and flushes memory. You seem to have experienced new phenomena, corruption of memory and dimming of display with key press, but I think they are symptomatic of the same problem of there being no graceful shut-down on low battery.
Quote:
I hope a firmware solution can be found by HP (or the user community).
My hope that a fix will be provided by HP is fading. The talent most likely exists in the user community to either fix the 2011-04-15 firmware, or do another port of the rom which would not have the problems reported with the rom developed by HP. But that could be a lot of work to ask of those with the talent, and there is also concern over potential legal issues. So the 2011-04-15 firmware may be the best we ever get, in which case users should do as you suggest, write down all programs. I was going to suggest that perhaps batteries could be preemptively changed on a scheduled basis, but I recalled that when I did my tests, swapping in new batteries (one at a time as directed) often led to Pr Error anyway, so users might as well run the batteries all the way down.
▼
Posts: 125
Threads: 9
Joined: Oct 2011
The supplied batteries were Panasonic CR2032. I will experiment with a different brand and see if there are any differences in behaviour, especially the corruption of memory I experienced a month before the exhaustion of the batteries.
I would rather have had a 2 to 10 times speed up, rather than an 150x calculator that shows these symptoms. Even native speed emulation would have been acceptable, if I could have relied on it retaining my programs uncorrupted. I am fine with the hardware and the keyboard is quite good, but the released firmware is in my view inadequate.
Like a number of other enthusiasts here, I signed the on-line `Bring Back the HP 15C' petition and bought several of these calculators out of a mix of nostalgia and the attractiveness of a small pocket size. However, without a fix these may well be the last new HP calculators I will buy.
Nick
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
Quote: However, without a fix these may well be the last new HP calculators I will buy.
That was my 2008/2009 resolution after the 35s, but it didn't hold ;-).
A fix is not the only problem (however, there is one reported 30b update and an updated 20b firmware in the SDK) - communicating it is another one. There's no supported way to reflash a HP calculator as there's no cable to buy from HP. That must be so much of a problem to HP that the inofficial updates will remain attached to new hardware.
Of course, I'll refuse to buy another reflashable calculator but expect new images available in the official channels.
@Tim, please try to do something about that :-(.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
The new designs are based on USB and reflashing is an option for the end user. That has been exercised for years now for the 49g+ and the 50g and will be available for the 39gii. I agree that it is a problem for the Atmel based devices 20b, 30b, 10bii+, 12C+ and 15C LE.
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
The problem is this #*$! (fine) cable, right?
▼
Posts: 125
Threads: 9
Joined: Oct 2011
I have the cable (thanks to Gene Wright). The problem is not having a revised firmware to upload...
Nick
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
Quote:
I have the cable (thanks to Gene Wright). The problem is not having a revised firmware to upload...
Nick
I too have one. I meant if there's no official distribution of those cables, how would HP handle requests for them if they make updates available from their website? Should they answer 'please ask Gene'?
▼
Posts: 756
Threads: 31
Joined: Aug 2010
Just out of interest, does Gene have any cables left?
Posts: 875
Threads: 37
Joined: Jul 2005
Quote:
I meant if there's no official distribution of those cables, how would HP handle requests for them if they make updates available
from their website?
I think this may be one of main reasons we may never see a new rom. The complexity of the re-flash procedure and special equipment required (special cable from HP plus USB to serial converters for many) makes it untenable for general application supported by HP. That leaves in-house reflashing by HP, or enlisting a cadre of outside volunteers to do it for the general public. The former would be costly, the latter would require HP to assume liability for the volunteers’ handling and return of the units.
▼
Posts: 202
Threads: 9
Joined: Jul 2009
I would think HP could do something along the lines of "Here's a firmware update, this is how you load it." HP gave Gene the cables, so they *could* potentially sell them on their website. A reasonable option for those who don't have cables or want to deal with SAM-BA (at least from HP's perspective) could be to have current owners pay something to cover the shipping/labor costs for a reflash. Of course, people would complain about that, but if volunteers wanted to offer to do it for only the cost of shipping they certainly could, and it would absolve HP of responsibility for volunteers bricking calculators since there did exist an official channel.
-- Just my 2 cents worth
Posts: 875
Threads: 37
Joined: Jul 2005
Quote:
I would rather have had a 2 to 10 times speed up, rather than an 150x calculator that shows these symptoms.
Someone (Marcus?) correct me if I am wrong, but I do not think the speed-up is the cause of the problems. The cause is inadequate (or non-existent) brown-out detection. Speed-up does impact how long the batteries last of course and so therefore how quickly you will get to the point of the brown-out problem, but it will still happen eventually. I got something like 16 hours of program run time out of a set of batteries, which I consider adequate and would prefer to retain the high speed operation. A lower speed setting to extend batty life at the user’s discretion would be a welcome addition, though.
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
I agree, the speed up is not the real problem, even the 20ma current draw when a key is held down is not the real problem. The total failure of the low battery detection and functional brown-out detection shut down are the real power issues. The 12C+ suffers from these too, but down not have the 20ma key-down problem. Even if these problems are fixed, the chances of losing memory when replacing batteries remains quite high. Having the cells in parallel with with no diode steering was a really bad hardware design.
In addition the broken PSE command on the 15C LE is a big problem in my view.
Releasing a new batch of 15C LE's without a firmware fix seems to signal that HP will not fix these problems. They've only compounded the issue by potentially having to offer firmware updates to the older machines out there.
Unless..... their plan is to release a 15C+ with these issues fixed and hope that all of us will buy that one to use and stick our 15C LE's away in a drawer.
▼
Posts: 50
Threads: 1
Joined: Sep 2011
The 35s seems to be poor this way as well. Last week, I pressed R/S to evaluate an equation I've used many times before, and was rewarded with a flashing 'memory clear'. I had to pull the batteries to clear this.
Before replacing the batteries, I experimented a bit. With a simple equation that could be evaluated in a second or so, when the answer appeared, so did the low battery warning, but it only stayed on for a few seconds at most. With a more complicated equation, the crash recurred. At no time have I seen the low battery warning during normal use from the keyboard.
I think this was only the second set of batteries since 2007, but it would have been nice to know they were low before the memory was wiped.
Posts: 384
Threads: 18
Joined: Sep 2010
Quote:
I agree, the speed up is not the real problem, even the 20ma current draw when a key is held down is not the real problem. The total failure of the low battery detection and functional brown-out detection shut down are the real power issues.
To be fair the problem requires a bit of futzing to address.
In the legacy voyagers this lowbatt indicator was an
autonomous hardware function implemented in the display
controller.
In the sam7 version this segment is program driven. So we
need to be in the window of a battery rail between significantly
low but above inoperably low voltage. And there will be some
swing above/below the BOD threshold during execution due to
dynamic current draw such that hysteresis and/or averaging are
likely needed to ferret out a true lowbatt condition.
The excessive current draw on the CR2032 cells exacerbates the
problem by increasing the dynamic current swing and essentially
lowering the S/N ratio of the available information.
Beyond this the LCD drive varies with the battery rail
voltage which is substantially depressed in this state
(charge pump is disabled according to my schematic take
off) and LCD glass itself has a minimum polarization voltage.
The combination of which may cause an erratic display at
reduced voltage when attempting to convey this condition to
the user.
Quote:
The 12C+ suffers from these too, but down not have the 20ma key-down problem. Even if these problems are fixed, the chances of losing memory when replacing batteries remains quite high. Having the cells in parallel with with no diode steering was a really bad hardware design.
A dual isolation diode exists in the sam7 voyagers. But
it appears bypassed in production presumably as the reduced
headroom caused by the diode voltage drop was found to be
more of a liability than losing the benefit of cell isolation.
I'm still not seeing where a live cell replacement would
short the rail. The mechanical design of the CR2032 wells
is such that accidental shorting of both terminals via a
cell removal/extraction appears quite unlikely.
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
Quote:
accidental shorting of both terminals via a cell removal/extraction appears quite unlikely.
If you accidentally start putting the battery in upside down it will instantly short out the contacts well before you realize what you're' doing wrong.
But I've found that even putting the cells in the correct way, on the 12C/15C, it s really quite easy to get create a short if I'm not very careful. Try doing it a few times without paying a lot of attention and I'll bet that you'll get "Pr Error" at least 30% of the time.
▼
Posts: 875
Threads: 37
Joined: Jul 2005
It seemed to me that a Pr Error was more likely the lower the battery voltage got, e.g., when replacing ones at 2.5 Volts with new ones at 3.1 Volts. I don't know if there is any technical reason for that to occur.
Posts: 384
Threads: 18
Joined: Sep 2010
Quote:
If you accidentally start putting the battery in upside down it will instantly short out the contacts well before you realize what you're' doing wrong.
Indeed that's true. I'm unsure how mechanical polarizing could
have prevented this given the lack of useful asymmetry in a coin
cell envelope and the drop-in nature of the well on a sam7
voyager. But this is the same consideration seen by other
coin cell powered devices. So while an inherent limitation of
the package, it seems more/less workable in practice.
Quote:
But I've found that even putting the cells in the correct way, on the 12C/15C, it s really quite easy to get create a short if I'm not very careful. Try doing it a few times without paying a lot of attention and I'll bet that you'll get "Pr Error" at least 30% of the time.
I took another look at a sam7 cell well and it does have
substantially less daylight than I'd recalled. The
anode fingers project out considerably as they are the only
source of vertical contact compression. So this could be
finessed at additional cost/complexity if the problem
was found to be prevalent, presumably with the sam7 12c+.
Adding a parallel
diode to shunt cell reversal, and addressing
the larger problem of relying on a constant battery rail
to retain data in the device would be my redesign approach.
|