Communication stack

Cyclic Data Exchange


The communication with the iRJ45 module/ SoM uses the Serial Peripheral Interface (SPI) or with the Firmware Version 2.2.0.0 the Universal Asynchronous Receiver / Transmitter Protocol (UART).

A cyclic transfer must always be triggered by the application core (AC) and must at least be once during the heartbeat timeout. The implementation in the iRJ45/ SoM updates the cyclic data after each transfer to make sure it doesn't interrupt a running transfer.

Clock domains and communication cycle



Figure 1 ctc clock domains

Operation of the device includes two clock domains, which run independently of each other. First clock domain is the fieldbus side. Commonly the PLC interacts with the device in one clock domain, where the PLC controls the timing of the output data. Second clock domain is driven by the AC through initiation of the ctc-cycle, which reads the output data from the device and updates input data for the next fieldbus cycle. Therefore, a specific timing of the process data is set up as shown in Figure 2 Communication Cycle.

Following data transports occur:

  1. New output data from PLC

  2. Processing of output data in CC module and preloading of cyclic transfer buffer

  3. A finished cyclic transfer initiated by the AC executes data exchange between AC and CC

  4. Preloading of new input data for the next cyclic transfer

  5. A finished sequential cyclic transfer executes data exchange between AC and CC, thus providing new input data for the next fieldbus transfer


Figure 2 Communication Cycle

Technical data

 

  • Transfer length:

    • Cyclic only: 72 Bytes

    • Cyclic + RPC data: 128 Bytes

  • Baud-rate:

    • at SPI: max. 10 Mbps, usually 2 Mbps.

    • at UART: max. 921600 baud/s.

  • Delay between cyclic transfer:

    • SPI: 0.5 ms... Heartbeat Timeout (1 second)

    • UART: 2 ms… Heartbeat Timeout (1 second)

  • Minimal round-trip time: 4 ... 6 ms (depending on the used protocol and setup)

SPI Timing


Following simplified diagram shows basic SPI timing which must be considered by the application controller.


Figure 3 Basic SPI timing

SPI Speed


The communication module supports SPI speed in the range of 29.3 kHz and 10MHz. Default SPI speed is 2MHz.

SPI Setup Time


In Figure 3 Basic SPI timing, the communication scheme between AC and CC is shown. Following time needs to be considered by the Application Controller during communication: the SPI Setup Time - the time between activation of the module using the Slave Select signal and first data - must at least be 10ns, before the module accepts data over SPI.

SPI Cycle Time


This time is the distance between two consecutive SPI transfers. Between two transfers a minimum time of 250 us must be kept to secure proper processing in the module.

Cyclic Frame Structure


The cyclic frame must contain the structure from Table 18: Frame Structure to get accepted by the iRJ45 module/ SoM.

Bytes
0..1

Byte
2

Byte
3

Bytes
4 .. 76

Bytes
77 .. 127

Fletcher-16
Checksum with
Offset 0x0007
(little endian)

Sequence

Data Length

Cyclic Data

RPC Data

Table 18 Frame Structure

The same layout is send back by the device containing its local sequence counter. The sequence counter is tracked and if it doesn't change during the heartbeat timeout the communication gets stopped until the sequence is updated again.

Fletcher-16 Checksum (16 Bit)


To calculate the Fletcher-16 checksum this Wikipedia entry can be used. Start index is byte 4 and end is at 127. After the calculation the value 0x0007 needs to be added to not have false positives if the whole area is set to zeros. In the frame the value has a width of 16 bit and needs to have the little endian encoding.

Sequence Counter (8 Bit)


The sequence counter must be incremented on each sent out frame to be recognized as new data. It can start at any 8 bit value.

Data Length (8 Bit)


If only cyclic data is transferred the data length can be set from 0 to 73 bytes. When using RPC the data length needs to have a fixed value of 124.

Remote Procedure Call


The RPC protocol used by the Micro Core-To-Core (MCTC) implementation of the iRJ45 module is transferred in byte 77 – 127. RPC transfers are always acknowledged to minimize data loss on erroneous transfers as good as possible. Also the RPC calls can be larger than the available 50 bytes as the iRJ45 module internally stores each received RPC frame in a ring-buffer and waits until a partitioned transfer is completed before proceeding with the request.

RPC Frame Structure


The RPC frame must contain the structure from Table 19: RPC Frame Structure to be accepted by the iRJ45 module.

Bytes
0..1

Byte
2

Byte
3

Byte
4

Byte
5

Bytes
6 .. 49

Fletcher-16
Checksum with
Offset 0x0007
(little endian)

Local
Sequence

Remote
Sequence
Acknowledge

Data
Length

Flags

Data

Table 19 RPC Frame Structure

Each time a new local sequence is sent the iRJ45 will respond with the corresponding acknowledge in the second transferred frame. If no acknowledge was received the AC can retransmit its frame to re-request the acknowledge.

Fletcher-16 Checksum (16 Bit)


To calculate the Fletcher-16 checksum this Wikipedia entry can be used. Start index is byte 6 and end is at the included data length. After the calculation the value 0x0007 needs to be added to not have false positives if the whole area is set to zeros. In the frame the value has a width of 16 bit and needs to have the little endian encoding.

Local Sequence (8 Bit)


The sequence counter must be incremented for each RPC frame with changed data. For each unseen incremental frame the iRJ45 module will put the transferred data into its internal ring-buffer and after the length matches it will process the RPC call.

Remote Sequence Acknowledge (8 Bit)


For each processed received RPC frame the AC needs to send out an acknowledge. If the received frame doesn't match the expected sequence the AC must leave the acknowledge on the previous sequence to trigger a resend from the iRJ45 module. If the resend fails the AC can also perform a re-sync.

Data Length (8 Bit)


Contains the length of the RPC data and must be between 0 (acknowledge-only frame) and 44.

Flags (8 Bit)

 

Bit
0

Bit
1

Bit
2

Bit
3

Sync Request

Sync Acknowledge

Reserved

Request Acknowledge

Table 20 RPC Header Flags

Sync Request


If set to 1 the iRJ45 module enters the RPC synchronization.

Sync Acknowledge


During the Sync Request both sides need to set the Sync Acknowledge flag, see RPC Synchronization for details.

Request Acknowledge


Forces an acknowledge from the partner device.

RPC Synchronization


Before the iRJ45 module is ready to operate and after a synchronization is lost the RPC must be synchronized. This is triggered by setting the Sync Request flag to 1.

AC

iRJ45 Module

Sync Request = 1
Local Sequence = 0
Local Sequence Acknowledge = 0
Remote Sequence Acknowledge = 0





Sync Request = 1
Local Sequence = 0
Local Sequence Acknowledge = 0
Remote Sequence Acknowledge = 0

Sync Request = 0
Sync Acknowledge = 1
Local Sequence = 1
RPC_Send(<empty>)





RPC_Receive()
→ Remote Sequence Acknowledge = 1

Sync Request = 0
Sync Acknowledge = 1
Local Sequence = 1
RPC_Send(<empty>)

RPC_Receive()
→ Local Sequence Acknowledge = 1
→ Remote Sequence Acknowledge = 1

Sync Acknowledge = 0

RPC_Start()





RPC_Receive()
→ Local Sequence Acknowledge = 1

RPC_Start()

Table 21 RPC Synchronization

After the synchronization has finished the iRJ45 both devices must initiate the generic RPC call SetupStateGet to verify if the partner device is in the same state. If one partner is already configured but the other is not, than the configured parter must reboot and the synchronization starts again.

Normal Operation


If the AC successfully passed the synchronization stage and configured the iRJ45 module it must call the RPC API SetupDone. At this point the iRJ45 module is ready for normal operation.

RPC Protocol


The GOAL RPC protocol uses a virtual push/pop stack to call remote API functions with arguments. Each call must have a return value that is usually set to GOAL_OK when the call succeeded.

RPC Request/Response Structure


An RPC request/response consists of the parts shown in Table 21 and Table 22.

Byte 0..1

Byte 2..5

Byte 6 .. x

Byte x+1 .. x+4

Byte x+5..x+8

Byte x+9

Byte x+10

Byte (x+11) .. (x+14)

Static Identifier
0xaa, 0xee

Data Length
fromByte 6 to Flags (included)

Data

Function Id
(little endian)

RPC Id(little endian)

CTC Id

Flags

Fletcher-16
Checksum with
Offset 0x0007
(little endian)

Table 22 RPC Request Structure

Byte 0..1

Byte 2..5

Byte 6 .. x

Byte x+1

Byte x+2

Byte (x+3)..(x+4)

Static Identifier
0xaa, 0xee

Data Length
fromByte 6 to Flags (included)

Response Data

CTC Id

Flags

Fletcher-16
Checksum with
Offset 0x0007
(little endian)

Table 23 RPC Response Structure

Static Identifier


The 2 byte static identifier is used on the iRJ45 module to detect the start of a new RPC request or response. If the identifier is also contained in the data bytes the Fletcher-16 checksum will make sure that it don't gets threaded like an RPC request/response.

Data Length


The data length contains the count of bytes starting with the "Function Id" and ending with the last data byte.

RPC Id


The RPC id is the module or group id. For example GOAL PROFINET uses the RPC id GOAL_ID_PNIO to register its calls.

Function Id


The function id is used as a sub id to map the function calls in the specific module to their handlers.

CTC Id


The CTC id is used to match requests and responses to their specific MCTC internal handle. A response must use the same CTC id as the request.

Flags


The flags define the type of the request, see Table 5: RPC Request/Response Flags for details.

Bit 0..1

0 – Response1 – Request
2 – Info (Request without waiting for a response)

Table 24 RPC Request/Response Flags

Data


The data part contains the virtual stack of the RPC request/response.

Fletcher-16 Checksum (16 Bit)


To calculate the Fletcher-16 checksum the Wikipedia entry can be used. Start index is byte 16 and end is at the included data length. After the calculation the value 0x0007 needs to be added to not have false positives if the whole area is set to zeros. In the frame the value has a width of 16 bit and needs to have the little endian encoding.

GOAL PROFINET Data Mapper API


The GOAL PROFINET Data Mapper API allows to map PROFINET subslots, producer & consumer states and the connection information to the cyclic data stream of the Data Mapper that is used for example in MCTC transfers.

Map Subslot Data – goal_pnioDmSubslotAdd


The API goal_pnioDmSubslotAdd maps input and output data of the given subslot to the also given instances of the DM.

Parameter

Description

GOAL_PNIO_T *pPnio

GOAL PROFINET instance

uint32_t idMiDmPeerFrom

Handle that receives data from CC

uint32_t idMiDmPeerTo

Handle that sends data to CC

GOAL_MI_DM_PART_T **ppPartDataOut

Output pointer to store the DM partition

GOAL_MI_DM_PART_T **ppPartDataIn

Output pointer to store the DM partition

uint32_t idApi

API id

uint16_t idSlot

Slot id

uint16_t idSubslot

Subslot id

uint32_t lenDataOut

Output data length

uint32_t lenDataIn

Input data length

Table 25 goal_pnioDmSubslotAdd API Description

Map Subslot IOCS/IOPS - goal_pnioDmSubslotIoxsAdd


The API goal_pnioDmSubslotIoxsAdd maps IOCS and IOPS states of the given subslot to the given instances of the DM.

Parameter

Description

GOAL_PNIO_T *pPnio

GOAL PROFINET instance

uint32_t idMiDmPeerFrom

Handle that receives data from CC

uint32_t idMiDmPeerTo

Handle that sends data to CC

GOAL_MI_DM_PART_T **ppPartIocsOut

Output pointer to store the DM partition

GOAL_MI_DM_PART_T **ppPartIopsOut

Output pointer to store the DM partition

GOAL_MI_DM_PART_T **ppPartIocsIn

Output pointer to store the DM partition

GOAL_MI_DM_PART_T **ppPartIopsIn

Output pointer to store the DM partition

uint32_t idApi

API id

uint16_t idSlot

Slot id

uint16_t idSubslot

Subslot id

Table 26 : goal_pnioDmSubslotIoxsAdd API Description

Map APDU Status – goal_pnioDmApduAdd


The API goal_pnioDmApduAdd maps the APDU status to the given instance of the DM.

Parameter

Description

GOAL_PNIO_T *pPnio

GOAL PROFINET instance

uint32_t idMiDmPeerTo

(ignored) Handle that sends data to CC

GOAL_MI_DM_PART_T **ppPartApduOut

Output pointer to store the DM partition

Table 27 goal_pnioDmApduAdd API Description

Map Data Provider Status – goal_pnioDmDpAdd


The API goal_pnioDmDpAdd maps the Data Provider status to the given instance of the DM.

Parameter

Description

GOAL_PNIO_T *pPnio

GOAL PROFINET instance

uint32_t idMiDmPeerTo

(ignored) Handle that sends data to CC

GOAL_MI_DM_PART_T **ppPartDp

Output pointer to store the DM partition

Table 28 goal_pnioDmApduAdd API Description