[sdiy] destroying flash memory cell on a PIC

[cheater cheater]

So... no chance of ESD damage?

On Sun, Mar 21, 2021 at 1:34 PM Roman Sowa <modular at go2.pl> wrote:
>
> Thank you all for so many replies. Frankly I didn't expect that many for
> such mysterious matter.
> Let me reply to all in one email separating replies with dash line:
>
> -------------------------
>
> Gerry said:
> "I believe that, even though you can exit from the page erase and go on
> to do other things straight away, the actual process of erase takes a
> while after the task is called.
> I believe there's a bit that can be examined to tell you if the erase is
> still in progress."
>
> I have read EECON1 register right after initiating erase and write
> cycles, which in reality means when internally timed erase/write process
> ends, and put it on enxternal pins to observe on the scope. None of
> EECON1 bits have shown any signs of erase or write being in progress. I
> could only see that write cycle (one 64-byte page) takes 1.5ms
>
> -------------------------
>
> Richie said about endurance:
> "I haven't looked at a PIC datasheet for a while but from what I
> remember the flash write endurance is quite a small "
>
> It is actually 10.000 writes endurance. While this happened maybe after
> 5 - 10 writes. Well, one write means about 11KB, so 174 pages written,
> but the addresses do not overlap, this was confirmed even before first
> try in hardware. Even if they did write the same area, that's still 10%
> of claimed endurance.
>
> -------------------------
>
> Richie also said:
> "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."
> And Eric explained that later:
> "In most digital processes a high-density SRAM bit is not just a D
> flip-flop - typically it's cross-coupled arrangement of 4-6 MOS
> transistors in a stable loop "
>
> this is terrifying! Microchgip does not say anything about RAM
> endurance, but if it's really made with only few transistors forcing the
> other state by current, it turns my world upside down.
>
> -------------------------
>
> Veronica said about cycling:
> "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."
>
> There is no control over any cycle timing in PIC. I can only initiate
> write cycle, and wait till internal timer does the job. This cannot be
> seen in anyway. The program executions simply stops after initiating
> write, and when it's over after about 1.5ms, next instruction is executed.
>
> -------------------------
>
> Jay asked about errata - yes I always check that, no mention about any
> memory whatsoever
>
> -------------------------
>
> Brian suggested firmware bug and interrupts - no, there are no
> interrupts, GIE is disabled during erase/write operations and during
> data fill. Firmware bug? I don't think so. The procedure is very simple
> and was tested many times in simulator.
>
> -------------------------
>
> Later Jay said:
> "After the E/W cycle did you verify the memory that was written to
> FLASH? Maybe the memory written (I assume RAM) got corrupted between
> setup and when it was written. "
>
> The data to be written to flash cannot be verified, it's 64-byte RAM
> buffer accessible only to write. Nevertheless even if it was corrupted,
> what about locations not programmed this way and affected with error?
>
> -------------------------
>
> Tom said:
> "I couldn’t find the problem with the write routine because it wasn’t
> there. It was a problem with the code that set up the pointer that
> fetched the data, so it was reading rubbish and writing the rubbish
> accurately"
>
> My procedure was carefully tested in simulator before even powering on.
> It is also very simple, not giving any special meaning to first byte,
> registers are not abused, data is transfered directly from input stream.
> I cannot see any chance of data corruption
>
> -------------------------
>
> And finally Achim said something intriguing:
> "That would be program disturb… which is a common failure mode when
> cells starting to get marginal after cycling. (...) The second most
> likely possibility is a non-catastrophic failure somewhere in
> the decoder circuitry and high voltage distribution."
>
> It would be strange coincidence that cells get marginal so quickly in
> this chip and not any others so far. Likewise - damaging high voltage
> decoder. Maybe cycling of self-write is done very different way and ISP?
> It only makes me think there is no hope, and it's all driven by pure
> luck. And no, I have no plans to burn it for 24h in 180°C just to see if
> cells got marginal.
>
> -------------------------
>
> Last response was again from Brian, about programmer and power supply
> issues - the same happens if I program with $300 programmer you
> mentioned, and PIC is povered from lab supply (cheap but very good)
> followed by pi LC filter, followed by linear regulator on the same PCB.
>
> ===========================================================
>
> So I'm still where I was, but wiser by few things that make me think
> microcontrollers and flash memory are evil. My poor damaged PIC is now
> showing this errors in lower parts of memory, so I cannot even flash my
> flasher anymore. I'll be back in the office on Monday so I can replace
> the chip then, but really I have no other idea what to try next.
>
> Thanks again to everyone who replied, it's been valuable discussion.
>
> 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