[sdiy] destroying flash memory cell on a PIC

[Roman Sowa]

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