Power down data save to EEprom - PIC

Status
Not open for further replies.
A

augustinetez

Active Member
This is just a general enquiry to see how others have handled things and any pitfalls re saving data to EEprom on powering down.

I currently use an interrupt that generates a user settable (at program time) x number of seconds delay (can be anywhere from 1 to 255 seconds).

This is used to save 5 bytes of data after the user has stopped turning an encoder for the above mentioned delay period.

It was done this way as there are no spare pins in the current project to implement a power down save which is all that is actually required so settings can be restored on the next power up.

Now that I'm porting the project over to a bigger PIC (ref my previous "New set of eyes" post), I will have a spare pin that can be assigned to a falling edge interrupt to trigger the save.

Based on the 16F1827 datasheet, I figure that at worse, I need 30mS to perform this (25mS to actually save the data and an extra 5mS to cover the interrupt/program overhead plus a bit spare).

I haven't got as far as the actual triggering mechanism yet so open to suggestions on the hardware as well.
 
In my case the system ran on 12 Volts. The 12 Volt input went through a diode, then to an electrolytic cap before feeding the 5 V regulator.

I used a voltage divider from the raw 12V input power, before the diode. The divider was scaled so that the interrupt pin detected the loss when Vin fell to about 8V.

There was enough energy in the capacitor to ensure plenty of time to save all data before 5V was lost at the microcontroller.
 
Thanks Chris, that was where I had got to re the triggering, just wasn't sure if being that simple it would be reliable.

I'll give it a bash over the weekend and see what happens.
 
augustinetez said:
Thanks Chris, that was where I had got to re the triggering, just wasn't sure if being that simple it would be reliable.

I'll give it a bash over the weekend and see what happens.
Click to expand...

Chris mentioned his supply was 12V, so there's lot's of scope to detect the fall while the 5V is still stable, what is your supply voltage?.
 
Just use classical charge storage capacitor equation to determine rerquired energy
storage needed to complete write operations -

Q = C x V
I = C x dV/dT
C = (I x dT) / dV

Volts, Amps, Farads, Seconds

So dV is V at detection - min processor supply V
dT of course time to complete housekeeping/write storage operations.
I chip worst case current draw.

Regards, Dana.
 
Last edited:
Nigel Goodwin said:
what is your supply voltage?.
Click to expand...
Currently 6V but that could be increased (the 5V reg has a dropout of 210mV above the 5V)

Dana - working with

I =1mA (0.001A)
dT = 30mS (0.00003S)
dV =3.2 (5v supply - 1.8V lowest operate V)

I get 0.00000003F or 0.03uF, doesn't sound right to me, but then I was never any good at maths.

"So dV is V at detection - min processor supply V" -> V at detection = V in to the regulator or the 5V out of the regulator?
 
dV is the Vdd supply to PIC. Thats what you care about.

30 mS = .03 sec. so 21 uF result.


Regards, Dana.
 
I =1mA (0.001A)
Click to expand...
There's only a 1mA load on the output of the 5V regulator?

Also, you'd probably be better off using one of the comparator inputs to detect the level instead of using a digital input.
 
When you pick cap for holding up power to PIC don't forget to take its tolerances into
consideration.

Also make sure in PIC you shut off un-needed ancillary tasks that could. affect timing when
trying to write saved values, same for un-needed interrupts that would affect timing and current
consumption. Basically unload PIC from un-necessary operations. that are irrelevant to saving
and shutting down.

There is example in datasheet.


Regards, Dana.
 
tumbleweed said:
There's only a 1mA load on the output of the 5V regulator?
Click to expand...
When I shut off the LED and other unneeded stuff, it is actually much less than 1mA
danadak said:
Basically unload PIC from un-necessary operations. that are irrelevant to saving
and shutting down.
Click to expand...
Thanks Dana re the calculation - so used to working in μS that I seem to have gone there automatically.

As mentioned, I already had the notion to shut off all running ancillaries and there are no other interrupts at this stage.

I'll give it a run with 47μF, should give it plenty in reserve.
 
