HP Forum Archive 21

[ Return to Index | Top of Index ]

HP 15c LE low power anomalies Message #1 Posted by Nick_S on 29 Mar 2012, 3:08 a.m. 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

Re: HP 15c LE low power anomalies Message #2 Posted by uhmgawa on 29 Mar 2012, 8:22 a.m., in response to message #1 by Nick_S 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.

Re: HP 15c LE low power anomalies Message #3 Posted by Marcus von Cube, Germany on 29 Mar 2012, 10:12 a.m., in response to message #2 by uhmgawa 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.

Re: HP 15c LE low power anomalies Message #4 Posted by uhmgawa on 29 Mar 2012, 6:10 p.m., in response to message #3 by Marcus von Cube, Germany 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.

Re: HP 15c LE low power anomalies Message #5 Posted by Marcus von Cube, Germany on 30 Mar 2012, 2:30 a.m., in response to message #4 by uhmgawa 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.

Re: HP 15c LE low power anomalies Message #6 Posted by Jeff O. on 29 Mar 2012, 11:21 a.m., in response to message #1 by Nick_S 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.

Re: HP 15c LE low power anomalies Message #7 Posted by Nick_S on 30 Mar 2012, 2:15 a.m., in response to message #6 by Jeff O. 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

Re: HP 15c LE low power anomalies Message #8 Posted by Thomas Radtke on 30 Mar 2012, 3:48 a.m., in response to message #7 by Nick_S 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 :-(.

Re: HP 15c LE low power anomalies Message #9 Posted by Marcus von Cube, Germany on 30 Mar 2012, 4:32 a.m., in response to message #8 by Thomas Radtke 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.

Re: HP 15c LE low power anomalies Message #10 Posted by Thomas Radtke on 30 Mar 2012, 5:12 a.m., in response to message #9 by Marcus von Cube, Germany The problem is this #*$! (fine) cable, right?

Re: HP 15c LE low power anomalies Message #11 Posted by Nick_S on 30 Mar 2012, 5:24 a.m., in response to message #10 by Thomas Radtke I have the cable (thanks to Gene Wright). The problem is not having a revised firmware to upload... Nick

Re: HP 15c LE low power anomalies Message #12 Posted by Thomas Radtke on 30 Mar 2012, 5:35 a.m., in response to message #11 by Nick_S 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'?

Re: HP 15c LE low power anomalies Message #13 Posted by M. Joury on 30 Mar 2012, 7:00 a.m., in response to message #12 by Thomas Radtke Just out of interest, does Gene have any cables left?

Re: HP 15c LE low power anomalies Message #14 Posted by Jeff O. on 30 Mar 2012, 12:56 p.m., in response to message #12 by Thomas Radtke 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.

Re: HP 15c LE low power anomalies Message #15 Posted by Lincoln R. on 30 Mar 2012, 1:50 p.m., in response to message #14 by Jeff O. 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

Re: HP 15c LE low power anomalies Message #16 Posted by Jeff O. on 30 Mar 2012, 8:31 a.m., in response to message #7 by Nick_S 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.

Re: HP 15c LE low power anomalies Message #17 Posted by Katie Wasserman on 30 Mar 2012, 8:56 a.m., in response to message #16 by Jeff O. 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.

Re: HP 15c LE low power anomalies Message #18 Posted by Derek Walker (UK) on 30 Mar 2012, 9:44 a.m., in response to message #17 by Katie Wasserman 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.

Re: HP 15c LE low power anomalies Message #19 Posted by uhmgawa on 30 Mar 2012, 3:37 p.m., in response to message #17 by Katie Wasserman 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.

Re: HP 15c LE low power anomalies Message #20 Posted by Katie Wasserman on 30 Mar 2012, 6:15 p.m., in response to message #19 by uhmgawa 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.

Re: HP 15c LE low power anomalies Message #21 Posted by Jeff O. on 30 Mar 2012, 8:13 p.m., in response to message #20 by Katie Wasserman 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.

Re: HP 15c LE low power anomalies Message #22 Posted by uhmgawa on 31 Mar 2012, 9:32 a.m., in response to message #20 by Katie Wasserman 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.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall