PY32F002B: To trust or not to trust on flash endurance?

[Sacodepatatas]

In the program i'm doing, there's some user settings (about 128 Bytes) that might be stored in flash whenever the user has changed some of them (usually after exiting from the main menu). This MCU has 24KB of available flash. I have been adding many features to my program so currently it's occuping about 18KB. There's no many features left for implementing, but I wonder if i might keep the last 6KB left for future updates or just use the last 4KB sector for storing the settings 32 times before erasing the whole sector (implementing a sort of wear leveling). Besides that, there is the user OTP flash that, despite its name, its just a regular flash page of 128 Bytes, that can be used for storing user data. The datasheet states a number of erase/program cycles that, being sincere, i don't trust very much on it. If I asume that a flash page can be erased 10K times, then it is enough to just use the USER OTP flash, because it is unlikely that the user would change the settings ten thousand times during the life time of the device, but if the real number is much lower, lets say, 500 times, then using the last sector of the main flash wouldn't be a bad idea at all. What would you do? Any advices? Thanks.

[brucehoult]

Without knowing the exact use-case it's hard to know how ofter a user is likely to change settings.

But I think it's reasonable to assume that even on a 10c Chinese chip the specs aren't completely made up and 500 or 1000 rewrites is not going to be the limit when they claim 10000. More likely, it's going to actually do 10000, or close to it, at the most extreme environmental conditions in the data sheet and you're hopefully not operating it at or outside of those environmental conditions.

[Smokey]

Run the experiment and write the flash until it wears out.

[SiliconWizard]

Run the experiment and write the flash until it wears out.

Yes and be patient. At room temperature, you may need to wait a pretty long time.
Now if very frequent writes are expected, using an external EEPROM or FRAM may be warranted. A 32 kbits EEPROM can be had for about 3-4 cents per 1000. 1 million write cycles minimum guaranteed and 100 years retention. I know that's expensive though.

[DavidAlfa]

I don't know about the 002B variant, the 002A datasheet guarantees 100K cycles. It specifies 3ms / 1ms  (Typ.) for page erase/write.
Assuming you can perform a full erase+write cycle in 5ms, that's 200 cycles per second, 100K cycles will take less than 10 minutes!

Edit: I tested myself, it's doing an erase+write cycle in just 2ms...
It did ~300Kcycles, still going...
I'm cycling these patterns: 0x11223344, 0x22334455, 0x33445566, 0x44556677, 0x55667788, 0xAA55AA55, 0x55AA55AA, 0x00000000

Edit: Stopped the test at 1.3M cycles... No issues.

[IOsetting]

Puya's main products are flash and eeprom https://www.puyasemi.com/en/about.html 
I don't worry too much about their flash endurance.

[wek]

> no issues

And the retention is stilll 10-20 years on those cells, isn't it.

JW

[Siwastaja]

Run the experiment and write the flash until it wears out.

IMHO, useless advice.

First, you can't design a product on a single specimen; worst case can be orders of magnitude worse.

Second, destructive flash testing takes tens of years to complete, because it consists of the wear phase (as you suggest), but also the subsequent waiting step to see to what level the retention time reduced to. It's not like the cells are completely killed; no, their leakage increases and thus data retention time decreases, but does not go to zero.

There are of course ways to do accelerated testing (e.g., by increasing temperature and knowing from literature how to translate the result back to actual operating temperature range) but now you are in the territory of spending man-years on R&D, while you should be trusting the flash manufacturer's characterization (they have hopefully done this job) and concentrate on developing your own product.

My advice for the OP is, pick one sector and implement simple "write subsequently until sector is full, then erase" scheme. Then add some way to limit the user from doing adjustments in an automated way too often. If it's actual pressing buttons through menus, don't worry about it. For example, if write endurance is 10000 cycles * 32 (from the simple wear leveling) and product lifetime 10 years, that would mean someone adjusting the setting 87 times every single day. That's just not going to happen.

