Skip navigation
Home > All Places > Topics > Cypress Community Blogs > ModusToolbox Blog > Blog
1 2 3 Previous Next

ModusToolbox Blog

71 posts

ModustoolBox (MTB) 2.2 brings with it a new unified workflow for applications. In ModustoolBox 2.0 or ModustoolBox 2.1, BTSDK apps had a different workflow than PSoC6 SDK apps, but with ModustoolBox 2.2, apps using PSoC6/BTSDK/AnyCloud SDK follow the same workflow.

In addition to the unified flow, there are some improvements available in MTB 2.2 such as added flexibility in how libraries are managed.

It’s necessary to make some changes in MTB 2.0/2.1 BTSDK applications to start using the unified flow in MTB 2.2. This blog will give you migration steps for BTSDK apps from MTB 2.0/2.1 to MTB 2.2


Before we move on to the steps for migration, there are some points to note:

  1. An MTB 2.0/2.1 workspace containing BTSDK app and wiced_btsdk 2.7.1 can be used with MTB 2.2 to build/program. If you want to access the library manager features of MTB 2.2, then you must upgrade your application to work with the MTB 2.2 flow.
  2. If you are using wiced_btsdk 2.7 or below but have updated to MTB 2.2, applications might break for some BSPs while using MTB 2.2 tools. The solution is to update to wiced_btsdk 2.7.1, or even better, migrate the app to the MTB 2.2 flow.
  3. BTSDK MTB 2.1 CEs are not compatible with MTB 2.2.


What has changed in BTSDK app structure in MTB 2.2?


  1. The first change you will notice is the option to create required apps from the BLE, mesh or HAL group. With MTB 2.1, all apps were created from a given group with no choice. Figure 1 shows the difference in the list of apps for the BLE CE group.
    Figure 1.  MTB 2.0/2.1 CE list(left) and MTB 2.2 CE list(right) in Project Creator

  2. In MTB 2.0/2.1, the wiced_btsdk repo needed to be cloned into the workspace before creating the application. In MTB 2.2, there is no need to create wiced_btsdk prior to the creation of app. The BTSDK apps include .mtb files for the Board Support Package (BSP) and the required libraries for the BSP are automatically detected and cloned into the shared library folder (mtb_shared) or in the libs folder in the project. Figures 2.1 and 2.2 show the difference.
      Figure 2.1. MTB 2.0/2.1 workspace vs MTB 2.2 BTSDK workspace

    Figure 2.2. MTB 2.0/2.1 BTSDK CE folder vs MTB 2.2 BTSDK CE folder

  3. The BSP and libraries can be shared or can reside locally in the project. When we say shared, it means that, all the apps created in the same workspace will use the same copy of the common libraries from the mtb_shared folder. New copies of the same shared libraries are not created for every new app. Use library manager 1.2 to make a BSP/library local or shared as shown in Figure 3 by selecting/deselecting the shared checkbox.
    Figure 3. Screenshot of library manager 1.2 to select a BSP/Library and make it shared or local

    If the BSP/library is shared, it will be created in the mtb_shared/wiced_btsdk folder. If the BSP/library is not shared, then it will be created in the libs folder in the project.

Steps to migrate an MTB 2.0/2.1 BTSDK application to the MTB 2.2 workflow


  1. Makefile Changes
    The makefile has changed significantly for BTSDK applications. Download the makefile and make changes to the following makefile variables according to your app:
        a. TARGET – the default target
        b. APPNAME – name of your project
        c. Copy any other app specific makefile variable from your MTB 2.0/2.1 CE makefile
        d. Save the makefile with the changes
        e. Copy this makefile and replace with the existing one in your app folder

  2. Adding deps folder and BSP/libraries to the application
    Library manager 1.2 must be used to add or update any BSP or libraries. Launch the library manager 1.2 tool from the start menu or go to the MTB installation folder and navigate to this path: ModusToolbox\tools_2.2\library-manager. From here launch the library manager 1.2 tool.
    a. Select the directory of your application using the browse option as shown in Figure 4.
    Figure 4. Screenshot of Library Manager 1.2 highlighting the ‘browse’ option

    Alternately, from the command line (modus-shell on Windows or from a command window on MacOS or Linux), navigate to the project directory and enter “make modlibs”. This will launch the library manager and will provide the correct directory.

    b. Next, select the required BSP from the ‘BSP’ tab. The dependency libraries are selected automatically. Select any other required libraries (ex: mesh, HID etc…) from the ‘Libraries’ tab.
    c. Click on the update button at the bottom right corner of the library manager. Wait for it to successfully update the BSP and libraries.

    d. Close the library manager. Now you can observe that in your project folder two new folders called deps and libs are added. Deps and libs contain the .mtb files of the BSP/libraries you selected in previous step and the dependency libraries, respectively.
    e. In the project directory, you can see that a new folder called ‘mtb_shared’ is created. If you navigate inside the folder into wiced_btsdk, you can see the BSP/library folders downloaded. This is the shared library that we talked about earlier in the blog.

  3. Update the Readme file of your project if required.
  4. Update the .gitignore file in your app if present. You can refer to the example .gitignore file. This is useful if you are maintaining your project on github.
  5. Open the .cybt  file present in your app with bt-configurator 2.20.0 tool (can be launched from the start menu or found in the MTB installation folder: ModusToolbox\tools_2.2\bt-configurator). Check the notice list in the bt-configurator for any changes required. If required, do the necessary changes and save the file.
    Alternately, from the command line (modus-shell on Windows or from a command window on MacOS or Linux), navigate to the project directory and enter “make config_bt”. This will launch the Bluetooth configurator and will open the .cybt file.
  6. All required changes have now been done for your app to work with the MTB 2.2 unified workflow. If desired, you can import your project into the Eclipse IDE for MTB 2.2 using the Eclipse IDE for MTB 2.2 menu item File > Import > ModusToolbox > ModusToolbox Application Import.
  7. Now you can build/clean/program/debug your application from the IDE and use any MTB 2.2 tool. You can use library manager 1.2 to update your app to use local/shared library or add/remove any BSP/library.



With wiced_btsdk 2.8, if you add more than one BSP to a project, the build will result in an error. Refer to the Bluetooth SDK 2.8 Release Notes.

To work with a different BSP, use library manager and remove (deselect) the older BSP, select the new BSP and update. Note that in a single project you can have only the BSP/BSPs of the same chip, but in a workspace if you have two or more projects, each one can use a different BSP.


Developing legacy WICED BT projects in ModusToolbox requires the shared project wiced_btsdk to be correctly configured in the workspace. For details creating project wiced_btsdk, see below:

GitHub - cypresssemiconductorco/wiced_btsdk: BTSDK (headers, libraries, chip and BSP files, peer/host applications, buil…


Q: Will Library Manager do the work?

Normally, to update the libraries in a project, we use Library Manager provided by ModusToolbox.

In this case, Library Manager won't give much help here. Because it can only update the Libraries and WICED BSPs inside the project wiced_btsdk, while it can't update the whole project itself, a.k.a. the framework. So if only Library Manager is used, then you will be using the latest BSPs via the old wiced_btsdk framework, which will cause you errors. (This is because the directories like btsdk-include in wiced_btsdk will stay in older version in this situation, which won't provide the correct reference to the latest BSPs).

We notice that, wiced_btsdk is managed by Git, a version control system. Hence we can use Git to update the entire project to the latest version, to avoid the issue stated above.

So this blog illustrates how to use Git to update wiced_btsdk in ModusToolbox. For better practise, the demonstration uses Eclipse IDE for ModusToolbox 2.2.


Q: Can I only follow the universal process of using Git in Eclipse to get the job done?

Normally, to update a project in Eclipse, you can right-click on wiced_btsdk and then choose Team => Pull.... Somehow this universal process doesn't fit in wiced_btsdk because it adopts different library management in it.

In order to update wiced_btsdk soundly, you should follow the flow stated below.


Q: Will this blog apply to ModusToolbox 2.2 or later?

The answer only depends on whether the project wiced_btsdk exists in your workspace. The version of ModusToolbox is irrelevant.

If you import the latest version of WICED BT code examples that support MTB flow, then it won't require the project wiced_btsdk (Instead wiced_btsdk and it's BSPs are moved to the new shared project named mtb_shared). So the project wiced_btsdk won't exist in your workspace. Hence this blog won't apply to this situation. This kind of projects follow the unified workflow and they are called the unified MTB projects in this blog.

But if you insist to develop WICED BT applications in the legacy style (i.e. staying in the old versions of the code examples) that support LIB flow, then the project wiced_btsdk is still needed and wiced_btsdk probably exists in your workspace already. Hence this blog will apply to this situation. This kind of projects follow the legacy workflow and they are called the legacy MTB projects in this blog.

In other words, all versions of ModusToolbox (<MTB2.2 or >=MTB2.2) support legacy MTB projects. Since wiced_btsdk is a legacy MTB project, this blog applies to all versions of ModusToolbox, including 2.2 or later.

In fact, the main purpose of this blog is trying to enable the legacy WICED BT projects to get the latest wiced_btsdk (2.8.0 or later) while preserve the old developing workflow.

This is useful when you have a heavily customized legacy WICED BT projects that you have difficulties migrating it to unified MTB projects, but you still want to get the latest wiced_btsdk and the latest ModusToolbox for it.

Besides, this blog applies to all ModusToolbox projects in all versions of ModusToolbox, no matter what dependency flow it follows (LIB flow or MTB flow), and what version ModusToolbox is, (<MTB2.2 or >=MTB2.2). This is because, It's merely about version control. It's not about dependency flow or ModusToolbox features.



  1. Right-click on wiced_btsdk, and then choose Team => Remote => Fetch from....
  2. Click on the button Finish.
  3. Ensure all the new refs have been fetched, and then click on the button Close.
  4. Right-click on wiced_btsdk, and choose Team => Reset....
  5. Now you can see all the versions of wiced_btsdk in Tags, including the latest one. Choose the latest version, select Reset Type to Hard, and then click on the button Reset.
  6. After the Reset process completed, you should see that the project wiced_btsdk has been reset to the latest version v2.8.0 from previous v2.6.0. But the sub-directories / libraries inside it remain in v2.6.0. This is the issue we are trying to avoid.
  7. To fix this, right-click on wiced_btsdk and choose Build Targets => Create....
  8. Create the build target getlibs. Configure as below and click on the button OK.
  9. Then you should see the build target is created under wiced_btsdk. Double-click on it to run the build target. This action may last for a few minutes.
  10. When the last action finishes, you can see now the sub-directories/libraries inside wiced_btsdk should all be updated to the latest version, aligning with wiced_btsdk itself.
  11. (Optional) Sometimes you can get exceptions. You might find that some of the sub-directories stalls in the previous version. This can be confirmed by the console log, with lines saying some sub-directories were skipped to be updated, as below.

    This is because uncommitted/untracked files in these sub-directories are detected, which means the files inside them might have been altered manually or unawares. So these directories are skipped for safety.
    Before going on, you should take care of these changes, or make sure the changes can be discarded. Then you can correct these directories to the desired version by one of the two steps below, and finally you should have all sub-directories updated, nice and clean:
  • a) Right-click on these directories respectively (not wiced_btsdk) and choose Team => Reset.... Then reset them to the latest version respectively. The steps are similar to the steps [4]~[5] resetting wiced_btsdk, stated above.
  • b) Close ModusToolbox, go to the folder of wiced_btsdk, manually delete these sub-directories inside wiced_btsdk, re-open ModusToolbox and run the build target getlibs again.



  1. You may relate this flow to the feature --recurse-submodule provided by Git. But in fact wiced_btsdk doesn't rely on this feature. So you can only use the build target getlibs to update the sub-directories.
  2. You can also rollback/switch between the versions of wiced_btsdk, following the same flow above. Do this by choosing the version tag you want, instead of the latest one.
  3. Other ModusToolbox project governed by Git can use the same flow above to update/rollback, too.
  4. Sometimes you may want to rollback/switch only some of the sub-directories (e.g. merely rollback 20706A2 to v2.5.0 in dev-kit\baselib), while other sub-directories remain the same, for experimental/temporary usage. In this case, the step [11-a] can also help you with this. But when it comes to BSPs/Libraries, you may better use Library Manager on this purpose for smoother experience.
  5. The flow above uses getlibs to satisfy the dependencies, that's whay the flow is compatible to the unified MTB projects and the legacy MTB projects. Because getlibs supports both LIB flow and MTB flow in ModusToolbox projects.



Welcome to the sixth session of the ModusToolbox Training Series!


In the previous session, Session 5: Introduction to Low Power Modes in PSoC 6 we learnt about different power modes available in PSoC 6 devices and how to use each of them in your application.


In this session, we will learn about the different analog peripherals available in PSoC6 devices. We will also see how to access each of the peripherals using HAL APIs, PDL APIs and Device Configurator available in ModusToolbox.


Duration: 1 hour




The exercises created as part of this training series have been tested to work on the following board. The exercises might need minor modifications if being used for a different board.

PSoC 6 WiFi-BT Pioneer Kit (CY8CKIT-062-WiFi-BT)



  1. Introduction to Programmable Analog Subsystem
  2. ModusToolBox Based Design
  3. Analog Peripherals Overview
  4. Digital to Analog Converter(CTDAC)
  5. Analog to Digital Converter (SAR ADC)
  6. CTBm Opamps
  7. Low Power Comparator (LPComp)
  8. System Analog Reference Block (AREF)
  9. Analog Routing


Using the Training Material:


The training material and exercises are hosted here: ModusToolbox training Session 6 Github Repository

In this blog, we will see how we can interface an OLED display with a PSoC 6 device and add it to our application to make a simple standalone system. We developed a ModusToolbox application to interface a DHT-11 sensor with a PSoC 6 device and print the values on a serial terminal application. Printing on a serial terminal implies that the device needs to be always connected to a PC which can be an inconvenience.

If you are new to the blog series, then you can refer to the previous blog here.


A quick description on the OLED display before we get started. There are many variations of OLED displays to choose from. I am using an OLED display module containing an SSD1306 controller that is manufactured by Solomon Systech Limited and a 128x64 pixel dot-matrix OLED. This is a monochrome OLED display and can be interfaced using the I2C interface. Additional information about this display can be found here.


At this point, you might be expecting me to talk about the driver files needed by the OLED display and how to write low-level I2C interface APIs to interact with the driver files. Now, what if I told you that we have a ready-made board utility library that you can use right off the bat? That’s right! We have one! To add to it, we can now use the emWin library with OLED displays. Isn't that cool!


We will start with the application developed in the previous blog. If you do not have the application, you can download it from here. Build and program the application once to confirm that you have the application set up and are ready to begin. To use the OLED display we need to import the libraries and we are going to do just that. Open Library Manager and enable abstraction-rtos (under Abstraction Layers), display-oled-ssd1306 (under Board Utils) and emwin (under PSoC 6 Middleware). After the libraries are imported, open the application makefile, and add EMWIN_OSNTS and FREERTOS to the COMPONENTS variable as shown:




Just a few more steps, we are almost there. Copy FreeRTOSConfig.h file from <makefile_directory>/libs/freertos/Source/portable directory to <makefile_directory>/source directory. The <makefile_directory> is the directory in which the application makefile exists. The makefile will now consider the copied FreeRTOSConfig.h (in the source directory) and ignore the .h file in the libs directory. Now we need to make the following edits in the FreeRTOSConfig.h file that we copied to the source directory: 

  1. Comment “#warning This is a template” line
  2. Change the values of configUSE_MUTEXES and configUSE_RECURSIVE_MUTEXES macros to 1 like this –

          #define configUSE_MUTEXES                       1

#define configUSE_RECURSIVE_MUTEXES             1


All done? Good! We now have the libraries needed for our application set up. Go ahead and build the project to ensure the libraries are set up correctly.


Next, create oled_task.h/.c files which will have the OLED Task for our application. The first step is to initialize the display and the libraries. To do that:

  1. Include mtb_ssd1306.h and GUI.h
  2. Initialize I2C peripheral using the I2C HAL Driver
  3. Initialize the OLED display using mtb_ssd1306_init_i2c() API
  4. Finally, initialize the emWin library using GUI_Init() API

If you are stuck or face any issues with the above steps you can refer to the Display OLED SSD1306 Guide. After you are done with these steps, your OLED task should be something similar to this:

You can now use the emWin library APIs in your task to interact with the OLED display. emWin Library has a vast set of features and I will not be covering all the features in this blog post. Refer to the emWin Graphics Library Guide for more information on all the features available. Let me explain what I have done so that you can try and replicate the same.


After initialization the OLED task performs the following functions:

  1. Displays the Infineon + Cypress logo
  2. Displays the tagline
  3. In the loop, it continuously updates the humidity and temperature readings


Digging into each of these functions in a little more detail:


Displaying the logo:


Just showing the humidity and temperature will achieve our end goal but to make things a bit more interesting I decided to display the Infineon + Cypress logo and the tagline. This way I get to learn how to display images using emWin! To display an image you will have to first convert the image into a C structure. How do you do that? I will get to this question at the end of this blog. If you know how to do that, great! If not, for now, let's assume we have the structure ready. Once you have the C structure, you first need to set the colour of the image and the background colour and then display the image using the emWin API - GUI_DrawBitmap(). The image needs to stay for a while for us to perceive the image, so a delay is added and then the display is cleared each time using GUI_Clear().


Displaying the tagline:


This functionality is more straightforward as it is just displaying the text. A few APIs that prove to be useful:

  1. GUI_SetTextMode() – You can use this API to reverse the foreground and background colour, invert the colours, etc.
  2. GUI_SetFont() – Sets the font to be used for text output.
  3. GUI_SetTextAlign() – Sets the alignment for the text in both the X and Y-axis.

Finally, I have used the GUI_DispStringAt() API to display the text at the specified X and Y position (in pixels) respectively on the OLED display.


Displaying the sensor readings:


Before we get into displaying the sensor readings we will have to consider one more key aspect – how to receive the sensor readings from the DHT task. Previously we had used xQueueReceive() API in the Print task to receive data. We cannot do the same here because the API removes the data from the queue when reading from the queue. So, only one task will receive the data. We can use the xQueuePeek() API which just reads the data from the queue without removing the data. Sounds good? Not really. We now have another problem in our hands. The queue is never cleared so how do we inform the tasks that the elements in the queue are updated? I could think of 2 approaches to tackle this issue:

  1. All tasks except the lowest priority task (Print task in this case) peeks and the lowest priority task clears the queue using the receive API. In this case, we will have to ensure that the Print task is always executed last and it is executed every time the queue is updated without fail. This might cause synchronization issues especially when there are a lot of tasks in the application.
  2. Use FreeRTOS notifications to notify each task that the queue is updated. This works. But we will have to create a new task notification for each new task added to the application which can become a bit messy. On the same lines, we could use an event group to notify each task when the queue is updated and I decided to go with this approach. If you have a better approach to tackle this issue please leave a comment. I would love to know about it and learn.


Now that we can get the data from the DHT task we will have to display this data. I have used the same APIs again to display the strings ‘Humidity:’ and ‘Temperature:’. To display the float temperature and humidity values I have used the GUI_DispFloat(). This API also takes in the number of characters to display (including the decimal point) and I have specified 5 characters in this application.


That’s pretty much it for the OLED task. Few modifications to the other tasks to incorporate the new developments in the other tasks like the event group etc and you should be good to go! Like before, the entire application is shared on our Community Code Examples Git Repo and you can check it out using this link. Hope you have fun trying it out! To make things a little more interesting, you can try using EInk or TFT displays and experiment with emWin a bit more to customize the application. You can use our code examples as a reference. Created something cool? Feel free to share it with the community  




Now let me get back to the question as promised,

How do I convert an image to a C structure?


For this, I used a tool – Segger Bitmap Converter. Download and install the tool. After the tool is set up, click on File > Open and select the image that you want to convert to a C structure. For example, I will select an image of PSoC 6 and the image should open in the tool as shown:

The first thing to do is to reduce the image size to fit the display that you choose. For the OLED display that I am using, I need to reduce it to something less than 128x64. To do this, click on Image > Scale and you can reduce the size in the window that appears:

Next, we will have to make the image monochrome. Click on Image > Conver to > BW

It's ready to be converted to a C structure! Click on File > Save As and give a name to the C file. Next, select 1 bit per pixel in the Format specifications window and click Ok. A .c file will be generated and you will find a similar structure in the file:

You can extern this structure and use it in your application.

There is an entire section dedicated to 2D Graphics in the emWin User Guide and Reference Manual. A lot of fascinating features, do check it out!


Welcome to the fifth session of the ModusToolbox Training Series!


In the previous session, Session 4: AnyCloud WIFI Design Flow, we learnt about AnyCloud WiFi Design Flow and how to build basic WiFi applications in ModusToolbox using the WiFi Connection Manager Library.


In this session, we will learn about the low power modes in PSoC 6 devices - why is low power important? what are the different low power modes available? and how to use these low power modes in your application? We will also go through some of the advanced features of low power in PSoC 6 and a few additional steps that you can inculcate in your application to reduce the current consumption of your device even further.


Duration: 60 mins



The exercises created as part of this training series have been tested to work on the following board. The exercises might need minor modifications if being used for a different board.



  1. Introduction to Low Power MCU systems
  2. Overview of different power modes available in PSoC 6
  3. System and CPU power modes
  4. Overview of CPU power modes:
    1. CPU Active
    2. CPU Sleep
    3. CPU Deep Sleep
  5. Description of each system power mode:
    1. System LP
    2. System ULP
    3. System Deep Sleep
    4. System Hibernate
  6. Resources available in each power mode
  7. Wake up sources
  8. Transitioning between low power modes
  9. Power mode transition callbacks
  10. Power reduction techniques
  11. Factors affecting the current measured
  12. Overview of back-up domain resources
  13. References


Using the Training Material:

The presentation used in the video is attached to the blog.


The training material and exercises are hosted here: ModusToolbox Training Session 5 Github Repository


Have any Questions?

Feel free to drop in your queries in the Cypress Developer Community.

In the previous blog, I shared the PSoC Creator projects to interface a PSoC 6 device with the DHT-11 sensor. The previous blog also covered details regarding the DHT-11 sensor and its working. In this blog, we will be creating the project on ModusToolbox 2.1 to achieve the same functionality with a few additional features. You can download ModusToolbox 2.1 here and learn about the new exciting features of ModusToolbox 2.1 release here.


We will start by creating an Empty_PSoC6_App. You can create a new project by clicking on New Application in Quick Panel. Select the BSP of your choice. I will be using the CY8CPROTO-062-4343W Kit for this blog. Select the Empty_PSoC6_App, you can rename the project if needed. Click on Create. You can even create the project using the CLI option which you can learn more about here.


Now that we have an empty project ready, we need to add the libraries that we will be using for this project. In this project, we will be using the retarget-io and the FreeRTOS middleware libraries. To do that, click on Library Manager under Tools in the Quick Panel and select retarget-io (under Board Utils) and freertos (under PSoC 6 Middleware) as shown. You can now build the project to confirm that there are no errors so far. The ‘project directory’ is now the ‘application directory’. So, in this case, the application directory will be the folder Empty_PSoC6_App or the name of your application in case you have renamed it.

I have predominantly used the code from the Temperature_Sensor_Direct project from my previous blog. The PSoC Creator project was created using PDL. The project would still work if I just copy the entire code and place it in the main.c file. All I have to do is select the right pin in the Device Configurator and name it accordingly. But the problem here is that this makes my project device-dependent. What I mean by this is that if at all I change my device, I will have to reconfigure the pin.  With the release of ModusToolbox 2.0 and 2.1, you would have noticed most of us talk about ‘device agnosticity’. The idea is that the project should work without any changes even when the device is changed. If you are just curious and you want to try out your project on all your devices or if you are as fickle-minded as I am you will soon realize that this is a lifesaver, especially in a project that uses a lot of hardware blocks.


To achieve that, I will be using the Hardware Abstraction Layer (HAL) and the Board Support Package (BSP) feature. HAL allows me to easily initialize all my hardware resources in my source code and BSP takes care of the pin allotment of some of the common resources in each device. For example, if I have to use an LED that is on my kit, I can just use the CYBSP_USER_LED macro. This macro is defined specific to each device. Now even if I change my device, I can be assured that I will be using the appropriate LED pin itself. I will be talking in detail about how these features are used in the project when going through each of the source files.


In this project, I have also used FreeRTOS to create separate tasks so that each task can just be picked up and used in any FreeRTOS project.


To keep the code modular and perspicuous, I have separated the application into three source files –

  • main.c
  • print_task.c
  • dht_task.c


main.c file contains the initialization code and the task creation code. You can consider this as the master code and in this file, the FreeRTOS scheduler is started. All the pin/middleware initialization code can be found here. The code first initializes the device and board peripherals and the hardware manager. Next, the retarget-io is initialized. Retarget-io allows you to transmit messages to and from the board via standard printf/scanf functions using a UART SCB block. Just by including cy_retarget_io.h file and initializing the middleware you can use printf and scanf statements directly. So, it saves the time and effort needed to manually map the printf/scanf functions to the UART block. The DATA pin is initialized as shown below –

Each HAL API starts with cyhal followed by the name of the driver and then the functionality. In this case, the API initializes a GPIO pin. The LED is also initialized in a similar way. You can refer to the following link to learn about the different HAL drivers and their usage: HAL Documentation.

The next part is the initialization of FreeRTOS objects. A queue is used for communication of sensor readings between the tasks. The queue-handle is passed as an argument to the tasks. The two tasks, namely, DHT_Task and Print_Task are created with DHT_Task having a higher priority.


Moving on to dht_task.c file. As I have mentioned before, this primarily consists of the code used in the Temperature_Sensor_Direct project. I have changed the PDL functions to its HAL counterparts –

  • CY_GPIO_Write()         =>      cyhal_gpio_write()
  • CY_GPIO_Read()         =>     cyhal_gpio_read()
  • CyDelay()                       =>     cyhal_system_delay_ms()
  • CyDelayUs()                  =>      cyhal_system_delay_us()

The task reads the sensor values and if the value is valid, an LED is toggled, and the readings are sent to a queue. If the queue is full, the task will wait until the queue has a vacancy.  Now in case there is a connection failure or the sensor values read are not valid, the error code along with the previous data is sent to the queue. As the sampling rate of the sensor is approximately 2 seconds the task then goes into the blocked state for 2 seconds. After this, the cycle repeats.


print_task.c, as the name suggests, contains the Print_Task function. This task has the lowest priority and executes only when all other tasks are in the blocked state. It receives the sensor reading from the queue and prints the value into the serial terminal. If the queue is empty, the task enters the blocked state until DHT_Task sends the reading to the queue.


I have attached all the .c/.h files, put in source folder, with this blog. You can go ahead and place this folder in the application directory of the new project that you created and delete the default main.c that was in the project. That’s it! The auto-discovery feature in ModusToolbox will take care of the rest. No more ‘Add to Project’!


You can build the project, program the device, and connect the sensor and voila! you now have a simple FreeRTOS project to read the temperature and humidity value using the DHT-11 sensor and print it on a serial terminal. The best part is that it is a ModusToolbox 2.1 project! For your reference, the entire project is shared on our Community Code Examples Git Repo and you can check it out using this link. To know how to import the project, refer to the ReadMe file.


Hopefully, by now you will have a basic idea on how to use ModusToolbox 2.1 to develop simple FreeRTOS applications.


Here are a couple of things you can do next:

> Try changing the BSP in Library Manager and programming a different device to check out the device-agnostic feature.

> The task is in the blocked state for 2 seconds which means that the PSoC 6 is in the idle state most of the time. You can try exploring the low power capability of PSoC 6. Keep in mind that you should be using the Tickless Idle Mode capability of FreeRTOS for this to work. You can use this code example for reference - CE223508 – PSoC 6 MCU Implementing BLE Multi-connection (4 Slaves)

> You can combine this task with any other FreeRTOS task and create an application. Feel free to post your cool applications and share them with the community!


Welcome to the fourth session of the ModusToolbox Training Series!


In the previous Session 3: Introduction to CapSense in ModusToolbox , we learnt about CapSense in ModusToolbox and how to built basic CapSense applications using CapSense Middleware Library.

In this session, we are going to introduce you to the AnyCloud WIFI Design Flow. The session starts with a brief introduction to different software architectures (Mbed, AFR and AnyCloud), followed by AnyCloud Stack. You will get insights on how to build basic WiFi application in Modus Toolbox using the WiFi Connection Manager Library. You will also learn about the required libraries or the minimum set of libraries for getting started with WiFi (WCM, WiFi Middleware Core, Secure Sockets, WHD). In the end, an interesting demo project will help you create your own basic TCP application in Modus Toolbox. Let’s get started!


Duration: 90 mins



The exercises created as part of this training series have been tested to work on the following boards. The exercises might need minor modifications if being used for a different board.





1.  Software Architecture – AnyCloud / AFR / Mbed

2.  AnyCloud Stack

3.  AnyCloud WiFi Libraries

        a. Using Library manager to add Wi-Fi to a PSoC 6 project in AnyCloud

        b. Middleware Core Libraries

        c. Wi-Fi Connection Manager (WCM)

        d. Secure Sockets

4.  WICED Wi-Fi Driver

5.  WHD WiFi Host Driver

6.  Demo – TCP Client

7.  Abbreviations

8.  References


Using the Training Material:

The presentation used in the video is attached to the blog. Jump to 2:08 in the video to get started with the session.






The training material and exercises are hosted here: Community-Code-Examples/mtb_training/session04 at master · cypresssemiconductorco/Community-Code-Examples · GitHub

You can also refer to the documentation tab in the MODUS toolbox that gives you more insights on all the required WiFi libraries (Secure Sockets, WHD, WCM and Middleware Core Library).



Have any Questions?

Feel free to drop in your queries in the Cypress Developer Community.

ModusToolbox supports various build tools used to build the application. ModusToolbox currently uses GCC version 7.2.1 by default. To specify a different toolchain, normally you can modify the file "Makefile" which is under the root directory of your project in ModusToolbox and set the variable "TOOLCHAIN" to other supported values. See below:

Currently ModusToolbox officially supports 3 options: GCC_ARM, ARM and IAR. If you specified ARM or IAR, the correspondent toolchain should be installed by yourself as prerequisite. And you should also specify the path to the desired toolchain using the variable "CY_COMPILER_PATH". See below:

For the most concerned details, please refer to ModusToolbox™ User Guide, Document Number: 002-29893. This blog is intended to give extra information on this.


As we all know, ModusToolbox supports two categories of projects: PSoC 6 projects and WICED Bluetooth projects. One important finding is that the actual supported options may differ according to the project type. To find out the actual supported options of your project, you can execute the following command (within the Cygwin environment and change the working directory to your project directory):


For example, under PSoC 6 projects I got the following result:

The result shows that it actually supports 4 options: GCC_ARM, IAR, ARM, and A_Clang.

But under WICED Bluetooth projects, I got the following result:

The result shows that it only supports 1 option: GCC_ARM.

So if you are facing problems using other toolchains, before you proceed, you can check whether your project actually supports the toolchain you desired, using the command given above.

Welcome to the third session of the ModusToolbox Training Series!


In the previous session, we learnt about Digital Peripherals on PSoC 6 and how you can interact with them using the HAL, the PDL, and the BSP.


In this session, we are going to introduce you to the industry-leading capacitive touch sensing solution, CapSense. You will learn how to build basic CapSense Applications in Modus Toolbox using the CapSense Middleware Library. This session has interesting demo projects at the end to get started with building your own CapSense application!


Duration: 90 mins



The exercises created as part of this training series have been tested to work on the following boards. The exercises might need minor modifications if being used for a different board.



  1. Introduction to CapSense Technology
  2. CapSense Widgets
  3. Self Capacitance vs Mutual Capacitance sensing
    • When to use Self Cap, When to use Mutual Cap
  4. Introduction to CapSense Hardware Architecture
  5. Basic Terminologies to understand this training
  6. CapSense Performance Tuning
    • SmartSense
    • Manual Tuning
  7. CapSense Middleware Library
  8. ModusToolbox CapSense Configurator Tool
  9. Build your first CapSense Project
    • CapSense Initialization
    • Scanning and Processing
    • Checking Widget Status
  10. CapSense Data Structure
  11. CapSense Tuner GUI
    • Adding CapSense Tuner Support using EZI2C interface
    • Viewing CapSense Raw data
    • Tuning your sensors at run time!
    • Measuring Signal to Noise for your sensors
  12. Advanced Topics
    • Firmware filters
    • Multi Frequency Scanning
    • Pipeline Scanning using Low Level APIs
    • Liquid Tolerance in CapSense Designs
    • Built in Self Test
    • Gestures detection in CapSense
  13. Resources


Using the Training Material:

The presentation used in the video is attached to the blog. Jump to 1 : 43 s in the video to get started with the session.


The training material and exercises are hosted here: ModusToolbox Training Session 3 Github Repository


Have any Questions?

Feel free to drop in your queries in the Cypress Developer Community.

Welcome to the second session of the ModusToolbox Training Series!


In the last session, we set up ModusToolbox, got an overview of the software but we didn't exactly get our hands dirty by creating any applications.


In this session, we are going to learn all about Digital Peripherals on the PSoC6 and how you can interact with them using the HAL, the PDL, and the BSP. This session comes packed with plenty of exercises and by the end of it, you will have sufficient knowledge to create applications on our own!


Duration: 90 mins



The exercises created as part of this training series have been tested to work on the following boards. The exercises might need minor modifications if being used for a different board.



  1. A quick recap of Session 1
  2. What’s new in ModusToolbox 2.1?
  3. Introduction to Digital Peripherals
    1. PSoC 6 Device Architecture
    2. PSoC 6 Digital Peripherals
      • Programmable Digital
      • Fixed Function Digital
  4. High-Speed Input / Output Matrix (HSIOM)
  5. Smart-IO
    1. Smart-IO Configurator
    2. Look-up table (LUT)
    3. Using Smart-IO in your application
    4. Exercises
  6. TCPWM
    1. Overview
    2. Counter functionality
    3. Understanding HAL
    4. Using Timer in your application using HAL and PDL
    5. Using Counter in your application using PDL
    6. Using PWM in your application using HAL and PDL
    7. Exercises on TCPWM
  7. Serial Communication Blocks (SCB)
    1. Introduction to UART / SPI / I2C
    2. Using SCBs in your application using HAL and PDL
    3. Exercises on SCBs
  8.   Resources


Using the Training Material:

The presentation used in the video is attached to the blog. Jump to 4:15s in the video to skip the general introductions and get right to the training.


The training material and exercises are hosted here: ModusToolbox Training Session2 Github Repository


The file Exercises_ReadMe.pdf attached to the blog highlights the steps to import the exercises into ModusToolbox and use them.


In the next session, we will learn about Cypress's industry-leading capacitive touch sensing solution CapSense and how we can create exciting applications using it in ModusToolbox.


Have any Questions?

Feel free to drop in your queries in the Cypress Developer Community.

ModusToolbox software is a set of multi-platform development tools and libraries that lets you create interesting applications on your favorite Cypress kits. Due to its vastness, understanding all the features and aspects that come with it might be a challenge! They say a picture speaks a thousand words, so having a video series, you can only imagine how helpful they will be to accelerate this process and we have done just that.


Introducing the ModusToolbox Training Series!


In the first session, we will have a deep dive into the world of ModusToolbox and understand all the features and capabilities on a high level!


Duration: 90 mins



  • Download ModusToolbox™ 2.1 from here.
  • Follow the steps to install it here.
  • Once installed, follow the steps mentioned in the Getting Started Guide to create your first application.



  • If there are firewall restrictions, you need to follow a couple more steps to get your environment configured as mentioned here.
  • If the user name on your system contains spaces or special characters, follow the steps mentioned in the User Guide to install ModusToolbox at a custom location.
  • If application creation fails, please refer to this KBA to get your environment cleaned.
  • Once the application is built, program the kit.
  • If you’ve reached this stage, great! You’re ready for the training!


(OPTIONAL) To understand the training better, take some time to go through the following material:



The exercises created as part of this training series have been tested to work on the following boards. The exercises might need minor modifications if being used for a different board.



  1. Introduction to ModusToolbox 2.0
    1. What is ModusToolbox?
    2. What comes with the installer?
    3. Design Goals
    4. Where is the SDK?
  2. Core Tools
    1. Build Infrastructure
      1. Introduction
      2. Creating a project
      3. Autodiscover and project creation
      4. Libraries, .lib files and make getlibs
  • Library Manager
  • Creating an executable
  • Building code from within the IDE
  • Program and Debug
  1. Configurators and Tools
    1. Introduction
    2. New configurators and tools
    3. Utilities
    4. ModusToolbox IDE
  2. Software Enablement
    1. Introduction
    2. Low-level resources
    3. Peripheral Driver Library (PDL)
    4. Hardware Abstraction Layer (HAL)
    5. Board Support Package (BSP)
    6. PDL, HAL, BSP, what do you use?
    7. Middleware
    8. Code examples
  3. Supported Ecosystems
    1. PSoC6 MCU and Bluetooth SoC Ecosystem
    2. MbedOS Ecosystem
    3. Amazon FreeRTOS Ecosystem
    4. Amazon FreeRTOS Libraries
  4. Resources


