0% found this document useful (0 votes)

93 views154 pages

Netx Dual-Port Memory Interface DPM 17 EN

Uploaded by

a.ansarain101

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

93 views154 pages

Netx Dual-Port Memory Interface DPM 17 EN

Uploaded by

a.ansarain101

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 154

Dual-Port Memory Interface Manual

netX Dual-Port Memory Interface

Hilscher Gesellchaft für Systemautomation mbH

Table of content
1 Introduction............................................................................................................................................. 4
1.1 About this Document ...................................................................................................................... 4
1.2 List of revisions .............................................................................................................................. 4
1.3 Considerations / Prerequisites and Limitations .............................................................................. 5
1.4 Terms, abbreviations and definitions ............................................................................................. 7
1.5 References to documents .............................................................................................................. 8
1.6 Information and data security ......................................................................................................... 8
2 Dual-Port Memory Structure ................................................................................................................. 9
2.1 Block Diagram of the default Dual-Port Memory ......................................................................... 11
2.2 Dual-port memory layout and sizes ............................................................................................. 12
2.2.1 Variable Layout ............................................................................................................................... 13
2.3 Channel Definitions ...................................................................................................................... 14
2.3.1 System Channel .............................................................................................................................. 14
2.3.2 Handshake Channel ........................................................................................................................ 15
2.3.3 Communication Channel ................................................................................................................. 16
2.3.4 Application Channel ........................................................................................................................ 17
2.4 Data Block Definitions .................................................................................................................. 18
2.4.1 System Information Block ................................................................................................................ 18
2.4.2 Channel Information Block .............................................................................................................. 18
2.4.3 System Control Block ...................................................................................................................... 18
2.4.4 System Status Block ....................................................................................................................... 18
2.4.5 Common Control Block.................................................................................................................... 19
2.4.6 Common Status Block ..................................................................................................................... 19
2.4.7 Extended Status Block .................................................................................................................... 19
2.4.8 Mailbox System ............................................................................................................................... 19
2.4.9 I/O Data Areas ................................................................................................................................. 20
2.5 netX Chip Register Block ............................................................................................................. 20
3 Data access and synchronization ...................................................................................................... 21
3.1 Handshake Flag naming convention............................................................................................ 22
3.2 System Channel - Handshake Register and Flags ...................................................................... 23
3.3 Communication Channel - Handshake Register and Flags ......................................................... 27
3.4 Synchronization - Handshake Register and Flags ....................................................................... 31
4 Data Transfer Mechanism.................................................................................................................... 34
4.1 Non-Cyclic Data Transfer via Mailbox and Packets ..................................................................... 35
4.1.1 Packet structure .............................................................................................................................. 37
4.1.2 Default Packet Handling .................................................................................................................. 40
4.1.3 Packet Addressing via ulDest ....................................................................................................... 41
4.1.4 Using ulSrc and ulSrcId ................................................................................................................... 43
4.1.5 Client/Server Mechanism ................................................................................................................ 44
4.1.6 Packet Fragmentation ..................................................................................................................... 45
4.1.7 Packet transfer synchronization ...................................................................................................... 46
4.2 Cyclic Data Transfer via Input/Output Data Areas ....................................................................... 49
4.2.1 I/O Data Exchange Modes .............................................................................................................. 50
4.2.1.1 Buffered Host Controlled Mode ...................................................................................... 52
4.2.1.2 Buffered Device Controlled Mode ................................................................................... 54
4.2.2 I/O Data Area Access Synchronization............................................................................................ 56
4.2.2.1 Synchronization in Buffered Host Controlled Mode ........................................................ 57
4.2.2.2 Synchronization in Buffered Device Controlled Mode..................................................... 59
4.3 Change of State Mechanism (COS) ............................................................................................ 60
4.3.1 Communication COS Handling ........................................................................................................ 61
4.3.2 Application COS Handling ............................................................................................................... 62
4.3.3 Enable Flag Handling ...................................................................................................................... 63
5 DPM Definitions / Mapping and Content ............................................................................................ 65
5.1 DPM Mapping .............................................................................................................................. 65
5.2 System Channel ........................................................................................................................... 68
5.2.1 System Information Block ................................................................................................................ 69
5.2.2 Channel Information Block .............................................................................................................. 80
5.2.3 System Handshake Block................................................................................................................ 87
5.2.4 System Control Block ...................................................................................................................... 88

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

DOC060302DPM17EN | Revision 17 | English | 2020-06 | Released | Public © Hilscher, 2006– 2020
Introduction 3/154
5.2.5 System Status Block ....................................................................................................................... 90
5.2.6 System Mailbox ............................................................................................................................... 94
5.3 Handshake Channel..................................................................................................................... 95
5.4 Communication Channel .............................................................................................................. 97
5.4.1 Channel Handshake Block .............................................................................................................. 99
5.4.2 Common Control Block.................................................................................................................. 100
5.4.3 Common Status Block ................................................................................................................... 102
5.4.3.1 Master State Information .............................................................................................. 109
5.4.4 Extended Status Block .................................................................................................................. 111
5.4.5 Channel Mailbox ............................................................................................................................ 117
5.4.6 High Priority Input/Output Data Image ........................................................................................... 118
5.4.7 Reserved Area .............................................................................................................................. 118
5.4.8 Input / Output Process Data Image ............................................................................................... 119
5.5 Application Channel ...................................................................................................................119
6 System Behavior and Services .........................................................................................................120
6.1 Timing Considerations ...............................................................................................................120
6.2 netX Boot Procedure ..................................................................................................................121
6.3 Hardware LEDs ..........................................................................................................................122
6.3.1 System LED .................................................................................................................................. 122
6.3.2 Communication Channel LEDs ..................................................................................................... 122
6.4 Reset Handling ...........................................................................................................................123
6.4.1 Hardware Reset ............................................................................................................................ 124
6.4.2 System Reset ................................................................................................................................ 124
6.4.3 Boot Start ...................................................................................................................................... 125
6.4.4 Update Start .................................................................................................................................. 125
6.5 Communication Channel Services .............................................................................................126
6.5.1 Channel Initialization ..................................................................................................................... 126
6.5.2 Start / Stop Communication........................................................................................................... 129
6.5.3 Lock / Unlock Configuration........................................................................................................... 130
6.5.4 Channel Watchdog ........................................................................................................................ 131
6.6 Packet Services .........................................................................................................................132
7 Error codes .........................................................................................................................................133
7.1 Second Stage Bootloader Errors ...............................................................................................134
7.2 netX System Errors (System).....................................................................................................135
7.3 netX System Errors (General) ....................................................................................................136
7.4 Protocol Stack Errors .................................................................................................................145
8 Appendix .............................................................................................................................................146
8.1 List of figures ..............................................................................................................................146
8.2 List of tables ...............................................................................................................................146
8.3 Legal notes .................................................................................................................................148
9 Glossary ..............................................................................................................................................152
10 Contact ................................................................................................................................................154

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

1 Introduction
1.1 About this Document
This manual describes the user interface respectively the application programming interface of the
dual-port memory for netX-based products manufactured by Hilscher.
In a dual-processor system, the netX dual-port memory (DPM) is the interface between a host (e.g.
PC or microcontroller) and the netX chip. It is a shared memory area, which is accessible from the
netX side and the host side and it is used to exchange process and diagnostic data between both
systems.
The netX firmware determines the dual-port memory layout in size and content. It offers up to 8
memory areas or channels, which create the dual-port memory layout. The flexible memory
structure provides access to the netX chip with its integrated network/fieldbus controller.
The content of the individual memory channels depends on the type of the channel. System
channel and handshake channel using a fixed structure and location, while a communication
channel can provide some variable areas. The system channel can be used to obtain information
regarding type, offset and length of the variable areas.

1.2 List of revisions

Rev Date Name Revisions
15 2019-04-26 HHE, ALM Section Packet Fragmentation: Description moved to reference [1] and [3].
Document updated to new header files and definitions. Values are unchanged.
Section System Information Block: Ethernet TAP added to Table 50.
Section System Control Block: ulSystemControl field added.
Section System Status Block: HIL_SYS_STATUS_IDPM and
HIL_SYS_STATUS_APP added in Table 67 and Table 68.
Section System Information Block: Device classes 0x43, 0x44, and 0x45 and
added to Table 55.
Section Error codes updated.
16 2019-08-13 RMA Section System Control Block updated.
Section Common Status Block: Table 85 added.
Section Reset Handling expanded.
Section Update Start added.
17 2020-06-02 HHE Section System Information Block: Serial Number specified.
Section System Information Block: Device classes
HIL_HW_DEV_CLASS_NETFIELD_COM, HIL_HW_DEV_CLASS_COMX_52 added to
Table 55.
Table 1: List of revisions

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

1.3 Considerations / Prerequisites and Limitations

The dual-port memory (DPM) and the containing structures and definitions apply to Hilscher netX-
based products only. The dual-port memory documented here is not compatible to Hilscher AMD
or EC1-based products.
Whenever the term “netX firmware” / "protocol stack" is used throughout this manual, it refers to
ready-made firmware provided by Hilscher.
 Little Endian Data Representation
The netX CPU kernel is ARM based and uses the Little Endian data representation
(LSB/MSB, known as 'Intel format'), therefore all variables, parameters and data used in this
manual corresponding to this representation.
 C99-Standard-based data types
Data which are transferred between different CPU systems (host system / netX system)
needs to be fixed in sizes, therefore the C99 standard is used to define the following fixed
data types.
Data width Signed definition Unsigned definition
8 bit int8_t uint8_t
16 bit int16_t uint16_t
32 bit int32_t uint32_t
64 bit int64_t uint64_t
Table 2: Data types

Within the rcX operating system (for netX 10/50/51/52/100/500) alternative names for these
data types may be used.
Standard Types General Definition TLR Types
int8_t INT8 TLR_INT8
uint8_t UINT8 TLR_UINT8
int16_t INT16 TLR_INT16
uint16_t UINT16 TLR_UINT16
int32_t INT32 TLR_INT32
uint32_t UINT32 TLR_UINT32
int64_t INT64 TLR_INT64
uint64_t UINT64 TLR_UINT64
Table 3: Data types of the rcX operating systems

 Data Packing / Data Alignment

Most of the values in the DPM and the non-cyclic command packets are given as C data
structures. These C structures are partly byte packed (not always Natural Aligned) to safe
space in the DPM and the non-cyclic functions. If byte packing is not supported by the host
CPU or development environment, some of the structures are not usable and data has to be
processed manually to meet this specification and corresponding C structure cannot be used
is this case.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

 Additional Terms
The terms Host, Host System, Application, Host Application and Driver are used
interchangeably to identify an external process interfacing the netX via its dual-port memory
(DPM).
 Individual Implementations
A netX firmware or protocol stack may support only a subset of the structures and functions
described in this document.
 Host Controlled Mode
In Host Controlled Mode, the host application initially has access to the I/O data areas in the
DPM and can be the first to read and write data before starting a transfer between the netX
firmware and the DPM.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

1.4 Terms, abbreviations and definitions

Term Description
ACK Acknowledge
ASCII American Standard Code of Information Interchange
CMD Command
COS Change of State
DMA Direct Memory Access
DPM Dual-Port Memory
DRAM Dynamic Random Access Memory
EC1 80186 based Micro Controller
EEPROM Electrically Erasable Programmable Read Only Memory
FW Firmware
FIFO “First in, first out”, Storage Mechanism
GPIO General Purpose Input/Output Pins
HMI Human Machine Interface
Hz Hertz (1 per Second)
I²C Inter-Integrated Circuit
IO Input/Output Data
LED Light Emitting Diode
LSB Least Significant Bit or Byte
MBX Mailbox
MMC Multimedia Card
ms Milliseconds, 1/1000 Second
MSB Most Significant Bit or Byte
OS Operating System
PCI Peripheral Component Interconnect
PLC Programmable Logic Controller
PIO Programmable Input/Output Pins
RAM Random Access Memory
rcX Real Time Operating System on netX
RTC Real Time Clock
s Second, 1/60 of a Minute
SRAM Static Random Access Memory
UART Universal Asynchronous Receiver Transmitter
USB Universal Serial Bus
WORD 2 Bytes, 16 Bit Entity
xC Communications Channel on the netX Chip (short form)
xPEC, xMAC Communications Channel on the netX Chip
Table 4: Terms, abbreviations and definitions

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

1.5 References to documents

For netX 10/50/51/52/100/500-based firmware
[1] Hilscher Gesellschaft für Systemautomation mbH: Packet API, netX Dual-Port Memory,
Packet-based services netX 10/50/51/52/100/500, Revision 4, DOC161001API04EN,
English, 2020.
[2] Hilscher Gesellschaft für Systemautomation mbH: Function Description, Second Stage
Bootloader, netX 10/50/51/52/100/500, V1.6, Revision 16, DOC070301FD16EN, English,
2018.
For netX 90/4000/4100-based firmware
[3] Hilscher Gesellschaft für Systemautomation mbH: Packet API, netX Dual-Port Memory,
Packet-based services netX 90/4000/4100, Revision 5, DOC190301API05EN, English, 2020.
For all netX-based firmware:
[4] Hilscher Gesellschaft für Systemautomation mbH: Programming reference guide, netX Dual-
Port Memory, Revision 2, DOC160904PRG02EN, English, 2019.

1.6 Information and data security

Please take all the usual measures for information and data security, in particular for devices with
Ethernet technology. Hilscher explicitly points out that a device with access to a public network
(Internet) must be installed behind a firewall or only be accessible via a secure connection such as
an encrypted VPN connection. Otherwise the integrity of the device, its data, the application or
system section is not safeguarded.
Hilscher can assume no warranty and no liability for damages due to neglected security measures
or incorrect installation.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2 Dual-Port Memory Structure

The Dual-Port Memory (DPM) is a structured memory address space in the internal SRAM
(INTRAM) of the netX chip. It is the general access to functions and data of a netX firmware. It can
be accessed from two sides, the host side and the netX side and provides mechanisms for
communication, control, and synchronization.

Data Bus

DPM
Host CPU Address Bus
netX

Control Lines

Figure 1: DPM Structure: DPM Connection to netX

The DPM structure is based on the general functionality of a netX firmware.

It is organized in ‘Channels’ and various ‘Data Blocks’ inside the channels. Each type of channel
provides specific functions and information necessary for working with the hardware and firmware.

System Handshake Communication Communication Communication Communication Application netX

Channel Channel Channel Channel Channel Channel Channel (2x) Registers

Dual-Port Memory

Offset Offset
0x0000 0xFFFF

Figure 2: DPM Structure: Overview of DPM Memory Layout

 System Channel
The system channel provides information and functions affecting the entire netX hardware
like the version of the operating system or the structure of the dual-port memory and allows
basic communication via a mailbox system.
 Handshake Channel
The handshake channel provides synchronization mechanism to ensure data consistency
and data access synchronization between a host system and the netX firmware.
The synchronization is based on so called ‘Handshake Register’ (e.g. bit toggle mechanism
via handshake registers) explained later in this manual. In the default layout, the handshake
registers from system, communication and application channels are packed together in this
channel.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

 Communication Channel / Application Channel

System and handshake channel are followed by one or more communication and/or
application channels. A 'Communication Channel' provides access to a fieldbus protocol or
network and contains areas for cyclic and acyclic communication data and information. An
‘Application Channel’ can be used for any functionality that may be executed in the context of
the netX firmware and which does not correspond to a communication channel.
In the example below, two netX communication channels and one application channel are defined
where the communication channel corresponds to a protocol stack like PROFINET or DeviceNet.
In the example, one of the protocol stacks uses two xMAC/xPEC ports (xC ports).

System Handshake Communication Communication Application

Channel Channel Channel Channel Channel

Protocol Stack 1 Protocol Stack 2

Dual-Port Memory

Task R Task O
System Handshake
Application
Task S Task P
Task

Task T Task Q

rcX Operating System xC xC xC

Port Port Port

netX Firmware

To Networks

Figure 3: DPM Structure: netX Firmware Block Diagram

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2.1 Block Diagram of the default Dual-Port Memory

The block diagram below gives an overview on how the netX firmware organizes the dual-port
memory if channels with default configurations are used.
0x10000
netX Register Block
Dual Port Memory
0xF6FF
0x3FFF
Communication Channel
Communication
Channel 2 / 3 Input Data
0xBA00 or
Application Area 0
Channel 0 / 1
Handshake Channel
0x2980
0x7D00
System Channel

Communication Output Data

Channel 1 Area 0

0x4000
0x1300

Reserved
0x1200
Input Data
Area 1 0x01FF
(high priority)
0x11C0
Output Data System
Area 1
(high priority) Receive Mailbox
0x1180

0x0180
Receive
Mailbox
System
Communication Send Mailbox
0x0B40
Channel 0
0x0100
0x02FF
Send System Status
Mailbox Block
0x00C0
System Control
0x0500
0x00B8 Block
0x00B0 Reserved
Extended
Status Block

0x0350
0x021C Handshake Channel 7 Channel
Common 0x0218 Handshake Channel 6 Information
Status Block 0x0214 Handshake Channel 5 Block
0x0310 0x0210 Handshake Channel 4
Common 0x020C Handshake Channel 3

0x0308 Control Block 0x0208 Handshake Channel 2 0x0030

0x0300 0x0300 Reserved 0x0204 Handshake Channel 1
System
0x0200 Handshake 0x0200 Handshake Channel 0
Information
System
Block
0x0000 Channel 0x0000

Figure 4: DPM Structure: Block Diagram Default Dual-Port Memory Layout

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2.2 Dual-port memory layout and sizes

The DPM address space is available in different variants:
 64 Kbyte address space, which is considered as the default layout and size
(used on PCI-based hardware like CIFX 50 and CIFX 50E PC cards).
 16 Kbyte address space (used by COMX modules).
 8 Kbyte address space (used by COMX 10 modules).

64 KByte

16KByte Firmware dependent

8KByte Firmware dependent

Figure 5: DPM Structure: DPM Address Spaces

Note: If not mentioned otherwise, this document refers to the 64 Kbyte layout as the 'default
memory layout'.

The size of a channel (system, handshake, communication and application) is always a multiple of
256 bytes.

Channel Channel Name Size Size Description

Number 64 KByte 8 KByte
Channel 0 System Channel 512 Bytes 512 Bytes System (card) related information, state
and controls
Channel 1 Handshake Channel 256 Bytes 256 Bytes Block of synchronization registers for all
channels
Channel 2 Communication Channel 0 Variable Variable Fieldbus protocol specific information,
n * 256 Bytes n * 256 Bytes states and controls
Channel 3 Communication Channel 1 Variable Not available Fieldbus protocol specific information,
n * 256 Bytes states and controls
Channel 4 Communication Channel 2 Variable Not available Fieldbus protocol specific information,
n * 256 Bytes states and controls
Channel 5 Communication Channel 3 Variable Not available Fieldbus protocol specific information,
n * 256 Bytes states and controls
Channel 6 Application Channel 0 Variable Not available Custom specific application (optional)
n * 256 Bytes
Channel 7 Application Channel 1 Variable Not available Custom specific application (optional)
n * 256 Bytes
N/A netX Register Block 512 Bytes Not available netX chip specific registers
Table 5: DPM Structure: DPM Layout 8 KByte / 64 Kbyte

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2.2.1 Variable Layout

A netX firmware is also able to create variable DPM layouts where communication channel data
blocks are variable in size (location is changed by the size).
Such a non-default layout is indicated by the 'Default Memory Map' flag in the ‘System Status
Block’ of the 'System Channel' (in the ulSystemCOS field). If the 'Default Memory Map' flag is not
set, the user application can determine the layout of the communication channels by using so
called command packages.
A variable DPM layout has the following restrictions:
 System Channel
Size, location and structure is fixed as defined in this manual
 Handshake Channel
Size, location and structure is fixed as defined in this manual
 Communication Channel
 'Control Block' is mandatory, always present, structure and size is fix
 'Common Status Block' is mandatory, always present, structure and size is fix
 'Send Mailbox' and 'Receive Mailbox' are mandatory but variable in size and location
 'Input Areas' and 'Output Areas' are optional, may not be present or variable in size and
location
 'Extended Status Block' is optional, may not be present
 Application Channel are not defined yet

Note: The start address of the communication channels 1 to 4 is variable and depends on the
size of preceding communication channels.
The start address of communication channel 0 is always fix because this one follows the
system and the handshake channel which are fix in location and size.

Note: The location (offset) of a data block inside a channel is not directly defined. It is implicitly
given by the channel start address and the size of the preceding blocks/channels.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2.3 Channel Definitions

Channels are structured memory areas in the DPM which contain data blocks. This chapter
describes the available channels and the defined data blocks inside a channel.

2.3.1 System Channel

The system channel is always the first channel in the DPM structure. It is always present, even if
no application firmware is loaded to the netX.
It is the “window” to the operating system or netX boot loader (if no firmware is loaded).
The system channel is located at offset 0x0000 of the dual-port memory and has a fixed size of
512 byte. Inside the channel, the first 256 bytes and the containing structures are also fixed while
the following 256 bytes are reserved for the mailbox system. The size of the mailbox structure is by
default 128 bytes for the send mailbox and 128 bytes for the receive mailbox.

Data Block Name Size Description

System Information Block 48 Bytes General system information (e.g. device number /
serial number etc.)
See section System Information Block on page 69.
Channel Information Block 128 Bytes Information about available channels and necessary
to evaluate variable channel structure information.
See section Channel Information Block on page 80.
Reserved 8 Bytes Reserved, Not Used
See section System Handshake Block on page 87.
System Control Block 8 Bytes Used for passing control information to the channel.
See System Control Block on page 88.
System Status Block 64 Bytes Used to provide state information to the host system.
See section System Status Block on page 90.
Mailbox System default: 256 Bytes Send Mailbox / Receive Mailbox
(Send / Receive Mailbox) (128Byte / 128Byte) Used for non-cyclic data transfer of command data
organized in packages.
See section System Mailbox on page System
Mailbox.
Table 6: DPM Structure: System Channel - Overview

For more details about the System Channel refer to section System Channel on page 68.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2.3.2 Handshake Channel

The handshake channel contains the handshake registers for all channels. These registers with
their defined handshake mechanism (see section 3) allow synchronization of data accesses
between the host system and the netX.
The handshake channel always starts at DPM offset address 0x0200 and has a fixed size of 256
bytes and a fixed structure.

Data Block Name Size Description

Handshake Register Block 256 Byte Cumulated handshake register.
See section Handshake Channel on page 95.
Table 7: DPM Structure: Handshake Channel - Overview

Note: Handshake register are special registers inside the DPM. They are able to generate
physical interrupts if their content changes. These registers are also used for data access
synchronization between a host and the netX system.

For more details about the Handshake Channel refer to section Handshake Channel on page 95.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2.3.3 Communication Channel

The communication channel area in the dual-port memory is used by a protocol stack. A protocol
stack provides network access and consumes an area of the netX dual-port memory. Each
communication channel can have the following elements.

Data Block Name Size Description

Reserved 8 Byte Reserved, not used
See section Channel Handshake Block on page 99.
Common Control Block 8 Byte Control Register
See section Common Control Block on page 100.
Common Status Block 64 Byte Protocol Stack Status Information
See section Common Status Block on page 102.
Extended Status Block 432 Byte Network Specific Information
See section Extended Status Block on page 111.
Mailbox System default: 3200 Byte Send Mailbox / Receive Mailbox
(Send / Receive Mailbox) (1600Byte / 1600Byte) Used for non-cyclic data transfer of command data
-> variable organized in packages
See section Channel Mailbox on page 117.
I/O Data Area (1) default: 128Byte Reserved for the cyclic
(Output / Input data) (64Byte / 64 Byte) 'High Priority' Input / Output Process Data Image
-> variable
See section High Priority Input/Output Data Image on
page 118.
Reserved default: 256 Byte Reserved, not used
-> variable See section Reserved Area on page 118.
I/O Data Area (0) default: 11520 Byte Cyclic Input / Output process data image
(Output / Input data) (5760Byte / 5760 Byte) See section Input / Output Process Data Image on page
-> variable 119.
Table 8: DPM Structure: Communication Channel - Overview

The first communication channel starts always at DPM offset 0x0300 while subsequent channels
will follow without a gap in between. The start address of a following channel depends on the size
of the preceding one while the size of each channel must be a multiple of 256 bytes.
Depending on the firmware implementation, multiple communication channels could be available.
For more details about the Communication Channel refer to section Communication Channel on
page 97.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2.3.4 Application Channel

Depending on the implementation, an application channel may or may not be present in the dual-
port memory.
The application channel is intended to be used by OEMs if they decide to create an own netX
firmware including an additional application which needs the possibility to transfer data between
the host and the application via the DPM.
An example for such an application could be a barcode scanner application doing some data
preprocessing on netX system.

Data Block Name Size Description

unknown unknown Application Specific, not defined here

Table 9: DPM Structure: Application Channel - Overview

Application channels must follow the rules for communication channels. They will follow preceding
channels without a gap in between and the size must be a multiple of 256 bytes.
For more details about the Application Channel refer to section Application Channel on page 119.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2.4 Data Block Definitions

'Data Blocks' are defined structures inside a channel and used to organize function specific data.

2.4.1 System Information Block

The System Information Block is only available in the system channel and holds general system
depending information (e.g. device number / serial number etc.).
The system info block is written by the netX firmware and read by the host application.
For more information about the content of the System Information Block see section System
Information Block on page 69.

2.4.2 Channel Information Block

The Channel Information Block is only available in the system channel and contains information
about available channels. It is needed to evaluate variable channel structure information.
The channel information block is written by the netX firmware and read by the host application.
For more information about the content of the Channel Information Block see section Channel
Information Block on page 80.

2.4.3 System Control Block

The System Control Block is only available in the system channel and used to pass control
information to the general system (e.g. operating system).
The system control block is written by the host application and read by the netX firmware.
For more information about the content and the functionality of the System Control Block see
section System Control Block on page 88.

2.4.4 System Status Block

The System Status Block is only available in the system channel and provides general system
status information like system errors, boot errors, CPU usage etc.
The block is written by the netX firmware and read by the host application.
For more information about the content of the System Status Block see section System Status
Block on page 90.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

2.4.5 Common Control Block

The Common Control Block of a communication channel contains commands related to general
channel functions which can be activated by writing to a memory address inside the control block.
The commands vary between different types of channels, because a system channel offers other
functions than a communication channel.
A control block is always present in both system and communication channel.
For some commands, additional information from the Common Status Block is necessary to handle
the commands correctly.
The common control block is written by the host system while the netX firmware is only allowed to
read it.
For more information about the content and the functionality of the Common Control Block see
section Common Control Block on page 100.

2.4.6 Common Status Block

A Common Status Block is always present in a communication channel. It contains information
about tasks, network states and network related issues.
The common status block is written by the protocol stack and is read by the host system.
For more information about the content of the Common Status Block see section Common Status
Block on page 102.

2.4.7 Extended Status Block

The Extended Status Block is a fieldbus protocol specific information block. It is located in a
communication channel and contains specific state information about the protocol stack.
The extended status block may be present or not (usually available on most protocol stacks). It is
written by the netX firmware / protocol stack and read by the host application.
For more information about the content of the Extended Status Block see section Extended Status
Block on page 111.

2.4.8 Mailbox System

The mailbox system provides a non-cyclic data transfer mechanism for packet based commands
and confirmations. This mechanism is used to access functions like firmware download, reading
firmware information, executing resets, retrieving diagnostic information or to control functionality of
a channel by using predefined command packets.
This is always necessary if the required information is not located in the memory area of the DPM.
For more information about the functionality of a mailbox system see section Non-Cyclic Data
Transfer via Mailbox and Packets on page 35.
The position and mapping of the system mailbox is described in section System Mailbox (page 94)
while the channel mailbox description can be found in section Channel Mailbox (page 117).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

DOC060302DPM17EN | Revision 17 | English | 2020-06 | Released | Public © Hilscher, 2006– 2020
Dual-Port Memory Structure 20/154
2.4.9 I/O Data Areas
I/O data areas are used to hold the cyclic process data of a fieldbus protocol stack, which consists
of input and output data exchanged between members of a fieldbus network. The areas are
dedicated to their direction and named Input Data Area and Output Data Area. To allow an
independent handling of each area, separate data access synchronization is provided for each.
These areas are only provided by a communication channel.
For more information on the functionality of the I/O Data Area see section Cyclic Data Transfer via
Input/Output Data Areas ona page 49.

2.5 netX Chip Register Block

The netX Register Block is an area located at the end of the 64 KByte DPM containing internal
registers of the netX chip. The availability depends on the netX firmware which must map the
registers into the DPM and of the used physical connection to the hardware because some of the
hardware does not support the necessary amount of address lines to address a 64 KByte area.
The content of the register block depends on the used netX chip type and is described in the
corresponding 'netX Technical Data Reference Guide'.

Note: It is not recommended to access the netX Register Block by a user application. It is
only mentioned here because it can be seen on the end of the DPM.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

3 Data access and synchronization

Data access to memory areas, shared between two independent CPUs systems, needs to be
synchronized, especially if the information in the memory consists of multiple bytes.
Synchronization is necessary, because two independent CPUs are not using the same clock
source and not running with the same clock speed and therefore it is unpredictable when a CPU
access sections of the memory. A single byte access is synchronized by the memory hardware
itself (only one read/write access at a time).
This is also valid for the netX DPM and therefore a synchronization mechanism is introduced to
ensure data consistency of memory areas which are allowed to be read and written from the netX
and the host CPU.
The netX DPM synchronization mechanism is based on so called Handshake Register, controlling
the access to certain areas inside the DPM (e.g. mailbox systems and I/O data areas) while the
access to the handshake registers is strictly regulated to ensure register consistency.

Handshake Register Definition

Every channel has one 32-bit handshake register. This register is subdivided into Host Register /
Host Flags and netX Register / netX Flags. This means, they are either dedicated to the host or to
the netX.
 Host Register / Host Flags
These registers and the containing flags are dedicated to the host side. Only the host is
allowed to read and write the register while the netX is only allowed to read it.
 netX Register / netX Flags
The netX registers and the containing flags are dedicated to the netX side and only the netX
firmware is allowed to read and write these registers while the host is only allowed to read it.
Each channel (System Channel and Communication Channels) has its own handshake register
and in the default DPM layout, these registers are accumulated in the Handshake Channel (see
section Handshake Channel on page 95).
Three types of handshake register are defined:
 System Channel - Handshake Register
Related to the System Channel are used by the host application to execute netX-wide
(system wide) commands like reset, etc.
 Communication Channel - Handshake Register
Are used to synchronize cyclic data transfer via I/O data areas or non-cyclic data over
mailboxes in the communication channels as well as indicating status changes to the host
system
 Synchronization - Handshake Register
This register is used to synchronize the host system to fieldbus specific events.

Note: Handshake registers are able to generate physical interrupts when their content is
changed.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

3.1 Handshake Flag naming convention

Handshake registers contain bits, called handshake flags, where each flag has an assigned
function or state depending if it is a member of the host or netX handshake register.
To better distinguish handshake flags, their names follow a simple pattern:
Member of Location Function Signal Type
[H/N] [C/S] _F_FUNCTION_ [ACK/CMD/none]
ACK = Acknowledge flag
CMD = Command flag
none = Simple Signal
Name / Function of the handshake flag
S = System Channel flag
C = Communication Channel flag
H = Host flag
N = netX flag
Table 10: Handshake Flag Naming Convention

Example

 HSF_SEND_MBX_CMD
Member of: HSF Host System Flags
Function: SEND_MBX Send Mailbox
Signal Type: CMD Command Flag
 NCF_PD0_IN_CMD
Member of: NCF NetX Communication Flags
Function: PD0_IN Process Data Area 0 - Input
Signal Type: CMD Command Flag
 NCF_PD0_IN_ACK
Member of: NCF NetX Communication Flags
Function: PD0_IN Process Data Area 0 - Input
Signal Type: ACK Acknowledge Flag

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

3.2 System Channel - Handshake Register and Flags

The system channel handshake registers and flags are used to synchronize the data transfer
between the netX firmware and the host application. They hold information about the status of the
operating system and can be used to execute certain commands in the firmware (e.g. a system
wide reset).

Note: Handshake registers are located in the handshake channel (see section Handshake
Channel on page 95) of the DPM.

System Channel - Handshake Register Structure

The system channel handshake register needs less synchronization flags than a communication
channel. The length of the flags is 8 bits for the netX firmware (netX Flags = bNetxFlags) and 8
bits for the host application (Host Flags = bHostFlags).

Bit 31 32 Bit Register Value (DPM Offset = 0x0200) Bit 0

Bit 7 Host Flags Bit 0 Bit 7 netX Flags Bit 0 Bit 7 empty Bit 0 Bit 7 empty Bit 0

Table 11: System Channel - Handshake Register Structure

System Channel - Handshake Register / Flag Access Definition

 netX System Flags (NSF)

Are read and written by netX firmware, host is only allowed to read the flags
 Host System Flags (HSF)
Are read and written by the host, netX firmware is only allowed to reads these flags

System Channel - Handshake Register DPM Offset

 netX System Channel Register  located at DPM address 0x0202

 Host System Channel Register  located at DPM address 0x0203

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

System Channel - Handshake Flag Definition

Host System Flags (HSF) bHostFlags – Host writes, netX reads

unused, set to 0 HSF_RECV_MBX_ACK

HSF_SEND_MBX_CMD
HSF_NETX_COS_ACK
HSF_HOST_COS_CMD
HSF_BOOTSTART
HSF_RESET
7 6 5 4 3 2 1 0 HSF
|| || || ||
7 6 5 4 3 2 1 0 NSF
NSF_READY
NSF_ERROR
NSF_HOST_COS_ACK
NSF_NETX_COS_CMD
NSF_SEND_MBX_ACK
unused, set to 0 NSF_RECV_MBX_CMD

netX System Flags (NSF) bNetxFlags – netX writes, Host reads

Table 12: System Channel - Handshake Register and Flag Definition

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Host System Flags (HSF) (Host  netX System)

Variable: bHostFlags

Bit Definition Description

0 HSF_RESET Reset
The Reset flag is set by the host system to execute a system wide reset. This
forces the system to restart. All network connections are interrupted immediately
regardless of their current state.
For more details see section Reset Handling on page 123.
1 HSF_BOOTSTART Boot Start
If set during reset, the Boot-Start flag forces the netX to stay in boot loader mode;
a firmware that may reside in the context of the operating system is not started. If
cleared during reset, the operating system will start the firmware, if available.
For more details see section Boot Start on page 125.
2 HSF_HOST_COS_CMD Host Change Of State Command
The Host Change of State Command flag is set by the host system to signal a
change of its state to the netX. Details of what has changed can be found in the
ulSystemCommandCOS field of the System Control Block (see section System
Control Block on page 88).
3 HSF_NETX_COS_ACK netX Change Of State Acknowledge
The netX Change of State Acknowledge flag is set by the host system to
acknowledge the new state of the netX. This flag is used together with the netX
Change of State Command flag located in the netX System Flags.
4 HSF_SEND_MBX_CMD Send Mailbox Command
Both the Send Mailbox Command flag and the Send Mailbox Acknowledge flag
are used together to transfer non-cyclic packages between the host system and
the netX firmware.
5 HSF_RECV_MBX_ACK Receive Mailbox Acknowledge
Both the Receive Mailbox Acknowledge flag and the Receive Mailbox Command
flag are used together to transfer non-cyclic packages between the netX and the
host system.
6-7 unused, set to zero
Table 13: System Channel - Host System Flags

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