But be careful if settings can be adjusted through some interface (uart, modbus, IoT, whatever). Then, even if you thought it's just a "setting" and not "operating parameter", some user will find it useful as real-time operating parameter and write it once a second automatically.

[DavidAlfa]

Generally, don't store anything until the user exits the menu... will already reduce the write cycles by a lot.

Yeah, leakage and retention are hard if not impossible things to test out...
You can't store the device for 10 years, check if it survived, and then start selling your product!

[Smokey]

Run the experiment and write the flash until it wears out.

IMHO, useless advice.
...

As a rigorous proof of performance, yes, of course for all the reasons you pointed out. 

But I think the main question here is whether the company lied on the datasheet.  Since the parts will probably fail in a normal distribution, a small sample of parts run through a write-to-failure cycle have a good chance of giving you the data you are looking for.  Which again, is a spot check on the datasheet spec (with all the caveats you pointed out like how hard it is to prove long term reliability in accelerated testing).  You only need one part to fail or underperform.

When I did a device that had a similar function, it was battery operated and I was in control of power up and shut down so I didn't write to flash until the thing turned off.  That greatly reduced user induced data updates and flash writes of stuff like this.

[brucehoult]

When I did a device that had a similar function, it was battery operated and I was in control of power up and shut down so I didn't write to flash until the thing turned off.  That greatly reduced user induced data updates and flash writes of stuff like this.

If doesn't take much of a capacitor to give a brown-out interrupt handler time to do that.

I haven't tried this in a good long while, but in the 80s I demonstrated to people that I could unplug Apple (both Mac and Apple ][) computers and plug them into the adjacent power socket and they'd just keep on running. You had to be pretty quick :-) That was on 240V with switch-mode power supplies that also worked on 110V. I think they were labelled as 80V-280V. It might or might not work if you started with only 110 :-)

[Sacodepatatas]

But I think it's reasonable to assume that even on a 10c Chinese chip the specs aren't completely made up and 500 or 1000 rewrites is not going to be the limit when they claim 10000.

As DavidAlfa said, they claim 100k cycles, but, they only specify the retention for 20 years after 10k cycles. I said retention and not "data retention" because acording to the datasheet, they guarantee "date retention", whatever that means.



Besides that, i believed it was reasonable to trust on the ADC accuracy, and then i found that the 4 LSBs out of 12 are very noisy (no matter how much sample time or ADC clock speed), almost random. Thanks god that i don't need high speed so i can oversample and extract the 4 remaining bits or even more bits by aggressive low pass filtering.

Run the experiment and write the flash until it wears out.

I thought of it, but as some stated, it's not how many times a flash section can be erased, but how long will hold the new programmed data. I would test if 10k cycles is enought, by doing one cycle every 10 seconds in order to let some settling time, then i would know if 10k cycles are reached by waiting a week or so. Anyhow, this wouldn't be a serious test, as you know. Anyway this is not a life supporting device, although i don't want the user to get a bricked thing if the flash eventually fails retaining user data.

Now if very frequent writes are expected, using an external EEPROM or FRAM may be warranted

Not the case, having the settings stored in memory is more of a convenience rather than a need. Many users won't deviate so much from the default configuration. In fact, i programmed almost all features before thinking of this issue. Some users will replace the standard sensor with a non standard one, or one from a different application, or just want to fine tune the sensing range, then having customized parameters is a good thing.

I don't know about the 002B variant, the 002A datasheet guarantees 100K cycles.

I'm planning to go to the IOT world congress next month (from 13th to 15th in Barcelona). If you aim to go there aswell, we can meet and i'll swap a tube with you by a coffee. That's at least 10 "PY32F002B" chips  (i've got SOT16 and SOT14 variants for replacing old PIC16 projects), and, speaking of Barcelona, easily 20 chips 

Edit: Stopped the test at 1.3M cycles... No issues.

Some time ago i read in hackaday about a guy that did such a test with a PIC that claimed to guarantee about 100k cycles, the test reached about 5 Million before the IC  failed... Of course more of a curiosity than a workbench test.

Puya's main products are flash and eeprom
I don't worry too much about their flash endurance.

