[sdiy] destroying flash memory cell on a PIC

Sun Mar 21 17:48:44 CET 2021

I was going to ask if you had managed to try a pristine new chip yet?  It 
could just be a faulty chip and you were really unlucky.

I remember encountering an interesting failure in 1994 in my first job 
programming PICs...  Back in those days there weren't many flash parts, 
emulators were quite expensive and the simulator wasn't up to much.  So I 
bought a bunch of ceramic EPROM based PICs with the little round glass 
window in the top.  My firmware development cycle consisted of programming 
up a blank chip, then testing it in a development board whilst another chip 
was sat erasing in the UV box.  (It's crazy to think what we had to do back 
then!?)

Needless to say these chips spent a lot of time being inserted and removed 
from programmer and dev board sockets.  All had been going smoothly for 
weeks, then one day I was suddenly greeted with a bright light from the 
glass window when I put the programmed chip in the development board and 
powered it up!  It was quite bright, like a small filament bulb, and the 
firmware wasn't running.  I switched the power off immediately, initially 
thinking I'd put the chip in the socket the wrong way round. I got a 
magnifying glass and took a look through the window.  A foreign object, 
(looked like a piece of metal swarf, but I guess it would have been 
silicon,) was resting across a bunch of the bond-wires, and two of them lit 
up like a light bulb when 5 volts was applied!

I'd been using this chip for weeks without any problem and the offending 
conductive object must have been rattling around inside since it was 
manufactured.  They had been handled lots, but on that particular day it 
decided to make it's presence known!  Just removing the chip from the socket 
disturbed the short-circuit, and it was difficult to get the offending 
object in view through the window again.  I marked up the chip with a cross 
and gave it to the Microchip rep when he was next in, but never heard any 
explanation back.  Hopefully QC is better at Microchip now.  Maybe not.

-Richie,

-----Original Message----- 
From: Roman Sowa
Sent: Sunday, March 21, 2021 12:29 PM
To: synth-diy at synth-diy.org
Subject: Re: [sdiy] destroying flash memory cell on a PIC

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 

-- 
This email has been checked for viruses by AVG.
https://www.avg.com