Introduction

This document provides information about how to build an application for the irj45 communication module.

Hardware setup

The module provides a management inferface, where initial configuration can be done. These properties can be stored permanently within the device. Following properties are provided to configure the SPI interface:

Table 3 SPI configuration
The module does only support SPI_TYPE slave.
The module does only support SPI_UNITWIDTH of 8 bit.
The module does only support SPI_TRANSFERSIZE of 128 byte.
The SPI mode can be configured according to Table 4.
The SPI bitorder can be configured according to Table 5.

Table 4 SPI Mode configuration

Table 5 SPI bitorder configuration

Basic application setup

A basic application consists of the optional function calls appl_init, appl_setup and appl_loop. It follows the design philosphy of the GOAL middleware.

Default Features

By default, the irj45 CC module will start a web server (on port 8080) for the firmware update feature and an instance of Device Detection for management using the management tool.
It is not possible by an AC application to disable the web server on the CC. However, the AC can start another instance of the web server.
It is possible for an AC application to limit the by default full management access through Device Detection in different ways. Please refer to the corresponding chapter in the documentation.

Features

Device Detection

Initial state

On the irj45 communication module DD is enabled by default. This allows full access to all variables and logs on the CC module. DD bases on a simple UDP based protocol with no encryption. Thus, an application can and should limit the access to a feasable range. Limitation of features and access is possible on various levels.

Initial disabling of features by the application

This property is applied at application startup when the AC application setup is executed. With the call of goal_ddNew() from appl_setup() a bitmask can be passed whith bits representing single functions of DD. Please refer to the API documentation of DD for possible values. If all bits are set, all features (hello, get, set, get_list, wink) are enabled.

Initial disabling of features by CM variable

The in chapter 4.5.1.2 described mechanism can also be set before application start by setting the corrensponding CM variable FEATURE_DISABLE (see chapter 4.9.1). Each request processed by the device detection module will utilize the value of this variable to determine, if the request is allowed to be processed.

Please note, that any call of goal_ddNew will overwrite the value of this variable, if a different initialization value is passed.

Temporary enable features of the device detection

This property is applied at an arbitraty time, for example when configured using a web site provided by the AC application.

• The parameter bitmask contains bits representing features being enabled

• Those bits overwrite the disable bits from CM for the current session

Filtering and access rights

This property is applied at starup of the AC application.

Using filters it is possible to limit access to CM variables by groups (module ids) and variables (variable ids). Currently some filters are predefined for usage. These can be enabled using following function:

  
This function works on a created instance of DD, thus requires passing of a valid DD handle. The setId can be used with following values:

Table 6 DD Filter IDs
Please refer to the API documentation of DD for detailed information.

PNIO

The communication module contains a full featured PROFINET slave stack. For application see the proper PROFINET documentation.

EtherNet/IP

The communication module contains a full featured EtherNet/IP slave stack. For application see the proper EtherNet/IP documentation.

EtherCAT

The communication module contains a full featured EtherCAT slave stack. For application see the EtherCAT stack documentation.

HTTPD

The communication module contains a web server for basic management functionality. Please refer to the proper HTTPD documentation as part of the GOAL - Programmer’s Manual.

Network channels

The communication module provides TCP and UDP communication channels. Please refer to the API documentation within this document for detailed description.

Generic Data Provider

For fieldbus communication applications a generic data provider is available, which contains gneralized information and led status for the application.

Table 7 MCTC Status information
The LED status information are a recommendation regarding conformance/usability of a device implementation. The delivered examples show usage of this feature.

Ethernet Startup Delay

With integration of EtherCAT in version 2.0.0.0 of the ccm module, an additional functionality was integrated which allows a dedicated startup of the network by the application controller. Depending on the chosen communication stack (e.g. PROFINET or EtherCAT), the network interface is brought up in the required mode.

A ccm module without an application controller however would never start the network in this scenario. Thus a fallback was implemented, which by default brings up the network after 5 seconds after startup of the ccm module. This behaviour can be configured using a ccm variable (module id 72, variable id 13).
Following table shows configuration options:

Table 8 ethernet timeout configuration
If powering of the application controller and establishing of the communication between AC and CC take longer then the configured timeout, it needs to be increased.

External Reset

The module provides an external reset input, where the AC can perform a reset of the irj45 module.

Therefore, it is recommended to utilize this reset only if the AC module is initially powered up (cold start).

RPC Synchronization reset

If either AC or CC restart, the peer module is required to restart too. Else a repeatedly RPC synchronization is not possible.

CC

By default, the CC module does not perform a reset implicitly. If the AC application restarts, a power cycle of the CC module (or a manual reset) is required. It is possible to configure this behaviour using the CM variable interface (see chapter 4.9.10).

AC

The AC performs a reset of it's application on request of the CC, e.g. when the CC restarts. This can happen during a firmware update.

IP Settings

IP Settings can be done with the CM interface.

Table 9 IP configuration with CM
To enable DHCP set the CM Variable GOAL_ID_NET:DHCP_ENABLED to 1 and perform a power cycle.

Management Interface CC

See goal_db, Page "Variables": The column "Long description" contains documentation of single variables. The management interface has following functions:

• Responding to scan requests for devices

• Listing CM variables

• Reading CM variables

• Writing CM variables

• Setting IP address

• Wink command

Each of those functions can be permanently disabled by setting a bit in the CM variable GOAL_ID_DD:FEATURE_DISABLE.

Management Interface DD

Module Id = GOAL_ID_DD (34)

Table 10 DD management interface

PNIO

Module Id = GOAL_ID_PNIO (27)

• Internal variables used by the Profinet stack

LM

These variables provide an interface for the logging manager of the irj45 module.
Module Id = GOAL_ID_LM (35)

Table 11 LM Management interface

NET

Module Id = GOAL_ID_NET (12)

Table 12 NET Management interface

BOOT

Module Id = GOAL_ID_BOOT (37)

Table 13 BOOTLOADER Management interface

CM

Module Id = GOAL_ID_CM (2)

Table 14 CM Management interface

ETH

Module Id = GOAL_ID_ETH (4)

Table 15 ETH Management interface

EIP

Module Id = GOAL_ID_EIP (23)

• Internal variables used by the EtherNet/IP stack

HTTPD

Module Id = GOAL_ID_HTTP (25)

Table 16 HTTP Management interface

CCM

Interface for Management Tool for informative and configuration purpose.
Module Id = GOAL_ID_CCM (72)

Table 17 CCM Management interface

Firmware Update

Update the communication controller

Firmware update of the communiation controller is possible in the field. It is done using the Management tool. This tool uses the HTTP protocol to transfer a firmware package to the device.

Firmware package

Firmware image is bundled within a package. This package contains a signed firmware, which secures only acceptance of firmware from the device originator. Thus, it is possible for the device to check authenticity of the firmware image.

Control interface

By default, a firmware update is possible at any time. The communication module provides an interface to enable and disable the firmware update process. An application should use this interface as there are situations where a firmware update should not be accepted. This should be deactivated during an active cyclic connection to the PLC. For usage of this interface see chapter 6.1.

Optionally the application controller can register for events regarding firmware update. Then a start and finish of transfer is signalled to the application controller. Its task is also to trigger the reboot to the bootloader and performance of the actual firmware update. Beside that a failed or succeeded firmware update is reported to the application controller. The callback function can be registered using appl_ccmFwUpdateCbReg().

Firmware update sequence

Firmware update is a two-step process. At first the firmware is uploaded to the http server of the CC module. Following checks are done during this check:

1. This upload uses authentication with authentication level 0, where credentials are checked if configured for the HTTPD module. Those variables are configurable through the RPC interface of the HTTPD service. By default, these credentials are empty. Thus, any attempt to authenticate is accepted.

2. The firmware update must be allowed by the AC. By default, this is the case. However, the AC can disable this function using the RPC interface.

If at the end of the transfer a valid firmware is detected, the module restarts and enters the bootloader. This software module checks the signature of the firmware and writes the correctly signed firmware to the memory of the device. As a fallback, the previously run firmware is kept. After restart of the module a successful communication to the management tool required to permanently enable the updated firmware. If this is possible, the module will restart again, and the bootloader will mark the new firmware as the current firmware. If this fails, the bootloader will revert to the original firmware with the next power cycle.

Keep update functionality while disabling DD

An application integrator might want to disable the DD feature to not expose any internal information of the device. Disabling is possible. However, to allow a firmware update using the management tool, the following steps need to be implemented:

1. Disabling DD by default

When calling the API function goal_ddNew, a bitmask can be passed, that determines the active DD features. If the predefined value GOAL_DD_FEAT_NO is used, DD is disabled completely.
Internally this value is stored to the CM variable FEATURE_DISABLE, which state also can be saved permanently to flash.

2. Introducing a switch to termporarily enable DD features

If a firmware update shall be processed, minimal DD features need to be set temporarily. These are:

• HELLO REQUEST

• SET CONFIG

• GET CONFIG

• SET IP

This can be done using the API function goal_ddSessionFeatureActivate() with the following arguments:

The temporary switch, to enable the management interface, can be implemented using the web server. See example 01_pnio_io_mirror for usage. As a result, the device will be invisible for the management tool. For firmware update, the required interface is temporarily activated, thus allowing to update the communication module firmware.

Update possibilities for application controller

By default, there is no firmware update available for the application controller. However, the module provides mechanisms for implementing such a feature within the customer application.
Following, two possible solutions are shown:

AC Firmware update over HTTP

The application controller can provide a web site or tool-based firmware update over HTTP transport, utilitung the provided RPC interface of the HTTPD service. As a starting point, the HTTPD example goal_http/02_post, respectively ccm example 20015013_irj45/01_pnio_io_mirror can be used.
For the latter, data for firmware update transported using a HTTP POST request will be processed in the callback function httpDataCbPost, for example as shown in the following sample code:

AC Firmware update over TCP

If HTTP is not favoured for transport of the firmware update, a plain TCP socket can be used for data transfer. This transport can be used the stream of data it provides, or any additional protocol can be used above this transport. See RPC interface of the networking tcp module.

Respectively, following callback function will handle received data: