Document info

• Version 1.0

• Last modification: 26.03.2021 / 08:47

Features

Which features provides the module

• PROFINET stack, Conformance Class B, Real Time Class 1

• EtherNet/IP stack

• Web server

• TCP channels

• UDP channels

• cyclic communication channel for real time data (PROFINET process data,
  EtherNet/IP process data) with up to 68 bytes input and 68 byte
  output data and a cycle time of 1 ms

• RPC interface for management, application setup and non realtime data

PROFINET

What are the capabilities of the device

• configurable number of modules and slots

• up to 68 bytes or process data per direction (input, output, ioxs, status
  information)

• up to 1 ms cycle time

• support for process alarms

• support for record data (read, write)

What functionality is not supported

• Redundancy (MRP)

• Dynamic module configuration (provided by connection request from PLC)

• Queue for sequential process alarm sending

ETHERNET/IP

What are the capabilities of the device

• Redundancy (DLR) - Beacon Based Ring Node

• 68 bytes of process data

What functionality is not supported

• Virtual CIP classes

Application Controller Integration

Footprint and Performance

What is a typical work load on the application controller?

TODO

What is the possible minimum cycle time on the SPI interface?

The SPI interface supports clock rates between 29.3 kHz and 10 MHz. Depending
on the SPI clock rate a minimum cycle time results. The module depends on
constant cyclic requests, thus with a slow SPI clock rate a required
responsiveness may not be achievable. Using a clock rate of 2 Mhz with a cyclic
request of 1 ms cycle time suffies to implement a slave in the field of
industrial communication capable of cycle times of 1 ms.

What are typical firmware footprints for the application controller?

This depends on the platform. Currently the Synergy S7, the STM32F4 and the
Raspberry PI are supported. Typical memory requirements are following:

An application for the application controller, which uses the GOAL framework
will typically utilize 200 - 300 kByte of ROM. Beside that typically around 100
kByte of RAM will be required. GOAL reserves a large memory block for it's heap
implementation, which is configured at compile time using
GOAL_CONFIG_HEAP_SIZE. Within this heap by default a 5 kByte Logging buffer
will be allocated, which can be configured using GOAL_LM_BUFFER_SIZE.

Table: memory footprint

Is an operating system required?

No, software package for the application controller operates with or without an operating system. The example code for the Synergy S7 CPU uses ThreadX operating system. The example code for the STM32F4 CPU does not use an operating system.

Does the software package implement a watchdog functionality?

The software on the communication controller implements a watchdog regarding the internal functionality. It watches execution times of critical routines and restarts the module of those checks fail. Beside that a watchdog functionality is implemented regarding the communication interface.

Once a cyclic communication on the AC - CC Interface is established, a timeout detection is activated. This timeout closes any cyclic fieldbus connections and sets an error. Timeout is detected after 1 second of inactivity.

The AC application can use this watchdog functionality by registering a callback function with goal_miMctcCbRegToutRx().

Compiling

Creating a custom project

A application project for SoM consists of several files which require specifc settings. It is possible to get a list of required files and settings from any project. To do so please execute the following commands on a command line (linux):

The resulting output shows all files (*.c), include paths and required symbols to compile the specific project.

If this step is not possible, please contact support.

Porting

How to port the software package to a own CPU / platform. Porting of the software package is possible, all platform specific files are located in the plat/ folder. For a typical application the following files have to be adapted (example STM32F4):

File Description

plat/arch/stm32f4/goal_target.c CPU target specific routines

plat/arch/stm32f4/goal_target_common.c CPU target specific routines

plat/arch/stm32f4/goal_target_nvs.c CPU specific storage access function (unused by applications)

plat/board/st/stm32fxxx_nucleo144/goal_target_board.c initialization of the system and registration of drivers

plat/drv/bus/mdio/stm32f4/mdio.c required for Ethernet, unused by the applications

plat/drv/eth/st/stm32xx/goal_target_eth.c required for Ethernet, unused by the applications

plat/drv/led/iic/stm32f4xx_ccmshield/stm32f4xx_ccmshield.c LED driver

plat/drv/lock/goal_target_lock.c mutex implementation for os less systems

plat/drv/phy/generic/phy_generic.c PHY driver, unused by the applications

plat/drv/phy/smsc_lan8742a/smsc_lan8742a.c PHY driver, unused by the applications

plat/drv/spi/stm32f4xx/spi_stm32f4xx.c SPI driver

plat/drv/uart/stm32fxxx/uart_stm32fxxx.c UART driver

Table: list of files regarding porting

Target Synergy

Unable to compile the Synergy e2studio project

To compile the Synergy e2studio examples, please make sure that you opened the project "configuration.xml" file and generated the BSP code with the "Generate" button.

Target Raspberry PI

How to compile the AC application natively on the raspberry pi?

You need to extract the source code delivery to the raspberry pi. Secondly you need to be able to compile code, thus install the package "build-essential" with apt:

Enter a project folder, that you want to compile:

Select target via 'make select' call:

Chose the proper configuration from the list (e.g. raspberry_pi_raspi_shield or raspberry_pi_irj45)

Compile the code with make

By setting the variable CROSS_COMPILE to empty, the native gcc compiler will be used.

The binary will be located in the build/...configuration name... folder

How to start a own application on the raspberry pi demo

The default demo application provided by port for the raspberry pi contains a service, which automatically starts the AC application on bootup. To start an own application, this service must be disabled before:

How to replace the boot AC application on the raspberry pi

The default demo application provided by port for the raspberry pi contains a service, which automatically starts the AC application on bootup. To replace this application, the service needs to be stopped:

Then replace the binary in /home/pi/goaldemo/goal_raspberry_pi_irj45.bin with your own binary. Keep the filename of the target file.

After restarting the service, the application will be started:

Application

IP configuration issues

If the switch between static IP configuration and DHCP fails after reboot, please check the follow CM variables using the management tool: 

To disable DHCP set the variable DHCP_ENABLED to 0. Make sure variable „VALID" is set to 1. Upload these settings to the module and save those values permanently. After a reboot DHCP should be disabled. 

RPC requests not working

Please make sure that RPC requests are only initiated from the goal main loop. This is the case in appl_loop() or in any registered loop function. Even software timers created by goal_timerCreate() won't trigger RPC requests properly.

If the log shows message as below:

If the last log entry regarding „sync needs local reset to proceed" is shown, the communication controller needs a reset. This can be achieved using the „RST" button on the shield board.

If the low shows messages as below:

Please check the physical connection between application controller and communication module. The SPI interface did not provide a reliable communication.

Timeouts during Debugging

If the application is paused while RPC requests occur, RPC timeouts will happen. Those are signaled with return value 0x800000AB (GOAL_ERR_TIMEOUT).

Hereafter, possibilities to disable the peer-loss detection, on both the SoM and the application controller, are described.

GOAL

Those timeout errors can be supressed using the following modification to goal_appl.c:

uGOAL

Those timeout errors can be supressed adding the following define to goal_config.c:

or using following command in a project directory, like ugoal/projects/ugoal/02_profinet/gcc:

and building the project:

General Debugging procedure

If debugging an application some precautions need to be considered. The correct sequence for debugging a application would be:

1. stop the application (on the application controller)

2. reset the SoM module (e.g. using the reset button on the arduino shield)

3. start debugging of the application (application controller)

4. run the application

Then the application should be able to start the communication module as required. It would be possible to automate this process by performing a reset using the reset input input of the communication module, however remarks regarding the reset handling in the appliation node 1001 (firmware update and reset) should be considered.

PROFINET

PROFINET cyclic communication sporadically fails

Please make sure to use cycle times > 32 ms on Windows / Linux Desktop. Those operating systems do not support any realtime capability. To use cycle times up to 1 ms use a PLC.

PROFINET cyclic communication cannot be established

Please make sure that you use the correct GSDML file, which is documented per example project in the User Manual.

Device Detection

Device Detection doesn't find the CCM module, however it is directly connected to the PC

Please make sure that you applied the firewall settings from the Management Tool User Manual.

How do I create a shapshot of the CCM module

A snapshot contains all relevant information from the device (configuration variables, logs). It can be generated using the Management Tool. Please make sure that you found the CCM module using "Scan Network" and select the device in the "Network Navigator". Now click the button "Get Snapshot" in the Toolbar. After the snapshot is generated, it will be shown in the "Network Navigator" under the topic "Snapshots". Select the newly created snapshot and click the button "Save Snapshot" in the toolbar. the generated XML-file can then be sent to support, e.g. Best practice is to zip this file to prevent issues with email spam filters.

