Community Translated by NoTa_4591161       Version: **

Translation - English: Programming Fails when Changing Target in Makefile - KBA231391

質問： MakefileのTARGET変数を使用してターゲットBSPを変更すると、プログラミング中に次のエラーが発生します。

Error: timeout waiting for algorithm, a target reset is recommended

Error: SROM API execution failed. Status: 0x080008B4

Error: failed erasing sectors...

どうすればこれを解決できますか？

回答：このエラーは、接続されているデバイスとHexファイルの対象となるデバイスの間に不一致がある場合に発生します。MakefileでTARGET変数が変更されると、プロジェクトは新しいBSPを使用してビルドされます。 ただし、クイックパネルのLaunches セクションにある起動コンフィギュレーションには、これらの変更は反映されていません。それらは、古いBSPのHexファイルを引き続き指し示します。

間違ったHexファイルがプログラムされているためにエラーが発生します。これを修正するには、Generate Launches for <AppName> をクリックします。 正しいHexファイルを指す新しい起動コンフィギュレーションが生成されます。これで、正常にプログラミングできるようになります。

注：ライブラリマネージャを使用してBSPを変更することをお勧めします。これは、Makefile TARGETの編集と、起動コンフィギュレーションの自動再生成を処理するためです。ライブラリマネージャの[Active BSP]オプションを使用して、BSPを切り替えます。

Author: DheerajK_81           Version: **

Translation - Japanese: サイプレスタイトル - KBA231391 - Community Translated (JA)

Question: When I change the target BSP using the TARGET variable in Makefile, the following error occurs while programming:

Error: timeout waiting for algorithm, a target reset is recommended

Error: SROM API execution failed. Status: 0x080008B4

Error: failed erasing sectors...

How can I solve this?

Answer: This error occurs when there is a mismatch between the device connected and the device targeted by the hex file. When the TARGET variable is modified in the Makefile, the project is built using the new BSP. However, the launch configurations found in Quick Panel under the Launches section do not reflect these changes. They continue to point to the hex file of the older BSP.

The error occurs due to the wrong hex file being programmed. To fix this, click Generate Launches for <AppName>; the new launch configurations will be generated, which point to the correct hex file. You should now be able to program successfully.

Note: It is recommended to use the Library Manager to change BSPs because it handles editing the Makefile TARGET and regenerating the launch configurations automatically. Use the Active BSP option in the Library Manager to switch between BSPs.

Community Translated by NoTa_4591161       Version: **

Translation - English: ModusToolbox 2.2 and later: Make a Custom BSP - KBA231373

質問：
自分のハードウェア用のカスタムボードサポートパッケージ（BSP）を作成するにはどうすればよいですか？

回答：
この記事の手順に従ってください。この記事はModusToolboxv2.2以降を対象としています。このプロセスの一部の詳細が変更されました。ModusToolbox v2.1の詳細については、参照KBA230822を参照してください。

バックグラウンド

BSPは、ModusToolboxソフトウェアの中核です。キットごとにBSPを提供しています。BSPには（とりわけ）次のものが含まれます。

• キットのパーツのリンカスクリプトとスタートアップコード
• クロック、ペリフェラル、およびピンを設定するコンフィグレーションファイル（デフォルト名design.modus）
• ボードをサポートするために必要なライブラリの追加ファイル

カスタムBSPの場合、これらの要素はハードウェアに合わせて調整する必要があります。このKBAは、その目標を達成する方法を説明しています。ハイレベルで手順は簡単です。

1. 既存のBSPを使用してアプリケーションを作成します。
2. 既存のBSPに基づいて新しいBSPを作成します。
3. 新しいBSPを更新します。

新しいBSPには、design.modusファイルのコピーが含まれており、元のBSPと同じライブラリを使用します。このKBAは、汎用BSPから始まり、機能を追加する方法を示しています。これにより、ハードウェアの機能を追加できる最小限のBSPが実現します。汎用BSPは、すべてのPSoC 6MCUデバイスをサポートする最小の共通点です。ただし、ほとんどの例ではキットの機能が必要なため、サポートするコード例はごくわずかです。

別の方法として、より多くの機能を備えたキットBSPを使用してアプリケーションを作成できます。たとえば、設計で静電容量センシングを使用している場合は、CapSense機能を備えたキットにBSPを使用します。BSPが使用するデザインファイルとライブラリは、そのキット用に設定されています。より高性能なBSPから始める場合は、ハードウェアに一致するように機能を変更または削除しますが、ここで概説する原則は同じです。

手順1：既存のBSPを使用してアプリケーションを作成します。

1. ModusToolbox Project Creatorを使用します。この例では、PSoC6アプリケーションを作成します。スターターのBSPとしてPSOC6-GENERICを選択します。
2. [Next>]をクリックします。 
3. テンプレートアプリケーションを選択します。Empty PSoC6 Appを使用して名前を付け、ルートパスが新しいアプリケーションディレクトリを表示する場所であることを確認します。 
4. [Create]をクリックします。

Project Creatorが完了すると、アプリケーションディレクトリが作成されます。元のBSPは、アプリケーションディレクトリに隣接するmtb_sharedディレクトリにあります。ただし、実際にはどこにあるかを知る必要はありません。アプリケーションディレクトリで作業を行います。

ステップ2：新しいBSPを作成します。

1. コマンドウィンドウ（macOSまたはLinux）を開くか、modus-shellプログラム（Windows）を実行します。
2. makefileが配置されている新しいアプリケーションディレクトリの最上位に移動し、makebspコマンドを使用します。

このコマンドには3つのパラメーターがあります。

• TARGET_GENは、新しいBSPの名前です。
• DEVICE_GENは部品番号です。ボード上のパーツが既存のBSPと同じパーツである場合、DEVICE_GENはオプションです。
• ADDITIONAL_DEVICES_GENは、BSPでサポートされている追加パーツ（通常はWiFiまたはBluetooth無線デバイス）のオプションのパーツ番号です。

新しいデバイスの単純なケースを使用すると、コマンドは次のようになります。

$ make bsp TARGET_GEN = MyBSP DEVICE_GEN = CY8C6316BZI-BLF03

ModusToolboxビルドシステムは、アプリケーションディレクトリのトップレベルに新しいBSPを作成し、TARGET_という名前が付けられ、その後に名前を付けます。この例では、TARGET_MyBSPです。

新しいBSPには、パーツ固有のリンカスクリプトとスタートアップコードが自動的に含まれています。design.modusのファイルは、元のBSPと同じです。元のデザインが新しいパーツで機能しない場合は、エラーが表示されます。

この例では、新しいパーツを同じ周波数でクロックすることはできません。これらのエラーは次のステップで修正します。

手順3：新しいBSPを更新します。

主なタスクは2つあります。design.modusファイルのデバイス構成を更新することと、ライブラリを追加することです。新しいBSPの作成時に使用したアプリケーションには、makefileがあります。この例では、Empty_PSOC6_Appにあります。

1. そのファイルを開き、TARGET変数を変更して新しいBSPを指すようにします。     TARGET = MyBSP
2. 変更を保存します。次に、コマンドウィンドウで、このmakeコマンドを発行します
         make config

ビルドシステムは、新しいBSP /デバイスのDevice Configuratorを起動します。エラーを解決し、ハードウェアの必要に応じて設計を変更します。たとえば、この場合、PLL周波数をパーツでサポートされている値に設定する必要があります。

Device Configuratorに慣れていない場合は、ドキュメントを読んで、デバイスのクロック、ピン、ペリフェラル、およびその他の機能を有効にして設定する方法を学習してください。

BSPに含まれているライブラリは、TARGET_MyBSP/deps のディレククトリにあります。汎用BSPから始める場合、これらはデバイスに必要な最小限のライブラリセットを表します。各.libおよび対応する.mtbxファイルは、ライブラリファイルを含むgitリポジトリへのURLです。

注意 .mtbxファイルはMTBライブラリ管理フローに使用され、.libファイルはLIBライブラリ管理フローに使用されます。アプリケーションが使用するフローに応じて、ファイルの各ペアの1つだけが使用されます。各フローの説明については、ライブラリマネージャーガイドを参照してください。

BSPにライブラリを追加するには、対応する.libファイルと.mtbxファイルをこのディレクトリに配置するだけです。

キットBSPに基づいてカスタムBSPを作成する場合、追加のライブラリが存在する可能性があります。コード例を調べて、使用しているライブラリを確認することもできます。ModusToolboxライブラリはすべてGitHubで入手できます。

ステップ4：新しいBSPを使用します。

新しいBSPの設定が完了したら、好きな場所に移動できます。それは自己完結型のライブラリです。必要に応じて、BSPをバージョン管理システムにチェックインします。

このBSPを使用する方法はいくつかあります。ここにいくつか示します：

• 新しいアプリケーションを作成するときに、BSPをProject Creatorにインポートします。詳細については、Proeject Creatorガイドを参照してください。

• BSPディレクトリ全体をアプリケーションプロジェクトのルートにコピーします。
  • BSPの名前と一致するようにmakefile のTARGETの変数を更新します。
  • BSPの依存関係のために、アプリケーションのdepsディレクトリに.mtbファイルを作成します。これは、makeimport_depsコマンドを使用して実行できます。例えば：

make import_deps IMPORT_PATH=TARGET_MyBsp

• BSPファイルをIDEのアプリケーションプロジェクトに直接追加します。
  • makefileのTARGETを更新します。
  • BSPの依存関係のためにアプリケーションのdepsのディレクトリに.mtbファイルを作成します。これは、import_depsコマンドを使用して実行できます。例えば：

make import_deps IMPORT_PATH=TARGET_MyBspp

• 新しいBSPを使用するには、起動構成を更新する必要がある場合があります。

• gitを使用する場合は、BSPリポジトリを指す.mtbファイル（MTBフローを使用する場合）または.libファイル（LIBフローを使用する場合）を作成し、そのファイルをアプリケーションのdeps（依存関係）ディレクトリに含めます。コード例を調べて、これがどのように行われるかを確認してください。

• ModusToolboxマニフェストファイルを変更して、BSPがプロジェクトクリエーターに自動的に表示されるようにします。次に、新しいアプリケーションを作成するときにBSPを選択します。詳細については、ModusToolboxユーザーガイドのマニフェストファイルの章を参照してください。

Version: **

Translation - Japanese: ModusToolbox 2.2以降用：カスタムBSPを作成する - KBA231373 - Community Translated (JA)

Question:
How do I create a custom Board Support Package (BSP) for my own hardware?

Answer:
Follow the steps in this article. This article is for ModusToolbox v2.2 and later. Some details of this process have changed. For information about ModusToolbox v2.1, see KBA230822.

Background

The BSP is at the core of the ModusToolbox software. We provide a BSP for each of our kits. A BSP includes (among other things):

• Linker scripts and startup code for the part on the kit
• A configuration file (default name design.modus) that sets up clocks, peripherals, and pins
• Files that add libraries required to support the board

For a custom BSP, these elements must be adjusted for your hardware. This KBA explains how to accomplish that goal. At a high level, the steps are straightforward:

1. Create an application using an existing BSP.
2. Create a new BSP based on the existing BSP.
3. Update the new BSP.

The new BSP includes a copy of the design.modus file, and it uses the same libraries as the original BSP. This KBA starts with the generic BSP and shows you how to add functionality. This results in a minimalist BSP to which you can add functionality for your hardware. The generic BSP is a lowest-common denominator that supports all PSoC 6 MCU devices; however, it will support very few code examples because most examples require some kit functionality.

As an alternative, you can create your application with a kit BSP that has more functionality. For example, if your design uses capacitive sensing, use a BSP for a kit that has CapSense functionality. The design files and libraries used by the BSP are set up for that kit. When you start with a more capable BSP, you modify and/or remove functionality to match your hardware, but the principles outlined here are identical.

Step 1: Create an application using an existing BSP.

1. Use the ModusToolbox Project Creator.
        For this example, we'll create a PSoC 6 application. Select PSOC6-GENERIC as your starter BSP.
2. Click Next >.
   
3. Choose a template application.
        Use the Empty PSoC6 App, give it a name, and ensure the root path is where you want the new application directory to appear.
   
4. Click Create.

When the Project Creator is done you have an application directory. The original BSP will be in the mtb_shared directory, adjacent to the application directory. However, you really don’t need to know where it is. You do your work in the application directory.

Step 2: Create a new BSP.

1. Open a command window (macOS or Linux) or run the modus-shell program (Windows).
2. Go to the top level of your new application directory where the makefile is located and use the make bsp command.

This command has three parameters:

• TARGET_GEN is the name of your new BSP
• DEVICE_GEN is the part number. DEVICE_GEN is optional if the part on your board is the same part as in the existing BSP
• ADDITIONAL_DEVICES_GEN is the optional part number for an additional part (typically a WiFi or Bluetooth radio device) supported by the BSP.
  
  

Using the simple case of a new device, your command would look something like this:

$ make bsp TARGET_GEN=MyBSP DEVICE_GEN=CY8C6316BZI-BLF03

The ModusToolbox build system creates the new BSP at the top level of the application directory, and it is named TARGET_ followed by whatever you named it. In this example it is TARGET_MyBSP.

The new BSP includes part-specific linker scripts and startup code automatically. The design.modus file is identical to the original BSP. If the original design does not work for the new part, you will see an error.

In this example the new part cannot be clocked at the same frequency. You fix these errors in the next step.

Step 3: Update the new BSP.

There are two primary tasks: update the device configuration in the design.modus file, and add libraries. The application you used when creating the new BSP has a makefile. In this example it is in Empty_PSOC6_App.

1. Open that file and change the TARGET variable to point to your new BSP.
        TARGET=MyBSP
2. Save the change. Then in the command window, issue this make command
        make config

The build system launches the Device Configurator for your new BSP/device. Resolve any errors and modify the design as required for your hardware. For example, in this case you must set the PLL frequency to a value supported by the part.

If you are unfamiliar with the Device Configurator read the documentation to learn how to enable and configure clocks, pins, peripherals, and other features of the device.

The libraries included with the BSP are in this directory: TARGET_MyBSP/deps. If you start with the generic BSP, these represent the minimal set of libraries required for your device. Each .lib and corresponding .mtbx file is a URL to a git repository that contains the library files.

Note The .mtbx files are used for the MTB library management flow while the .lib files are used by the LIB library management flow. Depending on the flow your application uses, only one of each pair of files will be used. Refer to the Library Manager Guide for descriptions of each flow.

To add an additional library to your BSP, simply put the corresponding .lib and .mtbx file in this directory.

If you create a custom BSP based on a kit BSP, there may be additional libraries. You can also study code examples to see which libraries they use. ModusToolbox libraries are all available on GitHub.

Step 4: Use the new BSP.

When you are done setting up the new BSP, you can move it anywhere you want; it is a self-contained library. Check the BSP into a version control system if you wish.

There are several ways you can use this BSP. Here are a few:

• Import the BSP into the Project Creator when creating a new application. Refer to the Project Creator Guide for details.

• Copy the entire BSP directory into the root of an application project.
  • Update the makefile TARGET variable to match the BSP's name.
  • Create .mtb files in the application's deps directory for the BSP’s dependencies. You can do this using the make import_deps command. For example:

make import_deps IMPORT_PATH=TARGET_MyBsp

• Add the BSP files directly to an application project in an IDE.
  • Update the makefile TARGET
  • Create .mtb files in the application's deps directory for the BSP’s dependencies You can do this using the make import_deps command. For example:

make import_deps IMPORT_PATH=TARGET_MyBsp

• You may need to update launch configurations to use the new BSP.

• If using git, create a .mtb file (if using the MTB flow) or .lib file (if using the LIB flow) that points to your BSP repository, and include that file in your application’s deps (dependencies) directory. Examine a code example to see how this is done.
  
  
• Modify the ModusToolbox manifest files so that your BSP appears automatically in the Project Creator. Then pick your BSP when creating a new application. For information see the Manifest Files chapter of the ModusToolbox User Guide.

Community Translated by NoTa_4591161          Version: *A

Translation - English: Offloading the Manifest Files of ModusToolbox - KBA230953

質問：
ModusToolbox™2.1は、新しいアプリケーションを作成するときに、マニフェストファイルをホストするサイトにアクセスできません。別の方法でファイル要求をマニフェストファイルにオフロードできますでしょうか？

回答：

ModusToolboxで新しいアプリケーションを作成すると、「マニフェスト」と呼ばれるファイルから情報がフェッチされ、ボードサポートパッケージ（BSP）とコード例のテンプレートが表示されます（ModusToolboxユーザーガイドの「マニフェストファイル」の章を参照）。

マニフェストファイルは、サイプレスGitHubリポジトリでホストされています。ウェブサイトraw.githubusercontent.comは、GitHubリポジトリに保存されているファイルを提供するために使用されます。

一部の国またはこのドメインへのアクセスが制限されている状況では、この問題を回避するための2つのオプションがあります。

• 方法1：マニフェストを別の場所にオフロードする
• 方法2：ModusToolboxオフラインパッケージの使用

Method1は、インターネットにアクセスできるが、ドメインへのアクセスに問題がある場合にのみお勧めします。新しいアプリケーションを作成するたびに、最新のライブラリ、コード例、BSPなどを取得できます。方法2では、静的オフラインパッケージをダウンロードします。このパッケージのサイズは数百MBであり、新しいライブラリとコード例が追加されるたびにダウンロードする必要があることに注意してください。オフラインで作業する場合にのみお勧めします。

1. 方法1：マニフェストを別の場所にオフロードする（Windowsのみ）

これは1回限りのプロセスです。作成されたすべての新しいアプリケーションは、これらのオフロードされたマニフェストを使用します。利用可能なマニフェストの新しいバージョンがある場合にのみ、マニフェストファイルを更新する必要があります。マニフェストファイルをオフロードするには、次の手順を実行します。

1. このKBAに添付されているマニフェストファイルのzipアーカイブをダウンロードします（これらのファイルは最新ではない可能性があります。How do I get the most recent version of the manifest files?（マニフェストファイルの最新バージョンを取得するにはどうすればよいですか？）を参照してください）
2. コンピューター上にファイルを抽出します。
3. mtb-super-manifest.xmlファイルをエディターで開き、ローカルマニフェストファイルを指すようにすべてのURIラベルを変更します。

<board-manifest>

<uri><path_to_file>/mtb-bsp-manifest.xml</uri>

</board-manifest>

例えば：

注：マニフェストはローカルシステムに存在する必要はありません。また、内部Gitリポジトリまたは共有ドライブに置くこともできます。

   4. システム環境変数を編集して、次の変数を追加します。

変数：CyRemoteManifestOverride

値：<path_to_file> /mtb-super-manifest.xml

例えば：

  5. ModusToolboxまたはProject Creatorスタンドアロンツール用のEclipse IDEを使用して新しいアプリケーションを作成します。どちらの方法でもProject Creatorウィンドウが呼び出され、マニフェストファイルがローカルファイルシステムからフェッチされていることがわかります。

マニフェストファイルの最新バージョンを取得するにはどうすればよいですか？

移動にサイプレスのGitHubリポジトリとマニフェストのための検索クエリを実行します。ファイルが最後に更新された日時に関する情報が表示されます。

新しいバージョンのマニフェストが利用可能な場合は、mtb-super-manifestリポジトリに移動して、ファイルmtb-super-manifest.xmlをダウンロードします。このファイルには、以下に示す他のすべてのマニフェストファイルへのURLが含まれています。

これらのURLに移動して、すべてのマニフェストファイルをダウンロードします。既存のすべてのマニフェストファイルをダウンロードしたファイルで置き換え、マニフェストをオフロードする手順3〜5を繰り返します。

2. 方法2：ModusToolboxオフラインパッケージの使用

ModusToolboxは、ダウンロードして新しいアプリケーションを作成するために使用できるオフラインコンテンツパッケージを提供します。オフラインパッケージの使用の詳細については、次の記事を参照してくださいhttps：//community.cypress.com/docs/DOC-19903

Author: DheerajK_81           Version: *B

Translation - Japanese: ModusToolboxのマニフェストファイルのオフロード - KBA230953 - Community Translated (JA)

Question:

ModusToolbox™ 2.x is not able to access the site that hosts the manifest files when creating a new application. The Project Creator fails with the error “Failed to access remote server”. Can I offload the file request to the manifest files in any way to resolve this error?

Answer:

When you create a new application in ModusToolbox, information is fetched from files called “manifests” to display Board Support Packages (BSP) and code example templates  (see the “Manifest Files” chapter in the ModusToolbox User Guide.

The manifest files are hosted on the Cypress GitHub Repository. The website raw.githubusercontent.com is used to serve files kept in GitHub repositories.

In some countries or in situations when access to this domain is restricted, there are three options to work around this problem:

• Method 1: Offloading the manifests to a different remote server location
• Method 2: Offloading the manifests to a location on the disk
• Method 3: Using ModusToolbox Offline Package

Method 1 or 2 is recommended if you have access to the internet but only face problems accessing the Github domain through raw http access. It allows you to get the latest libraries, code examples, BSPs etc. each time you create a new application.

Method 3 involves downloading a static offline package. Note that this package is a few hundreds of MBs in size and updated on a quarterly basis. To get the new libraries and code examples, you need to download it from time to time. It is only recommended when working offline.

Use the methods in priority order as stated below.

1. Method 1: Offloading the manifests to a different remote server location

This is a one-time process; all new applications created will use these offloaded manifests.

Do the following to offload manifest files to a different server (in our case from GitHub to itools.infineon.cn):

a. Run the in-built bash shell if you are a Linux/MacOS user. Windows users can skip to the next step.

b. Set the System Variable:

• Windows users: Set the system environment variable to override the manifests permanently. Set the variable name to CyRemoteManifestOverride  

• Linux/MacOS users: Execute the following command in the bash shell:

i. For ModusToolbox 2.1 users:

  >> export CyRemoteManifestOverride=https://itools.infineon.cn/mtb/manifests/mtb-super-manifest.xml

ii. For ModusToolbox 2.2 users:

  >> export CyRemoteManifestOverride=https://itools.infineon.cn/mtb/manifests/mtb-super-manifest-fv2.xml

c. Create a new application:

• Windows users: Launch Eclipse IDE for ModusToolbox or Project Creator standalone tool to create a new application. Both methods invoke the Project Creator window.
• Linux/MacOS users: Invoke Eclipse IDE for ModusToolbox or Project Creator standalone tool from the bash shell in the same bash session. The variable set in the previous step will only have effect in the same bash session.

To invoke Eclipse IDE for ModusToolbox run the command:

>> ~/ModusToolbox/ide_2.2/eclipse/ModusToolbox.exe

To invoke Project Creator tool run the command:

>> ~/ModusToolbox/tools_2.2/project-creator/project-creator.exe

     Note: Change the path accordingly if you have installed ModusToolbox in a custom location.

You will notice that the manifest files are now being fetched from a different server location.

2. Method 2: Offloading the manifests to a location on the disk

This is a one-time process; all new applications created will use these offloaded manifests.

Do the following to offload manifest files:

a. Download the zip archive of the manifest files from here.

b. Extract the files to ~/.modustoolbox directory. In case you don’t see this directory, create a directory named “.modustoolbox” and extract inside it.

c. Run the in-built bash shell if you are a Linux/MacOS user. Windows users can skip to the next step.

d. Set the System Variable:

• Windows users: Set the system environment variable to override the manifests permanently. Set the variable name to CyRemoteManifestOverride
• For MTB 2.1 users, the variable value is:

<path_to_file>/.modustoolbox/mtb-super-manifest.xml

• For MTB 2.2 users, the variable value is:

<path_to_file>/.modustoolbox/mtb-super-manifest-fv2.xml

• Linux/MacOS users: Execute the following command in the bash shell:

i. For ModusToolbox 2.1 users:

  >> export CyRemoteManifestOverride=file:///$HOME/.modustoolbox/mtb-super-manifest.xml

ii. For ModusToolbox 2.2 users:

  >> export CyRemoteManifestOverride=file:///$HOME/.modustoolbox/mtb-super-manifest-fv2.xml

e. Create a new application:

• Windows users: Launch Eclipse IDE for ModusToolbox or Project Creator standalone tool to create a new application. Both methods invoke the Project Creator window.
• Linux/MacOS users: Invoke Eclipse IDE for ModusToolbox or Project Creator standalone tool from the bash shell in the same session. The variable set in the previous step will only have effect in the same bash session.

To invoke Eclipse IDE for ModusToolbox run the command:

>> ~/ModusToolbox/ide_2.2/eclipse/ModusToolbox.exe

To invoke Project Creator tool run the command:

>> ~/ModusToolbox/tools_2.2/project-creator/project-creator.exe

          Note: Change the path accordingly if you have installed ModusToolbox in a custom location.

You will notice that the manifest files are now being fetched from the location on the disk.

3. Method 3: Using ModusToolbox Offline Package

ModusToolbox provides an offline content package that you can download and use to create new applications. This method should only be used as a last resort option. Asset releases occur frequently while offline content releases are not. So, the offline content may not always reflect the latest updates. For more information on using the offline package, see this article: https://community.cypress.com/docs/DOC-19903

Community Translated by  NoTa_4591161          Version: **

Translation - English: Migrating from ModusToolbox v1.1 to v2.x - KBA229043

ModusToolbox™v2.xは、以前のバージョンとはかなり異なります。その結果、プロジェクトをModusToolbox v1.1からv2.xに移行するための簡単な移植オプションはIDEにはありません。

v2.xには多くの根本的な変更があります。たとえば、v2.xでは、ボードサポートパッケージ（BSP）がソフトウェア開発の中心です。BSPは、ボードの機能へのCypressキット全体の標準インターフェイスを提供します。他のソフトウェア（ミドルウェアやユーザーのアプリケーションなど）は、BSPを使用してハードウェアを設定および制御できます。v1.1にはBSPはありません。

このKBAは、v2.xへの移行時に発生する可能性のある一般的な状況についての高いレベルの手順とガイダンスを提供します。ModusToolbox 2.xを初めて使用する場合は、 ModusToolbox Software Overviewを読んで、その機能の概要をご確認願います。これは、このガイダンスの一部を理解するのに役立ちます。このKBAは、ModusToolbox IDEに精通していることを前提としています。IDEについて質問がある場合は、  ModusToolbox IDE User Guideをご参照願います。

1. ModusToolbox 2.xプロジェクトを作成します。

New Applicationウィザードを使用します。スターターアプリケーションとして使用するBSPとコード例を選択します。このプロセスでは、ModusToolbox 1.1で使用したものとほとんど同じ機能を提供するコード例を選択してください。

キッのトBSPで利用可能なパーツとは異なるパーツを使用している場合は、同様のパーツ用のBSPから始めて、デバイス用のカスタムBSPを作成します。 詳細はBSP User Guideを参照してください。

2. 不足しているライブラリを追加し、（オプションで）未使用のライブラリを削除します。

スターターアプリケーションには、アプリケーションで使用されるミドルウェアが含まれていない場合があります。同様に、アプリケーションは、スターターアプリケーションにデフォルトで含まれているすべてのものを使用しない場合があります。キットはCapSenseのをサポートしている場合たとえば、^®、CapSenseのライブラリは、キットのBSPによってデフォルトで含まれています。アプリケーションがCapSenseを使用しない場合は、そのライブラリを削除できます。

PSoC 6 MCU関連プロジェクトの場合、ライブラリマネージャーを使用してライブラリを追加または削除します。使用する各ライブラリのバージョンを制御することもできます。

Bluetooth SDKを使用するアプリケーションの場合、ライブラリはSDK内にあるため、ライブラリマネージャーを使用できません。代わりに、メイクファイルを直接変更する必要があります。詳細については、wiced_btsdk readmeファイルを参照してください。

ライブラリのローカルコピーに変更を加えた後、ライブラリマネージャーを使用して別のバージョンに更新すると、保存されていない変更があるため警告が表示され、更新はスキップされます。

3.残りのアプリケーションソースファイルをプロジェクトに追加します。

アプリケーション固有のソースファイルをv1.1からv2.xプロジェクトにコピーします。これには、使用する追加の外部ライブラリも含まれます。お好みに整理してください。ソースファイルをプロジェクトフォルダの任意の場所に置くだけです。

その後、IDEの「New Application」コマンドを使用して、このプロジェクトのメイクファイルをインポートすると、すべてのソースファイルが自動的に検出され、プロジェクトに追加されます。

ファイルをプロジェクトに直接コピーするのではなく、参照でリンクする場合は、対応する変更をmakefileに加えて、SOURCESおよびINCLUDESを追加する必要があります。コマンドラインからModus Toolboxを実行するを参照してください。

4.新しいビルド環境で発生する問題を解決します。

もちろん、発生する問題は、アプリケーションの性質とその実装方法によって異なります。一部の機能は変更されていません。一部には追加オプションがあります。いくつかは異なるソリューションを必要とします。このKBAはすべての可能なケースをカバーできるわけではありません。ただし、いくつかの一般的な状況を見ることができます。

表1. ModusToolbox v1.1と2.xの違い

適切なライブラリを入手する

表2は、v2.xで利用可能な多くのライブラリと、同じコードまたは類似のコードがv1.1に存在していた場所を示しています。これは、v2.xで必要なライブラリを決定するのに役立ちます。一部のライブラリは、Mbed OS開発にのみ役立ちます。v2.x BSPには、キットに必要なライブラリが自動的に含まれることに注意してください。たとえば、キットがCapSenseをサポートしている場合、CapSenseライブラリはBSPによって追加されます。

GitHubでv2.x用に提供されたコードは、通常v1.1で提供されたものよりも新しいバージョンです。すべてではないにしてもほとんどの場合、これらは下位互換性があります。可能性は低いですが、新しいバージョンのライブラリに対応するために、コードを変更する必要がある場合があります。各ライブラリの説明は、GitHubで入手できます。完全なリストについては、psoc6-middlewareを参照してください。

表2. ModusToolbox v1.1コードと対応するv2.xライブラリ

Community Translated by  KoSa_1909416          Version: **

Translation - English: Cypress Firmware Deliverables in Mbed OS – KBA228252

この記事では、Mbed™OS向けにサイプレスから提供されるファームウェアの詳細について説明します。

図1は、Mbed OSのアーキテクチャを示しています（出典：Mbed OS Documentation）。

Mbed OSの概要については、https://os.mbed.com/docs/にあるドキュメントを参照してください。

　　　　　　　　　　　　　　　　　　　　　　図１

この記事ではサイプレスが提供している、図1でオレンジ色で強調表示されている関連コンポーネントの詳細を説明します。

具体的には、以下のファームウェアとなります。

  • ハードウェア アブストラクション レイヤー（HAL）

  • ボード サポート パッケージ（BSP）

  • Wi-Fi および BLEの実装

１．ハードウェア アブストラクション レイヤー（HAL）

これには、デジタル/アナログI / Oピン、I2C、UART、SPI、クワッドSPI、PWMなどの一般的な周辺機器用のドライバーが含まれます。

ドライバーAPIの詳細については、https://os.mbed.com/docs/mbed-os/latest/apis/drivers.html を参照してください。

使用例については、https://os.mbed.com/docs/mbed-os/latest/tutorials/index.htmlを参照してください。

図2は、Mbed OSアプリケーションでのPSoC 6 MCU HAL、Mbed HAL、およびMbed OSドライバーの関係を示しています。

　　　　　　　　　　　　図２

1.1 PSoC 6 MCU ペリフェラル ドライバ ライブラリ

ペリフェラル ドライバ ライブラリ（PDL）は、PSoC 6 MCUアーキテクチャのソフトウェア開発を簡素化します。

PDLは、レジスタの使用法とビット構造を理解する必要性を減らし、幅広い周辺機器のソフトウェア開発を容易にします。

PDLにはMbed OS固有の情報は含まれておらず、一般的なRTOS環境で使用することができます。

PSoC 6 MCU PDLは mbed-os\targets\ TARGET_Cypress\TARGET_PSOC6\psoc6cspディレクトリにあります。

PDLドキュメントは PSoC 6 PDL API Reference Manual.にあります。

1.2 PSoC 6 HAL

PSoC 6 MCU HALは、PSoC 6 ペリフェラルとの高レベルのインターフェースを提供します。

このインターフェイスは、チップ固有の機能を抽象化します。

チップ固有の機能が必要な場合、またはパフォーマンスが重要な場合は、

PSoC 6 MCU PDLで提供される低レベルの機能を直接使用できます。

PSoC 6 MCU HALは、mbed-os \targets \TARGET_Cypress \TARGET_PSOC6 \psoc6cspディレクトリにあります。

1.3 Mbed HAL

異なるArm®Cortex®-Mベースのデバイス間でアプリケーションコードのシームレスな移植を可能にするために、

Mbed OSは異なるペリフェラルを使用するためのMbed HALレイヤーを提供します。

Mbed HAL API（ヘッダーファイル）は、\mbed-os \hal ディレクトリにあります。

PSoC 6 MCU向けに実装したMbed HAL API（ソースファイル）は、

\mbed-os \targets \TARGET_Cypress \TARGET_PSOC6ディレクトリにサイプレスから提供されています。

Mbed HALのサイプレスへの実装は、主にPSoC 6 MCU HAL APIに、必要に応じてPSoC 6 MCU PDL APIに依存しています。

1.4 Mbedドライバ

Mbed OSは、共通で使用されるMCUペリフェラルのC ++ラッパーを提供します。

これらは、\mbed-os \driversディレクトリにあります。

２．ボード サポート パッケージ

Mbed OSで、”ターゲット”とはハードウェア開発キットを指します。

サイプレスは、すべてのMbed OS対応キット用に、

ボード サポート パッケージ（BSP）とも呼ばれるターゲットへの実装を提供します。

BSPの詳細を以下に示します。

2.1ターゲットリスト

すべてのパートナーがMbed OSでサポートしているターゲット（BSP）のリストと、

それぞれの構成は、mbed-os \ targets \ targets.jsonファイルにあります。

このファイルには、Mbed OSでサポートされているサイプレスのターゲットも含まれています。

このファイルの詳細については、

https://os.mbed.com/docs/mbed-os/latest/reference/adding-and-configuring-targets.htmlを参照してください。

2.2ターゲット固有のBSP

ターゲットのBSPは、\ mbed-os \ targets \ TARGET_Cypress \ TARGET_PSOC6ディレクトリにあります。

各ターゲットには、TARGET_(ターゲット名)という命名則でディレクトリがあります。

たとえば、図3に示すように、CY8CKIT-062-WiFi-BTのフォルダーはTARGET_CY8CKIT_062_WiFi_BTです。

　　　　　　　　　　　　　　　　　　　図３

BSPには、ターゲット ハードウェアの初期化コード、構成設定、スタートアップコード、リンカースクリプトなどがあります。

フォルダーで提供されるBSPファイルの情報は、以下の表になります。

2.3 PSoC 6 MCU CM0+ CPUイメージ

サイプレスは、デュアルCPU PSoC 6 MCUのCortex M0+コアで実行される

プリコンパイルされたアプリケーションイメージを提供します。

これらのイメージは、\mbed-os \targets \ ARGET_Cypress \TARGET_PSOC6 \psoc6cm0pフォルダーにあります。

イメージは、Cortex M4アプリケーションの一部としてコンパイルできるC言語の配列として提供されます。

Cortex M0+アプリケーションコードは、Cortex M4リンカースクリプトによって内部フラッシュに配置されます。

さまざまなCM0+イメージのタイプの詳細を以下に示します。

        TARGET_CM0P_SLEEP：このフォルダーには、CY_CORTEX_M4_APPL_ADDR = 0x10002000から

                                                    CM4コアを開始して書き込むCM0+イメージが含まれています。

3. Wi-FiとBLEの実装

図4は、PSoC 6 MCUのWi-FiおよびBLEプロトコル実装のレイヤーと、

MBed OSのCYW43xxxベースのソリューションを示しています。

                                           　　　　　　図４

CYW43xxxのWANサブシステムは、SDIOインターフェースを介してPSoC 6 MCUと通信します。
SDIOインターフェイスは、SDIO_CMD、SDIO_CLK、およびSDIO_DATA [3：0]の6つの信号で構成されています。
CYW43xxxのWLANサブシステムには、802.11物理層（PHY）と802.11メディアアクセス制御（MAC）層が含まれています。
ネットワークスタックを含むWi-Fiプロトコルの上位層、および上位層プロトコル（IP、TCP / UDP、HTTP、MQTTなど）は、PSoC 6 MCUで処理されます。

CYW43xxxのBluetoothサブシステムは、フロー制御が有効になっている（TX、RX、RTS、CTS）HCI UARTインターフェースを介してPSoC 6 MCUと通信します。
CYW43xxxのBluetoothサブシステムは、無線とリンク層を含むBLEスタックのコントローラー部分を実装します。
BLEスタックのホスト部分、BLEプロファイル、およびアプリケーションコードはPSoC 6 MCUに常駐します。

SDIOおよびUARTインターフェースに加えて、PSoC 6 MCUとCYW43xxxデバイスの間には6つの制御信号があります。
これらには、電力制御信号（WL_REG_ON、BT_REG_ON）、CYW43xxxデバイスウェイクアップ信号（WL_DEV_WAKE、HOST_DEV_WAKE）、
およびPSoC 6 MCUホストウェイクアップ信号（WL_HOST_WAKE、BT_HOST_WAKE）があります。
これらの制御信号、SDIO、およびUARTインターフェースの詳細については、CYW43xxxデバイスのデータシートを参照してください。

次のセクションでは、Wi-FiとBLEに関連するサイプレスファームウェアの詳細について説明します。

3.1 Wi-Fi ファームウェア

3.1.1 ホスト ドライバー  (WHD)
Wi-Fi ホスト ドライバー (WHD)は、ホストMCU (PSoC 6 MCU) で実行されるドライバー ファームウェアであり、
通信インターフェース（通常、SDIOインターフェースに限定されません）を使用して、

CYW43xxxデバイスのWLANサブシステムとインターフェースします。
WHDは、ホストMCUソフトウェアフレームワークの上位層で使用できるWLAN APIを提供します。
これらには、スキャン、ジョイン、SoftAPなどのAPIがあります。
サイプレスは、Mbed OSの一部としてWHDファームウェアを提供しています。
mbed-os \ targets \ TARGET_Cypress \ TARGET_PSOC6 \ TARGET_WHDフォルダーにあります。

WHDフォルダーには、以下に示す他のリソースも含まれています。

   • \TARGET_WHD \resources \firmware : CYW43xxxデバイスのWLANファームウェア AN225347

   • \TARGET_WHD \resources \nvram : ハードウェアプラットフォームに対応するNVRAMファイル。

       このファイルには、RF構成やアンテナ設定などのボードハードウェア構成設定が含まれています。

3.1.2イーサネット MAC (EMAC)

イーサネット MAC（EMAC）WHDからMbed Ethernet MAC（EMAC）へのドライバーインターフェイスは、

mbed-os \ features \ netsocket \ emac-drivers \ TARGET_WHDフォルダーに保持されます。

WiFiのEMACドライバーの詳細については、

https://os.mbed.com/docs/mbed-os/v5.13/porting/ethernet-port.html を参照してください。

3.1.3 LWIP ネットワーク スタック

Wi-Fi接続をサポートするボードは、mbed-os \ features \ lwipstack \ mbed_lib.jsonファイルに適切な設定で追加する必要があります。

Wi-Fi機能を備えたサイプレスキットのLWIPスタック設定がこのファイルに追加されました。

3.1.4ネットワーク ソケット API

IPネットワーキングのAPIがソケットAPIです。

ソケットAPIは、トランスポート層であるOSIレイヤー4に関連しています。

Mbed OSでは、ソケットAPIが抽象化され、TCPやUDPなどのさまざまなプロトコルをサポートしています。

Mbed OSネットワークソケットAPIについては、

https://os.mbed.com/docs/mbed-os/latest/apis/network-socket.htmlを参照してください。

3.1.5 ネットワーク インターフェイス API

ソケットには、ソケットを作成する必要があるネットワーク インターフェイスを示すインスタンスが必要となります。

ネットワーク インターフェイスは、基盤となるソケット操作を実装するネットワークスタックを提供します。

ネットワーク インターフェイス、アプリケーションがネットワーク構成を指定するために使用する制御APIでもあります。

Mbed OSネットワークインターフェイスAPIの詳細については、

https://os.mbed.com/docs/mbed-os/latest/apis/network-interfaces.htmlを参照してください。

3.2 BLEファームウェア

CYW43xxx Wi-Fi / BTコンボデバイス（CYW43012、CYW4343W）には、

デュアルモードBluetoothの無線とコントローラー機能が含まれています。
これらのコンボデバイスのBluetoothサブシステムは、HCI UARTインターフェースを介してPSoC 6 MCUホストとインターフェースし、

BLEホストスタックはPSoC 6 MCUで実行されます。
Mbed OSはクラシックBluetoothをサポートしていません。
サイプレスのBLE実装とCordio BLEスタックの間の抽象化レイヤーは、

mbed-os \features \FEATURE_BLE \targets \TARGET_Cypressにあります。

Arm Mbed BLEはBLE_APIとも呼ばるMbed OS用のBluetooth Low Energyソフトウェアソ リューションです。
開発者はこれを使用して、新しいBLE対応アプリケーションを作成できます。
Mbed OSのBLE_APIは、プラットフォーム上のBLEコントローラーとインターフェースします。
これは、BLEスタックの複雑さをC ++の抽象化の背後に隠し、BLE対応のすべてのMbedプラットフォームと互換性があります。
BLE APIの詳細については、https://os.mbed.com/docs/mbed-os/latest/apis/ble.htmlを参照してください。