About VxWorks watchdog - VxWorks

This is a discussion on About VxWorks watchdog - VxWorks ; As you know, VxWorks provides watchdog schema which could be used to guard a task to prevent long-time run... If we don't cancel the watchdog timer before it timed out, it will trigger handler running at the ISR context of ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: About VxWorks watchdog

  1. About VxWorks watchdog

    As you know, VxWorks provides watchdog schema which could be used to
    guard a task to prevent long-time run...
    If we don't cancel the watchdog timer before it timed out, it will
    trigger handler running at the ISR context of OS's sytem clock. And, if
    the handler can't be executed immediately, it wil be add to tExcTask's
    work queue, so this could guarantee the fast handling...

    In the handler, we could choose to reboot the system if think the time
    out is un-acceptable...

    Not sure my understandings above and below is right...
    ---
    The watchdog is more likely to be a software watchdog, because our app
    handles it and choose the next action. To a H/W watchdog, there is a
    counter in the H/W, if program don't reset the counter from time to
    timer, it will time out and H/W reset the card...

    Do you agree this is a S/W watchdog?
    Do your system use the H/W watchdog, how to use it?

    Thanks!


  2. Re: About VxWorks watchdog

    Your're pretty close. wdLib is purely a SW timing mechanism You could
    certainly use it to "pet" a hardware watchdog, to prevent your system
    from getting locked up by an out of control task.

    Your board may or may not have a watch dog timer circuit. If it does,
    you could create a task that pets it or use a wdLib function to pet it.
    HW watch dog timers are board-specific, and generally there is no BSP
    support for them either.

    As an examply, my PPC8280 has a built-in HW watchdog that works as
    you've described. Here's Moto descrition from the RM...

    Software watchdog timer -
    Asserts a reset or NMI interrupt, selected by the system protection
    control register (SYPCR) if the software fails to service the software
    watchdog timer for a certain period of time (for example, because
    software is lost or trapped in a loop). After a system reset, this
    function is enabled, selects a maximum time-out period, and asserts a
    system reset if the time-out is reached. The software watchdog timer
    can be disabled or its time-out period may be changed in the SYPCR.
    Once the SYPCR is written, it cannot be written again until a system
    reset. For more information, see Section 4.1.5, "Software
    WatchdogTimer.

    Good luck,
    lc

    jeanwelly wrote:
    > As you know, VxWorks provides watchdog schema which could be used to
    > guard a task to prevent long-time run...
    > If we don't cancel the watchdog timer before it timed out, it will
    > trigger handler running at the ISR context of OS's sytem clock. And, if
    > the handler can't be executed immediately, it wil be add to tExcTask's
    > work queue, so this could guarantee the fast handling...
    >
    > In the handler, we could choose to reboot the system if think the time
    > out is un-acceptable...
    >
    > Not sure my understandings above and below is right...
    > ---
    > The watchdog is more likely to be a software watchdog, because our app
    > handles it and choose the next action. To a H/W watchdog, there is a
    > counter in the H/W, if program don't reset the counter from time to
    > timer, it will time out and H/W reset the card...
    >
    > Do you agree this is a S/W watchdog?
    > Do your system use the H/W watchdog, how to use it?
    >
    > Thanks!



  3. Re: About VxWorks watchdog

    Great thanks!!!

    Yes... Spawning a new task running a corresponding low priority (say 0)
    to pet HW watchodg is good method.

    LarryC wrote:
    > Your're pretty close. wdLib is purely a SW timing mechanism You could
    > certainly use it to "pet" a hardware watchdog, to prevent your system
    > from getting locked up by an out of control task.
    >
    > Your board may or may not have a watch dog timer circuit. If it does,
    > you could create a task that pets it or use a wdLib function to pet it.
    > HW watch dog timers are board-specific, and generally there is no BSP
    > support for them either.
    >
    > As an examply, my PPC8280 has a built-in HW watchdog that works as
    > you've described. Here's Moto descrition from the RM...
    >
    > Software watchdog timer -
    > Asserts a reset or NMI interrupt, selected by the system protection
    > control register (SYPCR) if the software fails to service the software
    > watchdog timer for a certain period of time (for example, because
    > software is lost or trapped in a loop). After a system reset, this
    > function is enabled, selects a maximum time-out period, and asserts a
    > system reset if the time-out is reached. The software watchdog timer
    > can be disabled or its time-out period may be changed in the SYPCR.
    > Once the SYPCR is written, it cannot be written again until a system
    > reset. For more information, see Section 4.1.5, "Software
    > WatchdogTimer.
    >
    > Good luck,
    > lc
    >
    > jeanwelly wrote:
    > > As you know, VxWorks provides watchdog schema which could be used to
    > > guard a task to prevent long-time run...
    > > If we don't cancel the watchdog timer before it timed out, it will
    > > trigger handler running at the ISR context of OS's sytem clock. And, if
    > > the handler can't be executed immediately, it wil be add to tExcTask's
    > > work queue, so this could guarantee the fast handling...
    > >
    > > In the handler, we could choose to reboot the system if think the time
    > > out is un-acceptable...
    > >
    > > Not sure my understandings above and below is right...
    > > ---
    > > The watchdog is more likely to be a software watchdog, because our app
    > > handles it and choose the next action. To a H/W watchdog, there is a
    > > counter in the H/W, if program don't reset the counter from time to
    > > timer, it will time out and H/W reset the card...
    > >
    > > Do you agree this is a S/W watchdog?
    > > Do your system use the H/W watchdog, how to use it?
    > >
    > > Thanks!



  4. Re: About VxWorks watchdog

    Priority 0 would be a high priority task. Not sure either extreme is
    what you want.

    lc
    jeanwelly wrote:
    > Great thanks!!!
    >
    > Yes... Spawning a new task running a corresponding low priority (say 0)
    > to pet HW watchodg is good method.
    >
    > LarryC wrote:
    > > Your're pretty close. wdLib is purely a SW timing mechanism You could
    > > certainly use it to "pet" a hardware watchdog, to prevent your system
    > > from getting locked up by an out of control task.
    > >
    > > Your board may or may not have a watch dog timer circuit. If it does,
    > > you could create a task that pets it or use a wdLib function to pet it.
    > > HW watch dog timers are board-specific, and generally there is no BSP
    > > support for them either.
    > >
    > > As an examply, my PPC8280 has a built-in HW watchdog that works as
    > > you've described. Here's Moto descrition from the RM...
    > >
    > > Software watchdog timer -
    > > Asserts a reset or NMI interrupt, selected by the system protection
    > > control register (SYPCR) if the software fails to service the software
    > > watchdog timer for a certain period of time (for example, because
    > > software is lost or trapped in a loop). After a system reset, this
    > > function is enabled, selects a maximum time-out period, and asserts a
    > > system reset if the time-out is reached. The software watchdog timer
    > > can be disabled or its time-out period may be changed in the SYPCR.
    > > Once the SYPCR is written, it cannot be written again until a system
    > > reset. For more information, see Section 4.1.5, "Software
    > > WatchdogTimer.
    > >
    > > Good luck,
    > > lc
    > >
    > > jeanwelly wrote:
    > > > As you know, VxWorks provides watchdog schema which could be used to
    > > > guard a task to prevent long-time run...
    > > > If we don't cancel the watchdog timer before it timed out, it will
    > > > trigger handler running at the ISR context of OS's sytem clock. And, if
    > > > the handler can't be executed immediately, it wil be add to tExcTask's
    > > > work queue, so this could guarantee the fast handling...
    > > >
    > > > In the handler, we could choose to reboot the system if think the time
    > > > out is un-acceptable...
    > > >
    > > > Not sure my understandings above and below is right...
    > > > ---
    > > > The watchdog is more likely to be a software watchdog, because our app
    > > > handles it and choose the next action. To a H/W watchdog, there is a
    > > > counter in the H/W, if program don't reset the counter from time to
    > > > timer, it will time out and H/W reset the card...
    > > >
    > > > Do you agree this is a S/W watchdog?
    > > > Do your system use the H/W watchdog, how to use it?
    > > >
    > > > Thanks!



  5. Re: About VxWorks watchdog

    LarryC wrote:

    >> Yes... Spawning a new task running a corresponding low priority (say 0)
    >> to pet HW watchodg is good method.

    >
    >Priority 0 would be a high priority task. Not sure either extreme is
    >what you want.


    Right. In VxWorks, 0 is the highest task priority and HW watchdog maintenance
    should probably not be a real time system's highest priority. If it is then
    I would suspect that the dog's time constant is probably too short.

    What is more, using a timer to schedule HW watchdog maintenance is probably
    not an optimal approach. The idea is to generate a reset if the system's
    mission is not being accomplished and, in most real time systems, the
    ability to respond to a periodic timer is probably not highest on the
    list of mission critical accomplishments. Instead, one would do well to
    perform HW watchdog maintenance as the last step of a high priority task,
    ideally after it has shown to have met its deadline.

    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at hotmail dot com | - The Who, Bargain

  6. Re: About VxWorks watchdog

    My base line is:
    If the task responsible for petting the HW watchdog running at the
    highest priority could not pet the dog as expected, system stuck may
    happen...

    Just as Moto said, to spawn a task, so in your system, how to use in
    this way? In which priority?
    Furthermore, I agree using a timer is not a good way.

    Michael R. Kesti wrote:
    > LarryC wrote:
    >
    > >> Yes... Spawning a new task running a corresponding low priority (say 0)
    > >> to pet HW watchodg is good method.

    > >
    > >Priority 0 would be a high priority task. Not sure either extreme is
    > >what you want.

    >
    > Right. In VxWorks, 0 is the highest task priority and HW watchdog maintenance
    > should probably not be a real time system's highest priority. If it is then
    > I would suspect that the dog's time constant is probably too short.
    >
    > What is more, using a timer to schedule HW watchdog maintenance is probably
    > not an optimal approach. The idea is to generate a reset if the system's
    > mission is not being accomplished and, in most real time systems, the
    > ability to respond to a periodic timer is probably not highest on the
    > list of mission critical accomplishments. Instead, one would do well to
    > perform HW watchdog maintenance as the last step of a high priority task,
    > ideally after it has shown to have met its deadline.
    >
    > --
    > ================================================== ======================
    > Michael Kesti | "And like, one and one don't make
    > | two, one and one make one."
    > mrkesti at hotmail dot com | - The Who, Bargain



+ Reply to Thread