netX System Flag (NSF) (netX  Host System)

Variable: bNetxFlags

Bit Definition Description

0 NSF_READY Ready
The Ready flag is set as soon as the operating system has initialized itself
properly and passed its self test. When the flag is set, the netX is ready to accept
packets via the system mailbox. If cleared, the netX does not accept any packets.
1 NSF_ERROR Error
The Error flag is set when the netX has detected an internal error condition. This is
considered to be a fatal error and an error code, helping to identify the issue, is
placed in the ulSystemError field of the System Status Block (see section
System Status Block on page 90).
2 NSF_HOST_COS_ACK Host Change Of State Acknowledge
The Host Change of State Acknowledge flag is set when the netX acknowledges a
command from the host system. This flag is used together with the Host Change
of State Command flag in the Host System Flags.
3 NSF_NETX_COS_CMD netX Change Of State Command
The netX Change of State Command flag is set if the netX signals a change of its
state to the host system. Details of what has changed can be found in the
ulSystemCOS variable in the System Status Block (see section System Status
Block on page 90).
4 NSF_SEND_MBX_ACK Send Mailbox Acknowledge
Both the Send Mailbox Acknowledge flag and the Send Mailbox Command flag
are used together to transfer non-cyclic packages between the host system and
the netX.
5 NSF_RECV_MBX_CMD Receive Mailbox Command
Both the Receive Mailbox Command flag and the Receive Mailbox Acknowledge
flag are used together to transfer non-cyclic packages between the netX and the
host system.
6-7 unused, set to zero
Table 14: System Channel - netX System Flags

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

3.3 Communication Channel - Handshake Register and Flags

The channel handshake registers and flags are used to control data synchronization of the mailbox
system and of the process data image. They are also used to indicate the status of the protocol
stack and to execute commands in the protocol stack (e.g. reset of a channel).

Note: Handshake registers are located in the Handshake Channel (see section Handshake
Channel on page 95) of the DPM.

Communication Channel - Handshake Register Structure

The communication channel handshake register defines 16 bits for the netX firmware (netX Flags
= usNetxFlags) and 16 bits for the host application (Host Flags = usHostFlags).
A netX firmware supports up to 4 communication channels, numerated by an index from 0 to 3 with
the same structure.

Communication Channel - Handshake Register Structure

Bit 31 32 Bit Register Value Bit 0

Bit 15 Host Flags Bit 0 Bit 15 netX Flags Bit 0

Table 15: Communication Channel - Handshake Register Structure

Communication Channel - Handshake Register / Flag Access Definition

 netX Communication Flags (NCF)

Are read and written by the netX firmware, host is only allowed to read the flags
 Host Communication Flags (HCF)
Are read and written by the host, netX firmware is only allowed to read the flags

Communication Channel - Handshake Register DPM Offset

 netX Communication Channel 0 register  located at DPM address 0x0208

 Host Communication Channel 0 register  located at DPM address 0x020A

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Communication Channel - Handshake Flag Definition

Host Communication Flags (HCF) usHostFlags – Host writes, netX reads
unused, set to zero HCF_PD1_IN_ACK (not supported yet)
HCF_PD1_OUT_CMD (not supported yet)
HCF_PD0_IN_ACK
HCF_PD0_OUT_CMD
HCF_RECV_MBX_ACK
HCF_SEND_MBX_CMD
HCF_NETX_COS_ACK
HCF_HOST_COS_CMD
unused
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 HCF
|| || || || || || || ||
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 NCF
NCF_COMMUNICATING
NCF_ERROR
NCF_HOST_COS_ACK
NCF_NETX_COS_CMD
NCF_SEND_MBX_ACK
NCF_RECV_MBX_CMD
NCF_PD0_OUT_ACK
NCF_PD0_IN_CMD
NCF_PD1_OUT_ACK (not supported yet)
unused, set to zero NCF_PD1_IN_CMD (not supported yet)

netX Communication Flags (NCF) usNetXFlags – netX writes, Host reads

Table 16: Communication Channel - Handshake Register and Flag Definition

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Host Communication Flags (HCF) (Application  netX System)

Variable: usHostFlags

Bit Definition Description

0,1 undefined unused, set to 0
2 HCF_HOST_COS_CMD Host Change Of State Command
The HCF_HOST_COS_CMD flag is used to signal a change in the state of the
host application. The new state is set in the ulApplicationCOS variable in
the Common Control Block (see section Common Control Block on page 100).
The protocol stack has acknowledged the processing of the new state by
toggling the NCF_HOST_COS_ACK flag. At initialization time, this flag is
cleared.
3 HCF_NETX_COS_ACK Host Change Of State Acknowledge
The HCF_NETX_COS_ACK flag is used by host applications to indicate that
the new state of the protocol stack has been read. At initialization time, this flag
is cleared.
4 HCF_SEND_MBX_CMD Send Mailbox Command
Both flags HCF_SEND_MBX_CMD and NCF_SEND_MBX_ACK are used
together to transfer non-cyclic packets between the application and the protocol
stack. At initialization time, this flag is cleared.
5 HCF_RECV_MBX_ACK Receive Mailbox Acknowledge
Both flags HCF_RECV_MBX_ACK and NCF_RECV_MBX_CMD are used
together to transfer non-cyclic packets between the protocol stack and the
application. At initialization time, this flag is cleared.
6 HCF_PD0_OUT_CMD Process Data 0 Out Command
Both the HCF_PD0_OUT_CMD flag and the NCF_PD0_OUT_ACK flag are
used together to transfer cyclic output data from the application to the protocol
stack. At initialization time, this flag may be set, depending on the data
exchange mode.
7 HCF_PD0_IN_ACK Process Data 0 In Acknowledge
Both flags HCF_PD0_IN_ACK and NCF_PD0_IN_CMD flag are used together
to transfer cyclic input data from the protocol stack to the application. At
initialization time, this flag may be set, depending on the data exchange mode.
8 HCF_PD1_OUT_CMD Process Data 1 Out Command (not supported yet)
Both flags HCF_PD1_OUT_CMD and NCF_PD1_OUT_ACK are used together
to transfer cyclic output data from the application to the protocol stack.
9 HCF_PD1_IN_ACK Process Data 1 In Acknowledge (not supported yet)
Both the HCF_PD1_IN_ACK flag and the NCF_PD1_IN_CMD flag are used
together to transfer cyclic input data from the protocol stack to the application.
10-15 Reserved, set to 0
Table 17: Communication Channel - Host Communication Flags

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

netX Communication Flags (NCF) (netX  Application)

Variable: usNetXFlags

Bit Definition Description

0 NCF_COMMUNICATING Communicating
NCF_COMMUNICATING is set if the protocol stack has successfully opened a
connection to at least ONE of the configured network slaves (for master
protocol stacks), respectively has an open connection to the network master
(for slave protocol stacks).
If cleared, the input data should not be evaluated, because it may be invalid,
old or both. At initialization time, this flag is cleared.
1 NCF_ERROR Error
If set, NCF_ERROR signals an error condition that is reported by the protocol
stack. The corresponding error code is placed in the
ulCommunicationError field of the Common Status Block (see section
Common Status Block on page 102).
At initialization time, this flag is cleared.
2 NCF_HOST_COS_ACK Host Change Of State Acknowledge
The NCF_HOST_COS_ACK flag is used by the protocol stack indicating that
the new state of the host application has been read.
At initialization time, this flag is cleared.
3 NCF_NETX_COS_CMD netX Change Of State Command
The NCF_NETX_COS_CMD flag is used to signal a change in the state of the
protocol stack. The new state is set in the ulCommunicationCOS field in the
Common Status Block (see section Common Status Block on page 102). If the
host application has read the new protocol state, it has to acknowledge it by
toggling the HCF_NETX_COS_ACK flag.
At initialization time, this flag is cleared.
4 NCF_SEND_MBX_ACK Send Mailbox Acknowledge
Both flags NCF_SEND_MBX_ACK and HCF_SEND_MBX_CMD are used
together to transfer non-cyclic packets between the protocol stack and the
application. At initialization time, this flag is cleared.
5 NCF_RECV_MBX_CMD Receive Mailbox Command
Both flags NCF_RECV_MBX_CMD and HCF_RECV_MBX_ACK flag are used
together to transfer non-cyclic packets between the application and the
protocol stack. At initialization time, this flag is cleared.
6 NCF_PD0_OUT_ACK Process Data 0 Out Acknowledge
Both flags NCF_PD0_OUT_ACK and HCF_PD0_OUT_CMD are used together
to transfer cyclic output data from the application to the protocol stack. At
initialization time, this flag may be set, depending on the data exchange mode.
7 NCF_PD0_IN_CMD Process Data 0 In Command
Both flags NCF_PD0_IN_CMD and the HCF_PD0_IN_ACK are used together
to transfer cyclic input data from the protocol stack to the application. At
initialization time, this flag may be set, depending on the data exchange mode.
8 NCF_PD1_OUT_ACK Process Data 1 Out Acknowledge (not supported yet)
NCF_PD1_OUT_ACK and HCF_PD1_OUT_CMD are used together to transfer
cyclic output data from the application to the protocol stack.
9 NCF_PD1_IN_CMD Process Data 1 In Command (not supported yet)
NCF_PD1_IN_CMD and HCF_PD1_IN_ACK are used together to transfer
cyclic input data from the protocol stack to the application.
10-15 reserved, set to zero
Table 18: Communication Channel - netX Communication Flags

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

3.4 Synchronization - Handshake Register and Flags

The synchronization handshake register is a special register located in the handshake channel
used for fieldbus specific synchronization events.
Synchronization is only available if the fieldbus system supports specific synchronization and it
must be configured within the fieldbus configuration.

Note: The fieldbus specific synchronization register is located in the Handshake Channel (see
section Handshake Channel on pabe 95) at Handshake Register 1.

Synchronization - Handshake Register Structure

The synchronization handshake register defines 16 bits for the netX firmware (netX Flags =
usNSyncFlags) and 16 bits for the host application (Host Flags = usHsyncFlags).
Each bit in the synchronization has a fix assignment to one of the possible 4 communication
channels starting with bit 0 for communication channel 0.
Synchronization - Handshake Register Layout

Bit 31 32 Bit Register Value (DPM Offset = 0x0204) Bit 0

Bit 15 Host Flags Bit 0 Bit 15 netX Flags Bit 0

Table 19: Synchronization - Handshake Register Structure

Synchronization - Handshake Register / Flag Access Definition

 netX Synchronization Flags (NCFSYNC)

Are read and written by the netX firmware, host is only allowed to read the flags
 Host Synchronization Flags (HCFSYNC)
Are read and written by the host, netX firmware is only allowed to read the flags

Synchronization - Handshake Register DPM Offset

 netX Synchronization Register  located at DPM address 0x0204

 Host Synchronization Register  located at DPM address 0x0206

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Synchronization - Handshake Flag Definition

Host Synchronization Flags (HSYNCF) usHSyncFlags – Host writes, netX reads
unused, set to zero HSYNCF_CH4
HSYNCF_CH2
HSYNCF_CH1
HSYNCF_CH0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 HSYNC
|| || || ||
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 NSYNC
NSYNCF_CH0
NSYNCF_CH1
NSYNCF_CH2
unused, set to zero NSYNCF_CH3

netX Synchronization Flags (NSYNCF) usNSyncFlags – netX writes, Host reads

Table 20: Synchronization - Handshake Register and Flag Definition

Host Synchronization (HSYNCF) (Application  netX System)

Variable: usHSyncFlags (DPM offset 0x206)

Bit Definition Description

0 HSYNCF_CH0 Fieldbus specific synchronization flags:
1 HSYNCF_CH1 Used to signal synchronization command events to the netX protocol stack or
to acknowledge a netX synchronization command event.
2 HSYNCF_CH2
Each flag is fixed communication channel assignment.
3 HSYNCF_CH3
4-15 Reserved, set to 0
Table 21: Synchronization - Host Synchronization Flags

netX Synchronization Flags (NSYNC) (netX  Application)

Variable: usNSyncFlags (DPM offset 0x204)

Bit Definition Description

0 NSYNCF_CH0 Fieldbus specific synchronization flags:
1 NSYNCF_CH1 Used to signal synchronization command events to the host application or to
acknowledge a host synchronization command event.
2 NSYNCF_CH2
Each flag is fixed communication channel assignment
3 NSYNCF_CH3
4-15 Reserved, set to 0
Table 22: Synchronization - netX Synchronization Flags

Note: The complete description of synchronization handling is located in an own manual

(netX IO Synchronization Manual).
Consult this manual on how to work with synchronization events.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Synchronization Information - Common Status Block

Additional information about the synchronization, like the sync source, sync handshake mode and
the sync error counter, is located in the Common Status Block of the communication channel.
Type Variable Description
uint8_t bErrorSyncCnt Number of synchronization handshake errors
Depending on the configuration the error counter is used if the sync
information could not be updated because of a missing acknowledgement.
uint8_t bSyncHskMode Synchronization Handshake Mode
Configured mode of the synchronization (host controlled / device
controlled)
uint8_t bSyncSource Synchronization Source
Definition of the sync source (bus cycle / hardware trigger etc.)
Table 23: Synchronization - Synchronization Information

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4 Data Transfer Mechanism

The DPM, respectively the netX firmware, provides several data transfer mechanisms and
synchronization methods depending on the data areas used for the transfer.
The netX firmware offers several general methods to exchange data with it.
 Non-Cyclic data transfer via Mailbox and Packets
Non-cyclic data is binary data streams named Packets. A packet is a structure which
consists of a header with general administration information (command / length / source /
destination etc) and a data area. The mailbox system contains two memory areas used to
exchange packets between the host and the netX device.
 Cyclic data transfer via Input/Output Data Areas
Cyclic data is the fieldbus protocol stacks input and output data which is cyclically exchanged
between members of a fieldbus network.
 Change Of State
Used to signal state changes and commands between the host application and a
communication channel.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.1 Non-Cyclic Data Transfer via Mailbox and Packets

Mailboxes are data areas located in a channel and part of a Mailbox System. A mailbox system
consists of two areas named Receive Mailbox and Send Mailbox (from the view of the host
application) which are dedicated to a transfer direction and used to transfer Packets between the
host program and the netX firmware, while packets itself describing the data which are transferred.
Each of the area owns a separate data access synchronization allowing an independent handling.

Mailbox System
Host Application

Send Mailbox Receive Mailbox

netX Firmware

Figure 6: Packets: Mailbox System Overview

Mailbox System

 Send Mailbox (System / Communication Channel)

Packet transfer from host system to netX firmware
 Receive Mailbox (System / Communication Channel)
Packet transfer from netX firmware to host system
Both Send and Receive Mailboxes are structured into a counter, for tracking the number of active
packets and a data area which holds the packet data.
Mailbox Structure (System Channel):
/*****************************************************************************/
/*! System send packet mailbox (Size 128 Byte) */
/*****************************************************************************/
typedef __HIL_PACKED_PRE struct HIL_DPM_SYSTEM_SEND_MAILBOX_Ttag
{
uint16_t usPackagesAccepted; /*!< Number of packages that can be accepted */
uint16_t usReserved; /*!< Reserved */
uint8_t abSendMbx[HIL_DPM_SYSTEM_MAILBOX_MIN_SIZE]; /*!< Send mailbox packet buffer */
} __HIL_PACKED_POST HIL_DPM_SYSTEM_SEND_MAILBOX_T;

/*****************************************************************************/
/*! System receive packet mailbox (Size 128 Byte) */
/*****************************************************************************/
typedef __HIL_PACKED_PRE struct HIL_DPM_SYSTEM_RECV_MAILBOX_Ttag
{
uint16_t usWaitingPackages; /*!< Number of packages waiting to be processed */
uint16_t usReserved; /*!< Reserved */
uint8_t abRecvMbx[HIL_DPM_SYSTEM_MAILBOX_MIN_SIZE]; /*!< Receive mailbox packet buffer */
} __HIL_PACKED_POST HIL_DPM_SYSTEM_RECV_MAILBOX_T;

Note: The mailbox structure of a Communication Channel corresponds to the structure of a

System Channel, except the user data area size is different.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Mailbox Data Buffer Size

Channel Definition Size [bytes]

System Channel NETX_SYSTEM_MAILBOX_MIN_SIZE 124

Communication Channel NETX_CHANNEL_MAILBOX_SIZE 1596

Table 24: Mailbox Data Buffer Size

Only one packet can be placed into a mailbox at a time (abSendMbx[] / abRecvMbx[]), while the
counter in the send mailbox tracks the amount of packets acceptable by the netX firmware and the
counter in the receive mailbox tracks the amount of packets waiting in the receive packet queue of
the firmware.

Host DPM netX

Packet Receive Mailbox Send Packet Queue

Packet Send Mailbox Receive Packet Queue

Figure 7: Data Transfer Mechanism: Mailbox Packet Exchange

Note: Each packet will occupy a piece of memory inside the netX firmware. Therefore the
amount of concurrent packages is limited by the firmware (default: 16).

The netX firmware stores packets into internal memory segments organized in send and receive
queues, where the size of the queues is limited.
If the internal packet queues are getting full, the firmware is not able to accept further packets from
the send mailbox. This is because each send packet will usually be answered by the netX
firmware, which creates a corresponding confirmation packet and stores the answers into the
receive packet queue (to be send later on to the host application). In other words, each command
packet sent to the firmware generates a confirmation packet which must be read by the host
application.
Therefore, if non-cyclic data transfer is used, it is strongly recommended to empty the receive
mailbox frequently, otherwise the sending of packets can be influenced.
Access to the mailboxes is synchronized by dedicated Handshake-Register-Flags (see Handshake
Registers), signaling the state of a mailbox, which can be either empty or full.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.1.1 Packet structure

Packets are asynchronous commands/confirmations which can be exchanged with the firmware. A
packet is a data structure containing a Packet header holding global command/confirmation,
routing and handling information, followed by a User Data Area containing the packet-specific data.
The structure HIL_PACKET_T is the general structure of a packet.
Area Variable / Type Value / Range Description
Element
Header ulDest uint32_t 0 … 0xFFFFFFFF Destination Address / Handle
(tHead) ulSrc uint32_t 0 … 0xFFFFFFFF Source Address / Handle
ulDestId uint32_t 0 … 0xFFFFFFFF Destination Identifier
ulSrcId uint32_t 0 … 0xFFFFFFFF Source Identifier
ulLen uint32_t 0 … max.packet data size Packet Data Length (in Byte)
ulId uint32_t 0 … 0xFFFFFFFF Packet Identifier
ulSta uint32_t 0 … 0xFFFFFFFF Packet State / Error
ulCmd uint32_t 0 … 0xFFFFFFFF Packet Command / Answer
ulExt uint32_t see below Packet Extension
ulRout uint32_t 0 … 0xFFFFFFFF Reserved (routing information)
Packet abData … Packet Data (packet specific data)
Data Variable ulLen defines the length of
(abData)
abData.
Table 25: General packet structure: HIL_PACKET_T

 Minimum packet size is 40 byte (equal to the packet header structure without user data).
 Maximum packet size (header + data) is limited by the mailbox send / receive area size.

Default packet structure

/* packet header definition */
typedef struct HIL_PACKET_HEADER_Ttag
{
uint32_t ulDest; /* destination of the packet (task message queue reference) */
uint32_t ulSrc; /* source of the packet (task message queue reference) */
uint32_t ulDestId; /* destination reference (internal use for message routing) */
uint32_t ulSrcId; /* source reference (internal use for message routing) */
uint32_t ulLen; /* length of packet data (starting from the end of the header) */
uint32_t ulId; /* identification reference (internal use by the sender) */
uint32_t ulSta; /* operation status code (error code, initialize with 0) */
uint32_t ulCmd; /* operation command code */
uint32_t ulExt; /* extension count (nonzero in multi-packet transfers) */
uint32_t ulRout; /* router reference (internal use for message routing) */
} HIL_PACKET_HEADER_T;

/* definition of a packet with maximum size */

typedef struct HIL_PACKET_Ttag
{
HIL_PACKET_HEADER_T tHead;
uint8_t abData[HIL_MAX_PACKET_SIZE - sizeof (HIL_PACKET_HEADER_T)];
} HIL_PACKET_T;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Parameter description

Variable / Description
Element

ulDest Destination Address / Handle

ulDest defines (addresses) the receiver of a packet and must be set in any case (mandatory).
The destination address could be either a simple definition or a handle to a task packet input buffer.
Definitions are used if packets passed via a mailbox, while handles are used inside a netX firmware.
See section Packet Addressing via ulDest on page 41.
A receiving process or task may evaluate this field and has to pass it back unchanged.

ulSrc Source Address / Handle

ulSrc field identifies the sender of the packet. If used by a host application (outside a netX firmware),
any number, which identifies the application uniquely (e.g. process handle), can be used. If used
inside a netX firmware (e.g. inter-task communication), this field holds the identifier of the sending task
respectively the task input queue handle.
See section Using ulSrc and ulSrcId on page 43.
The receiver may evaluate this field and has to pass it back unchanged.

ulDestId Destination Identifier

ulDestId is an additional field to identify the receiver of a packet. It can hold any number or handle.
The packet command (ulCmd) defines if the value is necessary (used) or not.
A receiving process or task may evaluate this field and has to pass it back unchanged.

ulSrcId Source Identifier

ulSrcId can be used by the originator of a command packet to additionally distinguish between sub
components for which a packet is generated or sent.
A receiving process or task does not evaluate this field and has to pass it back unchanged.

ulLen Packet Data Length

ulLen defines the length of the user data contained in the packet area (abData[]).
The size of the packet header is not included. The header has a fixed size of 40 bytes.
A process or task, creating a confirmation packet, must adjust the packet size according to the size of
the confirmation packet data.

ulId Packet Identifier

ulId is a unique number used to identify multiple packets of the same type (given in ulCmd). It allows
the originator of the packet to match a specific confirmation with a specific command packet, if multiple
packets of the same type are activated. It is up to the originator of a packet if ulId is used or not, but
it maybe necessary for some services (like fragmented packets).
A receiving process or task may evaluate this value and has to pass it back unchanged.

ulSta Packet State / Error

The ulSta is used in confirmation packets to indicate failures in the command delivery, packet data or
in command processing of the receiving process.
Status and error codes that may be returned in ulSta are outlined in section Error codes (from page
133).
In a command packet, this field has to be zero.

ulCmd Packet Command / Answer

ulCmd holds the command or confirmation code. Each command ulCmd has a specified code, which
is always an even number (bit 0 = 0) while the corresponding confirmation is always ulCmd + 1 (an
odd number, bit 0 = 1).
It is used by the receiving process to identify the command (even number, excluding zero) and
confirmation packets (odd number).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

ulExt Packet Extension

The extension field ulExt is used for controlling packets that are sent in a sequenced or fragmented
manner. The field indicates the first, last or a packet of a sequence.
If fragmentation of packets is not required, the extension field is set to zero.
0x00000000 = HIL_PACKET_SEQ_NONE (default)
0x00000080 = HIL_PACKET_SEQ_FIRST
0x000000C0 = HIL_PACKET_SEQ_MIDDLE
0x00000040 = HIL_PACKET_SEQ_LAST
ulRout Routing Information
The ulRout field is used internally by the netX firmware only.
It has no meaning to a host application and therefore the host application has to set it to zero for
commands and has to be returned unchanged in confirmations.
abData Packet Data
The abData field contains the payload of the packet. Depending on the command (ulCmd) or
confirmation (ulCmd +1) a packet may or may not have a data field.
The length of the data field is given in the ulLen field.
Table 26: Packets: Packet description

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.1.2 Default Packet Handling

For a complete transfer, a sent packet has to be answered (confirmed) by the receiving process.
The creation of a confirmation packet must follow the rules described below.

Packet Creator

 The packet must be filled with the necessary information (header and/or data).
Unused fields must be set to 0.
 Confirmations to a command must be verified (ulCmd, ulSta, ulLen and/or content).

Packet Receiver

 Evaluation of the header and/or data content (at least ulCmd and ulLen).
 Each command must be answered.
ulSta must be set to the processing result (ulSta = 0 = no Error).
ulCmd must be set to ulCmd + 1 marking the packet as an answer
(e.g. Command value = 0x02 / Answer value = 0x03).
ulLen must be set to the amount of data returned in the answer.
 All other values of the header must be returned unchanged.
(*) except when using Packet Fragmentation (page 45).
Command Packet Answer Packet

ulDest ulDest

ulSrc ulSrc

ulDestId ulDestId

ulSrcId ulSrcId

Command data length

ulLen ulLen
Answer data lenth

ulId ulId

Value = 0
ulState ulState
State / Error (0 = no error)

Command code
ulCmd Answer code (ulCmd +1)
ulCmd

ulExt(*) ulExt(*)

ulRout ulRout

abData abData

Figure 8: Packets: Default Packet Handling

Note: Default error codes are defined in Hil_Results.h and named ERR_HIL_...

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.1.3 Packet Addressing via ulDest

The receiver of a packet is addressed by the destination identifier ulDest in the packet header,
which must be filled out according to the specified receiver. The netX firmware offers several
addressable targets. A target itself is usually a task inside the firmware offering services.

Possible Packet Targets

 Operating system middleware task of the netX firmware (operating system)

 A fieldbus protocol stack behind a communication channel
 Any task offering public services

Addressing a task inside a netX firmware

Tasks inside a netX firmware are addressed by their task handle created from the tasks dedicated
packet queue. This handle can be retrieved by a system command but for this procedure the name
of the task must be known.

Addressing a task via a DPM mailbox

To simplify the addressing for host applications working with the DPM, mailboxes are already
connected with corresponding tasks inside the firmware.
In case of the System Channel mailbox, the connected task is the middleware task of the operating
system. The Communication Channel mailboxes are connected to the application task (AP-task) of
the fieldbus protocol stack. This makes it unnecessary for the host application to know the name of
a task and to retrieve task handles from the system.
Default Target Addresses
Definition Value Description
HIL_PACKET_DEST_DEFAULT_CHANNEL 0x00000020 Default Channel (recommended)
Packet is passed to default handler
System Channel = Middleware
Communication Channel = Fieldbus protocol
HIL_PACKET_DEST_SYSTEM 0x00000000 Packet is passed to the Middleware
Independent of the channel
Table 27: Packets: Default Target Addresses for ulDest

Furthermore, the netX firmware also offers a routing mechanism which allows sending commands
to other channels by using the channel index.
Additional Target Addresses
Definition Value Description
HIL_PACKET_DEST_PORT_0 0x00000001 Packet passed to communication channel 0
HIL_PACKET_DEST_PORT_1 0x00000002 Packet passed to communication channel 1
HIL_PACKET_DEST_PORT_2 0x00000003 Packet passed to communication channel 2
HIL_PACKET_DEST_PORT_3 0x00000004 Packet passed to communication channel 3
Table 28: Packets: Additional Target Addresses for ulDest

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Note: The recommended way to address the middleware of the operating system is through
the system mailbox and a fieldbus protocol via the communication channel mailbox.
This is because additional packets to the middleware via a channel mailbox could
influence the performance of the protocol stack handling.

Note: Confirmations are always returned to the mailbox of the channel, which initiated the
command.

ulDest = 0x20

ulDest = 0x00
Host Application

DPM Channel Mailbox

netX Firmware Middelware Task

(operating system)

Connected Default
Receiver

Figure 9: Packets: Target Addressing with ulDest

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.1.4 Using ulSrc and ulSrcId

The originator of a packet is defined by ulSrc which is the default identification of the sender (e.g.
host application / firmware task). The identification of the packet sender depends on the location of
the creating process.

Task inside the netX firmware

In case of a task inside a firmware, ulSrc is the task handle or better the address of the packet
queue of the task.

Host application outside the netX firmware

Host applications, which are located outside of a netX firmware and using the DPM to
communicate to the firmware, can set ulSrc to any value including 0.
But it is recommended to use a unique number (e.g. process handle) to prevent collisions with
other send processes.
ulSrdId can be freely used by the sending application (e.g. to address internal components).

Host Application = ulSrc

Process1: ulSrcId = 1

Local Packet Process2: ulSrcId = 2

Handler
Process3: ulSrcId = 3

DPM Channel Mailbox

netX Firmware
Protocol Stack

Figure 10: Packets: Using ulSrc and ulSrcId

Note: The netX firmware will not touch ulSrc and ulSrcId and both values are always
delivered back in the confirmation packet.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.1.5 Client/Server Mechanism

The Client/Server Mechanism is used to describe which part of the software (host application /
netX firmware) has initiated a command and which one has to answer it.
Naming Convention
 Client is the initiator of a command
Host commands are called requests (REQ) / netX commands are called indications (IND)
 Server is the responder to a command
netX answers are called confirmations (CNF) / Host answers are called responses (RSP)
By default, the host application will be the Client and the netX firmware will be the Server in a
transfer operation. The netX firmware usually doesn’t create commands for the host application.
This is because the host application must prepare itself to receive firmware commands and be able
to answer them.
But there are several services, offered by a netX firmware / protocol stack, which allow a stack to
actively inform the host application about state changes of the fieldbus system (e.g. alarm
messages from a fieldbus device). Such firmware requests must be activated by the host
application by sending an application register request command to the protocol stack. In this
situation, the netX firmware becomes the Client and the host application the Server.
For a better distinction between Client and Server in conjunction with the transfer direction,
commands are specified as Requests / Indications and answers are specified as Confirmation /
Response.
Client Server Server Client
Host Application netX Host Application netX

REQUEST Indication
1 5

2 6

3 7

4 8

CONFIRMATION RESPONSE

Figure 11: Client/Server mechanism

Host to netX netX to Host

Direction Description Direction Description

 Host application sends a Request packet  Host application receives an Indication packet
to the netX firmware from the netX firmware

 netX firmware answers by a  Host application sends a Response packet
Confirmation packet back to the netX firmware (may not be
required
Table 29: Directions and names of packets

Note: Indications must be explicitly activated by the host application.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.1.6 Packet Fragmentation

Two mailboxes are used to transfer a packet from the host application to the netX firmware or visa
versa. Each mailbox has a limited size (= mailbox size). If the packet to be transferred is larger
than the mailbox size, the packet has to be fragmented.
For a description for netX 10/50/51/52/100/500-based firmware, see reference [1].
For a description for netX 90/4000/4100-based firmware, see reference [3].

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.1.7 Packet transfer synchronization

The transfer of packets via the mailbox system is synchronized by the corresponding handshake
flags in the handshake flag registers of each channel (see usNetxFlags / usHostFlags).
The following flag pairs are used to synchronize the packet transfer / mailbox handling.
 System Channel Flags
HSF_SEND_MBX_CMD / NSF_SEND_MBX_ACK
NSF_RECV_MBX_CMD / HSF_RECV_MBX_ACK
 Communication Channel Flags
HCF_SEND_MBX_CMD / NCF_SEND_MBX_ACK
NCF_RECV_MBX_CMD / HCF_RECV_MBX_ACK
Each mailbox has an owner allowed to initiate a transfer. The owner of the Send Mailbox is the
host application while the Receive Mailbox is owned by the netX firmware. And a mailbox can have
2 states (EMPTY / FULL), signaled by the corresponding handshake flags.

General Mailbox Definition

SYSTEM CHANNEL - Send Mailbox / Owner: Host Application

Handshake Flag Status Handshake Flag Mailbox State
HSF_SEND_MBX_CMD 0 0 NSF_SEND_MBX_ACK
EMPTY
1 1
1 0
FULL
0 1

SYSTEM CHANNEL - Receive Mailbox / Owner: netX Firmware

NSF_RECV_MBX_CMD 0 0 HSF_RECV_MBX_ACK
EMPTY
1 1
1 0
FULL
0 1
Table 30: Packet: System Channel Mailbox State Definition

COMMUNICATION CHANNEL - Send Mailbox / Owner: Host Application

Handshake Flag Status Handshake Flag Mailbox State
0 0
HCF_SEND_MBX_CMD NCF_SEND_MBX_ACK EMPTY
1 1
1 0
0 1 FULL

COMMUNICATION CHANNEL - Receive Mailbox / Owner: netX Firmware

0 0
NCF_RECV_MBX_CMD HCF_RECV_MBX_ACK EMPTY
1 1
1 0
0 1 FULL

Table 31: Packet: Communication Channel Mailbox State Definition

Note: The owner of a mailbox is allowed to start a transfer but he has to ensure the mailbox
is empty before starting it.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

DOC060302DPM17EN | Revision 17 | English | 2020-06 | Released | Public © Hilscher, 2006– 2020
Data Transfer Mechanism 47/154
Evaluation of the actual mailbox state can be done by a simple XOR relation of the host and netX
handshake registers and masking out the corresponding command flags:

if (0 == ((usHostFlags ^ usNetxFlags) & HCF_SEND_MAILBOX_CMD))

/* Mailbox empty */
else
/* Mailbox full */

Default Packet Handling

Transmitter Handling Receiver Handling
 Check if the mailbox is empty  Check if the mailbox is full
 Copy packet into the mailbox  Copy packet from the mailbox to a local buffer
 Toggle of the corresponding command flag (e.g.  Toggle of the corresponding acknowledge flag (e.g.
HCF_SEND_MBX_CMD / NCF_RECV_MBX_CMD). HCF_RECEIVE_MBX_ACK / NCF_SEND_MBX_ACK).
Table 32: Packet: Default Packet Handling

Example: Host sending a packet to the device via the Send Mailbox
Step Function / Flags Mailbox State Description

1 Initial state - Host checks if Send Mailbox empty (Flags Equal: both 1 or both 0)

HCF_SEND_MBX_CMD NCF_SEND_MBX_ACK Access allowed by host.

1 1 EMPTY

0 0

2 Host - Send Mailbox Handling

 Host copies a packet to the Send Mailbox
 Host toggles the HCF_SEND_MBX_CMD (10 or 01)
HCF_SEND_MBX_CMD NCF_SEND_MBX_ACK Access switched to netX.

0 1 FULL

1 0

3 netX - Send Mailbox Handling

 netX firmware gets a handshake flag change interrupt
 Firmware checks for Send Mailbox full (Flags Not Equal)
 Firmware copies the packet from the Send Mailbox to internal RAM
 Firmware acknowledges the received packet by toggling
NCF_SEND_MBX_ACK (01 or 10)
HCF_SEND_MBX_CMD NCF_SEND_MBX_ACK Mailbox is empty; access is
switched back to host.
0 0 EMPTY

1 1

Back to Step 1
Table 33: Packet: Send Mailbox Example

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Example: netX device sends a packet to the host via the Receive Mailbox
Step Function / Flags Mailbox State Description

1 Initial state - netX checks if the Receive Mailbox is empty (Flags Equal: both 1 or both 0)

NCF_RECV_MBX_CMD HCF_RECV_MBX_ACK Access allowed by netX.

1 1 EMPTY

0 0

2 netX - Receive Mailbox Handling

 netX copies the packet into the Receive Mailbox
 netX toggles NCF_RECV_MBX_CMD (10 or 01)
NCF_RECV_MBX_CMD HCF_RECV_MBX_ACK Access switched to host.

0 1 FULL

1 0

3 Host - Receive Mailbox Handling

 Host cyclically checks for Receive Mailbox full (Flags Not Equal)
 Host copies the packet from the mailbox to internal RAM
 Host acknowledges the received packet by toggling
HCF_RECEIVE_MBX_ACK (01 or 10)
NCF_RECV_MBX_CMD HCF_RECV_MBX_ACK Mailbox is empty; access is
switched back to netX.
0 0 EMPTY

1 1

Back to step 1
Table 34: Packet: Receive Mailbox Example

Note: The system mailbox works in the same way, with the difference that the flags are called
differently and located in a different handshake register.
Send Mailbox flags  HSF_SEND_MBX_CMD / NSF_SEND_MBX_ACK
Receive Mailbox Flags  NSF_RECV_MBX_CMD / HSF_RECV_MBX_ACK

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.2 Cyclic Data Transfer via Input/Output Data Areas

Cyclic process data of a fieldbus protocol stack (input and output data) is exchanged between
members of a fieldbus network and stored in separate input and output areas. Each area has its
own dedicated synchronization flags.
The input area holds the process data image received from the network whereas the output area
holds data sent to the network.

INPUT/OUTPUT Data Areas

Host Application

OUTPUT Data Area INPUT Data Area

netX Firmware

Figure 12: I/Os: Input / Output Data Areas

When a transfer takes place, either the host or the netX temporarily “owns” the input/output data
area and has exclusive read/write access to it. This guarantees data consistency over the data
areas while the synchronization can be performed independently for each of the areas.
The fieldbus protocol stacks also support different data exchange modes, which define the initiator
of a data transfer and how I/O data from the fieldbus network are handled inside the netX firmware
respectively a fieldbus protocol stack.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.2.1 I/O Data Exchange Modes

I/O data exchange modes are defined to allow a data flow control of I/O data between a fieldbus
network and the host application and the use of a simple synchronization flag mechanism to
ensure data consistency during the transfer.
This might be necessary because the speed of a host system and the network can be different and
a fieldbus protocol may offer additional options to exchange data with the fieldbus system. Both
must be considered in the host application and may influence the data processing and program
flow in the application.

General overview

Host DPM netX

Input Buffer Input Data Area Input Buffer

Output Buffer Output Data Area Output Buffer

Figure 13: I/Os: I/O Data Exchange

A data exchange mode is described by two attributes. The first is the initiator of the transfer,
described as the controlled mode: Host Controlled or Device Controlled. While the second attribute
defines the transfer mode of the I/O data: Buffered or Synchron.
 Controlled Mode Host Controlled or Device Controlled
 Transfer Mode Buffered or Synchron
Both attributes are necessary to cover the possibilities of a data transfer and to handle it correctly.
 Host Controlled Mode
In Host Controlled Mode, the host application initially has access to the I/O data areas in the
DPM and can be the first to read and write data before starting a transfer between the netX
firmware and the DPM.
 Device Controlled Mode
Device Controlled Mode defines the device (netX / fieldbus protocol stack) as the initiator of a
data transfer. In this case the device (netX) initially has access to the I/O data areas inside
the DPM and will activate the data transfer between the host and the DPM.
 Buffered Transfer
Defines that I/O data is automatically transferred between the fieldbus system and internal
buffer inside the netX firmware. A transfer between the internal buffer and the DPM depends
on the Controlled Mode.
 Synchronous Transfer
Defines that I/O data is not buffered inside the device (netX / fieldbus protocol) instead they
are exchanged (read/written) directly with the I/O areas in the DPM. The Controlled Mode
defines the initiator of a transfer.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

The following data exchange modes are defined

Data Exchange Modes Controlled by Consistency Supported by
Buffered Host Controlled (default) Host Yes Master & Slave Firmware
Buffered Device Controlled netX Yes Slave Firmware
Uncontrolled Mode none No currently not supported
Table 35: I/Os: Process Data Exchange Modes

Note: Data exchange modes are a part of the fieldbus protocol configuration which may allow
configuring different exchange modes for the input / output areas but not all
combinations are reasonable.

Meaningful configurations are:

Output Area  Buffer Host Controlled
Input Area  Buffered Host or Device Controlled / Buffered Device Controlled

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.2.1.1 Buffered Host Controlled Mode

The Buffered Host Controlled Mode is the default mode for the transfer of input/output data
between the fieldbus system and the host application and available on master and slave devices.
In Buffered mode, the protocol stack uses internal buffers to store/send cyclic fieldbus data. The
exchange between the local buffers and the DPM is only done if the host application requests an
update. This allows a complete asynchronous handling of I/O data, on both sides, the fieldbus and
the host application.

Note: Network cycle and task cycle of the host application are not synchronized but input and
output data transfer is consistent.

General Definitions

 Host has access to the input and output data area

 Host has to request an update of the input/output area
 A request switches data access to the netX device
 The netX exchanges the content of the requested data with the internal buffer
 The netX confirms the data exchange by switching back data access to the host
Sequence of the process data exchange:
Step Action Figure

1 (1) The application (host) owns access rights to Application

DPM
Protocol Stack Network
2
the input/output data areas in the DPM and is
Input Input
able to read and write the process data Area Buffer

areas.
1

(2) For each valid bus cycle, the protocol stack Output Output
Area Buffer
exchanges the process data with the internal
buffers.

2 (1) The application requests an update of the Application

DPM
Protocol Stack Network

process data areas inside the DPM.

Input Input
1 Area Buffer

Output Output
Area Buffer

3 (1) The protocol stack exchanges the data of Application

DPM
Protocol Stack Network

the requested DPM area (input/output) with 1

Input Input
the internal buffer content. Area Buffer
2

(2) The update process will be acknowledged

1
and access to the DPM areas is switch back Output Output
Area Buffer
to the host application. 2

Goto step 1

Table 36: I/Os: Buffered Host Controlled Mode

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual
DOC060302DPM17EN | Revision 17 | English | 2020-06 | Released | Public © Hilscher, 2006– 2020
Data Transfer Mechanism 53/154
Considerations
 If the host application is faster than the network cycle, it might be possible that data in the
output buffers is overwritten without ever being sent to the network. As for the other direction,
the host application may read the same input values over several read cycles or the protocol
stack may block further input updates by delaying the acknowledgement.
 If the host application is slower than the network cycle, the protocol stack might overwrite the
input buffer with new data received from the network, without it ever being received by the
host application. The output data on the network will be the same over several network
cycles.

Note: In case of a network fault (e.g. network cable disconnect) the protocol stack clears
NCF_COMMUNICATING flag in the netX communication flags usNetXFlags, see
section Communication Channel - Handshake Register on page 27.
Input data should not be evaluated anymore by the host application while output data
can be still exchanged with the protocol stack.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.2.1.2 Buffered Device Controlled Mode

The Buffered Device Controlled Mode defines the netX device (protocol stack) as the initiator of a
data exchange between the protocol stack and the host application.
Like in the Buffered Host Controlled Mode, the Buffered attribute defines the data handling inside
the fieldbus protocol stack, where cyclic fieldbus input/output data is stored to/send via internal
buffers. The exchange of the local buffers with the corresponding DPM areas is activated by the
protocol stack (netX device), which also signals the host application when new data is received
from or send to the fieldbus network.

Note: The Device Controlled Mode is only offered for the input data of slave devices!

The general handling in a host application for data areas transferred in Buffered Device Controlled
Mode, corresponds to the handling in Buffered Host Controlled Mode, except the initiator of a
transfer is the netX device and therefore the evaluation of the synchronization flags is inverted.

General Definitions

 netX device has access to the input and output data area
 netX (protocol stack) signals new data received by the field bus network and written to the
input data area of the DPM
 Access to the DPM input area is switched to the host
 The host copies the input data to a local buffer
 Host confirms the data processing
 Access to the DPM area is switched back to the netX

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Sequence of the process data exchange:

Step Action Picture

1 (1) The application (host) checks if access rights to Application

DPM
Protocol Stack Network

the input area are available.

Input Input
1 Area Buffer 2
(2) The protocol stack takes the input data from the
first valid bus cycle, inserts the data into the
internal buffer and the input DPM area and Output Output
Area Buffer

signals the new data available. This switches

the access right to the host.

2 (1) The application (host) recognizes the new data Application Protocol Stack Network
DPM 2
in the input area. Takes the data from the input
Input Input
area and confirms the processing. Access right Area Buffer

1
to the DPM area is switch back to netX.
(2) While the host has access to the input DPM Output Output
Area Buffer
area, the protocol stack will store any further
received field bus data in the internal input
buffer.

3 (1) The protocol stack recognizes the Application

DPM
1 Protocol Stack Network

acknowledgement from the host. 2

Input Input
Area Buffer
(2) If new data from the field bus are available,
Data is copied to the DPM area and host will be
signaled. Access right is switch to the host. Output Output
Area Buffer

Goto step 2

Table 37: I/Os: Buffered Device Controlled Mode

Considerations:
 If the host application is slower than the network cycle, the protocol stack buffers further
network data and might overwrite the input buffer several times, resulting in data never send
to the host application.
 A protocol stack counts the number of incomplete updates of the input data area in DPM
(see Common Status Block - bErrorPDInCnt) where access was switched to the host
application. This counter can be evaluated by the host application to find out if bus cycles
have been missed.

Note: In case of a network fault (e.g. network cable disconnect) the protocol stack clears the
NCF_COMMUNICATING flag in the netX communication flags usNetXFlags (see
section Communication Channel - Handshake Register on page 27).
Input data should not be evaluated anymore by the host application while output data
can be still exchanged with the protocol stack.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.2.2 I/O Data Area Access Synchronization

Access to the I/O process data areas in the DPM is synchronized by dedicated handshake flags in
the handshake register of the corresponding communication channel.
 I/O Process Data INPUT Flag Definitions
NCF_PD0_IN_CMD / HCF_PD0_IN_ACK
 I/O Process Data OUTPUT Flag Definitions
HCF_PD0_OUT_CMD / NCF_PD0_OUT_ACK

Attention: In the Hil_DualPortMemory.h file there is only ONE definition for the HCF_PD0_ and
NCF_PD0_ handshake bits per direction _IN / _OUT available. Therefore the
interpretation of _CMD / _ACK will change depending on the Controlled Mode by using
the same definition. The correct functional interpretation will be given in brackets (.....)!

Handshake flag definition corresponding to the Controlled Mode:

 Input Data Area Flags
Controlled Mode Host netX

Host Controlled HCF_PD0_IN_ACK(_CMD) NCF_PDO_IN_CMD(_ACK)

Device Controlled HCF_PD0_IN_ACK NCF_PDO_IN_CMD

 Output Data Area Flags

Controlled Mode Host netX

Host Controlled HCF_PDO_OUT_CMD NCF_PDO_OUT_ACK

Device Controlled HCF_PDO_OUT_CMD(_ACK) NCF_PDO_OUT_ACK(_CMD)

Depending on the I/O data exchange mode, the handling of the handshake flags differs for the host
and the netX. The exchange mode is part of the fieldbus protocol stack configuration and
separated for the input and output data area. The current settings can be retrieved from the
Common Status Block of the communication channel.

Handshake Mode Information - Common Status Block

Offset Type Name Description

Input Data Area
0x0020 uint8_t bPDInHskMode Handshake Mode:
Input Process Data Handshake Mode, see page 107.
0x0021 uint8_t bPDInSource Input Process Data Handshake Source
0x002D uint8_t bErrorPDInCnt Number of input process data handshake errors
Output data area
0x0022 uint8_t bPDOutHskMode Handshake Mode:
Output Process Data Handshake Mode, see page 107.
0x0023 uint8_t bPDOutSource Output Process Data Handshake Source
0x002E uint8_t bErrorPDOutCnt Number of output process data handshake errors
Table 38: Input / Output Data Area

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.2.2.1 Synchronization in Buffered Host Controlled Mode

Example: Read INPUT data by the host in Buffered Host Controlled Mode
Step Flags INPUT State Description

1 Initial state - Host has access to the input data area

HCF_PD0_IN_ACK(_CMD) NCF_PD0_IN_CMD(_ACK) FREE Access allowed by host.

1 1

0 0

2 Host - Input Data Handling

 Host checks for access right for the input area (HCF_PD0_IN_ACK equal to NCF_PD0_IN_CMD)
 Host copies the input data from the input data area of the DPM to a local buffer
 Host requests the device to update input data area in the DPM by toggling
HCF_PD0_IN_ACK (10 or 01)
HCF_PD0_IN_ACK(_CMD) NCF_PD0_IN_CMD(_ACK) BUSY Access switched to netX which
should update the data.
0 1

1 0

3 netX - Input Data Handling

 netX gets an interrupt signaling a state change in the handshake flags
 netX checks the state of HCF_PD0_IN_ACK not equal NCF_PD0_IN_CMD (request from host)
 netX has access rights and copies the actual local input data into the input data area of the DPM and
toggles NCF_PD0_IN_CMD (10 or 01)
NCF_PD0_IN_ACK(_CMD) NCF_PD0_IN_CMD(_ACK) DONE Device has updated the INPUT
data; access is switched back
0 0
to host.
1 1

Back to Step 2
Table 39: I/Os: Synchronization in Buffered Host Controlled Mode - Input

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Example: Write OUTPUT data by the host in Buffered Host Controlled Mode
Step Flags OUTPUT State Description

1 Initial state - Host has access to the output data area

HCF_PD0_OUT_CMD NCF_PD0_OUT_ACK FREE Access allowed by host.

1 1

0 0

2 Host - Output Data Handling

 Host checks for access right to output area (HCF_PD0_OUT_CMD equal to NCF_PD0_OUT_ACK)
 Host copies its local data to the output data area of the DPM
 Host signals to the device that new output data is available in the DPM output data area by toggling
HCF_PD0_OUT_CMD (10 or 01)
HCF_PD0_OUT_CMD NCF_PD0_OUT_ACK DATA available Access switched to netX which
should take the data.
0 1

1 0

3 netX - Output Handling

 netX gets an interrupt signaling a state change in the handshake flags
 netX checks the state of HCF_PD0_OUT_CMD not equal NCF_PD0_OUT_ACK (request from host)
 netX copies the data from the DPM output data area into the local output buffer and toggles
NCF_PD0_OUT_ACK (10 or 01) (The Output data will be sent to the network with the next field
bus cycle)
HCF_PD0_OUT_CMD NCF_PD0_OUT_ACK DONE netX has taken the OUTPUT
data; access is switched back
0 0
to host.
1 1

Back to Step 2
Table 40: I/Os: Synchronization in Buffered Host Controlled Mode - Output

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.2.2.2 Synchronization in Buffered Device Controlled Mode

In Device Controlled Mode the initiator of the transfer changes from HOST to netX. While in Host
Controlled Mode the transfer for the INPUT data area was started by toggling HCF_PD0_IN_ACK,
it is now used to acknowledge a transfer. In Device Controlled Mode the transfer starts by toggling
NCF_PD0_IN_CMD.
Example: Read INPUT data by the host in Buffered Device Controlled Mode
Step Flags INPUT State Description

1 Initial state - netX has access to the input data area

NCF_PD0_IN_CMD HCF_PD0_IN_ACK FREE Access allowed by netX.

1 1

0 0

2 netX - Input Handling

 netX gets new input data from the field bus network and stores the data in the local input buffer
 netX checks if handshake flags NCF_PD0_IN_CMD equal to HCF_PD0_IN_ACK. If not
bErrorPDInCnt is incremented and new data will not be signaled to the host
 netX copies the content of the input buffer to the input data area of the DPM and toggles
NCF_PD0_IN_CMD (10 or 01)
NCF_PD0_IN_CMD HCF_PD0_IN_ACK DATA available Access switched to the host,
which should take the data.
0 1

1 0

3 Host - Input Handling

 Host checks if handshake flag NCF_PD0_IN_CMD not equal to HCF_PD0_IN_ACK
 Host copies the input data area from the DPM to a local buffer and toggles
HCF_PD0_IN_ACK (10 or 01)
NCF_PD0_IN_CMD HCF_PD0_IN_ACK DONE Host has taken the INPUT data;
access is switched back to
0 0
device.
1 1

Back to Step 2
Table 41: I/Os: Synchronization in Buffered Device Controlled Mode - Input

Note: Buffered Device Controlled Mode for OUTPUT data is usually not supported by the
protocol stacks.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.3 Change of State Mechanism (COS)

A communication channel has more options and commands than bits (flags) available in the
handshake flag register. Therefore a so called Change of State (COS) mechanism is defined which
extends the direct usable handshake flags by an additional 32 Bit value, including the opportunity
to generate interrupts when the value in the additional 32 Bits is changed.
In other words Change of State (COS) registers are basically extensions to the handshake
registers.
Furthermore, the COS mechanism defines an acknowledgement of state changes before another
state change will be signaled. The mechanism is direction oriented and distinguishes between
state changes from the host application and from the device:
 Communication COS Handling
Describes the handling of additional device states located in the Communication COS
Register in the Common Status Block (see section Common Status Block on page 102).
 Application COS Handling
Describes the handling of additional application states located in the Application COS
Register in the Common Control Block (see section Common Control Block on page 100).
The Change of State Command and Change of State Acknowledge flags are located in the
corresponding handshake registers of the communication channel (see section Communication
Channel - Handshake Register and Flags on page 27).
The COS handling also defines an Enable Flag Handling for signals inside the COS registers.
This simplifies handling of COS signals, because the receiver of the COS information is able to
clearly detect which signals are currently active and which not.
 Enable Flag Handling
Is used to mark signals, inside a COS register, as active (enabled) or not active (disabled).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.3.1 Communication COS Handling

The COS handling is used to signal additional states to the host application.
Sequence of the Communication COS handling

Change Of State (COS) - Communication COS Handling

Host Application DPM Layout

5
4
3 Communication Channel
Communication Channel

Common Status Block structure

Handshake Register NETX_COMMON_STATUS_BLOCK
Host Flags netXFlags
Offset 0x0010 = ulCommunicationCOS

HCF_NETX_COS_ACK NCF_NETX_COS_CMD 2
1

netX Firmware

Figure 14: Change of State Mechanism (COS): Communication COS Handling

Step Description

1 netX Firmware checks if access to the COS information is allowed (COS flags are equal,
NCF_NETX_COS_CMD equal to NCF_NETX_COS_ACK) and updates the COS information in
ulCommunicationCOS.

2 netX firmware toggles the NCF_NETX_COS_CMD which signals new information available to the host.

3 Host cyclically checks if COS flags are not equal (NCF_NETX_COS_CMD unequal to
NCF_NETX_COS_ACK) and if so, new information is available and can be read by the host.

4 Host has access to ulCommunicationCOS and reads the value.

5 Host application acknowledges COS state change by toggling HCF_NETX_COS_ACK.

Table 42: Change of State Mechanism (COS): Communication COS Handling

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.3.2 Application COS Handling

Used to signal additional states / commands to a firmware.
Sequence of the Application COS handling

Change Of State (COS) - Application COS Handling

Host Application DPM Layout

2 1

Communication Channel
Communication Channel

Control Block structure

Handshake Register NETX_CONTROL_BLOCK
Host Flags netXFlags Offset 0x0008 = ulApplicationCOS

NCF_HOST_COS_ACK
HCF_HOST_COS_CMD 5

3 netX Firmware

Figure 15: Change of State Mechanism (COS): Application COS Handling

Step Description

1 Host checks if access to the COS information is allowed (COS flags are equal, HCF_HOST_COS_CMD
equal to NCF_HOST_COS_ACK) and updates the COS information in ulApplicationCOS.

2 Host toggles HCF_HOST_COS_CMD which signals new information available.

3 Firmware gets an interrupt if the COS flags are changed and checks the COS flags for inequality
(HCF_HOST_COS_CMD unequal to NCF_HOST_COS_ACK) and if so, new information is available and can
be read by the firmware

4 netX firmware reads ulApplicationCOS.

5 Firmware acknowledges COS state change by toggling NCF_HOST_COS_ACK.

Table 43: Change of State Mechanism (COS): Application COS Handling

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

4.3.3 Enable Flag Handling

Enable flags are used in the Communication COS and Application COS registers to selectively
activate and deactivate functions, without interfering with each other and to permit an evaluation of
currently activated functions. It also simplifies, for both the initiator and receiver of a command, to
identify actual active commands.

Note: If a command, equipped with an enable flag, should be signaled in the COS register,
the enable flag must be set to 1 (enabled) before the state in the corresponding
command flag will be evaluated by the receiver of the COS command. And the enable
flag must be set to 0 (disabled) after the receiver has acknowledged the recognition of
the command and before a new COS command is initiated.

Example: Signal HIL_APP_COS_BUS_ON, located in the Application COS flags

The command consists of two flags HIL_APP_COS_BUS_ON_ENABLE and
HIL_APP_COS_BUS_ON. It can be used to switch the field bus communication ON and OFF and
the command is executed by the fieldbus protocol stack.
Signal State Description

HIL_APP_COS_BUS_ON_ENABLE 0 = command is not active

1 = command is active

HIL_APP_COS_BUS_ON 0 = switch OFF fieldbus communication

1 = switch ON fieldbus communication

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Default COS Handling

Step Flags COS State Description

1 Initial state - Host has no active COS state

HCF_HOST_COS_CMD NCF_HOST_COS_ACK Free COS signal not active, host can

signal a new state.
1 1

0 0

2 Host - COS Handling - Bus ON command

 Host checks if COS handling is possible (HCF_HOST_COS_CMD equal to NCF_HOST_COS_ACK)
 Host sets the command flag and the enable flag of the new state to signal
(e.g. HIL_APP_COS_BUS_ON = 1 / HIL_APP_COS_BUS_ON_ENABLE = 1)
 Host signals the new state to the device by toggling HCF_HOST_COS_CMD (10 or 01)
HCF_HOST_COS_CMD NCF_HOST_COS_ACK BUSY Access to COS state is switched
to device.
0 1

1 0

3 netX - COS Handling

 netX gets an interrupt signaling a state change in the handshake registers
 netX checks the state of HCF_HOST_COS_CMD not equal NCF_HOST_COS_ACK
(new COS state from the host/request from host)
 netX reads and evaluates the ulApplicationCOS register
(e.g. HIL_APP_COS_BUS_ON == 1 && HIL_APP_COS_BUS_ON_ENABLE == 1)
 netX firmware processes the Bus ON command
 netX acknowledges the COS handling by toggling NCF_HOST_COS_ACK ( 01 or 10)

HCF_HOST_COS_CMD NCF_HOST_COS_ACK DONE Device has processed the COS

flags and access is switched back
0 0
to host.
1 1

4 Host - COS Handling - Deactivation

 Host recognizes a COS acknowledgment (HCF_HOST_COS_CMD equal to NCF_HOST_COS_ACK)
 Host disables the COS command by setting the enable flag HIL_APP_COS_BUS_ON_ENABLE = 0
Goto Step 2
Table 44: Change of State Mechanism (COS): Enable Flag Handling

Note: The COS enable flag handling is identical for the host and the netX commands.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5 DPM Definitions / Mapping and Content

This section describes the DPM mapping in more detail. The presented DPM structures and
definitions are provided by two C header files.
 Hil_DualPortMemory.h
This C header file contains all parts necessary to work with the DPM by using symbolic
names. It provides definitions of the DPM structure, data blocks and all global definitions
offered by the DPM.
 Hil_Packet.h
Provides the Packet definitions

Note: All structures and definitions used in the following chapters can be found in the Hil_*.h
header files.

5.1 DPM Mapping

In the default memory layout, each channel has a fixed structure and a fixed length. The following
chapter describes the structures and elements offered by the DPM layout.
Dual-Port Memory Mapping: Default Mapping (64KByte)
Name Offset Size Description

System Channel (0x000 … 0x01FF)

System Information 0x0000 48 Bytes System Information Area

Channel Information 0x0030 128 Bytes Channel Information Area

Reserved 0x00B0 8 Bytes Reserved

System Control 0x00B8 8 Bytes System Control and Commands

System Status 0x00C0 64 Bytes System Status Information

System Mailboxes 0x0100 256 Bytes System Send / Receive Mailbox

Handshake Channel (0x0200 … 0x02FF)

Handshake Register 0x0200 64 Bytes Handshake Registers Area

Reserved 0x0240 192 Bytes Reserved

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Name Offset Size Description

Communication Channel 0 (0x0300 … 0x3FFF)

Reserved 0x0300 8 Bytes Reserved

Common Control Block 0x0308 8 Bytes Common Control Register

Common Status Block 0x0310 64 Bytes Common Protocol Stack Status Information
Extended Status Block 0x0350 432 Bytes Network Specific Information
Send Mailbox 0x0500 1600 Bytes Send Mailbox for Non-Cyclic Data Transfer
Receive Mailbox 0x0B40 1600 Bytes Receive Mailbox for Non-Cyclic Data Transfer
Output Data Image 1 0x1180 64 Bytes High Priority Output Process Data Image
Input Data Image 1 0x11C0 64 Bytes High Priority Input Process Data Image
Reserved 0x1200 256 Bytes Reserved for Future Use, Set to Zero
Output Data Image 0 0x1300 5760 Bytes Cyclic Output Process Data Image
Input Data Image 0 0x2980 5760 Bytes Cyclic Input Process Data Image

Communication Channel 1..3 (0x4000 …)

Comm. Channel 1 0x4000 15616 Bytes Structure see Communication Channel 0
Comm. Channel 2 0x7D00 15616 Bytes Structure see Communication Channel 0
Comm. Channel 3 0xBA00 15616 Bytes Structure see Communication Channel 0

Application Channel 0..1

App. Channel 0/1 unknown unknown Application channel not defined yet
Table 45: DPM Mapping: Default Mapping

 Default DPM size of 64 KByte (65536 Byte) results from the sizes of the System Channel,
Handshake Channel and 4 Communication Channels.
 The default communication channel size is 15616 Byte.

Note: The firmware will set the Default Memory Map flag in the System COS field in System
Status block, if the default memory layout is used.

Note: The default mapping is also available with 16 KByte DPM size, but than with only one
communication channel.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Dual-Port Memory Mapping: 8Kbyte Mapping

Name Offset Size Description

System Channel (0x000 … 0x01FF)

System Information 0x0000 48 Bytes System Information Area

Channel Information 0x0030 128 Bytes Mapping Information

Reserved 0x00B0 8 Bytes Reserved

System Control Block 0x00B8 8 Bytes System Control and Commands

System Status Block 0x00C0 64 Bytes System Status Information

System Mailboxes 0x0100 256 Bytes System Send / Receive Mailbox

Handshake Channel (0x0200 … 0x02FF)

Handshake Register 0x0200 64 Bytes Cumulated Handshake Registers

Reserved 0x0240 192 Bytes Reserved

Communication Channel 0 (0x0300 … 0x1FFF)

Reserved 0x0300 8 Bytes Reserved

Common Control Block 0x0308 8 Bytes Common Control Register

Common Status Block 0x0310 64 Bytes Common Protocol Stack Status Information
Extended Status Block 0x0350 432 Bytes Network Specific Information
Send Mailbox 0x0500 1600 Bytes Send Mailbox for Non-Cyclic Data Transfer
Receive Mailbox 0x0B40 1600 Bytes Receive Mailbox for Non-Cyclic Data Transfer
Output Data Image 1 0x1180 64 Bytes High Priority Cyclic Output Process Data Image
Input Data Image 1 0x11C0 64 Bytes High Priority Cyclic Input Process Data Image
Reserved 0x1200 256 Bytes Reserved for Future Use, Set to Zero
Output Data Image 0 0x1300 1536 Bytes Cyclic Output Process Data Image
Input Data Image 0 0x1900 1536 Bytes Cyclic Input Process Data Image

Reserved Area (0x1F00 … 0x1FFF)

Reserved 0x1F00 256 Bytes Reserved for Future Use, set to Zero
Table 46: DPM Mapping: 8 Kbyte Mapping

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.2 System Channel

The System Channel is the first channel in the dual-port. It holds information about the system
itself (netX firmware/netX operating system) and provides a mailbox transfer mechanism for
system related messages or packets.

Note: Offsets are given relative to the start offset of the System Channel start address.

Structure of the System Channel

System Channel: NETX_SYSTEM_CHANNEL DPM Start Offset = 0x0000

Offset Type Name Description

0x0000 Structure tSystemInfo System Information Block
Identifies netX Dual-Port Memory
See section System Information Block on page 69.
0x0030 Structure atChannelInfo[8] Channel Information Block
Contains Configuration Information about available
Communication and Application Channel Blocks.
See section Channel Information Block on page 80.
0x00B0 Structure tSysHandshake System Handshake Block
(not used, set to zero)
0x00B4 uint8_t bReserved[4] Reserved
0x00B8 Structure tSystemControl System Control Block
System Control and Commands
See section System Control Block on page 88.
0x00C0 Structure tSystemState System Status Block
System Status Information
See section System Status Block on page 90.
0x0100 Structure tSystemSendMailbox System Mailboxes
0x0180 tSystemRecvMailbox System Send and Receive Packet Mailbox Area, always
located at the end of the System Block.
See section System Mailbox on pabe 94.
Table 47: System Channel: System Channel Structure

System Channel Structure Reference

typedef struct NETX_SYSTEM_CHANNELtag
{
NETX_SYSTEM_INFO_BLOCK tSystemInfo;
NETX_CHANNEL_INFO_BLOCK atChannelInfo[8];
NETX_HANDSHAKE_CELL tSysHandshake;
uint8_t abReserved[4];
NETX_SYSTEM_CONTROL_BLOCK tSystemControl;
NETX_SYSTEM_STATUS_BLOCK tSystemState;
NETX_SYSTEM_SEND_MAILBOX tSystemSendMailbox;
NETX_SYSTEM_RECV_MAILBOX tSystemRecvMailbox;
} NETX_SYSTEM_CHANNEL;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.2.1 System Information Block

The System Information Block helps to identify the netX dual-port memory and holds general
information about the netX device including a cookie, DPM length as well as information regarding
the firmware running on the netX.
Structure of the System Information Block
System Information Block: NETX_SYSTEM_INFO_BLOCK
Offset Type Name Description
0x0000 uint8_t abCookie[4] netX DPM Identification (start of DPM)
ASCII characters:
'netX’ = firmware is running
0x0004 uint32_t ulDpmTotalSize DPM Size in bytes (see page 70)
0x0008 uint32_t ulDeviceNumber Device Number (see page 71)
0x000C uint32_t ulSerialNumber Serial Number (see page 71)
0x0010 uint16_t ausHwOptions[4] Hardware Assembly Options (see page 71)
0x0018 uint16_t usManufacturer Manufacturer Code (see page 73)
0x001A uint16_t usProductionDate Production Date (see page 74)
0x001C uint32_t ulLicenseFlags1 License Code - Flags 1 (see page 75)
0x0020 uint32_t ulLicenseFlags2 License Code - Flags 2 (see page 75)
0x0024 uint16_t usNetxLicenseID netX License Identification (see page 75)
0x0026 uint16_t usNetxLicenseFlags netX License Flags (see page 75)
0x0028 uint16_t usDeviceClass Device Class (see page 77)
0x002A uint8_t bHwRevision Hardware Revision (see page 79)
0x002B uint8_t bHwCompatibility Hardware Compatibility (see page 79)
Hardware Device Identification Number
0x002C uint8_t bDevIdNumber
(DIP-switch / Rotary Switch, see page 79)
Reserved
0x002D uint8_t bReserved
Set to Zero
0x002E Reserved
uint16_t usReserved
… 0x002F Set to Zero
Table 48: System Channel: System Information Block

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

System Information Block Structure Reference

typedef struct NETX_SYSTEM_INFO_BLOCKtag
{
uint8_t abCookie[4]; /* 'netX' cookie */
uint32_t ulDpmTotalSize; /* DPM size (in bytes) */
uint32_t ulDeviceNumber; /* device number */
uint32_t ulSerialNumber; /* serial number */
uint16_t ausHwOptions[4]; /* hardware options */
uint16_t usManufacturer; /* manufacturer */
uint16_t usProductionDate; /* production date */
uint32_t ulLicenseFlags1; /* license flags 1 */
uint32_t ulLicenseFlags2; /* license flags 2 */
uint16_t usNetxLicenseID; /* license ID */
uint16_t usNetxLicenseFlags; /* license flags */
uint16_t usDeviceClass; /* device class */
uint8_t bHwRevision; /* hardware revision */
uint8_t bHwCompatibility; /* hardware compatibility */
uint8_t bDevIdNumber; /* device identification */
uint8_t bReserved;
uint16_t usReserved;
} NETX_SYSTEM_INFO_BLOCK;

netX DPM Identification

The netX DPM Identification abCookie[4], identifies the start of the dual-port memory. It has a
length of 4 bytes and is always present if a netX firmware is running.

Note: The cookie is the last element, initialized by the firmware. The firmware ensures, if a
valid value is inserted in the cookie, all other elements of the DPM are initialized.

Variable Value Definition / Description

abCookie[4] 'netX' netX Firmware cookie

'BOOT' netX Bootloader cookie

0x0BAD Bad memory content (HIL_SYS_BAD_MEMORY_COOKIE), memory is not
correctly mapped by the firmware or no firmware running.
0xFFFF DPM not available
Table 49: System Channel: netX Identification, netX Cookie

Dual-Port Memory Size

The size field ulDpmTotalSize holds the total size of the dual-port memory in bytes (8 Kbyte /
16 KByte / 64 KByte). The usable size may differ because each channel defines an own layout.
If the default memory layout is used, the usable size is 16 Kbyte (see section DPM Mapping on
page 65).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Device Number

The device number given in ulDeviceNumber holds the hardware order or item number of a
device. The number is given as a hexadecimal number and follows the following format:
xxx.yyyy.zzz.
Example:
A value of 0x499602D2 is translated into the decimal value of 1234567890 which results in an
order number of 123.4567.890
If the value is equal to zero, the device number is not set.

Serial Number

The serial number given in ulSerialNumber holds the hardware serial number used in
conjunction with the device number to uniquely identify a device. It is a 32-bit value given as
hexadecimal number.
For netX 50/51/52/100/500: The Serial Number is read from the SecurityMemory, if a
SecurityMemory is available. If no SecurityMemory is available, the Serial Number is read from the
Flash Device Label (FDL) and will be used. If no FDL is available, a default Serial Number "8194"
will be used.
For netX 90/4000: The Serial Number is read from the Flash Device Label (FDL) and will be used.
If no FDL is available, the serial number is set to zero.
Example:
A value of 0x00004E21 compares to the decimal number 20021.

Hardware Assembly Options (xC Port 0..3)

The assembly option defines the physical hardware interface connected to a netX xC
(Communication Controller) port. A netX chip offers up to 4 xC ports and the assembly option is an
array of 4 elements (ausHWOptions[4]) where each element holds the definition of one xC port
(Port 0..3).
The definition is necessary because each fieldbus protocol has specific requirements to the
physical interface and only with a correct assembled physical interface the communication on the
fieldbus system is possible.
Hardware Assembly Options
Variable: ausHWOptions

Value Definition / Description

0x0000 HIL_HW_ASSEMBLY_UNDEFINED
The xC port is marked UNDEFINED, if the hardware cannot be determined. This might be the case, if no
security memory / device label is found or read access to it failed.
0x0001 HIL_HW_ASSEMBLY_NOT_AVAILABLE
The xC port is not available (netX50 will show this for xC2 / xC3)
0x0003 HIL_HW_ASSEMBLY_USED
The xC port is marked used if a port is already used by another component of the netX firmware (e.g.
another protocol stack or other functionalities)
0x0010 HIL_HW_ASSEMBLY_SERIAL
A serial RS232 interface is connected to the xC port

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Variable: ausHWOptions

Value Definition / Description

0x0020 HIL_HW_ASSEMBLY_ASI
The connected interface allows communication according to the AS-INTERFACE standard
0x0030 HIL_HW_ASSEMBLY_CAN
The connected interface allows communication according to the CAN (Controller Area Network)
specification
0x0040 HIL_HW_ASSEMBLY_DEVICENET
The connected interface allows communication according to the DeviceNet specification
0x0050 HIL_HW_ASSEMBLY_PROFIBUS
The connected interface allows communication according to the PROFIBUS specification
0x0070 HIL_HW_ASSEMBLY_CCLINK
The connected interface allows communication according to the CC-Link specification
0x0071 HIL_HW_ASSEMBLY_CCLINK_IE_FIELD_1GB
The connected interface allows communication via 1 GBit/s Ethernet (external Phy) according to the CC-
Link IE Field specification
0x0080 HIL_HW_ASSEMBLY_ETHERNET (internal Phy)
The connected interface allows communication via Ethernet (internal Phy)
0x0081 HIL_HW_ASSEMBLY_ETHERNET_X_PHY (external Phy)
The connected interface allows communication via Ethernet (external Phy)
0x0082 HIL_HW_ASSEMBLY_ETHERNET_FIBRE_OPTIC (internal Phy)
The connected interface allows communication via Ethernet (internal Phy) with connected fiber optics
0x0083 HIL_HW_ASSEMBLY_ETHERNET_TAP
The connected interface allows capturing from Ethernet
0x0090 HIL_HW_ASSEMBLY_SPI (Serial Peripheral Interface)
The connected interface allows communication via a SPI (Serial Peripheral Interface) interface
0x00A0 HIL_HW_ASSEMBLY_IO_LINK
The connected interface allows communication according to the IO-Link specification
0x00B0 HIL_HW_ASSEMBLY_COMPONET
The connected interface allows communication according to the CompoNet specification
0xFFF4 HIL_HW_ASSEMBLY_I2C_UNKNOWN
I2C is used to determine physical interface but Interface can't be determined (e.g. option module is not
connected)
0xFFF5 HIL_HW_ASSEMBLY_SSI
The physical interface is SSI conform
0xFFF6 HIL_HW_ASSEMBLY_SYNC
xC port is used for special synchronization signals
0xFFFA HIL_HW_ASSEMBLY_TOUCH_SCREEN
xC port is connected to a touch screen interface
0xFFFB HIL_HW_ASSEMBLY_I2C_PIO
I2C is used to determine physical interface. This is used for option modules (AIFX modules) offering the
identification via I2C. If the detection of the option module succeeds, the value is replaced by the real
information from the option module.
If the module detection fails, I2C INTERFACE UNKNOWN is shown.
0xFFFC HIL_HW_ASSEMBLY_I2C_PIO_NT (netTAP device)
I2C is used to determine a physical interface on a netTAP hardware platform.
If the detection succeeds, the value is replaced by the real information from the option module
0xFFFD HIL_HW_ASSEMBLY_PROPRIETARY
Unspecified physical interface

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Variable: ausHWOptions

