[Zephyr®シリーズ] 第４回 Kconfigとデバイスツリーの概要と実践的活用法 (日本語ブログ)   今回からZephyrの応用編に突入していきます。 今回は、Kconfigとデバイスツリーの概要とそしてそれを活用できるようハンズオンによるプログラミングの実践を行っていきます。   Zephyr RTOSの特徴として前回紹介したソフトウェアのスケーラビリティ（再利用性）により一度開発したソフトウェアを別のプロジェクトや派生製品に再利用することが容易に行えるようになり迅速な開発が可能になります。   そして、幅広いハードウェアプラットフォームに対応するために、Zephyrには「Kconfig」 と 「デバイスツリー (Devicetree)」 という強力な構成システムを採用しています。   これにより、同じC/C++言語のソースコードを書き換えることなく、設定ファイルの変更だけで異なるマイコンボードにプログラムを移植することができます。 本記事では、Kconfigとデバイスツリーの基本的な仕組みを解説します。そして実践的な活用法として、第３回で作成したハードウェアに依存しないＬチカプログラムを修正して、それを「FRDM-MCXA153」と「FRDM-MCXN947」という異なるマイコンのボードで動作するようにします。   異なるボード（マイコンやプロセッサ）で同じアプリケーションを動作させるため、Kconfigとデバイスツリーを使って実践的プログラミング方法を説明していきます。     目次   前準備 Kconfigの基礎 デバイスツリー(Devicetree)の基礎 ソフトウェアの再利用性を高めるためのベストプラクティス Kconfigとデバイスツリーの実践 簡単なプログラムを作成する（ハンズオン） 1. プログラムの仕様 2. ディレクトリ構成 3. Kconfig と prj.conf の作成 4. デバイスツリーオーバーレイとボード別設定の作成 5. ハードウェア非依存の共通コード (main.c) の作成 6. ビルドと実行 まとめ 前準備   HWの準備   本記事では、主に以下のボードを使用してプログラムの作成と動作確認を行います。 FRDM-MCXA153 (メインで使用) また、作成したプログラムのポータビリティ（移植性）を確認するための補足として、以下のボードも使用します。 FRDM-MCXN947   SWの準備   Zephyrの開発環境（Zephyr SDK, Westコマンドなど）がすでに構築されていることを前提とします。構築がまだの場合は、第２回の環境構築の記事を参照してください。 [Zephyr® シリーズ] 第２回 はじめてのビルドと実機動作（日本語ブログ）   Zephyrシリーズ第３回で作成したLチカプログラムを使用します。まだ作成していない方は、前回の記事を参考に作成することをおすすめします。 [Zephyr® シリーズ] 第3回 初めてのLチカとソフトウェアの再利用性（日本語ブログ）   Kconfigの基礎     Kconfigは、Linuxカーネルでも採用されている設定システムです。Zephyrでは、カーネル機能、デバイスドライバー、サブシステム、アプリケーションの固有設定など、ソフトウェア機能を「有効にするか無効にするか」、あるいは「どのようなパラメータを設定するか」を管理するために使用されます。 Kconfigには以下２つのファイルが重要になります。 「Kconfig」 ファイル：　選択可能な設定項目（シンボル）とそのデフォルト値、依存関係を定義します。 「prj.conf」 ファイル*：　アプリケーションの開発者が、「Kconfig」 で定義された項目に対して実際に設定したい値（「y」 で有効化、あるいは具体的な数値など）を記述するファイルです。 Kconfigを使用することで、不要なコードをコンパイルから除外し、メモリ使用量を最適化することができます。 そして、Kconfigやprj.confファイルはすべてテキストで記述されています。 機能を有効にする方法 prj.confファイルではプロジェクト全体に対して機能の有効化を行っています。 例えば、ADCとDAC、そしてOPAMPドライバはKconfigで定義されています。このKconfigで定義されている機能を利用する場合に、prj.confに「CONFIG_」を先頭に追加して宣言します。 Kconfig：ADCの定義Kconfig：ADCの定義 prj.conf例prj.conf例   デバイスツリー(Devicetree)の基礎   Devicetree例Devicetree例   デバイスツリーは、マイコンがどのようなハードウェア（CPU、メモリ、周辺機器、ピン設定など）に対応しているか、それらのハードウェアの設定や構成を記述するテキストファイルです。 そして、こられ設定や構成はマクロに展開されます。   C言語のコードの中にハードウェアのアドレスを直接書き込む（ハードコーディングする）代わりに、デバイスツリーに記述された情報をZephyrのマクロを通じて読み込むことで、ハードウェア非依存のプログラミングが可能になります。 ノードとプロパティ：　ハードウェアの各要素は「ノード」として階層構造で表現され、レジスタアドレスや割り込み番号などが「プロパティ」として記述されます。 「.dts」 と 「.dtsi」：　マイコンやボードごとの標準的なハードウェア構成は 「.dts」 (Devicetree Source) や 「.dtsi」 (Include) ファイルでZephyrリポジトリ内にあらかじめ定義されています。 dts：　ボードのデバイスツリーとして記述 dtsi：　SoC・マイコンのデバイスツリーとして記述され、デバイスメーカーから提供されます。 「.overlay」 ファイル：　アプリケーション固有の配線（例：特定のGPIOピンにLEDを繋いだ）や、標準設定に対して上書きを行いたい場合に作成するファイルです。   ソフトウェアの再利用性を高めるためのベストプラクティス   Zephyrでソフトウェアの再利用性を高めるためには、以下の設計原則に従うことが重要です。 ハードウェア依存部分と非依存部分の分離：　Cコード（`main.c` など）には、特定のマイコンのレジスタ操作やピン番号を直接書かないようにします。 デバイスツリーの「エイリアス」を活用する：　アプリケーションからは、実際のハードウェアノード（例：「`&red_led`」 や 「`&gpioa`」）を直接参照するのではなく、「aliases（エイリアス）」 ノードで定義した抽象的な名前（例：「`led0`」など）を参照するようにします。これにより、ボードが変わってもエイリアスの指す先を変更するだけで対応できます。 ボード別デバイスツリー（オーバーレイ）を準備する　：派生製品など一部の機能に違いがある場合に、ボード別にハードウェアの差分がある部分のみ上書き（オーバーレイ）することができます。 Kconfigによる機能の切り替え　: アプリケーションの動作パラメータや特定の機能のオン・オフは、C言語の 「#define」 ではなく Kconfig シンボルを使用して制御します。   Kconfigとデバイスツリーの実践   ここから、実際に実践で使用できるようになるために簡単なプログラムを作成しながらKconfigとデバイスツリーの使い方を学んでいきます。     簡単なプログラムを作成する（ハンズオン） プログラムは、前回作成したLチカプログラムを変更して以下のような仕様のプログラムを作成します。   ここでは実践として、「FRDM-MCXA153」と「FRDM-MCXN947」の両方で動く共通アプリケーションを作成します。 1. プログラムの仕様 ソースコード：　「第３回 始めてのLチカプログラム〜」を利用し、以下修正を加える LEDの点滅速度：　Kconfigを用いて点滅間隔を設定可能にする。 ボタン機能（機能の有効/無効化）：　Kconfigの設定により、ボタン機能の有効/無効を切り替えられるようにする。有効な場合は、ボタンを押すたびにLEDの「点滅」と「常時点灯」が切り替わる。 ボード名の出力：　起動時に標準出力（ターミナル）へ、Kconfigで設定した「デバイス（ボード）名」を出力する。 2. ディレクトリ構成   プロジェクトのディレクトリ構成を以下のようにします。   前回作成したLチカプログラムの「my_hello」フォルダにKconifgファイルやboardsフォルダを追加します。ファイルの追加はどのような方法でも問題ありません。 WindowsではPowerShellの`ni`コマンドやテキストエディターで「新規ファイル作成」をして、my_helloフォルダに保存してください。 LInuxでは、`touch`コマンドを使用することで空の新規ファイルを作成することが可能です。   「boards/」 以下のファイルによって、ボードごとのハードウェア差異や固有設定を吸収します。     my_hello/ ├── CMakeLists.txt ├── Kconfig <- 新規追加：アプリ独自のKconfig ├── prj.conf <- アプリの共通設定 ├── src/ │ └── main.c <- ハードウェア非依存の共通コード └── boards/　<- 新規作成フォルダ 　├── frdm_mcxa153.overlay <- 新規作成：FRDM-MCXA153用のデバイスツリー設定 　├── frdm_mcxa153.conf <- 新規作成：FRDM-MCXA153用のKconfig設定 　├── frdm_mcxn947_cpu0.overlay <- 新規作成：FRDM-MCXN947用のデバイスツリー設定 　└── frdm_mcxn947_cpu0.conf <- 新規作成：FRDM-MCXN947用のKconfig設定   参考：　アプリケーションのディレクトリ内に特定のファイルを作成することで、Zephyrのビルドシステム（West）は自動的にそれらを認識し、設定を適用します。 Kconfigの追加：　 アプリケーションフォルダに 「Kconfig」 ファイルを置くことで、独自のコンフィグシンボルを追加できます。 ボードごとの設定 (「boards/」 ディレクトリ)：　アプリケーション内に 「boards」 ディレクトリを作成し、そこに 「[ボード名].overlay」 や 「[ボード名].conf」 を配置すると、そのボードをターゲットとしてビルドした時にのみ、自動的にオーバーレイやKconfigの上書きが適用されます。   3. Kconfig と prj.conf の作成 まず、アプリケーションルートに独自の 「Kconfig」 を作成し、アプリケーション専用のパラメータを定義します。 my_hello/Kconfig   mainmenu "my LED blink" config CUSTOM_BLINK_RATE_MS int "LED blink rate in milliseconds" default 1000 help Set LED blink frequency. #LEDの点滅周期（ミリ秒）を設定します config ENABLE_BUTTON_TOGGLE bool "Enable button to toggle LED state" default y help Enable button to toggle LED state. # ボタン入力によるLEDの点滅/点灯状態>の切り替え機能を有効にします。 config BOARD_NAME_STRING string "Board Name String" default "Unknown Board" help Set board name for printf. # 標準出力に表示するボード名を設定します。 source "Kconfig.zephyr"     次に、アプリケーション全体の共通設定として 「prj.conf」 を記述します。 このprj.confに先ほど作成したKconfigシンボルを使って以下のように設定します。 my_hello/prj.conf   # GPIOの有効化 CONFIG_GPIO=y # アプリケーションの共通設定 CONFIG_CUSTOM_BLINK_RATE_MS=500 CONFIG_ENABLE_BUTTON_TOGGLE=y   4. デバイスツリーオーバーレイとボード別設定の作成 「boards」ディレクトリを作成し、各ボードに向けたファイルを用意します。 FRDM-MCXA153用 (メインボード)     アプリケーションからは `sw0` という標準的なエイリアスでアクセスできるように、ボード上のボタン（`sw2`）をマッピングします。`led0` はすでにボード定義にあるためここでは省略できますが、必要に応じて明示的に上書きすることも可能です。   my_hello/boards/frdm_mcxa153.overlay / { aliases { sw0 = &user_button_2; /* FRDM-MCXA153のユーザーボタン */ }; };   my_hello/boards/frdm_mcxa153.conf   CONFIG_BOARD_NAME_STRING="FRDM-MCXA153 Board"   アプリケーション（main.c）内でこの.conf(ボード別Kconfig)のシンボルを参照して、printf関数でボード名を標準出力させることが可能になります。 FRDM-MCXN947用  FRDM-MCXN947でも同様に 「sw0」 を定義します。ボタンのハードウェア名が異なる場合でも、ここで吸収します。   実際、ボードによりハードウェア（ペリフェラルやインスタンスが異なる）名が異なる場合は、デバイスツリー内のエイリアスノードに実際のハードウェアを割当てます。 my_hello/boards/frdm_mcxn947_cpu0.overlay   / { aliases { sw0 = &user_button_3; /* FRDM-MCXN947のユーザーボタン */ }; };   my_hello/boards/frdm_mcxn947_cpu0.conf   MCXN947でビルドした時だけ、LEDの点滅速度を250msに上書き変更してみます。   CONFIG_BOARD_NAME_STRING="FRDM-MCXN947 Board" CONFIG_CUSTOM_BLINK_RATE_MS=250 FRDM-MCXA153とFRDM-MCXN947では、アプリケーションコードは同じですが、Lチカの点滅の挙動をここでそれぞれ設定することができます。 5. ハードウェア非依存の共通コード (main.c) の作成 「my_hello/src/main.c」を以下のように記述します。   LED制御部分は、前回の記事で作成したハードウェア非依存のコード（「led0」 エイリアスを使用）を再利用し、そこにKconfigとボタンの制御を組み込んでいます。 my_hello/src/main.c   #include #include #include /* Devicetreeのエイリアスを参照する */ /* どのボードでも、一番目のLEDは通常 "led0" と定義されています */ #define LED0_NODE DT_ALIAS(led0) #define SW0_NODE DT_ALIAS(sw0) /* エイリアスからGPIO仕様(ポート、ピン、フラグ)を取得 */ static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios); /* ボタン機能がKconfigで有効化されている場合のみコンパイルされる部分 */ #ifdef CONFIG_ENABLE_BUTTON_TOGGLE static const struct gpio_dt_spec sw = GPIO_DT_SPEC_GET(SW0_NODE, gpios); static struct gpio_callback button_cb_data; static bool is_blinking = true; void button_pressed(const struct device *dev, struct gpio_callback *cb, uint32_t pins) { is_blinking = !is_blinking; if (!is_blinking) { /* 点滅オフ時はLEDを点灯させた状態にする */ gpio_pin_set_dt(&led, 1); } } #endif //CONFIG_ENABLE_BUTTON_TOGGLE int main(void) { int ret; /* Kconfigで設定されたボード名を出力 */ printf("Starting application on %s\n", CONFIG_BOARD_NAME_STRING); /* デバイスの準備確認 */ if (!gpio_is_ready_dt(&led)) { return -1; } /* ピンの設定 (Devicetreeで定義された初期状態などを考慮して設定) */ ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE); if (ret < 0) { return -1; } #ifdef CONFIG_ENABLE_BUTTON_TOGGLE if (!gpio_is_ready_dt(&sw)) { return -1; } ret = gpio_pin_configure_dt(&sw, GPIO_INPUT); if (ret < 0) { return -1; } ret = gpio_pin_interrupt_configure_dt(&sw, GPIO_INT_EDGE_TO_ACTIVE); if (ret < 0) { return -1; } gpio_init_callback(&button_cb_data, button_pressed, BIT(sw.pin)); gpio_add_callback(sw.port, &button_cb_data); #endif //CONFIG_ENABLE_BUTTON_TOGGLE while (1) { #ifdef CONFIG_ENABLE_BUTTON_TOGGLE if (is_blinking) { ret = gpio_pin_toggle_dt(&led); } #else /* ピンの状態を反転 (ボタン機能が無効な場合は常に点滅) */ ret = gpio_pin_toggle_dt(&led); #endif //CONFIG_ENABLE_BUTTON_TOGGLE /* Kconfigで設定された点滅間隔で待機 */ k_msleep(CONFIG_CUSTOM_BLINK_RATE_MS); } return 0; }     6. ビルドと実行 さて、実際に動作を確認してみます。ビルド環境セットアップやwestコマンド有効化については、前回の記事を参考にしてください。 まずは、下記のコマンド手順の様にインストールしているzephyrprojectリポジトリのディレクトリに移動し、west 有効化を行ってから進めます。 FRDM-MCXA153 での動作確認（メイン） 以下のコマンドでビルドし、FRDM-MCXA153に書き込みます。   ##　ホームディレクトリからZephyrprojectディレクトリに移動 cd ~/zephyrproject ## west環境を有効化 source .venv/bin/activate ## zephyr v4.3をチェックアウトしていない場合は、前回（第３回 初めてのLチカとソフトウェアの再利用性）を参考にv4.3をチェックアウトしてください。 west build -b frdm_mcxa153 my_hello west flash     実行結果   コンソール出力コンソール出力   LED点滅、点灯モード切り替えLED点滅、点灯モード切り替え   ターミナルに 「Starting application on FRDM-MCXA153 Board」 と表示されます。 LEDは 500ms 間隔で点滅します（「prj.conf」 の設定）。 SW2（「custom-sw」）を押すと点灯状態になり、再度押すと点滅に戻ります。 FRDM-MCXN947 での動作確認 全く同じC言語のソースコードのまま、ボード指定だけを変えてビルドします。   # -pオプションを使用し、frdm_mcxa153のビルド情報をクリーンしてビルドします。 west build -p -b frdm_mcxn947//cpu0 my_hello west flash   実行結果   「boards/frdm_mcxn947_cpu0.conf」 の内容が自動的に反映され、ターミナルには 「Starting application on FRDM-MCXN947 Board」 と表示されます。 LEDは 250ms 間隔で速く点滅します（「prj.conf」の設定）。 SW3（MCXN947側のボタンにマッピングされた 「user_button_3」）を押すことでLED点灯、点滅動作が同様に切り替わります。 FRDM-MCXA153とFRDM-MCXN947では、LED制御しているGPIOやスイッチボタンに繋がっているGPIOが異なりますが、デバイスツリーによりその差分が吸収され、アプリケーションのプログラムとハードウェアがきれいに分離できていることが実感できたと思います。   まとめ     今回は、ZephyrにおけるKconfigとデバイスツリーの基本を学び、それらを活用してハードウェア依存部分をCコードから分離する手法を実践しました。   デバイスツリーのオーバーレイ（「.overlay」）によってハードウェア設定を吸収し、ボード別Kconfigファイル（「.conf」）によってアプリケーションのパラメータを柔軟に変更したり、機能を簡単に有効、無効にすることができ、同一のソースコードを複数の異なるボードで再利用する強力な仕組みを体験できたかと思います。   =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。）​ Zephyrのソフトウェア再利用性を高めるための特徴であるデバイスツリーとKconfigの概要を説明します。そして、それらを実践で利用するためにステップを踏んで説明していきます。 このぜZephyrシリーズ第１回から今回の第４回までを読み終えると、Zephyr RTOSを利用してプログラムが書けるようになります。 General Purpose Microcontrollers MCX 日本語ブログ

[Zephyr ®系列] 第 4 部分：Kconfig 和设备树的概述及实际应用（日语博客）   从现在开始，我们将进入 Zephyr 的高级主题学习。 本次课程将概述 Kconfig 和设备树，然后进行实践编程练习，帮助您有效地使用它们。   如前所述，Zephyr RTOS 的一个关键特性是其软件可扩展性（可重用性），这使得在其他项目或衍生产品中重用一次开发的软件变得容易，从而实现快速开发。   此外，为了支持各种硬件平台，Zephyr 采用了名为“Kconfig”和“Devicetree”的强大配置系统。   这样，您只需更改配置文件，即可将程序移植到不同的微控制器板，而无需使用相同的 C/C++ 语言重写源代码。 本文解释了Kconfig和设备树的基本机制。作为实际应用，我们将修改第三部分中创建的与硬件无关的LED闪烁程序，使其能够在两种不同的微控制器板“ FRDM-MCXA153 ”和“ FRDM-MCXN947 ”上运行。   为了在不同的电路板（微控制器和处理器）上运行同一个应用程序，我们将解释使用 Kconfig 和设备树的实用编程方法。     目录   准备 Kconfig基础知识 设备树基础知识 提高软件重用性的最佳实践 Kconfig 和设备树的实际应用 创建一个简单的程序（动手实践） 1. 程序规范 2. 目录结构 3. 创建 Kconfig 和 prj.conf 文件 4. 创建设备树覆盖层和板级特定设置 5. 与硬件无关的通用代码（main.c）创造 6. 构建并运行 总结 准备   硬件准备   本文将主要使用以下开发板来创建和测试程序。 FRDM-MCXA153 （主要用途） 此外，以下电路板将作为辅助工具，用于验证您所创建的程序的可移植性。 FRDM-MCXN947   SW 准备   本指南假设您已搭建好 Zephyr 开发环境（Zephyr SDK、West 命令等）。如果您尚未搭建，请参阅第二篇关于环境搭建的文章。 【Zephyr ®系列】第二部分：首次构建与测试（日语博客）   我们将使用在 Zephyr 系列第三篇文章中创建的 LED 闪烁程序。如果您尚未创建该程序，我们建议您参考上一篇文章进行创建。 【Zephyr ®系列】第三部分：LED 闪烁和软件复用的第一步（日语博客）   Kconfig基础知识     Kconfig 是 Linux 内核中使用的一种配置系统。在 Zephyr 中，它用于管理是否“启用或禁用”软件功能，或者“设置哪些参数”，例如内核函数、设备驱动程序、子系统和应用程序特定的设置。 以下两个文件对 Kconfig 很重要： “Kconfig”文件定义了可选的配置项（符号）、它们的默认值和依赖关系。 "prj.conf" 文件*：应用程序开发人员在此文件中指定他们想要为 "Kconfig" 中定义的项目设置的值（例如，使用 "y" 启用它们或提供特定的数值）。 使用 Kconfig，您可以排除编译中不必要的代码并优化内存使用。 此外，Kconfig 和 prj.conf 文件都是以文本格式编写的。 如何启用此功能 prj.conf 文件启用整个项目的功能。 例如，ADC、DAC 和 OPAMP 驱动程序在 Kconfig 中定义。使用 Kconfig 中定义的函数时，需要在 prj.conf 文件开头添加“CONFIG_”来声明它们。 Kconfig：ADCの定義Kconfig：ADC定义 prj.conf例prj.conf 示例   设备树基础知识   Devicetree例设备树示例   设备树是一个文本文件，它描述了微控制器支持的硬件（CPU、内存、外设、引脚设置等），以及这些硬件的设置和配置。 然后将这些设置和配置展开成宏。   Zephyr 宏可以读取设备树中描述的信息，而不是直接将硬件地址写入 C 代码（硬编码），从而实现与硬件无关的编程。 节点和属性：硬件的每个元素在层次结构中都表示为一个“节点”，寄存器地址、中断号等则被描述为“属性”。 ".dts" 和 ".dtsi"：每个微控制器和电路板的标准硬件配置都在 Zephyr 存储库中的 ".dts"（设备树源）和 ".dtsi"（包含）文件中预定义。 dts：被描述为电路板的设备树。 dtsi：描述 SoC/微控制器的设备树，由设备制造商提供。 ".overlay" 文件：当您想要覆盖特定应用程序的接线（例如，将 LED 连接到特定的 GPIO 引脚）或默认设置时，将创建此文件。   提高软件重用性的最佳实践   为了提高 Zephyr 软件的可重用性，遵循以下设计原则非常重要： 硬件相关部分与硬件无关部分的分离： C 代码（`main.c`）例如，避免直接描述具体的微控制器寄存器操作或引脚编号。 利用设备树别名：应用程序不应直接引用实际的硬件节点（例如 `&red_led` 或 `&gpioa`），而应引用在 `aliases` 节点中定义的抽象名称（例如 `led0`）。这样，只需更改别名指向的内容，即可轻松适配不同的开发板。 准备特定于电路板的设备树（覆盖） ：当某些功能存在差异时，例如在衍生产品中，您可以仅对每个电路板上硬件不同的部分进行覆盖（覆盖）。 使用 Kconfig 切换功能：应用程序行为参数和特定功能的开/关状态使用 Kconfig 符号而不是 C 语言“#define”进行控制。   Kconfig 和设备树的实际应用   接下来，我们将通过创建一个简单的程序来学习如何使用 Kconfig 和设备树，以便我们能够在实践中实际使用它们。     创建一个简单的程序（动手实践） 该程序将通过修改我们上次创建的 LED 闪烁程序来创建，并将具有以下规格。   在这里，作为一项实践练习，我们将创建一个可以在“FRDM-MCXA153”和“FRDM-MCXN947”上运行的通用应用程序。 1. 程序规范 源代码：使用“第 3 部分：你的第一个 LED 闪烁程序”中的代码，并进行以下修改。 LED闪烁速度：可以使用Kconfig设置闪烁间隔。 按钮功能（启用/禁用）：可通过 Kconfig 设置启用或禁用按钮功能。启用后，按下按钮可在 LED 闪烁和常亮之间切换。 输出板卡名称：启动时，Kconfig 中配置的“设备（板卡）名称”将输出到标准输出（终端）。 2. 目录结构   项目目录结构应如下所示：   将 Kconfig 文件和 boards 文件夹添加到上次创建的 LED 闪烁程序的“my_hello”文件夹中。添加文件的方法不限。 在 Windows 系统中，使用 PowerShell `ni` 命令或文本编辑器创建一个新文件，并将其保存在 `my_hello` 文件夹中。 在 Linux 系统中，可以使用 `touch` 命令创建一个新的空文件。   “boards/”目录下的文件用于处理硬件差异以及每个主板特有的独特设置。     my_hello/ ├── CMakeLists.txt ├── Kconfig <- 新規追加：アプリ独自のKconfig ├── prj.conf <- アプリの共通設定 ├── src/ │ └── main.c <- ハードウェア非依存の共通コード └── boards/　<- 新規作成フォルダ 　├── frdm_mcxa153.overlay <- 新規作成：FRDM-MCXA153用のデバイスツリー設定 　├── frdm_mcxa153.conf <- 新規作成：FRDM-MCXA153用のKconfig設定 　├── frdm_mcxn947_cpu0.overlay <- 新規作成：FRDM-MCXN947用のデバイスツリー設定 　└── frdm_mcxn947_cpu0.conf <- 新規作成：FRDM-MCXN947用のKconfig設定   注意：通过在应用程序目录中创建特定文件，Zephyr 的构建系统（West）将自动识别它们并应用设置。 添加 Kconfig：您可以通过在应用程序文件夹中放置“Kconfig”文件来添加自己的配置符号。 板级特定设置（“boards/”目录）：通过在应用程序中创建“boards”目录并将“[板级名称].overlay”或“[板级名称].conf”文件放置于其中，overlay和Kconfig覆盖将仅在以该板级为目标进行构建时自动应用。   3. 创建 Kconfig 和 prj.conf 文件 首先，在应用程序根目录中创建您自己的“Kconfig”文件，并定义特定于应用程序的参数。 my_hello/Kconfig   mainmenu "my LED blink" config CUSTOM_BLINK_RATE_MS int "LED blink rate in milliseconds" default 1000 help Set LED blink frequency. #LEDの点滅周期（ミリ秒）を設定します config ENABLE_BUTTON_TOGGLE bool "Enable button to toggle LED state" default y help Enable button to toggle LED state. # ボタン入力によるLEDの点滅/点灯状態>の切り替え機能を有効にします。 config BOARD_NAME_STRING string "Board Name String" default "Unknown Board" help Set board name for printf. # 標準出力に表示するボード名を設定します。 source "Kconfig.zephyr"     其次，作为整个应用程序的通用设置，还有“prj.conf”。这件事将会被写下来。 在 prj.conf 文件中，使用您刚刚创建的 Kconfig 符号按如下方式进行配置： my_hello/prj.conf   # GPIOの有効化 CONFIG_GPIO=y # アプリケーションの共通設定 CONFIG_CUSTOM_BLINK_RATE_MS=500 CONFIG_ENABLE_BUTTON_TOGGLE=y   4. 创建设备树覆盖层和板级特定设置 创建一个名为“boards”的目录，并为每个电路板准备必要的文件。 FRDM-MCXA153主板     我们将电路板上的按钮（`sw2`）映射出来，以便应用程序可以使用标准别名`sw0`访问它。`led0`已经在电路板定义中，因此这里可以省略，但如果需要，也可以显式地覆盖它。   my_hello/boards/frdm_mcxa153.overlay / { aliases { sw0 = &user_button_2; /* FRDM-MCXA153のユーザーボタン */ }; };   my_hello/boards/frdm_mcxa153.conf   CONFIG_BOARD_NAME_STRING="FRDM-MCXA153 Board"   通过在应用程序 (main.c) 中引用此 .conf（特定于板的 Kconfig）中的符号，可以使用 printf 函数将板名称输出到标准输出。 适用于 FRDM-MCXN947 同样，我们在 FRDM-MCXN947 中定义了“sw0”。这可以处理按钮硬件名称的任何差异。   事实上，如果硬件名称（因外围设备或实例而异）在不同电路板之间有所不同，则需要将实际硬件分配给设备树中的别名节点。 my_hello/boards/frdm_mcxn947_cpu0.overlay   / { aliases { sw0 = &user_button_3; /* FRDM-MCXN947のユーザーボタン */ }; };   my_hello/ boards/frdm_mcxn947_cpu0.conf   我将尝试仅在使用 MCXN947 构建时将 LED 闪烁速度设置为 250ms。   CONFIG_BOARD_NAME_STRING="FRDM-MCXN947 Board" CONFIG_CUSTOM_BLINK_RATE_MS=250 FRDM-MCXA153 和 FRDM-MCXN947 的应用程序代码相同，但您可以在此处单独配置 LED 的闪烁行为。 5. 与硬件无关的通用代码（main.c）创造 在“my_hello/src/main.c”中写入以下内容：   LED 控制部分重用了上一篇文章中创建的硬件无关代码（使用“led0”别名），并将 Kconfig 和按钮控制集成到其中。 my_hello/ src/main.c   #include #include #include /* Devicetreeのエイリアスを参照する */ /* どのボードでも、一番目のLEDは通常 "led0" と定義されています */ #define LED0_NODE DT_ALIAS(led0) #define SW0_NODE DT_ALIAS(sw0) /* エイリアスからGPIO仕様(ポート、ピン、フラグ)を取得 */ static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios); /* ボタン機能がKconfigで有効化されている場合のみコンパイルされる部分 */ #ifdef CONFIG_ENABLE_BUTTON_TOGGLE static const struct gpio_dt_spec sw = GPIO_DT_SPEC_GET(SW0_NODE, gpios); static struct gpio_callback button_cb_data; static bool is_blinking = true; void button_pressed(const struct device *dev, struct gpio_callback *cb, uint32_t pins) { is_blinking = !is_blinking; if (!is_blinking) { /* 点滅オフ時はLEDを点灯させた状態にする */ gpio_pin_set_dt(&led, 1); } } #endif //CONFIG_ENABLE_BUTTON_TOGGLE int main(void) { int ret; /* Kconfigで設定されたボード名を出力 */ printf("Starting application on %s\n", CONFIG_BOARD_NAME_STRING); /* デバイスの準備確認 */ if (!gpio_is_ready_dt(&led)) { return -1; } /* ピンの設定 (Devicetreeで定義された初期状態などを考慮して設定) */ ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE); if (ret < 0) { return -1; } #ifdef CONFIG_ENABLE_BUTTON_TOGGLE if (!gpio_is_ready_dt(&sw)) { return -1; } ret = gpio_pin_configure_dt(&sw, GPIO_INPUT); if (ret < 0) { return -1; } ret = gpio_pin_interrupt_configure_dt(&sw, GPIO_INT_EDGE_TO_ACTIVE); if (ret < 0) { return -1; } gpio_init_callback(&button_cb_data, button_pressed, BIT(sw.pin)); gpio_add_callback(sw.port, &button_cb_data); #endif //CONFIG_ENABLE_BUTTON_TOGGLE while (1) { #ifdef CONFIG_ENABLE_BUTTON_TOGGLE if (is_blinking) { ret = gpio_pin_toggle_dt(&led); } #else /* ピンの状態を反転 (ボタン機能が無効な場合は常に点滅) */ ret = gpio_pin_toggle_dt(&led); #endif //CONFIG_ENABLE_BUTTON_TOGGLE /* Kconfigで設定された点滅間隔で待機 */ k_msleep(CONFIG_CUSTOM_BLINK_RATE_MS); } return 0; }     6. 构建并运行 现在，让我们实际测试一下它的功能。请参考上一篇文章，了解如何设置构建环境和启用 west 命令。 首先，按照下面的命令说明导航到已安装的 zephyrproject 存储库目录，并在继续操作之前启用 west。 已确认 FRDM-MCXA153（主）运行正常 使用以下命令构建并将其写入 FRDM-MCXA153。   ##　ホームディレクトリからZephyrprojectディレクトリに移動 cd ~/zephyrproject ## west環境を有効化 source .venv/bin/activate ## zephyr v4.3をチェックアウトしていない場合は、前回（第３回 初めてのLチカとソフトウェアの再利用性）を参考にv4.3をチェックアウトしてください。 west build -b frdm_mcxa153 my_hello west flash     执行结果   コンソール出力控制台输出   LED点滅、点灯モード切り替えLED闪烁和常亮模式切换   终端上将显示“正在FRDM-MCXA153板上启动应用程序”的消息。 LED 灯以500 毫秒的间隔闪烁（“prj.conf”）。（设置）。 按下 SW2（“自定义开关”）即可将其打开，再按下即可使其恢复闪烁状态。 已确认FRDM-MCXN947运行正常 我们将使用完全相同的 C 源代码来构建该项目，只更改电路板规格。   # -pオプションを使用し、frdm_mcxa153のビルド情報をクリーンしてビルドします。 west build -p -b frdm_mcxn947//cpu0 my_hello west flash   执行结果   “boards/frdm_mcxn947_cpu0.conf”的内容将自动应用，终端将显示“在FRDM-MCXN947板上启动应用程序”。 LED 灯以250 毫秒的间隔快速闪烁（在“prj.conf”中配置）。 按下 SW3（MCXN947 上映射到“user_button_3”的按钮）同样可以在 LED 点亮和闪烁之间切换。 虽然 FRDM-MCXA153 和 FRDM-MCXN947 使用不同的 GPIO 来控制 LED 和开关按钮，但设备树有效地吸收了这些差异，这表明应用程序和硬件是如何清晰分离的。   总结     在本节课中，我们学习了 Zephyr 中 Kconfig 和设备树的基础知识，并练习了如何利用它们将硬件相关的部分与 C 代码分离。   我相信您已经体验到了一种强大的机制，可以在多个不同的电路板上重用相同的源代码，其中硬件设置被设备树覆盖（“overlay”）吸收，应用程序参数可以灵活地更改，并且可以使用特定于电路板的 Kconfig 文件（“conf”）轻松启用或禁用功能。   ========================== 我们目前无法回复此帖子“评论”部分留下的评论。 由此给您带来的不便，我们深表歉意。如有任何疑问，请参考“NXP 技术问题 - 如何联系我们（日语博客）”。 （如果您已经是恩智浦的分销商或与恩智浦有合作关系，您可以直接咨询您的代表。） 本文档概述了设备树和 Kconfig，这两项功能旨在增强 Zephyr 的软件重用性。随后，本文档详细介绍了在实践中使用这些功能所需的步骤。 读完 Zephyr 系列的第一册到第四册后，你将能够使用 Zephyr 实时操作系统编写程序。 通用微控制器 MCX 日本博客

PDB ADC pre trigger sequence error recovery Hi NXP community, ADC0/ADC1 Interrupts Stop After Runtime Flash Erase/Program Operation on S32K144 As a continuation of my previous question, I need some clarification on how to properly recover from a PDB ADC pre-trigger sequence error on the S32K144. I tried the following three methods, but only one of them worked correctly. Method 1 (working): Stop PDB0 and PDB1 before performing the flash erase/program operation. After the flash operation is complete, restart both PDBs and re-enable the corresponding ISRs. With this approach, no PDB sequence error occurs. Method 2: After the flash erase/program operation was completed, I stopped and restarted PDB0 and PDB1. However, a PDB pre-trigger sequence error occurred. I then attempted to recover by stopping and restarting the PDB modules again, but the sequence error persisted. Method 3: Method 3 (Not Working): I did not stop or restart PDB0 and PDB1 during the flash erase/program operation. Instead, after the operation completed, one pending PDB ISR and ADC ISR were triggered. Inside the PDB ISR, I attempted to clear the sequence error flag using: PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); The corresponding ADC ISR was then executed, and reading the ADC result register cleared the COCO flag. I expected this to prevent further pre-trigger sequence errors, but the issue still persisted and this method did not work. My question is: once a PDB pre-trigger sequence error has been triggered, is it possible to recover the PDB/ADC operation and resume normal triggering without resetting the system? Or does the PDB need to be stopped and restarted beforehand to avoid entering an unrecoverable state? Re: PDB ADC pre trigger sequence error recovery Hi PetrS, I tried the following approach. After the flash erase operation without PDB stop, micro got one pending ADC ISR callback. Inside that callback, after reading the ADC result register, I call the functions below to check and recover from a PDB sequence error: ```c void PDB1_check_seq_err(void) { if ((PDB1->CH[0].S & PDB_S_ERR_MASK) != 0) { PDB1->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); PDB1->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK); PDB1->SC |= (uint32_t)PDB_SC_PDBEN_MASK; PDB1->SC |= (uint32_t)PDB_SC_SWTRIG_MASK; } } void PDB0_check_seq_err(void) { if ((PDB0->CH[0].S & PDB_S_ERR_MASK) != 0) { PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); PDB0->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK); PDB0->SC |= (uint32_t)PDB_SC_PDBEN_MASK; PDB0->SC |= (uint32_t)PDB_SC_SWTRIG_MASK; } } ``` The recovery sequence I used is: 1. Clear the `ERR` flag. 2. Stop the PDB. 3. Re-enable and restart the PDB. With this stop-and-start sequence, everything works correctly again: subsequent pre-triggers occur, and the ADC ISR callbacks are invoked normally. However, I still do not fully understand why this is necessary. The Reference Manual states that clearing the `ERR` condition and reading the ADC result register (which clears `COCO`) should release the lock. In my case, that alone does not seem to be sufficient, and a PDB stop/start sequence is required for recovery. Also, I observed that `PDBn->SC |= PDB_SC_SWTRIG_MASK` is not strictly required. Even without issuing a software trigger, the lock is released and the ADC ISR starts executing again after the PDB restart. Could you please clarify why stopping and restarting the PDB is necessary in this scenario, even though the RM indicates that clearing `ERR` and `COCO` should release the lock? Re: PDB ADC pre trigger sequence error recovery Hi, Clearing PDB_S_ERR alone is usually not sufficient to recover from a pre-trigger sequence error because the ADC/PDB sequence may already be out of synchronization. Based on your test results, preventing the condition by stopping the PDB before the flash operation and restarting it afterwards appears to be the most reliable approach. If recovery is attempted after the error occurs, I would recommend ensuring that both the PDB and ADC state are fully re-synchronized. This may include disabling the PDB, clearing pending PDB status flags, ensuring all pending ADC conversion results have been read (COCO cleared), re-enabling the PDB, and reloading the configuration if required before triggering resumes. According to the RM, the pre-trigger lock is released when the corresponding COCO flag is set, when the pre-trigger is disabled, or when the PDB is disabled, so a full PDB disable/enable sequence may also be worth investigating. BR, Petr

IMX93はデバイスツリー経由でのみCCM CLKOを自由に実行できます みなさんこんにちは、 MX93_PAD_CCM_CLKO3__CCMSRCGPCMIX_CLKO3 に、フリーランニング 12288000Hz のクロックを出力したいです。 マニュアルによると、これはIMX93_CLK_AUDIO_PLLから導き出すことができるはずです。 device-treeのみでこれを実現する方法のヒントを教えてもらえますか? Linux Re: imx93 free running ccm clko via device tree only IMX93クロックドライバーを参照してください。これをサポートするには新しいPLLを追加する必要があります。DTSだけを変更することはできません

OP-TEE in Falcon Mode || iMX8MP_EVK Hi, I want to enable OP-TEE along with Falcon Mode on the i.MX8MP EVK. Machine: imx8mpevk Repository: https://github.com/nxp-imx/imx-manifest Branch: imx-linux-walnascar XML: imx-6.12.34-2.1.0.xml Currently, I am using meta-imx-fastboot (lf-6.12.20-2.0.0-secure) to achieve fast boot via Falcon Mode. However, when Falcon Mode is enabled, OP-TEE gets disabled. As per my requirement, I need both OP-TEE and Falcon Mode to be enabled simultaneously. Could you please guide me on how to enable OP-TEE in Falcon Mode on the i.MX8MP EVK? i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Security Yocto Project Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @Sanjiv_Mns  Currently, the meta-imx-fastboot layer does not support OP-TEE. It should be possible in principle, but it is not implemented yet. Explanation: In the default BSP, the OP-TEE start address and size are calculated during the U-Boot proper boot stage based on the rom_pointer (see: https://github.com/nxp-imx/uboot-imx/blob/lf-6.12.20-2.0.0/arch/arm/mach-imx/dt_optee.c#L13). The rom_pointer has different meaning/values in the SPL, compared to U-Boot proper. So, the ft_add_optee_node function cannot be executed from SPL without further changes. Thanks, Elena Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @elena_popa  Could you please guide me on how to proceed further to achieve the SPL → OP-TEE → Linux boot flow? I’d like to understand the correct steps and components involved to make this work reliably. I also came across the following link where a similar flow was implemented on STM32MP platforms: https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ Could you please let me know whether this approach is applicable to my use case, or if parts of it can be reused or adapted for achieving the same boot sequence on my platform? Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @elena_popa I have already completed this activity, and it is now booting successfully on my i.MX8MP board. The current boot flow is: SPL → ATF → OP-TEE → Linux Everything is working as expected. Thank you for your comments @elena_popa   [ 0.412349] optee: probing for conduit method. [ 0.412373] optee: revision 4.6 (788dc101b05ae47b) [ 0.412678] optee: dynamic shared memory is enabled [ 0.413062] optee: initialized driver Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @Sanjiv_Mns  I managed to enable and run OP-TEE in Falcon Mode for i.MX 8MP.  The boot flow on i.MX 8MP will be: SPL -> ATF -> OP-TEE -> Linux Here are the steps: 1. Remove the following line in the conf/layer.conf of the meta-imx-fastboot layer. MACHINE_FEATURES:remove = "optee"  2. In imx-boot mkimage source code, modify the iMX8M/mkimage_fit_atf_kernel.sh script to add the OP-TEE binary into the FIT image. 6a7,9 > # keep backward compatibility > [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe000000" > 19a23,41 > [ -z "$BL32" ] && BL32="tee.bin" > PAD=../scripts/pad_image.sh > > if [ ! -f $BL32 ]; then > BL32=/dev/null > else > echo "Building with TEE support, make sure $BL31 is compiled with spd. If you do not want tee, please delete $BL32" >&2 > if [ $TEE_COMPRESS_ENABLE ]; then > echo "Start compress $BL32" >&2 > rm -f $BL32.lz4 > lz4 -9 $BL32 $BL32.lz4 >&2 > BL32=$BL32.lz4 > ./$PAD $BL32 >&2 > fi > echo "$BL32 size: " >&2 > ls -lct $BL32 | awk '{print $5}' >&2 > LOADABLES="$LOADABLES, \"tee-1\"" > fi > 71a94,103 > tee-1 { > description = "TEE firmware"; > data = /incbin/("$BL32"); > type = "firmware"; > arch = "arm64"; > compression = "none"; > load = <$TEE_LOAD_ADDR>; > entry = <$TEE_LOAD_ADDR>; > }; > 87c119 < loadables = "kernel","dtb"; --- > loadables = "tee-1","kernel","dtb"; 3. In the kernel device tree, add manually the OP-TEE nodes (firmware and reserved memory). Edit the imx8mp.dtsi device tree and: - add the following OP-TEE firmware node in the root node ("/"). firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; - add the OP-TEE reserved memory regions under the reserved-memory node: optee_core@56000000 { reg = <0 0x56000000 0 0x1e00000>; no-map; }; optee_shm@57e00000 { reg = <0 0x57e00000 0 0x200000>; no-map; };  4. Build the image and write it on the boot device. 5. To check that OP-TEE has started and Linux probed the driver, run: root@imx8mp-lpddr4-evk:~# dmesg | grep optee [ 0.000000] OF: reserved mem: 0x0000000057e00000..0x0000000057ffffff (2048 KiB) nomap non-reusable optee_shm@57e00000 [ 0.000000] OF: reserved mem: 0x0000000056000000..0x0000000057dfffff (30720 KiB) nomap non-reusable optee_core@56000000 [ 2.581777] optee: probing for conduit method. [ 2.590862] optee: revision 4.8 (e7ed997213779e3d) [ 2.596363] optee: dynamic shared memory is enabled [ 2.601567] optee: initialized driver 6. If you want to test the OP-TEE you can run xtest. root@imx8mp-lpddr4-evk:~# xtest Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression+pkcs11+regression_nxp # ###################################################### * regression_1001 Core self tests o regression_1001.1 Core self tests regression_1001.1 OK o regression_1001.2 Core dt_driver self tests regression_1001.2 OK o regression_1001.3 Core transfer list self tests ..... +----------------------------------------------------- 49354 subtests of which 0 failed 161 test cases of which 0 failed 0 test cases were skipped TEE test application done! Please, let me know if you have issues during enablement. Thanks, Elena

S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hi We are working on Secure Debug authentication for the S32N55 platform and have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600. We are now trying to extend this to the CRS domain (HSE_DEBUG_DOMAIN_APP = 0x1B) and have the following questions: --- [Q1] Is ADKP usable for CRS domain Secure Debug authentication? After provisioning ADKP via HSE_OTP_FOEM_ADKP_ATTR_ID, is it possible to use the same ADKP for CRS domain (APP) Secure Debug authentication via HSE_DEBUG_CMD_APP_CHALLENGE? --- [Q2] Does SetOwnerDebugKeyMap() need to be called separately per MU (FSS MU vs CRS MU)? Per the RM description of hseOwnerDebugKeyMapConfig_t: "This service is called for each installed device owner individually from an owning MU. HSE FW assumes the owner identity based on the MU this service request is sent to." Our current implementation calls SetOwnerDebugKeyMap() (HSE_SRV_ID_DEBUG_KEY_MAPPING) only through FSS MU (MU0), mapping aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP. - Is a separate SetOwnerDebugKeyMap() call required through the CRS MU for CRS domain authentication? - If so, which MU number should be used for the CRS domain on S32N55? --- [Q3] Does SetOwnerDebugKeyMap() need to be called on every boot? The RM states: "Only the numOfAuthorizationRefEntries and numOfAuthenticationRefEntries are logged, rest of the entries are ignored." This implies the key mapping is volatile and not stored in NVM. Does this mean SetOwnerDebugKeyMap() must be called on every boot (after SU rights are granted) for both FSS and CRS domains? --- [Q4] Correct keyRef value for APP_CHALLENGE In hseDebugAuthorizeStartCmd_t, the keyRef field references the index mapped via hseOwnerDebugKeyMapConfig_t. Since we map aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP, we send keyRef = 0x00 for CRS domain authentication. Is this correct? --- [Q5] Response size and packet structure for APP_CHALLENGE Per hseDebugAuthorizeProofProvCmd_t byte map, the packet structure is always 32 bytes (2 packets x 8 words). HSE_CR_APP_RESPONSE_SIZE = 16U vs HSE_CR_FSS_OR_HSE_RESPONSE_SIZE = 32U. For APP_CHALLENGE, should the host send: - 16 bytes of AES-encrypted response + 16 bytes of zero padding = 32 bytes total? - Or only 16 bytes? Currently, after sending FLAG_START + DebugSignalMap(4 bytes) + Response(16 bytes) + FLAG_END, HSE2 does not respond and T32 hangs waiting indefinitely. When we send 32 bytes (16-byte response + 16-byte zero padding), we observe the same hang. --- For reference: - Sherpa_Cdd_AllocateChannel() always allocates MU0 (FSS) - SetOwnerDebugKeyMap(): aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP (0x00000302), called with SU rights - crs_auth.cmm: DEBUG_TARGET=0x1B, OID=0xFF*16, keyRef=0x00 - AUTH_MODE_REQ passes successfully (HSE_DEBUG_WAITING_RESPONSE_TO_CHG received) - Challenge received: 32 bytes - After sending Response, no ACK (0x4A4A4A4A) received from HSE2 Please see the attached CMM script and log for reference. Thank you in advance. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you for your suggestion. As requested, I have created a new post to track the CRS (APP domain) Secure Debug authentication issue: [S32N55 HSE2 — CRS (APP Domain) Secure Debug Authentication via hseDebugCardCmd_t] (Please search the title above in NXP Community) This issue is currently blocking our customer delivery schedule. Could you please review the new post at your earliest convenience? The CMM script (crs_auth.cmm) and log file are attached in the new post. Thank you very much for your urgent support. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you for your response.  We have additional questions regarding hseDebugCardCmd_t implementation for CRS (APP) domain Secure Debug authentication on S32N55. --- [Q1] Is the Owner ID (ownerId) in hseDebugCardInfo_t the same value as provisioned via hseOwnerDebugKeyMapConfig_t? Our device is configured in single-owner scenario where Fss_Firmware_au8Oid[] = {0xFF * 16}. Should the ownerId field in hseDebugCardCmd_t also be set to 0xFF * 16? Or does it need to match a specific value provisioned during Device Owner installation? --- [Q2] Does hseDebugCardCmd_t need to be sent after APP_CHALLENGE, or instead of hseDebugAuthorizeProofProvCmd_t? Per RM: "For APP based options, debug signals are enabled and authorized only through the debug cards authentication (see hseDebugCardCmd_t)(field is ignored)." Our current flow: 1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) 2. rx_authmode → HSE_DEBUG_WAITING_RESPONSE_TO_CHG received 3. APP_CHALLENGE → rx_challenge (32 bytes received) 4. hseDebugCardCmd_t sent directly (skipping hseDebugAuthorizeProofProvCmd_t) 5. HSE2 stops responding (T32 hangs at FLAG_END of CARD_REQUEST) Should hseDebugAuthorizeProofProvCmd_t (appChallengeAuth = AES256-CMAC) be sent BEFORE hseDebugCardCmd_t? Or should hseDebugCardCmd_t be sent directly after rx_challenge without ProofProv? --- [Q3] What is the correct Authentication Tag (authTag) computation for hseDebugCardTag_t when using MAC scheme? We are using: authScheme.macScheme.macAlgo = HSE_MAC_ALGO_CMAC (0x11) authTag = AES256-CMAC(key=ADKP, data=Challenge[32 bytes]) authLen = 16 Is this the correct computation? Or should the CMAC input include additional fields (OID, domain map, etc.)? --- [Q4] What is the correct packet structure for hseDebugCardCmd_t? Based on the RM byte map, our current implementation: Packet 1 (32 bytes): KRI(4B) + CMD(4B=0x5DCDEB77) + OID(16B=0xFF*16) + AuthScheme(8B=CMAC) Packet 2 (32 bytes): enabledDebugDomainMap(bit27=0x08000000) + padding(28B) Packet 3: debugDomainMapping(4B) + numOfAllowedUids(2B) + reserved(2B) + authLen(2B) + reserved(2B) + authTag(256B) Is this structure correct? HSE2 stops responding after receiving the OID field (0xFF bytes). --- Could you please let me know your email?  I will send you cmm file for crs auth. BRs. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your post. Pleased to hear that the Secure Debug authentication for the S32N55 platform have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600. I will continue to help check with the details for your new issues, sorry that I did not see the attached CMM script and log for reference, would you mind uploading them again to share with us? BR Chenyin Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your reply. There are already 6 questions existed in this post, and may take a relative long time to investigate, in order for improving the efficiency,  for additional questions, I suggest creating a new post to track. And as you mentioned, there would be scripts/logs attached for checking, but I do not see in your post, may I know if they would be uploaded again? BR Chenyin Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your reply. 1. As always, we will try our best to support your queries. 2. I understand it is a urgence issue, but as what I had mentioned in previous support, S32N55 is still in pre-production phase, it is not yet supported via the community channel, (during this period, we suggest directly contacting your FAE/Distributor to accelerate the efficiency)so it would take relative long time to reply, furthermore, the secure debug with LC advanced is usually at a relatively late stage of development, the document/samples are still limited in recent term. Sorry for your inconvenience. BR Chenyin Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your patience, below are some initial comments for your reference [Q1] Is ADKP usable for CRS domain Secure Debug authentication? [Comments]: Yes, the used key for App domain secure debug authentication is selected from the hseOwnerDebugKeyMapConfig_t->pOwnerCardAuthenticationRef, it could includes the ADKP 's keyhandle. [Q2] Does SetOwnerDebugKeyMap() need to be called separately per MU (FSS MU vs CRS MU)? [Comments]: SetOwnerDebugKeyMap() should bound to the Device owner , not MU. The Device owner could includes multiple cohorts which has multiple MU instances. If FSS and CRS are included in the same device owner, it could be called by the CRS MU or FSS MU. [Q3] Does SetOwnerDebugKeyMap() need to be called on every boot? [Comments]:  It should not be called on every boot, the configuration should be saved in the SYS-IMG or fuse, otherwise the secure debug will fail after repowering the device, it does not meet the design expectation of secure debug. However not sure where to store this configuration from the current available resource. [Q4] Correct keyRef value for APP_CHALLENGE In hseDebugAuthorizeStartCmd_t, the keyRef field references the index mapped via hseOwnerDebugKeyMapConfig_t. Since we map aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP, we send keyRef = 0x00 for CRS domain authentication. Is this correct? [Comments]: Yes, if  ADKP handle is the first entry of OwnerCardAuthenticationRef and the user wants to use ADKP to authenticate CRD debug, the authKeyRef  should be 0(The index of ADKP handle entry) [Q5] Response size and packet structure for APP_CHALLENGE [Comments]: For App debug, besides the debug signal map and challenge response data fileds, the other unused data  in packet 1 can be filled with 0. Since the corresponding documents are not yet updated fully for this topic(the S32N55 is still at early stage), there is limited information we would provide. Sorry for your inconvenience. BR Chenyin  Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you again for your continued support. We fully understand that S32N55 is still in the pre-production phase and that documentation/resources for this topic are currently limited. We sincerely apologize for the additional questions, but as our customer delivery schedule is approaching and this is a critical blocker, we are compelled to ask for a bit more guidance. We have applied your previous comments (Q1-Q5): keyRef=0x00, ADKP in pOwnerCardAuthenticationRef, and Packet 1 filled to 32 bytes (debugSignalMap 4B + appChallengeAuth 16B + unused 12B = 0). However, we are still blocked at the ProofProv / CARD_REQUEST stage. Our current status: 1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) -> OK (HSE2 returns 0x4A4A4A4A) 2. APP_CHALLENGE -> OK (32-byte Challenge received) 3. ProofProv (hseDebugAuthorizeProofProvCmd_t): - Packet 1 = debugSignalMap(4B=0) + appChallengeAuth(16B AES256-CMAC) + unused(12B=0) - All 32 bytes transmitted successfully over SDC-600 - >>> HSE2 gives NO response after this <<< The SDC-600 TX appears to stall shortly after ~20 bytes and HSE2 never sends any response frame. Could you please clarify the following about the APP (CRS) domain authentication sequence: [Q1] After the host sends ProofProv (hseDebugAuthorizeProofProvCmd_t with appChallengeAuth) for APP_CHALLENGE, does HSE2 send an intermediate response frame back to the host? Or does HSE2 remain silent and wait for the next command? For reference, in the FSS domain, after ProofProv the HSE2 returns 0x4A4A4A4A. We observe NO such response in APP domain. Is this expected? [Q2] What is the correct ordering between ProofProv (hseDebugAuthorizeProofProvCmd_t) and CARD_REQUEST (hseDebugCardCmd_t) for APP_CHALLENGE? - Option A: APP_CHALLENGE -> ProofProv -> (HSE2 response?) -> CARD_REQUEST - Option B: APP_CHALLENGE -> CARD_REQUEST directly (ProofProv skipped for APP) - Option C: some other sequence Since RM states debugSignalMap is 'ignored' for APP and authorization happens 'only through the debug card authentication', should ProofProv be sent at all for APP domain, or should we go directly to CARD_REQUEST after the challenge? [Q3] Could you please provide the complete command sequence for APP (CRS) domain Secure Debug authentication from COMM_START to the final authorization response? We would like to confirm the exact order and which commands expect a response from HSE2, specifically: COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE -> [ProofProv?] -> [CARD_REQUEST?] -> [final response?] Any reference flow or example for the APP/CRS domain would be extremely helpful, as the current behavior (HSE2 silent after ProofProv) does not match the FSS domain flow. Thank you very much for your understanding and support. Best regards, Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello,   Thanks for your reply, I understand, and will always. try our best to support. 1. I have downloaded the cmm and auth files you shared from the other post S32N55 HSE2 CRS domain authentication does not complete, are they still the same one currently used? 2. For your questions listed later: [Q1] Is the Owner ID (ownerId) in hseDebugCardInfo_t the same value as provisioned via hseOwnerDebugKeyMapConfig_t? [Comments]: Yes, the OID of hseDebugCardInfo_t is just the ownerid of Device Owner installation service. [Q2] Does hseDebugCardCmd_t need to be sent after APP_CHALLENGE, or instead of hseDebugAuthorizeProofProvCmd_t? [Comments]: hseDebugAuthorizeProofProvCmd_t should be sent before sending CARD_REQUEST [Q3] What is the correct Authentication Tag (authTag) computation for hseDebugCardTag_t when using MAC scheme? [Comments]:  Sorry that no obvious description about this in API RM. But the authentication tag for App domain may not use the received challenge, the challenge is used for hseDebugAuthorizeProofProvCmd_t. For user's CRS domain debug, maybe it is authTag = AES256-CMAC(key=ADKP, data=hseDebugCardInfo_t). You may have a try. [Q4] What is the correct packet structure for hseDebugCardCmd_t? [Comments]:  The structure of hseDebugCardCmd_t could be referred to the comment in HSE FW API interface which is more clear than the description in HSE FW API RM. by checking your original script shared, we found some errors about hseDebugCardCmd_t structure, see the attached word. For any other files that you may not be conveniently shared within the post, you may send them to me via the private message BR Chenyin

S32J100ではMCU_performresetは発生していません こんにちは、 Mcu_performReset機能を使ってコントローラをリセットしようとしていますが、PCはリセット機能から出てきて、このリセット機構Power_Ip_Specific_RequestPerformReset()を扱う機能には機能リセットか破壊リセットかのデータがありません。S32DSの設定を試みましたが、問題は解決しません。 私はSW32J100_RTD_R23-11_0.8.0_CD04_HF01、S32DSバージョン3.6.7を使用しています。 どこで間違っているのか教えてもらえますか? ありがとうございます アモル Re: MCU_performreset is not happening in S32J100 こんにちは、 @PavelL さん。 状況は理解しました。この件については現場のエンジニアに連絡します。 サポートありがとうございます。 よろしくお願いいたします。 アモル Re: MCU_performreset is not happening in S32J100 こんにちは、 @Ajadhav5 さん。 現在お手元にある製品、まだ正式に発売されていないNPI(新製品導入)についてお手伝いしています。 これらの製品の早期アクセス権を得たお客様は、現場エンジニアを割り当てていることにご注意ください。指定されたフィールドエンジニアが、この製品に関する問題や懸念、問い合わせの主要なサポートチャネルとなります。 正式リリース後、オンラインサポートチームは本製品に対してより幅広いサポートを展開していきます。それまでは、私たちは必要な支援を提供する体制が整っていません。 このマターについてご理解いただけるとありがとうございます。今後もパートナーシップをさらに深めていきたいと思います。ご質問があれば、ぜひフィールドエンジニアにご連絡いただくか、私と私のチームに直接お問い合わせください。 ご理解いただきありがとうございます。 よろしくお願いいたします。 パベル

CODEWARRIOR 11.1 I used a M9S08QG8 micro chip, with this code in 1984. I am using windows 11 now. Is there a compiler that will debug this code Now. Also, is this chip still made? void my_main(void) { initial(); } void initial(void) { if(loopcount==2){goto initend;} PTADD_PTADD0 = 0; //io direction PTADD_PTADD1 = 0; PTADD_PTADD2 = 0; PTADD_PTADD3 = 1; PTBDD_PTBDD0 = 1; PTBDD_PTBDD1 = 1; //PTADD_PTADD4 = 0; //io direction //PTADD_PTADD5 = 0; //PTBDD_PTBDD6 = 1; //osc direction //PTBDD_PTBDD7 = 0; //PTBPE_PTBPE6 = 1; //pullup resistor //PTBPE_PTBPE7 = 0; //PTAPE_PTAPE0 = 0; //PTAPE_PTAPE1 = 0; //PTAPE_PTAPE2 = 0; //PTAPE_PTAPE4 = 0; //PTAPE_PTAPE5 = 0; //ICSC1_IREFS = 0; //select external osc param //ICSC1_CLKS0 = 0; //ICSC1_CLKS1 = 1; //ICSC2_EREFS = 0; //ICSC2_BDIV0 = 0; //ICSC2_BDIV1 = 0; PTAD_PTAD0 = 0; PTAD_PTAD1 = 0; PTAD_PTAD2 = 0; PTAD_PTAD3 = 0; PTBD_PTBD0 = 1; PTBD_PTBD1 = 1; bobbin_one_white=0; bobbin_two_white=0; bobbin_one_black=0; bobbin_two_black=0; bobbin_count_one=0; bobbin_count_two=0; bobbin_one_count_up_down = 20; bobbin_two_count_up_down = 20; bobbin_three_count_up_down = 20; bobbin_four_count_up_down = 20; rewind1 = 1; rewind2 = 1; rewind3 = 1; rewind4 = 1; programlength = 10; buzzcount = 0; buzzdelay = 0; buzzonoff = 1; needle = 20; delay = 100; light = 20; speed = 1000; c=0; //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=1;} //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=0;} //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=1;} //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=0;} PTAD_PTAD3 = 0; //buzzonoff = 1; buzzonoff = 0; initend: PTAD_PTAD3 = 1; //PTAD_PTAD3 = 0; c=0; peace(); } void peace(){ loopcount=2; onemoretime: buzzer(); //__RESET_WATCHDOG(); for(speed=0;speed<=delay;speed++){} if(PTAD_PTAD2==0){PTAD_PTAD3=0;buzzonoff=1;} //if(PTAD_PTAD2==0){setlength();} // winding bobbin on bobbin winder if(PTAD_PTAD0==0){bobbin_one_black++;PTBD_PTBD1=0;if(bobbin_count_one==1){bobbin_count_one=2;}} if(PTAD_PTAD0==1){bobbin_one_white++;PTBD_PTBD1=1;halfturna=1;bobbin_count_one=1;} if(bobbin_count_one==2){ if(halfturna == 1){fullturna=1;bobbin_count_one=0;}} // hook sewing if(PTAD_PTAD1==0){bobbin_two_black++;PTBD_PTBD0=0;if(bobbin_count_two==1){bobbin_count_two=2;}} if(PTAD_PTAD1==1){bobbin_two_white++;PTBD_PTBD0=1;halfturnb=1;bobbin_count_two=1;} if(bobbin_count_two==2){ if(halfturnb== 1){fullturnb=1;bobbin_count_two=0;}} if(fullturna==1)goto bobbinwinder; if(fullturnb==1)goto hook; goto onemoretime; Re: CODEWARRIOR 11.1 Hello, The CodeWarrior tool version 11.1, is supported in windows 11, this tool supports different connections [P&E USB Multilink Universal / USB Multilink, P&E Cyclone, Open-Source BDM, P&E Full chip simulation] You can download the tool from this link: CodeWarrior® for MCUs (Eclipse IDE) v11.1 The device status is in "NOT RECOMMENDED FOR NEW DESIGNS (NRND)", but you can still order from the distributors available stock, please refer to product part page in buy options section MC9S08QG8CDTE Product Information | NXP Semiconductors Best Regards, Luis

コードウォリアー 11.1 I used a M9S08QG8 micro chip, with this code in 1984. I am using windows 11 now. Is there a compiler that will debug this code Now. Also, is this chip still made? void my_main(void) { initial(); } void initial(void) { if(loopcount==2){goto initend;} PTADD_PTADD0 = 0; //io direction PTADD_PTADD1 = 0; PTADD_PTADD2 = 0; PTADD_PTADD3 = 1; PTBDD_PTBDD0 = 1; PTBDD_PTBDD1 = 1; //PTADD_PTADD4 = 0; //io direction //PTADD_PTADD5 = 0; //PTBDD_PTBDD6 = 1; //osc direction //PTBDD_PTBDD7 = 0; //PTBPE_PTBPE6 = 1; //pullup resistor //PTBPE_PTBPE7 = 0; //PTAPE_PTAPE0 = 0; //PTAPE_PTAPE1 = 0; //PTAPE_PTAPE2 = 0; //PTAPE_PTAPE4 = 0; //PTAPE_PTAPE5 = 0; //ICSC1_IREFS = 0; //select external osc param //ICSC1_CLKS0 = 0; //ICSC1_CLKS1 = 1; //ICSC2_EREFS = 0; //ICSC2_BDIV0 = 0; //ICSC2_BDIV1 = 0; PTAD_PTAD0 = 0; PTAD_PTAD1 = 0; PTAD_PTAD2 = 0; PTAD_PTAD3 = 0; PTBD_PTBD0 = 1; PTBD_PTBD1 = 1; bobbin_one_white=0; bobbin_two_white=0; bobbin_one_black=0; bobbin_two_black=0; bobbin_count_one=0; bobbin_count_two=0; bobbin_one_count_up_down = 20; bobbin_two_count_up_down = 20; bobbin_three_count_up_down = 20; bobbin_four_count_up_down = 20; rewind1 = 1; rewind2 = 1; rewind3 = 1; rewind4 = 1; programlength = 10; buzzcount = 0; buzzdelay = 0; buzzonoff = 1; needle = 20; delay = 100; light = 20; speed = 1000; c=0; //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=1;} //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=0;} //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=1;} //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=0;} PTAD_PTAD3 = 0; //buzzonoff = 1; buzzonoff = 0; initend: PTAD_PTAD3 = 1; //PTAD_PTAD3 = 0; c=0; peace(); } void peace(){ loopcount=2; onemoretime: buzzer(); //__RESET_WATCHDOG(); for(speed=0;speed<=delay;speed++){} if(PTAD_PTAD2==0){PTAD_PTAD3=0;buzzonoff=1;} //if(PTAD_PTAD2==0){setlength();} // winding bobbin on bobbin winder if(PTAD_PTAD0==0){bobbin_one_black++;PTBD_PTBD1=0;if(bobbin_count_one==1){bobbin_count_one=2;}} if(PTAD_PTAD0==1){bobbin_one_white++;PTBD_PTBD1=1;halfturna=1;bobbin_count_one=1;} if(bobbin_count_one==2){ if(halfturna == 1){fullturna=1;bobbin_count_one=0;}} // hook sewing if(PTAD_PTAD1==0){bobbin_two_black++;PTBD_PTBD0=0;if(bobbin_count_two==1){bobbin_count_two=2;}} if(PTAD_PTAD1==1){bobbin_two_white++;PTBD_PTBD0=1;halfturnb=1;bobbin_count_two=1;} if(bobbin_count_two==2){ if(halfturnb== 1){fullturnb=1;bobbin_count_two=0;}} if(fullturna==1)goto bobbinwinder; if(fullturnb==1)goto hook; goto onemoretime; Re: CODEWARRIOR 11.1 こんにちは、 CodeWarriorツールバージョン11.1はWindows 11でサポートされており、このツールはさまざまな接続に対応しています[P&E USB Multilink Universal / USB Multilink、P&E Cyclone、オープンソースBDM、P&E Full chip simulation] このツールはこちらのリンクからダウンロードできます: CodeWarrior® for MCUS (Eclipse IDE) v11.1 デバイスの状態は「新しいデザインには推奨されません(NRND)」ですが、代理店の在庫からも注文可能です。製品情報の購入オプションセクションMC9S08QG8CDTE製品部品ページを参照してください 。NXPセミコンダクターズ 敬具、ルイス

PDB ADC プリトリガーシーケンスエラー回復 こんにちは、NXPコミュニティの皆さん、 S32K144では、ランタイムフラッシュ消去/プログラム操作後にADC0/ADC1割り込みが停止します。 前回の質問の続きとして、S32K144におけるPDB ADCのプリトリガーシーケンスエラーから適切に復旧する方法について、いくつか説明が必要です。 以下の3つの方法を試しましたが、そのうち1つだけが正しく動作しました。 方法1(動作中): フラッシュ消去／書き込み操作を実行する前に、PDB0とPDB1を停止してください。 フラッシュ処理が完了したら、両方のPDBを再起動し、対応するISRを再度有効にします。 この方法を用いると、PDB配列のエラーは発生しない。 方法2： フラッシュメモリの消去／書き込み操作が完了した後、PDB0とPDB1を停止して再起動しました。しかし、PDBプレトリガーシーケンスエラーが発生しました。そこで、PDBモジュールを停止して再起動することで復旧を試みましたが、シーケンスエラーは解消されませんでした。 方法3: 方法3(効果なし): フラッシュ消去／書き込み操作中、PDB0とPDB1を停止または再起動しませんでした。その代わりに、操作が完了した後、保留中のPDB ISRとADC ISRがそれぞれ1つずつトリガーされました。 PDB ISR内で、以下の方法でシーケンスエラーフラグをクリアしようと試みました。 PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); 対応するADC割り込みサービスルーチンが実行され、ADC結果レジスタを読み取ることでCOCOフラグがクリアされた。これでさらなるプリトリガーシーケンスエラーを防ぐつもりでしたが、問題は依然として解決せず、この方法はうまくいきませんでした。 私の質問は、PDBプリトリガーシーケンスエラーが発生した場合、システムをリセットせずにPDB/ADCの動作を回復し、通常のトリガー動作を再開することは可能かということです。それとも、回復不能な状態に陥るのを避けるために、PDBを事前に停止して再起動する必要があるのでしょうか？ Re: PDB ADC pre trigger sequence error recovery こんにちは、 PDB_S_ERRをクリアするだけでは、ADC/PDBシーケンスが既に同期していない可能性があるため、プリトリガーシーケンスエラーからの回復には通常不十分です。テスト結果に基づくと、フラッシュ処理の前にPDBを停止し、処理後に再起動することで、この問題を回避するのが最も確実な方法であると思われます。 エラー発生後に復旧を試みる場合は、PDBとADCの両方の状態が完全に再同期されていることを確認することをお勧めします。これには、PDB の無効化、保留中の PDB ステータス フラグのクリア、保留中のすべての ADC 変換結果が読み取られていることの確認 (COCO がクリアされていること)、PDB の再有効化、および再開をトリガーする前に必要に応じて構成の再読み込みが含まれる場合があります。 RMによると、プレトリガーロックは対応するCOCOフラグが設定されたとき、プリトリガーが無効化されたとき、またはPDBが無効化されたときに解除されるため、完全なPDB無効化・有効シーケンスも検討する価値があるかもしれません。 BR、ペトル Re: PDB ADC pre trigger sequence error recovery こんにちは、PetrSさん。 私は以下の方法を試してみました。 PDB停止なしでフラッシュ消去操作を行った後、マイクロコントローラは保留中のADC ISRコールバックを1つ受け取りました。そのコールバック関数内で、ADC結果レジスタを読み取った後、以下の関数を呼び出してPDBシーケンスエラーをチェックし、エラーから回復します。 「`c」 void PDB1_check_seq_err(void) ヤージュ ((PDB1->CH[0].S & PDB_S_ERR_MASK) != 0) の場合 ヤージュ PDB1->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); PDB1->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK); PDB1->SC |= (uint32_t)PDB_SC_PDBEN_MASK; PDB1->SC |= (uint32_t)PDB_SC_SWTRIG_MASK; } } void PDB0_check_seq_err(void) ヤージュ ((PDB0->CH[0].S & PDB_S_ERR_MASK) != 0) の場合 ヤージュ PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); PDB0->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK); PDB0->SC |= (uint32_t)PDB_SC_PDBEN_MASK; PDB0->SC |= (uint32_t)PDB_SC_SWTRIG_MASK; } } 「`」 私が使用した復旧手順は以下のとおりです。 1. `ERR`フラグをクリアします。 2. PDBを停止します。 3. PDBを再度有効化して再起動します。 この停止と開始のシーケンスにより、すべてが再び正常に動作するようになります。後続のプリトリガーが発生し、ADC ISRコールバックが正常に呼び出されます。 しかし、なぜこれが必要なのか、私にはまだ完全には理解できていません。リファレンスマニュアルには、「ERR」条件をクリアし、ADC結果レジスタ(「COCO」をクリア)を読み取ることでロックが解除されると述べられています。私のCASEでは、それだけでは十分ではなく、回復にはPDBのストップ/ストップシーケンスが必要です。 また、`PDBn->SC |= PDB_SC_SWTRIG_MASK` は厳密には必須ではないことも確認しました。ソフトウェアトリガーを発行しなくても、ロックは解除され、PDB再起動後にADC ISRの実行が再び始まります。 RMでは「ERR」と「COCO」をクリアすればロックが解除されるはずだと示されているにもかかわらず、なぜPDBを停止して再起動する必要があるのか、説明していただけますか?

MCU_performreset is not happening in S32J100 HI,  I am trying to reset the controller using the Mcu_performReset function but the PC is coming out of the function with reset and the function which handles this reset mechanism Power_Ip_Specific_RequestPerformReset() has no data depending on the Functional or destructive reset. i tried configuring the S32DS but issue persist. i am using SW32J100_RTD_R23-11_0.8.0_CD04_HF01, S32DS 3.6.7 version. can you please suggest where i am going wrong? Thanks, Amol Re: MCU_performreset is not happening in S32J100 Hi @PavelL , I understood the Scenario, Will connect to the Field engineers for this issue. Thanks for the support. Regards, Amol  Re: MCU_performreset is not happening in S32J100 Hello @Ajadhav5 , I am writing to you in regard to a product currently in your possession – an NPI (New Product Introduction) which has not been officially launched yet. Please be advised that customers who have been granted early access to such products have assigned their field engineers. Your designated field engineer should serve as your primary support channel for any issues, concerns or queries you may have about this product. Our online support team will be opening a wider range of support for this product once it has been officially released. Until then, we will not be equipped to provide the desired assistance. We appreciate your understanding in this matter and look forward to further enhance our partnership with you. Should you have any questions, please feel free to connect with your field engineer or contact my team and me directly. Thank you for your understanding. Best regards, Pavel

PDB ADC 预触发序列错误恢复 NXP社区的各位好， S32K144 运行时闪存擦除/编程操作后，ADC0/ADC1 中断停止 作为我之前问题的延续，我需要一些关于如何正确恢复 S32K144 上的 PDB ADC 预触发序列错误的说明。 我尝试了以下三种方法，但只有一种方法有效。 方法一（有效）： 在执行闪存擦除/编程操作之前，请先停止 PDB0 和 PDB1。 闪存操作完成后，重新启动两个 PDB 并重新启用相应的 ISR。 采用这种方法，不会出现PDB序列错误。 方法2: 闪存擦除/编程操作完成后，我停止并重新启动了 PDB0 和 PDB1。然而，PDB 预触发序列出现错误。然后我尝试通过停止并重新启动 PDB 模块来恢复，但序列错误仍然存在。 方法三： 方法三（无效）： 在闪存擦除/编程操作期间，我没有停止或重新启动 PDB0 和 PDB1。相反，操作完成后，产生了一个待处理的 PDB ISR 和一个 ADC ISR 触发信号。 在 PDB ISR 中，我尝试使用以下方法清除序列错误标志： PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); 然后执行相应的 ADC ISR，读取 ADC 结果寄存器清除 COCO 标志。我原本期望这样做可以防止进一步的预触发序列错误，但问题仍然存在，这种方法并没有奏效。 我的问题是：一旦触发了 PDB 预触发序列错误，是否有可能在不 RESET 系统的情况下恢复 PDB/ADC 操作并恢复正常触发信号？或者是否需要事先停止并重新启动 PDB，以避免进入不可恢复的状态？ Re: PDB ADC pre trigger sequence error recovery 嗨 PetrS， 我尝试了以下方法。 在未停止 PDB 的情况下执行闪存擦除操作后，微控制器收到一个待处理的 ADC ISR 回调。在该回调函数中，读取 ADC 结果寄存器后，我调用以下函数来检查和恢复 PDB 序列错误： ```c void PDB1_check_seq_err(void) { 如果 ((PDB1->CH[0].S & PDB_S_ERR_MASK) != 0) { PDB1->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); PDB1->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK); PDB1->SC |= (uint32_t)PDB_SC_PDBEN_MASK; PDB1->SC |= (uint32_t)PDB_SC_SWTRIG_MASK; } } void PDB0_check_seq_err(void) { 如果 ((PDB0->CH[0].S & PDB_S_ERR_MASK) != 0) { PDB0->CH[0].S &= (uint32_t)(~PDB_S_ERR_MASK); PDB0->SC &= (uint32_t)(~PDB_SC_PDBEN_MASK); PDB0->SC |= (uint32_t)PDB_SC_PDBEN_MASK; PDB0->SC |= (uint32_t)PDB_SC_SWTRIG_MASK; } } ``` 我使用的恢复顺序是： 1. 清除 `ERR` 标志。 2. 停止 PDB。 3. 重新启用并重启 PDB。 通过这种停止和启动序列，一切都恢复正常：后续的预触发发生，ADC ISR 回调正常调用。 然而，我仍然不太明白为什么有必要这样做。参考手册指出，清除“ERR”条件并读取ADC结果寄存器（这将清除“COCO”）应该可以释放锁定。就我而言，仅靠这一点似乎还不够，需要执行 PDB 停止/启动序列才能恢复。 另外，我观察到 `PDBn->SC |= PDB_SC_SWTRIG_MASK` 并不是严格必需的。即使没有发出软件触发信号，PDB 重启后，锁定也会被释放，ADC ISR 也会再次开始执行。 请问为什么在这种情况下需要停止并重新启动 PDB，即使 RM 指示清除 `ERR` 和 `COCO` 应该可以释放锁？ Re: PDB ADC pre trigger sequence error recovery 您好， 仅清除 PDB_S_ERR 通常不足以从触发信号前序列错误中恢复，因为 ADC/PDB 序列可能已经失去同步。根据您的测试结果，在刷写操作之前停止 PDB，然后在刷写操作之后重新启动 PDB，似乎是防止出现这种情况的最可靠方法。 如果在发生错误后尝试恢复，我建议确保 PDB 和 ADC 的状态完全重新同步。这可能包括禁用 PDB、清除待处理的 PDB 状态标志、确保所有待处理的 ADC 转换结果都已读取（COCO 已清除）、重新启用 PDB，以及在执行触发信号恢复之前根据需要重新加载配置。 根据 RM 的说法，当相应的 COCO 标志被设置、预触发被禁用或 PDB 被禁用时，预触发锁将被释放，因此完整的 PDB 禁用/启用序列也可能值得研究。 BR，彼得

S32J100 中 MCU_performreset 没有执行。 你好， 我尝试使用 Mcu_performReset 函数 RESET 控制器，但 PC 从该函数退出时处于 RESET 状态，而处理此 RESET 机制的函数Power_Ip_Specific_RequestPerformReset () 没有数据，取决于功能性 RESET 还是破坏性 RESET。我尝试配置S32DS，但问题仍然存在。 我使用的是 SW32J100_RTD_R23-11_0.8.0_CD04_HF01，S32DS 3.6.7 版本。 请问我哪里做错了？ 谢谢！ 阿莫尔 Re: MCU_performreset is not happening in S32J100 嗨@PavelL ， 我了解了情况，会联系现场工程师解决这个问题。 感谢您的支持。 此致， 阿莫尔 Re: MCU_performreset is not happening in S32J100 你好@Ajadhav5 ， 我写信给您是关于您目前拥有的一款产品——一款尚未正式上市的新产品（NPI）。 请注意，已获准提前使用此类产品的客户已指派了现场工程师。您指定的现场工程师应作为您解决有关本产品任何问题、疑虑或疑问的主要支持渠道。 我们的在线支持团队将在该产品正式版本发布后，提供更广泛的支持服务。在此之前，我们将无法提供所需的帮助。 感谢您对此事的理解，我们期待进一步加强与您的合作关系。如有任何疑问，请随时联系您的现场工程师，或直接联系我的团队和我。 感谢您的理解。 顺祝商祺！ 帕维尔

MC33774 Balance Ctrl HI. 我当前使用33665A+33774的采样系统，我在控制MC33774均衡开启时遇到一个问题，我希望使用定时器均衡的模式，并且设置超时时间为10S来开启均衡，但是当我按照“MC33774_ADDR_BAL_GLOB_TO_TMR->MC33774_ADDR_BAL_TMR_CH_ALL->MC33774_ADDR_BAL_GLOB_CFG”的顺序开启均衡时，我发现MC33774_ADDR_BAL_TMR_CH_ALL的数据在下发后会马上清0导致均衡无法开启。 我想知道这是什么原因导致的？另外我看到手册中说均衡会以奇偶交替的方式开启，这部分是奇数通道在前还是偶数通道在前，有寄存器可以控制吗？ Re: MC33774 Balance Ctrl 你可以用公司的邮箱提交ticket的形式获得这个手册，但是再community您被识别为C客户因为用了自己的邮箱所以无法share Home Re: MC33774 Balance Ctrl 非常感谢，这个问题解决了。请问下这个操作流程手册是开源的吗？ Re: MC33774 Balance Ctrl 尝试下按照下面的steps：

CODEWARRIOR 11.1 I used a M9S08QG8 micro chip, with this code in 1984. I am using windows 11 now. Is there a compiler that will debug this code Now. Also, is this chip still made? void my_main(void) { initial(); } void initial(void) { if(loopcount==2){goto initend;} PTADD_PTADD0 = 0; //io direction PTADD_PTADD1 = 0; PTADD_PTADD2 = 0; PTADD_PTADD3 = 1; PTBDD_PTBDD0 = 1; PTBDD_PTBDD1 = 1; //PTADD_PTADD4 = 0; //io direction //PTADD_PTADD5 = 0; //PTBDD_PTBDD6 = 1; //osc direction //PTBDD_PTBDD7 = 0; //PTBPE_PTBPE6 = 1; //pullup resistor //PTBPE_PTBPE7 = 0; //PTAPE_PTAPE0 = 0; //PTAPE_PTAPE1 = 0; //PTAPE_PTAPE2 = 0; //PTAPE_PTAPE4 = 0; //PTAPE_PTAPE5 = 0; //ICSC1_IREFS = 0; //select external osc param //ICSC1_CLKS0 = 0; //ICSC1_CLKS1 = 1; //ICSC2_EREFS = 0; //ICSC2_BDIV0 = 0; //ICSC2_BDIV1 = 0; PTAD_PTAD0 = 0; PTAD_PTAD1 = 0; PTAD_PTAD2 = 0; PTAD_PTAD3 = 0; PTBD_PTBD0 = 1; PTBD_PTBD1 = 1; bobbin_one_white=0; bobbin_two_white=0; bobbin_one_black=0; bobbin_two_black=0; bobbin_count_one=0; bobbin_count_two=0; bobbin_one_count_up_down = 20; bobbin_two_count_up_down = 20; bobbin_three_count_up_down = 20; bobbin_four_count_up_down = 20; rewind1 = 1; rewind2 = 1; rewind3 = 1; rewind4 = 1; programlength = 10; buzzcount = 0; buzzdelay = 0; buzzonoff = 1; needle = 20; delay = 100; light = 20; speed = 1000; c=0; //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=1;} //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=0;} //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=1;} //__RESET_WATCHDOG(); for(speed=0;speed<=1000;speed++){ PTAD_PTAD3=0;} PTAD_PTAD3 = 0; //buzzonoff = 1; buzzonoff = 0; initend: PTAD_PTAD3 = 1; //PTAD_PTAD3 = 0; c=0; peace(); } void peace(){ loopcount=2; onemoretime: buzzer(); //__RESET_WATCHDOG(); for(speed=0;speed<=delay;speed++){} if(PTAD_PTAD2==0){PTAD_PTAD3=0;buzzonoff=1;} //if(PTAD_PTAD2==0){setlength();} // winding bobbin on bobbin winder if(PTAD_PTAD0==0){bobbin_one_black++;PTBD_PTBD1=0;if(bobbin_count_one==1){bobbin_count_one=2;}} if(PTAD_PTAD0==1){bobbin_one_white++;PTBD_PTBD1=1;halfturna=1;bobbin_count_one=1;} if(bobbin_count_one==2){ if(halfturna == 1){fullturna=1;bobbin_count_one=0;}} // hook sewing if(PTAD_PTAD1==0){bobbin_two_black++;PTBD_PTBD0=0;if(bobbin_count_two==1){bobbin_count_two=2;}} if(PTAD_PTAD1==1){bobbin_two_white++;PTBD_PTBD0=1;halfturnb=1;bobbin_count_two=1;} if(bobbin_count_two==2){ if(halfturnb== 1){fullturnb=1;bobbin_count_two=0;}} if(fullturna==1)goto bobbinwinder; if(fullturnb==1)goto hook; goto onemoretime; Re: CODEWARRIOR 11.1 你好， CodeWarrior 工具版本 11.1 支持 Windows 11，该工具支持不同的连接方式 [P&E USB Multilink Universal / USB Multilink、P&E Cyclone、开源 BDM、P&E 全芯片仿真]。 您可以从以下链接下载该工具： CodeWarrior ® for MCUs (Eclipse IDE) v11.1 该设备状态为“不建议用于新设计 (NRND)”，但您仍然可以从代理商的现有库存中订购，请参阅购买选项部分的产品零件页面： MC9S08QG8CDTE 产品信息 | NXP 半导体 此致敬礼，路易斯

imx93 free running ccm clko via device tree only hi everybody, i would like to output a free-running 12288000Hz clock on MX93_PAD_CCM_CLKO3__CCMSRCGPCMIX_CLKO3 according to the manual this should be possible to derive from IMX93_CLK_AUDIO_PLL. can anybody give a hint on how to do this via device-tree only? Linux Re: imx93 free running ccm clko via device tree only refer to the imx93 clock driver, you need add new pll to support this, couldn't modify the dts only

猎鹰模式下的 OP-TEE || iMX8MP_EVK 您好， 我想在 i.MX8MP EVK 上启用OP-TEE 和 Falcon 模式。 机器： imx8mpevk 代码库： https://github.com/nxp-imx/imx-manifest 分支： imx-linux-walnascar XML： imx-6.12.34-2.1.0.xml 目前，我使用meta-imx-fastboot (lf-6.12.20-2.0.0-secure)通过 Falcon 模式实现快速启动。但是，当启用猎鹰模式时，OP-TEE 将被禁用。 根据我的要求，我需要同时启用 OP-TEE 和 Falcon 模式。 请问如何在 i.MX8MP EVK 的 Falcon 模式下启用 OP-TEE？ i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano 安全 Yocto Project Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@Sanjiv_Mns 目前 meta-imx-fastboot 层不支持 OP-TEE。理论上是可行的，但目前尚未实现。 说明：在默认的 电路板支持包。 中，OP-TEE 的起始地址和大小是在 U-Boot 的正确启动阶段根据rom_pointer计算的（参见： https://github.com/nxp-imx/uboot-imx/blob/lf-6.12.20-2.0.0/arch/arm/mach-imx/dt_optee.c#L13） 。 与 U-Boot 本身相比，SPL 中的rom_pointer具有不同的含义/值。因此，如果不进行进一步修改，就无法从 SPL 执行ft_add_optee_node函数。 谢谢！ 埃琳娜 Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@elena_popa 请问如何才能进一步实现SPL → OP-TEE → Linux启动流程？我想了解使其可靠运行所需的正确步骤和元器件。 我还找到了以下链接，其中在STM32MP平台上实现了类似的流程： https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ 请问这种方法是否适用于我的使用场景，或者其中的部分内容是否可以重复使用或修改，以在我的平台上实现相同的启动顺序？ Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@elena_popa 我已经完成了这项操作，现在它在我的 i.MX8MP 开发板上启动成功了。 当前启动流程如下： SPL → ATF → OP-TEE → Linux 一切运行正常。感谢你的评论@elena_popa   [ 0.412349] optee：探测管道方法。 [ 0.412373] optee：修订版 4.6 (788dc101b05ae47b) [ 0.412678] optee：动态共享内存已启用 [ 0.413062] optee：已初始化驱动程序 Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@Sanjiv_Mns 我成功地在 Falcon 模式下为 i.MX 8MP 启用并运行了 OP-TEE。 i.MX 8MP 的启动流程为：SPL -> ATF -> OP-TEE -> Linux 步骤如下： 1. 删除 meta-imx-fastboot 层的 conf/layer.conf 中的以下行。 MACHINE_FEATURES:remove = "optee" 2.在imx-boot mkimage 源代码中，修改iMX8M/mkimage_fit_atf_kernel.sh脚本，将 OP-TEE 二进制文件添加到 FIT 镜像中。 6a7,9 > # keep backward compatibility > [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe000000" > 19a23,41 > [ -z "$BL32" ] && BL32="tee.bin" > PAD=../scripts/pad_image.sh > > if [ ! -f $BL32 ]; then > BL32=/dev/null > else > echo "Building with TEE support, make sure $BL31 is compiled with spd. If you do not want tee, please delete $BL32" >&2 > if [ $TEE_COMPRESS_ENABLE ]; then > echo "Start compress $BL32" >&2 > rm -f $BL32.lz4 > lz4 -9 $BL32 $BL32.lz4 >&2 > BL32=$BL32.lz4 > ./$PAD $BL32 >&2 > fi > echo "$BL32 size: " >&2 > ls -lct $BL32 | awk '{print $5}' >&2 > LOADABLES="$LOADABLES, \"tee-1\"" > fi > 71a94,103 > tee-1 { > description = "TEE firmware"; > data = /incbin/("$BL32"); > type = "firmware"; > arch = "arm64"; > compression = "none"; > load = <$TEE_LOAD_ADDR>; > entry = <$TEE_LOAD_ADDR>; > }; > 87c119 < loadables = "kernel","dtb"; --- > loadables = "tee-1","kernel","dtb"; 3. 在内核设备树中，手动添加 OP-TEE 节点（固件和保留内存）。编辑imx8mp.dtsi设备树并： - 在根节点（“/”）中添加以下 OP-TEE 固件节点。 firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; - 在保留内存节点下添加 OP-TEE 保留内存区域： optee_core@56000000 { reg = <0 0x56000000 0 0x1e00000>; no-map; }; optee_shm@57e00000 { reg = <0 0x57e00000 0 0x200000>; no-map; }; 4. 构建镜像并将其写入启动设备。 5. 要检查 OP-TEE 是否已启动以及 Linux 是否已探测到驱动程序，请运行： root@imx8mp-lpddr4-evk:~# dmesg | grep optee [ 0.000000] OF: reserved mem: 0x0000000057e00000..0x0000000057ffffff (2048 KiB) nomap non-reusable optee_shm@57e00000 [ 0.000000] OF: reserved mem: 0x0000000056000000..0x0000000057dfffff (30720 KiB) nomap non-reusable optee_core@56000000 [ 2.581777] optee: probing for conduit method. [ 2.590862] optee: revision 4.8 (e7ed997213779e3d) [ 2.596363] optee: dynamic shared memory is enabled [ 2.601567] optee: initialized driver 6.如果你想测试 OP-TEE，你可以运行xtest 。 root@imx8mp-lpddr4-evk:~# xtest Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression+pkcs11+regression_nxp # ###################################################### * regression_1001 Core self tests o regression_1001.1 Core self tests regression_1001.1 OK o regression_1001.2 Core dt_driver self tests regression_1001.2 OK o regression_1001.3 Core transfer list self tests ..... +----------------------------------------------------- 49354 subtests of which 0 failed 161 test cases of which 0 failed 0 test cases were skipped TEE test application done! 如果您在启用过程中遇到任何问题，请告诉我。 谢谢！ 埃琳娜

S32N55 HSE2 — 使用 ADKP 的 CRS(APP) 功能域安全调试身份验证 HI 我们正在为 S32N55 平台开发安全调试身份验证，并且已经通过 SDC-600 使用 ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) 成功实现了 FSS 功能域调试授权。 我们现在正尝试将其扩展到 CRS 功能域（HSE_DEBUG_DOMAIN_APP = 0x1B），并有以下问题： --- [Q1] ADKP 是否可用于 CRS 功能域安全调试身份验证？ 通过 HSE_OTP_FOEM_ADKP_ATTR_ID 配置 ADKP 后，是否可以使用同一个 ADKP 通过 HSE_DEBUG_CMD_APP_CHALLENGE 进行 CRS 功能域（APP）安全调试身份验证？ --- [Q2] SetOwnerDebugKeyMap() 是否需要针对每个 MU（FSS MU 与 CRS MU）单独调用？ 根据 RM 对 hseOwnerDebugKeyMapConfig_t 的描述： “这项服务由拥有该设备的 MU 为每个已安装设备的所有者单独调用。 HSE FW 会根据发送此服务请求的 MU 来假定所有者身份。 我们目前的实现仅通过 FSS MU (MU0) 调用 SetOwnerDebugKeyMap() (HSE_SRV_ID_DEBUG_KEY_MAPPING)，映射 aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP。 - CRS 功能域身份验证是否需要通过 CRS MU 单独调用 SetOwnerDebugKeyMap()？ - 如果是这样，S32N55 上的 CRS 功能域应该使用哪个 MU 编号？ --- [Q3] 每次启动时都需要调用 SetOwnerDebugKeyMap() 吗？ RM表示： “仅记录 numOfAuthorizationRefEntries 和 numOfAuthenticationRefEntries， 其余条目将被忽略。 这意味着密钥映射是易失性的，不会存储在非易失性存储器 (NVM) 中。这是否意味着对于 FSS 和 CRS 域，每次启动时（在授予 SU 权限之后）都必须调用 SetOwnerDebugKeyMap()？ --- [Q4] 更正 APP_CHALLENGE 的 keyRef 值 在 hseDebugAuthorizeStartCmd_t 中，keyRef 字段引用通过 hseOwnerDebugKeyMapConfig_t 映射的索引。由于我们将 aOwnerAuthRef[0] 映射为 HSE_OTP_KEY_FOEM_ADKP，因此我们发送 keyRef = 0x00 来进行 CRS 功能域身份验证。这样对吗？ --- [Q5] APP_CHALLENGE 的响应大小和数据包结构 根据 hseDebugAuthorizeProofProvCmd_t 字节映射，数据包结构始终为 32 字节（2 个数据包 x 8 个字）。HSE_CR_APP_RESPONSE_SIZE = 16U 与 HSE_CR_FSS_OR_HSE_RESPONSE_SIZE = 32U。 对于 APP_CHALLENGE，主机是否应该发送： - 16 字节的 AES 加密响应 + 16 字节的零填充 = 总共 32 字节？ 或者只有 16 字节？ 目前，在发送 FLAG_START + DebugSignalMap(4 字节) + Response(16 字节) + FLAG_END 后，HSE2 没有响应，T32 无限期地挂起等待。当我们发送 32 字节（16 字节响应 + 16 字节零填充）时，会观察到同样的卡顿现象。 --- 供参考： - Sherpa_Cdd_AllocateChannel() 总是分配 MU0 (FSS) - SetOwnerDebugKeyMap(): aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP (0x00000302)，使用 SU 权限调用 - crs_auth.cmm：DEBUG_TARGET=0x1B，OID=0xFF*16，keyRef=0x00 - AUTH_MODE_REQ 请求成功通过（已收到 HSE_DEBUG_WAITING_RESPONSE_TO_CHG 信号） - 已接收挑战码：32 字节 发送响应后，未收到来自 HSE2 的 ACK (0x4A4A4A4A)。 请参阅附件中的CMM脚本和日志以供参考。 提前谢谢您。 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， 谢谢你的建议。应要求，我创建了一个新帖子来跟踪 CRS（APP 功能域）安全调试身份验证问题： [S32N55 HSE2 — CRS（应用程序功能域）通过 hseDebugCardCmd_t 进行安全调试身份验证] （请在NXP社区搜索以上标题） 这个问题目前影响了我们的客户发货计划。请您在方便的时候尽快查看一下这篇新文章。 CMM脚本（crs_auth.cmm）新帖子中附上了日志文件。 非常感谢您的及时支持。 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， 感谢您的回复。 我们对 S32N55 上 CRS (APP) 功能域安全调试身份验证的 hseDebugCardCmd_t 实现还有其他疑问。 --- [Q1] hseDebugCardInfo_t 中的 Owner ID (ownerId) 是否与通过 hseOwnerDebugKeyMapConfig_t 配置的值相同？ 我们的设备配置为单所有者场景，其中 Fss_Firmware_au8Oid[] = {0xFF * 16}。 hseDebugCardCmd_t 中的 ownerId 字段是否也应设置为 0xFF * 16？ 或者它是否需要与设备所有者安装期间配置的特定值相匹配？ --- [Q2] hseDebugCardCmd_t 是否需要在 APP_CHALLENGE 之后发送，还是应该代替 hseDebugAuthorizeProofProvCmd_t 发送？ 根据 RM 的说法：“对于基于 APP 的选项，调试信号仅通过调试卡身份验证启用和授权（参见 hseDebugCardCmd_t）（该字段被忽略）。” 我们目前的流程： 1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) 2. rx_authmode → 已收到 HSE_DEBUG_WAITING_RESPONSE_TO_CHG 3. APP_CHALLENGE → rx_challenge（已接收 32 字节） 4. 直接发送 hseDebugCardCmd_t（跳过 hseDebugAuthorizeProofProvCmd_t） 5. HSE2 停止响应（T32 卡在 CARD_REQUEST 的 FLAG_END 处挂起） 是否应该在发送 hseDebugCardCmd_t 之前发送 hseDebugAuthorizeProofProvCmd_t (appChallengeAuth = AES256-CMAC)？ 或者，是否应该在不发送 ProofProv 的情况下，直接在 rx_challenge 之后发送 hseDebugCardCmd_t？ --- [Q3] 使用 MAC 方案时，hseDebugCardTag_t 的正确认证标签 (authTag) 计算方法是什么？ 我们正在使用： authScheme.macScheme.macAlgo = HSE_MAC_ALGO_CMAC (0x11) authTag = AES256-CMAC(key=ADKP, data=Challenge[32 字节]) authLen = 16 这个计算结果正确吗？或者 CMAC 输入是否应包含其他字段（OID、功能域映射等）？ --- [Q4] hseDebugCardCmd_t 的正确数据包结构是什么？ 基于 RM 字节映射，我们目前的实现方式如下： 数据包 1（32 字节）：KRI（4 字节）+ CMD（4 字节=0x5DCDEB77）+ OID（16 字节=0xFF*16）+ AuthScheme（8 字节=CMAC） 数据包 2（32 字节）：启用调试域映射（bit27=0x08000000）+ 填充（28B） 数据包 3：debugDomainMapping(4B) + numOfAllowedUids(2B) + reserved(2B) + authLen(2B) + reserved(2B) + authTag(256B) 这个结构正确吗？HSE2 在接收到 OID 字段（0xFF 字节）后停止响应。 --- 请问您的邮箱地址是什么？我会把用于 CRS 认证的 CMM 文件发给你。 BRs。 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， @EddiePark 感谢你的帖子。 很高兴听到S32N55 平台的安全调试认证已经通过 SDC-600 使用 ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) 成功实现了 FSS 功能域调试授权。 我会继续协助您核实新问题的详细信息。很抱歉我没有看到您提供的 CMM 脚本和日志，能否请您再次上传以便我们参考？ BR 陈银 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， @EddiePark 感谢您的回复。 本帖中已有 6 个问题，可能需要较长时间进行调查，为了提高效率，对于其他问题，我建议另开新帖进行跟踪。 正如您所提到的，会有脚本/日志作为附件供检查，但我没有在您的帖子中看到，请问它们是否会再次上传？ BR 陈银 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， @EddiePark 感谢您的回复。 1.我们将一如既往地尽力解答您的疑问。 2. 我理解这是一个紧急问题，但正如我之前在支持中提到的，S32N55 仍处于预生产阶段，尚未通过社区渠道提供支持（在此期间，我们建议您直接联系您的 FAE/代理商以加快效率），因此回复可能需要较长时间。此外，使用 LC advanced 进行安全调试通常处于开发后期阶段，近期相关的文档/示例仍然有限。 给您带来的不便，敬请谅解。 BR 陈银 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， @EddiePark 感谢您的耐心等待，以下是一些初步评论供您参考。 [Q1] ADKP 是否可用于 CRS 功能域安全调试身份验证？ [评论] ：是的，用于应用程序功能域安全调试身份验证的密钥是从 hseOwnerDebugKeyMapConfig_t->pOwnerCardAuthenticationRef 中选择的，它可能包含 ADKP 的密钥句柄。 [Q2] SetOwnerDebugKeyMap() 是否需要针对每个 MU（FSS MU 与 CRS MU）单独调用？ [评论] ：SetOwnerDebugKeyMap() 应该绑定到设备所有者，而不是 MU。设备所有者可以包含多个群组，每个群组可以有多个 MU 实例。如果 FSS 和 CRS 属于同一设备所有者，则可以通过 CRS MU 或 FSS MU 调用。 [Q3] 每次启动时都需要调用 SetOwnerDebugKeyMap() 吗？ 【评论】 ：不应该在每次启动时都调用，配置应该保存在 SYS-IMG 或熔丝中，否则设备重新上电后安全调试将失败，这不符合安全调试的设计预期。但是，我不确定应该从当前可用资源中存储此配置的哪个位置。 [Q4] 更正 APP_CHALLENGE 的 keyRef 值 在 hseDebugAuthorizeStartCmd_t 中，keyRef 字段引用通过 hseOwnerDebugKeyMapConfig_t 映射的索引。由于我们将 aOwnerAuthRef[0] 映射为 HSE_OTP_KEY_FOEM_ADKP，因此我们发送 keyRef = 0x00 来进行 CRS 功能域身份验证。这样对吗？ 【备注】 ：是的，如果 ADKP 句柄是 OwnerCardAuthenticationRef 的第一个条目，并且用户想要使用 ADKP 对 CRD 调试进行身份验证，则 authKeyRef 应为 0（ADKP 句柄条目的索引）。 [Q5] APP_CHALLENGE 的响应大小和数据包结构 【注释】 ：对于应用程序调试，除了调试信号映射和挑战响应数据字段外，数据包 1 中的其他未使用数据可以填充 0。 由于有关此主题的相应文件尚未完全更新（S32N55 仍处于早期阶段），因此我们能提供的信息有限。 给您带来的不便，敬请谅解。 BR 陈银 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， 再次感谢您一直以来的支持。我们完全理解 S32N55 仍处于预生产阶段，目前有关该主题的文档/资源有限。对于这些额外的问题，我们深表歉意。但由于我们的客户交货日期临近，而这是一个关键的障碍，我们不得不请求您提供更多指导。 我们已采纳您之前的评论（Q1-Q5）：keyRef=0x00，ADKP 在 pOwnerCardAuthenticationRef 中，数据包 1 填充为 32 字节（debugSignalMap 4B + appChallengeAuth 16B + 未使用的 12B = 0）。 但是，我们仍然卡在 ProofProv / CARD_REQUEST 阶段。我们目前的状况： 1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) -> OK (HSE2 返回 0x4A4A4A4A) 2. APP_CHALLENGE -> OK（已收到 32 字节挑战） 3. ProofProv (hseDebugAuthorizeProofProvCmd_t): - 数据包 1 = debugSignalMap(4B=0) + appChallengeAuth(16B AES256-CMAC) + unused(12B=0) 所有 32 字节数据均已通过 SDC-600 成功传输 - >>> HSE2 在此之后没有反应 <<< SDC-600 TX 在发送约 20 字节后似乎会停止，HSE2 也不会发送任何响应帧。 请您澄清以下关于APP（CRS）功能域认证顺序的问题： [Q1] 主机发送 APP_CHALLENGE 的 ProofProv (hseDebugAuthorizeProofProvCmd_t with appChallengeAuth) 后，HSE2 是否会向主机发送中间响应帧？或者 HSE2 保持静默，等待下一个命令？ 作为参考，在 FSS 功能域中，经过 ProofProv 后，HSE2 返回 0x4A4A4A4A。我们在 APP 功能域未观察到此类响应。这是预期之内的吗？ [Q2] 对于 APP_CHALLENGE，ProofProv (hseDebugAuthorizeProofProvCmd_t) 和 CARD_REQUEST (hseDebugCardCmd_t) 之间的正确顺序是什么？ - 选项 A：APP_CHALLENGE -> ProofProv -> (HSE2 响应？)-> 卡片请求 - 选项 B：APP_CHALLENGE -> CARD_REQUEST 直接执行（APP 跳过 ProofProv） - 选项 C：其他序列 由于 RM 指出 debugSignalMap 对于 APP 是“忽略的”，并且授权“仅通过调试卡认证”进行，那么对于 APP 功能域是否应该发送 ProofProv，或者我们应该在挑战后直接执行 CARD_REQUEST？ [Q3] 请提供从 COMM_START 到最终授权响应的 APP (CRS) 功能域安全调试身份验证的完整命令序列？ 我们希望确认具体的命令顺序以及哪些命令需要 HSE2 的响应，具体如下： COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE -> [ProofProv?] -> [CARD_REQUEST?] -> [final response?] 任何关于 APP/CRS 功能域的参考流程或示例都将非常有帮助，因为当前的行为（ProofProv 后 HSE2 静默）与 FSS 功能域的流程不符。 非常感谢您的理解和支持。 顺祝商祺！ Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， 谢谢你的回复，我明白了，以后也会一直明白。我们会尽力提供支持。 1.我已经下载了您在另一个帖子“S32N55 HSE2 CRS 功能域身份验证未完成”中分享的 cmm 和 auth 文件，它们与当前使用的文件相同吗？ 2. 对于您稍后提出的问题： [Q1] hseDebugCardInfo_t 中的 Owner ID (ownerId) 是否与通过 hseOwnerDebugKeyMapConfig_t 配置的值相同？ 【评论】 ：是的，hseDebugCardInfo_t 的 OID 就是设备所有者安装服务的 ownerid。 [Q2] hseDebugCardCmd_t 是否需要在 APP_CHALLENGE 之后发送，还是应该代替 hseDebugAuthorizeProofProvCmd_t 发送？ [注释] ：应在发送 CARD_REQUEST 之前发送 hseDebugAuthorizeProofProvCmd_t。 [Q3] 使用 MAC 方案时，hseDebugCardTag_t 的正确认证标签 (authTag) 计算方法是什么？ 【备注】：抱歉，API RM 中没有关于这方面的明确描述。但是 App 功能域 的身份验证标签可能不会使用收到的质询，该质询用于 hseDebugAuthorizeProofProvCmd_t。对于用户的 CRS 功能域调试，可能是authTag = AES256-CMAC(key=ADKP, data=hseDebugCardInfo_t)。您可以尝试一下。 [Q4] hseDebugCardCmd_t 的正确数据包结构是什么？ 【备注】： hseDebugCardCmd_t 的结构可以参考 HSE FW API 接口中的注释，这比 HSE FW API RM 中的描述更清晰。通过检查您分享的原始脚本，我们发现 hseDebugCardCmd_t 的结构存在一些错误，请参见附件。 如果您觉得其他文件不方便在帖子中分享，可以通过私信发送给我。 BR 陈银

ファルコンモードのOP-TEE || iMX8MP_EVK こんにちは、 i.MX8MP EVKで、OP-TEEとFalcon Modeの両方を有効にしたいです。 マシン: imx8mpevk リポジトリ: https://github.com/nxp-imx/imx-manifest Branch: imx-linux-walnascar XML: imx-6.12.34-2.1.0.xml 現在、私はmeta-imx-fastboot（lf-6.12.20-2.0.0-secure）を使用して、Falcon Mode経由で高速起動を実現しています。しかし、ファルコンモードが有効になっている場合、OP-TEEは無効になります。 私の要望としては、 OP-TEEとファルコンモードの両方を同時に有効にする必要があります。 i.MX8MP EVKのファルコンモードでOP-TEEを有効にする方法を教えていただけますか? i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Security Yocto Project Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @Sanjiv_Mns 現在、meta-imx-fastbootレイヤーはOP-TEEをサポートしていません。原理的には可能であるはずだが、まだ実現されていない。 説明: デフォルトの BSP では、OP-TEE の開始アドレスとサイズは、 rom_pointerに基づいて U-Boot の適切なブート ステージ中に計算されます (参照: https://github.com/nxp-imx/uboot-imx/blob/lf-6.12.20-2.0.0/arch/arm/mach-imx/dt_optee.c#L13) 。 SPLにおけるrom_pointerは、U-Boot本体とは異なる意味/値を持つ。SO、 ft_add_optee_node 関数はSPLからさらに変更なしで実行できません。 ありがとうございます エレナ Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @elena_popa OP-TEE→LinuxブートフローでSPLを達成するためにさらに進める方法→教えていただけませんか?これを確実に動作させるために必要な正しい手順と構成要素を理解したいです。 また、 STM32MP プラットフォームで同様のフローが実装されているリンクも見つけました。 https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ この方法が私のユースケースに適用できるのか、それとも一部を再利用したり、同じブートシーケンスを実現するために適応できるのか教えていただけますか? Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @Sanjiv_Mns i.MX 8MPでOP-TEEをFalconモードで有効化して実行することに成功しました。 i.MX 8MPのブートフローは、SPL -> ATF -> OP-TEE -> Linux となります 手順は以下の通りです。 1. meta-imx-fastboot レイヤーの conf/layer.conf ファイル から次の行を削除します。 MACHINE_FEATURES:remove = "optee" 2.imx-boot mkimageのソースコードにおいて、 iMX8M/mkimage_fit_atf_kernel.shスクリプトを修正し、OP-TEEバイナリをFITイメージに追加する。 6a7,9 > # keep backward compatibility > [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe000000" > 19a23,41 > [ -z "$BL32" ] && BL32="tee.bin" > PAD=../scripts/pad_image.sh > > if [ ! -f $BL32 ]; then > BL32=/dev/null > else > echo "Building with TEE support, make sure $BL31 is compiled with spd. If you do not want tee, please delete $BL32" >&2 > if [ $TEE_COMPRESS_ENABLE ]; then > echo "Start compress $BL32" >&2 > rm -f $BL32.lz4 > lz4 -9 $BL32 $BL32.lz4 >&2 > BL32=$BL32.lz4 > ./$PAD $BL32 >&2 > fi > echo "$BL32 size: " >&2 > ls -lct $BL32 | awk '{print $5}' >&2 > LOADABLES="$LOADABLES, \"tee-1\"" > fi > 71a94,103 > tee-1 { > description = "TEE firmware"; > data = /incbin/("$BL32"); > type = "firmware"; > arch = "arm64"; > compression = "none"; > load = <$TEE_LOAD_ADDR>; > entry = <$TEE_LOAD_ADDR>; > }; > 87c119 < loadables = "kernel","dtb"; --- > loadables = "tee-1","kernel","dtb"; 3. カーネルデバイスツリーに、OP-TEEノード（ファームウェアと予約済みメモリ）を手動で追加します。imx8mp.dtsiデバイスツリーを編集して、以下の手順を実行してください。 - ルートノード（"/")に以下のOP-TEEファームウェアノードを追加します。 firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; - OP-TEEの予約済みメモリ領域をreserved-memoryノードの下に追加します。 optee_core@56000000 { reg = <0 0x56000000 0 0x1e00000>; no-map; }; optee_shm@57e00000 { reg = <0 0x57e00000 0 0x200000>; no-map; }; 4. イメージを作成し、ブートデバイスに書き込みます。 5. OP-TEEが起動しLinuxがドライバーをプローブしたかを確認するには、以下を実行します: root@imx8mp-lpddr4-evk:~# dmesg | grep optee [ 0.000000] OF: reserved mem: 0x0000000057e00000..0x0000000057ffffff (2048 KiB) nomap non-reusable optee_shm@57e00000 [ 0.000000] OF: reserved mem: 0x0000000056000000..0x0000000057dfffff (30720 KiB) nomap non-reusable optee_core@56000000 [ 2.581777] optee: probing for conduit method. [ 2.590862] optee: revision 4.8 (e7ed997213779e3d) [ 2.596363] optee: dynamic shared memory is enabled [ 2.601567] optee: initialized driver 6.OP-TEEをテストしたいなら xtestを実行することができます。 root@imx8mp-lpddr4-evk:~# xtest Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression+pkcs11+regression_nxp # ###################################################### * regression_1001 Core self tests o regression_1001.1 Core self tests regression_1001.1 OK o regression_1001.2 Core dt_driver self tests regression_1001.2 OK o regression_1001.3 Core transfer list self tests ..... +----------------------------------------------------- 49354 subtests of which 0 failed 161 test cases of which 0 failed 0 test cases were skipped TEE test application done! イネーブルメント中に問題があれば、ぜひ教えてください。 ありがとうございます エレナ Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @elena_popa この作業は既に完了しており、現在私のi.MX8MPボードで正常に起動しています。 現在の起動フローは以下のとおりです。 SPL → ATF → OP-TEE → Linux すべて想定通りに動作しています。@elena_popaさん、コメントありがとうございます。   [ 0.412349] OPEE:導管方法のプロービング。 [ 0.412373] optee: リビジョン 4.6 (788dc101B05ae47b) [ 0.412678] optee: 動的共有メモリが有効です [ 0.413062] optee: 初期化されたドライバ

imx93 仅通过设备树自由运行 ccm clko 大家好， 我希望在 MX93_PAD_CCM_CLKO3__CCMSRCGPCMIX_CLKO3 上输出一个自由运行的 12288000Hz 时钟。 根据手册，这应该可以从 IMX93_CLK_AUDIO_PLL 中推导出来。 请问有人能提供一下仅通过设备树实现此功能的方法吗？ Linux Re: imx93 free running ccm clko via device tree only 请参考imx93时钟驱动程序，您需要添加新的pll来支持此功能，仅修改dts文件是无法实现的。