Introduction

DLR stands for Device Level Ring. It is a Layer 2 redundancy protocol which is independent of CIP. It relies on circulation of periodic frames through the network called Beacons or Announce frames to monitor the health of the network, a variety of other frames are used to find out where the fault is and which devices participate in the network. The basic information regarding DLR is summarized below.

DLR network consists of:

DLR Supervisor : A supervisor is responsible for sending out periodic frames called Beacons or Announce frames at regular intervals to monitor the network for faults. A controller or PLC is typically the DLR supervisor. The main job of a DLR supervisor is to detect transition from ring to linear topology and open one of it's ports for communication which is usually closed in a ring configuration to prevent a loop.
DLR Node : A DLR Node forwards beacon/announce frames from one port to other without any modification, it also checks for continuous reception of DLR frames and if any is missed it reports the status to supervisor. The EIP Adapter application is a DLR Node. All DLR frames contain the protocol identifier 0x80E1 (comes immediately after destination MAC) which is how the firmware identifies the protocol. Once frame type is identified as DLR, the flow changes from normal frame to one for DLR processing.

Frame Types

Beacon : Is the most common frame type and used to monitor ring health. It is sent out periodically on both the ports by the Supervisor based on the ring parameter beaconInterval. The lowest possible value for this is 100us. The beacons are transmitted simultaneously from both ports and reach the opposite ports of same device after traversing the entire network, this is how the supervisor confirms that ring is functional. Failure to observe a beacon within a specified interval called beaconTimeout triggers a state change to Fault. This type of frame is cut-through.
Announce : Analogous to Beacon but much slower, this is for legacy networks. EIP Adapter does not support this mode. All Announce frames get cut-through.
Sign On : This contains information about every node on the network. This is sent on one port by the Supervisor and gets trapped by every node on the network, the devices then add their own information and send it over the other port. These frames are sent to the Host over Host queues, the Host adds it's own information and then transmits it over the other port.
Locate Fault : This is a frame sent by the Supervisor in response to a missed beacon or any other fault event. All devices are supposed to report their neighbor status on receiving this frame. EIP Adapter cuts-through this frame and generates Neighbor Check Requests for neighboring devices.
Neighbor Check Request : This is a frame that is generated by every node including the supervisor in response to a fault generating event on the network. A device is supposed to consume this frame and generate a neighbor check request. Our application forwards this frame to Host for a response. A device generates 3 such frames on each port at intervals of 100ms and if no response is received then a status is reported to Supervisor that corresponding port has an issue.
Neighbor Check Response : A device is supposed to consume this frame. If this frame isn't received after 3 requests then a neighbor status frame is sent indicating the port on which device is faulty. This frame is not forwarded.
Link Status/Neighbor Status : This is sent by a device to supervisor to indicate a link break or an issue with adjacent device. This frame is cut-through.

Timers

DLR uses lots of timers because it has to keep track of when every beacon arrives and whether there has been a timeout, there's also a timeout related to neighbor check response. The lowest beacon interval according to the standard (and what the application supports) is 100us and with a minimum 2x timeout interval the minimum value for timeout comes to 200us. Thus the minimum resolution for a DLR Beacon timeout timer should be 200us. This is possible with ICSS Watchdog Timers.

The WD Timer ISR is configured to get triggered on expiry of the count. Every time a beacon is received in firmware the timer is restarted and this prevents the ISR from getting hit. In case the

The current firmware implementation uses the watchdog timers IEP_PD_WD and IEP_PDI_WD. The watchdog clock divider is set to 10us in the PRU-ICSS register PRUSS_IEP_WD_PREDIV so the granularity supported today is 10us. This means that, a value of 405 us cannot be configured as timeout value, it can either be 400 us or 410 us.

For the Neighbor Check Response timers we use software timers since the requirement is not very stringent.

The timers with their default values are configured in the DLR initialization API EIP_DLR_init. The beacon timeout timers are configured with network parameters received from the master when the first beacon is received.

Interrupts

There are mainly 4 different types of interrupts when it comes to DLR. They are explained as follows.

