AN68272
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Authors: Anu M D, Siddalinga Reddy
Associated Project: Yes
Associated Part Family: CY8C3xxx, CY8C42xx, CY8C4Axx, CY8C40xxS, CY8C41xxS, CY8C5xxx
Software Version: PSoC Creator™ 3.3 SP2 and higher
Related Application Notes: For a complete list, Related Application Notes
More code examples? We heard you.
To access an ever-growing list of hundreds of PSoC code examples, please visit our code
examples web page. You can also explore the PSoC 4 video library here.
®
AN68272 describes a UART-based bootloader for PSoC 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor. In
this application note, you will learn how to use PSoC Creator™ to quickly and easily build a UART-based bootloader
project and bootloadable projects. It also shows how to build a UART-based embedded bootloader host program and
a C#-based bootloader application.
Contents
1
Introduction ...............................................................1
1.1
Terms and Definitions ......................................2
1.2
Using a Bootloader ..........................................3
1.3
Bootloader Function Flow ................................3
1.4
Techniques to Enter Bootloader ......................4
2
Projects ....................................................................5
2.1
UART Bootloader.............................................5
2.2
PSoC 3 and PSoC 5LP Bootloadables .......... 13
2.3
PSoC 4 Bootloadables ................................... 16
2.4
Bootloading Using a PC Host ........................ 19
2.5
Bootloading Using an Embedded Host .......... 21
3
Testing the Projects ................................................ 25
3.1
Kit Configuration ............................................ 25
3.2
Bootloading PSoC 3 ...................................... 26
3.3
Bootloading PSoC 4/
PSoC Analog Coprocessor ............................ 26
4
Summary ................................................................ 26
1
5
Related Application Notes ...................................... 26
6
Related Projects ..................................................... 27
A
Appendix A – Memory ............................................ 28
B
Appendix B – Project Files ..................................... 32
C
Appendix C – Host/Target Communications........... 33
D
Appendix D – Host Core APIs ................................ 36
E
Appendix E – Bootloader and Device Reset........... 37
F
Appendix F – Miscellaneous Topics ....................... 40
G
Appendix G – C# Bootloader Host Application ....... 43
H
Appendix H – Kit Selection ..................................... 47
Worldwide Sales and Design Support ............................. 49
Products .......................................................................... 49
®
PSoC Solutions ............................................................. 49
Cypress Developer Community....................................... 49
Technical Support ........................................................... 49
Introduction
Bootloaders are a common part of an MCU system design. A bootloader makes it possible for a product's firmware to
be updated in the field. At the factory, the firmware is initially programmed into a product typically through the MCU's
Joint Test Action Group (JTAG) or the ARM serial wire debug (SWD) interface. However, these interfaces are usually
not accessible in the field.
This is where bootloading comes in. Bootloading is a process that allows you to upgrade your system firmware over a
2
standard communication interface such as USB, I C, UART, or SPI. A bootloader communicates with a host to get
new application code or data and writes it into the device's flash memory.
www.cypress.com
Document No. 001-68272 Rev. *J
1
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
In this application note you will learn:
How to create a UART bootloader using PSoC Creator
Bootloader host topics:
How to use the Bootloader Host tool
The basic building blocks and functionality of a bootloader host system
How to create an embedded UART bootloader host using PSoC 5LP
How to create a PC bootloader application
This application note assumes that you are familiar with PSoC and the PSoC Creator Integrated Design Environment
(IDE). If you are new to PSoC 3, PSoC 4, PSoC 5LP, or PSoC Analog Coprocessor, refer to AN54181 – Getting
Started with PSoC 3, AN79953 – Getting Started with PSoC 4, AN77759 – Getting Started with PSoC 5LP, or
AN211293 – Getting Started with PSoC Analog Coprocessor, respectively. If you are new to PSoC Creator, see the
PSoC Creator home page.
This application note also assumes that you are familiar with bootloader concepts. If you are new to these concepts,
see AN73854 – PSoC 3, PSoC 4, and PSoC 5LP Introduction to Bootloaders. For a complete list of other application
notes on bootloading, see Related Application Notes.
Finally, this application note assumes that you are familiar with the UART protocol and the PSoC Creator UART
Component. If you are new to the UART Component, see the PSoC Creator UART Component datasheet. You can
also get the datasheet by right-clicking on the UART Component in PSoC Creator.
1.1
Terms and Definitions
Figure 1 illustrates the main elements in a bootloader system. It shows that the product's embedded firmware must
be able to use the communication port for two different purposes: normal operation and updating flash. The portion of
the embedded firmware that knows how to update the flash is called the “bootloader.” The other terms in Figure 1 are
defined in the following paragraphs.
Figure 1. Bootloading System Diagram
Target
PSoC
Host
Application
File
Communication
Channel
UART
Flash
Memory
Application
Bootloader
The system that provides the data to update the flash is called the “host,” and the system being updated is called the
“target.” The host can be an external PC (PC host) or another MCU (embedded host such as PSoC 5LP device) on
the same PCB as the target.
The act of transferring data from the host to the target flash is called “bootloading,” or a “bootload operation,” or a
“bootload” for short. The firmware that is placed in flash is called the “application” or the “bootloadable.”
Another common term for bootloading is “in-system programming (ISP).” Cypress has a product with a similar name
but a different function called in-system serial programming (ISSP)” and an operation called “host-sourced serial
programming (HSSP).” For more information, see AN73054 – PSoC 3 and PSoC 5LP Programming Using an
External Microcontroller (HSSP).
www.cypress.com
Document No. 001-68272 Rev.*J
2
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
1.2
Using a Bootloader
A bootloader communication port is typically shared between the bootloader and the actual application. The first step
to use a bootloader is to manipulate the target so that the bootloader, and not the application, is executing.
Once the bootloader is running, the host can send a start bootload command over the communication channel. If the
bootloader sends an OK response, bootloading can begin.
During bootloading, the host reads the file for the new application, parses it into flash write commands, and sends
those commands to the bootloader. After the entire file is sent, the bootloader can pass control to the new application.
1.3
Bootloader Function Flow
Typically, when the device resets, the bootloader is the first function to execute. It then performs the following actions:
Checks the application's validity before letting it run
Manages the timing to start host communication
Does the bootload/flash update operation
Passes control to the application
Figure 2 shows the typical bootloader functions.
www.cypress.com
Document No. 001-68272 Rev.*J
3
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Figure 2. Bootloader Function Flow
Reset
Bootloader
valid in flash?
No
Halt execution
Yes
Application
valid in flash?
No
Yes
Wait for
new application
from host ?
No
Yes
Yes
Wait forever ?
Host comm.
start ?
Yes
No
Host comm.
start?
No
Yes
Receive new
application from
host,
install in flash,
overwriting
existing
application
No
Timeout ?
Yes
Go to application
No
1.4
Techniques to Enter Bootloader
As mentioned previously, the bootloader is the first function to run at reset. As Figure 2 shows, the bootloader code
waits for the host for a short period before passing control to the application. This may cause the host to miss an
opportunity to start the bootload operation. However, another way exists to start bootloading, and that is to pass
control from the application or bootloadable back to the bootloader.
1.4.1
Bootloadable API
The Bootloadable Component in PSoC Creator has an application programming interface (API) function to start the
bootloader: Bootloadable_Load(). This allows the host to start a bootload operation at any time.
The problem with this method is that you must depend on the application code to perform an application upgrade.
What happens if the application has a defect that prevents transfer of control to the bootloader?
www.cypress.com
Document No. 001-68272 Rev.*J
4
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
1.4.2
Customize Bootloader
Instead, it may be better to have the bootloader wait an infinite amount of time for the host. To do that, you can
customize the bootloader project to check for some user input before calling Bootloader_Start() and running
through its normal routine.
For example, the bootloader may monitor the UART and wait forever for a user command before calling
Bootloader_Start(). For more information, refer to AN73854 – PSoC 3, PSoC 4, and PSoC 5LP Introduction to
Bootloaders.
2
Projects
This section shows you the steps to create the following PSoC Creator projects:
UART bootloader
Bootloadable
Embedded bootloader host
The projects are designed to be used with Cypress development kits. Kit selection is based on the target device; refer
to Appendix H – Kit Selection for details. You may be required to change the pins connection based on the kit.
Review the specific kit documentation for connections. The projects can be easily adapted for other custom boards.
2.1
UART Bootloader
In this section, you create and build a UART-based bootloader project. One feature of this project is that while
bootloading is taking place, the kit’s LED blinks.
1.
Create a new PSoC Creator project, and name it “UART_Bootloader.” Select the target device and create a new
workspace for the project.
Note: For PSoC Creator 3.1 and lower version, the application type should be specified while creating the project. To
do so, click on the “+” button next to the Advanced tab to expand the configuration options. Select Bootloader as
the application type.
2.
Add a UART Component to the TopDesign schematic, as Figure 3 and Figure 4 shows.
Figure 3. UART Component for PSoC 3 and PSoC 5LP
www.cypress.com
Document No. 001-68272 Rev.*J
5
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Figure 4. UART Component for PSoC 4 and PSoC Analog Coprocessor
3.
Add a Bootloader Component to the TopDesign schematic, as Figure 5 shows.
Figure 5. Bootloader Component
www.cypress.com
Document No. 001-68272 Rev.*J
6
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
4.
To blink an LED, add a PWM (TCPWM for PSoC 4 and PSoC Analog Coprocessor), a Clock, and a Digital
Output Pin Component to the schematic.
5.
Rename the Components and pins, as Table 1 shows.
Table 1. Bootloader Project Component Names
Component
6.
Name
Bootloader_1
Bootloader
UART_1
UART
Rx_1
Rx
Tx_1
Tx
Clock_1
Clock
Pin_1
Pin_LED
PWM_1 / TCPWM_1
PWM
With an LED and resistor added as annotation Components, the TopDesign of the project for PSoC 3 and
PSoC 5LP looks similar to Figure 6, and the TopDesign for PSoC 4 and PSoC Analog Coprocessor looks similar
to Figure 7.
Figure 6. TopDesign of UART_Bootloader Project for PSoC 3 and PSoC 5LP
www.cypress.com
Document No. 001-68272 Rev.*J
7
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Figure 7. TopDesign of UART Bootloader Project for PSoC 4 and PSoC Analog Coprocessor
R
D
250 Hz
In this example, there is no need to reset the UART so the reset terminal is connected to a Logic Low '0'
Component.
7.
To configure the Bootloader, double-click on the Component.
8.
Select UART as the Communication component, as Figure 8 shows. Leave the other parameters at their
default settings. For more information on these configuration parameters, refer to the Bootloader Component
datasheet.
Figure 8. Bootloader Configuration
www.cypress.com
Document No. 001-68272 Rev.*J
8
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
9.
To configure the UART Component, double-click on it. By default, it is in Full UART mode with a data rate of
57,600 bps. Leave all parameters at their default settings. Figure 9 and Figure 10 shows the basic configuration
tab of the UART Component.
Figure 9. Basic UART Configuration for PSoC 3 and PSoC 5LP
Figure 10. Basic UART Configuration for PSoC 4 and PSoC Analog Coprocessor
www.cypress.com
Document No. 001-68272 Rev.*J
9
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
10. Click on the Advanced tab of the UART configuration window.
11. Set both the receive (Rx) and transmit (Tx) buffer sizes to 64 to avoid communication overflow (the host packet
size is as much as 64 bytes). Leave the other parameters at their default settings. See Figure 11 and Figure 12.
Figure 11. Advanced UART Configuration for PSoC 3 and PSoC 5LP
www.cypress.com
Document No. 001-68272 Rev.*J
10
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Figure 12. Advanced UART Configuration for PSoC 4 and PSoC Analog Coprocessor
12. To configure the PWM Component, double-click on it. Set the Period to 255, and the Compare to 127. Leave
the other parameters at their default settings.
13. To configure the Clock Component, double-click on it. Set the Frequency to ILO / 4, or ~250 Hz. Leave the other
parameters at their default settings.
14. For the Pin_LED Component, leave the parameters at their default settings.
15. Assign the Pin Components to physical pins. In the Workspace Explorer window, double-click the
UART_Bootloader.cydwr file, and click on the Pins tab. Table 2 shows the pin assignments for different kits. Pin
assignments depend on the kit; refer to the kit user guide for information.
www.cypress.com
Document No. 001-68272 Rev.*J
11
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Table 2. Pin Assignments for UART Bootloader Projects for Kits
Pin Name
CY8CKIT-030
CY8CKIT-050
CY8CKIT-042
CY8CKIT-041-40xx
CY8CKIT-041-41xx
CY8CKIT-048
\UART:rx\
P0[0]
P0[0]
P4[0]
P0[4]
P0[4]
P0[4]
\UART:rx\
P0[1]
P0[1]
P4[1]
P0[5]
P0[5]
P0[5]
Pin_LED
P6[2]
P6[2]
P1[6]
P3[4]
P3[4]
P1[4]
16. Add the Bootloader_Start() function to the main.c file. This API function does the entire bootloading
operation. It does not return—it ends with a software device reset. Therefore, any code that is placed after this
API call is not executed.
Add the PWM_Start() function to initialize the PWM in main(), as Code 1 shows. For more information on this
Component API, see the PWM Component datasheet.
Code 1. PWM Initialization in Bootloader
void main()
{
/* Initialize PWM */
PWM_Start();
Bootloader_Start();
/* Uncomment this line to enable
global interrupts. */
/* CyGlobalIntEnable; */
for(;;)
{
/* Place your code here. */
}
}
17. Build the project and program it into a specific kit based on your target device selection. Refer to Appendix H –
Kit Selection to get kit-related information based on your device selection.
You have now created a simple UART-based bootloader. It can communicate with a host and download the
bootloadable project. The bootloader can be expanded and customized in a number of ways; see the Bootloader and
UART Component datasheets and AN73854 – PSoC 3, PSoC 4 and PSoC 5LP Introduction to Bootloaders for
details.
Note: The bootloader occupies a portion of the PSoC flash, reducing the amount of flash available for the application.
See Appendix F for details.
Now you will see how to create bootloadable applications that can be used with this bootloader.
www.cypress.com
Document No. 001-68272 Rev.*J
12
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
2.2
PSoC 3 and PSoC 5LP Bootloadables
This section involves creating two bootloadable projects. They are very similar—one displays "Hello" on the kit’s
character LCD and the other displays "Bye." The section describes the steps to create these bootloadable projects.
1.
Create a new PSoC Creator project, and name the project “Bootloadable1.” The devices for this project and the
UART_Bootloader project must be the same.
Note: For PSoC Creator 3.1 and lower versions, the application type should be specified while creating the
project. To do so, click on the “+” button next to the Advanced tab to expand the configuration options. Select
Bootloadable as the application type.
2.
For this project, you need the Bootloadable, Digital Input Pin, and LCD Components. Add these Components to
your TopDesign schematic, as Figure 13 shows.
Figure 13. Bootloadable1 Project Components
3.
Rename the Components according to Table 3.
Table 3. Bootloadable Project Component Names
4.
Component
Name
Bootloadable_1
Bootloadable
Pin_1
Pin_StartBootloader
LCD_Char_1
LCD_Char
To configure the Bootloadable Component, double-click on it.
A.
A bootloadable project is always linked to the .hex file of a bootloader project. To configure the component,
go to the Dependencies tab of the Bootloadable Component configuration window, as Figure 14 shows.
www.cypress.com
Document No. 001-68272 Rev.*J
13
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
B.
Select the UART_Bootloader.hex file, as Figure 14 shows. For more information on Bootloader Component
configuration, see the Bootloader Component datasheet.
Figure 14. Bootloadable Component Configuration
You can find the UART_Bootloader.hex file in the bootloader project's Debug or Release folder:
When PSoC 3 is the bootloader,
..\UART_Bootloader\UART_Bootloader.cydsn\DP8051\DP8051_Keil_951\Debug\UART_Bootloader.hex
When PSoC 5LP is the bootloader,
..\UART_Bootloader\UART_Bootloader.cydsn\CortexM3\ARM_GCC_493\Debug\UART_Bootloader.hex
5.
The digital input pin Pin_StartBootloader is used to switch from the application back to the bootloader. When the
DVK button is pressed, it shorts to ground, so configure the drive mode of the Pin to be Resistive pull up, as
Figure 15 shows.
Figure 15. Digital Input Pin Configuration
www.cypress.com
Document No. 001-68272 Rev.*J
14
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
6.
With the addition of the annotation Components for the button and the input pin, the TopDesign is complete; it
should be similar to Figure 16.
Figure 16. TopDesign of Bootloadable1 Project for PSoC 3 and PSoC 5LP
7.
Assign the Pin Components to physical pins. In the Workspace Explorer window, double-click the
Bootloadable1.cydwr file and assign the pins as Figure 17 shows.
Figure 17. Pin Assignments of Bootloadable1 Project
On the CY8CKIT-030 and CY8CKIT-050 kit boards, the LCD pins are hardwired to P2[6:0], and SW2 is
hardwired to P6[1].
8.
A completed Bootloadable1 project is associated with this application note. Insert the code listing from the main.c
file of this associated project to the main.c file of your project.
The main() function continuously checks the status of the Pin_StartBootloader. When this pin shorts to ground,
the API function Bootloadable_Load() is called to invoke the bootloader. The bootloader waits indefinitely for
the host to start the bootload operation.
9.
Build the project. When a bootloadable project is built, PSoC Creator generates a .cyacd file. This is the file that
is bootloaded onto the target. For more information on this file and its contents, see Appendix B.
10. To create the other bootloadable project that displays "Bye," repeat the previous steps in this section. Name the
project “Bootloadable2.” The only difference between the two projects is that the code in main.c displays "Bye"
instead of "Hello."
Note: For PSoC Creator versions before 3.0, if the bootloader is updated, you must also rebuild all bootloadable
projects that depend on that bootloader project. Use the “Clean and Build” option.
To bootload this project using a PC host, see Bootloading Using a PC Host.
www.cypress.com
Document No. 001-68272 Rev.*J
15
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
2.3
PSoC 4 Bootloadables
In this section you will create two bootloadable projects for PSoC 4 and PSoC Analog Coprocessor. These projects
are designed for the CY8CKIT-042 kit, but they can be easily adapted to other kits that use other PSoC 4 and PSoC
Analog Coprocessor devices. For kit-related information, refer to Appendix H – Kit Selection and the kit user manual.
These projects are very similar–one blinks the green LED and the other blinks the blue LED on the kit. This section
describes the steps for creating these bootloadable projects.
1.
Create a new PSoC Creator project, and name the project “Bootloadable1.” The devices for this project and the
UART_Bootloader project must be the same.
Note: For PSoC Creator 3.1, the application type should be specified while creating the project. To do so, click
on the “+” button next to the Advanced tab to expand the configuration options. Select Bootloadable as the
application type.
2.
For this project, you need the Bootloadable, Digital Input Pin and Digital Output Pin Components. Add these
Components to your TopDesign schematic, as Figure 18 shows.
Figure 18. Bootloadable1 Project Components
3.
Rename the Components according to Table 4.
Table 4. Bootloadable1 Component Names
Component
Name
Bootloadable_1
Bootloadable
Pin_1
Green_LED
Pin_2
Pin_StartBootloader
The next step is to configure these Components.
4.
To configure the Bootloadable Component, double-click on it.
A.
A bootloadable project is always linked to the .hex file of a bootloader project. To configure the component,
go to the Dependencies tab of the Bootloadable Component configuration window, as Figure 19 shows.
B.
Select the UART_Bootloader.hex file as shown. For more information on the Bootloader Component
configuration, see the Bootloader Component datasheet.
www.cypress.com
Document No. 001-68272 Rev.*J
16
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Figure 19. Bootloadable Component Configuration
1
2
You can find the UART_Bootloader.hex file in the bootloader project’s Debug or Release folder:
For PSoC 42xx,
..\UART_Bootloader\UART_Bootloader.cydsn\Cortex M0\ARM_GCC_493\Debug\UART_Bootloader.hex
For PSoC CY8C4Axx, CY8C40xxS, CY8C41xxS,
..\UART_Bootloader\UART_Bootloader.cydsn\Cortex M0p\ARM_GCC_493\Debug\UART_Bootloader.hex
5.
The digital input pin (Pin_StartBootloader) is used to switch from the application back to the bootloader. When
the DVK button is pressed, it shorts to ground, so configure the drive mode of the pin to be Resistive pull up, as
Figure 20 shows.
Figure 20. Digital Input Pin Configuration
www.cypress.com
Document No. 001-68272 Rev.*J
17
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
6.
With the addition of annotation Components for the button and the input pin, the TopDesign is complete; it should
be similar to Figure 21.
Figure 21. TopDesign of Bootloadable1 Project
7.
Assign the Pin Components to physical pins. In the Workspace Explorer window, double-click the
Bootloadable1.cydwr file and assign the pins. Table 5 shows the pin assignment for bootloable1 project for
different kits.
Table 5. Pin Assignments for Bootloadable1 for Kits
Pin Name
CY8CKIT-042
CY8CKIT-04140xx
CY8CKIT-04141xx
CY8CKIT-048
Green_LED
P0[2]
P2[6]
P2[6]
P2[6]
Pin_StartBootloader
P0[7]
P0[7]
P0[7]
P0[3]
On the CY8CKIT-042 kit board, the green LED is hardwired to P0[2], and SW2 is hardwired to P0[7].
8.
A completed bootloadable project for PSoC 4 is associated with this application note. Insert the code listing from
the main.c file of this associated project to the main.c file of your project.
The main() function continuously checks the status of the Pin_StartBootloader. When this pin shorts to ground,
the API function Bootloadable_Load() is called to invoke the bootloader. The bootloader waits indefinitely for
the host to start the bootload operation.
9.
Build the project. When a bootloadable project is built, PSoC Creator generates a .cyacd file. This is the file that
is bootloaded onto the target. For more information on this file and its contents, see Appendix B.
10. To create the other bootloadable project that blinks the blue LED, repeat the previous steps in this section. Name
the project “Bootloadable2.” The only difference between the two projects is that the Digital Output Pin Blue_LED
connection will be different.
Note: For PSoC Creator versions before 3.0, if the bootloader is updated, you must also rebuild all bootloadable
projects that depend on that bootloader project. Use the “Clean and Build” option.
You will now bootload this project into a target PSoC 4 or PSoC Analog Coprocessor using the UART Bootloader
Host application (PC host).
www.cypress.com
Document No. 001-68272 Rev.*J
18
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
2.4
Bootloading Using a PC Host
A bootloader host executable is provided with this application note for bootloading an application from a PC host, as
Figure 22 shows. UARTBootloaderHost.exe can be found in the Bootloader_Host_GUI_exe folder inside the
AN68272.zip file. Review it and follow the instructions in the Prerequisites.txt file to install the software required to run
this tool. The Dynamic Link Libraries (dll) to be used with the executable for 64-bit and 32-bit Windows platforms are
given in the respective folders inside the Bootloader_Host_GUI_exe folder. Note that this executable does not
support multi-application bootloading. Use the Bootloader Host provided with PSoC Creator for that purpose. This
tool can be accessed through Tools > Bootloader Host.
Figure 22. Bootloading Using a PC Host
Follow these steps to bootload an application using the Bootloader Host application. As noted previously, you must
program the bootloader project to the PSoC device before starting a bootload operation.
1.
To bootload PSoC 3 or PSoC 5LP, connect an RS-232 serial cable to port (P7) of CY8CKIT-030/CY8CKIT-050.
To bootload PSoC 4, an RS-232 serial cable is not required, as the PSoC 5LP on the PSoC 4 and PSoC Analog
Coprocessor kits has a USB–UART bridge. Therefore, you only need to provide an external connection between
the UART port pins of PSoC 4 and the onboard PSoC 5LP on the kit. For example, in CY8CKIT-042 connect
P0[0] to pin 10 on the header J8 and P0[1] to pin 9 on the header J8.
2.
Open the Bootloader Host application (UARTBootloaderHost.exe). Select the appropriate COM port and baud
rate, as Figure 23 shows. The baud rate selected must be the same as that configured in the UART Component
in the bootloader project (Figure 9 on page 9).
The COM ports in your computer are listed in the Ports (COM and LPT) category in the Device Manager. If you
are using a USB-to-UART Bridge, they appear in this category after enumeration. The COM port number is
displayed in brackets after the COM port name.
Figure 23. Bootloader Host Application
www.cypress.com
Document No. 001-68272 Rev.*J
19
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
3.
Choose the appropriate bootloadable file in the bootloadable project’s Debug/Release folder:
When PSoC 3 is the bootloader,
...\Bootloadable1.cydsn\DP8051\DP8051_Keil_951\Debug\Bootloadable1.cyacd
When PSoC 5LP is the bootloader,
...\Bootloadable1.cydsn\CortexM3\ARM_GCC_493\Debug\Bootloadable1.cyacd
When PSoC 4000S/4100S or PSoC Analog Coprocessor is the bootloader,
...\Bootloadable1.cydsn\CortexM0p\ARM_GCC_493\Debug\Bootloadable1.cyacd
When PSoC 4200 is the bootloader,
...\Bootloadable1.cydsn\CortexM0\ARM_GCC_493\Debug\Bootloadable1.cyacd
4.
Browse the .cyacd file and click the Bootload button to begin bootloading. The bootloading status will be
displayed in the Status Log section, as Figure 24 shows.
Figure 24. Downloading Bootloadable Project
5.
After a successful bootload operation, for PSoC 3 or PSoC 5LP the message "Hello" is displayed on the
CY8CKIT-030/CY8CKIT-050 LCD. For PSoC 4 and PSoC Analog Coprocessor, the green LED on the kit starts
to blink.
Note: For KitProg 2.16 needs a device reset after the successful bootload operation to pass the control to
bootloaded application. This is a known issue and it will be resolved in higher version of KitProg.
6.
To bootload again, press SW2 on the DVK. This makes the PSoC device enter the bootloader. Now repeat steps
3 to 5 to bootload again.
www.cypress.com
Document No. 001-68272 Rev.*J
20
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
2.5
Bootloading Using an Embedded Host
In addition to studying the example projects, it is useful to understand the general structure of a bootloader host
program. This can help you to build your own bootloader host system.
2.5.1
Bootloader Host Program
Figure 25 illustrates a protocol-level diagram of a bootloader system. The bootloader host and target each have two
blocks: a core and a communication layer.
Figure 25. Protocol-Level Diagram of Bootloading
Bootloader Host
UI Application
Bootloader Target
Bootloader Host Core
command.c / .h
api.c / .h
Bootloader Target Core
api2.c / .h
parse.c / .h
UART
Communication Layer
2.5.2
Communication Layer
The bootloader host core performs all bootloading operations—it sends command packets and flash data to the
The bootloader target core decodes the commands from the host; executes them by calling flash routines such
as erase row, program row, and verify row; and forms response packets.
The communication layer on both the host and the target provides physical layer support to the bootloading
target. Based on the response from the target, it decides whether to continue bootloading.
protocol. It contains communication protocol (UART)-–specific APIs to perform this function. This layer is
responsible for sending and receiving protocol packets between the host and the target.
B o o t l o a d e r S ys t e m A P I s
All APIs for the target core and communication layer are automatically generated by PSoC Creator when you build a
bootloader project.
The APIs for the host core are also provided by PSoC Creator and can be found at:
<install folder> \ PSoC Creator \ 3.3 \ PSoC Creator \ cybootloaderutils
For more information on these API files, see Appendix D.
The only code that you need to write is the host-side API functions for the communication layer, which are in a file
pair communication_api.c /.h. There are four functions: OpenConnection(), CloseConnection(),
ReadData(),
and
WriteData().
They
are
pointed
to
by
function
pointers
within
the
CyBtldr_CommunicationsData structure, defined in cybtldr_api.h.
Appendix F – Miscellaneous Topics shows you how to use these APIs to create your own host using C#.
www.cypress.com
Document No. 001-68272 Rev.*J
21
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
2.5.3
Steps to Create a UART Bootloader Host Project
This section shows you how to create an embedded UART bootloader host project using PSoC 5LP, which can
bootload another PSoC device. With this project, the host can bootload two different bootloadable files (.cyacd files)
on alternate switch presses.
1.
Create a new PSoC Creator project, select the PSoC 5LP as a target device, name the project
“UART_Bootloader_Host,” and create a new workspace for that project.
Note: For PSoC Creator 3.1, the application type should be specified while creating project. To do son, click the
“+” button next to the Advanced tab to expand the configuration options. Select Normal as the application type.
2.
Add a UART Component to the TopDesign schematic, as Figure 26 shows. Also, add Digital Input Pin and
Character LCD Components to the TopDesign .
Figure 26. UART Component
3.
Rename the Components according to Table 6.
Table 6. Component List for UART Bootloader Host Project
Component
Name
UART_1
UART
Rx_1
Rx
Tx_1
Tx
Pin_1
Pin_Switch
LCD_Char_1
LCD_Char
The next step is to configure these Components.
4.
To configure the UART Component, double-click on it. By default, it is in Full UART mode with a data rate of
57,600 bps. Leave all parameters at their default settings.
Note: The project can run at any supported data rate, but the data rate must be the same as that of the
bootloader project.
5.
In the Advanced tab of the Component configuration window, set the transmit (Tx) and receive (Rx) buffer sizes
to 64 to avoid any communication overflow (the host packet is as much as 64 bytes), as illustrated in
Figure 27.
www.cypress.com
Document No. 001-68272 Rev.*J
22
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Figure 27. UART Advanced Configuration
a
6.
The Digital Input Pin Pin_Switch is used to initiate the bootloading operation in the host. When the kit button is
pressed, it shorts to ground, so you need to configure this pin to have a resistive pull-up.
7.
With the addition of annotation Components to the button, the TopDesign of this project should be similar to
Figure 28.
Figure 28. TopDesign of UART_Bootloader_Host project
www.cypress.com
Document No. 001-68272 Rev.*J
23
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
8.
Assign the input and output pins. In the Workspace Explorer
UART_Bootloader_Host.cydwr and assign the pins as Figure 29 shows.
window,
double-click
the
file
Figure 29. UART_Bootloader_Host Project Pin Assignments
On the CY8CKIT-050 kit boards, the LCD pins are hardwired to P2[6:0], and SW2 is hardwired to P6[1]. Wire the
kit board to connect the designated port pins (P4) to TX and RX (P5).
9.
Add firmware to this project. The UART_Bootloader_Host project is attached to this application note. Insert the
code listing from the main.c file of this associated project to the main.c file of your project.
The main() function in main.c continuously checks the status of Pin_Switch. When it is grounded, bootloading is
initiated. The file main.c has a function called BootloadStringImage(), which is defined in device.h. This
function bootloads the .cyacd file using the Bootloader Host API files (host core; see Figure 25 on page 21).
The main() function has a variable called “toggle.” It alternates between '0' and '1' on every button press. This
makes the host select alternate bootloadable files.
10. As explained previously, a bootloader host core is built on four API files. These files do all the host bootloading
operations. You must include these files in your project. Find these API files at the following location:
<install folder> \ PSoC Creator \ 3.3 \ PSoC Creator \ cybootloaderutils
To include these files, go to the Workspace Explorer window, right-click on the project name, and choose
Add > Existing Item, as Figure 30 shows. Add the following files provided by PSoC Creator: cybtldr_api.c /.h,
cybtldr_command.c /.h, cybtldr_parse.c /.h, and cybtldr_utils.h.
Figure 30. Adding API Files
11. In addition to the bootloading API files, the host also requires communication layer support. This support is
provided by adding the communication_api.c /.h files. You can include the contents of these files from the
UART_Bootloader_Host project associated with this application note (follow the previous step to add these files
to the project). Update these files by copying from the project attached to this application note.
12. Now include the bootloadable files in the host system. When a bootloadable file is built, a .cyacd file is
generated; the file is similar to a .hex output file. For more information on the .cyacd file, see Appendix B.
A.
Copy the contents of this file in the form of an array of strings such that each line is an element of the array.
Since you have two bootloadable files, you must define two such arrays, named “StringImage1” and
“StringImage2.” For each array, define a macro to store the number of lines in that array. Define these arrays
in a separate file named “StringImage.h” (this file must be added to the project before defining the strings).
B.
Refer to the StringImage.h file in the UART_Bootloader_Host project associated with this application note.
Alternatively, you can use the Windows C# application provided along with this application note to generate the
StringImage.h file.
13. Build the project and program it into the PSoC 5LP device on the CY8CKIT-050 kit.
www.cypress.com
Document No. 001-68272 Rev.*J
24
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
3
Testing the Projects
The main.c file of the UART_Bootloader_Host project has a macro called “TARGET_DEVICE.” This macro is used to
choose the target device among PSoC 3, PSoC 4, PSoC Analog Coprocessor, and PSoC 5LP. By default, it is
defined as “PSoC_3” (another macro in the same file). If you are using PSoC 4, PSoC Analog Coprocessor, or
PSoC 5LP as your target device, change the definition of this macro to “PSoC_4,” “PSoC_AC,” or “PSoC_5LP”
respectively.
3.1
Kit Configuration
To test the projects, configure the kits as follows:
For CY8CKIT-030:
1.
Program the PSoC 3 device with the UART_Bootloader project.
2.
Set jumpers J10 and J11 to 5 V.
3.
Connect the character LCD to Port 2 [6:0].
For PSoC 4 or PSoC Analog Coprocessor based kits:
1.
Program PSoC 4 or PSoC Analog Coprocessor with the UART_Bootloader project (PSoC 4 and PSoC Analog
Coprocessor project).
2.
Set the jumper to 5 V.
For CY8CKIT-050:
1.
Program PSoC 5LP with the UART_Bootloader_Host project.
2.
Set jumpers J10 and J11 to 5 V.
3.
Connect the character LCD to Port 2 [6:0].
Make the following connections between the two DVKs. This example considers the CY8CKIT-030 and CY8CKIT-042
kits to be the target.
1.
Connect P0 [0] of CY8CKIT-030 (CY8CKIT-042) to P0 [1] of CY8CKIT-050.
2.
Connect P0 [1] of CY8CKIT-030 (CY8CKIT-042) to P0 [0] of CY8CKIT-050.
3.
Short together the ground pins of the kits.
The connections are illustrated in Figure 31. The connection may change based on the UART pins selected in the
bootloader project.
Note: In Figure 31, the target can also be a PSoC 5LP device (CY8CKIT-050), in which case, the pin connections
are same as that for CY8CKIT-030.
Figure 31. Host/Target Connections
Character LCD (mounted in
CY8CKIT-030)
Character LCD
CY8CKIT-050
SW1
P6 [1]
Bootloader Host
PSoC 5LP
P0[1] Tx
Rx P0[0]
P0[0] Rx
Tx P0[1]
GND
www.cypress.com
CY8CKIT-030/CY8CKIT-042
Target
PSoC 3
(PSoC 4)
SW1
P6 [1]
(P0 [7])
GND
Document No. 001-68272 Rev.*J
25
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
3.2
Bootloading PSoC 3
After the DVKs are configured, you can test the example projects as follows:
3.3
4
On the first button press (P6 [1]) on CY8CKIT-050, the Bootloadable1.cyacd file is bootloaded to the target
PSoC 3 device. On successful completion, the message "Bootloaded - Hello" is displayed on the CY8CKIT-050
LCD, and the message "Hello" is displayed on the CY8CKIT-030 LCD.
For subsequent bootloading operations, press the button (P6 [1]) on CY8CKIT-030. This makes the PSoC 3
device enter the bootloader and be ready to bootload a new application. The LED starts blinking.
On the next button press on CY8CKIT-050, the Bootloadable_2.cyacd file is bootloaded to the target PSoC 3
device. On successful bootloading the message "Bootloaded - Bye" is displayed on the CY8CKIT-050 LCD, and
the message "Bye" is displayed on the CY8CKIT-030 LCD.
Bootloading PSoC 4/ PSoC Analog Coprocessor
In the main.c file of the UART_Bootloader_Host project, change the TARGET_DEVICE macro to PSoC_4 or
PSoC_AC for PSoC 4 or PSoC Analog Coprocessor respectively. Rebuild the project and program it into the
PSoC 5LP device on the CY8CKIT-050.
After the first button press (P6 [1]) on CY8CKIT-050, the Bootloadable1.cyacd file is bootloaded to the target
PSoC 4/PSoC Analog Coprocessor. On successful completion, the green LED on the PSoC 4/PSoC Analog
Coprocessor kit starts to blink.
For subsequent bootloading operations, press the button Pin_Startbootloader. This makes the PSoC 4/PSoC
Analog Coprocessor enter the bootloader and be ready to bootload a new application. The red LED on the
PSoC 4/PSoC Analog Coprocessor kit starts to blink.
After the next button press on CY8CKIT-050, the Bootloadable2.cyacd file is bootloaded to the target
PSoC 4/PSoC Analog Coprocessor. On successful completion, the blue LED on the PSoC 4/PSoC Analog
Coprocessor kit starts to blink.
Summary
This application note explained how to bootload PSoC 3, PSoC 4, and PSoC 5LP using UART as the communication
interface. It also introduced the basic building blocks of a bootloader host and showed how to build an embedded
UART bootloader host.
Bootloaders are a standard method for doing field upgrades. With PSoC Creator doing the entire configuration for
you, it is easy to make a bootloader for PSoC.
For more advanced information, see the Appendix A – Memory sections and the PSoC 3, PSoC 4, and PSoC 5LP
Technical Reference Manuals.
5
Related Application Notes
Refer to the following application notes to learn more about bootloaders and flash programming.
AN73854 – PSoC 3, PSoC 4, and PSoC 5LP Introduction to Bootloaders
AN60317 – PSoC 3 and PSoC 5LP I2C Bootloader
AN73503 – USB HID Bootloader for PSoC 3 and PSoC 5LP
AN84401 – PSoC 3 and PSoC 5LP SPI Bootloader
AN86526 – PSoC 4 I2C Bootloader
AN73054 – PSoC 3 and PSoC 5LP Programming Using an External Microcontroller (HSSP)
AN61290 – PSoC 3 and PSoC 5LP Hardware Design Considerations
AN54181 – Getting Started with PSoC 3
www.cypress.com
Document No. 001-68272 Rev.*J
26
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
AN79953 – Getting Started with PSoC 4
AN77759 – Getting Started with PSoC 5LP
AN211293 – Getting Started with PSoC Analog Coprocessor
To learn more about the many other features and capabilities of PSoC, click here for a complete list of application
notes.
6
Related Projects
The projects attached to this application note are organized as shown in Table 7.
Table 7. Projects Associated with This Application Note
Design Project Name
Description
UART_Bootloader_Host
This is an embedded bootloader host project demonstrating a PSoC 5LP bootloading a PSoC 3,
PSoC 4, PSoC Analog Coprocessor or PSoC 5LP with UART as the communication channel.
UART_Bootloader
This bootloader project has UART as the communication channel. The bootloader blinks an LED.
Bootloadable1
For PSoC 3/PSoC 5LP, this project displays “Hello” on the character LCD of the target device.
For PSoC 4/PSoC Analog Coprocessor this project blinks the green LED on the target kit.
Bootloadable2
For PSoC 3/PSoC 5LP, this project displays “Bye” on the character LCD of the target device.
For PSoC 4/PSoC Analog Coprocessor this project blinks the blue LED on the target kit.
About the Authors
Name:
Anu M D
Title:
Sr. Applications Engineer
Background:
Anu M D is an applications engineer in Cypress Semiconductor
Programmable Systems Division focused on PSoC applications.
Name:
Siddalinga Reddy
Title:
Applications Engineer
Background:
Siddalinga Reddy is an applications engineer in Cypress Semiconductor
Programmable Systems Division focused on PSoC applications.
www.cypress.com
Document No. 001-68272 Rev.*J
27
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
A
Appendix A – Memory
Flash Memory Details
Flash memory provides storage for firmware, bulk data, ECC data, device configuration data, factory configuration
data, and user-defined flash protection data. Figure 32 shows the physical organization of the flash memory in
PSoC 3, PSoC 4, and PSoC 5LP.
PSoC flash is divided into blocks called arrays. Arrays are uniquely identified by array IDs. In PSoC 3 and PSoC 5LP,
each array has 256 rows of flash memory. Each row has 256 data bytes, plus, if enabled, 32 ECC (error correction
code) bytes. You can use the 32 ECC bytes to store configuration data instead of error correction data. So, an array
can have 64 KB or 72 KB for instruction and data storage.
In PSoC 4 and PSoC Analog Coprocessor, each array has 128 or 256 rows of flash memory. Each row has 128 data
bytes. So, an array can have 16 KB or 32 KB for instruction and data storage.
The number of flash arrays depends on the device and the part. PSoC 3 and PSoC 4100S have a maximum flash of
64 KB, so they have only one array, and the only valid array ID is 0. PSoC 4100/4200, PSoC Analog Coprocessor,
and PSoC 4000S devices have a maximum flash of 32 KB, so they have only one array, and the only valid array ID is
0. PSoC 5LP has a maximum of 256 KB of flash, or 4 flash arrays, with valid array IDs 0 to 3.
Flash memory is programmed one row at a time. It can be erased in 64 row sectors or the entire flash can be erased
at once. Rows are identified by a unique combination of the array ID and the row number.
Figure 32 also shows that the first X rows of flash are occupied by the bootloader. X is set such that there is enough
space for:
The vector table for the bootloader, starting at address 0 (PSoC 4 and PSoC 5LP only)
The bootloader project configuration bytes
The bootloader project code and data
The checksum for the bootloader portion of the flash
For PSoC 4 and PSoC 5LP, the vector table contains the initial stack pointer (SP) value for the bootloader project
and the address of the start of the bootloader project code. It also contains vectors for the exceptions and
interrupts to be used by the bootloader. In PSoC 3, the interrupt vectors are not in flash—they are supplied by
the interrupt controller.
The bootloadable project occupies the flash starting at the first 256-byte boundary after the bootloader (for
PSoC 4, it is the first 128-byte boundary). This region of the flash includes:
Vector table for the bootloadable project (PSoC 4 and PSoC 5LP only)
The bootloadable project code and data
The highest 64-byte block of flash is used as a common area for both projects. Parameters saved in this block
include:
The entry in flash of the bootloadable project (4-byte address)
The amount of flash occupied by the bootloadable project (number of flash rows)
The checksum for the bootloadable portion of flash (1 byte)
The size in bytes of the bootloadable portion of flash (4 bytes).
For more information on the location of metadata in the flash memory, see Metadata Layout in Flash.
www.cypress.com
Document No. 001-68272 Rev.*J
28
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Figure 32. Physical Organization of Flash Memory in PSoC
Byte0
• • • • • • • Byte L
Byte1
Byte0
• • • • • • • Byte L
Byte1
Byte0
• • • • • • • Byte L
Byte1
Row1
Row1
Row1
Row2
Row2
Row2
Row3
Row3
Row3
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Row4
Row5
Row6
Row7
Row8
•
•
•
•
•
• •• • • ••
Row N
Array0
Array1
Array M
L = 127 or 255 for PSoC 4 and PSoC Analog Coprocessor; 255 or 287 (if ECC is disabled) for PSoC 3 and PSoC 5LP
N = 32, 64, 128, 256 or 512 depending on part
M = 0, 1, 2 or 3 depending on part
= Bootloader Portion
= Bootloadable Portion
= Reserved for Metadata
Memory Usage in PSoC
There are two types of bootloader projects: standard and multi-application. The multi-application bootloader is useful
for designs that require a guarantee that there is always a valid application that can be run. But this guarantee comes
with a limitation that each application has only one-half of the flash available. Figure 33 shows the flash memory
usage for each type of PSoC Creator project.
Figure 33. Flash Memory Usage
Metadata
Metadata# 1
Metadata# 2
Bootloadable
Application
#2
Normal
Application
Address 0
www.cypress.com
Bootloadable
Application
Bootloadable
Application
#1
Bootloader
Application
Multi- Application
Bootloader
Document No. 001-68272 Rev.*J
29
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
M e t a d a t a L a yo u t i n F l a s h
The metadata section is the highest 64-byte block of flash and is used as a common area for both bootloader and
bootloadable projects, as Figure 33 shows. Various parameters, depending on the device used, are stored in this
block, as Table 8 shows. For the multi-application bootloader, there are two sets of metadata.
Table 8. Metadata Layout
Address
0x00
PSoC 3
App Checksum
PSoC 4 / PSoC 5LP
App Checksum
0x01
Reserved
0x02
Application Address
0x03
Application Address
0x04
0x05
NA
0x06
NA
Last Bootloader Row
0x07
0x08
Last Bootloader Row
0x09
0x0A
Application Length
0x0B
0x0C
Application Length
0x0D
NA
0x0E
NA
0x0F
NA
NA
0x10
Application Active
Application Active
0x11
Application Verified
Application Verified
0x12
Bootloader Application Version
Bootloader Application Version
Bootloadable Application ID
Bootloadable Application ID
0x13
0x14
0x15
Bootloadable Application Version Bootloadable Application Version
0x16
0x17
0x18
Bootloadable Application
Custom ID
0x19-0x3F NA
Bootloadable Application
Custom ID
NA
Note: For the multi-application bootloader, Last Bootloader Row for metadata (image 2) signifies the last row of
bootloadable 1 in the flash section and not the bootloader row.
Flash Protection
If the bootloader code is invalid, it makes the product unusable. So it is important to protect the bootloader portion of
the flash from accidental overwrites.
PSoC devices include a flexible flash protection system. This feature is designed to prevent duplication and reverse
engineering of proprietary code. But it can also be used to protect against inadvertent writes to the bootloader portion
of flash.
www.cypress.com
Document No. 001-68272 Rev.*J
30
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Four protection levels are provided for flash memory, as Table 9 shows. Each row of flash can be configured to have
a different protection level, which can be set using PSoC Creator (the Flash Security tab of the .cydwr file).
Table 9. Levels of Flash Protection
Protection Level
Unprotected
Factory upgrade
Allowed
External read and write
Internal read and write
External write
Internal read and write
Not Allowed
–
External read
Field upgrade
Internal read and write
External read and write
Full protection
Internal read
External read and write
Internal write
Note: PSoC 4 has only two levels of flash protection: Unprotected and full protection.
After the bootloader portion of the flash is configured to have a protection level of full protection, it cannot be changed
in the field. The only way to alter the protection level or the bootloader code is to completely erase the flash and
reprogram it using the JTAG/SWD interface.
An example for protecting bootloader flash follows.
Example of Flash Protection
When the bootloader project is built, the PSoC Creator Output window shows the amount of flash used. For
example, if the flash occupied by the UART_Bootloader project is 9250 bytes, then the output is (for PSoC 3 with
64 KB flash):
Flash used: 9250 of 65536 bytes (14.11 %).
The bootloader thus occupies 37 rows of flash (9250/256), that is, flash locations 0x0000 to 0x2300. Set the flash
protection level as full protection for these rows (in the Flash Security tab of the .cydwr file in PSoC Creator). The
protection level for the remaining rows can be unprotected (the default) or field upgrade, as Figure 34 shows. For
more information on how to use the flash protection dialog, see the PSoC Creator help article “Flash Security Editor.”
Figure 34. Flash Protection in PSoC Creator
N o n vo l a t i l e L a t c h S e t t i n g s
Nonvolatile latch (NVL) settings can be configured in a bootloader project or any other normal PSoC Creator project,
but not in the bootloadable projects. This is because the NVL settings are always loaded on device bootup. Upon
device bootup, the bootloader project executes first followed by the bootloadable code. Therefore, a bootloadable
project's NVL settings are those of the bootloader project with which it is associated.
Some of the PSoC Creator Design-Wide Resource (.cydwr) settings are programmed using user NVLs. You will get a
warning or error message if some of the .cydwr settings for the bootloadable project are different from the bootloader
project's settings.
www.cypress.com
Document No. 001-68272 Rev.*J
31
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
B
Appendix B – Project Files
Bootloadable Output Files
When any PSoC Creator project is built, an output file of type .hex is generated. This is the file that is downloaded to
the PSoC device while programming using the JTAG/SWD interface.
For a bootloadable project, the .hex file is a combined .hex file of both the bootloadable and the related bootloader
project. This file is typically used to download both projects via JTAG/SWD in a production environment.
* . c ya c d F i l e F o r m a t
When a bootloadable project is built, an additional file of type .cyacd (application code and data) is also generated.
This file contains a header followed by lines of flash data. Excluding the header, each line in the file represents an
entire row of flash data. The data is stored as ASCII data in big endian format. Therefore, while bootloading, the
contents of this file must be parsed (converted from ASCII to hex). Parsing is not required for programming a file of
type .hex.
The header of this file has the following format:
[4 bytes Silicon ID] [1 byte Silicon rev] [1 byte checksum type]
The flash lines have the following format:
[1 byte array ID] [2 bytes row number] [2 bytes data length] [N bytes of data] [1 byte
checksum]
The checksum type in the header indicates the type of checksum used in the packets sent between the bootloader
and the bootloader host during the bootloading operation. If this byte is 0, the checksum is a basic summation. If it is
1, the checksum is CRC-16.
www.cypress.com
Document No. 001-68272 Rev.*J
32
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
C
Appendix C – Host/Target Communications
Communication Flow
The Bootloader Function Flow section looked at the operation of a bootloader in PSoC, and Bootloading using
embedded host introduced the building blocks of a bootloader host. With this background, Figure 35 explains the flow
of communication between the host and the target during a bootloading operation. This gives the order in which
commands are issued to the target and responses are received. See Command and Status/Error Codes for a
complete list of bootload commands, their codes, and their expected responses.
Figure 35. Communication Flow During Bootloading
Host
Send ‘Enter Bootload’ command to start
the bootload operation
Check whether the Silicon ID and Silicon
Rev received are same as those contained
in the bootloadable file.
Send the ‘Get Flash Size’ command.
With these start and end row numbers, make
sure whether the rows to be programmed are
within the bootloadable area of the flash.
Then, split the row data into small chunks and
send them with the ‘Send Data’ command
Bootloader
Enter Bootlo
ad
Silicon ID
Command
ver
, Bootloader
, Silicon Rev
Get Flash Si
ze
Command
bers
d row num
Start and En
Send Data
Gets the Silicon ID, Silicon Rev
and bootloader version. Put this in
the response packet
Send the start and end row
numbers of the bootloadable flash
area.
Command
Saves the data in the receive Buffer
ilure
Success / Fa
Issue program row command along with
last chunk of row data
Send ‘Verify Row’ command to
verify the programmed row data.
Verify whether the received
checksum matches with the
expected row checksum.
Send verify checksum
command to verify the
entire application code
checksum
Issue ‘End Bootload
operation’ command
.
.
.
.
Program R
ow Comman
d
ilure
Success / Fa
Verify Row
R
Command
m
ow Checksu
Calculates Row checksum and
places it in the return packet buffer
.
.
.
.
Verify Applic
ation Check
Checksum
sum
Good / Bad
End Bootlo
ad
Command
NACK
www.cypress.com
Erase the specified flash row and
program it with the new row data.
Document No. 001-68272 Rev.*J
Verifies the entire application code
checksum against the checksum stored
in the flash
Give a software reset to jump to the
newly downloaded Application
project
33
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Protocol Packet Format
The bootloading operation involves the exchange of command and response packets between the host and the
target. These packets have specific formats, as Figure 36 shows.
Figure 36. Bootloading Packet Format
Command packets from the host
Start
0x01
Command
code
1 byte
1 byte
Checksum
Data length (N)
N bytes of data
LSB
LSB
MSB
2 bytes
N bytes
MSB
2 bytes
End
0x17
1 byte
Compute checksum for these bytes
Response packets from the target
Start
0x01
Status /
Error code
1 byte
1 byte
Checksum
Data length (N)
N bytes of data
LSB
LSB
MSB
2 bytes
N bytes
MSB
2 bytes
End
0x17
1 byte
Compute checksum for these bytes
Each packet includes checksum bytes. The checksum can be a basic summation (2's complement) or CRC-16,
depending on the bootloader project setting. When sending multibyte data such as DataLength and Checksum, the
least significant byte is sent first.
The bootloader responds to each command from the host with a response packet. The format of the response packet
is similar to the command packet except that there will be a status/error code instead of the command code. The
important commands and data bytes and the bootloader response packet data are given in Table 10.
Command and Status/Error Codes
As the previous section explains, the command and response packet structures are similar. The only difference is
that the second byte contains a command code or a status/error code.
Table 10 provides a list of commands and their expected responses. Table 11 provides a list of status and error
codes.
Table 10. Bootloading Commands
Command
Byte
0x31
Command
Verify checksum
Data Byte in the
Command Packet
N/A
Expected Response Data Bytes
1 byte: Non zero or '0'.
If it is a non-zero byte, then the application checksum matches and it is a
valid application.
If it is a zero byte, then the checksum is bad and the application is
invalid.
0x32
Get flash size
Flash array ID, 1 byte
First row number of the bootloadable flash, 2 bytes;
Last row number of the bootloadable flash, 2 bytes.
These numbers are for the requested array ID.
0x33
Get application status
(valid only for multiapplication bootloader)
www.cypress.com
Application number,
1 byte
Valid application number, 1 byte;
Active application number, 1 byte.
Checks whether the specified application is valid and it is active.
Document No. 001-68272 Rev.*J
34
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Command
Byte
0x34
0x35
Data Byte in the
Command Packet
Command
Erase row
Sync bootloader
Expected Response Data Bytes
Flash array ID, 1 byte;
N/A.
Flash row number,
2 bytes
Erases the contents of the specified flash row.
N/A
N/A.
Resets the bootloader to a clean state. Any data that was buffered in will
be thrown out. This command is needed only if the bootloader and the
host go out of sync with each other.
0x36
0x37
0x38
Set active application
(valid only for multiapplication bootloader)
Application number,
1 byte
N/A.
Send data
N bytes of data to be
sent
N/A.
N/A
Silicon ID, 4 bytes;
Enter bootloader
Sets the specified application as active.
The received data bytes will be buffered by the bootloader in anticipation
of the program row command.
Silicon Rev, 1 byte;
Bootloader version, 3 bytes.
All the commands are ignored until this command is received.
0x39
Program row
Flash array ID, 1 byte;
N/A.
Flash row number,
2 bytes;
After sending multiple bytes of data to the bootloader using the send
data command, the last chunk of data is sent along with this command.
N bytes of data to be
sent
0x3A
0x3B
Verify row
Exit bootloader
Flash array ID, 1 byte;
Row checksum, 1 byte.
Flash row number,
2 bytes
Returns the checksum of the specified row.
N/A
N/A.
This command is not acknowledged.
Table 11. Bootloading Status / Error Codes – Possible Responses to Commands
Status/
Error Code
Label
Description
0x00
CYRET_SUCCESS
The command was successfully received and executed.
0x02
BOOTLOADER_ERR_VERIFY
The verification of flash failed.
0x03
BOOTLOADER_ERR_LENGTH
The amount of data available is outside the expected range.
0x04
BOOTLOADER_ERR_DATA
The data is not in the proper form.
0x05
BOOTLOADER_ERR_CMD
The command is not recognized.
0x06
BOOTLOADER_ERR_DEVICE
The expected device does not match the detected device.
0x07
BOOTLOADER_ERR_VERSION
The bootloader version detected is not supported.
0x08
BOOTLOADER_ERR_CHECKSUM
The checksum does not match the expected value.
0x09
BOOTLOADER_ERR_ARRAY
The flash array ID is not valid.
0x0A
BOOTLOADER_ERR_ROW
The flash row number is not valid.
0x0C
BOOTLOADER_ERR_APP
The application is not valid and cannot be set as active.
0x0D
BOOTLOADER_ERR_ACTIVE
The application is currently marked as active.
0x0F
BOOTLOADER_ERR_UNK
An unknown error occurred.
www.cypress.com
Document No. 001-68272 Rev.*J
35
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
D
Appendix D – Host Core APIs
c yb t l d r _ a p i 2 . c / . h
This is a higher level API that handles the entire bootload operation. It has functions to open and close files. It
invokes the functions of the cybtldr_api.c /.h API for the bootload operations. This API can be used when building a
GUI-based bootloader host.
c yb t l d r _ p a r s e . c / . h
This module handles the parsing of the .cyacd file that contains the bootloadable image to send to the device. It also
has functions for setting up access to the file, reading the header, reading the row data, and closing the file.
c yb t l d r _ a p i . c / . h
This is a low-level API file for sending a single row of data at a time to the bootloader target. It has functions for
setting up the bootload operation, erasing a row, programming a row, verifying a row, and ending the bootload
operation. Table 12 describes in detail the functions of this API file.
Table 12. Functions of cybtldr_api.c /.h
Function
CyBtldr_StartBootloadOperation
CyBtldr_ProgramRow
CyBtldr_VerifyRow
CyBtldr_EraseRow
CyBtldr_EndBootloadOperation
Description
This function enables the communication interface and sends an enter bootloader command to
the target.
From the response packet received, it verifies the silicon ID, silicon revision of the target device,
and bootloader version.
This function first validates a row, that is, sends a get flash size command to the target for a
particular array ID of the target flash. In response, the target returns the start and end row
numbers of the bootloadable flash portion in that array. The host reads this response and checks
whether the specified row is in the bootloadable area of the flash.
If row validation is a success, the host breaks the row data into smaller pieces and sends them to
the target using send data commands.
Along with the last portion of row data, the function sends a program row command to the target.
This function first validates a row for a particular array ID and row number.
If row validation is successful, it sends a verify row command for the validated flash row. In
response, the target returns the checksum of the row.
The returned checksum is verified against the expected checksum value.
This function first validates a row for a particular array ID and row number.
If row validation is successful, it sends an erase row command for the validated flash row.
This function sends an exit bootload command and disables the communication interface.
c yb t l d r _ c o m m a n d . c / . h
This API handles the construction of command packets to the target and parsing the response packets received from
the target. The cybtldr_api.c /.h API invokes the functions of this API. For example, to send an enter bootload
command, CyBtldr_StartBootloadOperation() calls the CyBtldr_CreateEnterBootloadCmd() function
of this API. It also has a function for calculating the checksum of the command packets before sending to the target.
www.cypress.com
Document No. 001-68272 Rev.*J
36
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
E
Appendix E – Bootloader and Device Reset
As noted previously, transferring control from the bootloader to the bootloadable, or vice versa, is always done
through a device reset. This may be a consideration if your system must continue to perform mission-critical functions
while changing from one program to the other. This section details why reset must be used, as well as its implications
for device performance in your application.
W h y D e vi c e R e s e t I s N e e d e d
To understand why a device reset is needed, it is important to note that the bootloader and bootloadable projects in
your system are each completely self-contained PSoC Creator projects. Each project has its own device configuration
settings. Thus, when you change from one project to the other, you can completely redefine the hardware functions of
the PSoC device.
To implement complex custom functions, the device configuration can involve the setting of thousands of PSoC
registers. This is especially true for the PSoC digital and analog routing features. When you configure the registers
and routing, you must make sure that in addition to setting the bits for the new configuration, you reset the bits for the
old configuration. Otherwise, the new configuration may not work and may even damage the device.
So when changing between bootloader and bootloadable projects, you do a device software reset (SRES). This
causes all PSoC registers to be reset to their default states. Configuration for the new project can then begin. Note
that by assuming that all PSoC registers are initialized to their device reset default states, you can reduce both
configuration time and flash memory usage.
E f f e c t o n D e vi c e I / O P i n s
As described in application notes AN61290 – PSoC 3, PSoC 5LP Hardware Design Considerations and AN60616 –
PSoC Startup Process, during the reset and startup process, the PSoC I/O pins are in three distinct drive modes, as
Table 13 shows.
Table 13. PSoC I/O Pin Drive Modes During Device Reset
Duration (Typical)
Startup Event
Device reset (SRES) active
I/O Pin Drive Mode
Slow IMO
(12 MHz)
HI-Z Analog
Fast IMO
(48 MHz)
40 µs
While reset is active, the I/Os are held in
the HI-Z Analog mode.
Device reset removed
NVLs copied to I/O ports
Code starts executing
NVL setting:
HI-Z Analog,
Pull-up, or Pull-down
~12 ms
~4 ms
I/O ports and pins are configured
PSoC Creator
project configuration
NA
Code reaches main()
Code may change
I/O pin function.
NA
Comment
Duration depends on code execution
speed and configuration complexity.
Eight possible drive modes. See device
datasheet for details.
For details on NVL usage in PSoC, see a device datasheet. In your PSoC Creator project, the NVL settings are
established in two places:
The Reset tab for I/O ports, the individual Pin Component configurations
The System tab for all other NVLs, the Design-Wide Resources (DWR) window
The NVLs are updated when the device is programmed with your project. Note that a bootloadable project cannot set
NVLs; its DWR settings must match those in the associated bootloader project.
Final I/O drive modes are set by individual Pin Component configurations.
Figure 37 shows the timing diagrams for device startup and configuration. The example in the middle diagram is for
PSoC 3; similar processes exist for PSoC 4 and PSoC 5LP. For more information, see AN60616 – PSoC Startup
Process.
www.cypress.com
Document No. 001-68272 Rev.*J
37
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Figure 37. Device Startup Process Diagrams
Hardware Startup
Reset
Boot
Firmware Startup
CPU Specific
Source File
CPU halted
Main.c
...
CyFitter_cfg.c
Reset Released
...
Hardware Startup
...
No CPU
execution
Firmware Startup
KeilStart.A51
Configure
Debug,
Bootloader
Clear
IDATA
Clear SRAM
Main.c
CyFitter_cfg.c
...
DMAC
configuration
CyFitter_cfg.c
Register
initialization
DSI config,
Digital routing
Digital array,
ClockSetup()
Analog set
default
Effect on Other Functions
At device reset, universal digital block (UDB) registers are reset, so all UDB-based Components cease to exist and
their functions are stopped. The same holds true for analog Components based on the configurable SC/CT blocks
and universal analog block (UAB)–based components.
All fixed peripherals, both digital and analog, are reset to their idle states. This includes the DMA, DFB, timers
2
(TCPWM), I C, USB, CAN, ADCs, DACs, comparators, and opamps. All clocks are stopped except the internal main
oscillator (IMO).
All digital and analog routing control registers are reset. This causes all digital and analog switches to be opened,
breaking all connections in the device. This includes all connections to the I/Os except the NVLs.
All hardware-based functions are restored after configuration (see Figure 37). All firmware functions are restored
when the project’s main() function starts executing.
Example: Fan Control
This section examines how a bootloader and its associated device reset can be integrated into a typical application
such as fan control. PSoC Creator provides a Fan Controller Component, which encapsulates all the necessary
hardware blocks including PWMs, tachometer input capture timer, control registers, status registers, and a DMA
channel or interrupt. For more information, see the Fan Controller Application page.
The fan control application is in a bootloadable project. Optionally, the bootloader can be customized to keep the fan
running while bootloading.
www.cypress.com
Document No. 001-68272 Rev.*J
38
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
The fan can also be kept running while the device is reset during the transfer between the bootloader to the
bootloadable, as Table 14 shows.
Table 14. PSoC I/O Pin Drive Modes During Device Reset for Fan Controller
I/O Pin Drive Mode
Comment
HI-Z Analog
Optionally add an external pull-up or pull-down resistor to the PWM pin for a 100 percent duty cycle.
This may not be needed because the fan may keep spinning due to inertia.
NVL setting: HI-Z Analog,
Pull-up, or Pull-down
Optionally set the PWM Pin Component reset value to Pull-up or Pull-down, for a 100 percent duty
cycle. This may not be needed because the fan may keep spinning due to inertia.
PSoC Creator
project configuration
Set the PWM Pin Component drive mode and initial state for a 100 percent duty cycle.
The PWM Component becomes active but does not run.
Main() starts executing
When PWM_Start() is called, the PWM starts driving the PWM pin at the Component’s default duty
cycle. The firmware can read the tachometer data and start actively controlling the duty cycle.
www.cypress.com
Document No. 001-68272 Rev.*J
39
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
F
Appendix F – Miscellaneous Topics
Bootloader Versus HSSP
The bootloader allows your system firmware to be upgraded over a communication interface. But for a complete flash
upgrade, including the bootloader flash area, you must use the JTAG/SWD programmer (HSSP). The ISSP
specifications to create HSSP are given in AN62391 (PSoC 3).
What Happens When Power Fails During the Bootload Operation
If power fails during the bootload operation, then at the next reset the checksum of the bootloadable project does not
match the expected value (the bootloadable project's checksum stored in the last row of flash), and the bootloadable
project is considered to be invalid. Program execution remains in the bootloader until a successful bootload happens.
The bootloader host must send a start bootload command to restart the bootload operations.
Wh y You Need a Reset to Jump Between the Bootloader and Bootloadable Projects
PSoC is an enormously configurable device. The bootloader allows you to change on-chip hardware resources as
well as firmware. Due to its highly configurable architecture, hardware reconfiguration (placement, routing, functional)
is possible only from a reset state. Therefore the bootloader requires a reset to jump between the bootloader and
bootloadable projects. See Appendix E – Bootloader and Device Reset.
C o n ve r t i n g a N o r m a l A p p l i c a t i o n P r o j e c t t o a B o o t l o a d a b l e P r o j e c t
If you have already created a standard (normal) project and want to convert it to a bootloadable project, add a
Bootloadable Component to the TopDesign and add the bootloader project's .hex file as a dependency as Figure 14
on page 14 shows.
If a project is created as a normal project and then later changed to a bootloader project by adding a Bootloader
Component to the TopDesign, you need to insert the Bootloader_Start() function call in main.c for the
bootloader project to work as expected.
Note: For PSoC Creator 3.1, if you want to convert a standard normal) project to a bootloadable/bootloader project,
change the application type of the project to bootloadable/bootloader. To do so, right-click on the project, choose
Build > Code Generation > General, and change the application type in addition to adding the
Bootloadable/Bootloader Component to the TopDesign.
Debugging Bootloadable Project s
In the PSoC Creator bootloader system, the bootloader project executes first (at device reset) followed by the
bootloadable project. The jump from the bootloader to the bootloadable project is done through a software-controlled
device reset. This resets the debugger interface, which means that the bootloadable project cannot be run in
debugger mode.
To debug a bootloadable project, convert the application type to normal, debug it, and then convert it back to
bootloadable after debugging is done.
Another option is to program the bootloadable project .hex file into the device and then use the ”Attach to running
target” option for debugging while the bootloadable project is running. In this case, you can debug the bootloadable
project only from the point where debugger is attached to the device.
Multi-Application Bootloader
A multi-application bootloader (MABL) is used to put two bootloadable applications in flash simultaneously. The two
applications can be the same to ensure that there is always a valid application in the device's flash. Or the two
applications can be different so that they can be switched using the bootloader commands. This functionality comes
with the obvious limitation that each application has one-half of the available flash memory. Figure 33 on page 29
shows the placement of two applications in flash memory.
MABL can be implemented by following these steps, which are different from that of a standard bootloader
application:
1.
2.
Create a new MABL bootloader project. Select the Multi-App bootloader checkbox in the Bootloader
configuration window.
Note: For PSoC Creator 3.1, set the application type as Multi-App Bootloader.
Add two bootloadable projects to the workspace, for example, Project_A and Project_B. For each project, add a
dependency to the MABL project. Two .cyacd files are generated for each project: one for the lower part of flash
and one for the upper part of flash:
www.cypress.com
Document No. 001-68272 Rev.*J
40
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
3.
4.
5.
Project_A_1.cyacd and Project_A_2.cyacd
Project_A_1.cyacd and Project_A_2.cyacd
Project_B_1.cyacd and Project_B_2.cyacd
The .cyacd file with suffix 1 always occupies the first half of flash, and the .cyacd file with suffix 2 occupies the
second half. Thus, only certain combinations of .cyacd files can be used. These combinations are:
Project_B_1.cyacd and Project_B_2.cyacd
Project_A_1.cyacd and Project_B_2.cyacd
Project_B_1.cyacd and Project_A_2.cyacd
Program the device with the multi-application bootloader project and bootload the applications (.cyacd files)
sequentially in one of the above combinations.
To switch between applications, send the set active application command to the bootloader. You can create this
command using the API function CyBtldr_CreateSetActiveAppCmd(). Before sending the set active app
command, send the enter bootloader command, and after sending all the commands, send the exit bootloader
command. For more information on these APIs, refer to the CyBtldr_Command.c / .h files.
Memory Requirement for Bootloader
A typical UART bootloader project with all the optional commands included occupies approximately 7 KB of PSoC 3
flash with Keil 8051 compiler optimization level 5.
It occupies approximately 4.6 KB of PSoC 4 flash with the GCC compiler optimization set to “size.” And it occupies
approximately 5.4 KB of PSoC 5LP flash with the GCC compiler optimization set to "size." You can find the memory
used by the bootloader project in the output window when you build the project. The RAM memory used by the
bootloader project can be reused by the bootloadable project.
The memory usage of a bootloader project can be reduced a small amount by removing the optional commands
supported by the Bootloader Component, as Figure 38 shows.
Set the Device Configuration Mode to Compressed in the .cydwr System tab, as Figure 39 shows, to minimize
flash memory usage. Set Device Configuration Mode to DMA if startup time is more important than code size.
www.cypress.com
Document No. 001-68272 Rev.*J
41
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Figure 38. Unchecking Optional Commands in Bootloader Component
Figure 39. Device Configuration Mode
www.cypress.com
Document No. 001-68272 Rev.*J
42
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
G
Appendix G – C# Bootloader Host Application
The following software must be installed to develop a GUI for a bootloader host application:
Visual C# 2010 Express Edition and Visual C++ 2010 Express Edition.
Visual Studio 2010 Complete
Professional editions of the software can be purchased from Microsoft.
Read this MSDN page if you are targeting the DLL for a 64-bit Windows platform.
You should have some experience with Visual C# or Visual C++ to implement the GUI explained in this section.
The architecture of a PSoC 3 or PSoC 5LP bootloader host is shown in Figure 40.
Figure 40. Bootloader Host Architecture
Bootloader Host
User Interface
Cybootloaderutils
Read cyacd file contents
Erase, Program & Verify
Read response Packet
and decode it
Write
Read
Frame Command Packets and
send to PSoC
User Defined Code
I2C
USB
UART
SPI
The steps to create a C# bootloader host application are as follows:
1.
Create a DLL for the C functions (cybootloader Utils) provided with PSoC Creator.
2.
Create a C# GUI (user interface).
3.
Import essential bootloader functions from the DLL created in step 1.
4.
Provide a definition for the communication functions using a serial port (UART) communication interface.
5.
Complete the Windows Forms application.
The following sections explain each step in detail.
Step 1: Create bootloaderutils.dll
Create a DLL for the C functions provided with PSoC Creator. A copy of the DLL(BootLoad_Utils.dll) created using
Visual C++ 2010 Express Edition for various Windows platforms is attached with this application note
(BootLoad_Utils_dll).
www.cypress.com
Document No. 001-68272 Rev.*J
43
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
S t e p 2 : C r e a t e a C # W i n d o w s F o r m s Ap p l i c a t i o n
Create a C# Windows Forms application. Include the necessary Windows forms from the toolbox including serialPort.
Figure 41 shows a screen shot of the GUI that was created for the UART bootloader provided with this document.
Figure 41. UART Bootloader Host GUI
Step 3: Import Essential Bootloader Functions from the DLL Created in Step 1
The methods and objects provided by the BootLoad_Utils.dll are accessed from the C# application using the Platform
1
Invoke (pInvoke) utility provided by Windows. Platform Invoke is a service that enables managed code to call
2
unmanaged functions implemented in DLLs. It locates and invokes an exported function and marshals its arguments
(integers, strings, arrays, structures, and so on). To use exported DLL functions:
a.
Identify functions in the DLL that are directly invoked by the C# host application. This includes
CyBtldr_Program(), CyBtldr_Erase(), CyBtldr_Verify(), and CyBtldr_Abort().
b.
Create a class to hold DLL functions. Specify the names of the functions and the name of the DLL that contains
them in the class.
You can use an existing class, create an individual class for each unmanaged function, or create one class that
contains a set of unmanaged functions.
c.
Create prototypes in managed code.
In C#, you use the DllImport attribute to identify the DLL and function. Mark the method with the “static” and
“extern” modifiers. Note that these prototypes are simple and do not define the required DllImport attributes.
Refer to the source code for details.
[[DllImport("BootLoad_Utils.dll")]
int CyBtldr_Program(string file, ref CyBtldr_CommunicationsData comm,
CyBtldr_ProgressUpdate update);
[DllImport("BootLoad_Utils.dll")]
int CyBtldr_Erase(string file, ref CyBtldr_CommunicationsData comm,
CyBtldr_ProgressUpdate update);
1
Code that executes under the control of the .NET run time is called “managed code.”
2
Code that runs outside the run time is called “unmanaged code.”
www.cypress.com
Document No. 001-68272 Rev.*J
44
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
[DllImport("BootLoad_Utils.dll")]
int CyBtldr_Verify(string file, ref CyBtldr_CommunicationsData comm,
CyBtldr_ProgressUpdate update);
[DllImport("BootLoad_Utils.dll")]
int CyBtldr_Abort();
d.
Call the DLL function. You can invoke the method in your C# code as you invoke any other method.
S t e p 4 : P r o vi d e D e f i n i t i o n s f o r C o m m u n i c a t i o n F u n c t i o n s i n V i s u a l C #
A bootloader normally requires a particular communication protocol to send bootloader commands. The C files
provided by PSoC Creator provide C code that has functions to read the .cyacd file and frame the bootloader
packets. You only need to define the communication functions. Therefore, the following four unmanaged functions
that correspond to the UART communication must be managed in C# using the desired communications Component,
UART in this example.
OpenConnection()
CloseConnection()
ReadData()
WriteData()
To manage them, first define in C# the functions that perform OpenConnection, CloseConnection, ReadData, and
WriteData. Then use these functions as delegates to the functions OpenConnection(), CloseConnection(),
ReadData(), and WriteData() in BootLoad_Utils.dll.
For example, to implement the CloseConnection function, do the following:
a.
Indicate that a delegate will be used to implement the function:
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate int OpenConnection_UART();
b.
Define the function in C#:
public int OpenConnection()
{
/*Open communication channel*/
serialPort.Open();
}
These steps are required for all the delegated functions.
c.
The structure CyBtldr_CommunicationsData present in cybtldr.h must be declared in the C# program as well.
This is done inside a class. See the “Bootload_Utils” class in the C# code attached.
[StructLayout(LayoutKind.Sequential)]
public struct CyBtldr_CommunicationsData
{
public OpenConnection_UART OpenConnection;
public CloseConnection_UART CloseConnection;
public ReadData_UART ReadData;
public WriteData_UART WriteData;
public uint MaxTransferSize;
};
d.
Create an instance (comm_data) of the structure defined above:
Bootload_Utils.CyBtldr_CommunicationsData comm = new
Bootload_Utils.CyBtldr_CommunicationsData();
www.cypress.com
Document No. 001-68272 Rev.*J
45
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
e.
Delegate the members of the structure:
comm.OpenConnection = OpenConnection;
comm.CloseConnection = CloseConnection;
comm_data.ReadData = ReadData;
comm_data.WriteData = WriteData;
comm_data.MaxTransferSize = 64;
A brief explanation of what each function does for the UART bootloader follows.
public delegate int OpenConnection_UART();
For the UART bootloader, this function makes a connection to the selected COM port.
public delegate int CloseConnection_ UART ();
This function closes the COM port connection.
public delegate int ReadData_ UART (IntPtr buffer, int size);
This function waits for a timeout period for the data to be available in the input buffer. The data length is specified as
a size in the above API, and the pointer to the buffer is provided as IntPtr.
public delegate int WriteData_ UART(IntPtr buffer, int size);
This function writes data to the selected serial port. The data to be sent is preloaded in a buffer. The data length is
specified as a size in the above API, and the pointer to buffer is provided as IntPtr.
public delegate void CyBtldr_ProgressUpdate(byte arrayID, ushort rowNum);
This function provides a way to visualize the progress of the bootload operation. This function can be as simple as
updating a text box showing the percentage of progress, or it can be something that updates a progress bar.
The
definitions
for
the
communication
functions
BootLoad_Utils_NativeCode.cs in the attached C# project.
are
given
in
delegated_functions.cs
and
S t e p 5 : C o m p l e t e t h e W i n d o w s F o r m s Ap p l i c a t i o n
After the necessary APIs are imported and definitions are provided to the communications APIs described above,
these are used to implement various control operations. For example, pressing the Bootload button will initiate a
bootload operation. Therefore, on a button-click event, the function Bootload_Utils.CyBtldr_Program must be
invoked.
Check the UART bootloader host C# project to see the detailed implementation of the host.
www.cypress.com
Document No. 001-68272 Rev.*J
46
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
H
Appendix H – Kit Selection
Table 15. Kit Selection Based on Target Device
Target Device
www.cypress.com
Kit Name
User Guide
CY8C42xx
CY8CKIT-042 PSoC 4 Pioneer Kit
CY8CKIT-042
CY8C4Axx
CY8CKIT-048 PSoC Analog Coprocessor Pioneer Kit
CY8CKIT-048
CY8C40xx-S
CY8CKIT-041-40xx 4 S-Series Pioneer Kit
CY8CKIT-041
CY8C41xx-S
CY8CKIT-041-41xx 4 S-Series Pioneer Kit
CY8CKIT-041
CY8C3xxx
CY8CKIT-030 PSoC 3 Development Kit
CY8CKIT-030
CY8C5xxx
CY8CKIT-050 PSoC 5 Development Kit
CY8CKIT-050
Document No. 001-68272 Rev.*J
47
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Document History
®
Document Title: AN68272 - PSoC 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
Document Number: 001-68272
Revision
ECN
Orig. of
Change
Submission
Date
Description of Change
**
3208805
ANMD
03/27/2011
New application note.
*A
3471679
ANMD
12/22/2011
Revised AN with UART Bootloader Example
Updated template
*B
3623001
ANMD
05/22/2012
Updated figures 9 and 10, and tables 2 and 3. Minor text edits.
Added Appendix C.
Updated template and project files.
*C
3671377
ANMD
07/11/2012
Updated the Application Note project and document to PSoC Creator 2.1.
*D
3811899
PHAL
11/26/2012
Updated for PSoC 5LP
*E
3895950
PHAL
03/19/2013
Updated project files
Sunset review
*F
4078736
SRYP
07/31/2013
Updated to align with SPI and I2C bootloader application notes. Added a UART
bootloader host project. Added support for PSoC 4.
*G
4339454
RNJT
04/10/2014
Updated for PSoC Creator 3.0 SP1
*H
4435010
MKEA
07/17/2014
Added Appendix E – Bootloader and Device Reset
*I
4678368
VAIR
03/17/2015
Updated for PSoC Creator 3.1 CP1
Updated the screenshots of PC bootloader application
Sunset update
*J
5152725
AKSM
03/03/2016
Updated for PSoC Analog Coprocessor, PSoC 4000S/4100S
Updated images for PSoC Creator 3.3 SP2
Added Appendix H – Kit Selection
www.cypress.com
Document No. 001-68272 Rev.*J
48
PSoC® 3, PSoC 4, PSoC 5LP, and PSoC Analog Coprocessor UART Bootloader
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
®
®
ARM Cortex Microcontrollers
cypress.com/arm
cypress.com/psoc
Automotive
cypress.com/automotive
PSoC 1 | PSoC 3 | PSoC 4 | PSoC 5LP | PSoC Analog
Clocks & Buffers
cypress.com/clocks
Interface
cypress.com/interface
Lighting & Power Control
cypress.com/powerpsoc
Cypress Developer Community
Memory
cypress.com/memory
Community | Forums | Blogs | Video | Training
PSoC
cypress.com/psoc
Technical Support
Touch Sensing
cypress.com/touch
USB Controllers
cypress.com/usb
Wireless/RF
cypress.com/wireless
Coprocessor
cypress.com/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, 2011-2016. This document is the property of Cypress Semiconductor Corporation and its subsidiaries, including
Spansion LLC (“Cypress”). This document, including any software or firmware included or referenced in this document (“Software”), is owned by
Cypress under the intellectual property laws and treaties of the United States and other countries worldwide. Cypress reserves all rights under such
laws and treaties and does not, except as specifically stated in this paragraph, grant any license under its patents, copyrights, trademarks, or other
intellectual property rights. If the Software is not accompanied by a license agreement and you do not otherwise have a written agreement with
Cypress governing the use of the Software, then Cypress hereby grants you under its copyright rights in the Software, a personal, non-exclusive,
nontransferable license (without the right to sublicense) (a) for Software provided in source code form, to modify and reproduce the Software solely for
use with Cypress hardware products, only internally within your organization, and (b) to distribute the Software in binary code form externally to end
users (either directly or indirectly through resellers and distributors), solely for use on Cypress hardware product units. Cypress also grants you a
personal, non-exclusive, nontransferable, license (without the right to sublicense) under those claims of Cypress’s patents that are infringed by the
Software (as provided by Cypress, unmodified) to make, use, distribute, and import the Software solely to the minimum extent that is necessary for you
to exercise your rights under the copyright license granted in the previous sentence. Any other use, reproduction, modification, translation, or
compilation of the Software is prohibited.
CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS DOCUMENT OR ANY SOFTWARE,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Cypress reserves the right to make changes to this document without further notice. Cypress does not assume any liability arising out of the application
or use of any product or circuit described in this document. Any information provided in this document, including any sample design information or
programming code, is provided only for reference purposes. It is the responsibility of the user of this document to properly design, program, and test
the functionality and safety of any application made of this information and any resulting product. Cypress products are not designed, intended, or
authorized for use as critical components in systems designed or intended for the operation of weapons, weapons systems, nuclear installations, lifesupport devices or systems, other medical devices or systems (including resuscitation equipment and surgical implants), pollution control or hazardous
substances management, or other uses where the failure of the device or system could cause personal injury, death, or property damage (“Unintended
Uses”). A critical component is any component of a device or system whose failure to perform can be reasonably expected to cause the failure of the
device or system, or to affect its safety or effectiveness. Cypress is not liable, in whole or in part, and Company shall and hereby does release Cypress
from any claim, damage, or other liability arising from or related to all Unintended Uses of Cypress products. Company shall indemnify and hold
Cypress harmless from and against all claims, costs, damages, and other liabilities, including claims for personal injury or death, arising from or related
to any Unintended Uses of Cypress products.
Cypress, the Cypress logo, Spansion, the Spansion logo, and combinations thereof, PSoC, CapSense, EZ-USB, F-RAM, and Traveo are trademarks or
registered trademarks of Cypress in the United States and other countries. For a more complete list of Cypress trademarks, visit cypress.com. Other
names and brands may be claimed as property of their respective owners.
www.cypress.com
Document No. 001-68272 Rev.*J
49