UM0541
User manual
DCP monitor
Introduction
CPU commander is a user-friendly tool to perform data logging or to control and to monitor
software applications running on MCU targets such as EVA boards, customer modules or
application boards. Using CPU commander and its collection of visual instruments makes it
possible to quickly build control panels for a large number of application fields.
The user can connect CPU commander to a target device using different communication
systems. If the user connects CPU commander to the target device via RS232, CPU
commander uses a specific protocol called DCP that is described in
Section 1.1.1: DCP
protocol.
In this case, a software called DCP monitor must be present on the target side to
establish the communication between CPU commander and the target.
This document provides a complete guideline to porting and to configure the DCP monitor in
a target device project.
Chapter 1: Architecture
gives a brief description of the architecture
and the DCP protocol.
Chapter 2: Using DCP monitor
describes how to use the DCP
monitor and provides details on its configuration and initialization.
Chapter 3: DCP-
Application Programming Interface
describes the API of the DCP monitor.
Requirements
CPU commander (PCs) has been designed to work with Windows 2000 and Windows XP
platforms and with no particular hardware requirements. However, in order to connect your
PC to the target, either a UART port or a USB port and an ST COMBox kit (driver and board)
must be installed in your PC.
September 2013
Rev 2
1/19
www.st.com
Contents
UM0541
Contents
1
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1
1.2
DCP monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1
DCP protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Communication mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ACK management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Resend management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
CRC management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2
Using DCP monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1
Defining behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1
2.1.2
Autonomously . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2
Configuring DCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1
2.2.2
2.2.3
2.2.4
Communication API configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
ACK management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
DCP version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Communication error management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3
2.4
Initializing the monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Writing the callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1
Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3
DCP-Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1
3.2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
API reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
DCP_register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
DCP_RegisterErrorHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
DCP_SendFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
DCP_Callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
DCErrorManagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
DCP_Init() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2/19
UM0541
Contents
3.3
Data structures and constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1
3.3.2
3.3.3
3.3.4
Type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Configuration constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A Software end-user agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3/19
Architecture
UM0541
1
1.1
Architecture
DCP monitor
DCP monitor consists of the following files:
●
●
●
●
DCP.c - contains all functions of the DCP monitor
DCP.h - header file used to configure the DCP monitor
DCPPort_xxx.c - contains all functions specific for the target
DCPPort_xxx.h - header file for DCPPort_xxx.c
All these files have to be included in the target side project to implement the DCP monitor.
1.1.1
DCP protocol
DCP protocol is used by CPU commander during a UART communication.
Figure 1
describes the format of a DCP frame.
Figure 1.
Serial communication frame format
SYS
CRC
RESERVED
ACK
RESERVED
....
RESERVED
FrameID
8 bits
CommandID
32 bits
Length
8 bits
Data
0 - 255 bits
CRC
16 bits
8 bits
FrameID
(Frame Identifier): is used only if acknowledge management is set. It is a counter 8
bits long and identifies the frame.
Command ID
(Command Identifier): is the identifier of the frame and is 32 bits long.
SYS
(System) flag: when it is set, the frame is a system frame.
CRC
(Cyclic Redundancy Check) flag: when it is set the CRC is present in the frame
otherwise not.
ACK
(Acknowledge) flag: when it is set, the receiver must send an acknowledge frame.
Length:
this field is 8 bits long and indicates the length of the data in bytes (from 0 to 255
bytes) present in the current frame.
Data:
it contains from 0 up to 255 bytes of data.
CRC:
if CRC flag is set the last filed contains the CRC value. It is 16 bits long.
4/19
UM0541
Architecture
1.2
1.2.1
Communication mechanism
Introduction
This section describes the transmission mechanism and the reception mechanism between
CPU commander and a target device.
1.2.2
Transmission
To send data, the sender must build a DCP frame and insert information in each field.
The sender has to perform these steps:
1.
2.
3.
4.
5.
6.
Insert the CommandID.
Set the correct flags for the functionality requested (SYS, ACK, CRC).
Insert the Length of the bytes of the data.
Insert the data.
Calculate the CRC if the CRC flag is set and insert the value at the end of the frame.
Call the function SendFrame(frame).
1.2.3
Reception
The reception is interrupt implemented.
Using UART communication, the receiver receives one byte at a time, so the number of the
byte received depends from the properties of each frame.
If the acknowledge management is activated, the first seven bytes (FrameID, CommandID,
Flags, Length) are mandatory. If the acknowledge management is not activated the first six
bytes are always present (CommandID, Flags, Length). After the reception of the Length, it
is possible to know how many bytes of data the receiver has to receive. After the receiver
has received all data, it waits for CRC flag if the CRC flag is set, otherwise the reception is
complete.
When the frame is complete, the receiver can pass the frame to the DCP protocol for the
parsing calling DCP_ProcessFrame() function.
If the frame is a system (SYS) frame, DCP protocol executes the task programmed for the
specific SYS. If the frame is an acknowledge frame (ACK), the protocol checks if the
FrameID of the frame received corresponds to the expected FrameID. If the FrameID does
not match, an error occurs.
If the CommandID of the frame is a user CommandID, the management of this frame is
passed to the CallBack function managed by the user. In fact, the user has to insert the
managed frame into the Callback function with a CommandID which is specific to the
application.
5/19
京公网安备 11010802033920号
Copyright © 2005-2026 EEWORLD.com.cn, Inc. All rights reserved
电子工程世界
