RT1064 I2C 通信异常，频率为 400kHz RT1064 设备的 I2C2 接口连接到模块 A。在 400kHz 频率下出现通信异常，但在 100kHz 频率下工作正常。 1. 将同一系列中不同型号的模块 B 以 400kHz 的频率连接没有问题。 2. 从波形上看，这相当于主机时钟在连接到模块 A 后被拉伸然后恢复时发生的异常情况。 PS：将该设备的 I2C 驱动程序移植到另一台 1064 设备上，测试模块 A，在 400k 功耗下未发现问题。 原因可能是什么？ 图 1 模块 A 逻辑分析仪在 400kHz 下的异常波形 图 2：模块 A 在 100kHz 下的逻辑分析仪波形 图3：模块B在400kHz时的波形 i.MX RT106x Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 感谢您的进一步说明——这是一个非常重要的发现。   根据您的观察，该问题似乎更有可能是由于两级 ADUM1251 隔离链路导致的 400 kHz I2C 时序裕量不足，而不是模块 A 本身的异常。 即使上升时间在规格范围内，在 RT1064 上，我们仍然建议检查 LPI2C 主侧 400 kHz 配置，特别是 MCFGR2[FILTSCL/FILTSDA] 和 MCCR0/MCCR1，因为 RT1064 上的主同步延迟不仅受上升时间的影响，还受数字滤波器和定时参数设置的影响。 我们建议您阅读项目中实际使用的配置，并将其与 RT1064 参考手册第 47 章中的表 47-5“LPI2C 示例时序配置”进行比较。 请特别检查以下设置是否与您所选时钟条件的示例值相符： I2C模块时钟源 目标波特率：400Kbps 预分频 FILTSCL/FILTSDA SETHOLD CLKLO CLKHI DATAVD 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 补充信息：昨天在定位方面取得了一些进展： 我们的硬件扩容计划如下： 主板：RT1064--- ADUM1251 3.3V 至 5 V 子板：ADUM1251-模块A 5V转3.3V 经验证，在硬件链路的两层中添加 ADUM1251 后，模块 A 的通信出现异常。但移除 ADUM1251 后，通信在 400k 处恢复正常。造成这种情况的原因可能是什么？ PS：我们的硬件工程师认为 ADUM1251 只会增加通信延迟，不会产生其他影响。 Re: RT1064 I2C communication abnormality at 400kHz 你好，@mayliu1 我们的产品即将发布，我们已经调查这个问题好几天了。如果您能尽快回复，我们将不胜感激！ Re: RT1064 I2C communication abnormality at 400kHz HI 补充信息 1.我们的两位硬件工程师使用示波器检查了故障波形，上升时间符合要求，在 100ns 以上。 2. 我将 I2C 初始化和读写功能驱动程序移植到另一种 RT1064 设备，并测试了模块 A，没有发现任何问题。 下图显示了另一个设备模块 A 的测试逻辑分析仪的波形。 怀疑： 1.如果时钟在拉伸后恢复异常，还有哪些其他原因可能导致这种情况？ 2. 是否有专门的功能来设置上次回复中提到的 MCFGR2 等设置？我没有看到在 I2C 初始化过程中需要设置任何接口。 ----如果上升时间满足要求，我们是否就不需要考虑这些寄存器设置了？ Re: RT1064 I2C communication abnormality at 400kHz 嗨@foreverwlh2025 ， 非常感谢您对我们产品的关注以及对我们社区的使用。 我认为这很可能不是 A 模块的问题，而是该特定 RT1064 LPI2C2 总线上的 400 kHz 时序裕量问题。 在 RT1064 上，LPI2C 时序受总线上升时间、总线负载、上拉电阻和毛刺滤波器延迟的影响。 RT1064RM 参考手册指出，上升时间越大，同步延迟就越高。（参见第 47.3.1.4 章）时序参数） 主故障滤波器 MCFGR2[FILTSCL/FILTSDA] 必须设置，使其延迟保持在最小 SCL 低/高周期以下，RT1064 在 MCCR0/MCCR1 中提供了 400 kbps 定时设置的示例。请查看表 47-5。LPI2C 示例时序配置 因此，如果模块 A 使总线边沿稍微变慢或改变有效负载，则总线可能在 400 kHz 时发生故障，但在 100 kHz 时仍然可以工作。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz RT1064 参考手册中没有列出 400 kbps 的 10 MHz LPI2C 功能时钟。 虽然可以使用此时钟生成 400 kbps 波特率，但应根据 I2C 规范仔细验证自动生成的定时参数，特别是 tLOW、tHIGH、建立/保持定时和数据有效定时。 为降低设计风险，建议使用经过验证的时钟源，例如 48 MHz，如参考手册所示。 Re: RT1064 I2C communication abnormality at 400kHz 以下是打印配置。可能需要调整哪个参数？ PS：显然是由于自动接口分配造成的 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 您可以尝试直接设置寄存器。 例如，当使用 60 MHz I2C 时钟时，可以采用以下配置。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 当前的 I2C 时钟是基于 SDK2_13_0-EVK-MIMXRT1064 板 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c 目录中的示例配置进行配置的。 #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); 我该如何修改才能获得精确的 8MHz 或 48MHz 频率？（时钟树似乎看不见） Re: RT1064 I2C communication abnormality at 400kHz 我尝试将频率修改为 60MHz 和 8MHz，但仍然无效。下图中的红色方框显示的是修改后打印的值，这些值与手册中的值不同。 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 配置 I2C 时钟有多种方法。 建议您尝试 8 MHz 和 60 MHz，因为这两个时钟设置相对容易实现。 我正在使用 SDK 演示版： "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" 方法一：将 LPI2C 时钟源配置为 60 MHz 只需将时钟分频器设置为 0 即可。 方法二：将 LPI2C 时钟源配置为 8 MHz 使用 MCUXpresso IDE 时钟工具并按如下所示进行配置。选择 OSC_CLK 作为时钟源，并将分频器设置为 3，这将为 LPI2C (I2C) 模块生成 8 MHz 时钟。 希望对你有帮助 顺祝商祺！ 5月

iMX8M Plus - Flexspi chip select pin On the i.MX8M Plus EVK, the ECSPI chip select signal can be configured using a GPIO pin. Could you please confirm whether FlexSPI also supports GPIO-based chip-select signals, or whether only the dedicated FlexSPI chip select pins can be used? As per our requirement, we need two chip select signals for FlexSPI. Kindly suggest the recommended configuration for supporting two FlexSPI devices. Re: iMX8M Plus - Flexspi chip select pin Hi @pengyong What we can do for two chip select of QSPI? This is also from our requirement. If there is lack of CS pin means, can we use the any gpio has a chip select? If it will work Re: iMX8M Plus - Flexspi chip select pin Hi @Govind1807  You could use a GPIO-based chip select signal. However, you only have two FlexSPI Flash devices. Why would you use a GPIO as the chip select signal? The imx8mp has four FLEX SS signals that can be used directly： https://github.com/nxp-imx/linux-imx/blob/5768b67a64961d932b7c50adf15ba3f5bfcc8f70/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h B.R

例tflm_cifar10_cm33_core0に tflm_label_image_ext_mem のメモリ設定を使ってもいいですか? 良い１日を。 現在はEIQ例tflm_cifar10_cm33_core0 を使ってNPUモードでモデル化しています。モデルデータはSRAMに保存されます。推論時間は良好です。そして、こちらがメモリ構成です。このeiq例を5クラスのモデル用に修正しました https://docs.nxp.com/bundle/AN14700/page/topics/eiq_enablement.html しかし今はモデルが大きくなり、NPU tfliteモデルを外部メモリ上で特定したいと考えています。モデルデータはFlashに格納されています。そして、こちらは eiq の例tflm_label_image_ext_memの設定です。 https://docs.nxp.com/bundle/AN14700/page/topics/imx_rt700_system_details.html 私の目標は、ソースコードをtflm_cifar10_cm33_core0から保持したい(tflm_label_image_ext_memで新しいソースコードを作成したくはありません)が、NPU tfliteモデルを外部メモリ上で特定したい ということです。 私の解決策は、上記の画像のように、メモリ構成をSRAMから外部メモリに変更することだけです。それで合っていますか？あるいは、他の設定も変更する必要があるのかもしれません。 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? こんにちは、 @nnxxpp さん。 ご説明ありがとうございます。 「--use-sequencer」を外部メモリモデルの実行と組み合わせて使用しないでください。 「tflm_label_image_ext_mem」例では、モデルが外部メモリから実行されるため、「--fetch-constants-to-sram」を残し、「--use-sequencer」は削除してください。 モデルを以下のように変換してみてください。 ./Neutronコンバータ \ --入力 QAT.tflite\ --出力 QAT_NPU.tflite\ --target imxrt700 \ --ヘッダーファイル出力をダンプする --dump-header-file-input \ --定数をSRAMに取得   お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? @mayliu1 こんにちは。これは新たな問題です（まだ解決されていません）。この問題は、外部メモリ(SRAMではなく)でのNPU tfliteモデルのデプロイに関連しています。 現在はSDKs of MIMRT700のeiqサンプルtflm_label_image_ext_memを使っています。この例はCANうまく実行できます。この例はモデル mobilenetv1 で、サイズ=224、クラス数=1000です。 サンプルのモデルを自分のモデル(同じ分類モデル)に置き換えようとしましたが、クラス数を変えました。 ラベルを変えました。(レーベル名の場合)、 サンプルのモデルを自分のモデルに置き換え、名前は同じまま使っています model_data.h ファイル内のmodel_data_lenも変更しました。 ビルドはできましたが、デバッグを実行するとプログラムは「静的プロセッシング」で停止し、結果が出ませんでした。 上の画像には 「モデルハンドルを保存できません。完了したらneutronModelUnprepare()を呼び出せ」というメッセージがありますが、NXPの従業員の一人はエラーではないと言っていました。https://community.nxp.com/t5/eIQ-Machine-Learning-Software/eIQ-FAQ/ta-p/1099741 NPUモデルが外部メモリ上にあるCASE、拡張子.tflite モデルを使います(モデルがSRAM上で位置する場合はヘッダーファイル.hではありません)。 モデルをフラグで--fetch-constants-to-sramに変換して、外部メモリ上のNPUモデルをこのように位置づけています ./Neutronコンバータ \ --input QAT.tflite \ --output QAT_NPU.tflite \ --target imxrt700 \ --ヘッダーファイル出力をダンプする --dump-header-file-input \ --use-sequencer \ --定数をSRAMに取得   NXPから設定や設定(SOの変更方法や場所)のチュートリアルが見当たらなかったので、上記の手順で試しましたがうまくいきませんでした。 手伝ってもらえますか?ありがとう。 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? こんにちは@nnxxpp さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 返信が遅くなり申し訳ありません。 前回の投稿で、問題はすでに解決済みだと書かれていたことに気づきました。全てが正常に機能していると聞いて安心しました。 ご理解いただき、改めて感謝申し上げます。 よろしくお願いいたします。 5月

S32G399A-RDB3 QNX PFEドライバの問題 ご挨拶申し上げます。 私たちはQNXを搭載したS32G399A-RDB3ボード上でPFEを動作させようと試みています。私の知る限り、これは有効な組み合わせです: BSP 37.0 PFE-FW_S32G_1.7.0 PFE-DRV-S32G_A53_QNX_1.4.0 すべてのネットワークインターフェースで「キャリアエラーなし」で終わります。ケーブルを異なるイーサネットポートに差しても何も変わりません。 以前はgmac0で動作していました。 何か解決策はありますか。 io pkt呼び出し: io-pkt-v6-hc -p tcpip -d pfe-2 pfe0_mac=000a0b0c0d66,pfe1_mac=001a1b1c1d66,pfe2_mac=002a2b2c2d66,class_fw=/proc/boot/s32g_pfe_class.fw,no_reset,mode0=sgmii,phy0=0,mode1=sgmii,phy1=1 U-Bootパラメータ： UbootはLinuxのSDカードイメージと同じで、qnxブート用にパーメーターを修正しています。 setenv hwconfig "pcie0:mode=rc,clock=ext;pcie1:mode=sgmii,clock=ext,fmhz=125,xpcs_mode=2G5" setenv pfeng_mode 'enable,sgmii,sgmii,rgmii' setenv s32cc_gmac_mode disable setenv pfeng enable; s32ccgmac disable; s32ccgmac enable; setenv boot_qnx_atf 'mmc dev 0; fatload mmc 0:1 0x83e00000 s32g399a-rdb3.dtb;pfeng を有効化; s32ccgmac を無効化; s32ccgmac を有効化; fatload mmc 0:1 0x80080000 ifs-s32g399a-rdb.ui;bootm 0x80080000 - 0x83E00000' setenv bootcmd 'run boot_qnx_atf' saveenv ログ： U-Boot 2020.04+g156b168010(2023年6月9日 10:14:25 +0000)   CPU: NXP S32G399A rev.1.1 モデル:NXP S32G399A-RDB3 DRAM: 3.5 GiB MMC: FSL_SDHC: 0 MMCから環境を読み込んでいます... OK PCIe0をルートコンプレックスとして構成する PCIe0: リンクアップに失敗しました PCI: 自動構成バー 1c が失敗しました 入力: serial@401c8000 出力: serial@401c8000 エラー: serial@401c8000 ボード改訂：RDB3 改訂F ネットワーク: EQOS 物理: rgmii @ 1   警告: eth_eqos (eth0) はランダムな MAC アドレス - 26:e4:e6:43:15:ad を使用しています eth0: eth_eqos emac1_xpcs の XPCS の速度を取得できませんでした PFE: emac0: sgmii emac1: sgmii emac2: rgmii 、eth1: eth_pfeng 自動起動を停止するには、いずれかのキーを押してください: 3 2 1 0 パーティション#0に切り替える、OK mmc0は現在のデバイスです 50640バイトを17ミリ秒で読み込みました（2.8 MiB/秒） 11948752バイトを540ミリ秒で読み込みました（21.1 MiB/秒） ## レガシーイメージからカーネルを80080000番地で起動中... 画像名: イメージタイプ:AArch64 Linux カーネルイメージ(非圧縮) データサイズ: 11948688バイト = 11.4MiB ロードアドレス: 80080000 エントリーポイント: 80080000 チェックサムを検証中...OK ## フラット化されたデバイスツリーブロブ (83e00000) 0x83e00000にあるfdtブロブを使用して起動しています カーネルイメージをロード中 デバイスツリーを0000000083e00000で使用、終了0000000083e0f5cf 修正: pfe0 を 00:01:be:be:ef:11 に設定 修正: pfe1 を 00:01:be:be:ef:22 に設定 修正: pfe1: phy アドレスを 0x8 に更新 修正: pfe2 を 00:01:be:be:ef:33 に設定   カーネルを起動中…   EVB/RDB上のPFEドライバ用にRAM領域を予約する 終わり。 ClockCyclesのサンプル： 0 43600679 1 43600679 2 43600678 3 43600679 4 43600678 5 43600678 6 43600678 7 43600679 許容範囲内のすべてのクロックサイクルオフセット QNX Neutrino 7.1.0へようこそNXP S32G399A RDBボード上で!! 監視役を開始… シリアルドライバー起動中... ネットワークドライバー(/dev/socket)を起動中...   プロセス4107（ifconfig）が終了ステータス0で終了しました。   プロセス10（sh）が終了ステータス0で終了しました。   プロセス9（dhclient）の終了ステータスは0です。 cp: ファイルをオープンソースできません。(/proc/boot/libfci_cli)   プロセス20489（cp）が終了ステータス1で終了しました。 起動中のSPIドライバー(/dev/spi0,1,2,3,4,5)... I2C 0/1/2/3/4ドライバー(/dev/i2c0,1,2,3,4)を起動中... USDHC0メモリーカードドライバーを起動中... [00] SIM="SDMMC" HBA="imx" [00,0,0] type=00 ver=05 resp=00 SDMMC:   プロセス24596（chkqnx6fs）が終了ステータス0で終了しました。   プロセス28692（マウント）が終了ステータス0で終了しました。 QSPI Flashドライバーを起動中... USBホストドライバー(/dev/usb/*)を起動中 検出されたQSPIフラッシュ：Macronix MX25UW512、JEDEC 0xC2 - 0x813A、サイズ：0x4000000 /dev/usb/* 用に devb-umass を起動しています... # プロセス36891（スリープ）が終了ステータス0で終了しました。 sh: /var/cetitec2/startup.sh:そのようなファイル、又はディレクトリはありません   プロセス 45081 (sh) は、プロセス 0 によって signo=0 code=0 で終了しました。 slog2info   1月1日 00:00:00.023ランダム。4low* 0 qcrypto: 設定ファイル '/etc/qcrypto.conf' を読み込んでいます[qcrypto_common.c(190)] 1月1日 00:00:00.024random.4..0 slog* 700 Random は Fortuna PRNG を使用しています 1月1日 00:00:00.031ランダム。4low 0 qcrypto: 'openssl' プラグインがロードされました [qcrypto_plugins.c(354)] 1月1日 00:00:00.031random.4..0 slog 700 タイマーをエントロピー源として選択 1月1日 00:00:00.032random.4..0 slog 700 登録されたパス名 1月1日 00:00:00.032random.4..0 slog 700 random: resmgr を起動しています 1月1日 00:00:00.032random.4..0 slog 700 random: プロセスをデーモン化しています 1月1日 00:00:00.042devc_serlinflexd.7slog* 0 serlinflexd_interrupt_attach: 割り込み 114 に接続しています 1月1日 00:00:00.047iopkt.8main_buffer* 0 tcpip 起動中 1月1日 00:00:00.047iopkt.8main_buffer SMMUサポートは無効化されています 1月1日 00:00:00.049iopkt.8main_buffer 0 IPsecを初期化しています... 1月1日 00:00:00.049iopkt.8メインバッファ 0 完了   1月1日 00:00:00.049iopkt.8main_buffer 0 IPsec:初期化されたセキュリティ関連プロセッシング。   1月1日 00:00:00.051iopkt.8main_buffer 0 devnp-pfe-2.so pfe0_mac=000a0b0c0d66,pfe1_mac=001a1b1c1d66,pfe2_mac=002a2b2c2d66,class_fw=/proc/boot/s32g_pfe_class.fw,pfe0_mode=sgmii,pfe0_phy=0,pfe1_mode=sgmii,pfe1_phy=1 1月1日 00:00:00.052io_pkt_v6_hc.8slog* 0 INF[src/pfe_drv.c:1377]:バージョン情報 ドライバーバージョン:1.4.0 ドライバーコミットハッシュ: 2f3265a49ac18f94ba5e48254c8f870fe7bfc511 PFE_CFG_MULTI_INSTANCE_SUPPORT: 0 PFE_CFG_LOCAL_IF: 6 PFE_CFG_MASTER_IF: 6 PFE_CFG_SC_HIF: 1 PFE_CFG_HIF_RING_LENGTH: 256 PFE_CFG_PFE0_PROMISC: 1 PFE_CFG_PFE1_PROMISC: 1 PFE_CFG_PFE2_PROMISC: 1     1月1日 00:00:00.052io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1384]:--- 安全なIRQが有効になっています。InterruptAttach() または InterruptAttach_r() は許可されていません。   1月1日 00:00:00.052io_pkt_v6_hc.8slog 0 INF[src/pfe_fw.c:83]:42792バイトを読み込みました   1月1日 00:00:00.053io_pkt_v6_hc.8slog 0 INF[src/pfe_fw.c:89]:ファームウェアファイルがロードされました: /proc/boot/s32g_pfe_class.fw   1月1日 00:00:00.053io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1477]:pfe0/EMAC0のMIIモード設定が見つかりませんでした。SGMIIを使用しています。   1月1日 00:00:00.053io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1477]:pfe1/EMAC1のMIIモード設定が見つかりませんでした。SGMIIを使用しています。   1月1日 00:00:00.053io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1477]:pfe2/EMAC2 用の MII モード設定が見つかりませんでした。RGMIIを使用しています。   1月1日 00:00:00.053io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1495]:PFEペリフェラルリセットを発行中...   1月1日 00:00:00.274io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1496]:PFEリセット成功。   1月1日 00:00:00.274io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:3519]:PFE CBUS p0x46000000 が v0x38f2e23000 にマッピングされました   1月1日 00:00:00.274io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:3524]:ハードウェアバージョン 0x101   1月1日 00:00:00.274io_pkt_v6_hc.8slog 0 INF[src/pfe_hw_feature.c:95]: シリコンS32G3   1月1日 00:00:00.274io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:3536]:フェイルストップモードは無効です   1月1日 00:00:00.275io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2687]:PFE_ERRORS:パリティインスタンスが作成されました   1月1日 00:00:00.275io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2702]:PFE_ERRORS: ウォッチドッグインスタンスが作成されました   1月1日 00:00:00.275io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2718]:PFE_ERRORS:バスエラーインスタンスが作成されました   1月1日 00:00:00.275io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2731]:PFE_ERRORS:FW フェイルストップインスタンスが作成されました   1月1日 00:00:00.275io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2744]:PFE_ERRORS:ホストの障害停止インスタンスが作成されました   1月1日 00:00:00.275io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2757]:PFE_ERRORS:インスタンスの停止に失敗しました   1月1日 00:00:00.275io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2770]:PFE_ERRORS: ECC エラーインスタンスが作成されました   1月1日 00:00:00.275io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:1766]:BMU1 バッファベース: p0xc0000000   1月1日 00:00:00.277io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:1810]:BMU2バッファベース：p0x83000000（0x200000バイト）   1月1日 00:00:00.279io_pkt_v6_hc.8slog 0 INF[src/oal_irq_qnx.c:117]:PFE BMU IRQワーカーが開始されました（IRQ ID：226）   1月1日 00:00:00.279io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:2194]:オプション「g2_ordered_class_writes」は無効になっています。   1月1日 00:00:00.279io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_bmu_csr.c:96]: BMU_EMPTY_INT (BMU @ p0x88000)。プール準備完了。   1月1日 00:00:00.279io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_bmu_csr.c:96]: BMU_EMPTY_INT (BMU @ p0x8c000)。プール準備完了。   1月1日 00:00:00.281io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2239]:ファームウェア.elf検出されました   1月1日 00:00:00.281io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2248]:CLASSファームウェアをアップロード中   1月1日 00:00:00.281io_pkt_v6_hc.8slog 0 INF[src/pfe_pe.c:609]:選択したFWロード操作により、8つのPEを並列ロードします。   1月1日 00:00:00.285io_pkt_v6_hc.8slog 0 INF[src/pfe_pe.c:1945]:pfe_ct.hファイルバージョン"92367c0e25f21f49217a9b08168ad2c8"   1月1日 00:00:00.288io_pkt_v6_hc.8slog 0 INF[src/pfe_pe.c:2422]:[FW バージョン] 1.7.0、ビルド: 2023年6月2日 13:48:57 (nogitaaa)、ID: 0x31454650   1月1日 00:00:00.406io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:2312]:VLAN IDが間違っているか、設定されていません。デフォルトのVLAN ID = 0x01を使用します。   1月1日 00:00:00.406io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:2318]:VLAN統計情報のサイズが正しくないか、設定されていません。デフォルトのVLAN統計サイズ=20を使用します。   1月1日 00:00:00.406io_pkt_v6_hc.8slog 0 INF[src/pfe_l2br.c:1181]:ソフトウェアVLANハッシュテーブル @ p0x20001228     1月1日 00:00:00.406io_pkt_v6_hc.8slog 0 INF[src/pfe_l2br.c:1286]:フォールバックブリッジドメイン @ 0x20000a7c (クラス)   1月1日 00:00:00.406io_pkt_v6_hc.8slog 0 INF[src/pfe_l2br.c:1287]:デフォルトブリッジドメイン @ 0x20000a74 (クラス)   1月1日 00:00:00.406io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2412]:ルーティングテーブルが作成されました。ハッシュテーブルはp0x80014000、プールはp0x8001c000です（65536バイト）。   1月1日 00:00:00.407io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_chnl.c:1997]: RXバッファプールを初期化しています。深度: 256; バッファサイズ: 2048; キャッシュラインサイズ: 64   1月1日 00:00:00.408io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_chnl.c:1997]: RXバッファプールを初期化しています。深度: 256; バッファサイズ: 2048; キャッシュラインサイズ: 64   1月1日 00:00:00.409io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_chnl.c:1997]: RXバッファプールを初期化しています。深度: 256; バッファサイズ: 2048; キャッシュラインサイズ: 64   1月1日 00:00:00.508io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:3705]:機能 err051211_workaround: 無効   1月1日 00:00:00.509iopkt.8メインバッファ 0 pfe0   1月1日 00:00:00.509io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2152]:pfe0: PHYモードを使用: MDIO=0、ADDR=0、CLAUSE=0、RESET=0   1月1日 00:00:00.509io_pkt_v6_hc.8slog 0 INF[src/oal_irq_qnx.c:117]:PFE HIF0 IRQワーカーが開始されました（IRQ ID: 222）   1月1日 00:00:00.509io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1795]:pfe0に00:0a:0b:0c:0d:66を追加   1月1日 00:00:00.511iopkt.8メインバッファ 0 pfe1   1月1日 00:00:00.511io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2298]:pfe0の速度/デュプレックス設定が見つかりませんでした。1Gbps/全二重通信を使用。   1月1日 00:00:00.511io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:336]: HIFクライアントの登録を試みます: 0   1月1日 00:00:00.511io_pkt_v6_hc.8スログ0 INF[SRC/pfe_hif_drv_sc.c:1189]:HIFドライバー起動   1月1日 00:00:00.511io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2363]:新しいPFEデバイス: 0、ID: 0   1月1日 00:00:00.511io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2152]:pfe1: PHYモードを使用: MDIO=1、ADDR=0、CLAUSE=0、RESET=0   1月1日 00:00:00.511io_pkt_v6_hc.8slog 0 INF[src/oal_irq_qnx.c:117]:PFE HIF1 IRQワーカーが開始されました（IRQ ID：223）   1月1日 00:00:00.511io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1795]:pfe1に00:1a:1b:1c:1d:66を追加   1月1日 00:00:00.513iopkt.8メインバッファ 0 pfe2   1月1日 00:00:00.513io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2298]:pfe1の速度/デュプレックス設定が見つかりませんでした。1Gbps/全二重通信を使用。   1月1日 00:00:00.513io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:336]: HIFクライアントの登録を試みます: 1   1月1日 00:00:00.513io_pkt_v6_hc.8スログ0 INF[SRC/pfe_hif_drv_sc.c:1189]:HIFドライバー起動   1月1日 00:00:00.513io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2363]:新しいPFEデバイス：1、ID：2   1月1日 00:00:00.513io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2145]:pfe2: 静的PHYモードを使用、RESET=0   1月1日 00:00:00.513io_pkt_v6_hc.8slog 0 INF[src/oal_irq_qnx.c:117]:PFE HIF2 IRQワーカーが開始されました（IRQ ID: 224）   1月1日 00:00:00.513io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1795]:pfe2に00:2a:2b:2c:2d:66を追加   1月1日 00:00:00.515io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2298]:pfe2の速度/デュプレックス設定が見つかりませんでした。1Gbps/全二重通信を使用。   1月1日 00:00:00.515io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:336]: HIFクライアントの登録を試みました: 2   1月1日 00:00:00.515io_pkt_v6_hc.8スログ0 INF[SRC/pfe_hif_drv_sc.c:1189]:HIFドライバー起動   1月1日 00:00:00.515io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2363]:新しいPFEデバイス：2、ID：4   1月1日 00:00:00.530io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2702]:pfe0に00:0a:0b:0c:0d:66を追加   1月1日 00:00:00.530io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2707]:MACアドレス00:0a:0b:0c:0d:66をpfe0に割り当てることができません   1月1日 00:00:00.530io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します   1月1日 00:00:00.538io_pkt_v6_hc.8スログ 0 INF[src/pfe_mdio.c:427]:pfe0: PHY @ バス 0 アドレス 0 が見つかりません。静的モードに切り替えます。   1月1日 00:00:00.538io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2829]:SGMIIにおけるEMAC速度の変更は、現在サポートされていません。   1月1日 00:00:00.538io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加   1月1日 00:00:00.540io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します   1月1日 00:00:00.540io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:00:00:00:01を追加できませんでした   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2829]:SGMIIにおけるEMAC速度の変更は、現在サポートされていません。   1月1日 00:00:00.542io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に01:00:5e:00:00:01を追加   1月1日 00:00:00.544io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加   1月1日 00:00:00.544io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:00:00:00:01を追加できませんでした   1月1日 00:00:00.544io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加   1月1日 00:00:00.544io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした   1月1日 00:00:00.544io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します   1月1日 00:00:00.554spi_master.24585 通常* 0 スパイマスターリソースマネージャー起動 1月1日 00:00:00.558spi_master.24587 通常* 0 spi-masterリソースマネージャー起動 1月1日 00:00:00.561spi_master.24588 normal* 0 spi-master resource マネージャ 起動 1月1日 00:00:00.565spi_master.24589 通常* 0 スパイマスターリソースマネージャー開始 1月1日 00:00:00.582devb_sdmmc_mx8x.24595 slog* 1800 devb-sdmmc-mx8x 1.00A (2026年6月23日 09:45:48) 1月1日 00:00:00.583devb_sdmmc_mx8x.24595 スログ 0 libcam.so(2020年6月22日 21:33:15) ババー 7010003 1月1日 00:00:00.594devb_sdmmc_mx8x.24595 slog 1800 sdio_cd: 挿入パス 0、cd 状態 0x1 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 SD CID: 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 MID 0x27、OID 0x5048、PNM SD32G 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 PRV 0x62、PSN 0x6c62d132、MDT 4-2023 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 SD CSD: 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 CSD_STRUCTURE 1、SPEC_VERS 0、CCC 0x5b5 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 TAAC 14、NSAC 0、TRAN_SPEED 50 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 C_SIZE 59023、C_SIZE_MULT 0 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 READ_BL_LEN 9、WRITE_BL_LEN 9 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 ERASE GRP_SIZE 0, GRP_MULT 0, SIZE 127 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 blksz 512、セクター 60440576、dtr 25000000 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 SD SW CAPS: 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 バスモード 0x3、コマンドシステム 0x1 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 drvタイプ 0x1、現在の制限 0x1 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 dtr 50000000 1月1日 00:00:00.644devb_sdmmc_mx8x.24595 slog 1800 CFG: タイミング HS、DTR 50000000、バス幅 4 ビット   1月1日 00:00:00.645devb_sdmmc_mx8x.24595 スログ 100 cam-disk.so(2020年6月22日 21:33:17) 1月1日 00:00:00.647devb_sdmmc_mx8x.24595 slog 0 scsi_interpret_sense (sdmmc ptl-0:0:0): cam_status=c4、scsi_status=2、flag=00000040、vuflag=0008、cmd=1a、error=70、sense=5、asc=24、ascq=0 1月1日 00:00:00.647devb_sdmmc_mx8x.24595 slog 0 scsi_interpret_sense (sdmmc ptl-0:0:0): cam_status=c4、scsi_status=2、flag=00000040、vuflag=0008、cmd=5a、error=70、sense=5、asc=24、ascq=0 1月1日 00:00:00.647devb_sdmmc_mx8x.24595 slog 0 scsi_interpret_sense (sdmmc ptl-0:0:0): cam_status=c4、scsi_status=2、flag=00000040、vuflag=0008、cmd=5a、error=70、sense=5、asc=24、ascq=0 1月1日 00:00:01.827devb_sdmmc_mx8x.24595 slog 1000 fs-qnx6: 割り当て戦略 0 1月1日 00:00:01.827devb_sdmmc_mx8x.24595 slog 1000 fs-qnx6: btree ディレクトリ 0 を使用します 1月1日 00:00:01.828devb_sdmmc_mx8x.24595 slog 1000 fs-qnx6: fs-qnx6: trim (0,1048576,2) は要求されておらず、サポートされていません 1月1日 00:00:01.833io_usb_otg.36885 slog* 0 main(453)[tid:1]: io-usb-otg (2020年6月13日 20:10:17) args: -d hcd-ehci-mx28 ioport=0x44064100,irq=243,ulpi,no_stream,verbose=5 1月1日 00:00:01.835devf_qspi_s32g.36884 slog* 0 (devf t1::f3s_qspi_ident:73) ページサイズ: 256 1月1日 00:00:01.835devf_qspi_s32g.36884 slog 0 (devf t1::f3s_qspi_ident:74) チップの合計サイズ: 0x4000000、ユニットサイズ: 0x10000 1月1日 00:00:01.839io_usb_otg.36885 slog 0 ehci_init: サーバーバージョン2で初期化中 1月1日 00:00:01.839io_usb_otg.36885 slog 0 ehci_controller_init(4303): devu-hcd-ehci-mx28.so (2024年4月19日 13:44:54): args ulpi,no_stream,verbose=5 1月1日 00:00:01.840io_usb_otg.36885 slog 8 usb_enum_port(94)[tid:1]: busno 0, parent -1, port 0, High speed 1月1日 00:00:01.840io_usb_otg.36885 slog 11 usb_client_descriptor_get(198)[tid:1]: (タイプ 1、インデックス 0、長さ 😎 1月1日 00:00:01.840io_usb_otg.36885 slog 12 usb_device_set_address(245)[tid:1]: b:0 devno 0 1月1日 00:00:01.840io_usb_otg.36885 slog 11 usb_client_descriptor_get(198)[tid:1]: (タイプ 1、インデックス 0、長さ 18) 1月1日 00:00:01.841io_usb_otg.36885 slog 11 usb_client_descriptor_get(198)[tid:1]: (タイプ 2、インデックス 0、長さ 9) 1月1日 00:00:01.841io_usb_otg.36885 slog 11 usb_client_descriptor_get(198)[tid:1]: (タイプ 2、インデックス 0、長さ 25) 1月1日 00:00:01.841io_usb_otg.36885 slog 8 usb_enum_port(141)[tid:1]: vid 0x0000、did 0x0000 が列挙されました(busno 0、devno 0:0) 1月1日 00:00:01.841io_usb_otg.36885 slog 11 hub_state_inserted(569)[tid:1]: bdentry 0, dentry 0 0 1月1日 00:00:01.841io_usb_otg.36885 slog 13 hub_configuration_enable(263)[tid:1]: 1 1月1日 00:00:01.943io_usb_otg.36885 slog 0 usbh_timeout_init(203)[tid:1]: 完了 1月1日 00:00:01.954io_usb_otg.36885 slog 0 read_vid_pid: ULPI VID 0x0424 PID 0x0009 1月1日 00:00:01.954io_usb_otg.36885 slog 0 s32g_phy_set_vbus: set_vbus off 1月1日 00:00:01.968io_usb_otg.36885 slog 0 s32g_phy_set_vbus: set_vbus オン 1月1日 00:00:01.979io_usb_otg.36885 slog 0 ehci_get_port_status(3568 0x44064100): port=0, tpstatus 10100 e_pstatus 8c001000 1月1日 00:00:01.979io_usb_otg.36885 slog 8 usb_enum_port_extract(172)[tid:7]: (busno 0, pdevno 0, portno 1) 1月1日 00:00:01.979io_usb_otg.36885 slog 8 usb_enum_port_extract(192)[tid:7]: ステータス (2) 1月1日 00:00:01.983devb_umass.36886 slog* 900 devb-umass 1.00A (2020年6月22日 21:33:41) 1月1日 00:00:01.984devb_umass.36886 スログ 0 libcam.so(2020年6月22日 21:33:15)学士 7010003 1月1日 00:00:01.985io_usb_otg.36885 slog 0 usbdi_client_connect(58)[tid:5]: pid 36886 proc=proc/boot/devb-umass usbdi_client 32eebb9a80 1月1日 00:00:01.986io_usb_otg.36885 slog 0 usbdi_resmgr_connect(310)[tid:5]: usbdi_resmgr_connect: pid 36886 usbdi_client 32eebb9a80 1月1日 00:00:01.986devb_umass.36886 slog 0 usbdi デバッグパス /pps/usb/debug/ が存在しません   プロセス49177（slog2info）が終了ステータス0で終了しました。 # ifconfig   lo0: flags=8049 mtu 33136 inet 127.0.0.1 ネットマスク 0xff000000 inet6 ::1 プレフィックス長 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 pfe0: flags=8843 mtu 1500 capabilities=1f 有効=0 アドレス: 00:0a:0b:0c:0d:66 メディア:イーサネットなし(1000baseT全二重) ステータス: アクティブ inet 0.0.0.0 ネットマスク 0xff000000 ブロードキャスト 255.255.255.255 inet6 fe80::20a:bff:fe0c:d66%pfe0 prefixlen 64 scopeid 0x11 pfe1: flags=8802 mtu 1500 capabilities=1f 有効=0 住所: 00:1a:1b:1c:1d:66 メディア:イーサネットなし(1000baseT全二重) 状態: キャリアなし pfe2: flags=8802 mtu 1500 capabilities=1f 有効=0 アドレス: 00:2a:2b:2c:2d:66 メディア:イーサネットなし(1000baseT全二重) 状態: キャリアなし   プロセス57369（ifconfig）が終了ステータス0で終了しました。 # Re: S32G399A-RDB3 QNX PFE Driver Problems さて、ここでs32g_pfe_class.fwとs32g_pfe_util.fwをPFE-FW_S32G_1.6.0.zipのファイルに置き換えました: https://nxp.flexnetoperations.com/control/frse/download?agree=Accept&element=14074877 U-Bootパラメータ： setenv boot_qnx_atf 'mmc dev 0; fatload mmc 0:1 0x83e00000 s32g399a-rdb3.dtb;atf_fdt_0to3 を実行; atf_fdt_4to7 を実行; mmc 0:1 0x80080000 ifs-s32g399a-rdb.ui をファットロード;pfeng 有効化; s32ccgmac 無効化; s32ccgmac 有効化; bootm 0x80080000 - 0x83E00000' setenv atf_fdt_0to3 'fdt addr 0x83e00000; fdt resize; fdt set /cpus/cpu@1 cpu-release-addr <0x0 0xa0000010>; fdt set /cpus/cpu@100 cpu-release-addr <0x0 0xa0000010>; fdt set /cpus/cpu@101 cpu-release-addr <0x0 0xa0000010>;' setenv atf_fdt_4to7 'fdt set /cpus/cpu@2 cpu-release-addr <0x0 0xa0000010>; fdt set /cpus/cpu@3 cpu-release-addr <0x0 0xa0000010>; fdt set /cpus/cpu@102 cpu-release-addr <0x0 0xa0000010>; fdt set /cpus/cpu@103 cpu-release-addr <0x0 0xa0000010>;' setenv release_cpus 'run cpu_trap; mp 1 release 0xa0000000; mp 2 release 0xa0000000; mp 3 release 0xa0000000; mp 4 release 0xa0000000; mp 5 release 0xa0000000; mp 6 release 0xa0000000; mp 7 release 0xa0000000;' setenv cpu_trap 'dcache off; mw.l 0xa0000000 0xd503205f; mw.l 0xa0000004 0x58000060; mw.l 0xa0000008 0xb4ffffc0; mw.l 0xa000000C 0xd61f0000; mw.q 0xa0000010 0x00000000; dcache on;' setenv bootcmd 'run boot_qnx_atf' setenv hwconfig "pcie0:mode=rc,clock=ext;pcie1:mode=sgmii,clock=ext,fmhz=125,xpcs_mode=2G5" setenv pfeng_mode 'enable,sgmii,sgmii,rgmii' setenv s32cc_gmac_mode disable saveenv 注: boot_qnx_atf から release_cpus コマンドを削除しました。そうしないと、CPU 1 エラーが発生するためです。 私にはあまり良く見えません。 お知らせ：BL2：v2.5（リリース）：bsp37.0_rc6-2.5 お知らせ：BL2：ビルド日時：2023年6月13日 09:12:21 通知: BL2: BL31を起動しています     U-Boot 2020.04+g156b168010(2023年6月9日 10:14:25 +0000)   CPU: NXP S32G399A rev.1.1 モデル:NXP S32G399A-RDB3 DRAM: 3.5 GiB MMC: FSL_SDHC: 0 MMCから環境を読み込んでいます... OK PCIe0をルートコンプレックスとして構成する PCIe0: リンクアップに失敗しました PCI: 自動構成バー 1c が失敗しました 入力: serial@401c8000 出力: serial@401c8000 エラー: serial@401c8000 ボード改訂：RDB3 改訂F ネットワーク: EQOS 物理: rgmii @ 1   警告: eth_eqos (eth0) はランダムな MAC アドレス 16:ec:a0:4e:1d:7c を使用しています eth0: eth_eqos emac1_xpcs の XPCS の速度を取得できませんでした PFE: emac0: sgmii emac1: sgmii emac2: rgmii 、eth1: eth_pfeng 自動起動を停止するには、いずれかのキーを押してください: 3 2 1 0 パーティション#0に切り替える、OK mmc0は現在のデバイスです 50640バイトを17ミリ秒で読み込みました（2.8 MiB/秒） 11950600バイトを534ミリ秒で読み込みました（21.3 MiB/秒） ## レガシーイメージからカーネルを80080000番地で起動中... 画像名: イメージタイプ:AArch64 Linux カーネルイメージ(非圧縮) データサイズ: 11950536バイト = 11.4MiB ロードアドレス: 80080000 エントリーポイント: 80080000 チェックサムを検証中...OK ## フラット化されたデバイスツリーブロブ (83e00000) 0x83e00000にあるfdtブロブを使用して起動しています カーネルイメージをロード中 デバイスツリーを0000000083e00000で使用、終了0000000083e0ffff 修正: pfe0 を 00:01:be:be:ef:11 に設定 修正: pfe1 を 00:01:be:be:ef:22 に設定 修正: pfe1: phy アドレスを 0x8 に更新 修正: pfe2 を 00:01:be:be:ef:33 に設定   カーネルを起動中…   EVB/RDB上のPFEドライバ用にRAM領域を予約する 終わり。 ClockCyclesのサンプル： 0 43642864 1 43642864 2 43642864 3 43642864 4 43642864 5 43642864 6 43642864 7 43642864 許容範囲内のすべてのクロックサイクルオフセット QNX Neutrino 7.1.0へようこそNXP S32G399A RDBボード上で!! 監視役を開始… シリアルドライバー起動中... ネットワークドライバー(/dev/socket)を起動中...   プロセス4107（ifconfig）が終了ステータス0で終了しました。   プロセス10（sh）が終了ステータス0で終了しました。   プロセス9（dhclient）の終了ステータスは0です。 cp: ファイルをオープンソースできません。(/proc/boot/libfci_cli)   プロセス20489（cp）が終了ステータス1で終了しました。 起動中のSPIドライバー(/dev/spi0,1,2,3,4,5)... I2C 0/1/2/3/4ドライバー(/dev/i2c0,1,2,3,4)を起動中... USDHC0メモリーカードドライバーを起動中... [00] SIM="SDMMC" HBA="imx" [00,0,0] type=00 ver=05 resp=00 SDMMC:   プロセス24596（chkqnx6fs）が終了ステータス0で終了しました。   プロセス28692（マウント）が終了ステータス0で終了しました。 QSPI Flashドライバーを起動中... USBホストドライバー(/dev/usb/*)を起動中 検出されたQSPIフラッシュ：Macronix MX25UW512、JEDEC 0xC2 - 0x813A、サイズ：0x4000000 /dev/usb/* 用に devb-umass を起動しています... # ifconfig   lo0: flags=8049 mtu 33136 inet 127.0.0.1 ネットマスク 0xff000000 inet6 ::1 プレフィックス長 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 pfe0: flags=8843 mtu 1500 capabilities=1f 有効=0 アドレス: 00:0a:0b:0c:0d:66 メディア:イーサネットなし(1000baseT全二重) ステータス: アクティブ inet 0.0.0.0 ネットマスク 0xff000000 ブロードキャスト 255.255.255.255 inet6 fe80::20a:bff:fe0c:d66%pfe0 prefixlen 64 scopeid 0x11 pfe1: flags=8802 mtu 1500 capabilities=1f 有効=0 住所: 00:1a:1b:1c:1d:66 メディア:イーサネットなし(1000baseT全二重) 状態: キャリアなし pfe2: flags=8802 mtu 1500 capabilities=1f 有効=0 アドレス: 00:2a:2b:2c:2d:66 メディア:イーサネットなし(1000baseT全二重) 状態: キャリアなし   プロセス40985（ifconfig）が終了ステータス0で終了しました。 # プロセス36891（スリープ）が終了ステータス0で終了しました。 sh: /var/cetitec2/startup.sh:そのようなファイル、又はディレクトリはありません   プロセス 53273 (sh) は、プロセス 0 によって signo=0 code=0 で終了しました。   # ifconfig   lo0: flags=8049 mtu 33136 inet 127.0.0.1 ネットマスク 0xff000000 inet6 ::1 プレフィックス長 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 pfe0: flags=8843 mtu 1500 capabilities=1f 有効=0 アドレス: 00:0a:0b:0c:0d:66 メディア:イーサネットなし(1000baseT全二重) ステータス: アクティブ inet 0.0.0.0 ネットマスク 0xff000000 ブロードキャスト 255.255.255.255 inet6 fe80::20a:bff:fe0c:d66%pfe0 prefixlen 64 scopeid 0x11 pfe1: flags=8802 mtu 1500 capabilities=1f 有効=0 住所: 00:1a:1b:1c:1d:66 メディア:イーサネットなし(1000baseT全二重) 状態: キャリアなし pfe2: flags=8802 mtu 1500 capabilities=1f 有効=0 アドレス: 00:2a:2b:2c:2d:66 メディア:イーサネットなし(1000baseT全二重) 状態: キャリアなし   # slog2info | grep pfe 1月1日 00:00:00.051 iopkt.8main_buffer 0 devnp-pfe-2.so pfe0_mac=000a0b0c0d66,pfe1_mac=001a1b1c1d66,pfe2_mac=002a2b2c2d66,class_fw=/proc/boot/s32g_pfe_class.fw 1 月 1 日 00:00:00.052 io_pkt_v6_hc.8slog* 0 INF[src/pfe_drv.c:1377]:バージョン情報 1 月 1 日 00:00:00.052 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1384]:--- 安全なIRQが有効になっています。InterruptAttach() または InterruptAttach_r() は許可されていません。 1 月 1 日 00:00:00.052 io_pkt_v6_hc.8slog 0 INF[src/pfe_fw.c:83]:49480バイトを読み込みました 1 月 1 日 00:00:00.052 io_pkt_v6_hc.8slog 0 INF[src/pfe_fw.c:89]:ファームウェアファイルがロードされました: /proc/boot/s32g_pfe_class.fw 1 月 1 日 00:00:00.053 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1477]:pfe0/EMAC0のMIIモード設定が見つかりませんでした。SGMIIを使用しています。 1 月 1 日 00:00:00.053 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1477]:pfe1/EMAC1のMIIモード設定が見つかりませんでした。SGMIIを使用しています。 1 月 1 日 00:00:00.053 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1477]:pfe2/EMAC2 用の MII モード設定が見つかりませんでした。RGMIIを使用しています。 1 月 1 日 00:00:00.053 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1495]:PFEペリフェラルリセットを発行中... 1月1日 00:00:00.274 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1496]:PFEリセット成功。 1 月 1 日 00:00:00.274 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:3519]:PFE CBUS p0x46000000 が v0x1abef95000 にマッピングされました 1 月 1 日 00:00:00.274 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:3524]:ハードウェアバージョン 0x101 1 月 1 日 00:00:00.274 io_pkt_v6_hc.8slog 0 INF[src/pfe_hw_feature.c:95]: シリコンS32G3 1 月 1 日 00:00:00.274 io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:3536]:フェイルストップモードは無効です 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2687]:PFE_ERRORS:パリティインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2702]:PFE_ERRORS: ウォッチドッグインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2718]:PFE_ERRORS:バスエラーインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2731]:PFE_ERRORS:FW フェイルストップインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2744]:PFE_ERRORS:ホストの障害停止インスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2757]:PFE_ERRORS:インスタンスの停止に失敗しました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2770]:PFE_ERRORS: ECC エラーインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:1766]:BMU1 バッファベース: p0xc0000000 1 月 1 日 00:00:00.277 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:1810]:BMU2バッファベース：p0x83000000（0x200000バイト） 1 月 1 日 00:00:00.279 io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:2194]:オプション「g2_ordered_class_writes」は無効になっています。 1 月 1 日 00:00:00.279 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_bmu_csr.c:96]: BMU_EMPTY_INT (BMU @ p0x88000)。プール準備完了。 1 月 1 日 00:00:00.279 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_bmu_csr.c:96]: BMU_EMPTY_INT (BMU @ p0x8c000)。プール準備完了。 1 月 1 日 00:00:00.281 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2239]:ファームウェア.elf検出されました 1 月 1 日 00:00:00.281 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2248]:CLASSファームウェアをアップロード中 1 月 1 日 00:00:00.281 io_pkt_v6_hc.8slog 0 INF[src/pfe_pe.c:609]:選択したFWロード操作により、8つのPEを並列ロードします。 1 月 01 日 00:00:00.285 io_pkt_v6_hc.8slog 0 INF[src/pfe_pe.c:1945]:pfe_ct.hファイルバージョン"92367c0e25f21f49217a9b08168ad2c8" 1 月 1 日 00:00:00.288 io_pkt_v6_hc.8slog 0 INF[src/pfe_pe.c:2422]:[FW バージョン] 1.6.0、ビルド: 2023年3月15日 12:37:54 ()、ID: 0x31454650 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:2312]:VLAN IDが間違っているか、設定されていません。デフォルトのVLAN ID = 0x01を使用します。 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:2318]:VLAN統計情報のサイズが正しくないか、設定されていません。デフォルトのVLAN統計サイズ=20を使用します。 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 INF[src/pfe_l2br.c:1181]:ソフトウェアVLANハッシュテーブル @ p0x20001208 1月1日 00:00:00.406 io_pkt_v6_hc.8slog 0 INF[src/pfe_l2br.c:1286]:フォールバックブリッジドメイン @ 0x20000a44 (クラス) 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 INF[src/pfe_l2br.c:1287]:デフォルトのブリッジドメイン @ 0x20000a3c (クラス) 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2412]:ルーティングテーブルが作成されました。ハッシュテーブルはp0x80014000、プールはp0x8001c000です（65536バイト）。 1 月 1 日 00:00:00.407 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_chnl.c:1997]: RXバッファプールを初期化しています。深度: 256; バッファサイズ: 2048; キャッシュラインサイズ: 64 1 月 1 日 00:00:00.408 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_chnl.c:1997]: RXバッファプールを初期化しています。深度: 256; バッファサイズ: 2048; キャッシュラインサイズ: 64 1 月 1 日 00:00:00.409 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_chnl.c:1997]: RXバッファプールを初期化しています。深度: 256; バッファサイズ: 2048; キャッシュラインサイズ: 64 1 月 1 日 00:00:00.508 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:3705]:機能 err051211_workaround: 無効 1月1日 00:00:00.509 iopkt.8メインバッファ 0 pfe0 1 月 1 日 00:00:00.509 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2145]:pfe0: 静的PHYモードを使用、RESET=0 1 月 1 日 00:00:00.510 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1795]:pfe0に00:0a:0b:0c:0d:66を追加 1月1日 00:00:00.512 iopkt.8メインバッファ 0 pfe1 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2298]:pfe0の速度/デュプレックス設定が見つかりませんでした。1Gbps/全二重通信を使用。 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:336]: HIFクライアントの登録を試みます: 0 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8スログ0 INF[SRC/pfe_hif_drv_sc.c:1189]:HIFドライバ起動 1月1日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2363]:新しいPFEデバイス: 0、ID: 0 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2145]:pfe1: 静的PHYモードを使用、RESET=0 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1795]:pfe1に00:1a:1b:1c:1d:66を追加 1月1日 00:00:00.514 iopkt.8メインバッファ 0 pfe2 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2298]:pfe1の速度/デュプレックス設定が見つかりませんでした。1Gbps/全二重通信を使用。 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:336]: HIFクライアントの登録を試みます: 1 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8スログ0 INF[SRC/pfe_hif_drv_sc.c:1189]:HIFドライバ起動 1月1日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2363]:新しいPFEデバイス：1、ID：2 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2145]:pfe2: 静的PHYモードを使用、RESET=0 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1795]:pfe2に00:2a:2b:2c:2d:66を追加 1 月 1 日 00:00:00.516 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2298]:pfe2の速度/デュプレックス設定が見つかりませんでした。1Gbps/全二重通信を使用。 1 月 1 日 00:00:00.516 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:336]: HIFクライアントの登録を試みました: 2 1 月 1 日 00:00:00.516 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:1189]: HIFドライバ started Jan 01 00:00:00.516 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2363]:新しいPFEデバイス：2、ID：4 1 月 1 日 00:00:00.531 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2702]:pfe0に00:0a:0b:0c:0d:66を追加 1 月 1 日 00:00:00.531 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2707]:MACアドレス00:0a:0b:0c:0d:66をpfe0に割り当てることができません 1 月 1 日 00:00:00.531 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します 1 月 1 日 00:00:00.531 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2829]:SGMIIにおけるEMAC速度の変更は、現在サポートされていません。 1 月 1 日 00:00:00.532 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加 1 月 1 日 00:00:00.534 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します 1 月 1 日 00:00:00.534 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:00:00:00:01を追加できませんでした 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2829]:SGMIIにおけるEMAC速度の変更は、現在サポートされていません。 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に01:00:5e:00:00:01を追加 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:00:00:00:01を追加できませんでした 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します #slog2info | grep io_pkt_v6_hc 1 月 1 日 00:00:00.052 io_pkt_v6_hc.8slog* 0 INF[src/pfe_drv.c:1377]:バージョン情報 1 月 1 日 00:00:00.052 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1384]:--- 安全なIRQが有効になっています。InterruptAttach() または InterruptAttach_r() は許可されていません。 1 月 1 日 00:00:00.052 io_pkt_v6_hc.8slog 0 INF[src/pfe_fw.c:83]:49480バイトを読み込みました 1 月 1 日 00:00:00.052 io_pkt_v6_hc.8slog 0 INF[src/pfe_fw.c:89]:ファームウェアファイルがロードされました: /proc/boot/s32g_pfe_class.fw 1 月 1 日 00:00:00.053 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1477]:pfe0/EMAC0のMIIモード設定が見つかりませんでした。SGMIIを使用しています。 1 月 1 日 00:00:00.053 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1477]:pfe1/EMAC1のMIIモード設定が見つかりませんでした。SGMIIを使用しています。 1 月 1 日 00:00:00.053 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1477]:pfe2/EMAC2 用の MII モード設定が見つかりませんでした。RGMIIを使用しています。 1 月 1 日 00:00:00.053 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1495]:PFEペリフェラルリセットを発行中... 1月1日 00:00:00.274 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1496]:PFEリセット成功。 1 月 1 日 00:00:00.274 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:3519]:PFE CBUS p0x46000000 が v0x1abef95000 にマッピングされました 1 月 1 日 00:00:00.274 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:3524]:ハードウェアバージョン 0x101 1 月 1 日 00:00:00.274 io_pkt_v6_hc.8slog 0 INF[src/pfe_hw_feature.c:95]: シリコンS32G3 1 月 1 日 00:00:00.274 io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:3536]:フェイルストップモードは無効です 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2687]:PFE_ERRORS:パリティインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2702]:PFE_ERRORS: ウォッチドッグインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2718]:PFE_ERRORS:バスエラーインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2731]:PFE_ERRORS:FW フェイルストップインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2744]:PFE_ERRORS:ホストの障害停止インスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2757]:PFE_ERRORS:インスタンスの停止に失敗しました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2770]:PFE_ERRORS: ECC エラーインスタンスが作成されました 1 月 01 日 00:00:00.275 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:1766]:BMU1 バッファベース: p0xc0000000 1 月 1 日 00:00:00.277 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:1810]:BMU2バッファベース：p0x83000000（0x200000バイト） 1 月 1 日 00:00:00.279 io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:2194]:オプション「g2_ordered_class_writes」は無効になっています。 1 月 1 日 00:00:00.279 io_pkt_v6_hc.8slog 0 INF[src/oal_irq_qnx.c:117]: PFE BMU IRQワーカーが開始されました (IRQ ID: 226) 1 月 1 日 00:00:00.279 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_bmu_csr.c:96]: BMU_EMPTY_INT (BMU @ p0x88000)。プール準備完了。 1 月 1 日 00:00:00.279 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_bmu_csr.c:96]: BMU_EMPTY_INT (BMU @ p0x8c000)。プール準備完了。 1 月 1 日 00:00:00.281 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2239]:ファームウェア.elf検出されました 1 月 1 日 00:00:00.281 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2248]:CLASSファームウェアをアップロード中 1 月 1 日 00:00:00.281 io_pkt_v6_hc.8slog 0 INF[src/pfe_pe.c:609]:選択したFWロード操作により、8つのPEを並列ロードします。 1 月 01 日 00:00:00.285 io_pkt_v6_hc.8slog 0 INF[src/pfe_pe.c:1945]:pfe_ct.hファイルバージョン"92367c0e25f21f49217a9b08168ad2c8" 1 月 1 日 00:00:00.288 io_pkt_v6_hc.8slog 0 INF[src/pfe_pe.c:2422]:[FW バージョン] 1.6.0、ビルド: 2023年3月15日 12:37:54 ()、ID: 0x31454650 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:2312]:VLAN IDが間違っているか、設定されていません。デフォルトのVLAN ID = 0x01を使用します。 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 WRN[hw/s32g/pfe_platform_master.c:2318]:VLAN統計情報のサイズが正しくないか、設定されていません。デフォルトのVLAN統計サイズ=20を使用します。 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 INF[src/pfe_l2br.c:1181]:ソフトウェアVLANハッシュテーブル @ p0x20001208 1月1日 00:00:00.406 io_pkt_v6_hc.8slog 0 INF[src/pfe_l2br.c:1286]:フォールバックブリッジドメイン @ 0x20000a44 (クラス) 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 INF[src/pfe_l2br.c:1287]:デフォルトのブリッジドメイン @ 0x20000a3c (クラス) 1 月 1 日 00:00:00.406 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:2412]:ルーティングテーブルが作成されました。ハッシュテーブルはp0x80014000、プールはp0x8001c000です（65536バイト）。 1 月 1 日 00:00:00.407 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_chnl.c:1997]: RXバッファプールを初期化しています。深度: 256; バッファサイズ: 2048; キャッシュラインサイズ: 64 1 月 1 日 00:00:00.408 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_chnl.c:1997]: RXバッファプールを初期化しています。深度: 256; バッファサイズ: 2048; キャッシュラインサイズ: 64 1 月 1 日 00:00:00.409 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_chnl.c:1997]: RXバッファプールを初期化しています。深度: 256; バッファサイズ: 2048; キャッシュラインサイズ: 64 1 月 1 日 00:00:00.508 io_pkt_v6_hc.8slog 0 INF[hw/s32g/pfe_platform_master.c:3705]:機能 err051211_workaround: 無効 1 月 1 日 00:00:00.509 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2145]:pfe0: 静的PHYモードを使用、RESET=0 1 月 1 日 00:00:00.509 io_pkt_v6_hc.8slog 0 INF[src/oal_irq_qnx.c:117]: PFE HIF0 IRQワーカーが開始されました (IRQ ID: 222) 1 月 1 日 00:00:00.510 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1795]:pfe0に00:0a:0b:0c:0d:66を追加 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2298]:pfe0の速度/デュプレックス設定が見つかりませんでした。1Gbps/全二重通信を使用。 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:336]: HIFクライアントの登録を試みます: 0 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8スログ0 INF[SRC/pfe_hif_drv_sc.c:1189]:HIFドライバ起動 1月1日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2363]:新しいPFEデバイス: 0、ID: 0 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2145]:pfe1: 静的PHYモードを使用、RESET=0 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/oal_irq_qnx.c:117]: PFE HIF1 IRQワーカーが開始されました (IRQ ID: 223) 1 月 1 日 00:00:00.512 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1795]:pfe1に00:1a:1b:1c:1d:66を追加 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2298]:pfe1の速度/デュプレックス設定が見つかりませんでした。1Gbps/全二重通信を使用。 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:336]: HIFクライアントの登録を試みます: 1 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8スログ0 INF[SRC/pfe_hif_drv_sc.c:1189]:HIFドライバ起動 1月1日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2363]:新しいPFEデバイス：1、ID：2 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2145]:pfe2: 静的PHYモードを使用、RESET=0 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/oal_irq_qnx.c:117]: PFE HIF2 IRQワーカーが開始されました (IRQ ID: 224) 1 月 1 日 00:00:00.514 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:1795]:pfe2に00:2a:2b:2c:2d:66を追加 1 月 1 日 00:00:00.516 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2298]:pfe2の速度/デュプレックス設定が見つかりませんでした。1Gbps/全二重通信を使用。 1 月 1 日 00:00:00.516 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:336]: HIFクライアントの登録を試みました: 2 1 月 1 日 00:00:00.516 io_pkt_v6_hc.8slog 0 INF[src/pfe_hif_drv_sc.c:1189]: HIFドライバ started Jan 01 00:00:00.516 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2363]:新しいPFEデバイス：2、ID：4 1 月 1 日 00:00:00.531 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2702]:pfe0に00:0a:0b:0c:0d:66を追加 1 月 1 日 00:00:00.531 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2707]:MACアドレス00:0a:0b:0c:0d:66をpfe0に割り当てることができません 1 月 1 日 00:00:00.531 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します 1 月 1 日 00:00:00.531 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2829]:SGMIIにおけるEMAC速度の変更は、現在サポートされていません。 1 月 1 日 00:00:00.532 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加 1 月 1 日 00:00:00.534 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します 1 月 1 日 00:00:00.534 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:00:00:00:01を追加できませんでした 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2829]:SGMIIにおけるEMAC速度の変更は、現在サポートされていません。 1 月 01 日 00:00:00.536 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に01:00:5e:00:00:01を追加 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:00:00:00:01を追加できませんでした 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした 1 月 1 日 00:00:00.538 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します プロセス172057（slog2info）が終了ステータス0で終了しました。 1 月 1 日 00:01:01.630 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:00:00:00:01を追加 1 月 1 日 00:01:01.630 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:00:00:00:01を追加できませんでした 1 月 1 日 00:01:01.630 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2443]:emac0に33:33:ff:0c:0d:66を追加 1 月 1 日 00:01:01.630 io_pkt_v6_hc.8slog 0 WRN[src/pfe_drv.c:2450]:emac0:17に33:33:ff:0c:0d:66を追加できませんでした 1 月 1 日 00:01:01.630 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2495]:emac0から01:00:5e:00:00:01を削除しています 1 月 1 日 00:01:01.632 io_pkt_v6_hc.8slog 0 INF[src/pfe_phy_if.c:2716]:アドレス 01:00:5e:00:00:01 が emac0 から削除されました 1 月 1 日 00:01:01.632 io_pkt_v6_hc.8slog 0 INF[src/pfe_drv.c:2663]:pfe0: プロミスキャスモードを無効化します Re: S32G399A-RDB3 QNX PFE Driver Problems こんにちは、 @Seneca 投稿ありがとうございます。 デフォルトでは、S32G PFE QNX ドライバーバージョン1.4.0はS32G PFEファームウェア標準バージョン1.6.0に対応していますが、このPFEファームウェアバージョンでもう一度テストしていただけますか? BR チェイン Re: S32G399A-RDB3 QNX PFE Driver Problems さて、ダウンロードしました BSP_nxp-s32g-evb_br-710_be-710_SVN984052_JBN51 あなたが言及したパッケージ、.buildを修正したファイルを追加して kprintf("EVB/RDB\nでPFEドライバー用にRAM領域を予約する"); as_add_containing(0x80000000,0x80000000 + 0x4000000 - 1,AS_ATTR_RAM、「pfe_ddr」「ram」); ～ src/hardware/startup/boards/s32g/s32g399a-rdb/s32g_init_raminfo.c を開き、ifs ファイルを生成された ifs-s32g399a-rdb.ui に置き換えます。 残念ながら、上記のpfe_ddr割り当ては実行されないようです。 この新しいイメージを動作させるために、ubootのパラメータなどを変更する必要はありますか？ よろしくお願いします。 Re: S32G399A-RDB3 QNX PFE Driver Problems こんにちは、 @Seneca ご返信ありがとうございます。 統合マニュアルを厳密に参照することをお勧めします。あなたが言及した部分を参照してください。QNX BSPをビルディングする前に以下の部分を修正する必要があります。 BR チェイン Re: S32G399A-RDB3 QNX PFE Driver Problems ご挨拶申し上げます。 NXPは、board_cleanup_before_linuxのように、PFEに必要なubootの変更が既に含まれているSDカードイメージを提供しているかどうかご存知ですか？ binaries_auto_linux_bsp37.0_s32g3_pfeのようなパッケージが何をするのかはわかりません。 よろしくお願いします。

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

SDKのフラッシュAPIと、欠けているデータD_Flash呼び出S32K144 チームの皆さん、こんにちは。 プロジェクト(S32K144)でSDKのflash init APIを呼び出し、その後Flash消去とFlash書き込みを呼び出します。その後、フラッシュメモリ内の一部のデータが0xFFになっていることに気づきました。そこで、フラッシュ初期化とフラッシュ消去/書き込みの間に遅延時間を追加してみたところ、データが正常になりました。そして、遅延関数を使用する代わりに、while (!(FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK)); をチェックしてみます。しかし、それでも失敗に終わった。SO、ハードウェア層でフラッシュモジュールの初期化が完了するまで待つ時間を少し遅らせなければならないのかもしれません。 BR ロキー Re: Call SDK flash API and some data in D_Flash missing of S32K144 こんにちは、 @Loky さん。 副操縦士が言いました:「どのドライバーバージョンを使っていますか?」 レガシーSDKドライバの使用は推奨されません。RTDドライバを使うべきです。 Flash_Init関数はフラッシュメモリの内容を変更しません。 消去・書き込み機能はすでに内部でCCIFフラグをポーリングしているので、アプリケーションコード内でポーリングする必要はありません。 観察された動作は、キャッシュまたはフラッシュのプリフェッチバッファに関連している可能性があります。PCCCRとOCMDR0を無効にして、問題が解決するかどうか確認してください。 よろしくお願いいたします。 ダニエル Re: Call SDK flash API and some data in D_Flash missing of S32K144 こんにちは、ダニエルさん。 これが現在使っているSDKのFlashドライバーバージョンです。同僚によると、S32K144はSDK Flash Driverしかなく、RTDドライバーはないそうです。SDKドライバーの何が問題なのか簡単に説明してもらえますか?もしS32K144 RTDドライバをお持ちなら、共有していただけますでしょうか。 ご指摘の方法（キャッシュを無効にする）を試してみましたが、うまくいきませんでした。 電源投入リセットまたはLVDリセット時に、フラッシュメモリにいくつかの情報を記録し、同じセクターに他のデータも記録します。私はすべてのセクターデータを読み込み、情報を更新してセクター向けに書き直します。しかし、いくつか新たな発見がありました。フラッシュメモリを読み取る前に、データが既に0xFFになっていることが分かりました。消去命令または書き込み命令の実行中にフラッシュメモリの電源が誤ってオフになった場合、電源を再びオンにしたときにセクター内のデータが0xFFになるのでしょうか？この問題を引き続き調査します。もしかしたらソフトウェアのバグかもしれません。 BR ロキー

MIMXRT1052CVJ5Bの電源問題 MIMXRT1050HDUGの仕様にあるように、このMCUには2つのバージョンが存在します。電源設計の参考にするために、自分のMCUの具体的なバージョンをどのように特定すればよいでしょうか？ i.MXRT 105x Re: MIMXRT1052CVJ5B供电问题 ありがとう！ Re: MIMXRT1052CVJ5B供电问题 こんにちは、 @Simon_CHan さん。 NXPのRTシリーズ製品にご関心をお寄せいただき、またNXPコミュニティをご利用いただきありがとうございます。 i.MX RT1050 のチップ正誤表にある ERR011093 を参照してください。正誤表には、この問題は A1 シリコンで修正済みであると記載されています。したがって、最も簡単な方法は、チップのシルクスクリーンでシリコン リビジョンを確認することです。A は A0、B は A1 を示します。バージョンが B の場合は、問題は修正済みです。バージョンが A の場合は、正誤表で規定されているとおり、DCDC_IN/DCDC_IN_Q を 2.8 V ～ 3.0 V の範囲内に制御する必要があります。 上記の情報がお役に立てば幸いです。 よろしくお願いします 5月

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

FS32K144UAVLL水晶発振器に問題が発生しました！ マネージャー： FS32K144UAVLL水晶発振器、20MHz水晶発振器、10pFの整合コンデンサ、1MRの負荷抵抗、および0.5Vp-pの電圧でグランドに接続された20MHzシングルエンド正弦波を使用します。MCUは外部水晶発振器を使用するプログラムを実行できませんが、内部水晶発振器を使用するプログラムは実行できます。 開発ボードプログラムを使用する場合、開発ボードはFS32K144HFVLで、8MHz水晶発振器、22pFの整合コンデンサ、1MRの負荷抵抗、および水晶発振器のグランドへのシングルエンド8MHz正弦波（電圧1Vp-p）を使用します。 すみません： 1. FS32K144UAVLLとFS32K144HFVLの違いは何ですか？同じプログラムを共有できますか？同じ外部水晶発振器を使用する必要がありますか？ 2. 外部水晶発振器（FS32K144UAVLL）の許容振幅はどれくらいですか？ 3．外部水晶発振器の振幅を調整する方法は？ ありがとう！ 回复： FS32K144UAVLL晶振问题！ こんにちは、 @YF666666 S32K1xxデータシートのセクション4では、M温度範囲（-40℃～125℃）では112MHzのコア周波数はサポートされていないことが明記されています。 データシートに添付されているS32K1xx_Orderable_Part_Number_List.xlsxを参照して、利用可能な部品番号を確認し、要件を満たすオプションを特定することをお勧めします。 Re: FS32K144UAVLL晶振问题！ こんにちは、 @YF666666 1. デバイスの違い FS32K144UAVLL U: コア周波数最大112MHz A：CAN FD、FlexIO、およびセキュリティ機能が含まれています FS32K144HFVLL H: コア周波数最大80MHz F：CAN FDおよびFlexIOを搭載（セキュリティ機能なし） 2. S32K1xxファミリは、4MHz～40MHzの範囲で外部水晶発振器または共振器をサポートします。 3. 水晶発振器の設計および振幅に関する検討事項については、以下の資料が参考になるかもしれません。 AN14518 ：水晶発振器設計ガイド AN5426 ：S32K1xx向けハードウェア設計ガイドライン これらの資料は、発振器の構成、負荷コンデンサ、および設計のベストプラクティスに関する詳細なガイダンスを提供します。 BR、VaneB 回复： FS32K144UAVLL晶振问题！ マネージャー： 主周波数が112MHzのFS32K144UAT0VLLTは、-40℃～+105℃の温度範囲で動作しますか？ 自動車用途の場合、-40℃～+125℃の車載グレードの温度範囲が必要です。 チップの型番は正しいでしょうか？FS32K144UAT0MLLTに変更され、メイン周波数は112MHz、パッケージはLQFP100となっています。 型番が間違っている場合は、正しい型番をお送りください。よろしくお願いいたします。 Re: FS32K144UAVLL晶振问题！ FS32K144UAVLLを8MHz水晶発振器、22pFの結合コンデンサ、および1MΩの負荷抵抗と組み合わせて試してみてください。

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

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

RDBESS774A3EVBに関するお問い合わせ - コネクタ（J1_1とJ1_3）の入れ替えによる基板の損傷 こんにちは、 現在、 RDBESS774A3EVB セルモニタリングユニット(CMU)ボード(MC33774Aバッテリー・セルコントローラ搭載)を50セルのバッテリーパック構成に接続して評価しています。 先日、テスト中に偶発的な接続ミスが発生しました。誤って、 J1_1 （上側のセット）とJ1_3 （下側のセット）のセルコネクタセットを入れ替えてしまいました。 事件発生時に以下の行動が観察された。 初期イベント: コネクタを交換した直後、セル36で激しいショートが発生し、外部の配線/トレースが焼き切れてしまいました。 その後の行動: ミスが分かった後、正しいコネクタ位置で同じ基板にバッテリーパックを再接続しました。 二次的な挙動：正しい接続が確立されるとすぐに、基板上の複数のバランス抵抗（R_balance）が過熱して焼損し始めました。 このシナリオに基づき、以下の質問に関して貴社の技術的な見識をお聞かせいただければ幸いです。 Q1: 最初の出来事でJ1_1とJ1_3のコネクタが交換され、MC33774A ICや関連回路に壊滅的な内部損傷を引き起こしましたか? Q2: 2回目の(正しい)接続中に複数のバランス抵抗が焼き切れたのは、最初の事故によるMC33774A IC内部の損傷(例:内部FETブレークダウンやゲートドライバーのオン状態の停止)が直接原因と考えてよいのでしょうか? Q3: 損傷したMC33774A ICと焼失したすべてのバランス抵抗を交換すれば、RDBESS774A3EVB基板は完全に機能し安全な状態に戻せるのでしょうか?他に重要な補助部品(ESD/ゼナー保護ダイオードやアイソレータ回路素子など)は、メインICと併用して点検または交換すべきものはありますか? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) こんにちは@guoweisunさん 50個のセルすべてを1つのコネクタに接続したわけではありません。その代わりに、当社の50セルシステムは、3つの異なるセルコネクタを備えた3つの独立したセグメントに分割されています。 1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION 初期イベントエラー:コネクタ 交換 2 その後の動作:通常接続 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 50*3.6V を追加したのが間違いだったということですか？MC33774の最初の部分で、C17とグランド間の電圧は？ Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) こんにちは@guoweisunさん ハードウェアの完全なセーフティを確保し、配線トラブルを防ぐために、50SバッテリーパックをRDBESS774A3EVBに配線する中間の 「CSUブリッジボード」 を設計しました(3つのMC33774A AFEをデイジーチェーンに配置しています)。 添付の回路図(CSUBridge_Connector.png と CSUBridge_Block Diagram.png)を確認して、ピンのマッピングや接続戦略が正しいか確認していただけますか?   Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) これ以上問題は見つからないようですが、GDN1、GND2、GND3のポジショニングに注目してください。 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 皆様の継続的なサポートに感謝いたします。まず、実際のハードウェア構成におけるAFEのスタッキング順序を明確にし、認識のずれがないようにしたいと思います。 AFE1（J1_1）は高電圧ステージ（セル37～50）用に指定されています。 AFE3（J1_3）は低電圧ステージ（セル1～18）用に指定されています。 添付の画像は、我々の最近の調査結果と、現在直面している重大な問題点をまとめたものです。 最初の事件に関する以前の質問や、新しいボードに関する新たな問題について、具体的な回答をいただけるとありがたいです。 【パート1：最初のボードに関する回顧的な質問】 Q1: 最初のJ1_1とJ1_3のコネクタ交換が、その最初のイベント情報でMC33774A ICや関連回路に壊滅的な内部損傷を引き起こしましたか? Q2: 2回目の(修正済み)接続時に複数のバランシング抵抗が焼き切れたのは、最初の事故によるMC33774A IC内部の損傷(例:内部FETブレークダウンやゲートドライバーがON状態で固着した)が直接原因と考えてよいのでしょうか? Q3: 損傷したMC33774A ICと焼失したすべてのバランス抵抗を交換すれば、RDBESS774A3EVB基板は完全に機能し安全な状態に戻せるのでしょうか?他に重要な補助部品(ESD/ゼナー保護ダイオードやアイソレータ回路素子など)は、メインICと併用して点検または交換すべきものはありますか? 【パート2:新しいボード】 上記で述べた正しいスタッキング順序（高電圧をAFE1/J1_1、低電圧をAFE3/J1_3）に従って、全く新しいRDBESS774A3EVBボードを使用してシステムをテストしました。 しかし、コネクテッド直後に 煙が発生し、高電圧セグメント(セル37–50 / AFE1)のバランスIC(MC33774A)が再び損傷しました。 接続が意図通りにマッピングされていた(HighからHigh、LowからLow)なのに、なぜ新しいボードがAFE1段階で即座に故障したのか、分析を手伝っていただけますか?

RT1064 400kHzでのI2C通信異常 RT1064デバイスのI2C2インターフェースはモジュールAに接続されます。通信異常は400kHzで発生しますが、100kHzでは正常に動作します 1. 同じシリーズ内の異なるモデルのモジュールBを400kHzで接続することは問題ありません 2. 波形の観点からは、ホストクロックが伸縮され、モジュールAに接続された後に復元される異常に相当します 追伸:デバイスのI2Cドライバーポートを別の1064デバイスに実装し、モジュールAをテストしましたが、400kで問題ありません その理由は何でしょうか? 1. 図1 モジュールA ロジックアナライザの400kHzにおける異常波形 2. 図2：モジュールAの100kHzにおけるロジックアナライザの波形 3. 図3：モジュールBの400kHzにおける波形 i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 追加のご説明ありがとうございます。これは非常に重要な指摘です。   あなたの観察からすると、問題はモジュールA自体の異常というよりも、2段ADUM1251アイソレーションリンクによる400 kHz I2Cのタイミングマージン不足に関連している可能性が高いようです。 ライズ時間が規格内であっても、RT1064ではLPI2Cマスター側の400kHz構成、特にMCFGR2[FILTSCL/FILTSDA]およびMCCR0/MCCR1の確認を推奨します。なぜなら、RT1064のマスター同期レイテンシはライズ時間だけでなく、デジタルフィルターやタイミングパラメータ設定にも影響を受けるからです。 プロジェクトで実際に使用されている構成を読み、RT1064リファレンスマニュアル第47章の表47-5「LPI2C例タイミング構成」と比較することをお勧めします。 特に、選択したクロック条件における以下の設定が、サンプル値と一致しているかどうかを確認してください。 I2Cモジュールクロックソース 目標ボーレート：400Kbps PRESCALE FILTSCL / FILTSDA セソルド クロックロ CLKHI データビデオ お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 追加情報として、昨日ポジショニングにいくつかの進展がありました: ハードウェア拡張は以下の通りです: マザーボード:RT1064--- ADUM1251 3.3V～5V サブボード：ADUM1251 - モジュールA 5V～3.3V 検証の結果、ハードウェアリンクの2層にADUM1251を追加した後、モジュールAで通信異常が発生したことが判明した。しかし、ADUM1251を取り外すと、400kで通信が正常に戻った。その理由は何でしょうか? 追伸:ハードウェアエンジニアは、ADUM1251は通信レイテンシを増加させるだけで、それ以外には影響がないと考えています Re: RT1064 I2C communication abnormality at 400kHz こんにちは、@mayliu1 当社の製品はまもなくリリースされ、数日間この問題を調査してきました。できるだけ早くご返信いただければ、大変ありがたいです! Re: RT1064 I2C communication abnormality at 400kHz ハイ 補足情報 1.2人のハードウェアエンジニアはオシロスコープで問題の波形を確認し、上昇時間は100+ns以内の要件を満たしました 2. I2Cの初期化および読み書き機能ドライバを別のタイプのRT1064デバイスに移植し、モジュールAを問題なくテストしました 以下の図は、別のデバイスモジュールAの波形を示しています。テスト用ロジックアナライザー 疑い： 1.ストレッチ後に時計が異常に回復するなら、他にどんな理由が考えられますか 2. 前回の返信で言及されたMCFGR2のような設定設定専用機能はありますか?I2C初期化プロセスで設定するインターフェースは見当たりませんでした ----上昇時間が満たされた場合、これらのレジスタ設定を考慮する必要はないのでしょうか? Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 これはモジュールAの問題ではなく、その特定のRT1064 LPI2C2バスの400 kHzのタイミングマージンの問題だと思います。 RT1064では、LPI2Cのタイミングはバスの上昇時間、バス負荷、プルアップ抵抗、グリッチフィルタ レイテンシの影響を受けます。 リファレンス・マニュアルRT1064RMでは、上昇時間が長いと同期レイテンシが増加すると説明されています。（第47.3.1.4章を参照）タイミングパラメータ） マスターグリッチフィルターMCFGR2[FILTSCL/FILTSDA]は、**レイテンシ**がSCLの最低ロー/ハイ期間を下回るように設定されなければならず、RT1064はMCCR0/MCCR1の400 kbpsタイミング設定の例を提供しています。表47-5をご確認ください。LPI2Cのタイミング構成例 したがって、モジュールAがバスエッジをわずかに遅くしたり、実効負荷を変えたりすると、バスは400kHzで故障しても100kHzでは動作し続けることがあります。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 10 MHzのLPI2C機能クロックは、RT1064リファレンスマニュアルの400 kbpsのタイミング設定例には記載されていません。 このクロックを使用すれば400kbpsのボーレートを生成することは可能ですが、自動生成されるタイミングパラメータは、特にtLOW、tHIGH、セットアップ/ホールドタイミング、およびデータ有効タイミングに関して、I2C仕様と照らし合わせて慎重に検証する必要があります。 デザインリスクを減らすために、リファレンス・マニュアルに示されている48 MHzなどの検証済みクロックソースを使用することが推奨されています。 Re: RT1064 I2C communication abnormality at 400kHz 以下は印刷設定です。どのパラメータを調整する必要があるでしょうか？ 追伸:どうやら自動インターフェース割り当てによるようです Re: RT1064 I2C communication abnormality at 400kHz 60MHzと8MHzの両方を変更してみましたが、それでもうまくいきませんでした。下図の赤い枠で囲まれた部分は、修正後に印刷された値を示しており、マニュアルに記載されている値とは異なっています。 Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 I2Cクロックを設定する方法はいくつかあります。 提案として、8 MHzと60 MHzを試してみるのも良いでしょう。この2つのクロック設定は比較的簡単に達成できます。 SDKのデモを使っています: 「evkmimxrt1064_lpi2c_edma_b2b_transfer_master」 方法1：LPI2Cクロックソースを60MHzに設定する 時計の分周器を0に設定するだけです。 方法2：LPI2Cクロックソースを8MHzに設定する MCUXpresso IDEsクロックツールを使い、以下の通りに設定してください。クロックソースとしてOSC_CLKを選択し、分周器を3に設定すると、LPI2C（I2C）モジュール用の8MHzクロックが生成されます。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 現在のI2Cクロックは、SDK2_13_0-EVK-MIMXRT1064 \ ボード \ evkmimxrt1064 \ river_deamples \ lpi2cディレクトリ内のサンプル構成に基づいて構成されています。 #define LPI2C_CLOCK_SELECT(0U) #define LPI2C_CLOCK_DIVIDER(5U) CLOCK_SetMux(kCLOCK_Lpi2cMux、LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv、LPI2C_CLOCK_DIVIDER); ---正確な8MHzか48MHzをどうやって修正すればいいですか?（時計の木が見えないようですね） Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 レジスタを直接設定してみるのも良いでしょう。 例えば、60 MHzのI2Cクロックを使用する場合、以下の構成を適用できます。 お役に立てれば幸いです。 よろしくお願いいたします。 5月

关于 RDBESS774A3EVB 的咨询 - 由于连接器（J1_1 和 J1_3）互换导致的板损坏 您好， 我目前正在评估RDBESS774A3EVB电池监控单元 (CMU) 板（采用 MC33774A 电池单元控制器），该板连接到 50 节电池组设置。 最近，我们在测试过程中发生了一起意外的连接错误。我们错误地将J1_1 （上部）和J1_3 （下部）之间的电池连接器组互换了。 事件发生期间观察到以下行为： 初始事件：连接器互换后，第 36 单元立即发生严重短路，导致外部电线/线路烧毁断裂。 后续措施：发现错误后，我们使用正确的连接器位置将电池组重新连接到同一块电路板上。 次要行为：一旦建立了正确的连接，板上的多个平衡电阻器（R_balance）就开始过热并烧毁。 基于以上情况，我们非常希望您能就以下问题提供工程方面的见解： Q1：在第一次事件中，J1_1 和 J1_3 之间的初始连接器互换是否对 MC33774A IC 或相关电路造成了灾难性的内部损坏？ Q2：假设在第二次（正确的）连接期间多个平衡电阻烧毁是由于第一次事故造成的 MC33774A IC 内部损坏（例如，内部 FET 击穿或栅极驱动器卡在导通状态）的直接结果，这种假设是否正确？ Q3：如果我们更换损坏的MC33774A IC和所有烧毁的平衡电阻，RDBESS774A3EVB板能否恢复到完全功能和安全的工作状态？除了主集成电路之外，是否还有其他重要的配套组件（例如静电放电/齐纳保护二极管或隔离电路元件）需要检查或更换？ Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 嗨@guoweisun ， 我们没有将整个 50 节电池组连接到一个连接器上。相反，我们的 50 单元系统分为三个独立的部分，并配有三个不同的单元连接器。 1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 初始事件错误：连接器交换 2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 后续操作：正常连接 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 你是说你把50*3.6V加错了吗？MC33774 第一部分中 C17 到地之间的电压是多少？ Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 嗨@guoweisun ， 为了确保硬件的功能安全并防止任何潜在的接线问题，我们设计了一个中间“CSU 桥接板” ，将我们的 50S 电池组连接到 RDBESS774A3EVB（采用菊花链连接三个 MC33774A AFE）。 请您查看我们附上的原理图（ CSUBridge_Connector.png和CSUBridge_Block Diagram.png ），并确认我们的引脚映射和连接方式是否正确？   Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 似乎没有发现其他问题，但请注意 GDN1 GND2 GND3 的位置。 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 感谢您一直以来的支持。首先，我们想澄清一下我们实际硬件配置中的 AFE 堆叠顺序，以确保我们保持一致： AFE1 (J1_1)指定用于高压级（单元 37–50）。 AFE3 (J1_3)指定用于低电压级（单元 1–18）。 我们附上了一张图片，其中记录了我们最近的发现以及我们目前面临的关键问题。 我们希望您能就之前提出的关于第一次事件的问题，以及新董事会提出的新问题，给出明确的答复： 【第一部分：对第一次板的回顾性问题】 Q1：在第一次事件中，J1_1 和 J1_3 之间的初始连接器互换是否对 MC33774A IC 或相关电路造成了灾难性的内部损坏？ Q2：假设在第二次（更正后的）连接过程中多个平衡电阻烧毁是由于第一次事故造成的 MC33774A IC 内部损坏（例如，内部 FET 击穿或栅极驱动器卡在导通状态）的直接结果，这种假设是否正确？ Q3：如果我们更换损坏的MC33774A IC和所有烧毁的平衡电阻，RDBESS774A3EVB板能否恢复到完全功能和安全的工作状态？除了主集成电路之外，是否还有其他重要的配套组件（例如静电放电/齐纳保护二极管或隔离电路元件）需要检查或更换？ 【第二部分：新董事会带来的新问题】 按照上述正确的堆叠顺序（高压端接 AFE1/J1_1，低压端接 AFE3/J1_3），我们尝试使用全新的 RDBESS774A3EVB 板来测试我们的系统。 然而，一接上电源，就立即冒烟，高压段（37-50 节电池/AFE1）上的平衡 IC（MC33774A）再次损坏。 鉴于连接映射完全按照预期进行（高对高，低对低），请问您能否帮助我们分析一下为什么新板在 AFE1 阶段立即失效？

RT1064 I2C communication abnormality at 400kHz The I2C2 interface of the RT1064 device connects to Module A. Communication anomalies occur at 400kHz, but it functions properly at 100kHz 1. Connecting module B of a different model within the same series at 400kHz is no problem 2. In terms of waveform, it is equivalent to an anomaly occurring when the host clock is stretched and then restored after connecting to Module A PS: Implement the I2C driver port of the device to another 1064 device, test module A, no issues at 400k What might be the reason？ 1. Figure 1 Module A Abnormal Waveform of Logic Analyzer at 400kHz 2. Figure 2: Waveform of Logic Analyzer for Module A at 100kHz 3. Figure 3: Waveform of Module B at 400kHz i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , Thanks for the additional clarification — this is a very important observation.   From your observations, the issue appears more likely to be related to insufficient 400 kHz I2C timing margin caused by the two-stage ADUM1251 isolation link, rather than an abnormality of Module A itself. Even if the rise time is within spec, on RT1064, we still recommend checking the LPI2C master-side 400 kHz configuration, especially MCFGR2[FILTSCL/FILTSDA] and MCCR0/MCCR1 , because the master synchronization latency on RT1064 is affected not only by rise time, but also by the digital filter and timing parameter settings. We suggest reading out the actual configuration used in your project and comparing it with Table 47-5, “LPI2C Example Timing Configurations,” in Chapter 47 of the RT1064 Reference Manual . In particular, please check whether the following settings match to the example values for your selected clock condition: I2C module clock source Target baud rate: 400Kbps PRESCALE FILTSCL / FILTSDA SETHOLD CLKLO CLKHI DATAVD Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Additional information, there was some progress in positioning yesterday: Our hardware expansion is: Motherboard: RT1064--- ADUM1251    3.3 V to 5 V Subboard: ADUM1251- Module A          5v to 3.3v After verification, it was found that after adding ADUM1251 to the two layers of the hardware link, module A had abnormal communication. However, after removing it, communication returned to normal at 400k. What could be the reason for this？ PS: Our hardware engineers believe that ADUM1251 only increases communication latency and has no other impact Re: RT1064 I2C communication abnormality at 400kHz Hi,@mayliu1 Our product is about to be released, and we have been investigating this issue for several days. If we could receive your response as soon as possible, we would greatly appreciate it！ Re: RT1064 I2C communication abnormality at 400kHz Hi  Supplementary information 1. Our two hardware engineers checked the waveform of the problem through an oscilloscope, and the rise time met the requirements, within 100+ns 2. I ported I2C initialization and read-write function drivers to another type of RT1064 device,  and tested module A without any issues The following figure shows the waveform of another device module A testing logic analyzer doubt: 1. If the clock recovers abnormally after stretching, what other reasons could be causing it 2. Is there a dedicated function to set settings such as MCFGR2 mentioned in the last reply? I didn't see any interface to be set in the I2C initialization process ----If the rise time is met, do we not need to consider these register settings？ Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 ， Thank you so much for your interest in our products and for using our community. I think that this is most likely not a Module A issue, but a 400 kHz timing-margin issue on that specific RT1064 LPI2C2 bus. On RT1064, LPI2C timing is affected by bus rise time, bus loading, pull-up resistors, and glitch-filter latency.  RT1064RM  reference manual describe  that larger rise time increases synchronization latency.  (refer to chapter 47.3.1.4 Timing Parameters) The master glitch filters MCFGR2[FILTSCL/FILTSDA] must be set so their latency stays below the minimum SCL low/high period, and RT1064 provides example 400 kbps timing settings in MCCR0/MCCR1 .  Please check the Table 47-5. LPI2C Example Timing Configurations So if Module A makes the bus edges slightly slower or changes the effective loading, the bus may fail at 400 kHz but still work at 100 kHz .  Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Below is the configuration for printing. Which parameter may need to be adjusted? PS:apparently due to automatic interface allocation Re: RT1064 I2C communication abnormality at 400kHz A 10 MHz LPI2C functional clock is not listed in the RT1064 Reference Manual example timing configurations for 400 kbps. Although it is possible to generate a 400 kbps baud rate with this clock, the automatically generated timing parameters should be carefully verified against the I2C specification, particularly with respect to tLOW, tHIGH, setup/hold timing, and data valid timing. To reduce design risk, it is recommended to use a validated clock source, such as 48 MHz, as shown in the Reference Manual. Re: RT1064 I2C communication abnormality at 400kHz I tried modifying 60MHz and 8MHz, but it still didn't work. The red box in the figure below shows the values printed after modification, which are different from the manual Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , There are several ways to configure the I2C clock. As a suggestion, you can try 8 MHz and 60 MHz, as these two clock settings are relatively easy to achieve. I am using the SDK demo: "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" Way 1: Configure LPI2C clock source to 60 MHz Simply set the clock divider to 0. Way 2: Configure LPI2C clock source to 8 MHz Use the MCUXpresso IDE Clock Tool and configure it as shown below. Select OSC_CLK as the clock source and set the divider to 3, which will generate an 8 MHz clock for the LPI2C (I2C) module. Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , You may try setting the registers directly. For example, when using a 60 MHz I2C clock, the following configuration can be applied. Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz The current I2C clock is configured based on the sample configuration in the SDK2_13_0-EVK-MIMXRT1064 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c directory, #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); ---How can I modify it to obtain the precise 8MHz or 48MHz? (The clock tree doesn't seem to be visible)

ADC Configuration Issue Hi @Senlent , I have also same issue which you mentioned above. Our external oscillator clock is 25 MHz. According to the S32K322 datasheet, the ADC supports up to 80 MHz, so I have configured a prescaler of 2. I also configured the sampling time to 1.2 microseconds and set the BCTU mode to trigger mode. However, we are still getting noisy data when executing the BCTU method and the normal chain method simultaneously on the same ADC0 peripheral. Is there a workaround or an alternative method to safely run both on the same ADC0 peripheral? S32 SDK for S32K1 Re: ADC Configuration Issue Hello @praveen_ext , Considering the previous Community thread, the behavior in BCTU Control Mode is expected: when the ADC is controlled by BCTU in Control Mode, normal conversions cannot be started independently on the same ADC instance. This explains why the current sensing becomes more stable in Control Mode, but the voltage and temperature channels configured in the normal chain stop working. In Trigger Mode, the situation is different. This mode allows BCTU-triggered conversions as well as normal/injected conversions, but all these conversions still share the same ADC instance and therefore the same ADC conversion resources. For a time-critical current sensing use case, especially if synchronized with PWM, the important point is not only whether the conversion is possible, but also whether the sampling instant remains deterministic. From the shared data, the current-sense signal seems mostly stable, but it shows occasional large spikes/dropouts. These do not look like ordinary random analog noise only. They look more like event-related outliers, possibly caused by conversion scheduling, result handling or interaction between the BCTU-triggered conversions and the normal chain conversions on the same ADC peripheral. Therefore, I would suggest first isolating whether the issue is caused by the mixed use of the ADC instance: 1. Please run only the BCTU-triggered current sensing in Trigger Mode and completely disable the normal chain execution.    - Do the current-sense spikes still occur? 2. Please run only the normal chain conversions and disable the BCTU-triggered current sensing.    - Are the voltage and temperature channels still stable? 3. Please check whether the current-sense spikes correlate with the moment when the normal chain conversion is started by the application.  Could you also clarify how the normal chain conversion is started while the BCTU-triggered current sensing is running? For example, is the normal chain started periodically by software, from an interrupt or from another scheduler task? One more point to confirm: from your channel list, ADC1-P2 and ADC1-P3 seem to be mentioned both as BCTU current-sensing channels and as normal-chain channels. Could you please confirm whether these channels are intentionally used by both acquisition methods or if this is only a description/configuration mismatch?  If the spikes disappear when the normal chain is disabled, then the likely issue is not the ADC electrical configuration itself, but the timing/scheduling of two acquisition flows on the same ADC instance. In that case, possible workarounds would be: - keep the current-sensing channels exclusively under BCTU control, - move the slower voltage/temperature measurements to another ADC instance, if available, - or schedule the normal chain conversions only in a time window where they cannot interfere with the BCTU/PWM-synchronized current measurement.   After this isolation test, it is still recommended to check the analog front-end, especially for the continuously noisy signals: - source impedance of the measured signal, - external RC filter values, - ADC input capacitor value, - capacitor placement close to the MCU ADC input pin, - whether the configured sampling time is sufficient for the given source impedance and external components.   Similar ADC accuracy/noise-related discussions are available here: - Issue with Inaccurate ADC Values on S32K3:   https://community.nxp.com/t5/S32K/Issue-with-Inaccurate-ADC-Values-on-S32K3/m-p/2033042   - Smoke detector interfacing with FS32K146HAT0MLLT:   https://community.nxp.com/t5/S32K/Smoke-detector-interfacing-with-FS32K146HAT0MLLT/m-p/1773787   - S32K3 Confusion about ADC accuracy and results:   https://community.nxp.com/t5/S32K/S32K3-Confusion-about-ADC-accuracy-and-results/m-p/2006783   Best regards, Pavel

Issue with the FS32K144UAVLL crystal oscillator! Manager: We are using the FS32K144UAVLL with a 20 MHz crystal oscillator, a 10 pF matching capacitor, and a 1 MΩ load resistor. The crystal oscillator outputs a single-ended 20 MHz sine wave to ground with a 0.5 Vp-p amplitude. The MCU cannot run the program when using the external crystal oscillator, but it works fine when using the internal crystal oscillator. Using the development board software, the FS32K144HFVL development board, with an 8 MHz crystal oscillator, a 22 pF coupling capacitor, and a 1 MΩ load resistor; the crystal oscillator outputs a single-ended 8 MHz sine wave with a peak-to-peak voltage of 1 V. May I ask: 1. What is the difference between the FS32K144UAVLL and the FS32K144HFVL? Can the same program be used for both? Do they require the same external crystal oscillator? 2. What is the acceptable amplitude for the external crystal oscillator of the FS32K144UAVLL? 3. How do I adjust the amplitude of an external crystal oscillator? Thank you! 回复： FS32K144UAVLL晶振问题！ Hi @YF666666  In Section 4 of the S32K1xx Data Sheet, it is noted that a core frequency of 112 MHz is not supported for the M temperature range (–40°C to 125°C). I recommend referring to the S32K1xx_Orderable_Part_Number_List.xlsx, which is attached to the data sheet, to verify the available part numbers and identify the options that meet your requirements. Re: FS32K144UAVLL晶振问题！ Hi @YF666666  1. Device Differences FS32K144UAVLL U: Core frequency up to 112 MHz A: Includes CAN FD, FlexIO, and Security features FS32K144HFVLL H: Core frequency up to 80 MHz F: Includes CAN FD and FlexIO (no security features) 2. The S32K1xx family supports external crystals or resonators in the range of 4 MHz to 40 MHz. 3. You may find the following documents helpful for crystal oscillator design and amplitude considerations: AN14518: Crystal Oscillator Design Guide AN5426: Hardware Design Guidelines for S32K1xx These references provide detailed guidance on oscillator configuration, load capacitors, and design best practices. BR, VaneB 回复： FS32K144UAVLL晶振问题！ Manager: Does the FS32K144UAT0VLLT have a clock speed of 112 MHz and an operating temperature range of -40°C to +105°C? We use it in automobiles, which require an automotive-grade temperature range of -40° to +125°, The chip model has been changed to FS32K144UAT0MLLT, with a clock speed of 112 MHz and an LQFP100 package. Is this the correct model? If the model number is incorrect, please send us the correct one. Thank you! Re: FS32K144UAVLL晶振问题！ You may try FS32K144UAVLL with an 8 MHz crystal oscillator, a 22 pF coupling capacitor, and a 1 MΩ load resistor

MIMXRT1052CVJ5B power supply problem As indicated by the MIMXRT1050HDUG, there are two versions of the MCU. How do I determine my specific version to guide my power supply design? i.MXRT 105x Re: MIMXRT1052CVJ5B供电问题 Thanks! Re: MIMXRT1052CVJ5B供电问题 Hi @Simon_CHan , Thank you for your interest in NXP's RT series products and for using the NXP community. You can refer to ERR011093 in Chip Errata for the i.MX RT1050. The Errata documentation states that this issue has been fixed in A1 silicon. Therefore, the simplest method is to check the chip silkscreen for Silicon Rev: A indicates A0, and B indicates A1. If it's version B, the issue has been fixed; if it's version A, you need to control DCDC_IN/DCDC_IN_Q within the 2.8 V–3.0 V range as required by Errata. I hope the above is helpful to you. Best Regards May

オーバーレイファイルがfrdm_mcxw72ボードで動作しません adc_dtコードサンプルをボードfrdm_mcxw72で実行しようとしましたが、デバイスツリーフォルダのオーバーレイファイルを追加し、Cmakelistファイルでボード名を変更しても、うまくビルドできませんでした。必ず エラーが表示されます:#error「適切なデバイスツリーオーバーレイ指定されていません」 と表示される。原因を見つける手助けをしてもらえますか?よろしくお願いします! Re: Overlay file can't worked in frdm_mcxw72 board こんにちは、RomanVRさん。 オーバーレイファイルをその位置に入れました。それでもうまくいきません。私の作業台については、以下のスナップショットで詳しくご覧いただけます。私はZephyr版のV4.4.0を使っていました。何か分かったことがあれば教えてください。 よろしくお願いいたします！ Re: Overlay file can't worked in frdm_mcxw72 board こんにちは、 @anliu114036 さん。お元気でお過ごしでしょうか。 どのZephyrバージョンに取り組んでいるのか教えていただけますか?また、例を作るためにMCUXpresso for VS Code拡張機能を使っているのかも教えてください。 その間、プロセスを容易にするために、プロジェクト ファイル内にある「boards」フォルダ内にオーバーレイが作成されていることを確認してください。オーバーレイ ファイルの名前が「frdm_mcxw72.overlay」であることを確認してください。この2つのステップを踏むと、ZephyrはCMakeで明示的にパスを設定することなく、ビルドプロセスでオーバーレイを取得します。 もし私たちのMCUXpresso for VS Code拡張機能を使用している場合、プロジェクトの表示は以下の画像のように見えるはずです。 これが役に立つかどうか教えてください。 Re: Overlay file can't worked in frdm_mcxw72 board こんにちは、 @anliu114036 さん。 最初の投稿で「CMakelistファイル内のボード名を変更した」と述べられていましたが、「ボード名を変更する」ために具体的にどのような操作を行ったのか、詳しく教えていただけますか？ また、サンプルを作成するためにどのような手順を踏んだのか教えていただけますか？ Re: Overlay file can't worked in frdm_mcxw72 board こんにちは、RomanVRさん 以下のスナップショットは、元のcmakefileを示しています。 ボード名を「 eval_cn0391_ardz」から「 frdm_mcxw72」に変更しました。 以下は私の手順です 1. adc_dtプロジェクトをロードします 2. プロジェクトをビルドしましたが、失敗しました。 3. cmakefile内のボード名を変更して再度ビルドしたが、やはり失敗した。 Re: Overlay file can't worked in frdm_mcxw72 board こんにちは、 @anliu114036 さん。 そのパラメータは外部の第三者機関で使用されており、FRDMのビルドプロセスとは関係がないため、変更しないでください。さらに、ターミナルの出力ログ全体を共有していただけますでしょうか？これにより、オーバーレイがビルドプロセスによって正しく取得されているかどうかを確認できます。 その間、FRDM-MCXW72 用のプロジェクトを再インポートし、インポート後に以下の内容でオーバーレイファイルを作成し、ファイル名を「frdm_mcxw72.overlay」としてプロジェクトをビルドすることをお勧めします。 Re: Overlay file can't worked in frdm_mcxw72 board こんにちは、 @anliu114036 さん。 ビルドログを共有していただきありがとうございます。ビルドシステムがボードのオーバーレイを取得していません。新しくインポートした例では、オーバーレイはデフォルトでは作成されていないため、作成する必要があります。 オーバーレイを作成するには、Visual Studio Code のエクスプローラー タブでプロジェクト フォルダーを開き、/boards フォルダー内にファイルを作成して、前回の回答で添付し忘れた以下の設定を追加することをお勧めします。 #include #include / { zephyr,user { io-channels = <&adc0 0>; }; }; &adc0 { #address-cells = <1>; #size-cells = <0>; status="okay"; channel@0 { reg = <0>; zephyr,gain = "ADC_GAIN_1"; zephyr,reference = "ADC_REF_EXTERNAL1"; zephyr,acquisition-time = ; zephyr,resolution = <12>; zephyr,vref-mv = <1800>; /* channel 2 signal 6A */ zephyr,input-positive = ; }; }; &pinctrl{ pinmux_lpadc0: pinmux_lpadc0 { group0 { pinmux = ; }; }; }; オーバーレイを作成したら、それがボードフォルダに表示され、ビルドシステムによって取得されていることを確認してください。表示は次の画像のようになるはずです。 この手順があなたにとって有効かどうか教えてください。 Re: Overlay file can't worked in frdm_mcxw72 board こんにちは、RomanVRさん。 端末のログファイル全体は添付ファイル内にあります。 FRDM-MCXW72用にプロジェクトを再インポートしましたが、何もしなければプロジェクトフォルダにMCXW72のオーバーレイファイルが見つかりません。 しかし、FRDM-MCXW71のオーバーレイファイルがあります。 よろしくお願いいたします！

ARA240(.dvm)用のカスタムONNX/TFLiteモデルをコンパイルする方法は?(搬送波はi.MX95 FRDMを使用しています) 私はi.MX95 FRDMのARA240 M.2アクセラレータを評価しています。 ランタイムは正常に動作しています。 ARA240はPCIe経由で検出されます。 nnapp は提供された .dvm を正常に実行しますモデル. ランタイムSDKs(rt-sdk-ara240)とPython DVAPIバインディングがインストールされています。 しかし、自分でMobileNetモデルを展開したいのですが、モデルを.dvmにコンパイルするためのツールチェーンが見つかりません形式。 私の質問は以下のとおりです。 カスタムONNX/TFLiteモデルを.dvmにコンパイルする際のサポートワークフローは何ですか?ARA240用ですか？ Ara2コンバータ(またはdvconvert/dvnc)は公開されているのか、それともRuntime SDKsとは別に配布されているのか? NXPがサポートするカスタムCNNモデルを展開する方法はありますか(例:MobileNet) を ARA240 に移植する際に、私が見落としている点はありますか？ どんなガイダンスやドキュメントでも大変ありがたいです。 よろしくお願いします！