WP34S - Flashing Limits

The documentation advises that there is a risk of, so to speak, wearing out the flash memory if it is used imprudently as there seems to be an upper limit of about 10,000 on how many times it can be rewritten.

How should this effect day to day use? For example, I rather obsessively back up my calculator state with ON-STO-STO, sometimes several times in a day or even a session. Should I refrain from this practice and only back up sparingly?

I ask this because of concern that in some places the 30b can be found at fire sale prices, implying (to me) that the item may be discontinued. I would hate to burn out the flash memory in both of my WP34S units in the next few years, only to find that the base calculator is not easy to find any more and I failed to stock up.

Any thoughts on this? I really see no purpose in having more than two units (heck, who needs more than one?), but I am tempted to get another for rainy day back up as I hope to enjoy my WP34S fascination for many years.



The documentation advises that there is a risk of, so to speak, wearing out the flash memory if it is used imprudently as there seems to be an upper limit of about 10,000 on how many times it can be rewritten.

The 10,000 times is a minimum. I haven't tested the 34S's flash, but when I did some stress testing on USB flash a few years back we comfortably exceeded the rated rewrites by an order of magnitude and in the end we gave up testing before destruction.

Assuming only 10,000 write cycles you can do twenty seven writes per day, every day, for a whole year and not quite reach the threshold. So at a couple a day, you'll likely make a decade without wearing the flash out. I believe that is about as long as the flash is rated to retain its contents.

The comment was originally put in the manual because there was a concern that a program that wrote to the flash could do so often and quickly. I don't think this is the case anymore. In the current firmware, SAVE, PSTO and PRCL are not programmable. So this avenue for self-destruction should be impossible in v3.

Any thoughts on this? I really see no purpose in having more than two units (heck, who needs more than one?), but I am tempted to get another for rainy day back up as I hope to enjoy my WP34S fascination for many years.

I wouldn't bother backing up all that often, the firmware doesn't show too many signs of being unstable or crash prone especially if you doing the same things over and over and not stressing the new features too hard. I usually set up my preferred settings, save to flash and basically never bother doing so again.

Programs are developed in RAM and then flashed to the library but the latter step isn't common.

- Pauli


I don't see a spec for temperature dependence on the number of write cycles or the stated 10 year data retention period. However, I'm willing to bet that there is a strong temperature dependence and that both the data retention period and especially the number of write cycles will decrease substantially with increasing temperature.

Ages ago I built an automatic test setup for very early flash-type memories in development so that we could characterize their write endurance. We found a greater than linear temperature dependence. The semiconductor technology has changed a lot since then, but most of the same principles still apply. I wouldn't keep this on my car dashboard in Arizona and expect flash memory to hold for many write cycles.

Edited: 12 Mar 2012, 11:41 p.m. after one or more responses were posted


The numbers are per flash erase block, not per device. My knowledge in in the area of flash memory, and not specifically the WP34S, but typically, devices purposes spread block usage across the device with wear leveling algorithms. Added to that, flash erase blocks are made up of several pages (a typical configuration is 256 4096k pages making up a single erase block). Each page can be written individually before having to erase the block again.

...And, if it is NAND flash, the device will be able to handle flash blocks that are worn out by retiring them.


I don't know if the AT91SAM7L128 CPU has NAND or NOR flash. Pages are 256 bytes and if I had to guess, I'd go NOR (and probably be wrong :-)

We have no wear leveling in our firmware and no real capability for this.

- Pauli


I suspect I win the temperature and humidity tests :-) Unless we've a unit in India or similar truly tropical conditions. I've had CD cases melt almost unrecognisably on a car seat in the sun (and not even full midday sun at that) and the humidity here is often over 90 percent in summer. At least our winters make up for it -- low humidity and temperatures in the middling twenties Centigrade. Plus, wonderful clear blue skies. I.e. don't intentionally visit during November to February :-)

I could easily be wrong about the write cycles and retention period, but my comments are still realistic -- don't worry too much about flash life outside of a program & there is no need to backup incredibly often.

- Pauli


I wouldn't keep this on my car dashboard in Arizona...

That way I think you'd be more likely to kill the LCD than the flash :-)

Hi all,

Write cycles

As already stated, the write cycles are a minimum - and the device is not going to fail immediately at the 10,001st write. To wear it out within 10 years, you have to flash it about 3 times a day every day of those 10 years. Remember that this is the same technology as those USB drives we use daily. My first 128MB USB drive I purchased 9 years ago (and still in regular use) shows no failures. Any failures we are likely to see in the near future will most probably be as a result of the normal failure rate of these devices rather than wearout.


As most will be used in relatively decent temperature controlled places such as at home or in the office, it will not have a great influence. If it gets left in the car in a hot (or for that matter very cold) part of the world, well there will probably be other problems apart from the flash to worry about. There is of course the question of temperature shock and high temperature cycling - to which commercial ICs are not suited.


I checked my old files and found the earliest reference to that sentence in September 2011 (v2.1 *). At that time, SAVE and similar commands writing to flash memory were definitively allowed in PRG mode. Thus, I put a warning in the manual. Remember those were the days of HHC in San Diego (and it is well known in the world you have to put such warnings in your product documentation before giving such a product to an US-American unless you want to be sued since (s)he will do something nobody elsewhere in this world would do with your product - and if somebody elsewhere really did something alike by lack of reasonable thought, (s)he would be ashamed and tell nobody else - but those people in the US of A run to the next lawyer instead and get you to court and you'll get ruined for nothing. No offence intended but that's what experienced people tell ;-) Now you know.).

And I've learned this way these commands aren't programmable anymore. So it became a win-win situation, didn't it? ;-)


* Addendum: Found meanwhile I wrote that sentence even earlier, i.e. for v1.18 of the manual in early June of 2011. But the reasoning stays unchanged in principle d:-)

Edited: 12 Mar 2012, 1:41 p.m. after one or more responses were posted


... upper limit of about 10,000 on how many times it can be rewritten.

...obsessively back up my calculator state with ON-STO-STO, sometimes several times in a day or even a session.

As said by other, 10,000 is the lower limit - and that will do you quite a while with that kind of usage. Once a day on average will last you 27 years and 5 months minimum.


The Atmel ARM processor uses NOR flash in the microcontroller. This is different than NAND flash in memory sticks. NAND flash always has a memory controller paired with it and typically uses ECC for error detection and correction. True random access NOR flash on most modern microcontrollers today has a minimum write/erase endurance of 10,000 cycles over a -40 to +85 deg. C temp. range. As Katie W. said earlier, this is highly temperature dependent and when operating at around 25 deg. C., this endurance goes up dramatically. The retention time is typically well over 20 years and can be as high as 100 years before the charge will leak from the gate sufficiently to cause a state change. Few (if any) microcontrollers automatically "wear level" through the flash memory array. If wear leveling is needed, an algorithm is usually written that keeps track of the pages written and periodically moves a pointer to a new page to wear the flash memory evenly. Wear leveling is dependent on the memory size, the size of the data written to the memory and the frequency of the write/erase cycle. Also, ECC is used in some flash memory on some microcontrollers, however most do not use it since it consumes extra memory to hold the Error-Correcting Code bits. If a flash cell becomes weak due to being overwritten, it's up to the user to detect it and not use that byte, block or page. That's why many algorithms write to flash memory, then go back and read the block of memory just written and compare it to what was supposed to be written in the block of memory to insure that there are no write/erase errors.


Jim, do you think WP 34S needs a "read after write" verification for the pages which are written internally by the firmware (not by SAM-BA)? I doubt it.


Hello Marcus. In general, I would say no. Since most applications would not even approach the 10,000 write/erase minimums. However if the current algorithm continuously erases/writes the same memory space over and over again when it does a "save", then an aggressive user who saves repeatedly (say 30X/day), could, in a year, exceed 10,000 write/erase cycles. Even at this rate I suspect they wouldn't reach the wear out mechanism for several years. Does the current algorithm rotate throughout unused flash memory space? If not, you may wish to include this in your algorithm so you don't continously erase and write to the same space repeatedly.


Flash is rewritten in the same places over and over again. We simply do not have the room to rotate the writes (neither for the data nor for the necessary code).

So just don't save too often, please!

Possibly Related Threads...
Thread Author Replies Views Last Post
  WP-34s ISP (flashing cable) again ;( Bernhard 16 4,333 11-01-2013, 05:02 PM
Last Post: Bernhard
  Re: [WP34S] Flashing Issues Les Wright 22 4,426 10-30-2013, 02:16 PM
Last Post: Les Wright
  help flashing a hp30b to a wp34s john mantooth 3 1,230 09-25-2013, 08:58 AM
Last Post: Thomas Chrapkiewicz
  Flashing cable for HP 20 / 30B Stefan Koenig 3 1,446 09-19-2013, 05:53 AM
Last Post: Marcus von Cube, Germany
  USB flashing/Li-po boards patryk 6 1,847 09-08-2013, 12:31 PM
Last Post: patryk
  Help with flashing HP30s John Ioannidis 14 2,970 09-04-2013, 09:37 PM
Last Post: John Ioannidis
  Flashing at HHC2013 Kiyoshi Akima 1 842 08-30-2013, 09:12 AM
Last Post: Matt Kernal
  Self-made WP-34s flashing cable? Victor Koechli 6 2,246 08-15-2013, 10:11 AM
Last Post: Les Wright
  wp34s flashing successful at last Glenn Becker 2 1,079 08-04-2013, 04:33 PM
Last Post: Walter B
  trouble flashing wp34s under Linux Glenn Becker 8 1,964 07-23-2013, 02:21 AM
Last Post: Marcus von Cube, Germany

Forum Jump: