AN62792 Updating Field Firmware With PLC.pdf

AN62792
Updating Field Firmware with PLC
Author: Jeffrey Hushley
Associated Project: Yes
Associated Part Family: CY8CPLC20
Software Version: PSoC® Designer™ 5.1
AN62792 describes how to update the user application code of devices in the field with a Cypress Powerline
Communication (PLC) device without any external microcontroller or EEPROM. A transmitter project that sends out its
user application code over the powerline and a receiver project that receives the data from the powerline and reconfigures itself to the new application are attached to this application note.
Contents
Introduction
Introduction .......................................................................1
Powerline Communication.................................................2
CPU and Flash Operation .................................................3
Field Update Operation Overview .....................................3
Allocating Code in Flash and RAM ....................................4
Sending the User Code with PLC .................................6
Transmitting PLC Packets ............................................6
Processing Received PLC Messages ..........................7
Writing To and Reading From Flash..................................7
Special Considerations .................................................8
Performing the Field Update .............................................8
Example Project ................................................................ 9
Receiver Project ................................................................ 9
PSoC Designer Project............................................... 12
Implementation on Hardware ..................................... 13
Transmitter Project .......................................................... 13
PSoC Designer Project............................................... 16
Implementation on Hardware ..................................... 16
Worldwide Sales and Design Support ............................. 19
After a system is deployed to the field, it may require
updates in the future to either add features or fix issues in
the application. If the systems are connected on a
communication bus, updates can be performed over the
communication bus. This way, the update can be sent
from one central location, saving time and money. With
the Cypress PLC solution, this concept of a field update
can be performed without adding any additional
components. The reception of data from the powerline and
the update of the application code are performed in one
device.
www.cypress.com
This application note provides an overview of powerline
communication, describes the operation of the device’s
CPU and how the code is read and updated. It describes
how to write the application code so that it can be updated
over PLC. It also walks through the attached example
firmware projects that show how to transmit and receive a
field update.
Note The example projects are designed to update only
the application code. It is not designed to support field
updates of the user modules (additional user modules or
version updates of user modules). In other words, the first
deployment can have any set of user modules, but these
cannot be modified by the PLC field upgrade. Only the
application code that uses these user modules can be
updated.
Document No. 001-62792 Rev. *C
1
Updating Field Firmware with PLC
Figure 1. Field Update System Diagram
Field Update
Transmitter Node
Node in the Field
Node in the Field
PLC Device
(CY8CPLC20)
+ Coupling Circuit
(e.g. CY3274)
PLC Device
(CY8CPLC20)
+ Coupling Circuit
(e.g. CY3274)
PLC Device
(CY8CPLC20)
+ Coupling Circuit
(e.g. CY3274)
Field Update
Powerline
Powerline Communication
Powerlines are widely available communication medium
all over the world for PLC technology. The pervasiveness
of Powerline also makes it difficult to predict the
characteristics and operation of PLC products. Because of
the variable quality of Powerlines around the world,
implementing robust communication over Powerline has
been an engineering challenge for years. The Cypress
PLC solution enables secure and reliable communication
over Powerline. Cypress PLC features that enable robust
communication over Powerline include:

Integrated Powerline PHY modem with optimized
filters and amplifiers to work with lossy high voltage
and low voltage Powerlines.

Powerline optimized Network Protocol that supports
bidirectional communication with acknowledgement
based signaling. In case of data packet loss due to
noise on the Powerline, the transmitter has the
capability to retransmit the data.

The Powerline Network Protocol also supports
8-bit CRC for error detection and data packet
retransmission.

A Carrier Sense Multiple Access (CSMA) scheme is
built into the Network Protocol; it minimizes collision
between packet transmissions on the Powerline,
supports multiple masters, and enables reliable
communication on a bigger network.
A block diagram of the PLC solution with the CY8CPLC20
programmable PLC chip is shown in Figure 2.
www.cypress.com
Figure 2. Cypress PLC Solution Block Diagram
To interface a PLC device to the Powerline, a coupling
circuit is required. The CY3274 High Voltage
Programmable PLC Development Kit (DVK)contains the
required coupling circuitry for high voltage powerline
applications.
The high voltage kits CY3274 are designed with the
filtering and power supply circuitry to operate on 110 V to
240 V AC powerlines. They are compliant to the following
CENELEC and FCC standards.

Powerline Signaling (EN50065-1:2001, FCC Part 15)

Powerline Immunity (EN50065-2-1:2003, EN61000-32/3)
Document No. 001-62792 Rev. *C
2
Updating Field Firmware with PLC

Field Update Operation Overview
Safety (EN60950)
The CY3274 kits are used to develop an embedded
powerline networking application on the CY8CPLC20
programmable PLC device. They contain user interface
2
options such as I C, RS232, GPIO, analog voltage, LCD
display, and LED to develop a full application.
More information on
www.cypress.com/go/plc.
PLC
can
be
found
at
CPU and Flash Operation
The PLC devices contain an M8C CPU, which executes
the code stored in the flash memory of the device. The
®
flash within the specified PSoC devices is organized in
64-byte blocks. The PLC devices have 512 blocks
numbered 0 through 511. User code, when running, can
modify the data in these blocks.
Writing to flash requires that an entire 64-byte block be
written, even if only 1 byte is to be modified. On the other
hand, reading from flash can be performed on a
byte-by-byte basis.
The flow chart in Figure 3 represents the basic operation
of the device that receives the field update. After
initializing, the device runs its normal application until it
receives a field update message over the powerline. When
it receives a message, it updates the flash that contains
the user code with the received data. At this point, the
code is only partially updated, so it is important that user
code not be executed until the rest of the field update is
received. The device continues to receive the remaining
field update messages until the entire application code
space is updated. Now, the new user code can be run.
At this point, there are many details that need to be
addressed:

How do I make sure that application code is stored in
the same area in flash when I make an update?

How is the user code sent and received over the
powerline?

How is the user code written to the flash?
Each block is assigned a unique protection level whenever
the PSoC programmer or a commercial production
programmer programs the device. These levels of
protection are shown in Table 1.
TM
By default, the PSoC Designer hex file sets each block
to level 3, Full Protection. Running firmware cannot
change the protection levels. The protection level of each
block can be configured in the PSoC Designer Workspace
Explorer by editing the flashsecurity.txt file.
Table 1. Flash Protection Levels
Level
0 Unprotected
Protection Description
All reads enabled
All writes enabled
1 Factory Upgrade
External reads disabled
All writes enabled
2 Field Upgrade
External reads disabled
External writes disabled
Internal writes enabled
3 Full Protection
External reads disabled
All writes disabled
It is best to give the flash blocks a very high protection
level.
In this application, the code that needs to be modified
should have a level of 2, since the flash is written
internally.
For more details, see the application note AN2015 ®
PSoC 1 - Reading and Writing Flash.
www.cypress.com
Document No. 001-62792 Rev. *C
3
Updating Field Firmware with PLC

Figure 3. Basic Field Update Operation
Initialize PLC to
Receive Messages
Run User
Application
PLC Field
Update Message
Received?
N
Y
N
Y
Allocating Code in Flash and RAM
Since the user code is being updated from another device,
it is necessary to make sure that it always starts from the
same location in flash and that it does not overwrite any
non-user code. In order to do this, the following steps
need to be performed.
1.
User_Code.c

ISR_Handler.c

PLC_Common.c

PLC_Flash_Update_RX.c

myData.asm

User_Code.h

ISR_Handler.h

PLC_Common.h

PLC_Flash_Update_RX.h

PLC_Flash_Update_Common.h

custom.lkp
2.
Write your application code: Inside User_Code.c, all
the user code should been written. Inside
ISR_Handler.c, all of the code for processing any
interrupt service routines (ISRs) should be written.
The other .c files should not be modified (including
main.c). After this, the code should be built to see
where the user code can be allocated.
3.
Determine where to place the code: The user
application code must be allocated after all the user
module code so that any future changes in user
application code do not change the location of the
user module code. The location of the code can be
determined by opening the map file (extension .mp).
In the menu, click Debug  Output Files  Map File.
Search for the user code and ISR handler functions
and see the address where the code starts and ends.
This is the size of the modifiable code, which needs to
be assigned to a fixed starting location in memory. In
the example below, the ISR handler occupies 0x21
bytes (0x18C3 – 0x18E3) and the user code occupies
0xB2 bytes (0x18E4 – 0x1995).
Y
N
PLC Field
Update Message
Received?

To add the .c, .h, and .asm files to the PSoC Designer
project, in Workspace Explorer, right-click the project
folder and click “Add File…”. The main.c file is already
in the project so it does not need to be added again.
The file custom.lkp does not need to be added either.
Update the flash
with the data from
the PLC message
Update Complete?
main.c (overwrite existing file)
Create a field updateable project: Create a new
project, place and configure all of the user modules
and generate the project. Then, using Windows
Explorer, copy the following files from the attached
PLC_Field_Update_RX_Base project into the new
project:
www.cypress.com
Document No. 001-62792 Rev. *C
4
Updating Field Firmware with PLC
Figure 4. Flash Location of ISR Handler and User
Code
5.
ISR Handler Code
(Modifiable)
User Code (Modifiable)
The name my_code_area is given as an example
and can be any name. It is critical that the first
function in the user code is User_Main(). This is
because the main.c code calls User_Main() and since
the main.c code is fixed, the address of User_Main()
must always be the same. All other user functions can
be re-allocated for a field update because they call
each other and all of the user code is updated by a
field update. At the end of the user code, uncomment
the line:
#pragma text:text // switch back to the text
AREA
User Module Code (Fixed)
This returns to the general area of flash where
non-user code can be stored in flash.
End of Code
Similarly, each ISR handler function (in this example
GPIO_Int) must be at the beginning of its own AREA
(for example, my_isr_area) because they are
called by code that is fixed (e.g. boot.asm). Therefore,
in ISR_Handler.c, above where the ISR is defined,
uncomment the line:
Next, identify the size of any constant arrays or
structures (for example, constant strings) that are
declared in the user code. In the example project, the
user code has two constant strings that are 16 bytes
each.
#pragma text:my_isr_area
Figure 5. Flash Location of User Code Constants
And at the end of the functions needed for that ISR,
uncomment the line:
#pragma text:text // switch back to the text
AREA
6. Tell the compiler where to allocate the code: In the
project folder that also contains main.c, there should
be a file called custom.lkp, which was copied over in
Step 1. In the file, add a line that will define the
location of your user code. The line is as follows:
-bmy_code_area:<address start>.<address end>
In this example, we allocate some extra space for the
ISR handler section for future expansion. The user
code section occupies the rest of the available flash
memory.
Then, in the map file, identify the end of the user
module code (end of the text AREA), which is
equivalent to the value of xidata_end (see
Figure 4). In the example project, the end is 0x561E.
The starting address of the modifiable code should
start after this. The modifiable code is shifted after
this, and therefore we should subtract the size of the
modifiable code to determine the starting address.
Therefore, the starting address = (End of Code
address) – (ISR Handler code size) – (User code
size) – (User code constants). In this example, the
starting address = 0x561E – 0x21 – 0xB2 –
0x20 = 0x552B. Since flash blocks are 64 (0x40)
bytes each, the modifiable code should start at
0x5600.
4.
Note The PLC Field Update code occupies the end of
the flash (0x7C80 – 0x7FFF)
-bmy_ISR_area:0x5600.0x567F
-bmy_code_area:0x5680.0x7C7F
7.
#pragma abs_address: 0x5740
const char abText[8]="Example";
#pragma end_abs_address
Define areas for the user code in C: In the
User_Code.c file, above where the functions are
defined, uncomment the line:
#pragma text:my_code_area
www.cypress.com
The constant arrays need to be allocated in flash
memory. These can be allocated after the user code.
In this example, the user code uses 0xB2 bytes and
starts at 0x5680. Therefore, the constants can be
placed after 0x5680 + 0xB2 = 0x5732. For this
example, we use 0x5740. After determining the
available memory location from the map file, assign
the location using the pragma abs_address directive.
For example, to allocate a constant string starting at
address 0x5740 write the following:
8.
Setting the security level in flash. In the project folder
that also contains main.c, there is a file called
Document No. 001-62792 Rev. *C
5
Updating Field Firmware with PLC
flashsecurity.txt (example shown in Figure 6). Since
the section of user code needs to be writeable during
code execution, it needs to be changed to the field
upgrade protection level (“R”).
Figure 6. Example of flashsecurity.txt
extern BYTE _bMyVariable;
c)
Allocate the RAM area in custom.lkp. The prefix
for declaring the page location should be –
B (capital B) followed by the area name, followed
by a colon and the page number. For example:
-Bmy_User_RAM:2
10. Setting the starting flash block to be updated over
PLC. The starting flash block is determined by
dividing the starting address by 64 (0x40). In this
example, the starting address is 0x5600. Therefore,
the starting flash block is 0x5600 / 0x40 = 0x158. In
PLC_Flash_Update_Common.h,
set
the
CODE_START_BLOCK constant to this value.
11. At this point, the code can be built and programmed
onto the device.
Sending the User Code with PLC
The PLC family of devices uses a memory array structure
that sets the configuration of the PLC interface, contains
the transmit data and receive data, and reports the status
of operation.
The next sections describe how to transmit and receive a
PLC packet using the memory array.
Transmitting PLC Packets
To transmit a PLC packet, the following registers in the
memory array need to be accessed. Only the bits that are
important for this application are shown in Table 2.
. For details on these registers, see the PLT user module
datasheet in PSoC Designer.
9.
Finally, the data variables should be allocated to their
own page so that future variables can be added
without moving the non-user variables. To allocate
variables in RAM, the following three steps need to be
performed:
The TX Command ID is typically used to represent the
type of data being transmitted. The command IDs 0x01 –
0x2f are reserved for internal commands. The command
IDs 0x30 – 0xff are available for custom commands (for
example, the field update command).
a)
Since the maximum payload size is 31 bytes and each
flash block is 64 bytes, the flash blocks need to be
separated into multiple packets (for example. four packets
of 16 bytes each). When the receiver receives the
packets, it can combine them back into the one 64-byte
array for writing to the flash.
Declare the variables in an assembly file (the file
myData.asm is included in the attached receiver
example project). An AREA needs to be created
for all of the RAM variables. The variable needs
to be exported and the name should start with an
underscore so that it can be used in the C file.
For example:
AREA my_User_RAM (RAM, REL, CON)
export _bMyVariable
_ bMyVariable:BLK 1
b)
Declare the variable in C by using the external
declaration. For example:
www.cypress.com
After setting the configuration properties (PLC_Mode and
TX_Config registers), destination address, command ID,
data length, and data payload in the memory array, the
PLT_SendMsg() API followed by the PLT_Poll() API
should be called to send the message.
Document No. 001-62792 Rev. *C
6
Updating Field Firmware with PLC
Table 2. PLC Memory Array Transmitter Registers
Offset
Register Name
Access
7
6
5
0x01
Local_LA_LSB
RW
8-bit Logical Address
0x05
PLC_Mode
RW
TX_Enable
0x06
TX_Message_Length
RW
0x07
TX_Config
RW
TX_SA_Type
0x08
TX_DA
RW
Remote Node Destination Address (8 bytes)
0x10
TX_CommandID
RW
TX Command ID
0x11
TX_Data
RW
TX Data (31 bytes)
0x69
INT_Status
R
Status_Value_
Change
4
3
2
1
0
RX_Enable
Payload_Length_MASK
TX_Service
TX_Retry
_Type
TX_DA_Type
Status_
UnableTo
TX
Status_TX_
NO_ACK
Status_TX_
Data_Sent
Processing Received PLC Messages
When a PLC message is received, the PLC memory array registers are updated. The registers that need to get set and the
registers that get updated are shown in Table 3. For details on these registers, see the PLT user module datasheet in PSoC
Designer.
Table 3. PLC Memory Array Receiver Registers
Offset
Register Name
Access
7
6
5
0x01
Local_LA_LSB
RW
8-bit Logical Address
0x05
PLC_Mode
RW
TX_Enable
RX_Enable
0x40
RX_Message_INF
O
RW
New_RX_Msg
RX_DA_Type
0x41
RX_SA
R
Remote Node Source Address(8 Bytes)
0x49
RX_CommandID
R
RX Command ID
0x4a
RX_Data
R
RX Data (31 bytes)
RW
Status_Value
_
Change
0x69
INT_Status
4
3
2
1
0
RX_Overri
de
RX_SA_Ty
pe
RX_Msg_Length
Status_
RX_Pac
k
et_Drop
p
ed
Status_RX_
Data_Availa
b
le
Writing To and Reading From Flash
After an entire 64-byte flash block of data is received, it
can be written to the flash. There are two flash API
functions related to reading and writing data to and from
flash blocks while a user’s program is running. These are
bFlashWriteBlock() and FlashReadBlock() and
are located in the PSoC project object library. The header
files, flashblock.h and flashblock.inc, are found in the
External Headers sub-directory in the Workspace Explorer
of the PSoC Designer project.
Code 1 shows the function declarations for these two flash
block APIs.
Code 2 shows the definition of the data structure that is
passed into the bFlashWriteBlock()
API function.
www.cypress.com
Code 3 shows the definition of the data structure that is
passed into the FlashReadBlock() function. The user
must allocate these data structures in SRAM memory to
be initialized and then passed into the API functions. The
wARG_ReadCount in Code 3 is used to specify any valid
16-bit number. This is because flash reads are not
restricted to reading one flash block at a time. In fact, the
flash read is done on a byte-by-byte basis.
The wArg_BlockID is the flash block to write to. Now that
the starting address of the user code has been defined in
custom.lkp, the starting flash block can be determined by
dividing the <address start> by 64 (0x40).
Document No. 001-62792 Rev. *C
7
Updating Field Firmware with PLC
Code 1. Flash Block API Function Declarations
BYTE
void
bFlashWriteBlock(FLASH_WRITE_STRUCT * );
FlashReadBlock(FLASH_READ_STRUCT * );
Code 2. Flash Block Write API Data Structure
typedef struct
{
WORD
wARG_BlockId;
// 2 bytes: block ID [0…511] to operate upon
BYTE *
pARG_FlashBuffer; // 2 bytes: pointer from SRAM for data
CHAR
cARG_Temperature
// 1 byte: temp. in Celsius (2s complement)
BYTE
bDATA_PWErase;
// Local variable storage (reserved)
BYTE
bDATA_PWProgram;
// Local variable storage (reserved)
BYTE
bDATA_PWMultiplier;
// Local variable storage (reserved)
} FLASH_WRITE_STRUCT;
Code 3. Flash Block Read API Data Structure
typedef struct
{
WORD
wARG_BlockId;
BYTE *
pARG_FlashBuffer;
WORD
wARG_ReadCount
} FLASH_READ_STRUCT;
// 2 bytes: block ID [0…511] to operate upon
// 2 bytes: pointer to SRAM for data
// 2 bytes: number of bytes to read
Special Considerations
Calling
bFlashWriteBlock()
globally
disables
interrupts while erasing and writing the specified block.
Calling FlashReadBlock() does not disable interrupts.
Each PSoC device is encoded with an optimized writepulse duration value. The nominal duration is 10 ms, but
this value also depends on individual PSoC die
characteristics and the temperature. Higher temperatures
use a smaller duration and lower temperatures use a
larger than nominal duration. For more details, refer to the
specific
PSoC
device
datasheets
at
http://www.cypress.com.
The supply voltage (VDD) must be within the valid
operating
region
during
a
bFlashWriteBlock()operation. It is best to properly
use the power-on reset (POR) circuit so that a write
operation does not occur if VDD decreases below minimum
operating voltage. The code located in boot.asm (an
automatically generated file) properly sets the correct POR
level based on the CPU’s operating frequency. It is best
not to change the POR level in user code. If the voltage
supply is not properly maintained during a write operation,
a reset may occur, and the data within the block may not
be written correctly and there is no indication of the write
failure.
www.cypress.com
Performing the Field Update
To update the firmware, the first step is to clone the
original project to create a copy. To do this, go to File 
New Project. After naming the new project and clicking
OK, the next window should show Clone Project at the
top. Click Browse… and find the .soc file in the original
project’s main directory, then click Open. Select Use the
same target device option and click OK.
After creating the new project, perform the following steps
to convert it to be able to transmit the field update:
1.
Replace the main.c file from the attached transmitter
example project
2.
In main.c, set the logical address of this node by
modifying the parameter to the Init_PLC() function
3.
In main.c, set the destination address of the node that
receives the update
4.
Replace PLC_Flash_Update_RX.c (and .h) with
PLC_Flash_Update_TX.c (and .h). In the Workspace
Explorer, right-click the file to be removed and click
“Exclude from project”. To add a file, right-click the
PLC_Field_Update_TX folder and click “Add File…”
5.
Create a new application by modifying User_Code.c
(and .h), ISR_Handler.c, and myData.asm, if
necessary. Note that it is not possible to add user
modules at this point because that section of code is
not part of the field update.
Document No. 001-62792 Rev. *C
8
Updating Field Firmware with PLC
6.
If any constant arrays were defined, make sure that
they are allocated just after the end of the user code
(using the #pragma abs_address: directive described
in step 7 in section ’Allocating Code in Flash and
RAM’). If the user code size increases from the
original code, but the constant arrays are located in
the same spot, the linker may display an error “Trying
to write to absolute address 0x5740 but it already
contains a value”. If this occurs, then either increase
the number after #pragma abs_address until the build
succeeds or comment out the lines:
Receiver Project
The receiver project runs on the CY8CPLC20 PLC
device. A block diagram of the receiver system is shown
in Figure 7.
Figure 7. CY8CPLC20 Transmitter Block Diagram
RX
LED
TX
LED
BIU
LED
P2[3]
P2[5]
P2[1]
#pragma abs_address:
#pragma end_abs_address
7.
Then, find the end of my_code_area in the map file.
Then, uncomment the above lines and set the value
to the next available location after the end of
my_code_area.
CY8CPLC20
Push Button
8.
9.
In the memory map file, determine the amount of flash
used by the my_ISR_area, my_code_area, and any
constant arrays (usually listed in the memory area).
This should be the difference between the start of the
my_ISR_area to then end of the constant arrays.
Divide this value by 64 (0x40) and round up to get the
number of flash blocks that require an update. Then,
assign this value to USER_CODE_SIZE_BLOCKS in
User_Code.h. If unsure of the exact value, it is okay
to add 1 to this constant and update an extra block of
code, even if it is not used.
Build the project and program the device. Upon power
up, the new flash code is read from this new project
and transmitted via PLC to the node requiring the
update. Upon completion of the transmission, the
receiving node runs the new application.
PLC
RX
www.cypress.com
LCD
PLC
TX
The CY8CPLC20 device has the following inputs and
outputs.

Push Button: When the GPIO input (P1[6])
transitions from low to high, it generates an interrupt.
When the interrupt occurs, the variable bButtonCount
is incremented and displayed on the LCD.

PLC: The field update is received from PLC. After the
update is complete, the confirmation is sent via PLC.
The PLC message types are as follows:

Field Update Start (ID 0x50): Sent by the
transmitter. This message informs the receiver
that the field update is beginning. It contains the
number of flash blocks that are transmitted. The
LCD displays ’Updating’.

Field Update Data (ID 0x51): Sent by the
transmitter. This message contains the relative
number of the flash block being updated (starting
at 0x00), the relative packet number (0x00 –
0x03), followed by 16 bytes of the flash data.

Field Updated Confirmation (ID 0x52): Sent by
the receiver. This message contains no data and
is sent to inform that the field update is
successful.
Example Project
The example project is composed of a receiver project,
which starts out as a simple push-button incrementing a
value on an LCD, and a transmitter project, which
transmits a PLC message when a push-button is pressed
and displays the number of packets transmitted and
received on the LCD. The transmitter project also
transmits its flash contents of the user code to the receiver
via PLC. Both projects display the status of the update on
the LCD. Upon completion of the flash contents transfer,
the receiver behaves the same as the transmitter.
P4[7:0]
P1[6]
Document No. 001-62792 Rev. *C
9
Updating Field Firmware with PLC
set to ‘0’ so that the message in the memory array is not
overwritten until it is processed.
The PLC memory array settings for these packets are
shown in Table 6 through Table 8. The RX_Override bit is
Table 4. Receiver Memory Array Settings for Field Update Start
Offset
Register Name
Access
7
6
5
4
3
2
1
0
2
1
0
2
1
0
0x02
0x01
Local_LA_LSB
RW
0x05
PLC_Mode
RW
0x40
RX_Message_INFO
RW
0x41
RX_SA
R
Remote Node Source Address(8 Bytes) = 0x01
0x49
RX_CommandID
R
0x50
0x4a
RX_Data[0]
R
Number of flash blocks that will be updated –coordinate
TX_Enable
= ‘1’
New_RX_Msg
= ‘1’
RX_Enable = ‘1’
RX_Override = ‘0’
RX_SA_Type
= ‘0’ (Logical)
RX_DA_Type =’0’
RX_Msg_Length = ‘00001’
Table 5. Receiver Memory Array Settings for Field Update Data
Offset
Register Name
Access
7
New_RX_Msg
= ‘1’
6
RX_DA_Type
=’0’ (Direct)
5
RX_SA_Type
= ‘0’ (Logical)
0x40
RX_Message_INFO
RW
0x41
RX_SA
R
Remote Node Source Address(8 Bytes) = 0x01
0x49
RX_CommandID
R
0x51
0x4a
RX_Data[0]
R
Flash Block Number
0x4b
RX_Data[1]
R
Packet Number (0x00 – 0x03)
0x4c
RX_Data[2-17]
R
Flash Data (16 bytes)
4
3
RX_Msg_Length = ‘10010’
Table 6. Transmitter Memory Array Settings for Field Update Confirmation
Offset
7
6
0x01
Local_LA_LSB
Register Name
RW
Access
0x02
0x05
PLC_Mode
RW
TX_Enable = ‘1’
RX_Enable = ‘1’
Send_Message
= ‘1’
TX_SA_Type =
‘0’ (Logical)
0x06
TX_Message_Length
RW
0x07
TX_Config
RW
0x08
TX_DA
RW
0x01
0x06
TX_Message_Length
RW
Send_Message
= ‘1’
0x10
TX_CommandID
RW
0x52
A flow chart of the receiver algorithm is shown in Figure 8.
Note that the code is separated across multiple files. The
User_Code.c file contains the code that will be updated by
the field update. The code in the other files (including
www.cypress.com
5
4
3
Payload_Length_MASK = ‘00000’
TX_DA_Type = ‘00’
(Direct Logical)
TX_Service _Type = ‘1’
(ACK)
TX_Retry = ‘0011’
Payload_Length_MASK = ‘00000’
main.c) is not updated. The files not shown are
ISR_Handler.c (which handles the GPIO interrupt and
updates a global variable bInterrupted that is read in
User_Code.c) and PLC_Common.c (which contains
common PLC functions).
Document No. 001-62792 Rev. *C
10
Updating Field Firmware with PLC
Figure 8. Receiver Flow Chart
main.c
Initialize PLC to
Receive Messages
User_Code.c
PLT_Field_Update_RX.c
Run User
Application
Interrupt on P1[6]?
N
Expected Blocks =
RX Data[0]
Block Count = 0
Packet Count = 0
Clear RX buffer
Y
Increment
bButtonCount and
display on the LCD
Field
Update Data
Received?
N
Y
Field
Update Start
Received?
Y
RX[0]
= Block Count
RX [1] = Packet
Count?
N
Y
Store 16-byte RX
Data in the offset
of 64-byte Buffer
Increment Packet
Count
Process Field
Update
Packet Count = 4?
N
Store buffer
contents to the
flash block at
Block Count
Block Count =
Expected Blocks?
N
Y
Send Confirmation
Message to
address 0x01
www.cypress.com
Document No. 001-62792 Rev. *C
11
Updating Field Firmware with PLC
PSoC Designer Project
The project was created with PSoC Designer 5.1. Figure 9 shows the chip level view of the project. The FSK Modem +
Network Stack user module option is selected for the PLT user module. The configuration of the LCD user module is shown
in the same figure. The BIU_LED, RX_LED, and TX_LED user modules are placed at P2[1], P2[3], and P2[5], respectively and
are all set to Active High. Port pin P1[6] Drive is set to Pull Down and the interrupt is set to Rising Edge.
Figure 9. PLC Receiver PSoC Designer Project
The firmware is written in C, with the exception of the PLT
interrupt routines (in PLT_1INT.asm), which are modified
to drive transmit, receive, and band-in-use LEDs.
ISR_Handler.c: This is where the user ISRs is processed.
The variable bInterrupted needs to be accessible by the
code in User_Code.c .
The following files are created:
PLC_Flash_Update_RX.c: This is where the received PLC
packet is processed and the flash is updated.
User_Code.c: This is where all of the user’s application
code is written. There should be only one function that is
called from main.c because the calling function needs to
always have the same address. This should be the first
function in the file so that the starting address does not
change whenever there are code modifications. In this
case, the function is called User_Main(). Note that there is
also an interrupt function that modifies a global variable
(bInterrupted), which is used in the User_Main() function.
www.cypress.com
PLC_Common.c: This contains common PLC functions.
myData.asm: Contains the user variables, which are
allocated to page 2 of the RAM
There is a .h header file associated with each of the .c
files.
Document No. 001-62792 Rev. *C
12
Updating Field Firmware with PLC
Allocating in Flash Memory
The code was allocated to the flash according to the
guidelines defined in section “Allocating Code in Flash and
RAM”. The file custom.lkp was updated accordingly. In
addition, the file flashsecurity.hex was updated to set the
corrected protection levels for the flash that contains the
user code.
Transmitter Project
Note If the hardware configuration is modified (for
example, User Modules added), it may extend the initial
AREAs and cause overlap with the user-defined AREAs.
In this case, the AREAs will need to be shifted.
The CY8CPLC20 device has the following inputs and
outputs for the transmitter project:
The transmitter project runs on the CY8CPLC20 PLC
device. The hardware is the same as the receiver project
since only a field update is expected for this example.
Therefore, the block diagram of the transmitter system is
the same as the receiver, which was shown in Figure 7.

Implementation on Hardware
Push Button: When the GPIO input (P1[6])
transitions from low to high, it generates an interrupt.
When the interrupt occurs, the following occurs:
This section describes how to implement the receiver
project in hardware.

The variable bButtonCount is incremented and
displayed on the LCD
P L C R e c e i ve r H a r d w a r e
The PLC receiver project was designed to run on the
CY3274 High Voltage PLC Development Kit. Follow these
steps to set up the system:

A normal data message (ID 0x09) is transmitted
on the powerline. If it is successful, the
bSuccessCount is incremented and displayed on
the LCD
1.
Connect a jumper wire from SW to P1[6]. See
Figure 10 for the location of the headers.
2.
Connect the LCD daughter card to the LCD
connector.
3.
Connect the board to the powerline. The blue
power LED should turn ON.
4.
Program the firmware with the MiniProg in Reset
mode.
5.
Disconnect the programmer and reset the board.
6.
Press the push-button and observe the LCD. The
Count should increment to 01.

PLC: The field update is received from PLC. After the
update is complete, the confirmation is sent via PLC.
The PLC message types are as follows:

Normal Data Message (ID 0x09): When a
normal data message is received, the variable
bRXCount is incremented and displayed on the
LCD.

Field Update Start (ID 0x50): Sent by the
transmitter. This message informs the receiver
that the field update is beginning. It contains the
number of flash blocks that will be transmitted.
The LCD will display “Updating”.

