Reliability of a microcontroller in sleep mode

Marcel, having put C51's to sleep I cannot recall any such problems. You
have to meticulously follow the manufacturers instructions as to how to
wake it up, and the behavior during wake-up. But remember, the chip still
has its supply voltage and only the clock is shut down.

Regards, Joerg.

> You can refresh the initialization from time to time, or even at every
> wake-up. 

Yeah, but his point is that the alien mind control rays will flip the
interrupt enable or DDR or whatever that gates a signal from the
outside world into the wakeup interrupt that brings the processor out
of sleep. Really there is no way of solving that short of extra
external stateless hardware that forces a reset if the CPU doesn't
respond to stimuli.

Lewin A.R.W. Edwards <larwe@larwe.com> says...

>Yeah, but his point is that the alien mind control rays will flip the
>interrupt enable or DDR or whatever that gates a signal from the
>outside world into the wakeup interrupt that brings the processor out
>of sleep. Really there is no way of solving that short of extra
>external stateless hardware that forces a reset if the CPU doesn't
>respond to stimuli.

Even then, I have had prototypes decide to respond to interupts 
while the main loop is frozen, or to run the main loop but ignore
interupts.  I have heard of programs that crash in an infinite
"tell the watchdog I am running" loop.


-- 
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
have an "impossible" engineering project that only someone like 
Doc Brown can solve?  My resume is at http://www.guymacon.com/ 

On Mon, 19 Apr 2004 11:40:42 +0100, Mike Harrison
<mike@whitewing.co.uk> wrote:


>>Just curious, how would this be different from being in running state? Is
>>there any reason to suspect higher susceptibility to EMI/ESD corruption in
>>sleep mode?

>In many cases it will be in sleep mode for the vast majority of time, and therefore statistically
>more likely that an upset event will occur in sleep mode. 

I really suggest that you should concentrate on solving the EMC/ESD
issues and not bother with this kind of wakeup issues.

In general a fully static logic (i.e. the clock can be fully stopped
without loss of data) is likely to loose data due to EMC/ESD/radiation
since these are built around bistable multivibrators than dynamic or
pseudo static circuits. If some minimum clock frequency (say 32 kHz)
is required to maintain the internal data, some data is usually stored
as an electric charge only, which requires regular refreshing. Such
structures are more likely to suffer from SEUs.

Paul

"Marcel-G" <marcel-g@xs4all.nl> wrote in message
news:1a53e44a.0404190554.713f0a1c@posting.google.com...
> > > When a microcontroller is put in sleep mode many registers and RAM are
> > > in an initialized state. In this condition the microcontroller can be
> > > affected by ESD, EMI which means the initialization can be corrupted
> > > -> there is a risk it does not wake up anymore.
> > >
> > > Of course there are watchdogs, but due to power constraints this can
> > > not be on during sleep.
> > >
> > > Is there anybody who has experience with this kind of problems ?
> > >
> > > MarcelG
> >
> > Just curious, how would this be different from being in running state?
Is
> > there any reason to suspect higher susceptibility to EMI/ESD corruption
in
> > sleep mode?
> >
> > Rob
>
> If a microcontroller can run permanently in running state some clock
> is running and the power consumption is higher then in sleep.
> So during running state it is usually not a problem from power
> consumption point of view to have  a watchdog running.
>
> I`m talking about a device which can be a year in sleep, used for a
> few minutes and sleep again for a long time.
>

Marcel,
If this thing is going to be off for perhaps a year at a time, I'm still
wondering why you don't turn the micro off completely (with state held in
non-volatile memory) and use a simple robust circuit to power up the micro
from reset when your wake-up stimulus arrives? I'm sure a couple of
transistors or a FET or whatever will be less susceptible to interference or
cosmic rays than the itty-bitty gates in the micro.

Is there a response-time issue?

Peter.

Thanks for all the comments... I was curious how others dealt with it.
Cith the C51 I have also never seen it, but the tendency now is faster
cores and lower voltages so it become more sensitive to external
interference.
And in cost and space sensitive applications it`s not always possible
to design the pcb as good as it should be.

I only came up with the same as some people suggested... alsways start
from out of reset, or use some watchdog construction which is also
triggered by the event which wakes up the mcu.

It would be nice to have mcu`s with an "always on" interrupt which
also anables the watchdog when triggered.

Regards,
  Marcel

In article <1a53e44a.0404201049.ad54b75@posting.google.com>, marcel-
g@xs4all.nl says...
> Thanks for all the comments... I was curious how others dealt with it.
> Cith the C51 I have also never seen it, but the tendency now is faster
> cores and lower voltages so it become more sensitive to external
> interference.
> And in cost and space sensitive applications it`s not always possible
> to design the pcb as good as it should be.
> 
> I only came up with the same as some people suggested... alsways start
> from out of reset, or use some watchdog construction which is also
> triggered by the event which wakes up the mcu.
> 
> It would be nice to have mcu`s with an "always on" interrupt which
> also anables the watchdog when triggered.
> 

I was just reading the data sheet for the Philips LPC2106 yesterday,
and it seems to have that kind of functionality.  There are several
external interrupts that function when the MPU is in sleep mode with
all clocks halted.  The handler for one of those interrupts could
vector to a routine in internal flash that does just about anything
you want up to a full reset.    Of course with no clocks, the
RTC will not be working and you will need to get the time (if 
required) from some other source.

I suspect that 'always on' interrupts that work even when all clocks
are halted are not all that rare.

Mark Borgerson