ColdFire MCFxxxx processors typically come with two on-chip
watchdog devices. The main watchdog is not readily usable by eCos: it
comes up enabled and, once disabled, it can never be reenabled. Hence
in a typical development environment that watchdog device needs to be
disabled early on or it will interfere with debugging, and cannot be
used again. There is a second watchdog device embedded in the System
Control Module which is usable. This package
CYGPKG_DEVS_WATCHDOG_MCFxxxx_SCM provides an eCos
driver for that device, complementing the generic package
CYGPKG_IO_WATCHDOG. The driver functionality should
be accessed via the standard eCos watchdog functions
The MCFxxxx SCM watchdog driver package should be loaded automatically
when selecting a platform containing a suitable MCFxxxx ColdFire processor.
It should never be necessary to load it explicitly into the
configuration. The package is inactive unless the generic watchdog support
CYGPKG_IO_WATCHDOG is loaded. Depending on the
choice of eCos template it may be necessary to load the latter.
There are a number of configuration options. The first is
CYGIMP_WATCHDOG_HARDWARE, which can be used to
disable the use of the hardware watchdog and switch to a software
emulation provided by the generic watchdog package instead. This may
prove useful during debugging.
By default the watchdog device is set to reset the system when the
timeout expires. It can be configured to raise an interrupt instead by
interrupt ISR will invoke any installed application action handlers.
The watchdog timeout is controlled by
corresponds to the
CWT field in the SCM's
CWCR register. It can take a value between 8 and
31, with a default of 28. That means 2^28 peripheral bus clock ticks
have to elapse before the watchdog triggers. Typically that
means a timeout of a small number of seconds. There is a
calculated CDL option
CYGNUM_DEVS_WATCHDOG_MCFxxxx_SCM_DELAY which gives the
current delay in nanoseconds.
The watchdog device has a bit which turns it read-only, preventing any
errant code from accidentally disabling it. By default the driver will
set this bit after starting the watchdog. If for some reason the
application needs to access the device directly then the option
CYGIMP_DEVS_WATCHDOG_MCFxxxx_SCM_WRITE_ONCE should be
By default the watchdog is set to continue ticking even if the
core is halted by an idle thread action or by power management code.
This can cause problems if the application code halts the core for an
extended period of time, so the behaviour can be changed by disabling
If the watchdog device is configured to raise interrupts rather than
generate a reset then
the interrupt priority. There are also configuration options allowing
developers to tweak the compiler flags used for building this package.
The watchdog device driver usually does not require any
platform-specific support. The processor HAL should provide the
device definitions needed by the code. The only porting effort
required is to list
CYGPKG_DEVS_WATCHDOG_MCFxxxx_SCM as one of the
hardware packages in the ecos.db target entry.