PROFINET stack, Conformance Class B, Real Time Class 1
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
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
Dynamic module configuration (provided by connection request from PLC)
Queue for sequential process alarm sending
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?
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.
Static RAM usage
Dynamic RAM usage
Table: memory footprint
Much smaller Footprints are achievable using uGOAL.
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().
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):
# chose your platform
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.
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):
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
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:
sudo apt-get install build-essential
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:
sudo systemctl stop irj45demo
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:
sudo systemctl stop irj45demo
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:
sudo systemctl start irj45demo
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_setup or in registered loop functions.
If the log shows message as below:
GOAL_LOG_SEV_ERROR 501 [CC_E|goal_miMctcRpcSyncLoop:956] sync needs local reset to proceed
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:
GOAL_LOG_SEV_ERROR 492 [CC_E|goal_miMctcMonitorRx:1250] data channel offline: MCTC SPI
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.
Make sure to enable the timeout detection for productive code, else a loss of communication between AC and CC will not be detected as an error.
Those timeout errors can be supressed using the following modification to goal_appl.c:
user: ~/ugoal/projects/ugoal/02_profinet/gcc: make PLATFORM=stm32f429zi
*** Debugging Mode enabled - note that: ***
> this mode should only be used for debugging purposes
> peer-loss detection on application controller is disabled
> logging might be enabled
*** Disabling per 'make debug' ***
To switch the Debugging Mode off, use ‘make debug’ too.
General Debugging procedure
If debugging an application some precautions need to be considered. The correct sequence for debugging a application would be:
stop the application (on the application controller)
reset the SoM module (e.g. using the reset button on the arduino shield)
start debugging of the application (application controller)
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 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 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.
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:
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.
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.
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.
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.
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?
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: