[sdiy] destroying flash memory cell on a PIC

[cheater cheater]

wow, what process was that? junctions heating that much? crazy

On Wed, Mar 17, 2021 at 3:59 PM Richie Burnett
<rburnett at richieburnett.co.uk> wrote:
>
> 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
>