[sdiy] destroying flash memory cell on a PIC

[Brian Willoughby]

Not directly related, but Dangerous Prototypes actually created a platform to test this issue.

http://dangerousprototypes.com/docs/Flash_Destroyer <http://dangerousprototypes.com/docs/Flash_Destroyer>

In this case, they're destroying an external Flash, not the Flash memory in the PIC, but there is a PIC used as a controller to drive the LED counter. One could possibly modify this platform to verify how long your specific PIC internal Flash would last.

In your specific case, I would suspect a firmware bug.

I've shipped a product based on the PIC18F67J50 where user settings were saved in a single erase sector/block of the Flash, above the firmware, and there were never any issues. I made sure to avoid auto-save, so the user could tweak settings extensively before committing to "permanent" Flash. The Flash write takes enough time that I had to stop the LED column scan, making the display go blank for a fraction of a second, and I think that also discouraged users from clicking on the "Save" button frequently. I used the Microchip algorithm, but I remember tweaking the assembly source and fine-tuning the interrupt masking so that the other features of the firmware were not tripped up during the Flash write. For example, without blanking the LEDs, the Flash write could have burning out a column of LEDs due to over-current because of the necessity to mask interrupts (and the fact that the LED column sequencer is interrupt-based).

Do you have any interrupts enabled during your Flash write? I don't know why interrupts would only destroy 0x400/800/C00 but it's worth looking.

Brian


On Mar 17, 2021, at 03:55, Roman Sowa wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20210317/962fea71/attachment.htm>