Specifications are subject to change without notice.

The Debounce Time register, when programmed for a non-zero value, is used with channels programmed as input to “filter” or “ignore” expected application spurious initial transitions. Once a signal level is a logic voltage level period longer than the Debounce Time (Logic High and Logic Low), a logic transition is validated. Signal pulse widths less than programmed Debounce Time are filtered. Once valid, the transition status register flag is set for the channel and the output logic changes state.

The module contains automatic background BIT testing that verifies channel processing (data read or write logic), tests for overcurrent conditions and provides status for threshold signal transitioning.

Any failure triggers an Interrupt (if enabled) with the results available in status registers. The testing is totally transparent to the user, requires no external programming and has no effect on the operation of this card. It can be enabled or disabled via the bus (see further details in register description), and continually checks that each channel is functional. This capability is accomplished by an additional test comparator that is incorporated into each module. The test comparator checks each channel and is compared against the operational channel. Depending upon the configuration, the Input data read or Output logic written of the operational channel and test comparator must agree or a fault is indicated with the results available in the associated status register. Low-toHigh and High-to-Low logic transitions are indicated.

There is no independent overcurrent detection. Instead, the BIT detection circuitry is used to infer an overcurrent condition if the output state setting doesn’t match the readback value seen by the input circuitry. For example, a shorted output, causing the read state to be opposite from the expected value would trigger this. If the fault persists beyond the BIT interval stabilization time, the overcurrent protection will kick in and reset the drive output by returning the transceiver to input mode. To reset this condition, a reset command needs to be issued to the Overcurrent Reset register, which will restore drive output and allow the latched status to be reset. This is separate from the reset for the Overcurrent Interrupt Enable register on this module. It is recommended that a reset command is done whenever status is cleared to avoid a non-apparent output reset condition.

The DF Digital I/O Function Module provide registers that indicate faults or events. Refer to “Status and Interrupts Module Manual” for the Principle of Operation description.

The DF Digital I/O Function Module provide registers that support User Watchdog Timer capability. Refer to “User Watchdog Timer Module Manual” for the Principle of Operation description.

The DF Digital I/O Function Module provide module common registers that provide access to module-level bare metal/FPGA revisions & compile times, unique serial number information, and temperature/voltage/current monitoring. Refer to “Module Common Registers Module Manual” for the detailed information.

Function: Sets data outputs High (1) or Low (0).

Type: unsigned binary word (32-bit)

Read/Write: R/W

Initialized Value: 0

Operational Settings: Write 1 for High output; write 0 for Low.

Refer to “User Watchdog Timer Module Manual” for the register descriptions.

Refer to “Module Common Registers Module Manual” for the register descriptions.

The DF Digital I/O Module provides status registers for BIT, Low-to-High Transition, High-to-Low Transition, and Overcurrent.

When interrupts are enabled, the interrupt vector associated with the specific interrupt can be programmed (typically with a unique number/identifier) such that it can be utilized in the Interrupt Service Routine (ISR) to identify the type of interrupt. When an interrupt occurs, the contents of the Interrupt Vector registers is reported as part of the interrupt mechanism. In addition to specifying the interrupt vector, the interrupt can be directed (“steered”) to the native bus or to the application running on the onboard ARM processor.

Refer to “User Watchdog Timer Module Manual” for the User Watchdog Timer Status Function Register Map

Refer to “Module Common Registers Module Manual” for the Module Common Registers Function Register Map

BIT

Low-to-High Transition

High-to-Low Transition

Overcurrent

The DF Digital I/O Module provides registers that support User Watchdog Timer capability. Refer to “User Watchdog Timer Module Manual” for the User Watchdog Timer Fault Status Function Register Map.

The Interrupt Vector and Interrupt Steering registers are mapped to the Motherboard Memory Space and these addresses are absolute based on the module slot position. In other words, do not apply the Module Address offset to these addresses.

When interrupts are enabled, the interrupt vector associated with the specific interrupt can be programmed with a unique number/identifier defined by the user such that it can be utilized in the Interrupt Service Routine (ISR) to identify the type of interrupt. When an interrupt occurs, the contents of the Interrupt Vector registers is reported as part of the interrupt mechanism. In addition to specifying the interrupt vector, the interrupt can be directed (“steered”) to the native bus or to the application running on the onboard ARM processor.

In most applications, limiting the number of interrupts generated is preferred as interrupts are costly, thus choosing the correct Edge/Level interrupt trigger to use is important.

Example 1: Fault detection

This example illustrates interrupt considerations when detecting a fault like an “open” on a line. When an “open” is detected, the system will receive an interrupt. If the “open” on the line is persistent and the trigger is set to “edge”, upon “clearing” the interrupt, the system will not regenerate another interrupt. If, instead, the trigger is set to “level”, upon “clearing” the interrupt, the system will re-generate another interrupt. Thus, in this case, it will be better to set the trigger type to “edge”.

Example 2: Threshold detection

This example illustrates interrupt considerations when detecting an event like reaching or exceeding the “high watermark” threshold value. In a communication device, when the number of elements received in the FIFO reaches the high-watermark threshold, an interrupt will be generated. Normally, the application would read the count of the number of elements in the FIFO and read this number of elements from the FIFO. After reading the FIFO data, the application would “clear” the interrupt. If the trigger type is set to “edge”, another interrupt will be generated only if the number of elements in FIFO goes below the “high watermark” after the “clearing” the interrupt and then fills up to reach the “high watermark” threshold value. Since receiving communication data is inherently asynchronous, it is possible that data can continue to fill the FIFO as the application is pulling data off the FIFO. If, at the time the interrupt is “cleared”, the number of elements in the FIFO is at or above the “high watermark”, no interrupts will be generated. In this case, it will be better to set the trigger type to “level”, as the purpose here is to make sure that the FIFO is serviced when the number of elements exceeds the high watermark threshold value. Thus, upon “clearing” the interrupt, if the number of elements in the FIFO is at or above the “high watermark” threshold value, another interrupt will be generated indicating that the FIFO needs to be serviced.

The examples in this section illustrate the differences in behavior of the Dynamic Status and Latched Status registers as well as the differences in behavior of Edge/Level Trigger when the Latched Status register is cleared.

Figure 1. Example of Module’s Channel-Mapped Dynamic and Latched Status States

The examples in this section illustrate the interrupt behavior with Edge/Level Trigger.

Figure 2. Illustration of Latched Status State for Module with 4-Channels with Interrupt Enabled

The User Watchdog Timer (UWDT) Capability is available on the following modules:

The User Watchdog Timer is optionally activated by the applications that require the module’s outputs to be disabled as a failsafe in the event of an application failure or crash. The circuit is designed such that a specific periodic write strobe pattern must be executed by the software to maintain operation and prevent the disablement from taking place.

The User Watchdog Timer is inactive until the application sends an initial strobe by writing the value 0x55AA to the UWDT Strobe register. After activating the User Watchdog Timer, the application must continually strobe the timer within the intervals specified with the configurable UWDT Quiet Time and UWDT Window registers. The timing of the strobes must be consistent with the following rules:

A violation of any of these rules will trigger a User Watchdog Timer fault and result in shutting down any isolated power supplies and/or disabling any active drive outputs, as applicable for the specific module. Upon a User Watchdog Timer event, recovery to the module shutting down will require the module to be reset.

The Figure 1 and Figure 2 provides an overview and an example with actual values for the User Watchdog Timer Strobes, Quiet Time and Window. As depicted in the diagrams, there are two processes that run in parallel. The Strobe event starts the timer for the beginning of the “Quiet Time”. The timer for the Previous Strobe event continues to run to ensure that no additional Strobes are received within the “Window” associated with the Previous Strobe.

The optimal target for the user watchdog strobes should be at the interval of [Quiet time + ½ Window time] after the previous strobe, which will place the strobe in the center of the window. This affords the greatest margin of safety against unintended disablement in critical operations.

Figure 1. User Watchdog Timer Overview

Figure 2. User Watchdog Timer Example

Figure 3. User Watchdog Timer Failures

The register descriptions provide the register name, Type, Data Range, Read or Write information, Initialized Value, and a description of the function.

Key

The registers in this section provide module information such as firmware revisions, capabilities and unique serial number information.

The registers in this section provide module temperature measurement information.