First eight bytes of program memory self-erase randomly

I'm using a PIC16LF877A for a project and the first eight memory bytes erased themselves between a power-up. This is currently happening with the low voltage TQFP package but has also happened recently in the past with the normal voltage DIP package.

Here's the sequence of events.
1) I program the PIC.
2) Everything is fine, everything works.
3) This continues for quite awhile.
4) Things stop working, seemingly randomly.
5) I use the PICkit 2 to read the programming memory, the first eight bytes are read as 0x3FFF.

This has never happened to me before and I've used an 877A on another project, nor have I had it ever happen with anything else on the PIC line.

Your help is appreciated!

That sounds really strange. I've done many PIC projects and haven't encountered anything like that.

Are you really really sure the PIC isn't being abused somehow? Can Vdd ever spike beyond 5.5V? What is the ground connection between the PIC and the power supply like? Is it possible spikes are getting into there?

Do you have brownout detect enabled? That is usually a good idea unless you need to run off of a low battery voltage or power consumption is important. What does the MCLR circuit look like?

Olin,

Thanks for the reply!

I am assuming the PIC is being abused, I'm just trying to figure out how. After I posted the question, I started thinking it is probably the MCLR, since it also is used as the programming signal when the voltage is pushed up to 12V, I believe. Unfortunately, this project was rushed and there were quite a few mistakes (design errors?) made, one of which the MCLR was left floating, so I just jumpered it to VDD. My thought is that any transient spikes or small ESD on that pin would cause the PIC to clear the first eight bytes, since no data would be put in while the PIC is thinking it is being programmed.

Unfortunately, I don't have a very good understanding of the inner workings of the PIC, I don't know if that makes any sense at all.

Other than that, none of the other ideas seem likely, except that brownout detection is disabled. However, as I was searching for another issue online, I read advice from random strangers that brown out detection should be disabled if you're going to be running the PIC at less than 4V. What's your opinion?

I do still think MCLR might be the cause though...

Yes, you have to disable brownout detect if you are deliberately running the PIC at a low enough voltage so that the browout logic might trip.

With MCLR tied to Vdd, how can this PIC ever be programmed? The programmer must be able to raise MCLR to 13V during programming, but Vdd can't exceed 5.5V. Usually I put a 20 KOhm resistor from Vdd to MCLR.

Even if the PIC somehow got into programming mode, it would be unlikely the right commands got clocked in on PGD and PGC to erase the first 8 words, so I think something else is happening. I don't think a cause within spec is doing this. Somehow the PIC is being run out of spec at some time, and then of course anything goes.

Another thought: Since you said there is bad design envolved, what about the bypass cap connections? Does each power pin have its own bypass cap physically close to the PIC with a short return to the PIC ground pins? These caps need to be ceramic. I usually use 1uF surface mount right at each power pin.

I tied MCLR to VDD with a jumper, actually using the header that I use for programming. I ghetto-soldered a jumper using another header with a resistor, so now it has the resistor to at least limit the current into MCLR.

It does seem unlikely that the PIC got into programming mode, but I'm grasping at straws here.

To your below post, while there are bypass capacitors, they aren't directly at the two VDD pins. I thought of that as well but my only high draw device is a speaker. When the project is working, the timing of it stopping to work has yet to coincide with the speaker being used. (Whew, that was an ugly sentence) Of course, those are to help with environmental transients as well... could be.

Thanks again for all of your help.

Are you sure the only the first 8 bytes are being erased?

Read the entire chip program memory in and look at it with view/program memory [if you are using MPLAB] - The programmers tend to report only the first few errors, not all of them - also - a speaker is a nice source of inductive transients - how is it being driven, and are there any diodes across it to suppress the transients?

Karl,

No, I haven't independently verified, I'm just going off of what the PICkit 2 program says. It doesn't give errors, but it shows all of the code that has been programmed onto the 877A. Which, other than the first eight bytes, looks exactly like what I loaded in.

I hadn't considered the inductive transients from the speaker. It seems prudent to reduce those. A combination of protecting from those and making sure my caps are properly sized and spaced should significantly reduce the chance of it being a noise problem.

Thanks for the idea.

something else to try:

1) Run without the speaker connected.

2) Question: are you writing to eeprom anywhere?
Or are you writing to code space?
If you accidentally set the chip to self-write code space, you might be erasing the first 8 locations.