RE: [ECOS] Hardware Watchdog

RE: [ECOS] Hardware Watchdog

[Doug Fraser]

There are several opinions on this,
so don't be surprised by disagreements.

With a multi tasking OS, one could
take two task based views.

One: Stick it at the highest priority level
(thread, process, whatever....) and the
watchdog fires if the kernel crashes
or stops scheduling for any reason.

Two: Stick it at the lowest priority level
and the watchdog will fire in any starvation
situation.

There are good and bad points for either,
and I won't argue them here. (the list
is arbitrary and HUGE!)

In either case, a still running system can
make other decisions about its own health
and kill or block the watchdog thread,
forcing a reset. You might even consider
adding a rendezvous point to the watchdog thread.

On acknowledging the watchdog from an interrupt...

Depending on you interrupt structure, you
should not associate it with an interrupt.
The reason being that on many systems, the
interrupts will continue to fire even if
the kernel is dead or scheduling has ceased.

That would be bad if your periodic timer
interrupt was hammering away happily on your
otherwise dead system, keeping the much
needed watchdog at bay.

Doug

> -----Original Message-----
> From: fche@redhat.com [ mailto:fche@redhat.com ]
> Sent: Thursday, July 26, 2001 7:57 AM
> To: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] Hardware Watchdog
> 
> 
> Content-Type: text/plain; charset=US-ASCII
> From: fche@redhat.com (Frank Ch. Eigler)
> Date: 26 Jul 2001 07:56:53 -0400
> In-Reply-To: < 20010726125313.A14929@frequentis.com >
> Message-ID: <o5ofq7ucmy.fsf@touchme.toronto.redhat.com>
> Lines: 23
> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
> MIME-Version: 1.0
> 
> Christoph Csebits <christoph.csebits@frequentis.com> writes:
> 
> : [...]
> : im having a MPC860T based board with
> : an hardware watchdog on it.
> : [...]
> : In eCos applications i am having a
> : separate thread triggering the watchdog.
> : No problem.
> : [...]
> : What do you think about using some
> : of the timer interrupts for generating
> : the watchdog triggers.
> 
> Is it typical to put watchdog reset calls into separate dedicated
> threads, or low-level automatically-invoked code like interrupt
> handlers?  I was under the impression that watchdog resets are most
> appropriately placed within the activity loops of the application code
> itself -- it is their demise that the watchdog mechanism is meant to
> detect.
> 
> 
> - FChE
> 

Re: [ECOS] Hardware Watchdog

[Christoph Csebits]

On Thu, Jul 26, 2001 at 10:24:08AM -0400, Doug Fraser wrote:
> [......]
> 
> Doug

Thanks for your statement, I basically
agree with you. 

But my really problem is porting
RedBoot to my platform.

RedBoot doesnt support scheduling,
its a single task, and finding
every single little loop that could
last longer as my watchdog period
is really annoying, and time consuming.

And you never know, if you missed one.

The best solution would be a switchable
watchdog. During the Bootstrapper is
running the watchdog is disabled.
Starting the real application goes
hand in hand with enabling the watchdog
so the application can handle it in
a case dependend manner.

Nevertheless my watchdog is not
software controlled. :-|

comments would be appreciated
Is nobody running RedBoot with such a device?

regards, christoph
-- 

Re: [ECOS] Hardware Watchdog

[Gary Thomas]

On 26-Jul-2001 Christoph Csebits wrote:
> Nevertheless my watchdog is not
> software controlled. :-|
> 

What happens when your watchdog fires?   
Is there an exception that you can catch?
What is the watchdog time [limit]?  Can you adjust it?

Fixing this may be hard.  Within RedBoot, there is a notion of "idle"
routines which will be called while RedBoot waits.  However, once the
GDB stubs start running, all of that stops and everything is simply
polled based on the serial port.

Re: [ECOS] Hardware Watchdog

[Christoph Csebits]

On Thu, Jul 26, 2001 at 09:49:29AM -0600, Gary Thomas wrote:
> 
> On 26-Jul-2001 Christoph Csebits wrote:
> > Nevertheless my watchdog is not
> > software controlled. :-|
> > 
> 
> What happens when your watchdog fires?   

the MPCs reset lines are pulled accordingly
to do an hard reset. no way to catch it. :-)

> Fixing this may be hard.  Within RedBoot, there is a notion of "idle"
> routines which will be called while RedBoot waits.  However, once the
> GDB stubs start running, all of that stops and everything is simply
> polled based on the serial port.

I have a running version of RedBoot, but as i told, from
time to time i am running into a loop, and the board resets.
Then i start to locate the loop and fix it.

The best solution may be a timer interrupt routine
with detaching the interrupt when starting an application.
(Someone mentioned it earlier, thanks to him
- i lost the mail and do not remember the name)

Is it the right way to do it with
cyg_drv_interrupt_create( );
cyg_drv_interrupt_attach( );
cyg_drv_interrupt_acknowledge( );
cyg_drv_interrupt_unmask( );
:

Re: [ECOS] Hardware Watchdog

[Gary Thomas]

On 26-Jul-2001 Christoph Csebits wrote:
> On Thu, Jul 26, 2001 at 09:49:29AM -0600, Gary Thomas wrote:
>> 
>> On 26-Jul-2001 Christoph Csebits wrote:
>> > Nevertheless my watchdog is not
>> > software controlled. :-|
>> > 
>> 
>> What happens when your watchdog fires?   
> 
> the MPCs reset lines are pulled accordingly
> to do an hard reset. no way to catch it. :-)
> 
>> Fixing this may be hard.  Within RedBoot, there is a notion of "idle"
>> routines which will be called while RedBoot waits.  However, once the
>> GDB stubs start running, all of that stops and everything is simply
>> polled based on the serial port.
> 
> I have a running version of RedBoot, but as i told, from
> time to time i am running into a loop, and the board resets.
> Then i start to locate the loop and fix it.
> 
> The best solution may be a timer interrupt routine
> with detaching the interrupt when starting an application.
> (Someone mentioned it earlier, thanks to him
> - i lost the mail and do not remember the name)
> 
> Is it the right way to do it with
> cyg_drv_interrupt_create( );
> cyg_drv_interrupt_attach( );
> cyg_drv_interrupt_acknowledge( );
> cyg_drv_interrupt_unmask( );
>:

Sorry, interrupts are not enabled in RedBoot, so this just isn't going to
cut it.

What is the period on the watchdog?
Do you have any ideas what's happening (in RedBoot or otherwise) then it fails?

Re: [ECOS] Hardware Watchdog

[Robin Farine]

Christoph Csebits <christoph.csebits@frequentis.com> writes:

Does your board use an external chip such as the Maxim MAX691A as watchdog? And
if yes, does it use a GPIO pin of the CPU to keep the watchdog quiet?

Robin

Re: [ECOS] Hardware Watchdog

[Christoph Csebits]

On Thu, Jul 26, 2001 at 08:24:59PM +0200, Robin Farine wrote:
> Christoph Csebits <christoph.csebits@frequentis.com> writes:
> 
> Does your board use an external chip such as the Maxim MAX691A as watchdog? And
> if yes, does it use a GPIO pin of the CPU to keep the watchdog quiet?

Yes you are right (MAX690T) and it is served an a GPIO pin (PortB) of
the MPC.
-- 
___________________________________
DI Christoph Csebits, System Design
FREQUENTIS   -   www.frequentis.com
A-1120 Wien, Spittelbreitengasse 34
voice:  +43/1/81150-2149, fax: 2499

Re: [ECOS] Hardware Watchdog

[Robin Farine]

Christoph Csebits <christoph.csebits@frequentis.com> writes:

> On Thu, Jul 26, 2001 at 08:24:59PM +0200, Robin Farine wrote:
> > Christoph Csebits <christoph.csebits@frequentis.com> writes:
> > 
> > Does your board use an external chip such as the Maxim MAX691A as watchdog? And
> > if yes, does it use a GPIO pin of the CPU to keep the watchdog quiet?
> 
> Yes you are right (MAX690T) and it is served an a GPIO pin (PortB) of
> the MPC.

Ok, have you already tried to configure the GPIO pin as *input*? This would
set the line in high-impedance mode and the MAX should disable its watchdog
function. Check your ROM startup code for access to the GPDR (IO direction
register). Then, in the application, reconfigure this bit as output to use the
watchdog.

Robin

Re: [ECOS] Hardware Watchdog

[Christoph Csebits]

On Fri, Jul 27, 2001 at 08:48:14AM +0200, Robin Farine wrote:
> Ok, have you already tried to configure the GPIO pin as *input*? This would
> set the line in high-impedance mode and the MAX should disable its watchdog
> function. Check your ROM startup code for access to the GPDR (IO direction
> register). Then, in the application, reconfigure this bit as output to use the
> watchdog.

basically its right, but the hardware designers
made a good job of it, and there is a pull down
resistor preventing the watchdog input from floating.
(which would disable the watchdog timer)

i dont think the soldering iron is an acceptable
solution. :-)

thanks, christoph
- 

Re: [ECOS] Hardware Watchdog

[Robin Farine]

Christoph Csebits <christoph.csebits@frequentis.com> writes:

> On Fri, Jul 27, 2001 at 08:48:14AM +0200, Robin Farine wrote:
> > Ok, have you already tried to configure the GPIO pin as *input*? This would
> > set the line in high-impedance mode and the MAX should disable its watchdog
> > function. Check your ROM startup code for access to the GPDR (IO direction
> > register). Then, in the application, reconfigure this bit as output to use the
> > watchdog.
> 
> basically its right, but the hardware designers
> made a good job of it, and there is a pull down
> resistor preventing the watchdog input from floating.
> (which would disable the watchdog timer)

That's exactly what I suspected :-(

> 
> i dont think the soldering iron is an acceptable solution. :-)
> 

Why not? I would call this a design flaw and report it to the manufacturer. The
fact that a place for a pull down resistor exists is a good thing (we have seen
some chips with specified internal pull down/up resistors but in the reality,
those pins were floating so we now always put some pads just in case), but in
this case the resistor should not be fitted.

Robin

[ECOS] RedBoot RAM version problem

[Andre Sebastien]

Hi everyone;


I build a Redboot RAM version for a ARM7TDMI PID Board.
Download it into RAM via t32 software + lauterbach; JTAG link
And i Run IT

The start output of Redboot :


+FLASH: driver init failed!, status: 0xd

RedBoot(tm) bootstrap and debug environment - built 16:17:25, Jul 26 2001

Platform: PID (ARM 7TDMI)
Copyright (C) 2000, 2001, Red Hat, Inc.

RAM: 0x00000000-0x00080000, 0x0001a0f8-0x00080000 available
RedBoot>

SO i see that Redboot can t initialize the FLASH DRIVER !!
===> + FLASH: driver init failed!, status: Oxd

So when i try to make a fis init command the system HANG when he try to print the
message: ... Warning:device contents not erased, some blocks may not be usable...

At this moment i had think that FLASH package wasn t added to redboot
Then i had try an ecosconfig add flash but .... it has already into redboot
configuration.

So now i think that i have some problem with JUMPER of my board !!
in a ecos documentation  i see that i need to put it:

SET JUMPER 7-8 on LK6 (using the angle cpde in the 16 bit EPROM)
SET JUMPER 5-6 on LK6 (select 8bit ROM mode)
SET JUMPER LK18 (ROM REMAP - this is also required for ecos)
SET S1 to 0-0-1-1

So when i did it after i can run the hello example in ram !!!
What i shloud do ?
My working configuration for run in ram is :
JUMPER 7-8 on LK6   ON
JUMPER 5-6 on LK6   OFF
JUMPER LK18 OFF
S1 is to 1-1-1-1

thanks for your help.

best regards,
Sebastien.

Re: [ECOS] RedBoot RAM version problem

[Jesper Skov]

>>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:

Andre> +FLASH: driver init failed!, status: 0xd

That error code is "wrong part". Does your board have a AT29C040A on
it?

Jesper

Re: [ECOS] RedBoot RAM version problem

[Andre Sebastien]

Yes it s this flash device that i have (AT29C040A) !!!!

What does it wrong ?


Jesper Skov wrote:

> >>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:
>
> Andre> +FLASH: driver init failed!, status: 0xd
>
> That error code is "wrong part". Does your board have a AT29C040A on
> it?
>
> Jesper

Re: [ECOS] RedBoot RAM version problem

[Jesper Skov]

>>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:

Andre> Yes it s this flash device that i have (AT29C040A) !!!!  What
Andre> does it wrong ?

Dunno. I remember we had a similar problem with one of the boards in
our test farm, but I never got around to investigate.

The problem is that the device ID returned by the device when queried
is not what the driver expects. See flash_hwr_init in
devs/flash/atmel/at29cxxxx/current/include/flash_at29cxxxx.inl.

Jesper

Re: [ECOS] RedBoot RAM version problem

[Andre Sebastien]

Hi,

I start to examine this file !! i make a little changment in the code for see th
differents ID , build it and execute it !!!

so  MANUFACTURER ID that device return is 18 and the expected by redboot is 31
      FLASH device ID that device return is 0 and the expected by redboot is 164

So What should i do ? bypass this test or not ?

Jesper Skov wrote:

> >>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:
>
> Andre> Yes it s this flash device that i have (AT29C040A) !!!!  What
> Andre> does it wrong ?
>
> Dunno. I remember we had a similar problem with one of the boards in
> our test farm, but I never got around to investigate.
>
> The problem is that the device ID returned by the device when queried
> is not what the driver expects. See flash_hwr_init in
> devs/flash/atmel/at29cxxxx/current/include/flash_at29cxxxx.inl.
>
> Jesper

Re: [ECOS] RedBoot RAM version problem

[Gary Thomas]

On 27-Jul-2001 Andre Sebastien wrote:
> Hi,
> 
> I start to examine this file !! i make a little changment in the code for see th
> differents ID , build it and execute it !!!
> 
> so  MANUFACTURER ID that device return is 18 and the expected by redboot is 31
>       FLASH device ID that device return is 0 and the expected by redboot is 164
> 
> So What should i do ? bypass this test or not ?

It seems to me that the device is not responding to the inquiry - those are not
valid numbers AFAIK.

In most of the flash drivers, there is a pause after sending the "identify" command
before reading the data.  Some devices take a really long time to go into that
mode and send back the correct information.  Try increasing the pause and see
if it starts working.

> 
> Jesper Skov wrote:
> 
>> >>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:
>>
>> Andre> Yes it s this flash device that i have (AT29C040A) !!!!  What
>> Andre> does it wrong ?
>>
>> Dunno. I remember we had a similar problem with one of the boards in
>> our test farm, but I never got around to investigate.
>>
>> The problem is that the device ID returned by the device when queried
>> is not what the driver expects. See flash_hwr_init in
>> devs/flash/atmel/at29cxxxx/current/include/flash_at29cxxxx.inl.
>>
>> Jesper

Re: [ECOS] RedBoot RAM version problem

[Andre Sebastien]

Hi everybody !!

So i try to increase a pause in this function : 'void flash_dev_query(void* data)'

into i make a pause at two differents points !!! each pause are around 1 sec (but i
had test it with 15 secs too :-) )

    void flash_dev_query(void* data)
     {

        .....

     HAL_FLASH_CACHES_OFF(d_cache, i_cache);

      <=========== HERE

    (*_flash_query)(data);

      <=========== HERE

    HAL_FLASH_CACHES_ON(d_cache, i_cache);
   }

So this way don t work !!! i have always the same problem !!!!



Gary Thomas wrote:

> On 27-Jul-2001 Andre Sebastien wrote:
> > Hi,
> >
> > I start to examine this file !! i make a little changment in the code for see th
> > differents ID , build it and execute it !!!
> >
> > so  MANUFACTURER ID that device return is 18 and the expected by redboot is 31
> >       FLASH device ID that device return is 0 and the expected by redboot is 164
> >
> > So What should i do ? bypass this test or not ?
>
> It seems to me that the device is not responding to the inquiry - those are not
> valid numbers AFAIK.
>
> In most of the flash drivers, there is a pause after sending the "identify" command
> before reading the data.  Some devices take a really long time to go into that
> mode and send back the correct information.  Try increasing the pause and see
> if it starts working.
>
> >
> > Jesper Skov wrote:
> >
> >> >>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:
> >>
> >> Andre> Yes it s this flash device that i have (AT29C040A) !!!!  What
> >> Andre> does it wrong ?
> >>
> >> Dunno. I remember we had a similar problem with one of the boards in
> >> our test farm, but I never got around to investigate.
> >>
> >> The problem is that the device ID returned by the device when queried
> >> is not what the driver expects. See flash_hwr_init in
> >> devs/flash/atmel/at29cxxxx/current/include/flash_at29cxxxx.inl.
> >>
> >> Jesper

Re: [ECOS] RedBoot RAM version problem

[Jesper Skov]

>>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:

Andre> Hi everybody !!  So i try to increase a pause in this function
Andre> : 'void flash_dev_query(void* data)'

Wrong place. You want to tweak this function:

//----------------------------------------------------------------------------
// Flash Query
//
// Only reads the manufacturer and part number codes for the first
// device(s) in series. It is assumed that any devices in series
// will be of the same type.

void
flash_query(void* data)
{
    volatile flash_data_t *ROM;
    flash_data_t* id = (flash_data_t*) data;
    int i;

    ROM = (volatile flash_data_t*) CYGNUM_FLASH_BASE;

    ROM[FLASH_Setup_Addr1] = FLASH_Setup_Code1;
    ROM[FLASH_Setup_Addr2] = FLASH_Setup_Code2;
    ROM[FLASH_Setup_Addr1] = FLASH_Read_ID;

    // FIXME: 10ms delay
    for (i = 10000; i > 0; i--);

    // Manufacturers' code
    id[0] = ROM[0];
    // Part number
    id[1] = ROM[1];

    ROM[FLASH_Setup_Addr1] = FLASH_Setup_Code1;
    ROM[FLASH_Setup_Addr2] = FLASH_Setup_Code2;
    ROM[FLASH_Setup_Addr1] = FLASH_Read_ID_Exit;

    // FIXME: 10ms delay
    for (i = 10000; i > 0; i--);
}

it's in devs/flash/atmel.../flash_at29cxxxx.inl

Jesper

Re: [ECOS] RedBoot RAM version problem

[Andre Sebastien]

Ohh excuse me :-) i don t see this function !!!
 i try to increase these delay ( i had try 100ms 1s and 5s) but the same problems
all the time !!!!

thanks
best regards,
Sebastien.


Jesper Skov wrote:

> >>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:
>
> Andre> Hi everybody !!  So i try to increase a pause in this function
> Andre> : 'void flash_dev_query(void* data)'
>
> Wrong place. You want to tweak this function:
>
> //----------------------------------------------------------------------------
> // Flash Query
> //
> // Only reads the manufacturer and part number codes for the first
> // device(s) in series. It is assumed that any devices in series
> // will be of the same type.
>
> void
> flash_query(void* data)
> {
>     volatile flash_data_t *ROM;
>     flash_data_t* id = (flash_data_t*) data;
>     int i;
>
>     ROM = (volatile flash_data_t*) CYGNUM_FLASH_BASE;
>
>     ROM[FLASH_Setup_Addr1] = FLASH_Setup_Code1;
>     ROM[FLASH_Setup_Addr2] = FLASH_Setup_Code2;
>     ROM[FLASH_Setup_Addr1] = FLASH_Read_ID;
>
>     // FIXME: 10ms delay
>     for (i = 10000; i > 0; i--);
>
>     // Manufacturers' code
>     id[0] = ROM[0];
>     // Part number
>     id[1] = ROM[1];
>
>     ROM[FLASH_Setup_Addr1] = FLASH_Setup_Code1;
>     ROM[FLASH_Setup_Addr2] = FLASH_Setup_Code2;
>     ROM[FLASH_Setup_Addr1] = FLASH_Read_ID_Exit;
>
>     // FIXME: 10ms delay
>     for (i = 10000; i > 0; i--);
> }
>
> it's in devs/flash/atmel.../flash_at29cxxxx.inl
>
> Jesper

Re: [ECOS] RedBoot RAM version problem

[Jesper Skov]

>>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:

Andre> Ohh excuse me :-) i don t see this function !!!  i try to
Andre> increase these delay ( i had try 100ms 1s and 5s) but the same
Andre> problems all the time !!!!

The loop count is probably not accurate as a 10ms. But if you tried
with a factor of 500, timing is probably not the problem.

Do you have an ARM9 on the PID board, by any chance?

Jesper

Re: [ECOS] RedBoot RAM version problem

[Andre Sebastien]

No it s an ARM7TDMI board !!!
the problem can become of WRONG configuration of JUMPERS board like jumper LK18
?


Jesper Skov wrote:

> >>>>> "Andre" == Andre Sebastien <sebastien.andre@sxb.bsf.alcatel.fr> writes:
>
> Andre> Ohh excuse me :-) i don t see this function !!!  i try to
> Andre> increase these delay ( i had try 100ms 1s and 5s) but the same
> Andre> problems all the time !!!!
>
> The loop count is probably not accurate as a 10ms. But if you tried
> with a factor of 500, timing is probably not the problem.
>
> Do you have an ARM9 on the PID board, by any chance?
>
> Jesper

RE: [ECOS] Hardware Watchdog

[Doug Fraser]

Very possibly you are correct, but I do
not know the gdb stubs at that level.
To honk the thing, you just write a register.
The problem is, if you are late even one
clock tick, the processor resets, and there
is absolutely nothing you can do about that.

That is why I propose finding all the normal
surface loops, then just plain shutting the
watchdog down if GDB starts.

Doug

> 
> So the idea is that you need some piece of code telling
> the watchdog "I'm alive", correct?  Surely this can be
> done without all of the baggage of handling interrupts.

Yup, as long as you cover every single loop location.


> I don't see how you can handle interrupts without enabling then.
> Once they are enabled, then other interrupt conditions might need
> to be serviced, etc.

Install NULL handlers....


> 
> I think it much better/wiser to figure out where it might be "looping"
> and put in stuff to tickle the watchdog appropriately.
> 

RE: [ECOS] Hardware Watchdog

[Doug Fraser]

Interrupts may not be enabled in redboot, but
does that stop him from installing his own
tick handler and servicing the watchdog from there?
The maximum time on the 860 watchdog is around
three seconds with a 50Mhz CPU clock.
As Christoph mentioned, the watchdog activates
a hard reset cycle, and there is nothing you can
do to catch it. The other problem is that if you
disable the watchdog, you cannot reenable it
without performing a hard reset.

As well as servicing it with a tick interrupt
during redboot, you could also disable it if
the redboot polling mechanism detects a GDB
connect. You probably want the watchdog off
during debugging anyway, so that would allow the
target to boot with a watchdog in a normal run
state, yet reduce the complexity of having to
service it during a debug session.

good luck...

Doug

> -----Original Message-----
> From: Gary Thomas [ mailto:gthomas@redhat.com ]
> Sent: Thursday, July 26, 2001 12:24 PM
> To: Christoph Csebits
> Cc: Doug Fraser; fche@redhat.com; ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] Hardware Watchdog
> 
> 
> 
> On 26-Jul-2001 Christoph Csebits wrote:
> > On Thu, Jul 26, 2001 at 09:49:29AM -0600, Gary Thomas wrote:
> >> 
> >> On 26-Jul-2001 Christoph Csebits wrote:
> >> > Nevertheless my watchdog is not
> >> > software controlled. :-|
> >> > 
> >> 
> >> What happens when your watchdog fires?   
> > 
> > the MPCs reset lines are pulled accordingly
> > to do an hard reset. no way to catch it. :-)
> > 
> >> Fixing this may be hard.  Within RedBoot, there is a 
> notion of "idle"
> >> routines which will be called while RedBoot waits.  
> However, once the
> >> GDB stubs start running, all of that stops and everything is simply
> >> polled based on the serial port.
> > 
> > I have a running version of RedBoot, but as i told, from
> > time to time i am running into a loop, and the board resets.
> > Then i start to locate the loop and fix it.
> > 
> > The best solution may be a timer interrupt routine
> > with detaching the interrupt when starting an application.
> > (Someone mentioned it earlier, thanks to him
> > - i lost the mail and do not remember the name)
> > 
> > Is it the right way to do it with
> > cyg_drv_interrupt_create( );
> > cyg_drv_interrupt_attach( );
> > cyg_drv_interrupt_acknowledge( );
> > cyg_drv_interrupt_unmask( );
> >:
> 
> Sorry, interrupts are not enabled in RedBoot, so this just 
> isn't going to
> cut it.
> 
> What is the period on the watchdog?
> Do you have any ideas what's happening (in RedBoot or 
> otherwise) then it fails?
> 

RE: [ECOS] Hardware Watchdog

[Gary Thomas]

On 26-Jul-2001 Doug Fraser wrote:
> Interrupts may not be enabled in redboot, but
> does that stop him from installing his own
> tick handler and servicing the watchdog from there?
> The maximum time on the 860 watchdog is around
> three seconds with a 50Mhz CPU clock.
> As Christoph mentioned, the watchdog activates
> a hard reset cycle, and there is nothing you can
> do to catch it. The other problem is that if you
> disable the watchdog, you cannot reenable it
> without performing a hard reset.
> 

So the idea is that you need some piece of code telling
the watchdog "I'm alive", correct?  Surely this can be
done without all of the baggage of handling interrupts.

> As well as servicing it with a tick interrupt
> during redboot, you could also disable it if
> the redboot polling mechanism detects a GDB
> connect. You probably want the watchdog off
> during debugging anyway, so that would allow the
> target to boot with a watchdog in a normal run
> state, yet reduce the complexity of having to
> service it during a debug session.
> 

I don't see how you can handle interrupts without enabling then.
Once they are enabled, then other interrupt conditions might need
to be serviced, etc.

I think it much better/wiser to figure out where it might be "looping"
and put in stuff to tickle the watchdog appropriately.

[ECOS] Hardware Watchdog

[Christoph Csebits]

hi

im having a MPC860T based board with
an hardware watchdog on it. It must be
triggered within a second, otherwise
the MPC will be reset.

In eCos applications i am having a
separate thread triggering the watchdog.
No problem.

How should i deal with it in RedBoot:

Currently i scattered several of 
TOGGLE_WATCHDOG macros into the
RedBoot code, but this should only
be a preliminarily solution.

What do you think about using some
of the timer interrupts for generating
the watchdog triggers.

Thanks for advice, and how to start.

best regards, christoph
-- 

Re: [ECOS] Hardware Watchdog

[fche]

Content-Type: text/plain; charset=US-ASCII
From: fche@redhat.com (Frank Ch. Eigler)
Date: 26 Jul 2001 07:56:53 -0400
In-Reply-To: < 20010726125313.A14929@frequentis.com >
Message-ID: <o5ofq7ucmy.fsf@touchme.toronto.redhat.com>
Lines: 23
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0

Christoph Csebits <christoph.csebits@frequentis.com> writes:

: [...]
: im having a MPC860T based board with
: an hardware watchdog on it.
: [...]
: In eCos applications i am having a
: separate thread triggering the watchdog.
: No problem.
: [...]
: What do you think about using some
: of the timer interrupts for generating
: the watchdog triggers.

Is it typical to put watchdog reset calls into separate dedicated
threads, or low-level automatically-invoked code like interrupt
handlers?  I was under the impression that watchdog resets are most
appropriately placed within the activity loops of the application code
itself -- it is their demise that the watchdog mechanism is meant to
detect.


- FChE