PIC16LF877A first 8 program memory bytes read as 0x3FFF after power-up—why?

51 8

#1 21657942 01 Apr 2011 04:52

Joshua Bishop Joshua Bishop

Anonymous

Post #1
21657942 01 Apr 2011 04:52

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!
ADVERTISEMENT
#2 21657943 01 Apr 2011 06:57

Olin Lathrop Olin Lathrop

Anonymous

Post #2
21657943 01 Apr 2011 06:57

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?
ADVERTISEMENT
#3 21657944 01 Apr 2011 07:06

Joshua Bishop Joshua Bishop

Anonymous

Post #3
21657944 01 Apr 2011 07:06

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...
ADVERTISEMENT
#4 21657945 01 Apr 2011 08:28

Olin Lathrop Olin Lathrop

Anonymous

Post #4
21657945 01 Apr 2011 08:28

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.
#5 21657946 01 Apr 2011 08:31

Olin Lathrop Olin Lathrop

Anonymous

Post #5
21657946 01 Apr 2011 08:31

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.
#6 21657947 01 Apr 2011 08:54

Joshua Bishop Joshua Bishop

Anonymous

Post #6
21657947 01 Apr 2011 08:54

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.
ADVERTISEMENT
#7 21657948 06 Apr 2011 14:29

Karl Wacker Karl Wacker

Anonymous

Post #7
21657948 06 Apr 2011 14:29

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?
#8 21657949 08 Apr 2011 06:57

Joshua Bishop Joshua Bishop

Anonymous

Post #8
21657949 08 Apr 2011 06:57

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.
#9 21657950 08 Apr 2011 08:18

Karl Wacker Karl Wacker

Anonymous

Post #9
21657950 08 Apr 2011 08:18

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.
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Didn't find an answer? Ask Artificial Intelligence

*I agree to send the question to OpenAI, Anthropic PBC, Perplexity AI, Inc., Kagi Inc., Google LLC - owners of language models in order to prepare the best response. The companies may monitor and log information entered into the form.

*I agree to publicly display my question and answer. The question and answer will be publicly available to everyone. The process may take a few minutes. Upon completion, you will be redirected to the page with the answer.

Wait...(2min)

Topic summary

A PIC16LF877A microcontroller exhibits an issue where the first eight program memory bytes read as 0x3FFF after power-up, indicating apparent erasure. This occurs intermittently on both low voltage TQFP and normal voltage DIP packages. The problem may be related to improper MCLR pin handling, as the MCLR was initially left floating and later tied directly to VDD without a resistor, potentially causing unintended resets or programming mode entry due to voltage transients or ESD. Brown-out detection is disabled, which could allow unstable power conditions to corrupt memory. Bypass capacitors are present but not optimally placed near the VDD pins, possibly allowing noise or inductive transients from a connected speaker to affect operation. Suggestions include adding a resistor (e.g., 20 kΩ) between VDD and MCLR, ensuring proper bypass capacitor placement with ceramic capacitors close to power pins, protecting against speaker-induced inductive spikes with diodes, enabling brown-out detection, and verifying whether code space self-write operations might be inadvertently erasing memory. The PICkit 2 programmer shows the first eight bytes as erased, but the rest of the program memory appears intact. The root cause likely involves power supply noise, MCLR pin misconfiguration, or unintended self-programming rather than normal device behavior.
Summary generated by the language model.

PIC16LF877A first 8 program memory bytes read as 0x3FFF after power-up—why?

Didn't find an answer? Ask Artificial Intelligence

Topic summary