MRF300AN 27MHz 参考设计 TVS 和电源时序 您好，NXP团队，关于MRF300AN-27MHz参考设计有两个问题：问题1：我可以在漏极和地之间连接一个110V TVS进行保护吗？Vds 为 133V。这是个好选择吗？Q2：正确的开机顺序是什么？栅极偏置先于漏极，还是漏极偏置先于栅极？另外，射频驱动应该缓慢增加功率还是可以直接施加全功率？谢谢。 Re: MRF300AN 27MHz Ref DesignTVS and Power Sequence 你好， 一般而言，TVS 反向截止电压应选择高于最大正常工作漏极电压，以防止正常工作期间发生意外导通，同时还能提供对异常瞬态事件的保护。 关于上电顺序，漏极电源可以在栅极偏置之前施加，反之亦然。在稳定且经过适当调整的电路中，这两种方法都是可以接受的。 此外，建议逐步增加射频驱动功率，而不是突然施加全功率驱动，因为这有助于确保更平稳的启动，并减少设备在运行条件下的压力。 希望这能帮到你！

MCUXpresso SDK 最新バージョン - フラッシュデータストレージの推奨アプローチ チームの皆さん、こんにちは。   私は最新バージョンのMCUXpresso SDKを評価しており、NXP MCUを使って作業しています。       小さな設定パラメータ(デバイス設定、キャリブレーション値、カウンターなど)を内部フラッシュメモリに保存する場合、現在推奨されている方法は何でしょうか?     具体的には：   1. 専用のフラッシュストレージ領域を使用するのと、EEPROMエミュレーション（サポートされている場合）を使用するのとでは、どちらが良いでしょうか？   2. フラッシュメモリへの書き込み操作を頻繁に行う場合、パフォーマンスや信頼性に関して考慮すべき点はありますか？ 3. NXPは、パラメータの保存とウェアレベリングに関するベストプラクティスを示すサンプルプロジェクトを提供していますか？ 4. 永続的な設定データを管理するために推奨されるSDKライブラリはありますか? 利用可能なSDKドキュメントは確認しましたが、新規プロジェクトでの推奨実装アプローチについての指針をいただけるとありがたいです。   Re: MCUXpresso SDK Latest Version - Recommended Approach for Flash Data Storage こんにちは、 @Manjuanth さん。 S32Kの製品フォーラムに投稿されているのを見ましたが、S32KのMCUはMCUXpressoと互換性がなく、代わりに S32 Design Studioを使っています。どのNXPのMCUを使っているか教えてもらえますか? よろしくお願いします、 ジュリアン

i.MX8M Plus HiFi4 DSP（Zephyr）：SDMA 循环发送回调触发一次后停止 在运行 Zephyr 的 i.MX8MP HiFi4 DSP 上，我正在使用 Zephyr nxp,dai-sai (SAI3) 和 nxp,sdma (SDMA3) 驱动程序以循环模式启动硬件端点播放路径。开始播放时，SDMA 通道完成回调恰好触发一次，然后不会再发生 SDMA 中断。我想请教一下，为什么循环 SDMA 传输不会持续产生周期性中断？ 硬件/启动 - 板：i.MX8MP EVK，DTS：imx8mp-evk-dsp.dts - DSP核心：HiFi4（Cadence Xtensa），目标板为imx8mp_evk/mimx8ml8/adsp - 编解码器：WM8960 - 外设：SAI3、SDMA3 建筑和版本细节： - 架构概述： https://audioreach.github.io/platform/nxp.html#architecture-overview - 版本详情： - Yocto： https://audioreach.github.io/platform/nxp.html#step-1-create-a-yocto-image - Linux（控制/主机）：Yocto（scarthgap）、linux-imx。 - 仓库清单：imx-6.6.52-2.2.0.xml - Zephyr DSP 镜像： https://audioreach.github.io/platform/nxp.html#step-2-create-a-zephyr-image - Zephyr (v4.2.0)， AudioReach Engine信号处理框架，运行于 HiFi4 上。 我正在建造的东西 DSP 映像中的一个自定义硬件端点（接收器）模块，其功能如下： 1.通过 Zephyr DAI API 配置 SAI3。 2.建立从 动态随机存取存储器 (DRAM) 环到 SAI TX FIFO 的循环 SDMA 传输（2 个缓冲区描述符，MEMORY_TO_PERIPHERAL）。 3.使用 SDMA 完成回调来通知信号处理框架重新填充环。 音频格式 - 48 kHz，16 位，单声道音频流；SAI 线 = 16 位 × 2 个插槽（WM8960 的立体声 I2S 帧），BCLK = 1.536兆赫兹。 - DMA 周期 = 192 字节（48 帧 × 2 字节 × 2 个时隙），2 个描述符，384 字节环 已启用相关 Kconfig（DSP 映像）。 CONFIG_DAI=y CONFIG_DMA=y CONFIG_DAI_NXP_SAI=y CONFIG_DMA_NXP_SDMA=y CONFIG_SAI_HAS_MCLK_CONFIG_OPTION=y CONFIG_CLOCK_CONTROL_FIXED_RATE_CLOCK=y 设备树叠加（DSP 应用）： 链接： app/boards/imx8mp_evk_mimx8ml8_adsp.overlay mclk1：mclk { 状态 = "正常"; }; &sdma3 { 状态 = "正常"; }; &sai3 { rx-fifo-watermark = <65>; tx-fifo-watermark = <65>; 先进先出深度 = <128>; rx-sync-mode = <1>; 状态 = "正常"; }; &micfil { 状态 = "正常"; }; 使用的DAI/DMA配置（DSP） - dai_config: type=DAI_IMX_SAI, dai_index=3, format= DAI_PROTO_I2S (SAI 从设备), rate=48000, channels=2, word_size=16. - SAI 定制：mclk_rate=12288000，fsync_rate=48000，bclk_rate=1536000，tdm_slots=2，tx_slots=rx_slots=0x3，tdm_slot_width=16。 - DMA（struct dma_config）：channel_direction=MEMORY_TO_PERIPHERAL，source_data_size=4，dest_data_size=4，source_burst_length=4，cyclic=1，block_count=2，dma_slot 来自 SAI 握手，dma_callback 设置。两个 dma_block_config BD 指向 dma_src_addr[0/192] 源代码参考： endpoint/capi/src/capi_nxp_device_utils.c 应用程序处理器： - DTS：imx8mp-evk-dsp.dts https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx8mp-evk-dsp.dts - 使用虚拟 DAI 和虚拟平台枚举带有 wm8960 编解码器的 PCM 设备。 附件： - DSP 日志（sdma，sai） - 修改了 imx8mp-evk-dsp.dts 我很乐意提供其他任何细节。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano 多媒体

i.MX8MP: SAI3オーディオを有効にしてM7を実行すると、SErrorとページフォルトが発生します。 NXP公式チームの皆様、こんにちは。 i.MX 8M Plus プラットフォームを使用し、 Linux A53 と FreeRTOS M7 を実行する システムを開発しています 。M7 を実行中に SAI3 オーディオインターフェースをLinuxに割り当てようとしたところ、カーネルクラッシュ（SError/ページフォルト）が発生しました。 1. ソフトウェアのバージョンと環境： カーネルバージョン: Linux 5.10.72 U-Bootバージョン: U-Boot 2021.04 M7 SDK: i.MX8MP 用 MCUXpresso SDK (rpmsg_lite_str_echo_rtos) 公式記事を参照してください: NXPナレッジベース: remoteprocを使用してM7ファームウェアを実行中にSAI3をテストする 2. システム構成：   <1> M7ファームウェア（m7.bin）はシステムパーティションに保存され、...U-Bootステージは、bootaux 0x007e0000コマンドを使用して直接起動されます。 <2> Cortex-A53 Linux側では、SAI3 + I2C3 + SDMA3バスに搭載された物理サウンドカードチップ（SGTL5000）を使用します。 <3> Cortex-M7は、GPIO2_IO09ピンでデータを取得し、高周波サンプリング割り込みをトリガーし、RPMsg仮想シリアルポート（/dev/ttyRPMSG30）を介してコア間でA53 Linuxとやり取りする役割を担っています。 3．発生した問題： サウンドカードのリソースがA53に調整されていない場合、/dev/ttyRPMSG30デバイスの動作は正常です。 現在、A53サウンドカードが必要です。公式記事「<リモートプロシージャコールでM7ファームウェアを実行中にSAI3をテストする>」に従って、以下の調整を行いましたが、カーネルの起動時に問題が発生します。変更点は以下のとおりです。 <1> カーネルのDTS設定が復元され、サウンドカードの設定が添付ファイル に示すようにA53に変更されました。 <2> u-boot dts: A53 にサウンドカードのリソースを割り当てます。例: <3> ATF、 SAI3、sdma3、i2c3をA53に割り当て、 imx8mp_bl31_setup.cを修正します。例： <4>M7 SDK: 添付の および に示されているように、AUDIO の変更に関連する BOARD_BootClockRUN および BOARD_RdcInit 関数に関するコメント。 4. カーネルのdmesgクラッシュログ： 以下のログに示すように、カーネル起動中にシステムがフリーズします。 [ 2.992289] i2c i2c-1: IMX I2C adapter registered [ 2.997631] SError Interrupt on CPU2, code 0xbf000002 -- SError [ 2.997634] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997636] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997638] Workqueue: events deferred_probe_work_func [ 2.997642] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 2.997644] pc : i2c_imx_probe+0x31c/0x8fc [ 2.997645] lr : i2c_imx_probe+0x2b0/0x8fc [ 2.997647] sp : ffff8000126a3af0 [ 2.997648] x29: ffff8000126a3af0 x28: ffff80001135c3f0 [ 2.997654] x27: ffff0000c50aa880 x26: 0000000000000023 [ 2.997660] x25: ffff0000c50aaca0 x24: ffff0000c50aa8f0 [ 2.997666] x23: ffff800011d7c090 x22: ffff0000c4410e40 [ 2.997672] x21: ffff80001135c428 x20: ffff0000c041d800 [ 2.997677] x19: ffff0000c041d810 x18: 0000000000000020 [ 2.997683] x17: 0000000000000000 x16: 0000000000000000 [ 2.997689] x15: ffff0000c44112b8 x14: 0000000000000000 [ 2.997695] x13: ffff0000c4410e40 x12: ffff8000126a3a70 [ 2.997700] x11: aaaaaaaaaaaaaaab x10: 0000000000000060 [ 2.997706] x9 : ffff800011b993b4 x8 : ffff800011b99000 [ 2.997712] x7 : 00007dfed2122a00 x6 : 000000000007a120 [ 2.997718] x5 : 0000000000b71aff x4 : 0000000000000002 [ 2.997723] x3 : 0000000000000002 x2 : 0000000000000000 [ 2.997729] x1 : ffff0000ff86ea08 x0 : ffff800013c8000c [ 2.997736] Kernel panic - not syncing: Asynchronous SError Interrupt [ 2.997741] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997742] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997744] Workqueue: events deferred_probe_work_func [ 2.997747] Call trace: [ 2.997748] dump_backtrace+0x0/0x1a0 [ 2.997750] show_stack+0x18/0x70 [ 2.997751] dump_stack+0xd0/0x12c [ 2.997752] panic+0x16c/0x334 [ 2.997754] nmi_panic+0x8c/0x90 [ 2.997755] arm64_serror_panic+0x78/0x84 [ 2.997757] do_serror+0x64/0x6c [ 2.997758] el1_error+0x90/0x110 [ 2.997760] i2c_imx_probe+0x31c/0x8fc [ 2.997762] platform_drv_probe+0x54/0xb0 [ 2.997763] really_probe+0xec/0x4d0 [ 2.997765] driver_probe_device+0x58/0xc0 [ 2.997766] __device_attach_driver+0xa8/0x10c [ 2.997768] bus_for_each_drv+0x78/0xd0 [ 2.997769] __device_attach+0xd8/0x180 [ 2.997771] device_initial_probe+0x14/0x20 [ 2.997773] bus_probe_device+0x9c/0xa4 [ 2.997774] deferred_probe_work_func+0x80/0xc0 [ 2.997776] process_one_work+0x1cc/0x350 [ 2.997777] worker_thread+0x2bc/0x46c [ 2.997779] kthread+0x154/0x160 [ 2.997780] ret_from_fork+0x10/0x30 [ 2.998109] SMP: stopping secondary CPUs [ 2.998111] Kernel Offset: disabled [ 2.998113] CPU features: 0x0240002,2000200c [ 2.998114] Memory Limit: none 問題点をご確認いただき、解決に役立つ関連文書や修正点がないかご検討ください。ご提案やご回答をお待ちしております。よろしくお願いいたします。 回复： i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled 解決しました。M7側のオーディオ設定を完全に無効にする必要がありました。

MR-CANHUBK344 IEEE1722自動車用イーサネット例 – S32DS 3.5/3.6.7の作業プロジェクトが必要 こんにちは、 私はMR-CANHUBK344を使っていて、その100BASE-T1自動車用イーサネットインターフェースを使いたいと思っています。 最初の目標は、アプリケーションに合わせて修正する前に、基板上で動作するオートモーティブ イーサネットの例を動かすことです。 公式のMR_CANHUBK3_IEEE1722サンプルをダウンロードしました。これはMR-CANHUBK344、100BASE-T1、TJA1103、GMAC、IEEE 1722 ACF-CAN、CAN/CAN-FDからイーサネットへの変換、FreeRTOSの実証が可能であるため適切に見えます。 しかし、ツールチェーン／バージョンの互換性の問題に直面しています。 私が利用できる環境は以下のとおりです。 S32 Design Studio 3.5 with S32K3 RTD 3.0.0 S32 Design Studio 3.6.7 with S32K3 RTD 7.0.1 元のMR_CANHUBK3_IEEE1722プロジェクトをインポートするとソースファイルは見えますが、.mexを開こうとすると設定時に以下のエラーが発生します。 プロセッサS32K344、PlatformSDK_S32K3_2022_03バージョンは現在のツールバージョンではサポートされていません。 例えば、FreeRTOS_Toggle_Led_Example_S32K344.mexはPlatformSDK_S32K3_2022_03を期待しているため開けません。 オリジナルのMR_CANHUBK3_IEEE1722デモは、古いS32DS/RTD環境を使用して開発されたものだと理解しています。 S32 Design Studio 3.4をインストールしてSW32K3_S32DS_3.4.3_D2112.zipをダウンロードしてみました。しかし、NXPアカウントにv3.4ライセンスの権利が表示されないため、現在S32DS 3.4を有効化できません。 以下のいずれかの点を教えていただけませんか? S32DS 3.5およびRTD 3.0.0に対応した、動作するMR-CANHUBK344 IEEE1722プロジェクトはありますか？ S32DS 3.6.x用のMR-CANHUBK344 オートモーティブ イーサネットの最新例はありますか?そして、より新しいRTDバージョンは？ 今のところ、2台のMR-CANHUBK344ボードが100BASE-T1リンクを確立し、S32K344 GMACとTJA1103を使って基本的なイーサネットフレームを送受信する、シンプルなオートモーティブ イーサネットのデモンストレーションだけで十分です。 現時点ではSOME/IP、TSN、複雑なTCP/IPアプリケーションは必要ありません。 MR_CANHUBK3_IEEE1722のS32DS 3.5版、更新されたプロジェクト、または移行ガイドがあれば、ぜひ共有してください。 あるいは、ライセンスの有効化を手伝ってもらえれば。ダウンロードボタンをクリックしたのですが、バージョン3.4に関するメールが届きませんでした。3.6に関するメールは1通届きました。 よろしくお願いします。 Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 よろしくお願いします。 Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 こんにちは、 @Aaditya773 さん。 元のMR_CANHUBK3_IEEE1722デモは古いS32DS/RTD環境向けにリリースされていました。つまり.mexです新しいS32DS 3.5 / 3.6.xとの非互換性バージョンが想定されています。この正確なIEEE1722 ACF-CANデモの公式に移行版がS32DS 3.5やS32DS 3.6.xで入手可能かどうかは確認できません/ RTD 7.0.1 現在の目標としては、まず100BASE-T1イーサネットインターフェースを立ち上げることなので、古いIEEE1722プロジェクトを直接移行するよりも、新しいイーサネットの例から始めることをお勧めします。 NXPコミュニティにはMR-CANHUBK344 lwIPの例があります: Example S32K344 EMAC lwIP FreeRTOS MRCANHUB S32DS 3.6.1 RTD600。この例はlwip_FreeRTOS_s32K344をベースに、MR-CANHUBK344ボード向けに改変したもので、lwIPスタックへのpingを実行する方法を示しています。 ただし、この例はRTD 6.0.0ベース向けに作成されたものです。設定。したがって、RTD 7.0.1に関しては、直接インポートするプロジェクトとしてではなく、主に参考資料として使用することをお勧めします。よりクリーンなアプローチとしては、インストール済みのTCP/IPスタックに付属するlwip_FreeRTOS_s32k344サンプルから始め、コミュニティサンプルからMR-CANHUBK344固有の部分、主にGMAC/MIIポートマッピング、ピン構成、クロック、割り込み、およびTJA1103関連の設定を適応させる方法があります。 別の参考として、パッケージS32K344_gptp_dsの例を使うこともできますSW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip 以下のソフトウェア構成で簡単に確認しました: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_FreeRTOS_11.1.0_7.0.0_CD1_HF1_D2511_DesignStudio_updatesite.zip SW32K3_TCPIP_STACK_5.0.0_CD01_D2605_DesignStudio_updatesite.zip SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip S32構成ツールの設定でいくつかの小さな修正を加えた後、S32K344_gptp_ds例はこの環境で構築可能です。 これはオリジナルのIEEE1722 ACF-CANデモの直接移植ではないことにご注意ください。これは、新しいソフトウェア環境を用いてMR-CANHUBK344上で基本的な100BASE-T1イーサネットを起動するための実用的な方法です。 議論を分かりやすく、他のユーザーにとっても役立つようにするため、このスレッドはMR-CANHUBK344イーサネット/100BASE-T1の話題に焦点を当てておきましょう。他にサポートが必要な場合は、別のコミュニティThreadを作成してください。   よろしくお願いいたします。 パベル

MR-CANHUBK344 IEEE1722 车载以太网示例 – 需要适用于 S32DS 3.5/3.6.7 的工作项目 您好， 我正在使用 MR-CANHUBK344，想使用其 100BASE-T1 车载以太网接口。 我的首要目标是在修改汽车以太网示例以适应我的应用之前，先在电路板上运行该示例。 我下载了官方的 MR_CANHUBK3_IEEE1722 示例。这看起来很合适，因为它演示了 MR-CANHUBK344、100BASE-T1、TJA1103、GMAC、IEEE 1722 ACF-CAN、CAN/CAN-FD 到以太网的转换以及 FreeRTOS。 但是，我遇到了工具链/版本兼容性问题。 我可用的环境有： S32 设计工作室 3.5 和 S32K3 RTD 3.0.0 S32 设计工作室 3.6.7 和 S32K3 RTD 7.0.1 当我导入原始的 MR_CANHUBK3_IEEE1722 项目时，可以看到源文件，但是当我尝试打开 .mex 文件时却无法打开。配置时出现以下错误： 处理器 S32K344，PlatformSDK_S32K3_2022_03 版本不受当前版本工具的支持。 例如，FreeRTOS_Toggle_Led_Example_S32K344.mex 无法打开，因为它需要 PlatformSDK_S32K3_2022_03。 我了解到最初的 MR_CANHUBK3_IEEE1722 演示程序是使用较旧的 S32DS/RTD 环境开发的。 我还尝试安装了 S32 Design Studio 3.4，并下载了 SW32K3_S32DS_3.4.3_D2112.zip。但是，我目前无法激活 S32DS 3.4，因为我的 NXP 帐户没有显示 v3.4 许可证授权。 请问您能否帮我解决以下其中一个问题？ 是否有适用于 S32DS 3.5 和 RTD 3.0.0 的 MR-CANHUBK344 IEEE1722 项目？ 是否有适用于 S32DS 3.6.x 的 MR-CANHUBK344 汽车以太网示例（已更新）还有更新的即饮版吗？ 目前，我只需要一个简单的汽车以太网演示，其中两个 MR-CANHUBK344 板建立 100BASE-T1 链路，并使用 S32K344 GMAC 和 TJA1103 发送/接收基本以太网帧。 现阶段我不需要 SOME/IP、TSN 或复杂的 TCP/IP 应用程序。 如果 MR_CANHUBK3_IEEE1722 有可用的 S32DS 3.5 移植版、更新的项目或迁移指南，请分享。 或者，如果您能帮我激活许可证就太好了。我点击了下载链接，但没有收到 3.4 版本的电子邮件。不过我收到了一封关于3.6版本的邮件。 谢谢！ Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 谢谢！ Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 你好@Aaditya773 ， 最初的 MR_CANHUBK3_IEEE1722 演示程序是为较旧的 S32DS / RTD 环境发布的，因此 .mex 文件也存在问题。与较新的 S32DS 3.5 / 3.6.x 版本不兼容版本号是预期的。我无法确认是否有适用于 S32DS 3.5 或 S32DS 3.6.x 的官方发布的 IEEE1722 ACF-CAN 演示程序的迁移版本。/ RTD 7.0.1。 对于您当前的目标是首先启动 100BASE-T1 以太网接口，我建议您从较新的以太网示例入手，而不是直接迁移旧的 IEEE1722 项目。 NXP 社区上有一个 MR-CANHUBK344 lwIP 示例：示例 S32K344 EMAC lwIP FreeRTOS MRCANHUB S32DS 3.6.1 RTD600 。本示例基于 lwip_FreeRTOS_s32K344，适用于 MR-CANHUBK344 板，演示了如何 ping lwIP 协议栈。 然而，此示例是基于 RTD 6.0.0 的版本编写的。设置。因此，对于 RTD 7.0.1，我主要会将其用作参考，而不是直接导入的项目。更简洁的方法是，从已安装的 TCP/IP 协议栈附带的当前 lwip_FreeRTOS_s32k344 示例开始，然后根据社区示例调整 MR-CANHUBK344 的特定部分，主要是 GMAC / MII 端口映射、引脚配置、时钟、中断和 TJA1103 相关设置。 作为另一参考，您还可以使用软件包 SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip 中的 S32K344_gptp_ds 示例。 我已使用以下软件配置进行了快速检查： SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_FreeRTOS_11.1.0_7.0.0_CD1_HF1_D2511_DesignStudio_updatesite.zip SW32K3_TCPIP_STACK_5.0.0_CD01_D2605_DesignStudio_updatesite.zip SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip 在对 S32 配置工具配置进行一些小的修改后，可以在此环境中构建 S32K344_gptp_ds 示例。 请注意，这不是原始 IEEE1722 ACF-CAN 演示的直接移植。对于使用较新的软件环境在 MR-CANHUBK344 上启动基本的 100BASE-T1 以太网而言，这是一种相当实用的方法。 为了使讨论更容易理解，也为了对其他用户有所帮助，让我们把这个帖子集中在 MR-CANHUBK344 以太网 / 100BASE-T1 启动主题上。如果您需要其他方面的帮助，请另开一个社区帖子。   顺祝商祺！ 帕维尔

S32K358 SEMA42 デモ こんにちは！ SEMA42モジュールのゲートレジスタを使用して、そのGTFSMフィールドに書き込みを行う必要があります。使用中にGTFSMフィールドへの書き込みと読み出しが正しく行えるように、mcalでSEMA42の操作を有効にする必要があります。SEMA42を使用したコア間通信のデモを提供していただけますでしょうか？よろしくお願いいたします！ Re: S32K358 SEMA42 demo こんにちは@liyongfengさん SEMA42を使用するには、まずXRDCを設定する必要があります。 デフォルトでは、ドメイン0のみがアクティブになっています。たとえば、ドメイン1（GTFSM = 0010b、つまりドメイン1がロックを保持している状態）でコアがゲートをロックするようにするには、XRDCでドメイン1を有効にする必要があります。 XRDCはRM RTD MCALドライバを通じて設定されます。ですので、MCAL RMドライバーを使うか、カスタムコード内で該当するXRDC設定を有効にするかのどちらかです。 参考として、RTD のサンプル Rm_Example_All_S32K358 を参照してください。これは、XRDCとSEMA42の両方を設定する方法を示しています。 danielmartynek_0-1786518348453.png よろしくお願いいたします。 ダニエル

MK22FN1M0VLQ12搭載デバイスが、しばらく動作後にリセットループに陥る。 こんにちは、みんな、 私はMK22FN1M0VLQ12を搭載したデバイスを持っています。 問題は、しばらく動作させた後、起動時にリセットループに陥ってしまうことです。 最初はフラッシュメモリの破損(アプリケーションがログをフラッシュに保存します)の問題かと思いました。私は卓球の戦略を使ってそれを解決しました。 しかし、一部の端末は同様の問題を抱えたまま返品された。あるデバイスのデバッグを試みましたが、ブレークポイントを設定しなくても常にASerialLDD2_InitかIntFlashLdd1_Eraseで止まります。どちらもプロセッサエキスパートが生成する関数です。他のデバイスではメモリダンプを使ったところ、メモリが確かに破損していることが分かったので、FLASHの使い方を直しました。 もう一つ重要な点は、それが数か月後に起こる場合もあれば、ほぼ1年後に起こる場合もあるということです。また、1年半以上前に設置したデバイスの中には、問題なく動作しているものもあります。 もう一つは、USBでメモリダンプを試みて同じアドレスを読み取ろうとしたところ、時には問題なく読み取れる時もあれば、ARMトランスエーションフォルトを返すこともあります。 誰か、そんな感じの人を見たことがありますか？

デュアルコア通信S32K322 こんにちは、皆さん Core 0とCore 1の両方を有効にするデュアルコアプロジェクトを開始しました。テストとして、各コア上にインクリメントされる変数を作成しました。 Core 1からCore 0へ（またはその逆方向へ）この可変データを共有または転送するための推奨される方法は何ですか？ 共有RAMの利用例やベストプラクティスがあれば、ぜひ教えていただきたいです。 マイクロコントローラ:NXPS32k322 IDE:S32 Design Studio RTD:v3 デバッガ:PEMicro ありがとう！ Re: Dual core communication S32K322 こんにちは、@db16122さん デュアルコア構成での作業を開始し、カウンターを使用してコア0とコア1が動作していることを確認しました。しかし、私の主な疑問は、コア1からコア0へ、またその逆方向へデータをどのように渡せばよいかということです。コア間でのデータ共有に関する例はありますか？ Re: Dual core communication S32K322 私はInter-Platform Communication Framework(IPCF)の使用をおすすめします https://www.nxp.com/design/design-center/software/automotive-software-and-tools/inter-platform-communication-framework-ipcf:IPCF 事例やトレーニングも含まれています。 Re: Dual core communication S32K322 M7コアごとにカウンターを2つ追加するのはどうでしょうか？M7が稼働するとカウンターがカウントされ始め、値が同じかどうかを確認できます。 ちなみに、各コアの状態を確認する目的は何ですか?セーフティ上の理由で?

mc9s08qg8コンパイラ プロトタイプ:このチップを使った製品があります。それは時代遅れではない。コンパイルするためのコードは1980年のものを持っています。私がやりたいのは、Windows 11のCS v6.3コードを更新することです。製品と評価ユニットを動作ユニットに更新し、裁縫機器の製造業者に提供したいと考えています。製品を本番環境向けに更新するためのCコードが3行あります。歴史：ボビンショー < 1980年。展示会で試作品を展示し、1台150ドルで15台を販売した。私はInternational Microcircuits INC（IMI）で、特定の機能を実装するための特殊なゲートアレイチップを開発しました。ええと、そのユニットは使い捨てでした。特許を取得し、ボビンコントローラー「BC」は1983年までしまっていました。mc9s08qg8チップを使用して、BCの機能を多数追加アップグレードしました。生活保護を受けていたので、事業を拡大するためのお金がありませんでした。開発済みのユニットを保管場所から取り出し、72歳という年齢で最新の機能を実現するために最後のコーディングを完了させようとしています。死ぬ前に、それを大きく売ってみせるつもりだ。死ぬ前の最後の一手、負けるわけにはいかない。これ以上助けられない場合は、TIに行って彼らのチップを使うつもりです。あなたの開発ソフトウェアから締め出されています。SO i got maybe 12 years left, and ur chip is the core of the 製品.もしこの製品に興味がなければ、TIに行きます。君たちの景気循環に付き合っている暇はない。もしこのユニットが成功すれば、2万台売れると思っています。43年前に思っていたよりもうまくいく。だから、私は参加するのか、それとも出るのか。Wiztronics製機器用にBDMドライブが必要です。最終ユニットを仕上げるためにComボードインターフェースとCW 11.1を導入しました。あと、私はまだ社会保障給付を受けています。お金はない、あるのは夢だけ。私はP&E USBマルチリンクのユニバーサルプランマーに500ドルも払う余裕はありません。もしかしたら、そのデバイスに「ベンチャーキャピタル」を投資したいと思うかもしれませんね。君は私がダウンロードしたCコード全体を手に入れた!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ボールは君のコートにある。 Re: mc9s08qg8 compiler Hello あなたの他の投稿で提案しますが、CodeWarriorでBDMドライバーを修復するのに役立つかどうか助かります mc9s08qg8 ドライバ Wiztronicsのボードでのドライバの使用について相談したことはありますか?何かフィードバックはありますか? よろしくお願いいたします。

S32DS K116 compilation issues Hello, NXP engineer! I'm new to MCSPTE1AK116. I installed MCSPTE1AK116-SW; S32K11x_AMMCLIB_RTM_1_1_45_BIN; S32DS-IDE-ARM_2.2.2_D2312; and FMASTERSW32. I imported the MCSPTE1AK116_PMSM_FOC_1Sh sample project into S32DS and compiled it. Then I copied the .srec file directly to drive E, and after a power cycle, I connected and ran it using FreeMaster. It communicated and ran at a given speed, but it stopped after a few seconds and reported a PDB0 error. If I directly copied the original .srec file from the SW directory to drive E, it ran normally. Is there something wrong with my compilation settings? Re: S32DS K116编译问题 Hi Robin, 我安装了S32 Design Studio (S32DS) for ARM 2.2 UP1和UP2 也安装了S32 Software Development Kit (SDK) for S32K1xx 3.0.3 如图，我下了老的S32K11X_AMMCLIB_RTM_1_1_37_BIN，还是不行， 我找不到S32K11X_AMMCLIB_RTM_1_1_29_BIN下载链接，你能发一个给我试试吗？而且我三个工程，只有PMSM_FOC_1Sh工程编译了不行，另外两个工程编译是没有问题的。 7a6c7c4ef61e9213d789cace0810a496.png   Re: S32DS K116编译问题 Hi If your test file (.srec) in the original folder runs fine, but your compiled file (.srec) encounters an error, then you should be able to run it. Therefore, it is recommended to download an older version of the Automotive Math and Motor Control Library Set for S32K11x . For example, the version mentioned in the MCSPTE1AK116-SW installation process: S32K11X_AMMCLIB_RTM_1_1_29_BIN. S32K116 Motor Control Development Kit AMMCLIB.png The MCSPTE1AK116_ReleaseNotes.txt file shows that this project was developed based on the following version: The Development Kit application was built and tested using the following IDE, Drivers and Tools: ===================================================================================== - S32 Design Studio (S32DS) for ARM 2.2 - S32 Software Development Kit (SDK) for S32K1xx 3.0.3 - FreeMASTER 3.1.4.5 Please confirm that the S32K1 SDK has version 3.0.3 installed. Best Regards, Robin 回复： S32DS K116编译问题 It's a strange problem. I can download and download the project directly using the accompanying BLDC_6Steps and PMSM_FOC_2Sh projects, and I can also download it after compiling it. It's just that I can't download it after compiling it.

mc9s08qg8 编译器 原型：我有一个使用这款芯片的产品。它并没有过时。我有一份要编译的代码，是 1980 年的。我想做的是更新 Windows 11 上的 CS v6.3 代码。我想将产品从评估单元更新为可运行的单元，以便发布给缝纫设备制造商。我用三行C代码更新了产品，使其能够投入生产环境。历史：线轴展 <1980 年。在展会上展示了该设备的样机，并以每台 150 美元的价格售出了 15 台。我在国际微电路公司（IMI）开发了专用门阵列芯片来实现各种功能。嗯，这台设备是一次性的。我获得了专利，然后把线轴控制器“BC”收了起来，直到1983年才重新启用。使用 mc9s08qg8 芯片将 BC 升级到更多功能。我靠救济金生活，没有钱发展我的事业。现在我把开发好的设备从仓库里拿出来了，我已经72岁了，正在努力完成最后的编码工作，以获得最新的功能。我打算在死前把它卖个好价钱。这是我临死前的最后一步，我绝不能输。如果你不能再帮我了，我就去德州仪器（TI）用他们的芯片了。你们的开发软件把我锁住了。所以，我大概还有 12 年的时间，而你的芯片是产品的核心。如果你对这款产品不感兴趣，我就去德州仪器（TI）看看。我没时间跟你们玩弄商业周期。我估计如果这款产品畅销，我能卖出2万台。它比我43年前预想的要好得多，所以我到底是加入还是退出？我的Wiztronics电脑需要BDM驱动器。com 板接口和 cw 11.1 完成最终单元。另外，我目前仍在领取社保金。身无分文，只有梦想。我买不起500美元的P&E USB多链路通用编程器。或许你想对这款设备进行“风险投资”。我已经把完整的C语言代码下载给你了！现在轮到你了。 Re: mc9s08qg8 compiler Hello 我在你的另一篇帖子中给你提了个建议，或许能帮你修复 BDM 驱动程序，以便在 CodeWarrior 中使用该设备。 mc9s08qg8 驱动程序 请问您是否就驱动程序在其电路板上的使用情况咨询过 Wiztronics 公司？您有任何反馈吗？ 顺祝商祺！

The application's reading of the DCSR register value caused a CPU freeze. My device environment consists of a B4860 hardware chip platform running the OSE operating system, with a DCSR address space mapping type of SASE. 0xf1100000 - 0xf14fffff 0x00400000 rw-r-- cio ----g- SASE dcsr Dereferencing any address within the range 0xf1124fff to 0xf1125fff caused a CPU freeze, followed by a reset due to a watchdog timeout. This address space is 4KB in size. I'd like to know information about the chip's DCSR register. What is the function of the DCSR register? Can't its value be directly accessed and read?

デモ資料のアップロードエラー 電源管理ICの機能安全と関連システムに関する考慮事項 | NXPセミコンダクターズ　このビデオの情報はビデオのURLであり、ドキュメントのURLではありません。 Re: 演示资料上传错误 こんにちは、 ご報告いただいた問題は把握しており、影響を受けているページを特定しました。トレーニングコース「電源管理IC的功能安全及相关システム注意事项 |NXP中国語のウェブサイトにある「NXP半导体」(Functional Safety in Power Management ICs and Related System Considerations, COURSE ID: TIP-NXP-AUT-T4050)には、動画URLを指し示す誤った資料/プレゼンテーションのダウンロードリンクが表示されているようです。 担当のウェブコンテンツチームに修正を依頼しましたので、リンクが修正され次第、ご連絡いたします。 その間、このトレーニングのプレゼンテーションスライドが必要な場合は、同じコースのグローバル英語版が以下で利用可能です: https://www.nxp.com/design/design-center/training/TIP-NXP-AUT-T4050 BRs、トーマス

双核通信 S32K322 大家好， 我已经启动了一个双核项目，其中核心 0 和核心 1 都已启用。作为测试，我在每个核心上创建了一个递增变量。 将变量数据从核心 1 共享或传输到核心 0（反之亦然）的推荐方法是什么？ 非常感谢您能提供一些使用共享内存的示例或最佳实践。 微控制器：NXPS32k322 IDE：S32 设计工作室 RTD：v3 调试器：PEMicro 谢谢！ Re: Dual core communication S32K322 你好@db16122 我开始搭建双核系统，并通过计数器验证了核心 0 和核心 1 是否正在运行。但是，我的主要问题是：如何将数据从核心 1 传递到核心 0，反之亦然？您能否提供一些关于核心间数据共享的例子？ Re: Dual core communication S32K322 我建议使用跨平台通信框架（IPCF）。 https://www.nxp.com/design/design-center/software/automotive-software-and-tools/inter-platform-communication-framework-ipcf:IPCF 包含示例和培训。 Re: Dual core communication S32K322 如果给每个 M7 核心增加两个计数器呢？M7 运行后，计数器开始计数，您可以检查该值是否相同。 顺便问一下，检查每个核心状态的目的是什么？是为了功能安全原因吗？

imx8 nanoカーネルのA53コアへの5.15から6.18への移行 imx_rproc_kick こんにちは A53コアのカーネルを5.15から6.18にアップグレードしていますが、imx_rproc_kickが見つかりません。 デバッグメッセージを探してください # DMESG |grep -nE "rpmsg|virtio|remoteproc|imx-rproc|imx_rproc_kick|goodbye|new チャネル|get [0-9]」 118:[ 0.030048] IMX RPMSGドライバーが登録されています。 222:[ 1.538994] remoteproc remoteproc0: imx-rproc が利用可能です 224:[ 1.544537] RemoteProc RemoteProc0: IMX-rprocへの接続 225:[ 1.555034] rproc-virtio rproc-virtio.1.auto:割り当てられた予約メモリノードvdevbuffer@b8400000 226:[ 1.564322] virtio_rpmsg_bus virtio0: rpmSGホストがオンライン 227:[ 1.569846] rproc-virtio rproc-virtio.1.auto:登録済みVirtio0(タイプ7) 228:[ 1.576689] RemoteProc RemoteProc0: リモートプロセッサ IMX-Rproc が接続されました 327:[ 5.860600] IMX-rproc imx8mn-cm7: imx_rproc_kick: failed (1, err:-62) 敬具 ヤドゥナート・R Re: imx8 nano kernel migration for a53 core from 5.15 to 6.18 imx_rproc_kick imx_rproc_kick 6.18カーネルに欠けているわけではありません。ログにはドライバーが到達しエラーを返したことが示されています: imx-rproc imx8mn-cm7: imx_rproc_kick: 失敗しました (1、エラー:-62) err:-62 は、リモートコアへのキックがタイムアウトしたことを意味します。NXPのi.MX remoteproc/RPMsgのコンテキストでは、これはRPMsgキックパス中のタイムアウトとして説明されています。デフォルトのBSPリモート準備完了待機時間は50msですが、キャッシュがオフになっている場合やファームウェアがまだ準備できていない場合など、RPMsgの初期化が遅れるとMコアはより長い時間が必要になる場合があります。 あなたのログによると、Linux側はここまで来ています: remoteproc0: imx-rprocに接続中 rproc-virtio... 予約済みメモリノード vdevbuffer@b8400000 を割り当てました virtio_rpmsg_bus virtio0: rpmsgホストはオンラインです リモートプロセッサIMX-RproCが接続されました つまり、A53/Linux側はすでに動作中のM7に接続し、virtio RPMsgホストを作成しています。失敗は後にLinuxがvirtqueue 1に通知しようとした際に発生しますが、MU/RPMsg側が間に合わずハンドシェイクを完了しません。i.MX remoteprocキックパスは、LinuxとハードウェアのMU(リモートプロック)間のIPC割り込み信号にメールボックス/MUを使用します。 5.15 → 6.18へのアップグレードでデバッグが必要になる可能性が最も高い箇所： M7ファームウェアリソーステーブル/RPMsgメモリレイアウト M7のファームウェアリソーステーブルがLinuxのDT予約メモリ配置と一致しているか確認してください。 NXPのドキュメントによると、リソーステーブルはvirtioデバイスおよびvringエントリを定義しており、RSC_VDEV、NUM_VRINGS、VDEV0_VRING_DA_BASE、VRING_ALIGN、バッファカウントなどが含まれます。 有効なリソーステーブルが存在しない場合、NXPのLinuxユーザーガイドではリソーステーブル領域をクリアすべきと記載されています。i.MX 8M Mini/Nano/Quad LPDDR4 EVK では、文書化されたコマンドは mw 0xb80ff000 0 4 です。 デバイスツリーの予約メモリとrsc-da 6.18 DT が、M7 ファームウェアが想定するアドレスと同じアドレスに RPMsg vring/buffer/resource-table 領域を予約していることを確認してください。 ログにはLinuxが割り当てられたvdevbuffer@b8400000が表示されているので、M7ファームウェアのRPMsg-Lite/OpenAMP設定が同じvring/bufferベース領域を使っているか確認してください。 また、imx8mn-cm7ノードに、お使いのボード/ファームウェアに適したmboxes、memory-region、rsc-daの値が設定されていることを確認してください。 M7ファームウェアの準備状況 ログにはタイムアウト前のRPMsg「新しいチャネル」ラインは表示されません。これはLinuxがRPMsgホストとしてオンラインであることを示唆していますが、M7側が正しくチャネルをアナウンス・サービスしていない可能性があります。 Linuxがトラフィックを送信する前にM7アプリケーションがRPMsg-Lite/OpenAMPを初期化し、エンドポイントを有効にする前にブロックされていないことを確認してください。 新しいカーネルのRPMsgに関する前提に基づいて構築されたファームウェア NXPは、リモートRPMsgリソースが破壊された後もLinux側がM7をキックし続けた事例を記録しており、その結果imx_rproc_kick失敗(...、ええと:-62)が出ています。 SDKのピンポン風デモを使う場合は、M7ファームウェアが一定数のメッセージ後にRPMsgエンドポイントを終了または破壊するかどうかを確認してください。そのパターンはまさにこの種類の誤りを引き起こすことがあります。 推奨される次のデバッグコマンド： dmesg | grep -nE "remoteproc|rproc|rpmsg|virtio|mailbox|mu|imx-rproc|imx_rproc" ls -l /sys/class/remoteproc/remoteproc0/ cat /sys/class/remoteproc/remoteproc0/state cat /sys/class/remoteproc/remoteproc0/name また、5.15と6.18のこれらの値を比較してください。 grep -n "imx8mn-cm7" -n your-board.dts grep -n "vdevbuffer\|vdev0vring\|rsc\|rpmsg\|reserved-memory" your-board.dts まず最初に確認すべきことは、 6.18 デバイスツリーが M7 ファームウェアのリソーステーブルと RPMsg メモリ アドレスと一致しているかどうかです。Linux側は正常に接続しています。故障はMU/RPMsgのキック/アクック段階にあり、これはimx_rproc_kick機能の欠如よりもM7の準備状況、メールボックス/DTの設定、リソーステーブル/vringの不一致を示唆しています。

アプリケーションがDCSRレジスタの値を読み取った際に、CPUがフリーズした。 私のデバイス環境は、OSEオペレーティングシステムを実行するB4860ハードウェアチッププラットフォームで構成されており、DCSRアドレス空間マッピングタイプはSASEです。 0xf1100000 - 0xf14fffff 0x00400000 rw-r-- cio ----g- SASE dcsr 0xf1124fffから0xf1125fffの範囲内のアドレスを逆参照すると、CPUがフリーズし、ウォッチドッグタイムアウトによりリセットされました。このアドレス空間のサイズは4KBです。チップのDCSRレジスタについて知りたいのですが、DCSRレジスタの機能は何ですか？その値に直接アクセスして読み取ることはできないのでしょうか？ Re: 应用程序中读取DCSR寄存器的值引发CPU停滞的问题 フリーズは、通常の読み取り可能なDCSRレジスタではなく、B4860 DCSR空間内の記録されたアクセス不能ホールにアクセスすることと一致しています。 DCSRは一つのレジスタではありません。これは、実行制御/デバッグイベント、トレース生成、イベントカウント、EPUパフォーマンスカウンタ、Nexus/トレース関連レジスタなど、デバッグ関連のハードウェアリソースに使用される4MBのメモリマップ付きデバッグ/制御/ステータスアドレス空間です。一部のDCSRリソースはデバッグや内部用途のみ使用可能であり、少なくとも1つのサポートノートではDCSR/DSCRアクセスは「内部使用のみ」と記載されており、該当する場合はDTUにはCCSRアクセスの使用を推奨しています。 マッピングについて： DCSRベース = 0xf1100000 範囲が不正です = 0xf1124fff - 0xf1125fff オフセット = 0x24fff - 0x25fff 重要な点は次のとおりです。 0xf1125000 - 0xf1125fff  ＞ DCSR オフセット 0x25000 - 0x25fff その正確なDCSRオフセット範囲はアクセス不能スロットとして記載されており、NXPのサポート証拠ではDCSR領域で0x25000~0x25fffを読み取ると「システムハングを引き起こす」とされています。推奨される解決策は、DCSR空間のMMUウィンドウを有効にする際にその範囲を除外することです。他のB4860関連の証拠も同様に、CCSR/DCSRの未マッピング・未使用・予約領域はアクセスできず、それらにアクセスするとSC3900コアやSoCが停止する可能性があると示されています。 つまり答えは次の通りです: いいえ、DCSRマップされた範囲内の任意のアドレスを直接スキャンしたり、逆参照したりしてはいけません。 アクセスすべきは、文書化された有効なDCSRオフセットのみです。 予約済み、未使用、またはアクセス不能のDCSRスロットは、バスエラーを返す代わりにCPU/SoCをハングさせることがあります。 お客様の特定の障害発生範囲は、既知の不良DCSRオフセット0x25000～0x25fffと重複しており、これがCPUフリーズ後にウォッチドッグリセットが発生する理由です。 もう一つ追加情報として、0xf1124fffは文書化された0x25000ホールの1バイト前ですが、その非揃列アドレスでの32ビットアクセスは0xf1125000に交差する可能性があります。DCSR/レジスタアクセスは、任意のバイト/ワードプロービングではなく、アラインドされた32ビットレジスタアクセスとして扱うべきです。 推奨される処理方法：特定のデバッグ リソースが必要な場合にのみ DCSR をマッピングし、読み取り/書き込みを既知の有効なオフセットに制限し、診断ダンプまたはメモリ スキャン コードから DCSR + 0x25000 から DCSR + 0x25fff を明示的にブロック/除外します。 フリーズはそのアドレス範囲で予想されます。0xf1125000–0xf1125fffはB4860 DCSRの非アクセス可能なスロット0x25000–0x25fffにマッピングされるため、DCSR空間の任意の直接読み込みは安全ではありません。 Re: 应用程序中读取DCSR寄存器的值引发CPU停滞的问题 なるほど、この問題はチップ自体の根本的な問題だと正式に確認されたんですね？私の個人的な設定や誤った使用方法が原因ではないということですね（とはいえ、あの領域にアクセスすべきではなかったのは確かですが）。

Demonstration material upload error Functional Safety and Related System Considerations for Power Management ICs | NXP Semiconductors The information in this video is the video URL, not the document URL. Re: 演示资料上传错误 Hi, The issue you reported has been noted and I have identified the affected page. The training course "电源管理IC的功能安全及相关系统注意事项 | NXP 半导体" (Functional Safety in Power Management ICs and Related System Considerations, course ID: TIP-NXP-AUT-T4050) on the NXP Chinese website does appear to have an incorrectly configured material/presentation download link, pointing to the video URL rather than the downloadable presentation file. I have flagged this to the responsible web content team for correction and will update you once the link has been fixed. In the meantime, if you require the presentation slides from this training, the global English-language version of the same course is available at: https://www.nxp.com/design/design-center/training/TIP-NXP-AUT-T4050 BRs, Tomas

NXP SR040のピーク消費電力 こんにちは、SR040の最大消費電力はどれくらいですか？Tx/Rx/アイドルの内訳を教えてもらえますか? Re: NXP SR040 Peak Power Consumption こんにちは、 あなたの調子が良いといいのですが。ご不便をおかけして申し訳ありませんが、この製品の情報はNDA(秘密保持契約)に基づいており、公開されていません。 チップについての詳細は、代理店ネットワークで利用可能な当社の代理店のいずれかにお問い合わせください。NXPですか?または、このデバイスを手に入れるのを手伝った直接の連絡先がいれば、ぜひ連絡してください。 もし当社のUWB製品に関する情報をお探しの方やこのテクノロジに興味がある方は、パートナー(Trimension UWB Partners)のこれらの開発キットとモジュールをご確認いただくことをお勧めします。 これらのキットやモジュールに興味がある場合は、直接彼らに相談してプロセスやサポートを受けられるかを知る必要があります。なぜなら、このテクノロジのサポートは彼らを通じて行われるからです。 ドキュメントとソフトウェアは対応するUWBモジュールパートナーによって配布されます。モジュールを選択すると、パートナーのページに案内され、データシート、アプリケーションノート、必要なイネーブルメントにアクセスできます よろしくお願いいたします。 リカルド

imx8 nano 内核迁移（适用于 a53 核心），从 5.15 版本迁移到 6.18 版本 imx_rproc_kick 你好 我正在将 A53 核心的内核从 5.15 升级到 6.18，但是我发现缺少 imx_rproc_kick。 请查看调试信息 # dmesg | grep -nE "rpmsg|virtio|remoteproc|imx-rproc|imx_rproc_kick|goodbye|new 频道|获取[0-9]" 118:[ 0.030048] imx rpmsg 驱动程序已注册。 222:[ 1.538994] remoteproc remoteproc0: imx-rproc 可用 224:[ 1.544537] remoteproc remoteproc0：正在连接到 imx-rproc 225:[ 1.555034] rproc-virtio rproc-virtio.1.auto:已分配保留内存节点 vdevbuffer@b8400000 226:[ 1.564322] virtio_rpmsg_bus virtio0: rpmsg 主机已联机 227:[ 1.569846] rproc-virtio rproc-virtio.1.auto:已注册 virtio0（类型 7） 228:[ 1.576689] remoteproc remoteproc0: 远程处理器 imx-rproc 已连接 327:[ 5.860600] imx-rproc imx8mn-cm7: imx_rproc_kick: 失败 (1, 错误:-62) 问候 亚杜纳特·R Re: imx8 nano kernel migration for a53 core from 5.15 to 6.18 imx_rproc_kick 你的 6.18 内核中并没有缺少 imx_rproc_kick 函数——你的日志显示驱动程序已经执行到该函数，但返回了错误： imx-rproc imx8mn-cm7：imx_rproc_kick：失败（1，错误代码：-62） 错误代码 -62 表示向远程核心发送的指令超时。在 NXP 的 i.MX remoteproc/RPMsg 上下文中，这被描述为 RPMsg 启动路径期间的超时；默认的 BSP 远程就绪等待时间为 50 毫秒，如果 RPMsg 初始化延迟，例如当缓存关闭或固件尚未准备就绪时，M 内核可能需要更长时间。 从你的日志来看，Linux 端执行到了这一步： remoteproc0：正在连接到 imx-rproc rproc-virtio... 已分配预留内存节点 vdevbuffer@b8400000 virtio_rpmsg_bus virtio0：rpmsg 主机已联机 远程处理器 imx-rproc 已连接 因此，A53/Linux 端连接到已经运行的 M7，并创建 virtio RPMsg 主机。故障发生在 Linux 尝试通知 virtqueue 1 时，但 MU/RPMsg 端未能及时完成握手。i.MX remoteproc kick 路径使用邮箱/MU 在 Linux remoteproc 和硬件 MU 之间进行 IPC 中断信号传递。 5.15 → 6.18 升级过程中最可能需要调试的区域： M7固件资源表/RPMSg内存布局 验证 M7 固件资源表是否仍然与 Linux DT 保留内存布局匹配。 NXP 文档显示资源表定义了 virtio 设备和 vring 条目，包括 RSC_VDEV、NUM_VRINGS、VDEV0_VRING_DA_BASE、VRING_ALIGN 和缓冲区计数。 如果映像没有有效的资源表，NXP 的 Linux 用户指南指出应该清除资源表区域；对于 i.MX 8M Mini/Nano/Quad LPDDR4 EVK，记录的命令是 mw 0xb80ff000 0 4。 设备树保留内存和 rsc-da 检查 6.18 DT 是否仍然在 M7 固件预期的相同地址保留 RPMsg vring/buffer/resource-table 区域。 您的日志显示 Linux 分配了 vdevbuffer@b8400000，因此请确认 M7 固件的 RPMsg-Lite/OpenAMP 配置使用相同的 vring/buffer 基础区域。 另外，请确认 imx8mn-cm7 节点具有适用于您的板/固件的正确 mboxes、memory-region 和 rsc-da 值。 M7固件准备情况 日志中未显示超时前 RPMsg “新通道” 行。这表明 Linux 作为 RPMsg 主机在线，但 M7 端可能没有正确地通告/服务该通道。 确保 M7 应用程序在 Linux 发送流量之前初始化 RPMsg-Lite/OpenAMP，并且在启用端点之前没有被阻止。 为新内核的 RPMsg 假设而构建的固件 NXP 记录了一些案例，在这些案例中，即使远程 RPMsg 资源已被销毁，Linux 端仍然继续踢 M7，导致 imx_rproc_kick: failed (..., err:-62)。 如果您使用的是 SDK 乒乓式演示，请确认 M7 固件是否会在发送固定数量的消息后退出/销毁 RPMsg 端点。这种模式可能会触发此类错误。 建议的后续调试命令： dmesg | grep -nE "remoteproc|rproc|rpmsg|virtio|mailbox|mu|imx-rproc|imx_rproc" ls -l /sys/class/remoteproc/remoteproc0/ cat /sys/class/remoteproc/remoteproc0/state cat /sys/class/remoteproc/remoteproc0/name 另外，请比较 5.15 和 6.18 之间的这些差异： grep -n "imx8mn-cm7" -n your-board.dts grep -n "vdevbuffer|vdev0vring|rsc|rpmsg|reserved-memory" your-board.dts 我首先要检查的主要事项是6.18 设备树是否仍然与 M7 固件的资源表和 RPMsg 内存地址匹配。您的 Linux 端已成功连接；失败发生在 MU/RPMsg kick/ack 阶段，这更多地指向 M7 就绪、邮箱/DT 配置或资源表/虚拟环不匹配，而不是 imx_rproc_kick 函数缺失。