[sdiy] destroying flash memory cell on a PIC

Richie Burnett rburnett at richieburnett.co.uk
Wed Mar 17 14:46:39 CET 2021

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.


-----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

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!

Synth-diy mailing list
Synth-diy at synth-diy.org
Selling or trading? Use marketplace at synth-diy.org 

This email has been checked for viruses by AVG.

More information about the Synth-diy mailing list