PIC RAM GETS CLEARED

[ljubex]

Hi people,
I work with PIC 18F452 and have strange problem. In some moments all RAM data goes to 0. I guess that it happens when power supply is bad. But, does anyone know WHY is this happening, and how to solve this.

Thanks a lot !

[philba]

After completely studying all the information you gave us, I can, with near 100% certainty, say that it's something wrong, somewhere in your circuit. The solution is simple, correct the problem.

[removing tongue from cheek]. How could anyone help you with out some detail? circuit diagram? or even a description? details of what happens when you see the zero'd ram? how is it you know it's been cleared? Have you taken any voltage measurements? when is the assignment due? what things are going on when the problem manifests?

You will find people in this forum to be most helpful but you've got to provide some details.

<small>[ November 06, 2005, 08:54 AM: Message edited by: philba ]</small>

[ljubex]

Hi there,
here is detailed description:

The system contains two units:
- central unit, doing some aquisition, displaying some data ond 5 displays...
- money acceptor unit, serving two acceptor units (coin and paper) and doing parallel comunication with central part

Both units are based on Pic 18F452 device.

On low voltage detect, both units have to save some data into internal EEPROM. When power comes back, the data is restored. Some of that data is displayed on displays.

At first I used switcher power supply. And the quality of the print circuit board was poor.

The manifestation of the problem was like this: When some big power consumer is turned on or turned of near the system, certain values displayed on displays all go to 0. At that point the problem vas reproducibile and "zeroes" could be made by powering on some refrigerator engine, or by turning off the system for some time (2-3 seconds) and turning on after that time. Unit for money accepting doesn't seem to be "zeroed" (some led indicators are present...). Money accepting unit stores only few bytes, less than 10, but central unit stores about 120B.

At that point, my colegue and me was suspecting that EEPROM makes the problem. On LVD the data storing starts, but we supposed that if voltage comes during the data storing, something strange happens which produce the problem. That should explain why money accepting unit isn't "zeroed".

But, we made better print cicuit board, and put linear power supply. The problem remained, but now it is unreproducible. It occures ones in two or three days of constant work of the system. And, the same system is doing it frequently at places where 220V is not stable, but unfortunatly these places are not available to me for experiments.

I will provide any information you people think that is necessary, I just didn't want to anoy anyone with long post. I will post the circuit diagram in few minutes.

Thanks in advance

[philba]

Much better!

I suppose eeprom is possible but the eeprom write cycle is pretty fast. Does your power supply provide enough power to get through power glitches? You might get a small UPS for the system that is having problems and see if that solves it (temporarily).

You might need to supply a "power good" signal to the PIC and use that to start eewrite during impending power out. Brownout is good if the supply goes away slowly but might be a problem if it goes away quickly. Personally, I'd want to get the earliest possible indication of a power problem. You should also check eewrite voltage requirements.

I'd look at powerline induced noise on the mclr line. What value of pull-up do you have on it? A weak pul-up (100K) might cause this kind of problem Do any power traces run next to that part of your circuit?

[Gorgon]

Hi Ljubex,
My first question is, where is your LVD placed in the chain of power supply?
If it is sensing the 5V then you are in real trouble if you try to write to the eeprom. The LVD need to be in a place where the time before the 5V disappear is long enough to do the eeprom programming with good margin. This time depends on how much data you want to save.

Another question is how do you know that the values saved isn't '0' in the first place?

The glitch or power spike could change the contents of the ram in the PIC before saving the data. I think you need to protect your ram data integrity with some sort of checksum algorithm, before writing garbage to the eeprom?

TOK

[philba]

I think they are using brown out to detect low voltage. That may be late to do much useful, in my opinion.

The "reset - then save values" is a likely scenario. worth exploring, anyway.

<small>[ November 06, 2005, 03:20 PM: Message edited by: philba ]</small>

[ljubex]

Hi everybody,
My colegue and me found problem (didn't solve it yet, but I hope it wan't be so difficult). The situation was that on reset initial values of all data in one program section was set to zero. This is what compiler is doing, we didn't know that. We use Hi-Tech's compiler. Here is their explanation:

"Any object file may contain bytes to be stored in memory in one or more program sections, which will be referred to as psects. These psects represent logical groupings of certain types of code bytes in the program. In general the compiler will produce code in three basic types of psects, although there will be several different types of each. The three basic kinds are text psects, containing executable code, data psects, containing initialised data, and bss psects, containing uninitialised but reserved data. The difference between the data and bss psects may be illustrated by considering two external variables; one is initialised to the value 1, and the other is not initialised. The first will be placed into the data psect, and the second in the bss psect. The bss psect is always cleared to zeros on startup of the program, thus the second variable will be initialised at run time to zero. The first will however occupy space in the program file, and will maintain its initialised value of 1 at startup. It is quite possible to modify the value of a variable in the data psect during execution, however it is better practice not to do so, since this leads to more consistent use of variables, and allows for restartable and romable programs. For more information on the particular psects used in a specific compiler, refer to the appropriate machine-specific chapter."

In situation where electricity is bad, we've got resets frequently. I hope this will be usefull for somebody else.

And special thanks to Philba, I was working aronund that pullup on MCLR when I realised what's going on. (btw, we use 330ohms pullup)


Thanks again for your time and patiente

[Gorgon]

Hi Ljubex,
I normally use assembler myself on the smaller controllers, but anyway I think using some sort of warm and cold start/ reset scheme is useful in any program. If your program gets resets while running you have a warm start condition, and only needs to check your variables for validity(checksum again )
If you reset/ overwrite the RAM variables all the time you'll never now if they are valid.

I think you'll need to do some thinking on the startup(init) procedure in your program.

TOK

[philba]

Lol, when you start asking for help, that's when you figure it out. Never fails...

By the way, I think saving the eeprom values when the power is going away is asking for trouble. I have used a different approach in the past - regularly save the values I care about (not too often, it IS EEPROM) so that when power goes away, the data is there. You can distribute the data over the whole eeprom to increase the life span.

I agree with gorgon, cold vs warm restart should be well thought through.