I know, that is one point towards the "trust the datasheet" consideration. However i don't forget 25 years back when the Microchip's PIC16F84A failed programming after no more than 50 cycles but they guaranteed a minimun of 1000 cycles.

But be careful if settings can be adjusted through some interface (uart, modbus, IoT, whatever). Then, even if you thought it's just a "setting" and not "operating parameter", some user will find it useful as real-time operating parameter and write it once a second automatically.

Very good advice. I was just casting the relevant structs to a RAM buffer, then format the buffer and save it to flash (then, when reading, casting some pointers back to the flash to compare the current parameters with the stored ones). In my code there is a function that compares the RAM buffer with what is stored in flash, and if they are different after the user leaves the main menu, then such buffer is programmed, but then i save an erase/program cycle if the function returns that both buffers have the same content... After i read you i recalled that some parameters within the structs are not changed by the user but by the operating conditions (ADC, Timers...), so the function was returning always "different content" unnecessarily. I changed that to just look up the user settings. Thanks.

I have been thinking about it for some days, and i finally found a nice solution. I call it "Let the user having the responsibility of managing the case in which the flash may fail be a product feature". Let me show:

Currently, the params buffer that is stored in flash begins with the header "0xdeadbeef" and ends with a computed CRC (excluding the header) because... well, because the CRC hardware comes free with this device. I can add a menu feature to let the user select the "Working profile", and let have 5 profiles, the first of them in the user OTP area (0x1FFF0280) and the rest at the end of the main memory (0x08005E00, 0x08005E80, 0x08005F00, 0x08005F80). I should test it, but i think i can change to zero an already programmed page. Then I can mark a non-selected profile with the header "0xdead0000". The time the device boots up, a function would search for valid profiles (those that pass the CRC check), then see if the active profile is within them and use it, or if there is no active profiles within the good ones, let the user select one of them before starting, report the last profile used as corrupted and encourage the user to not use it anymore.

As a curiosity, when talking about the information area of the PY32F002B, the area across 0x1FFF0200 to 0x1FFF027F, according to the reference manual/datasheet, is reserved. But if you dump from 0x1FFF0200 instead of 0x1FFF0280, you get this...

[DavidAlfa]

You can program single words in stm32, but not in py32, you must program an entire page.
I recall reading that an already programmed page can only be erased or zeroed, so don't overcomplicate it.

[Sacodepatatas]

You can program single words in stm32, but not in py32, you must program an entire page.
I recall reading that an already programmed page can only be erased or zeroed, so don't overcomplicate it.

That's what I refer to. I can program a page already programmed with a mask such as {0xFFFF0000, 0XFFFFFFFF, ...}... Just I want to avoid neither having to erase/write both the old and the new profile respective pages, nor having an update index/counter within the settings.

Edit:

Tested, it works. Two consecutive writes, the second masks the first one...

[NorthGuy]

Besides that, i believed it was reasonable to trust on the ADC accuracy, and then i found that the 4 LSBs out of 12 are very noisy (no matter how much sample time or ADC clock speed), almost random.

Most likely, it is your signal, or voltage reference, or power, causing the noise, not ADC.

[DavidAlfa]

Try powering it from a battery, but ADCs in these cheap mcus are just that, cheap 

[John Celo]

Besides that, i believed it was reasonable to trust on the ADC accuracy, and then i found that the 4 LSBs out of 12 are very noisy (no matter how much sample time or ADC clock speed), almost random

I've had the exact same observation about ADCs in these. So much so that it felt like it's just an 8bit adc. It's still possible that I messed up somewhere and might go recheck sometime in future (I've learned quite a lot since then and might get better results this time)...

[IOsetting]

I've had the exact same observation about ADCs in these. So much so that it felt like it's just an 8bit adc. It's still possible that I messed up somewhere and might go recheck sometime in future (I've learned quite a lot since then and might get better results this time)...

I feel so, too, only 8~9 bits are reliable, the last few bits might change randomly.

[SiliconWizard]

That's the case of an awful lot of MCU ADCs, not just the cheap ones either.
The RP2350's ADC has a min ENOB of 9 bits and typical 9.5 bits, and they have improved it - in the RP2040, it was close to 8 bits.
For STM32 MCUs, the 12-bit ADCs have usually around 10 ENOB.

There are a few MCUs out there with *good* ADCs, but they are usually niche.

[NorthGuy]

That's the case of an awful lot of MCU ADCs, not just the cheap ones either.
The RP2350's ADC has a min ENOB of 9 bits and typical 9.5 bits, and they have improved it - in the RP2040, it was close to 8 bits.
For STM32 MCUs, the 12-bit ADCs have usually around 10 ENOB.

There are a few MCUs out there with *good* ADCs, but they are usually niche.

Published ENOBs are for ideal conditions. The power supply noise, the noise from the CPU switching, if not completely decoupled, the noise coupled on the reference, the inherent signal noise, the noise coupled onto the signal from ground currents or from nearby wires. 12 bit is roughly 0.025% - 50 uV for a 2V signal. You need to work really hard to reduce noise to such levels. 10 bit is 0.1% - 200 uV for a 2V signal. You won't get that without trying.

[SiliconWizard]

That's the case of an awful lot of MCU ADCs, not just the cheap ones either.
The RP2350's ADC has a min ENOB of 9 bits and typical 9.5 bits, and they have improved it - in the RP2040, it was close to 8 bits.
For STM32 MCUs, the 12-bit ADCs have usually around 10 ENOB.

There are a few MCUs out there with *good* ADCs, but they are usually niche.

Published ENOBs are for ideal conditions. The power supply noise, the noise from the CPU switching, if not completely decoupled, the noise coupled on the reference, the inherent signal noise, the noise coupled onto the signal from ground currents or from nearby wires. 12 bit is roughly 0.025% - 50 uV for a 2V signal. You need to work really hard to reduce noise to such levels. 10 bit is 0.1% - 200 uV for a 2V signal. You won't get that without trying.

For sure. That's just what one could expect at the very best. If this best case doesn't meet your requirements, then it's directly game over. Mentioning it, because it's an extremely common question.
First look at what you could expect in the best case, then assume you will get to that point only with sufficient care.

[brucehoult]

That's the case of an awful lot of MCU ADCs, not just the cheap ones either.
The RP2350's ADC has a min ENOB of 9 bits and typical 9.5 bits, and they have improved it - in the RP2040, it was close to 8 bits.
For STM32 MCUs, the 12-bit ADCs have usually around 10 ENOB.

There are a few MCUs out there with *good* ADCs, but they are usually niche.

It's pretty hard to do precise analogue stuff in the same package with a digital CPU going nuts at the same time.

Maybe if you can (and don't mind) put the CPU to sleep for the duration of the ADC conversion -- possibly thousands of clock cycles.

Or use an specialised external chip that doesn't have all that other stuff going on.

[Doctorandus_P]

If I asume that a flash page can be erased 10K times,

Any advices? Thanks.

Start by looking up flash endurance in the datasheet.

[SiliconWizard]

That's the case of an awful lot of MCU ADCs, not just the cheap ones either.
The RP2350's ADC has a min ENOB of 9 bits and typical 9.5 bits, and they have improved it - in the RP2040, it was close to 8 bits.
For STM32 MCUs, the 12-bit ADCs have usually around 10 ENOB.

There are a few MCUs out there with *good* ADCs, but they are usually niche.

It's pretty hard to do precise analogue stuff in the same package with a digital CPU going nuts at the same time.

Maybe if you can (and don't mind) put the CPU to sleep for the duration of the ADC conversion -- possibly thousands of clock cycles.

Or use an specialised external chip that doesn't have all that other stuff going on.

Yes. Analog Devices have interesting MCUs though with up to 24-bit ADCs and good analog performance, with their ADuCM series.

[DavidAlfa]

Start by looking up flash endurance in the datasheet.

Obviuous and ignoring the main question from the OP