Field Update Data (ID 0x51): Sent by the
transmitter. This message contains the relative
number of the flash block being updated (starting
at 0x00), the relative packet number (0x00 –
0x03), followed by 16 bytes of the flash data.

Field Updated Confirmation (ID 0x52): Sent by
the receiver. This message contains no data and
is sent to inform that the field update was
successful.
Figure 10. CY3274 Receiver Hardware Setup
The PLC memory array setting for these packets is shown
in Table 6 through Table 8. The RX_Override bit is set to
‘0’ so that the message in the memory array is not
overwritten until it is processed.
www.cypress.com
Document No. 001-62792 Rev. *C
13
Updating Field Firmware with PLC
Table 7. Transmitter Memory Array Settings for Field Update Start
Offset
Register Name
Access
7
6
5
4
0x01
Local_LA_LSB
RW
0x01
0x05
PLC_Mode
RW
TX_Enable = ‘1’
0x06
TX_Message_Length
RW
Send_Message = ‘1’
0x07
TX_Config
RW
TX_SA_Type
= ‘0’ (Logical)
0x08
TX_DA
RW
0x02
0x10
TX_CommandID
RW
0x50
0x11
TX_Data[0]
RW
Number of flash blocks that will be updated -coordinate
3
2
1
0
RX_Enabl
e = ‘1’
Payload_Length_MASK
= ‘00001’
TX_DA_Type =
‘00’ (Direct
Logical)
TX_Service_Type= ‘1’ (ACK)
TX_Retry
= ‘0011’
Table 8. Transmitter Memory Array Settings for Field Update Data
Offset
Register Name
Access
7
0x01
Local_LA_LSB
RW
0x01
0x05
PLC_Mode
RW
TX_Enable = ‘1’
0x06
TX_Message_Length
RW
Send_Message= ‘1’
6
5
4
3
2
1
0
RX_Enable = ‘1’
Payload_Length_MASK= ‘10010’
TX_DA_Type = ‘00’
(Direct Logical)
0x07
TX_Config
RW
TX_SA_Type
= ‘0’ (Logical)
0x08
TX_DA
RW
0x02
0x10
TX_CommandID
RW
0x51
0x11
TX_Data[0]
RW
Flash Block Number
0x12
TX_Data[1]
RW
Packet Number (0x00 – 0x03)
0x13 –
0x23
TX_Data[2]
RW
Flash Data (16 bytes)
TX_Service _Type = ‘1’
(ACK)
TX_Retry
= ‘0011’
Table 9. Receiver Memory Array Settings for Field Update Confirm
Offset
Register Name
Access
7
6
RX_DA_Type
=’0’ (Direct)
5
RX_SA_Type
= ‘0’ (Logical)
0x40
RX_Message_INFO
RW
New_RX_Msg = ‘1’
0x41
RX_SA
R
Remote Node Source Address(8 Bytes) = 0x02
0x49
RX_CommandID
R
0x52
0x4a
RX_Data[0]
R
Flash Block Number
0x4b
RX_Data[1]
R
Packet Number (0x00 – 0x03)
4
3
RX_Msg_Length
= ‘00000’
2
1
A flow chart of the transmitter algorithm is shown in the following figure. Note that the code is separated across multiple files.
The User_Code.c file contains the code that will be sent to the receiver for the field update. The code in the other files
(including main.c) is not sent. The files not shown are ISR_Handler.c (which handles the GPIO interrupt and updates a global
variable bInterrupted that is read in User_Code.c) and PLC_Common.c (which contains common PLC functions).
www.cypress.com
Document No. 001-62792 Rev. *C
14
0
Updating Field Firmware with PLC
Figure 11: Transmitter Flow Chart
main.c
Initialize PLC to
Receive Messages
Send Field
Update
User_Code.c
PLT_Field_Update_TX.c
Run User
Application
Send Field Update
Start Message to
Address 0x02
Interrupt on P1[6]?
N
ACK Received?
Y
N
Display “FAIL” on
the LCD
Y
Increment
bButtonCount and
display on the LCD
Block Count = 0
Packet Count = 0
Send a packet to
address 0x02 with
TX Data =
bButtonCount
ACK
Received?
N
Read flash
contents at Block
Count and store in
a 64-byte buffer
Read from the
Packet Count
offset of the buffer
Send Message to
Address 0x02
Y
Increment
bSuccessCount
and display on the
LCD
ACK Received?
N
Data Message
Received?
Display “FAIL” on
the LCD
Y
Y
Packet Count = 4?
Increment
bRXCount and
display on the LCD
N
Y
Field
Update Start
Received?
Block Count =
Total Blocks?
N
Y
Y
N
Confirmation
Received?
www.cypress.com
Document No. 001-62792 Rev. *C
15
Updating Field Firmware with PLC
PSoC Designer Project
The transmitter project has the same configuration as
shown in Figure 9. It is necessary that the configuration is
the same and it is recommended that the transmitter
project is cloned from the receiver project so that the code
is allocated in the same location.
To perform the field update, the guidelines described in
section ’Performing the Field Update’ were followed. The
flash and RAM is allocated in the same locations and the
only differences are:
1.
The PLC_Field_Update_RX.c (and .h) file is replaced
with PLC_Field_Update_TX.c (and .h) so that the field
update can be sent, not received
2.
The User_Main function in User_Code.c is modified to
have a different functionality (described above)
3.
The constant string arrays in User_Code.c are
modified for the new functionality shown by the LCD
display.
4.
The location (#pragma abs_address) of the constant
string arrays was changed from 0x5740 to 0x57C0
because the code size of User_Main and User_Init
increased. The end of the area my_code_area
changed from 0x5732 to 0x57A2, which would have
caused a conflict with the strings.
5.
The code in main.c is modified so that the field update
can be performed.
6.
The new variables in User_Code.c are declared in
myData.asm
7.
The USER_CODE_SIZE_BLOCKS
parameter in
User_Code.h was set to 8 based on the code size:
a.
start = 0x5600 (my_ISR_area),
b.
end = 0x57E0 (end of abLCDText1)
c.
# of blocks = (0x57E0 – 0x5600) / 64 = 7.5
4.
Program the firmware with the MiniProg in Reset
mode.
5.
Disconnect the programmer and reset the board.
6.
Observe the transmitter and receiver LCDs. The
following sequence should occur:

The transmitter will display (“Send Update
XXYY”, where XX represents the flash block
number and YY represents the packet
number for that block. Recall that each
64-byte block is broken into four 16-byte
data packets. Figure 12 shows what the
transmitter’s LCD will display when it has
sent packet 2 of flash block 1. Figure 13
shows what the receiver’s LCD will display
for the same packet. The receiver’s LCD
also displays how many total flash blocks
that it expects receive. In this case, it is 8.

If the receiver is not within range of the
transmitter, then the transmitter’s LCD will
display “Fail” as shown in Figure 14.

If the field update was a success, then the
transmitter and receiver will both display
“Application 2” as shown in Figure 15.

To test out the update, press the pushbutton
SW on both of the boards. If communication
is successful, then both boards will show that
1 packet was acknowledged out of 1
transmitted (“TX =01/01”) and 1 packet was
received (“RX = 01”) as shown in Figure 16.
Figure 12. Transmitter Field Update Display
Implementation on Hardware
This section describes how to implement the transmitter
project in hardware. A second board is needed for
evaluating this project.
PLC Transmitter Hardware
The PLC transmitter project is designed to run on the
CY3274 High Voltage PLC Development Kit. Follow these
steps to set up the system:
1.
Connect a jumper wire from SW to P1[6].
2.
Connect the LCD daughter card to the LCD
connector.
3.
Connect the board to the powerline. The blue
power LED should turn ON.
www.cypress.com
Document No. 001-62792 Rev. *C
16
Updating Field Firmware with PLC
Figure 13. Receiver Field Update Display
Figure 15. Transmitter and Receiver Successful Update
Display
Figure 14. Transmitter Field Update Failure Display
Figure 16. Application 2 Packet Transmit and Receive
www.cypress.com
Document No. 001-62792 Rev. *C
17
Updating Field Firmware with PLC
Document History
Document Title: Updating Field Firmware with PLC - AN62792
Document Number: 001-62792
Revision
ECN
Orig. of
Change
Submission
Date
**
2969819
FRE
07/05/10
*A
3177822
FRE
02/20/2011
*B
3379910
ADIY
9/22/2011
*C
4542402
ROIT
10/17/2014
www.cypress.com
Description of Change
New Application Note.
Updated Software Version as PSoC® Designer™ 5.1 SP1
Updated Allocating Code in Flash and RAM.
Updated Performing the Field Update.
Updated Receiver Project.
Updated Transmitter Project.
Updated PSoC Designer Project.
Removed reference to CY8CLED16P01, CY3276 and CY3277.
Updated Figure 1 and Figure 2.
Updated template.
Removed reference to CY3275 kit (obsolete)
Document No. 001-62792 Rev. *C
18
Updating Field Firmware with PLC
Worldwide Sales and Design Support
Cypress maintains a worldwide network of offices, solution centers, manufacturer’s representatives, and distributors. To find
the office closest to you, visit us at Cypress Locations.
PSoC® Solutions
Products
Automotive
cypress.com/go/automotive
psoc.cypress.com/solutions
Clocks & Buffers
cypress.com/go/clocks
PSoC 1 | PSoC 3 | PSoC 4 | PSoC 5LP
Interface
cypress.com/go/interface
Lighting & Power Control
cypress.com/go/powerpsoc
cypress.com/go/plc
Memory
cypress.com/go/memory
PSoC
cypress.com/go/psoc
Touch Sensing
cypress.com/go/touch
USB Controllers
cypress.com/go/usb
Wireless/RF
cypress.com/go/wireless
Cypress Developer Community
Community | Forums | Blogs | Video | Training
Technical Support
cypress.com/go/support
PSoC is a registered trademark and PSoC Creator is a trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks
referenced herein are the property of their respective owners.
Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
Phone
Fax
Website
: 408-943-2600
: 408-943-4730
: www.cypress.com
© Cypress Semiconductor Corporation, 2010- 2014. The information contained herein is subject to change without notice. Cypress Semiconductor
Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any
license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or
safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as
critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The
inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies
Cypress against all charges.
This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide
patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a
personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative
works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress
integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the
right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or
use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a
malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems
application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.
www.cypress.com
Document No. 001-62792 Rev. *C
19