ICSS HSR PRP Developer Guide

About this Guide

This is the companion developer guide for the HSR PRP application on TI-RTOS SYSBIOS. See the User Guide for the component here and release notes here

There is also a RT-Linux implementation for HSR-PRP, both implementations use the same firmware and basic design and differ only in OS related aspects like driver design etc. The RT-Linux implementation is offered as part of the Processor SDK Linux package from TI. See the developer guide for the TI-RTOS here

A lot of material is common to both the developer guides and will be cross-referenced.

Recommended Reading

Before reading this developers should review the following wikis if they haven't already. Most of the material will be cross-referenced and will not be repeated.

1. ICSS EMAC LLD Design : This discusses the firmware and driver architecture in detail. This wiki will reference it often.
2. Industrial SDK Getting Started Guide : Introduction to Industrial SDK and how to run the examples
3. PTP/1588 Developer Guide : PTP/1588 Developer guide

This wiki is provided to help developers use the HSR/PRP DAN application, provide general information on the architecture and adapt it to their needs. HSR and PRP are actually two different redundancy protocols but are part of the same family of redundancy protocols. They are specified by the standard IEC 62439-3. TI's implementation adheres to Edition 2 of the standard.

The application implements a DAN or Dual Attached Node as per HSR/PRP terminology. A HSR DAN is called a DANH and a PRP DAN is called DANP.

Most of HSR/PRP is about implementing what's known as an LRE or Link Redundancy Entity. An LRE provides a transparent view to the upper TCP/IP layer when it comes to transmission and reception of packets. Basically an LRE manages duplicates. On the transmit side it involves duplicating frames sent by upper layers on the two ports and on receive side it means detecting and eliminating duplicates and forwarding only a single copy to upper layers. A detailed discussion of HSR and PRP protocols is beyond the scope of this guide as such only a basic introduction is provided.

PTP-1588 is provided only with HSR at present and complies to Ed 2.0 specs which require HSR Tag compliance for non link local PTP frames. PTP-1588 is discussed in a separate PTP Developer guide.

Glossary of terms

Glossary of HSR/PRP terms

Terms	Abbreviation
HSR	High-Availability Seamless Redundancy
PRP	Parallel Redundancy Protocol
LRE	Link Redundancy Entity
TS	Timestamp
DAN	Dual Attached Node
DANH	HSR Dual Attached Node
DANP	PRP Dual Attached Node
RCT	Redundancy Control Trailer
BC/MC/UC	Broadcast/Multicast/Unicast

About HSR/PRP on PRU-ICSS

The HSR/PRP driver and firmware implements a LRE which provides a transparent view to the upper layers and implements redundancy. Most of the LRE implementation is largely encapsulated inside the firmware which performs tasks like

• Duplicate detection and elimination
  • Port to Host
  • Port to Port
• Node Table management (for other devices on the network)

The driver performs the task of duplicating a packet and sending it out on both ports. It also performs the task of node table, port-port and port-host duplicate table management.

The LRE replaces EMAC LLD Rx and Tx API's with identical API's providing the redundancy.

Features & Capabilities

• Enhance ICSS cut-through switch with HSR capability
• HSR End Node (DANH) complying to IEC62439-3 Edition 2 Clause 5
• PRP End Node (DANP) complying to IEC6239-3 Edition 2 Clause 4
• 100 Mbits/s Full Duplex Ethernet Interface
• Cut-through
• Store & forward with data integrity check
• Support for HSR Modes H;N,T,U,M
• PTP-1588 support
  • P2P mode
  • Ordinary and Transparent Clock support
  • Both Master and Slave supported
• Configurable node table size
  • Upto 256 entries
  • Firmware can be extended to support 512 entries on AM57x
• QoS based on 8-bit VLAN PCP field. The 8 levels are mapped to 4 different queues
• Support all statistics MIB variables defined in the Standard
• Node table enhanced with traffic capture (statistics) for all frames received by the host.

Design

The HSR/PRP basic design is common to BIOS and RT-Linux implementations, it's covered here

Memory Map

Memory map is described here

Porting Guide

This section lists out the resource usage by HSR/PRP Driver/application and steps required to port the implementation to another Operating system, TCP/IP stack

Interrupts

HSR/PRP does not use any additional interrupts other than those used by EMAC-LLD. Description provided here. PTP/1588 implementation which is implemented on top of HSR/PRP has it's own PRUSS-INTC interrupt usage. Those are listed in the PTP developer guide here

Callbacks from EMAC-LLD

Because of it's design HSR/PRP uses it's own Rx and Tx wrappers which encapsulate Receive and Transmit tasks.

This is done using callbacks.

Callbacks

• Rx non RT Callback : RedRxPktGet(ICSSEMAC_rxArgument *rxArg, void *userArg). The callback is registered with EMAC-LLD through the following

((((ICSSEMAC_Object *)emachandle->object)->callBackHandle)->rxCallBack)->callBack = (ICSS_EmacCallBack)RedRxPktGet

The callback handles the HSR header and PRP trailer present it in the message and removes it for the upper layers, presenting a transparent interface.

• Tx Callback : RedTxPacket(ICSSEMAC_txArgument *txArg, void *userArg)

((((ICSSEMAC_Object *)emachandle->object)->callBackHandle)->txCallBack)->callBack = (ICSS_EmacCallBack)RedTxPacket

The callback inserts the redundancy tags in the frame, duplicates packets on both ports and attempts to send them out at the same time.

• Rx RT callback : processHighPrioPackets(uint32_t *queue_number, void *userArg). This callback is implemented in the application itself as an example. Registration is done through

((((ICSSEMAC_Object *)emachandle->object)->callBackHandle)->rxRTCallBack)->callBack = (ICSS_EmacCallBack)processHighPrioPackets

Tasks

HSR/PRP uses one task to prepare and then send Supervision frames periodically.

• RedLifeCheckTask() : Check for Link up, prepare a supervision frame and then send them periodically. This is done by waiting on a semaphore redLifeCheckSemaphore which is in turn posted by a Timer.

The task initialization is done inside RedLifeCheckTaskCreate()

Semaphore

The HSR/PRP driver uses a semaphore redLifeCheckSemaphore to gate the sending of Supervision frames. A timer interrupt upon expiry posts the semaphore thus enabling periodic transmission of Supervision frames.

• redLifeCheckSemaphore : Semaphore created in RedLifeCheckTaskCreate()

Timers

HSR/PRP uses two generic timers from BIOS

• redPruCheckTimer : This timer is used to periodically check and clear bits in Firmware implementation. ISR is RedPruCheckTimerHandler(). Period is specified by RED_PRU_CHECK_TIMER_PERIOD (in milliseconds)

• redLifeCheckTimer : This timer is used to send supervision frames periodically. ISR is RedLifeCheckTimerHandler() where it posts a semaphore redLifeCheckSemaphore to indicate to a waiting task to send supervision frames. Period is specified by RED_LIFE_CHECK_TIMER_PERIOD (in milliseconds)