ImageCraft ICCAVR - Startup ?

The environment is an ATmega64 with a 32 KHz watch crystal running a
real time clock on AVR timer0.

The problem is with an occasional watch dog reset that happens every
few days or longer is resetting the AVR processor and wiping out the
current real time clock values. The long term fix it to find what is
causing the watchdog resets, but saving the real time clock through a
watchdog reset is still a desirable program enhancement.

What I would like to do is use the MCUSR register reset flags to
detect the watchdog (WDRF) flag only and treat this as a warm start
(i.e. a warm start as in the SRAM real time clock variables still have
valid data in them).

 In order to do this, I need to read the MCUSR register and copy the
real time clock variables before these real time clock variables are
initialized, before main() is run. I think using a custom startup file
is the correct place to access the MCUSR and the real time clock
variables. The problem is I cannot see a straight forward way of
creating a protected memory storage area just for the copies of the
real time clock variables and the MCUSR flag.

Of course, if it is not a warm start then the normal real time clock
initialization would still apply.

The idea is roughly:
STARTUP-
  read MCUSR
  save MCUSR to a protected temporary location
  clear MCUSR (as per data sheet instructions)
  if MCUSR == WDRF
    read the real time clock values
     save the real time clock values in a protected temporary location

memory will be initialized before main() is run, except for the
protected memory-

main()-
  read the MCUSR flag from the protected temporary location
  if MCUSR == WDRF
     read the real time clock values from the protected temporary
location
     restore the real time clock values (i.e. overwrite the ICC
initialized values)


I'm open to any other suggestions on how to do this.

On 16/05/2007 Scott Kelley wrote:

> 
> 
> The environment is an ATmega64 with a 32 KHz watch crystal running a
> real time clock on AVR timer0.
> 
> The problem is with an occasional watch dog reset that happens every
> few days or longer is resetting the AVR processor and wiping out the
> current real time clock values. The long term fix it to find what is
> causing the watchdog resets, but saving the real time clock through a
> watchdog reset is still a desirable program enhancement.
> 
> What I would like to do is use the MCUSR register reset flags to
> detect the watchdog (WDRF) flag only and treat this as a warm start
> (i.e. a warm start as in the SRAM real time clock variables still have
> valid data in them).
> 
>  In order to do this, I need to read the MCUSR register and copy the
> real time clock variables before these real time clock variables are
> initialized, before main() is run. I think using a custom startup file
> is the correct place to access the MCUSR and the real time clock
> variables. The problem is I cannot see a straight forward way of
> creating a protected memory storage area just for the copies of the
> real time clock variables and the MCUSR flag.
> 
> Of course, if it is not a warm start then the normal real time clock
> initialization would still apply.
> 
> The idea is roughly:
> STARTUP-
>   read MCUSR
>   save MCUSR to a protected temporary location
>   clear MCUSR (as per data sheet instructions)
>   if MCUSR == WDRF
>     read the real time clock values
>      save the real time clock values in a protected temporary location
> 
> memory will be initialized before main() is run, except for the
> protected memory-
> 
> main()-
>   read the MCUSR flag from the protected temporary location
>   if MCUSR == WDRF
>      read the real time clock values from the protected temporary
> location
>      restore the real time clock values (i.e. overwrite the ICC
> initialized values)
> 
> 
> I'm open to any other suggestions on how to do this.

Hello again Scott.

Why don't you put the RTC variables in the 'noinit' area and only
intitialise it when specifically required, rather than at every reset?

-- 
John B

On May 15, 9:14 pm, Scott Kelley <sco...@iccom.com> wrote:
> The environment is an ATmega64 with a 32 KHz watch crystal running a
> real time clock on AVR timer0.
>
> The problem is with an occasional watch dog reset that happens every
> few days or longer is resetting the AVR processor and wiping out the
> current real time clock values. The long term fix it to find what is
> causing the watchdog resets,

Sound like a power or signal noise problem.

> but saving the real time clock through a
> watchdog reset is still a desirable program enhancement.

How about saving to EEPROM?