Guider v1.8.1のダウンロードはどこにありますか？ こんにちは、 現在、GUI Guider v1.8.1で開く必要があるプロジェクトがあります。しかし、公開ウェブサイトでGUI Guider v1.8.1のダウンロードリンクが見つかりません。 このバージョンをダウンロードできる場所を教えていただけますか? ありがとう。 GUIガイド

S32k144でバックドアアクセスキーを使った解析 プロジェクト開始前に、s32k144を使用してバックドアテストを検証したいです。 unsecureProjectに関するサンプルコードがあります。(Example_S32K144_Verify_Backdoor_Access_Key_S32DS1.3_v2.zip) サンプルコードとリファレンスマニュアルを比較して、いくつか質問があります。 1.Verify Backdoor Access Keyに関するリファレンス・マニュアルによると、以下の表のように記載されています。 FCCOB 番号 0 はコマンド時に使用されます。 しかし、コードでは、コマンドのときにFCCOB番号4が使用されます。 だから考えたんだ。 FTFC->FCCOB[0x0] = 0x45; // バックドアキー検証コマンド (0x45) FTFC->FCCOB[0x3] = 0x45; // バックドアキー検証コマンド (0x45) どちらが正しいですか？ 2. ロックとアンロック(バックドアアクセスの確認)機構を確認したい。 初め。T32を使用してバックドアキーを設定します。（普通のやり方ではないことは分かっています。）通常はコードを挿入します） 例） Data.Set SD:0x400 %LE %Long &pwd_Head データ.Set SD:0x404 %LE %Long &pwd_Tail データ.Set SD:0x40C %LE %Long 0xFFFF7FBF 2番。リセットすると、FSECレジスタ(0x40020002)はフラッシュ構成フィールド(0x40C)のセキュリティバイトに格納された値で初期化されます。 Q.2-1。これは、デバイスがリセットされるまで非セキュア状態のままであり、リセット後にFSECレジスタ（0x40020002）が0x40Cから読み取られた値で更新され、デバイスがセキュア状態に入るという意味でしょうか？ 三番目。バックドアアクセスを確認する際、以下のリファレンス・マニュアルに「キャプチャ」と記載されています。 Q. 2-2.これは、FSECレジスタが一時的に非セキュアモードに変更され、リセット後に元の状態に戻るという意味でしょうか？リセット時に、FSECレジスタ（0x40020002）は再び0x40Cから値を読み取る、ということですよね？ 問2-3この更新が行われるとき、セキュリティ関連ビットだけが変更されるのか、それともFSECバイト全体が上書きされるのか? 例えば、遷移はBF → FEなのか、それともBF → BEなのか？ 3. この説明に基づくと、キーが一致しない場合、デバイスはリセットされるまで保護されたままになります。この場合、バックドアアクセスが無効化された場合、どのようにデバイスをリセットできますか? 4. 次のコマンドを実行すると： データ.Set AD:0x40020000 %バイト 0x30 そしてすぐに、以下の方法で読み返してください。 データ.Byte(AD:0x40020000) 値は依然として0x80のままです。 この行動の理由は何で、それは何を意味するのでしょうか? ================================================================== だから、私は思う S32K144にデータを書き込む際、設定値は0x400～0x40Fの領域に書き込まれます。 MCUがリセットまたは再起動されると、FTFCレジスタは0x400–0x40F領域に保存された設定値を読み取り、その設定に従って動作します。 右？ また、バックドア比較キーがstartup_S32K144.Sに現れますが、これはmain()に入る前に設定が適用されるという意味でしょうか？ ================================================= アドレス0x40000100または0x40000104を使用して、セキュリティ保護されていない状態を確認します。 これは正しいですか？ リファレンス・マニュアルには関連する説明が見つかりませんでした。 ありがとう。 #s32k144 @backdoor アクセス Re: Verfiying Backdoor access key using in S32k144 サポートありがとうございます!! Re: Verfiying Backdoor access key using in S32k144 こんにちは、 @LGI さん。 A4フォローアップ： アドレス0x40020000にFSTATレジスタがあります。 前述の通り、このレジスタは0から1までのビットを設定する書き方はできません。 ビットに「1」を書き込むとクリアされるだけです(W1C – Write-1-to-clear)。したがって、「1」を書き込んでもビットは設定されず、既に「1」になっているビットがクリアされるだけです。 A8のフォローアップ： これらはMDM-APの状態および制御レジスタで、Arm Debugアクセスポート(DAP)を通じてのみアクセス可能です。 例えば、このスクリプトでは使用されています。 https://community.nxp.com/t5/S32K-Knowledge-Base/Lauterbach-Script-For-MDM-AP-Mass-erase-S32K142/ta-p/2336449 よろしくお願いいたします。 ダニエル Re: Verfiying Backdoor access key using in S32k144 ご回答ありがとうございます。@danielmartynek それでは、いくつか質問がありますので、お答えください。 A4。アドレス0x40020000に0x30を書き込みましたが、読み戻したときに値は0x30に変わらず、0x80のままでした。 この行動の理由は何で、それは何を意味するのでしょうか? Q8.これは実際にはTrace32の例に関連しています。 S32K144のTrace32例では、セキュリティ状態情報のためにアドレス0x40000100と0x40000104が使われています。 しかし、0x40000100と0x40000104の住所に関する情報は見つかりませんでした。私が質問しているのはまさにその点です。 再開まで今しばらくお待ちください。 Re: Verfiying Backdoor access key using in S32k144 こんにちは、 @LGI さん。 A1: これは FTFC->FCCOB[0x3] = 0x45; // バックドアキー検証コマンド (0x45) です。 FCCOB0はメモリマップの4番目のレジスタだからです。 A2: プログラマーやデバッガを使ってフラッシュ構成フィールドをプログラムできますが、セクターは事前に消去しておく必要があります。一括消去を行うと、FSECバイトも非セキュア状態にプログラムされることに注意してください。 A2.1: はい A2.2: はい A2.3:FSEC[SEC]のみ。 A3:MCUには多くのリセットソースがあります(RM、25.2.2システムリセットソース)。 デバッガはピン(PTA5)をアサートすることでMCU Reset_bリセットできます。 A4: レジスタへの書き込みにはW1C機能のみがあります。 Q5: S32K144にデータをプログラムする際、設定値は0x400～0x40Fの領域に書き込まれます。 A5: はい Q6: MCUがリセットまたは再起動されると、FTFCレジスタは0x400–0x40F領域に保存された設定値を読み取り、それらの設定に従って動作します。 A6: はい、MCUはフラッシュ構成フィールドの値をFTFCレジスタに読み込みます。 Q7: また、バックドア比較キーはstartup_S32K144.Sに現れますが、これはmain()に入る前に設定が適用されるという意味でしょうか？ A7: リセットが必要ですが、これはプログラマー/デバッガーがプログラミング後に通常行うことです。 Q8: アドレス 0x40000100 または 0x40000104 を使用して、セキュリティ保護されていない状態を確認します。これは正しいですか？ A9：私はあなたが言っているような人間ではありません。詳しく説明してください。 よろしくお願いいたします。 ダニエル

HSEファームウェアのインストール 上記の図に示されているHSE-Bファームウェアリファレンスマニュアルのドキュメントはどこでダウンロードできますか?ダウンロードリンクを提供してください。ありがとうございます。 Re: HSE Firmware Installation こんにちは、羅京さん 既に秘密保持契約書（NDA）に署名済みの方は、文書に記載されている手順に従って登録し、NDAをアップロードしてください。https://www.nxp.com.cn/docs/en/user-guide/nxp-secure-access-rights-registration.pdf 次に、RM00286 HSE-B ファームウェア リファレンス・マニュアル - V2.7が表示されます。 よろしくお願いいたします ロビン

适用于 FRDM i.MX 93 的 22 引脚 MIPI-DSI 显示屏 您好， 我正在使用 FRDM i.MX 93，正在寻找可连接到 22 针 MIPI-DSI 端口的兼容显示器。最好是尺寸在 5/5.5 英寸左右，可以背靠背安装在主板上的那种。我找到了 RK055HDMIPI4MA0 显示屏，但它只支持 40 针 FPC 和 Waveshare 的 7 英寸显示屏，但我还不太确定具体型号。请问有人可以分享一下NXP Yocto 电路板支持包。Linux官方支持的显示器型号信息，或者分享一下使用非官方支持的显示器的经验吗？ 谢谢！ Re: 22-Pin MIPI-DSI Display for FRDM i.MX 93 非常感谢@Zhiming_Liu 。我会试试。 Re: 22-Pin MIPI-DSI Display for FRDM i.MX 93 嗨@KoThi 您可以在之前提交的内容中引用此产品链接。 https://github.com/nxp-imx-support/meta-imx-frdm/blob/lf-6.6.36-2.1.0/meta-imx-bsp/recipes-kernel/linux/linux-imx/0004-Add-DSI-Panel-for-imx93.patch#L224 此致， 志明

MCUXpresso for Visual Studio Code - MCX MCUXpresso for Visual Studio Code (VS Code) provides an optimized embedded developer experience for code editing and development. The extension enables NXP developers to use one of the most popular embedded editor tools and provides an easy and fast way to create, build and debug applications based on MCUXpresso SDK or Zephyr projects.   Install it following the next steps: Download Visual Studio Code from Microsoft Store or visual studio code web page Download Visual Studio Code - Mac, Linux, Windows Access to vscode for MCUX wiki and download MCUXpresso Installer  Dependency Installation · nxp-mcuxpresso/vscode-for-mcux Wiki · GitHub Run MCUXpresso Installer and for MCXW72 Hands On install at least MCUXpresso SDK Developer Matter Developer Arm GNU Toolchain Standalone Toolchain Add ons Linkserver PEmicro Installing the FRDM-MCX SDK  Each MCU has its own SDK that includes driver, examples, middleware, docs and other components. To get and build the demo, let’s install the SDK into VS Code. Install the NXP’s GitHub SDK: Once MCUXpresso for Visual Studio Code is installed, open VS Code. Go to MCUXpresso for VS Code extension that is on the tools column at the left. Look for INSTALLED REPOSITORIES option and press ‘+’ (Detail steps are described in wiki page. Working with MCUXpresso SDK · nxp-mcuxpresso/vscode-for-mcux Wiki · GitHub).                                               Search for the remote option of the Import Repository window. Select the MCUXpresso SDK in the repository option to download the GitHub SDK, then in the Revision tab you can select either the “main” revision or to select a specific version), optionally you can change the repository name and location. Finally click on the “Import” button. FRDM-Training Hands-On Training

LLM / VLM Edge Studio - Display Inference Metrics Failure Applies to: LLM / VLM Edge Studio Go Point Demo Workaround: Update demos via deb package In the current BSP release, users may encounter a runtime failure when the requesting inference metrics after running an inference in the LLM / VLM Edge Studio demo, as a result, metrics are not displayed at all. This issue is caused by a change in the metrics response format from the AAF Connector, which is not compatible with the current demo version.  To fix, update the demo by installed the patched Debian package attached to this thread.  - Download and copy deb packages to target board:  scp vlm-edge-studio_1.0.1.deb [email protected]: scp llm-edge-studio_2.0.1.deb [email protected]: - Overwrite the demo installation: dpkg -i --force-overwrite vlm-edge-studio_1.0.1.deb dpkg -i --force-overwrite llm-edge-studio_2.0.1.deb BR, ARA240 DNPU

LLM Edge Studio - Qwen2.5-Coder-1.5B not supported out-of-the-box Applies to: LLM Edge Studio Go Point Demo Workaround: Requires custom llm_params configuration The model Qwen2.5-Coder-1.5B is not supported out-of-the-box in LLM Edge Studio using the default configuration. The model loading will fail when attempting to run the model with the default  server_config.json fix: update the  llm_params  section in  server_config.json  with compatible sampling values: - Open config file: vi llm-edge-studio/usr/share/llm-edge-studio/server_config.json - Replace the parameters as follows: "llm_params": { - "temperature": 0.0, - "top_k": 0, - "top_p": 0.0, + "temperature": 1.0, + "top_k": 50, + "top_p": 0.95 } Qwen2.5-Coder-1.5B should run with proper output quality and sampling behavior after applying the updated configuration.  Remarks:  This configuration enables proper behavior for Qwen2.5-Coder-1.5B It may generate warning messages when running Qwen2.5-Instruct-7B, but the model will continue to function normally BR, ARA240 DNPU

VLM Edge Studio Demo – Qwen‑VL Initialization Failure   Applies to: VLM Edge Studio Demo using Qwen‑VL backend Workaround: Apply the attached  apply_qwenvl_fix.sh  script   In the current VLM Edge Studio Demo, users may encounter a runtime failure when starting the Qwen‑VL Vision Language Model. The issue is caused by incorrect processor initialization, where the code attempts to load tokenizer and image processor assets directly from a hard‑coded Hugging Face model reference instead of the locally deployed tokenizer path. This typically manifests as: Model startup failures Tokenizer / processor load errors Inconsistent behavior when running in offline environments To fix no configuration changes are required, copy and apply the provided patch on the board: root@imx95evk:~# chmod a+x apply_qwenvl_fix.sh root@imx95evk:~# sh apply_qwenvl_fix.sh remarks: please make sure the path in the script match your installation: PROD_FILE="/usr/share/eiq/aaf-connector/venv/lib/python3.13/site-packages/eiq_aaf_connector/llm_engines/QwenVL.py" ARA240 DNPU

Brake Control Monitoring Course Using NXP FRDM-A-S32K3 Automotive Platforms Introduction Braking systems are among the most important safety-related functions in modern vehicles. Modern automotive electronic systems continuously monitor brake inputs and react in real time to ensure driver awareness and vehicle safety. This course introduces brake control and brake status monitoring concepts using NXP S32K3 automotive microcontrollers and Application Code Hub examples. Through practical demonstrations, participants will learn how embedded software acquires, processes, and reacts to brake-related signals using automotive-grade development platforms. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. The course is based on the following Application Code Hub demonstrations: Brake-Control-Monitoring-FRDM-A-S32K312 Brake-Control-Monitoring-FRDM-A-S32K344 Both examples implement the same brake monitoring concept and can be executed on either FRDM-A-S32K312 or FRDM-A-S32K344, allowing teachers, students, and developers to choose the platform that best fits their hardware availability and learning objectives. The demonstrations simulate a braking event using a Force Click board connected through the FRDM K64 Click Shield. The Force Click acts as a brake pedal sensor and generates an analog signal proportional to the applied pressure. This signal is acquired through the MCU ADC peripheral, processed by the application, and used to drive a 4x4 RGB Click board that provides visual indication of the current braking condition. The examples illustrate how automotive brake monitoring systems can detect braking events and react in real time using embedded software running on the S32K3 platform. FRDM-A-S32K312FRDM-A-S32K312 FRDM-A-S32K344FRDM-A-S32K344 Course Objectives After completing this course, participants will be able to: Understand the fundamentals of automotive brake monitoring systems Acquire analog signals using ADC peripherals Process brake-related inputs in real time Control visual indicators based on system status Understand ADC and FlexIO peripheral integration Develop applications using S32 Design Studio and RTD drivers Prototype automotive applications on FRDM-A-S32K312 and FRDM-A-S32K344 boards Hardware Platforms and Components Platform Selection One of the advantages of this course is the flexibility to use either the FRDM-A-S32K312 or the FRDM-A-S32K344 platform. Both examples demonstrate the same automotive brake monitoring functionality and learning concepts, enabling users to select the board available in their laboratory environment while following the same workflow and development methodology. FRDM K64 Click Shield Provides mikroBUS™ connectivity for Click boards and simplifies hardware expansion. Force Click Simulates the brake pedal input by generating an analog signal proportional to the applied pressure. The ADC peripheral continuously reads this signal to determine the brake status. 4x4 RGB Click Acts as the brake status indicator. Different LED patterns can be used to represent braking conditions and emergency braking events. The LEDs are controlled through the FlexIO peripheral. Brake Control Monitoring on FRDM-A-S32K312Brake Control Monitoring on FRDM-A-S32K312 Brake Control Monitoring on FRDM-A-S32K344Brake Control Monitoring on FRDM-A-S32K344 System Architecture The application follows a simple automotive workflow: The user applies pressure to the Force Click sensor. The ADC peripheral acquires the analog value. The application processes the braking signal. Brake status is evaluated against predefined thresholds. The 4x4 RGB Click LEDs are updated to indicate the current braking condition. This workflow illustrates how sensors, software processing, and output indicators interact in a real-time automotive embedded system. Educational Value This course can be used as: Eat-Sleep-Code-Repeat University laboratory material Automotive embedded systems training S32K3 hands-on workshop content Introduction to automotive safety-related software Application Code Hub learning path Students gain practical experience with ADC acquisition, signal processing, real-time decision making, and peripheral control using real automotive hardware. Getting Started Open S32 Design Studio. Select Import Project from Application Code Hub. Search for the desired brake demo. Import the project. Build and flash the application. Assemble the hardware. Apply pressure on the Force Click sensor. Observe the brake status indication on the 4x4 RGB Click LEDs. Conclusion This course demonstrates how brake control and brake status monitoring systems can be prototyped on NXP S32K3 automotive platforms. By combining analog signal acquisition, real-time processing, and LED-based indication, the examples provide a practical introduction to automotive embedded software development and safety-oriented system design. Participants can choose either the FRDM-A-S32K312 or FRDM-A-S32K344 platform and follow the same learning path to understand the implementation of brake monitoring functionality on modern automotive microcontrollers. Result on FRDM-A-S32k312Result on FRDM-A-S32k312 Result on FRDM-A-S32K344Result on FRDM-A-S32K344 References https://mcuxpresso.nxp.com/appcodehub?search=dm-brake-control-s32k312 https://mcuxpresso.nxp.com/appcodehub?search=dm-brake-status-monitoring-frdm-a-s32k344

DESFire EV3 事务 MAC 输入 (TMI) 构建 — 使用 TapLinx 进行后端验证 您好， 我正在后端验证 DESFire EV3 交易 MAC (TMV/TMC) 值。这张卡片 通过 TapLinx (CommitTransaction) 生成交易 MAC。我有这笔交易 MAC密钥、卡UID、TMC（前后）以及退回的TMV，我都有。 已实现从公共引用派生 EV2 会话密钥——但我无法 由于我没有确切的交易 MAC 输入 (TMI) 字节，因此需要重现 TMV。 EV3 的建设。 请问您能否帮忙解决以下问题： 1.DESFire EV3 的确切 TMI 累积量（哪些命令字节/字段是） 包括它们的顺序和填充物）。 2. 是否涵盖在同一事务中提交的备份数据文件写入操作 由 TMI 提供。 3. 是否存在已知密钥的交易 MAC 参考向量 （密钥 + TMI + TMC + TMV）用于验证实现。 4. 如果这是 NDA 专属的，那么作为一家小公司，获取 DS4870 / AN12757 的正确方法是什么？ 谢谢！ Re: DESFire EV3 Transaction MAC Input (TMI) construction — backend verification with TapLinx 您好，先生， 非常感谢您对我们产品的关注。 遗憾的是，要获得 MIFARE DESFire EV3 的安全文档，需要签署一份保密协议。请查看我们的常见问题解答并填写保密协议表格。您需要从我们的网站创建一个新的工单。 希望这些信息对您有所帮助。

请求提供适用于 Linux 内核 6.1.85 的 IW416 Wi-Fi/BT 驱动程序源代码和构建指南 NXP社区的各位朋友，大家好！ 我目前正在将NXP IW416（基于 8997） Wi-Fi/蓝牙模块集成到定制的 SBC 中。我的系统运行的是基于 Yocto 的发行版，内核版本为Linux Kernel 6.1.85 。 我想将 Wi-Fi 和蓝牙驱动程序构建为内核外部模块，但我希望确保我使用的是正确且最稳定的源代码。 请问您能否指导我完成以下事项？ 驱动程序源代码：对于内核 6.1.85，我应该使用哪个特定的存储库和分支（或提交）？ 构建说明：是否有任何官方文档、应用说明或指南，说明如何正确构建和集成这些驱动程序和所需的固件？ 任何帮助或相关资源的指引都将不胜感激。 提前谢谢！   Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 我的环境配置如下： $ ls -al /lib/firmware/nxp/ drwxr-xr-x 2 root root 4096 2月28日 02:44 ./ drwxr-xr-x 3 root root 4096 2024年2月28日 ../ -rw-r--r-- 1 root root 415996 2024年2月28日 sdioiw416_wlan_v0.bin -rw-r--r-- 1 root root 570976 2024年2月28日 sdiouartiw416_combo_v0.bin -rw-r--r-- 1 root root 154920 Feb 28 2024 uartiw416_bt_v0.bin -rw-r--r-- 1 root root 58 2月 28 02:28 wifi_mod_para.conf   $ cat /lib/firmware/nxp/wifi_mod_para.conf fw_name= "nxp/sdiouartiw416_combo_v0.bin" cal_data_cfg=none   $ lsmod 模块尺寸使用 摩尔 745472 0 mlan 585728 1摩尔   我可以提供 dmesg 日志的相关部分。请问我应该搜索哪些具体的关键词或部分？另外，我想知道它在正常运行时的预期结果/输出是什么。   谢谢！ + 启动时，mlan 驱动程序会输出如下日志。 [ 1.312336] wlan：正在加载 MWLAN 驱动程序 [ 1.316381] wlan：向总线驱动程序注册... [ 1.321331] wlan：已完成向总线驱动程序注册 [ 1.326355] wlan：驱动程序已成功加载   Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 你好， @sunam 固件应放置在 /lib/firmware/nxp/ 目录下。 如果您使用的是 Wi-Fi 和蓝牙组合固件，请按如下方式操作： root@imx8mnevk: /lib/firmware/nxp # ls -l sduartiw416_combo.bin -rw-r--r-- 1 root root 406996 2011年4月5日sduartiw416_combo.bin 安装完成后，请检查/lib/firmware/nxp/wifi_mod_para.conf 中的 wifi 驱动程序加载参数，并再次确认固件名称是否匹配。 如果仍然失败，请提供设备启动时的 dmesg 日志。 顺祝商祺！ Christine。 Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 你好， 我目前正在使用IW416芯片。我已经使用 6.1.55-2.2.2 分支成功构建了驱动程序，并确认驱动程序已正确生成。 但是，它似乎无法正常工作，我怀疑是因为缺少最新的固件。请问固件文件应该放在哪个目录下？ 谢谢！ Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 你好， @sunam 1. 请再次确认您使用的是IW416 还是 88W8997 ，它们是不同的芯片组。 对于 IW416， 下载我们最新的固件： imx-firmware/FwImage_IW416_SD at lf-6.18.20_2.0.0 · nxp-imx/imx-firmware · GitHub 下载我们最新的驱动程序： GitHub - nxp-imx/mwifiex at lf-6.18.20_2.0.0 · GitHub 驱动程序源代码与运行 Linux 内核版本2.6.32 到 6.19.0 的主机兼容，因此适用于您的 L6.1.85。 2.组装说明： 是否有任何官方文档、应用说明或指南，介绍如何正确构建和集成这些驱动程序和所需的固件？ ==> 请参阅： 如何下载和构建 NXP Wi-Fi 驱动程序 我相信以下文档对您也很有用： 在运行 Linux 操作系统的 i.MX 8M Quad EVK 上使用基于 NXP 的无线模块入门指南 如果您还有其他疑问，请告诉我。 如果不行，请将我的回答标记为解决方案，以便我们关闭此问题。 如果您在使用我们产品的过程中遇到任何问题，欢迎创建新案例。 顺祝商祺！ Christine。 Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 你好， @sunam 通常情况下，它应该打印类似如下的 dmesg 日志： ========= root@imx8mnevk:~# dmesg | grep 无线局域网 [ 5.127546] wlan：正在加载 MWLAN 驱动程序 [ 5.141006] wlan：向总线驱动程序注册... [ 5.213728] wlan：启用 TX SG 模式 [ 5.217262] wlan: mpa_tx.buf_size=65280 [ 5.221136] wlan：启用 RX SG 模式 [ 5.224679] wlan: mpa_rx.buf_size=65280 [ 6.505940] wlan：启用 RX SG 模式 [ 6.585864] wlan: 版本 = SD8987----16.92.21.p155.1-MM6X16540.p33-GPL-(FP92)//这是我们的 88W8987 的示例。 [ 6.624373] wlan：已完成向总线驱动程序注册 [ 6.637582] wlan：驱动程序已成功加载 ======== 您可以按如下方式修改 wifi_mod_para.conf 文件： ====== SDIW416 = { fw_name=nxp/sdiouartiw416_combo_v0.bin cal_data_cfg=none cfg80211_wext=0xf max_sta_bss=1 驱动模式=7 } ======= 如果仍然失败，请提供设备启动时的完整 dmesg 日志。 您可以将 dmesg 日志作为附件上传。 顺祝商祺！ Christine。

ssscli 对 SE051 默认支持哪些 AES 模式？ 你好， 我目前正在使用 Plug & Trust 中间件中的 ssscli 工具评估 SE051。 我的目标是使用 密码块链接(CBC)、ECB 等模式执行 AES 加密和解密操作，理想情况下，还可以使用 GCM 或 CCM 等 AEAD 模式。 在查看提供的 ssscli Python 源代码时，我注意到以下几点： 在 const.py 中，CRYPT_ALGO 字典仅定义了 AES_CTR。 在 cli.py 中，加密和解密命令的帮助文本只提到了 --algo oaep 和 --algo rsaes。 由于我计划将其用于商业产品，因此我希望避免修改 NXP 提供的源代码（例如 const.py 或 cli.py）。 请您澄清以下几点？ 开箱即用的支持： 在不修改任何源代码的情况下，当前版本（04.07.01）中的 ssscli 加密/解密命令有哪些 AES 模式可用？ 是否仅限于 AES_CTR？ 替代方案： 如果我需要在不修改 Python CLI 脚本的情况下使用 密码块链接(CBC) 或 GCM 等其他模式，推荐的方法是否是使用 C-API 开发自定义应用程序？ 或者，NXP 是否有其他预构建的工具/二进制文件可用于评估这些特定的 AES 模式？ 环境： 板： MCIMX8M-WEVK 和 OM-SE051ARD SoC： i.MX 8M Linux 版本： 6.1.151-cip46 Plug & Trust MW 版本： 2001年7月4日 任何指导都将不胜感激。 Re: What AES modes are supported out-of-the-box by ssscli for SE051? 嗨@Uc_S ， 是的，ssscli 对 AES 的开箱即用支持仅限于 AES_CTR，如果您不想修改 Python 代码，则必须用 C 开发自定义应用程序，例如 MW 中提供的示例，例如 ex_sss_symmetric 演示。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: What AES modes are supported out-of-the-box by ssscli for SE051? 感谢您的清晰答复。 我完全理解。值得注意的是，AES_CTR 是 ssscli 唯一开箱即用的受支持模式。 根据您的建议，我们将考虑使用提供的示例开发一个自定义的 C 应用程序来实现其他 AES 模式。

FS26 Amux sensing issue I am attempting to measure the voltage on the AMUX pin after routing the BAT sense voltage to it. I have verified all relevant register values, and the FS_STATES register reports the device is in Normal mode. However, the AMUX pin continues to output 0 V, and my 12‑bit ADC consistently reads a value of 0. I used one of the S32K3xx reference examples as the basis for my code, which I have attached, but the AMUX measurement is not functioning as expected. please, check this. Re: FS26 Amux sensing issue Hi, Thank you for sharing the code and details. Could you please check the following: - Read back M_AMUX_CTRL register after the write and confirm that AMUX_EN = 1 and AMUX[4:0] = 0x16 (BATSENSE selected).  - Please also confirm that the SPI response indicates M_AVAL = 1, meaning the main state machine is in Normal mode. - On the hardware side, please verify that the BATSENSE pin has the expected voltage present and that the AMUX pin is correctly routed to the ADC input.   BRs, Tomas Re: FS26 Amux sensing issue Hi,  Your read-back confirms the AMUX is configured correctly, but the device is stuck in the INIT_FS. To resolve this, please follow the initialization and watchdog sequence described in AN13850 (Secure file requiring an NDA), sections 6.1 and 6.2: After power-up or reset, configure all required FS_I_xxx and FS_I_NOT_xxx registers as described in section 6.1. Perform a good watchdog refresh within the 256ms INIT_FS window to close the initialization phase. Once the safety outputs are released, the device will enter Normal mode and AMUX measurements should function as expected. BRs, Tomas Re: FS26 Amux sensing issue The M_AMUX_CTRL register was configured for M_AMUX_EN | M_AMUX_BATSENSE | M_AMUX_DIV_0 and verified via read-back as 0x56. This confirms the analog multiplexer is active and correctly routing the 12V BATSENSE input.   However, the SPI device status (u8DeviceStatus) reads back as 0xCA. Because the most significant bit is set (sbc_fs26_RxFrameType.u8DeviceStatus & 0x80 == 1), a global Fail-Safe fault is active. Additionally, the FS_STATES register returns 11, proving the device is stuck in the INIT_FS (Initialization Fail-Safe) state. 

S32DS for ARM 2018R1 IDE 的许可证已过期 我的 S32DS for ARM 2018R1 IDE 许可证 已过期。请问您能否帮忙查询并续期？ 我查看了软件许可，但是这个版本我无法自行扩展（ARM2.2 版本可以）。 提前谢谢您。 激活 | 安装 | 许可 | 安装程序下载 Re: License of S32DS for ARM 2018R1 IDE has expired Ahoj Matúši, 您的S32DS许可证已延期。请使用您之前的激活码重新激活S32DS。

KW47 NBU programming and upgrade Hi: I want to know how to programming and upgrade of KW47 NBU.I hope the steps can be more detailed.  Thank you! Re: KW47 NBU programming and upgrade Hi: Thank you very much for your support. I can now update the nbu firmware through the method you provided.  I see that the method you provided doesn't include the way to update nbu through firmware?  For instance, if my device is launched on the market and I need to update the nbu version, how should I proceed?  Thank you! Re: KW47 NBU programming and upgrade Hello, hope you are doing well. You can refer to AN14796 Migration Guide from the KW45 to the KW47, section 6.2 "Load NBU firmware in KW47". In this document you will find several methods to update the NBU for KW47 (the steps are demonstrated using the KW47-EVK), including blhost, the Secure Provisioning Tool and LinkServer, you can use whichever approach works best for your development. The detailed steps for each method are included as well. Hope this helps! If you have any further question, please let me know. Best regards, Ana Sofia. Re: KW47 NBU programming and upgrade Hello, The ROM Bootloader has a firmware update feature that can be used for updating main flash as well as radio flash firmware. For in-field NBU updates, the workflow typically follows this sequence: the application stores the update image and writes the corresponding metadata into the User IFR0 OTACFG region, then triggers a system reset so the ROM bootloader can take over and perform the radio firmware update. More information is available in the KW47 Security Reference Manual sections 4.2.6 “Firmware update feature” and 4.2.2.3 Over-the-air (OTA) update configuration. Best regards, Ana Sofia.

LPC55S28 VBAT_PMU 电流消耗 我有一块PCB板，原理图如下。我备有一颗纽扣电池，以防PCB主电源断开。据我了解，MCU 上的 VBAT_PMU（引脚 51）专用于Always‑On (PD_AON) 域。 当我测量电池的电流消耗时（没有主电源，只有电池供电），我得到大约 102uA 的电流。这远远高于 RTC 的预期功耗，即使移除 D12 也是如此。Vbat 仅连接到 VBAT_PMU 引脚，没有连接到其他任何引脚。 这里预期会出现什么情况？我预计 VBAT_PMU 只会消耗足够的电流，以确保在断电期间 RTC 能够保持时间。102uA 的电流会很快耗尽 CR1632 纽扣电池的电量。 如何给MCU供电，才能使电池只为RTC供电，并且在主电源断开时电流消耗小于1uA？ Re: LPC55S28 VBAT_PMU Current Draw 嗨@guitardenver 在 LPC55S28 上，VBAT_PMU 是始终开启功能域的电源，该功能域包括 PMC、RTC 和 OS 事件定时器，只要存在有效的 VBAT 电源，该功能域就会保持通电状态。从该功能域来看，即使深度掉电，RTC 也能继续运行。 VBAT_PMU 本身并不能保证“仅 RTC 电流”。要获得亚微安级的备用电流，设备必须处于深度掉电模式。 因此，您测得的在主电源移除后的 ~102 µA 与仅 RTC 深度掉电运行不符。 对于 LPC55S2x/LPC552x，数据手册显示，在 25 °C 和 3.0 V 的深度睡眠模式下，典型总供电电流为 110 µA；而 RTC 振荡器禁用时的深度掉电电流为 590 nA；RTC 由外部晶体供电时的深度掉电电流为 790 nA。 要使 LPC55S28 上的纽扣电池电流小于 1 µA，只需从电池为 VBAT_PMU 供电，并在移除主电源之前使固件进入深度掉电状态。 BR 哈里 Re: LPC55S28 VBAT_PMU Current Draw 感谢你的回复！ 我编写了一段代码，可以在发生低电压中断时触发深度掉电，效果很好。但这种方法存在一个巨大的问题。如果 ROM 引导加载程序正在执行，并且电源被移除，则不会设置掉电中断，也没有代码将其置于掉电状态。 有没有什么好办法可以保证我能进入深度关机模式？如果任何状态使MCU处于正常模式，电池就会耗尽。或许我遗漏了什么。如果不行，我可能就得在板子上加装一个外置实时时钟芯片了。 Re: LPC55S28 VBAT_PMU Current Draw 嗨@guitardenver 不——对于 LPC55S28，如果设备在主电源移除时可能正在执行 ROM 引导加载程序，则不能仅通过固件保证进入深度掉电状态。深度掉电是通过电源 API 以软件方式进入的模式。 BR 哈里

如何在 SGMII 中为 M7 内核配置 PFE_MAC 您好，NXP， 我们希望在 PFE_MAC 和以太网交换机的端口之间建立 SGMII 链路。 请问是否有针对 M7 内核在 SGMII 中配置 PFE_MAC 的示例？ 感谢您的帮助。 Re: How to configure PFE_MAC in SGMII for the M7 core 你好， @77373 感谢你的帖子。 是的，PFE MCAL 软件包中确实包含此功能，您可以查看其中包含的相应示例，这些示例可以通过您的 NXP 帐户访问和下载，或者通过以下链接应用： https://www.nxp.com/app-autopackagemgr/automotive-software-package-manager:AUTO-SW-PACKAGE-MANAGER BR 陈银

IMX8MP secondary image boot Does IMG_CNTN_SET1_OFFSET secondary image boot (RM 6.1.6.2) work for ECSPI ("SPI") NOR boot on i.MX8MP, or only for FlexSPI NOR (and SD/eMMC)? Table 6-28 lists "SPI" and "FlexSPI NOR" as separate boot devices, and the secondary-offset valid values are stated only "for FlexSPI NOR boot."

Difference in ADC noise between BCTU Control Mode and Trigger Mode Hello, I am working on an application using the [S32k322] where I use the eMIOS timer to trigger the BCTU every 100 µs to read analog data. I am observing a strange behavior between the two BCTU modes: Control Mode: When the ADC CTU mode is set to Control Mode, the ADC conversions are completely stable. The data read via FreeMASTER is clean and free of noise or glitches. Trigger Mode: When I switch the ADC CTU mode to Trigger Mode (keeping the 100 µs eMIOS trigger identical), the sampled analog data becomes noisy and exhibits noticeable glitches in FreeMASTER. Are there specific architectural configurations, timing constraints, or register settings (such as trigger delays, FIFO configurations, or clock synchronization) required for Trigger Mode to prevent this noise? Thank you for your help. Output with ADC ctu mode : Trigger Mode output with ADC ctu mode : Control Mode Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi@Stark_ could you please share the test project and i will test it on myside. Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi @Senlent ,    Thanks for the response. My ADC clock is 160MHz, and I've attached my ADC configuration and register values below. Clock ADC Configuration Output with ADC ctu mode : Trigger Mode output with ADC ctu mode : Control Mode Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi@Stark_ Based on the configuration screenshot you provided, there are some configuration issues, specifically the division ratios for the module clock and calibration clock. The ADC clock configuration must strictly follow the table below. please change it and test  again, Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi @Senlent  I have attached test code. is it possible to work on BCTU and normal conversion for the some selected channels (ADC_Instance0 and ADC_Instance1)? Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi @Senlent  " yes, it is possible to work on BCTU and normal conversion." is there any example code for reference? " Also, your program still doesn't modify the ADC module clock and calibration clock divider. Below are my test results; I connected the port externally to GND. You can see there isn't a significant difference. " could you please share the modified test project and i will test it on myside. Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi@Stark_ I don't have a demo like that; the attached file is a modified project. Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi@Stark_ yes, it is possible to work on BCTU and normal conversion. I tested the program you provided and made some modifications. Your external clock is 25MHz, while mine is 16MHz. Also, your program still doesn't modify the ADC module clock and calibration clock divider. Below are my test results; I connected the port externally to VDD（my typing error）. You can see there isn't a significant difference.

LPC55S28 VBAT_PMU 消費電流 下記の回路図が描かれたプリント基板があります。基板の主電源が切断された場合に備えて、バックアップ用のコイン型電池を用意しています。私の理解では、MCUのVBAT_PMU(ピン51)は常時オン(PD_AON)ドメイン。 メイン電源を使わずにバッテリーだけを使った状態でバッテリーの電流消費量を測ると、約102uAになります。これはRTCが消費する量をはるかに超える。D12が削除された場合のイベントです。VBATはVBAT_PMUピンにのみ接続されており、それ以外は接続されません。 ここで期待される動作は何ですか？VBAT_PMUは、電源が切れている間、RTCが時刻を維持するために必要なだけの電流しか消費しないはずだと私は考えています。102μAの電流では、CR1632型コイン電池はかなり早く消耗してしまうだろう。 MCUに電力を供給するにはどうすればいいですか?バッテリーはRTCだけに電力を供給し、メイン電源を外したときに1uA未満の電力を消費します。 Re: LPC55S28 VBAT_PMU Current Draw こんにちは、 @guitardenver LPC55S28では、VBAT_PMU常時オンドメインの電源であり、PMC、RTC、OSイベントタイマーを含む。有効なVBAT電源が存在する限り、そのドメインは電源を維持します。RTCはそのドメインから深いダウン状態で動作を続けられます。 VBAT_PMU単体では「RTC専用電流」を保証するものではありません。サブマイクロアンペアのバックアップ電流を得るには、デバイスをディープパワーダウンモードにする必要があります。 したがって、主電源を抜いた状態で測定された約102μAは、RTCのみの深切断動作とは一致しません。 LPC55S2x/LPC552xのデータシートによると、25℃、3.0Vでのディープスリープモード時の標準的な総供給電流は110μAですが、RTC発振器を無効にした状態でのディープパワーダウン時は590nA、外部水晶発振器でRTCを動作させた状態では790nAとなっています。 LPC55S28のコイン型電池から1µA未満の電流を得るには、バッテリーからVBAT_PMUのみに電力を供給し、主電源が切断される前にファームウェアがディープパワーダウン状態に入るようにします。 BR ハリー Re: LPC55S28 VBAT_PMU Current Draw お返事ありがとうございます！ 電圧低下割り込みでディープパワーダウンをトリガーするコードがあり、これはうまく機能しています。しかし、この方法には大きな問題があります。ROMブートローダーが実行中に電源が切断された場合、ブラウンアウト割り込みは設定されておらず、電源を切断するためのコードも含まれていません。 ディープパワーダウンモードに入ることを確実にする方法はありますか?もしMCUがノーマルモードに残る状態が現れると、バッテリーが消耗します。何か見落としていることがあるのかもしれない。そうでない場合は、基板上に外部RTCチップを取り付ける必要があるかもしれません。 Re: LPC55S28 VBAT_PMU Current Draw こんにちは、 @guitardenver いいえ — LPC55S28では、メイン電源が外れたときにデバイスがROMブートローダーを実行している可能性がある場合、ファームウェアだけでDeep Power-downに入ることを保証できません。ディープ・ダウンは、パワーAPIを通じてソフトウェアで入力されるモードです。 BR ハリー