1 Introduction
2 Basic application setup
3 Default Features
- 3.1 Web Server with Device Detection
- 3.2 Profinet
- 3.3 EtherNet/IP
- 3.4 EtherCAT
- 3.5 HTTPD
- 3.6 Network channels
- 3.7 Generic Data Provider
- 3.8 Ethernet Startup Delay
4 External Reset
5 RPC Synchronization reset
6 IP Settings
7 Management Interface CC
8 Firmware Update
- 8.1 Update the communication controller
- 8.2 Update possibilities for application controller

Introduction

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

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

Web Server with Device Detection

By default, the System-on-Module starts a web server (on port 8080) for the firmware update feature and an instance of Device Detection for management using the Industrial Communication Explorer. It is not possible by the application controller to disable the web server on the System-on-Module. However, the application controller can start another instance of the web server.

The activaed Device Detection allows full access to all variables and logs on the module. Device Detection 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.

The access can be fully modified using the appropriate API described at the DD documentation.

Profinet

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.

Data Provider Information	PROFINET	EtherNet/IP	EtherCAT
GOAL_MCTC_DP_STATUS_FLG_CONN	Connection	Connection	Connection (ESM-State == OP)
GOAL_MCTC_DP_STATUS_FLG_ERR	Error	Error	Application Layer Error
GOAL_MCTC_DP_STATUS_FLG_VALID	-	Process data valid	Process data valid

GOAL_MCTC_DP_LED_WINK	DCP blink signaling	-	-
GOAL_MCTC_DP_LED_RED1	Error	Module Status red	EC ERR Led May be configured to a STATUS Indicator, wher only LED_GREEN1 and LED_RED_1 are used.
GOAL_MCTC_DP_LED_RED2	Maintainance	Network Status red	(optional: part of the STATUS indicator)
GOAL_MCTC_DP_LED_GREEN1	Connection	Module Status green	EC RUN Led
GOAL_MCTC_DP_LED_GREEN2	DCP blink signaling	Network Status green	-

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 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 System-on-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:

Timeout value	function
0	default timeout enabled (5 seconds)
1 ... 254	value determines timeout in seconds
255	timeout disabled

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 module.

Do not perform this reset during a firmware update of the CC. This will prevent proper update functionality.

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.

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

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

IP Settings

IP Settings can be done with the Industrial Communication Explorer, via goal_maNetIpSet() or CM access, as described following:

Set CM Variable GOAL_ID_NET:IP to configure IP address,
Set CM Variable GOAL_ID_NET:NETMASK,
Set CM Variable GOAL_ID_NET:GW,
Set CM Variable GOAL_ID_NET:Valid to 1,
Set CM Variable GOAL_ID_NET:DHCP_ENABLED to 0,
Set CM Variable GOAL_ID_NET:COMMIT to 1

To enable DHCP set the CM Variable GOAL_ID_NET:DHCP_ENABLED to 1 and perform a power cycle.

Management Interface CC

See the Configuration Manager for a full list of availabel CM 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.

Firmware Update

Update the communication controller

Firmware update of the communiation controller is possible using HTTP. It is done using the Industrial Communication Explorer. 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 System-on-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.

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 callback
 *
 */
static void appl_fwUpdateCb(
    FW_UPDATE_SOURCE_T source,                  /**< fw update source */
    FW_UPDATE_STATUS_T state,                   /**< fw update status */
    uint8_t progress                            /**< fw update progress */
)
{
    switch (state) {
        default:
        case FW_UPDATE_IDLE:
            goal_logInfo("fw update state : IDLE");
            break;
        case FW_UPDATE_TRANSFER_INIT:
            goal_logInfo("fw update state : TRANSFER INIT");
            switch (source) {
                case FW_UPDATE_SOURCE_RPC:
                    goal_logInfo("fw update source : RPC");
                    break;
                case FW_UPDATE_SOURCE_HTTP:
                    goal_logInfo("fw update source : HTTP");
                    break;
                case FW_UPDATE_SOURCE_FOE:
                    goal_logInfo("fw update source : FOE");
                    break;
            }
            break;
        case FW_UPDATE_TRANSFER:
            goal_logInfo("fw update state : TRANSFER, progress = %d", progress);
            break;
        case FW_UPDATE_TRANSFER_DONE:
            goal_logInfo("fw update state : TRANSFER DONE");

            goal_logInfo("performing update, rebooting CCM module");
            /* perform actual update */
            appl_ccmFwUpdateExecute();
            break;
        case FW_UPDATE_ABORT:
            goal_logInfo("fw update state : ABORT");
            break;
        case FW_UPDATE_COMMIT_PENDING:
            goal_logInfo("fw update state : PENDING");
            break;
        case FW_UPDATE_COMMIT_DONE:
            goal_logInfo("fw update state : UPDATE DONE");
            break;
    }
}

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:

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.
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:

