On 8 Apr 2006 12:04:32 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> 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).
>
>That's a dubious plan.

In core memory systems, it was easy to save the internal state and
resume execution at the next instruction, when the power was restored.
While the internal state was nicely preserved, the "external" real
word situation might no longer match the stored internal state.

Assuming input A changes state before input B you should end in one
state, but if B changes before A, you should end in an other state in
the state diagram. If both A and B changes state during the state
machine power failure and both are ON when the power is restored, did
A change before B or vice versa and what should the final state be ?

Thus, it is not enough to store the internal state, but you should
also check that similar situations do not exist in the state diagram
or have a special transition if both A and B becomes simultaneously ON
(indicating a restoration of state machine power). 

In more complex systems it would be highly dangerous to resume
operation with the settings used before the power failure, without
checking the current state of the external world after power
restoration.

Paul

<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 

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/>

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

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/

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.

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

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.

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