# ModusToolbox™ user guide¶

## About this document¶

2.4.0

### Scope and purpose¶

This guide provides information and instructions for using the ModusToolbox™ tools provided by the version

2.4.0 installer and the make build system. This document contains the following chapters:

• Chapter 1 describes ModusToolbox™ software from a high level.

• Chapter 2 provides instructions for getting started using the ModusToolbox™ tools.

• Chapter 3 includes an overview of all the software considered a part of ModusToolbox™ tools.

• Chapter 4 describes the ModusToolbox™ build system.

• Chapter 5 covers different aspects of the ModusToolbox™ board support packages (BSPs).

• Chapter 6 explains the ModusToolbox™ manifest files and how to use them with BSPs, libraries, and code examples.

• Chapter 7 provides instructions for using a ModusToolbox™ application with various integrated development environments (IDEs).

### Intended audience¶

This document helps application developers understand how to use all the tools included with ModusToolbox™ software.

### Document conventions¶

Convention

Explanation

Bold

Emphasizes heading levels, column headings, menus and sub-menus

Italics

Denotes file names and paths.

Courier New

Denotes APIs, functions, interrupt handlers, events, data types, error handlers, file/folder names, directories, command line inputs, code snippets

File > New

Indicates that a cascading sub-menu opens when you select a menu item

Abbreviations and definitions

The following define the abbreviations and terms used in this document that you may not be familiar with:

• BSP – board support package

• PDL – peripheral driver library

• HAL – hardware abstraction layer

• WHD – Wi-Fi host driver

• WCM – Wi-Fi connection manager

## 1 Introduction¶

### 1.1 what-is-modustoolbox-software¶

ModusToolbox™ software is a modern, extensible development environment supporting a wide range of Infineon microcontroller devices. It provides a flexible set of tools and a diverse, high-quality collection of application-focused software. These include configuration tools, low-level drivers, libraries, and operating system support, most of which are compatible with Linux-, macOS-, and Windows-hosted environments. ModusToolbox™ software does not include proprietary tools or custom build environments. This means you choose your compiler, your IDE, your RTOS, and your ecosystem without compromising usability or access to our industry-leading CAPSENSE™, AIROC™ Wi-Fi and Bluetooth®, security, and low-power features.

#### 1.1.1 Supported devices¶

ModusToolbox™ software supports development on the following Arm Cortex-M devices.

• PSoC™ 4 Configurable Microcontroller

• XMC™ Industrial Microcontroller

• PMG1 USB-C Power Delivery Microcontroller

• PSoC™ 6 MCU

• PSoC™ 64 “Secure Boot” MCU

• AIROC™ Wi-Fi and Bluetooth® chips

#### 1.1.2 Development tools¶

The ModusToolbox™ tools package provides you with all the desktop products needed to build sophisticated, low-power embedded, connected and IoT applications. The tools enable you to create new applications (Project Creator), add or update software components (Library Manager), set up peripherals and middleware (Configurators), program and debug (OpenOCD and Device Firmware Updater), and compile (GNU C compiler).

Infineon Technologies understands that you want to pick and choose the tools and products to use, merge them into your own flows, and develop applications in ways we cannot predict. That’s why ModusToolbox™ software is not a monolithic, proprietary software tool that dictates the use of any particular IDE. For convenience, the tools package installation includes the Eclipse IDE for ModusToolbox™. However, we fully support the following IDEs and their corresponding compiler technology, so you are free to develop the way you wish:

• Microsoft Visual Studio Code (VS Code)

• IAR Embedded Workbench (EW-ARM)

• Arm Microcontroller Developers Kit (µVision 5)

For detailed instructions developing ModusToolbox™ applications with third-party IDEs, see the Exporting to supported IDEs chapter in this guide.

#### 1.1.2 Run-time software¶

ModusToolbox™ tools also include an extensive collection of GitHub-hosted repos comprising Code Examples, BSPs, plus middleware and applications support. We release run-time software on a quarterly “train model” schedule, and access to new or updated libraries typically does not require you to update your ModusToolbox™ installation.

New projects start with one of our many Code examples that showcase everything from simple peripheral demonstrations to complete application solutions. Every Infineon kit is backed by a comprehensive BSP implementation that simplifies the software interface to the board, enables applications to be re-targeted to new hardware in no time, and can be easily extended to support your custom hardware without the usual porting and integration hassle.

The extensive middleware collection includes an ever-growing set of sensor interfaces, display support, and connectivity-focused libraries. The ModusToolbox™ installer also conveniently bundles packages of all the necessary run-time components you need to leverage the following key Infineon technology focus areas:

• CAPSENSE™ technology

• AnyCloud (AIROC™ Wi-Fi and Bluetooth® applications)

• Machine Learning

• Device Security (PSoC™ 64 “Secure Boot” MCU)

### 1.2 Partner ecosystems¶

To support Infineon microcontrollers in our partner ecosystems, some tools and middleware from ModusToolbox™ software are also integrated into Mbed OS and Amazon FreeRTOS. Refer to mbed.com and aws.amazon.com/freertos, respectively, to learn more about developing applications in those environments.

## 2 Getting started¶

ModusToolbox™ software provides various graphical user interface (GUI) and command-line interface (CLI) tools to create and configure applications the way you want. You can use the included Eclipse-based IDE, which provides an integrated flow with all the ModusToolbox™ tools. Or, you can use other IDEs or no IDE at all. Plus, you can switch between GUI and CLI tools in various ways to fit your design flow. Regardless of what tools you use, the basic flow for working with ModusToolbox™ applications includes these tasks:

This chapter helps you get started using various ModusToolbox™ tools. It covers these tasks, showing both the GUI and CLI options available.

### 2.1 Install and configure software¶

The ModusToolbox™ tools package is located on our website: https://www.cypress.com/products/ModusToolbox-software-environment

You can install the software on Windows®, Linux, and macOS. Refer to the ModusToolbox™ installation guide for specific instructions.

#### 2.1.1 GUI set-up instructions¶

In general, the IDE and other GUI-based tools included as part of the ModusToolbox™ tools package work out of the box without any changes required. Simply launch the executable for the applicable GUI tool. On Windows, most tools are on the Start menu.

#### 2.1.2 CLI set-up instructions¶

Before using the CLI tools, ensure that the environment is set up correctly.

• For Windows, the tools package provides a command-line utility called “modus-shell.” You can run this from the Start menu, or navigate to the following installation directory and run Cygwin.bat :

<install_path>/ModusToolbox/tools_2.4/modus-shell/

• For macOS, the installer will detect if you have the necessary tools. If not, it will prompt you to install them using the appropriate Apple system tools.

• For Linux, there is only a ZIP file, and you are expected to understand how to set up various tools for your chosen operating system.

To check your installation, open the appropriate command-line shell.

• Type which make. For most environments, it should return /usr/bin/make.

• Type which git. For most environments, it should return /usr/bin/git.

If these commands return the appropriate paths, then you can begin using the CLI. Otherwise, install and configure the GNU make and git packages as appropriate for your environment.

### 2.2 Get help¶

In addition to this user guide, we provide documentation for both GUI and CLI tools. GUI tool documentation is generally available from the tool’s Help menu. CLI documentation is available using the tool’s -h option.

#### 2.2.1 GUI Documentation¶

##### 2.2.1.1 Eclipse IDE¶

If you choose to use the integrated Eclipse IDE, see the Eclipse IDE for ModusToolbox™ quick start guide for getting started information, and the Eclipse IDE for ModusToolbox™ user guide for additional details.

##### 2.2.1.1 Configurator and tool guides¶

Each GUI-based configurator and tool includes a user guide that describes different elements of the tool, as well as how to use them. See Installation resources for descriptions of these tools and links to the documentation.

#### 2.2.2. Command line documentation¶

##### 2.2.2.1 make help¶

The ModusToolbox™ build system includes a make help target that provides help documentation. In order to use the help, you must first run the make getlibs command in an application directory (see make getlibs for details). From the appropriate shell in an application directory, type in the following to print the available make targets and variables to the console:

make help

To view verbose documentation for any of these targets or variables, specify them using the CY_HELP variable. For example:

make help CY_HELP=TOOLCHAIN

Note

This help documentation is part of the base library, and it may also contain additional information specific to a BSP.*

To see the various make targets and variables available, see the Available make targets and Available make variables sections in the ModusToolbox™ build system chapter.

##### 2.2.2.2 CLI tools¶

Various CLI tools include a -h option that prints help information to the screen about that tool. For example, running this command prints output for the Project Creator CLI tool to the screen:

./project-creator-cli -h

### 2.3 Create applications¶

ModusToolbox™ software provides the Project Creator as both a GUI tool and a command line tool to easily create one or more ModusToolbox™ applications. See Project Creator tools. If you prefer not to use the Project Creator tools, you can use the git clone command directly. See git clone. However, be sure to also run the make getlibs command in the application directory. See make getlibs. You can then use those application files in your preferred IDE or from the command line.

Note

Beginning with the ModusToolbox™ 2.2 release, we structure applications with the MTB flow. Using this flow, applications can share BSPs and libraries. If needed, different applications can use different versions of the same BSP/library. Sharing resources reduces the number of files on your computer and speeds up subsequent application creation time. Shared BSPs, libraries, and versions are located in the mtb_shared directory adjacent to your application directories. You can easily switch a shared BSP or library to become local to a specific application, or back to being shared. Refer to the* Library Manager User Guidefor details.

Looking ahead, most example applications will use the MTB flow. However, there are still various applications that use the previous flow, now called the LIB flow, and these applications generally do not share BSPs and libraries. ModusToolbox™ software fully supports both flows, but it only supports one flow or the other for a given application.