goal_ddSessionFeatureActivate(pHdlDd, GOAL_DD_FEAT_GETCONFIG | GOAL_DD_FEAT_SETCONFIG | GOAL_DD_FEAT_SETIP);

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:

/****************************************************************************/
/**
 * This is the http application callback.
 *
 * @retval GOAL_OK on success
 * @retval GOAL error code otherwise
 */
static GOAL_STATUS_T goal_http_cb(
    GOAL_HTTP_APPLCB_DATA_T *pCbInfo            /**< callback info */
)
{
    GOAL_STATUS_T res = GOAL_OK;                /* return value */
    static uint8_t data[32];                    /* test data */
    static uint8_t lenData = 0;                 /* test data length */
    unsigned int lenCopy = 0;                   /* length for copying data */

    /* check resource handle */
    if (hdlRes != pCbInfo->hdlRes) {
        /* error */
        goal_logErr("Requested resource does not match");
        res = GOAL_ERROR;
    }

    if (GOAL_RES_OK(res)) {
        /* check requested method */
        switch (pCbInfo->reqType)
        {
        case GOAL_HTTP_FW_GET:
            if (0 == GOAL_MEMCMP(pCbInfo->cs.pUrl, "/index.html?data", GOAL_STRLEN("/index.html?data"))) {
                /* return test data */
                GOAL_HTTP_GET_RETURN_RAW(pCbInfo, data, lenData);
            } else {
                /* set information for send function */
                GOAL_HTTP_GET_RETURN_HTML(pCbInfo, pageIndex, GOAL_STRLEN((const char *) pageIndex));
            }
            break;

        case GOAL_HTTP_FW_POST_START:
            goal_logInfo("Start of POST request reached application");
            /* reset test data */
            GOAL_MEMSET(data, 0, sizeof(data));
            lenData = 0;
            /* return html code "204 no content" */
            GOAL_HTTP_RETURN_OK_204(pCbInfo);
            break;

        case GOAL_HTTP_FW_POST_DATA:
            goal_logInfo("Data chunk of POST request reached application");
            /* calculate length for copying data */
            if (lenData < sizeof(data)) {
                if (pCbInfo->cs.lenData < (sizeof(data) - lenData)) {
                    lenCopy = pCbInfo->cs.lenData;
                } else {
                    lenCopy = sizeof(data) - lenData;
                }
                /* update recent data length */
                lenData += lenCopy;
            }
            /* copy testdata */
            GOAL_MEMCPY(data, pCbInfo->cs.pData, lenCopy);
            /* return html code "204 no content" */
            GOAL_HTTP_RETURN_OK_204(pCbInfo);
            break;

        case GOAL_HTTP_FW_POST_END:
            goal_logInfo("End POST request reached application");
            /* return html code "204 no content" */
            GOAL_HTTP_RETURN_OK_204(pCbInfo);
            break;

        case GOAL_HTTP_FW_REQ_DONE_OK:
        case GOAL_HTTP_FW_REQ_DONE_ERR:
            /* send info message */
            goal_logInfo("Transmission done");
            GOAL_HTTP_RETURN_OK_204(pCbInfo);
            break;

        default:
            break;
        }
    }

    return res;
}

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:

Application