Skip to main content

ModusToolbox™ build system

This chapter covers various aspects of the ModusToolbox™ build system. Refer to CLI set-up instructions for getting started information about using the command line tools. This chapter is organized as follows:

Overview​

The ModusToolbox™ build system is based on GNU make. It performs application builds and provides the logic required to launch tools and run utilities. It consists of a light and accessible set of Makefiles deployed as part of every application. This structure allows each application to own the build process, and it allows environment-specific or application-specific changes to be made with relative ease. The system runs on any environment that has the make and git utilities.

note

User-defined command line make parameters are not supported and the only supported variables are TOOLCHAIN and TARGET.

The ModusToolbox™ command line interface (CLI) and supported IDEs all use the same build system. Hence, switching between them is fully supported. Program/Debug and other tools can be used in either the command line or an IDE environment. In all cases, the build system relies on the presence of ModusToolbox™ tools included with the ModusToolbox™ installer.

The tools contain a start.mk file that serves as a reference point for setting up the environment before executing the recipe-specific build in the base library. The file also provides a getlibs make target that brings libraries into an application. Every application must then specify a target board on which the application will run. These are provided by the [BSP].mk files deployed as a part of a BSP library.

The majority of the Makefiles are deployed as git repositories (called "repos"), in the same way that libraries are deployed in the ModusToolbox™ software. There are two separate repos: core-make used by all recipes and a recipe-make-xxx that contains BSP/target specific details. These are the minimum required to enable an application build. Together, these Makefiles form the build system.

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.

make getlibs​

When you run the make getlibs command, the build system finds all the .mtb files in the application directory and performs git clone operations on them. A .mtb file contains the source location of a library repo, a specific tag for a version of the code, and the location to store the library.

The getlibs target finds and processes all .mtb files and uses the git clone command to clone or pull the code as appropriate. The target generates .mtb files for indirect dependencies. Then, it checks out the specific tag listed in the .mtb file. The Project Creator and Library Manager invoke this process automatically.

note

ModusToolbox™ version 3.x no longer supports the old LIB flow, thus all .lib files are ignored.

  • The getlibs target must be invoked separately from any other make target (for example, the command make getlibs build is not allowed and the Makefiles will generate an error; however, a command such as make clean build is allowed).

  • The getlibs target performs a git fetch on existing libraries but will always checkout the tag pointed to by the overseeing . mtb file.

  • The getlibs target detects if users have modified standard code and will not overwrite their work. This allows you to perform some action (for example commit code or revert changes, as appropriate) instead of overwriting the changes.

The build system also has a printlibs target that can be used to print the status of the cloned libraries.

repos​

The cloned libraries are located in their individual git repos in the directory pointed to by the CY_GETLIBS_PATH variable (for example, /deps). These all point to the "our" remote origin. You can point your repo by editing the .git/config file or by running the git remote command.

If the repos are modified, add the changes to your source control (git branch is recommended). When make getlibs is run (to either add new libraries or update libraries), it requires the repos to be clean (that is, all changes must be committed). You may also use the .gitignore file for adding untracked files when running make getlibs. See also KBA231252.

BSPs​

An application must specify a target BSP through the TARGET variable in the Makefile. We provide BSPs based on our kits to use as a starting point. When you create an application, the selected BSP is then owned by that application, and you can modify it as needed. For more information about BSPs, refer to the Board support packages chapter.

  • When using the Project Creator to create an application, it provides the selected BSP and updates the Makefile .

  • Use the Library Manager to add, update, or remove a BSP from an application. You can also add a . mtb file that contains the URL and a version tag of interest in the application.

Environment variables​

note

In ModusToolbox™ tools package 3.5.0 and later, you can use the Settings tool instead of these environment variables. If these are set, they will be disabled in the Settings tool. See the Settings tool user guide for more details.

ModusToolbox™ software supports custom installation paths, and we provide the following variables to specify locations of tools and support files other than the default:

  • CY_TOOLS_PATHS (path to the installation " tools_[version] " directory)

  • CyManifestLocOverride (path to the local manifest.loc file)

  • CyRemoteManifestOverride (URL to a specific manifest file)

We also include a global path for assets like device-db using the variable named CY_GETLIBS_GLOBAL_PATH. If the variable does not exist, it assumes a default path of ~/.modustoolbox/global.

note

When entering variables that require a path, use a Windows-style path (not Cygwin-style, like /cygdrive/c/). Also, use forward slashes. For example, "C:/MyPath/ModusToolbox/tools_[version]".

Adding source files​

Source and header files placed in the application directory hierarchy are automatically added by the auto-discovery mechanism. Similarly, library archives and object files are automatically added to the application. Any object file not referenced by the application is discarded by the linker. The Project Creator and Library Manager tools run the make getlibs command and generate a mtb.mk file in the application's libs subdirectory. This file specifies the location of shared libraries included in the build.

The application Makefile can also include specific source files (SOURCES), header file locations (INCLUDES) and prebuilt libraries (LDLIBS). This is useful when the files are located outside of the application directory hierarchy or when specific sources need to be included from the filtered directories.

Auto-discovery​

The build system implements auto-discovery of library files, source files, header files, object files, and pre-built libraries. If these files follow the specified rules, they are guaranteed to be brought into the application build automatically. Auto-discovery searches for all supported file types in the application directory hierarchy and performs filtering based on a directory naming convention and specified directories, as well as files to ignore. If files external to the application directory hierarchy need to be added, they can be specified using the SOURCES, INCLUDES, and LIBS make variables.

To control which files are included/excluded, the build system implements a filtering mechanism based on directory names and .cyignore files.

.cyignore​

Prior to applying auto-discovery and filtering, the build system will first search for .cyignore files in the roots of applications/projects, libraries, and BSPs, and construct a set of directories and files to exclude. This can be used to skip searching directories that contain no source code, or skip source code you don't want included. As an example, many ModusToolbox™ BSPs and libraries contain a directory named docs in the root directory, which contains no source code. So to speed up auto-discovery, these BSPs and middleware libraries include a .cyignore file that contains a line docs, which causes auto-discovery to ignore that directory. The system will only detect .cyignore files in the application/project root, as well as in the roots of libraries and BSPs, so there is not a recursive search.

All paths inside a .cyignore file are relative to the location of that specific .cyignore file. You could use keep/all/except if you wanted to keep "all" but exclude "except." You also can use "../" to look up and out from the current directory.

As mentioned, some library might contain source code that you do not want added to your build. Specifying that directory's location would require hard-coding the version of the library in use, which could potentially cause problems later. In this case, the variable $(SEARCH_library) solves this problem. For example, if the bluetooth-freertos library contains a directory named firmware_deprecated, you could add the following to the .cyignore file in the application root directory to exclude it:

$(SEARCH_bluetooth-freertos)/firmware_deprecated/

This causes that directory inside the bluetooth-freertos library to be ignored no matter where it is inside the workspace.

Another useful feature in a .cyignore file is a comment line. Any line that starts with "#" is skipped. So, you could write a description about why a file or directory is to be excluded. Or, you could just comment out an entry to assist in debugging your application.

note

Wildcards and expressions are not allowed, and each directory or file requires its own entry in the file. However, the .cyignore file can contain make variables, such as SEARCH as shown above.

The CY_IGNORE variable can also be used in the Makefile to define directories and files to exclude.

note

The CY_IGNORE variable should contain paths that are relative to the application root. For example, ./src1.

TOOLCHAIN_[NAME]​

Any directory that has the prefix "TOOLCHAIN_" is interpreted as a directory that is toolchain specific. The "NAME" corresponds to the value stored in the TOOLCHAIN make variable. For example, an IAR-specific set of files is located under a directory named TOOLCHAIN_IAR. Auto-discovery only includes the TOOLCHAIN_[NAME] directories for the specified TOOLCHAIN variable. All others are ignored. ModusToolbox™ supports IAR, ARM, GCC_ARM, and LLVM_ARM.

TARGET_[NAME]​

Any directory that has the prefix "TARGET_" is interpreted as a directory that is target specific. The "NAME" corresponds to the value stored in the TARGET make variable. For example, a build with TARGET=APP_KIT_PSC3M5_EVK ignores all TARGET_ directories except TARGET=APP_KIT_PSC3M5_EVK.

note

The TARGET_ directory is often associated with the BSP, but it can be used in a generic sense. For example, if application sources need to be included only for a certain TARGET, this mechanism can be used to achieve that.

note

The output directory structure includes the TARGET name in the path, so you can build for target A and B and both artifact files will exist on disk.

CONFIG_[NAME]​

Any directory that has the prefix "CONFIG_" is interpreted as a directory that is configuration (Debug/Release) specific. The "NAME" corresponds to the value stored in the CONFIG make variable. For example, a build with CONFIG=CustomBuild ignores all CONFIG_ directories, except CONFIG_CustomBuild.

note

The output directory structure includes the CONFIG name in the path, so you can build for config A and B and both artifact files will exist on disk.

COMPONENT_[NAME]​

Any directory that has the prefix "COMPONENT_" is interpreted as a directory that is component specific. This is used to enable/disable optional code. The "NAME" corresponds to the value stored in the COMPONENT make variable. For example, consider an application that sets COMPONENTS+=comp1. Also assume that there are two directories containing component-specific sources:

COMPONENT_comp1/src.c
COMPONENT_comp2/src.c

Auto-discovery will only include COMPONENT_comp1/src.c and ignore COMPONENT_comp2/src.c. If a specific component needs to be removed, either delete it from the COMPONENTS variable or add it to the DISABLE_COMPONENTS variable.

BSP makefile​

Auto-discovery will also search for a bsp.mk file (aka, BSP makefile). If no matching BSP makefile is found, it will fail to build.

Pre-builds and post-builds​

A pre-build or post-build operation is typically a script file invoked by the build system. Such operations are possible at several stages in the build process. They can be specified at the application, BSP, and recipe levels.

You can pre-build and post-build arguments in the application Makefile. For example:

project_prebuild:
    command1 -arg1
    Command2 -arg2

The sequence of execution in a build is as follows:

  1. Recipe pre-build – Defined using recipe_prebuild target.
  2. BSP pre-build – Defined using bsp_prebuild target.
  3. Project pre-build – Defined using project_prebuild target.
  4. Source compilation and linking.
  5. Recipe post-build – Defined using recipe_postbuild target.
  6. BSP post-build – Defined using bsp_postbuild target.
  7. Project post-build – Defined using project_postbuild target.

Available make targets​

A make target specifies the type of function or activity that the make invocation executes. The build system does not support a make command with multiple targets. Therefore, a target must be called in a separate make invocation. The following tables list and describe the available make targets for all recipes.

General make targets​

TargetDescription
allSame as build. That is, builds the application.
This target is equivalent to the build target.
getlibsClones the repositories and checks out the identified commit.
When using .mtb files, the repos are cloned to the shared location $(CY_GETLIBS_SHARED_PATH)/$(CY_GETLIBS_SHARED_NAME). By default, this directory is specified by the project Makefile.
buildBuilds the application.
The build process involves source auto-discovery, code-generation, pre-builds, and post-builds. For faster incremental builds, use the qbuild target to skip the auto-discovery step.
For multi-core applications, running this target builds all core projects in the application, and generates a combined hex file.
build_projBuild a single project.
Build a single target in the application. In single core-applications, this target is the same as the build target.
qbuildQuick builds the application using the previous build's source list.
When no other sources need to be auto-discovered, this target can be used to skip the auto-discovery step for a faster incremental build.
qbuild_projBuilds a single project using the previous build's source list. In the single project-applications, this target is the same as the qbuild target.
When no other sources need to be auto-discovered, this target can be used to skip the auto-discovery step for a faster incremental build.
programBuilds the application and programs it to the target device. In multi-core applications, this will program the combined hex file.
The build process performs the same operations as the build target. Upon completion, the artifact is programmed to the board.
program_projBuild and program only the current project to the target device. In single-core applications, this target is the same as the program target.
The build process performs the same operations as the build target. Upon completion, the artifact is programmed to the board.
qprogramQuick programs a built application to the target device without rebuilding.
This target allows programming an existing artifact to the board without a build step.
qprogram_projPrograms a built project to the target device without rebuilding. In single-core applications, this target is the same as the qprogram target.
This target allows programming an existing artifact to the board without a build step.
cleanCleans the /build/[TARGET] directory.
The directory and all its contents are deleted from disk.
helpPrints the help documentation.
Use the CY_HELP=[name of target or variable] to see the verbose documentation for a given target or a variable.
prebuildGenerates code for the application.
Runs custom prebuild commands to generate source code.

IDE make targets​

TargetDescription
eclipseGenerates Eclipse IDE launch configs and project files.
This target generates a .cproject and a .project if they do not exist in the application root directory.
vscodeGenerates VS Code IDE files.
This target generates VS Code files for debug/program launches, IntelliSense, and custom tasks. These overwrite the existing files in the application directory except for settings.json.
ewarm /
ewarm8		This target generates an IAR Embedded Workbench compatible .ipcf file that can be imported into IAR-EW. The .ipcf file is overwritten every time this target is run.
Project generation requires Python 3 to be installed and present in the PATH variable.
For applications that were created using core-make-3.0 or older, you must use the make ewarm8 command instead.
uvision /
uvision5		Generates a Keil µVision IDE .cprj file.
This target generates a CMSIS-compatible file that can be imported into Keil µVision. The file is overwritten every time this target is run. Files in the default cmsis output directory will be automatically excluded when calling make uvision.
Project generation requires Python 3 to be installed and present in the PATH variable.
For applications that were created using core-make-3.0 or older, you must use the make uvision5 command instead.

Utility make targets​

TargetDescription
progtoolPerforms specified operations on the programmer/firmware-loader. Only available for devices that use KitProg3.
This target expects user-interaction on the shell while running it. When prompted, you must specify the command(s) to run for the tool.
printlibsPrints the status of the library repos.
This target parses through the library repos and prints the SHA1 commit. It also shows whether the repo is clean (no changes) or dirty (modified or new files).
checkChecks for the necessary tools.
Not all tools are necessary for every build recipe. This target allows you to get an idea of which tools are missing if a build fails in an unexpected way.

Available make variables​

The following variables customize various make targets. They can be defined in the application Makefile or passed through the make invocation. The following sections group the variables for how they can be used.

Basic configuration make variables​

These variables define basic aspects of building an application. For example:

make build TOOLCHAIN=GCC_ARM CONFIG=CustomConfig -j8
VariableDescription
TARGETSpecifies the target board/kit (that is, BSP). For example, CY8CPROTO-062-4343W.
Example usage: make build TARGET=CY8CPROTO-062-4343W
CORESpecifies the name of the Arm® core for which a project is building (e.g. CM4).
Example Usage: make build CORE=CM4
Use this variable to select compiler and linker options to build a project for a specified Arm® core.
CORE_NAMESpecifies the name of the on-chip core for which a project is building (e.g. CM7_0).
Example Usage: make build CORE_NAME=CM7_0
Use this variable to select compiler and linker options to build a project for a specified on-chip core.
This variable is applicable for some multi-core devices only (e.g. XMC7xxx).
APPNAMESpecifies the name of the application. For example, "AppV1" > AppV1.elf.
Example usage: make build APPNAME="AppV1"
This variable is used to set the name of the application artifact (programmable image).
This variable may also be used when generating launch configs when invoking the eclipse target.
TOOLCHAINSpecifies the toolchain used to build the application. For example, IAR.
Example Usage: make build TOOLCHAIN=IAR
Supported toolchains for this include GCC_ARM, IAR, ARM and LLVM_ARM.
When setting TOOLCHAIN=IAR, you should also specify the heap type using LDFLAGS. The --advanced_heap option is required if the program uses a library that requires it.
CONFIGSpecifies the configuration option for the build [Debug Release].
Example Usage: make build CONFIG=Release
The CONFIG variable is not limited to Debug/Release. It can be other values. However in those instances, the build system will not configure the optimization flags. Debug=lowest optimization, Release=highest optimization.
The optimization flags are toolchain specific. If you go with your custom config, then you can manually set the optimization flag in the CFLAGS.
VERBOSESpecifies whether the build is silent [false] or verbose [true].
Example Usage: make build VERBOSE=true
Setting VERBOSE to true may help in debugging build errors/warnings. By default, it is set to false.

Advanced configuration make variables​

These variables define advanced aspects of building an application.

VariableDescription
SOURCESSpecifies C/C++ and assembly files outside of application directory.
Example Usage (within Makefile): SOURCES+=path/to/file/Source1.c
This can be used to include files external to the application directory. The path can be both absolute or relative to the application directory.
INCLUDESSpecifies include paths outside of the application directory.
Example Usage (within Makefile): INCLUDES+=path/to/headers
These MUST NOT have -I prepended. The path can be either absolute or relative to the application directory.
DEFINESSpecifies additional defines passed to the compiler.
Example Usage (within Makefile): DEFINES+=EXAMPLE_DEFINE=0x01
These MUST NOT have -D prepended.
VFP_SELECTSelects hard/soft ABI or full software for floating-point operations [softfp hardfp softfloat].
If not defined, this value defaults to softfp.
Example Usage (within Makefile): VFP_SELECT=hardfp
VFP_SELECT_PRECISIONSelects single-precision or double-precision operating mode for floating-point operations.
If not defined, this value defaults to double-precision. Enable single-precision mode by using the "singlefp" option.
Example Usage (within Makefile): VFP_SELECT_PRECISION=singlefp
CFLAGSPrepends additional C compiler flags.
Example Usage (within Makefile): CFLAGS+= -Werror -Wall -O2
CXXFLAGSPrepends additional C++ compiler flags.
Example Usage (within Makefile): CXXFLAGS+= -finline-functions
ASFLAGSPrepends additional assembler flags.
Usage is similar to CFLAGS.
LDFLAGSPrepends additional linker flags.
Example Usage (within Makefile): LDFLAGS+= -nodefaultlibs
LINKER_SCRIPTSpecifies a custom linker script location.
Example Usage (within Makefile): LINKER_SCRIPT=path/to/file/Custom_Linker1.ld
This linker script overrides the default.
Additional linker scripts can be added for GCC via the LDFLAGS variable as a -L option.
COMPONENTSAdds component-specific files to the build.
Example Usage (within Makefile): COMPONENTS+=CUSTOM_CONFIGURATION
Create a directory named COMPONENT_[VALUE] and place your files. Then include the corresponding make variable to have that feature library be included in the build. For example, create a directory named COMPONENT_ACCELEROMETER into auto-discovery. Then, add the following make variable to the Makefile: COMPONENT=ACCELEROMETER. If the make variable does not include the [VALUE], then that library will not be included in the build.
DISABLE_COMPONENTSRemoves component-specific files from the build.
Example Usage (within Makefile): DISABLE_COMPONENTS=BSP_DESIGN_MODUS
Include a [VALUE] to this make variable to have that feature library be excluded in the build. For example, to exclude the contents of the COMPONENT_BSP_DESIGN_MODUS directory, set DISABLE_COMPONENTS=BSP_DESIGN_MODUS.
SEARCHList of paths to include in auto-discovery. For example, ../mtb_shared/lib1.
Example Usage (within Makefile): SEARCH+=directory_containing_source_files
The SEARCH variable can also be used by the application to include other directories to auto-discovery.
SKIP_CODE_GENDisables code generation from configurators when building.
When set to a non-empty value, the build process will no longer run code generation from configurators.
MERGEList of projects in the application to generate a combined hex file from.
By default, building a multi-project application will generate a combined hex file from its sub-projects. This variable can be set from the application Makefile to override the set of projects to generate combined hex file from.
VCORE_ATTRSVirtual core attribute.
Currently supported values are "TRUSTZONE_SECURE" and "TRUSTZONE_NON_SECURE" which specify the core property for Arm® TrustZone.
TRUSTZONE_VENEERThe path of the veneer object file used for Arm® TrustZone.
When specified for a secure project, it specifies the path of the veneer object file to generated. When specified for a non-secure project, it specifies the path of the veneer object file to include.

BSP make variables​

VariableDescription
DEVICEDevice ID for the primary MCU on the target board/kit. Set by bsp.mk.
The device identifier is mandatory for all board/kits.
ADDITIONAL_DEVICESIDs for additional devices on the target board/kit. Set by bsp.mk.
These include devices such as radios on the board/kit. This variable is optional.
BSP_PROGRAM_INTERFACESpecifies the debugging and programming interface to use. The default value and valid values all depend on the BSP.
Possible values include KitProg3, JLink, and FTDI. Most BSPs will only support a subset of this list.

Getlibs make variables​

These variables are used with the make getlibs target.

note

When entering variables that require a path, use a Windows-style path (not Cygwin-style, like /cygdrive/c/). Also, use forward slashes. For example, "C:/MyPath/ModusToolbox/tools_[version]."

VariableDescription
MTB_USE_LOCAL_CONTENTIf set to non-empty, enable local content storage.
Enable local content storage to allow use of ModusToolbox™ software without requiring internet access. Refer to the LCS Manager CLI User guide for more details.
CY_GETLIBS_PATHPath to the intended location of libs info directory.
The directory contains local libraries and metadata files about shared libraries.
CY_GETLIBS_DEPS_PATHPath to where the library-manager stores .mtb files.
Setting this path allows relocating the directory that the library-manager uses to store the .mtb files in your application. The default location is in a directory named deps.
CY_GETLIBS_SHARED_PATHRelative path to the shared repo location.
All .mtb files have the format, [URI][COMMIT][LOCATION]. If the [LOCATION] field begins with $$ASSET_REPO$$, then the repo is deposited in the path specified by the CY_GETLIBS_SHARED_PATH variable. The default is set from the project Makefile.
CY_GETLIBS_SHARED_NAMEDirectory name of the shared repo location.
All .mtb files have the format, [URI][COMMIT][LOCATION]. If the [LOCATION] field begins with $$ASSET_REPO$$, then the repo is deposited in the directory specified by the CY_GETLIBS_SHARED_NAME variable. By default, this is set from the project Makefile.

Path make variables​

These variables are used to specify various paths.

note

When entering variables that require a path, use a Windows-style path (not Cygwin-style, like /cygdrive/c/). Also, use forward slashes. For example, "C:/MyPath/ModusToolbox/tools_[version]."

VariableDescription
CY_APP_PATHRelative 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 the Makefile.
CY_COMPILER_GCC_ARM_DIRAbsolute path to the gcc-arm toolchain directory.
Setting this path overrides the default GCC_ARM toolchain directory. It is used when the compiler is located at a non-default directory. Make uses this variable for the path to the assembler, compiler, linker, objcopy, and other toolchain binaries.
For example, CY_COMPILER_GCC_ARM_DIR=C:/Program Files (x86)GNU arm Embedded Toolchain/10 2021.10
When set in the Makefile, no quotes are required.
CY_COMPILER_IAR_DIRAbsolute path to the IAR toolchain directory.
Setting this path overrides the default IAR toolchain directory. It is used when the compiler is located at a non-default directory. Make uses this variable for the path to the assembler, compiler, linker, objcopy, and other toolchain binaries.
For example, CY_COMPILER_IAR_DIR=C:/Program Files/IAR Systems/Embedded Workbench 9.1/arm
When set in the Makefile, no quotes are required.
CY_COMPILER_ARM_DIRAbsolute path to the ARM toolchain directory.
Setting this path overrides the default ARM toolchain directory. It is used when the compiler is located at a non-default directory. Make uses this variable for the path to the assembler, compiler, linker, objcopy, and other toolchain binaries.
For example, CY_COMPILER_ARM_DIR=C:/Program Files/ARMCompiler6.16
When set in the Makefile, no quotes are required.
CY_COMPILER_LLVM_ARM_DIRAbsolute path to the LLVM toolchain directory.
Setting this path overrides the default LLVM toolchain directory. It is used when the compiler is located at a non-default directory. Make uses this variable for the path to the assembler, compiler, linker, objcopy, and other toolchain binaries.
For example, CY_COMPILER_LLVM_ARM_DIR=C:/Program Files/LLVM
When set in the Makefile, no quotes are required.
CY_TOOLS_DIRAbsolute path to the tools root directory.
Example Usage: make build CY_TOOLS_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_LOCATIONAbsolute 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_PATHSpecifies the path to a specific Python executable.
Example Usage: CY_PYTHON_PATH="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 however CY_PYTHON_PATH is defined, it will use that python executable.
MTB_JLINK_DIRSpecifies the path to the SEGGER J-Link software install directory "JLink".
Example Usage: MTB_JLINK_DIR:=C:/Program Files/SEGGER/JLink
Setting this path allows the make system to locate the JLink executable when calling make program. If not specified, make will default to the JLink executable in the PATH variable.
When generating launch configurations for IDEs, this will override the default J-Link path.

Miscellaneous make variables​

These are miscellaneous variables used for various make targets.

note

When entering variables that require a path, use a Windows-style path (not Cygwin-style, like /cygdrive/c/). Also, use forward slashes. For example, "C:/MyPath/ModusToolbox/tools_[version]."

VariableDescription
CY_IGNOREAdds 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 variable are ignored in auto-discovery. This mechanism works in combination with any existing .cyignore files in the application.
CY_IDE_PRJNAMEThis variable contains the name that will be used to create the application name and support files for an IDE during application export.
Use this variable to provide a custom name of an application for the IDE during application export. If CY_IDE_PRJNAME is not set on the command line, then APPNAME (which is specified in the Makefile) is used as the default. This name can be important for some IDEs to set a correct meaningful name for the application, support files, and launch configurations in the IDE.
CY_SIMULATOR_GEN_AUTOIf set to 1, automatically generate a simulator archive (if supported by the target device).
When enabled, the build make target will generate a debugging tgz archive for the Infineon online simulator as part of the post-build process.

Tools targets​

note

There are various targets to launch tools and configurators that are not part of the make system, but they can be used in the application directory. The following table lists a few of the common targets as a convenience. Refer to the applicable user guide for details for the given configurator or tool.

TargetDescription
bsp-assistantLaunches the BSP Assistant with the active BSP for the application.
bt-configuratorLaunches the Bluetooth® Configurator GUI for the application's cybt file.
capsense-configuratorLaunches the CAPSENSE™ Configurator GUI for the target's cycapsense file.
capsense-tunerLaunches the CAPSENSE™ Tuner GUI for the target's cycapsense file.
device-configuratorLaunches the Device Configurator on the application's *.modus file.
library-managerLaunches the Library Manager for the application to add/remove libraries and to upgrade/downgrade existing libraries.
lin-configuratorLaunches the LIN Configurator GUI for the target's mtblin file.
qspi-configuratorLaunches the QSPI Configurator GUI for the target's cyqspi file.
seglcd-configuratorLaunches the Segment LCD Configurator GUI for the target's cyseglcd file.
smartio-configuratorLaunches the Smart I/O Configurator GUI for the target's modus file.
usbdev-configuratorLaunches the USB Configurator GUI for the target's cyusbdev file.
Last updated on