[sdiy] destroying flash memory cell on a PIC

[Richie Burnett]

It was something like a 16-bit 32 kiloword static RAM.  Samples were taken 
away for analysis by the manufacturer and they were found to have permanent 
damage at those locations.

I remember that temperature also played a part here.  I remember discovering 
that you could provoke failures in RAM chips that were on the brink of 
failing with a gentle squirt of aerosol cooling spray!

-Richie,



-----Original Message----- 
From: cheater cheater
Sent: Wednesday, March 17, 2021 2:54 PM
To: Richie Burnett
Cc: synth-diy ; Roman Sowa
Subject: Re: [sdiy] destroying flash memory cell on a PIC

Was that SRAM error permanent damage, or was it rowhammer style leakage?

On Wed, Mar 17, 2021 at 2:50 PM 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