Community Translated by NoTa_4591161     Version: **

Translation - English: Using emWin's QR-Code functions – KBA231613

SEGGER emWinライブラリをPSoC^®デバイスで使用して、ディスプレイにGUI要素を作成できます。 バージョン5.34では、ユーザーがGUIディスプレイでQRコードを簡単に作成できる機能が追加されました。

それらは4つの関数へのAPI呼び出しを単純化しました：

• GUI_QR_Create() －コードのRAMベースの構造体を作成します。注：QRコードを読み取るための最良のコントラストを提供するには、明るい（白）背景色を使用します。
• GUI_QR_Delete() －コードのRAMベースの構造体を削除します。
• GUI_QR_Draw() － ディスプレイにQRコードのRAMベースの構造体を描画します。
• GUI_QR_GetInfo() －コードに関する物理情報を取得します。

  詳細については、emWinユーザーガイドおよびリファレンスマニュアルを参照してください。

GUIのプールメモリへのRAM割り当て：

QRコードの生成には、かなりのRAMリソースが必要になる場合があります。より多くのRAMを必要とする要因は次のとおりです。

• エンコードするコンテンツが大きいほど、より多くのRAMが必要になります。つまり、短いテキスト文字列はより少ないRAMを使用します。テキスト文字列が長いほど、より多くのRAMが必要になります。
• QR「モジュール」で使用されるピクセル数。「モジュール」は、正方形の論理エンコーディング要素です。
• ECCレベル。エラー訂正レベルが高いほど、より大きなQRビットマップが必要になります。
• 「バージョン」が高いほど、間接的により多くのRAMが必要になる可能性があります。通常、Version = 0を使用して、コンテンツに基づいて必要なバージョンを自動検出します。

十分なGUIRAMメモリを使用できるようにするには、GUIConf.hで#defineGUI_NUMBYTESを設定します。Seggerは、この値を少なくとも0x10000に設定することをお勧めします。これにより、ライブラリ全体にGUIプールRAMメモリが割り当てられ、QRコードや必要に応じて他のGUI機能に使用されます。

このRAMの量がアプリケーションに必要な量を超える場合は、提供できる最大量を割り当てます。次のステップとして、開発フェーズで、できるだけ多くのさまざまなユースケースを表示してアプリケーションを実行します。GUI_ALLOC_GetMaxUsedBytes()関数を含めて、アプリケーションで使用されているGUIRAMの実行時ピークカウントを取得します。GUI_NUMBYTESの値は、この最大値（プラス予防措置として10％）で修正することができます。

注： 通常、emWinライブラリに十分なRAMが割り当てられていない場合、SysLibフォルトでクラッシュする可能性があります。

コード例：

#include "GUI.h"

/* この例は、ディスプレイの右下隅に配置する単純なQRコード生成です。

「モジュール」は、最小の論理要素のQR定義です。「モジュール」のサイズは、使用されたピクセル数（1次元）です。このサイズは、「X」と「Y」の両方の大きさに使用されます。

*/

      GUI_HMEM qrCode = GUI_QR_Create(

“This is a text string.  It could be a URL address”,

// QRコードに使用されるUTF-8テキスト

      2, //「モジュール」サイズの1次元ピクセルサイズを定義します。

      GUI_QR_ECLEVEL_H, // ECCレベル。レベルが高いほど、エラー訂正が向上します。

      　0 ); // QRの「バージョン」エンコーディングスタイル。値0は、必要なものを自動検出します。

/* QRCodeが仮想的に作成されたので、その大きさの情報を取得します。GUI_QR_GetInfo()を使用します。*/

GUI_QR_INFO pInfo;

    GUI_QR_GetInfo(

    qrCode,    // 描画するQRコードのハンドル。

      &pInfo);    // QR情報構造のメモリへのポインタ。

/* QR情報を使用して、1次元のQRCodeのサイズ（pInfo.Size）を決定します。右下隅に配置するには、ディスプレイのXサイズとYサイズから差し引きます */

    UI_QR_Draw(

    qrCode,                         //描画するQRコードのハンドル。

    LCD_GetXSize()-pInfo.Size, //ディスプレイのXサイズからビットマップの1次元サイズを減算します。

    LCD_GetYSize()-pInfo.Size); //ディスプレイのYサイズからビットマップの1次元サイズを減算します。

    GUI_QR_Delete(qrCode);  //描画するQRコードの処理。これはもう必要ありません。割り当てられたGUIRAMを解放します。

/* 使用しているディスプレイ（EINKなど）によっては、更新機能が必要になる場合があります。その他は自動的に更新される場合があります。*/

    /* ディスプレイバッファデータをディスプレイに送信します */

    UpdateDisplay(CY_EINK_FULL_4STAGE, true);   //表示を更新します。

SeggerのWikiページの例を参照してください：https://wiki.segger.com/QR_Code_(Sample)

添付のPSoCCreator™ およびModusToolbox^® プロジェクトは、さまざまなGUI_QR_Create()パラメータの設定の表示効果を示しています。

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: LePo_1062026        Version: **

Translation - Japanese: emWinのQRコード機能の使用 – KBA231613 - Community Translated (JA)

The SEGGER emWin library can be used with PSoC^® devices to create GUI elements in displays. Version 5.34 added the ability for the user to easily construct QR codes on GUI displays.

They simplified the API calls to four functions:

