WatchDog Use

[sheershak-agarwal]

Hey,

How do I use Watchdog timer?

I read on the doc that A health component in the system uses a set of ping ports to send a message to an active component. The active component is required to respond with the value in the key argument passed in the port by a certain timeout.

So I understand that Watchdog timer uses Health component but where I do add Watchdog in my top design?
Also how will my system react when a FATAL error is encountered? will the system automatically start f-prime again? if not then how do I start my application again?

Thanks

[LeStarch]

@timcanham can you assist here?

[sheershak-agarwal]

Hello again, Can someone please assist me with this question?

[sheershak-agarwal]

@LeStarch @timcanham I am still stuck with integration of the WatchDog in my design. Any help will be much appreciated.

[timcanham]

@sheershak-agarwal Watchdogs are dependent on the system you are designing. It is commonly a hardware timer that counts down and will reset the processor if it reaches zero. The software periodically resets the count of the watchdog so the countdown never reaches zero. The idea is that if the software goes unstable and stops resetting the counter, it will eventually reach zero and reset the processor to provide a way to recover the computer if the error was a transient one.

The Fprime reference app does not include a watchdog because it is specific to a platform. What it does provide is an output port on the Health component. A particular project is expected to implement a component connected to that port that resets the watchdog. If, for instance, you had a watchdog timer that was on an SPI bus, each time the component is called by the Health component WdogStroke port, it would send the SPI transaction to reset the timer. The Health component will only call the port when all components connected to the PingSend ports respond correctly on the corresponding PingReturn port. That way if any task stops responding, the watchdog will not get stroked.

The FatalAnnounce on the ActiveLogger component behaves in a similar way. It is up to the system to decided how to handle FATAL events, so it is also system-specific. The user will write a component to handle the FATAL. Since FATAL (and FW_ASSERT that turns into a FATAL) typically means the computing platform is compromised and untrustworthy, it is common to just reset the processor to hopefully clear the condition. A particular platform may have other requirements, such as making an attempt put hardware in a safe state (ex. motor spinning) before resetting. The reference application, since it is written for Linux, raises the SIGSEGV in the Svc/FatalHandler component to generate a core so that the app can be debugged, but the expectation is that an embedded platform would not use this component, but one appropriate for the system. To follow the previous example, the FATAL handler might send an SPI transaction to a power control module to cycle power to the processor.

As for restarting the system, that would be tied to whether or not you thought the system could just restart the application successfully or if it needs to power cycle itself to clear any issues. If a processor is in a bad state, just restarting the application may not clear the condition that caused the FATAL. The reference application doesn't attempt to do anything other than generate a core file. If you do decided you want to restart the application, it would have to be tied into the implementation of the FATAL handler component.

[timcanham]

@sheershak-agarwal If you give us an idea of the system you are trying to design, perhaps we can give you some ideas.

[sheershak-agarwal]

Thank you so much. This helps a lot.