Using the Training Material:

The presentation used in the video is attached to the blog. All the materials that will be part of this training series can be found here: ModusToolbox Training Github Repository


This being an introductory session does not have any exercises. In the next session, we will look at the Digital Peripherals in PSoC6 and some cool exercises to crystallize your learnings.


Have any Questions?

Feel free to drop in your queries in the Cypress Developer Community.

This blog has the details of benchmark test performed for BLE GATT Throughput between Cypress BT SoC CYW20820/CYW20721 and different Android and iPhones.

The firmware used to perform the measurement is available on GitHub as a Code Example. Go through the Readme file associated with the code example to get a quick understanding of BLE throughput and the parameters used to tune it. Using this code example, you can easily perform the throughput measurement on your own with just a BT SoC based Cypress kit and your phone!


Let’s get started by checking out how the benchmarking is done.


Test Setup

To conduct this activity, CYW920820EVB-02/CYW920721EVB-02 were used as BLE GAP Peripheral and GATT Server with custom throughput measurement service. The iPhones and the Android Phones listed below were used as a BLE GAP Central and GATT Client:

  • Google Pixel 3
  • Google Pixel 3A                                
  • Samsung Galaxy S8
  • Samsung Galaxy S10 Plus
  • iPhone X
  • iPhone 11

The measurements were done for both 1M and 2M PHY. An MTU size of 515 was exchanged between both the devices and DLE(Data Length Extension) was enabled. The BT SoC is programmed to send a request for connection interval of 26.25 ms, but the interval chosen depends on the Central device. Ellisys Bluetooth Sniffer was used to collect BLE air logs for all measurements.

The data traffic is only one way, i.e., GATT notifications from the BT SoC (Tx) to the smartphone (Rx). But the code example can operate for two more modes of data traffic; First mode is where, the data traffic from smartphone (Tx) to BT SoC (Rx) and the second mode mode is where, the both the Tx and Rx operation of data happen simultaneously on both the devices. For these two modes, we need a custom feature in Android/iOS CySmart app which can send frequent, automated GATT write/notifications. The android/iOS apps currently available on Playstore/Appstore do not have this feature. So, the values presented here are for GATT notifications from BT SoC to smartphone.


Throughput rates for 2M PHY

The below table summarizes the results obtained for 2M PHY:


Test ID

BT SoC -> Phone


Connection Interval

BLE GATT Throughput


CYW20721 -> iPhone 11


26.25 ms

311 kbps


CYW20721 -> iPhone 11 Pro


26.25 ms

365 kbps


CYW20820 -> iPhone X


26.25 ms

340 kbps


CYW20721 -> Google Pixel 3


45.00 ms

1236 kbps


CYW20721 -> Samsung Galaxy S10 Plus


26.25 ms

1222 kbps


CYW20820 -> iPhone X


26.25 ms

362 kbps


CYW20820 -> Google Pixel 3A


45.00 ms

1303 kbps


CYW20820 -> Samsung Galaxy S8


26.25 ms

1320 kbps

Note: The throughput values are averaged for 15 readings.


By now, you might have observed that with the iPhone, we get a lesser throughput (with the same parameters exchanged) compared to Android. This is because, iPhone which is the LL master in the connection, is terminating the connection event length in a connection interval. Let us compare one connection interval captured by the sniffer for both Android and iPhone to understand this:


  One connection interval (26.25 ms) for Android: Samsung Galaxy S10 Plus

Screenshot (391).png


   One connection interval (26.25 ms) for iPhone: iPhone 11

Screenshot (390).png


Notice that, in case of Android, most of the interval (25 ms) is utilized for data transfer, whereas, in case of iPhone, the connection event is terminated by Central after 7 ms from start of the interval. 

This means, the remaining air time is wasted and not utilized for data transfer. This is the reason, for lesser throughput in case of iPhone for the negotiated parameters.


Throughput rates for 1M PHY

The below table summarizes the results obtained for 1M PHY:


Test ID

BT SoC -> Phone


Connection Interval

BLE GATT Throughput


CYW20721 -> iPhone 11


26.25 ms

130 kbps


CYW20721 -> iPhone 11 Pro


26.25 ms

82 kbps


CYW20820 -> iPhone X


30.00 ms

160 kbps


CYW20721 -> Google Pixel 3


45.00 ms

527 kbps


CYW20721 -> Samsung Galaxy S10 Plus


26.25 ms

222 kbps

Note: The throughput values are averaged for 15 readings.


Ellisys Sniffer Logs

A look into the Instant Throughput graph of entire data traffic captured by Ellisys Sniffer:


                                                             CYW20721 -> Google Pixel 3

Screenshot (387).png


Three Ellisys log files are attached with this blog for reference:

  1. Ellisys Sniffer logs for CYW20721 -> iPhone 11 (1M)
  2. Ellisys Sniffer logs for CYW20721 -> Google Pixel 3 (2M) and Samsung Galaxy S10 Plus (2M)



This project demonstrates using Cypress PSoC 4 AFE Shield with CYW920819EVB-02 Kit, to collect data from different sensors present on the shield board and send it over Bluetooth using a custom GATT service to the peer device.


Project Technology Focuses

  • CYW20819 MCU
  • Sensors
  • BLE

Project Requirements




Project Description

The objective of this project is to read the values from sensors on PSoC 4 AFE shield board and send it to peer BLE GATT Client using GATT notifications.


AFE shield board has temperature sensor, humidity sensor, ambient light sensor, CapSense, push buttons, potentiometer and an OLED display. PSoC 4 on AFE Shield processes the data from all the components mentioned above. The values are stored in PSoC 4 registers. Refer the AFE Shield kit guide for more information. CYW20819 reads data from AFE shield through I2C. A custom GATT server is configured on CYW20819 to frame the sensor data as shown below.


GATT notification data format

Byte (0 -3)

Byte (4 -7)

Byte (8 -11)

Byte (12 -15)

Byte 16

Byte 17

Byte 18

Byte 19




Pot value






Once the peer device subscribes for notifications, the sensor data is sent using GATT notification for every 500 milliseconds. Also, the data is displayed on the OLED and UART terminal console.




Running the Demo

Download the project files attached with this post ( and import into Eclipse IDE for ModusToolbox. Refer the user guide for importing existing projects into Eclipse IDE for ModusToolbox Flash the firmware and pair the board with CySmart windows/android/iOS application. Go to GATT DB and enable the notification in the app to see all the sensor values.




This project demonstrates how to interface the Infineon 3D Magnetic sensor with Cypress’ PSoC 6 wireless device and showcase an automotive use case example of knob control with TFT display.


Project Technology Focuses

  • PSoC 6 MCU
  • 3D Magnetic Sensor
  • emWin Graphics
  • FreeRTOS


Project Requirements




Project Description

The objective of this project is to read the 3D magnetic sensor data and display it on the TFT display. It mimics the use case of knobs for automotive and industrial application. The Infineon sensor TLE493D-A2B6 is a 3-dimensional magnetic sensor with I2C interface. The evaluation kit and Knob can be ordered from Infineon or distributor website.


Project Setup

To interface with Cypress PSoC 6 WiFi-BT Pioneer Kit, we need to break the sensor part from the Infineon evaluation board. The separated sensor part will have the following pin connections.


This separated board is interfaced with the PSoC 6 WiFi-BT Pioneer Kit using fly wires.The sensor board and Knob are separated by 3 to 5 mm air-gap and taped with the board using some double-sided tape.


Pin Details


Infineon 3D Magnetic SensorPSoc 6 WiFi-BT Pioneer Kit


The 3D Magnetic sensor is powered through the PSoC 6 MCU pin P6_2 (3.3v). PWM is used on pin P1_5 to control the brightness of the LED8. The PsoC 6 WiFi-BT Pioneer Kit is powered via Type C USB cable.



The CY8CKIT-028-TFT display shield board has a 2.4 inch TFT screen which is mounted on Arduino compatible pin headers of PSoC 6 WiFi-BT Pioneer Kit. The values obtained from the sensor is updated in TFT screen with the help of emWin graphics library.


Code Flow

Configure the Sensor

In this project we put the sensor in master controlled / power down mode and INT is disabled. Trigger option is used to start the ADC conversion in the 3D magnetic sensor. Refer the sensor datasheet for more details.

Two key registers must be configured to disable interrupt and enable trigger mode as shown below,

  • CONFIG (0x10)
  • MOD1 (0x11)

PSoC 6 I2C master clock is configured at 400 KHz. The sensor values are read with 20 ms interval. To obtain the angle of rotation refer to the application notes.


Running the Demo

To run this demo, Download the project files attached with this post ( and Import into ModusToolbox IDE. Open the CLI terminal and resolve the library dependencies by executing the 'make getlibs' command. Refer the user manual for importing existing projects into ModusToolbox IDE.

Rotating the Knob updates the fill bar and knob graphics in the display. Pushing the knob switches the control between the fill bars and highlights it.


The sensor values are sent to the UART console. Take a look at the demo in this video here



In the last blog, we created an EmptyPSoC6 application using the Command Line interface.


Today we will see how to build, program, and debug the ModusToolbox application all from the command line.  We will write code using Hardware Abstraction Layer (HAL) APIs and also have a short sneak peek into the Visual Studio Code (VSCode) features unlocked with ModusToolbox 2.1.


If you didn't already know, ModusToolbox 2.1 is now available and it comes with loads of new features. Click here to find out what’s new.


Let's begin! Navigate to the directory where you created your application in the modus-shell command-line.


To add code, we will be editing the main.c file using VSCode editor. ModusToolbox 2.1 adds support for VSCode making code development easier. Although it can be used as a fully-fledged IDE, we will be using the VSCode editor only to write code.

Using the command line, navigate to the application directory and run the command

>> make vscode

This command generates json files for debug/program launches, IntelliSense, and custom tasks. Once the command has finished execution, follow the instructions to open the files in VSCode as highlighted below. For more details, refer Section 7.3 Export to VS Code in the ModusToolbox User Guide here.

Once set up, open main.c. We will be developing using HAL APIs. So, type in “cyhal_gpio_” and press CTRL+SPACE. You will see the auto-complete feature offering suggestions.

Based on the hardware driver you want to interact with, type “cyhal_<driver>” to get the API suggestions.


Add the following code in main.c:

int main(void)
 cy_rslt_t result;

    /* Initialize the device and board peripherals */
 result = cybsp_init() ;
    if (result != CY_RSLT_SUCCESS)


    /* Initialize the USER LED (LED1) as OUTPUT pin in strong drive mode */

    for (;;)


Save the file. In the command line typemake buildto build your application.

Using the HAL APIs makes the code portable and device agnostic. make provides various options to control the build. To verify that the same code works for a different target board, you can add other BSPs by using the Library Manager. To invoke it run the command

>> make modlibs


Now select all the BSPs you want to test the code with and click Apply as shown below.

This will import all the necessary files for the BSPs selected into your application directory.


To build the application for a particular target, run the command

>> make build TARGET=<board_name>

Example usage:make build TARGET=CY8CPROTO_062_4343W”.


Once the build is complete, the hex file will be generated for the target at this path:



To program the kit i.e CY8CKIT-062-BLE, type

>> make program TARGET=CY8CKIT-062-BLE


You should observe the LED blinking on the kit.


To start a debug session, you can type

>> make debug TARGET=CY8CKIT-062-BLE

This will start a server which the GDB clients can connect to for debugging as shown below:

You can now open another terminal to use GDB to connect to the target for debugging. GDB is available with GNU Arm Toolchain which comes packaged with ModusToolbox in the path: “ModusToolbox\tools_2.1\gcc-7.2.1\bin\


We covered just a few options in make. As an exercise, explore the various options by running the command:

>> make help

Here are a couple of things to try additionally:

  • Program another BSP target without modifying the code and check if the LED is blinking. Run the following command for clues:
    >> make help CY_HELP=TARGET
  • Build the application using a Release build profile and then program the target. Run the following command for clues:
    >> make help CY_HELP=CONFIG
  • Identify the command that programs the application without rebuilding. Run it and check if it works as expected.


In summary, we learned how to create an application from scratch, write the application code using HAL APIs, build the application, program it and finally debug it, all without using an IDE.


In the next blog, we will see how to open the configurators and write code using the Peripheral Driver Library (PDL) APIs, all using the powerful make command-line options.

Filter Blog

By date:
By tag: