PY32F002B: To trust or not to trust on flash endurance? - Page 1
Forum section: electronics / general

author: Sacodepatatas
author_rank: Regular Contributor
timestamp: April 12, 2025, 11:50:32 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 13, 2025, 12:38:44 am
content: 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.

author: Smokey
author_rank: Super Contributor
timestamp: April 13, 2025, 04:10:24 am
content: Run the experiment and write the flash until it wears out.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 13, 2025, 12:57:24 pm
content: Quote from: Smokey on April 13, 2025, 04:10:24 amYes 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.

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 13, 2025, 05:26:54 pm
content: 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, 0x00000000Edit: Stopped the test at 1.3M cycles... No issues.

author: IOsetting
author_rank: Regular Contributor
timestamp: April 14, 2025, 03:32:51 am
content: Puya's main products are flash and eepromhttps://www.puyasemi.com/en/about.htmlI don't worry too much about their flash endurance.

author: wek
author_rank: Frequent Contributor
timestamp: April 14, 2025, 09:46:41 am
content: > no issuesAnd the retention is stilll 10-20 years on those cells, isn't it.JW

author: Siwastaja
author_rank: Super Contributor
timestamp: April 14, 2025, 11:13:06 am
content: Quote from: Smokey on April 13, 2025, 04:10:24 amIMHO, 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.

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 14, 2025, 03:25:31 pm
content: 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!

author: Smokey
author_rank: Super Contributor
timestamp: April 14, 2025, 08:28:54 pm
content: Quote from: Siwastaja on April 14, 2025, 11:13:06 amAs 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 15, 2025, 02:59:37 am
content: Quote from: Smokey on April 14, 2025, 08:28:54 pmIf 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 :-)

author: Sacodepatatas
author_rank: Regular Contributor
timestamp: April 15, 2025, 09:08:19 am
content: Quote from: brucehoult on April 13, 2025, 12:38:44 amAs 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.Quote from: Smokey on April 13, 2025, 04:10:24 amI 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.Quote from: SiliconWizard on April 13, 2025, 12:57:24 pmNot 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.Quote from: DavidAlfa on April 13, 2025, 05:26:54 pmI'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 chipsQuote from: DavidAlfa on April 13, 2025, 05:26:54 pmSome 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.Quote from: IOsetting on April 14, 2025, 03:32:51 amI 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.Quote from: Siwastaja on April 14, 2025, 11:13:06 amVery 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...

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 15, 2025, 11:03:20 am
content: 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.

author: Sacodepatatas
author_rank: Regular Contributor
timestamp: April 15, 2025, 12:21:49 pm
content: Quote from: DavidAlfa on April 15, 2025, 11:03:20 amThat'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...

author: NorthGuy
author_rank: Super Contributor
timestamp: April 15, 2025, 03:35:19 pm
content: Quote from: Sacodepatatas on April 15, 2025, 09:08:19 amMost likely, it is your signal, or voltage reference, or power, causing the noise, not ADC.

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 15, 2025, 04:41:33 pm
content: Try powering it from a battery, but ADCs in these cheap mcus are just that, cheap

author: John Celo
author_rank: Regular Contributor
timestamp: April 16, 2025, 10:52:28 am
content: Quote from: Sacodepatatas on April 15, 2025, 09:08:19 amI'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)...

author: IOsetting
author_rank: Regular Contributor
timestamp: April 16, 2025, 01:05:23 pm
content: Quote from: John Celo on April 16, 2025, 10:52:28 amI feel so, too, only 8~9 bits are reliable, the last few bits might change randomly.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 16, 2025, 01:25:35 pm
content: 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 16, 2025, 05:42:25 pm
content: Quote from: SiliconWizard on April 16, 2025, 01:25:35 pmPublished 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 16, 2025, 06:43:45 pm
content: Quote from: NorthGuy on April 16, 2025, 05:42:25 pmFor 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 18, 2025, 07:38:55 am
content: Quote from: SiliconWizard on April 16, 2025, 01:25:35 pmIt'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.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: April 18, 2025, 10:29:14 am
content: Quote from: Sacodepatatas on April 12, 2025, 11:50:32 pmQuote from: Sacodepatatas on April 12, 2025, 11:50:32 pmStart by looking up flash endurance in the datasheet.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 18, 2025, 12:33:17 pm
content: Quote from: brucehoult on April 18, 2025, 07:38:55 amYes. Analog Devices have interesting MCUs though with up to 24-bit ADCs and good analog performance, with their ADuCM series.

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 18, 2025, 01:18:51 pm
content: Quote from: Doctorandus_P on April 18, 2025, 10:29:14 amObviuous and ignoring the main question from the OP

author: brucehoult
author_rank: Super Contributor
timestamp: April 18, 2025, 02:05:13 pm
content: Quote from: SiliconWizard on April 18, 2025, 12:33:17 pm4 ksps vs 2.4 Msps for the PY32F002B.Also $9.24 qty 1000 ($17 for 1) vs ~$0.10 for the PY32F002B.Not really playing in the same league.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 19, 2025, 01:06:40 pm
content: Quote from: DavidAlfa on April 18, 2025, 01:18:51 pmTo be fair, Doctorandus_P gave direct answer to the very question in the title, which you quoted. If you struggled to understand this 9-word long sentence, I can rephrase it:Yes, to trust.And I tend to agree it's a sensible opinion. Youhaveto trust it, because testing it independently is a massively expensive and long project. The best that can be done, really, is to apply some extra derating, but that's it. You can't practically verify it.Besides, if the spec is 10 000 cycles, that doesn't sound specifically high. Many others specify larger counts. So it's not an "alarmingly good" spec either.

author: Sacodepatatas
author_rank: Regular Contributor
timestamp: April 19, 2025, 11:25:49 pm
content: Quote from: Siwastaja on April 19, 2025, 01:06:40 pmAn answer is an answer, and Doctorandus_P gave an answer of a typical engineer, that is, absolutely precise, but not so much accurate. If i assumed 10k is because contrary to other manufacturers the datasheet specifies 2 numbers, one for the minimum number of cycles (100k) and another for a minimum "date retention" (i should assume they meant data retention but then I could be advised to check the datasheet again). I don't know what happens between 10k and 100k cycles, so i think it's better so assume the lower specified amount of cycles as the most reliable number.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 20, 2025, 01:19:34 pm
content: Quote from: Sacodepatatas on April 19, 2025, 11:25:49 pmIt's like your car. It may last 20 years, but if you drive 200 km every day, it won't. But you'll have hard time finding out how long exactly the car may last for a given driving pattern. All you can get is guesstimates.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2025, 01:27:26 pm
content: Yes, now the OP said the writes would not be frequent (define frequent here?). Say the flash area for these settings is written to 1 time per day. 10000 cycles min would be 27 years.Not sure it would be worth fretting about, but if the OP intends to make a product with a PY32F002B planned to have a > 27 years lifetime, that's interesting.Or, again, if unsure, just use a small external EEPROM which are very cheap in those small sizes, and call it a day.