Netx Dual-Port Memory Interface DPM 12 EN
Netx Dual-Port Memory Interface DPM 12 EN
Netx Dual-Port Memory Interface DPM 12 EN
Table of Content
1 INTRODUCTION ................................................................................................7
1.1 About this Document .........................................................................................7
1.2 List of Revisions ................................................................................................8
1.3 Terms, Abbreviations and Definitions................................................................9
1.4 References ......................................................................................................10
1.5 Limitations .......................................................................................................10
1.6 Legal Notes .....................................................................................................11
1.6.1 Copyright ..................................................................................................11
1.6.2 Important Notes........................................................................................11
1.6.3 Exclusion of Liability.................................................................................12
1.6.4 Export .......................................................................................................12
5 DIAGNOSTIC..................................................................................................210
5.1 Versioning......................................................................................................210
5.2 Network Connection State.............................................................................211
5.2.1 Mechanism .............................................................................................211
5.2.2 Obtain List of Slave Handles..................................................................212
5.2.3 Obtain Slave Connection Information ....................................................214
5.3 Obtain I/O Data Size Information...................................................................216
5.3.1 Get DPM I/O Information Request .........................................................216
5.3.2 Get DPM I/O Information Confirmation ..................................................217
5.4 LEDs..............................................................................................................220
5.4.1 System LED ...........................................................................................220
5.4.2 Communication Channel LEDs ..............................................................220
7 APPENDIX......................................................................................................225
7.1 Device Class..................................................................................................225
7.2 List of Figures ................................................................................................228
7.3 List of Tables .................................................................................................229
8 GLOSSARY ....................................................................................................231
9 CONTACT ......................................................................................................233
1 Introduction
1.1 About this Document
This manual describes the user interface respectively the dual-port memory for netX-based products
manufactured by Hilscher.
In a dual processor system the netX dual-port memory 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 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 8 variable
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 and layout
of the individual memory channels depend on the communication protocol running on the netX chip;
only the system channel and the handshake channel have a fixed structure and location. This area is
used to obtain information regarding type, offset and length of the variable areas.
The system channel holds a system register area. This area contains netX control registers and allows
access to chip specific functions. The control area is not always necessary; if it is present depends on
the hardware configuration of the netX chip and the firmware functions.
All variables, parameters and data used in this manual have the LSB/MSB (“Intel”) data
representation.
The terms Host, Host System, Application, Host Application and Driver are used interchangeably to
identify a process interfacing the netX via its dual-port memory in a dual-processor system.
1.4 References
[1] User Manual netX 2nd Stage Boot Loader Revision 8, Hilscher GmbH
1.5 Limitations
The dual-port memory layout of netX based products is not compatible to AMD or EC1 based
products. The dual-port memory and its structure and definitions apply for netX products only.
The netX dual-port memory interface manual makes general definitions for netX based products. The
individual implementation of a protocol stack / firmware may support only a subset of the structures
and functions from this document.
Structures and functions described in this document apply only to hardware from 3rd party vendors
insofar as original Hilscher firmware is concerned. Therefore, whenever the term "netX firmware" is
used throughout this manual, it refers to ready-made firmware provided by Hilscher. Although 3rd
party vendors are free to implement the same structures and functions in their product, no guarantee
for compatibility of drivers etc. can be given.
1.6.4 Export
The delivered product (including the technical data) is subject to export or import laws as well as the
associated regulations of different counters, in particular those of Germany and the USA. The software
may not be exported to countries where this is prohibited by the United States Export Administration
Act and its additional provisions. You are obligated to comply with the regulations at your personal
responsibility. We wish to inform you that you may require permission from state authorities to export,
re-export or import the product.
NOTE The ROM loader from step 1 is a pure hardware function of the netX chip and is executed
automatically, while step 2 and 3 are software driven and depend on the target hardware. If
the target hardware supports non-volatile boot devices, downloading the 2nd stage loader
and firmware is not necessary after power-on reset, because the ROM loader will find either
the 2nd stage loader or an executable firmware during step 1. Without a non-volatile boot
device, step 2 and step 3 must be always processed after each power-on reset.
Dual-Port Memory
Task R Task O
System Handshake
Task S Task P Application
Task T Task Q
netX Firmware
To Networks
max.
0x10000
Input Data
Application
Area 0
Channel 1
0x2980
Application
Channel 0
Output Data
Area 0
Communication
Channel 3 0x1300
Reserved
0x1200
Communication
Channel 2 Input Data
Area 1
(high priority)
0x11C0
Receive System
Mailbox Receive Mailbox
0x0B40 0x0180
Send System
Mailbox Send Mailbox
0x02FF
Communication
Channel 0
0x0500 0x0100
System Status
Block
0x00C0
0x00B8 System Control Block
Extended 0x00B0 Reserved
Reserved
Status Block
0x0350 Channel
Information Block
Common 0x0220
0x021C Handshake Channel 7
Status Block 0x0218 Handshake Channel 6
0x0214 Handshake Channel 5
0x0310 0x0210 Handshake Channel 4 0x0030
0x0308 Control Block 0x020C Handshake Channel 3
0x0300 0x0300 Reserved 0x0208 Handshake Channel 2
0x0204 Handshake Channel 1
0x0200 Handshake Ch. 0x0200 Handshake Channel 0 System
System Information Block
0x0000 Channel 0x0000
Communication Variable I/O Data, None Cyclic Data Exchange, Diagnostic Data of
Channel 2
Channel 0 m • 256 Bytes the Protocol stack Running on Channel 0
Communication Variable I/O Data, None Cyclic Data Exchange, Diagnostic Data of
Channel 3
Channel 1 n • 256 Bytes the Protocol stack Running on Channel 1
Communication Variable I/O Data, None Cyclic Data Exchange, Diagnostic Data of
Channel 4
Channel 2 p • 256 Bytes the Protocol stack Running on Channel 2
Communication Variable I/O Data, None Cyclic Data Exchange, Diagnostic Data of
Channel 5
Channel 3 q • 256 Bytes the Protocol stack Running on Channel 3
Application Variable
Channel 6 Custom Specific (Application)
Channel 0 r • 256 Bytes
Application Variable
Channel 7 Custom Specific (Application)
Channel 1 s • 256 Bytes
Table 3: Memory Configuration (Overview)
From a driver/application point of view, the system channel is the most important location in the dual-
port memory. It is always present, even if no application firmware is loaded to the netX. It is the
"window" to the rcX operating system or netX boot loader respectively, if no firmware is loaded.
The system channel is located at the beginning of the dual-port memory (starting at offset 0x0000).
The first 256 byte page of this channel has a fixed structure. The following 256 byte page is reserved
for the system mailboxes. The size of the mailbox structure is 128 bytes for the send mailbox and 128
bytes for the receive mailbox.
For details on the system channel refer to section 3.1 on page 27.
The handshake channel brings all handshake register from all channels together in one location. This
is the preferred approach for PC based solutions. The handshake mechanism allows synchronizing
data transfer between the host system and the netX. The channel has a size of 256 bytes and starts
always at address 0x0200. This channel has a fixed structure.
Name Size Description
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.
Name Size Description
Output Data Image 1 Variable High Priority Cyclic Output Process Data Image
Input Data Image 1 Variable High Priority Cyclic Input Process Data Image
The communication channel follows the preceding channels without gaps. Depending on the
implementation, the blocks mentioned above may or may not be present.
For details on the communication channels refer to section 3.2 on page 51.
Depending on the implementation, an application channel may or may not be present in the dual-port
memory. An OEM may choose to run an additional preprocessing application on the netX rather than
on the host system. That application can use this channel for preprocessing data and transferring the
results. An example for such an application is a barcode scanner using solely the netX chip.
For details on the application channels refer to section 3.4 on page 78.
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 5760 Bytes Cyclic Output Process Data Image
Input Data Image 0 0x2980 5760 Bytes Cyclic Input Process Data Image
App. Channel 1
Table 8: Default Memory Mapping
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 Today, most of the fieldbus firmware utilizes the default memory layout.
NOTE If not mentioned otherwise, this document refers to the default memory layout.
The size of one communication channel is always 15.616 Bytes for the default layout. The size of the
communication channel plus the size of the handshake channel plus the size of the system channel
equals 16 KBytes.
In the variable layout, the Control and Common Status blocks are mandatory and always present.
Structure and size of these blocks are fixed. The Extended Status block is optional and may not be
present. The Send and Receive Mailbox are mandatory and always present, but variable in its size
and location. Depending on the implementation, Input and Output Data Images may or may not be
present. They have a variable size.
! Change of State
collection of flags, that initiate execution of certain commands or signal a change of state
! Mailbox
transfer non-cyclic messages or packages with a header for routing information
! Data Area
holds process image for cyclic process data or user defined data structures
! Control Block
is used to signal application related state to the netX firmware
! Status Block
holds information regarding the current network state
Lock Configuration
Yes
RCX_COMM_COS_CONFIG_LOCKED Set?
No
No
HCF_HOST_COS_CMD = =
NCF_HOST_COS_ACK?
Yes
Set APP_COS_LOCK_CONFIG
Set APP_COS_LOCK_CONFIG_ENABLE
Toggle HCF_HOST_COS_CMD
Yes
HCF_HOST_COS_CMD = =
NCF_HOST_COS_ACK?
No
Yes
No
Wait Timeout?
Yes
HCF_HOST_COS_CMD = =
NCF_HOST_COS_ACK?
No
Clear APP_COS_LOCK_CONFIG_ENABLE
Finish Fault
The application sets the Lock Configuration flag and the Lock Configuration Enable flag in the control
block. Then the application toggles the Host Change of State Command flag in the host handshake
register, signaling to the channel firmware the new request. The firmware acknowledges the new state
by toggling the Host Change of State Acknowledge flag in the netX handshake register.
2.4.5 Mailbox
The mailbox system on netX provides a non-cyclic data transfer channel for fieldbus protocols.
Another use of the mailbox is allowing access to the firmware running on the netX chip itself for
diagnostic purposes. There is always a send and a receive mailbox. Send and receive mailboxes
utilize handshake bits to synchronize data packets into or out of the mailbox area. The handshake
registers have a pair of handshake bits, one for the send mailbox and one for the receive mailbox.
The netX operating system rcX uses only the system mailbox. The system mailbox, however, has a
mechanism to route packets to a communication channel. A channel mailbox passes packets to its
own protocol stack only.
Process data transfer through the data blocks can be synchronized by using a handshake mechanism
(configurable). If in uncontrolled mode, the protocol stack updates the process data in the input and
output data image in the dual-port memory for each valid bus cycle. No handshake bits are evaluated
and no buffers are used. The application can read or write process data at any given time without
obeying the synchronization mechanism otherwise carried out via handshake registers. This transfer
mechanism is the simplest method of transferring process data between the protocol stack and the
application. This mode can only guarantee data consistency over a byte.
For the controlled / buffered mode, the protocol stack updates the process data in the internal input
buffer for each valid bus cycle. Each IO block uses handshake bits for access synchronization. Input
and output data block handshake operates independently from each other. When the application
toggles the input handshake bit, the protocol stack copies the data from the internal buffer into the
input data image of the dual-port memory. Now the application can copy data from the dual-port
memory and then give control back to the protocol stack by toggling the appropriate input handshake
bit. When the application/driver toggles the output handshake bit, the protocol stack copies the data
from the output data image of the dual-port memory into the internal buffer. From there the data is
transferred to the network. The protocol stack toggles the handshake bits back, indicating to the
application that the transfer is finished and a new data exchange cycle may start. Using this
mechanism either the protocol stack or application/driver temporarily "owns" the input/output data area
and has exclusive write/read access to it. So this mode guarantees data consistency over both input
and output area.
2 (Extended) Status Block Send Mailbox Receive Mailbox Output Data Image Input Data Image
Application Task
3 Fieldbus Task(s)
Network
This document explains how to access the dual-port memory through alternative 1 (and 2, if the user
application is executed on the netX chip in the context of the rcX operating system and uses the virtual
DPM) in the above image. Alternative 3 is explained in the fieldbus specific documentation and is not
part of this document.
Manufacturer
0x0018 UINT16 usManufacturer Manufacturer Code / Manufacturer Location
(see page 31)
Production Date
0x001A UINT16 usProductionDate
Date of Production (see page 31)
License Code
0x001C UINT32 ulLicenseFlags1
License Flags 1 (see page 32)
License Code
0x0020 UINT32 ulLicenseFlags2
License Flags 2 (see page 32)
License Code
0x0024 UINT16 usNetxLicenseID
netX License Identification (see page 32)
License Code
0x0026 UINT16 usNetxLicenseFlags
netX License Flags (see page 32)
Device Class
0x0028 UINT16 usDeviceClass
netX Device Class (see page 33)
Hardware Revision
0x002A UINT8 bHwRevision
Hardware Revision Index (see page 34)
Hardware Compatibility
0x002B UINT8 bHwCompatibility
Hardware Compatibility Index (see page 35)
Device Identification Number
0x002C UINT8 bDevIdNumber Identification Number read form Rotary Switches
(or similar) (see page 35)
Reserved
0x002D UINT8 bReserved
Set to Zero
0x002E Reserved
UINT16 usReserved
… 0x002F Set to Zero
Table 10: System Information Block
Serial Number
This field holds the serial number of the netX chip, respectively device. It is a 32-bit value. If the value
is equal to zero, the serial number is not set.
Manufacturer
The manufacturer code / manufacturer location is one of the following.
Production Date
The production date entry is comprised of the calendar week and year (starting in 2000) when the
module was produced. Both, year and week are shown in hexadecimal notation. If the value is equal
to zero, the manufacturer date is not set.
Example:
A Production Date of 0x062B indicates year 2006 and calendar week 43.
License Code
These fields contain licensing information that is available for the netX firmware and tools. All four
fields (License Flags 1, License Flags 2, netX License ID & netX License Flags) help identifying
available licenses. If the license information fields are equal to zero, a license or license code is not
set. The license information is read from the security memory during startup.
License Flags 1 are used to indicate the type of master protocols that are licensed. If a flag set, a
license is present. The number of master stacks that are licensed is indicated by bits 31 and 30 (see
below).
ulLicenseFlags1
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
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
ulLicenseFlags1 (continued)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 …
Reserved, Set to Zero
00 = Unlimited Number of Master Licenses
01 = 1 Master License
10 = 2 Master Licenses
11 = 3 Master Licenses
Table 15: License Flags 1
License Flags 2 are used for tool licenses, e. g. SYCON.net or OPC server (bits 1 and 0). If a flag is
set, a tool license is present.
ulLicenseFlags2
31 30 29 28 … 10 9 8 7 6 5 4 3 2 1 0
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 17: License Flags 2
Device Class
This field identifies the hardware and helps selecting a suitable firmware file from the view of an
application when downloading a new firmware. The following hardware device classes are defined.
Hardware Revision
The Hardware Revision field indicates the current hardware revision of a module. It starts with one and
is incremented with every significant hardware change. The value ranges from 1 to 35. The identi-
fication label on the hardware shows 1, 2 ... 9, A, B ... Z, where A corresponds to 10, B to 11 … and Z
to 35.
ASCII characters are used for the hardware revision, if the Device Class is equal to NETX CHIP (see
above, either netX 50, 100 or 500). In this case, the hardware revision starts with ‘A’ (0x41, 65
respectively). All other devices use numbers.
Channel Type
This field identifies the channel type of the corresponding memory location. The following channel
types are defined.
Size of Channel
This field contains the length of the entire channel itself in bytes.
Communication Class
This array element holds further information regarding the protocol stack. It is intended to help
identifying the ‘communication class’ or ‘device class’ of the protocol.
Conformance Class
This field identifies the supported functionality of the protocol stack (PROFIBUS supports DPV1 or
DPV2, PROFINET complies with conformance class A/B/C, etc.). The entry depends on the protocol
class of the communication channel (see above) and is defined in the protocol specific manual.
Reserved
These areas are reserved for further use and should not be altered. It is set to zero. The same applies
to the user-defined array in the application section of the above structure.
The netX system register is written by the netX; the host system reads this register. The netX system
register is located at address 0x0202 in the dual-port memory.
NOTE The data width of the netX system flags is 8 bit. The bits D15 – D8 are ignored.
The host system flags are written by the host system; the netX reads these flags. The host system
register is located at address 0x0203 in the dual-port memory.
NOTE The data width of the host system flags is 8 bit. The bits D15 – D8 are ignored.
Changing flags in this register requires the driver/application also to toggle the Host Change of State
Command flag in the Host System Flags register (see page 43). Only then, the netX protocol stack
recognizes the change.
System Status
Among others, the system status field holds information whether or not a Flash Files system is
supported by the RCX operating system.
ulSystemStatus
31 30 29 28 27 26 25 24 23 22 21 … 3 2 1 0
RCX_SYS_STATUS_OK
unused, set to zero
Boot Medium
0000 = RCX_SYS_STATUS_BOOTMEDIUM_RAM
0001 = RCX_SYS_STATUS_BOOTMEDIUM_SERFLASH
0010 = RCX_SYS_STATUS_BOOTMEDIUM_PARFLASH
unused, set to zero
RCX_SYS_STATUS_NO_SYSVOLUME
RCX_SYS_STATUS_SYSVOLUME_FFS
RCX_SYS_STATUS_NXO_SUPPORTED
Table 33: System Status Field
Boot Error
If the 2nd Stage Boot Loader encounters an error during startup procedure, an error code is written into
this location. For details see boot loader documentation.
CPU Load
This field holds the netX CPU load. The resolution is 0,01%. Therefore a value of 10.000 corresponds
to 100%.
Hardware Features
The hardware features field indicates if an external memory is supported. Additionally, it indicates the
type of clock that is supported by the netX hardware, if any.
ulHWFeatures
31 30 … 12 11 10 9 8 7 6 5 4 3 2 1 0
External Memory Type
0000 = None
0001 = MRAM 64*16 Bit (1 Mbit/128 KB)
Reserved, set to 0
External Memory Access Type
00 = No access
01 = External access (host)
10 = Internal access
11 = External and internal access
Clock Type
00 = No RTC
01 = RTC external
10 = RTC internal
11 = RTC emulated
Clock Status
0 = Time not valid
1 = Time valid
Unused, set to zero
Table 35: Hardware Features Field
NOTE If not mentioned otherwise, the offset address convention used in this section is always
related to the beginning of corresponding communication channel start address, which starts
with 0x0000 here.
Default Communication Channel Layout
Offset Type Name Description
Reserved
0x0000 Structure tReserved
See Page 56 for Details
Control
0x0008 Structure tControl
See Page 57 for Details
Common Status Block
0x0010 Structure tCommonStatus
See Page 59 for Details
Extended Status Block
0x0050 Structure tExtendedStatus
See Page 66 for Details
Send Mailbox
0x0200 Structure tSendMbx
See Page 66 for Details
Receive Mailbox
0x0840 Structure tRecvMbx
See Page 66 for Details
High Priority Output Data Image 1
0x0E80 UINT8 abPd1Output[64]
Not Yet Supported, Set to 0
High Priority Input Data Image 1
0x0EC0 UINT8 abPd1Input[64]
Not Yet Supported, Set to 0
Reserved
0x0F00 UINT8 abReserved1[256]
Set to 0
Output Data Image 0
0x1000 UINT8 abPd0Output[5760]
See Page 74 for Details
Input Data Image 0
0x2680 UINT8 abPd0Input[5760]
See Page 74 for Details
Table 38: Default Communication Channel Layout
This flags register is organized as a bit field. The netX protocol stack writes the register to control data
synchronization via the mailbox system and the process data image. It also informs the host
application about its current network state. The register is read by the host system.
This flags register is organized as a bit field. The register is written by the host system to control data
synchronization via the mailbox system and the process data image. The register is read by the netX
protocol stack.
Device Watchdog
The protocol stack supervises the host system using the watchdog function. If the application fails to
copy the value from the host watchdog location (page 59) to the device watchdog location (page 57),
the protocol stack assumes that the host system has some sort of problem and interrupts all network
connections immediately regardless of their current state. For details on the watchdog function, refer
to section 4.15 on page 168.
Handshake Mode
The protocol stack supports different handshake mechanisms to synchronize process data exchange
with the host application. Depending on the configured mode, this mechanism insures data
consistency over the entire data image and helps synchronizing host application and network. This
register holds the configured handshake mode. For details on the handshake mechanism refer to
section 4.2 on page 94.
Synchronization Status
This field is reserved for future use.
In addition to the Common Status Block outlined on page 59, a master firmware maintains the
following field. In slave protocol implementations this field is reserved for future use and set to zero.
Master Status
Slave State
The Slave State field indicates whether the master is in cyclic data exchange to all configured slaves.
If there is at least one slave missing or if the slave has a diagnostic request pending, the status
changes to FAILED. For protocols that support non-cyclic communication only, the slave state is set to
OK as soon as a valid configuration is found.
Other Elements
Today no structure elements for devices such as gateway type devices are defined. Those elements
may be included into or added to the structure when it becomes necessary in the future.
The slave firmware uses the common structure as outlined on page 59 only.
Status Structures
The Status Structures tStatusStruct are a collection of descriptors for a specific memory area in the
DPM. This location is used to maintain various protocol, device or implementation specific status
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 the channel, the status information and the IO data image are consistent and
updated together according to the configured handshake mode.
Extended Status Block (Channel Specific)
Offset Type Name Description
Area
0x0100 + n UINT8 bStateArea
Location of the external state information
Type ID
0x0101 + n UINT8 bStateTypeID Defines meaning and size of entity within this
state area
Number of State Entries
0x0102 + n UINT16 usNumOfStateEntries
Number of state entries in the state area
0x0104 + n UINT32 ulStateOffset Byte start offset in the defined memory area
With n = 0, 8, 16, 24 … 248
Table 56: Extended State Structure
Status Type ID
The Status Type ID indicates the type of the status information field. It implicitly defines meaning and
size of the entity within state field. This could be i.e. a list of one or more bits or even bytes per IO data
unit corresponding to the status definition of the specific protocol. The following types of status
information are defined. The list of supported type IDs can be found in the related Protocol API
manual.
Value Definition / Description
1 List of Configured Slaves (Bit Field)
2 List of Activated Slaves (Bit Field)
3 List of Faulted Slaves (Bit Field)
Other values are reserved
Table 58: Status Type ID
NOTE Not all of the status types are supported by every protocol stack.
Status Offset
This field holds the offset to the start of the status information field location. The status information
field itself is located in this communication channel, in the area defined by “Sub Block Type”, begins at
“Status Offset” and consists of “Number of State Entries”. The information content is defined by
“Status Type ID”. The offset address is related to the beginning of corresponding communication
channel start address.
NOTE Depending on bStateTypeID and usNumOfStateEntries, the state field always allocates
memory space aligned to 32 bit entities (rounded up to the next double word).
Example
This is an example of the state structures in the extended status block and state field definitions for
communication channel 0.
In the above example, the first entry in the Status 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 data
image. bStateTypeID holds the type of information located in the output data image (list of configured
slaves, list of activated slaves or list of faulted slaves). The next entry, too, points to a location within
the output data image (bStateArea = 8), and so on.
NOTE If the status field is configured to be located in the IO data image of the channel, the status
filed and the IO data image are consistent and updated together according to the handshake
mode.
A send/receive mailbox is always available in the communication channel. See page 79 for details on
mailboxes and packets.
Channel Mailboxes
Offset Type Name Description
Packages Accepted
0x0200 UINT16 usPackagesAccepted
Number of Packages that can be Accepted
Reserved
0x0202 UINT16 usReserved
Set to 0
Send Mailbox
0x0204 UINT8 abSendMbx[1596] Non Cyclic Data To The Network or To the
Protocol Stack
Packages Waiting
0x0840 UINT16 usWaitingPackages Counter of Packages that are Waiting to be
Processed
Reserved
0x0842 UINT16 usReserved
Set to 0
Receive Mailbox
0x0844 UINT8 abRecvMbx[1596] Non Cyclic Data From the Network or From the
Protocol Stack
Table 59: Channel Mailboxes
In case of a network fault (e.g. disconnected network cable), a slave firmware keeps the last state of
the input data image and clears the Communicating flag in netX communication flags (see page 52).
The input data should not be evaluated.
NOTE In case of a network fault (e.g. disconnected network cable), a slave firmware keeps the last
state of the input data and clears the Communicating flag in netX communication flags (see
page 52). In this case the input data should not be evaluated.
This block can also be read using the mailbox interface (see page 80 for details).
NOTE If not mentioned otherwise, the offset addresses convention used in this section are always
related to the beginning of corresponding channel start address.
The firmware running on the netX chip can configure the handshake channel to be 16 bit or 8 bit wide.
Changing from one setting to another will not only change the width, it will also change the offset
addresses of these registers. The current width of the handshake registers can be found on page 39 in
section 3.1.2.
The handshake flags of the system channel are always 8 bit wide.
Please note: the data width of the handshake register is not the same as the width of the physical
interface used to access the dual-port memory.
NOTE In interrupt mode, when an 8 bit-host performs a read access to any of the 16 bit wide
handshake registers, the netX releases the interrupt as soon as the high byte or the low byte
was read. The read order (high byte first or low byte first) is irrelevant. An 8 bit-host shall use
polling mode instead of interrupt mode.
For compatibility reasons, the cells for the handshake block itself are present but not used and set to
zero. The application channels 0 and 1 are not supported yet and set to zero.
NOTE Each mailbox can hold one packet at a time. The netX firmware stores packets that are not
retrieved by the host application in an internal packet queue. This queue has limited space
and may fill up so new packets maybe lost. To avoid these deadlock situations, it is strongly
recommended to empty the mailbox frequently, even if packets are not expected by the
host application. Unexpected command packets should be returned to the sender with an
Unknown Command in the status field; unexpected reply messages can be discarded.
The size of a packet is always at least 40 bytes. Depending on the command, a packet may or may
not have a payload in the data field (tData). If present, the content of the data field is specific to the
command or reply, respectively.
Destination Identifier
The ulDestId field identifies the destination of an unsolicited packet from the netX firmware to the host
system. It can hold any handle that helps to identify the receiver. Its use is mandatory for unsolicited
packets. The receiver of unsolicited packets has to register for this service (details are TBD).
Source Identifier
The ulSrcId field identifies the originator of a packet. This field is used by a host application, which
passes a packet from an external process to an internal netX task. The ulSrcId field holds the handle
of the external process. When netX operating system returns the packet, the application can identify
the packet and returns it to the originating process. The receiving task on the netX does not evaluate
this field and passes it back unchanged. For inter-task communication, this field is not used.
Identifier
The ulId field is used to identify a specific packet among others of the same kind. That way the
application or driver can match a specific reply or confirmation packet to a previous request packet.
The receiving task does not change this field and passes it back to the originator of the packet. Its use
is optional in most of the cases. But it is mandatory for fragmented packets! Example: Downloading
big amounts of data that does not fit into a single packet. For fragmented packets the identifier field is
incremented by one for every new packet.
Command / Response
The ulCmd field holds the command code or the response code, respectively. The command/response
is specific to the receiving task. If a task is not able to execute certain commands, it will return the
packet with an error indication. A command is always even (the least significant bit is zero). In the
response packet, the command code is incremented by one indicating a confirmation to the request
packet.
Extension
The extension field ulExt is used for controlling packets that are sent in a sequenced or fragmented
manner. The extension 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.
Routing Information
The ulRout field is used internally by the netX firmware only. It has no meaning to a driver type
application and therefore set to zero.
ulDest = 0x00
ulDest = 0x01
ulDest = 0x02
ulDest = 0x20
ulDest = 0x00
ulDest = 0x01
ulDest = 0x02
ulDest = 0x20
ulDest = 0x00
ulDest = 0x01
ulDest = 0x02
netX OS
rcX
AP Task 1
AP Task 2
The above figure and table below illustrates the use of the destination identifier ulDest.
ulDest Description
A word about the channel identifier 0x00000020 (= Channel Token). The Channel Token is valid for
any mailbox. That way the application uses the same identifier for all packets without actually knowing
which mailbox or communication channel is applied. The packet stays ‘local’. The system mailbox is a
little bit different, because it is used to communicate to the netX operating system rcX. The rcX has its
own range of valid commands codes and differs from the communication channels.
If there is a reply packet, the netX operating system returns it to the same mailbox the request packet
went through. Consequently, the host application has to return its reply packet to the mailbox the
request was received from.
Send Packet
No
Packet Length < =
Mailbox Size?
Yes
No
HCF_SEND_MBX_CMD = =
NCF_SEND_MBX_ACK?
Yes
Wait...
No
No Yes
HCF_SEND_MBX_CMD = =
Timeout?
NCF_SEND_MBX_ACK?
Yes
Copy Packet
Toggle
HCF_SEND_MBX_CMD
Finish Fault
In order to receive a packet, the function checks if the netX Receive Mailbox Command flag and the
Host Receive Mailbox Acknowledge flag have different values. If so, the host application is allowed to
access the mailbox. When coping data form mailbox is done, the host toggles the Host Receive
Mailbox Acknowledge flag to give control to the netX firmware.
Receive Packet
NCF_RECV_MBX_CMD = = No
HCF_RECV_MBX_ACK?
Yes
Wait...
No
No Yes
NCF_RECV_MBX_CMD = =
Timeout?
HCF_RECV_MBX_ACK?
Yes
Copy Packet
Toggle
HCF_RECV_MBX_ACK
Finish Fault
Application #444
Process #11
Process #22
Process #33
Channel
Mainbox
Example:
This example applies to command messages imitated by a process in the context of the host
application identified by number #444. If the process #22 sends a packet through the channel mailbox
to the AP task, the packet header has to be filled in as follows:
Destination Queue Handler ulDest = 32; /* 0x20: local channel mailbox */
Source Queue Handler ulSrc = 444; /* host application */
Destination Identifier ulDestId = 0; /* not used */
Source Identifier ulSrcId = 22; /* process number */
For packets through the channel mailbox, the application uses 32 (= 0x20, Channel Token) for the
destination queue handler ulDest. The source queue handler ulSrc and the source identifier ulSrcId
are used to identify the originator of a packet. The destination identifier ulDestId can be used to
address certain resources in the protocol stack. It is not used in this example. The source queue
handler ulSrc has to be filled in. Therefore its use is mandatory; the use of ulSrcId is optional.
The netX operating system passes the request packet to the protocol stack’s AP task. The protocol
stack then builds a reply to the packet and returns it to the mailbox. The application has to make sure
that the packet finds its way back to the originator (process #22 in the example).
The host application may send request packets to the netX firmware at any time (transition 1 " 2).
Depending on the protocol stack running on the netX, parallel packets are not permitted (see protocol
specific manual for details). The netX firmware sends a confirmation packet in return, signaling
success or failure (transition 3 " 4) while processing the request.
The host application has to register with the netX firmware in order to receive indication packets
(transition 5 " 6). Depending on the protocol stack, this is done either implicit (if application opens a
TCP/UDP socket) or explicit (if application wants to receive unsolicited DPV1 packets). Details on
when and how to register for certain events is described in the protocol specific manual. Depending on
the command code of the indication packet, a response packet to the netX firmware may or may not
be required (transition 7 " 8).
Application netX
#
$
%
&
'
(
)
The host application has to register with the netX firmware in order to receive indication packets
(unsolicited telegrams). Depending on the protocol stack, this is done either implicit (if application
opens a TCP/UDP socket) or explicit (if application wants to receive unsolicited DPV1 packets).
Details on when and how to register for certain events is described in the protocol specific manual.
When an appropriate event occurs and the host application is registered to receive such a notification,
the netX firmware passes an indication packet through the mailbox (transition 1 " 2). The host
application is expected to send a response packet back to the netX firmware (transition 3 " 4).
Application netX
#
$
%
&
While transferring fragmented packets, two elements of the packet header receive special attention.
For one, there is the extension field ulExt. The field extension is used for controlling fragmented
packets. The extension field indicates a single packet or a packet of a sequence (first, middle or last).
The following definitions apply to the extension field.
The other important field is the identifier field ulId. The identifier field is used to identify a specific
packet among others. It holds the sequence number, which gets incremented by one for every new
packet. The identifier field does not necessarily need to start with zero for a new sequence. It may hold
any value as long as it gets incremented by one for the next packet.
NOTE A data block must be sent in the order of its original sequence. Sequence numbers must not
be skipped or used twice. The firmware cannot re-assemble a data block that is out of its
original order.
4.1.7.2 Procedure
The sections below shows packet by packet the use of the command field ulCmd, the identifier field
ulId and the extension field ulExt from the packet header while transferring fragmented data block
between host application and netX firmware. Note that every request packet has a confirmation
packet.
Download Request, Initiated by the Host Application
In this scenario the application knows that the data packet to send is too big to fit into the one packet
at once. Hence the application sets the First Packet of Sequence bit in the extension field ulExt; the
netX firmware on the other side can expect at least one more packet. The fragmented download is
always finalized with Last Packet of Sequence set in the extension field.
… … … Middle Fragment, …
… … … Middle Fragment, …
A data block transfer should be aborted when a sequence number in the identifier field ulId is skipped
or used twice. Failure in handling the extension flags in ulExt result a sequence fault, too. In case the
receiving process runs out of memory to store the data, the Out of Memory fault code shall be used.
To abort the sequence of fragmented data blocks, the receiving or sending process may send a
packet with the packet’s original command code (in this example: ulCmd = CMD, CMD is fieldbus
dependent) at any time during the process. Additionally, the length field ulLen is set to zero and the
extension field ulExt is set to indicate the last sequenced packet. In a regular sequence, the
combination of last packet bit set and zero data length is invalid.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
ulSrc UINT32 Source Queue Handle
ulDestId UINT32 Destination Queue Reference
ulSrcId UINT32 Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 Status
0xC02B0024 Packet out of Sequence
0xC0000010 Out Of Memory
ulCmd UINT32 CMD Command
ulExt UINT32 Extension
0x00000040 Last Packet of Sequence
ulRout UINT32 0x00000000 Routing Information
For the abort request packet, ulSta holds the error / status code. The following codes are used to
indicate a sequence or memory error, respectively.
/* PACKET OUT OF SEQUENCE */
#define RCX_E_PACKET_OUT_OF_SEQ 0xC000000F
/* OUT OF MEMORY */
#define RCX_E_PACKET_OUT_OF_MEMORY 0xC0000010
The receiver returns a packet with original command code plus one (in this example: ulCmd = CMD+1,
CMD is fieldbus dependent). The length field ulLen is set to zero and the extension field ulExt is set to
indicate the last sequenced packet.
0 Input Data
0
1 Output Data
2 Input Data
1
3 Output Data
4 Input Data
2
5 Output Data
6 Input Data
3
7 Output Data
Table 71: DMA Channel Assignment
Not all protocol stacks support I/O data transfer by DMA. Refer to the protocol specific documentation
to find out whether or not DMA transfer is supported.
NOTE Only PCI cards support DMA mode.
NOTE The network cycle and the task cycle of the host application are not synchronized but
consistent.
! 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.
! If the host application is slower than the network cycle, the protocol stack overwrites the input
buffer with new data received from the network, which were never received by the host
application. The output data on the network will be the same over several network cycles.
For each valid bus cycle the protocol stack updates the process data in the internal input buffer. When
the application toggles the appropriate input handshake bit, the protocol stack copies the data from the
internal IN buffer into the input data image of the dual-port memory. Now the application can copy data
from the dual-port memory and then give control back to the protocol stack by toggling the appropriate
input handshake bit. When the application/driver toggles the output handshake bit, the protocol stack
copies the data from the output data image of the dual-port memory into the internal buffer. From there
the data is transferred to the network. The protocol stack toggles the appropriate handshake bits back,
indicating to the application that the transfer is finished and a new data exchange cycle may start.
This mode guarantees data consistency over both input and output area.
Step-by-Step Procedure
Application Network
OUT OUT
DPM Buffer
IN IN
DPM Buffer
Step 1 The protocol stack sends data from the internal OUT buffer to the network and receives data
from the network in the internal IN buffer.
Application Network
OUT OUT
DPM Buffer
IN IN
DPM Buffer
Step 2 The application has control over the dual-port memory and exchanges data with the input
and output data images in the dual-port memory. The application then toggles the handshake bits,
giving control over the dual-port memory to the protocol stack.
Application Network
OUT OUT
DPM Buffer
IN IN
DPM Buffer
Step 3 The protocol stack copies the content of the output data image into the internal OUT buffer
and from the IN buffer to the input data image.
Application Network
OUT OUT
DPM Buffer
IN IN
DPM Buffer
Step 4 The protocol stack toggles the handshake bits, giving control back to the application. Now
the protocol stack uses the new output data image from the OUT buffer to send it to the network and
receives data into the internal IN buffer. The cycle starts over.
# Data
-
Handshake
$ %
&
'
t
. The protocol stack constantly transmits data from the buffer to the network.
/ The application has control over the dual-port memory and can copy data to the
output data image.
0 The application then toggles the handshake bits, giving control over the dual-port
memory to the protocol stack.
1 The protocol stack copies the content of the output data image into the internal OUT
buffer.
2 The protocol stack toggles the handshake bits, giving control back to the
application.
3 Once updated, the protocol stack uses the new data from the internal buffer and
sends it to the network. The cycle starts over with step 1.
Data
-
#
Handshake
%
$
'
t
&
-' The protocol stack constantly receives data from the network into the buffer.
4 The application has control over the dual-port memory input data image and
exchanges data with the input data image in the dual-port memory.
5 The application then toggles the handshake bits, giving control over the dual-port
memory to the netX protocol stack.
6 The protocol stack copies the latest content of the internal IN buffer to the input data
image of the dual-port memory.
7 The protocol stack then toggles the handshake bits, giving control back to the
application.
'- The protocol stack receives data from the network into the buffer. The cycle starts over with the
first step.
NOTE In case of a network fault (e.g. disconnected network cable), a slave firmware keeps the last
state of the input data image. As soon as the firmware detects the network fault, it clears the
Communicating flag in netX communication flags (see page 52); the input data should not be
evaluated anymore.
For master implementations, the input data status field indicates whether the data following this field is
valid. The status is either transferred by the originator of the data or generated locally in the netX
firmware.
If the Generated flag is set to True (= generated locally), the master firmware set the status to Good
for slaves that are healthy and available on the network; otherwise it is set to Bad. If the Generated
flag is set to False (= generated remotely), the status information shown in the field is generated and
transmitted by the originator of the data (for instance PROFINET supports this feature). For slave
implementations if generated locally (Generated flag is True) the data status is set to Good, if the
slave has a faultless connection to the network master.
The lower nibble of the data status field is specific to the underlying fieldbus and therefore described in
a separate manual.
31 30 … 12 11 10 9 8 7 6 5 4 3 2 1 0
Fieldbus Specific
Reserved, set to zero
Generated
0 = Remote
1 = Locally
Provider State
0 = Stop
1 = Run
Data State
0 = Bad
1 = Good
unused, set to zero
Table 73: Input Data Status
The output status data field indicates whether the data following this field is valid. The status flags are
generated by the application. The application indicates its own status and therefore this field is also a
provider status. The choices are Good or Bad for the data state flag and Run or Stop for the provider
state flag.
The lower nibble of the data status field is specific to the underlying fieldbus and therefore described in
a separate manual.
31 30 … 12 11 10 9 8 7 6 5 4 3 2 1 0
Fieldbus Specific
Reserved, set to zero
Provider State
0 = Stop
1 = Run
Data State
0 = Bad
1 = Good
unused, set to zero
Table 75: Output Data Status
The second option enables the channel firmware to open network connections automatically without
interacting with the host application. It is called Automatic start of communication. This method is not
recommended, because the host application has no control over the network connection status. In this
case the Bus On flag is not evaluated.
NOTE For the default dual-port memory layout, the Controlled Start of communication is the default
method used.
To allow the protocol stack to open connections or to allow connections to be opened, the application
sets the Bus On flag in the Application Change of State register in the channel’s control block (see
page 57). When firmware has established a cyclic connection to at least one network mode, the
channel firmware sets the Communicating flag in the netX Communication Flags register (see page
52).
To force the channel firmware to disable all network connections, the host application clears the Bus
On flag in the Application Change of State register in the channel’s control block (see page 57). The
firmware then closes all open network connections. A slave protocol stack would reject attempts to re-
open a connection, until the application allows opening network connections again (Bus On flag is
set). When all connections are closed, the channel firmware clears the Communicating flag in the netX
Communication Flags register on page 52.
The application uses the following packet in order to start or stop network communication. The packet
is send through the channel mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000020 CHANNEL
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 4 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00002F30 Start/Stop Communication
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
ulParam UINT32 Parameter
0x00000001 Start Communication
0x00000002 Stop communication
The application uses the following packet in order to lock or unlock the current configuration. The
packet is send through the channel mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000020 CHANNEL
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 4 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00002F32 Lock/Unlock Configuration
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
ulParam UINT32 Parameter
0x00000001 Lock Configuration
0x00000002 Unlock Configuration
The following structure is located in the system channel information block (see page 36). It is an
example for the communication channel 1. The structure indicates whether the channel is present. If
the channel type is NOT AVAILABLE, the channel is not present and no information from this structure
should be evaluated.
Channel Structure taken from System Channel Information Block
Address Channel Area Structure
Data Type Description
Communication
0x0060 UINT8 Channel Type = COMMUNICATION (see page 38)
Channel 1
UINT8 Channel ID, Channel Number
UINT8 Size / Position of Handshake Cells
UINT8 Total Number of Blocks in this Channel
UINT32 Size of Channel in Bytes
UINT16 Communication Class (Master, Slave…)
UINT16 Protocol Class (PROFIBUS, PROFINET…)
UINT16 Protocol Conformance Class (DPV1, DPV2…)
… 0x006F UINT8[2] Reserved
Table 77: Block Definition (Example for Communication Channel 1)
4.6.3 Mechanism
Evaluating the structure outlined on page 36, the application generates a request message through
the system block to obtain more information regarding the structure of the channel. Using the position
of the structure in the system channel information block, the application knows which of the channels
are available. The first channel following the handshake channel is the communication channel 0; the
next entry represents the second communication channel, and so on.
The application creates further messages through the system channel mailbox with the channel ID
number bChannelId from channel information block (see page 36) using the command message from
below. The netX firmware returns a confirmation message with the number of areas or blocks present
in the given memory block.
With the number of blocks, the application is able to create another message to the netX firmware
through the system block mailbox. The netX firmware returns a confirmation message with the identity,
type, start offset and length of the block. In addition, the reply message contains the data direction of
the block (host system to netX or netX to host system) as well as the transfer mode (DPM or DMA).
The following request message is sent to the netX firmware to obtain block information. The message
is sent through the system mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 8 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification As Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001EF8 Get Block Information Request
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
ulAreaIndex UINT32 0 … 7 Area Index (see below)
ulSubblock
Index UINT32 0 … 0xFFFFFFFF Sub Block Index (see below)
Area Index
This field holds the index of the channel. The system channel is identified by an index number of 0; the
handshake has index 1, the first communication channel has index 2 and so on.
Area Index
This field defines the channel number that the block belongs to. The system channel has the number
0; the handshake channel has the number 1; the first communication channel has the number 2 and
so on (max. 7).
Offset
This field holds the offset of the block based on the start offset of the channel.
Size
The size field holds the length of the block section in multiples of bytes.
Transmission Flags
The flags field is separated into nibbles (4 bit entities). The lower nibble is the Transmission Direction
and holds information regarding the data direction from the view point of the application. The
transmission type nibble in this location holds the type of how to exchange data with this sub block.
Handshake Mode
The handshake mode is defined only for IO data images.
Handshake Position
The handshake cells either can be in the handshake channel or (in the future and therefore not
supported yet) they can be located at the beginning of each channel. See pages 75 and 52 for details.
NOTE Not all combinations of values from this structure are allowed. Some are even contradictory
and do not make sense.
! License Code
! Device Class
Zone 2 is used for PCI configuration and operating system parameter. Zone 2 is readable and
writeable.
Zone 3 is fully under control of a user application running on the netX to store its data, if applicable.
Zone 3 is readable and writeable.
The Configuration Zone holds entries that are predefined by the manufacturer of the EEPROM. This
zone is written only during production. The Configuration Zone is neither readable nor writable. The
zone includes serial number, device number, hardware revision, production date, device class and
hardware compatibility. This information is shown in the system information block (Table 10 on page
28) and is part of the packet which is described in section Identifying netX Hardware through Packets
on page 121.
NOTE Usually it is not necessary to write to zones 1 or 2 nor is it recommended. Changes can
cause memory access faults, configuration or communication problems!
Zones 1 and 2 of the Security Memory are protected by a checksum (see page 120 for details).
An application uses the following packet in order to read from the Security EEPROM. The packet is
send through the system mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 4 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001EBC Read Security EEPROM
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
Zone Identifier
0x00000001 Zone 1
ulZoneId UINT32
0x00000002 Zone 2
0x00000003 Zone 3
/* Memory Zones */
#define RCX_SECURITY_EEPROM_ZONE_1 0x00000001
#define RCX_SECURITY_EEPROM_ZONE_2 0x00000002
#define RCX_SECURITY_EEPROM_ZONE_3 0x00000003
Zone Data
The zone data field holds data that is returned from Zone X (X equal to 1, 2 or 3).
An application uses the following packet in order to write to the Security EEPROM. The packet is sent
through the system mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 36 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001EBE Write Security EEPROM
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
Zone Identifier
0x00000001 Zone 1
ulZoneId UINT32
0x00000002 Zone 2
0x00000003 Zone 3
abZone Data for Zone X (X equal to 1, 2 or 3);
UINT8 0 ... 0xFF
Data[32] Size is 32
/* Memory Zones */
#define RCX_SECURITY_EEPROM_ZONE_1 0x00000001
#define RCX_SECURITY_EEPROM_ZONE_2 0x00000002
#define RCX_SECURITY_EEPROM_ZONE_3 0x00000003
The configuration zone and zone 0 are neither readable nor writable.
Data Field
There is no data field returned in the write security EEPROM confirmation packet.
NOTE To avoid changing essential parameters in the security memory by accident, the application
must read the entire zone first, modify fields as required and write the entire zone afterwards.
Channing parameter like SDRAM register or PCI settings may cause unwanted behavior of
the netX chip and it might get into a state where no further operation is possible.
4.7.1.6 Checksum
Zones 0, 1 and 2 of the Security Memory are protected by a checksum. The netX operating system
provides functions that automatically calculate the checksum when the zones 1 and 2 are written. So
in a packet to write these zones the checksum field is set to zero. The packet to read these zones
returns the checksum stored in the Security Memory.
In case the Security Memory is not found or provides inconsistent data, the netX operating system
copies the following default values into the system information block (see page 28).
! Device Number, Device Identification Set to zero
! Serial Number Set to zero
! Hardware Assembly Options Set to NOT AVAILABLE
! Manufacturer Set to UNDEFINED
! Production Date Set to zero for both, production year and week
! License Code Set to zero
! Device Class Set to UNDEFINED
The application uses the following packet in order to identify netX hardware. The packet is send
through the system mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001EB8 Identify Hardware
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
Boot Type
This field indicates how the netX operating system was started.
Chip Type
This field indicates the type of chip that is used.
The application uses the following packet in order to obtain license information from the netX firmware.
The packet is send through the system mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001EF4 License Information
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
License Code
These fields contain licensing information that is available for the netX chip. All four fields (License
Flags 1, License Flags 2, netX License ID & netX License Flags) help identifying available licenses. If
the license information fields are equal to zero, a license or license code is not set. See page 32 for
details.
The application uses the following packet in order to obtain information about the netX hardware. The
packet is send through the system mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001EF6 Read Hardware Information
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
bHw
UINT8 Hardware Compatibility Index (see page 35)
Compatibility 0
ulHardware Hardware Features 1
UINT32
Features1 0 Not used, set to 0
ulHardware Hardware Features 2
UINT32
Features2 0 Not used, set to 0
Boot Option
bBootOption UINT8
0 Not used, set to 0
Array of Reserved
bReserved[11]
UINT8 0 Reserved, set to 0
/*Channel Identification */
#define RCX_SYSTEM_CHANNEL 0xFFFFFFFF
#define RCX_COMM_CHANNEL_0 0x00000000
#define RCX_COMM_CHANNEL_1 0x00000001
#define RCX_COMM_CHANNEL_2 0x00000002
#define RCX_COMM_CHANNEL_3 0x00000003
Only if the packet is sent through the system channel, ulChannelId is evaluated. Otherwise
ulChannelId is ignored.
If the boot loader is active, the request above returns its version. Once a firmware is loaded, the boot
loader is erased from the memory. Then packet returns the version of the operating system. In both
cases RCX_PACKET_DEST_SYSTEM is used for ulDest and the packet is passed through the system
mailbox.
NOTE Boot loader and operating system (or firmware respectively) does not reside on the netX chip
side by side.
Version
The version field is described on page 210.
Name
This field holds the name of the firmware comprised of ASCII characters. The first byte of the field
holds the length of the following valid characters. Unused bytes are set to zero. The name string is
limited to 63 characters.
Date
This field holds the date of the release of the firmware. The first element holds the year; the second
element holds the month (range 1 … 12); the third element holds the day (range 1 … 31).
To reset the netX operating system rcX and all communication channels the host application has to
write 0x55AA55AA (System Reset Cookie) to the ulSystemCommandCOS variable in the system
control block (see page 45). Then the HSF_RESET flag in bHostSysFlags (see page 43) has to be
set. If the operating system does not find 0x55AA55AA in the ulSystemCommandCOS variable, the
reset command is being ignored.
The operating system clears the NSF_READY flag in bNetxFlags in the system handshake register
(page 42), indicating that the system wide reset is in progress. During the reset all communication
channel tasks are stopped regardless of their current state. The rcX operating system flushes the
entire dual-port memory and writes all memory locations to zero. After the reset the rcX is finished
without complications and all protocol stacks are started properly, the NSF_READY flag is set again.
Otherwise, the NSF_ERROR flag in bNetxFlags in the system handshake register is set and an error
code is being written in ulSystemError in the system status block (see page 46) that helps identifying
possible problems.
The image below illustrates the steps the host application has to perform in order to execute a system-
wide reset on the netX chip through the dual-port memory.
System Rest
Yes
NSF_READY Bit Set?
No
Write Reset Cookie
Yes Yes
NSF_READY Bit Cleared? NSF_READY Bit Set?
No No
No No
Timeout? Timeout?
Yes Yes
Fault Finish
Timing
The duration of the reset outlined above, depends on the firmware. Typically the NSF_READY flag is
cleared within around 100 – 500 ms after the HSF_RESET Flag was set. When cleared, the
NSF_READY bit will be set again after around 0.5 – 5 s. Generally, the reset should not take more
than 6 s.
In order to force the protocol stack to restart and evaluate the configuration parameter again, the
application can set the APP_COS_INIT flag in the ulApplicationCOS register in the control block or
send a reset packet to the communication channel. All open network connections are interrupted
immediately regardless of their current state. If the database is locked, re-initializing the channel is not
allowed (see pages 57 and 59).
Changing flags in the ulApplicationCOS register requires the application also to toggle the host
change of state command flag in the host communication flags register (see page 54). Only then, the
netX protocol stack recognizes the reset command.
During channel initialization the RCX_COMM_COS_READY flag and the RCX_COMM_COS_RUN
flag are cleared together. The RCX_COMM_COS_READY flag stays cleared for at least 20 ms before
it is set again indicating that the initialization has been finished. The RCX_COMM_COS_RUN flag is
set, if a valid configuration was found. Otherwise it stays cleared.
After the initialization process has finished, the protocol stack checks ulApplicationCOS register. If the
RCX_APP_COS_BUS_ON flag and the RCX_APP_COS_BUS_ON_ENABLE flag set, network
communication will be restored automatically. The same is true for the Lock Configuration feature
(RCX_APP_COS_LOCK_CONFIG / RCX_APP_COS_LOCK_CONFIG_ENABLE) and the DMA data
transfer mechanism (RCX_APP_COS_DMA / RCX_APP_COS_DMA_ENABLE).
The image below illustrates the steps the host application has to perform in order to execute a channel
initialization on the protocol stack through the dual-port memory.
Channel Initialization
No
HCF_HOST_COS_CMD ==
NCF_HOST_COS_ACK?
No
Yes
Yes
Wait... Timeout?
Yes No
HCF_HOST_COS_CMD ==
NCF_HOST_COS_ACK?
Set RCX_APP_COS_INIT
Set RCX_APP_COS_INIT_ENABLE
Toggle HCF_HOST_COS_CMD
No
HCF_HOST_COS_CMD ==
NCF_HOST_COS_ACK?
No
Yes
Yes
Wait... Timeout?
Yes No
HCF_HOST_COS_CMD ==
NCF_HOST_COS_ACK?
Clear RCX_APP_COS_INIT_ENABLE
No
RCX_COMM_COS_READY Set?
No
Yes
Yes Wait... Timeout?
Yes No
RCX_COMM_COS_READY Set?
Finish Fault
The Boot Start feature uses a flag from the bHostFlags in the system handshake register on page 43 If
the HSF_BOOTSTART flag is set while a system reset is executed the netX operating system is
forced to stay in boot loader mode after the system reset has finished. A firmware that might reside on
the chip is not started. If the flag is cleared during reset, the firmware is being started.
To enable the boot loader mode, do the following:
2. Set HSF_BOOTSTART flag in bHostFlags in the host system flags in the system handshake
register.
3. Write the system reset cookie into the ulSystemCommandCOS variable in the system control
block.
4. Set the HSF_RESET flag in bHostFlags in the host system flags in the system handshake
register. The system reset is being executed as outlined above.
NOTE The Boot Start feature is not available on cifX 50 cards.
The application uses the following packet in order to reset netX chip. The reset packet is send through
the system mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 8 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E00 System Reset
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information, Not Used
tData Structure Information
ulTimeToReset UINT32 0 … 0xFFFFFFFF Time Delay to Reset in ms
Reset Mode
ulResetMode UINT32
0 Not used, set to zero
Compared to the system reset, the channel initialization affects the designated channel only. A
channel initialization forces the protocol stack to immediately close all network connections and start
over. While the stack is started the configuration settings are evaluated again. The packet is send
through the channel mailbox.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000020 CHANNEL
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00002F80 Channel Initialization
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information, Not Used
If an error occurs during the download, the process must be canceled by sending a download abort
command.
The packet below is the first request to be sent to the rcX operating system to start a file download.
The application provides the length of the file and its name in the request packet.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 18 + n Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command:
0x00001E62 File Download Request
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
ulRout UINT32 0x00000000 Routing Information (not used)
tData Structure Information
Download Transfer Type
ulXferType UINT32
1 File Transfer
ulMaxBlock Max Block Size
UINT32
Size 1 … m Maximum Size of Block per Packet
File Length
ulFileLength UINT32
File size to be downloaded
Channel Number
ulChannelNo UINT32 0 … 3 Communication Channel
0xFFFFFFFF System Channel
usFileName Length of Name
UINT16
Length n Length of the Following File Name (in Bytes)
File Name
abFileName[n] UINT8
0x20 … 0x7F ASCII string, Zero Terminated; Size is n
/* NO SEQUENCED PACKET */
#define RCX_PACKET_SEQ_NONE 0x00000000
/* TRANSFER FILE */
#define RCX_FILE_XFER_FILE 0x00000001
/* TRANSFER MODULE */
#define RCX_FILE_XFER_MODULE 0x00000002
/* Channel Number */
#define RCX_SYSTEM_CHANNEL 0xFFFFFFFF
#define RCX_COMM_CHANNEL_0 0x00000000
#define RCX_COMM_CHANNEL_1 0x00000001
#define RCX_COMM_CHANNEL_2 0x00000002
#define RCX_COMM_CHANNEL_3 0x00000003
The rcX operating system returns the following confirmation packet. It contains the size of the data
block that can be transferred in one packet.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
4 If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 From Request Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E63 File Download
ulExt UINT32 0x00000000 Extension
ulRout UINT32 Z Routing Information, Don’t Care, Don’t Use
tData Structure Information
ulMaxBlock Max Block Size
UINT32
Size 1 … n Maximum Size of Block per Packet
Block Size
The block size is returned in the reply packet, if ulSta is equal to RCX_S_OK. Otherwise no data field is
returned.
This packet is used to transfer a block of data to the netX operating system rcX to be stored on the file
system. The term data block is used to describe a portion of a file. The data block in the packet is
identified by a block or sequence number and is secured through a continuous CRC32 checksum.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 8 + n Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E64 File Data Download
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
0x00000080 First Packet of Sequence
0x000000C0 Sequenced Packet
0x00000040 Last Packet of Sequence
ulRout UINT32 0x00000000 Routing Information, Not Used
tData Structure Information
Block Number
ulBlockNo UINT32
0 ... m Block or Sequence Number
Checksum
ulChksum UINT32
S CRC32 Polynomial
abData[n] UINT8 0 … 0xFF File Data Block (Size is n)
/* PACKET SEQUENCE */
#define RCX_PACKET_SEQ_NONE 0x00000000
#define RCX_PACKET_SEQ_FIRST 0x00000080
#define RCX_PACKET_SEQ_MIDDLE 0x000000C0
#define RCX_PACKET_SEQ_LAST 0x00000040
The block or sequence number ulBlockNo starts with zero for the first data packet and is incremented
by one for each following packet. The checksum in ulChksum is calculated as a CRC32 polynomial. It
is a calculated continuously over all data packets that were sent already. A sample to calculate the
checksum is included in the toolkit for netX based products.
NOTE If the download fails, the rcX returns an error code in ulSta. The user application then has to
send an abort request packet (see page 149) and start over.
The rcX operating system returns the following confirmation packet. It contains the expected CRC32
checksum of the data block.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
4 If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 From Request Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E65 File Data Download
ulExt UINT32 Extension:
0x00000000 No Sequenced Packet
ulRout UINT32 Z Routing Information, Don’t Care, Don’t Use
tData Structure Information
ulExpected Checksum
UINT32
Crc32 S Expected CRC32 Polynomial
/* PACKET SEQUENCE */
#define RCX_PACKET_SEQ_NONE 0x00000000
Checksum
The checksum is returned in the reply that was calculated for the request packet, if ulSta is equal to
RCX_S_OK. Otherwise no data field is returned.
If necessary, the application can abort the download procedure at any time. If an error occurs during
downloading a file (the rcX operating system returns ulSta not equal to RCX_S_OK), the user
application has to abort the download procedure by sending the abort command outlined below.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E66 Abort Download Request
ulExt UINT32 0x00000000 Extension: None
ulRout UINT32 0x00000000 Routing Information, Not Used
The rcX operating system returns the following confirmation packet, indicating that the download was
aborted.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 From Request Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E67 Abort Download Confirmation
ulExt UINT32 0x00000000 Extension: None
ulRout UINT32 Z Routing Information, Don’t Care, Don’t Use
Data Field
There is no data field returned in the Abort Download confirmation packet.
If an error occurs, during uploading a file, the process must be canceled by sending an upload abort
command.
The packet below is the first request to be sent to the rcX operating system to start a file upload. The
application provides the length of the file and its name in the request packet.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 14 + n Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E60 File Upload Request
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
ulRout UINT32 0x00000000 Routing Information, Not Used
tData Structure Information
Transfer Type:
ulXferType UINT32
1 rcX File Transfer
ulMaxBlock Max Block Size
UINT32
Size 1 … m Maximum Size of Block per Packet
Channel Number
ulChannelNo UINT32 0 … 3 Communication Channel
0xFFFFFFFF System Channel
usFileName Length of Name
UINT16
Length n Length of Following File Name (in Bytes)
File Name
abFileName[n] UINT8
0x20 … 0x7F ASCII String, Zero Terminated (Length is n)
/* PACKET SEQUENCE */
#define RCX_PACKET_SEQ_NONE 0x00000000
/* TRANSFER TYPE */
#define RCX_FILE_XFER 0x00000001
/* CHANNEL Number */
#define RCX_SYSTEM_CHANNEL 0xFFFFFFFF
#define RCX_COMM_CHANNEL_0 0x00000000
#define RCX_COMM_CHANNEL_1 0x00000001
#define RCX_COMM_CHANNEL_2 0x00000002
#define RCX_COMM_CHANNEL_3 0x00000003
/* PACKET SEQUENCE */
#define RCX_PACKET_SEQ_NONE 0x00000000
This packet is used to transfer a block of data from the rcX file system to the user application. The
term data block is used to describe a portion of a file. The data block in the packet is identified by a
block or sequence number and is secured through a continuous CRC32 checksum.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E6E File Data Upload
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
0x00000080 First Packet of Sequence
0x000000C0 Sequenced Packet
0x00000040 Last Packet of Sequence
ulRout UINT32 0x00000000 Routing Information, Not Used
/* PACKET SEQUENCE */
#define RCX_PACKET_SEQ_NONE 0x00000000
#define RCX_PACKET_SEQ_FIRST 0x00000080
#define RCX_PACKET_SEQ_MIDDLE 0x000000C0
#define RCX_PACKET_SEQ_LAST 0x00000040
The rcX operating system returns the following confirmation packet. It contains the block number and
the expected CRC32 checksum of the data block.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Form Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 8 + n Packet Data Length (in Bytes)
ulId UINT32 From Request Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E6F File Data Upload
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
ulRout UINT32 Z Routing Information, Don’t Care, Don’t Use
tData Structure Information
Block Number
ulBlockNo UINT32
0 ... m Block or Sequence Number
Checksum
ulChksum UINT32
S CRC32 Polynomial
abData[n] UINT8 0 … 0xFF File Data Block (Size is n)
/* PACKET SEQUENCE */
#define RCX_PACKET_SEQ_NONE 0x00000000
NOTE If the download fails, the user application has to abort the download and start over.
If necessary, the application can abort the upload procedure at any time. If an error occurs during
uploading a file (the rcX operating system returns ulSta not equal to RCX_S_OK), the user application
has to cancel the upload procedure by sending the abort command outlined below.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle:
0x00000000 SYSTEM
ulSrc UINT32 x Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E5E Abort Upload Request
ulExt UINT32 0x00000000 Extension: None
ulRout UINT32 0x00000000 Routing Information, Not Used
The rcX operating system returns the following confirmation packet, indicating that the Upload was
aborted.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 From Request Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E5F Abort Upload
ulExt UINT32 0x00000000 Extension: None
ulRout UINT32 z Routing Information, Don’t Care, Don’t Use
/*****************************************************************************/
/*! CRC 32 lookup table */
/*****************************************************************************/
static unsigned long Crc32Table[256]=
{
0x00000000UL, 0x77073096UL, 0xee0e612cUL, 0x990951baUL, 0x076dc419UL, 0x706af48fUL, 0xe963a535UL,
0x9e6495a3UL, 0x0edb8832UL, 0x79dcb8a4UL, 0xe0d5e91eUL, 0x97d2d988UL, 0x09b64c2bUL, 0x7eb17cbdUL,
0xe7b82d07UL, 0x90bf1d91UL, 0x1db71064UL, 0x6ab020f2UL, 0xf3b97148UL, 0x84be41deUL, 0x1adad47dUL,
0x6ddde4ebUL, 0xf4d4b551UL, 0x83d385c7UL, 0x136c9856UL, 0x646ba8c0UL, 0xfd62f97aUL, 0x8a65c9ecUL,
0x14015c4fUL, 0x63066cd9UL, 0xfa0f3d63UL, 0x8d080df5UL, 0x3b6e20c8UL, 0x4c69105eUL, 0xd56041e4UL,
0xa2677172UL, 0x3c03e4d1UL, 0x4b04d447UL, 0xd20d85fdUL, 0xa50ab56bUL, 0x35b5a8faUL, 0x42b2986cUL,
0xdbbbc9d6UL, 0xacbcf940UL, 0x32d86ce3UL, 0x45df5c75UL, 0xdcd60dcfUL, 0xabd13d59UL, 0x26d930acUL,
0x51de003aUL, 0xc8d75180UL, 0xbfd06116UL, 0x21b4f4b5UL, 0x56b3c423UL, 0xcfba9599UL, 0xb8bda50fUL,
0x2802b89eUL, 0x5f058808UL, 0xc60cd9b2UL, 0xb10be924UL, 0x2f6f7c87UL, 0x58684c11UL, 0xc1611dabUL,
0xb6662d3dUL, 0x76dc4190UL, 0x01db7106UL, 0x98d220bcUL, 0xefd5102aUL, 0x71b18589UL, 0x06b6b51fUL,
0x9fbfe4a5UL, 0xe8b8d433UL, 0x7807c9a2UL, 0x0f00f934UL, 0x9609a88eUL, 0xe10e9818UL, 0x7f6a0dbbUL,
0x086d3d2dUL, 0x91646c97UL, 0xe6635c01UL, 0x6b6b51f4UL, 0x1c6c6162UL, 0x856530d8UL, 0xf262004eUL,
0x6c0695edUL, 0x1b01a57bUL, 0x8208f4c1UL, 0xf50fc457UL, 0x65b0d9c6UL, 0x12b7e950UL, 0x8bbeb8eaUL,
0xfcb9887cUL, 0x62dd1ddfUL, 0x15da2d49UL, 0x8cd37cf3UL, 0xfbd44c65UL, 0x4db26158UL, 0x3ab551ceUL,
0xa3bc0074UL, 0xd4bb30e2UL, 0x4adfa541UL, 0x3dd895d7UL, 0xa4d1c46dUL, 0xd3d6f4fbUL, 0x4369e96aUL,
0x346ed9fcUL, 0xad678846UL, 0xda60b8d0UL, 0x44042d73UL, 0x33031de5UL, 0xaa0a4c5fUL, 0xdd0d7cc9UL,
0x5005713cUL, 0x270241aaUL, 0xbe0b1010UL, 0xc90c2086UL, 0x5768b525UL, 0x206f85b3UL, 0xb966d409UL,
0xce61e49fUL, 0x5edef90eUL, 0x29d9c998UL, 0xb0d09822UL, 0xc7d7a8b4UL, 0x59b33d17UL, 0x2eb40d81UL,
0xb7bd5c3bUL, 0xc0ba6cadUL, 0xedb88320UL, 0x9abfb3b6UL, 0x03b6e20cUL, 0x74b1d29aUL, 0xead54739UL,
0x9dd277afUL, 0x04db2615UL, 0x73dc1683UL, 0xe3630b12UL, 0x94643b84UL, 0x0d6d6a3eUL, 0x7a6a5aa8UL,
0xe40ecf0bUL, 0x9309ff9dUL, 0x0a00ae27UL, 0x7d079eb1UL, 0xf00f9344UL, 0x8708a3d2UL, 0x1e01f268UL,
0x6906c2feUL, 0xf762575dUL, 0x806567cbUL, 0x196c3671UL, 0x6e6b06e7UL, 0xfed41b76UL, 0x89d32be0UL,
0x10da7a5aUL, 0x67dd4accUL, 0xf9b9df6fUL, 0x8ebeeff9UL, 0x17b7be43UL, 0x60b08ed5UL, 0xd6d6a3e8UL,
0xa1d1937eUL, 0x38d8c2c4UL, 0x4fdff252UL, 0xd1bb67f1UL, 0xa6bc5767UL, 0x3fb506ddUL, 0x48b2364bUL,
0xd80d2bdaUL, 0xaf0a1b4cUL, 0x36034af6UL, 0x41047a60UL, 0xdf60efc3UL, 0xa867df55UL, 0x316e8eefUL,
0x4669be79UL, 0xcb61b38cUL, 0xbc66831aUL, 0x256fd2a0UL, 0x5268e236UL, 0xcc0c7795UL, 0xbb0b4703UL,
0x220216b9UL, 0x5505262fUL, 0xc5ba3bbeUL, 0xb2bd0b28UL, 0x2bb45a92UL, 0x5cb36a04UL, 0xc2d7ffa7UL,
0xb5d0cf31UL, 0x2cd99e8bUL, 0x5bdeae1dUL, 0x9b64c2b0UL, 0xec63f226UL, 0x756aa39cUL, 0x026d930aUL,
0x9c0906a9UL, 0xeb0e363fUL, 0x72076785UL, 0x05005713UL, 0x95bf4a82UL, 0xe2b87a14UL, 0x7bb12baeUL,
0x0cb61b38UL, 0x92d28e9bUL, 0xe5d5be0dUL, 0x7cdcefb7UL, 0x0bdbdf21UL, 0x86d3d2d4UL, 0xf1d4e242UL,
0x68ddb3f8UL, 0x1fda836eUL, 0x81be16cdUL, 0xf6b9265bUL, 0x6fb077e1UL, 0x18b74777UL, 0x88085ae6UL,
0xff0f6a70UL, 0x66063bcaUL, 0x11010b5cUL, 0x8f659effUL, 0xf862ae69UL, 0x616bffd3UL, 0x166ccf45UL,
0xa00ae278UL, 0xd70dd2eeUL, 0x4e048354UL, 0x3903b3c2UL, 0xa7672661UL, 0xd06016f7UL, 0x4969474dUL,
0x3e6e77dbUL, 0xaed16a4aUL, 0xd9d65adcUL, 0x40df0b66UL, 0x37d83bf0UL, 0xa9bcae53UL, 0xdebb9ec5UL,
0x47b2cf7fUL, 0x30b5ffe9UL, 0xbdbdf21cUL, 0xcabac28aUL, 0x53b39330UL, 0x24b4a3a6UL, 0xbad03605UL,
0xcdd70693UL, 0x54de5729UL, 0x23d967bfUL, 0xb3667a2eUL, 0xc4614ab8UL, 0x5d681b02UL, 0x2a6f2b94UL,
0xb40bbe37UL, 0xc30c8ea1UL, 0x5a05df1bUL, 0x2d02ef8dUL
};
/* Channel Number */
#define RCX_SYSTEM_CHANNEL 0xFFFFFFFF
#define RCX_COMM_CHANNEL_0 0x00000000
#define RCX_COMM_CHANNEL_1 0x00000001
#define RCX_COMM_CHANNEL_2 0x00000002
#define RCX_COMM_CHANNEL_3 0x00000003
/* TYPE: DIRECTORY */
#define RCX_DIR_LIST_CNF_FILE_TYPE_DIRECTORY 0x00000001
/* TYPE: FILE */
#define RCX_DIR_LIST_CNF_FILE_TYPE_FILE 0x00000002
4.15.1 Function
The netX firmware reads the content of the device watchdog cell, increments the value by one and
copies it back into the host watchdog location. Now the application has to copy the new value from the
host watchdog location into the device watchdog location. Copying the host watchdog cell to the
device watchdog cell has to happen in the configured watchdog time. When the overflow occurs, the
firmware starts over and a one appears in the host watchdog cell. A zero turns off the watchdog and
therefore never appears in the host watchdog cell in the regular process.
The minimum watchdog time is 20 ms. The application can start the watchdog function by copying any
value unequal to zero into device watchdog cell. A zero in the device watchdog location stops the
watchdog function. The watchdog timeout is configurable in SYCON.net and downloaded to the netX
firmware.
If the application fails to copy the value from the host watchdog location to the device watchdog
location within the configured watchdog time, the protocol stack will interrupt all network connections
immediately regardless of their current state. If the watchdog tripped, power cycling, channel reset or
channel initialization allows the communication channel to open network connections again.
Parameter Field
ulParam
31 30 … 12 11 10 9 8 7 6 5 4 3 2 1 0
Store MAC Address
Force MAC Address
Reserved, set to zero
Table 88: Set MAC Address Parameter Field
Data Field
There is no data field returned in the Set MAC Address confirmation packet.
/* Channel Number */
#define RCX_COMM_CHANNEL_0 0x00000000
#define RCX_COMM_CHANNEL_1 0x00000001
#define RCX_COMM_CHANNEL_2 0x00000002
#define RCX_COMM_CHANNEL_3 0x00000003
This packet is used to request the System Information Block as outlined on page 28.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E32 Read System Information Block
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
The following packet is returned. The structure in the data portion of the packet is the System
Information Block from section 3.1.1.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
48 If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E33 Read System Information Block
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
ulRout UINT32 0x00000000 Routing Information (not used)
tData Structure Information
System Information Block
tSystemInfo Structure
(see page 28 for details)
This packet is used to request one section of the Channel Information Block as outlined on page 36.
Using channel ID, the application can request one block per packet.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 4 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E34 Read Channel Information Block
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
Channel Identifier
ulChannelId UINT32
0 … 7 Port Number, Channel Number
The following packet is returned by the firmware. The data portion of the packet is the channel
information block of either the system channel, handshake channel, communication channel or the
application channel.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
16 If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E35 Read Channel Information Block
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
ulRout UINT32 0x00000000 Routing Information (not used)
tData Structure Information
Channel Information Block
tChannelInfo Structure
(see page 36 for details)
This packet is used to request the System Control Block as outlined on page 45.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E36 Read System Control Block
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
The following packet is returned by the firmware. The structure in the data portion of the packet is
identical to the structure outlined in section 3.1.5.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
8 If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E37 Read System Control Block
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
ulRout UINT32 0x00000000 Routing Information (not used)
tData Structure Information
tSystem System Control Block
Structure
Control (see page 45 for details)
This packet is used to request the System Status Block as outlined on page 46.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 0 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E38 Read System Status Block
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
The following packet is returned by the firmware. The structure in the data portion of the packet is
identical to the structure outlined in section 3.1.6.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
64 If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E39 Read System Status Block
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
ulRout UINT32 0x00000000 Routing Information (not used)
tData Structure Information
System Status Block
tSystemState Structure
(see page 46 for details)
This packet is used to request the Communication Control Block as outlined on page 57. The firmware
ignores the Channel Identifier ulChannelId, if the packet is passed through the channel mailbox.
The length field, however, has to be set to 4.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
0x00000020 CHANNEL
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 4 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001E3A Read Communication Control Block
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
Channel Identifier
ulChannelId UINT32
0 … 7 Port Number, Channel Number
The following packet is returned by the firmware. The structure in the data portion of the packet is
identical to the structure outlined in section 3.2.4.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
8 If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001E3B Read Communication Control Block
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
ulRout UINT32 0x00000000 Routing Information (not used)
tData Structure Information
Communication Control Block
tControl Structure
(see page 57 for details)
This packet is used to request the common status block as outlined on page 59. The firmware ignores
the Channel Identifier ulChannelId, if the packet is passed through the channel mailbox. The length
however, has to be set to 4 in any case.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
0x00000020 CHANNEL
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 4 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001EFC Read Common Status Block
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
Channel Identifier
ulChannelId UINT32
0 … 7 Port Number, Channel Number
The following packet is returned by the firmware. The structure in the data portion of the packet is
identical to the structure outlined in section 3.2.5.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
64 If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001EFD Read Common Status Block
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
ulRout UINT32 0x00000000 Routing Information (not used)
tData Structure Information
Common Status Block
tCommonStatus Structure
(see page 59 for details)
This packet is used to request the Extended Status Block as outlined on page 66. The firmware
ignores the Channel Identifier ulChannelId, if the packet is passed through the channel mailbox.
The length however, has to be set to 12.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000000 SYSTEM
0x00000020 CHANNEL
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 12 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00001EFE Read Extended Status Block
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
ulOffset UINT32 0 … 431 Byte offset in extended status block structure
ulDataLen UINT32 1 … 432 Length in byte read
ulChannel Channel Identifier
UINT32
Index 0 … 7 Port Number, Channel Number
The following packet is returned by the firmware. The structure in the data portion of the packet is
identical to the structure outlined in section 3.2.6.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
1 … 432 If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00001EFF Read Extended Status Block
ulExt UINT32 Extension
0x00000000 No Sequenced Packet
0x00000080 First Packet of Sequence
0x000000C0 Sequenced Packet
0x00000040 Last Packet of Sequence
ulRout UINT32 0x00000000 Routing Information (not used)
tData Structure Information
ulOffset UINT32 0 … 431 Byte offset in extended status block structure
ulDataLen UINT32 1 … 432 Length in byte read
Extended Status Block
abData[432] UINT8
(see page 66 for details)
/* Time Commands */
#define TIME_CMD_GETSTATE 0x00000001 /* get state */
#define TIME_CMD_GETTIME 0x00000002 /* get time */
#define TIME_CMD_SETTIME 0x00000003 /* set time */
/* Time Commands */
#define TIME_CMD_GETSTATE 0x00000001 /* get state */
#define TIME_CMD_GETTIME 0x00000002 /* get time */
#define TIME_CMD_SETTIME 0x00000003 /* set time */
ulData
31 30 … 12 11 10 9 8 7 6 5 4 3 2 1 0
Clock Type
00 = No RTC
01 = RTC internal
10 = RTC external
11 = RTC emulated
Clock Status
0 = Time not valid
1 = Time valid
Unused, set to zero
Table 90: Clock Status
5 Diagnostic
5.1 Versioning
Firmware and operating system versions consist of four parts. The version string is separated into a
Major, Minor, Build and Revision section.
The major number is increased for significant enhancements in functionality (backward compatibility
cannot be assumed); the minor number is incremented when new features or enhancement have been
added (backward compatibility is intended). The third number denotes bug fixes or a new firmware
build. The revision number is not used and set to zero. As an example, a firmware may at time jump
from version 1.80 to 1.85 indicating that significant features have been added.
The build number is set to one again, after the major number has been incremented. A zero value is
not valid for the build number.
Version Structure
typedef struct RCX_FW_VERSION_Ttag
{
UINT16 usMajor; /* major version number */
UINT16 usMinor; /* minor version number */
UINT16 usBuild; /* build number */
UINT16 usRevision; /* revision number */
} RCX_FW_VERSION_T;
5.2.1 Mechanism
The application can request information about the status of network slaves in regards of their cyclic
connection. Non-cyclic connections are not handled here. The netX firmware returns a list of handles
that each represents a slave device. Note that a handle of a slave is not its MAC ID, station or node
address, nor an IP address. The following lists are available:
The host application uses the packet below in order to request a list of slaves depending on the
requested type of list (configured, activated or faulted).
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000020 CHANNEL
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 4 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00002F08 Get Slave Handle
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
Parameter
0x00000001 List of Configured Slaves
ulParam UINT32
0x00000002 List of Activated Slaves
0x00000003 List of Faulted Slaves
/* LIST OF SLAVES */
#define RCX_LIST_CONF_SLAVES 0x00000001
#define RCX_LIST_ACTV_SLAVES 0x00000002
#define RCX_LIST_FAULTED_SLAVES 0x00000003
The master firmware (channel firmware) returns a list of handles. Each of the handles represents a
slave device depending on the requested type of list (configured, activated or faulted).
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
4 x (1+n) If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 From Request Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00002F09 Get Slave Handle
ulExt UINT32 Extension:
0x00000000 No Sequenced Packet
ulRout UINT32 Z Routing Information, Don’t Care, Don’t Use
tData Structure Information
Parameter
0x00000001 List of Configured Slaves
ulParam UINT32
0x00000002 List of Activated Slaves
0x00000003 List of Faulted Slaves
aulHandle[n] UINT32 0 … 0xFFFFFFFF Slave Handle, Number of Handles is n
Using the handles from the section above, the application can request network status information for
each of the configured network slaves.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 Destination Queue Handle
0x00000020 CHANNEL
ulSrc UINT32 X Source Queue Handle
ulDestId UINT32 0x00000000 Destination Queue Reference
ulSrcId UINT32 Y Source Queue Reference
ulLen UINT32 4 Packet Data Length (in Bytes)
ulId UINT32 Any Packet Identification as Unique Number
ulSta UINT32 0x00000000 Status
ulCmd UINT32 Command
0x00002F0A Get Slave Connection Information Request
ulExt UINT32 0x00000000 Reserved
ulRout UINT32 0x00000000 Routing Information
tData Structure Information
ulHandle UINT32 0 … 0xFFFFFFFF Slave Handle
The data returned in this packet is specific for the underlying fieldbus. It is identified by a unique
identification number. The identification number references a specific structure. Identification number
and structure are described in the fieldbus related documentation and the corresponding C header file.
Structure Information
Area Variable Type Value / Range Description
tHead Structure Information
ulDest UINT32 From Request Destination Queue Handle
ulSrc UINT32 From Request Source Queue Handle
ulDestId UINT32 From Request Destination Queue Reference
ulSrcId UINT32 From Request Source Queue Reference
ulLen UINT32 Packet Data Length (in Bytes)
8+sizeof(tState) If ulSta = RCX_S_OK
0 Otherwise
ulId UINT32 From Request Packet Identification as Unique Number
ulSta UINT32 See Below Status / Error Code, see Section 6
ulCmd UINT32 Confirmation
0x00002F0B Get Slave Connection Information
ulExt UINT32 Extension:
0x00000000 No Sequenced Packet
ulRout UINT32 Z Routing Information, Don’t Care, Don’t Use
tData Structure Information
ulHandle UINT32 0 … 0xFFFFFFFF Slave Handle
ulStructId UINT32 0 … 0xFFFFFFFF Structure Identification Number
Fieldbus Specific Slave Status Information
tState STRUCT
(Refer to Fieldbus Documentation)
Flags
The flags field holds information regarding the data transfer direction from the view point of the
application. The following flags are defined.
The transmission type field in the flags location holds the type of how to exchange data with this block.
The choices are:
Offset
This field holds the offset of the first byte used in the data image based on the start offset of the I/O
data block of the channel.
Length
The length field holds the number of bytes consumed by the process data image. Status fields are not
included in the length.
5.4 LEDs
There is only one system LED (SYS LED) per netX chip. The SYS LED is always present 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.
7 Appendix
7.1 Device Class
8 Glossary
See also
Term Description Page(s):
Area Process data image or other data structures of a channel using
Block handshake mechanism to synchronize access to the dual-port
memory; holds status information and diagnostic data of both
network related issues and firmware or task related issues
Change of State Method to synchronize or manage read/write access to shared 22 | 42 | 52
(COS) Mechanism memory blocks between the netX firmware on one side and the 57 | 60
6
9 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 Suwon, 443-734
Phone: +33 (0) 4 72 37 98 40 Phone: +82 (0) 31-695-5515
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]
New Delhi - 110 025 Support
Phone: +91 11 40515640 Phone: +49 (0) 6190 9907-99
E-Mail: [email protected] E-Mail: [email protected]
Italy USA
Hilscher Italia srl 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]