Quick update, got this to work with a 100μF input cap (diode isolated as per Chris at post#2) and resistive divider.

I do note that it seems sensitive to noise on the pre diode side of the + supply ie, using the switch to turn off the supply the save works intermittently whereas pulling the power connector gives a clean save every time (test board has DC barrel connector for the plugpack/wallwart connection).

Wondering if a low value (10n?) cap across the bottom resistor of the divider might be appropriate.
 
tumbleweed said:
Also, you'd probably be better off using one of the comparator inputs to detect the level instead of using a digital input.
Click to expand...
I might try this if I can shift various pins around so I can access one of the comparator inputs to see if it might be less susceptible to switching noise.
 
Do you have a schematic you can post.....?

Did you debounce the switch for the save code ? or disable the interrupt after first edge detected ?
Also if you use a global variable in interrupt did you declare it as volatile ?



Regards, Dana.
 
Last edited:
These are all good suggestions for writing an EEPROM. Back in the day, a lot of flip phones used to write the eprom every time you closed the lid.

Another possibility, though, is to use a different memory technology. There are memories that do not have a wear mechanism, so you can write them constantly. The first one is plain old static ram. Many PIC processors are so incredibly low powered in sleep that the main register memory can easily be made non-volatable with a coin cell or super cap.

Or, many real time clock chips have a little bit of RAM and they are intended to run on minimal standby power. If you don't need the clock function, you don't have to hook up a crystal, and then they take even less power. In this mode, the clock registers themselves can be used to store arbitrary data. Microchip MCP7940 is a classic in this category. It has 64 bytes of RAM not counting the clock registers.

Ferroelectric RAM, aka FRAM, is non-volatile without any power at all. The only slightly suboptimal thing about FRAM is that the read is destructive. Doesn't sound like that would matter in your application. These are pricey on a per-byte basis but there are sub-kbyte parts around 50 cents that can be cheaper overall than anything requiring a battery or a supercap.

The best is magnetoresistive RAM, sometimes called MRAM. This is a fantastic technology. You could write every millisecond for thousands of years without wearing it out. The read is non-destructive. Sadly, where FRAM is "pricey," these are freakin' expensive.

Whatever the memory technology, it is a good idea to design in a little redundancy. You can set up multiple copies of the data and write them sequentially, so there is always at least one copy that is intact if the right cycle doesn't complete before power goes away.

I use multi-dimensional parity on my non volatile storage so I can recover from an interrupted write or other corruption. It's a little more complicated and takes a few more CPU cycles than multiple redundant blocks but gives you more protection with less extra storage.

I hope that was helpful to someone ...
 
I do note that it seems sensitive to noise on the pre diode side of the + supply ie, using the switch to turn off the supply the save works intermittently
Click to expand...
So, when you get the falling edge interrupt I would:
- disable all interrupts
- write data to eeprom
- sit in a 'while(1)' loop with interrupts disabled as power continues to drop

No need to debounce the switch... you have more important things to do.

Do you have any brownout detection enabled to hold the part in reset once VDD drops below the rated supply voltage?
The 16F1827 allows settings of 1.9V or 2.5V, depending on what osc freq you're running at.
 
If you want to handle brownout >> power fail or brownout >> power recovers
then later you do have to debounce the switch. To make sure its next edge
is valid, not an artifact of the prior interrupt. So set a timer to create a non
blocking process and when times out check switch to have released. That
way you can continue processing while in a brownout condition. If power
recovers re-enable the interrupt. If power fails then part gets restarted.

Or just restart the part to start from scratch. But if switch still bouncing you
have to treat that. So I would vote for handling it in the first case. Or if brownout
leads to power fail while you are debouncing handle the recovery where if
switch still bouncing you treat that. I have had switches bounce as long as 300+ mS
so keep that in mind unless you have a good quality switch (mine was an archeological
artifact from BC era).

Regards, Dana.
 
Yes to all re the code (see below) and no to Brown out, it is turned off.

Will get the scope out later and look at the power rails to see what is happening.

I have to crack open one of the plug packs, I have a sneaking suspicion there is an electrolytic in there that may be causing the problem.

Re using an external memory device, not needed, the PIC is more than capable of covering what needs to be done and constantly writing data interferes with the rest of the program runtime.

The Retfie at the end was a 'just in case it escaped the interupt' code.

C-like: 
ORG     0x0004        ; interrupt routine data save

    bcf    INTCON,GIE    ; Global Interrupt Enable bit

    BANKSEL    IOCBF
    bcf    IOCBF,IOCBF7    ; INTERRUPT-ON-CHANGE FLAG REGISTER
    movlb    0

    clrf    PORTA
    clrf    PORTB

    call    update_EEPROM

    goto    $

    retfie             ; Enable general interrupts and return
 
Status
Not open for further replies.

Similar threads

R
  • Question
Having a problem with the EEPROM on PIC32MK1024MCF064
Replies
0
Views
4K
R-K-8592
R
G
  • Question
Which PIC programmer to be used?
Replies
1
Views
3K
Nigel Goodwin
P
Can't get EEPROM to work.
Replies
3
Views
4K
Ian Rogers
P
  • Question
Place EEPROM at byte boundaries in Pic18 series.
Replies
1
Views
4K
Ian Rogers
  • Question
Libraries for I2C (MSSP1), RTC DS1307 and EEPROM AT24C32 (Pic Basic Compiler Oshonsoft).
Replies
0
Views
718
DogFlu66
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…