Introduction

...

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.

...

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 whatssoever.
Thus, an application can and should limit the access to a feasable range. Limitation of features and access is possible on various levels.

...

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.

...

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.

...

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:

...

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

...

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 http HTTPD documentation as part of the goal maGOAL - 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.

...

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.

...

With integration of EtherCAT in version 2.0.0.0 of the ccm module, an additional functionality was integrated which allows deticated 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.

...

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

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

...

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

...

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.

...

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

...

Table 10 DD management interface

PNIO

Module Id = GOAL_ID_PNIO (27)

...

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)

...

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 HTTP protocol to transfer a firmware package to the device.

...

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().

...

When calling the API function goal_ddNew, a bitmask can be passed, that determines the active DD features. If the predefined value GOAL_DD_FEAATFEAT_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.

...

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.

...

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:

...

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:

/****************************************************************************/
/** TCP Server Callback
 *
 * Print a hexdump of the received data.
 */
static void tcpCallback(
    GOAL_MA_CHAN_TCP_T *pMaTcpHdl,              /**< MA handle */
    GOAL_NET_CB_TYPE_T cbType,                  /**< callback type */
    struct GOAL_NET_CHAN_T *pChan,              /**< channel descriptor */
    struct GOAL_BUFFER_T *pBuf                  /**< GOAL buffer */
)
{
    GOAL_NET_ADDR_T remote;                     /* remote address */
    GOAL_STATUS_T res;                          /* result */

    if (cbType == GOAL_NET_CB_NEW_SOCKET) {
        goal_logInfo("new TCP socket from TCPListener: %p", (void *) pChan);

        /* get IP Address of remote node */
        res = goal_maChanTcpGetRemoteAddr(pMaTcpHdl, pChan, &remote);
        if (GOAL_RES_ERR(res)) {
            goal_logErr("Failed to get Remote Address for socket %p", (void *) pChan);
            return;
        }

        goal_logInfo("sender 0x%08"FMT_x32":%u", remote.remoteIp, remote.remotePort);
    }
    else if (cbType == GOAL_NET_CB_NEW_DATA) {
        goal_logDbg("Data received on tcp socket %p", (void *) pChan);

        /* echo message or process data */
        goal_maChanTcpSend(pMaTcpHdl, pChan, pBuf);

    }
    else if (cbType == GOAL_NET_CB_CLOSING) {
        goal_logInfo("Closing TCP socket %p", (void *) pChan);
    }
}