This example demonstrates how to create a field upgradable project for PSOC™ 4 using the DFU middleware. The device firmware update (DFU) will occur over the I2C or UART interfaces. This includes downloading an application from a host device (PC/MCU) and installing it in PSOC™ 4 device flash. This document details the following:
- A high-level overview of the DFU process described in Design and implementation section.
- An example to explain the installation of DFU firmware inside the flash of the target device and upload an application code via the I2C or UART interface.
This example bundles two applications:
-
Bootloader app: Implements a DFU middleware library-based basic bootloader application run by the CPU. The bootloader handles the image download, verification, erase, and upgrade process. When the image is valid, the bootloader lets the CPU boot the application.
-
Blinky app: A tiny CPU-run application that continuously blinks an LED at a 5 Hz rate. This application transfers control to the bootloader when you press the user button. Here, the application project is a simple Blinky project, but you can change it according to your requirements.
Note: For CY8CKIT-040T, CY8CPROTO-040T, and CY8CPROTO-040T-MS only I2C is available as the DFU transport layer. For CY8CKIT-040T, switching between the application and the bootloader is controlled by an I2C command rather than a button press.
Provide feedback on this code example.
- ModusToolbox™ v3.4 or later (tested with v3.4)
- Board support package (BSP) minimum required version: 3.2.0
- Programming language: C
- Associated parts: PSOC™ 4100S, PSOC™ 4100S Max, PSOC™ 4100S Plus, PSOC™ 4000S, PSOC™ 4500S, and PSOC™ 4000T
- GNU Arm® Embedded Compiler v11.3.1 (
GCC_ARM) – Default value ofTOOLCHAIN - Arm® Compiler v6.16 (
ARM) - IAR C/C++ Compiler v9.50.2 (
IAR)
- PSOC™ 4100S Max Pioneer Kit (
CY8CKIT-041S-MAX) - Default value ofTARGET - PSOC™ 4100S Plus Prototyping Kit (
CY8CKIT-149) - PSOC™ 4000S CAPSENSE™ Prototyping Kit (
CY8CKIT-145-40XX) - PSOC™ 4500S Pioneer Kit (
CY8CKIT-045S) - PSOC™ 4000T CAPSENSE™ Evaluation Kit (
CY8CKIT-040T) - PSOC™ 4000T CAPSENSE™ Prototyping Kit (
CY8CPROTO-040T) - PSOC™ 4000T Multi-Sense Prototyping Kit (
CY8CPROTO-040T-MS)
I2C is the default transport. See the Operation section for instructions to change the transport option, TRANSPORT_OPT.
| TARGET | UART | I2C |
|---|---|---|
| CY8CKIT-041S-MAX | Yes | Yes |
| CY8CKIT-149 | Yes | Yes |
| CY8CKIT-145-40XX | Yes | Yes |
| CY8CKIT-045S | Yes | Yes |
| CY8CKIT-040T | No | Yes |
| CY8CPROTO-040T | No | Yes |
| CY8CPROTO-040T-MS | No | Yes |
This example uses the board's default configuration for the kits listed above, except for the CY8CPROTO-040T and CY8CPROTO-040T-MS. For the CY8CPROTO-040T and CY8CPROTO-040T-MS kits, make the following hardware changes:
- Change the SW2 switch towards I2C on the kit to use I2C functionality.
- Short J6.2 and J6.3 with the jumper shunt on the kit to use the user button.
See the kit user guide to ensure that the board is configured correctly.
Note: Some of the PSOC™ 4 kits are shipped with KitProg2 installed. ModusToolbox™ requires KitProg3. Before using this code example, make sure that the board is upgraded to KitProg3. The tool and instructions are available in the Firmware Loader GitHub repository. If you do not upgrade, you will see an error like "unable to find CMSIS-DAP device" or "KitProg firmware is out of date".
See the ModusToolbox™ tools package installation guide for information about installing and configuring the tools package.
This example requires no additional software or tools.
The ModusToolbox™ tools package provides the Project Creator as both a GUI tool and a command line tool.
Use Project Creator GUI
-
Open the Project Creator GUI tool.
There are several ways to do this, including launching it from the dashboard or from inside the Eclipse IDE. For more details, see the Project Creator user guide (locally available at {ModusToolbox™ install directory}/tools_{version}/project-creator/docs/project-creator.pdf).
-
On the Choose Board Support Package (BSP) page, select a kit supported by this code example. See Supported kits.
Note: To use this code example for a kit not listed here, you may need to update the source files. If the kit does not have the required resources, the application may not work.
-
On the Select Application page:
a. Select the Applications(s) Root Path and the Target IDE.
Note: Depending on how you open the Project Creator tool, these fields may be pre-selected for you.
b. Select this code example from the list by enabling its check box.
Note: You can narrow the list of displayed examples by typing in the filter box.
c. (Optional) Change the suggested New Application Name and New BSP Name.
d. Click Create to complete the application creation process.
Use Project Creator CLI
The 'project-creator-cli' tool can be used to create applications from a CLI terminal or from within batch files or shell scripts. This tool is available in the {ModusToolbox™ install directory}/tools_{version}/project-creator/ directory.
Use a CLI terminal to invoke the 'project-creator-cli' tool. On Windows, use the command-line 'modus-shell' program provided in the ModusToolbox™ installation instead of a standard Windows command-line application. This shell provides access to all ModusToolbox™ tools. You can access it by typing "modus-shell" in the search box in the Windows menu. In Linux and macOS, you can use any terminal application.
The following example clones the "mtb-example-psoc4-dfu-basic" application with the desired name "MyDFU" configured for the CY8CKIT-041S-MAX BSP into the specified working directory, C:/mtb_projects:
project-creator-cli --board-id CY8CKIT-041S-MAX --app-id mtb-example-psoc4-dfu-basic --user-app-name MyDFU --target-dir "C:/mtb_projects"
The 'project-creator-cli' tool has the following arguments:
| Argument | Description | Required/optional |
|---|---|---|
--board-id |
Defined in the field of the BSP manifest | Required |
--app-id |
Defined in the field of the CE manifest | Required |
--target-dir |
Specify the directory in which the application is to be created if you prefer not to use the default current working directory | Optional |
--user-app-name |
Specify the name of the application if you prefer to have a name other than the example's default name | Optional |
Note: The project-creator-cli tool uses the
git cloneandmake getlibscommands to fetch the repository and import the required libraries. For details, see the "Project creator tools" section of the ModusToolbox™ tools package user guide (locally available at {ModusToolbox™ install directory}/docs_{version}/mtb_user_guide.pdf).
After the project has been created, you can open it in your preferred development environment.
Eclipse IDE
If you opened the Project Creator tool from the included Eclipse IDE, the project will open in Eclipse automatically.
For more details, see the Eclipse IDE for ModusToolbox™ user guide (locally available at {ModusToolbox™ install directory}/docs_{version}/mt_ide_user_guide.pdf).
Visual Studio (VS) Code
Launch VS Code manually, and then open the generated {project-name}.code-workspace file located in the project directory.
For more details, see the Visual Studio Code for ModusToolbox™ user guide (locally available at {ModusToolbox™ install directory}/docs_{version}/mt_vscode_user_guide.pdf).
Keil µVision
Double-click the generated {project-name}.cprj file to launch the Keil µVision IDE.
For more details, see the Keil µVision for ModusToolbox™ user guide (locally available at {ModusToolbox™ install directory}/docs_{version}/mt_uvision_user_guide.pdf).
IAR Embedded Workbench
Open IAR Embedded Workbench manually, and create a new project. Then select the generated {project-name}.ipcf file located in the project directory.
For more details, see the IAR Embedded Workbench for ModusToolbox™ user guide (locally available at {ModusToolbox™ install directory}/docs_{version}/mt_iar_user_guide.pdf).
Command line
If you prefer to use the CLI, open the appropriate terminal, and navigate to the project directory. On Windows, use the command-line 'modus-shell' program; on Linux and macOS, you can use any terminal application. From there, you can run various make commands.
For more details, see the ModusToolbox™ tools package user guide (locally available at {ModusToolbox™ install directory}/docs_{version}/mtb_user_guide.pdf).
The project has the necessary settings by default. The Operation section describes how to test the example.
-
Connect the board to the PC using the provided USB cable through the KitProg3 USB connector.
-
Select mtb-example-psoc4-dfu-basic and click on Build Application as shown in Figure 1 to build a project to bundle the bootloader and the Blinky application together.
Figure 1. Building the application
Note: I2C is configured as the default DFU transport. To change the DFU transport, edit the common.mk makefile to set
TRANSPORT_OPT?=<transport>before building the project, as shown in Figure 2.Figure 2. TRANSPORT_OPT
-
Flash the bootloader:
Using Eclipse IDE
-
Select the bootloader_cm0p project (mtb-example-psoc4-dfu-basic.bootloader_cm0p) in the Project Explorer.
-
In the Quick Panel, scroll down to launches and click mtb-example-psoc4-dfu-basic.bootloader_cm0p Program (KitProg3_MiniProg4).
Figure 3. Flashing the bootloader
In other IDEs
Follow the instructions in your preferred IDE.
Using CLI
From the terminal, execute the
make programcommand to build and program the application using the default toolchain to the default target with default DFU transport. You can specify a target, toolchain and transport manually:make program TOOLCHAIN=<toolchain>Example:
make program TOOLCHAIN=GCC_ARMNote: The TOOLCHAIN variable is found in the common.mk makefile and is changed according to the user. However, the user has to provide the compiler path CY_COMPILER_PATH= in the makefiles of both the bootloader and the Blinky application.
-
-
After programming, the bootloader restarts, making the user LED blink at approximately 1 Hz.
-
Perform the device firmware upgrade using the DFU Host Tool:
a. Open the Device Firmware Upgrade Host Tool under the Tools section in the Quick Panel. Plug in the kit.
Figure 4. Device Firmware Upgrade Host Tool
b. Make a note of the path to the blinky_cm0p_crc.cyad2 file. You need it to configure the DFU Host Tool. By default, it will be generated in the mtb-example-psoc4-dfu-basic/blinky_cm0p/build/APP_CY8CKIT-041S-MAX/Debug directory. Paste this path in the File field of the DFU Host Tool.
Note: CY8CKIT-041S-MAX is the target kit in this example. If you are using a different kit, the name of the APP_xxx folder inside the build folder will change accordingly.
Figure 5. Locating the *.cyacd2 file
c. Select the appropriate port based on the transport (
TRANSPORT_OPT) configured in the common.mk makefile. I2C is the default transport configuration and the default parameters are:- I2C speed = 400 kHz
- I2C address = 12
If you are using UART as the transport, the default parameters are:
- Baud = 115200
- Data bits = 8
- Stop bits = 1
- Parity = None
Figure 6. Setting up the DFU Host Tool
d. Click Program and observe the image download progress status on the progress bar, and wait for the download to complete.
Figure 7. Uploading the application firmware
Note: See the DFU Host Tool documentation for further details on selecting a port and configuring it for communication based on the transport enabled in the bootloader.
After you download the application firmware, the device starts to boot in the blinky_cm0p project. Observe that the user LED blinks at 5 Hz.
-
Issue: DFU Host Tool actions failing for the PSOC™ 4000T WLCSP devices
For PSOC™ 4000T devices featuring a factory-programmed bootloader within the WLCSP package, it is essential to use a unique product ID as detailed in the WLCSP Bootloader Package section of the PSOC™ 4000T device datasheet. To ensure successful firmware flashing, a correct product ID must be assigned to the
__cy_product_idvariable for the GCC_ARM and IAR compilers within the linker scripts, or as the macro#define CY_PRODUCT_IDin the dfu_common.h file if you are using the ARM compiler. See the Memory layout section of this document for locating the linker scripts. -
Issue: DFU Host Tool actions failing after updating the bootloader
The device might be previously programmed with a valid application and on reset, the bootloader boots to its previous application. To solve this issue, erase the entire device flash by running the
make erasecommand in the terminal, as shown in Figure 8, and repeat from Step 3 of the previous section.Figure 8. Erasing the device chip
For kits other than CY8CKIT-040T
Dynamic switching between the bootloader and the application is triggered by the user button events. Press the user button to switch to the bootloader while the application is running. Similarly, press the user button to switch to the application while the bootloader is running. Note that the bootloader accepts the switching request only if there is a valid application in the memory.
For CY8CKIT-040T kit
Dynamic switching between the bootloader and the application is triggered by sending commands over I2C. To send the commands, a USB-to-I2C bridge and a I2C serial terminal software like Bridge Control Panel (BCP) is used. BCP is included with the installation of PSOC™ Programmer. To know how to write data using BCP, see the Help Topics section under the Help tab in the menu bar. The CY8CKIT-040T kit has an onboard KitProg which acts as the USB-to-I2C bridge and it is connected to the I2C bus of the PSOC™ 4000T device.
Note: Bridge Control Panel (BCP) is currently supported only on Windows.
To switch to the bootloader while the application is running, send the following 3 bytes to the I2C address 0x0C using BCP, as shown in Figure 9.
0x01 0xEA 0x17
Figure 9. BCP command 1
The command follows a basic packet structure that consists of Start Of Packet (SOP): 0x01, Command Byte (this is the actual command to trigger a flag in the main.c): 0xEA, and End Of Packet (EOP): 0x17.
Send the following 7 bytes to the I2C address 0x0C to switch from the bootloader to the application.
0x01 0x3B 0x00 0x00 0xC4 0xFF 0x17
Figure 10. BCP command 2
The Exit Bootloader command is an integrated command given by the DFU MW. The command details and the packet structure is found in the host command/response protocol section of the application note AN236282 - Device firmware update (DFU) middleware (MW) FOR ModusToolbox™.
Note that the bootloader accepts the switching request to jump to an application only if there is a valid application in the memory.
You can debug the example to step through the code.
In Eclipse IDE
Use the <Application Name> Debug (KitProg3_MiniProg4) configuration in the Quick Panel. For details, see the "Program and debug" section in the Eclipse IDE for ModusToolbox™ user guide.
In other IDEs
Follow the instructions in your preferred IDE.
This example demonstrates the basic device firmware upgrade (DFU) operations based on the DFU middleware library.
Figure 11. Bootloader flow diagram
This bootloader_cm0p project implements an immutable bootloader with support to upgrade the application firmware over I2C or UART interface.
The DFU Host Tool (typically running on the host PC) sends the application (<APPNAME>.cyacd2) to the device. The bootloader receives the application image in chunks and overwrites the existing application image (See Figure 11). If a DFU session is interrupted, the application firmware will not be in a usable state. However, the device can still run the bootloader and perform necessary actions to download and install the application in the subsequent DFU sessions.
Figure 12. DFU design overview
The project supports I2C or UART interfaces to communicate with the DFU host. The config directory in the mtb-example-psoc4-dfu-basic/bsps/TARGET_APP_CY8CKIT-041S-MAX/config includes all the necessary configurations to select the supported interfaces. These configurations can also be edited or reconfigured using the Device Configurator under the BSP Configurators in the Quick Panel.
Note: The Device Configurator is common for both the bootloader and the application; therefore, the resources are shared among them.
Figure 13. Device Configurator
See the following table for the default configuration details. You can change the default configurations according to the use case. However, ensure that the configuration of the DFU Host Tool matches with that of the project.
DFU transport configurations
By default, both I2C and UART modes are enabled and configured for transport. For more details on transport resources see Resources and settings.
Default I2C configuration
| Parameter | Default Setting | Description |
|---|---|---|
| Mode | Slave | Device acts as a slave |
| Address | 12 | 7-bit slave device address |
| Data rate | 400 kbps | DFU supports standard data rates from 50 kbps to 1 Mbps |
Figure 14. I2C configuration
Default UART configuration
| Parameter | Default Setting | Description |
|---|---|---|
| Com Mode | Standard | Standard, SmartCard, and IrDA are supported UART modes in SCB |
| Baud rate(bps) | 115200 | Supports standard baud rates from 19200 to 115200 |
| Bit order | LSB first | Standard frame |
| Data width | 8 bits | Standard frame |
| Parity | None | Standard frame |
| Stop bits | 1 bit | Standard frame |
Figure 15. UART configuration
The first 16 KB region of the flash is reserved for the bootloader followed by a 4 KB reserved region for future enhancements. Another 32 KB is allocated to the application firmware followed by the empty/reserved region. The size of this empty/reserved region depends on the size of the flash available on the selected target device. See the respective device datasheets for more details. The last 256 B region of the flash is reserved for bootloader metadata.
To change the memory layout or usage, update the respective target linker scripts. The files are found in the bsps folder.
For example: mtb-example-psoc4-dfu-basic/bsps/TARGET_APP_CY8CKIT-041S-MAX/COMPONENT_CM0p/TOOLCHAIN_GCC_ARM
Figure 16. Linker scripts
There are two linker scripts, one for each application in the corresponding toolchain directory. In the TOOLCHAIN_GCC_ARM directory, the dfu_cm0p_app0.ld linker script is for the bootloader and the dfu_cm0p_app1.ld linker script is for the Blinky application. The linker scripts can also be modified to define dedicated regions of the memory for each application.
The RAM is shared by the bootloader and Blinky application, with a common area used by both projects. The RAM regions must be aligned to the 1 KB boundary because they contain the interrupt vector table remapped at the start.
Figure 17. Flash layout of CY8CKIT-041S-MAX
The recommended method of transferring control from one application to another is through a device software reset. This enables each application to initialize device hardware blocks and signal routing from a known state. It is possible to freeze the state of I/O pins so they are maintained through a software reset. Defined portions of the SRAM are also maintained through a software reset. For more information, see the device-specific reference manual.
Table 1. Bootloader resources
| Resource | Alias/object | Purpose |
|---|---|---|
| SCB (I2C) (PDL) | DFU_I2C | I2C slave driver to communicate with the DFU host |
| SCB (UART)(PDL) | DFU_UART | UART driver to communicate with the DFU host |
| GPIO (PDL) | CYBSP_USER_LED | User LED |
| GPIO (PDL) | CYBSP_USER_BTN | User button |
Note: The Alias/Name must be DFU_<TRANSPORT_OPT> to support DFU communication API. Like DFU_I2C for I2C and DFU_UART for UART.
Table 2. Application resources
| Resource | Alias/object | Purpose |
|---|---|---|
| GPIO (PDL) | CYBSP_USER_LED | User LED |
| GPIO (PDL) | CYBSP_USER_BTN | User button |
| Resources | Links |
|---|---|
| Application notes | AN79953 – Getting started with PSOC™ 4 AN85951 – PSOC™ 4 and PSOC™ 6 MCU CAPSENSE™ design guide |
| Code examples | Using ModusToolbox™ on GitHub |
| Device documentation | PSOC™ 4 datasheets PSOC™ 4 technical reference manuals |
| Development kits | Select your kits from the Evaluation board finder. |
| Libraries on GitHub | mtb-pdl-cat2 – PSOC™ 4 Peripheral Driver Library (PDL) |
| Middleware on GitHub | Device Firmware Update (DFU) Middleware Library – Links to DFU SDK middleware |
| Tools | ModusToolbox™ – ModusToolbox™ software is a collection of easy-to-use libraries and tools enabling rapid development with Infineon MCUs for applications ranging from wireless and cloud-connected systems, edge AI/ML, embedded sense and control, to wired USB connectivity using PSOC™ Industrial/IoT MCUs, AIROC™ Wi-Fi and Bluetooth® connectivity devices, XMC™ Industrial MCUs, and EZ-USB™/EZ-PD™ wired connectivity controllers. ModusToolbox™ incorporates a comprehensive set of BSPs, HAL, libraries, configuration tools, and provides support for industry-standard IDEs to fast-track your embedded application development. |
Infineon provides a wealth of data at www.infineon.com to help you select the right device, and quickly and effectively integrate it into your design.
Document title: CE236395 – PSOC™ 4: Basic device firmware upgrade (DFU)
| Version | Description of change |
|---|---|
| 1.0.0 | New code example |
| 1.1.0 | Updated Linker files |
| 1.1.1 | Minor README update |
| 1.2.0 | Added support for CY8CPROTO-040T and updated to support ModusToolbox® v3.1 |
| 2.0.0 | README template update and bug fix in Makefile |
| 2.1.0 | Updated Flash memory allocation for CY8CKIT-040T to fix IAR compiler error |
| 2.2.0 | Added support for CY8CPROTO-040T-MS and updated to support ModusToolbox™ v3.4. |
All referenced product or service names and trademarks are the property of their respective owners.
The Bluetooth® word mark and logos are registered trademarks owned by Bluetooth SIG, Inc., and any use of such marks by Infineon is under license.
© Cypress Semiconductor Corporation, 2023-2025. This document is the property of Cypress Semiconductor Corporation, an Infineon Technologies company, and its affiliates ("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 a personal, non-exclusive, nontransferable license (without the right to sublicense) (1) under its copyright rights in the Software (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, and (2) 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 for use with Cypress hardware products. Any other use, reproduction, modification, translation, or compilation of the Software is prohibited.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS DOCUMENT OR ANY SOFTWARE OR ACCOMPANYING HARDWARE, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. No computing device can be absolutely secure. Therefore, despite security measures implemented in Cypress hardware or software products, Cypress shall have no liability arising out of any security breach, such as unauthorized access to or use of a Cypress product. CYPRESS DOES NOT REPRESENT, WARRANT, OR GUARANTEE THAT CYPRESS PRODUCTS, OR SYSTEMS CREATED USING CYPRESS PRODUCTS, WILL BE FREE FROM CORRUPTION, ATTACK, VIRUSES, INTERFERENCE, HACKING, DATA LOSS OR THEFT, OR OTHER SECURITY INTRUSION (collectively, "Security Breach"). Cypress disclaims any liability relating to any Security Breach, and you shall and hereby do release Cypress from any claim, damage, or other liability arising from any Security Breach. In addition, the products described in these materials may contain design defects or errors known as errata which may cause the product to deviate from published specifications. To the extent permitted by applicable law, 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. "High-Risk Device" means any device or system whose failure could cause personal injury, death, or property damage. Examples of High-Risk Devices are weapons, nuclear installations, surgical implants, and other medical devices. "Critical Component" means any component of a High-Risk Device whose failure to perform can be reasonably expected to cause, directly or indirectly, the failure of the High-Risk Device, or to affect its safety or effectiveness. Cypress is not liable, in whole or in part, and you shall and hereby do release Cypress from any claim, damage, or other liability arising from any use of a Cypress product as a Critical Component in a High-Risk Device. You shall indemnify and hold Cypress, including its affiliates, and its directors, officers, employees, agents, distributors, and assigns harmless from and against all claims, costs, damages, and expenses, arising out of any claim, including claims for product liability, personal injury or death, or property damage arising from any use of a Cypress product as a Critical Component in a High-Risk Device. Cypress products are not intended or authorized for use as a Critical Component in any High-Risk Device except to the limited extent that (i) Cypress's published data sheet for the product explicitly states Cypress has qualified the product for use in a specific High-Risk Device, or (ii) Cypress has given you advance written authorization to use the product as a Critical Component in the specific High-Risk Device and you have signed a separate indemnification agreement.
Cypress, the Cypress logo, and combinations thereof, ModusToolbox, PSOC, CAPSENSE, EZ-USB, F-RAM, and TRAVEO are trademarks or registered trademarks of Cypress or a subsidiary of Cypress in the United States or in other countries. For a more complete list of Cypress trademarks, visit www.infineon.com. Other names and brands may be claimed as property of their respective owners.