For simplicity, this guide focuses on the MTB flow. For details about how the LIB flow works, refer to the

ModusToolbox™ 2.1 revision of this guide, located here:

https://www.cypress.com/file/504361/download

#### 2.3.1 Project Creator tools¶

The Project Creator tools run the git clone command for the selected code example(s) and create a directory at the specified location with the specified name. The tools also updates the application Makefile and create a

<BSP-NAME>.mtb file based on the specified BSP. That .mtb file contains the following:

• The URL of the git repo where the BSP contents can be found.

• The commit (version of the library) to checkout / make visible / use in the application.

• A variable of where to put the BSP on disk (shared or local to the application).

The Project Creator tools then run the make getlibs command to read the BSP manifest file, resolve dependencies, and import libraries. Depending on the settings in the application and manifest, the tools put everything into application directories and an mtb_shared directory. In most cases, BSPs are placed local to the application, while libraries are shared.

##### 2.3.1.1 Project Creator GUI¶

The Project Creator GUI tool provides a series of screens to select a BSP and code example, specify the application name and location, as well as select target IDE. The tool displays various messages during the application creation process. Refer to the Project Creator user guide for more details. Open the Project Creator GUI tool from the Windows Start menu or by running the executable file installed in the following directory by default:

*<install_path>/ModusToolbox/tools_2.4/project-creator/*


The option to select a target IDE generates necessary files for that IDE. If you launch the Project Creator GUI tool from the included Eclipse-based IDE, it seamlessly exports the created application for use in the Eclipse IDE.

##### 2.3.1.2 project-creator-cli¶

You can also use the project-creator-cli tool to create applications from a command-line prompt or from within batch files or shell scripts. The tool is located in the same directory as the GUI version (<install_path>/ModusToolbox/tools_2.4/project-creator/). To see all the options available, run the tool with the -h option:

* ./project-creator-cli -h*

The following example shows running the tool with various options.

* ./project-creator-cli \\*

--board-id CY8CKIT-062-WIFI-BT \\

--app-id mtb-example-psoc6-hello-world \\

--user-app-name MyLED \\

--target-dir "C:/my_projects"


In this example, the project-creator-cli tool runs the git clone command to clone the Hello World code example from our GitHub server (https://github.com/Infineon). It also updates the TARGET variable in the Makefile to match the selected BSP (–board-id), creates a .mtb file for it, and runs the make getlibs command to obtain the necessary library files. This example also includes options to specify the name (– user-app-name) and location (–target-dir) where the application will be stored.

#### 2.3.2 git clone¶

The Project Creator GUI and command line tools run the git clone command as part of the process of creating an application. You can run the git clone command directly from the command line. Open the appropriate shell and type in the following command (replace the <URL> with the appropriate URL of the repo you wish to clone):

git clone <URL>

The clone operation creates an application directory in your current location. Navigate to that directory (cd

<DIR>), and find the application Makefile. This is the top-level file that determines the application build flow. To see the various make targets and variables that you can edit in this file, refer to the Available make targets and Available make variables sections in the ModusToolbox™ build system chapter.

Note

When using the git clone command directly, be sure to also run the make getlibs command in the application directory. See* make getlibs.Also, each code example has a default BSP included in the application’s deps subdirectory. If you want to use a different BSP, you must create a .mtb file for it in the deps subdirectory before running make getlibs, and you must change the TARGET variable in the Makefile.

#### 2.3.3 Typical application contents¶

After an application has been created for the MTB flow and all the libraries have been imported, it contains the following basic files and directories as shown in the following image:

##### 2.3.3.1 Application directory¶

This directory contains the application source code, Makefile, readme file, as well as the deps and libs subdirectories. If you create multiple applications, there will be multiple application directories contained in the same directory structure or workspace.

• Source code – This is one or more files for your application’s code. Often it is named main.c, but it could be more than one file and the files could have almost any name. Source code files can also be grouped into a subdirectory anywhere in the application’s directory (for example, sources/main.c).

• Makefile – This is the application’s Makefile, which contains configuration information. See the

ModusToolbox™ build system chapter for more details.

• deps subdirectory – By default, this subdirectory contains .mtb files using the MTB flow.

• Initially, this subdirectory contains only the <BSP>.mtb file for the BSP you selected for the application.

• It could also contain <library>.mtb files for libraries that were included directly or for which you changed using the Library Manager. See the Update BSPs and libraries section for details.

• This subdirectory also contains the locking_commit.log file, which keeps track of the version for each dependent library.

• libs subdirectory – This subdirectory may contain different types of files generated by the make getlibs process, based on how the application is created. You can regenerate these files using the make getlibs command, so you do not need to add these files to source control.

• This subdirectory contains BSPs that are local to the application (that is, not shared).

• If you update your application to specify any libraries to be local as well, then this directory will also contain source code for those libraries.

• By default, this subdirectory contains the <library>.mtb files for libraries included as indirect dependencies of the BSP or other libraries.

• This directory also contains the mtb.mk file that lists the shared libraries and their versions.

##### 2.3.3.2 mtb_shared directory¶

Typically, a new application also includes a mtb_shared directory adjacent to the application directory, and this is where the shared BSP and libraries are cloned by default. This location can be modified by specifying the CY_GETLIBS_PATH variable. Duplicate libraries are checked to see if they point to the same commit and if so, only one copy is kept in the mtb_shared directory. You can regenerate these files using the make getlibs command, so you do not need to add these files to source control.

### 2.4 Update BSPs and libraries¶

As part of the application creation process, the Project Creator tools update the application with BSP and library information. If you use the git clone command, you will have to update BSP and library information as a separate process using the Library Manager tool or from the command line using the make getlibs command. You can also update the BSP and library information at any point in the development cycle using these tools.

#### 2.4.1 Library Manager¶

As needed, use the Library Manager tool to add or remove BSPs and libraries for your application, as well as change versions for BSPs and libraries. You can also change the active BSP. Open the Library Manager tool from the application directory using the make modlibs command.

The Library Manager opens for the selected application and its available BSPs and libraries.

Note

There are several ways to open the Library Manager; refer to the* Library Manager user guidefor more details.

The Library Manager tool provides a field to select the Active BSP. It also includes two tabs to view and update BSPs and Libraries.

Make changes to BSPs and libraries as follows:

• Select one or more check boxes under Name for the items to add. Deselect check boxes for items to remove.

• Specify whether items are shared (placed in the mtb_shared directory) or local to the application (placed in the libs subdirectory) by selecting/deselecting the Shared check box.

• Choose an appropriate Version for each item.

Click Update to proceed with the changes. The status box displays various messages while applying changes, and then indicates if the application was updated or not.

#### 2.4.2 make getlibs¶

In the MTB flow, the Project Creator tools and the Library Manager tool run the make getlibs command to search for all .mtb files in the application directory. Each .mtb file contains information used when the application is created. These files are parsed, and the libraries are cloned into a directory named mtb_shared.

If you ran the git clone command manually and did not use the Library Manager, then your application will contain only default .mtb files. You must run the make getlibs command to parse those files and clone the libraries. However, if you want to use to a different BSP than the default provided by the code example, you must first edit the Makefile to update the TARGET variable to match the desired BSP. Then, you must add a .mtb file in the /deps subdirectory that includes a URL to the desired BSP location.

Note

ModusToolbox™ applications that use the LIB flow contain.lib files in the deps subdirectory. If an application uses the MTB flow, then all .lib files are ignored.*

When you are ready to update your application, open the appropriate shell (see CLI set-up instructions) and run the following command in the application directory:

make getlibs

Note

The make getlibs operation may take a long time to execute as it depends on your internet speed and the size of the libraries that it is cloning. To improve subsequent library cloning operations, a cache directory named “.modustoolbox/cache” exists in the $HOME (Linux, macOS) and$USERPROFILE (Windows) directories.*

### 2.5 Configure settings for devices, peripherals, and libraries¶

Depending on your application, you may want to update and generate some of the configuration code. While it is possible to write configuration code from scratch, the effort to do so is considerable. ModusToolbox™ software provides applications called configurators that make it easier to configure a hardware block or a middleware library. For example, instead of having to search through all the documentation to configure a serial communication block as a UART with a desired configuration, open the appropriate configurator to set the baud rate, parity, stop bits, etc.

Before configuring your device, you must decide how your application will interact with the hardware; see Application layers. That decision affects how you configure settings for devices, peripherals, and libraries.

Note

Before you make changes to settings in configurators, you should first copy the configuration information to the application and* override the BSP configurationorcreate a custom BSP. See details about BSPs in the Board support packageschapter. If you make changes to a standard BSP library, it will cause the repo to become dirty. Additionally, if the BSP is in the shared asset repository, changes will impact all applications that use the shared BSP. If this happens, refer toKBA231252.

The configurators can be run as GUIs to easily update various parameters and settings. Most can also be run as command line tools to regenerate code as part of a script. For more information about configurators, see the Configurators section. Also, each configurator provides a separate document, available from the configurator’s Help menu, that provides information about how to use the specific configurator.

#### 2.5.1 Configurator GUI tools¶

You can open various configurator GUIs using the appropriate make command from the application directory. For example, to open the Device Configurator, run:

make config

This opens the Device Configurator with the current application’s design.modus configuration file.

As described under Tools make targets, you can use the make open command with appropriate arguments to open any configurator. For example, to open the CAPSENSE™ Configurator, run:

make open CY_OPEN_TYPE=capsense-configurator

You can also use the Eclipse IDE provided with ModusToolbox™ software to open configurators. For example, if you select the “Device Configurator” link in the IDE Quick Panel, the tool opens with the application’s design.modus file. Refer to the Eclipse IDE for ModusToolbox™ user guide for more details about the Eclipse IDE.

One other way to open BSP configurators (such as CAPSENSE™ and SegLCD Configurators) is by using a link from inside the Device Configurator. However, this does not apply to Library configurators (such as Bluetooth® and USB Configurators).

#### 2.5.2 Configurator CLI tools¶

Most of the configurators can also be run from the command line. The primary use case is to re-generate source code based on the latest configuration settings. This would often be part of an overall build script for the entire application. The command-line configurator cannot change configuration settings. For information about command line options, run the configurator using the -h option.

### 2.6 Write application code¶

As in any embedded development application using any set of tools, you are responsible for the design and implementation of the firmware. This includes not just low-level configuration and power mode transitions, but all the unique functionality of your product. When writing application code, you must decide how the application will interact with the hardware; see Application layers.

ModusToolbox™ software is designed to enable your workflow. It includes an integrated Eclipse IDE, as well as support for Visual Studio (VS) Code, IAR Embedded Workbench, and Keil µVision (see Exporting to supported IDEs). You can also use a text editor and command line tools. Taken together, the multiple resources available to you in ModusToolbox™ software: BSPs, configurators, driver libraries, and middleware, help you focus on your specific application.

### 2.7 Build, program, and debug¶

After the application has been created, you can export it to an IDE of your choice for building, programming, and debugging. You can also use command line tools. The ModusToolbox™ build system infrastructure provides several make variables to control the build. So, whether you are using an IDE or command line tools, you edit the Makefile variables as appropriate. See the ModusToolbox™ build system chapter for detailed documentation on the build system infrastructure.

Variable

Description

TARGET

Specifies the target board/kit. For example, CY8CPROTO-062-4343W

APPNAME

Specifies the name of the application

TOOLCHAIN

Specifies the build tools used to build the application

CONFIG

Specifies the configuration option for the build [Debug Release]

VERBOSE

Specifies whether the build is silent or verbose [true false]

ModusToolbox™ software is tested with various versions of the TOOLCHAIN values listed in the following table. Refer to the release information for each product for specific versions of the toolchains.

TOOLCHAIN

Tools

Host OS

GCC_ARM

GNU Arm Embedded Compiler

Mac OS, Windows, Linux

ARM

Arm compiler

Windows, Linux

IAR

Embedded Workbench

Windows

In the Makefile, set the TOOLCHAIN variable to the build tools of your choice. For example:

TOOLCHAIN=GCC_ARM. There are also variables you can use to pass compiler and linker flags to the toolchain.

ModusToolbox™ software installs the GNU Arm toolchain and uses it by default. If you wish to use another toolchain, you must provide it and specify the path to the tools. For example, CY_COMPILER_PATH=<yourpath>. If this path is blank, the build infrastructure looks in the ModusToolbox/ install directory.

#### 2.7.1 Use Eclipse IDE¶

When using the provided Eclipse IDE, click the Build Application link in the Quick Panel for the selected application.

Because the IDE relies on the build infrastructure, it does not use the standard Eclipse GUI to modify build settings. It uses the build options specified in the Makefile. This design ensures that the behavior of the application, its options, and the make process are consistent regardless of the development environment and workflow.

If you do change settings in the Makefile (for example, TARGET or CONFIG), you must re-create the launch configs using the link in the Quick Panel; refer to the Eclipse IDE for ModusToolbox™ user guide for more details.

#### 2.7.2 Export to another IDE¶

If you prefer to use an IDE other than Eclipse, you can select the appropriate IDE from the Target IDE pull-down menu when creating an application using the Project Creator tool. You can also use the appropriate make <ide> command. For example, to export to Visual Studio Code, run:

make vscode

For more details about using other IDEs, see the Exporting to supported IDEs chapter. When working with a different IDE, you must manage the build using the features and capabilities of that IDE.

#### 2.7.3 Use command line¶

##### 2.7.3.1 make build¶

When all the libraries are available (after executing make getlibs), the application is ready to build. From the appropriate shell, type the following:

make build

This instructs the build system to find and gather the source files in the application and initiate the build process. In order to improve the build speed, you may parallelize it by giving it a -j flag (optionally specifying the number of processes to run). For example:

make build -j16

##### 2.7.3.2 make program¶

Connect the target board to the machine and type the following in the shell:

make program

This performs an application build and then programs the application artifact (usually an .elf or .hex file) to the board using the recipe-specific programming routine (usually OpenOCD). You may also skip the build step by using qprogram instead of program. This will program the existing build artifact.

##### 2.7.3.3 make debug/qdebug/attach¶

The following commands can be used to debug the application, as follows:

• make debug – Build and program the board. Then launch the GDB server.

• make qdebug – Skip the build and program steps. Just launch the GDB server.

• make attach – Starts a GDB client and attaches the debugger to the running target.

## 3 ModusToolbox™ software overview¶

This chapter provides an overview of the ModusToolbox™ software environment. As described in the Introduction chapter, ModusToolbox™ software provides support for many types of devices and environments. From a practical standpoint, ModusToolbox™ software is delivered in various ways, such as Installation resources, Code examples, and BSPs & libraries, and you only use the resources you need. When you create applications, you use these resources and interact with the hardware through the Hardware Abstraction Layer (HAL) and/or the Peripheral Driver Library (PDL).

The following block diagram shows a very high-level view of what is available as part of ModusToolbox™ software. This is not a comprehensive list. It merely conveys the idea that there are multiple resources available to you.

Another important aspect of the ModusToolbox™ software is that each product is versioned. This ensures that each product can be updated on an ongoing basis, but it also allows you to lock down specific versions of the tools for your specific environment. See Product versioning for more details.

### 3.1 Application layers¶

There are four distinct ways for an application to interact with the hardware as shown in the following diagram:

• HAL structures: Application code uses the HAL, which interacts with the PDL through structures created by the HAL

• Configurator structures: Application code uses PDL through structures created by a Configurator.

• Manual structures: Application code uses PDL through structures created manually.

• Register read/write: Application code uses direct register read and writes.

Note

A single application may use different methods for different peripherals.*

#### 3.1.1 HAL¶

Using the HAL is more portable than the other methods. It is the preferred method for simpler functions and those that don’t have extremely strict flash size limitations. It is a high-level interface to the hardware that allows many common functions to be done quickly and easily. This allows the same code to be used even if there are changes to pin assignments, different devices in the same family, or even to a different family that may have radically different underlying architectures.

The advantages include:

• Easy hardware changes. Just change the pin assignment in the BSP and the code remains the same. For example, if LED1 changes from P0_0 to P0_1, the code remains the same as long as the code uses the name LED1 with the HAL. The only change is to the BSP pin assignment.

• Easy migration to a different device as product requirements change.

• Ability to use the same code base across multiple projects and generations, even if underlying architectures are different.

The disadvantages include:

• The HAL may not support every feature that the hardware has. It supports the most common features but not all of them to maintain simplicity.

• The HAL will use additional flash space. The additional flash depends on which HAL APIs are used.

#### 3.1.2 PDL¶

The PDL is a lower-level interface to the hardware (but still simpler than direct register access) that supports all hardware features. Usually the PDL goes hand-in-hand with Configurators, which will be described next. Since the PDL interacts with the hardware at a lower level it is less portable between devices, especially those with different architectures.

The advantages/disadvantages are the exact opposite of those for the HAL. The main advantage is that it provides access to every hardware feature.

#### 3.1.3 Configurators¶

Configurators make initial setup easier for hardware accessed using the PDL. The Configurators create structures that the PDL requires without you needing to know the exact composition of each structure, and they create the proper structure based on your selections. See Configurators for more information.

If you use the HAL for a peripheral, it will create the necessary structures for you, so you should NOT use a Configurator to set them up. The HAL structure is accessible, and once you initialize a peripheral with the HAL you can view and even modify that structure (that is, a HAL object). Keep in mind that the underlying structures are hardware-specific, so you may be sacrificing portability if you modify the structure manually. There are a few exceptions. For example, it is reasonable to configure system items (such as clocks) and use them with the HAL.

### 3.2 Installation resources¶

The ModusToolbox™ tools package installer provides required and optional core resources for any application. This section provides an overview of the available resources:

The installer does not include code examples or libraries, but it does provide the tools to access them.

#### 3.2.1 Directory structure¶

Refer to the ModusToolbox™ installation guide for information about installing ModusToolbox™. Once it is installed, the various ModusToolbox™ top-level directories are organized as follows:

Note

This image shows ModusToolbox™ versions 2.3 and 2.4 installed. Your installation may only include ModusToolbox™ version 2.4. Refer to the* Product versioningsection for more details.

The ModusToolbox directory contains the following subdirectories for version 2.4:

• docs_2.4 – This is the top-level documentation directory. It contains various top-level documents and an html file with links to documents provided as part of ModusToolbox™ software. See Documentation for more information.

• ide_2.4

• eclipse (or ModusToolbox.app on macOS) – This contains the optional Eclipse IDE for ModusToolbox™. It includes the ModusToolbox™ perspective, application management, code authoring and editing, build tools, and debug capabilities. The IDE supports the C and C++ programming languages. It includes the GCC Arm build tools. It supports debugging via OpenOCD or J-Link. For more details, refer to the Eclipse IDE for ModusToolbox™ software user guide.

• tools_2.4: This contains all the various tools and scripts installed as part of ModusToolbox™. See Tools for more information.

#### 3.2.2 Documentation¶

The docs directory contains top-level documents and an HTML document with links to all the documents included in the installation and on the web.

##### 3.2.2.1 Release notes¶

For the 2.4 release, the release notes document is for all of the ModusToolbox™ software included in the installation.

##### 3.2.2.2 Top-level documents¶

This folder contains the Eclipse IDE documentation, the ModusToolbox™ software installation guide, and this user guide. These guides cover different aspects of using the IDE and various ModusToolbox™ tools.

##### 3.2.2.3 Document index page¶

The doc_landing.html file provides links to all the documents included in the installation and on the web. This file is also available from the IDE Help menu.

#### 3.2.3 IDE support¶

The ModusToolbox™ installer includes an optional Eclipse IDE that is a full-featured, cross-platform IDE. The ModusToolbox™ build system also provides support for Visual Studio (VS) Code, IAR Embedded Workbench, and Keil µVision. See the Exporting to supported IDEs chapter for more details.

#### 3.2.4 Tools¶

The tools_2.4 directory includes the following configurators, tools, and utilities:

##### 3.2.4.1 Configurators¶

Each configurator is a cross-platform tool that allows you to set configuration options for the corresponding hardware peripheral or library. When you save a configuration, the tool generates the C code and/or a configuration file used to initialize the hardware or library with the desired configuration.

Configurators are independent of each other, but they can be used together to provide flexible configuration options. They can be used stand alone, in conjunction with other configurators, or as part of a complete application. All of them are installed during the ModusToolbox™ installation. Each configurator provides a separate guide, available from the configurator’s Help menu.

Configurators perform tasks such as:

• Displaying a user interface for editing parameters

• Setting up connections such as pins and clocks for a peripheral

• Generating code to configure middleware

Note

Some configurators may not be useful for your application.*

Configurators store configuration data in an XML data file that provides the desired configuration. Each configurator has a “command line” mode that can regenerate source based on the XML data file. Configurators are divided into two types: BSP Configurators and Library Configurators.

The following diagram shows a high-level view of the configurators that could be used in a typical application.

BSP configurators

BSP configurators configure the hardware on a specific device. This can be a board provided by us, a partner, or a board that you create that is specific to your application. Some of these configurators interact with the design.modus file to store and communicate configuration settings between different configurators. Code generated by a BSP Configurator is stored in a directory named GeneratedSource, which is in the same directory as the design.modus file. This is generally located in the BSP for a given target board. Some of the BSP configurators include:

• Device Configurator: Set up the system (platform) functions such as pins, interrupts, clocks, and DMA, as well as the basic peripherals, including UART, Timer, etc. Refer to the Device Configurator guide for more details.

• CAPSENSE™ Configurator: Configure CAPSENSE™ hardware, and generate the required firmware. This includes tasks such as mapping pins to sensors and how the sensors are scanned. Refer to the CAPSENSE™ Configurator guide for more details.

There is also a CAPSENSE™ Tuner to adjust performance and sensitivity of CAPSENSE™ widgets on the board connected to your computer. Refer to the CAPSENSE™ Tuner guide for more details.

• QSPI Configurator: Configure external memory and generate the required firmware. This includes defining and configuring what external memories are being communicated with. Refer to the QSPI Configurator guide for more details.

• Smart I/O Configurator: Configure the Smart I/O. This includes Chip, I/O, Data Unit, and LUT signals between port pins and the HSIOM. Refer to the Smart I/O Configurator guide for more details.

• SegLCD Configurator: Configure LCD displays. This configuration defines a matrix Seg LCD connection and allows you to setup the connections and easily write to the display. Refer to the SegLCD Configurator guide for more details.

Library configurators

Library configurators support configuring application middleware. Library configurators do not read nor depend on the design.modus file. They generally create data structures to be consumed by software libraries. These data structures are specific to the software library and independent of the hardware. Configuration data is stored in a configurator-specific XML file (for example, *.cybt, *.cyusbdev, etc.). Any source code generated by the configurator is stored in a GeneratedSource directory in the same directory as the XML file. The Library configurators include:

• Bluetooth® Configurator: Configure Bluetooth® settings. These include options for specifying what services and profiles to use and what features to offer by creating SDP and/or GATT databases in generated code. This configurator supports both PSoC™ MCU and AIROC™ Bluetooth® applications. Refer to the Bluetooth® configurator guide for more details.

• USB Configurator: Configure USB settings and generate the required firmware. This includes options for defining the Device Descriptor and Settings. Refer to the USB Configurator guide for more details.

• LIN Configurator: Configure various LIN settings, such as frames and signals, and generate the required firmware. Refer to the LIN Configurator guide for more details.

• Machine Learning (ML) Configurator: Accept a pretrained ML model and generate an embedded model (as a library), which can be used along with your application code for a target device. Refer to the ML configurator guide for more details.

• EZ-PD™ Configurator: Configure the features and parameters of the PDStack middleware for PMG1 family of devices. Refer to the EZ-PD™ Configurator guide for more details.

• “Secure Policy” Configurator: Open, create, and change policy configuration files for PSoC™ 64 “Secure Boot” MCU devices. Refer to the “Secure Policy” Configurator guide for more details.

##### 3.2.4.2 Other tools¶

ModusToolbox™ software includes other tools that provide support for application creation, device firmware updates, and so on. All tools are installed by the ModusToolbox™ tools package installer. With rare exception each tool has a user guide located in the docs directory beside the tool itself. Most user guides are also available online.

Other tools

Details

Documentation

project-creator

Create a new application. This tool is a stand-alone tool, available as a GUI and a command-line tool (CLI).

user guide

library-manager

Add, remove, or update libraries and BSP used in an application; edits the Makefile

user guide

cymcuelftool

Merges CM0+ and CM4 application images into a single executable. Typically launched from a post-build script. This tool is not used by most applications.

user guide is in the tool’s docs directory

dfuh-tool

Use the Device Firmware Update Host tool to communicate with a PSoC™ 6 MCU that has already been programmed with an application that includes device firmware update capability. Provided as a GUI and a command-line tool.

Depending on the ecosystem you target, there may be other over-the-air firmware update tools available.

user guide

##### 3.2.4.3 Utilities¶

ModusToolbox™ software includes some additional utilities that are often necessary for application development. In general, you use these utilities transparently.

Utility

Description

GCC

Supported toolchain included with the ModusToolbox™ installer.

GDB

The GNU Project Debugger is installed as part of GCC.

JRE

Java Runtime Environment; required by the Eclipse IDE integration layer.

##### 3.2.4.4 Build system infrastructure¶

The build system infrastructure is the fundamental resource in ModusToolbox™ software. It serves three primary purposes:

• create an application, update and clone dependencies

• create an executable

• provide debug capabilities

A Makefile defines everything required for your application, including:

• target hardware (board/BSP to use)

• source code and libraries to use for the application

• ModusToolbox™ tools version, as well as compiler toolchain to use

• compiler/assembler/linker flags to control the build

• assorted variables to define things like file and directory locations

The build system automatically discovers all .c, .h, .cpp, .s, .a, .o files in the application directory and subdirectories, and uses them in the application. The Makefile can also discover files outside the application directory. You can add another directory using the CY_SHAREDLIB_PATH variable. You can also explicitly list files in the SOURCES and INCLUDES make variables.

Each library used in the application is identified by a .mtb file. This file contains the URL to a git repository, a commit tag, and a variable for where to put the library on disk. For example, a capsense.mtb file might contain the following line:

#### 4.9.5 Path make variables¶

These variables are used to specify various paths.

Variable

Description

CY_APP_PATH

Relative path to the top-level of application. For example, ./ Settings this path to other than ./ allows the auto-discovery mechanism to search from a root directory location that is higher than the application directory. For example, CY_APP_PATH=../../ allows auto-discovery of files from a location that is two directories above the location of ./Makefile.

CY_BASELIB_PATH

Relative path to the base library. For example, ./libs/recipe-make-cat1a This directory must be relative to CY_APP_PATH. It defines the location of the library containing the recipe Makefiles, where the expected directory structure is <CY_BASELIB_PATH>/make. All applications must set the location of the recipe base library. For applications using .mtb files, the BSP’s TARGET.mk file sets this variable and therefore the application does not need to.

CY_BASELIB_CORE_PATH

Relative path to the core base library. For example, ./libs/core-make This directory must be relative to CY_APP_PATH. It defines the location of the library containing the core make files, where the expected directory structure is <CY_BASELIB_CORE_PATH>/make. All applications must set the location of the core base library. For applications using .mtb files, the BSP’s TARGET.mk file sets this variable and therefore the application does not need to. This variable is not applicable for applications using the combined base library (such as recipe-make-cat1a).

CY_EXTAPP_PATH

Relative path to an external application directory. For example, ../external This directory must be relative to CY_APP_PATH. Setting this path allows incorporating files external to CY_APP_PATH. For example, CY_EXTAPP_PATH=../external lets auto-discovery pull in the contents of ../external directory into the build.

Note

This variable is only supported in CLI. Use the shared_libs mechanism and* DEPENDENT_LIB_PATHS for tools and IDE support.

Note

The same functionality exists in the SEARCH variable. Using the SEARCH* variable is preferred over CY_EXTAPP_PATH.

CY_COMPILER_PATH

Absolute path to the compiler (default: GCC_ARM in CY_TOOLS_DIR).

Setting this path allows custom toolchains to be used instead of the defaults. This should be the location of the /bin directory containing the compiler, assembler, and linker. For example:

CY_COMPILER_PATH=”C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.4/arm/”

CY_TOOLS_DIR

Absolute path to the tools root directory. Example Usage: make build

CY_TO OLS_DIR=”path/to/ModusToolbox/tools_x.y”

Applications must specify the tools_<version> directory location, which contains the root Makefile and the necessary tools and scripts to build an application. Application Makefiles are configured to automatically search in the standard locations for various platforms. If the tools are not located in the standard location, you may explicitly set this.

CY_BUILD_LOCATION

Absolute path to the build output directory (default: pwd/build).

The build output directory is structured as /TARGET/CONFIG/. Setting this variable allows the build artifacts to be located in the directory pointed to by this variable.

CY_PYTHON_PATH

Specifies the path to a specific Python executable. Example Usage:

CY_PYTHON_PAT H=”path/to/python/executable/python.exe”

For make targets that depend on Python, the build system looks for Python 3 in the user’s PATH and uses that to invoke python. If you have a version of Python installed in a non-default location and do not have a path set for it, you can set CY_PYTHON_PATH as a System Variable. In Windows, you must use forward slashes in the path to the Python executable.

CY_DEVICESUPPORT_PATH

Relative path to the devicesupport.xml file.

This path specifies the location of the devicesupport.xml file for the Device Configurator. It is used when the configurator needs to be run in a multi-application scenario.

TOOLCHAIN_MK_PATH

Specifies the location of a custom TOOLCHAIN.mk file.

Defining this path allows the build system to use a custom TOOLCHAIN.mk file pointed to by this variable.

Note

The make variables in this file should match the variables used in existing TOOLCHAIN.mk files

#### 4.9.6 Miscellaneous make variables¶

These are miscellaneous variables used for various make targets.

Variable

Description

CY_IGNORE

Adds to the directory and file ignore list. For example, ./file1.c ./inc1

Example Usage: make build CY_IGNORE=”path/to/file/ignore_file”

Directories and files listed in this va riable are ignored in auto-discovery. This mechanism works in combination with any existing*.cyignore* files in the application.

CY_SKIP_RECIPE

Skip including the recipe Makefiles.

Setting this to [true/1] allows the application to not include any recipe Makefiles and only include the start.mk file from the tools install.

CY_SKIP_CDB

Skip creating .cdb files.

Constant Database (CDB) files are gener ated during the build process. Setting this to [true] allows the build process to skip the .cdb files creation.

CY_EXTRA_INCLUDES

Specifies additional Makefiles to add to the build.

Example Usage: make build CY_EXTRA_INCLUDES=”./custom1.mk” This variable provides a way of injecting additional make files into the core make files. It can be used when including the make file before or after start.mk in the application Makefile is not possible.

CY_LIBS_SEARCH_DEPTH

Directory search depth for .mtb files (default: 5).

Example Usage: make getlibs CY_LIBS_SEARCH_DEPTH=7

This variable controls how deep the search mechanism in getlibs looks for .mtb files.

Note

Deeper searches take longer to process.*

CY_UTILS_SEARCH_DEPTH

Directory search depth for .cyignore and TARGET.mk files (default: 5). Example Usage: make getlibs CY_UTILS_SEARCH_DEPTH=7

This variable controls how deep the search mechanism looks for .cyignore and TARGET.mk files. Min=1, Max=9.

Note

Deeper searches take longer to process.*

CY_IDE_PRJNAME

Name of the Eclipse IDE application.

Example Usage: make eclipse CY_IDE_PRJNAME=”AppV1”

This variable can be used to define the file and target application name when generating Eclipse launch configurations in the eclipse target.

CY_CONFIG_FILE_EXT

Specifies the configurator file extension. For example, *.modus.

Example Usage: make get_app_info CY_CONFIG_FILE_EXT=”modus cybt cyusbdev”

This variable accepts a space-separated list of configurator file extensions to search when running the get_app_info target.

CY_SUPPORTED_TOOL_TYPES

Defines the supported tools for a BSP.

Example Usage (bsp.mk): CY_SUPPORTED_TOOL_TYPES+=seglcd- configurator

BSPs can define the supported tools that can be launched using the open target. The supported tool types are bt-configurator, capsense-configurator, capsense-tuner, device-configurator, dfuh-tool, library- manager, project-creator, qspi-configurator, seglcd- configurator, smartio-configurator, and usbdev-configurator. The BSP can make adjustments to the default recipe if needed.

## 5 Board support packages¶

### 5.1 Overview¶

A BSP provides a standard interface to a board’s features and capabilities. The API is consistent across our kits. Other software (such as middleware or an application) can use the BSP to configure and control the hardware. BSPs do the following:

• initialize device resources, such as clocks and power supplies to set up the device to run firmware.

• contain default linker scripts and startup code that you can customize for your board.

• contain the hardware configuration (structures and macros) for both device peripherals and board peripherals.

• provide abstraction to the board by providing common aliases or names to refer to the board peripherals, such as buttons and LEDs.

• include the libraries for the default capabilities on the board. For example, the BSP for a kit with CAPSENSE™ capabilities includes the CAPSENSE™ library.

### 5.2 What’s in a BSP¶

This section presents an overview of the key resources that are part of a BSP. Using the MTB flow, applications can share BSPs and libraries. BSPs that are local to the application are located in the libs subdirectory, while shared BSPs are located in the mtb_shared directory adjacent to the application directory. For more details about library management, refer to the Library Manager user guide.

The following shows a typical PSoC™ 6 BSP located in the application’s libs subdirectory on the left. It also shows a shared BSP located in the mtb_shared directory on the right.

Note

For BTSDK v2.8 and later, shared BSPs and some shared libraries are located in subdirectories in the mtb_shared directory. For example:

For BTSDK v2.7 and earlier, shared BSPs and libraries can be found in the same structure, but without the leading mtb_shared directory as shown in the previous image.

The following sections describe the various files and directories in a typical BSP:

#### 5.2.1 COMPONENT_BSP_DESIGN_MODUS¶

This directory contains the configuration files (such as design.modus) for use with various BSP configurator tools, including Device Configurator, QSPI Configurator, and CAPSENSE™ Configurator. At the start of a build, the build system invokes these tools to generate the source files in the GeneratedSource directory. See Modifying the BSP configuration for a single application to learn how the application can override this component.

#### 5.2.2 COMPONENT¶

Some applications may have additional “COMPONENT” subdirectories. These directories are conditional, based on what the BSP is being built for. For example, the PSoC™ 6 BSPs include COMPONENT directories to restrict which files are used when building for the Arm Cortex M4 or M0+ core.

#### 5.2.3 deps subdirectory¶

The deps subdirectory inside the BSP contains .lib files from earlier versions of ModusToolbox™. This is not the same as the deps subdirectory inside the application that contains the .mtb files. See Typical application contents for more details.

#### 5.2.4 docs subdirectory¶

The docs subdirectory contains the documentation in HTML format for the selected BSP.

#### 5.2.5 Support files¶

Different BSPs will contain various files, such as the API interface to the board’s resources. For example, a typical PSoC™ 6 BSP contains the following:

• cybsp.c /.h – You need to include only cybsp.h in your application to use all the features of a BSP. Call cybsp_init () from cybsp.c to initialize the board.

• cybsp_types.h – This currently contains Doxygen comments. It is intended to contain the aliases (macro definitions) for all the board resources, as needed.

• system_psoc6.h – This file provides information about the chip initialization that is done pre- main().

#### 5.2.6 <BSP_NAME>.mk¶

This file defines the DEVICE and other BSP-specific make variables such as COMPONENTS. These are described in the ModusToolbox™ build system chapter. It also defines board-specific information such as the device ID, compiler and linker flags, pre-builds/post-builds, and components used with this board implementation.

#### 5.2.7 locate_recipe.mk¶

This is a helper file for the BSP to specify the path to the core and recipe Makefiles that are included as dependent libraries.

#### 5.2.8 README/RELEASE.md¶

These are documentation files. The README.md file describes the BSP overall, while the RELEASE.md file covers changes made to version of the BSP.

#### 5.2.9 BTSDK-specific BSP files¶

BTSDK BSPs may optionally provide the following types of files:

• wiced_platform.h – Platform specific structures to define hardware information such as max number of GPIOs, LEDs or.user buttons available

• Makefile – Provided to support LIB flow applications (BTSDK 2.7 and earlier). Not used in MTB flow BTSDK 2.8 or later applications.

• *.hex – binary application image files that are used as part of the embedded application creation, program, and/or OTA (Over-The-Air) upgrade processes.

• platform.c/h* – Platform specific source and header files used by platform and application initialization functions.

• <BSP_NAME>.cgs* – Patch configuration records in text format, can be multiple copies supporting various board configurations.

• <BSP_NAME>.btp* – Configuration options related to building and programming the application image, can be multiple copies supporting various board configurations.

### 5.3 Creating your own BSP¶

This section contains a condensed version of these instructions. For a better understanding of the contents and structure of a BSP and more detailed information about how to update the Wi-Fi and Bluetooth® connectivity device and firmware in a BSP, refer to https://www.cypress.com/ModusToolboxCreateCustomBSP.

In most cases before you do any real design work on your application, you should create a BSP for your device and/or board. This allows you to configure the settings for your own custom hardware or for different linker options. Plus, you can save the BSP for use in future applications.

There are two basic methods to create a BSP; each involves creating an application. Using the first method, specify the closest-matching BSP to your intended BSP. In this case, you usually have to remove various settings and options that you don’t need. For the second method, specify a “generic” BSP template when creating your application. In this case, your BSP is essentially built from scratch, and you need to add and configure settings and options for your needs.

Regardless of the method you choose, the basic process is the same for both:

1. Create a simple example application. Use a BSP that is close to your goal or select a “generic” BSP.

2. Navigate to the application directory, and run the make bsp target. Specify the new board name by passing the value to the TARGET_GEN variable. This this is the minimum required. For example, to create a BSP called MyBSP:

make bsp TARGET_GEN=MyBSP

Optionally, you may use DEVICE_GEN specify a new device if it is different than the one included with the original BSP. For example:

make bsp TARGET_GEN=MyBSP DEVICE_GEN=CY8C624ABZI-S2D44

The make bsp command creates a new BSP with the provided name at the top of the application project. It automatically copies the relevant startup and linker scripts into the newly created BSP, based on the device specified by the DEVICE_GEN option.

It also creates .mtbx files for all the BSP’s dependences. The Library Manager tool uses these files to automatically resolve the dependencies of your custom BSP. These files can also be used with the make import_deps command if you need to manually include the custom BSP’s dependencies. Refer to the Library Manager user guide for details about managing BSPs and libraries for custom BSPs.

Note

The BSP used as your starting point may have library references (for example, capsense.lib or udb- sdio-whd.lib) that are not needed by your custom BSP. You can delete these from the BSP’s deps subdirectory. Be sure to remove the corresponding .mtbx files as well.*

3. Update the application’s Makefile TARGET variable to point to your new BSP. For example:

TARGET=MyBSP

4. Open the Device Configurator to customize settings in the new BSP’s design.modus file for pin names, clocks, power supplies, and peripherals as required. Also, address any issues that arise.

5. Start writing code for your application.

If using an IDE, you need to generate/regenerate the configuration settings to reflect the new BSP. Use the appropriate command(s) for the IDE(s) that are being used. For example:

make vscode

Note

Use make help to see all supported IDE make targets. See also the*Exporting to supported IDEschapter in this document.

If you want to re-use a custom BSP on multiple applications, you can copy it into each application or you can put it into a version control system such as Git. See the Manifest files chapter for information on how to create a manifest to include your custom BSPs and their dependencies if you want them to show up as standard BSPs in the Project Creator and Library Manager.

### 5.4 Modifying the BSP configuration for a single application¶

In cases where you don’t want to create a BSP, you can modify the BSP configuration for a single application (such as different pin or peripheral settings). However, you should not typically modify the BSP directly since that results in changes to the BSP library. This would prevent you from updating the repository in the future, and it may affect other applications in the same workspace. Instead, use the following process to create a custom set of configuration files for a specific application:

1. Create a directory at the root of the application to hold any custom BSP configuration files. For example:

Hello_World/COMPONENT_CUSTOM_DESIGN_MODUS

This is a recommended best practice. In an upcoming step, you will modify the Makefile to include files from that directory instead of the directory containing the default configuration files in the BSP.

2. Create a subdirectory for each target that you want to support in your application. For example:

Hello_World/COMPONENT_CUSTOM_DESIGN_MODUS/TARGET_CY8CKIT-062S2-43012

The subdirectory name must be TARGET_<board name>. Again, this is a recommended best practice. If you only ever build with one BSP, this directory is not required, but it is safer to include it.

The build system automatically includes all source files inside a directory that begins with TARGET_, followed by the target name for compilation, when that target is specified in the application’s Makefile. The file structure appears as follows. In this example, the COMPONENT_BSP_DESIGN_MODUS directory for this application is overridden for just one target: CY8CKIT-062S2-43012.

3. Copy the design.modus file and other configuration files (that is, everything from inside the original BSP’s

COMPONENT_BSP_DESIGN_MODUS directory), and paste them into the new directory for the target.

4. In the application’s Makefile, add the following lines. For example:

DISABLE_COMPONENTS += BSP_DESIGN_MODUS

COMPONENTS += CUSTOM_DESIGN_MODUS

Note

The Makefile already contains blank DISABLE_COMPONENTS and COMPONENTS lines where you can add the appropriate names.*

The first line disables the configuration files from the original BSP since they are now in different directory.

The second line is required to specify the new directory to include your custom configuration files, and to ensure that the init_cycfg_all function is still called from the cybsp_init function. The init_cycfg_all function is used to initialize the hardware that was set up in the configuration files.

1. Customize the configuration files as required, such as using the Device Configurator to open the design.modus file and modify appropriate settings.

Note

When you first create a custom configuration for an application, the Eclipse IDE Quick Panel entry to launch the Device Configurator may still open the design.modus file from the original BSP instead of the custom file. To fix this, click the*Refresh Quick Panellink.

When you save the changes in the design.modus file, the source files are generated and placed under the*GeneratedSource* directory. The file structure appears as follows:

1. When finished customizing the configuration settings, you can build the application and program the device as usual.

## 6 Manifest files¶

### 6.1 Overview¶

Manifests are XML files that tell the Project Creator and Library Manager how to discover the list of available boards, example projects, libraries and library dependencies. There are several manifest files.

• The “super-manifest” file contains a list of URLs that software uses to find the board, code example, and middleware manifest files.

• The “app-manifest” file contains a list of all code examples that should be made available to the user.

• The “board-manifest” file contains a list of the boards that should be presented to the user in the new project creation tool as well as the list of BSP packages that are presented in the Library Manager tool. There is also a separate BSP dependencies manifest that lists the dependent libraries associated with each BSP.

• The “middleware-manifest” file contains a list of the available middleware (libraries). Each middleware item can have one or more versions of that middleware available. There is also a separate middleware dependencies manifest that lists the dependent libraries associated with each middleware library.

Beginning with the ModusToolbox™ 2.2 release, there are two versions of manifest files: the existing ones for the LIB flow and earlier versions of ModusToolbox™ software, and new ones for the MTB flow (aka “fv2”). The existing super-manifest file for use with the ModusToolbox™ 2.1 release and earlier contains only references to manifests that contain items that support the LIB flow. The new super-manifest file for use with the ModusToolbox™ 2.2 release and later contains references to all the manifest files.

### 6.2 Create your own manifest¶

By default, the ModusToolbox™ tools look for our manifest files maintained on our server. So, the initial lists of BSPs, code examples, and middleware available to use are limited to our manifest files. You can create your own manifest files on your servers or locally on your machine, and you can override where ModusToolbox™ tools look for manifest files.

To use your own examples, BSPs, and middleware, you need to create manifest files for your content and a super-manifest that points to your manifest files. To see examples of the syntax of super-manifest and manifest files, you can look at files provided on GitHub:

• Super-manifest: https://github.com/Infineon/mtb-super-manifest

• Code example manifest: https://github.com/Infineon/mtb-ce-manifest

• BSP manifest (including dependencies): https://github.com/Infineon/mtb-bsp-manifest

• Middleware manifest (including dependencies): https://github.com/Infineon/mtb-mw-manifest

Make sure you look at the “fv2” manifest files if you are using the MTB flow.

The manifest system is flexible, and there are multiple paths you can follow to customize the manifests.

• You can customize a super-manifest file and override the default file used by the tools.

• You can create secondary super-manifest files that identify additional content. The tools will merge your additional content with the default super-manifest.

• You can modify or replace any of the default manifest files (code example, BSP, etc.) with custom files, so long as your custom super-manifest file points to those rather than the default files.

#### 6.2.1 Overriding the standard super-manifest¶

The location of the standard super-manifest file is hard coded into all of the tools. However, you may override this location by setting the CyRemoteManifestOverride environment variable. When this variable is set, the tools use the value of this variable as the location of the super-manifest file and the hard-coded location is ignored. For example:

CyRemoteManifestOverride=https://myURL.com/mylocation/super-manifest.xml

#### 6.2.2 Secondary super-manifest¶

In addition to the standard super-manifest file, you can specify additional super-manifest files. This allows you to add additional items (BSPs, code examples, libraries) along with the standard items. Do this by creating a file called manifest.loc in a hidden directory in your home directory named “.modustoolbox.”

<user_home>/.modusToolbox/manifest.loc

For example, a manifest.loc file may have:

# This points to the IOT Expert template set

https://github.com/iotexpert/mtb2-iotexpert-manifests/raw/master/iotexpert-super-manifest.xml

Note

You can point to local super-manifest and manifest files by using file:/// with the path instead of https://. For example:*

file:///C:/MyManifests/my-super-manifest.xml

If the manifest.loc file exists, then each line in this file is treated as the URL to a super-manifest file. These are called the secondary or custom super-manifest files. The format of these files is exactly like the standard super- manifest file. Each of the custom super-manifest files are treated as separate super-manifest files. See the Conflicting data section for dealing with conflicts.

#### 6.2.3 Processing¶

The process for using the manifest files is the same for all tools that use the data. The first step is to access the super-manifest file(s) to obtain a list of manifest files for each of the categories that the tool cares about. For example, the Library Manager tool cares about the board and middleware manifests.

The second step is to retrieve the manifest data from each manifest file and merge the data into a single global data model in the tool. See the Conflicting data section for dealing with conflicts.

There is no per-file scoping. All data is merged before it is presented. The combination of a super manifest file and the merging of all of the data allows various contributors, including third party contributors, to make new data available without requiring coordinated releases between the various contributors.

The following table shows how manifests are processed:

Source

Syntax

Effect

CyRe moteManifestOverride

valid URL (e.g., file:/// … or http:// …)

Use that URL to fetch the super-manifest.

Fragment (e.g., my/manifests/super- manifest.xml

Append the home directory to the front (e.g., f ile:///c:/Users/benh /my/manifests/super- manifest.xml)

manifest.loc

valid URL (e.g., file:/// … or http:// …)

Use that URL to fetch the super-manifest.

Fragment (e.g., my/manifests/super- manifest.xml

Append the directory in which manifest.loc resides (e.g., file:/ //c:/Users/benh/.mod ustoolbox/my/manifes ts /super-manifest.xml)

Manifest URIs

valid URI (e.g., file:/// … or http:// …)

Use that URI to fetch the manifest.

Manifest URIs from a local super-manifest file

fragment (e.g., my/man ifests/manifest.xml)

Append the directory in which source super- manifest resides (e.g., file:/ //c:/Users/benh/.mod ustoolbox/my/manifes ts/manifest.xml

Manifest URIs from a remote super-manifest file

fragment (e.g., my/man ifests/manifest.xml)

Append the home directory to the front (e.g., file:/// c:/Users/benh/my/man ifests/manifest.xml)

#### 6.2.4 Conflicting data¶

Ultimately, data from all of the super-manifest and manifest files are combined into a single data collection of BSPs, code examples, and middleware. During the collation of this data, there may be conflicting data entries. There are two types of conflicts.

The first kind is a conflict between data that comes from the primary super-manifest (and linked manifests) and data that comes from the custom super-manifest (and linked manifests). In this case, the data in the custom location overwrites the data from the standard location. This mechanism allows you to intentionally override data that is in the standard location. In this case, no error or warning is issued. It is a valid use case.

The second kind of conflict is between data coming from the same source (that is, both from primary or both from secondary). In this case, an error message is printed and all pieces of conflicting data are removed from the data model. This is done because in this case, it is not clear which data item is the correct one.

### 6.3 Using offline content¶

In normal mode, ModusToolbox™ tools look for manifest files maintained on GitHub and downloads the firmware libraries from git repositories referenced by the manifests. If a network connection to online resources is not available, you can download a copy of all manifests and content, and then point the tools to use this copy in offline mode. This section describes how to download, install, and use the offline content.

Note

ModusToolbox™ libraries are updated frequently, and the offline content does not always have the latest versions available. We strongly recommend using the online content whenever possible. See* https://community.cypress.com/docs/DOC-19903for more details.

1. Download the modustoolbox-offline-content.zip file from the our website:

https://www.cypress.com/products/modustoolbox-software-environment

2. If you do not already have a hidden directory named .modustoolbox in your home directory, create one. Using Cygwin on Windows for example:

mkdir -p “$USERPROFILE/.modustoolbox” 3. Extract the ZIP archive to the /.modustoolbox sub-directory in your home directory. The resulting path should be: ~/.modustoolbox/offline The following is a Cygwin on Windows command-line example to use for extracting the content: unzip -qbod “$USERPROFILE/.modustoolbox” modustoolbox-offline-content.zip

Note

If you previously installed a copy of the offline content, you should delete the existing ~/.modustoolbox/offline directory before extracting the archive. Using Cygwin on Windows for example:

rm -rf “$USERPROFILE/.modustoolbox/offline” 1. To use the Project Creator GUI or Library Manager GUI in offline mode, select Offline from the Settings menu (refer to the appropriate user guide for details). Note Make sure CyRemoteManifestOverride variable is not set when you use offline mode.* 1. To use the Project Creator CLI in offline mode, execute the tool with the –offline argument. For example: project-creator-cli –board-id CY8CPROTO-062-4343W –app-id mtb-example-psoc6- hello-world –offline 2. The Project Creator and Library Manager tools execute the make getlibs command under the hood to download/update the firmware libraries. To execute the make getlibs target in offline mode, pass the CY_GETLIBS_OFFLINE=true argument: make getlibs CY_GETLIBS_OFFLINE=true To override the location of the offline content, set the CY_GETLIBS_OFFLINE_PATH variable: make getlibs CY_GETLIBS_OFFLINE=true CY_GETLIBS_OFFLINE_PATH=”~/custom/offline/content” Refer to the ModusToolbox™ build system chapter for more details about make targets and variables. 3. Once network connectivity is available, you can use the Library Manager tool to update the ModusToolbox™ project previously created offline to use the latest available content. Or you can execute the make getlibs command without the CY_GETLIBS_OFFLINE argument. ### 6.4 Access private repositories¶ You can extend the custom manifest with additional content from git repositories (repos) hosted on GitHub or any other online git server. To access private git repos, you must configure the git client so that the Project Creator and Library Manager tools can authenticate over HTTP/HTTPS protocols without an interactive password prompt. Note While you can host libraries on private repos, the custom content manifest must be accessible without authentication (that is, it cannot be hosted on a private git repo).* To configure git credentials for non-interactive remote operations over HTTP protocols, refer to the git documentation: • https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage • https://git-scm.com/docs/git-credential-store The simplest way is to configure a git-credential-store and save the HTTP credentials is in a plain text file. Note that this option is less secure than other git credential helpers that use OS credentials storage. The following steps show how to configure a git client to access GitHub private repositories without a password prompt: 1. Login to GitHub and go to Personal access tokens: https://github.com/settings/tokens 2. Click Generate new token to open the New personal access token screen. 3. On that screen: 1. Type some text in the Note field. 2. Under Select scopes, click on repo. 3. Click Generate token (scroll down to see the button). 4. Copy the generated token. 4. Open an interactive shell (for example, modus-shellCygwin.bat on Windows), and type the following commands (replace the user name and token with your information): git config –global credential.”https://github.com”.helper store GITHUB_USER=<your-github-username> GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # generated at https://github.com/settings/tokens echo “https://$GITHUB_USER:\$GITHUB_TOKEN@github.com” >> ~/.git-credentials

After entering the commands, you can clone private GitHub repositories without an interactive user/password prompt.

Note

A GitHub account password can be used instead of GITHUB_TOKEN, in case the 2FA (two-factor authentication) is not enabled for the GitHub account. However, this option is not recommended.*

## 7 Using applications with third-party tools¶

ModusToolbox™ software includes a variety of ways to use applications with third-party tools. This chapter covers the following:

### 7.1 Import to Eclipse¶

The easiest way to create a ModusToolbox™ application for Eclipse is to use the Eclipse IDE included with the ModusToolbox™ software. ModusToolbox™ includes an Eclipse plugin that provides links to launch the Project Creator tool and then import the application into Eclipse. For details, refer to the Eclipse IDE for ModusToolbox™ quick start guide or user guide.

If you already have a ModusToolbox™ application created some other way than through the included Eclipse IDE, you can import that application for use in Eclipse as follows:

1. Open the Eclipse IDE included with ModusToolbox™, and select Import Application on the Quick Panel

2. In the Project Location field, click the Browse… button; navigate to and select the application’s directory.

3. Click Finish.

The application displays in the Eclipse IDE Project Explorer.

### 7.2 Exporting to supported IDEs¶

#### 7.2.1 Overview¶

This chapter describes how to export a ModusToolbox™ application to various supported IDEs in addition to the provided Eclipse IDE. As described Getting started chapter, the Project Creator tool includes a Target IDE option that generates files for the selected IDE. Also, as noted in the ModusToolbox™ build system chapter, the make command includes various targets for the following IDEs:

#### 7.2.2 Export to VS Code¶

This section describes how to export a ModusToolbox™ application to VS Code.

##### 7.2.2.1 Prerequisites¶
• ModusToolbox™ 2.4 software and application

• VS Code version 1.42.x or later

• VS Code extensions. Install the following.

Note

These versions change often; use the most current.*

##### 7.2.2.2 Process example¶
1. Create a ModusToolbox™ application.

1. If you use the Project Creator tool, choose “VS Code” from the Target IDE pull down menu.

2. If you use the command line, open an appropriate shell program (see CLI set-up instructions), and navigate to the application directory, and run the following command:

make vscode

Either process generates json files for debug/program launches, IntelliSense, and custom tasks.

Note

Any time you update/patch the tools for your application(s), that path information might change. So, you will need to regenerate the needed support files by running the make vscode command or update them manually.*

1. Open the VS Code tool.

1. To open the application and the mtb_shared directory in the same workspace, select File > Open Workspace…

Navigate to the application directory and select the <application_name>.code-workspace file.

If you have several applications in the workspace, you can add them using Add workspace folder…

2. To open just the application and select File > Open Folder…

Note

On macOS, this command is*File > Open…

Navigate to and select the application directory, and then click Select Directory.

2. When your application opens in the VS Code IDE, select Terminal > Run Build Task…

3. Then, select Build: Build [Debug]. After building, the VS Code terminal should display messages similar to the following:

##### 7.2.2.3 To debug using KitProg3/MiniProg4¶

Click the Run and Debug icon on the left and then click the Play button.

The VS Code tool runs in debug mode.

#### 7.2.3 Export IAR EWARM (Windows only)¶

This section describes how to export a ModusToolbox™ application to IAR Embedded Workbench and debug it with CMSIS-DAP or J-Link.

##### 7.2.3.1 Prerequisites¶
• ModusToolbox™ 2.4 software and application

• Python 3.7 is installed in the tools_2.4 directory, and the make build system has been configured to use it. You don’t need to do anything if you use the modus-shell/Cygwin.bat file to run command line tools.

However, if you plan to use your own version of Cygwin or some other type of bash, you will need to ensure your system is configured correctly to use Python 3.7. Use the CY_PYTHON_PATH as appropriate.

• IAR Embedded Workbench version 8.42.2 or later

• PSoC™ 6 Kit (for example, CY8CPROTO-062-4343W) with KitProg3 FW

• For J-Link debugging, download and install J-Link software: https://www.segger.com/downloads/jlink/JLink_Windows.exe

##### 7.2.3.2 Process example¶
1. Create a ModusToolbox™ application.

1. If you use the Project Creator tool, choose “IAR” from the Target IDE pull down menu.

2. If you use the command line, open an appropriate shell program (see CLI Set-up Instructions), navigate to the application directory, and run the following command:

make ewarm8 TOOLCHAIN=IAR

Note

Check the output log for instructions and information about various flags.

Note

Alternately, you can edit the application’s Makefile to specify the IAR toolchain.*

An IAR connection file appears in the application directory. For example:

mtb-example-psoc6-capsense-buttons-slider-freertos.ipcf

2. Start IAR Embedded Workbench.

3. On the main menu, select Project > Create New Project > Empty project and click OK.

4. Browse to the ModusToolbox™ application directory, enter a desired application name, and click Save.

5. After the application is created, select File > Save Workspace. Then, enter a desired workspace name.

6. Select Project > Add Project Connection and click OK.

7. On the Select IAR Project Connection File dialog, select the .ipcf file and click Open:

8. On the main menu, Select Project > Make.

Note

If you don’t care about staying connected to the ModusToolbox™ tools that generate the project

files, you can delete the .ipcf file from the workspace and restart IAR. The official IAR site discusses this option: https://github.com/IARSystems/project-migration-tools

If you don’t remove the .ipcf file, you need to make all file/group additions at the workspace level.

9. Connect the PSoC™ 6 kit to the host PC.

##### 7.2.3.3 To use KitProg3/MiniProg4¶
1. As needed, run the fw-loader tool to make sure the board firmware is upgraded to KitProg3. See the KitProg3 User Guide for details. The tool is in the following directory by default:

<user_home>/ModusToolbox/tools_2.4/fw-loader/bin/

2. Select Project > Options > Debugger and select CMSIS-DAP in the Driver list:

3. Select the CMSIS-DAP node, switch the interface from JTAG to SWD, and set the Interface speed to 2MHZ.

4. Click OK.

5. Select Project > Download and Debug.

The IAR Embededed Workbench starts a debugging session and jumps to the main function.

##### 7.2.3.4 To use MiniProg4 with PSoC™ 6 single core and PSoC™ 6 256K¶

For a single-core PSoC™ 6 MCU, you must specify a special type of reset, as follows:

#### 7.2.4 Export to Keil µVision 5 (Windows only)¶

This section describes how to export ModusToolbox™ application to Keil µVision and debug it with CMSIS-DAP or J-Link.

##### 7.2.4.1 Prerequisites¶
• ModusToolbox™ 2.4 software and application

• Python 3.7 is installed in the tools_2.4 directory, and the make build system has been configured to use it. You don’t need to do anything if you use the modus-shell/Cygwin.bat file to run command line tools.

However, if you plan to use your own version of Cygwin or some other type of bash, you will need to ensure your system is configured correctly to use Python 3.7. Use the CY_PYTHON_PATH as appropriate.

• Keil µVision version 5.28 or later

• PSoC™ 6 Kit (for example, CY8CPROTO-062-4343W) with KitProg3 Firmware

• For J-Link debugging, download and install J-Link software: https://www.segger.com/downloads/jlink/JLink_Windows.exe

##### 7.2.4.2 Process example¶
1. Create a ModusToolbox™ application.

1. If you use the Project Creator tool, choose “ARM MDK” from the Target IDE pull down menu.

2. If you use the command line, open an appropriate shell program (see CLI Set-up Instructions), navigate to the application directory, and Run the following command:

make uvision5 TOOLCHAIN=ARM

Note

Alternately, you can edit the application’s Makefile to specify a toolchain.*

This generates the following files in the application directory:

• mtb-example-psoc6-hello-world.cpdsc

• mtb-example-psoc6-hello-world.cprj

• mtb-example-psoc6-hello-world.gpdsc

The cpdsc file extension should have the association enabled to open it in Keil µVision.

2. Double-click the mtb-example-psoc6-hello-world file (either *.cpdsc or *.cprj, depending on version). This launches the Keil µVision IDE. The first time you do this, the following dialog displays:

3. Click Yes to install the device pack. You only need to do this once.

4. Follow the steps in the Pack Installer to properly install the device pack.

Note

In some cases, you may see the following error message:* SSL caching disabled in Windows Internet settings. Switched to offline mode.

See this link for how to solve this problem:https://developer.arm.com/documentation/ka002253/latest

When complete, close the Pack Installer and close the Keil µVision IDE. Then double-click the .cpdsc/.cprj file again and the application will be created for you in the IDE.

1. Right-click on the mtb-example-psoc6-hello-world directory in the µVision Project view, and select Options for Target ‘<application-name>’

1. On the dialog, select the C/C++ (AC6) tab.

• Check that the Language C version was automatically set to c99.

• Select “AC5-like warnings” in the Warnings drop-down list.

• Select “-Os balanced” in the Optimization drop-down list.

1. Select the Debug tab, and select KitProg3 CMSIS-DAP as an active debug adapter:

1. Click OK to close the Options dialog.

2. Select Project > Build target.

To suppress the linker warnings about unused sections defined in the linker scripts, add “6314,6329” to the

Disable Warnings setting in the Project Linker Options.

3. Connect the PSoC™ 6 kit to the host PC.

4. As needed, run the fw-loader tool to make sure the board firmware is upgraded to KitProg3. See KitProg3 User Guide for details. The tool is located in this directory by default:

<user_home>/ModusToolbox/tools_2.4/fw-loader/bin/

1. Select Debug > Start/Stop Debug Session.

You can view the system and peripheral registers in the SVD view.

##### 7.2.4.3 To use KitProg3/MiniProg4, CMSIS-DAP, and ULink2 debuggers¶
1. Select the Device tab in the Options for Target dialog and check that M4 core is selected:

2. Select the Debug tab and click “Settings” to display the dialog Target Driver Setup:

3. On the Target Driver Setup dialog, on the Debug tab, select the following:

• set Port to “SW”

• set Max Clock to “1 MHz”

• set Connect to “Normal”

• set Reset:

• For PSoC™ 6, to “VECTRESET”

• For PSoC™ 4, to “SYSRESETREQ”

• enable Reset after Connect option

1. Select the Flash Download tab and select “Reset and Run” option after download, if needed:

1. Select the Pack tab and check if “Cypress.PSoC6_DFP” is enabled:

##### 7.2.4.5 Program external memory¶
1. Download internal flash as described above.

Notice “No Algorithm found for: 18000000H - 1800FFFFH” warning.

2. Select the Flash Download tab in Target Driver Setup dialog and remove all programming algorithms for On-chip Flash and add programming algorithm for External Flash SPI:

1. Download flash.

Notice warnings:

• No Algorithm found for: 10000000H - 1000182FH

• No Algorithm found for: 10002000H - 10007E5BH

• No Algorithm found for: 16007C00H - 16007DFFH

##### 7.2.4.6 Erase external memory¶
1. Select the Flash Download tab in Target Driver Setup dialog and remove all programming algorithms for On-chip Flash and add programming algorithm for External Flash SPI:

1. Click Flash > Erase in menu bar.

### 7.3 Generating files for XMC™ Simulator tool¶

For the XMC1100, XMC1200, XMC1300, and XMC1400 families of devices, you can generate an archive file to upload to the XMC™ Simulator tool (https://design.infineon.com/tinaui/designer.php) for simulation and debugging. To do this:

Specify the CY_SIMULATOR_GEN_AUTO=1 variable as follows:

• Edit the application Makefile to add the CY_SIMULATOR_GEN_AUTO=1 variable, and then build the application, or

• Add the variable on the command line: make build CY_SIMULATOR_GEN_AUTO=1

When the build completes, it generates an archive file (<application-name>.tar.tgz) in the <Application- Name>build<Kit-Name>Debug directory, and the build message displays the URL to the appropriate simulator tool. For example:

==============================================================================
= Generating simulator archive file =
==============================================================================

The Infineon online simulator link: https://design.infineon.com/tinaui/designer.php?path=EXAMPLESROOT%7CINFINEON%7CApp lications%7CIndustrial%7C&file=mcu_XMC1200_Boot_Kit_MTB_v2.tsc

Simulator archive file C:/Users/XYZ/mtw2.4/5699/xmc- 2/Empty_XMC_App/build/KIT_XMC12_BOOT_001/Debug/mtb-example-xmc-empty-app.tar.tgz successfully generated

• If using the Eclipse IDE, click the link in the Quick Panel under Tools to open the XMC™ Simulator tool in the default web browser.

• If building with the command line, open a web browser to the URL displayed in the output message.

Upload the generated archive file to the XMC™ Simulator tool, and follow the tool’s instructions for using the tool as appropriate.

## Revision history¶

Date

Revision

Description of change

3/24/2020

**

New document.

3/27/2020

*A

Updates to screen captures and associated text.

4/1/2020

*B

Fix broken links.

4/29/2020

*C

Fix incorrect link.

8/28/2020

*D

Updates for ModusToolbox™ 2.2.

9/23/2020

*E

Corrections to Build system and Board support packages chapters.

9/29/2020

*F

Added links to KBAs; updated text for cyignore.

10/2/2020

*G

Added details for BTSDK v2.8 BSPs/libraries.

1/14/2021

*H

Updated Manifest chapter and fixed broken links.

3/23/2021

*I

Updates for ModusToolbox™ 2.3.

5/24/2021

*J

Updated information for creating a custom BSP.

9/27/2021

*K

Updates for ModusToolbox™ 2.4.