Skip navigation
Home > All Places > Topics > Cypress Community Blogs > ModusToolbox Blog > Blog > Authors ChunleiL_51

ModusToolbox Blog

3 Posts authored by: ChunleiL_51 Moderator

/////////////Basics////////////////////////////////////////////////////

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.

 

/////////////Demonstration////////////////////////////////////////////////////

  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.

 

/////////////Note////////////////////////////////////////////////////

  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.

 

/////////////Reference////////////////////////////////////////////////////

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):

make help CY_HELP=TOOLCHAIN

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.

Note: This blog is DEPRECATED since ModusToolbox offline content package is provided. Read this blog for reference purpose only.

 

-----------------------------------------------------------------------------------------------------------------------------

 

Network connection problems to raw.githubusercontent.com could cause malfunctioning of ModusToolbox. In this case you may face the following issues:

 

  1. While trying to new a ModusToolbox IDE application, you see the blank list of Boad Support Package (BSP) shown below:

    And you could also find a log message in Console saying:
    Unable to open file at http://github.com/cypresssemiconductorco/mtb-super-manifest/raw/v2.X/mtb-super-manifest.xml. Some boards and apps may be missing. Check the logfile for a detailed error message.
  2. While trying to launch Library Manager, you see the logs shown below:
    Library Manager 100.814 Target : C Makefile Project: C:/Userg /mtw/wiced_btsdk Getting from remote Which will tell us available Apply super-manifest: https://github.com/eypressæmiconductorco/mtb-super-manife*/raw/vzx/mtb-super- manifest.xml Dm•mload of https://github.com/cypresssemiconductorco/mtb-super•manife*/rawmwmtb-super• manifest-vill failed; Connection dosed Failed to get SSP/ Library information.

 

This is because ModusToolbox needs the manifest files (mtb-super-manifest.xml, etc.) at the very beginning to initiate the following download procedures. But the manifest file could be compromised because it is actually hosted in the domain raw.githubusercontent.com which could be restricted in some regions due to the report of customers.

 

Further investigation shows that, the manifest files are the only files that could face the impact of restrictions, and none of the following download procedures (i.e. the cloning operation of Git client) would be touched. So a workaround to quickly solve this issue is that we could merely "hijack" the requests of the manifest files of ModusToolbox and redirect them to the locally stored ones. ModusToolbox will then find the proper manifest files and conduct the following actions successfully.

 

Before other solutions (like a complete offline repo source is officially provided as a standalone supplement) come out, this should be the easiest way to bypass the filtering and restriction issue in case you can't use VPNs / Tunnels.

 

///////////////////////////////////////////////////////////////////////////////////////////

 

Here are the instructions of it:

 

a) Download and install Fiddler.

 

b) Download the attached file and unzip it to directory "C:\".

 

c) Open Fiddler, and then do the following:

  1. Find "AutoResponder" tab in the main window and click it.
  2. Click the checkboxes "Enable rules" and "Unmatched requests passthrough".
  3. Click the button "Import...". Then navigate to and choose the file "C:\test\rules.farx".
  4. The final settings should be the same as the screenshot shown below:

 

d) Continue to setup Fiddler, in the following steps:

  1. Choose "Tools ==> Options" in the top menubar. Go to "HTTPS" tab in the pop-up dialogue, make sure "Capture HTTPS CONNECTs" and "Decrypt HTTPS traffic" is checked as shown below:

    Then permit and fire the operations automatically generated by Fiddler, which is essential for Fiddler to "hijack" the request of HTTPS, using Man-In-The-Middle strategy. If it is interrupted, you can click the button "Actions" to recover from it.
  2. Then make sure the item "File ==> Capture traffic" in the top menubar is checked as shown below, making it a proxy server system-wide:

 

e) Open ModusToolbox, then do the following:

  1. Open Preference dialogue by selecting "Window ==> Preference" in the top menu bar.
  2. Expand to "General => Network Connections" from the left menutree.
  3. In this tab, change "Active Provider" to "Native" and make sure the settings in this tab is like below:
  4. Click "Apply and Close" to save properly.

 

f) It's all set and done. Use "New Application" or "Library Manager" in ModusToolbox as usual and the boards or BSPs can now be seen and cloned properly:

 

g) How to undo?

Simply quit Fiddler.

The proxy settings in your system will be restored then. It should be automatically undone by Fiddler after you quit it.

And Since ModusToolbox is set to use system proxy settings, it will always be consistent with the system changes.

 

///////////////////////////////////////////////////////////////////////////////////////////

 

Trouble-shooting:

 

If you are still facing problems, please double check the key work noted below:

  • Make sure no "HTTP_PROXY" or "HTTPS_PROXY" is set in system environment variables. These variables could compromise "git clone" phase. Please note that Git client must be able to access github.com directly and independently in this workaround. And If you changed or delete these variables, remember to re-open ModusToolbox to make it work.
  • The global gitconfig of Git client could also lead to exceptions. There are several ways to verify and change it but I suggest that you do it in ModusToolbox. Open "Windows ==> Preference" and navigate to "Team ==> Git ==> Configuration", and then make sure that you won't see something like this below:

    And the best global gitconfig should be like this below (it would be best to add key http.sslVerify and https.sslVerify and set them to false):
  • Make sure the attached file is unzipped to the exact directory "C:\" otherwise Fiddler won't be able to find the xml files (or your should make sure you change the rules in Fiddler properly and point it to your location).
  • Make sure the "Capture traffic" is checked in Fiddler to ensure that project-creator or library-manager can get the xml files, too (because they don't follow ModusToolbox preference but comply to system proxy settings).
  • Don't use "Manual" proxy settings in ModusToolbox preference but use "Native" instead, to avoid unexpected errors or troubles.
  • Make sure Fiddler is decoding HTTPS and redirecting request properly. For example, A Complete "New Application" action could produce the following records in Fiddler. Make sure that purple lines can be seen (which indicates that the request matches with AutoResponder's rules and is redirected). Then make sure that "HTTPS" can be found at column "Protocol" (which indicates HTTPS requests are properly decoded):

Filter Blog

By date:
By tag: