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