i.MX95 Android Automotive 16 CSI1 Ov5640 摄像头问题 大家好， 我们正在使用定制的 i.MX95 板和 OV5640 摄像头传感器，当摄像头连接到 Android Automotive 16 上的 CSI1 时，我们遇到了问题。 硬件设计已经过验证： - CSI0 和 CSI1 在 Linux 6.18.20 下工作正常。 - CSI0 和 CSI1 在基于 Linux 6.18.20 的 Android 16 上也能正常工作。 - 该问题仅在基于 Linux 6.18.20 的 Android Automotive 16 中出现。 观察结果： - CSI0 运行正常，没有任何问题。 - CSI1 无法开始播放。 - 我们对 CSI1 进行了独立测试。 - 我们还禁用了 NEO ISP，仅使用 ISI 管道进行了测试，但问题仍然存在。 观察到的误差： LIBCAMERA：启动流媒体失败：连接超时 LIBCAMERA：'mxc_isi.0'：无法在 0/0 号焊盘上设置格式：设备或资源忙 日志和 media-ctl 验证结果已附上，供参考。 有人在 i.MX95 EVK 或 Android Automotive 16 上遇到过类似的 CSI1 问题吗？任何建议、修复方案、补丁或关于 EVK 上 CSI1 验证的确认信息都将不胜感激。 谢谢， 马鲁蒂·奈克 评估板 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 你好， 我们已验证内核 DTS 配置正确。当前的 Android Automotive 16 电路板支持包。也基于 Linux 6.18.20，相同的 DTS 配置在 Linux 6.18.20 电路板支持包。中运行没有任何问题。 我们还成功地在 Android Automotive 15 电路板支持包中测试并验证了配备 OV5640 摄像头的 CSI1。 请问最新的 Android Automotive 16.0.0_2.1.0 版本对 CSI1 摄像头的支持是否存在任何限制？电路板支持包。？此版本是否需要进行任何其他更改才能启用 CSI1 摄像头支持？ 请予以澄清。 问候， 马鲁蒂 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 我检查了AAOS，它默认支持csi0，但当前的电路板支持包。不支持摄像头的mipi dsi/csi，你应该修改dts和摄像头配置，你修改过什么吗？如果可以，请分享您修改后的详细步骤和代码。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 嗨@joanxie 关于这个问题有任何进展吗？请分享您的发现或提供一些技术指导，以帮助我们解决 CSI1 摄像头问题。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 亲爱的@joanxie 是的，我们的 B0 板设计基于 NXP i.MX95 19x19 EVK。 供您参考，同样的硬件在 Linux 6.18.20 和基于 Linux 6.18.20 的 Android 16 上都能正常工作。CSI0和CSI1（CSI-DSI 组合）均使用双 OV5640 摄像头。 我们使用的是Android Automotive 16.0.0_2.1.0 版本。（基于 6.18.20_2.0.0 BSP），它使用相同的内核版本和内核配置。 然而，Android Automotive 16.0.0_2.1.0电路板支持包，OV5640 摄像头在CSI0上工作正常，但CSI1（CSI-DSI 组合）上的 OV5640 摄像头无法工作。日志已经共享。 我们目前没有 i.MX95 B0 EVK 板（我们有 A1 EVK 板），所以我们无法在 EVK 上进行测试。 如果您能使用最新的 Android Automotive 16 电路板支持包。 在 NXP i.MX95 19x19 EVK B0 板上，对任何支持的摄像头测试CSI1（CSI-DSI 组合） ，并分享您的测试结果，那将非常有帮助。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 您好， 马鲁蒂 你的板设计是基于imx95 evk板吗？如果是，您是否在 nxp imx95 evk 板上重现了此问题？以及具体的安卓16 电路板支持包。版本信息？1.1.0还是 1.3.0 版本？ B.R. 琼 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 我会再次向 Android Auto 团队确认，但他们之前并没有说过 Android 16 的 Auto 功能有任何限制。根据你的测试结果，这个问题似乎与 Android 16 的 Auto 功能有关。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 亲爱的@joanxie ， 关于CSI1摄像头的问题，我有一个更新。 使用 Car2 图像，CSI0 和 CSI1 摄像头均工作正常。然而，对于汽车图像，我们仍然面临着让 CSI1 摄像头工作的问题。 请协助我们调查并解决车载图像中CSI1摄像头的问题。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 你好， 在我们的测试中，在 Android Automotive 15 电路板支持包。上，CSI0 和 CSI1 摄像头都能与 Car 图像（运行在 M7 内核上的 EVS）和 Car2 图像（运行在 A55 内核上的 EVS）正常工作。 在 Android Automotive 16 电路板支持包。上，使用 Car 映像（EVS 运行在 M7 内核上），CSI0 可以工作，但 CSI1 不能工作。但是，使用 Car2 镜像（EVS 运行在 A55 内核上），CSI0 和 CSI1 都能正常工作。 请检查一下车载系统镜像中是否有后台进程正在访问或占用 CSI1，导致摄像头无法工作？ Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 你说的car2图片是什么意思？您是指在 Arm Cortex-A 内核上使用 EVS 吗？既然您在 Android 15 自动测试版上测试成功了，那么您在 Android 15 自动测试版上测试的是什么？能否分享一下您的补丁以便我再次检查？ Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 我认为安卓自动开发团队之前没有测试过 CSI1，因为默认设置只针对 CSI0。你需要EVS 和 Camera APK 功能吗？你使用的是 Car2 镜像类型吗？ Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 亲爱的@joanxie ， 感谢您的支持。 请问能否提供任何变通方法或补丁，以在 Android Automotive 16.0.0_2.1.0 上启用对 CSI1（DSI-CSI 组合）的摄像头验证支持？ 非常感谢您的帮助。 此致， 马鲁蒂·奈克 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 亲爱的@joanxie 我们目前正在使用汽车图像，暂时不关注电动汽车。我们的需求是通过 Camera 应用程序直接启用和验证 CSI1 摄像头。 请协助我们解决CSI1摄像头的问题 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 能否提供一下 car2 和 car image 这两个日志文件？仅适用于 csi1，您能否尝试使用相同的 CM7 固件版本，从 AA15 升级到 AA16.0 2.1.0？

iMX8でサポートされるエンドポイントの数 iMX8はUSB用のDWC3を使っており、これはxHCIコントローラです。iMX8のレジスタを読み上げると、最大64台のデバイスをサポートしている可能性があることがわかりました。しかし、いくつかのデバイスを接続すると、かなり早い段階でxHCIリソースエラーが発生します。エンドポイントの数には何らかの制限があるようで、転送タイプ（バルク、コントロールなど）によっても異なるようです。私が使用しているタイプのデバイス（ハブを含む）では、エンドポイントが80個を超えると問題が発生するようです。サポートされているエンドポイントの数について、正確な数字や計算式を教えていただけますか? Re: Number of supported endpoints on the iMX8 こんにちは、 i.MX8 xHCI MaxSlots = 64という値は、有効にできるUSBデバイススロットの最大数を指定するものであり、エンドポイントの総容量を指定するものではありません。xHCIは1デバイスあたり最大31のエンドポイントコンテキストを利用できますが、コントローラは64スロットすべてが同時に最大数のエンドポイントを使用できる保証はありません。使用可能な合計値は、主に周期的な帯域幅、デバイスの速度、エンドポイントの間隔とパケットサイズ、ハブのトポロジー、トランザクショントランスレータの割り当て、およびDWC3の実装リソースに依存します。   詳細については、xHCI仕様書を参照してください。

Using CLRC663 as P2P device Hello, We would like to use the CLRC663 plus as a Peer-to-peer (P2P) device. According to the datasheet the CLRC663 supports P2P mode according to the ISO/IEC 18092 in Passive Initiator mode. This however brings up a multitude of questions: Is it possible to have two CLRC663 devices communicate with each other? If not, should the CLRC663 be combined with another device? Which is recommended? How to activate the ISO 18092 protocol? For other protocols I have found AN12657 at least describes how to activate some other protocols using the LoadProtocol functionality on the CLRC633, but the datasheet lacks any information on the ISO 18092 protocol. How these other two are activated is entirely unclear from the datasheet as well but can be inferred from this Application Note. Can two devices communicate in Passive Initiator mode? I have looked at probably all posts already on the forum related to this but found nothing of use. I have also seen the NFC Reader Library but am unable to find anything useful regarding P2P. Kind regards Re: Using CLRC663 as P2P device Hello, Thank you for your interest in NXP Semiconductors products and for the opportunity to support you CLRC663 is not fully NFC Forum compliant and it is intended for Reader/Writer mode. A CLRC663 can therefore be used with a different NFC device that supports the required target mode (i.e. HCE). For a standard ISO/IEC 18092 P2P connection, you could consider evaluating the PN5190. However, this hardware consideration must also be evaluated together with the available support. Please notice that the NXP NFC Reader Library states that maintenance of its P2P functionality is being discontinued. Although earlier library releases include legacy P2P support, P2P functionality is not supported in our current software baseline. Best regards,  Alondra

i.MX95 Android オートモーティブ 16 CSI1 Ov5640 カメラの問題 チームの皆さん、こんにちは。 カスタムのi.MX95ボードにOV5640カメラセンサーを搭載しており、Android オートモーティブ 16でカメラをCSI1に接続すると問題が発生しています。 ハードウェア設計はすでに検証されています: - CSI0およびCSI1はLinux 6.18.20で正常に動作します。 - CSI0およびCSI1はLinux 6.18.20ベースのAndroid 16でも正常に動作します。 - この問題はLinux 6.18.20ベースのAndroid オートモーティブ 16でのみ観察されます。 観察結果： - CSI0は問題なく動作します。 - CSI1がストリーミングを開始できませんでした。 - CSI1については独自にテストを実施しました。 - また、NEO ISPを無効にしてISIパイプラインのみでテストしましたが、問題は解決しませんでした。 観測されたエラー: LIBCAMERA: ストリーミングの開始に失敗しました: 接続がタイムアウトしました LIBCAMERA: 'mxc_isi.0':パッド0/0でフォーマットを設定できません：デバイスまたはリソースがビジー状態です 参照用にlogおよびmedia-ctlの検証結果を添付します。 i.MX95 EVKやAndroid オートモーティブ 16で同様のCSI1問題に遭遇した方はいらっしゃいますか?EVKでのCSI1検証の提案、修正、パッチ、または確認があればぜひ教えてください。 ありがとう、 マルティ・ナイク 評価ボード Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue こんにちは、 カーネルのDTS設定が正しいことを確認しました。現在のAndroid オートモーティブ 16 BSPもLinux 6.18.20をベースにしており、同じDTS構成がLinux 6.18.20 BSPでも問題なく動作しています。 また、Android オートモーティブ 15 BSPでOV5640カメラを搭載したCSI1のテストと検証も成功裏に行っています。 最新のAndroid オートモーティブ 16.0.0_2.1.0でCSI1カメラのサポートに制限や制限があるかどうか、確認していただけますか?BSP?このリリースでCSI1カメラのサポートを有効にするために追加の変更は必要ですか? ご説明をお願いします。 よろしくお願いいたします。 マルチ Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue AAOSを確認しましたが、デフォルトでCSI0をサポートしています。現在のBSPはカメラ用のMIPI DSI/CSIをサポートしていません。DTSやカメラの設定を変更するべきです。何か変更しましたか?はいの場合、変更した手順とコードの詳細を共有してください。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue こんにちは、 @joanxie この件に関して何か進展はありましたか？CSI1カメラの問題解決に役立つ調査結果や技術的なアドバイスをぜひお寄せください。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 親愛なる@joanxie  はい、私たちのB0ボードデザインはNXP i.MX95 19x19 EVKをベースにしています。 参考までに、同じハードウェアがLinux 6.18.20とAndroid 16(Linux 6.18.20ベース)で動作しています。CSI0とCSI1（CSI-DSIコンボ）はどちらも、2台のOV5640カメラで動作しています。 Android オートモーティブ 16.0.0_2.1.0を使用しています（6.18.20_2.0.0 BSP をベースにしており、同じカーネルバージョンとカーネル構成を使用しています。） しかし、Android オートモーティブ 16.0.0_2.1.0ではBSPでは、OV5640カメラはCSI0では動作しますが、 CSI1（CSI-DSIコンボ）上のOV5640カメラは動作しません。ログは既に共有済みです。 現在、i.MX95 B0 EVKボードは入手できず(A1 EVKボードを持っています)、EVK上でテストできません。 最新のAndroid オートモーティブ 16 BSPを使ってNXP i.MX95 19x19 EVK B0ボードで CSI1(CSI-DSIコンボ)を対応カメラでテストし、結果を共有していただけると助かります。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue こんにちは、 マルティさん ボードデザインはIMX95 EVKボードをベースにしたのですか?はいの場合、NXP IMX95 EVKボードでこの現象を再現できましたか？そして、詳細な車載Android 16 BSPバージョンは何ですか?1.1.0それとも1.3.0？ B.R. ジョーン Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue @joanxie様、 CSI1カメラの問題について、最新情報をお伝えします。 Car2の画像では、CSI0とCSI1の両カメラが正常に動作しています。しかし、車の画像に関しては、CSI1カメラを正常に動作させるという問題が依然として発生しています。 カーイメージにおけるCSI1カメラの問題の調査と解決にご協力をお願いいたします。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 親愛 なる@joanxieへ、 サポートありがとうございます。 Android オートモーティブ 16.0.0_2.1.0でCSI1(DSI-CSIコンボ)のカメラ検証サポートを有効にするための回避策やパッチを教えていただけますか? ご協力いただければ大変ありがたいです。 よろしくお願いします、 マルティ・ナイク Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 車載AndroidチームはCSI1を以前にテストしたことがないと思います。デフォルトはCSI0専用なので、EVSやカメラAPK機能は必要でしたか?そしてCar2の画像タイプは使いましたか? Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue car2イメージとはどういう意味ですか？ Arm Cortex-AコアのEVSでのことですか?車載Android 15でテストが成功したなら、車載Android 15では何をテストしていますか?確認のためにパッチを共有してもらえますか? Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 親愛なる@joanxie 現在、私たちは自動車のイメージを使用しており、今のところEVS（電気自動車）には注力していません。私たちの要件は、Cameraアプリケーションを通じてCSI1カメラを直接有効化・検証することです。 CSI1カメラの問題を解決するためにご協力をお願いします。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Android 車載チームから再度確認しますが、これまで車載 Android 16に制限があるとは言っていませんでした。あなたのテスト結果からすると、この問題は車載 Android 16に関連しているようです Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue こんにちは、 私たちのテストでは、Android オートモーティブ 15 BSP上で、CSI0とCSI1の両方のカメラが、車用画像(EVSはM7コア上で動作)とCar2画像(EVSはA55コア上で動作)の両方で正常に動作しました。 Android オートモーティブ 16 BSPでは、車のイメージ(M7コア上でEVSが動作している)ではCSI0は動作しますが、CSI1は動作しません。しかし、Car2イメージ（A55コア上で動作するEVS）では、CSI0とCSI1の両方が正しく動作します。 車の画像の背景処理がCSI1にアクセスしたり保持したりしていて、カメラが動かなくなるかどうか確認してもらえますか? Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue car2とcarimageの2つのログファイルを教えてもらえますか?CSI1専用で、AA15からAA16.0 2.1.0までの同じCM7 FWバージョンを使ってみてはどうでしょうか?

iMX8 支持的端点数量 iMX8 使用 DWC3 作为 USB 控制器，DWC3 是一款 xHCI 控制器。从 iMX8 的寄存器中读取数据后，我发现它最多可以支持 64 个设备。但是当我连接几个设备时，之前就出现了 xHCI 资源错误。似乎端点数量存在某种限制，而且似乎还取决于传输类型（批量、控制等）。在我使用的这类设备（包括集线器）中，似乎在连接 80 个终端后就会出现问题。请问能否提供一些确切的数字/公式，说明支持多少个端点？ Re: Number of supported endpoints on the iMX8 你好， i.MX8 xHCI MaxSlots = 64 值指定了可启用 USB 设备插槽的最大数量，而不是端点总容量。xHCI 每个设备最多支持 31 个端点上下文，但控制器不保证所有 64 个插槽都能同时使用最大数量的端点。可用总量主要取决于周期带宽、设备速度、端点间隔和数据包大小、集线器拓扑结构、事务转换器分配和 DWC3 实现资源。   详细信息请参考xHCI规范。

[Yealink]ASHAパケット損失、Bluetoothストレステスト切断に関するお問い合わせ 親愛なるNXP NXHサポートチームへ、 以下のAPIやイベント情報を用いてNXH2004 ASHA DSPの同期外問題に対処するよう、以前のご提案に感謝します。 AUDIO_ConfigureLlSyncParams() kAUDIO_Event_LlOutOfSync AUDIO_ForceSharedBufResync() ASHAの再生および再接続テスト中に、再同期通話が返kStatus_Success後に同期外れのイベント情報が発生することが繰り返し確認されました。また、有効なエンコードされたオーディオが共有バッファに書き込まれ続ける期間もありましたが、currentBufferRowNumberとnextExpectedTimestamp(AUDIO_GetDspSharedBufInfo(を通じて取得)は約5秒間隔のサンプル間で変化しませんでした。 私たちのプロジェクトは現在SDK 6.2に限定されています。以前報告された持続沈黙の問題については、SDK 6.2を用いた推奨回復手順と期待される結果について明確にしていただけると幸いです。 1. 回復の見込みと成功の確認 無線リンクが安定し、有効なオーディオデータとタイムスタンプが再開された後、推奨されている手順は NXH2004リセットや意図的にBLEを切断せずに通常のオーディオ再生を継続できると期待されますか? AUDIO_ForceSharedBufResync()がkStatus_Successに戻ったとき、これはDSPコマンドが成功裏に完了したことを意味するのか、それともDSPが同期を回復したことを意味するのか? ご説明をお願いします。 同期復元イベント情報や同期状態を問い合わせるAPIはありますか? これ以上の同期のずれイベント情報がなかったり、DSP行や予想されるタイムスタンプの再進行がなければ、成功した復旧を確実にするのに十分でしょうか? 回復を確認するために推奨される観察期間はどのくらいですか？有効な入力が再開された後、同期と通常の再生が回復するまでにはどのくらいの時間がかかりますか？ どの故障条件はデバイスのリセットなしで回復可能で、またどの条件は別の回復手順が必要でしょうか? 2. 推奨される回復手順と繰り返しのイベント情報の対処 同期ずれの原因として挙げられている2つのケースについて、推奨される対処方法をご確認ください。 kAUDIO_LlOutOfSync_Sync_Lost_During_Playback、アプリケーションはすぐに再同期を呼び出すべきか、それともまず無線リンクが安定するのを待つべきでしょうか?リンクが安定しているかどうかを判断するために、どのようなSDK情報を使うべきでしょうか? kAUDIO_LlOutOfSync_Sync_Not_Achieved_At_Startについては、UM11981§4.4.3はオーディオチェーンの停止と再開始を推奨しています。AUDIO_StopChains() の後に AUDIO_StartChains() を実行するだけで十分でしょうか、それともチェーンを解放して再構成する必要があり、QoS や LL 同期パラメータの再適用も必要ですか？ 共有のFIFO、アプリケーションバッファ、タイムスタンプの状態をどのように扱うべきか、推奨される定着時間、再試行間隔、再試行制限を指定してください。 再 同期後、チェーン再起動が行われる前、そしてアプリケーションレベルのASHAセッションがアクティブなチェーン再起動後の両方でSync_Not_Achieved_At_Startを観察しています。これら2つのCASEに関連するDSPの状態遷移について説明していただけますか? 復旧コマンドが成功を返した後にさらに同期外のイベント情報が発生した場合、アプリケーションは以下のように区別すべきか: 新たな同期エラーが発生しています。 同期処理が進行中ですが、まだ完了していません。 以前の故障による遅延イベント情報でしょうか? これらのリカバリーAPIはオーディオイベントのコールバックから直接呼び出せるのでしょうか、それともタスクに延期すべきでしょうか?また、オーディオAPI呼び出しのシリアライズ要件についても明確にしてください。 3. DSPプロセッシングが進展しない場合の検出と復旧 以前、すべてのミュート条件がkAUDIO_Event_LlOutOfSyncを生成するわけではないことを指摘されました。 有効なエンコードされたオーディオが書き込まれ続けているものの、DSPの行や期待されるタイムスタンプが進まない場合、停止した消費と通常の同期待ち条件を区別するために、SDK対応の方法を推奨しますか? また、観測期間中に累積されたパケットの欠損表示カウントがゼロになることがあり、DSP情報は変わらないことも観察しました。パケットの欠落数がゼロであることは、通常の復号の証拠として使えますか?パケット欠落または同期ずれの表示は、どのような条件下で停止しますか？ 共有バッファの再同期でこの状態を解決できない場合は、推奨される回復方法を提供してください。 応答しないDSPの場合、共有バッファの読み取りや同期リカバリーコマンドは制限時間内に必ず戻ってくる保証があるのでしょうか?どのようなタイムアウトおよびエラー処理手順を推奨しますか？ kAUDIO_Event_WatchdogIndicationを受け取った後、ローカル復旧を試みるためにオーディオAPIを呼び続けることはサポートされているのでしょうか、それとも特定のリセット手順に従う必要がありますか? NXH2004  NXH2004SDK  @Nasser_F見ていただけませんか?ありがとうございます! Re: [Yealink]Inquiry regarding ASHA packet loss, Bluetooth stress test disconnection, 以下は問題発生前のいくつかの歴史的なコミュニケーションです   回答1: はい、NXH2004を再起動せずにDSPの同期外れを解決する現実的な解決策はあります。   以下のAPIとイベント情報を導入しました:   AUDIO_ConfigureLlSyncParams() AUDIO_ForceSharedBufResync() イベント:kAUDIO_Event_LlOutOfSync   これらの新しいAPIを使ってDSPの同期外れを解決するには、以下の手順に従ってください。   AUDIO_ConfigureLlSyncParams() を使用して同期タイムアウトを設定します。 kAUDIO_Event_LlOutOfSyncイベントの監視をしてください。 DSPは、AUDIO_ConfigureLlSyncParams()で設定されたタイムアウトよりも長く有効なタイムスタンプを受け取らないと、有効なタイムスタンプを継続的に受け取らないと、kAUDIO_Event_LlOutOfSyncを生成します。 すべてのミュート条件がkAUDIO_Event_LlOutOfSyncをトリガーするわけではないことに注意してください。設定されたタイムアウト値を超えるものだけがトリガーされます。 kAUDIO_Event_LlOutOfSyncを受信したら、AUDIO_ForceSharedBufResync()を呼び出します。   回答2:   SDK 6.2で切断イベント情報が見逃される問題は確認していません。   この問題をどのように観察したのか、もう少し詳しく教えていただけますか?   故障したイヤホンからのログにハードフォルトイベントなどのエラーメッセージはありますか?もし問題を再現可能なら、PA/LNA信号をエアトレーサーのGPIO入力にコネクテッドしたエアトレースをキャプチャすることは可能でしょうか?   問題が再現された後、PA/LNA信号に何らかの変化が見られるかどうかを確認したいと考えています。 回答3:   「一部のデバイス」とは、特定のスマホモデルがアプリケーション内でメモリリークを引き起こし、他のモデルはそうでないという意味ですか?   もしそうなら:   どのデバイスで問題が発生していますか？   CAN、SDKのクリーンな例アプリケーションでも同じ問題を再現できるか確認できますか?  

Number of supported endpoints on the iMX8 The iMX8 uses the DWC3 for USB, which is an xHCI controller. When I read out the register from iMX8 i can figure out, that it may support up to 64 devices. But when I attach a few devices I much earlier on run in xHCI resource error. It seems there is some kind of a limitation on the number of endpoints, and it also seems that it depends on the type of transfer type (Bulk, Control, ...). On the type of devices I use (includsing the hubs) it seem I run after 80 endpoints into the problem. Could you please provide some exact numbers/formula how many endpoints are supported. Re: Number of supported endpoints on the iMX8 Hello,  The i.MX8 xHCI MaxSlots = 64 value specifies the maximum number of enabled USB device slots, not the total endpoint capacity. xHCI is up to 31 endpoint contexts per device, but the controller does not guarantee that all 64 slots can simultaneously use the maximum number of endpoints. The usable total depends mainly on periodic bandwidth, device speed, endpoint interval and packet size, hub topology, Transaction Translator allocation and DWC3 implementation resources.   Please refer xHCI specification for detailed information.

CLRC663をP2Pデバイスとして使用する こんにちは、 CLRC663 plusをピアツーピア（P2P）デバイスとして使用したいと考えています。データシートによると、CLRC663はISO/IEC 18092に準拠したパッシブイニシエータモードのP2Pモードをサポートしています。 しかし、これによって多くの疑問が生じる。 2台のCLRC663デバイスを相互に通信させることは可能ですか？ そうでない場合、CLRC663は別のデバイスと組み合わせるべきでしょうか？どちらがお勧めですか？ ISO 18092プロトコルを有効化するにはどうすればよいですか？他のプロトコルについては、 AN12657にCLRC633のLoadProtocol機能を使用して他のプロトコルをアクティブ化する方法が少なくとも記載されていることがわかりましたが、データシートにはISO 18092プロトコルに関する情報が一切ありません。これら2つの起動方法もデータシートからは全く不明ですが、このアプリケーションノートから推測できます。 パッシブイニシエーターモードで2台のデバイスが通信できますか? この件に関してフォーラムに投稿されている記事はほぼ全て確認しましたが、役に立つ情報は何も見つかりませんでした。NFCリーダ Libraryも見ましたが、P2Pに関して有益な情報は見つかりませんでした。 敬具 Re: Using CLRC663 as P2P device こんにちは、 NXPセミコンダクターズ製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます CLRC663はNFCフォーラムの規格に完全に準拠しておらず、リーダー/ライターモードでの使用を想定しています。したがって、CLRC663は必要なターゲットモードをサポートする(すなわちHCE）。標準的なISO/IEC 18092のP2P接続については 、PN5190の評価を検討してみてください。 しかし、このハードウェアの考慮も利用可能なサポートと併せて評価する必要があります。NXP NFCリーダライブラリでは、P2P機能の維持管理が中止されることにご注意ください。以前のライブラリリリースにはレガシーP2Pサポートが含まれていますが、現在のソフトウェアベースラインではP2P機能はサポートされていません。 よろしくお願いします、 アロンドラ

使用 CLRC663 作为 P2P 设备 你好， 我们希望将 CLRC663 plus用作点对点 (P2P) 设备。根据数据表，CLRC663 支持符合 ISO/IEC 18092 标准的被动启动器模式下的 P2P 模式。 但这又引发了一系列问题： 两个 CLRC663 设备之间可以相互通信吗？ 如果不行，CLRC663 是否应该与其他设备组合使用？哪种更推荐？ 如何激活 ISO 18092 协议？对于其他协议，我发现AN12657至少描述了如何使用 CLRC633 上的LoadProtocol功能激活一些其他协议，但数据手册缺少有关 ISO 18092 协议的任何信息。从数据手册中也完全不清楚另外两个功能的激活方式，但可以从本应用说明中推断出来。 两个设备能否在被动启动器模式下通信？ 我几乎已经查看了论坛上所有与此相关的帖子，但没有找到任何有用的信息。我也看过 NFC读取器库，但找不到任何关于 P2P 的有用信息。 亲切的问候 Re: Using CLRC663 as P2P device 你好， 感谢您对恩智浦半导体产品的关注，也感谢您给我们提供支持的机会。 CLRC663 不完全符合 NFC Forum 标准，并且是为读写器模式设计的。因此，CLRC663 可以与支持所需目标模式的不同 NFC 设备一起使用（即 ）。HCE）。对于标准的 ISO/IEC 18092 P2P 连接，您可以考虑评估PN5190 。 但是，这种硬件方面的考虑也必须与可用的支持结合起来评估。请注意， NXP NFC读取器库声明其 P2P 功能维护已停止。虽然早期的库版本包含对传统 P2P 的支持，但我们当前的软件基线不支持 P2P 功能。 此致， 阿隆德拉

ZSDK BLE主机资质参考似乎已过时 nxp-zsdk 版本说明中提到的 BLE 主机资格认证参考的是一个非常古老的资格认证。 例如nxp-zsdk 4.4状态； BLE主机，DN#: Q305748，链路*:主机资质 BLE 控制器， DN#: Q380314，链接*:控制器资质 *：需要 BLE SIG 帐户。 此主机资质要求支持 BLE 5.4。 控制器明确支持 BLE 6.1。 为了支持控制器的所有功能，主机需要相同或更高的 BLE 级别。 所以我认为版本说明中的参考有误，您能提供正确的参考吗？ 此致，托尼 Re: ZSDK BLE host qualification references seems obsolete 嗨，克里斯汀， 感谢你的回复。我还有一个关于蓝牙主机认证的后续问题。 版本说明链接至https://qualification.bluetooth.com/ListingDetails/227830 ，这表明： Bluetooth Host Solution Zephyr，2024-09-16 ( www.nxp.com ) 核心规格：主机 5.4，活动 这是两年前针对 BLE 5.4 的主机认证，而控制器则针对 BLE 6.1 进行了认证。如果我们按照这些标准来评判我们的产品，我们就不能声称其性能高于 BLE 5.4。 您提到了 BLE 6.3 的新主机认证，但版本说明中没有引用它。这就引出了两个问题： 我们的控制器符合 6.1 版本标准，主机符合 6.3 版本标准，那么我们的产品可以声明为哪个 BLE 版本？ 版本说明能否引用 Zephyr 项目/Linux 基金会主机认证信息（例如https://qualification.bluetooth.com/ListingDetails/332380 ）？只有当我们能在自己的资质认证中使用它时，提供主办方参考信息才对我们有帮助。 提前谢谢您。 此致， 托尼 Re: ZSDK BLE host qualification references seems obsolete 嗨， @tobg 感谢您的回复。 我查看了您提到的标签 ，NXP Zephyr 项目 v4.4.0将于2026 年 5 月 11 日版本。 我们还有另一个更新的 NXP 低功耗蓝牙 Host Stack Zephyr DN: Q393055，于2026-7-30获取。这意味着，我们在版本说明中没有列出错误的 BLE 主机 QDID： nxp-zsdk/doc/wireless/release-notes/topics/rw610rw612_release_notes.md at nxp-v4.4-branch · nxp-zephyr/nxp-zsdk · GitHub 。 实际上应该是旧的 QDID 号码：DN#: Q305748。 但我想要纠正你的理解，主机和控制器不需要具有相同的蓝牙核心规范版本。主机和控制器被认定为独立的蓝牙子系统，符合 Core 5.4 标准的主机可以与符合 Core 6.1 标准的控制器一起使用。 如果您对此帖还有其他疑问，请告诉我。 否则，请随时将我的回答标记为此问题的解决方案，谢谢！ BR， Christine。 Re: ZSDK BLE host qualification references seems obsolete 嗨， @tobg 请问您使用的是哪款BLE产品？ 我查看了您提供的链接，上面是RW610和RW612，所以我想和您确认一下您使用的是RW610还是RW612？ 这样我就可以帮你查一下了。 BR， Christine。 Re: ZSDK BLE host qualification references seems obsolete 它的NXP RW612。 谢谢托尼 Re: ZSDK BLE host qualification references seems obsolete 嗨，克里斯汀， 我们与 NXP RW612 一起使用的 BLE 主机是 Zephyr 项目中的主机，以源代码形式提供。这不是恩智浦半导体（NXP）的软件。 Zephyr 大约每 6 个月发布一个新版本，而 BLE 主机通常每个版本都会发生变化。如果我们只能使用 NXP 认证的 BLE 主机，那么我们就只能使用一个 Zephyr 版本。发行说明中提到的版本现在已经超过两年了（可能是 Zephyr 3.7.0）。从那时到目前的 4.5.0 版本，每个版本都包含了许多网络安全和功能性错误修复。自 3.7.0 版本以来，Zephyr 项目已发布了 61 份蓝牙网络安全公告，其中 43 份针对 BLE。 如果我们只依赖 NXP 的认证，那么 NXP 需要对每个 Zephyr 版本中的主机进行认证。 能否提供一份概述，说明每个 Zephyr 版本应该使用哪个 QDID？例如，Nordic 发布了一份类似这样的矩阵： https://docs.nordicsemi.com/r/bundle/comp_matrix_nrf52840/page/comp/nrf52840/nrf52840_ble_qdid_qual_matrix.html?section=nrf52840_ble_qdid_qual_matrix__sd-fn （在 Nordic 的矩阵中，他们的 SDK 版本号与 Zephyr 版本号不同。） 此致， 托尼 Re: ZSDK BLE host qualification references seems obsolete 嗨， @tobg 我查看了此链接中的所有分支： nxp-zsdk/doc/wireless/版本-notes/topics/rw610rw612_release_notes.md，位于 nxp-v4.4-branch · nxp-zephyr/nxp-zsdk · GitHub 我们已经在每个版本说明中列出了 QDID。即使 QDID 相同，也意味着它们都基于我们 NXP 的相同认证。 我们只有 2 个基于 Zephyr 的 QDID，一个在 2024 年，另一个在 2026 年。 继 2026 年发布这个新的 QDID 之后，我们的 GitHub 上将不再发布任何其他新版本： nxp-zsdk/doc/wireless/版本-notes/topics/rw610rw612_release_notes.md 位于 nxp-v4.4-branch· nxp-zephyr/nxp-zsdk · GitHub 所以我认为在未来的 nxp-zephyr 版本中，我们可能会修改版本说明，以提及新的 QDID。 如果您还有其他疑问，请告诉我。 BR， Christine。 Re: ZSDK BLE host qualification references seems obsolete 嗨，克里斯汀 NXP 更新了 BLE 4.4.0 的认证信息，这很好。即使版本说明中没有提到这一点。 如果是这样，Zephyr BLE 主机在 Zephyr 3.7 和 4.4.0 之间发生了变化，但 nxp-zsdk 并未对中间的任何版本进行认证。 从 4.5.0 版本开始，你们有什么计划？我们需要每次发布 nxp-zsdk 版本时都包含一个合格的 BLE 主机，无论主机何时发生更改。 此致，托尼 Re: ZSDK BLE host qualification references seems obsolete 嗨， @tobg 我们的控制器符合 6.1 版本标准，主机符合 6.3 版本标准，那么我们的产品可以声明为哪个 BLE 版本？ ==>[克里斯汀]:是的，你说得对。我认为你们的产品只能用于 6.1 这个较低版本。但需要指出的是，当您申请产品认证时，蓝牙技术联盟还会检查主机和控制器的 ICS 详细信息以及您在申请表中输入的我的类型。 版本说明能否引用 Zephyr 项目/Linux 基金会主机认证信息（例如https://qualification.bluetooth.com/ListingDetails/332380 ）？只有当我们能在自己的资质认证中使用它时，提供主办方参考信息才对我们有帮助。 ==>[Christine]：具体可以参考哪个主机 QDID 取决于您使用的 Zephyr 主机协议栈。此链接仅适用于Linux 基金会提供的 Zephyr RTOS LE 主机。如果您指的是 NXP 的低功耗蓝牙主机协议栈 Zephyr，那么我不建议您参考此链接，而是参考我们 NXP 的 QDID。 BR， Christine。 Re: ZSDK BLE host qualification references seems obsolete 嗨，克里斯汀 NXP 针对 4.4.0 版本更新了 BLE 认证，这很好，但是发行说明中没有提到这一点。 Zephyr BLE主机在Zephyr 3.7和4.4.0之间发生了变化，但在 nxp-zsdk 中，他没有资格参与中间的任何版本发布。 从 4.5.0 版本开始，你们有什么计划？我们需要每次发布 nxp-zsdk 版本时都包含一个合格的 BLE 主机，无论主机何时发生更改。 此致，托尼 Re: ZSDK BLE host qualification references seems obsolete 嗨， @tobg 感谢您的回复。 是的，我们当然有针对未来 Zephyr SDK 的规划。但具体的日程安排，请允许我花些时间向我们的内部团队核实。 一旦得到确认信息，我会通知你。 BR， Christine。

[亿联]关于ASHA丢包、蓝牙压力测试断开连接的咨询， 尊敬的恩智浦NXH支持团队： 感谢您之前建议使用以下 API 和事件来解决 NXH2004 ASHA DSP 不同步问题： AUDIO_ConfigureLlSyncParams() kAUDIO_Event_LlOutOfSync AUDIO_ForceSharedBufResync() 在 ASHA 回放和重新连接测试期间，我们观察到在重新同步调用返回 kStatus_Success 后，反复出现不同步事件。我们还观察到，在某些时期，有效的编码音频继续写入共享缓冲区，但通过 AUDIO_GetDspSharedBufInfo() 获取的 currentBufferRowNumber 和 nextExpectedTimestamp 在相隔约 5 秒的样本之间保持不变。 我们的项目目前仅限于 SDK 6.2。对于之前报告的持续静默问题，我们希望能够澄清使用 SDK 6.2 的推荐恢复程序和预期结果。 1. 预期恢复结果及成功确认 一旦无线链路稳定，有效的音频数据和时间戳恢复，您建议的步骤是否能够在不 RESET NXH2004 或故意断开 BLE 连接的情况下恢复持续正常的音频播放？ 当 AUDIO_ForceSharedBufResync() 返回 kStatus_Success 时，这是否意味着 DSP 命令已成功完成，还是意味着 DSP 实际上已恢复同步？ 请澄清： 是否存在同步恢复事件或用于查询同步状态的 API？ 如果不再发生不同步事件，或者 DSP 行和预期时间戳恢复正常，是否足以确认恢复成功？ 建议观察多长时间以验证恢复情况？恢复有效输入后，同步和正常播放需要多长时间才能恢复？ 哪些故障情况无需 RESET 设备即可恢复，哪些故障情况需要不同的恢复程序？ 2. 建议的恢复程序和重复事件处理方法 请确认针对这两种不同步原因的建议处理方法： 对于 kAUDIO_LlOutOfSync_Sync_Lost_During_Playback 错误，应用程序应该立即调用重新同步功能，还是应该先等待无线电链路稳定？应该使用哪些 SDK 信息来判断链路是否稳定？ 对于 kAUDIO_LlOutOfSync_Sync_Not_Achieved_At_Start，UM11981 §4.4.3 建议停止并重新启动音频链。执行 AUDIO_StopChains() 后再执行 AUDIO_StartChains() 是否足够，还是必须释放链并重新配置，包括重新应用 QoS 或 LL 同步参数？ 请具体说明如何处理共享的 FIFO、应用程序缓冲区和时间戳状态，以及建议的稳定时间、重试间隔和重试限制。 我们观察到，在重新同步之后、在执行任何链重启之前，以及在应用程序级 ASHA 会话保持活动状态时链重启之后，都会出现 Sync_Not_Achieved_At_Start 错误。能否解释一下与这两种情况相关的DSP状态转换？ 如果在恢复命令成功返回后又发生了其他不同步事件，应用程序应该如何区分： 出现新的同步故障； 正在进行的同步尝试尚未完成； 这是先前失败导致的延迟事件吗？ 这些恢复 API 可以直接从音频事件回调中调用，还是应该延迟到某个任务中调用？请同时说明音频API调用是否有序列化要求。 3. 当DSP处理不进行时，进行检测和恢复 您之前提到过，并非所有静音条件都会生成 kAUDIO_Event_LlOutOfSync。 当有效编码音频持续写入，但 DSP 行和预期时间戳没有更新时，您推荐使用哪种 SDK 支持的方法来区分停止消费和正常的同步等待情况？ 我们还观察到，在观察间隔内累积的丢包指示计数可能为零，而 DSP 信息保持不变。丢包计数为零能否作为正常解码的证据？在什么情况下丢包或不同步的指示会停止？ 如果共享缓冲区重新同步无法解决此问题，请提供推荐的恢复方法。 对于无响应的 DSP，共享缓冲区读取和同步恢复命令能否保证在限定时间内返回？您推荐怎样的超时和错误处理程序？ 收到 kAUDIO_Event_WatchdogIndication 后，是否支持继续调用音频 API 尝试本地恢复，还是必须遵循特定的 RESET 程序？ NXH2004 NXH2004SDK @Nasser_F能否请您帮忙看一下，谢谢！ Re: [Yealink]Inquiry regarding ASHA packet loss, Bluetooth stress test disconnection, 以下是该问题出现之前的一些历史通信记录。 答案 1： 是的，有一个可行的解决方案可以解决 DSP 不同步问题，而无需重启 NXH2004。 我们引入了以下 API 和事件： AUDIO_ConfigureLlSyncParams() AUDIO_ForceSharedBufResync() 事件：kAUDIO_Event_LlOutOfSync 要使用这些新 API 解决 DSP 不同步问题，请按照以下步骤操作： 使用 AUDIO_ConfigureLlSyncParams() 配置同步超时。 监测 kAUDIO_Event_LlOutOfSync 事件。 当 DSP 在超过通过 AUDIO_ConfigureLlSyncParams() 配置的超时时间的连续时间内未收到有效时间戳时，DSP 会生成 kAUDIO_Event_LlOutOfSync。 请注意，并非所有静音条件都会触发信号 kAUDIO_Event_LlOutOfSync；只有超过配置的超时值的条件才会触发信号该事件。 收到 kAUDIO_Event_LlOutOfSync 时，调用 AUDIO_ForceSharedBufResync()。 答案 2： 我们目前尚未发现 SDK 6.2 中存在任何会遗漏断开连接事件的问题。 您能否详细说明一下您是如何发现这个问题的？ 您在故障耳机的日志中是否看到任何错误消息，例如硬故障事件？如果可以重现该问题，能否在将 PA/LNA 信号也连接到空气跟踪器的 GPIO 输入端的情况下，捕获空气跟踪信号？ 我想确定在问题重现后，PA/LNA 信号上是否有任何活动。 答案 3： 您所说的“某些设备”是指某些手机型号会导致应用程序出现内存泄漏，而其他手机型号则不会吗？ 如果是这样： 哪些设备出现此问题？ 您能否确认使用 SDK 中的全新示例应用程序是否也能重现此问题？

i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi Team, We are using a custom i.MX95 board with the OV5640 camera sensor and are facing an issue when the camera is connected to CSI1 on Android Automotive 16. The hardware design has already been validated: - CSI0 and CSI1 work correctly with Linux 6.18.20. - CSI0 and CSI1 also work correctly with Android 16 based on Linux 6.18.20. - The issue is observed only with Android Automotive 16 based on Linux 6.18.20. Observations: - CSI0 works without any issues. - CSI1 fails to start streaming. - We tested CSI1 independently. - We also disabled NEO ISP and tested with the ISI pipeline only, but the issue persists. Observed errors: LIBCAMERA: Failed to start streaming: Connection timed out LIBCAMERA: 'mxc_isi.0': Unable to set format on pad 0/0: Device or resource busy Log and media-ctl validation results are attached for reference. Has anyone encountered a similar CSI1 issue on i.MX95 EVK or Android Automotive 16? Any suggestions, fixes, patches, or confirmation of CSI1 validation on the EVK would be greatly appreciated. Thanks, Maruti Naik Evaluation Board Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi, We have verified that the kernel DTS configuration is correct. The current Android Automotive 16 BSP is also based on Linux 6.18.20, and the same DTS configuration is working without any issues in the Linux 6.18.20 BSP. We have also successfully tested and validated the CSI1 with OV5640 camera in Android Automotive 15 BSP. Could you please confirm whether there are any restrictions or limitations on CSI1 camera support in the latest Android Automotive 16.0.0_2.1.0 BSP? Are any additional changes required to enable CSI1 camera support in this release? Kindly clarify. Regards, Maruti Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue I checked AAOS, which support csi0 as default, current bsp doesn't support mipi dsi/csi for camera, you should change the dts, camera configure, did you change anything? if yes, share the detailed your changed steps and code Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi @joanxie Any update on this issue? Kindly share your findings or provide some technical guidance to help us resolve the CSI1 camera issue. Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Dear @joanxie  Yes, our B0 board design is based on the NXP i.MX95 19x19 EVK. For your information, the same hardware is working with Linux 6.18.20 and Android 16 based on Linux 6.18.20. Both CSI0 and CSI1 (CSI-DSI combo) are working with dual OV5640 cameras. We are using Android Automotive 16.0.0_2.1.0 (based on 6.18.20_2.0.0 BSP), which uses the same kernel version and kernel configurations. However, with the Android Automotive 16.0.0_2.1.0 BSP, the OV5640 camera is working on CSI0, but the OV5640 camera on CSI1 (CSI-DSI combo) is not working. The logs have already been shared. We currently do not have an i.MX95 B0 EVK board available (we have an A1 EVK board), so we are unable to test this on the EVK. It would be helpful if you could test the CSI1 (CSI-DSI combo) with any supported camera on the NXP i.MX95 19x19 EVK B0 board using the latest Android Automotive 16 BSP and share your findings. Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi Maruti did your board design based on imx95 evk board? if yes, did you reproduce this on nxp imx95 evk board? and what detailed auto android 16 bsp version? 1.1.0 or 1.3.0? B.R. Joan Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue I will double confirmed this from android auto team again, but they didn't say auto android 16 has any limitation before, based on your test result, it seems this issue is related to the auto android 16 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi, In our testing, on the Android Automotive 15 BSP, both CSI0 and CSI1 cameras worked correctly with both the Car image (EVS running on the M7 core) and the Car2 image (EVS running on the A55 core). On Android Automotive 16 BSP, with the Car image (EVS running on the M7 core), CSI0 works, but CSI1 does not. However, with the Car2 image (EVS running on the A55 core), both CSI0 and CSI1 work correctly. Could you please check if any background process in the Car image is accessing or holding CSI1, preventing the camera from working? Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Dear @joanxie, I have one update regarding the CSI1 camera issue. With the Car2 image, both CSI0 and CSI1 cameras are working fine. However, with the Car image, we are still facing an issue getting the CSI1 camera working. Kindly help us investigate and resolve the CSI1 camera issue in the Car image. Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Dear @joanxie, Thank you for your support. Could you please provide any workaround or patch to enable CSI1 (DSI-CSI combo) support for camera validation on Android Automotive 16.0.0_2.1.0? Your assistance would be highly appreciated. Best regards, Maruti Naik Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Dear @joanxie We are currently using the Car image and are not focusing on EVS for now. Our requirement is to enable and validate the CSI1 camera directly through the Camera application. Kindly help us resolve the CSI1 camera issue Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue I don't think auto android team tested csi1 before, since the default is for csi0 only,  did you need EVS and Camera APK functions ? and did you use Car2 image type? Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue what do you mean car2 image? do you mean with  EVS in Arm Cortex-A core? since you tested on auto android 15 successfully, what do you test on auto android 15？ do you mind sharing your patches to double check? Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue could you give me the two log files for car2 and car image? only for  csi1, and could you try  try to use the same CM7 FW version from AA15 to AA16.0 2.1.0? 

ZSDK BLE host qualification references seems obsolete The BLE host qualification references in nxp-zsdk release notes refers to a very old qualification. E.g. nxp-zsdk  4.4 states; BLE Host, DN#: Q305748, Link *: Host qualification BLE Controller, DN#: Q380314, Link *: Controller qualification *: Requires BLE SIG account. This host qualification specifies BLE 5.4 support. The controller specifies BLE 6.1 support. To support all the features of the controller, the host would need the same BLE level or higher. So I think that the reference in the release notes are wrong, can you provide the correct references? Regards Tonny Re: ZSDK BLE host qualification references seems obsolete Hi, @tobg  Thanks for your reply. I checked the tag you mentioned NXP Zephyr project v4.4.0  is release on May 11 2026. And we have another newer NXP Bluetooth Low Energy Host Stack Zephyr DN: Q393055 is gotten on 2026-7-30. It means, we did not list the wrong BLE host QDID in the release note:nxp-zsdk/doc/wireless/release-notes/topics/rw610rw612_release_notes.md at nxp-v4.4-branch · nxp-zephyr/nxp-zsdk · GitHub. It actually should be the old QDID number: DN#: Q305748. But I want to correct your understandings, Host and Controller does not need to have matched Bluetooth Core Spec version. The Host and Controller are qualified as separate Bluetooth subsystems, and a Host qualified against Core 5.4 can be used with a Controller qualified against Core 6.1. Please let me know whether still have any other concerns on this thread. Otherwise, please do not hesitate to mark my answer as a solution for this case, Thanks! BR, Christine. Re: ZSDK BLE host qualification references seems obsolete Hi Christine, Thank you for your reply. I have a follow-up question about the Bluetooth host qualification. The release note links to https://qualification.bluetooth.com/ListingDetails/227830, which shows: Bluetooth Host Solution Zephyr, 2024-09-16 (www.nxp.com) Core Specification: Host 5.4, Active This is a two-year-old host qualification at BLE 5.4, while the controller is qualified for BLE 6.1. If we qualify our product against these listings, we can’t claim anything higher than BLE 5.4. You mentioned a newer host qualification for BLE 6.3, but the release note doesn’t reference it. That raises two questions: With a controller qualified for 6.1 and a host qualified for 6.3, which BLE version can we claim for our product? Could the release notes refer to the Zephyr Project / Linux Foundation host qualification instead (for example https://qualification.bluetooth.com/ListingDetails/332380)? Including a host reference only helps us if we can use it in our own qualification. Thank you in advance. Best regards, Tonny Re: ZSDK BLE host qualification references seems obsolete Its NXP RW612. Thanks Tonny Re: ZSDK BLE host qualification references seems obsolete Hi, @tobg  Can you please let me know which BLE product are you using? I checked in the link you provided, it is RW610 and RW612, so I prefer to confirm with you that you are using RW610 or RW612? So that I can check for you. BR, Christine. Re: ZSDK BLE host qualification references seems obsolete Hi Christine, The BLE host we use with the NXP RW612 is the one in the Zephyr project, delivered as source code. It is not NXP software. Zephyr has a new release every 6 months or so, and the BLE host usually changes with each release. If we may only use BLE hosts that NXP has qualified, we are tied to one Zephyr version. The release notes refer to a version that is now more than two years old (probably Zephyr 3.7.0). Every release since then, up to the current 4.5.0, has included many security and functional bug fixes. Since 3.7.0, the Zephyr project has published 61 Bluetooth security advisories, 43 of them for BLE. If we are to rely only on NXP’s qualification, NXP would need to qualify the host for each Zephyr release. Could you send us an overview of which QDID to use for each Zephyr release? Nordic publishes a matrix like this, for example: https://docs.nordicsemi.com/r/bundle/comp_matrix_nrf52840/page/comp/nrf52840/nrf52840_ble_qdid_qual_matrix.html?section=nrf52840_ble_qdid_qual_matrix__sd-fn (In Nordic’s matrix, their SDK version numbers are different from the Zephyr version numbers.) Best regards, Tonny Re: ZSDK BLE host qualification references seems obsolete Hi Christine It is nice that NXP has an updated BLE qualification for 4.4.0, even though the release notes don’t mention it. If so, the Zephyr BLE host changed between Zephyr 3.7 and 4.4.0 but wasn’t qualified in nxp-zsdk for any of the releases in between. What are your plans from 4.5.0 onward? We need each nxp-zsdk release to include a qualified BLE host whenever the host has changed. Regards Tonny Re: ZSDK BLE host qualification references seems obsolete Hi, @tobg  I checked all of the branches in this link, nxp-zsdk/doc/wireless/release-notes/topics/rw610rw612_release_notes.md at nxp-v4.4-branch · nxp-zephyr/nxp-zsdk · GitHub we already listed the QDID in each Release note. Even it is the same QDID, it means all of them are based on our NXP's same certification. We only have 2 Zephyr based QDID, one is in 2024, another is in 2026. And after this new QDID in 2026, there is still no other new release on our github: nxp-zsdk/doc/wireless/release-notes/topics/rw610rw612_release_notes.md at nxp-v4.4-branch · nxp-zephyr/nxp-zsdk · GitHub So I think in the future nxp-zephyr release, we might modify the release note to refer to the new QDID. If you have any other concerns, please let me know. BR, Christine. Re: ZSDK BLE host qualification references seems obsolete Hi, @tobg  With a controller qualified for 6.1 and a host qualified for 6.3, which BLE version can we claim for our product? ==>[Christine]:Yes, you are right. I think your product can only be claimed  for 6.1 as the lower version. But need to point out that when you apply for the certification for your product, the Bluetooth Sig will also check the details of host and Controller's ICS and what kind of profiles you input in the application form. Could the release notes refer to the Zephyr Project / Linux Foundation host qualification instead (for example https://qualification.bluetooth.com/ListingDetails/332380)? Including a host reference only helps us if we can use it in our own qualification. ==>[Christine]:Which host QDID can be referred to depends on which Zephyr Host Stack you are using.  This link is only applicable to Zephyr RTOS LE host from the Linux Foundation. If you are referring to NXP Bluetooth Low Energy Host Stack Zephyr, then I do not recommend you to refer this link, but our NXP's QDID. BR, Christine. Re: ZSDK BLE host qualification references seems obsolete Hi Christine Its fine that NXP has an updated BLE qualification for 4.4.0, but the release note don’t mention it. The Zephyr BLE host changed between Zephyr 3.7 and 4.4.0, but wasn’t qualified in nxp-zsdk for any of the releases in between. What are your plans from 4.5.0 onward? We need each nxp-zsdk release to include a qualified BLE host whenever the host has changed. Regards Tonny Re: ZSDK BLE host qualification references seems obsolete Hi, @tobg  Thanks for your reply. Yes, for sure, we have plan for the future Zephyr SDK.  But for the detailed schedule, please allow me some time to check with our internal team. Once have confirmed info, I will let you know. BR, Christine.

i.MX 8M Quad Evk I2C interface I need to interface an AM/FM tuner module with the NXP i.MX 8M Quad EVK using the I2C interface for tuner configuration and control. Could you please guide me on how to establish this hardware interface. Additionally, does the i.MX 8M Quad EVK expose I2S signals that can be used to receive digital audio output from the tuner module? If so, could you please share the relevant connector details and pin mapping? Re: i.MX 8M Quad Evk I2C interface Hello, Yes, the MCIMX8M-EVK has J801 connector to access I2C2 of the processor. Regarding access to I2S interface will be a little bit more difficult since an adapter will be needed. These signals are connected to M.2 KEY-E J1401 connector or J1801 connector. Please check it in the next design file: Design Files for the i.MX 8M Evaluation Kit (EVKB) Best regards.

在 PN5190B2 上移植固件更新 我想将NFC固件更新库代码移植到我的控制器上。我不太清楚应该在SW6592中包含哪些库，又应该移除哪些库，才能实现SPI主机目标通信和固件更新。主机是我的控制器，目标是NFC PN5190B2设备。 我需要将我的控制器移植到您的固件更新SW6592示例代码中的步骤。 此外，还要列出需要删除的不必要的库或代码文件……仅需进行必要的移植。

S32DS 应用中无法检测到 S32K344 HMS 板。 在 S32DS 中，我能够构建我的项目，但在 S32k3 板上进行调试或烧录时，我无法在 PEMicro 调试器的端口选项中检测到该 S32K3 板。即使按照正常方式，我通过 USB 电缆连接检查设备管理器是否显示已连接，但设备管理器也无法检测到这块 S32K344 HMS 板。#S32k344             Re: Unable to detect S32K344 HMS Board in S32DS application. 你好@Amit8863 板载LED指示灯似乎工作正常。 会不会是另一个 S32DS 实例或其他 IDE 当前正在使用此调试器？ 然而，板载调试器（ PEMicro OpenSDA 调试驱动程序） ）未出现在设备管理器中。请在插入USB线缆后查看我的设备管理器。请使用带有 D+ 和 D- 信号线的 USB 数据线。 板载调试器由 PEMicro 提供，建议下载最新的“USB 多链路资源安装程序”，该安装程序可从“支持与下载”类别下的“多链路调试探针”页面获得。安装完成后，打开PEFirmwareConfig.exe文件，该文件位于 C:\PEMicro\Multilink_Resources 目录下，用于检查固件版本。选择硬件类型：Multilink ACP Embedded - OnBoard Arm 调试接口然后检查是否有可用更新。 然后，应在 S32DS PEMicro 接口设置的端口字段中检测到“嵌入式多链路 Rev A ”。 此致敬礼， Robin Re: Unable to detect S32K344 HMS Board in S32DS application. 嗨@Robin_Shen 我在这里找不到像您截图中显示的那样选择设备的选项。但我这边什么都没显示。请问我如何才能获得选项？ 顺祝商祺！ 阿米特

[KW45B41Z] J-Link GDB 服务器错误：无法连接到自定义硬件上的目标 亲爱的团队， 我遇到了上述问题。请帮我解决这个问题。 硬件：定制板，搭载 KW45B41Z 芯片；调试器：SEGGER J-Link；IDE：MCUXpresso 尝试对我的定制 KW45B41Z 板进行烧录/调试时，J-Link GDB 服务器抛出以下弹出错误：“J-Link GDB 服务器报告了一个错误。原因：错误：无法连接到目标。 我附上了我的IDE和错误弹出窗口的截图。当J-Link在自定义设计中连接失败时，针对这款特定的MCU，建议的故障排除步骤是什么？

S32K358：闪存编程失败/CPU无法停止（PEmicro & J-Link） NXP团队/社区的各位好， 我遇到了一个问题，无法使用 PEmicro（在 S32 Design Studio 中）或 SEGGER J-Link Commander 对我的 S32K358 板进行刷写或恢复。调试器能够与 ARM CoreSight DAP 通信，但闪存编程失败，CPU 无法停止。 1. 环境： MCU： NXP S32K358 IDE： S32平台S32设计工作室 v3.6.6 调试探针： PEmicro Multilink / OpenSDA（插件版本 6.2.4） SEGGER J-Link Lite V9 (DLL v9.90) 接口： SWD（500 kHz / 1000 kHz） 项目： FreeRTOS LED切换示例 2. 症状和观察到的行为： A. S32 设计工作室中的 PEmicro： 启动调试会话时，PEmicro 连接到 SWD 接口，验证了 DAP ID (0x6BA02477)，但闪存编程失败： 信息：DAP IDCODE = 0x6BA02477 PEmicro GDB 启动失败：闪存编程期间出错。终止调试会话。 PE错误：下载到设备时出错。调试会话结束。   如果我尝试在 S32DS 中使用“通过完全芯片擦除进行设备恢复”选项，PEmicro 返回： “警告 - 不支持批量擦除。”请联系 PEmicro 获取支持。 B. SEGGER J-Link Commander： 在 J-Link Commander 中，探针检测到 DAP 并解锁设备： InitTarget() start SDA_AP detected Unlocking device if necessary... Locked device detected. Proceeding with the unlock procedure... Device successfully unlocked Found SW-DP with ID 0x6BA02477 CPUID register: 0x411FC272 Found Cortex-M7 r1p2, Little endian. 但是，当尝试停止 CPU 或运行擦除操作时： SetupTarget() start WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1. Initializing ECC RAM... Timeout while initializing ECC RAM WARNING: CPU could not be halted ****** Error: Could not start CPU core. (ErrorCode: -1) Cannot read register 0 (R0) while CPU is running J-Link> erase 'erase': Performing implicit reset & halt of MCU. WARNING: CPU could not be halted ****** Error: Failed to halt CPU. Erasing device... WARNING: CPU could not be halted Cannot access the watchdog SWT0 instance. ****** Error: Failed to preserve target RAM @ 0x20000000-0x20007FFF. ERROR: Erase returned with error code -1. 3. 已检查内容： 硬件 SWD 连接和电源功能正常（DAP ID = 0x6BA02477 和 CPUID = 0x411FC272 读取正确）。 该设备未永久安全（J-Link 确认使用默认密码解锁设备）。 已选择 PEmicro 默认算法 nxp_s32k358_1x32x2036k_hse_disabled.arp。 4. 问题： 如果 S32K358 的闪存内容触发信号立即硬故障/锁定或看门狗复位循环，推荐的恢复程序是什么？ 由于 S32K3 不支持批量擦除，当内核拒绝停止在 RAM 中运行时，我们如何通过 PEmicro 或 J-Link 强制擦除闪存扇区？ S32K358 是否需要特定的 RESET 序列或脚本来绕过应用程序的早期执行并恢复闪存访问？ 谢谢你的帮助。   Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) 你好@shreevalya135 ， 您可以尝试一下这个帖子里的解决方法： https://community.nxp.com/t5/S32-SDK/failed-to-power-up-dap-after-program-s32k312-with-pll0-equal/td-p/1609010 日志有所不同，但我很好奇，如果使用 JTAG 而不是 SWD 并将 MCU 保持在 RESET 状态，是否可以解决这个问题。 此致， 丹尼尔 Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) 你好@shreevalya135 ， 谢谢你提供的详细信息。 2 和 3。 调试器使用专有的 SEGGER 和 PEmicro 算法。您也可以联系他们以获取有关日志的更多详细信息。 1. 很难说。板载调试器也是一个 PEmicro 调试器。理论上，SRAM 可能会损坏，从而阻止调试器加载擦除和编程 MCU 所需的数据和编程例程。 4 和 5。 我们没有任何推荐的脚本。能否使用 J-Link Commander 访问 MDM-AP 状态寄存器和控制寄存器？ // Select MDM-AP SWDWriteDP 2, 0x06000000 // Read MDMAPSTTS and MDMAPCTL SWDReadAP 0 SWDReadAP 0 SWDReadAP 1 SWDReadAP 1 // Write MDMAPCTL SWDWriteAP 1 0x100 // Cortex-M7_0 debug request 顺祝商祺！ 丹尼尔 Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) 嗨@danielmartynek ， 谢谢你的建议。我们以 1000 kHz 的频率测试了 JTAG 和 SWD 接口，复位线既有钳位 (r0)，也有释放状态 (r1)。 硬件和调试配置： 电路板：FRDM-S32K358 EVK MCU/核心：S32K358 / S32K358_M7_0 IDE：S32 设计工作室 3.6.6 板载调试器：J11 USB-C 外部调试器：SEGGER J-Link Lite V9 (V8.88) 外部连接：J9（JP11 已移除） 目标电压：3.3V 测试结果： 配置结果 JTAG + 复位钳位 失败 SWD + 复位已钳位 失败（DAP 上电错误） JTAG + RESET已释放 失败 SWD + 重置已版本 成功检测到SW-DP和Cortex-M7 虽然 SWD 成功检测到目标，但 ECC RAM 初始化失败。 附加测试： NoDTCM0Init 脚本： ECC RAM 初始化仍然在0x20000010处超时，随后 CPU 停止运行失败。 NoRAMInit 脚本：目标初始化完成，但 CPU 无法停止。报告的 PC 值为0x200002B8 。 内存访问：读取0x00400000处的内部闪存成功，但读取0x20400000处的 SRAM失败。 通过 J11 USB-C 接口的原始编程失败 通过板载调试器进行编程时失败，并出现以下错误： CRC 命令超时 闪存中的当前内容与要编程的应用程序不匹配。 擦除设备闪存时出错 我们测试了禁用 HSE 和启用 HSE 的.arp闪存编程算法，但问题仍然存在。 需要支持： 我们希望您能就以下方面提供指导： 为什么之前运行正常的板突然无法通过板载 J11 调试器进行闪存编程了？ 什么原因会导致CRC 命令超时和闪存擦除错误？ 即使使用 NoDTCM0Init 脚本，为什么 ECC RAM 初始化仍然失败？ 为什么调试器可以使用 NoRAMInit 初始化目标，但却无法停止 CPU？ 是否有针对此 EVK 的 S32K358 专用 J-Link 脚本或调试器配置推荐？ 是否有推荐的恢复步骤来恢复板载调试器和正常的闪存编程？ 感谢您的支持。我们期待您的建议。 Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) 嗨@danielmartynek ， 感谢您的回复和建议。 我使用了一个外置的SEGGER J-Link Lite V9并将其连接到 FRDM-A-S32K358 板的 J9 接口。我已经执行了建议的调试和 MDM-AP 访问测试。以下是完整的连接详情和测试结果。 1.完成 J-Link 连接输出 执行的命令： exec ForceAttachTarget=1 device S32K358_M7_0 si SWD speed 800 connect 连接输出： Device "S32K358_M7_0" selected. Connecting to target via SWD ConfigTargetSettings() start ConfigTargetSettings() end - Took 63us 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 144ms 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 CPUID register: 0x411FC272 Found Cortex-M7 r1p2, Little endian. CoreBaseAddr manually set by user: 0x40250400 SetupTarget() start -- Attach mode active. Skipping halting core & work RAM init (https://kb.segger.com/NXP_S32K3xx#ECC_RAM). SetupTarget() end - Took 87us Memory zones: Zone: "Default" Description: Default access mode Cortex-M7 identified. 2. CPU 和内存访问结果 连接后，执行h和regs 命令显示 CPU 寄存器值无效： PC = CDCDCDCD SP = FFFFFFFD XPSR = CDCDCDCD IPSR = 00D (Reserved) 内存访问测试： 地址结果 0x00400000 成功的 0x00402000 失败 0x20000000 成功的 0x20400000 失败 3. MDM-AP 注册表访问结果 我还尝试了建议的 MDM-AP 操作： SWDWriteDP 2, 0x06000000 SWDReadAP 0 SWDReadAP 1 SWDWriteAP 1, 0x100 所有操作均返回错误，包括 MDM-AP 寄存器读取和写入。 4. 补充观察 在不启用连接模式的情况下，J-Link 在 ECC RAM 初始化期间会失败并报告： Could not start CPU core. (ErrorCode: -1) 5. 需要恢复指导 请问您能否就以下问题提供建议？ 为什么即使 SW-DP 检测和调试访问启用都成功，MDM-AP 访问仍然失败？ ECC RAM 初始化失败时，如何恢复 Cortex-M7_0 内核？ 能否在不成功启动 CPU 的情况下，通过硬件级恢复机制擦除并重新编程内部闪存？ 是否有推荐的步骤可以在不更换电路板的情况下恢复正常的调试和闪存编程功能？ 我们的目标是恢复 FRDM-A-S32K358 板，并恢复正常的调试和闪存编程功能。 恳请您协助我们查明此问题的原因，并推荐合适的恢复程序。任何帮助或建议都将不胜感激。 感谢您的时间和支持。 此致， 什里瓦利亚 Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) 你好@shreevalya135 ， 我无法解释为什么你能加载镜像却无法读取 MDM-AP 寄存器。 我可以在 S32K358 上成功运行该脚本。 device S32K358 si SWD speed 4000 connect sleep 100 // Select MDM-AP, bank 0 SWDWriteDP 2, 0x06000000 sleep 20 // Read MDMAPSTATUS and MDMAPCTL SWDReadAP 0 SWDReadAP 0 SWDReadAP 1 SWDReadAP 1 能否测量一下 RESET_B 引脚，以确定它是否周期性地被钳位？ 谢谢！ 丹尼尔 Re: S32K358: Flash programming fails / CPU cannot be halted (PEmicro & J-Link) 嗨@danielmartynek ， 感谢您的建议和一直以来的支持。恳请您进一步协助我们找回 FRDM-A-S32K358 板。 为了说明情况，我使用的是外部SEGGER J-Link Lite Cortex-M调试器。 产品链接： https://www.segger.com/products/debug-probes/j-link/models/j-link-lite/j-link-lite-cortex-m/ J-Link 连接到J9 连接器， JP11 跳线已移除，我正在使用 SWD 接口。 我试用了J-Flash Lite V8.88和J-Link Commander V9.90 。 我使用 J-Flash Lite 对 SDK 中的 LED 闪烁示例.bin文件进行了编程。它显示擦除和编程成功（“应用程序已成功转储”），但 LED 闪烁应用程序无法在板上运行。 此外，我还尝试了您之前回复中建议的 MDM-AP 命令： SWDWriteDP 2, 0x06000000 SWDReadAP 0 SWDReadAP 1 SWDWriteAP 1, 0x100 但是所有命令都返回错误，我无法访问 MDM-AP 寄存器。 但是，即使使用外部 J-Link，问题仍然存在。调试器检测到了目标，但 ECC RAM 初始化失败，CPU 无法停止。 请问您能否推荐一款适合用于恢复 S32K358 的 J-Link 型号或其他外部调试器？另外，当 CPU 无法停止且 MDM-AP 访问失败时，是否有其他可用的恢复程序？ 感谢您一直以来的支持。

#ftm_pwm_S32K116 こんにちは、NXPの同僚の皆様： ftm_pwm_s32k116プロジェクトについて助けを求めています。実際のところ、コードや設定をどう変えても、MCUはデフォルトチャネル(FTM0-チャネル0、つまりPTD15）。 これが私の手順です。 1.サンプルから新しいプロジェクトをインポートします。 2.コンパイルするとすべて合格し、ピンマルチプレクサとフレックスタイマーの設定を確認しましたが問題はありませんでした（実際にはNXPのサンプルからなので、完全に正しいと思います）。 3.次に、それをS32K116に書き込みます。 4.PTD15の波形を観察しましたが、何も見つかりませんでした。ほぼ2日間試しました。 私のプロジェクトのzipファイルは以下のとおりです。ありがとうございます。 Re: #ftm_pwm_S32K116 プロジェクトを添付してください Re: #ftm_pwm_S32K116 こんにちは、 @Tracy_Lu さん。 まず、プロセッサ Expertを使っているので、古いソフトウェアバージョンを使っているようですね。S32K1デバイスで開発を始める場合は、最新のソフトウェアとツール、現在S32K1_S32M24X リアルタイム・ドライバ AUTOSAR R21-11 バージョン3.0.0の使用をお勧めします(S32K1用のリアルタイム・ドライバ)とS32プラットフォーム向けのS32 Design Studio(S32 Design Studio |NXP Semiconductors)を共同で提供しています。 しかし、S32K1 SDKsを使い続けたい場合は、最新のSDKsバージョンがS32 Design Studio for S32 プラットフォーム 3.4に付属していました。 また、EVBを使っているのかカスタムボードなのか教えていただけますか? 現在のソフトウェア環境を維持したい場合は、使っている正確なS32K1 SDKバージョンも共有していただけると助かります。 BR、VaneB Re: #ftm_pwm_S32K116 こんにちは、NXPの同僚の皆様： 迅速かつプロフェッショナルなご回答ありがとうございます。サンプルから別のプロジェクトS32K116_Project_FTMに変更し、コードを修正しました（gemini AIの支援を受けて）。コンパイルとデバッグ中に問題が発生するエンジニアの方々が解決できるよう、以下の点を共有したいと思います。 1.私はFTM機能を使用して、PMIC（TPS650366）のESM（エラー信号モニタリング）に応答します。 2.at 最初にftm_pwm_S32k116プロジェクトを使い、約2日間コンパイルとデバッグに失敗しました。割り当てられたピンで出力PWMが見当たりません。そして、Gemini AIの助けを借りて正しい設定とデバッグをしているはずです。 3.次に、S32K116_Project_FTM という名前の別の例を見つけ、それを試してコンパイルしましたが、エラーはありませんでした。そして、PTD15(FTM0CH0)/16(FTM0CH1) という構成済みピンの出力が得られました。初期周波数は 1Hz/5Hz ですが、ゴールが近いことがわかりました。 4. 実はPWM周波数は40KHz付近で必要なので、次のステップはシステムの周波数プリスケーラ、MOD値、CnV(デューティサイクル)を変更することだと分かっていますが、MOD値は変更できません(値は変えるだけでMCUのルート場所に書き込めません)。何度も試して、役立つ情報を探しました。 5.最後に、MOD値を変更したい場合は、いくつかの前提条件を満たす必要があることがわかりました。たとえば、クロックを閉じ、書き込み保護を解除する必要があります...。 6.以下はコンパイル後の私のコードで、正常に動作します（PTD16で約48KHzの出力）。 int main(void) { /*! * 初期化: * ======================= */ WDOG_disable(); /* ウォッチドッグを無効にする */ SOSC_init_40MHz(); /* 40 MHz水晶発振器用のシステム発振器を初期化します */ RUN_mode_48MHz(); /* クロックを初期化: 48 MHz システム、コア、バス、 24 MHz フラッシュ。*/    FTM0_init(); /* 8 MHz SIRCDIV1_CLK を使用して FTM0 を初期化します */    //FTM0_CH0_OC_init();    /* FTM0 CH0、PTD15 を初期化 */   FTM0_CH1_PWM_init();    /* FTM0 CH1、PTD16 を初期化 */   FTM0_CH6_IC_init();    /* FTM0 CH6、PTE8 を初期化します  */ FTM1_Init(); FTM1_CH1_PWM_init(); PORT_init(); /* ポートの設定 */   start_FTM0_counter();  /* FTM0カウンタを開始 */   /*! * 無限： * ======================== */ のために（;;）   { //FTM0_CH0_output_compare();/* 出力比較が一致した場合: */   /* ピンの切り替え（ハードウェアによる自動切り替え） */   /* フラグ 8 をクリア */   /* リロードタイマー */ //FTM0_CH6_input_capture(); /* 入力がキャプチャされた場合：フラグをクリアし、タイマーを読み取る */   } } 7.インポートコードは以下のとおりです（FTM0_init()、FTM0_CH1_PWM_init()）： void FTM0_init(void) {/** * FTM0 クロック: * ================================================== */ PCC->PCCn[PCC_FTM0_INDEX] &= ~PCC_PCCn_CGC_MASK; /* 設定のためにクロックが無効になっていることを確認します */ PCC->PCCn[PCC_FTM0_INDEX] |= PCC_PCCn_PCS(0b010) /* クロックソース=1、8 MHz SIRCDIV1_CLK */ | PCC_PCCn_CGC_MASK; /* FTMレジスタのクロックを有効にする */ /*! * FTM0 の初期化: * =================================================== */ // 1. 最初のステップ：FTM 時間钟彻底关闭（CLKS = 0）、この時点では完全に構成可能な状態です FTM0->SC = 0x00000000; // 2. 2 番目：写保护并开启 FTM 完全モード volatile uint32_t dummy = FTM0->MODE; FTM0->MODE |= FTM_MODE_WPDIS_MASK; /* 禁止用写保护 */ FTM0->MODE |= FTM_MODE_FTMEN_MASK; /* 开启 FTM 完全モード */ // 3. 第三步：時钟关闭の安全状態下、顺利ハンドルMODと比较值写进去 FTM0->CNTIN = 0U; FTM0->MOD = 166 - 1; /* 8MHz / 166 ≈ 48.19 kHz */ // 4. 4 番目: 構成チャネル 1 (PTD16) は周縁 PWM モードです FTM0->CONTROLS[1].CnSC = FTM_CnSC_MSB_MASK | FTM_CnSC_ELSB_MASK; FTM0->コントロール[1].CnV = 83; /* 50% 占空比 (83 < 165) */ // 5. 第五章：极性と組み合わせモード清零 FTM0->COMBINE = 0x00000000; FTM0->POL = 0x00000000; // 6. 最後の一步：すべてのパラメータ已经安稳書入後，才真正开启道输出和時間钟源！ FTM0->SC = FTM_SC_PWMEN0_MASK | FTM_SC_PWMEN1_マスク | FTM_SC_PS(0) /* PS = 0 (不分周波数) */ | FTM_SC_CLKS(1); /* CLKS = 1 (最終启アニメーション计数器) */ } void FTM0_CH1_PWM_init(void) { /** * FTM0、PWMモードでのチャネル1: * ================================================== */ FTM0->CONTROLS[1].CnSC = FTM_CnSC_MSB_MASK |FTM_CnSC_ELSB_MASK;  /* FTM0 ch1: エッジアラインメント PWM、低真パルス */ /* CHIE (ちゃん割り込みエナ) = 0 (デフォルト) */ /* MSB:MSA (チャンネルモード選択)=0b10、エッジアラインPWM */ /* ELSB:ELSA (chan Edge/Level Select)=0b10、low true */   FTM0->CONTROLS[1].CnV =  46875; /* FTM0 ch1 比較値 (デューティサイクル約75%) */ }

i.MX 8ULP SPI NANDブート：FCB0が破損した場合、ブートROMはFCB1にフォールバックしない こんにちは、NXPコミュニティの皆さん、 私はi.MX 8ULPを使用しており、SPI NANDフラッシュ（Winbond W25N04LW）からブートしています。 私の理解では、FCB0が破損した場合、ブートROMは自動的にFCB1に切り替わるはずです。しかし、 FCB0が破損すると、システムは起動に失敗します。具体的には、ブートROMはFCB1を読み込もうとすらしないようです。 以下は私の「SPI NANDブートパラメータ」ヒューズ設定です。 FlexSPI NAND検索ストライド :00(64ページ) FlexSPI NAND検索回数 :00(2) FlexSPI NAND CS間隔：00（100ns） FlexSPI NAND 列アドレス幅: 01 (13) その他のヒューズはすべてデフォルト値のままです。 プロトコルアナライザを使用してSPI通信を監視しました。電源投入時に、 i.MX 8ULPはページアドレス0x000000のFCB0を読み取るページデータ読み取り（13h）を発行します。 FCB0が破損しているため、Boot ROMは64ページの検索ストライドに基づくページアドレス0x000040でFCB1を読み取ると思っていました。しかし実際には、FCB1を試さずに再度FCB0を読み込もうとします。 参考までに、私のSPI NANDメモリマップは以下のとおりです。 0x00000000 ┌─────────────────────────────────┐ │ ブロック 0 : FCB0 │ 0x00040000 ├─────────────────────────────────┤ │ ブロック 1 : FCB1 │ 0x00080000 ├─────────────────────────────────┤ │ ブロック 2 : DBBT0 │ 0x000C0000 ├─────────────────────────────────┤ │ ブロック 3 : DBBT1 │ 0x00100000 ├─────────────────────────────────┤ │ ブロック4-15：プライマリファームウェア │ 0x00400000 ├─────────────────────────────────┤ │ ブロック 16～31：セカンダリファームウェア│ 0x00800000 └─────────────────────────────────┘ FCB0を意図的に破損させるために2つの異なる方法を試しましたが、どちらの場合も挙動は同じでした(FCB1は一度も読み取られませんでした): ブロック0を完全に消去しました。 FCBの指紋を「NFCB」から「NFC@」に変更しました。 質問： FCB0が破損した場合にフォールバックメカニズムでFCB1を読み取るために、追加のFuse設定や特定の構成が必要ですか？ サポートありがとうございます。 i.MX8ULP Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted 追記として、追加の観察事項と質問を述べたいと思います。 もしBoot ROMが特定のFCBを読み取れなかった場合、停止する前に同じFCBを一度だけ読み直すように設計されているのかもしれません。もしこの仮説が正しければ、「FlexSPI NAND検索カウント」ヒューズを増やすことで、起動ROMにさらに探索を強制することで問題が解決されるかもしれません。 i.MX 8ULPリファレンスマニュアルには明示的に詳述されていませんが、i.MX 91(互換性のあるSPI NANDブートアーキテクチャを共有していると思われる)のFusemapでは、検索カウントを次のように説明しています。 FlexSPI NAND検索カウント 00 - 2 01 - 2 10 - 4 11 - 8 この検索数の仕様は i.MX 8ULPでも同一であると考えてよいのでしょうか? どんなご意見でも大変ありがたく思います。 Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted こんにちは、リタさん。 迅速なご返信とサポート、ありがとうございます! 念のため確認すると、私たちが観察している問題は内部のBoot ROM実行フェーズのみで発生しており、これはBSPやユーザーソフトウェアが読み込まれたり実行されたりする前の段階です。このため、BSPのバージョンはこの特定の動作には影響しないはずです。 私の核心的な質問は、ブートROMの内部仕様に関するものです。FCB0が破損している場合、i.MX 8ULPブートROMは具体的にどのような条件下でFCB1の読み取りを試みるのでしょうか？ また、前回のフォローアップで述べたように、このフォールバック動作は i.MX 91のように「FlexSPI NAND 検索 Count」ヒューズ設定に関係しているのでしょうか? この内部ロジックについて、Boot ROMのエンジニアリングチームにご相談いただけると大変ありがたいです。 お時間を割いていただき、またご協力いただき、ありがとうございました！ よろしくお願いします、 ミゾ族 Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted こんにちは@DaisukeMizobuchiさん 使用しているBSPのバージョンは何ですか？ 素敵な一日をお過ごしください よろしくお願いいたします。 リタ Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted こんにちは、リタさん。 このThreadについて、さっさと続けてお願いします。Boot ROMのフォールバック動作や検索 Countのヒューズについて、社内のエンジニアリングチームに確認する機会はありましたか? たとえまだ調査中であっても、最新情報をお知らせいただければ大変ありがたいです。 ありがとう、 ミゾ族