ST STEVAL-IHP007V1 User manual

December 2016 DocID026935 Rev 3 1/47
47
UM1818
User manual
Street lighting power line modem evaluation board based on
ST7580 PLM and STM32 microcontroller
Introduction
This document explains how to use and set up the firmware and the software designed for
the STEVAL-IHP007V1 board and all the necessary setup for using the hardware.
The system is based to the ST7580 data link protocol firmware, data link protocol described
in the application note AN4018. ST7580 data link protocol firmware is organized in a layer
structure. A dedicated layer allows the user to design its own application interfacing to the
evaluation board features with very simple and easy to use APIs.
Dedicated software graphic user interface (GUI) allows the user to use all the embedded
features interfacing the PLM evaluation board with the PC via an RS232 communication
port.
This firmware is developed using STM32F10x standard peripherals library Rel.3.5.0 and
IAR Embedded Workbench
®
IDE for STM32 microcontrollers Rel. 6.50x
The STEVAL-IHP007V1 hardware evaluation board embeds an ARM 32-bit Cortex™-M3
core-based STM32F103xB and an ST7580 PSK multi mode power line networking system-
on-chip.
Figure 1. STEVAL-IHP007V1 evaluation board
www.st.com

Contents UM1818
2/47 DocID026935 Rev 3
Contents
1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Hardware installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Firmware description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Remote firmware update (RFU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Firmware download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4 Firmware architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
4.5 Firmware data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6 Firmware frame types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6.1 Communication frames types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6.2 Ping frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6.3 Error frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6.4 Service frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A HID commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B Schematic diagrams and bill of material. . . . . . . . . . . . . . . . . . . . . 35
B.1 Schematic diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
B.2 Bill of material (BOM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix C CRC 16 calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

DocID026935 Rev 3 3/47
UM1818 Features
47
1 Features
•Configurable PSK power line modem interface with an embedded firmware stack for a
complete power line communication management
•8 user configurable general purpose input/output pins
•USART communication channel for evaluation board interfacing
•Internal configurable RTC evaluation board with lithium backup battery
•Programmable user data and PLM parameters Flash memory area
•Remote firmware update
•Embedded AES 128 encryption evaluation board with programmable AES Key

Description UM1818
4/47 DocID026935 Rev 3
2 Description
The STEVAL-IHP007V1 block diagram is shown in Figure 2. The general purpose power
line modem evaluation board is based on an ST7580 x-PSK power line modem device and
an ARM 32-bit Cortex™-M3 core based STM32F103xB microcontroller. The PLM
evaluation board is a fully functional communication evaluation board, with 8 programmable
I/Os, a real time clock and a Flash memory area for modem parameters and user data
storage. The firmware structure is made up of several layers, each dealing with a different
feature. The application layer engine is the general interface between the user program and
all the parts of the evaluation board. It manages the communication ports, the evaluation
board peripherals such as SCI, RTC, I/Os, LEDs and timing management. It is also the
interface between the PLM communication protocol and the user application layer. The PLM
communication protocol, itself made up of several layers, implements and manages the
power line communication, manages the conflicts, timing and repetitions, the addressing,
and so on. Please refer to AN4018 for details on the ST7580 communication protocol
features and application services provided. Some features are managed directly by the
application engine, and are transparent to the user, such as the RTC management or the
board parameter update, as well as the board programming and configuration, which is
done by particular programming or service commands managed and acknowledged directly
by the application engine. Even the remote firmware update is managed by the application
engine and allows the firmware being update remotely by power line modem.
The STEVAL-IHP007V1 is powered by a dual regulated DC power source, +12VDC (pin 1)
and +3.3 VDC (pin 2) from the power supply connector (J2). The pin 3 is the ground.
The communication is done via power line, which is applied to the board using the J1
connector, where the pin 1 must be connected to the neutral wire while the pin 3 to the
phase wires (refer to the Appendix A).
Figure 2. STEVAL-IHP007V1 block diagram
It is possible to connect the evaluation board in a three phase line (in case of
communication modules are connected in all three phases), in this case an external

DocID026935 Rev 3 5/47
UM1818 Description
47
capacitor of 220 nF X1 must be connected to any additional phase, and then the other side
of capacitors together with the common pin 5 of the J2 connector, following the schematic
shown in the Figure 3, and the 0 Ωresistor R1 must be mounted.
Figure 3. Three phase connection
The GP PLM module is provided of a user interface (J3) shown in Figure 4 where there are
connected the SPI interface pins (MOSI, MISO, SCK and NSS), the RS232 interface pins
(Tx and Rx), the USB interface pins (D+ and D-) and the user programmable general
purpose I/O pins. Remark that those pins are directly connected to the microcontroller, so be
careful to provide the correct insulation and
protection depending on the use those pins are addressed.
It is possible to power the PLM using the +3.3 VDC (pin 19), +12 VDC (pin 20 or 22) and
GND (pins 17, 23, 20 and 24) of this connector instead of the connector J2, using only a
single connector for power supply and control signals.
A lithium backup battery mounted on the board and 32 kHz quartz allows the use of the full
functionality of the internal RTC of the microcontroller, allowing precise time-based
operations.

Description UM1818
6/47 DocID026935 Rev 3
Figure 4. User interface connector
A two color LED allows the signaling the board operations, data transmission and reception.
Finally, a programming connector allows the firmware download and debug, even if it is
possible to use the remote firmware update feature to remotely update the firmware using
the PLM, as described further in this user manual. If the IAR - JLINK/JTRACE is used for the
firmware downloading, a simple JTAG adapter is necessary. The Figure 5 shows the
adapter schematics.
Figure 5. Programming connector JTAG adapter
PLM_GPIO0
PLM_GPIO1
PLM_GPIO2
PLM_GPIO3
PLM_GPIO4
PLM_GPIO5
PLM_GPIO6
PLM_GPIO7
BOOT0
SPI_ MOSI
SPI_ MISO
SPI_S CK
SPI_ NSS
USB_ DM
USB_ DP
USART_TX
USART_RX
VDDIOVCC
12
34
56
78
910
1112
1314
1516
1718
1920
2122
2324
J3
TSW-112-08-L-D- RA
GSPG23072015DI1045

DocID026935 Rev 3 7/47
UM1818 Hardware installation
47
3 Hardware installation
Connect a regulated dual DC power supply to the power source pins of the connector J3 as
described previously and power the board.
In order to download the firmware, plug the programmer adapter (Figure 5) in the
programming connector J1 and the IAR J-Link programmer in the JTAG connector of the
adapter.
Refer to the chapter firmware description (paragraph 6.3 for the firmware download
procedure). As soon as the application is launched, the LEDs should quickly switch on
indicating that the board has to be configured.

Firmware description UM1818
8/47 DocID026935 Rev 3
4 Firmware description
4.1 Introduction
The firmware structure is constituted of several layers each of it taking care of a different
feature. The application layer engine is the general interface between the user program and
all the parts of the module. It takes care of the communication ports, the board peripherals
as RTC and I/Os, and timing management. It is also the interface between the PLM
communication protocol and the user program. The PLM communication protocol, itself
constituted by several layers, implements and manages the power line communication,
manages the conflicts, timing and repetitions, the addressing and so on.
Some features are managed directly by the application engine, and are transparent to the
user, as well as the board programming and configuration, which is done by particular
programming or service commands managed and acknowledged directly by the application
engine, the RTC management, the board parameter or the firmware update.
The user application can be interfaced to the application engine by simples APIs used for
the data transfer and the evaluation board interface. The Figure 6 shows the firmware
structure.
Figure 6. Firmware structure
The file user.c/h and application.c/h are the owner of application management, this manage
the data flow from/to the PLM physical and from/to the UART side.
4.2 Remote firmware update (RFU)
The remote firmware update (RFU) uses the power line modem as external communication
channel for receiving a new firmware dump. The firmware dump is placed in the internal
Flash memory of the microcontroller. Hence, the total memory size of the microcontroller
must be at least the double of the estimated maximum size of the firmware application (in
this application is set to 60 kbytes), plus 4 Kb of additional memory for a bootloader. The
Figure 7 shows the microcontroller memory organization.
The bootloader is loaded at the startup and checks the active segment containing the actual
firmware. The implemented mechanism uses three partitions of the microcontroller’s Flash

DocID026935 Rev 3 9/47
UM1818 Firmware description
47
memory, one containing the bootloader and two containing the actual running firmware
(active image) and the new firmware as soon as a RFU is needed.
As soon as the firmware transfer is completed, a “swap” command sent from the remote
PLM causes the target PLM to check first the integrity of the firmware dump (actually a
checksum is calculated and compared with the one sent by the remote PLM), and after the
reset vector address of the new firmware is written in a dedicated Flash segment of the
bootloader. Last the microcontroller is self reset, and the new firmware executed.
Figure 7. Memory organization
The RFU protocol manages the RFU “start”, “get new firmware segment” (with the segment
address) and “swap” commands. The protocol is not embedded in the bootloader, hence it
can be updated with the new firmware, bust the user must be careful in the modifications as
any bugs can compromise the RFU mechanism.
As soon as a new firmware segment is received, the RFU manager checks if the address is
within the firmware interrupt vector table. If it is the case, an offset depending on the free
firmware image (1 or 2) allocation is added to each interrupt vector before being written in
the free image Flash area.
In the Figure 8 is shown the RFU flowchart.

Firmware description UM1818
10/47 DocID026935 Rev 3
Figure 8. RFU flowchart (1of 2)
Figure 9. RFU flowchart (2 of 2)
4.3 Firmware download
In the setup directory there are different workspaces stored in different directories. In order
to implement the remote firmware update feature it is necessary to download the project
located in the workspace “Firmware - Application and Bootloader”. This workspace contains
two different projects, one is the bootloader and the other one is the application itself. If the
board has never been programmed, this workspace must be downloaded before.
Open the IAR Embedded Workbench
®
IDE for STM32 microcontrollers Rel. 6.50 (or a more
recent release). Click File\Open\Workspace and load the following workspace placed in the
directory selected during the setup file installation: “Firmware - Application and
Bootloader\EWARM\Project.eww”. Verify that the application project is the active project
(the project name must be in bold), otherwise select the active project in the list below the
workspace (Figure 10).

DocID026935 Rev 3 11/47
UM1818 Firmware description
47
Figure 10. Active project selection
Click "Project - Batch Build" or press the key F8 in order to compile at the mean time the
bootloader and the application.
After the compiling is completed, press "Project - Download and Debug" or press the keys
CTRL+D. The both firmware download starts. As soon as the download is completed, press
F5 in order to run the application (or exit from the debug mode pressing the keys
CTRL+SHIFT+D and unplug the programmer).
If the procedure is done correctly, the orange LED should be on, indicating the board has
never been set up before. If it is not the case, try first to erase the memory by clicking
Project\Download\Erase Memory and download again the firmware as described before.
Use the GUI interface in order to setup the board and connect it to the power line as
described in the dedicated paragraph.
As soon as bootloader has been installed in the evaluation board is possible to remotely (via
power line) update the firmware using the RFU feature. Each new firmware version has to
be programmed using the workspace “Firmware - Application
standalone\EWARM\Project.eww”. The bin file produced by this workspace that is located in
the folder “Firmware - Application standalone\ EWARM\PLM_HID_STANDALONE.bin” can
be directly loaded using the GUI interface. The difference of this application with the one
contained in the workspace with the bootloader is mainly in the stm32f10x_flash.icf linker file
and some workspace parameters that are not used in the application without the bootloader
(as multiple build, simultaneous debug mode, etc.).
The setup folder contains also the Firmware - Bootloader folder, where inside there is the
bootloader firmware; and the folder Firmware - Sniffer which contains the sniffer workspace
to download in a PLM module useful if the data sniffing feature of the interface is used. In
this case the PLM module will work only as a sniffer.
4.4 Firmware architecture
The structure of the workspace is divided in different sections as shown in the Figure 11.

Firmware description UM1818
12/47 DocID026935 Rev 3
Figure 11. Workspace structure
At this level, all the communication APIs and all the APIs for the application engine interface
are available. In the main file, the following code is implemented for running the state
machine engines:
while(1){
DL_FSM();//PLM Main Loop
APP_StackUpdate();// USART State machine
USER_Program();// PLM State machine
#ifdef USE_WDG //STM32 Window Watchdog
IWDG_ReloadCounter();
#endif
#ifdef KEEP_ALIVE //PLM Keep Alive systems
Check_KA_Timeout();
#endif
}
After the initialization the infinite loop calls three main functions: the DL_FSM(),
USER_Program() and the APP_StackUpdate() routine.

DocID026935 Rev 3 13/47
UM1818 Firmware description
47
The DL_FSM() is the PLM stack main loop, this manage the PLM low level communication.
The application engine “APP_StackUpdate()” is the state machine which runs inside the
PLM application state machine; this uses the data link service provided from DL_Service
layer.
The user program implemented in this user manual realizes a bridge between the power line
communication and the COM port: all data arriving from the COM port addressed to another
PLM module is sent via PLM, and in turn all data received from PLM is sent back to the
COM port. It is necessary that the user program does not stop the core operations (looping
instructions) without calling the application engine.
All the hardware configurations are contained in the board support package file, and the file
DL_SimpleNodeConf contains the data link configuration parameters and the PLM modem
configuration value (frequency, modulation zero crossing delay, etc.).
The next paragraph lists all the data types and the APIs used in the application engine that
can be modified by the user if different needs arise.
4.5 Firmware data types
The data type found in the wrapper.h module, are listed hereafter:
/* USER FRAME STRUCTURE */
typedef struct
{
APP_ftype_t type;
bool broadcast;
u8 address[6];
u8 len;
u8 data[USER_PAYLOAD_SIZE]; /* MAX PAYLOAD SIZE: 100 bytes */
bool EnableTX
}APP_frame_t;
/* APPLICATION FRAME TYPE */
typedef enum
{
APP_DATA_FRAME = 0x00,
APP_SERVICE_FRAME = 0x01,
APP_PING_FRAME = 0x02,
APP_ERROR_FRAME = 0x03,
APP_PROGRAMMING_FRAME = 0x04,
APP_ACK_FRAME = 0x05,
APP_MIB_FRAME = 0x06
}APP_ftype_t;

Firmware description UM1818
14/47 DocID026935 Rev 3
/* APPLICATION ERRORS */
typedef enum
{
APP_ERROR_NONE = 0x00, // No error
APP_ERROR_GENERIC = 0x01, // Generic communication error
APP_ERROR_COMM_TIMEOUT = 0x02, // Communication timeout error
APP_ERROR_SERVICE_GRP_UNKNOWN = 0x03, // Service group unknown error
APP_ERROR_SERVICE_CMD_ERROR = 0x04, // Service command error
APP_ERROR_COMMUNICATION = 0x05, // Communication error
APP_ERROR_ISOLATED_NODE = 0x06, // Node unreachable error
APP_ERROR_HARDWARE = 0x07, // Hardware error
APP_ERROR_WRONG_PROG_COMMAND = 0x08, // Wrong programming command
error
APP_ERROR_WRONG_PROG_GROUP = 0x09, // Wrong programming group error
APP_ERROR_DEVICE_BLANK = 0x0a, // Device blank
APP_ERROR_RTC_ERROR = 0x0b, // Error setting the system time
APP_ERROR_WATCHDOG_DISABLED = 0x0c, // Hardware reset impossible
APP_ERROR_NODE_INIT_FAILED = 0x0d, // Node initialization failure
APP_ERROR_RTC_DISABLED = 0x0e // Internal RTC disabled
}APP_ERROR_t;
/* PROGRAMMING GROUPS */
typedef enum
{
PROG_GRP_DEVICE_DATA = 0x00, // Device Data
PROG_GRP_LL_STACK_PARAM = 0x01, // Link layer stack parameters
PROG_GRP_USER_DATA = 0x02 // User program
}APP_PROG_GROUP_t;
/* SERVICE COMMANDS */
typedef enum
{
/* NATIVE SERVICE COMMANDS */
SERVICE_SOFTWARE_RESET = 0x00,// Reset internal state machines
SERVICE_HARDWARE_RESET = 0x01,// Module hardware reset
SERVICE_PARAM_SET = 0x02,// Set service parameters
SERVICE_PARAM_GET = 0x03,// Get service parameters
SERVICE_INPUTS_GET = 0x04,// Get general purpose inputs pin status
SERVICE_OUTPUTS_SET = 0x05,// Set general purpose outputs pins
value
SERVICE_FW_REL_GET = 0x06,// Get the stack and the module firmware
release
SERVICE_PLM_CLOCK_SET = 0x07,// Set the internal time clock value

DocID026935 Rev 3 15/47
UM1818 Firmware description
47
SERVICE_PLM_CLOCK_GET = 0x08,// Get the internal time clock value
SERVICE_IO_CONFIG_SET = 0x09,// Set the general purpose input and
output pins
SERVICE_IO_CONFIG_GET = 0x0a,// Get the general purpose input and
output pins
SERVICE_NET_DISCOVER_REQ = 0x0b,
SERVICE_RFU_SET_IMG_HEADER = 0x0c,
SERVICE_RFU_SET_IMG_DATA = 0x0d,
SERVICE_RFU_SWAP_IMG = 0x0e,
SERVICE_SN_SET = 0x0f,
SERVICE_SN_GET = 0x10
/* USER DEFINED SERVICE COMANDS */
// SERVICE_USER_CMD_xx = 0x.., // User defined service commands
(0x0b to 0x7f)
}APP_SER_CMD_t;
4.6 Firmware frame types
This paragraph describes all the frame types that are implemented in this firmware. In each
field there is also the description.
4.6.1 Communication frames types
Frames exchanged between two PLM modules or between a PLM module and an external
device connected to the COMM interface.
From the COMM interface module (USART)
/* BROADCAST_FLAG = 0x80 -> data sent in broadcast - BROADCAST_FLAG = 0x00
-> data sent in unicast */
From / to communication interface (PLM, USART)
buffer[0] = n + 10;
buffer[1] = DATA_FRAME_TYPE | BROADCAST_FLAG;
buffer[2,..7] = target_module.address;
buffer[8,..8+n-1] = user_data[n];
buffer[8+n,8+n+1] = CRC16;
// Data frame payload length (n + 10)
// Data frame type
// Target device address (6 bytes)
// User data (n bytes, at least 1)
// CRC-16
frame.type = DATA_FRAME_TYPE;
frame.len = n;
frame.broadcast = TRUE / FALSE;
frame.address = target_module.address;
frame.data[n] = service_data[n];
// Data frame type
// Data frame payload length
// TRUE = broadcast, FALSE = unicast
// Target device address (6 bytes)
// User data (n bytes)

Firmware description UM1818
16/47 DocID026935 Rev 3
4.6.2 Ping frames
This particular frame is used to ping a remote (via PLM interface) or a local (via COMM
interface) module. When the ping frame is received, this is managed directly at the data link
layer and is not notified at the application and consequently the user levels.
From the COMM interface module (USART).
From / to communication interface (PLM, USART)
4.6.3 Error frames
Can be considered as data frames; they are user error frames from user application level
addressed to a target PLM module.
From / to communication interface (PLM, USART)
Error code list
0x0000 = APP_ERROR_NONE
0x0001 = APP_ERROR_GENERIC
0x0002 = APP_ERROR_COMM_TIMEOUT
0x0003 = APP_ERROR_SERVICE_GRP_UNKNOWN
0x0004 = APP_ERROR_SERVICE_CMD_ERROR
0x0005 = APP_ERROR_COMMUNICATION
0x0006 = APP_ERROR_ISOLATED_NODE
0x0007 = APP_ERROR_HARDWARE
0x0008 = APP_ERROR_WRONG_PROG_COMMAND
0x0009 = APP_ERROR_WRONG_PROG_GROUP
0x000a = APP_ERROR_DEVICE_BLANK
0x000b = APP_ERROR_RTC_ERROR
0x000c = APP_ERROR_WATCHDOG_DISABLED
0x000d = APP_ERROR_NODE_INIT_FAILED
0x000e = APP_ERROR_RTC_DISABLED
buffer[0] = 10;
buffer[1] = APP_PING_FRAME;
buffer[2,..7] = target_module.address;
buffer[8,9] = CRC16;
// Ping frame payload length
// Ping frame type
// Target device address (6 bytes)
// CRC-16
buffer[0] = 12;
buffer[1] = APP_ACK_FRAME;
buffer[2,..7] = target_module.address;
buffer[8]= APP_PING_FRAME;
buffer[9]= command_echo;
buffer[10,11] = CRC16;
// Frame payload length
// ACK frame type
// Target device address (6 bytes)
// Ping frame type
// Echo
// CRC-16
buffer[0] = 12;
buffer[1] APP_ERROR_FRAME;
buffer[2,..7] = target_module.address;
buffer[8,9]= user_error_code;
buffer[10,11] = CRC16;
// Error frame payload length
// Target device address (6 bytes)
// Ping frame type
// Echo
// CRC-16

DocID026935 Rev 3 17/47
UM1818 Firmware description
47
user_error_code = (APP_ERROR_t)(buffer[8]<<8)| buffer[9]);
4.6.4 Service frames
Frames containing service commands concerning both some native module features
(internal clock, general purpose inputs and outputs, etc.) and user defined service frames.
Native frames are managed directly by the application engine.
From the COMM interface module (USART)
/* BROADCAST_FLAG = 0x80 -> data sent in broadcast - BROADCAST_FLAG = 0x00
-> data sent in unicast */
From / to communication interface (PLM, USART)
buffer[0] = n + 11;
buffer[1] = APP_SERVICE_FRAME | BROADCAST_FLAG;
buffer[2,..7] = target_module.address;
buffer[8] = (APP_SER_CMD_t)command;
buffer[9,..9+n-1] = service_data[n];
buffer[9+n, 9+n+1] = CRC16;
// Service frame payload length (n + 11)
// Service frame type
// Target device address (6 bytes)
// Service command
// Service data
// CRC-16
buffer[0] = n + 11;
buffer[1] = DATA_FRAME_TYPE;
buffer[2,..7] = target_module.address;
buffer[8] = (APP_SER_CMD_t)command/APP_ACK_FRAME;
buffer[9,..n] = service_data[n]/Command_Echo;
buffer[n+1,n+2] = CRC16;
// length
// Service or ACK frame type
// Target device address (6 bytes)
// Service command/ACK
// Service data or Command echo(n=1)

Firmware description UM1818
18/47 DocID026935 Rev 3
Service command list
PLM reset: software, hardware
From the COMM interface (USART)
Note: Any response from PLM module
/* NATIVE SERVICE COMMANDS */
SERVICE_SOFTWARE_RESET = 0x00,
SERVICE_HARDWARE_RESET = 0x01,
SERVICE_PARAM_SET = 0x02,
SERVICE_PARAM_GET = 0x03,
SERVICE_INPUTS_GET = 0x04,
SERVICE_OUTPUTS_SET = 0x05,
SERVICE_FW_REL_GET = 0x06,
SERVICE_PLM_CLOCK_SET = 0x07,
SERVICE_PLM_CLOCK_GET = 0x08,
SERVICE_IO_CONFIG_SET = 0x09,
SERVICE_IO_CONFIG_GET = 0x0a,
SERVICE_NET_DISCOVER_REQ = 0x0b,
SERVICE_RFU_SET_IMG_HEADER = 0x0c,
SERVICE_RFU_SET_IMG_DATA = 0x0d,
SERVICE_RFU_SWAP_IMG = 0x0e,
SERVICE_SN_SET = 0x0f,
SERVICE_SN_GET = 0x10
/* USER DEFINED SERVICE COMANDS */
0x.. = SERVICE_USER_CMD_xx
// Reset internal state machines
// Module hardware reset
// Set service parameters
// Get service parameters
// Get general purpose inputs pin status
// Set general purpose outputs pins value
// Get the stack and the module firmware release
// Set the internal time clock value
// Get the internal time clock value
// Set the general purpose input and output pins
// Get the general purpose input and output pins
buffer[0] = 11;
buffer[1] = APP_SERVICE_FRAME;
buffer[2,..7] = target_module.address;
/* FOR SOFTWARE RESET */
buffer[8] = SERVICE_SOFTWARE_RESET;
/* FOR HARDWARE RESET */
buffer[8] = SERVICE_HARDWARE_RESET;
buffer[9,10] = CRC16;
// Service frame payload length
// Service frame type
// Target device address (6 bytes)
// CRC-16

DocID026935 Rev 3 19/47
UM1818 Firmware description
47
Set module parameters: programming user parameters
From the COMM interface (USART)
From / to communication interface (PLM, USART)
Get module parameters: programming user parameters
From the COMM interface (USART)
From / to communication interface (PLM, USART)
buffer[0] = 44
buffer[1] = APP_SERVICE_FRAME | BROADCAST_FLAG;
buffer[2,..7] = target_module.address;
buffer[8] = SERVICE_PARAM_SET;
buffer[9] = PROG_GRP_USER_DATA;
buffer[10 -> 41] = *user_data_buffer;
buffer[42,43] = CRC16;
// Service frame payload length
// Service frame type
// Target device address (6 bytes)
// Service command
// Type command
// Program data
// CRC-16
buffer[0] = 12;
buffer[1] = APP_ACK_FRAME;
buffer[2,..7] = target_module.address;
buffer[8]= APP_SERVICE_FRAME;
buffer[9]= command_echo;
buffer[10,11] = CRC16;
// Service frame payload length
// ACK frame type
// Target device address (6 bytes)
// Service frame type
// Echo
// CRC-16
buffer[0] = 12;
buffer[1] = APP_SERVICE_FRAME;
buffer[2,..7] = target_module.address;
buffer[8] = SERVICE_PARAM_GET;
buffer[9] = PROG_GRP_USER_DATA;
buffer[10,11] = CRC16;
// Service frame payload length
// Service frame type
// Target device address (6 bytes)
// Service command
// Type command
// CRC-16
buffer[0] = 44;
buffer[1] = APP_SERVICE_FRAME;
buffer[2,..7] = target_module.address;
buffer[8] = SERVICE_PARAM_GET;
buffer[9] = PROG_GRP_USER_DATA;
buffer[10 -> 41] = *user_data_buffer;
buffer[42,43] = CRC16;
// Service frame payload length
// Service frame type
// Target device address (6 bytes)
// Service command
// Type command
// Program Data
// CRC-16

Firmware description UM1818
20/47 DocID026935 Rev 3
Get module general purpose inputs/outputs configuration
From the COMM interface (USART)
From / to communication interface (PLM, USART)
Set module general purpose inputs/outputs configuration
From the COMM interface (USART)
From / to communication interface (PLM, USART)
Get module general purpose inputs value
From the COMM interface (USART)
buffer[0] = 11;
buffer[1] = APP_SERVICE_FRAME;
buffer[2,..7] = target_module.address;
buffer[8] = SERVICE_IO_CONFIG_GET;
buffer[9,10] = CRC16;
// Service frame payload length
// Service frame type
// Target device address (6 bytes)
// Service Command
// CRC-16
buffer[0] = 12;
buffer[1] = APP_SERVICE_FRAME;
buffer[2,..7] = target_module.address;
buffer[8] =SERVICE_IO_CONFIG_GET;
buffer[9] = *sender.configuration_value;
buffer[10,11] = CRC16;
// Service frame payload length
// Service frame type
// Target device address (6 bytes)
// Service command
// input/output configuration
// CRC-16
buffer[0] = 12;
buffer[1] = APP_SERVICE_FRAME;
buffer[2,..7] = target_module.address;
buffer[8] = SERVICE_IO_CONFIG_SET;
buffer[9] = target.configuration_value;
buffer[10,11] = CRC16;
// Service frame payload length
// Service frame type
// Target device address (6 bytes)
// Service command
// bit x = 1 -> IOx = output, bit x = 0
-> IOx = input
// CRC-16
buffer[0] = 12;
buffer[1] = APP_ACK_FRAME;
buffer[2,..7] = target_module.address
buffer[8]= APP_SERVICE_FRAME;
buffer[9]= command_echo;
buffer[10,11] = CRC16;
// Service frame payload length
// ACK frame type
// Target device address (6 bytes)
// Service frame type
// Echo
// CRC-16
buffer[0] = 11;
buffer[1] = APP_SERVICE_FRAME;
buffer[2,..7] = target_module.address;
buffer[8] = SERVICE_INPUTS_GET;
buffer[9,10] = CRC16;
// Service frame payload length
// Service frame type
// Target device address (6 bytes)
// Service command
// CRC-16