Forums

A state machine question

Started by Unknown April 8, 2006
I am implementing a state machine which has the following requirement:
If the state machine is interrupted by power off, the state machine
shall resume from where it was interrupted after the program is
restarted ( power on in this case).

A basic idea is to keep a snapshot of the state machine before it is
interrupted.

I am seeking a better solution. please advice me.

Thank you very much.

John

johnwang1wang@yahoo.com wrote:
> I am implementing a state machine which has the following requirement: > If the state machine is interrupted by power off, the state machine > shall resume from where it was interrupted after the program is > restarted ( power on in this case). > > A basic idea is to keep a snapshot of the state machine before it is > interrupted. > > I am seeking a better solution. please advice me.
You are going to have to store the last-state, somehow, so I'm not sure what 'better solution' you are after. Plus power recover might need some conditioning, to avoid power-related changes triggering an unwanted early next-state. -jg
On 7 Apr 2006 23:01:35 -0700, in comp.arch.embedded
johnwang1wang@yahoo.com wrote:

>I am implementing a state machine which has the following requirement: >If the state machine is interrupted by power off, the state machine >shall resume from where it was interrupted after the program is >restarted ( power on in this case). > >A basic idea is to keep a snapshot of the state machine before it is >interrupted. > >I am seeking a better solution. please advice me. > >Thank you very much. > >John
http://www.semiconductors.philips.com/acrobat/applicationnotes/AN468_1.pdf martin
johnwang1wang@yahoo.com wrote:
> I am implementing a state machine which has the following requirement: > If the state machine is interrupted by power off, the state machine > shall resume from where it was interrupted after the program is > restarted ( power on in this case).
That's a dubious plan.
> A basic idea is to keep a snapshot of the state machine before it is > interrupted.
You quite definitely don't need a snapshot of "the state machine". If you have more to store than the current state of the machine (i.e. in typically a single number), you didn't have a state machine to begin with. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
johnwang1wang@yahoo.com wrote:

> I am implementing a state machine which has the following requirement: > If the state machine is interrupted by power off, the state machine > shall resume from where it was interrupted after the program is > restarted ( power on in this case). > > A basic idea is to keep a snapshot of the state machine before it is > interrupted. > > I am seeking a better solution. please advice me.
This is ok. Just store the state of the state machine. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Rene Tschaggelar wrote:
> johnwang1wang@yahoo.com wrote: > >> I am implementing a state machine which has the following requirement: >> If the state machine is interrupted by power off, the state machine >> shall resume from where it was interrupted after the program is >> restarted ( power on in this case). >> >> A basic idea is to keep a snapshot of the state machine before it is >> interrupted. >> >> I am seeking a better solution. please advice me. > > This is ok. Just store the state of the state machine.
Yeah, but where? You also have to consider the case of power interruptions while the state machine is changing state. This pretty well requires that it be driven from an interrupt, be short, and disable the power fail interrupt while executing. In addition the power has to hold up for at least the execution period after the power fail interrupt is generated. Here a worm, there a worm. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/> Also see <http://www.safalra.com/special/googlegroupsreply/>
johnwang1wang@yahoo.com wrote:

> I am implementing a state machine which has the following requirement: > If the state machine is interrupted by power off, the state machine > shall resume from where it was interrupted after the program is > restarted ( power on in this case). > > A basic idea is to keep a snapshot of the state machine before it is > interrupted. > > I am seeking a better solution. please advice me. > > Thank you very much. > > John >
As CBFalconer pointed out you have to make this immune from power down. I can think of three ways to do this, with varying levels of function, cost and complexity. All require battery-backed or flash memory, which I'm just going to refer to as 'memory'. First and easiest is to establish two identical areas in memory where you will keep state data. Make sure there's a time stamp. Protect them with CRC checksums, and ping-pong between them. Each time you save state write to the whole area followed by a checksum. On power up look for the most recent state with a good checksum -- that's your baby. This method has the disadvantage that important things may happen but not get saved. Second is to make sure that your power supply hardware will keep the computer up for a while, and will tell you went it can't. Keep one area in memory to save state, with a checksum, and don't write to it if your power supply can't keep things going. Third is to equip your power supply with a means to interrupt your processor when power goes down, and gives you a guaranteed-good time to save your processor state. Take your _whole_ processor state, along with all of RAM, and save it away, along with a tag to identify the fact that the processor state is good. On power up, check the tag and if it's good then restore RAM and the _whole_ processor state and do a return-from-interrupt. Because you saved the _whole_ processor state it won't know the difference between what just happened and a glitch on the interrupt line. This is not, by the way, trivial. I know people who've done it and it's quite hard to do right. Furthermore, if you have a customer asking for it they'll get justifiably upset if it doesn't work. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/
CBFalconer wrote:

> Rene Tschaggelar wrote: > >>johnwang1wang@yahoo.com wrote: >> >> >>>I am implementing a state machine which has the following requirement: >>>If the state machine is interrupted by power off, the state machine >>>shall resume from where it was interrupted after the program is >>>restarted ( power on in this case). >>> >>>A basic idea is to keep a snapshot of the state machine before it is >>>interrupted. >>> >>>I am seeking a better solution. please advice me. >> >>This is ok. Just store the state of the state machine. > > > Yeah, but where? You also have to consider the case of power > interruptions while the state machine is changing state. This > pretty well requires that it be driven from an interrupt, be short, > and disable the power fail interrupt while executing. In addition > the power has to hold up for at least the execution period after > the power fail interrupt is generated.
Naa, this is unwieldy. I tend to store states in the embedded EEPROM if the state doesn't change too often. Else if the state changes more often, I'd take an RTC with Li battery and some bytes of RAM in it. Rene
Rene Tschaggelar wrote:
> CBFalconer wrote: >> Rene Tschaggelar wrote: >>> johnwang1wang@yahoo.com wrote: >>> >>>> I am implementing a state machine which has the following >>>> requirement: If the state machine is interrupted by power off, >>>> the state machine shall resume from where it was interrupted >>>> after the program is restarted ( power on in this case). >>>> >>>> A basic idea is to keep a snapshot of the state machine before >>>> it is interrupted. >>>> >>>> I am seeking a better solution. please advice me. >>> >>> This is ok. Just store the state of the state machine. >> >> Yeah, but where? You also have to consider the case of power >> interruptions while the state machine is changing state. This >> pretty well requires that it be driven from an interrupt, be short, >> and disable the power fail interrupt while executing. In addition >> the power has to hold up for at least the execution period after >> the power fail interrupt is generated. > > Naa, this is unwieldy. > I tend to store states in the embedded EEPROM if the > state doesn't change too often. Else if the state > changes more often, I'd take an RTC > with Li battery and some bytes of RAM in it.
If you don't pay attention to those unwieldy details your stored state is worth about as much as a Microsoft OS. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/> Also see <http://www.safalra.com/special/googlegroupsreply/>
<johnwang1wang@yahoo.com> wrote in message 
news:1144476095.695349.223130@v46g2000cwv.googlegroups.com...
>I am implementing a state machine which has the following requirement: > If the state machine is interrupted by power off, the state machine > shall resume from where it was interrupted after the program is > restarted ( power on in this case). > > A basic idea is to keep a snapshot of the state machine before it is > interrupted. > > I am seeking a better solution. please advice me.
I'd be cautious. The state of the hardware, and the environment, and indeed the time, are not the same after a powerdown as before. I'd recommend defining which bits of the *context* you need to maintain through powerdown, and doing a full restart - and then restoring the context intelligently. Simply storing one state (or the entire memory image, as another has suggested) is unlikely to be satisfactory. You may well have to reinitialise peripherals, and recover from interrupted processes and comms. Unless you have a powerfail interrupt, and enough holdup time to close down cleanly, you will also need to ensure that the "context" is valid at all times. Steve http://www.fivetrees.com