Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

Update wiced_btsdk to v2.8.0 in ModusToolbox

Update wiced_btsdk to v2.8.0 in ModusToolbox

Charles_Lai
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 sign-ins

/////////////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/hos...

 

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....
    pastedImage_0.png
  2. Click on the button Finish.
    pastedImage_0.png
  3. Ensure all the new refs have been fetched, and then click on the button Close.
    pastedImage_2.png
  4. Right-click on wiced_btsdk, and choose Team => Reset....
    pastedImage_3.png
  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.
    pastedImage_22.png
  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.
    pastedImage_23.png
  7. To fix this, right-click on wiced_btsdk and choose Build Targets => Create....
    pastedImage_24.png
  8. Create the build target getlibs. Configure as below and click on the button OK.
    pastedImage_7.png
  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.
    pastedImage_25.png
  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.
    pastedImage_26.png
  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.
    pastedImage_27.png
    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////////////////////////////////////////////////////

0 Likes
745 Views
Authors