Problem when PIC power on!!!

[Ttelmah]

Switching the oscillator reduces power consumption a little, but is not vital.

Look at the setup_oscillator function.

Much more important is the whole 'ethos' of the routines involved:

1) You want the warning ASAP. This is why monitoring the input rail is a much better solution than trying to use the 5v.
2) Then when you enter the routine, you switch to 'power saving'. Now the oscillator is one part of this, but is probably the smallest part. Every device the PIC is operating needs to be turned to it's 'off' state, and every output on the PIC needs to be switched to the point where least current is being drawn.
3) Then you perform the actual data write.
4) Then the routine needs to sit and keep checking that power actually has gone off. If after a few mSec the power has not actually failed, and the alarm signal disappears, then the code needs to do a 'warm start', resetting the oscillator, switching everything back on, and returning to where the signal triggered.
5) Then you need to consider the order that power fails, and how things will behave if parts have not fully discharged, and where power actually flows as the rails go down. If (for instance), your supply uses a simple linear regulator, and has a 'super capacitor' across the PIC, then as the input fails, the PIC rail will be above the incoming supply. This can destroy standard regulators. Then since the PIC supply will fall slowly and rise slowly, you need to consider the oscillator startup, and how the reset signal will actually be generated. I tend to use chips actually designed to do this. Fairchild, Texas, & National amongst others do 'supply supervisory' chips, that will trigger a fail interrupt, and also generate a reset signal an interval _after_ the supply goes good.

I suspect your problems are actually with 4, and 5. Either the chip is actually still running, so is still sitting in the 'fail' code, or the sequencing of supply rails is leading to hardware problems.

[tienchuan]