• GUI_QR_Create() – Create the RAM-based structure of the QR Code. Note: To provide the best contrast for reading QR Codes, use a light (white) background color.
• GUI_QR_Delete() - Delete the RAM-based structure of the QR code.
• GUI_QR_Draw() – Draw the RAM-based structure of the QR code on the display.
• GUI_QR_GetInfo() – Get physical information about the QR code.

  See the emWin User Guide & Reference Manual for details.

RAM Allocation for the GUI’s Pool Memory:

QR-Code generation may require significant RAM resources.  Here are the factors that require more RAM:

• Larger content to encode requires more RAM i.e., short text strings utilize less RAM; longer text strings need more RAM.
• Number of pixels used in a QR ‘module’.  The ‘Module’ is square logic encoding element.
• ECC level.  Higher error correction levels will require a larger QR bitmap.
• A higher ‘Version’ can indirectly require more RAM.  It is usually common to use Version=0 to auto-detect the Version needed based on content.

To make sure that you have enough GUI RAM memory available, set the #define GUI_NUMBYTES in GUIConf.h. Segger recommends setting this value to 0x10000 at a minimum.  This will allocate the GUI pool RAM memory for the entire library and be used for the QR-codes as well as other GUI functions as needed.

If this amount of RAM is more than your application requires, allocate the maximum you can provide. As the next step, during the development phase, run your application with as many display varying use cases as you can. Include the GUI_ALLOC_GetMaxUsedBytes() function to get the run-time peak count of the GUI RAM used in your application. The GUI_NUMBYTES value can be modified with this maximum value (plus 10% as a precaution).

Note:  Typically, if enough RAM is not allocated for the emWin library, it may crash with a SysLib fault.

Example Code:

#include "GUI.h"

/* This example is a simple QR-Code generation that places it in the bottom-right corner of the display.

A ‘Module’ is the QR definition of the smallest logic element.  The size of the ‘Module’ is how many pixels (in one dimension) used.  This size is used for both ‘X’ and ‘Y’ dimensions.

*/

    GUI_HMEM qrCode = GUI_QR_Create(

“This is a text string.  It could be a URL address”,

//UTF-8 text to be used for the QR-code

      2, // Define the one-dimensional pixel size for the 'Module' size.

      GUI_QR_ECLEVEL_H,  // ECC level.  A higher level will allow for better error correction.

      0 );  // The QR 'Version' encoding style.  A value of 0 will autodetect what is needed.

/*  Now that the QRCode is virtually created, get its' dimensional info.  Use GUI_QR_GetInfo(). */

GUI_QR_INFO pInfo;

    GUI_QR_GetInfo(

    qrCode,     //Handle of the QR-code to be drawn.

    &pInfo);    // pointer to the memory of the QR info structure.

/* Use the QR info to determine the size of the QRCode in one dimension (pInfo.Size).  To place it in the bottom-right corner, substract it from the display's X and Y size */

    GUI_QR_Draw(

    qrCode,                     //Handle of the QR-code to be drawn.

    LCD_GetXSize()-pInfo.Size,  //Subtract the one-dimensional size of the bitmap from the display's X size.

    LCD_GetYSize()-pInfo.Size); //Subtract the one-dimensional size of the bitmap from the display's Y size.

    GUI_QR_Delete(qrCode);  //Handle of the QR-code to be drawn.  This is no longer needed.  Free the GUI RAM allocated.

/* Depending on the display you are using (such as the EINK), it may require an update function.  Others may be automatically updated. */

    /* Send the display buffer data to display*/

    UpdateDisplay(CY_EINK_FULL_4STAGE, true);   // Update the display.

See the example on Segger’s Wiki page: https://wiki.segger.com/QR_Code_(Sample)​

The attached PSoC Creator™ and ModusToolbox^® projects show the display effects of the setting of the different GUI_QR_Create() parameters.

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 Warning: Uncommitted/Untracked Files Detected - KBA231252

質問：
ModusToolboxアプリケーションがコミットされていない/追跡されていないファイルに関する警告を報告するのはなぜですか？

回答：
ModusToolboxアプリケーションにコンパイルされた一部のファームウェアは、コンフィギュレータによって生成されます。ModusToolboxビルドプロセスは、次のような理由でソースコードが古くなった場合、ビルドプロセス中にソースコードを再生成します。

• コンフィギュレータを開き、変更を保存しました。
• BSPの「.mk」ファイルで選択したデバイス（DEVICE =）を更新しました。
• デバイスサポートライブラリを更新しました。
• ツールをアップグレードまたはパッチを適用して、新しいコンフィギュレータを追加しました。

ModusToolboxはgitを使用してファームウェアを配布および更新します。上記の変更により、これらのリポジトリを更新しようとすると、gitから警告がトリガーされる場合があります（たとえば、Library Managerを使用するか、コマンドラインでgitを使用して直接）。警告は次のようになります。

WARNING: Uncommitted/Untracked files detected in "<path to repository>".

Save your work in source control before updating this library.

Skipping current reference...

これは、処理されていない変更されたファイルがあり、それについて何かをする必要があることを通知するgitシステムの方法です。システムは、変更が誤って失われないように注意しています。

1. デバイスサポートライブラリは、ターゲットデバイスによって異なります。より一般的なオプションは次のとおりです。

PSoC 6: psoc6pdl or mtb-pdl
PSoC 4: mtb-psoc4-pdl
Bluetooth: 20706A2, 20719B2, 20721B2, 20735B1, 20819A1, 20820A1, 20835B1, 43012C0

警告を解決：

この警告を解決するには、ニーズと、デフォルトのビルドサポートパッケージ（BSP）を使用しているかカスタムBSPを使用しているかに応じて、いくつかの方法があります。

デフォルトのBSP

サイプレスが提供するデフォルトのBSPの1つを（上記のように）変更した場合は、カスタムBSPを作成してから、デフォルトのBSPの変更を元に戻す必要があります。

1. ModusToolboxユーザーガイドのBSPの章の指示に従って、現在の（変更された）BSPに基づいてカスタムBSPを作成します。

2.デフォルトのBSPに戻すには、gitを実行するように構成された適切なシェルを使用して次のコマンドを実行します。

# 注：これにより、存在してはならないファイルがすべて削除されます。

git -C <警告からリポジトリへのパス> clean -dfx

# 注：これにより、ファイルが元の状態に戻ります。

git -C <警告からリポジトリへのパス> restore。

3.すべてがクリーンされ、準備ができていることを確認します。

git -C <警告からリポジトリへのパス> status

4.出力に次のテキストが含まれていることを確認します。

"nothing to commit, working tree clean"

カスタムBSP

カスタムBSPのいずれかに変更を加えた場合は、その変更を元に戻すか（[デフォルトBSP]の手順に従ってください）、変更をコミットすることができます。

変更を受け入れるには、ソースコード管理システムに変更をコミットまたはチェックインします。たとえば、gitを使用する場合：

     # 注：変更を確認し、それらが正しいことを確認してください。

     git -C <警告からリポジトリへのパス>ステータス

     # 注：変更が受け入れ可能であることを確認した後、それらをコミットします。

     git -C <警告からリポジトリへのパス> add。

     git -C <警告からリポジトリへのパス> commit

Community Translated by NoTa_4591161       Version: **

Translation - English: Migrating from PSoC 6 BSP v1.x to v2.x in ModusToolbox v2.2 – KBA231266

このKBAは、BSP v1.x（最新-v1.Xタグ）を使用するModusToolboxアプリケーションに影響を与えるBoard Support Package（BSP）v2.xリリースによって導入された変更と新機能について説明し、これらのアプリケーションをBSPv2.x（最新-v2.Xタグ）に移行する方法に関する情報を提供します。

注： BSP v2.xは、KBA231080で説明されている新しい「MTBフロー」と以前の「libフロー」の両方をサポートします。BSP v2.xの新機能を使用するには、KBA231080 - ModusToolbox v2.1からv2.2に移行から、BSP v2.xを使用して、アプリケーションを新しいMTBフローに更新する必要があります。

BSP v2.x（TARGET_ <BSP> GitHubリポジトリのrelease.mdファイル）での具体的な詳細の変更については、各BSPのリリースノートとreadmeを参照してください。

次のセクションでは、既存のアプリケーションに影響を与える可能性のあるBSP全体の高レベルの変更を示します。

ピン定義をdesign.modusファイルに移行

変更：CYBSP_USER_LEDなどのピン定義がcybsp_types.hからdesign.modusファイルに移動された。

影響：これは、サイプレスが提供するBSPを変更せずにそのまま使用するプロジェクトには影響しません。ただし、カスタムdesign.modusを使用するプロジェクト、またはカスタムBSPを使用するプロジェクトを正しく機能させるには、更新が必要です。

• アプリケーションでカスタムBSPを使用する場合：カスタムBSPを再生成します（v2.x BSPを使用）。ModusToolboxユーザーガイドの「Creating a BSP for your board」セクションを参照してください。
• アプリケーションでBSPv1.xと共にカスタムdesign.modusファイルを使用する場合：次の手順を実行して、新しいBSPv2.Xライブラリを使用するように移行します。

1. KBA231080の指示に従って、例を新しいMTBフローに更新し、LibraryManagerを介してプロジェクトに最新のv2.xBSPを追加します。
2. 既存の<app_folder>\COMPONENT_CUSTOM_DESIGN_MODUS\TARGET_<BSP>\design.modusファイルの名前をdesign(1.x) .modusに変更してバックアップを作成し、アプリケーションの外部に移動します。アプリケーションに含めることができる.modusファイルは1つだけであることに注意してください。
3. design.modusファイルのv2.xバージョンを<app_folder>\..\mtb_shared\TARGET_<BSP>\latest-v2.X\COMPONENT_BSP_DESIGN_MODUSからコピーし、 <app_folder>\COMPONENT_CUSTOM_DESIGN_MODUS\TARGET_<BSP>\.に貼り付けます。
4. ModusToolbox 2.2ツール（Device-Configurator 2.20.0）とともにインストールされたDevice Configuratorを使用して、新しく追加されたdesign.modusファイルを開きます。
5. 「devicesupport.xml」を見つけるように求められたら、<app_folder>\..\mtb_shared\mtb-pdl\latest-v2.X\devicesupport.xmlに移動します。
6. アプリケーションに必要な構成をやり直します。場合によっては、design(1.x).modusファイルからパーソナリティ設定をコピーして貼り付けることができます。
   1. Device Configuratorの別のインスタンスを開き、design(1.x).modusファイルを開きます。
   2. ステップ5で行ったようにdevicesupport.xmlファイルに移動します。
   3. Peripheralsを強調表示して、[Copy]をクリックします。 
   4. 他のDevice Configuratorウィンドウを開き、対応するペリフェラルに設定を貼り付けます。ピン、クロックツリー、およびペリフェラルに必要なその他のリソースを再構成する必要がある場合があります。
7. Design(1.x).modusファイルを削除します。

更新されたクロック設定 - HFCLK0以外のHFCLKは無効にされる

この変更は、ファームウェアのクロックHALを使用してHFCLKを設定せずに、HFCLK0以外のHFCLKを使用するアプリケーションに影響を与えます。たとえば、USBアプリケーションにはHFCLK4が必要ですが、QSPIアプリケーションにはHFCLK2が必要です。これらのアプリケーションは、クロックを有効にしてカスタムdesign.modusを使用するか、ファームウェアでクロックHALを使用して、それぞれのHFCLKとそのソースを有効/設定する必要があります。

次のスニペットの例は、100MHzで実行するようにFLLを構成して50MHzのSMIF / QSPIクロック（HFCLK2）に使用する方法を示します：

   cy_rslt_t rslt;

    cyhal_clock_t clock_hf2、clock_fll、clock_imo;

    /* 最初にFLLを初期化します：FLLリソースを取得します */

    rslt = cyhal_clock_get(&clock_fll, &CYHAL_CLOCK_FLL);

    /* FLLインスタンスを初期化し、所有権を取得します */

    rslt = cyhal_clock_init(&clock_fll);

    /* クロックソースをIMOに設定します */

    rslt = cyhal_clock_get(&clock_imo, &CYHAL_CLOCK_IMO);

    rslt = cyhal_clock_set_source（&clock_fll, &clock_imo）;

    /* FLLクロック周波数を目的のHFCLK2周波数（この場合は50 MHz）に設定します */

    rslt = cyhal_clock_set_frequency(&clock_hf2, 100000000, NULL);

    /* FLLがまだ有効になっていない場合は、有効にします */

    if(!cyhal_clock_is_enabled(&clock_fll))

    {

    　       rslt = cyhal_clock_set_enabled(&clock_fll、true、true);

    }

    /* HFCLK2 – SMIFクロック–リソースを取得します */

    rslt = cyhal_clock_get(&clock_hf2, &CYHAL_CLOCK_HF [2]);

    /* HFCLK2インスタンスを初期化し、所有権を取得します */

    rslt = cyhal_clock_init(&clock_hf2);

    /* クロックソースを以前に設定したFLLに設定します */

    rslt = cyhal_clock_set_source(&clock_hf2, &clock_fll);

    /* クロック分周器を2に設定すると、50 MHzSMIFクロックになります */

    rslt = cyhal_clock_set_divider(&clock_hf2, 2）;

    /* クロックがまだ有効になっていない場合は、有効にします */

    if(!cyhal_clock_is_enabled(&clock_hf2))

    {

    　       rslt = cyhal_clock_set_enabled(&clock_hf2、true、true);

    }

    /* クロックを直接制御する必要がなくなった場合は、解放できます */

   cyhal_clock_free(&clock_hf2);

   cyhal_clock_free(&clock_fll）;

   cyhal_clock_free(&clock_imo）;

一部のボードのMPNを廃止されていないパーツに更新した

変更： CY8CPROTO-062-4343WおよびCY8CKIT-062S2-43012に同梱されているPSoC62S2パーツが新しいMPNに更新されました。MPNがCY8C624ABZI-D44からCY8C624ABZI-S2D44に変更されました。デバイス自体に機能またはパフォーマンスの変更はありません。これは、更新されたパーツ命名戦略に合わせたMPNの更新にすぎません。

影響：この変更は、標準のdesign.modusを使用した例には影響しません。カスタムdesign.modusを使用した例のみが影響を受けます。通常、BSP 2.xへのカスタムdesign.modus移植手順を使用する場合、この問題は自動的に修正されるはずです。必要な変更は、design.modusファイルの「Devicempn」値をCY8C624ABZI-D44からCY8C624ABZI-S2D44に更新することです。この変更は、BSPv2.xリリースの一部としてBSPdesign.modusファイルにすでに組み込まれているため、そのファイルからカスタムdesign.modusを作成すると、MPNが自動的に更新されます。

psoc6pdlの依存関係を新しいmtb-pdl-cat1に切り替えた

変更： BSP v2.xは、psoc6pdlの代わりに新しいmtb-pdl-cat1（psoc6pdlの更新および名前変更されたバージョン）を使用します。この新しい命名スキームにより、PDL、HAL、およびMakefileを、同様の基盤となるアーキテクチャを使用するデバイス/ファミリのさまざまなカテゴリ（cat1、cat2など）に編成できます。

影響：この変更による影響はありません。パスを更新する必要があるのは、アプリケーションコードが#include “<APP_PATH>/libs/psoc6pdl/drivers/include/cy_gpio.h”などのpsoc6pdlフォルダへの絶対パスまたは相対パスを使用してPDLヘッダーファイルを直接参照する場合のみです。このような場合は、新しい設定を使用します：#include “<APP_PATH>/../mtb_shared/mtb-pdl-cat1/drivers/include/cy_gpio.h”。

psoc6halの依存関係を新しいmtb-hal-cat1に切り替えた

変更： BSP v2.xは、psoc6halの代わりに新しいmtb-hal-cat1（psoc6halの更新および名前変更されたバージョン）を使用します。この新しい命名スキームにより、PDL、HAL、およびMakefileを、同様の基盤となるアーキテクチャを使用するデバイス/ファミリのさまざまなカテゴリ（cat1、cat2など）に編成できます。

影響：この変更による影響はありません。パスを更新する必要があるのは、アプリケーションコードが#include “<APP_PATH>/libs/psoc6hal/include/cyhal_gpio.h”などのpsoc6pdlフォルダへの絶対パスまたは相対パスを使用してPDLヘッダーファイルを直接参照している場合のみです。このような場合は、新しい設定を使用します： #include “<APP_PATH>/../mtb_shared/mtb-hal-cat1/include/yhal_gpio.h”。

psoc6makeの依存関係を新しいcore-makeやrecipe-make-cat1aに切り替えた

変更： BSP v2.xは、BSP v1.xで使用されていたpsoc6makeの代わりに、新しいcore-makeおよびreceipe-make-cat1aを使用します。この新しい命名スキームにより、PDL、HAL、およびMakefileを、同様の基盤となるアーキテクチャを使用するデバイス/ファミリのさまざまなカテゴリ（cat1、cat2など）に編成できます。

影響： KBA231080で説明されているMakefileのマイナーアップデートします。

注：このバージョンには、ModusToolboxツール2.2以降が必要です。このバージョンは、1.xバージョンとの下位互換性がありません。

Author: DheerajK_81           Version: **

Question:
When I build my application in ModusToolbox^® 2.x on Windows, I get the following error:

Makefile:163: *** Unable to find any of the available CY_TOOLS_PATHS -- C:\Users\<user>\ModusToolbox\tools_2.1 .  Stop.

Answer:
The error can be due to the following reasons:

• ModusToolbox is installed at a custom location
• Use of backslashes to represent the path to the tools directory

ModusToolbox installed at a custom location

If you install ModusToolbox in a non-default location, you must set the CY_TOOLS_PATHS environment variable for your system to point to the /ModusToolbox/tools_2.1 folder or set that variable in each Makefile. You must use forward slashes in the variable’s path, even in Windows. See “Product Versioning” in the ModusToolbox User Guide.

Use of backslashes to represent the path to the tools directory

ModusToolbox uses Cygwin make under the hood. Cygwin is a POSIX-compatible environment. POSIX paths use forward slash “/” as the separator for paths. On Windows, the path separator uses backward slash “\”. This error occurs when backward slashes are used to represent the path to the tools directory.

There are multiple methods to specify the tools version to be used in ModusToolbox as specified in the Section ”Specifying Alternate Tools Version” in ModusToolbox User Guide.

Based on the method you use to set the path of the tools directory, make the changes as described below:

Method 1: Using the System Variable

1. Go to System Environment Variables and edit the CY_TOOLS_PATHS variable. Change the path to use forward slashes.

2. Restart ModusToolbox.

Method 2: Using Project Makefile

1. Change the value of CY_TOOLS_PATHS in the Makefile variable to use forward slash. 

CY_TOOLS_PATHS+=C:/Users/<user>/ModusToolbox/tools_2.1

2.ModusToolbox detects the tools directory.

Version: **

Translation - Japanese: ModusToolbox v2.2でのPSoC6 BSP v1.xからv2.xへの移行– KBA231266 - Community Translated (JA)

This KBA describes changes and new features introduced by the Board Support Package (BSP) v2.x release which impact ModusToolbox applications using BSP v1.x (latest-v1.X tag) and provides information on how these applications can be migrated to BSP v2.x (latest-v2.X tag).

Note: BSP v2.x supports both the new “MTB flow” and earlier “lib flow” described in KBA231080. To use the new features of BSP v2.x, you must update your application to the new MTB flow by following KBA231080 - Migrating from ModusToolbox v2.1 to v2.2 before using BSP v2.x.

See the release notes and readme of each BSP for specific details changes in BSP v2.x (release.md file in the TARGET_<BSP> GitHub repo).

The following sections list the high-level changes across BSPs that could impact existing applications.

Migrated pin definitions into design.modus file

Change: The pin definitions such as CYBSP_USER_LED have been moved into the design.modus file from cybsp_types.h.

Impact: This does not impact projects using the Cypress-provided BSPs as-is without any modifications. However, projects using custom design.modus or the ones that use a custom BSP require an update for it to work properly.

• If your application uses a custom BSP: Regenerate the custom BSP (using a v2.x BSP). See the “Creating a BSP for your board” section in the ModusToolbox User Guide.
• If your application uses a custom design.modus file with BSP v1.x:  Do the following to migrate to use newer BSP v2.X libraries.

1. Follow the instructions in KBA231080 to update the example to the new MTB flow and add the latest v2.x BSP to the project through Library Manager.
2. Rename the existing <app_folder>\COMPONENT_CUSTOM_DESIGN_MODUS\TARGET_<BSP>\design.modus file as design(1.x).modus to create a backup and move it to a location that is outside the application. Note that your application can have only one .modus file.
3. Copy the v2.x version of the design.modus file from <app_folder>\..\mtb_shared\TARGET_<BSP>\latest-v2.X\COMPONENT_BSP_DESIGN_MODUS and paste it in <app_folder>\COMPONENT_CUSTOM_DESIGN_MODUS\TARGET_<BSP>\.
4. Open the newly added design.modus file using the Device Configurator installed with ModusToolbox 2.2 tools (Device-Configurator 2.20.0).
5. When prompted to find "devicesupport.xml", navigate to <app_folder>\..\mtb_shared\mtb-pdl\latest-v2.X\devicesupport.xml.
6. Redo the configuration needed by the application. In some cases, you can copy-paste the personality settings from the design(1.x).modus file:
   1. Open another instance of the Device Configurator and open the design(1.x).modus file.
   2. Navigate to devicesupport.xml file as done in Step 5.
   3. Highlight the peripheral and click Copy.
      
   4. Open the other Device Configurator window and paste the settings into the corresponding peripheral.
      You may need to re-configure pins, clock trees, and any other resources needed for the peripheral.
7. Delete the design(1.x).modus file.

Updated clock settings - HFCLKs other than HFCLK0 is disabled

This change impacts applications using HFCLKs other than HFCLK0 without setting up the HFCLK using the clock HAL in firmware. For example, USB applications need HFCLK4, while QSPI applications need HFCLK2. These applications would either need to use a custom design.modus with the clocks enabled, or use the clock HAL in firmware to enable/configure the respective HFCLKs and their sources.

The following example snippet shows configuring the FLL to run at 100 MHz use it for the SMIF/QSPI clock (HFCLK2) at 50 MHz:

      cy_rslt_t rslt;

    cyhal_clock_t clock_hf2, clock_fll, clock_imo;

    /* Initialize FLL first: Get the FLL resource */

    rslt = cyhal_clock_get(&clock_fll, &CYHAL_CLOCK_FLL);

    /* Initialize, take ownership of, the FLL instance */

    rslt = cyhal_clock_init(&clock_fll);

    /* Set the clock source to IMO */

    rslt = cyhal_clock_get(&clock_imo, &CYHAL_CLOCK_IMO);

    rslt = cyhal_clock_set_source(&clock_fll, &clock_imo);

    /* Set the FLL clock frequency to the desired HFCLK2 frequency – 50 MHz, in this case */

    rslt = cyhal_clock_set_frequency(&clock_hf2, 100000000, NULL);

    /* If the FLL is not already enabled, enable it */

    if (!cyhal_clock_is_enabled(&clock_fll))

    {

        rslt = cyhal_clock_set_enabled(&clock_fll, true, true);

    }

    /* Get the HFCLK2 – SMIF clock – resource */

    rslt = cyhal_clock_get(&clock_hf2, &CYHAL_CLOCK_HF[2]);

    /* Initialize, take ownership of, the HFCLK2 instance */

    rslt = cyhal_clock_init(&clock_hf2);

    /* Set the clock source to FLL that we configured earlier */

    rslt = cyhal_clock_set_source(&clock_hf2, &clock_fll);

    /* Set the clock divider to 2, which would result in a 50 MHz SMIF clock */

    rslt = cyhal_clock_set_divider(&clock_hf2, 2);

    /* If the clock is not already enabled, enable it */

    if (!cyhal_clock_is_enabled(&clock_hf2))

    {

        rslt = cyhal_clock_set_enabled(&clock_hf2, true, true);

    }

    /* If no longer need to directly control the clock, it can be freed */

    cyhal_clock_free(&clock_hf2);

    cyhal_clock_free(&clock_fll);

    cyhal_clock_free(&clock_imo);

Updated MPNs on some boards to non-obsolete parts

Change: The PSoC 62S2 part that ships with CY8CPROTO-062-4343W and CY8CKIT-062S2-43012 has been updated to a new MPN. The MPN has been changed from CY8C624ABZI-D44 to CY8C624ABZI-S2D44. There is no functional or performance change in the device itself. It is simply an MPN update to align with our updated part naming strategy.

Impact: This change does not impact examples using standard design.modus; only the examples using a custom design.modus will be affected. Typically, if you use the custom design.modus porting steps to BSP 2.x, this issue should automatically get fixed. The change that is required is to update the “Device mpn” value in the design.modus file from CY8C624ABZI-D44 to CY8C624ABZI-S2D44. Because this change already has been incorporated in the BSP design.modus file as part of the BSP v2.x release, the MPN is automatically updated when you create a custom design.modus from that file.

Switched psoc6pdl dependency to new mtb-pdl-cat1

Change: BSP v2.x uses the new mtb-pdl-cat1 (an updated and renamed version of psoc6pdl) instead of psoc6pdl. This new naming scheme allows you to organize PDL, HAL, and Makefiles into different categories (cat1, cat2, etc.) of devices/family that use similar underlying architecture.

Impact: There should not be any impact because of this change. You need to update the path only if the application code references any PDL header files directly using absolute or relative path to the psoc6pdl folder such as #include “<APP_PATH>/libs/psoc6pdl/drivers/include/cy_gpio.h”. In such cases, use the new structure: #include “<APP_PATH>/../mtb_shared/mtb-pdl-cat1/drivers/include/cy_gpio.h”.

Switched psoc6hal dependency to new mtb-hal-cat1

Change: BSP v2.x uses the new mtb-hal-cat1 (an updated and renamed version of psoc6hal) instead of psoc6hal. This new naming scheme allows you to organize PDL, HAL, and Makefiles into different categories (cat1, cat2, etc.) of devices/family that use similar underlying architecture.

Impact: There should not be any impact because of this change. You need to update the path only if the application code references any PDL header files directly using absolute or relative path to the psoc6pdl folder such as #include “<APP_PATH>/libs/psoc6hal/include/cyhal_gpio.h”. In such cases, use the new structure - #include “<APP_PATH>/../mtb_shared/mtb-hal-cat1/include/cyhal_gpio.h”.

Switched psoc6make dependency to new core-make and recipe-make-cat1a

Change: BSP v2.x uses the new core-make and receipe-make-cat1a instead of psoc6make used in BSP v1.x. This new naming scheme allows you to organize PDL, HAL, and Makefiles into different categories (cat1, cat2, etc.) of devices/family that use similar underlying architecture.

Impact: Minor Makefile updates described in KBA231080.

Note: This version requires ModusToolbox tools 2.2 or later. This version is not backward-compatible with 1.x versions.

Version: **

Note: If you are migrating an application created for an older version of ModusToolbox^® (v1.1) refer to Migrating from ModusToolbox v1.1 to v2.x - KBA229043.

ModusToolbox 2.2 fully supports applications created using v2.0/2.1 of the tools. That is, existing applications can be used with v2.2 tools and configurators without requiring any application changes. The application dependencies like Board Support Packages (BSPs) and libraries can also be updated to latest available versions supported by ModusToolbox 2.2.

Beginning with the ModusToolbox 2.2 release, a new way of structuring applications has been developed, called the MTB flow. Using this flow, applications can share BSPs and libraries. If needed, different applications can use different versions of the same BSP/library. Sharing resources reduces the number of files on your computer and speeds up subsequent application creation time. Shared BSPs, libraries, and versions are located in a new mtb_shared directory by default adjacent to your application directories. You can easily switch a shared BSP or library to become local to a specific application, or back to being shared. Refer to the MTB Flow section in Library Manager User Guide for more details.

Looking ahead, most example applications will use the new MTB flow. Applications that use the previous flow, now called the LIB flow, generally do not share BSPs and libraries. Applications can be migrated to the MTB flow to benefit from the new features like sharing libraries.

The easiest way to migrate existing applications to the MTB flow is to start with a ModusToolbox 2.2 application closest to yours, and port the source code over:

1. Use Project Creator (v1.2) or the Eclipse IDE for ModusToolbox v2.2 to create a new application using a similar BSP and code example to yours. Use “mtb-flow” keyword in the search field to show applications that are compatible with the MTB flow.

2. Use the Library Manager (v1.2) and add any needed libraries.

Notice that a new Shared checkbox is available, which can be used to place the selected library in a shared folder (when checked) or in a folder local to the application (when unchecked). Presence of the Shared checkbox indicates that the application uses the MTB flow.

3. Select the Version of the library if the default is not what you want. Only the versions compatible with the MTB flow are displayed. Click the ‘Update’ button after selecting all libraries.

Note: Applications that use the MTB flow and target PSoC 6 BSPs need to use BSP version 2.0.0 or later (Latest 2.X release). PSoC 6 BSP v2.X is a major update to the v1.X release and is not backward compatible.

4. Copy the source code and application configuration from the old application to the new one.

This completes the application migration.

The following section explains the changes in the structure and content of an application supporting the MTB flow, as compared to the LIB flow, for better understanding. These changes are already done as part of project creation using ModusToolbox 2.2 tools from a code example already updated to the MTB flow, if you followed the steps described above.

Makefile

1. For PSoC 6 applications, the following variable should be removed:

# Relative path to the "base" library. It provides the core makefile build infrastructure.

CY_BASELIB_PATH=libs/psoc6make

For an application to be detected as using the MTB flow, the application makefile must contain the CY_GETLIBS_SHARED_NAME and CY_GETLIBS_SHARED_PATH make variables. These variables define the name and location of the shared directory where source code for all BSPs and libraries are placed. The values shown below puts the libraries in a mtb_shared folder by default. Also, by default, this shared directory is located adjacent to application directories in the same application root path. For more details about the ModusToolbox build system and make variables, refer to the ModusToolbox User Guide.

# Relative path to the shared repo location.

CY_GETLIBS_SHARED_PATH=../

# Directory name of the shared repo location.

CY_GETLIBS_SHARED_NAME=mtb_shared

1. For applications that consist of multiple dependent projects (for example, a dual CPU application), some additional changes are required:

a. Each dependent project usually resides within its own folder within the application folder. The CY_GETLIBS_SHARED_PATH variable should point to two levels up relative to the dependent project folder, if it’s required to share the libraries with other applications:

CY_GETLIBS_SHARED_PATH=../../

b. Remove the following variables, if they exist:

# Link to the library folder

CY_EXTAPP_PATH=../shared/libs

# Link to the devicesupport.xml file

CY_DEVICESUPPORT_PATH=$(CY_EXTAPP_PATH)/psoc6pdl

# Get the absolute address where the Makefile is located

mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))

mkfile_dir := $(dir $(mkfile_path))

# Set path to the shared folders

CY_GETLIBS_PATH=$(mkfile_dir)/$(CY_EXTAPP_PATH)

c. Add the following lines to the primary project's makefile. This enables running make getlibs on the primary project to automatically invoke getlibs on the secondary project. Replace <secondary_project_name> with the folder name of the secondary project.

getlibs : getlibs_secondary

getlibs_secondary:

$(MAKE) -C ../<secondary_project_name>/ $(MAKECMDGOALS)

CYIGNORE file

Applications can use the. cyignore file to exclude code files or directories from the build process.

If existing applications contain paths to standard libraries in the cyignore file, replace these paths with the corresponding SEARCH_<library name> variable.

For example, replace "libs/psoc6cm0p" with $(SEARCH_psoc6cm0p).

The values of SEARCH_<library name> variables are auto-generated as part of running make getlibs and are available in the mtb.mk file in the application libs folder.

Note: The following library names have changed. Please use the new names indicated:

.mtb Files

These files provide information about the associated BSP/library. Each .mtb file contains:

• A URL to a git repository somewhere that is accessible by your computer such as GitHub.
• A git Commit Hash or Tag that tells which version of the library that you want.
• A path to where the library should be stored.

An .mtb file contains a string that has the format <URI>#<COMMIT>#<LOCATION>, for example:

https://github.com/cypresssemiconductorco/TARGET_CY8CPROTO-062-4343W#latest-v2.X#$$ASSET_REPO$$/TARGET_CY8CPROTO-062-4343W/latest-v2.X

The variable $$ASSET_REPO$$ points to the path defined by CY_GETLIBS_SHARED_PATH/CY_GETLIBS_SHARED_NAME, so the default value is ../mtb_shared.

If you want a library to be local to the application instead of shared, use $$LOCAL$$ instead of $$ASSET_REPO$$:

https://github.com/cypresssemiconductorco/TARGET_CY8CPROTO-062-4343W#latest-v2.X#$$LOCAL$$/TARGET_CY8CPROTO-062-4343W

There are two ways to create a .mtb file:

1. Using the Library Manager (applicable if the BSP/library is provided by Cypress or is in a custom manifest file):

• Open the Library Manager and navigate to the application directory.
• Use the check boxes under the Shared column to indicate if a BSP/library should be shared or local and select the version from the Version column.
• Click on the Update button to apply the changes.

The .mtb files for the selected libraries are created in the application’s deps folder.

2. Manually the create the .mtb file by editing a .lib files present in the deps folder of your existing application. Ensure the .mtb file content follows the correct format and change the file extension to .mtb.

Note: An application can either contain .lib files or .mtb files to declare dependencies, but not both. If a .mtb file is found, .lib files will be ignored during the make getlibs process.

Note: If a library is not in a manifest file, it will not appear in the Library Manager and will need to be managed manually. See the Manual Library Management section in the Library Manager User Guide for details.

Version: **

Translation - Japanese: ModusToolbox警告：コミットされていない/追跡されていないファイルが検出されました - KBA231252 - Community Translated (JA)

Question:
Why does my ModusToolbox application report a warning about uncommitted/untracked files?

Answer:
Some firmware compiled into a ModusToolbox application is generated by configurators. The ModusToolbox build process re-generates source code during its build process if it's out of date for any reason, such as:

• You opened a configurator and saved a change.
• You updated the selected device (DEVICE=) in your BSP's ".mk" file.
• You updated your device support library.
  
• You upgraded or patched your tools to include a newer configurator.

ModusToolbox uses git to distribute and update firmware, and the above changes may trigger a warning from git when trying to update those repositories (for example, with Library Manager or directly on the command-line with git). The warning looks like this:

WARNING: Uncommitted/Untracked files detected in "<path to repository>".

Save your work in source control before updating this library.

Skipping current reference...

This is the git system's way of telling you that there are modified files that haven't been dealt with, and you need to do something about it. The system is being careful to make sure changes are not accidentally lost.

1 The device support library depends on your target device. Here are the more common options:
PSoC 6: psoc6pdl or mtb-pdl
PSoC 4: mtb-psoc4-pdl
Bluetooth: 20706A2, 20719B2, 20721B2, 20735B1, 20819A1, 20820A1, 20835B1, 43012C0

Resolve the Warning:

There are several ways you can resolve this warning, depending on your needs and whether you are using a default Build Support Package (BSP) or a custom BSP.

Default BSP

If you changed one of the default BSPs provided by Cypress (as described above), you should create a custom BSP and then revert the changes in the default BSP.

1. To create a custom BSP based on the current (modified) BSP, following the instructions in the BSP chapter of the ModusToolbox User Guide.

2. To revert the default BSP, run the following commands using the appropriate shell configured to run git.

# NOTE: This will delete any files that should not be present.

git -C <path to repository from warning> clean -dfx

# NOTE: This reverts files back to their original state.

git -C <path to repository from warning> restore .

3. Make sure everything is clean and ready:

git -C <path to repository from warning> status

4. Make sure the output includes the following text:

"nothing to commit, working tree clean"

Custom BSP

If you made a change in one of your custom BSPs, you may either revert that change (follow instructions under Default BSP), or commit the change.

To accept the changes, commit or check them in to your source code control system. For example, if you use git:

     # NOTE: make sure you look at the changes and are sure they are correct.

     git -C <path to repository from warning> status

     # NOTE: after you are sure the changes are acceptable, and commit them.

     git -C <path to repository from warning> add .

     git -C <path to repository from warning> commit