Value Definition / Description

0xFFFE HIL_HW_ASSEMBLY_NOT_CONNECTED
No physical interface connectable to the xC port (the xC port can only be used for chip-internal purposes)
0xFFFF RESERVED, DO NOT USE
Table 50: System Channel: Hardware Assembly Options (xC Port 0..3)

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Manufacturer

The manufacturer code defines the manufacturer of the device (hardware)

Variable: usManufacturer

Value Definition / Description

0x0000 HIL_MANUFACTURER_UNDEFINED
Undefined manufacturer
0x0001... HIL_MANUFACTURER_HILSCHER_GMBH
Manufacturer is Hilscher Gesellschaft für Systemautomation mbH
Note: 0x0001...0x000FF reserved for Hilscher
... 0x00FF HIL_MANUFACTURER_HILSCHER_GMBH_MAX
Other values are usable for third party manufacturers and given by Hilscher
Table 51: System Channel: Manufacturer

Production Date

The production date entry is comprised of the calendar week and year (starting with year 2000)
when the hardware was produced. Both, year and week are shown in hexadecimal notation.
If the value is equal to zero, the manufacturer date is not set.
Variable: usProductionDate

Bit No. 15..8 = Production Year Bit No 7..0 = Production (Calendar) Week
0 - 255 (+2000) 1 - 52
Table 52: System Channel: Production Date

Example:
Production Date = 0x062B indicates year = 2006 / production week = 43

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

License Flags 1 / License Flags 2

License flags contain license information for the netX firmware and tools and are used to enable
functionalities which are protected by them. The flags are stored in a security memory on the
hardware and read during system startup.
If the license information fields / flags are zero, a license or license code is not set.
License Flags 1 are used to enable fieldbus master protocol stacks.
 Bits 0 to bit 29 License flags dedicated to a specific protocol stack
 Bits 30 and 31 Number of concurrent master protocol stack licenses

Variable: ulLicenseFlags1
31 30 29 … 8 7 6 5 4 3 2 1 0 Bit Number
PROFIBUS Master
CANopen Master
DeviceNet Master
AS-Interface Master
PROFINET IO RT Controller
EtherCAT Master
EtherNet/IP Scanner
SERCOS III Master
Reserved, Set to Zero
00 = Unlimited Number of Master Licenses
01 = 1 Master License
10 = 2 Master Licenses
11 = 3 Master Licenses
Table 53: System Channel: License Flags 1

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

License Flags 2 are used for tool licensing, e. g. SYCON.net, OPC servers and drivers etc.
If a flag is set, a tool license is present.

Variable: ulLicenseFlags2
31 … 8 7 6 5 4 3 2 1 0 Bit Number
SYCON.net
OPC Server
QViS
01 = Minimum Size
10 = Standard Size
11 = Maximum Size
CoDeSys (Hilscher)
01 = Minimum Size
10 = Standard Size
11 = Maximum Size
Driver / Operating System (Host Application)
Atvise Web Server
Reserved, Set to Zero
Table 54: System Channel: License Flags 2

netXLicenseID / netXLicenseFlags

netX license ID and flags (usNetxLicenseID / usNetxLicenseFlags) are reserved for OEM
customers allowing them to integrate their own license definition.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Device Class

The device class is used to create device groups specified by their functionality and hardware
options (e.g. used netX chip, special functionalities). This is necessary because a netX firmware
may not support all hardware devices or just one specific device.
The netX firmware file header also contains a device class definition, specifying which devices are
supported. This information can be used by host applications to verify if a given firmware will work
on a device before downloading it to the hardware.
The following hardware device classes are defined (variable usDeviceClass).
Value Definition Description
0x0000 HIL_HW_DEV_CLASS_UNDEFINED Hardware is not defined
0x0001 HIL_HW_DEV_CLASS_UNCLASSIFIABLE Hardware not classifiable
0x0002 HIL_HW_DEV_CLASS_CHIP_NETX_500 netX500 chip based hardware
0x0003 HIL_HW_DEV_CLASS_CIFX All PC cards (ISA/PCI/PCIe)
0x0004 HIL_HW_DEV_CLASS_COMX_100 COMX module netX00 based
0x0005 HIL_HW_DEV_CLASS_EVA_BOARD netX Evaluation board (e.g. NXHX51)
0x0006 HIL_HW_DEV_CLASS_NETDIMM netDIMM netX500 chip based DIMM module
0x0007 HIL_HW_DEV_CLASS_CHIP_NETX_100 netX100 chip based
0x0008 HIL_HW_DEV_CLASS_NETX_HMI netHMI hardware
0x0009 reserved reserved
0x000A HIL_HW_DEV_CLASS_NETIO_50 netIO netX50 based I/O module
0x000B HIL_HW_DEV_CLASS_NETIO_100 netIO netX100 based I/O module
0x000C HIL_HW_DEV_CLASS_CHIP_NETX_50 netX50 based hardware
0x000D HIL_HW_DEV_CLASS_GW_NETPAC netPAC Gateway
0x000E HIL_HW_DEV_CLASS_GW_NETTAP netTAP netX100 based Gateway
0x000F HIL_HW_DEV_CLASS_NETSTICK netSTICK netX50 based USB stick
0x0010 HIL_HW_DEV_CLASS_NETANALYZER netANALYZER PC card
0x0011 HIL_HW_DEV_CLASS_NETSWITCH netSWITCH Ethernet switch
0x0012 HIL_HW_DEV_CLASS_NETLINK netLINK network linking
0x0013 HIL_HW_DEV_CLASS_NETIC_50 netIC netX50 based DIL-32 communication IC
0x0014 HIL_HW_DEV_CLASS_NPLC_C100 netPLC netX100 based PLC PC card
0x0015 HIL_HW_DEV_CLASS_NPLC_M100 netPLC netX100 based PLC module
0x0016 HIL_HW_DEV_CLASS_GW_NETTAP_50 netTAP netX50 based Gateway
0x0017 HIL_HW_DEV_CLASS_NETBRICK netBRICK netX100 based Gateway (IP67)
0x0018 HIL_HW_DEV_CLASS_NPLC_T100 netPLC netX100 based PLC module (DIN rail)
0x0019 HIL_HW_DEV_CLASS_NETLINK_PROXY netLINK proxy
0x001A HIL_HW_DEV_CLASS_CHIP_NETX_10 netX10 based hardware
0x001B HIL_HW_DEV_CLASS_NETJACK_10 netJACK netX10 based exchangeable module
0x001C HIL_HW_DEV_CLASS_NETJACK_50 netJACK netX50 based exchangeable module
0x001D HIL_HW_DEV_CLASS_NETJACK_100 netJACK netX100 based exchangeable module
0x001E HIL_HW_DEV_CLASS_NETJACK_500 netJACK netX500 based exchangeable module
0x001F HIL_HW_DEV_CLASS_NETLINK_10_USB netLINK netX10 based with USB connection
0x0020 HIL_HW_DEV_CLASS_COMX_10 COMX module netX10 based
0x0021 HIL_HW_DEV_CLASS_NETIC_10 netIC netX10 based DIL-32 communication IC
0x0022 HIL_HW_DEV_CLASS_COMX_50 COMX module netX50 based
0x0023 HIL_HW_DEV_CLASS_NETRAPID_10 netRAPID netX10 based ready to solder chip-carrier
0x0024 HIL_HW_DEV_CLASS_NETRAPID_50 netRAPID netX50 based ready to solder chip-carrier

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition Description

0x0025 HIL_HW_DEV_CLASS_NETSCADA_T51 netSCADA netX51 based visualizing modem
0x0026 HIL_HW_DEV_CLASS_CHIP_NETX_51 netX51 based hardware
0x0027 HIL_HW_DEV_CLASS_NETRAPID_51 netRAPID netX51 based ready to solder chip-carrier
0x0028 HIL_HW_DEV_CLASS_GW_EU5C EU5C Gateway
0x0029 HIL_HW_DEV_CLASS_NETSCADA_T50 netSCADA netX50 based visualizing modem
0x002A HIL_HW_DEV_CLASS_NETSMART_50 netSMART netX50 based Smartwire module
0x002B HIL_HW_DEV_CLASS_IOLINK_GW_51 netX51 bases IO-LINK gateway
0x002C HIL_HW_DEV_CLASS_NETHMI_B500 netHMI netX500 based operator panel
0x002D HIL_HW_DEV_CLASS_CHIP_NETX_52 netX52 based hardware
0x002E HIL_HW_DEV_CLASS_COMX_51 COMX module netX51 based
0x002F HIL_HW_DEV_CLASS_NETJACK_51 netJACK netX51 based exchangeable module
0x0030 HIL_HW_DEV_CLASS_NETHOST_T100 netHOST netX100 based Lan controlled master
0x0031 HIL_HW_DEV_CLASS_NETSCOPE_C100 netSCOPE netX100 based PC card
0x0032 HIL_HW_DEV_CLASS_NETRAPID_52 netRAPID netX52 based ready to solder chip-carrier
0x0033 HIL_HW_DEV_CLASS_NETSMART_T51 netSMART netX51 based Smartwire module
0x0034 HIL_HW_DEV_CLASS_NETSCADA_T52 netSCADA netX52 based visualizing modem
0x0035 HIL_HW_DEV_CLASS_NETSAFETY_51 netSAFETY nex51 based safety module
0x0036 HIL_HW_DEV_CLASS_NETSAFETY_52 netSAFETY nex52 based safety module
0x0037 HIL_HW_DEV_CLASS_NETPLC_J500 netPLC netX500 based PLC module
0x0038 HIL_HW_DEV_CLASS_NETIC_52 netIC netX52 based (DIL-32 communication IC)
0x0039 HIL_HW_DEV_CLASS_GW_NETTAP_151 netTAP151 dual netX51 based Gateway
0x003A HIL_HW_DEV_CLASS_CHIP_NETX_4000_COM Device with netX 4000 (COM CPU)
0x003B Reserved Reserved
0x003C HIL_HW_DEV_CLASS_CHIP_NETX_90_COM Device with netX 90 (COM CPU)
0x003D HIL_HW_DEV_CLASS_NETRAPID_51_IO netRAPID netX51 based for I/O ready to solder chip-carrier
0x003E HIL_HW_DEV_CLASS_GW_NETTAP_151_CCIES netTAP151 netX100 and netX51 based Gateway for CC-Link IE
Slave
0x003F HIL_HW_DEV_CLASS_CIFX_CCIES PC cards for CC-Link IE Slave with 1 GBit Ethernet
0x0040 HIL_HW_DEV_CLASS_COMX_51_CCIES COMX module netX 51 based for CC-Link IE Field Slave with 1
GBit Ethernet
0x0041 HIL_HW_DEV_CLASS_NIOT_E_NPEX_BP52_IO netPI Extension Base Plate netX 52 based with I/O
0x0042 HIL_HW_DEV_CLASS_NIOT_E_NPEX_BP52_IOL netPI Extension Base Plate netX 52 based with IO-Link and I/O
0x0043 HIL_HW_DEV_CLASS_CHIP_NETX_4000_COM_ Device with netX 4000 (COM CPU) and SDRAM at host interface
HIFSDR
0x0044 HIL_HW_DEV_CLASS_CHIP_NETX_4000_COM_ Device with netX 4000 (COM CPU) and SDRAM at memory
SDR interface
0x0045 HIL_HW_DEV_CLASS_CHIP_NETX_90_COM_ Device with netX 90 (communication) and SDRAM at host
HIFSDR interface
0x0046 HIL_HW_DEV_CLASS_NETFIELD_COM netFIELD device with netX 90 (communication) and netIOL
0x0047 HIL_HW_DEV_CLASS_COMX_52 COMX module netX 52 based
0x0048 … Reserved Reserved
0x7FFF
0x8000 … Reserved Reserved
0xEFFF
0xFFFE HIL_HW_DEV_CLASS_OEM_DEVICE OEM Device
Other values are reserved -
Table 55: System Channel: Device Class

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Hardware Revision

The hardware revision field indicates the current revision of a module. In difference to the printed
device label, the revision field counts from 1 to 35 while the printed label shows the letters A to Z
for revision numbers greater 9.
Variable: bHwRevision

Revision number Revision Field Printed Device Label

1..9 1..9 1..9
10..35 10..35 A..Z
Table 56: System Channel: Hardware Revision

Hardware Compatibility Index

The hardware compatibility index bHwCompatibility is used to indicate incompatible hardware

changes during the life time of a hardware product. The index starts with 0 and is incremented for
every incompatible hardware change made to the hardware. The same index also exists in the
header of a netX firmware file which allows a host application to match a firmware index against a
given hardware index. This allows a host application to prevent a firmware download if necessary.

Device Identification Number

The device identification number bDevIdNumber is intended to be used as a uniquely distinction

of hardware modules/cards from each other. This might be necessary if multiple modules/cards of
the same type are used at the same time on one host system (e.g. multiple PCI cards in a PC
system).
The creation of the identification number is hardware based and needs either a DIP switch or
Rotary switch equipped on the modules/cards. In this case the setting from the switch will be read
by the firmware and shown in the identification number.
A zero (0) indicates that no identification number was assigned to the device. The value range of
the identification number depends on the used DIP switch/Rotary switch (usually between 0..9).

Note: The Device Identification Number is a hardware created number and the hardware
must support this option. It should not be mixed up with any addresses from a fieldbus
system (e.g. slave address on a fieldbus network).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.2.2 Channel Information Block

The channel information block structure holds information about the channels available in the dual-
port memory. A channel description is a 16 bytes structure and the first element (bChannelType)
of the structure defines the channel type and therefore the corresponding channel structure.
Structure of the Channel Information Block:
Channel Information Block: NETX_CHANNEL_INFO_BLOCK
Address Channel Structure Name: NETX_SYSTEM_CHANNEL_INFO
0x0030 System Channel Data Type Description
uint8_t Channel Type = SYSTEM (see page 82)
uint8_t Reserved (set to zero)
uint8_t Size / Position of Handshake Registers
uint8_t Total Number of Blocks
uint32_t Size of Channel in Bytes
uint16_t Size of Send and Receive Mailbox in Bytes
uint16_t Mailbox Start Offset
… 0x003F uint8_t[4] 4 Byte Reserved (set to zero)
Address Channel Structure Name: NETX_HANDSHAKE_CHANNEL_INFO
0x0040 Handshake Channel Data Type Description
uint8_t Channel Type = HANDSHAKE (see page 82)
uint8_t[3] 3 Byte Reserved (set to zero)
uint32_t Channel Size in Bytes
… 0x004F uint8_t[8] 8 Byte Reserved
Address Channel Structure Name: NETX_COMMUNICATION_CHANNEL_INFO
0x0050 Communication Channel 0 Data Type Description
uint8_t Channel Type = COMMUNICATION (see page 82)
uint8_t Channel ID, Channel Number
uint8_t Size / Position of Handshake Registers
uint8_t Total Number of Blocks in this Channel
uint32_t Size of Channel in Bytes
uint16_t Communication Class (Master, Slave...)
uint16_t Protocol Class (PROFIBUS, PROFINET....)
uint16_t Protocol Conformance Class (DPV1, DPV2...)
… 0x005F uint8_t[2] 2 Byte Reserved (set to zero)
0x0060.. Communication Channel 1, 2 &
Structure Same as Communication Channel 0
… 0x008F 3

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

DOC060302DPM17EN | Revision 17 | English | 2020-06 | Released | Public © Hilscher, 2006– 2020
DPM Definitions / Mapping and Content 81/154
Address Channel Structure Name: NETX_APPLICATION_CHANNEL_INFO
0x0090 Application Channel 0 Data Type Description
uint8_t Channel Type = APPLICATION (see page 82)
uint8_t Channel ID, Channel Number
uint8_t Size / Position of Handshake Registers
uint8_t Total Number of Blocks in this Channel
uint32_t Size of Channel in Bytes
… 0x009F uint8_t [8] 8 Byte Reserved (set to zero)
0x00A0
Application Channel 1 Structure Same as Application Channel 0
… 0x00AF
Table 57: System Channel: Channel Information Block

Structure Reference: NETX_CHANNEL_INFO_BLOCK

typedef union NETX_CHANNEL_INFO_BLOCKtag
{
NETX_SYSTEM_CHANNEL_INFO tSystem;
NETX_HANDSHAKE_CHANNEL_INFO tHandshake;
NETX_COMMUNICATION_CHANNEL_INFO tCom;
NETX_APPLICATION_CHANNEL_INFO tApp;
} NETX_CHANNEL_INFO_BLOCK;

Structure Reference: NETX_SYSTEM_CHANNEL_INFO

typedef struct NETX_SYSTEM_CHANNEL_INFOtag
{
uint8_t bChannelType;
uint8_t bReserved;
uint8_t bSizePositionOfHandshake;
uint8_t bNumberOfBlocks;
uint32_t ulSizeOfChannel;
uint16_t usSizeOfMailbox;
uint16_t usMailboxStartOffset;
uint8_t abReserved[4];
} NETX_SYSTEM_CHANNEL_INFO;

Structure Reference: NETX_HANDSHAKE_CHANNEL_INFO

typedef struct NETX_HANDSHAKE_CHANNEL_INFOtag
{
uint8_t bChannelType;
uint8_t bReserved[3];
uint32_t ulSizeOfChannel;
uint8_t abReserved[8];
} NETX_HANDSHAKE_CHANNEL_INFO;

Structure Reference: NETX_COMMUNICATION_CHANNEL_INFO

typedef struct NETX_COMMUNICATION_CHANNEL_INFOtag
{
uint8_t bChannelType;
uint8_t bChannelId;
uint8_t bSizePositionOfHandshake;
uint8_t bNumberOfBlocks;
uint32_t ulSizeOfChannel;
uint16_t usCommunicationClass;
uint16_t usProtocolClass;
uint16_t usConformanceClass;
uint8_t abReserved[2];
} NETX_COMMUNICATION_CHANNEL_INFO;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Structure Reference: NETX_APPLICATION_CHANNEL_INFO

typedef struct NETX_APPLICATION_CHANNEL_INFOtag
{
uint8_t bChannelType;
uint8_t bChannelId;
uint8_t bSizePositionOfHandshake;
uint8_t bNumberOfBlocks;
uint32_t ulSizeOfChannel;
uint8_t abReserved[8];
} NETX_APPLICATION_CHANNEL_INFO;

Channel Type

This field identifies the channel type of the corresponding memory location. The following channel
types are defined.
Variable: bChannelType

Value Definition Description

0x00 HIL_CHANNEL_TYPE_UNDEFINED Undefined
0x01 HIL_CHANNEL_TYPE_NOT_AVAILABLE Not available
0x02 HIL_CHANNEL_TYPE_RESERVED Reserved
0x03 HIL_CHANNEL_TYPE_SYSTEM System Channel
0x04 HIL_CHANNEL_TYPE_HANDSHAKE Handshake Channel
0x05 HIL_CHANNEL_TYPE_COMMUNICATION Communication Channel
0x06 HIL_CHANNEL_TYPE_APPLICATION Application Channel
0x07 Reserved Reserved for future use
…
0x7F
0x80 HIL_CHANNEL_TYPE_USER_DEFINED_START Start of user defined channels
…
0xFF
Table 58: System Channel: Channel Type

Channel ID, Channel Number (Communication and Application Channel Only)

The value given in bChannelId is used to enumerate the communication and application
channels. The value is unique in the system and ranges from 0 to 7 and corresponds to the order
of a channel in the DPM (e.g. Communication Channel 0 = 0, Communication Channel 1 = 1 etc.).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Size / Position of Handshake Registers

This field identifies the position of the handshake registers and their size. The handshake registers
may be located at the beginning of the channel itself or in a separate handshake area.
The size of the handshake registers can be either 8 or 16 bit.
Variable: bSizePositionOfHandshake

Bit No. Definition / Description

0..3 Handshake Register Size
0 = HIL_HANDSHAKE_SIZE_NOT_AVAILABLE
1 = HIL_HANDSHAKE_SIZE_8BIT (default for the System Channel)
2 = HIL_HANDSHAKE_SIZE_16BIT (default for the Communication Channel)
Other values are reserved
4..7 Handshake Register Position
0 = HIL_HANDSHAKE_POSITION_BEGINNING (located at the beginning of a channel)
1 = HIL_HANDSHAKE_POSITION_CHANNEL (default: located in the handshake channel)
Other values are reserved
Table 59: System Channel: Size / Position of Handshake Registers

Total Number of Blocks

A channel consists of data blocks (e.g. mailbox and status blocks) and the number of blocks
bNumberOfBlocks indicates how many blocks are contained in the channel structure.

Size of Channel

This field ulSizeOfChannel contains the size of the entire channel in bytes.

Size of Send and Receive Mailbox (System Channel Only)

The mailbox size field usSizeOfMailbox holds the size of the system mailbox structure (sum of
the send / receive mailbox). While the size of the send and receive mailbox is always symmetric,
the given size must be divided by 2 to get the size of the send/receive mailbox structure.
The default size of the send/receive mailbox structure is 128 bytes (sum = 256 bytes). Each
mailbox (send & receive) consists of one field for the package counter (packages accepted /
packages waiting) and 124 bytes for the user data (see section System Mailbox on page 94).

Mailbox Start Offset (System Channel Only)

The mailbox start offset element usMailboxStartOffset defines location (byte offset) of the
mailbox inside the system channel, starting with the send mailbox structure.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Communication Class (Communication Channel Only)

The communication class defines functionality (e.g. Master / Slave etc.) of the fieldbus protocol
stack and can be used by an application to adapt the handling for the protocol stack.
Variable: usCommunicationClass

Value Definition Description

0x0000 HIL_COMM_CLASS_UNDEFINED Undefined
0x0001 HIL_COMM_CLASS_UNCLASSIFIABLE Unclassifiable
0x0002 HIL_COMM_CLASS_MASTER Master stack
0x0003 HIL_COMM_CLASS_SLAVE Slave stack
0x0004 HIL_COMM_CLASS_SCANNER Scanner
0x0005 HIL_COMM_CLASS_ADAPTER Adapter
0x0006 HIL_COMM_CLASS_MESSAGING Messaging (no cyclic I/O data)
0x0007 HIL_COMM_CLASS_CLIENT Client
0x0008 HIL_COMM_CLASS_SERVER Server
0x0009 HIL_COMM_CLASS_IO_CONTROLLER IO-Controller
0x000A HIL_COMM_CLASS_IO_DEVICE IO-Device
0x000B HIL_COMM_CLASS_IO_SUPERVISOR IO-Supervisor
0x000C HIL_COMM_CLASS_GATEWAY Gateway
0x000D HIL_COMM_CLASS_MONITOR Monitor / Analyzer
0x000E HIL_COMM_CLASS_PRODUCER Producer
0x000F HIL_COMM_CLASS_CONSUMER Producer
0x0010 HIL_COMM_CLASS_SWITCH Switch
0x0011 HIL_COMM_CLASS_HUB Hub
0x0012 HIL_COMM_CLASS_COMBI Not used in the DPM
This value is used inside a netX firmware file header, if the
firmware file combines different protocol stacks in one file.
0x0013 HIL_COMM_CLASS_MANAGING_NODE Managing node
0x0014 HIL_COMM_CLASS_CONTROLLED_NODE Controlled node
0x0015 HIL_COMM_CLASS_PLC Programmable Logic Controller (PLC)
0x0016 HIL_COMM_CLASS_HMI Human Machine Interface (HMI)
0x0017 HIL_COMM_CLASS_ITEM_SERVER Item server
0x0018 HIL_COMM_CLASS_SCADA SCADA system
0x0019 HIL_COMM_CLASS_IO_CONTROLLER_SY IO-Controller with System Redundancy
STEM_REDUNDANCY
0x001A HIL_COMM_CLASS_IO_DEVICE_SYSTEM_ IO-Device with System Redundancy
REDUNDANCY
Other values are reserved
Table 60: System Channel: Communication Class

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Protocol Class (Communication Channel Only)

This field defines the fieldbus protocol running on the communication channel or a specific process
like a PLC program, running on the communication channel.
Variable: usProtocolClass

Value Definition Description

0x0000 HIL_PROT_CLASS_UNDEFINED Undefined
0x0001 HIL_PROT_CLASS_3964R 3964R
0x0002 HIL_PROT_CLASS_ASINTERFACE AS Interface
0x0003 HIL_PROT_CLASS_ASCII ASCII
0x0004 HIL_PROT_CLASS_CANOPEN CANopen
0x0005 HIL_PROT_CLASS_CCLINK CC-Link
0x0006 HIL_PROT_CLASS_COMPONET CompoNet
0x0007 HIL_PROT_CLASS_CONTROLNET ControlNet
0x0008 HIL_PROT_CLASS_DEVICENET DeviceNet
0x0009 HIL_PROT_CLASS_ETHERCAT EtherCAT
0x000A HIL_PROT_CLASS_ETHERNET_IP EtherNet/IP
0x000B HIL_PROT_CLASS_FOUNDATION_FB Foundation Fieldbus
0x000C HIL_PROT_CLASS_FL_NET FL Net
0x000D HIL_PROT_CLASS_INTERBUS InterBus
0x000E HIL_PROT_CLASS_IO_LINK IO-Link
0x000F HIL_PROT_CLASS_LON LON
0x0010 HIL_PROT_CLASS_MODBUS_PLUS Modbus Plus
0x0011 HIL_PROT_CLASS_MODBUS_RTU Modbus RTU
0x0012 HIL_PROT_CLASS_OPEN_MODBUS_TCP Open Modbus TCP
0x0013 HIL_PROT_CLASS_PROFIBUS_DP PROFIBUS DP
0x0014 HIL_PROT_CLASS_PROFIBUS_MPI PROFIBUS MPI
0x0015 HIL_PROT_CLASS_PROFINET_IO PROFINET IO
0x0016 HIL_PROT_CLASS_RK512 RK512
0x0017 HIL_PROT_CLASS_SERCOS_II SERCOS II
0x0018 HIL_PROT_CLASS_SERCOS_III SERCOS III
0x0019 HIL_PROT_CLASS_TCP_IP_UDP_IP TCP/IP, UDP/IP
0x001A HIL_PROT_CLASS_POWERLINK Powerlink
0x001B HIL_PROT_CLASS_HART HART
0x001C HIL_PROT_CLASS_COMBI Not used in the DPM
This value is used inside a netX firmware file header, if
the firmware file combines different protocol stacks in one
file.
0x001D HIL_PROT_CLASS_PROG_GATEWAY Programmable Gateway
The programmable gateway function uses netSCRIPT as
programming language.
0x001E HIL_PROT_CLASS_PROG_SERIAL Programmable Serial
The programmable serial protocol function uses
netSCRIPT as programming language.
0x001F HIL_PROT_CLASS_PLC_CODESYS PLC: CoDeSys
0x0020 HIL_PROT_CLASS_PLC_PROCONOS PLC: ProConOS
0x0021 HIL_PROT_CLASS_PLC_IBH_S7 PLC: IBH S7
0x0022 HIL_PROT_CLASS_PLC_ISAGRAF PLC: ISaGRAF
0x0023 HIL_PROT_CLASS_VISU_QVIS Visualization: QviS

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Variable: usProtocolClass

Value Definition Description

0x0024 HIL_PROT_CLASS_ETHERNET Ethernet
0x0025 HIL_PROT_CLASS_RFC1006 RFC1006
0x0026 HIL_PROT_CLASS_DF1 DF1
0x0027 HIL_PROT_CLASS_VARAN VARAN
0x0028 HIL_PROT_CLASS_3S_PLC_HANDLER 3S PLC Handler
0x0029 HIL_PROT_CLASS_ATVISE Atvise
0x002A HIL_PROT_CLASS_MQTT MQTT
0x002B HIL_PROT_CLASS_OPCUA OPCUA
0x002C HIL_PROT_CLASS_CCLINK_IE_BASIC CC-Link IE Field Basic
0x002D HIL_PROT_CLASS_CCLINK_IE_FIELD CC-Link IE Field
0x002E HIL_PROT_CLASS_NETWORK_SERVICES Network Services
0xFFF0 HIL_PROT_CLASS_OEM OEM, Proprietary
Other values are reserved
Table 61: System Channel: Protocol Class

Conformance Class (Communication Channel Only)

The conformance class describes an additional characteristic of a fieldbus protocol or process and
depends on the Protocol Class.
It is used to describe sub functionalities of the protocol stack like PROFIBUS DPV1/DPV2 support
or the conformance class (A/B/C) of a PROFINET protocol.
Because of protocol class dependency, values in here are specified in the corresponding
protocol/process specific manuals.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.2.3 System Handshake Block

The System Handshake Block is a reserved area which is intended to hold the system handshake
register and maybe used in the future.

Note: Currently all handshake registers of all channels are located in the Handshake Channel
of the DPM.

The System Handshake Block inside a channel is not yet supported and therefore set to zero.

System Handshake Block: NETX_HANDSHAKE_CELL

Offset Type Name Description

0x00B0 uint8_t t8Bit.abData[2] Reserved, set to 0
0x00B2 uint8_t t8Bit.bNetxFlags netX system channel handshake register
0x00B3 uint8_t t8Bit.bHostFlags Host system channel handshake register
Table 62: System Channel: System Handshake Block

Structure Reference - System Handshake Block

/*****************************************************************************/
/*! Handshake cell definition */
/*****************************************************************************/
typedef __HIL_PACKED_PRE union NETX_HANDSHAKE_CELLtag
{
__HIL_PACKED_PRE struct
{
volatile uint8_t abData[2]; /*!< Data value, not belonging to handshake */
volatile uint8_t bNetxFlags; /*!< Device status flags (8Bit Mode) */
volatile uint8_t bHostFlags; /*!< Device command flags (8Bit Mode) */
} __HIL_PACKED_POST t8Bit;

__HIL_PACKED_PRE struct
{
volatile uint16_t usNetxFlags; /*!< Device status flags (16Bit Mode) */
volatile uint16_t usHostFlags; /*!< Device command flags (16Bit Mode)*/
} __HIL_PACKED_POST t16Bit;
volatile uint32_t ulValue; /*!< Handshake cell value */
} NETX_HANDSHAKE_CELL;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.2.4 System Control Block

The System Control Block offers the possibility to define commands for the netX system in the
future. Those commands will be initiated by the host application.

Note: Currently no commands are defined.

System Control Block: NETX_SYSTEM_CONTROL_BLOCK

Offset Type Name Description

0x00B8 uint32_t ulSystemCommandCOS System Command Change Of State
System Reset = HIL_SYS_RESET_COOKIE to set Reset
Cookie
0x00BC uint32_t ulReserved netX 10/50/51/52/100/500: Reserved, not used, set to 0
ulSystemControl netX 90/4000/4100: ulSystemControl
Table 63: System Channel: System Control Block

Structure Reference - System Control Block

typedef struct NETX_SYSTEM_CONTROL_BLOCKtag
{
uint32_t ulSystemCommandCOS;
uint32_t ulReserved; /* ulSystemControl for netX 90/4000/4100-based firmware */
} NETX_SYSTEM_CONTROL_BLOCK;

System Control

Note: The System Control field is used to control the system reset behavior
of netX 90/4000/4100-based systems.

Variable: ulSystemControl

Bit No. Definition / Description

31..9 empty / undefined
8 Delete complete remanent data area after reset.
1 = For mode “bootstart” and “updatestart”, this value specifies that the remanent data area will be deleted.
0 = Remanent data area will not be deleted.
7..4 Reset parameter for mode “update start”
Argument evaluated during “update start”.
0x0 ... 0xF = Specifies the firmware variant to be installed. 0x0 corresponds to VAR0, 0x1 corresponds to
VAR1, etc.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

DOC060302DPM17EN | Revision 17 | English | 2020-06 | Released | Public © Hilscher, 2006– 2020
DPM Definitions / Mapping and Content 89/154
3..0 Reset Mode
0 = HIL_SYS_CONTROL_RESET_MODE_COLDSTART
System start
The system start will perform a reset (coldstart) of the device and will start the installed firmware again.
1 = reserved
2 = HIL_SYS_CONTROL_RESET_MODE_BOOTSTART
Boot start
Note: The boot start is usable for Flash-based devices only.
The boot start will perform a reset of the device and start the maintenance firmware. The boot start can be
used to activate the maintenance firmware without starting an update process (idle mode).
3 = HIL_SYS_CONTROL_RESET_MODE_UPDATESTART
Update start
The update start will perform a reset of the device and start the maintenance firmware.
If a valid update file is available, it will be automatically processed and installed.
If no update file is available or if the update file is not valid, the maintenance firmware will change into error
mode , changes the SYS LED (to yellow on) and sets an error code (e.g. ERR_HIL_NOT_AVAILABLE,
0xC0001152).
Other values are reserved
Table 64: System Channel: System Control Field

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.2.5 System Status Block

The system status block provides general status information of the device and the netX firmware.

System Status Block: NETX_SYSTEM_STATUS_BLOCK

Offset Type Name Description

System Change Of State
0x00C0 uint32_t ulSystemCOS
General system states (see page 91)
System Status
0x00C4 uint32_t ulSystemStatus Information about file system, boot medium etc.
(see page 91)
System Error
0x00C8 uint32_t ulSystemError Indicates runtime errors of the firmware
(see page 92)
Boot Error
0x00CC uint32_t ulBootError Indicates faults during the hardware boot process
(see page 92)
Time Since Startup
0x00D0 uint32_t ulTimeSinceStart Time elapsed since system start in seconds
(see page 92)
CPU Load
0x00D4 uint16_t usCpuLoad
CPU Load in 0.01% units (see page 92)
0x00D6 uint16_t usReserved Reserved, set to 0
Hardware Features
0x00D8 uint32_t ulHWFeatures
Available hardware features (see page 93)
0x00DC Reserved
uint8_t abReserved[36]
… 0x00FF Set to 0
Table 65: System Channel: System Status Block

System Status Block Structure Reference

typedef struct NETX_SYSTEM_STATUS_BLOCKtag
{
uint32_t ulSystemCOS;
uint32_t ulSystemStatus;
uint32_t ulSystemError;
uint32_t ulBootError;
uint32_t ulTimeSinceStart;
uint16_t usCpuLoad
uint16_t usReserved;
uint32_t ulHWFeatures;
uint8_t abReserved[36];
} NETX_SYSTEM_STATUS_BLOCK;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

System Change of State

The change of state field contains information about the current operating status of the system
channel.
Variable: ulSystemCOS

Bit No. Definition / Description

0..30 empty / undefined
31 DPM Memory Layout
Indicates if the DPM follows the default memory layout it set once after power up or reset.
0 = none default layout
1 = HIL_SYS_COS_DEFAULT_MEMORY
Other values are reserved
Table 66: System Channel: System Change of State

System Status

The system status holds general state information about the device, e.g. the used boot media, the
file system and its location and the supported firmware type.
Variable: ulSystemStatus
31 30 29 28 27 26 25 24 23 22 … 0 Bit Number
unused, set to zero HIL_SYS_STATUS_OK
HIL_SYS_STATUS_IDPM
HIL_SYS_STATUS_APP
Boot Medium
0000 = HIL_SYS_STATUS_BOOTMEDIUM_RAM
0001 = HIL_SYS_STATUS_BOOTMEDIUM_SERFLASH
0010 = HIL_SYS_STATUS_BOOTMEDIUM_PARFLASH
unused, set to zero
HIL_SYS_STATUS_NO_SYSVOLUME
HIL_SYS_STATUS_SYSVOLUME_FFS
HIL_SYS_STATUS_NXO_SUPPORTED
Table 67: System Channel: System Status Field

Bit No. Definition / Description

0 Actual System State (HIL_SYS_STATUS_OK)
If set, the data in system status register is valid (for backwards compatibility)
0 = System status not valid
1 = HIL_SYS_STATUS_OK
1..21 Reserved, set to 0
22 IDPM is configured (HIL_SYS_STATUS_IDPM), for netX 90/4000/41000 only
1 = IDPM is configured
0 = IDPM is not configured
23 Application CPU is available (HIL_SYS_STATUS_APP), for netX 90/4000/41000 only
1 = Application CPU is available
0 = Application CPU Is not available
24..27 Boot Medium
0000 = RAM (HIL_SYS_STATUS_BOOTMEDIUM_RAM)
0001 = Serial Flash (HIL_SYS_STATUS_BOOTMEDIUM_SERFLASH)
0010 = Parallel Flash (HIL_SYS_STATUS_BOOTMEDIUM_PARFLASH)
Other values are reserved

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

DOC060302DPM17EN | Revision 17 | English | 2020-06 | Released | Public © Hilscher, 2006– 2020
DPM Definitions / Mapping and Content 92/154
28 Reserved, set to 0
29 System Volume (HIL_SYS_STATUS_NO_SYSVOLUME)
Indicates if the device uses a file system
0 = File system available
1 = No file system available
30 Flash File System (HIL_SYS_STATUS_SYSVOLUME_FFS)
Indicates if a flash (remanent) file system is available
0 = No flash file system available
1 = Flash file system available
31 Loadable Modules (HIL_SYS_STATUS_NXO_SUPPORTED)
Indication if the firmware supports loadable modules (NXOs)
0 = Loadable modules (NXO) not supported
1 = Loadable modules (NXO) supported
Table 68: System Channel: System Status Field Description

System Error

The system error field ulSystemError holds information about general netX firmware errors (0 =
no error).
The system error field works in conjunction with the NSF_ERROR bit in the netX System Flags
register. NSF_ERROR is used to indicate an error while the error number is shown in the system
error field. Error codes are listed in section Error codes from page 133.
Using the system service HIL_SYSTEM_ERRORLOG_REQ, it is possible to retrieve additional
information about the error.

Boot Error

The boot error field ulBootError is used by the Second Stage Bootloader to indicate errors
during system startup or firmware loading.
Boot loader errors are described in the Second Stage Bootloader manual and listed in section 7.
Using the system service HIL_SYSTEM_ERRORLOG_REQ, it is possible to retrieve additional
information about the error.

Time Since Startup

Time since startup ulTimeSinceStart is used to shows the elapsed time since the last system
start (e.g. Power-On / hardware reset). The time is given in seconds [s] and can be used to detect
unexpected system re-starts.

CPU Load

The CPU load field usCpuLoad indicates the current netX CPU usage. The value is updated every
second and has a resolution of 0.01% (e.g. a value of 10000 is equal to 100%).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Hardware Features

The hardware features field is used to indicate additional hardware components available,
assembled on a netX device.
Variable: ulHWFeatures
31 … 11 10 9 8 7 6 5 4 3 2 1 0 Bit Number
External Memory Type
0000 = None
0001 = MRAM 64*16 Bit (1 Mbit/128 KB)
Reserved, set to 0
External Memory Access
00 = No access
01 = External access (host)
10 = Internal access
11 = External and internal access
Real-Time Clock
00 = No RTC
01 = RTC internal
10 = RTC external
11 = RTC emulated
Clock State
0 = Time not valid
1 = Time valid
Unused, set to zero
Table 69: System Channel: Hardware Features Field

Bit No. Definition / Description

0..3 External Memory Type
A netX device can provide an external memory which is independent of the DPM.
0000 = No external memory available (HIL_SYSTEM_EXTMEM_TYPE_NONE)
0001 = MRAM 128Kbyte available (HIL_SYSTEM_EXTMEM_TYPE_MRAM_128K )
4..5 Reserved, set to 0
6..7 External Memory Access
The external memory is accessible by the host application and the netX firmware.
00 = No access (HIL_SYSTEM_EXTMEM_ACCESS_NONE)
01 = External access by host (HIL_SYSTEM_EXTMEM_ACCESS_EXTERNAL)
10 = Internal access by netX (HIL_SYSTEM_EXTMEM_ACCESS_INTERNAL)
11 = External and internal (HIL_SYSTEM_EXTMEM_ACCESS_BOTH)
Note If HIL_SYSTEM_EXTMEM_ACCESS_BOTH is defined, the size of the memory is divided by 2 while
1st half of the RAM is owned by the host application and the 2nd half of the RAM is owned by netX firmware.
8..9 Real-Time Clock
These bits defining if a real-time clock is equipped on the netX device. By default all netX are offering a
standard (none real-time) clock.
00 = No RTC (HIL_SYSTEM_HW_RTC_TYPE_NONE)
01 = RTC internal (HIL_SYSTEM_HW_RTC_TYPE_INTERNAL)
10 = RTC external (HIL_SYSTEM_HW_RTC_TYPE_EXTERNAL)
11 = RTC emulated (HIL_SYSTEM_HW_RTC_TYPE_EMULATED)
10 Clock State
Indicates if the clock is set or not
0 = Time not valid, not initialized or battery fault
1 = Time valid, clock was set (HIL_SYSTEM_HW_RTC_STATE)
11..31 Reserved, set to 0
Table 70: System Channel: Hardware Feature Description Field

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.2.6 System Mailbox

The system mailbox allows access to the system channel and the general netX firmware (operating
system services) via packet based commands. It is present as soon as the Second Stage
Bootloader or a netX firmware is running.
A host application uses the mailbox system to download a protocol stack firmware, a fieldbus
configuration or to determine the actual DPM layout if necessary, see section Non-Cyclic Data
Transfer via on page 35 for details.
The mailbox handling is described in section Non-Cyclic Data Transfer via Mailbox and Packets on
page 35.

System Send Mailbox: NETX_SYSTEM_SEND_MAILBOX

Direction: Host System  netX

Offset Type Name Description

Packages Acceptable
0x0100 uint16_t usPackagesAccepted
Number of packets that can be accepted by the firmware
0x0102 uint16_t usReserved Reserved, set to 0
0x0104
Send Mailbox Buffer
… uint8_t abSendMbx[124]
Buffer to insert the send packet
0x017F
Table 71: System Channel: Send Mailbox

System Receive Mailbox: NETX_SYSTEM_RECV_MAILBOX

Offset Type Name Description

Waiting Packages
0x0180 uint16_t usWaitingPackages
Counter of packets waiting to be read by the host
0x182 uint16_t usReserved Reserved, set to 0
0x0184
Receive Mailbox Buffer
… uint8_t abRecvMbx[124]
Buffer containing a packet received from the firmware
0x01FF
Table 72: System Channel: Receive Mailbox

Structure Reference: NETX_SYSTEM_SEND_MAILBOX

typedef struct NETX_SYSTEM_SEND_MAILBOXtag
{
uint16_t usPackagesAccepted;
uint16_t usReserved;
uint8_t abSendMbx[124];
} NETX_SYSTEM_SEND_MAILBOX;

Structure Reference: NETX_SYSTEM_RECV_MAILBOX

typedef struct NETX_SYSTEM_RECV_MAILBOXtag
{
uint16_t usWaitingPackages;
uint16_t usReserved;
uint8_t abRecvMbx[124];
} NETX_SYSTEM_RECV_MAILBOX;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.3 Handshake Channel

In the default layout, the Handshake Channel follows the System Channel. It holds the handshake
registers of all other channels in the DPM, providing the data transfer synchronization mechanism
between the host system and the netX firmware.

Note: Offsets are given relative to the start offset of the channel start address.

There are three types of handshake registers.

 System Handshake Registers
are used by the host system to perform reset to the netX operating system or to indicate the
current state of either the host system or the netX
 Communication Channel Handshake Registers
are used to synchronize cyclic and non-cyclic data exchange over IO data images and
mailboxes for communication channels
 Application Handshake Registers
are not supported yet
For compatibility reason, the handshake channel itself has a handshake register defined in the
handshake channel.

Handshake Channel: NETX_HANDSHAKE_CHANNEL

Offset Type Element Description
0x0000 NETX_HANDSHAKE_CELL tSysFlags System Channel

Offset Type Element Description

0x0000 uint8_t abData[2] reserved, set to 0
0x0002 uint8_t bNetxFlags netX flag register
0x0003 uint8_t bHostFlags Host flag register

Offset Type Element Description

0x0004 Handshake Channel
NETX_HANDSHAKE_CELL tHskFlags
(contains the fieldbus synchronization flags)

Offset Type Element Description

0x0004 uint16_t usNSyncFlags netX flag register
0x0006 uint16_t usHSyncFlags Host flag register

Offset Type Element Description

0x0008 NETX_HANDSHAKE_CELL tCommFlags0 Communication Channel 0

Offset Type Element Description

0x0008 uint16_t usNetxFlags netX flag register
0x000A uint16_t usHostFlags Host flag register

Offset Type Element Description

0x000C NETX_HANDSHAKE_CELL tCommFlags1 Communication Channel 1

Offset Type Element Description

0x000C uint16_t usNetxFlags netX flag register
0x000E uint16_t usHostFlags Host flag register

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Offset Type Element Description

0x0010 NETX_HANDSHAKE_CELL tCommFlags2 Communication Channel 1

Offset Type Element Description

0x0010 uint16_t usNetxFlags netX flag register
0x0012 uint16_t usHostFlags Host flag register

Offset Type Element Description

0x0014 NETX_HANDSHAKE_CELL tCommFlags3 Communication Channel 3

Offset Type Element Description

0x0014 uint16_t usNetxFlags netX flag register
0x0016 uint16_t usHostFlags Host flag register

Offset Type Element Description

0x0018 NETX_HANDSHAKE_CELL tAppFlags0 Application Channel 0 (unused)

Offset Type Element Description

0x001E NETX_HANDSHAKE_CELL tAppFlags1 Application Channel 1 (unused)

Offset Type Element Description

0x0020 uint32_t aulReserved[56] Reserved, set to 0
Table 73: Handshake Channel: Handshake Channel Layout

Structure Reference: NETX_HANDSHAKE_CHANNEL

typedef struct NETX_HANDSHAKE_CHANNELtag
{
NETX_HANDSHAKE_CELL tSysFlags; /* system handshake flags */
NETX_HANDSHAKE_CELL tHskFlags; /* synchronization flags */
NETX_HANDSHAKE_CELL tCommFlags0; /* channel 0 handshake flags */
NETX_HANDSHAKE_CELL tCommFlags1; /* channel 1 handshake flags */
NETX_HANDSHAKE_CELL tCommFlags2; /* channel 2 handshake flags */
NETX_HANDSHAKE_CELL tCommFlags3; /* channel 3 handshake flags */
NETX_HANDSHAKE_CELL tAppFlags0; /* not supported yet */
NETX_HANDSHAKE_CELL tAppFlags1; /* not supported yet */
uint32_t aulReserved[56];
} NETX_HANDSHAKE_CHANNEL;

Structure Reference: NETX_HANDSHAKE_CELL

typedef union NETX_HANDSHAKE_CELLtag
{
struct
{
volatile uint8_t abData[2]; /* Data value, not belonging to handshake */
volatile uint8_t bNetxFlags; /* Device status flags (8Bit Mode) */
volatile uint8_t bHostFlags; /* Device command flags (8Bit Mode) */
} t8Bit;

struct
{
volatile uint16_t usNetxFlags; /* Device status flags (16Bit Mode) */
volatile uint16_t usHostFlags; /* Device command flags (16Bit Mode)*/
} t16Bit;
volatile uint32_t ulValue; /* Handshake cell value */
} NETX_HANDSHAKE_CELL;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.4 Communication Channel

The Communication Channel contains data structures and information about the fieldbus protocol
stack running on a channel.

Note: Offsets are given relative to the start offset of the channel start address.

Structure of the Communication Channel

Communication Channel: NETX_DEFAULT_COMM_CHANNEL / NETX_8K_DPM_COMM_CHANNEL
Offset Type Name Description
Reserved
0x0000 NETX_HANDSHAKE_BLOCK tReserved For details, see section Channel
Handshake Block (page 99).
Common Control Block
0x0008 NETX_CONTROL_BLOCK tControl For details, see section Common Control
Block (page 100).
Common Status Block
0x0010 NETX_COMMON_STATUS_BLOCK tCommonStatus For details, see section Common Status
Block (page 102).
Extended Status Block
0x0050 NETX_EXTENDED_STATUS_BLOCK tExtendedStatus For details, see section Extended Status
Block (page 111).
Send Mailbox
0x0200 NETX_SEND_MAILBOX_BLOCK tSendMbx For details, see section Channel Mailbox
(page 117).
Receive Mailbox
0x0840 NETX_RECV_MAILBOX_BLOCK tRecvMbx For details, see section Channel Mailbox
(page 117).
High Priority Output Data Image 1
0x0E80 uint8_t abPd1Output[64]
(not supported, yet)
High Priority Input Data Image 1
0x0EC0 uint8_t abPd1Input[64]
(not supported, yet)
0x0F00 uint8_t abReserved1[256] Reserved, set to 0
16 KB Layout (default layout)
Output Data Image 0
0x1000 uint8_t abPd0Output[5760] For details, see section Input / Output
Process Data Image (page 119).
Input Data Image 0
0x2680 uint8_t abPd0Input[5760] For details, see section Input / Output
Process Data Image (page 119).
8 KByte Layout
Output Data Image 0
0x1000 uint8_t abPd0Output[1536] For details, see section Input / Output
Process Data Image (page 119)
Input Data Image 0
0x1600 uint8_t abPd0Input[1536] For details, see section Input / Output
Process Data Image (page 119).
Table 74: COMM Channel: Communication Channel Layout

#define NETX_IO_DATA_SIZE 5760 /* I/O data size in bytes for 16KByte DPM */
#define NETX_IO_DATA_SIZE_8K_DPM 1536 /* I/O data size in bytes for 8KByte DPM */
#define NETX_HP_IO_DATA_SIZE 64 /* Default size of the high prio I/O data */

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Structure Reference: Communication Channel (16Kbyte Layout)

typedef struct NETX_DEFAULT_COMM_CHANNELtag
{
NETX_HANDSHAKE_BLOCK tReserved;
NETX_CONTROL_BLOCK tControl;
NETX_COMMON_STATUS_BLCOK tCommonStatus;
NETX_EXTENDED_STATUS_BLOCK tExtendedStatus;
NETX_SEND_MAILBOX_BLOCK tSendMbx;
NETX_RECV_MAILBOX_BLOCK tRecvMbx;
uint8_t abPd1Output[NETX_HP_IO_DATA_SIZE];
uint8_t abPd1Input[NETX_HP_IO_DATA_SIZE];
uint8_t abReserved1[256];
uint8_t abPd0Output[NETX_IO_DATA_SIZE];
uint8_t abPd0Input[NETX_IO_DATA_SIZE];
} NETX_DEFAULT_COMM_CHANNEL;

Structure Reference: Communication Channel (8Kbyte Layout)

typedef struct NETX_8K_DPM_COMM_CHANNELtag
{
NETX_HANDSHAKE_BLOCK tReserved;
NETX_CONTROL_BLOCK tControl;
NETX_COMMON_STATUS_BLCOK tCommonStatus;
NETX_EXTENDED_STATUS_BLOCK tExtendedStatus;
NETX_SEND_MAILBOX_BLOCK tSendMbx;
NETX_RECV_MAILBOX_BLOCK tRecvMbx;
uint8_t abPd1Output[NETX_HP_IO_DATA_SIZE];
uint8_t abPd1Input[NETX_HP_IO_DATA_SIZE];
uint8_t abReserved1[256];
uint8_t abPd0Output[NETX_IO_DATA_SIZE_8K_DPM];
uint8_t abPd0Input[NETX_IO_DATA_SIZE_8K_DPM];
} NETX_8K_DPM_COMM_CHANNEL;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.4.1 Channel Handshake Block

The Channel Handshake Block is a reserved area which is intended to hold the channel
handshake register and may be used in the future.

Note: Currently the handshake registers of all channels are located in the Handshake
Channel of the DPM.

The Channel Handshake Block inside a channel is not yet supported and therefore set to zero.

System Handshake Block: NETX_HANDSHAKE_CELL

Offset Type Name Description

0x0000 uint16_t t16Bit.usNetxFlags netX channel handshake register
0x0003 uint16_t t16Bit.usHostFlags Host channel handshake register
Table 75: COMM Channel: System Handshake Block

Structure Reference - Channel Handshake Block

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.4.2 Common Control Block

The control block of the communication channel holds a command cell (ulApplicationCOS),
which can be passed to the protocol stack by using the COS (Change of State) mechanism and a
watchdog element, allowing a netX firmware to supervise the host application and vice versa.

Control Block: NETX_CONTROL_BLOCK

Offset Type Name Description

0x0008 uint32_t ulApplicationCOS Application Change Of State
- READY
- BUS ON
- INITIALIZATION
- LOCK CONFIGURATION
0x000C uint32_t ulDeviceWatchdog Device Watchdog
Watchdog counter necessary for the handling and
supervision
(see page 102)
Table 76: COMM Channel: Communication Control Block

Structure Reference - Communication Control Block

typedef struct NETX_CONTROL_BLOCKtag
{
uint32_t ulApplicationCOS;
uint32_t ulDeviceWatchdog;
} NETX_CONTROL_BLOCK;

Application Change of State Register

The Application Change of State (ulApplicationCOS) is a bit field. The host application uses
this field in order to send commands to the communication channel synchronized by the COS
mechanism described in section 4.3.

ulApplicationCOS – Host writes, netX reads

31 … 9 8 7 6 5 4 3 2 1 0
HIL_APP_COS_APPLICATION_
READY
HIL_APP_COS_BUS_ON
HIL_APP_COS_BUS_ON_ENABLE
HIL_APP_COS_INITIALIZATION
HIL_APP_COS_INITIALIZATION_ENABLE
HIL_APP_COS_LOCK_CONFIGURATION
HIL_APP_COS_LOCK_CONFIGURATION_ENABLE
HIL_APP_COS_DMA
HIL_APP_COS_DMA_ENABLE
unused, set to zero
Table 77: COMM Channel: Application Change of State

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Application Change of State Flags (Application  netX System)

Bit No. Description

0 APPLICATION READY Flag (HIL_APP_COS_APPLICATION_READY)
Application ready is used to signal a protocol stack a host application is working with the DPM.
0 = Host application not Ready
1 = Host application Ready
1 BUS ON Flag (HIL_APP_COS_BUS_ON)
The Bus On flag is used to signal a protocol stack to start/stop communication on the fieldbus network.
0 = Bus OFF, network communication is inactive (stopped)
1 = Bus ON, network communication is active (should be activated)
Note: This flag is used in conjunction with the protocol stack configuration which can be set to "manual start
of the network communication".
2 BUS ON ENABLE Flag (HIL_APP_COS_BUS_ON_ENABLE)
The Bus On Enable flag defines if the HIL_APP_COS_BUS_ON flag will be evaluate and executed by the
protocol stack.
0 = HIL_APP_COS_BUS_ON flag evaluation disabled
1 = HIL_APP_COS_BUS_ON flag evaluation enabled
3 INITIALIZATION Flag (HIL_APP_COS_INITIALIZATION)
The Initialization flag is used to re-initialize a protocol stack. If the command is recognized, all network
connections are closed immediately and restarted by using the available configuration.
0 = No re-initialization
1 = Re-initialization activated
Note: If the database is locked by HIL_APP_COS_LOCK_CONFIGURATION, re-initializing the channel is not
allowed and rejected by the protocol stack.
4 INITIALIZATION ENABLE Flag (HIL_APP_COS_INITIALIZATION_ENABLE)
The Initialization Enable flag is used to enable the evaluation of HIL_APP_COS_INITIALIZATION flag.
0 = HIL_APP_COS_INITIALIZATION flag evaluation disabled
1 = HIL_APP_COS_INITIALIZATION flag evaluation enabled
5 LOCK CONFIGURATION Flag (HIL_APP_COS_LOCK_CONFIGURATION)
If this bit is set, the protocol stack configuration is locked and the host system does not allow the firmware to
reconfigure the communication channel.
0 = Configuration is unlocked, reconfiguration of the stack allowed
1 = Configuration is locked, reconfiguration is not allowed
6 LOCK CONFIGURATION ENABLE Flag (HIL_APP_COS_LOCK_CONFIGURATION_ENABLE)
The Lock Configuration Enable flag is used to enable the evaluation of the
HIL_APP_COS_LOCK_CONFIGURATION flag.
0 = HIL_APP_COS_LOCK_CONFIGURATION flag evaluation is disabled
1 = HIL_APP_COS_LOCK_CONFIGURATION flag evaluation is enabled
7 DMA MODE Flag (HIL_APP_COS_DMA)
The host system sets this flag in order to turn on DMA (Direct Memory Access) transfer of the cyclic process
data image between the host and the netX hardware.
0 = DMA mode disabled
1 = DMA mode enabled
Note: DMA mode only available on PCI and PCIe based hardware (e.g. CIFX50 / CIFX50e)
8 DMA MODE ENABLE Flag (HIL_APP_COS_DMA_ENABLE)
The DMA Mode Enable flag is used to enable the evaluation of the HIL_APP_COS_DMA flag.
0 = HIL_APP_COS_DMA flag evaluation is disabled
1 = HIL_APP_COS_DMA flag evaluation is enabled
9 … 31 Reserved, set to 0
Table 78: COMM Channel: Application Change of State Description

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

The device watchdog counter ulDeviceWatchdog is one part of the communication channel
watchdog mechanism. The second part ulHostWatchdog is located in the status block of the
channel.

5.4.3 Common Status Block

The common status block contains information common to all fieldbus protocol stacks and is
always present.

Common Status Block: NETX_COMMON_STATUS_BLOCK

Offset Type Name Description

0x0010 uint32_t ulCommunicationCOS Communication Change of State
- READY / RUN
- RESET REQUIRED / NEW CONFIG AVAILABLE
- CONFIG LOCKED
0x0014 uint32_t ulCommunicationState Communication State
- OFFLINE / STOP / IDLE / OPERATE
0x0018 uint32_t ulCommunicationError Communication Error
Protocol Stack error number
0x001C uint16_t usVersion Version
Version Number of this structure (e.g. 0x0002)
0x001E uint16_t usWatchdogTime Watchdog Time
Configured watchdog time given in milliseconds [ms]
0x0020 uint8_t bPDInHskMode Handshake Mode
Configured input process data handshake mode
0x0021 uint8_t bPDInSource Input Handshake Event Source
0x0022 uint8_t bPDOutHskMode Handshake Mode
Configured output process data handshake mode
0x0023 uint8_t bPDOutSource Output Handshake Event Source
0x0024 uint32_t ulHostWatchdog Host Watchdog
Host watchdog counter used for watchdog handling
0x0028 uint32_t ulErrorCount Error Count
Total Number of Detected Errors Since Power-Up or Reset (see
page 108)
0x002C uint8_t bErrorLogInd Number of Entries in the internal error log
Not supported yet
0x002D uint8_t bErrorPDInCnt Input process data handshake error counter
0x002E uint8_t bErrorPDOutCnt Output process data handshake error counter
0x002F uint8_t bErrorSyncCnt Synchronization handshake error counter
0x0030 uint8_t bSyncHskMode Synchronization Handshake Mode
0x0031 uint8_t bSyncSource Synchronization Source
0x0032 uint16_t ausReserved[3] Reserved
Set to 0
0x0038 union uStackDepended Common state information master protocol stacks
NETX_MASTER_STATUS tMasterStatusBlock Common master protocol stack state information
uint32_t aulReserved[6] Reserved, set to zero for slave protocols
Table 79: COMM Channel: Common Status Block

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Structure Reference - Common Status Block

typedef struct NETX_COMMON_STATUS_BLOCKtag
{
uint32_t ulCommunicationCOS;
uint32_t ulCommunicationState;
uint32_t ulCommunicationError;
uint16_t usVersion;
uint16_t usWatchdogTime;
uint8_t bPDInHskMode;
uint8_t bPDInSource;
uint8_t bPDOutHskMode;
uint8_t bPDOutSource;
uint32_t ulHostWatchdog;
uint32_t ulErrorCount;
uint8_t bErrorLogInd;
uint8_t bErrorPDInCnt;
uint8_t bErrorPDOutCnt;
uint8_t bErrorSyncCnt;
uint8_t bSyncHskMode;
uint8_t bSyncSource;
uint16_t ausReserved[3];
union
{
NETX_MASTER_STATUS tMasterStatusBlock; /* for master implementation */
uint32_t aulReserved[6]; /* otherwise reserved */
} uStackDepended;
} NETX_COMMON_STATUS_BLOCK;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Communication Change of State Register

The Communication Change of State register is a bit field, containing information about the current
operating status of the communication channel and its firmware.
The state information is exchanged between the netX firmware and the host by using the COS
(Change of State) mechanism described in section 4.3.

ulCommunicationCOS – netX writes, Host reads

31 … 8 7 6 5 4 3 2 1 0 Bit Number
HIL_COMM_COS_READY
HIL_COMM_COS_RUN
HIL_COMM_COS_BUS_ON
HIL_COMM_COS_CONFIG_LOCKED
HIL_COMM_COS_CONFIG_NEW
HIL_COMM_COS_RESTART_REQUIRED
HIL_COMM_COS_RESTART_REQUIRED_ENABLE
HIL_COMM_COS_DMA
Unused, set to zero
Table 80: COMM Channel: Communication State of Change Register

Communication Change of State Flags (netX System  Application)

Bit No. Definition / Description

0 READY Flag (HIL_COMM_COS_READY)
The READY flag indicates if the protocol stack on the given channel is started properly. In this state the
stack is ready to accept a configuration or other commands from the host application.
0 = not READY (protocol stack not started/working)
1 = READY (protocol stack is started)
1 RUNNING Flag (HIL_COMM_COS_RUN)
The RUNNING flag indicates a configured protocol stack, able to start a network communication.
Only if both, the READY and RUNNING flag are set, the protocol stack is started and configured.
0 = not RUNNING (not configured)
1 = RUNNING (protocol stack is configured)
Note: The fieldbus configuration defines if a READY and RUNNING protocol stack will automatically start
the network communication.
2 BUS ON Flag (HIL_COMM_COS_BUS_ON)
The BUS ON flag indicates the actual state of the fieldbus network communication.
0 = Bus OFF (fieldbus communication not started)
1 = Bus ON (fieldbus communication started)
The fieldbus configuration defines if the network communication will start automatically or if it has to be
started by the host application (see COMMON_CONTROL_BLOCK->ulApplicationCOS).
Also a wrong configuration may prevent the start of the network communication.
3 CONFIGURATION LOCKED Flag (HIL_COMM_COS_CONFIG_LOCKED)
The CONFIGURATION LOCKED flag indicates if the fieldbus configuration is protected and the protocol
stack is not allowed to execute a re-initialization with another configuration.
0 = Configuration not locked
1 = Configuration is locked
Locking is controlled by the host application (see COMMON_CONTROL_BLOCK->ulApplicationCOS).
Note: An application has to make sure to disable the configuration locking before executing a channel reset
or re-initialization (see COMMON_CONTROL_BLOCK->ulApplicationCOS)

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Bit No. Definition / Description

4 CONFIGURATION NEW Flag (HIL_COMM_COS_CONFIG_NEW)
The CONFIGURATION NEW flag is set by the protocol stack to indicate that a new configuration became
available, which has not been activated yet.
0 = No new configuration available
1 = A new configuration is available
This flag may be set together with the RESTART REQUIRED flag.
5 RESTART REQUIRED Flag (HIL_COMM_COS_RESTART_REQUIRED)
The RESTART REQUIRED flag is set by the protocol stack as an indication of a changed configuration,
either received by a host download or an upload via the fieldbus network. A new configuration will only be
activated if the host restarts the protocol stack in such a case.
0 = No restart required, no new configuration
1 = Restart required, new configuration available
This flag is used together with the RESTART REQUIRED ENABLE flag.
6 RESTART REQUIRED ENABLE Flag (HIL_COMM_COS_RESTART_REQUIRED_ENABLE)
The RESTART REQUIRED ENABLE flag enables the evaluation of the RESTART REQUIRED flag by the
host.
0 = Restart disabled
1 = Restart enabled
7 DMA Mode Flag (HIL_COMM_COS_DMA)
The protocol stack sets this flag in order to signal the host application that DMA (Direct Memory Access)
mode is turned on and used to transfer the cyclic process data images between the host system and the
netX firmware.
0 = DMA mode off (default)
1 = DMA mode on
Note: DMA mode is only available on PCI and PCIe based hardware (e.g. CIFX50 / CIFX50e)
8 … 31 Reserved, set to 0
Table 81: COMM Channel: Communication State of Change Description

Communication State

The Communication State field ulCommunicationState contains information about the current
network state.

Note: Depending on fieldbus protocol, not all of the defined states are always available or
may have different meanings.

Value Definition General Description

0x00000000 Unknown Current network state is unknown
0x00000001 Offline No valid configuration / no network communication
0x00000002 Stop Communication stopped by the user application or an error during
the network communication.
0x00000003 Idle Protocol stack is configured but has not reached operating state.
No cyclic data exchanged on the bus system
0x00000004 Operate Network communication is active, data exchange on the network
is activated
Other values are reserved
Table 82: COMM Channel: Communication State

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Communication Channel Error

ulCommunicationError holds the current error code of the communication channel (protocol
stack). An error is also indicated by the NCF_ERROR flag in the communication channel
handshake register.
If the cause of the error is resolved, the communication error field is set to 0 again.

Note: Error codes can be protocol specific and are described in the corresponding manual.
Default system errors are listed in section Error codes from page 133.

Structure Version

The version field usVersion holds the actual version number of the Common Status Block
structure. The structure number is used to indicate changes in the structure.
Value Definition / Description
0x0000 Undefined
0x0001 First version of the structure layout
0x0002 Second version of the structure layout (current)
The layout was extended by the following data
bPDInHskMode, bPDInSource,
bPDOutHskMode, bPDOutSource
bErrorLogInd, bErrorPDInCnt, bErrorPDOutCnt, bErrorSyncCnt
bSyncHskMode, bSyncSource
Table 83: COMM Channel: Common Status Block Structure Version

Watchdog Timeout

The watchdog timeout field usWatchdogTime holds the configured watchdog timeout value in
milliseconds [ms]. This value is set by the fieldbus configuration (default = 1000ms).
The application can use the value to setup their watchdog trigger interval accordingly. If the
application has activated the watchdog it must trigger the watchdog at least once during the given
watchdog time. Otherwise the protocol stack will interrupt all network connections immediately
regardless of their current state.
A watchdog fault will be indicated by the NCF_ERROR flag and a corresponding error is inserted in
ulCommunicationError.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Handshake Mode / Sources and Error Counters

Input and output data images can be driven in different handshake modes, while each mode also
allows configuring a so called synchronization source (not supported yet) and offers an error
handshake counter.
The following elements are used to indicate the actual configured mode / synchronization source
and handshake error for each image.
For details of the handshake mechanism refer to section Cyclic Data Transfer via Input/Output
Data Areas on page 49.
Image Type Variable Description
INPUT uint8_t bPDInHskMode Input data image Handshake mode
Indicates the actual configured handshake mode for the input data
image
uint8_t bPDInSource Input data synchronization source definition
Is intended to be used as an indicator of the actual configured input
data synchronization source. This must be supported by the fieldbus
protocol stack.
uint8_t bErrorPDInCnt Input data handshake errors
Depending on the configured handshake mode, it is possible the
protocol stack is not able to signal new input data, because the host
application has not acknowledged a previous state and therefore
access to the image is not allowed by the stack.
In this case, the protocol stack would increment this counter to signal
a missed update.
OUTPUT uint8_t bPDOutHskMode Output data image Handshake mode
Indicates the actual configured handshake mode for the output data
image
uint8_t bPDOutSource Output data synchronization source definition
Is intended to be used as an indicator of the actual configured output
data synchronization source. This must be supported by the fieldbus
protocol stack.
uint8_t bErrorPDOutCnt Output data handshake errors
Depending on the configured handshake mode, it is possible the
protocol stack needs new output data for the next network transfer.
If the host application is not quick enough to deliver the data, the
protocol stack would increment this counter to signal the missing
update.
Table 84: COMM Channel: Handshake Mode

Value Definition / Description

0x00 For compatibility reasons

This value is identical to 0x04 – Buffered Host Controlled IO Data Transfer

0x02 Buffered Device Controlled IO Data Transfer

0x03 Uncontrolled Mode

0x04 Buffered Host Controlled IO Data Transfer

Other values are reserved

Table 85: COMM Channel: Handshake Mode values

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Host Watchdog

The host watchdog field ulHostWatchdog is used together with the Common Control Block
ulDeviceWatchdog field for the handling of the netX watchdog functionality.
For details on the watchdog function, refer to sections Channel Watchdog (page 131) and
Common Status Block (page 102).

Error Count

This ulErrorCount field holds the total number of errors detected since power-up, respectively
after reset. The protocol stack counts all sorts of errors in this field no matter if they were network
related or caused internally.
After power cycling, reset or channel initialization this counter is being cleared again.

Error Log Indicator (not supported yet)

The error log indicator field bErrorLogInd is created for later use, when the netX firmware
supports an internal error logging array. In this case, the field will show the number of entries in the
logging array and if all entries are read from the log, the field is set to zero.

Extended Synchronization

A protocol stack may offer additional synchronization options, not depending on the input / output
data transfer synchronization and handled by dedicated synchronization flags.

Note: The extended synchronization mechanism is described in an own manual and must be
supported by the fieldbus protocol stack.

These options could be the synchronization with the network bus cycle or an external hardware
trigger. For such options the following three elements are defined to indicate the actual
configuration, the source of the sync signal and an error counter.
Type Variable Description
uint8_t bErrorSyncCnt Number of synchronization handshake errors
Depending on the configuration the error counter is used if the sync
information could not be updated because of a missing acknowledgement.
uint8_t bSyncHskMode Synchronization Handshake Mode
Configured mode of the synchronization (host controlled / device
controlled)
uint8_t bSyncSource Synchronization Source
Definition of the sync source (bus cycle / hardware trigger etc.)
Table 86: COMM Channel: Extended Synchronization

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.4.3.1 Master State Information

The master state information structure NETX_MASTER_STATUS offers common information for all
master protocol stacks.

Note: This structure is not available for slave protocols and set to zero.

Master Status: NETX_MASTER_STATUS

Start Offset Type Name Description
0x0038 uint32_t ulSlaveState Common Slave State
0 = HIL_SLAVE_STATE_UNDEFINED
1 = HIL_SLAVE_STATE_OK
2 = HIL_SLAVE_STATE_FAILED
0x003C uint32_t ulSlaveErrLogInd Number of entries in the internal error log array (not
supported yet)
0 = no error entry
0x0040 uint32_t ulNumOfConfigSlaves Number of configured slave devices in the master
configuration.
0 = no configured slaves
0x0044 uint32_t ulNumOfActiveSlaves Number of activated slave devices, the master has an
open connection to.
0 = no active slaves
0x0048 uint32_t ulNumOfDiagSlaves Number of slaves reporting diagnostic issues
0 = no slaves with diagnostic information
0x004C uint32_t ulReserved Reserved, set to 0
Table 87: COMM Channel: Master State Information

Master Status Structure Reference

typedef struct NETX_MASTER_STATUStag
{
uint32_t ulSlaveState; /* slave state */
uint32_t ulSlaveErrLogInd; /* slave error log Indicator */
uint32_t ulNumOfConfigSlaves; /* number of configured slaves */
uint32_t ulNumOfActiveSlaves; /* number of activated slaves */
uint32_t ulNumOfDiagSlaves; /* number of faulted slaves */
uint32_t ulReserved; /* */
} NETX_MASTER_STATUS;

Common Slave State

The Common Slave State field ulSlaveState is a collective indication on whether the master is
in cyclic data exchange to all configured slaves or not.
If there is at least one slave missing or one of the slaves has pending diagnostic information, the
status is changed to HIL_SLAVE_STATE_FAILED.
For protocols that only support packet based (non-cyclic) communication, the slave state is set to
HIL_SLAVE_STATE_OK as soon as a valid configuration is found.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Slave Error Log Indicator

Not supported yet and reserved for later use if the firmware supports an internal error log array.
The field will indicate the number of entries in the log array and is set to zero if all log entries have
been read by the host application.

Number of Configured Slaves

ulNumOfConfigSlaves indicates number of slave devices configured in the master

configuration.

Number of Active Slaves

ulNumOfActiveSlaves indicates the number of slaves, the master has an active communication
to. Ideally this number is equal to the number of configured slaves, if all configured slaves are
connected to the networks and working without problems.
For certain fieldbus systems, it could be possible that a slave is shown as active, but still has a
problem in terms of a diagnostic issue.

Number with Diagnostic Information

ulNumOfDiagSlaves indicates how many slaves are missing on the network or reporting a
diagnostic issue.
Slave diagnostic is reset if it was read by the master or host application. If all configured slaves are
on the network and no more diagnostic information is pending, the field is set to zero.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.4.4 Extended Status Block

The Extended Status Block contains protocol stack specific information, not common to all fieldbus
protocols, given in abExtendedStatus[] and, if supported by the protocol stack, additional
definitions in a structured descriptor table tExtStateField.
The idea behind the descriptor table is the free definition of memory areas inside the input/output
image of the process data. This allows an application to parse the descriptor table, if available, and
locating additional information inside the input /output image areas.
An example for such additional information is the List of Configured Slaves (Bit Field).

Overview Extended State Field Structure

1 Communication 2 Extended 3 Extended State

Channel 0 Status Block Field
0x0000
reserved reserved
0x0008
Control Block Reserved 0x00FF
0x0010 bNumStateStructs (0..32)
to maintain 0x0100 bStateArea
Common Status
compatibility to bStateTypeID
Block usNumOfStateEntries
existing definitions
0x0050 (0..65535)
0x00FC
ulStateOffset
0x0108
bStateArea
Extended Status
bStateTypeID
Block usNumOfStateEntries
Extended (0..65535)

State Field
ulStateOffset
NETX_EXTENDED_STATE_FIELD_T
0x0200
0x0120 bStateArea
bStateTypeID
usNumOfStateEntries
Send Mailbox (0..65535)

ulStateOffset
0x0840
0x0128 bStateArea
bStateTypeID
usNumOfStateEntries
Receive Mailbox (0..65535)

ulStateOffset
0x0140
bStateArea
bStateTypeID
usNumOfStateEntries
(0..65535)

ulStateOffset

...
0x01F8
bStateArea
bStateTypeID
usNumOfStateEntries
(0..65535)

ulStateOffset

Figure 16: COMM Channel: Overview - Extended State Field Structure

 DPM structure of the communication channel

 Extended status block inside the communication channel
 Organization of the extended state field structure

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Extended Status Block

The Extended Status Block is a byte array of 432 byte. This array is divided into the Extended
Status Area, which is protocol specific, and the Extended State Field.

Extended Status Block: NETX_EXTENDED_STATUS_BLOCK

Offset Type Name Description

0x0050 uint8_t abExtendedStatus[NETX_EXT_STATE_SIZE]; Extended Status Block
Protocol stack specific status area
(max. 432byte)
… 0x01FF Unused Space is Set to Zero
Table 88: COMM Channel: Extended Status Block Definition

Structure Reference - Extended Status

typedef struct NETX_EXTENDED_STATUS_BLOCKtag
{
uint8_t abExtendedStatus[NETX_EXT_STATE_SIZE]; /* Extended status buffer */
} NETX_EXTENDED_STATUS_BLOCK;

Extended Status Area

The definition of the Extended Status Area (abReserved[172]) is specific to the protocol stack
and contains additional information about network status (i.e. flags, error counters, events etc.).
The exact definition of this structure can be found in the corresponding protocol stack API manual.
This size of the structure is 172 bytes.

Note: Depending on the protocol stack, the status block is supported or not and it is defined
in the specific protocol stack manual.

Structure Reference - Extended Status Block / Extended State Field Definition

Extended State Field Definition: NETX_EXTENDED_STATE_FIELD_DEFINITION_T

Offset Type Name Description

0x0050 uint8_t abReserved[172] Extended Status Area
Protocol stack specific status area
0x00FC NETX_EXTENDED_STATE_FIELD_T tExtStateField Extended State Field Structure
… 0x01FF Unused Space is Set to Zero
Table 89: COMM Channel: Extended Status Block Structure

typedef struct NETX_EXTENDED_STATE_FIELD_DEFINITION_Ttag

{
uint8_t abReserved[172]; /* Protocol specific information area */
NETX_EXTENDED_STATE_FIELD_T tExtStateField; /* Extended status structures */
} NETX_EXTENDED_STATE_FIELD_DEFINITION_T;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Extended State Field Structure

The Extended State Field Structure is a collection of descriptor definitions, where each entry
describes the content and the size of additional memory areas in the DPM.
This location is used to maintain various protocol, device or implementation specific state fields.
The Status Structures contain definitions in terms of type, number of valid entries and start offset of
these fields in the communication channel.
If the status information is configured to be located in the IO data image of a channel, the status
information and the IO data image are consistent and updated together.

Structure Reference - Extended Status Block / Extended State Field Structure

Extended State Field: NETX_EXTENDED_STATE_FIELD_T

Offset Type Name Description

0x00FC uint8_t abReserved[3] Reserved, set to zero
0x00FF uint8_t bNumOfStateStruct Number of Status Structures
Number of valid structure definitions in the
following atStateStruct[] array
0x0100 NETX_EXTENDED_STATE_ atStateStruct[24] Status structure with a maximum of
STRUCT_T HIL_EXT_STS_MAX_STRUCTURES (24)
elements
… 0x01FF Unused Space is Set to Zero
Table 90: COMM Channel: Extended State Field Structure

typedef struct NETX_EXTENDED_STATE_FIELD_Ttag

{
uint8_t bReserved[3]; /* 3 Bytes preserved. Not used. */
uint8_t bNumStateStructs; /* Number of following state structures */
NETX_EXTENDED_STATE_STRUCT_T atStateStruct[HIL_EXT_STS_MAX_STRUCTURES];
} NETX_EXTENDED_STATE_FIELD_T;

Number of Status Structures

bNumOfStateStruct holds the number of Status Structures that following this field. Up to
HIL_EXT_STS_MAX_STRUCTURES structures can be defined. This field is set to zero if no such
structure is defined.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Extended State Structure

Each element of the Extended State Structure array (atStateStruct[]) describes exactly one
memory region.

Structure Reference - Extended Status Block / Extended State Structure

Extended Status Structure: NETX_EXTENDED_STATE_STRUCT_T

Offset Type Name Description

0x0100 uint8_t bStateArea State Area
Defines the memory location where the state information
can be found
0x0101 uint8_t bStateTypeID State Type Identification
Type of the state information
0x0102 uint16_t usNumOfStateEntries Number of State Entries
0x0104 uint32_t ulStateOffset State Offset
Start of the information in the given state area
… 0x01FF Unused Space is Set to Zero
Table 91: COMM Channel: Extended State Structure

typedef struct NETX_EXTENDED_STATE_STRUCT_Ttag

{
uint8_t bStateArea; /* Location of the ext. state information */
uint8_t bStateTypeID; /* Type of the state information */
uint16_t usNumOfStateEntries; /* Number of state entries of the type bStateTypeID */
uint32_t ulStateOffset; /* Byte start offset in the defined I/O area*/
} NETX_EXTENDED_STATE_STRUCT_T;

State Area

bStateArea defines the memory location where this state information can be found.
Value Definition State field located
0 HIL_EXT_STS_STD_INPUT_BLK_ID In standard input data area
1 HIL_EXT_STS_HI_INPUT_BLK_ID In high priority input data area (not supported yet)
8 HIL_EXT_STS_STD_OUTPUT_BLK_ID In standard output area
9 HIL_EXT_STS_HI_OUTPUT_BLK_ID In high priority output data area (not supported yet)
Other values are reserved
Table 92: COMM Channel: Extended State Area

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

State Type ID

The State Type ID (bStateTypeID) indicates the type of the status information. It implicitly
defines the content and the size of the information. This could be a list of one or more bits or even
bytes per IO data unit, corresponding to the state definition of the specific protocol.
The following types of state information are defined. The complete list of supported types can be
found in the protocol API manual of the used protocol.
Value Definition Description
1 HIL_EXT_STS_SLAVE_CONFIGURED Configured slave bit field
2 HIL_EXT_STS_SLAVE_ACTIV Active slave bit field
3 HIL_EXT_STS_SLAVE_DIAGNOSTIC Slave diagnostic bit field
Other values are reserved
Table 93: COMM Channel: Extended State Type ID

Note: Not all of the status types are supported by every protocol stack.

Number of State Entries

usNumOfStateEntries holds the number of bytes provided in the status information field. This
value is zero, if no state entries are provided and the field can hold up to 65535 entries.

State Offset

ulStateOffset holds the start offset of the status information in the defined memory area
(input/output image). The offset is related to the beginning of the defined data area and given in
bytes.

Note: The state information is always aligned to 32 bit offsets (round up to the next double
word).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Example

This is an example of the state structures in the extended status block and state field definitions for
communication channel 0.
Communication Extended Extended State
Channel 0 Status Block Field
0x0000
reserved reserved
0x0008
Control Block Reserved
0x0010 0x00FF bNumStateStructs (0..32) =5
to maintain
Common Status 0x0100 bStateArea =8
compatibility to
Block bStateTypeID =1
existing definitions
0x0050 usNumOfStateEntries
= 128
(0..65535)
0x00FC
ulStateOffset =n

0x0108 bStateArea =8
Extended Status
bStateTypeID =2
Block
Extended usNumOfStateEntries
= 128
(0..65535)
State Field
ulStateOffset =n
NETX_EXTENDED_STATE_FIELD_T
0x0200
0x0110 bStateArea =8
bStateTypeID =3
usNumOfStateEntries
Send Mailbox (0..65535)
= 128

ulStateOffset =n
0x0840
0x0118 bStateArea =0
bStateTypeID =1
usNumOfStateEntries
Receive Mailbox = 128
(0..65535)

ulStateOffset =n

0x0E80 bStateArea =0
0x0120
Output Data Area 1 bStateTypeID =2
(high priority) I/O Image usNumOfStateEntries
(0..65535) = 128
0x0EC0
Input Data Area 1 0x1000 data 0 ulStateOffset =n
(high priority)
data 1
0x0F00
...
reserved data n
0x1000 ... ...
0x01F8
Status field bStateArea
bStateTypeID
... usNumOfStateEntries
Status field (0..65535)
Output Data Area 0 ...
ulStateOffset
Status field
0x2680 data 0
data 1
...
0x2680
data n
...
Status field
...
Input Data Area 0 Status field

...

Figure 17: COMM Channel: Example Extended Status Structures

The first entry in the Extended State Field structure indicates that there is a status field located in
the output data image (bStateArea = 8) and ulStateOffset points to a location within the
output image. bStateTypeID holds the type of information located in the output data image (list
of configured/activated/faulted slaves). The second entry, points to the location in the output data
image, and so on.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.4.5 Channel Mailbox

The channel mailbox follows the definition for a mailbox system described in section 4.1. Send and
receive mailbox areas are used to exchange non-cyclic, packet based data with the communication
channel (netX firmware / fieldbus protocols).
The send mailbox is used to transfer data to the netX firmware or to the protocol stack. The
receive mailbox is used to receive packet based data from the netX firmware or from the
protocol stack.
A send/receive mailbox is always available in the communication channel and the default user data
size inside the send and receive mailbox is 1596 byte.
The handling of the mailbox system is described in section Non-Cyclic Data Transfer via Mailbox
and Packets on page 35.

Channel Send Mailbox: NETX_SEND_MAILBOX_BLOCK

Direction: Host System  netX

Offset Type Name Description

0x0200 uint16_t usPackagesAccepted Packages Acceptable
Number of packets that can be accepted by the firmware
0x0202 uint16_t usReserved Reserved, set to 0
0x0204 uint8_t abSendMbx[1596] Send Mailbox Buffer
… 0x023F Buffer to insert the send packet
Table 94: COMM Channel: Channel Mailbox - Send Mailbox

Channel Receive Mailbox: NETX_RECV_MAILBOX_BLOCK

Offset Type Name Description

0x0840 uint16_t usWaitingPackages Waiting Packages
Counter of packets waiting to be read by the host
0x0842 uint16_t usReserved Reserved, set to 0
0x0844 uint8_t abRecvMbx[1596] Receive Mailbox Buffer
… 0x0E7F Buffer containing a packet received from the firmware
Table 95: COMM Channel: Channel Mailbox - Receive Mailbox

Channel Mailboxes Structure Reference

typedef struct NETX_SEND_MAILBOX_BLOCKtag
{
uint16_t usPackagesAccepted;
uint16_t usReserved;
uint8_t abSendMbx[1596];
} NETX_SEND_MAILBOX_BLOCK;

typedef struct NETX_RECV_MAILBOX_BLOCKtag

{
uint16_t usWaitingPackages;
uint16_t usReserved;
uint8_t abRecvMbx[1596];
} NETX_RECV_MAILBOX_BLOCK;

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.4.6 High Priority Input/Output Data Image

These areas are currently not supported.
The high priority input and output areas are intended to divide standard cyclic I/O data from I/O
data which should be transferred with a higher priority.
Both blocks are reserved and always present in the default memory map.
High Priority Input / Output Data Image

Offset Type Name Description

0x0E80 uint8_t abPd1Output[64] High Priority Output Data Image
(not supported yet)
0x0EC0 uint8_t abPd1Input[64] High Priority Input Data Image
(not supported yet)
Table 96: COMM Channel: High Priority Input / Output Data Image

5.4.7 Reserved Area

This area is reserved for later use and always available in the default memory map.
Reserved Area

Offset Type Name Description

0x0F00 uint8_t abReserved1[256] Reserved
Set to 0
Table 97: COMM Channel: Reserved Area

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

5.4.8 Input / Output Process Data Image

The input and output data blocks are used by fieldbus protocols that support cyclic data transfer.
The output data image is used to transfer cyclic data to the network. The input data image is used
to transfer cyclic data from the network.

Note: In case of a network fault (e.g. disconnected network cable), a slave firmware keeps
the last state of the input and output data and clears the Communicating flag in netX
communication flags (see section Communication Channel - Handshake Register on
page 27).
In this case the input data should not be evaluated, while output data can be written.

The handling and synchronization of the input/output data areas is described in section Cyclic Data
Transfer via Input/Output Data Areas on page 49.

Default Memory Map

The size of the input and output data image in the default memory map is 5760 byte each.
Input / Output Process Data Image

Offset Type Name Description

0x1000 uint8_t abPd0Output[5760] Output Data Image
Cyclic Data To The Network
0x2680 uint8_t abPd0Input[5760] Input Data Image
Cyclic Data From The Network
Table 98: COMM Channel: Input/Output Process Data Image

8 KByte Memory Layout

The size of the input and output data image for the 8 Kbyte layout is 1536 bytes each.
Input / Output Process Data Image (8 KByte)

Offset Type Name Description

0x1000 uint8_t abPd0Output[1536] Output Data Image
Cyclic Data To The Network
0x1600 uint8_t abPd0Input[1536] Input Data Image
Cyclic Data From The Network
Table 99: COMM Channel: Input/Output Process Data Image (8 KByte)

5.5 Application Channel

The application channel is reserved for user specific implementations and is not yet supported.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

6 System Behavior and Services

6.1 Timing Considerations
The netX firmware and the handling of the handshake registers must meet some general timing
requirements to allow a host system a correct detection of state changes and therefore a correct
monitoring of the firmware behavior.
During a reset of the netX chip / firmware, the DPM will be re-initialized and this leads into invalid
data in the DPM for a certain time.
The following list will give an overview of times which have to be considered.
ROM Loader Time

Start-up / Restart Time until DPM content valid < 10ms

Second Stage Time until DPM content valid < 500 ms

Bootloader

Protocol Stack Time until DPM content valid

- without configuration < 1s
- with fieldbus configuration < 10s

Reset: netX chip / Firmware

Start / Re-start Time until DPM content is valid, if a Second Stage min. 100ms
Bootloader and/or netX firmware has initialized the
DPM.

Reset activation Clearing NSF_READY after HSF_RESET issued min. 100 - 500ms

Ready after reset Setting NSF_READY after recovering from a reset 0.5s - max. 6s

Fieldbus Communication

General COS command / signal handling must be typical 20ms

recognized, therefore changes should be stable for
a minimum of time and before the DPM content
becomes invalid in case of a reset.

Application Ready Time until channel signals READY typical 1000ms

BUS_ON / BUS_OFF Time until a fieldbus protocol stack signals an typical 5000ms
activated/deactivated fieldbus communication (if
available)

Channel Initialization Re-configuration of a protocol stack typical 10000ms

Packet Send / Receive Sending / receiving packets via a mailbox system typical 1000ms

Communication Channel Watchdog

Watchdog Watchdog trigger cycle >= 20ms

Note: The given times are valid if the netX dual port memory is interfaced via a data / address
bus. When using an SPI / USB or another serial connection, data transfer times of the
physical connection have to be taken in account which may increase these times.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

6.2 netX Boot Procedure

The netX supports different start-up scenarios depending on the hardware design. This chapter
describes the procedure for a design with a dual-port memory. In such an environment, the boot
procedure is divided into different steps as outlined below.

Step 1: After Power-On Reset

The netX chip contains a ROM loader. After power-on reset, the ROM loader is started and its
main task is to initialize the internal netX controller and its components (e.g. optional non-volatile
boot devices such as serial Flash, parallel Flash, and DPM etc.). If a boot device is found, the
ROM loader checks for an executable binary code residing in the boot media and starts it.
Otherwise it depends on the hardware settings how the ROM loader proceeds.

Note: The netX chip boot process and the requirements for creating a bootable binary code is
described in the netX Bootstrap Specification.

Step 2: Start of the Second Stage Bootloader

In general the first boot binary of a netX firmware is a Second Stage Bootloader. This loader
should handle all hardware specific initializations of the target hardware, which keeps a netX
protocol stack firmware independent of it. The Second Stage Bootloader creates the so-called
System Device / System Channel in the dual-port memory area before it starts to look for non-
volatile boot devices and a file system containing the resulting netX firmware.
If available, the firmware file will be started. Otherwise, the Second Stage Bootloader, will wait until
a firmware is downloaded by the host application using the System Mailbox.

Step 3: Start of the netX Firmware

If the found netX firmware is started by the Second Stage Bootloader, the firmware takes the
hardware specific information from the Second Stage Bootloader and creates the final layout of the
DPM (System Channel / Handshake Channel / Communication Channels).
If the target hardware does not support non-volatile boot devices, step 2 and step 3 must be
always processed after each power-on reset.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

6.3 Hardware LEDs

A standard netX based hardware offers several LEDs which can be used to identify the actual state
of the firmware.
The SYS LED is always present (only one per netX device) and described below. But there are up
to 4 LEDs per communication and application channel. These LEDs, like the communication
channel LED (COM LED) are network specific and are described in a separate document.

6.3.1 System LED

The system status LED (SYS LED) is always available. It indicates the state of the system and its
protocol stacks. The following blink patterns are defined:
Color State Meaning
Yellow netX is in Boot Loader Mode and is Waiting for Firmware
Flashing Cyclically at 1 Hz
Download
Solid netX is in Boot Loader Mode, but an Error Occurred
Green Solid netX Operating System is Running and a Firmware is Started
Yellow / Green Flashing Alternating Second Stage Bootloader its active
Off N/A netX has no Power Supply or Hardware Defect Detected
Table 100: SYS LED

6.3.2 Communication Channel LEDs

The meaning of the communication channel LEDs (COM LED) depends on the used firmware and
is described in a separate manual.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

6.4 Reset Handling

A reset can be executed either for the whole netX chip (Hardware Reset executed by the netX
chip) or the netX firmware (System Reset / Boot Start / Update Start).
A Hardware Reset re-starts the netX chip and the complete boot procedure starts with the ROM
loader execution. This includes an internal memory check and other functions to insure the integrity
of the netX chip itself.
System Reset, Boot Start and Update Start are handled by the netX firmware while the host
application uses commands and flags defined in the netX DPM to activate a reset.

Note: During a hardware reset and during the time the netX firmware starts, the content of
the dual-port memory can be invalid (0xFFFF / 0x0BAD).
As soon as the cookie at the beginning of the DPM can be read, the boot process is
finished (see section System Information Block (page 69) / abCookie[]).

Type of netX firmware

 netX 52/51/50/100/500
A Second Stage Bootloader and a standard communication protocol firmware (.NXF) is
used.
 netX 90/4000/4100
A Maintenance firmware (.MXF) and a standard communication protocol firmware (.NXI) is
used.

The startup handling varies slightly between the netX chips

 netX 50/51/52/100/500
First, the integrated ROM loader starts. Then the integrated ROM loader starts the Second
Stage Bootloader. Finally, the Second Stage Bootloader starts the (protocol) firmware. If no
firmware is available or the current firmware is damaged, the boot process will stop in the
Second Stage Bootloader.
 netX 90/4000/4100
First, the integrated ROM loader starts. If a firmware is available, the integrated ROM loader
starts the (protocol) firmware directly. If no firmware is available or the current firmware is
damaged, the integrated ROM loader will start the Maintenance Firmware (MFW).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

6.4.1 Hardware Reset

A hardware (chip) reset can only be processed via the netX Register Block and depends on the
netX chip type.
 netX 50/100/500
Register block is located at the end of the DPM and the accessible DPM address range must
be 64 Kbyte.
 netX 51/52/90/4000/4100
Register block is either located at the beginning or the end of the DPM. Without a firmware
(ROM loader only) the register block is mapped to the beginning of the DPM and the Second
Stage Boot Loader / netX firmware will map the block to the end of the DPM.
The accessible DPM address range must be 64 Kbyte if mapped to the end of the DPM.
To execute a netX chip reset, a reset pattern must be written to the netX reset register.
Reset pattern:
0x00000000, 0x00000001,0x00000003, 0x00000007, 0x0000000F, 0x0000001F,0x0000003F,
0x0000007F, 0x000000FF
The reset is activated when the last value of the pattern is written.

Note: For a complete description on how to reset a specific netX chip, please consult the
corresponding netX Programming Reference Guide.

6.4.2 System Reset

A System Reset is executed by a loaded netX firmware / Second Stage Bootloader / Maintenance
Firmware, forces the running firmware to close all resources and to do a re-start of the firmware.
The internal handling depends on the netX target layout. If the target offers a FLASH memory, a
System Reset will activate the netX ROM loader which loads the netX firmware.
Without a Flash (i.e. on a RAM-based device) the firmware just jumps to the program entry point
and starts over.

System Reset Procedure

 Writing HIL_SYS_RESET_COOKIE (0x55AA55AA) to the ulSystemCommandCOS

(see System Control Block in section System Control Block on page 88)
 Setting the HSF_RESET flag in bHostFlags (see System Handshake Register in section
System Channel - Handshake Register and Flags on page 23)
 The netX firmware clears the NSF_READY flag in bNetxFlags (see System Handshake
Register in section System Channel - Handshake Register and Flags on page 23), indicating
that the system wide reset is in progress.
 The NSF_READY flag is set after a successful reset. If a startup error is detected, the
NSF_ERROR flag is set (see bNetxFlags) and an error code is written to ulSystemError
(see System Status Block in section System Status Block on page 90) indicating the
problem.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

DOC060302DPM17EN | Revision 17 | English | 2020-06 | Released | Public © Hilscher, 2006– 2020
System Behavior and Services 125/154
6.4.3 Boot Start
Boot Start is an additional option to the System Reset, forcing the Second Stage Bootloader /
Maintenance firmware not to start an available firmware (e.g. for system maintenance).
It is activated by additionally setting the HSF_BOOTSTART flag in the bHostFlags before
executing the System Reset.

Note: Boot Start only works if Second Stage Bootloader and/or firmware is stored in a Flash.
On a netX target without a Flash (RAM-based systems), a firmware starts over without
activating the Maintenance mode.

6.4.4 Update Start

Update Start is a special option for netX 90/4000/4100-based devices because these systems are
Flash-based and an update is only possible by starting an (integrated) Maintenance Firmware
(MFW).
The MFW checks the available file(s) and in case of a changed firmware or a different boot option,
the MFW will install the firmware (selected by the boot option) and restarts the netX system.
The Update start is activated by writing an additional boot option into the ulSystemControl register
(see section System Control Block on page 88) before processing a System Reset (see section
System Reset on page 124).

Note: Update Start only works on Flash-based systems i.e. the firmware is stored in a Flash.
On a netX target without a Flash (i.e. RAM-based systems), the firmware starts over
without activating the Maintenance firmware.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

6.5 Communication Channel Services

6.5.1 Channel Initialization
The Channel Initialization is processed by the netX firmware and forces a protocol stack, running
behind a Communication Channel, to re-evaluate the actual fieldbus configuration and to restart
network communication.
A Channel Initiaization does not influence other Communication Channels and is used if a new
configuration database is downloaded to the device or if a new packet based configuration (see
packet services) should be activated.

Note: If the configuration database is locked, re-initializing the communication channel is not
allowed (see HIL_COMM_COS_CONFIG_LOCKED state page 102. and
HIL_APP_COS_LOCK_CONFIGURATION command page 100).

Channel Initialization Procedure

The initialization is handled in two steps

 Set the initialization command in the ulApplicationCOS register by setting the
HIL_APP_COS_INIT and HIL_APP_COS_INITIALIZATION_ENABLE flag at the same time
(see Common Control Block section Common Control Block on page 100).
 Signal the new COS command by using the HCF_HOST_COS_CMD flag in usHostFlags
(see section Application COS Handling on page 62).
In order to avoid race conditions in firmware (e.g. mailbox events generated by firmware are not
recognized by application) it is best practice to use the following sequence to perform a
ChannelInit.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Figure 18: Best practise pattern for ChannelInit

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Communication Channel Flags

 During the channel initialization the HIL_COMM_COS_READY and the
HIL_COMM_COS_RUN flag, located in the ulCommunicationCOS register, are cleared.
 The HIL_COMM_COS_READY flag stays cleared for at least 20 ms before it is set again.
This indicats that the initialization has been finished.
 The HIL_COMM_COS_RUN flag is set, if a valid configuration was found. Otherwise it stays
cleared and an initialization error may be inserted into the ulCommunicationError
indicated by the NCF_ERROR flag in usNetXFlags.
After the initialization process has finished, the protocol stack checks the ulApplicationCOS
register for further setting/commands from the application and depending on the "new"
configuration settings, the network communication will be restored automatically or waits until the
application starts the network communication again.
In this state the aplication has to proceed with normal handshake flag operation which means
checking handshake registers and setting additional application COS command like:
 BUS On (see HIL_APP_COS_BUS_ON / HIL_APP_COS_BUS_ON_ENABLE)

 Lock configuration (see HIL_APP_COS_LOCK_CONFIG / HIL_APP_COS_LOCK_CONFIG_ENABLE)

 Start DMA transfer (see HIL_APP_COS_DMA / HIL_APP_COS_DMA_ENABLE)

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

6.5.2 Start / Stop Communication

A communication channel (protocol stack) has the option to start network communication after
power up automatically or manually by an application. This behaviour can be defined in the
fieldbus configuration.
Possible Start-up Configuration Settings (e.g. SYCON.net):
Start of Bus Communication Description
Automatically by device The fieldbus communication is started as soon as the configuration is loaded and
evaluated by the protocol stack.
Controlled by application The protocol stack loads and evaluates the configuration bus waits until the
alpplication start it.

If the protocol stack is configured in Automatically by Device mode it will open the network
connections automatically as soon as the configuration is loaded. In the Controlled by Application
mode, the protocol stack loads the configuration and than waits until the application sends a Bus
On command.

Note: Which start-up mode is used is up to the application developer. In general Controlled
Start method gives a better control over the network communication.

The actual state of the bus communication is indicated by the protocol stack in the
HIL_COMM_COS_BUS_ON flag, located in the ulCommounicationCOS field.
Communication State Flag Value State
HIL_COMM_COS_BUS_ON 0 Bus communication is disabled
1 Bus communication is enabled

The host application can use the HIL_APP_COS_BUS_ON flag in the Application Change of State
field ulApplicationCOS to start and stop the bus communication. This also implies the
executing of the COS handling defined for application commands (see Application COS Handling
on page 62).
Application State Flag Value State
HIL_APP_COS_BUS_ON 0 Disable bus communication
1 Enable bus communication

In addtion to the HIL_COMM_COS_BUS_ON flag, which indicates the actual bus setting, the
protocol stack uses the NCF_COMMUNICATION flag in the usNetXFlags register to indicate if it
has an active bus communication to other devices on the network.
If the bus communication is disabled, the NCF_COMMUNICATION flag will be cleared an all
further attempts to re-open a connection are rejected until bus communication is started again.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

6.5.3 Lock / Unlock Configuration

The Lock / Unlock Configuration mechanism is used to prevent the configuration settings of a
communication channel from being deleted or changed during run-time.
Locking and unlocking of the configuration can be achieved by an application by using the Lock
Configuration flag HIL_APP_COS_LOCK_CONFIGURATION in ulApplicationCOS and
executing the COS handling defined for application commands (see Application COS Handling on
page 62).
Application State Flag Value State
HIL_APP_COS_LOCK_CONFIGURATION 0 Unlock configuration
1 Lock configuration

The communication channel indicates the actual state by the Configuration Locked flag
HIL_COMM_COS_CONFIG_LOCKED in ulCommunicationCOS.
Communication State Flag Value State
HIL_COMM_COS_CONFIG_LOCKED 0 Configuration unlocked
1 Configuration locked

Any configuration tool shall reject those attempts when the Configuration Locked flag
HIL_COMM_COS_CONFIG_LOCKED is set in ulCommunicationCOS.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

6.5.4 Channel Watchdog

Each Communication Channel offers a dedicated watchdog handling, allowing the netX firmware to
monitor the correct processing of the host application and vice versa.
Two fields are used for the watchdog handling:
 ulDeviceWatchdog (see Common Control Block section Common Control Block on page
100)
 ulHostWatchdog (see Common Status Block section Common Status Block on page 102)
The handling itself simply consist of copy function which must be cyclically exceuted by the host
application, where the application has to copy the content from the ulHostWatchdog field to the
ulDeviceWatchdog field.
The first copy automatically activates the watchdog supervising by the firmware and from this point
the application has to repeate the copy function once during the configured watchdog time. If the
application does not process the copy and the watchdog time expires, a watchdog hit will be
signaled to the Communication Channel.

Note: The actual configured watchdog time can be read from usWatchdogTime field located
in the Common Status Block. If the watchdog time is set to 0, the watchdog will not be
activated.

Communication Channel watchdog behavior in case of a watchdog hit:

 Close all network connections
 Clearing the NCF_COMMUNICATING flag
 Set HIL_E_WATCHDOG_TIMEOUT error into the ulCommunicationError field
 Set NCF_ERROR flag in the usNetXFlags register

Note: After a watchdog hit, the Communication Channel must be newly initialized (reset)
before it will start again.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Watchdog States and Processing

Watchdog State ulHostWatchdog ulDeviceWatchdog Description

Start-up Value 0x00000001 0x00000000 Default initialization after power-up or reset

- Watchdog supervision not active

Activation / The application has to copy the content of ulHostWatchdog to ulDeviceWatchdog field.
Processing The first copy automatically starts the watchdog supervising (ulDeviceWatchdog != 0)

0x00000001 0x00000001 Watchdog supervision activated

Checking Every system cycle (2ms), the firmware checks:

1. ulDeviceWatchdog != 0 (watchdog is activated
2. ulHostWatchdog == ulDeviceWatchdog (watchdog is handled by the application
In this case:
- The watchdog timer is restarted with the configured watchdog value
- The value of ulDeviceWatchdog is copied to ulHostWatchdog
- ulHostWatchdog is incremented by 1 (0 is skipped on overflows)

0x00000002 0x00000001 Watchdog check was successful

Watchdog Hit If the application does not copy ulHostWatchdog to ulDeviceWatchdog and the watchdog
time expires, a watchdog hit is signaled to the communication channel.

ulDeviceWatchdog == ulHostWatchdog Communication Channel will be signaled

and
watchdog timeout has expired

Deactivation The watchdog supervising will be deactivated as soon as the host application writes 0 to
ulDeviceWatchdog.

n 0x00000000 Application has deactivates the watchdog

0x00000001 0x00000000 netX firmware will:

- stop the internal watchdog timer
- re-initialize ulHostWatchdog to 1

Because of the copy functionality and the incrementation by the netX firmware, ulHostWatchdog
can also be used by the application to supervise the netX firmware processing.

Note: The minimum cycle time of the firmware for checking the watchdog values is 2ms and
the minimal configureable watchdog time is 20ms.

6.6 Packet Services

Most of the DPM data and functions can be executed by sending so-called command packets to
the netX firmware (either via the system mailbox or a channel mailbox).
These packets are defined in an own manual (see netX DPM Packet Services).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

7 Error codes
A netX firmware contains several components which are able to signal errors. Therefore error
numbers and places where the errors are signaled depend on the component.
The following table should help to identify the component signaling an error.
Component Format / Value Range Location Description

all 0x0000000 all No error

- SUCCESS_HIL_OK
- HIL_SYS_SUCCESS

Second Stage 0x00000001 … System Status Block See section System

Bootloader 0x000000C Variable: ulBootError Status Block (page 90).

netX System (System) 0x00000001 … System Status Block See section System
(operating system) 0x00007FFF Variable: ulSystemError Status Block (page 90).

netX System (General) 0xC0000001 … 0xC000xxxx System Status Block See section System
(General errors) 0xC02B0001 … 0xC02Byyyy Variable: ulSystemError Status Block (page 90).

or
Packet error in ulSta See section Packet
structure (page 37).

netX System 0xC0xxyyyy System Status Block See section System

- Protocol stack error xx = Protocol stack identifier Variable: ulSystemError Status Block (page 90).
yyyy = Error number or
Packet error in ulSta See section Packet
structure (page 37).

By default, an error code of 0 = SUCCESS_HIL_OK / HIL_SYS_SUCCESS indicates no failure or

error. In case a system error occurs, ulSystemError will be set.
Additionally the NSF_ERROR flag in the netX System Flags is set (see sections System Channel -
Handshake Register and Flags (page 23) and System Status Block (page 90) for details).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

7.1 Second Stage Bootloader Errors

Value Description
0x00000000 No Error
0x00000001 There was no bootable file found inside the flash disk or parallel flash
0x00000002 No flash disk could be determined by boot loader
Possible cause:
Defect of the serial flash
0x00000003 Timing parameters for target could not be determined
Possible causes:
No SDRAM parameters found in security memory / device label
or .NXF file
SRAM / Flash parameters in .NXF file are missing
0x00000004 Boot header in .NXF file is corrupt.
0x00000005 Application checksum in .NXF file is invalid
Possible causes:
Invalid RAM Parameters
Defective .NXF file
Flash error
0x00000006 Error opening file on flash disk
Possible cause:
Defective flash volume
0x00000007 Error reading file from flash disk
Possible cause:
Defective flash volume
0x00000008 Command mode of boot loader was forced by user
Possible causes:
Rdy/Run Pins of netX are configured to Extension bus boot mode
HSF_Bootstart bit was set in DPM
0x00000009 Firmware does not match device (firmware validation failed)
0x0000000A File does not fit in SQIROM (XiP) area, while trying to update firmware
0x0000000B Error copying firmware from to SQIROM (XiP) area
0x0000000C Error during license check (netX 100/500 only)
e. g. i2c transaction error
Table 101: Second Stage Bootloader Errors

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

7.2 netX System Errors (System)

System errors can be found in the Hil_DualPortMemory.h header file.
Value Definition / Description
0x00000000 HIL_SYS_SUCCESS
Success
0x00000001 HIL_SYS_RAM_NOT_FOUND
RAM Not Found
0x00000002 HIL_SYS_RAM_TYPE
Invalid RAM Type
0x00000003 HIL_SYS_RAM_SIZE
Invalid RAM Size
0x00000004 HIL_SYS_RAM_TEST
Ram Test Failed
0x00000005 HIL_SYS_FLASH_NOT_FOUND
Flash Not Found
0x00000006 HIL_SYS_FLASH_TYPE
Invalid Flash Type
0x00000007 HIL_SYS_FLASH_SIZE
Invalid Flash Size
0x00000008 HIL_SYS_FLASH_TEST
Flash Test Failed
0x00000009 HIL_SYS_EEPROM_NOT_FOUND
EEPROM Not Found
0x0000000A HIL_SYS_EEPROM_TYPE
Invalid EEPROM Type
0x0000000B HIL_SYS_EEPROM_SIZE
Invalid EEPROM Size
0x0000000C HIL_SYS_EEPROM_TEST
EEPROM Test Failed
0x0000000D HIL_SYS_SECURE_EEPROM
Security EEPROM Failure
0x0000000E HIL_SYS_SECURE_EEPROM_NOT_INIT
Security EEPROM Not Initialized
0x0000000F HIL_SYS_FILE_SYSTEM_FAULT
File System Fault
0x00000010 HIL_SYS_VERSION_CONFLICT
Version Conflict
0x00000011 HIL_SYS_NOT_INITIALIZED
System Task Not Initialized
0x00000012 HIL_SYS_MEM_ALLOC
Memory Allocation Failed
Other values are reserved
Table 102: System Error Codes (System)

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

7.3 netX System Errors (General)

General system errors can be found in the Hil_Results.h header files.
Value Definition / Description
0x00000000 SUCCESS_HIL_OK
No error
0xC0000001 ERR_HIL_FAIL
Common error, detailed error information optionally present in the data area of packet.
0xC0000002 ERR_HIL_UNEXPECTED
Unexpected failure.
0xC0000003 ERR_HIL_OUTOFMEMORY
Ran out of memory.
0xC0000004 ERR_HIL_UNKNOWN_COMMAND
Unknown Command in Packet received.
0xC0000005 ERR_HIL_UNKNOWN_DESTINATION
Unknown Destination in Packet received.
0xC0000006 ERR_HIL_UNKNOWN_DESTINATION_ID
Unknown Destination Id in Packet received.
0xC0000007 ERR_HIL_INVALID_PACKET_LEN
Packet length is invalid.
0xC0000008 ERR_HIL_INVALID_EXTENSION
Invalid Extension in Packet received.
0xC0000009 ERR_HIL_INVALID_PARAMETER
Invalid Parameter in Packet found.
0xC000000A ERR_HIL_INVALID_ALIGNMENT
Invalid alignment.
0xC000000C ERR_HIL_WATCHDOG_TIMEOUT
Watchdog error occurred.
0xC000000D ERR_HIL_INVALID_LIST_TYPE
List type is invalid.
0xC000000E ERR_HIL_UNKNOWN_HANDLE
Handle is unknown.
0xC000000F ERR_HIL_PACKET_OUT_OF_SEQ
A packet index has been not in the expected sequence.
0xC0000010 ERR_HIL_PACKET_OUT_OF_MEMORY
The amount of fragmented data contained the packet sequence has been too large.
0xC0000011 ERR_HIL_QUE_PACKETDONE
The packet done function has failed.
0xC0000012 ERR_HIL_QUE_SENDPACKET
The sending of a packet has failed.
0xC0000013 ERR_HIL_POOL_PACKET_GET
The request of a packet from packet pool has failed.
0xC0000014 ERR_HIL_POOL_PACKET_RELEASE
The release of a packet-to-packet pool has failed.
0xC0000015 ERR_HIL_POOL_GET_LOAD
The get packet pool load function has failed.
0xC0000016 ERR_HIL_QUE_GET_LOAD
The get queue load function has failed.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition / Description

0xC0000017 ERR_HIL_QUE_WAITFORPACKET
The waiting for a packet from queue has failed.
0xC0000018 ERR_HIL_QUE_POSTPACKET
The posting of a packet has failed.
0xC0000019 ERR_HIL_QUE_PEEKPACKET
Peeking a packet from queue has failed.
0xC000001A ERR_HIL_REQUEST_RUNNING
Request is already running.
0xC000001B ERR_HIL_CREATE_TIMER
Creating a timer failed.
0xC000001C ERR_HIL_BUFFER_TOO_SHORT
Supplied buffer too short for the data.
0xC000001D ERR_HIL_NAME_ALREADY_EXIST
Supplied name already exists.
0xC000001E ERR_HIL_PACKET_FRAGMENTATION_TIMEOUT
The packet fragmentation has timed out.
0xC0000100 ERR_HIL_INIT_FAULT
General initialization fault.
0xC0000101 ERR_HIL_DATABASE_ACCESS_FAILED
Database access failure.
0xC0000102 ERR_HIL_CIR_MASTER_PARAMETER_FAILED
Master parameter cannot activated at state operate.
0xC0000103 ERR_HIL_CIR_SLAVE_PARAMTER_FAILED
Slave parameter cannot activated at state operate.
0xC0000119 ERR_HIL_NOT_CONFIGURED
Configuration not available
0xC0000120 ERR_HIL_CONFIGURATION_FAULT
General configuration fault.
0xC0000121 ERR_HIL_INCONSISTENT_DATA_SET
Inconsistent configuration data.
0xC0000122 ERR_HIL_DATA_SET_MISMATCH
Configuration data set mismatch.
0xC0000123 ERR_HIL_INSUFFICIENT_LICENSE
Insufficient license.
0xC0000124 ERR_HIL_PARAMETER_ERROR
Parameter error.
0xC0000125 ERR_HIL_INVALID_NETWORK_ADDRESS
Network address invalid.
0xC0000126 ERR_HIL_NO_SECURITY_MEMORY
Security memory chip missing or broken.
0xC0000127 ERR_HIL_NO_MAC_ADDRESS_AVAILABLE
No MAC address available.
0xC0000140 ERR_HIL_NETWORK_FAULT
General communication fault.
0xC0000141 ERR_HIL_CONNECTION_CLOSED
Connection closed.
0xC0000142 ERR_HIL_CONNECTION_TIMEOUT
Connection timeout.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition / Description

0xC0000143 ERR_HIL_LONELY_NETWORK
Lonely network.
0xC0000144 ERR_HIL_DUPLICATE_NODE
Duplicate network address.
0xC0000145 ERR_HIL_CABLE_DISCONNECT
Cable disconnected.
0xC0000180 ERR_HIL_BUS_OFF
Bus Off flag is set.
0xC0000181 ERR_HIL_CONFIG_LOCK
Changing configuration is not allowed.
0xC0000182 ERR_HIL_APPLICATION_NOT_READY
Application is not at ready state.
0xC0000183 ERR_HIL_RESET_IN_PROCESS
Application is performing a reset.
0xC0000200 ERR_HIL_WATCHDOG_TIME_INVALID
Watchdog time is out of range.
0xC0000201 ERR_HIL_APPLICATION_ALREADY_REGISTERED
Application is already registered.
0xC0000202 ERR_HIL_NO_APPLICATION_REGISTERED
No application registered.
0xC0000203 ERR_HIL_INVALID_COMPONENT_ID
Invalid component identifier.
0xC0000204 ERR_HIL_INVALID_DATA_LENGTH
Invalid data length.
0xC0000205 ERR_HIL_DATA_ALREADY_SET
The data was already set.
0xC0000206 ERR_HIL_NO_LOGBOOK_AVAILABLE
Logbook not available.
0xC0001000 ERR_HIL_INVALID_HANDLE
No description available - ERR_HIL_INVALID_HANDLE.
0xC0001001 ERR_HIL_UNKNOWN_DEVICE
No description available - ERR_HIL_UNKNOWN_DEVICE.
0xC0001002 ERR_HIL_RESOURCE_IN_USE
No description available - ERR_HIL_RESOURCE_IN_USE.
0xC0001003 ERR_HIL_NO_MORE_RESOURCES
No description available - ERR_HIL_NO_MORE_RESOURCES.
0xC0001004 ERR_HIL_DRV_OPEN_FAILED
No description available - ERR_HIL_DRV_OPEN_FAILED.
0xC0001005 ERR_HIL_DRV_INITIALIZATION_FAILED
No description available - ERR_HIL_DRV_INITIALIZATION_FAILED.
0xC0001006 ERR_HIL_DRV_NOT_INITIALIZED
No description available - ERR_HIL_DRV_NOT_INITIALIZED.
0xC0001007 ERR_HIL_DRV_ALREADY_INITIALIZED
No description available - ERR_HIL_DRV_ALREADY_INITIALIZED.
0xC0001008 ERR_HIL_CRC
No description available - ERR_HIL_CRC.
0xC0001010 ERR_HIL_DRV_INVALID_RESOURCE
No description available - ERR_HIL_DRV_INVALID_RESOURCE.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition / Description

0xC0001011 ERR_HIL_DRV_INVALID_MEM_RESOURCE
No description available - ERR_HIL_DRV_INVALID_MEM_RESOURCE.
0xC0001012 ERR_HIL_DRV_INVALID_MEM_SIZE
No description available - ERR_HIL_DRV_INVALID_MEM_SIZE.
0xC0001013 ERR_HIL_DRV_INVALID_PHYS_MEM_BASE
No description available - ERR_HIL_DRV_INVALID_PHYS_MEM_BASE.
0xC0001014 ERR_HIL_DRV_INVALID_PHYS_MEM_SIZE
No description available - ERR_HIL_DRV_INVALID_PHYS_MEM_SIZE.
0xC0001015 ERR_HIL_DRV_UNDEFINED_HANDLER
No description available - ERR_HIL_DRV_UNDEFINED_HANDLER.
0xC0001020 ERR_HIL_DRV_ILLEGAL_VECTOR_ID
No description available - ERR_HIL_DRV_ILLEGAL_VECTOR_ID.
0xC0001021 ERR_HIL_DRV_ILLEGAL_IRQ_MASK
No description available - ERR_HIL_DRV_ILLEGAL_IRQ_MASK.
0xC0001022 ERR_HIL_DRV_ILLEGAL_SUBIRQ_MASK
No description available - ERR_HIL_DRV_ILLEGAL_SUBIRQ_MASK.
0xC0001100 ERR_HIL_DPM_CHANNEL_UNKNOWN
No description available - ERR_HIL_DPM_CHANNEL_UNKNOWN.
0xC0001101 ERR_HIL_DPM_CHANNEL_INVALID
No description available - ERR_HIL_DPM_CHANNEL_INVALID.
0xC0001102 ERR_HIL_DPM_CHANNEL_NOT_INITIALIZED
No description available - ERR_HIL_DPM_CHANNEL_NOT_INITIALIZED.
0xC0001103 ERR_HIL_DPM_CHANNEL_ALREADY_INITIALIZED
No description available - ERR_HIL_DPM_CHANNEL_ALREADY_INITIALIZED.
0xC0001120 ERR_HIL_DPM_CHANNEL_LAYOUT_UNKNOWN
No description available - ERR_HIL_DPM_CHANNEL_LAYOUT_UNKNOWN.
0xC0001121 ERR_HIL_DPM_CHANNEL_SIZE_INVALID
No description available - ERR_HIL_DPM_CHANNEL_SIZE_INVALID.
0xC0001122 ERR_HIL_DPM_CHANNEL_SIZE_EXCEEDED
No description available - ERR_HIL_DPM_CHANNEL_SIZE_EXCEEDED.
0xC0001123 ERR_HIL_DPM_CHANNEL_TOO_MANY_BLOCKS
No description available - ERR_HIL_DPM_CHANNEL_TOO_MANY_BLOCKS.
0xC0001130 ERR_HIL_DPM_BLOCK_UNKNOWN
No description available - ERR_HIL_DPM_BLOCK_UNKNOWN.
0xC0001131 ERR_HIL_DPM_BLOCK_SIZE_EXCEEDED
No description available - ERR_HIL_DPM_BLOCK_SIZE_EXCEEDED.
0xC0001132 ERR_HIL_DPM_BLOCK_CREATION_FAILED
No description available - ERR_HIL_DPM_BLOCK_CREATION_FAILED.
0xC0001133 ERR_HIL_DPM_BLOCK_OFFSET_INVALID
No description available - ERR_HIL_DPM_BLOCK_OFFSET_INVALID.
0xC0001140 ERR_HIL_DPM_CHANNEL_HOST_MBX_FULL
No description available - ERR_HIL_DPM_CHANNEL_HOST_MBX_FULL.
0xC0001141 ERR_HIL_DPM_CHANNEL_SEGMENT_LIMIT
No description available - ERR_HIL_DPM_CHANNEL_SEGMENT_LIMIT.
0xC0001142 ERR_HIL_DPM_CHANNEL_SEGMENT_UNUSED
No description available - ERR_HIL_DPM_CHANNEL_SEGMENT_UNUSED.
0xC0001143 ERR_HIL_NAME_INVALID
No description available - ERR_HIL_NAME_INVALID.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition / Description

0xC0001144 ERR_HIL_UNEXPECTED_BLOCK_SIZE
No description available - ERR_HIL_UNEXPECTED_BLOCK_SIZE.
0xC0001145 ERR_HIL_COMPONENT_BUSY
The component is busy and cannot handle the requested service.
0xC0001150 ERR_HIL_INVALID_HEADER
Invalid (file) header. E.g. wrong CRC/MD5/Cookie.
0xC0001151 ERR_HIL_INCOMPATIBLE
Firmware does not match device.
0xC0001152 ERR_HIL_NOT_AVAILABLE
Update file or destination (XIP-Area) not found.
0xC0001153 ERR_HIL_READ
Failed to read from file/area.
0xC0001154 ERR_HIL_WRITE
Failed to write from file/area.
0xC0001155 ERR_HIL_IDENTICAL
Update firmware and installed firmware are identical.
0xC0001156 ERR_HIL_INSTALLATION
Error during installation of firmware.
0xC0001157 ERR_HIL_VERIFICATION
Error during verification of firmware.
0xC0001158 ERR_HIL_INVALIDATION
Error during invalidation of firmware files.
0xC0001160 ERR_HIL_FORMAT
Volume is not formatted.
0xC0001161 ERR_HIL_VOLUME
(De-)Initialization of volume failed.
0xC0001162 ERR_HIL_VOLUME_DRV
(De-)Initialization of volume driver failed.
0xC0001163 ERR_HIL_VOLUME_INVALID
The volume is invalid.
0xC0001164 ERR_HIL_VOLUME_EXCEEDED
Number of supported volumes exceeded.
0xC0001165 ERR_HIL_VOLUME_MOUNT
The volume is mounted (in use).
0xC0001166 ERR_HIL_ERASE
Failed to erase file/directory/flash.
0xC0001167 ERR_HIL_OPEN
Failed to open file/directory.
0xC0001168 ERR_HIL_CLOSE
Failed to close file/directory.
0xC0001169 ERR_HIL_CREATE
Failed to create file/directory.
0xC0001170 ERR_HIL_MODIFY
Failed to modify file/directory.
0x0000F005 SUCCESS_HIL_FRAGMENTED
Fragment accepted.
0xC000F006 ERR_HIL_RESET_REQUIRED
Reset required.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition / Description

0xC000F007 ERR_HIL_EVALUATION_TIME_EXPIRED
Evaluation time expired. Reset required.
Table 103: Common status codes

Value Definition / Description

0x00000000 SUCCESS_HIL_OK
No error
0xC02B0001 ERR_RCX_QUE_UNKNOWN
Queue unknown.
0xC02B0002 ERR_RCX_QUE_IDX_UNKNOWN
Queue table index does not exist.
0xC02B0003 ERR_RCX_TSK_UNKNOWN
Task unknown.
0xC02B0004 ERR_RCX_TSK_IDX_UNKNOWN
Task table index does not exist.
0xC02B0005 ERR_RCX_TSK_HANDLE_INVALID
Task handle invalid.
0xC02B0006 ERR_RCX_TSK_INFO_IDX_UNKNOWN
Task info field index unknown.
0x402B0001 INFO_RCX_FILE_RETRANSMIT
The last data block was invalid, please retransmit.
0xC02B0007 ERR_RCX_FILE_XFR_TYPE_INVALID
Requested transfer type invalid.
0xC02B0008 ERR_RCX_FILE_REQUEST_INCORRECT
Request is incorrectly formatted i.e. wrong parameters.
0xC02B0009 ERR_RCX_UNKNOWN_PORT_INDEX
Unknown port index.
0xC02B000A ERR_RCX_ROUTER_TABLE_FULL
Router table is full.
0xC02B000B ERR_RCX_NO_SUCH_ROUTER_IN_TABLE
No such router in table.
0xC02B000C ERR_RCX_INSTANCE_NOT_NULL
Mid_Sys Instance is not 0.
0xC02B000D ERR_RCX_COMMAND_INVALID
Invalid command.
0xC02B000E ERR_RCX_TSK_INVALID
Invalid task handle.
0xC02B000F ERR_RCX_TSK_NOT_A_USER_TASK
Access denied. Not a user task (See Config-File).
0xC02B0010 ERR_RCX_LOG_QUE_NOT_SETTABLE
Logical queue handle not settable.
0xC02B0011 ERR_RCX_LOG_QUE_NOT_INVALID
Logical queue handle invalid.
0xC02B0012 ERR_RCX_LOG_QUE_NOT_SET
Logical queue handle has not been set.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition / Description

0xC02B0013 ERR_RCX_LOG_QUE_ALREADY_USED
Logical queue handle is already in use.
0xC02B0014 ERR_RCX_TSK_NO_DEFAULT_QUEUE
Task has no default process queue.
0xC02B0015 ERR_RCX_MODULE_INVALID
Firmware Module is invalid. CRC-32 check failed.
0xC02B0016 ERR_RCX_MODULE_NOT_FOUND
Firmware Module has not been found. Maybe it has not been downloaded before.
0xC02B0017 ERR_RCX_MODULE_RELOC_ERROR
Firmware Module has an invalid reloc table.
0xC02B0018 ERR_RCX_MODULE_NO_INIT_TBL
Firmware Module has no init table.
0xC02B0019 ERR_RCX_MODULE_NO_ENTRY_POINT
Firmware Module has no code entry point.
0xC02B001A ERR_RCX_ACCESS_DENIED_IN_LOCKED_STATE
Access denied due to current operating conditions.
0xC02B001B ERR_RCX_INVALID_FIRMWARE_SIZE
Firmware does not fit into flash.
0xC02B001C ERR_RCX_MODULE_RELOCATION_DISTANCE_TOO_LONG
The relocation distance is too long.
0xC02B001D ERR_RCX_SEC_FAILED
Access to the security flash failed.
0xC02B001E ERR_RCX_SEC_DISABLED
Security flash is disabled at firmware.
0xC02B001F ERR_RCX_INVALID_EXTENSION
Invalid Extension field.
0xC02B0020 ERR_RCX_BLOCK_SIZE_OUT_OF_RANGE
Block size out of range.
0xC02B0021 ERR_RCX_INVALID_CHANNEL
Invalid Channel.
0xC02B0022 ERR_RCX_INVLAID_FILE_LENGTH
Invalid File Length.
0xC02B0023 ERR_RCX_INVALID_CHARACTER
Invalid Character.
0xC02B0024 ERR_RCX_PACKET_OUT_OF_SEQUENCE
Packet out of sequence.
0xC02B0025 ERR_RCX_NOT_POSSIBLE_IN_CURRENT_STATE
Not possible in current state.
0xC02B0026 ERR_RCX_SECURITY_EEPROM_INVALID_ZONE
Security Eeprom Zone Parameter is invalid.
0xC02B0027 ERR_RCX_SECURITY_EEPROM_NOT_ALLOWED
Security Eeprom access is not allowed in current state.
0xC02B0028 ERR_RCX_SECURITY_EEPROM_NOT_AVAILABLE
Security Eeprom is not available.
0xC02B0029 ERR_RCX_SECURITY_EEPROM_INVALID_CHECKSUM
Security Eeprom has an invalid checksum.
0xC02B002A ERR_RCX_SECURITY_EEPROM_ZONE_NOT_WRITABLE
Security Eeprom Zone is not writeable.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition / Description

0xC02B002B ERR_RCX_SECURITY_EEPROM_READ_FAILED
Security Eeprom Read Failed.
0xC02B002C ERR_RCX_SECURITY_EEPROM_WRITE_FAILED
Security Eeprom Write Failed.
0xC02B002D ERR_RCX_SECURITY_EEPROM_ZONE_ACCESS_DENIED
Security Eeprom Zone Access Denied.
0xC02B002E ERR_RCX_SECURITY_EEPROM_EMULATED
Security Eeprom Emulated. No write possible.
0xC02B002F ERR_RCX_FILE_NAME_INVALID
File name is invalid.
0xC02B0030 ERR_RCX_FILE_SEQUENCE_ERROR
File Sequence Error.
0xC02B0031 ERR_RCX_FILE_SEQUENCE_END_ERROR
File Sequence End Error.
0xC02B0032 ERR_RCX_FILE_SEQUENCE_BEGIN_ERROR
File Sequence Begin Error.
0xC02B0033 ERR_RCX_UNEXPECTED_BLOCK_SIZE
Unexpected File Transfer Block Size.
0xC02B0034 ERR_HIL_FILE_HEADER_CRC_ERROR
Hilscher File Header has invalid CRC error.
0xC02B0035 ERR_HIL_FILE_HEADER_MODULE_SIZE_DIFFERS
Hilscher File Header specifies a different module size than the actual module header itself.
0xC02B0036 ERR_HIL_FILE_HEADER_MD5_CHECKSUM_ERROR
Hilscher File Header contains a wrong MD-5 checksum for file data.
0xC02B0037 ERR_RCX_PACKET_WOULD_BE_TOO_LONG_FOR_MTU
The packet would be too long for transfer.
0xC02B0038 ERR_INVALID_BLOCK
Invalid block id
0xC02B0039 ERR_INVALID_STRUCT_NUMBER
Invalid structure number
0xC02B003A ERR_HIL_FILE_HEADER_INVALID
Invalid file header
0xC02B003B ERR_LICENSE_CHIPTYPE_UNSUPPORTED
Target device not supported for license update
0xC02B003C ERR_LICENSE_CHIPTYPE_MISMATCH
License incompatible for target device
0xC02B003D ERR_LICENSE_HW_MISMATCH
License generated for different device
0xC02B003E ERR_MODULE_CONTAINS_NO_MODULE_DESCRIPTOR
Missing module descriptor in module.
0xC02B003F ERR_MODULE_CONTAINS_UNKNOWN_VERSION
Unknown version in module descriptor.
0xC02B0040 ERR_MODULE_HAS_NO_INIT_FUNCTION
Module has no init function.
0xC02B0041 ERR_MODULE_OFFSET_RANGE_ERROR
Module part exceeded offset range.
0xC02B0042 ERR_MODULE_INVALID_ELF_HEADER
Invalid ELF header in module.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition / Description

0xC02B0043 ERR_MODULE_INVALID_ELF_SECTION_REFERENCE
Invalid ELF section reference in module.
0xC02B0044 ERR_MODULE_INVALID_ELF_SYMBOL_REFERENCE
Invalid ELF symbol reference in module.
0xC02B0045 ERR_MODULE_CONTAINS_AN_UNDEFINED_SYMBOL
Module contains an undefined symbol.
0xC02B0046 ERR_MODULE_CONTAINS_INVALID_CODE_SYMBOL
Module contains invalid symbol to code area.
0xC02B0047 ERR_MODULE_CONTAINS_UNSUPPORTED_SYMBOL_BINDING
Module contains a supported symbol binding.
0xC02B0048 ERR_MODULE_CONTAINS_UNSUPPORTED_SYMBOL_TYPE
Module contains a supported symbol type.
0xC02B0049 ERR_MODULE_INVALID_SECTION_OFFSET_ENCOUNTERED
Invalid section offset encountered.
0xC02B004A ERR_MODULE_UNSUPPORTED_RELOC_TYPE
Unsupported reloc type.
0xC02B004B ERR_MODULE_RELOC_DISTANCE_TOO_LONG
Reloc distance too long.
0xC02B004C ERR_MODULE_RELOC_ERROR
Reloc error.
0xC02B004D ERR_MODULE_SHT_RELA_NOT_SUPPORTED
Rela relocs not supported.
0xC02B004E ERR_MODULE_SPECIAL_SYM_PARSE_ERROR
Special syms could not be parsed.
0xC02B004F ERR_MODULE_MISSING_SPECIAL_SYMS
Missing special symbols in ELF symtab.
0xC02B0050 ERR_MODULE_RCX_JUMP_TABLE_IS_SHORTER_THAN_EXPECTED
rcX Jump table is shorter than expected.
0xC02B0051 ERR_MODULE_LIBC_JUMP_TABLE_IS_SHORTER_THAN_EXPECTED
libc Jump table is shorter than expected.
0xC02B0052 ERR_MODULE_TASK_GROUP_RANGE_DOES_NOT_MATCH_STATIC_TASK_TABLE
Task Group Range does not match static task table.
0xC02B0053 ERR_MODULE_INTERRUPT_GROUP_RANGE_DOES_NOT_MATCH_INTERRUPT_TABLE
Interrupt Group Range does not match interrupt table.
0xC02B0054 ERR_MODULE_INTERRUPT_GROUP_TASK_RANGE_DOES_NOT_MATCH_INTERRUPT_TABLE
Interrupt Group Task-Range does not match interrupt table.
0xC02B0055 ERR_MODULE_LED_TAG_TOO_SHORT
LED-Tag is too short.
0xC02B0056 ERR_MODULE_LED_TAG_CONTAINS_INVALID_PARAMETERS
LED-Tag contains invalid parameters.
0xC02B0057 ERR_MODULE_CONTAINS_UNSUPPORTED_COMMON_SYMBOL
Module contains unsupported *COM* symbol.
0xC02B0058 ERR_RCX_DEVICE_CLASS_INVALID
Device class in file header does not match target.
0xC02B0059 ERR_RCX_MFG_INVALID
Manufacturer in file header does not match target.
0xC02B005A ERR_RCX_HW_COMPATIBILITY_INVALID
Hardware compatibility index in file header does not match target.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Value Definition / Description

0xC02B005B ERR_RCX_HW_OPTIONS_INVALID
Hardware options in file header does not match target.
0xC02B4D52 ERR_RCX_SECURITY_EEPROM_ZONE_NOT_READABLE
Security Eeprom Zone is not readable.
0xC02B524C ERR_RCX_FILE_TRANSFER_IN_USE
File Transfer in use.
0xC02B4444 ERR_RCX_FILE_TRANSFER_PACKET_INVALID
File Transfer Packet invalid.
0xC02B5342 ERR_RCX_FILE_TRANSFER_NOT_ACTIVE
File Transfer is not active.
0xC02B5257 ERR_RCX_FILE_TRANSFER_INVALID
File Transfer has invalid type code.
0xC02B4352 ERR_RCX_FILE_CRC_REPEATEDLY_WRONG
File Transfer was tried repeatedly with a wrong CRC.
0xC02B4353 ERR_RCX_FILE_TRANSFER_TYPE_NOT_AVAILABLE
Transfer Type is not available.
0xC02B5555 ERR_RCX_PATH_INVALID
File Path submitted in File Transfer was invalid.
0xC02BFFFF ERR_RCX_DRIVER_CFG_TABLE_INIT_FUNCTION_MISSING
Driver Configuration Table Init Function missing.
0xC02B4B54 ERR_RCX_CONFIGURATION_LOCKED
Configuration has been locked.
0xC02B4242 ERR_RCX_NOT_ENOUGH_SPACE_FOR_FILE
Not enough space on volume for file.
0xC02B4243 ERR_RCX_FORMAT_ERASE_FAILED
Error formatting / erasing volume.
0xC02B4244 ERR_RCX_FORMAT_VERIFY_FAILED
Error erasing sector.
Table 104: System Middleware errors

7.4 Protocol Stack Errors

These errors are protocol stack specific and defined in a file named …_Results.h that is part of the
header files of a protocol stack (not part of the default DPM definition).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

8 Appendix
8.1 List of figures
Figure 1: DPM Structure: DPM Connection to netX ............................................................................................................ 9
Figure 2: DPM Structure: Overview of DPM Memory Layout .............................................................................................. 9
Figure 3: DPM Structure: netX Firmware Block Diagram .................................................................................................. 10
Figure 4: DPM Structure: Block Diagram Default Dual-Port Memory Layout .................................................................... 11
Figure 5: DPM Structure: DPM Address Spaces............................................................................................................... 12
Figure 6: Packets: Mailbox System Overview ................................................................................................................... 35
Figure 7: Data Transfer Mechanism: Mailbox Packet Exchange ....................................................................................... 36
Figure 8: Packets: Default Packet Handling ...................................................................................................................... 40
Figure 9: Packets: Target Addressing with ulDest ............................................................................................................. 42
Figure 10: Packets: Using ulSrc and ulSrcId ..................................................................................................................... 43
Figure 11: Client/Server mechanism ................................................................................................................................. 44
Figure 12: I/Os: Input / Output Data Areas ........................................................................................................................ 49
Figure 13: I/Os: I/O Data Exchange .................................................................................................................................. 50
Figure 14: Change of State Mechanism (COS): Communication COS Handling .............................................................. 61
Figure 15: Change of State Mechanism (COS): Application COS Handling ..................................................................... 62
Figure 16: COMM Channel: Overview - Extended State Field Structure ......................................................................... 111
Figure 17: COMM Channel: Example Extended Status Structures ................................................................................. 116
Figure 18: Best practise pattern for ChannelInit .............................................................................................................. 127

8.2 List of tables

Table 1: List of revisions ..................................................................................................................................................... 4
Table 2: Data types ............................................................................................................................................................. 5
Table 3: Data types of the rcX operating systems ............................................................................................................... 5
Table 4: Terms, abbreviations and definitions ..................................................................................................................... 7
Table 5: DPM Structure: DPM Layout 8 KByte / 64 Kbyte ................................................................................................ 12
Table 6: DPM Structure: System Channel - Overview ...................................................................................................... 14
Table 7: DPM Structure: Handshake Channel - Overview ................................................................................................ 15
Table 8: DPM Structure: Communication Channel - Overview.......................................................................................... 16
Table 9: DPM Structure: Application Channel - Overview ................................................................................................. 17
Table 10: Handshake Flag Naming Convention ................................................................................................................ 22
Table 11: System Channel - Handshake Register Structure ............................................................................................. 23
Table 12: System Channel - Handshake Register and Flag Definition .............................................................................. 24
Table 13: System Channel - Host System Flags ............................................................................................................... 25
Table 14: System Channel - netX System Flags ............................................................................................................... 26
Table 15: Communication Channel - Handshake Register Structure ................................................................................ 27
Table 16: Communication Channel - Handshake Register and Flag Definition ................................................................. 28
Table 17: Communication Channel - Host Communication Flags ..................................................................................... 29
Table 18: Communication Channel - netX Communication Flags ..................................................................................... 30
Table 19: Synchronization - Handshake Register Structure .............................................................................................. 31
Table 20: Synchronization - Handshake Register and Flag Definition .............................................................................. 32
Table 21: Synchronization - Host Synchronization Flags .................................................................................................. 32
Table 22: Synchronization - netX Synchronization Flags .................................................................................................. 32
Table 23: Synchronization - Synchronization Information ................................................................................................. 33
Table 24: Mailbox Data Buffer Size ................................................................................................................................... 36
Table 25: General packet structure: HIL_PACKET_T ....................................................................................................... 37
Table 26: Packets: Packet description .............................................................................................................................. 39
Table 27: Packets: Default Target Addresses for ulDest ................................................................................................... 41
Table 28: Packets: Additional Target Addresses for ulDest .............................................................................................. 41
Table 29: Directions and names of packets ...................................................................................................................... 44
Table 30: Packet: System Channel Mailbox State Definition............................................................................................. 46
Table 31: Packet: Communication Channel Mailbox State Definition ................................................................................ 46
Table 32: Packet: Default Packet Handling ....................................................................................................................... 47
Table 33: Packet: Send Mailbox Example ......................................................................................................................... 47
Table 34: Packet: Receive Mailbox Example .................................................................................................................... 48
Table 35: I/Os: Process Data Exchange Modes................................................................................................................ 51
Table 36: I/Os: Buffered Host Controlled Mode................................................................................................................. 52
Table 37: I/Os: Buffered Device Controlled Mode ............................................................................................................. 55
Table 38: Input / Output Data Area ................................................................................................................................... 56
Table 39: I/Os: Synchronization in Buffered Host Controlled Mode - Input ....................................................................... 57
Table 40: I/Os: Synchronization in Buffered Host Controlled Mode - Output .................................................................... 58
Table 41: I/Os: Synchronization in Buffered Device Controlled Mode - Input .................................................................... 59

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

DOC060302DPM17EN | Revision 17 | English | 2020-06 | Released | Public © Hilscher, 2006– 2020
Appendix 147/154
Table 42: Change of State Mechanism (COS): Communication COS Handling ............................................................... 61
Table 43: Change of State Mechanism (COS): Application COS Handling ....................................................................... 62
Table 44: Change of State Mechanism (COS): Enable Flag Handling .............................................................................. 64
Table 45: DPM Mapping: Default Mapping........................................................................................................................ 66
Table 46: DPM Mapping: 8 Kbyte Mapping ....................................................................................................................... 67
Table 47: System Channel: System Channel Structure .................................................................................................... 68
Table 48: System Channel: System Information Block ..................................................................................................... 69
Table 49: System Channel: netX Identification, netX Cookie ............................................................................................ 70
Table 50: System Channel: Hardware Assembly Options (xC Port 0..3) .......................................................................... 73
Table 51: System Channel: Manufacturer ......................................................................................................................... 74
Table 52: System Channel: Production Date .................................................................................................................... 74
Table 53: System Channel: License Flags 1 ..................................................................................................................... 75
Table 54: System Channel: License Flags 2 ..................................................................................................................... 76
Table 55: System Channel: Device Class ......................................................................................................................... 78
Table 56: System Channel: Hardware Revision ................................................................................................................ 79
Table 57: System Channel: Channel Information Block .................................................................................................... 81
Table 58: System Channel: Channel Type ........................................................................................................................ 82
Table 59: System Channel: Size / Position of Handshake Registers ................................................................................ 83
Table 60: System Channel: Communication Class ........................................................................................................... 84
Table 61: System Channel: Protocol Class ....................................................................................................................... 86
Table 62: System Channel: System Handshake Block ..................................................................................................... 87
Table 63: System Channel: System Control Block ............................................................................................................ 88
Table 64: System Channel: System Control Field ............................................................................................................. 89
Table 65: System Channel: System Status Block ............................................................................................................. 90
Table 66: System Channel: System Change of State ....................................................................................................... 91
Table 67: System Channel: System Status Field .............................................................................................................. 91
Table 68: System Channel: System Status Field Description ........................................................................................... 92
Table 69: System Channel: Hardware Features Field ....................................................................................................... 93
Table 70: System Channel: Hardware Feature Description Field ...................................................................................... 93
Table 71: System Channel: Send Mailbox ........................................................................................................................ 94
Table 72: System Channel: Receive Mailbox .................................................................................................................... 94
Table 73: Handshake Channel: Handshake Channel Layout ............................................................................................ 96
Table 74: COMM Channel: Communication Channel Layout ............................................................................................ 97
Table 75: COMM Channel: System Handshake Block ...................................................................................................... 99
Table 76: COMM Channel: Communication Control Block.............................................................................................. 100
Table 77: COMM Channel: Application Change of State ................................................................................................ 100
Table 78: COMM Channel: Application Change of State Description ............................................................................. 101
Table 79: COMM Channel: Common Status Block ......................................................................................................... 102
Table 80: COMM Channel: Communication State of Change Register ........................................................................... 104
Table 81: COMM Channel: Communication State of Change Description ...................................................................... 105
Table 82: COMM Channel: Communication State .......................................................................................................... 105
Table 83: COMM Channel: Common Status Block Structure Version ............................................................................. 106
Table 84: COMM Channel: Handshake Mode................................................................................................................. 107
Table 85: COMM Channel: Handshake Mode values ..................................................................................................... 107
Table 86: COMM Channel: Extended Synchronization ................................................................................................... 108
Table 87: COMM Channel: Master State Information ..................................................................................................... 109
Table 88: COMM Channel: Extended Status Block Definition ......................................................................................... 112
Table 89: COMM Channel: Extended Status Block Structure ......................................................................................... 112
Table 90: COMM Channel: Extended State Field Structure ............................................................................................ 113
Table 91: COMM Channel: Extended State Structure ..................................................................................................... 114
Table 92: COMM Channel: Extended State Area............................................................................................................ 114
Table 93: COMM Channel: Extended State Type ID ....................................................................................................... 115
Table 94: COMM Channel: Channel Mailbox - Send Mailbox ......................................................................................... 117
Table 95: COMM Channel: Channel Mailbox - Receive Mailbox..................................................................................... 117
Table 96: COMM Channel: High Priority Input / Output Data Image ............................................................................... 118
Table 97: COMM Channel: Reserved Area ..................................................................................................................... 118
Table 98: COMM Channel: Input/Output Process Data Image........................................................................................ 119
Table 99: COMM Channel: Input/Output Process Data Image (8 KByte) ........................................................................ 119
Table 100: SYS LED ....................................................................................................................................................... 122
Table 101: Second Stage Bootloader Errors ................................................................................................................... 134
Table 102: System Error Codes (System) ....................................................................................................................... 135
Table 103: Common status codes ................................................................................................................................... 141
Table 104: System Middleware errors ............................................................................................................................. 145
Table 105: Glossary ........................................................................................................................................................ 153

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

8.3 Legal notes

All rights reserved.
The images, photographs and texts in the accompanying materials (in the form of a user's manual,
operator's manual, Statement of Work document and all other document types, support texts,
documentation, etc.) are protected by German and international copyright and by international
trade and protective provisions. Without the prior written consent, you do not have permission to
duplicate them either in full or in part using technical or mechanical methods (print, photocopy or
any other method), to edit them using electronic systems or to transfer them. You are not permitted
to make changes to copyright notices, markings, trademarks or ownership declarations.
Illustrations are provided without taking the patent situation into account. Any company names and
product designations provided in this document may be brands or trademarks by the
corresponding owner and may be protected under trademark, brand or patent law. Any form of
further use shall require the express consent from the relevant owner of the rights.

Important notes

Utmost care was/is given in the preparation of the documentation at hand consisting of a user's
manual, operating manual and any other document type and accompanying texts. However, errors
cannot be ruled out. Therefore, we cannot assume any guarantee or legal responsibility for
erroneous information or liability of any kind. You are hereby made aware that descriptions found
in the user's manual, the accompanying texts and the documentation neither represent a
guarantee nor any indication on proper use as stipulated in the agreement or a promised attribute.
It cannot be ruled out that the user's manual, the accompanying texts and the documentation do
not completely match the described attributes, standards or any other data for the delivered
product. A warranty or guarantee with respect to the correctness or accuracy of the information is
not assumed.
We reserve the right to modify our products and the specifications for such as well as the
corresponding documentation in the form of a user's manual, operating manual and/or any other
document types and accompanying texts at any time and without notice without being required to
notify of said modification. Changes shall be taken into account in future manuals and do not
represent an obligation of any kind, in particular there shall be no right to have delivered
documents revised. The manual delivered with the product shall apply.
Under no circumstances shall Hilscher Gesellschaft für Systemautomation mbH be liable for direct,
indirect, ancillary or subsequent damage, or for any loss of income, which may arise after use of
the information contained herein.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Liability disclaimer

The hardware and/or software was created and tested by Hilscher Gesellschaft für
Systemautomation mbH with utmost care and is made available as is. No warranty can be
assumed for the performance or flawlessness of the hardware and/or software under all application
conditions and scenarios and the work results achieved by the user when using the hardware
and/or software. Liability for any damage that may have occurred as a result of using the hardware
and/or software or the corresponding documents shall be limited to an event involving willful intent
or a grossly negligent violation of a fundamental contractual obligation. However, the right to assert
damages due to a violation of a fundamental contractual obligation shall be limited to contract-
typical foreseeable damage.
It is hereby expressly agreed upon in particular that any use or utilization of the hardware and/or
software in connection with
 Flight control systems in aviation and aerospace;
 Nuclear fission processes in nuclear power plants;
 Medical devices used for life support and
 Vehicle control systems used in passenger transport
shall be excluded. Use of the hardware and/or software in any of the following areas is strictly
prohibited:
 For military purposes or in weaponry;
 For designing, engineering, maintaining or operating nuclear systems;
 In flight safety systems, aviation and flight telecommunications systems;
 In life-support systems;
 In systems in which any malfunction in the hardware and/or software may result in physical
injuries or fatalities.
You are hereby made aware that the hardware and/or software was not created for use in
hazardous environments, which require fail-safe control mechanisms. Use of the hardware and/or
software in this kind of environment shall be at your own risk; any liability for damage or loss due to
impermissible use shall be excluded.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Warranty

Hilscher Gesellschaft für Systemautomation mbH hereby guarantees that the software shall run
without errors in accordance with the requirements listed in the specifications and that there were
no defects on the date of acceptance. The warranty period shall be 12 months commencing as of
the date of acceptance or purchase (with express declaration or implied, by customer's conclusive
behavior, e.g. putting into operation permanently).
The warranty obligation for equipment (hardware) we produce is 36 months, calculated as of the
date of delivery ex works. The aforementioned provisions shall not apply if longer warranty periods
are mandatory by law pursuant to Section 438 (1.2) BGB, Section 479 (1) BGB and Section 634a
(1) BGB [Bürgerliches Gesetzbuch; German Civil Code] If, despite of all due care taken, the
delivered product should have a defect, which already existed at the time of the transfer of risk, it
shall be at our discretion to either repair the product or to deliver a replacement product, subject to
timely notification of defect.
The warranty obligation shall not apply if the notification of defect is not asserted promptly, if the
purchaser or third party has tampered with the products, if the defect is the result of natural wear,
was caused by unfavorable operating conditions or is due to violations against our operating
regulations or against rules of good electrical engineering practice, or if our request to return the
defective object is not promptly complied with.

Costs of support, maintenance, customization and product care

Please be advised that any subsequent improvement shall only be free of charge if a defect is
found. Any form of technical support, maintenance and customization is not a warranty service, but
instead shall be charged extra.

Additional guarantees

Although the hardware and software was developed and tested in-depth with greatest care,
Hilscher Gesellschaft für Systemautomation mbH shall not assume any guarantee for the suitability
thereof for any purpose that was not confirmed in writing. No guarantee can be granted whereby
the hardware and software satisfies your requirements, or the use of the hardware and/or software
is uninterruptable or the hardware and/or software is fault-free.
It cannot be guaranteed that patents and/or ownership privileges have not been infringed upon or
violated or that the products are free from third-party influence. No additional guarantees or
promises shall be made as to whether the product is market current, free from deficiency in title, or
can be integrated or is usable for specific purposes, unless such guarantees or promises are
required under existing law and cannot be restricted.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Confidentiality

The customer hereby expressly acknowledges that this document contains trade secrets,
information protected by copyright and other patent and ownership privileges as well as any related
rights of Hilscher Gesellschaft für Systemautomation mbH. The customer agrees to treat as
confidential all of the information made available to customer by Hilscher Gesellschaft für
Systemautomation mbH and rights, which were disclosed by Hilscher Gesellschaft für
Systemautomation mbH and that were made accessible as well as the terms and conditions of this
agreement itself.
The parties hereby agree to one another that the information that each party receives from the
other party respectively is and shall remain the intellectual property of said other party, unless
provided for otherwise in a contractual agreement.
The customer must not allow any third party to become knowledgeable of this expertise and shall
only provide knowledge thereof to authorized users as appropriate and necessary. Companies
associated with the customer shall not be deemed third parties. The customer must obligate
authorized users to confidentiality. The customer should only use the confidential information in
connection with the performances specified in this agreement.
The customer must not use this confidential information to his own advantage or for his own
purposes or rather to the advantage or for the purpose of a third party, nor must it be used for
commercial purposes and this confidential information must only be used to the extent provided for
in this agreement or otherwise to the extent as expressly authorized by the disclosing party in
written form. The customer has the right, subject to the obligation to confidentiality, to disclose the
terms and conditions of this agreement directly to his legal and financial consultants as would be
required for the customer's normal business operation.

Export provisions

The delivered product (including technical data) is subject to the legal export and/or import laws as
well as any associated regulations of various countries, especially such laws applicable in
Germany and in the United States. The products / hardware / software must not be exported into
such countries for which export is prohibited under US American export control laws and its
supplementary provisions. You hereby agree to strictly follow the regulations and to yourself be
responsible for observing them. You are hereby made aware that you may be required to obtain
governmental approval to export, reexport or import the product.

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

9 Glossary
Term Description Section
(page)
Change of State (COS) Method to synchronize command / state exchange between a host 4.3 (p 60)
Mechanism application and the netX firmware
Change of State (COS) Part of the COS mechanism, used to selectively set flags without 4.3.3 (p 63)
Enable Flag Mechanism interfering other flags inside the Change of State register
Channel Logical interface / path from the DPM to dedicated parts of the netX 2.3 (p 14)
System Channel firmware
Communication Channel System Channel => netX Firmware / System services 5.2 (p 68)
Communication Channel => Protocol Stack / System services 5.4 (p 97)

Dual-Port Memory (DPM) Shared memory between the netX firmware and the host 2 (p 9)
application, representing the physical interface to a netX based
device.
Firmware Binary program code executed on the netX chip ARM CPU. It 2 (p 9)
contains the protocol stack and other components.
Handshake The handshake mechanism is used to synchronize data access to 2.3.2 (p 15)
Handshake Flags data located in the DPM and therefore ensuring consistent data 3.1 (p 22)
Handshake Block exchange via DPM. 5.2.3 (p 87)
5.3 (p 95)
5.4.1 (p 99)
Host Program that runs on a host controller (outside the netX chip) and
Host System uses the DPM to communicate and control the netX target.
Host Application
I/O Area Process data image of a communication channel using handshake 2.4.9 (p 20)
I/O Status mechanism to synchronize access 4.2.1 (p 50)
Holds the cyclic process data / state information of a network 5.4.8 (p 119)
I/O Status
Additional information regarding the state of input and output 5.4.4 (p 111)
process data in the IO data image
Lock Configuration Function to protect the configuration settings against changes 5.4.2 (p 100)
Mailbox Used to exchange non-cyclic data (packets) between the host 4.14.1 (p 35)
System Mailbox application and the netX firmware (protocol stack). Each channel
Channel Mailbox (system/Communication) offers an own mailbox.
Packet Definition A packet definition is an additional attribute of none-cyclic 4.1.5 (p 44)
commands/answers defining the originator of a packet.
Request / Confirmation
Indication / Response Request / Confirmation:
Request defines a command packet created by the host application
and sent to the netX firmware. While a confirmation is the answer of
the netX firmware.
Indication / Response:
Indications are command packets created by the netX firmware and
sent to the host application. A response is the answer packet of the
host application returned to the netX firmware.
Packet None cyclic, packet based commands/answers, exchanged via the 4.1.1 (p 37)
Packet Structure mailbox system
Process Data Image see I/O Data Area
Protocol Stack A protocol stack is the functional part (state machine) of a fieldbus
network application. It is an element of the netX firmware, while the
firmware can also include multiple protocol stacks (via different
communication channels).

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

Term Description Section

(page)
Reset A netX system offers different types of resets. 6.4 (p 123)
Hardware Reset
System Reset Hardware Reset
Channel Initialization Reset of the netX chip and therefore for the whole system
System Reset
Firmware handled reset of the netX target

Channel Initialization
Initialization / re-initialization of a specific Communication Channel
Security Memory Non-volatile memory use to store hardware specific and product 5.2.1 (p 69)
Security EEPROM related information
Watchdog Possibility to monitor the correct processing of the host application 6.5.4 (p 131)
Host Watchdog and/or netX firmware. Including the possibility to automatically shut
Device Watchdog down a fieldbus network communication if the host application
stucks or crashes.
xC Port Denotation of the netX chip internal communication controllers 2 (p 9)
Table 105: Glossary

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

10 Contact
Headquarters

Germany
Hilscher Gesellschaft für
Systemautomation mbH
Rheinstrasse 15
65795 Hattersheim
Phone: +49 (0) 6190 9907-0
Fax: +49 (0) 6190 9907-50
E-Mail: [email protected]
Support
Phone: +49 (0) 6190 9907-99
E-Mail: [email protected]

Subsidiaries

China Japan
Hilscher Systemautomation (Shanghai) Co. Ltd. Hilscher Japan KK
200010 Shanghai Tokyo, 160-0022
Phone: +86 (0) 21-6355-5161 Phone: +81 (0) 3-5362-0521
E-Mail: [email protected] E-Mail: [email protected]
Support Support
Phone: +86 (0) 21-6355-5161 Phone: +81 (0) 3-5362-0521
E-Mail: [email protected] E-Mail: [email protected]

France Korea
Hilscher France S.a.r.l. Hilscher Korea Inc.
69500 Bron Seongnam, Gyeonggi, 463-400
Phone: +33 (0) 4 72 37 98 40 Phone: +82 (0) 31-789-3715
E-Mail: [email protected] E-Mail: [email protected]
Support
Phone: +33 (0) 4 72 37 98 40 Switzerland
E-Mail: [email protected] Hilscher Swiss GmbH
4500 Solothurn
India Phone: +41 (0) 32 623 6633
Hilscher India Pvt. Ltd. E-Mail: [email protected]
Pune, Delhi, Mumbai Support
Phone: +91 8888 750 777 Phone: +49 (0) 6190 9907-99
E-Mail: [email protected] E-Mail: [email protected]

Italy USA
Hilscher Italia S.r.l. Hilscher North America, Inc.
20090 Vimodrone (MI) Lisle, IL 60532
Phone: +39 02 25007068 Phone: +1 630-505-5301
E-Mail: [email protected] E-Mail: [email protected]
Support Support
Phone: +39 02 25007068 Phone: +1 630-505-5301
E-Mail: [email protected] E-Mail: [email protected]

netX Dual-Port Memory Interface | Dual-Port Memory Interface Manual

E610 Datasheet Rev1 0
No ratings yet
E610 Datasheet Rev1 0
1,880 pages
Powerlogictm P5: User Manual
No ratings yet
Powerlogictm P5: User Manual
604 pages
Profibus DP Master Protocol API
100% (2)
Profibus DP Master Protocol API
336 pages
Tdoct6548 Eng
No ratings yet
Tdoct6548 Eng
104 pages
Netx Dual-Port Memory Interface DPM 12 EN
No ratings yet
Netx Dual-Port Memory Interface DPM 12 EN
233 pages
MCUXpresso SDK API Reference Manual - MKL26Z4
No ratings yet
MCUXpresso SDK API Reference Manual - MKL26Z4
573 pages
COMX Communication Module Design Guide DG 18 en
No ratings yet
COMX Communication Module Design Guide DG 18 en
78 pages
Cifx Netx Application Programmers Guide XX EN
No ratings yet
Cifx Netx Application Programmers Guide XX EN
53 pages
Moxa Industrial Protocol Users Guide v6.4
No ratings yet
Moxa Industrial Protocol Users Guide v6.4
85 pages
PG203 Pub
No ratings yet
PG203 Pub
169 pages
Industrial Protocols Users Guide 6e
No ratings yet
Industrial Protocols Users Guide 6e
75 pages
pg047 Gig Eth Pcs Pma
No ratings yet
pg047 Gig Eth Pcs Pma
245 pages
Cifx API PR 05 EN
No ratings yet
Cifx API PR 05 EN
118 pages
Cifx API PR 09 EN
No ratings yet
Cifx API PR 09 EN
122 pages
SOPC Builder User Guide PDF
No ratings yet
SOPC Builder User Guide PDF
178 pages
EDS-516A - UM SWITCH MOXA Manual
No ratings yet
EDS-516A - UM SWITCH MOXA Manual
122 pages
NetX Dual-Port Memory Packet-Based Services NetX 90 4000 4100 API 05 en
No ratings yet
NetX Dual-Port Memory Packet-Based Services NetX 90 4000 4100 API 05 en
162 pages
CPXFB 36
No ratings yet
CPXFB 36
218 pages
NetX Dual-Port Memory Packet-Based Services NetX 10 50 51 52 100 500 API 04 en
No ratings yet
NetX Dual-Port Memory Packet-Based Services NetX 10 50 51 52 100 500 API 04 en
138 pages
En tg200838 Uk0yr1204
No ratings yet
En tg200838 Uk0yr1204
11 pages
Blocos de Comunicação Schneider
No ratings yet
Blocos de Comunicação Schneider
550 pages
Lecture 3 Hypothesis Space & Inductive Bias
No ratings yet
Lecture 3 Hypothesis Space & Inductive Bias
29 pages
1732E Ethernet/Ip Armorblock Supporting Sequence of Events: Catalog Number 1732E-Ib16M12Soedr User Manual
No ratings yet
1732E Ethernet/Ip Armorblock Supporting Sequence of Events: Catalog Number 1732E-Ib16M12Soedr User Manual
132 pages
Eds-205 Hardware Installation Guide: Moxa Etherdevice Switch
No ratings yet
Eds-205 Hardware Installation Guide: Moxa Etherdevice Switch
10 pages
OCP IP OpenCoreProtocolSpecification 1.0
No ratings yet
OCP IP OpenCoreProtocolSpecification 1.0
202 pages
Alcatel Omnipcx Enterprise: Audit and Broadcast
No ratings yet
Alcatel Omnipcx Enterprise: Audit and Broadcast
46 pages
System Engineering A Management Perspective
100% (2)
System Engineering A Management Perspective
22 pages
l3 Phono Stage v2
100% (1)
l3 Phono Stage v2
110 pages
Presentation, Project and Technical Report On " Computer Hardware "
No ratings yet
Presentation, Project and Technical Report On " Computer Hardware "
12 pages
List of Drawing Instruments Equipments and Materials
No ratings yet
List of Drawing Instruments Equipments and Materials
16 pages
AC Servo System Tsta Series Install Operate Manual
No ratings yet
AC Servo System Tsta Series Install Operate Manual
194 pages
CELIKIS 20PRESENTATION 202022 - Genel 20sunum
No ratings yet
CELIKIS 20PRESENTATION 202022 - Genel 20sunum
64 pages
E-Commerce Lab - Code 108 & 311 - BBA (G.) & BBA (B & I) - Sem. II
No ratings yet
E-Commerce Lab - Code 108 & 311 - BBA (G.) & BBA (B & I) - Sem. II
12 pages
Application Form For Job
No ratings yet
Application Form For Job
3 pages
Indraworks 15Vrs: Safelogic - Project Configuration, Release 02V08
No ratings yet
Indraworks 15Vrs: Safelogic - Project Configuration, Release 02V08
696 pages
DSS02.1M BOSCH REXROTH - Product Information
No ratings yet
DSS02.1M BOSCH REXROTH - Product Information
2 pages
Information System Application
No ratings yet
Information System Application
53 pages
SmartOTDR Optics ENG
No ratings yet
SmartOTDR Optics ENG
304 pages
ADS1232IPWR Datasheet
No ratings yet
ADS1232IPWR Datasheet
40 pages
PV Inverter Thesis
100% (1)
PV Inverter Thesis
7 pages
AON7400A
No ratings yet
AON7400A
6 pages
Offers: Why Choose Intrcity Smartbus ?
100% (1)
Offers: Why Choose Intrcity Smartbus ?
6 pages
Q1-Proper Use of Tools
No ratings yet
Q1-Proper Use of Tools
10 pages
Sheet 4 FP
100% (1)
Sheet 4 FP
7 pages
Machine Learning Algorithms From Scratch
No ratings yet
Machine Learning Algorithms From Scratch
9 pages
Inline Bus Coupler For Sercos With Digital Inputs and Outputs
No ratings yet
Inline Bus Coupler For Sercos With Digital Inputs and Outputs
33 pages
Offensive Security Certified Professional OSCP
No ratings yet
Offensive Security Certified Professional OSCP
1 page
TSB13
No ratings yet
TSB13
4 pages
One Banc
No ratings yet
One Banc
6 pages
ESB Services API Reference Guide
No ratings yet
ESB Services API Reference Guide
12 pages
DEM315 100D - 3 Schematics
No ratings yet
DEM315 100D - 3 Schematics
11 pages
HWSCS06170 1-3072593
No ratings yet
HWSCS06170 1-3072593
4 pages
Chapter 05 PCPF
No ratings yet
Chapter 05 PCPF
32 pages
MX BNG 17.x-18.x New Features v02 (ENG)
No ratings yet
MX BNG 17.x-18.x New Features v02 (ENG)
48 pages
AiPhen - Solution Challenge - Project Submission
No ratings yet
AiPhen - Solution Challenge - Project Submission
13 pages
0.pham Bac Nguyen - LLM Algorithm
No ratings yet
0.pham Bac Nguyen - LLM Algorithm
2 pages
Liquidity Prog Spot Spec v5
No ratings yet
Liquidity Prog Spot Spec v5
5 pages
Eproc Tenders
No ratings yet
Eproc Tenders
104 pages
Guide LDP
No ratings yet
Guide LDP
6 pages
January 2022 Centre Listing Private Candidates
No ratings yet
January 2022 Centre Listing Private Candidates
2 pages
Code Is Political
No ratings yet
Code Is Political
11 pages
DSO-DP6 Plug-In Card 100-00168
No ratings yet
DSO-DP6 Plug-In Card 100-00168
2 pages
DA-100 Mod6-ENU-PowerPoint
No ratings yet
DA-100 Mod6-ENU-PowerPoint
26 pages
Extensive Study of Cloud Computing Technologies, Threats and Solutions Prospective
No ratings yet
Extensive Study of Cloud Computing Technologies, Threats and Solutions Prospective
15 pages
Mod 5
No ratings yet
Mod 5
5 pages
Mastering Python Advanced Concepts and Practical Applications
From Everand
Mastering Python Advanced Concepts and Practical Applications
Aissa Younes
No ratings yet
The Off-Grid Blueprint: DIY Survival Projects for Modern Self-Reliance: DIY Survival Projects for Modern Self-Reliance: DIY Survival Projects for Modern Self-Reliance
From Everand
The Off-Grid Blueprint: DIY Survival Projects for Modern Self-Reliance: DIY Survival Projects for Modern Self-Reliance: DIY Survival Projects for Modern Self-Reliance
Grant Wilder
No ratings yet
Intrusion Detection Honeypots
From Everand
Intrusion Detection Honeypots
Chris Sanders
3/5 (2)
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
10K Blueprint
From Everand
10K Blueprint
Cian O Farrell
5/5 (2)
BlockChain for Beginners
From Everand
BlockChain for Beginners
Matthew Smith
No ratings yet
Plain JavaScript: Learning the Front-End
From Everand
Plain JavaScript: Learning the Front-End
Roger Beans-Rivet
No ratings yet
ChatGPT for Business: Strategies for Success
From Everand
ChatGPT for Business: Strategies for Success
Matthew C. Smith
1/5 (1)
A Discourse Analysis of 1 Peter
From Everand
A Discourse Analysis of 1 Peter
Ervin Ray Starwalt
No ratings yet
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
From Everand
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
Michael Basler
No ratings yet
Mastering Windows Automation with AHK 2.0
From Everand
Mastering Windows Automation with AHK 2.0
John Nunez
No ratings yet
Blog Smarter, Not Harder: SEO, Blogging, and AI Strategies to Skyrocket Your Traffic
From Everand
Blog Smarter, Not Harder: SEO, Blogging, and AI Strategies to Skyrocket Your Traffic
Jay Nans
No ratings yet
Options Trading for Income: Learn the strategies and techniques for maximizing returns and minimizing risk in the options market (2023 Guide for Beginners)
From Everand
Options Trading for Income: Learn the strategies and techniques for maximizing returns and minimizing risk in the options market (2023 Guide for Beginners)
Lane Conner
No ratings yet
Viral Ipod Video
From Everand
Viral Ipod Video
MUHAMMAD NUR WAHID ANUAR
No ratings yet
Cybersecurity for Executives: A Guide to Protecting Your Business
From Everand
Cybersecurity for Executives: A Guide to Protecting Your Business
Matthew C. Smith
No ratings yet
Cutting-Edge Desktop UI Development with Python, PySide6, PyQt6
From Everand
Cutting-Edge Desktop UI Development with Python, PySide6, PyQt6
Jay Nans
No ratings yet
Aquaponics Design Plans, Construction, Operation, and Income: Organic Food
From Everand
Aquaponics Design Plans, Construction, Operation, and Income: Organic Food
David H Dudley
No ratings yet
Aquaponic Design Plans Everything You Needs to Know: Everything You Need to Know from Backyard to Profitable Business
From Everand
Aquaponic Design Plans Everything You Needs to Know: Everything You Need to Know from Backyard to Profitable Business
David H Dudley
No ratings yet
Aquaponics How to do Everything from Backyard to Profitable Business: from BACKYARD to PROFITABLE BUSINESS
From Everand
Aquaponics How to do Everything from Backyard to Profitable Business: from BACKYARD to PROFITABLE BUSINESS
David H Dudley
No ratings yet
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
From Everand
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
Matthew C. Smith
No ratings yet
CAN Bus for Beginners: A Practical Guide to Automotive Networking
From Everand
CAN Bus for Beginners: A Practical Guide to Automotive Networking
Mohamad Charara
No ratings yet
Content Creation Revolution with chatGPT
From Everand
Content Creation Revolution with chatGPT
Maria Cowen
No ratings yet
A To Z of Internet: Everything You Wanted to Know
From Everand
A To Z of Internet: Everything You Wanted to Know
Bittu Kumar
No ratings yet
Web Video Business
From Everand
Web Video Business
MUHAMMAD NUR WAHID ANUAR
No ratings yet
Software Patterns Made Easy
From Everand
Software Patterns Made Easy
Justice Nanhou
No ratings yet
Kellory the Warlock
From Everand
Kellory the Warlock
Lin Carter
No ratings yet