[sdiy] destroying flash memory cell on a PIC

[Veronica Merryfield]

In the late 90’s, early 2000s, whilst working at a cell phone OS provider and working with a major cell phone maker, my team got involved in endurance testing a number of NOR and NAND flash products looking at endurance. The results were variable. On the one hand some makers were quoting certain operating times against a cycle limit. With these we found that we could exceed the cycle limit with the just the write time being extended. The graph of write times were exponential. These devices remained reliable as long as the write cycle was extended.
With others we found that the makers were quoting failure statistics against cycle times. As we approached the cycle limits, were were seeing bit failures, that became clusters and blocks of failure fairly quickly after the first bit failure.
Initially we tested entire devices to characterize the whole device but found we could see the same results from a smaller number of blocks, which sped up the testing considerably. 
>From this we optimized our flash storage algorithms and the handset makers could pick devices with a bit more confidence.
I would imagine over the last 20 years as the processes have got smaller, speeds have increased but that some of the failure and endurance stats have changed and would expect them to decrease unless they have found way to over come the inherent write/erase life cycle issues. I have not looked recently it has to be said.
I do vaguely remember, however, that the PICs weren’t as well spaced as some of the flash we were testing. 
I would think SD cards have suffered the same fate. 
Back when we were testing flash, we did a couple of MMC cards and saw similar issues.
The patterns on bit boundaries are reminiscent of some of the failures I remember seeing.
—
Veronica Merryfield she/her
veronica at merryfield.ca



> On Mar 17, 2021, at 10:46 AM, Richie Burnett <rburnett at richieburnett.co.uk> wrote:
> 
> The only thing I can think of is flash cell write endurance.
> 
> I've managed to burn out SD cards before when my software got stuck in a loop and repeatedly wrote to the same region of flash.  This literally happened in a couple of seconds, and I was surprised how easy it was to do! I actually wrecked several SD cards before I had debugged the problem and finally realised what was happening.  The damaged SD cards could not be re-formatted and went in WEEE waste.
> 
> I haven't looked at a PIC datasheet for a while but from what I remember the flash write endurance is quite a small number these days for the program execution memory.  I seem to remember seeing a figure of around a 100 cycles once and remember thinking that you could easily hit that figure whilst developing software using a program-test-modify strategy during development. This is one of several reasons I won't let chips that have been used for dev work go out.
> 
> I think some PICs might have separate sections of high-endurance flash for things like data that the developer expects might get modified more frequently.  Perhaps the cell size is larger for this memory so it can withstand more write operations.
> 
> The error pattern you're seeing sound very reminiscent of an issue with write endurance that I saw about 30 years ago in industry.  Some poorly written software was writing "the number of seconds since power up" continuously to the same bunch of locations in battery-backed SRAM.  It was news to me that SRAM could even get damaged by repeated hammering of a handful of addresses, but the chip manufacturer got involved and that was definitely the cause.  (Dropping the write down to once per second, and periodically moving the variable around in RAM were recommended by Fujitsu and completely solved the problem.)
> 
> Good luck and please let us know when you get to the bottom of it.
> 
> -Richie,
> 
> 
> 
> -----Original Message----- From: Roman Sowa
> Sent: Wednesday, March 17, 2021 10:55 AM
> To: synth-diy at synth-diy.org
> Subject: [sdiy] destroying flash memory cell on a PIC
> 
> Hi,
> I was recently playing with PIC18 self-write and encountered strange
> problem. I can't be sure if it was because of my multiple write attempts
> (not that many of them) or it is extremely bad luck, but the
> microcontroller in question (PIC18F46K22) shows stange fault. About 20
> of flash memory bytes are showing 00 even if that range was not
> programmed. It is FF after bulk erase, but after programming even
> several kilobytes below, they read as 00.
> There's a pattern - they are all on 10-bit boundary, so it's address
> 400, 800, C00 and so on till FC00. To look even more strange, it's not
> all, but randomly few bytes fitting that pattern work OK.
> It happens either if I program it as self-write, or if using ICD3.
> 
> Have anyone ever encountered this problem?
> 
> After thousands of PICs used so far I have never encountered flash
> error. OTOH, I have never used self-write before, but despite looking
> like obvious coincidence I can't see a reason why self-write would
> damage a memory cell, or address decoder. Chip errata does not mention
> anything about memory precautions.
> 
> Maybe I'm doing this too fast? The 64-byte page write is initiated just
> a couple of us after page erase is finished. This shouldn't be a problem
> but maybe worth trying to put 2-3ms delay.
> Thanks for your help!
> 
> Roman
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org 
> 
> -- 
> This email has been checked for viruses by AVG.
> https://www.avg.com
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org