Interrupts related to timers: When the various timers expire, they trigger an ISR. There are 4 timer related ISRs.
- EIP_DLR_beaconTimeoutISR_P0 : This is the ISR for beacon timer expiry on Port 0
- EIP_DLR_beaconTimeoutISR_P1 : This is the ISR for beacon timer expiry on Port 1
- EIP_DLR_neighborTimeoutISR0 : This is the ISR for neighbor check request timer expiry on Port 0
- EIP_DLR_neighborTimeoutISR1 : This is the ISR for neighbor check request timer expiry on Port 1
Interrupts related to link breaks: Certain DLR events need to be processed when a link break occurs. A DLR callback is registered for the link ISR which is specific to this. There is one callback per port, which are identical and only differ in terms of which port they belong to.
- EIP_DLR_port0ProcessLinkBrk : Link change callback API for Port 0
- EIP_DLR_port1ProcessLinkBrk : Link change callback API for Port 1
Interrupts related to link breaks: Certain DLR events need to be processed when a link break occurs. A DLR callback is registered for the link ISR which is specific to this. There is one callback per port, which are identical and only differ in terms of which port they belong to.
- EIP_DLR_port0ProcessLinkBrk : Link change callback API for Port 0
- EIP_DLR_port1ProcessLinkBrk : Link change callback API for Port 1
Interrupts realted to state change processing: DLR mostly uses a fast ISR scheme for communicating with the host where firmware parses the fields, copies the data to preset locations and triggers an interrupt for the ARM. There is one ISR for each port. The acceptable latency of the ISR is determined by the beacon interval. If running at minimum level i.e. 100us, the ISR must be triggered and completed within that time.
- EIP_DLR_port0ISR : Fast ISR to process Port 0 DLR events
- EIP_DLR_port1ISR : Fast ISR to process Port 1 DLR events
Interrupt related to ICSS-EMAC Rx interrupt which uses the Host queues: Some DLR packets (mainly Sign-On and Neighbor Check Request) need to be processed by the Host and as per the spec are sent to the highest priority queue. They are handled by a DLR specific callback.
- EIP_DLR_processDLRFrame : DLR frame processing callback API programmed as RT-callback in ICSS_EMAC

DLR State Machine and Actions

Node State

The information related to the node state is stored in the ICSS Shared RAM at the location pointed by the DLR_STATE_MACHINE_OFFSET. A DLR Ring has three states (two as per standard).

No DLR : This is the state right after boot up and in the absence of any DLR frames. It's not an official classification, at this stage the beacon timeout timers are configured with default values and all flags are in a reset state. Corresponds to DLR_IDLE_STATE_VAL.
Fault : When the first beacon is received this is the state of state machine. A field in the DLR frame corresponds to this and is set by the Supervisor. When a supervisor receives two beacon frames that have traversed the entire network and reached opposing ports it changes this state to Normal. A fault state also occurs when a collision is detected or network is reset. When the first DLR beacon is received and the state machine is in reset state the DLR beacon timeout interval is copied and the DLR timeout timer is configured with the value in the Fast ISR. Corresponds to the value DLR_FAULT_STATE_VAL.
Normal : Indicates that ring is up and functional. This corresponds to the value DLR_NORMAL_STATE_VAL.

Common Events

There are various important events that are common to both the ports and are stored in the ICSS Shared RAM at the DLR_COMMON_EVENTS_OFFSET offset. The different common events are as follows:

DLR_RING_NORMAL_TRANSITION : The Node has transitioned from Fault to Normal; perform appropriate actions.
DLR_RING_FAULT_TRANSITION : The Node has transitioned from Idle to Fault; perform appropriate actions and configure the timers.
DLR_STOP_BOTH_TIMERS : Stop both beacon timeout timers.
DLR_PORT0_BEACON_RCVD : This denotes if a beacon has been received on Port 0
DLR_PORT1_BEACON_RCVD : This denotes if a beacon has been received on Port 1
DLR_RESET_EVENT_OCCURED : Reset the DLR state machine

Port Events

Some events are symmetric but unique to each port. These are stored in the ICSS DMEM_0 and DMEM_1 for Port 0 and Port 1 at the DLR_PORT_EVENTS_OFFSET. The various port events are as follows.

DLR_LOCFAULT_RCVD : Locate Fault Packet received on the current port.
DLR_NCREQ_RCVD : Neighbor Check request packet received on the current port.
DLR_NCRES_RCVD : Neighbor Check response packet received on the current port.
DLR_START_TIMER : Start the beacon timeout timer corresponding to the current port.
DLR_RING_FAULT_RCVD : Beacon received with ring status set to fault on the current port. Transition the node to fault state.
DLR_UPDATE_SUP_CFG : Supervisor has changed, update the supervisor parameters.
DLR_TIMER_RUNNING : When beacon timeout timer is running and has not expired on the current port.
DLR_SEND_LEARNING_UPDATE : Send learning update frame.
DLR_FLUSH_TABLE_RCVD : Flush table packet received on the current port. Flush learning table
IS_A_DLR_FRAME : Internal to firmware implementation
COMPARE_SUP_PRED : Internal to firmware implementation
UPDATE_NEW_SUP_CFG : Internal to firmware implementation
DLR_DROP_PACKET : Internal to firmware implementation
DLR_HOST_FWD : Internal to firmware implementation

QoS

All the DLR frames are sent to the host in the highest priority queue. EIP_DLR_processDLRFrame is the callback API that handles the different DLR frames recieved by the application in the highest priority queue.

Interface

All DLR information relevant to the EIP stack is stored in the structure dlrStruct which maps directly to the DLR Object (0x47) as defined in the standard. The attribute IDs refer to the corresponding IDs for the DLR Object.

The macro "IS_A_DLR_SUPERVISOR" has been kept for future use and cannot be enabled right now.

The structure is used as a global in "icss_dlr.c". A third party stack can declare this as an extern to access the member variables.

/**
* \brief DLR parent structure through which all other structures can be accessed
*/
typedef struct
{
    /**Supervisor config. Attribute ID 4*/
    superConfig supConfig;
    /**Supervisor address. Attribute ID 10*/
    activeSuperAddr addr;
    /**State Machine variables. Attributes 1 through 3*/
    dlrStateMachineVar SMVariables;
 
#ifdef IS_A_DLR_SUPERVISOR
    /**Attribute ID's 6 and 7*/
    lastActiveNode activeNode[2];
#endif
    /**DLR Capabilities, flag
    The Map is as follows
    * 0 : Announce Based Ring Node
    * 1 : Beacon based Ring Node
    * 2-4 : Reserved
    * 5 : Supervisor capable
    * 6 : Redundant capable
    * 7 : Flush Table frame capable
    * 8-31 : Reserved
    */
    /**DLR Capabilities of the device. Attribute ID 12*/
    uint32_t dlrCapabilities;
 
    /**Active Supervisor precedence. Attribute ID 11*/
    uint8_t activeSuperPred;
 
    HwiP_Object port0IntObject;
    HwiP_Object port1IntObject;
    HwiP_Object beaconTimeoutIntP0Object;
    HwiP_Object beaconTimeoutIntP1Object;
 
    /**DLR Port 0 Interrupt number for ARM*/
    uint8_t port0IntNum;
 
    /**DLR Port 1 Interrupt number for ARM*/
    uint8_t port1IntNum;
 
    /**DLR interrupt for beacon timeout for Port 0*/
    uint8_t beaconTimeoutIntNum_P0;
 
    /**DLR interrupt for beacon timeout for Port 1*/
    uint8_t beaconTimeoutIntNum_P1;
 
#ifdef IS_A_DLR_SUPERVISOR
    /**Number of Ring Faults since power up. Attribute ID 5*/
    uint32_t numRingFaultsPowerUp;
 
    /**Number of ring participants. Attribute ID 8*/
    uint16_t ringParticipantsCount;
 
    /**pointer to array of structures. Attribute ID 9*/
    protocolParticipants **ringNodes;
#endif
 
} dlrStruct;

Initialization

DLR is initialized using the API EIP_DLR_init and started with the API call EIP_DLR_start. A call to the API EIP_DLR_stop disables the DLR feature in the firmware. Initialization needs to be done only on startup. DLR can be enabled and disabled at runtime.

The IP address for DLR node is configured through the API EIP_DLR_addModuleIPAddress. There is a need to call this API once an IP address has been acquired or else DLR frames will not carry an IP address.

Table of Contents