EtherCAT

EoE is not working as expected

Please make sure that the fallback Ethernet activation, which is configured using the following CM variable, does not interfere with starting of the EtherCAT stack:

• GOAL_CM_CCM_MOD_ID:CCM_CM_VAR_ETH_SWITCH_MODE_TIMEOUT (72:13)

EoE will only work if the EtherCAT stack is up and running before the fallback Ethernet activation is executed. Using the provided CM variable the timeout can be configured in seconds.

Logging

How to see logging of Synergy S7G2SK board

The Synergy S7G2SK board provides a UART on header J10. In order to use the UART, make sure J9 is set correctly. Pins 1-3 and 2-4 must be connected. Please refer to the Boards user manual for correct settings. UART is available at J10, where Pin 1 is connected to RX and Pin 4 is conntected to TX of the Synergy CPU.

Arduino Shield

After an update of the software the LEDs on the shield stop working as expected

You are probably using an older revision of the hardware, where an outdated LED-driver is installed. Set the compiler define GOAL_CONFIG_PLAT_DRV_LED_IIC_PCA9552 1 in e.g. appl/projects/…/goal_config.h to support the older functionality.

How are the LEDs controlled by the SoM module

The SoM module does not provide visual indication of the stack. The respective information are available in the cyclic communication channel and can be mapped by the application. The corresponding LED states are coded in the "Generic data provider", where logical LED signals are available to be mapped to physical LEDs by the Application controller. For the reference design of the Arduino shield these LEDs are controlled using the I2C interface of the CPU.

Hardware

How to connect the LEDs for link and activity

Here it depends on the network socket used and the LEDs installed in it. On our ARDUINO Shield Board the cathode of the Ethernet port LEDs is directly connected to the pin header J302 of the SoM. This connects the activity and link signals directly to the integrated PHY's via a 22 Ohm series resistor. The anodes are each connected to 3.3V DC with a 220 Ohm resistor.

Is the shield connection on our circuit board or in our device still to be earthed?

Pin 23 on J301 (Shield) must not be connected to ground potential of the module. The decoupling of the shielding is integrated on the SoM. We recommend a minimum distance of 2 mm between shield and logic and supply voltage potential.

Do the inputs of the module need any pull-up or pull-down resistors so that they do not "float" undefined during the reset (our controller then has all pins high-impedance)?

The SoM has an internal pull-up of the reset line. This reset signal on J202 pin 4 is low active.

Is it still possible to block the power supply of the module (as often usual) close to the module with capacitors?

Supporting capacitors are not necessary for the SoM, but it depends on the conditions of the final product. The limit values (4. Electrical Characteristics) listed in the data sheet must be observed.

What are the two signals CATSYNC0/1 for? If we want to prepare our board for later support of EtherCAT, how do we (or should) wire them?

CATSYNC0/1 are protocol specific signals for EtherCAT. Both signals are also internally provided with a 22 Ohm series resistor for current limitation. These signals belong to EtherCAT DC, for the generation of an EtherCAT network-wide synchronous pulse, e.g. for axis synchronization. These signals are currently intended as output and are only available for EtherCAT. Without EtherCAT they are unused and do not need to be wired.

Tools

Is the ProfiNET Design Tool suitable as test environment for the devices built up with the module, i.e. can it work as ProfiNET master?

The Design Tool is not suitable as a master; however, we have a PROFINET DeviceMonitor, which enables minimalistic PROFINET communication: [[https://www.port.de/en/products/profinet/tools/configuration-command|download]]

Siemens tools are also recommended when working in the field of PROFINET: S7/1200 with TIA Portal, because this setup corresponds to the real case in use.

Is the Design Tool required to build applications for SoM?

The design tool is optional.

The SoM module cannot be detected, communication is not possible

In case an EtherCAT application is developed, please consider the following remarks:

It is required to differentiate between two modes: If the SoM is started without the application on the application controller, the ICC will be able to communicate directly to the SoM. However as soon as the application starts (in case of EtherCAT) one needs to set the network interface in the ICC to EtherCAT mode. You should be able to find the SoM with the ICC in any case. If it is not visible, you are in the wrong interface mode. Handling of the ICC is described within the manual.

The Industrial Communication Explorer fails to start on linux:

It is required to set capabilities for raw ethernet access: