PIC RAM DATA GETS CLEARED 1

[ljubex]

Hi people,
I tried on many forums, and had no luck. I work with PIC18F452 microcontroller and have strange problem. In some momment all RAM data goes to 0. I guess that it could be bad power supply (tried many types...). Does anyone know WHY is this happening?

Thanks a lot!

 

[melone]

It can be 3 things;

1) Improper power to the device. Put an o-scope on the power rails and monitor the voltage when failure occurs.

2) The code is doing it. Step through the code when the failure occurs, and see if it is doing EXACTLY what you expect.

3) Faulty part. Try replacing the specific device and see if it improves.

Obviously, my statements are based on the vague description of your problem. If you give more information, we can be MUCH more helpful. For example, have you been able to reproduce the problem at will? If so, that should help tremendously. When you say different power supply, are you talking about an switcher or a linear? Have you verified that your supply can handle the requirements for your device. etc.

 

[ljubex]

Hi there,

Here are some details of the problem:

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.


Thanks in advance!

 

[itsmoked]

melones ideas are all good. I would put a digital scope across the PIC's VCC and set it to single trigger on VCC dropping below about 4 Volts. You may see a big dive at some point.

I would guess the point would be when the PIC switches some nasty device on that tanks the supply.

Or you are allowing shoot-thru on a bridge circuit.

Alternatively you have the watchdog on and it's triggering then your initialization routines are diligently clearing the RAM.

 

[bill318]

As melone says, more info is needed to nail down the problem.

Do you have an innit routine that clears all RAM contents to 0? If so, are you over running the stack and stepping on the reset vector? Do you have a watchdog running that can reset the part?

Bill

 

[bill318]

ljubex,

Are you using an external reset line on the micros? Sometimes reset lines make good antennas to pick up noise and reset your parts.

What is your Vcc level and low voltage detect level and if using brown-out, what level is it set to?

It may be that you don't have enough time to store EEPROM contents when the rails are falling and you are corrupting the eeprom contents.

 

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

Thanks again for your time and patiente

 

[cbarn24050]

Hi, if you'd mentioned the 'C' word in the first place your problem would have been obvious. C always initialises its data ram at startup either with an intial value or zero.

 

[MikeHalloran]

Power fail detect circuits are among the very worst to debug, but I suggest that you have a system design problem that's making it worse.

The idea of detecting an incipient power failure and THEN saving all of your critical data into an EEPROM is just chock full of ways for things to go wrong. For one, the required EEPROM write cycles may take more time than you have available before the power supply goes out for good.

Better, in theory anyway, to save the critical data into some form of nonvolatile storage >whenever they change<, and limit the writes during power fail to whatever was in the process of changing when the power fail occurred. Of course, then you run into durability limits that make you wish you had selected BBSRAM instead of EEPROM. You may have to come up with tactics for dynamically reallocating the EEPROM in sections as it wears out. It's a nontrivial problem.

Additionally, you will never fix the problem until you can define what constitutes a power failure for your system, and can reproduce it at will. I.e., you may have to make or buy a test box that can precisely reduce the supply voltage or drop out a few cycles, or whatever. Yanking the plug out of the wall to see what happens doesn't provide the information you need to make the product better.







Mike Halloran
Pembroke Pines, FL, USA

 

[bill318]

Regardless if the RAM gets initialized to 0 or 1, your init routine probably is trying to restore RAM contents using the data stored in EE so you are back to where you were before the lights went out.

Figure your worst-case timing so that you have enough time to write your EE contents at least twice before VCC is too low. Then you can design your low voltage detect and size the amount of capacitance needed for your uP VCC rail so it has ample time to do its job before the BOD kicks in. Sometimes it is good to look at the voltage ahead of your VCC regulator to give you a heads up that power is going out.

Best of luck, sounds like you are on it...

 

[itsmoked]

" Sometimes it is good to look at the voltage ahead of your VCC regulator to give you a heads up that power is going out."

I would say that if you are trying to store things on power failure then you MUST monitor your supply before the regulator.

Furthermore a better way to do it is to detect the failing power supply (ahead of the regulator) then do your saves and enter a dead-end tight loop. This prevents further memory manipulations from occurring if the power is varying indeterminately. Normally the next step would be loss of power. Then when power is restored the system does a normal power up. Otherwise the watchdog will trigger and you will get a "controlled" restart.

Often power glitches come in little groups that will confuse your system by dipping several times causing several panic data saves that may become corrupted.

Your system should be able to take you turning its supply voltage down v e r y s l o w l y with a variac until you are at a point where your Power Fail sensing is being rapidly triggered. Your system should NOT corrupt any data with this type of torture.

 

[fsmyth]

Seems like a small battery would be in order here.
Eliminates the need to abuse the EEPROM if the power
loss is of short duration. Acts like a very LARGE cap
<als>

 

[itsmoked]

fsmyth; Actually the usual would probably be a large cap in the preregulator side of the supply as that side runs a higher voltage and hence the caps can easily store more energy there. This also gives a more linear decay of the voltage on that side for better detection of failing power as mentioned previously.

 

[cbarn24050]

itsmoked; I think your still going to need a battery to keep the processor from reseting during brown outs. The prcessor could cut the battery power if the main power is off for some time period (after storing whatever it needs to in eeprom).

 

[analogkid2digitalman]

Super Cap to the rescue?

Wheels within wheels / In a spiral array
A pattern so grand / And complex
Time after time / We lose sight of the way
Our causes can't see / Their effects.

 

[itsmoked]

I have had many bad experiences with batteries in these situations. The chargers add complexity and the batteries have a finite life that once expired brings all of the problems you are trying to solve right back at you. I have had batteries fail and take out the board by corrosion too.
Down the road the batteries fail then you have exactly the same problems until this is understood. Then you may need to send expensive service people out to change batteries in remote places just..because.

If you are trying to protect data integrity in a commercial/industrial setting then you need to do several things:

Determine if the information to be saved is a machine state that you want to return to.
Or
Is this information something like a user setting change.

If it is a user setting change it should be done once the <Enter> key is pressed. (Right then) as MikeHalloran pointed out.

You immediately write the info then you read it back and compare it with what you just wanted saved.

If this is important information you do this three times in three different locations!

When you read the data back for use,(next boot, etc.) you compare all three values. If they don't all agree, it is assumed the two that do are correct and the third is changed to agree. The prudent engineer then increments another nonvolatile register noting that there was a nonvolatile error.

If this is information is to save the process or machine state then the hardware must be designed to support this. You don't just assume you can "quick do it before the power is gone".

You store "some" energy somewhere to keep the system running long enough to write the data and read it back and re-write it if need be. In modern micro systems the amount of energy does not need to be very much at all. A 100uF is often more than enough. But the key is to make sure you only do the orderly shut down ONE TIME. Because if you don't then you may be caught with your pants down on subsequent shut downs. This is because the power often does not just go away... It almost goes away then returns then does go away but comes back briefly then goes away again. All in a few dozen line cycles. This will cause multiple "shut down storage attempts".

So as I stated above, all you need to do is provide enough high-side energy storage in the form of a capacitor to do a single orderly shut down. This also covers simply flipping the on/off switch.

Monitor the state of the high-side voltage. When the voltage drops to a point in a normal power switched-off situation where you would still have %250 of the time needed to preserve your states of interest you INTERRUPT your processor.

Proceed to save and check your data. Then lock the processor until proper voltage is available again. This can be done by your watch-dog although hardware comparators and timers are often used as can be seen by the 20-30 chips Maxim and others make for certifying supplies to processors.

As soon as power is restored run your system initialization, read back your info from three locations if that is the case and continue. Batteries need not apply..

 

[cbarn24050]

I was thinking more of the op's problem, of course batteries do fail/corrode/need replacing but thats chargeable.

 

[ljubex]

Well, we use 4700uF capacitor on the main unit side, and the same one on the money acceptor side, which makes these capacitors parallel conected. We made experiments with counting bytes stored in EEPROM, so we do have enough time for writing. Even when we don't use money acceptor unit, it is still enough time.

And one more thing: thank you people for manu valuable inforation at this topic



Cheers,
LjubeX

 

[zeitghost]

Is the 4700uF before or after the regulator?

 

[ljubex]

In our case it is after the regulator.