Preserving a few variables across Power cycles

tomcrawford

I need to save a few (less than 10) byte variables across power cycles. I am sure this has been discussed but I cannot find anything specific.

Up to now, I have had a clock chip with battery-backed RAM (DS-1302) and have kept them there and restored during initialization. But I will be getting time from a GPS from now on and don't need the clock chip any longer.

I am planning to use a little bit at the very top (last 16 bytes) of the EEPROM (24CL256). I will write and read it with code cribbed from "Basic I2C Routines V 1.3".

So here are my questions:

1. Does the boot loader always write the entire 32K bytes or just as much as it needs to? That is, will it over-write my variables (assuming my object leaves room)?
2. Would the boot loader work correctly if I used a 24CL512 (and keep the top 32K for myself)?
3. Is there something I am not thinking of that will keep this scheme from working? In other words, has anybody made this work in the past?

AdThanksVance for your time

ChrisGadd

No problem, create a dat section in your code for your variables, use the variables in the DAT section just as you would variables declared in a VAR section, and just before the power cycle write the new values back in to the DAT section. In my I2C routines EEPROM demo, I have a counter that is initialized to 0 in the code, the code reads and displays this value on the serial terminal, and then increments it and writes the new value back into the same location it was loaded from in EEPROM.

...
  FDS.hex(counter,2)                                        ' Display counter value - loaded automatically from EEPROM on each reset
  I2C.write(I2C#EEPROM,@counter,counter + 1)                ' Increment counter and store back in to EEPROM - Each reset causes the stored value to increase by 1

DAT            org
counter       byte     00                                   ' Initializes counter to 0, value gets incremented by the program.  Storing this program in EEPROM and resetting causes the incremented value to be used

Mike Green

1) The boot loader always writes the entire 32K and will clear any variables (VAR) in your program.

2) The boot loader only affects the 1st 32K of EEPROM. You can use larger EEPROMs or multiple EEPROMs (at different addresses) and the boot loader will ignore any other than the 1st 32K

It's easiest to use a 64K EEPROM and store your values in the 2nd 32K. If you have only 32K and store the values in the upper few bytes of the EEPROM, they will get erased when you download a new program version. It may not be a problem during program debugging and, depending on what these variables contain, the program may be able to tolerate them being reset from time to time.

Duane Degn

tomcrawford wrote: »

I need to save a few (less than 10) byte variables across power cycles. I am sure this has been discussed but I cannot find anything specific.

There's lesson on this in the PEK sticky in the Propeller forum (here's a direct link). You can save the new values of the variables to the EEPROM so they get loaded with the program on reboot.

Which Propeller board are you using? Most of the boards Parallax sells use 64K EEPROMs.

tomcrawford wrote: »

So here are my questions:

1. Does the boot loader always write the entire 32K bytes or just as much as it needs to? That is, will it over-write my variables (assuming my object leaves room)?

Whenever you load the EEPROM from the Prop Tool (F11) the entire lower 32K get overwritten. If you're just rebooting then whatever is in the EEPROM gets loaded to RAM including any changes you make. Rebooting wont mess up stuff you write EEPROM just loading the program from the Prop Tool will erase any changes you make to the lower 32K of EEPROM.

tomcrawford wrote: »

2. Would the boot loader work correctly if I used a 24CL512 (and keep the top 32K for myself)?

Yes, and the upper 32K doesn't get overwritten by the Prop Tool. It's very convenient to keep data you don't want overwritten in upper EEPROM.

tomcrawford wrote: »

3. Is there something I am not thinking of that will keep this scheme from working? In other words, has anybody made this work in the past?

AdThanksVance for your time

This is a common practice among many Propeller users. It can be immensely useful.

BTW, Some EEPROMs have their size listed in a cryptic manner. If you don't know if you have a 32K EEPROM or a 64K EEPROM you can use the program attached to post #24 of this thread to check which size it is (it doesn't check for EEPROMs larger than 64K). The part of the program which checks for size works but the other features listed are really buggy.

Edit: I see Mike and Chris have already answered a lot of what you've asked. Sorry about the duplicate information.

tomcrawford

Thank you, Gentlemen. To answer Duane about what board, it is one I did myself.

Er, do you suppose Parallax will be selling a 64KB EEPROM soon?

Mike Green

They do sell a surface mount version (here), the same part they use on their boards. For a PDIP version, you'll need to order from someone like Mouser or Jameco or Digikey.

Bobb Fwed

This is a bit different than what you are trying to resolve, but it is still a handy trick. You can store the current value of a variable to the variable's address in the EEPROM. Next time the Propeller boots the variable is already populated with the last stored value.
All you need to use is this: write(@variable, @variable, 1 or 2 or 4) ' the last parameter is based on the variable's type
No need for a read method, the value is already in the variable when the Prop turns on.

Using the I2C object and this method (I believe it is just I2C's recommended write method):

PUB write (addr, valueAddr, size) | time
'' write page to EEPROM with watchdog  

  IF i2c.WritePage(BootPin, EEPROM, addr, valueAddr, size)
    RETURN false
  time := cnt
  repeat while i2c.WriteWait(BootPin, EEPROM, addr)                             ' wait for watchdog
    if cnt - time > clkfreq / 10
      RETURN false

  RETURN true

WBA Consulting

I am using the Propeller EEProm code on Andy Lindsay's thread here to do the same thing with my Shackable Scavenger Hunt project. As others have mentioned already, it is actually very simple to store variables back into the EEProm. Heck, even I can do it........

JasonDorie

I've used Chris' method to write variables directly into the EEPROM so they're "auto loaded" on the next boot. It works well, is pretty simple to implement, and doesn't need more than the 32Kb EEPROM. You just write the variables from your DAT section to their HUB address in the EEPROM - they're the same.

The only caveat : try to do it relatively infrequently. If you write to the same block of the EEPROM frequently, you'll wear it out. There was a thread on here a while back where someone updated a variable once every couple seconds, as opposed to only when it was changed. He burned out his EEPROM in only a few days. (every 5 secs would be ~17000 writes in 24 hours).

Clive Wakeham

http://au.element14.com/fujitsu/mb85rc16vpnf-g-jne1/fram-16k-i2c-5v-8sop/dp/2070258

What about a FRAM which doesn't need battery backup and has the ability (on average) to be written to the same location up to (10 to the power of 10) times?