Description

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 watchdog_start, watchdog_reset and watchdog_get_resolution.

Configuration Options

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 disabling CYGIMP_DEVS_WATCHDOG_MCFxxxx_SCM_RESET. The interrupt ISR will invoke any installed application action handlers.

The watchdog timeout is controlled by CYGNUM_DEVS_WATCHDOG_MCFxxxx_SCM_TICKS. This 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 disabled.

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 CYGIMP_DEVS_WATCHDOG_MCFxxxx_SCM_RUN_WHILE_HALTED.

If the watchdog device is configured to raise interrupts rather than generate a reset then CYGNUM_DEVS_WATCHDOG_MCFxxxx_SCM_ISR_PRIORITY controls the interrupt priority. There are also configuration options allowing developers to tweak the compiler flags used for building this package.

Porting

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.