NXPのMCXマイコンとSDKを使ったSPI通信の基本：SPIの4つのモードと実際の信号確認 (日本語ブログ) はじめに 前回は、SPI通信の 前編としてFRDMボード2台用いて、SPI通信のサンプルアプリケーションを動かしてみました。 NXPのMCXマイコンとSDKを使ったSPI通信の基本：2台接続での実機テスト (日本語ブログ) 今回は、４つのSPIモードの設定を変えながら、実際に送受信されるSPI信号を確認してみようと思います。本稿では、以下の[前編]記事の作業が完了していることを前提に進めます。 [前編] SPI通信のサンプルアプリケーションを動かしてみる。 [後編] SPIのモードを変えながら、実際のSPI信号を観測して、変化を見てみる。 (作業時間：20分) ※前編の内容（MCUXpresso for VSC, SDKがインストールされていて、SPIのアプリケーション動作確認）が済んでいる前提。 目次  準備するもの SPIモード CPOL, CPHAの設定確認 (サンプル・コードのどこで設定されている？) SPI信号を実際に確認 各SPIモードにおける信号の測定結果 おわりに １．準備するもの ハードウェア ・FRDM-MCXN947 (USBケーブル付属) x 2枚 ・ジャンパ線 : 複数本 ・ロジックアナライザー ※SPI信号解析用 ソフトウェア ・FRDM-MCXN947用のSDK 　＊MCX N947向けのSDK(ver. 26.3.0)をVSCodeにインストールした前提で説明していきます。 　　開発環境(MCUXpresso for VSC)の準備、SDKのインストール方法は、以下の記事をご参考ください。 　　記事：MCUXpresso for VSCとSDKのインストール (日本語ブログ)   ２．SPIモード 記事SPIバスの概要 (日本語ブログ)にて、CPOL = 0 or 1, CPHA = 0 or 1の組み合わせ、計4通りのモードがあると説明されています。 CPOL（Clock Polarity：クロックの極性）：通信していない「アイドル時(=非転送時)」に、クロック線（SCLK）がどちらの電圧レベルになっているかを設定。 CPOL=0 : アイドル時Low CPOL=1 : アイドル時High CPHA（Clock Phase：クロックの位相）：データ送信とラッチ(サンプリング)タイミングをクロックのエッジ（立ち上がり・立ち下がり）のどちらに合わせるかを設定。 CPHA=0 : 1回目のクロックエッジでデータをサンプリング、2回目でデータを出力 CPHA=1 : 1回目のクロックエッジでデータを出力、2回目でデータをサンプリング 表１　４つのモードとCPOL，CPHA   CPOL CPHA mode=0 0 0 mode=1 0 1 mode=2 1 0 mode=3 1 1   図１　CPOL，CPHAの設定による挙動   ３．CPOL, CPHAの設定確認 (サンプル・コードのどこで設定されている？) 先ずは波形を確認していく前に、前回SPI通信のサンプル・アプリケーションをデフォルトの状態でビルドして動かしてみました。デフォルト状態のCPOL、CPHAの設定を確認します。  CPOLとCPHAは、fsl_lspi.hの中で定義されています。  図２　CPOLとCPHAの定義(fsl_lspi.h) 次にSPIの初期化は、fsl_lpspi.c内のLPSPI_MasterGetDefaultConfig()内で実施されていました。 下図赤枠内で、コントローラ(マスタ)側のCPOL=0, CPHA=0が設定されていることが分かりました。また同じファイル内にデバイス(スレーブ)側の設定LPSPI_SlaveGetDefaultConfig()も含まれているので、CPOL、CPHAをマスタとスレーブの2カ所ともパラメータを変更しながらテストしていきます。 図３　マスタ側の設定箇所 LPSPI_MasterGetDefaultConfig()    図４　スレーブ側の設定箇所 LPSPI_SlaveGetDefaultConfig()   ４．SPI信号を実際に確認 それでは、「前回の記事」を参考に２つのFRDMボードとPCを接続させて、シリアル・モニターも２つ開いて、それぞれのサンプル・アプリケーションが動作していることを確認してください。 図５　シリアルモニターでのSPI通信結果 この状態で、２つのFRDMボードのSPIを結線します。 ※先に結線してからFRDMボードに電源を入れてしまうと、うまく動かないことがありますので、ご注意ください。 前回の記事と同じ内容ですが、FRDM-MCXN947の回路図を確認してみると、以下のJ2コネクタの#8がMOSI、#10がMISOであることが分かります。 図６　FRDM-MCXN947のSPI回路図 FRDM-MCXN947上のJ2コネクタ同士を以下のように、ジャンパ線で接続してください。 ※J2の#6ピンと#8ピンをクロスさせて接続してください。 表２　FRDM-MCXN947同士のSPI結線 LPSPI_master LPSPI_slave J2-14 : GND J2-14 : GND J2-12 : CLK J2-12 : CLK J2-6 : SOUT(MOSI) J2-8 : SIN(MISO) J2-8 : SIN(MISO) J2-6 : SOUT(MOSI) J2-6 : SS(PCS) J2-6 : SS(PCS) 通常ArduinoシールドソケットでSPIに使われるD10、D11、D12、D13に相当する端子です。 図７　SPI接続図  ※今回はこのMaster - Slave間の信号を確認するためにロジック・アナライザーを接続します。 ではロジック・アナライザが正しく動作しているか実際にSPI信号を送受信して確認してみます。 図８　SPIデータ送受信をシリアル・モニターで表示した結果   図９　SPIデータ送受信をロジック・アナライザーで表示した結果 　上図の文字が小さいのですが、Masterから見た際に、送信、受信共に正しく動作していることが確認できました。 　ここで送信部分(↑画像上半分)を見てみると、MOSI(Master Out Slave In)はデータがインクリメントされていくのに対して、MISO(Master In Slave Out)がずっと"High (=hFF)"であることが分かります。反対に受信部分(↑画像下半分)を見てみると、今度はMOSIが"High (=hFF)"固定で、MISOはデータがインクリメントされています。 これは正しい動きで、SPIバスの概要 (日本語ブログ)にも記載があるとおり、非データ転送時のMOSI，MISOの出力はハイ・インピーダンス状態におかれるためです。 それでは実際の信号を見ていきます。 ５．各SPIモードにおける信号の測定結果 ここからは３．CPOL, CPHAの設定確認 (サンプル・コードのどこで設定されている？)を参考にしながら、マスタ、スレーブ両方の「CPOL、CPHAの値を変更→ビルド→書き込み」を行い、測定を行いました。 SPIモード0：CPOL=0, CPHA=0のSPI信号 (デフォルト設定の状態) 図１０　CPOL=0, CPHA=0時のMasterからSlaveへのデータ送信波形 図１０を見るとクロック(CLK)はデータが転送される前(アイドル時)にLowとなっている(図中の橙枠)ので、POL=0であることが分かります。 また1回目のCLKの立ち上がりエッジでMOSIのデータをラッチ(図中の赤線)しており、2回目のCLKの立ち下がりエッジでMOSIのデータを変化(図中の緑線)させているので、CPHA=0であることが分かります。 SPIモード1：CPOL=0, CPHA=1のSPI信号 図１１　CPOL=0, CPHA=1時のMasterからSlaveへのデータ送信波形 図１１を見るとCLKはデータが転送される前(アイドル時)にLowとなっている(図中の橙枠)ので、POL=0であることが分かります。 今度は、1回目のCLKの立ち上がりエッジでMOSIのデータを変化(図中の緑線)させており、2回目のCLKの立ち下がりエッジでMOSIのデータをラッチ(図中の赤線)しているので、CPHA=1であることが分かります。 SPIモード2：CPOL=1, CPHA=0のSPI信号 図１２　CPOL=1, CPHA=0時のMasterからSlaveへのデータ送信波形 図１２を見るとCLKはデータが転送される前(アイドル時)にHighとなっている(図中の橙枠)ので、POL=1であることが分かります。 また1回目のCLKの立ち下がりエッジでMOSIのデータをラッチ(図中の赤線)させており、2回目のCLKの立ち上がりエッジでMOSIのデータを変化(図中の緑線)しているので、CPHA=0であることが分かります。 ※クロックの極性が変わっているので、1回目と2回目のクロックが混同しないように。 SPIモード3：CPOL=1, CPHA=1のSPI信号  図１３　CPOL=1, CPHA=1時のMasterからSlaveへのデータ送信波形 図１３を見るとCLKはデータが転送される前(アイドル時)にHighとなっている(図中の橙枠)ので、POL=1であることが分かります。 また1回目のCLKの立ち下がりエッジでMOSIのデータを変化(図中の緑線)させており、2回目のCLKの立ち上がりエッジでMOSIのデータをラッチ(図中の赤線)しているので、CPHA=1であることが分かります。 あらためて今回の測定結果をまとめると以下(表３)のようになりました。 表３　４つのモードとCPOL、CPHAの関係まとめ SPIモード CPOL CPHA アイドル時のCLK 1回目のCLK 2回目のCLK mode=0 0 0 Low 立ち上がりエッジでデータをラッチ 立ち下がりエッジでデータを変化 mode=1 0 1 Low 立ち上がりエッジでデータを変化 立ち下がりエッジでデータをラッチ mode=2 1 0 High 立ち下がりエッジでデータをラッチ 立ち上がりエッジでデータをラッチ mode=3 1 1 High 立ち下がりエッジでデータを変化 立ち上がりエッジでデータをラッチ ６．おわりに 実際にSPIモードを4通り、CPOLとCPHAを変えながら信号の測定をしてみました。自分で測定しながら、極性と位相が変わると混乱しましたが、期待通りの動作を確認できました。基礎を学ぶ際には、プログラムを変えてビルドして動いたことを確認するだけでなく、実際に信号を見てみると理解が進むかもしれません。是非、みなさんも試してみてください。 参考情報 (前編) NXPのMCXマイコンとSDKを使ったSPI通信の基本：2台接続での実機テスト (日本語ブログ) NXPのインターフェース製品 ～まとめページ～ (日本語ブログ) SPIバスの概要 (日本語ブログ) NXP システム・マネジメントI²C, I3C, SPIセレクタ・ガイド =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） 前回は、SPI通信の 前編としてFRDMボード2台用いて、SPI通信のサンプルアプリケーションを動かしてみました。 NXPのMCXマイコンとSDKを使ったSPI通信の基本：2台接続での実機テスト (日本語ブログ) 今回は、４つのSPIモードの設定を変えながら、実際に送受信されるSPI信号を確認してみようと思います。本稿では、以下の[前編]記事の作業が完了していることを前提に進めます。 [前編] SPI通信のサンプルアプリケーションを動かしてみる。 [後編] SPIのモードを変えながら、実際のSPI信号を観測して、変化を見てみる。 (作業時間：20分) ※前編の内容（MCUXpresso for VSC, SDKがインストールされていて、SPIのアプリケーション動作確認）が済んでいる前提。 Interface MCUXpresso MCUXpresso SDK MCX 日本語ブログ

智能设备网关 智能设备网关 在这篇文章中，我想简要介绍 智能设备网关 ，这是一款基于Fastapi的演示服务器，允许联网设备使用由Ara240 DNPU加速的本地GenAI功能。 该演示背后的想法是将人工智能集中在一个网关中，而不是向每台设备添加强大的人工智能硬件。连接的设备只需要麦克风、扬声器和网络连接即可成为支持语音的助手。   它的作用 智能设备网关使设备或嵌入式客户端等设备能够将音频发送到本地服务器，使用语音识别、RAG、在 Ara240 DNPU 上运行的 LLM 和文本转语音处理请求，然后将语音响应流回客户端。 当前的演示展示了通用烤箱和咖啡机/咖啡师用例的智能设备助手，使用设备手册作为上下文响应的知识库。   建筑概览 智能设备网关通过 WebSocket 接收来自客户端的音频，将语音转换为文本，从设备知识库检索相关上下文，通过 eIQ AAF 连接器将提示发送到 LLM，将生成的响应转换回语音，并将音频响应流式传输到客户端。 高层次的流程是 Audio Input → STT → RAG → eIQ AAF Connector / LLM → TTS → Audio Output LLM 在 Ara240 DNPU 上运行，而服务器则在 FRDM i.MX 平台上运行。   基本服务器安装 在板上安装 Debian 软件包： dpkg -i smart-device-gateway_1.0.0_all.deb 启动服务器： run_server_only --host 0.0.0.0 --port 8080 服务器预计eIQ AAF 连接器已在 0.0.0.0:8000 上运行，并已安装 Qwen2.5-7B-Instruct正确配置。 或者，演示程序可以与连接器一起启动服务器： run_server --host 0.0.0.0 --port 8080   主机 PC 客户端示例 该演示包括一个可在主机上运行的 push_to_talk 客户端。复制 push_to_talk 文件夹后，运行： python -m uv run push_to_talk.py --server_ip --port --device oven 您还可以使用 python -m uv run push_to_talk.py --server_ip --port --device barista 如果未提供设备名称，则不使用 RAG 知识库，响应由 LLM 的常识生成。   演示视频 在随附的视频中，我展示了如何启动智能设备网关服务器、连接客户端、选择烤箱或咖啡师等设备配置文件、提出语音问题以及接收使用Ara240 DNPU加速在本地生成的语音响应。 (function() { var wrapper = document.getElementById('lia-vid-6396695931112w960h540r659'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (在我的视频中查看）   摘要 智能设备网关演示了日常设备如何通过连接到本地 AI 网关成为支持语音的助手。该演示将Ara240 DNPU上的STT、RAG、LLM推断与TTS相结合，为在恩智浦i.MX平台上构建以隐私为中心的本地GenAI体验提供了实用参考。   链接 智能设备网关存储库 ARA2-M2-16G-GT ARA240 实践培训

PN76xx - ULPCD チェックリスト ES_PN7642およびAN15028に記載されているように、ICは超低消費電力カード検出（ULPCD）中にまれに応答しない状態になることがあります。 ICがこの状態に入った疑いがある場合、NXPはそれを検証・確認するためのチェックリストを提供しています。添付ファイルにあるチェックリストを参照してください。 NFCコントローラ・ソリューション

FOCベースのモータ制御システムにおける機能安全 オートモーティブやインダストリアルシステム向けのモータ制御を開発する際、機能安全は、モーターが意図しないトルクや速度を発生させないことを保証するための重要な要件です。 しかし、フィールド指向制御（FOC）のような複雑なアルゴリズムを機能的に安全なコンポーネントとして実装すると、アーキテクチャが著しく複雑化し、開発工数が大幅に増加し、全体的なパフォーマンスが低下します。 この問題を解決するために、NXPはセーフティ分解アプローチを採用しています。これにより、アプリケーションは安全関連以外の部分（QM）と安全関連の部分（ASIL）に分割されます。この枠組みの中で、NXPはASCLIB (オートモーティブ セーフティ チェッカーライブラリ）を提供しています。セーフティ部分向けのすぐに使えるセーフティチェッカーを提供することで、QMモータ制御部分を再設計することなく、高いセーフティ基準への準拠を実現できます。 完璧な組み合わせ：AMMCLIB（QM）＋ASCLIB（ASIL） ほとんどのお客様は、コアとなるMC処理に、高度に最適化されたNXP AMMCLIB（オートモーティブ数学およびモータ制御ライブラリ）を利用しています。AMMCLIBは優れたパフォーマンスを発揮するものの、品質管理（QM）レベルのライブラリである。 ISO 26262などの安全規格に準拠するためには、チームはQMレベルのAMMCLIBを中心に独自の安全機構を構築する必要があり、多大な時間と労力がかかった。このプロセスを効率化するため、NXPは標準化された、すぐに実用化可能なソリューションとしてASCLIBを提供しています。包括的な事前検証済み安全チェックツールを提供することで、独自の安全ソフトウェア開発の必要性を大幅に削減し、設計から認証までのサイクルを加速します。 AMMCLIBとASCLIBの連携方法 この概念が実際にどのように適用されるかを説明するために、以下のブロック図は標準的なフィールド指向制御（FOC）システムの例を示しています。このシナリオでは、モーター制御ブロックは既存のQMレベルのAMMCLIBコード上で動作し、ASCLIB安全チェッカーが重要なポイントを監視して安全性を確保します。このアーキテクチャは、FOC PMSM向けのIEEE低複雑度セーフティコンセプトに基づいています。   このリファレンスアーキテクチャは、ASCLIBを統合する際に、既存のQMモータ制御アーキテクチャに変更を加える必要がないことを示しています。完全なデータ型互換性により、ASCLIBチェッカーはAMMCLIB信号に直接マッピングできるため、シームレスな相互接続が保証されます。 標準的なFOCは一般的な使用例ですが、ASCLIBはそれに限定されるものではありません。モジュール式で独立したブロックのおかげで、このライブラリは、センサーレスFOCやシングルシャント電流測定など、代替トポロジーや高度な技術をサポートしています。 ASCLIBの内部構造：階層型セーフティアーキテクチャ ASCLIBは、階層的にレイヤーとパッケージに整理された、高度に構造化された階層型ソフトウェアモデルを特徴としています。 サービス層（最上位層） 2つの独立したパッケージを通じて、高度な機能を安全アプリケーションに直接公開します。 高レベルチェッカー（HLC）：さまざまなモータ制御システム向けにカスタマイズされた、幅広いアプリケーションのセーフティチェッカー。 障害マネージャ（FMG）：エラーの同期、構成、およびアプリケーション通知を管理する高度な障害処理コンポーネント。 コア層（基礎層） サービス層で使用される低レベルの構成要素を提供します。これは2つの重要なパッケージで構成されています。 低レベルチェッカー（LLC）：基本的な数学的機能と認証機能を提供します。 フォールトデバウンス（FDB）：汎用的なフォールトデバウンスアルゴリズムを提供します。 開発者向けヒント：ライブラリ全体は完全にモジュール化され、分離されており、独立しています。アプリケーションに独自のチェッカーが必要な場合は、LLCおよびFDBパッケージ内の既存の低レベルブロックを使用して、独自のカスタムチェッカーを簡単に構築できます。さらに、障害マネジメント（FMG）パッケージは完全にオプションであり、使用を強制されることはなく、代わりに独自のアプリケーションレベルのエラー処理を実装することも可能です。   オートモーティブに限らない 名前に惑わされないでください。ASCLIBは名称に「オートモーティブ」という言葉を含み、 ISO 26262ワークフローをネイティブにサポートし、そのセーフティ原則は普遍的なものです。ASCLIBは、IEC 61508に準拠したインダストリアルシステムに最適です。 既存の開発ワークフローにシームレスに統合できるよう、ASCLIBは2種類の配信オプションを提供しています。 純粋なC言語ソースファイル：ベアメタルまたはRTOSベースの組み込みプロジェクトに直接統合できます。 BAM（ビット精度モデル）：モデルベース設計（MBD）用のすぐに使えるブロックで、セーフティアーキテクチャをMATLAB/Simulinkに直接ドラッグ＆ドロップしてシミュレーションできます。 開発者にとっての主なメリット AMMCLIBは引き続きQM用です。コアMCには、既存の高度に最適化されたAMMCLIBコードを引き続き使用してください。 モデルベース開発：専用のASCLIB BAMを使用してMATLAB/Simulink内でセーフティ部品全体を構築およびシミュレーションしてからターゲットCコードを生成することで、設計サイクルを加速します。 認証手続きの迅速化：事前に設計されたセーフティブロックと統合された障害マネジメント機能により、セーフティ基準への準拠と監査プロセスが大幅に簡素化されます。 さあ、始めて、あなたの考えを共有しましょう ASCLIBは完全にMCUに依存しないように設計されているため、さまざまなハードウェアプラットフォームに柔軟に展開できます。開発を加速させるため、本製品は既に完全な検証済みであり、NXPのオートモーティブおよびインダストリアルMCUとの統合に対応しています。制御と安全性を分離することで、最高のモーター性能と妥協のない安全性という、両方の利点を享受できます。 近々、ISO 26262またはIEC 61508規格に準拠したモーター制御プロジェクトに取り組んでいますか？AMMCLIB + ASCLIB アプローチが設計をどのように簡素化できるかについて、コメント欄で議論しましょう。または、以下のフォームからフィードバックをお寄せください。[フォームへのリンク] 機能的に安全なモーター制御システムを構築することは、性能を犠牲にしたり、アーキテクチャを再設計したりすることを意味するものではありません。NXPがAMMCLIBとASCLIBを組み合わせることで、セーフティと制御を分離し、開発労力を削減し、認証を迅速化する方法を、効率性を損なうことなくご紹介します。 モータ制御 導入

在 128 个总线时钟内配置 WDOG 说明 根据我对参考手册中以下内容的理解，我遇到了意外的 WDOG 行为： " 在 128 个总线时钟内 重置后，所有监视程序控制位、超时值和窗口值都只写入一次。这意味着，写入完成后，除非进行RESET ，否则无法对其进行更改。" 我对此的初步解释是，你必须在 RESET 后的前 128 个总线时钟内配置 WDOG，否则它将使用 UPDATE=0 的默认配置。这将防止您再次重新配置 WDOG。 然而，我却遇到了不同的情况。由于退出 RESET 的 KE1 以相同的频率运行总线和内核时钟，因此我决定在重新配置 WDOG 时查看 IAR 调试器中的 CYCLECOUNTER，因为我认为它能告诉我自 RESET 以来还经过了多少总线时钟。它显示自RESET释放以来已经过去了144个周期。于是，我开始在函数的起始位置添加越来越长的延迟循环，看看它是否还能让我在 144 个循环之后继续重新配置。 无论延迟时间有多长，只要低于 WDOG 默认的 8 毫秒超时时间，就能成功重新配置 WDOG。我在使用调试器和不使用调试器的情况下都观察到了这种行为，以确保调试器没有起到任何作用。我还能够通过使用Oscope闪烁RESET来确认计时。 因此，现在我对参考手册的理解是，RESET后，您可以重新配置 WDOG。而且，一旦您对 WDOG 执行了第一次写入，您将获得 128 个总线时钟来重新配置剩余的寄存器字段。 例如，假设我在重置时等待 1000 个总线时钟，然后配置 WDOG_CS 寄存器。在配置 WDOG_CS 来配置 WDOG_TOVAL 之后，我得到了 128 个总线时钟。TOVAL 配置完成后，新配置即生效。 这是对参考手册的正确解释吗？或者我之前的解释是否正确，你在 RESET 时获得 128 个总线时钟，或者默认配置生效？ Re: Configure WDOG within 128 Bus Clocks Clarification 你好@sean_dvorscak、 谢谢你的帖子。 请参阅"第 30.4.3.2.1 节 解锁看门狗" 和第30 .5.2 节 配置看门狗 在KE1xFP100M168SF0RM 中。 "30.5.2 在 KE1xFP100M168SF0RM 中配置看门狗" 。 正确的解释似乎如下： 重置后，WDOG 处于启用状态，并使用其重置默认设置运行。 WDOG 配置寄存器仍可用于初始配置序列。 监视程序解锁后，其余配置寄存器必须在 128 个总线时钟内写入。 如果 UPDATE=0，则在该初始配置完成后，在下次 RESET 之前，无法再次更改 WDOG 配置。 如果 UPDATE=1，则可以解锁并稍后重新配置 WDOG，每次解锁后将应用相同的 128 总线时钟窗口。 这种解释与您的测量结果一致：即使自RESET以来经过了超过 128 个总线时钟，WDOG 仍可以成功重新配置，前提是这种情况发生在默认监视程序超时到期之前。 换句话说，128 总线时钟配置窗口与解锁顺序相关，而不仅仅是自RESET释放以来经过的时间。 如果未完成任何新配置，WDOG 将继续使用其重置默认设置运行。 希望对您有所帮助。 BR 西莱斯特 ------------------------------------------------------------------------------------------------------------------------ 注：如果本帖回答了您的问题，请点击"ACCEPT AS SOLUTION" 按钮。Thank you! ------------------------------------------------------------------------------------------------------------------------ Re: Configure WDOG within 128 Bus Clocks Clarification 更新看门狗设置需要遵循一定的命令顺序。我不知道 128 个总线时钟来自哪里，但以 K80 子系列参考手册，2015 年 9 月 4 日修订版为例： 只要在监视程序控制寄存器中设置了 ALLOW_UPDATE，您就可以解锁和修改一次只写控制和配置寄存器： 1. 在 20 个总线时钟周期内将 0xC520 然后写入 0xD928 到特定的解锁寄存器 (WDOG_UNLOCK)。 2。等待一个总线时钟周期。在写入解锁序列之后，您无法在总线时钟周期内立即更新寄存器。 3.打开一个与看门狗配置时间（WCT）等长的更新窗口。在该窗口中，您可以更新配置和控制寄存器位。 这些寄存器位在解锁后只能修改一次。如果在更新窗口内没有更新任何配置和控制寄存器，监视程序会向系统发出RESET，即中断然后RESET。初始解锁后，尝试在 WCT 内解锁看门狗不会有任何效果。 Re: Configure WDOG within 128 Bus Clocks Clarification 谢谢你的澄清。 很高兴得知我有超过 128 个总线时钟脱离 RESET，无法配置 WDOG。 如果他们对 ke1xfp100m168sf0rm 进行了新的修订，我想建议在 128 个总线时钟内删除 "..."自第 30.4.3.1 节第一句。 感谢这个建议可能很愚蠢，但我之所以这样做，只是因为我在网上发现了一些错误信息，引用了这个措辞，暗示你只有 128 个总线时钟来配置 WDOG 而不 RESET。不幸的是，它还会让谷歌人工智能概述重复同样的错误信息（......不得不爱未来）。 🙂 ).因此，我不得不在这里亲自提问。 Re: Configure WDOG within 128 Bus Clocks Clarification 明白。不幸的是，据我所知，Kinetis系列没有新的路线图。我们最近推出了MCX系列，如果你感兴趣，可以考虑探索这个系列。MCX Arm Cortex-M 工业和物联网微控制器 | 恩智浦半导体

通过以太网在 S32Z280-594EVB 上闪烁应用程序 您好，NXP团队， 我正在使用 S32Z280-594EVB 评估板，想知道是否有可能通过以太网接口对应用程序二进制进行闪存/编程，而不是使用调试器 (J-Link /P & E)。 如果支持基于以太网的闪烁： 有哪些可用的方法来实现这一目标？ 是否有支持以太网编程的引导加载程序或固件更新机制？ 是否有任何示例项目、应用笔记或参考文档？ 主机需要哪些工具和软件？ 能否请您指导我通过以太网对 S32Z280 进行编程的推荐方法？ 感谢您的支持。 致以最崇高的敬意 Karthik Re: Flashing Application via Ethernet on S32Z280-594EVB 你好，@karthik_nikil 谢谢你的帖子。 通过查看最新的 GreenVIP，似乎未实现/支持通过以太网将映像编程到闪存，因此没有相关示例可供直接参考。 很抱歉给您带来不便。 BR 切宁

S32K3 bricked, unable to debug Hi, I've been trying to use AB_SWAP firmware for bootloading. I've not progressed the lifecycle or anything like that, and secure boot is not enabled. I am flashing one bank, and then performing an active bank switch using HSE. I was experiencing compounding reset reasons Bit 0 (0x0001): Power On Reset Bit 8 (0x0100): FXOSC Failure Bit 15 (0x8000): System Clock Divider Failure  After experimenting with switching the clock to FIRC before the bank switch reset call, I have not been able to access my MCU with JLink. I've tried connect under reset, running in a loop and power cycling etc. Is there any boot configuration via pins I can use to keep it in a known state, or factory reset tools to recover this? Type "connect" to establish a target connection, '?' for help J-Link>connect Please specify device / core. : S32K358_M7_0 Type '?' for selection dialog Device> Please specify target interface: J) JTAG (Default) S) SWD T) cJTAG TIF>s Specify target interface speed [kHz]. : 4000 kHz Speed> Device "S32K358_M7_0" selected. Connecting to target via SWD ConfigTargetSettings() start ConfigTargetSettings() end - Took 27us InitTarget() start SDA_AP detected Unlocking device if necessary... Device is not locked. Proceeding without the unlock procedure. Checking if debug access is already enabled... Debug access is not enabled yet. Performing enable debug access sequence... Debug access enabled Checking if HSE firmware is installed... HSE firmware not installed Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode Lock step mode enabled InitTarget() end - Took 10.0ms Found SW-DP with ID 0x6BA02477 DPIDR: 0x6BA02477 CoreSight SoC-400 or earlier AP map detection skipped. Manually configured AP map found. AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000) AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user AP[4]: Core found ConfigTargetSettings() start ConfigTargetSettings() end - Took 13us InitTarget() start SDA_AP detected Unlocking device if necessary... Device is not locked. Proceeding without the unlock procedure. Checking if debug access is already enabled... Debug access is not enabled yet. Performing enable debug access sequence... Debug access enabled Checking if HSE firmware is installed... HSE firmware not installed Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode Lock step mode enabled InitTarget() end - Took 20.5ms Found SW-DP with ID 0x6BA02477 DPIDR: 0x6BA02477 CoreSight SoC-400 or earlier AP map detection skipped. Manually configured AP map found. AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000) AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user AP[4]: Core found ****** Error: DAP error while reading AIRCR. Error occurred: Could not connect to the target device. For troubleshooting steps visit: https://kb.segger.com/J-Link_Troubleshooting J-Link> Re: S32K3 bricked, unable to debug I got new information from my colleague. If you meet this problem again, try following commands: r0 erase Do not use 'connect' before that. After 'erase' command, it will ask you to establish the connection. And then it will erase the flash and while no code is executed.  If it does not work, you can try to use JTAG mode instead of SWD. It looks like this can also make a difference.  Regards, Lukas Re: S32K3 bricked, unable to debug After 6 hours of leaving the board with the oscilloscope connected, I noticed the reset pattern had stopped. I was able to connect and erase the board. I'll continue with my development cautiously. A theory is that the code I added to switch HSE partition included a clock switch, from FXOSC + PLL to FIRC to resolve some reset issues. I guess not gracefully closing the GMAC peripheral that was using the PLL, or not waiting for it to complete shutdown was causing instability that was then exacerbated during clock init entering some kind of reset cycle. Re: S32K3 bricked, unable to debug To clarify. A 50us reset pulse is being asserted every 30ms, with or without the JLink connected Re: S32K3 bricked, unable to debug Hi Lukas, I scoped it out. Reset seems to be flickering intermittently without any JLink operation. It holds high during the connect, and then resets as part of the normal connection procedure. I tried with the Reset pin strongly pulled high to avoid any issues there but still I get the exact same issue Re: S32K3 bricked, unable to debug Hi @Greavesinator85  No, there are not boot configuration pins on this device. I know that this could be a workaround on some other devices but that’s not the case of S32K3. It always boots from internal flash memory only. Could you check the reset signal? Isn’t the reset asserted all the time? I was playing with JLink on my board and I got exactly the same error message when I kept the reset asserted during ‘connect’ command execution. Regards, Lukas Re: S32K3 bricked, unable to debug It's a custom board, but I have been using it for a few months so its not a hardware issue. Then its a J-Trace connected with SWD. Re: S32K3 bricked, unable to debug Could not connect to the target device.? What kind of board you are using for programming?

RPI-CAM-MINISAS用ファームウェアファイル RPI-CAM-MINISASボードを動作させようとしています。ap1302ドライバは、ファームウェアファイルap1302_ar0144_single_fw.binを要求します。 このページhttps://docs.nxp.com/bundle/RM00293/page/topics/ar0144.html州 ap1302_ar0144_single_fw.binという名前のファームウェアが必要です。/lib/firmwareフォルダに配置してください。 しかし、そのファイルの入手先については何も記載されていない。 OnSemiのGitHubリポジトリ（ https://github.com/ONSemiconductor/ap1302_binaries/tree/main ）で探してみました。 そのリポジトリには、このファイル名と完全に一致するファイルは存在しません。私が見つけた中で最も近いのは、 https://github.com/ONSemiconductor/ap1302_binaries/blob/main/NXP_i.MX93/ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin です。 しかし、このファームウェアファイルは動作しません。ドライバーはファイルを読み込んだようですが、その後dmesgに以下が表示されます。 [ 11.201244] ap1302 1-003c: __ap1302_read: レジスタ 0x0000 の読み取りに失敗しました: -6 Re: Firmware File for RPI-CAM-MINISAS こんにちは、 @rudolf_streif さん。 先ほどご提供いただいたログに基づくと、I2C通信に問題があるようです。このログが出力される前に、ファームウェアは既にロードされていたのでしょうか？そうでない場合は、AP1302のリセットピンとイネーブルピン（R82 → RST、TP1 → イネーブル）のGPIOステータスを確認する必要があると思います。 よろしくお願いします、 志明 Re: Firmware File for RPI-CAM-MINISAS ファームウェアファイルの確認をしていただき、 @Zhiming_Liu さん、ありがとうございます。 私はRPI-CAM-MINISASアダプタとAP1302/AR0144モジュールを組み合わせて使用しています。アダプタのLEDとカメラモジュールの赤色LEDが点灯していることから、FPCケーブルは正しく接続されています。 現在、私はimx93 evkではなくimx8mp evkを使用しています。NXPはこの組み合わせを公式にはサポートしていないという情報をどこかで見つけました。I2Cが動作するように、デバイスツリーを作成しました。しかし、24MHzクロックが正しく動作していない可能性もあります。私の理解では、カメラモジュールはI2C通信のために内部クロックで動作し、ファームウェアのダウンロード後に外部クロックに切り替わるようです。 もしかしたら、あなたはもっと深い洞察をお持ちかもしれませんね。 Re: Firmware File for RPI-CAM-MINISAS こんにちは、 このリンクは正しいファームウェアのリンクです。L6.18.2でテストしたところ、正常に動作しました。 root@imx93evk:~# dmesg | grep ap1302 [ 0.350765] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.391204] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c [ 0.486760] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.518939] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.560106] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c [ 0.572201] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.591913] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c [ 2.783982] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c [ 2.795274] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 9.648423] ap1302 2-003c: AP1302 revision 0.2.6 detected ハードウェアの接続を確認してください。 よろしくお願いします、 志明 Re: Firmware File for RPI-CAM-MINISAS これは、以下のNXPレイヤーを使用したカスタムYocto Projectビルドです。 meta-freescale = "master:4cc4bc05063f7f4c105587332493742379d11ad7" meta-freescale-3rdparty = "master:29c36ae80ba5762091f48d6d15b637455cc15758" meta-freescale-distro = "master:70b7591ecaa99cb6366f93ee05df7c38d94d724b" 基本的にはYPウィンラッター/ライノーズと同じだ。 ファームウェアはfirmware-imxの一部だと思っていたのですが（バージョンは8.28）、そうではありませんでした。 Re: Firmware File for RPI-CAM-MINISAS こんにちは、 @rudolf_streif さん。 使用しているBSPのバージョンを教えていただけますか？ よろしくお願いします、 志明

UJA1169 驱动程序代码 各位你好， 我需要可以通过 SPI 总线配置的 UJA1169ATK SBC 的示例驱动程序代码。 在产品页面上，有 AUTOSAR 驱动程序可用，但我们正在使用 NON_AUTOSAR 方法进行开发。 请分享这方面的示例项目。 谨致问候， Mohit Re: UJA1169 driver code 点击申请额外访问权限，然后上传 NDA 等待批准。 Re: UJA1169 driver code 你好， ，我有 NDA 权利，但没有显示。它要求添加权限，但按钮不起作用。 我试了好几次，都没有成功。 帮助我们更快地解决问题。 BR, Mohit Re: UJA1169 driver code 嗨 UJA1169ATK 迷你高速 CAN SBC |恩智浦半导体 您可以从上述链接下载。 谢谢！ BR

使用 SE050 时如何启用平台 SCP 大家好 我使用的是 SE050E，在使用 Platform SCP 时遇到了麻烦。我按照 AN12542(https://www.nxp.jp/docs/en/application-note/AN12542.pdf#4#4) 中的说明定义了 SSS_HAVE_SE05X_AUTH_PLATFSCP03 1，但当我调用 ex_sss_boot_open 函数打开会话时，结果却是 kStatus_SSS_Fail。我做错什么了吗？使用普通通信时，一切正常。如果还需要其他配置，请告诉我。 谢谢！ SE050 Re: How to enable Platform SCP when using SE050 你好@Kan_Li、 我按照第 6.2 和 6.3 节中的说明，尝试运行 SE-PLUG-TRUST-MW_04.07.01 中的 se05x_MandatePlatformSCP 示例，但 sss_key_object_init(eraseAuthCtx.auth.ctx.idobj.pObj、&pCtx->host_ks) 函数返回 kStatus_SSS_InvalidArgument。我需要调用 ex_sss_boot_open、ex_sss_key_store_and_object_init 和ex_sss_boot_open_host_session函数吗？调用sss_key_object_init函数之前先调用sss_key_object_init文件吗？代码如下： /* 关闭 clang-format */ #define MandateSCP_UserID_VALUE \ { \ n'、'e'、'e'、'd'、's'、'c'、'p    } /* clang-format ON */ sss_status_t se050_platformSCP03(void) { sss_status_t status = kStatus_SSS_Fail； sss_object_t keyObject； ex_sss_boot_ctx_t gex_sss_mandate_scp_boot_ctx； SE_Connect_Ctx_t eraseAuthCtx = { 0 }； sss_se05x_session_t *pSession = (sss_se05x_session_t *)&gex_sss_mandate_scp_boot_ctx.session； smStatus_t sw_status； Se05xSession_t *pSe05xSession； SE_Connect_Ctx_t* pOpenCtx； sss_object_t ex_id ={ 0 } ；   const uint8_t host_userid_value[] = MandateSCP_UserID_VALUE； const uint8_t userid_value_factoryreset[] = MandateSCP_UserID_VALUE； eraseAuthCtx.auth.ctx.idobj.pObj =&ex_id；   const char *portName = NULL；   memset(&gex_sss_mandate_scp_boot_ctx, 0, sizeof(gex_sss_mandate_scp_boot_ctx))；   //* 初始化会话以连接 SE050 */ // status = ex_sss_boot_open(&gex_sss_mandate_scp_boot_ctx, portName)； // 如果 (kStatus_SSS_Success != status) // { // ex_sss_session_close(&gex_sss_mandate_scp_boot_ctx)； // return status; /* return error if can't initialize session with SE050 */ // }   // ** 设置密钥存储 */ // status = ex_sss_key_store_and_object_init(&gex_sss_mandate_scp_boot_ctx)； // 如果 (kStatus_SSS_Success != status) // { // ex_sss_session_close(&gex_sss_mandate_scp_boot_ctx)； // return status; /* close sesion and return error if can't initialize fail */ // }   // ex_sss_boot_open_host_session(&gex_sss_mandate_scp_boot_ctx)； /* 准备主机 */ status = sss_key_object_init(eraseAuthCtx.auth.ctx.idobj.pObj.php)、&gex_sss_mandate_scp_boot_ctx.host_ks）； 如果 (kStatus_SSS_Success != status) { LOG_E("失败的 sss_key_object_init")； 去清理；    } status = sss_key_object_allocate_handle(eraseAuthCtx.auth.ctx.idobj.pObj.php)、 make_test_id(__LINE__)、 kSSS_KeyPart_Default、 kSSS_CipherType_UserID、 sizeof(host_userid_value)、 kKeyObject_Mode_Transient）； 如果 (kStatus_SSS_Success != status) { LOG_E("失败的 sss_key_object_allocate_handle")； 去清理；    } status = sss_key_store_set_key(&gex_sss_mandate_scp_boot_ctx.host_ks、 eraseAuthCtx.auth.ctx.idobj.pObj、 host_userid_value、 sizeof(host_userid_value)、 sizeof(host_userid_value) * 8、 NULL、 0); 如果 (kStatus_SSS_Success != status) { LOG_E("失败的 sss_key_store_set_key")； 去清理；    }   pSe05xSession =&pSession->s_ctx；   sw_status = Se05x_API_WriteUserID（pSe05xSession、 NULL、 SE05x_MaxAttemps_NA、 kSE05x_AppletResID_PLATFORM_SCP、 userid_value_factoryreset、 sizeof(userid_value_factoryreset)、 kSE05x_AttestationType_AUTH）；   pOpenCtx =&gex_sss_mandate_scp_boot_ctx.se05x_open_ctx； eraseAuthCtx.tunnelCtx = pOpenCtx->tunnelCtx； eraseAuthCtx.connType = pOpenCtx->connType； eraseAuthCtx.portName = pOpenCtx->portName； eraseAuthCtx.auth.authType = kSSS_AuthType_ID；     sss_session_close(&gex_sss_mandate_scp_boot_ctx.session)；   pSe05xSession =&pSession->s_ctx；   status = sss_session_open(&gex_sss_mandate_scp_boot_ctx.session、kType_SSS_SE_SE05x、 kSE05x_AppletResID_PLATFORM_SCP、 kSSS_ConnectionType_Password,&eraseAuthCtx)；     如果 (kStatus_SSS_Success != status) { LOG_E("失败的 sss_session_open")； 去清理；    }     /* 调用 SE05X API 授权平台 SCP。*/   sw_status = Se05x_API_SetPlatformSCPRequest(&pSession->s_ctx, kSE05x_PlatformSCPRequest_REQUIRED)； if(SM_OK != sw_status) { LOG_E("Se05x_API_SetPlatformSCPRequest 失败")； 去清理；    } 否则 { LOG_I("Se05x_API_SetPlatformSCPRequest Successful")； LOG_W("进一步通信必须加密")；    }   清理： 如果 (kStatus_SSS_Success == status) { LOG_I("se05x_MandatePlatformSCP Example Success !!!...")；    } 否则 { LOG_E("se05x_MandatePlatformSCP Example Failed !!!...")；    } 返回状态； }   谢谢！ Duong Re: How to enable Platform SCP when using SE050 你好@yang_lee、 第 6 章中提供的示例仅适用于 SE050E，但首先请确定您使用的是哪个编译系统。 1.如果使用 MCUXpresso SDK，请按照 6.2 和 6.3 中的步骤操作 2.如果使用 Cmake，请按照 6.4 和 6.5 中的步骤操作 希望对你有所帮助、 祝您愉快， Kan ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"标记正确" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题，并参考已关闭的主题。 -------------------------------------------------------------------------------

i.MX 8M Plus PCIe Endpoint DMA Test Failed (Failed to prepare DMA memcpy + SDMA Timeout) 各位 NXP 工程师和社区朋友， 我正在使用两块8MP开发板进行 PCIe Endpoint 测试（一块做 RC，一块做 EP）。链路可以正常 Link Up，但 DMA 传输失败。 环境信息： 开发板：8mp BSP 版本：linux 6.1.36 PCIe 配置：RC <-> EP 交叉线缆连接 问题现象： lspci 能正常看到 EP 设备（1131:0000） 中断测试正常 但执行 pcitest -d -w -s 4096000 等 DMA 测试时失败 EP 端出现以下错误： Failed to get private DMA rx channel... imx-sdma Timeout waiting for CH0 ready Failed to prepare DMA memcpy 求助问题： 如何正确启用 i.MX8MP PCIe 的 DMA 通道？ 使用 pci_epf_test 做 DMA 测试需要哪些关键配置或额外 patch？ AN13164 中提到的较高 DMA 带宽如何稳定复现？ 非常感谢大家的帮助！ Dear NXP Engineers and Community, I am using two i.MX 8M Plus development boards to test PCIe Endpoint functionality (one as RC, one as EP). The PCIe link comes up successfully, but DMA transfers are failing. Environment Information: Board: i.MX 8M Plus  BSP Version: Linux 6.1.36 PCIe Configuration: RC ↔ EP connected via crossover cable Problem Description: lspci can detect the EP device correctly (1131:0000) Interrupt test (pcitest -i 1) works fine DMA Write/Read tests fail when using larger sizes (e.g. pcitest -d -w -s 4096000) The following errors appear on the EP side: log   Failed to get private DMA rx channel. Falling back to generic one imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready pci_epf_test pci_epf_test.0: Failed to prepare DMA memcpy pci_epf_test pci_epf_test.0: Data transfer failed     Questions: How to correctly enable and use the DMA channel (especially Embedded DMA / eDMA) for PCIe Endpoint on i.MX 8M Plus? What key configurations or additional patches are required to make pci_epf_test DMA testing work stably? How can we stably reproduce the high DMA bandwidth results mentioned in AN13164? Any help or suggestions would be greatly appreciated! Thank you very much! i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano i.MX8ULP Re: i.MX 8M Plus PCIe Endpoint DMA Test Failed (Failed to prepare DMA memcpy + SDMA Timeout) 亲爱的 Zhiming, 非常感谢你的支持和通过私信发来的材料。 我明天将测试您提供的文件和补丁，并尽快向您通报测试结果。 Best Regards, forlove 您好 Zhiming， 非常感谢您的支持以及通过私信发送的资料。 我将在明天对您提供的文档和补丁进行测试，测试完成后会尽快将结果反馈给您。 此致 敬礼 forlove Re: i.MX 8M Plus PCIe Endpoint DMA Test Failed (Failed to prepare DMA memcpy + SDMA Timeout) Hi, 请参考消息中的附件。 Best Regards, Zhiming

FRDM-MX95 AAOS 16 NXP製のAndroid AAOS 16イメージはFRDM-MX95にインストールできますか？ 次に、そのスロットにM.2ハードドライブを取り付けることは可能ですか？ Re: FRDM-MX95 AAOS 16 1) frdmのソースコードがあるとのことですが、Android 16イメージをビルドすることは可能でしょうか？ 2) AAOS 16がFRDM-MX95で動作しなかった特別な理由があるのでしょうか？プロセッサはMIMX9596XVTXNACなので、フル機能を備えており、唯一の違いはメモリ速度だけです。MX95EVKはMIMX9596AVZXNACを使用しています。 どちらのプロセッサもフル機能プロセッサなので、AAOSもAndroidもFRDM-mx95ボードにインストールできない理由はないと思います。その理由について、もう少し詳しく説明していただけますか？ Re: FRDM-MX95 AAOS 16 NXPのドキュメントでは、i.MX 95 EVK/Verdinボード上でのAndroid 16およびAAOSのサポートが規定されていますが、FRDM-IMX95はサポートされていません。Android 16 BSPにはFRDM-95用のソースコードが含まれていますが、現時点ではまだ対応していません。また、 FRDM-IMX95にはAIカードおよびSSD用のM.2 Key-Mスロットが搭載されています。 Re: FRDM-MX95 AAOS 16 こんにちは、フリンさん。 FRDM-i.MX95に対応したAndroidイメージまたはソースパッケージも探しています。何か適切なものは見つかりましたか？

MMOexp:如何在奥丁.瓦尔哈拉崛起中更快地升级？使用米德加德和玛那海姆在《奥丁：瓦尔哈拉崛起》中更快地升级 奥丁： 奥丁 ：瓦尔哈拉崛起》（ Odin: Valhalla Rising）是一款受北欧神话启发的大型多人在线角色扮演游戏，它将电影般的世界构建与大规模探索、 奥丁-瓦尔哈拉崛起钻石 和深度角色进阶系统融为一体。游戏中最重要的早期地区之一是米德加德，尤其是被称为玛那海姆的起始中心。该区域的设计旨在向玩家温和地介绍游戏系统，同时为那些知道如何寻找的玩家提供高效的发展机会。 Midgard 不仅仅是一个教程区，它是一个功能齐全的游戏早期生态系统，玩家可以在其中耕种、制作、探索并为整个旅程打下基础。了解如何有效地使用《玛那海姆》可以大大加快前期的发展速度，并为中期游戏的顺利发展做好准备。 中庭：旅程的基础 米德加德是一个和平的起点世界，每个冒险者都从这里开始他们的故事。与后来充满更严酷敌人和高风险机制的地区不同，米德加德强调易用性和学习性。它的设计目的是让玩家自由尝试战斗、探索和资源收集，而没有持续的进度损失压力。 米德加德最重要的设计选择之一就是没有严厉的死刑。玩家可以尽情探索，而不必担心失败后失去宝贵的经验或稀有物品。这就为新玩家提供了一个理想的环境，以测试不同的玩法、学习等级机制并适应游戏的战斗节奏。 米德加德的中心城镇马纳海姆是早期进展的主要枢纽。从商贩到制作站和地下城入口，所有东西都集中在这里，是准备冒险最有效的地方。 马纳海姆：核心起始枢纽 马纳海姆不仅仅是一个安全区，它还是游戏早期发展的核心。在任务间隙返回城镇的玩家会经常把马纳海姆作为升级装备、购买补给品和计划地下城行动的基地。 玛娜海姆最实用的功能之一就是提供价格低廉的早期游戏消耗品。药水和基本治疗物品的购买成本很低，让玩家可以在野外停留更长时间，而无需不断返回休息。在游戏的最初几个小时，资源有限，这一点尤为重要。 除了消耗品外，玛娜海姆还提供必要的制作材料。这些材料对于升级第一套装备至关重要。因为《奥丁神殿：瓦哈拉崛起》的早期装备升级主要依靠制作和强化：由于《奥丁：瓦尔哈拉崛起》的早期装备进阶主要依赖于制作和强化，因此能够在起始城镇快速收集材料会大大减少游戏初期的摩擦。 米德加尔特的早期探索和战斗流程 米德加德》的一大特色就是将探索和战斗完美地结合在一起。怪物位于马纳海姆郊外，这意味着玩家可以在几秒钟内从安全过渡到战斗。 这种设计可以形成一个平滑的水平环： 在城里接受任务 出口进入附近的田野 与怪物战斗并收集掉落物 返回马纳海姆出售、制作或升级 以更高的效率重复 由于敌人距离起点枢纽很近，早期练级变得极为方便。战斗区域和安全区域之间没有漫长的旅行时间，这有助于在前进过程中保持动力。 这些早期区域的怪物有意保持平衡，使其易于接近。这些游戏介绍了躲闪、技能时机和资源管理等核心机制，但又不会让新玩家不知所措。这种渐进的难度曲线可确保玩家在进入更危险的区域之前建立信心。 高效的早期耕作：虚空废墟精英地下城 虚空废墟精英地下城是米德加尔特解锁的最重要的早期游戏系统之一。该地下城在加速升级方面发挥着关键作用，尤其是对于想要优化经验获取和金币积累的玩家而言。 虚空废墟被设计成一个高效的养殖环境，玩家可以在这里反复清理小怪以获取高价值的奖励。与开放世界的磨练不同，地下城提供了一个可控的环境，敌人密度更高，掉落率更高。 虚空废墟的主要优势包括 每次运行可获得大量 XP 可靠的黄金收入 与田间耕作相比，能更好地减少材料损耗 用于技能练习的结构化战斗遭遇战 对于希望在《奥丁神殿：瓦尔哈拉崛起》中快速进步的玩家来说，这个地牢是游戏初期最有效的活动之一：对于希望在《奥丁：瓦尔哈拉崛起》中快速前进的玩家来说，这个地下城是游戏初期最有效的活动之一。持续运行它有助于弥合早期任务和中期游戏内容之间的差距。 虚空召唤：容易获得奖励的早期目标 米德加德的另一个重要特征是虚空召唤的存在。这些敌人基本上是为早期玩家设计的简化精英目标。与后期的地下城首领或世界精英相比，它们更容易被击败，因此非常适合持续养殖。 虚空召唤提供源源不断的奖励，包括 基本增强材料 早期装备升级物品 少量但持续的黄金下降 由于虚空召唤相对容易被击败，因此它们非常适合想要在不依赖大规模队伍协调的情况下积累资源的单人玩家或小团体。 这些接触也具有重要的培训功能。它们帮助玩家在低风险的环境中了解精英敌人的机制，为游戏后期更复杂的战斗做好准备。 海蛇巢穴早期派对地下城攻略 海蛇巢穴是米德加尔特最有价值的早期合作体验之一，这是一个专为新手设计的低难度派对地下城。 与单人耕种区域不同，这个地下城鼓励团队合作和协调。虽然新手玩家仍然可以使用，但它介绍了基于群体的战斗的基本要素，如角色分配、攻击控制和共享资源管理。 海蛇巢穴对制作工艺的发展尤为重要。玩家可以获得 制作原料 符文相关奖励 增强材料 这些奖励对于在游戏初期打造更强的装备套装至关重要。由于《奥丁神殿：瓦尔哈拉崛起》中的装备升级与制作系统紧密相连，因此经常运行这个地下城可以显著加快整体实力的增长：由于《奥丁：瓦尔哈拉崛起》中的装备升级与制作系统紧密相连，因此经常运行这个地下城可以显著加快整体实力的增长。 地牢也是一个社会切入点。许多玩家通过反复运行形成了早期的友谊或公会联系，这对后期的高端内容非常重要。 游戏初期的最佳发展路径 要充分利用《米德加德》和《玛纳海姆》，玩家应遵循有条理的发展路线，在探险、耕作和地下城运行之间取得平衡。 推荐的游戏初期循环是这样的： 从玛纳海姆的主线任务开始 养殖附近的怪物，获取 XP 和基本材料 返回城镇进行升级和补充药水 进入虚空废墟精英地下城，实现高效耕作 猎杀虚空召唤兽获得额外奖励 加入海蛇巢穴，获取制作材料 用升级后的齿轮重复循环 这种循环可确保玩家在力量和资源方面不断进步，而不会将时间浪费在效率低下的旅行或低收益的农业上。 为什么中庭对长期发展至关重要？ 许多玩家低估了早期游戏在大型多人在线角色扮演游戏中的重要性，但《奥丁的米德加德》（Midgard in Odin：瓦尔哈拉崛起》专门为塑造长期成功而设计。 这里介绍的系统--制作、地牢养殖、精英遭遇战和合作游戏--都是贯穿整个游戏的基础机制。早期掌握米德加德的玩家可以更顺利地过渡到后期地区，获得更强大的装备、更好的资源管理和更精炼的战斗技能。 尤其是马纳海姆，它是一个提高效率的训练场。在这里学习如何在耕种、制作和地牢运行之间轮换，养成的习惯将在游戏的后期阶段继续带来回报。 总结与展望 米德加德和玛那海姆不仅仅是起始区域，它们还是《奥丁神殿》后续一切的蓝图：瓦尔哈拉崛起凭借便捷的战斗、高效的耕作区域以及虚空废墟和海蛇巢穴等早期地下城的奖励，玩家将获得购买奥丁· 瓦尔哈拉崛起钻石打下坚实基础所需的所有工具。 通过了解如何优化您在米德加尔特的时间--平衡探索、战斗、制作和地牢耕种--您可以大大加快您的早期进度，并为您在玛那海姆之外的更严峻挑战中取得成功做好准备。 关键的启示很简单：不要急于通过米德加尔特。掌握它。

bma7418のバランス調整 提供されたCDDを使用して、BMA7418の負荷分散を設定しようとしています。全体的な目標は、アプリケーションソフトウェアが任意の時点でどのセルを放電すべきか（もしあれば）を要求し、CDDがそれに応じてBCCを構成することである。 Tresosでは「BAL機能を有効にする」を有効にし、現在CDDのAPIを調べています。Bcc_D1xx_BAL_SetGlobalConfiguration と Bcc_D1xx_BAL_SetChannelConfiguration があります。 Bcc_D1xx_BAL_SetGlobalConfigurationで一度すべてのバランシングを有効にし、実行時にBcc_D1xx_BAL_SetChannelConfigurationを使用して実際のバランシングを構成する、という理解でよろしいでしょうか？ Bcc_D1xx_BAL_SetGlobalConfiguration は、struct Bcc_D1xx_BalConfigurationType を受け取ります。FullEvenBal/FullOddBal または BalChannels(0/1)En を使用する必要がありますか?TimerBasedBal、PreBalTimer、GlobalBalTimerの目的は何ですか？ Bcc_D1xx_BAL_SetChannelConfiguration は struct Bcc_D1xx_BalChannelConfigurationType を受け取りますが、チャネル ID をそのまま渡せばよいのでしょうか (ビットマスクは使用できませんか)？PWMはどうですか？タイマーの分解能はどれくらいですか？ バランス調整のサンプルコードがあれば大変助かります。付属のCDDには見当たりませんでした。 SPI

MIMXRT1176デュアルコアで、M4がランダムにロックアップ状態になる場合、どのようにデバッグすればよいですか？ ハードウェア：MIMXRT1176（Cortex-M7 + Cortex-M4） IDE：MCUXpresso アプリケーション：デュアルコアプロジェクト。 問題： 約1～2時間の通常動作後、M4コアはランダムに ロックアップ 州。 システムがロックアップした後、自動的にリセットされることがあります。 時々完全にフリーズしてしまい、ハードウェアのリセットが必要になることがあります。 私が既に行ったこと： 有効 MemManage 障害、 バス障害、および 使用上の誤り 起動コード内。 対応する障害ハンドラを実装しました（UART経由でコンテキストを出力します）。 奇妙な行動： ロックアップ前に、 なし 有効になっている障害ハンドラが入力されます（UART出力はありません）。 ロックアップ後、デバッガーはSWD経由で再接続できません（接続失敗）。 システムが自動リセットされた場合、（リセット原因レジスタを介して）ロックアップが発生したことしか検出できませんが、その原因となったPC、LR、およびスタックの内容は失われます。 質問： このような状況下で、M4のロックアップ現象の根本原因を調査するにはどうすればよいでしょうか？ 何かご提案やデバッグ方法などございましたら、大変ありがたく存じます。ありがとう！ Re: MIMXRT1176 dual-core, M4 enters random Lockup, How to Debug? 問題は解決しました。 根本原因：M4ロックアップ i.MX RT1176 – DCDC電源モード オン i.MX RT1176（特にデュアルコアプロジェクトの場合）の既知の原因の1つは、 DCDC電源構成 内部 clock_config.c （関数 BOARD_BootClockRUN) デフォルトでは、DCDCレギュレータは次のように設定されています。 CCM（連続伝導モード）負荷が高い場合、または動的に変化する負荷の場合（例：M7とM4の両方がアクティブ、フラッシュへのアクセス、ペリフェラルの切り替え）、 負荷変動は一時的な電圧降下を引き起こす可能性があります。M4コアはM7よりもこのような落下に敏感であり、 ロックアップ 障害ハンドラが実行されることなく。ロックアップ後、コアが応答しなくなるため、デバッガーは接続を失うことがよくあります。 解決： DCDCコンバータを切り替えて DCM（不連続伝導モード）DCMは負荷変動への対応能力が高く、ロックアップを引き起こす電圧降下を回避します。

S32DS 3.6.5 和 RTD 3.0.0 的引导加载程序示例可用性 嗨，团队、 我想查看是否有适用于 S32 Design Studio 3.6.5 和 RTD 3.0.0 的引导加载器应用示例。 如果您能分享一下，将对我们很有帮助： 任何用于实现引导加载程序的参考项目或示例代码 使用 RTD 3.0.0 开发引导加载程序的推荐方法或文档 兼容性考虑（如有 如果您能提供指导和参考，我们将不胜感激。 Re: Bootloader Example Availability for S32DS 3.6.5 with RTD 3.0.0 你好@Aravind_Togaralli 如前所述，共享链接中列出的项目和我添加的项目是目前可用的选项。 Re: Bootloader Example Availability for S32DS 3.6.5 with RTD 3.0.0 在搭载 RTD 3.0.0 的 S32 Design Studio 3.6.5 中支持的 S32K344 控制器板上是否有任何特定的引导加载程序应用程序可用？ Re: Bootloader Example Availability for S32DS 3.6.5 with RTD 3.0.0 你好@Aravind_Togaralli 请参阅社区主题 "S32K385 引导加载程序"，我的同事提供了当前可用引导加载程序的列表。 此外，线程示例S32K312 引导加载器到应用程序跳转 DS3.5 RTD300 也包含一个示例。 BR、VaneB

LX2160 上的 UE 到 UE 通信失败 恩智浦团队你好， 我们的 一位客户使用非IPsec模式和静态IP设置了以下配置。该板以 2160 ASF 为 基础。 核心区有一个 BH 服务器，从 BH 服务器分别 ping 到 UE1 和 UE2 都正常。 IP 地址：192.168.205.3 但当它们从 UE1 ping 到 UE2 时，ping 却不起作用。从 pcap 看来，ping 数据包是从 UPF 到达 gnb 的，但没有转发到 dpdk，而是转发到了 Linux 栈。 当我们看到"restool dpni info dpni.3" stats ingress_bytes 在增加，但 egress_bytes 没有增加。Dpni.3 是 ASF 接口。 我们尝试手动执行 setbhinfo 和 conntrack flush，但仍然没有成功。 问题出在哪里？ 请参见附件中的 pcap 和 nf_conntrack dump。 Re: UE to UE communication failure on LX2160 根据您的描述，您似乎正在使用"ASFSIB ASK" ，这是付费的 SDK。 在社区讨论这个话题很不方便。 我看到您创建了一个内部案件。我们将在内部案件中为您提供支持。

S32K3 FRDM オートモーティブ ボードインストールパッケージのダウンロードに関する問題：「保留中（不正行為者）」エラー こんにちは、 S32K3開発用の特定のソフトウェアパッケージをダウンロードしようとした際に問題が発生しており、アカウント権限または輸出管理スクリーニングに関連しているようです。 1. ダウンロード対象パッケージ: S32K3 / FRDM オートモーティブ基板インストールパッケージ（バージョン：2026.02） 同梱物：FreeMaster 1.5.0RFP D2512、S32 Design Studioおよび構成ツール3.6.5D2511、リアルタイム・ドライバ 7.0.0QLP03 D2512、FreeRTOS 7.0.0CD1 HF1 D2511、LINスタック 4.0.0D2511、TCP/IPスタック4.0.0D2512 2. 問題発生とエラーメッセージの発生順序： ステップ 1 (最初の試み - エラー メッセージ):最初はメインリストから FRDM オートモーティブ ボードインストール パッケージを直接選択しました。しかし、「輸出管理」段階への移行中に、次の警告メッセージが表示されました。 「以下のパッケージは保留状態（不正行為者）です。この要求により、他のパッケージが無効になる可能性があることに注意してください。」その結果、次のステップに進むボタンは完全に無効になり、[終了]ボタンのみが有効になった。（「nxp error2.png」を参照してください） ステップ 2 (エラー発生後 - アクセスがブロックされました):このエラーが発生した後、パッケージを再度ダウンロードしようとすると、システムはそれを失敗したカスタム選択リンクとして扱うようです。「警告：この選択には、現在入手できないパッケージが1つ以上含まれています」という警告が表示されたポップアップウィンドウが表示され、[この選択を適用]ボタンがグレー表示になっていて、先に進むことができません。（「nxp error.png」を参照してください） 3. 質問: この文脈において、「保留中（悪質な行為者）」というステータスは具体的に何を意味するのでしょうか？この問題は、私のアカウントの輸出管理審査／承認における遅延または制限が原因ですか？ 現在、ポップアップウィンドウが表示されて先に進めず、このパッケージの再選択やダウンロード処理を進めることができません。この問題を解決し、FRDM オートモーティブ ボードインストールパッケージを正常にダウンロードするために、私がどのような対応を取る必要がありますか？あるいは、NXP側でどのような調整が必要ですか？ ご協力ありがとうございました。 よろしくお願いいたします。 Re: Issue with Downloading S32K3 FRDM Automotive Board Installation Package: 'Pending(Bad Actor)' Er こんにちは、 @iamengineer さん、 類似の事例に基づくと、「保留中（悪意のある行為者）」というメッセージは、通常、ソフトウェアのダウンロードに関するアカウントまたは権限の制限を示しており、パッケージ自体に問題があるわけではありません。 お近くのNXP FAEにご連絡いただき、NXPアカウントのメールアドレス、会社名／国名、正確なパッケージ名／バージョン、およびメッセージのスクリーンショットをお送りください。 バンドルに含まれるコンポーネントを個別にダウンロードしてみることもできます。 よろしくお願いいたします。 パベル

NXP S32G-VNP-RDB2に関するヘルプ 私は組み込みLinuxに関しては全くの初心者で（ほとんど何も知りません）、NXP S32G-VPN-RDB2ボードを持っています。このボードでは、定期的にボード内の情報（CPU使用率、RAM使用率など）を収集し、テキストファイルに保存する必要があります。また、これをバックグラウンドサービスとして実行する必要があります。私は既にこれらの作業を実行するためのスクリプトを作成済みでした。ボードの起動は成功し、スクリプトも正常に実行されましたが、スクリプトをサービスにするために、Linux PC の systemd を使用しました。しかし、ボードの Linux (Auto Linux BSP 39.0) には systemd が存在せず、apt コマンド、systemctl、bashrc も存在しません。何をすればいいのか、このスクリプトをサービスにするにはどうすればいいのか、本当に困っています。どこかで、Yoctoを使えばボード上のLinuxをカスタマイズできると読んだのですが、全く知識がなく、どこから始めたらいいのか分かりません。助けてください :') Re: Help with NXP S32G-VNP-RDB2 こんにちは、 @lengoyeko 投稿ありがとうございます。 BSP42のようなより新しいBSPバージョンで作業することは可能でしょうか、それとも前述のとおりBSP39を使用することにこだわるのでしょうか？ RDB3をベースにしたBSP42（テスト準備が整っているため）で簡単なテストを行ったところ、systemdをベースにしたサービスを実装することをお勧めします。私のテストでは、このリリースで問題なく動作しているようです。 BR チェイン

SE05X - 同時アクセスおよび並列アクセスのサポート こんにちは、 私はSE05xをPlug & Trustミドルウェアを使用して運用していますが、同時アクセス（並列アクセス）のサポート状況について理解を深めたいと思っています。 複数のスレッドまたはプロセスから同時にSE05Xにアクセスすることは可能ですか？ はいの場合： 同時アクセスを使用する際に、何か制限や制約はありますか？ SE05Xは内部的に同期処理を行いますか、それともホスト側で完全に管理する必要がありますか？ マルチスレッドまたはマルチセッションでの利用に関して、推奨されるベストプラクティスはありますか？ そうでない場合： - マルチスレッドまたはマルチプロセス環境でSE05Xを使用する場合、推奨されるアーキテクチャは何ですか？ ご説明や関連ドキュメントへの参照などございましたら、大変ありがたく存じます。 ご回答をお待ちしています。 スマート・カード Re: SE05X - Support for concurrent and parallel access こんにちは@nofarbe あなたの調子が良いといいのですが。 SE05xはマルチテナントモデルをサポートしています。SE050A/B/C/Dユーザーガイド／ EdgeLock SE050Eユーザーガイドの第5章を参照してください。 よろしくお願いいたします。 エドゥアルド。