Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
IPCF version issue I'm using the following RTD version: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01&04; IPCF version: SW32K3_IPCF_4.2.1_D2504; EB version: 29.0. When importing into Excample... An error occurred in the project: IPCF_AutosarOS_S32K358_M7_0, with the following content: Errors (11061) Plug in with a module Os TS T40D34M413R184" is not instald - cannot create module configurations for project IPCF AutosarOS S32K358 M7 0" 0 (11061) Plug in with a module "pc TS T40D34M4210R0 is not installed cannot create module configurations for project "IPCF AutosarOS $32K358 M7 0" 0 (11061) Plug in with a module Resource TS T40D34M5010Ro is notinstaled -cannet create module configurations for prcject IPCF AutosarOS $32K358 M7 0° @ (11061) Plug in with a module 'BaseNXP TS T40D34M50I0RO is notinstalled - cannot create module configurations for prgject IPCF AutosarOS $32K358 M7 0 @ (11061) Plug-in with a module "Mcu TS T40D34M5010R0 "is not installed - cannot create module configurations for project 'IPCF AutosarOS $32K358 M7 0" How can I solve this problem using the appropriate IPCF or EB version? Re: IPCF版本问题 Hi @liyongfeng  Could you please let me know which plugin versions are currently installed in your EB tresos environment? Also, could you try reinstalling the RTD package and verify whether the issue persists afterward? BR, VaneB
View full article
我的NFC卡出了问题,需要帮助。 我最近在亚马逊上购买了 ACR122U-A9 和 13.56MHz RFID 近距离 ID 卡钥匙扣,可写入可重写 CUID 钥匙扣标签,兼容 MIFARE Classic 1K。我安装了 MWT V.1.6.8424.424.63,它读取了大约 4 个标签后就停止了,要么显示无法读取卡,要么读取到 63 到 64 时就停止了。请问有人能帮忙吗?我对科技真的不太擅长。 NFC读卡器库 Re: I need help with my NFC card 您好,先生, 感谢您使用我们的设备。 关于 ACR122U-A9 的使用,我注意到官方页面上提到,不建议在新设计中使用此读卡器。我的建议是迁移到推荐且受支持的版本。 关于您安装的 MW,能否请您说明一下您是从哪里获得的中间件?因为我在官方页面上找不到它。 我想了解一下您所说的“与 MIFARE Classic 兼容的标签能够像 4 个标签一样工作”是什么意思。MIFARE Classic 卡仅支持 ISO14443-3 命令,请查看数据表以获取正确的命令说明。 如果您能提供更多关于您项目的信息,我或许可以给出更好的建议,因为出于安全原因,我们也不推荐使用MIFARE Classic卡。
View full article
i.MX8M Plus — ECSPI/SPI NOR 上のセカンダリイメージブート (IMG_CNTN_SET1_OFFSET): OP で ROM がフォールバックするか i.MX8M Plus -- ECSPI/SPI NOR 上のセカンダリ イメージ ブート (IMG_CNTN_SET1_OFFSET): OPEN 構成では ROM がフォールバックしますか? ==== セットアップ ==== - SoC:i.MX8M Plus(カスタムSMARCモジュール) - ブートデバイス: ECSPI2 / CS1 上のシリアル NOR (Winbond W25Q128、16 MiB)。これはFlexSPIではなく、レガシーのeCSPIコントローラーです。 - セキュリティ:OPEN構成(デバイスがHABクローズドでない)。 - ヒューズ IMG_CNTN_SET1_OFFSET (ヒューズ読み取り 2 1) = 0x00000000。 - フラッシュマップ: プライマリブートローダーは0x000000、セカンダリコピーは0x400000 (4 MiB) にあります。 文書化されたSPIマッピングによると: 「SPIの場合:ヒューズが10より大きい場合はセカンダリブートが無効になります。n == 0の場合はオフセット = 4 MB、n == 2の場合は1 MB、その他でn <= 10の場合は1 MB * 2^nとなります。」 ヒューズ n = 0 (工場出荷時のデフォルト設定、書き込み不要) の場合、セカンダリオフセットは正確に 0x400000 になります。 ==== 問題点 ==== バイト単位で同一で、cmp.bで検証済みのプライマリイメージのコピーを0x400000に配置し、プライマリブートヘッダーを無効化(sf erase 0 0x1000)してリセットしました。 ROMはセカンダリイメージにフォールバックしないため、ボードは起動不能状態になります(USB SDP経由でのみ復旧可能)。 また、プライマリボディ内部の穴を消去する(sf erase 0x100000 0x40000)ことも試みましたが、結果は同じでした。 ==== 質問 ==== 1. SPI/ECSPI NORで、ROMがIMG_CNTN_SET1_OFFSETの二次映像に切り替わるのは具体的に何をトリガーするのか? これは無効なプライマリブートヘッダーやイメージ解析失敗、それとも特定のHAB認証失敗なのでしょうか? 2. セカンダリイメージブートは、OPEN(非セキュア)構成でも機能しますか、それともデバイスがHABで閉じられている場合にのみ機能しますか? 3. 同じリセットにフォールバックするのか、それとも電源のオンオフ/2回目のリセット(永続ブート方式)が必要なのか? 4. 0x400000 のセカンダリ イメージは、別々に構築されたブート可能なイメージ (そのオフセット用の独自の IVT/ブート データ) である必要があります。 それとも、プライマリとバイト単位で同一のコピーで十分なのでしょうか? ==== ロジックアナライザによる証拠(リセット中にキャプチャされたSPIバス) ==== リセット中に、Saleae Logic Pro 16を使用してECSPI2バス(CLK、MOSI、MISO、CS)を500 MS/sでプローブし、すべてのSPIトランザクションをデコードしました。比較のために、FlexSPI NORから起動し、セカンダリへのフォールバックも正常に行われるi.MX8QMモジュールでも同様のテストを実施しました。 ---- i.MX8M Plus (ECSPI NOR)、プライマリが破損しています ---- ROMは0x03のREADコマンドのみを発行し、オフセット0から厳密に順次読み取ります。 0x03 00 00 FC -> 0x0000FC を読み込む 0x03 00 04 EC -> 0x0004EC を読み込む 0x03 00 08 DC -> 0x0008DC を読み込む ...(64 KiBブロックあたり約50回の読み取り、増加傾向)... 0x03 00 13 xx -> ここで読み取りカウントが減少(0x100000-0x140000 の領域が消去され、MISO=0xFF) 0x03 00 18 xx -> 穴を越えて直線的に続く ...最大で約0x1A69E8まで... ROMはプライマリ領域全体を直線的に読み取り、消去/無効領域をそのまま通過し(0xFFを取得)、0x400000または0x800000(セカンダリ領域)への読み取りは決して行いません。 キャプチャ全体(2500万サンプル、デコードされたトランザクション654件)には、「0x03 40 xx xx」はどこにも存在しません。 完全に消去されたヘッダーの場合、ROMは0xFFをロードし実行し、同期アボートでクラッシュします。フォールバックは一切ありません。 ---- i.MX8QM (FlexSPI NOR) は比較のために使用しています -- セカンダリフォールバックは正常に動作します ---- プライマリコンテナヘッダーのみが無効化された場合(FCBは0x000400にそのまま残された場合)、QM ROMは次の動作をします。 0x0B 00 04 00 -> 高速読み取り FCB @0x000400、MISO: 46 43 46 42 ("FCFB" マジック、FlexSPI 設定有効) ...FCB構成データを読み込む... 0x0B 00 10 00 -> 高速読み取りプライマリコンテナ @0x001000、MISO: FF FF FF FF (無効!) 0x0B 40 10 00 -> 高速読み取りセカンダリコンテナ@0x401000、MISO:有効な<-- ROMスイッチ、同じリセット 0x0B 40 30 00、0x0B 40 40 00、... -> 2次画像全体を読み込みます(0x40xxxxで~90リード) QM ROMはFCBを読み取り、FlexSPIを設定し、0x001000のプライマリコンテナをチェックし、0xFFを認識します。 そして直ちに(同じリセットで)0x401000のセカンダリコンテナに切り替わります。これはうまくいきます。 代わりに最初の4MB(FCBを含む)をすべて消去すると、QM ROMは2回だけの読み込みを行います 0x000400で、0xFFを得て撤退しません。つまり、撤退が作戦するには有効なFCBが必要です。 - - 比較 - - i.MX8M Plus (このボード): コントローラ:eCSPI(レガシーSPI) オペコードを読みます:0x03 READ FCBの現状:いいえ(eCSPIにはFCBの概念はありません) 破損したプライマリでセカンダリーを読み取る:いいえ ― バスは「0x03 40 xx xx」を表示しません。 結果:レンガ(ロード0xFF ->クラッシュ) i.MX8QM(参考文献): コントローラー:FlexSPI オペコードを読んでください:0x0B 速読 FCBの提示:はい(0x400、魔法の「FCFB」) 破損したプライマリで二次を読み取る:はい -- 「0x0B 40 10 00」、同じリセット 結果:セカンダリーブーツ成功 ==== 要約 ==== バスキャプチャから、i.MX8M Plus の IMG_CNTN_SET1_OFFSET セカンダリイメージの起動が確認できる。 FlexSPI専用であるか、HABクローズド構成によって制限されているかのどちらかで、有効になりません。 OPEN構成のeCSPI NORの場合。 NXPの皆さん、確認いただけますか: - i.MX8M Plus上で、eCSPI(FlexSPIとは異なる)NORがセカンダリイメージブートにサポートされているかどうか; - トリガーがHAB-auth-failure(閉じた設定のみ)か、無効なヘッダー(開設定も含む)か; - フォールバックが同じリセットか電源サイクルが必要か; - セカンダリはそのオフセットのために別途構築する必要があるのか、それともバイト同一のコピーで問題ないのか。 よろしくお願いします。
View full article
Imx6ull KSZ8041NL ethernet issue Hello There , To utilize dule ethernet for one of our potential project , We have connected 2 Ethernet phy with Imx6ull processor , One phy is KSZ8081 and one phy is KSZ8041 , below is our DTS configuration : &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; status = "okay"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; status = "okay"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0: ethernet-phy@1 { reg = <1>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET_REF>; clock-names = "rmii-ref"; }; ethphy1: ethernet-phy@3 { reg = <3>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET2_REF>; clock-names = "rmii-ref"; }; }; }; pinctrl_enet1: enet1grp { fsl,pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2: enet2grp { fsl,pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; Both The Ethernet Phys are getting detected in kernel logs and also when we connect ethernet  cable , link is also getting detected on both. but Ip is arriving on ethernet which is connected to KSZ8081 phy , the IP is not getting assigned with the Ethernet which is connected to KSZ8084NL. and there is rx errors are observed in KSZ8041NL Ethernet which is eth0 , below are the logs : root@sls-imx6ull14x14evk:~# ifconfig eth0      Link encap:Ethernet  HWaddr BA:9C:69:1F:76:3A           UP BROADCAST MULTICAST  MTU:1500  Metric:1           RX packets:0 errors:1065 dropped:0 overruns:0 frame:1065           TX packets:65 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:0 (0.0 B)  TX bytes:12024 (11.7 KiB) eth1      Link encap:Ethernet  HWaddr 42:19:11:7F:5E:89           inet addr:10.20.0.184  Bcast:10.20.1.255  Mask:255.255.254.0           inet6 addr: fe80::8248:9837:9647:2a00/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:18 errors:0 dropped:0 overruns:0 frame:0           TX packets:23 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:2494 (2.4 KiB)  TX bytes:3162 (3.0 KiB) lo        Link encap:Local Loopback           inet addr:127.0.0.1  Mask:255.0.0.0           inet6 addr: ::1/128 Scope:Host           UP LOOPBACK RUNNING  MTU:65536  Metric:1           RX packets:17 errors:0 dropped:0 overruns:0 frame:0           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:2011 (1.9 KiB)  TX bytes:2011 (1.9 KiB)   root@sls-imx6ull14x14evk:~# ethtool eth0 Settings for eth0:         Supported ports: [ TP    MII ]         Supported link modes:   10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full         Supported pause frame use: Symmetric         Supports auto-negotiation: Yes         Supported FEC modes: Not reported         Advertised link modes:  10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full         Advertised pause frame use: Symmetric         Advertised auto-negotiation: Yes         Advertised FEC modes: Not reported         Link partner advertised link modes:  10baseT/Half 10baseT/Full                                              100baseT/Half 100baseT/Full         Link partner advertised pause frame use: No         Link partner advertised auto-negotiation: Yes         Link partner advertised FEC modes: Not reported         Speed: 100Mb/s         Duplex: Full         Auto-negotiation: on         Port: Twisted Pair         PHYAD: 3         Transceiver: external         MDI-X: Unknown         Supports Wake-on: g         Wake-on: d         Link detected: yes   We have also checked the clock which is 50MHz , which is generated properly and also coming into phy KSZ8041NL. In short 1 Ethernet with KSZ8081 is working properly but 2nd Ethernet not working with KSZ8041NL. Please suggest us solution. we have also attached screenshot of both Ethernet phy Hardware  for your reference . i.MX6 All i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue Hello NXP Team , Is there any update for us for our asked query ? Re: Imx6ull KSZ8041NL ethernet issue Hello NXP Support Team, We have already shared details about Ethernet issue which we are facing at our end.  So, would you please check it from your end and let us know resolution if anything from your end?  If needed then we will be available over call to discuss issue with your team as well. Waiting for positive feedback from your team end.  Regards, Ritesh Prajapati
View full article
Imx6ull KSZ8041NL 以太网问题 你好呀 , 为了在我们的潜在项目中利用双以太网,我们将两个以太网PHY芯片连接到了Imx6ull处理器上。 其中一块 PHY 芯片是 KSZ8081,另一块 PHY 芯片是 KSZ8041,以下是我们的 DTS 配置: &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; 状态 = "正常"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; 状态 = "正常"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0:以太网物理层@1 { reg = <1>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET_REF>; clock-names = "rmii-ref"; }; ethphy1:以太网物理层@3 { reg = <3>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET2_REF>; clock-names = "rmii-ref"; }; }; }; pinctrl_enet1:enet1grp { fsl,pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2:enet2grp { fsl,pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; 内核日志中检测到了两个以太网物理层,而且当我们连接以太网电缆时,两个设备上也都能检测到链路。 但是,连接到 KSZ8081 phy 的以太网上可以接收到 IP 地址,而连接到 KSZ8084NL 的以太网上却无法分配 IP 地址。 在KSZ8041NL以太网接口(eth0)上观察到接收错误,以下是日志: root@sls-imx6ull14x14evk:~# ifconfig eth0 链路封装:以太网硬件地址 BA:9C:69:1F:76:3A 上行广播组播 MTU:1500 指标:1 接收数据包:0 个错误:1065 个丢弃:0 个溢出:0 个帧:1065 个 发送数据包:65,错误:0,丢弃:0,溢出:0,载波:0 碰撞次数:0 txqueuelen:1000 接收字节数:0 (0.0 B) 发送字节数:12024 (11.7 KiB) eth1 链路封装:以太网 硬件地址 42:19:11:7F:5E:89 inet addr:10.20.0.184广播地址:10.20.1.255掩码:255.255.254.0 inet6 地址:fe80::8248:9837:9647:2a00/64 范围:链路 广播运行中 多播 MTU:1500 指标:1 接收数据包:18 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:23 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 RX 字节:2494 (2.4 KiB) TX 字节:3162 (3.0 KiB) lo Link encap:本地环回 inet addr:127.0.0.1掩码:255.0.0.0 inet6 地址: ::1/128 范围:主机 环路已启动,运行中,MTU:65536,指标:1 接收数据包:17 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:17 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 RX 字节:2011 (1.9 KiB) TX 字节:2011 (1.9 KiB)   root@sls-imx6ull14x14evk:~# ethtool eth0 eth0 的设置: 支持的端口:[ TP MII ] 支持的链路模式:10baseT/半高、10baseT/全高 100baseT/半成品 100baseT/全成品 支持的暂停帧使用方式:对称 支持自动协商:是 支持的FEC模式:未报告 宣传的连接模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 广告中暂停帧的使用:对称 广告中提及的自动协商:是 已公布的FEC模式:未报告 链路伙伴宣传的链路模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 链接伙伴宣传的暂停帧使用情况:否 链接合作伙伴已宣传自动协商:是 链接伙伴宣传的FEC模式:未报告 速度:100Mb/s 复式:全套 自动协商:开启 端口:双绞线 PHYAD:3 收发器:外部 MDI-X:未知 支持唤醒:g 唤醒:d 检测到连接:是   我们还检查了时钟,它是 50MHz 的,生成正常,并且也输入到 KSZ8041NL 物理层。 简而言之,使用 KSZ8081 的 1 个以太网接口工作正常,但使用 KSZ8041NL 的 2 个以太网接口无法工作。 请给我们提供解决方案。我们还附上了以太网PHY硬件的截图供您参考。 i.MX6 全部 i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue 您好,NXP团队, 我们提出的问题有任何更新吗? Re: Imx6ull KSZ8041NL ethernet issue 您好,NXP支持团队, 我们已经分享了我们这边遇到的以太网问题的详细信息。 所以,请您从您那边检查一下,如果有任何进展,请与我们联系。 如有需要,我们也可以通过电话与您的团队讨论问题。 等待贵团队的积极反馈。 此致, 里特什·普拉贾帕蒂
View full article
IMX95EVK-19-REV-A1 フラッシュの問題 NXP様、 Linuxイメージ(6.18.20_2.0.0/ 6.18.2_1.0.0/6.12.49_2.2.0)を IMX95LP5-19 EVK REV A1のeMMC/SDカードにフラッシュしようとしていますが、 どれも 成功しません。 コマンドプロンプトには[HID(W): LIBUSB_ERROR_PIPE (-9) ] SDPS: boot -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all と表示されます。 IMX95LPD5EVK-19CM:L6.18.2のUUU eMMCフラッシュが失敗(LinuxおよびWindowsでのLIBUSBエラー) 上記のリファレンスでは、公式サイトではA1シリコンは現在のイメージをサポートしていません(6.12.34にはパッチが付IMX95EVKいません)。そこで、適切な画像を含む未公開の公式リンクがあるのか気になっています。 ご返信をお待ちしております。よろしくお願いいたします。 BR/デビッド こちらは参考 文献IMX95LPD5EVK-19CMです:L6.18.2のUUU eMMCフラッシュが失敗(LinuxおよびWindowsでLIBUSBエラー発生) Re: IMX95EVK-19-REV-A1 flash problem A1シリコン:推奨BSPはLF 6.6.52_2.2.xです。 デモイメージL6.6.52_2.2.2_MX95をダウンロードしてください。 そして、imx-boot-imx95-a1-19x19-lpddr5-evk-sd.bin-flash_all イメージを使用します。 先ほど以下のコマンドを確認したところ、正常に動作しました。 uuu.exe -b emmc imx-boot-imx95-a1-19x19-lpddr5-evk-sd.bin-flash_all
View full article
エッジAI imx93でEDGE AIアプリを提案する Re: edge ai i.MX 93には、エッジAIの産業用ビジョン/タッチレスHMIアプリケーションが最も適していると提案します。 i.MX 93に適合する理由: i.MX 93は、インダストリアル、オートモーティブ、IoTマーケット全体でML加速と高速エッジ推論を備えた省エネエッジ・コンピューティングを目的としています。 組み込みおよびIoTデバイスにおける機械学習推論の高速化を目的としたArm Ethos-U65 microNPUを統合しています。 NXPのドキュメントには、産業用HMI、産業用ビジョン、産業用オートメーション、タッチレスアクセス制御、マシンビジョンが93の応用分野として具体的に挙げられています i.MX。 このプラットフォームは、コンピュータビジョン、音声認識、物体検出、顔認識、ポーズ検出などのAIユースケースをサポートしています。 実用的なアプリのコンセプト: スマートインダストリアルビジョン+タッチレスオペレーターインターフェース 機能例: 部品の存在、ラベルチェック、欠陥スクリーニングのためのカメラベースの物体検出。 非接触式機械制御のためのジェスチャーまたは姿勢検出。 オプションで音声コマンドインターフェースを備え、ハンズフリー操作が可能です。 i.MX 93でのローカル推論により、クラウド依存度とレイテンシを削減します。 i.MX 93セキュリティアーキテクチャを用いた安全なデバイス識別およびライフサイクルサポートを提供し、i.MX 93資料で言及されたEdgeLock関連機能も含まれます。 i.MX 93のエッジAIアプリケーションとして有望なその他の候補: アプリのアイデア なぜそれが適しているのか スマートドアベル/アクセスコントロール 顔/物体検出と局所推論を用い、スマートドアベルとスマートロックは93 i.MX スマートホームのターゲットに挙げられています。 ドライバー監視システム DMSは i.MX 93のオートモーティブ認定部品に明確にリストされています。 異常検知付きエネルギーメーター エネルギーメーターはインダストリアル/ビル制御用途として記載されています。MLはローカルで使用状況の異常を検出できます。 スマートフィットネス/姿勢検出デモ ポーズ検出やスマートフィットネスの例は、エッジAIのユースケースとして記録されています。 最良のおすすめは、i.MX 93上でインダストリアル ビジョンやタッチレスHMIエッジAIアプリを構築することです。これは文書化された i.MX 93 NPU、インダストリアル ビジョン、HMI、ローカルML推論のユースケースに直接連動するからです。
View full article
MTC40F2046S1RC64BD2 この部品番号: MTC40F2046S1RC64BD2がX線に敏感かどうか確認していただけますか? Re: MTC40F2046S1RC64BD2 それは事実ではありません。X線照射は一般的な検査手順であり、損傷を引き起こすことはありません。安全保証のために、適合証明書(COC)を持つ販売者を見つけることをお勧めします。
View full article
i.MX8M Plus - SPDIF Protocol Implementation Example Hi Team, Could someone pls suggest how to implement and validate SPDIF Protocol in i.MX8M plus? Re: i.MX8M Plus - SPDIF Protocol Implementation Example For the simplest i.MX 8M Plus S/PDIF implementation, use the i.MX Audio Board / MCIMX8M-AUD as the closest NXP reference hardware, not the base i.MX 8M Plus EVK alone. The audio board is documented as supporting i.MX 8M Plus and providing S/PDIF I/O with RCA and TOSLINK connectors, with TOSLINK support up to 192 kHz. Recommended simple approach: Use optical S/PDIF first if possible Easiest hardware path: i.MX8MP SPDIF_OUT → optical TOSLINK transmitter module. For receive: optical TOSLINK receiver module → i.MX8MP SPDIF_IN . This avoids coaxial 75 Ω line-drive, transformer/coupling, and grounding concerns. Use the i.MX 8M Plus S/PDIF pins through IOMUX The i.MX 8M Plus audio subsystem includes SPDIF input and output . The reference manual shows IOMUX options for AUDIOMIX_SPDIF1_OUT and AUDIOMIX_SPDIF1_IN on selectable pads. In Linux, the corresponding IOMUX definitions include MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF_OUT and MX8MP_IOMUXC_SPDIF_RX__AUDIOMIX_SPDIF_IN . If you need coaxial RCA Do not treat the SoC pin like a direct RCA line driver. Add the proper 75 Ω S/PDIF coax output network / coupling per the selected transmitter/interface circuit. Optical is usually the simpler and safer first implementation. Reference material to look at MCIMX8M-AUD / i.MX Audio Board : best NXP reference for S/PDIF I/O with RCA and TOSLINK on the i.MX 8M family. i.MX 8M Plus Reference Manual : pinmux / IOMUX setup for AUDIOMIX_SPDIF1_IN and AUDIOMIX_SPDIF1_OUT . i.MX 8M Plus datasheet : S/PDIF timing parameters are documented, including clock high/low timing. For the simplest design, route AUDIOMIX_SPDIF1_OUT/IN to optical TOSLINK modules and use the MCIMX8M-AUD as the NXP reference point for S/PDIF I/O behavior. Re: i.MX8M Plus - SPDIF Protocol Implementation Example Hi Yipingwang, Could you please guide me with any reference schematics to implement SPDIF in Simplest way. Re: i.MX8M Plus - SPDIF Protocol Implementation Example Use the existing Linux ALSA Audio XCVR / S/PDIF driver on i.MX8M Plus; you normally do not implement the S/PDIF protocol from scratch. The i.MX8M Plus Audio XCVR supports eARC, ARC, and S/PDIF modes, and the Linux S/PDIF support exposes one playback device for Tx and one capture device for Rx through ALSA.  Suggested implementation path: Enable the kernel driver Enable: CONFIG_SND_IMX_SPDIF Menu path: Copy Device Drivers   -> Sound card support     -> Advanced Linux Sound Architecture       -> ALSA for SoC audio support         -> SoC Audio for Freescale i.MX CPUs           -> SoC Audio support for i.MX boards with S/PDIF The documented DT bindings are under Documentation/devicetree/bindings/sound/fsl,spdif.txt and Documentation/devicetree/bindings/sound/imx-audio-spdfif.txt .  Configure the device tree For i.MX8M Plus, use the xcvr audio block and enable the sound card / DAI link. A representative configuration is: sound-xcvr {     compatible = "fsl,imx-audio-card";     model = "imx-audio-xcvr";     pri-dai-link {         link-name = "XCVR PCM";         cpu {             sound-dai = <&xcvr>;         };     }; }; &xcvr {     #sound-dai-cells = <0>;     pinctrl-names = "default";     pinctrl-0 = <&pinctrl_xcvr>;     status = "okay"; }; For Tx pin muxing, one documented example uses MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF1_OUT .  Check board routing / jumpers If using the NXP audio board, set the physical routing for the intended S/PDIF path. For i.MX8M Plus, J1500=1-2 routes the coaxial connector to i.MX8M Plus, and J1500=4-5 routes the optical connector to i.MX8M Plus.  If routing through CPLD / HDMI card, J2511=1-3 is documented as “i.MX 8M Plus to CPLD to HDMI card.”  Use ALSA / IEC958 correctly The S/PDIF Tx driver supports 32, 44.1, and 48 kHz sample rates, with S16_LE and S24_LE formats; for 24-bit output, the file must use 32 bits per channel frame with only the 24 LSBs valid.  If the path expects IEC958 subframes rather than raw PCM, do the PCM-to-IEC958 conversion in user space, for example using an ALSA PCM plugin.  Validation steps: aplay -l arecord -l Use these to identify the S/PDIF playback / capture card and device IDs. The documentation shows the S/PDIF device appearing as an ALSA card such as imxspdif [imx-spdif], device 0: S/PDIF PCM .  Tx validation: aplay -D hw: , audio48k24S.wav The reference validation method uses an external optical S/PDIF receiver, such as an M-Audio Transit USB sound card with WaveLab, then records the stream externally and plays it back to check correctness.  Rx validation: arecord -D hw: , -c 2 -d 20 -r 48000 -f S24_LE record.wav The sample rate passed to arecord must match the incoming S/PDIF stream sample rate.  For Rx, the application flow is to open the S/PDIF Rx PCM device, wait for the internal DPLL to lock to the input bit stream, get the input sample rate, set channel / format / rate parameters, then prepare and trigger capture.  For protocol-level checks, use: iecset -c iecset is the standard utility documented for setting or dumping IEC958 status bits, and the driver also exposes channel-status handling through the ALSA control interface.  For i.MX8M Plus EVK-style validation, NXP also documents loopback-style Linux testing using the imxaudioxcvr card, for example recording from imxaudioxcvr and playing to wm8960audio : arecord -Dsysdefault:CARD=imxaudioxcvr -c2 -r48000 -fS32_LE -twav | \ aplay -Dsysdefault:CARD=wm8960audio In short: enable the i.MX S/PDIF / XCVR ALSA driver, configure the xcvr device tree and board routing, then validate Tx/Rx with aplay , arecord , iecset , and an external optical/coax S/PDIF source or sink.
View full article
i.MX8M Plus - Sony Philips数字接口格式(SPDIF) 协议实现示例 大家好, 请问有人能指导一下如何在 i.MX8M plus 中实现和验证 Sony Philips数字接口格式(SPDIF) 协议吗? Re: i.MX8M Plus - SPDIF Protocol Implementation Example 对于最简单的 i.MX 8M Plus S/PDIF 实现,请使用 i.MX 音频板 / MCIMX8M-AUD 作为最接近的 NXP 参考硬件,而不是仅使用基本的 i.MX 8M Plus EVK。音频板的文档显示其支持 i.MX 8M Plus,并提供带有 RCA 和 TOSLINK 连接器的 S/PDIF I/O,TOSLINK 支持高达 192 kHz。 推荐的简易方法: 如果可以,请优先使用光纤 S/PDIF 接口。 最简单的硬件路径:i.MX8MP SPDIF_OUT → 光纤 TOSLINK 发射器模块。 接收:光纤 TOSLINK 接收器模块 → i.MX8MP SPDIF_IN。 这样就避免了同轴 75 Ω 线路驱动、变压器/耦合和接地问题。 通过 IOMUX 使用 i.MX 8M Plus 的 S/PDIF 引脚 i.MX 8M Plus 音频子系统包括Sony Philips数字接口格式(SPDIF) 输入和输出。 参考手册显示了可选择的焊盘上的 AUDIOMIX_SPDIF1_OUT 和 AUDIOMIX_SPDIF1_IN 的 IOMUX 选项。 在 Linux 中,相应的 IOMUX 定义包括 MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF_OUT 和 MX8MP_IOMUXC_SPDIF_RX__AUDIOMIX_SPDIF_IN 。 如果您需要同轴RCA接口, 不要将 SoC 引脚当作直接 RCA 线路驱动器使用。 根据所选的发射器/接口电路,添加合适的 75 Ω S/PDIF 同轴输出网络/耦合。 光学方式通常是更简单、更安全的首选方案。 可供参考的资料 MCIMX8M-AUD / i.MX 音频板:NXP 为 i.MX 8M 系列提供 S/PDIF I/O 的最佳参考级产品,带有 RCA 和 TOSLINK 接口。 i.MX 8M Plus 参考手册:AUDIOMIX_SPDIF1_IN 和 AUDIOMIX_SPDIF1_OUT 的 pinmux / IOMUX 设置。 i.MX 8M Plus 数据手册:记录了 S/PDIF 时序参数,包括时钟高/低时序。 对于最简单的设计,将 AUDIOMIX_SPDIF1_OUT/IN 连接到光纤 TOSLINK 模块,并使用 MCIMX8M-AUD 作为 NXP S/PDIF I/O 行为的参考点。 Re: i.MX8M Plus - SPDIF Protocol Implementation Example 王一平您好, 请问能否提供一些参考电路图,以便我以最简单的方式实现Sony Philips数字接口格式 (SPDIF) 功能? Re: i.MX8M Plus - SPDIF Protocol Implementation Example 在 i.MX8M Plus 上使用现有的 Linux ALSA Audio XCVR / S/PDIF 驱动程序;通常情况下,您不会从头开始实现 S/PDIF 协议。i.MX8M Plus 音频 XCVR 支持 eARC、ARC 和 S/PDIF 模式,Linux S/PDIF 支持通过 ALSA 公开一个用于 Tx 的播放设备和一个用于 Rx 的捕获设备。 建议的实施路径: 启用内核驱动程序: 配置_SND_IMX_SPDIF 菜单路径: 复制 设备驱动程序 -> 声卡支持 -> 高级 Linux 音频架构 -> ALSA 用于 SoC 音频支持 -> 适用于飞思卡尔 i.MX CPU 的 SoC 音频           -> 为带有 S/PDIF 的 i.MX 板提供 SoC 音频支持。 记录的 DT 绑定位于 Documentation/devicetree/bindings/sound/fsl,Sony Philips数字接口格式(SPDIF).txt 和 Documentation/devicetree/bindings/sound/imx-audio-Sony Philips数字接口格式(SPDIF)if.txt 下。 配置 i.MX8M Plus 的设备树,使用 xcvr 音频模块并启用声卡/DAI 链路。典型的配置如下: sound-xcvr { 兼容 = "fsl,imx-audio-card"; 型号 = "imx-audio-xcvr"; pri-dai-link { 链接名称 = "XCVR PCM"; 中央处理器 { sound-dai = <&xcvr>;         }; }; }; &xcvr { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_xcvr>; 状态 = "正常"; }; 对于 Tx 引脚复用,一个有记录的示例使用 MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF1_OUT。 检查电路板布线/跳线。如果使用 NXP 音频板,请设置预期 S/PDIF 路径的物理布线。对于 i.MX8M Plus,J1500=1-2 将同轴连接器连接到 i.MX8M Plus,J1500=4-5 将光纤连接器连接到 i.MX8M Plus。如果通过 CPLD / HDMI 卡进行路由,则 J2511=1-3 的文档为“i.MX 8M Plus 到 CPLD 到 HDMI 卡”。 正确使用 ALSA / IEC958 S/PDIF 发送驱动程序支持 32、44.1 和 48 kHz 采样率,以及 S16_LE 和 S24_LE 格式;对于 24 位输出,文件必须使用每通道帧 32 位,并且只有 24 个最低有效位有效。如果路径需要的是 IEC958 子帧而不是原始 PCM,则在用户空间中进行 PCM 到 IEC958 的转换,例如使用 ALSA PCM 插件。 验证步骤: aplay -l 记录 -l 使用这些信息来识别 S/PDIF 播放/采集卡和设备 ID。文档显示 S/PDIF 设备显示为 ALSA 卡,例如 imxspdif [imx-spdif],设备 0:S/PDIF PCM。 交易验证: aplay -D hw: , audio48k24S.wav 参考验证方法使用外部光纤 S/PDIF 接收器,例如带有 WaveLab 的 M-Audio Transit USB 声卡,然后外部录制音频流并回放以检查正确性。 处方验证: arecord -D hw: , -c 2 -d 20 -r 48000 -f S24_LE record.wav 传递给 arecord 的采样率必须与输入的 S/PDIF 流采样率相匹配。对于 Rx,应用程序流程是打开 S/PDIF Rx PCM 设备,等待内部 DPLL 锁定到输入比特流,获取输入采样率,设置通道/格式/速率参数,然后准备并触发捕获。 对于协议级检查,请使用: iecset -c iecset 是用于设置或转储 IEC958 状态位的标准实用程序,并且该驱动程序还通过 ALSA 控制接口公开通道状态处理。 对于 i.MX8M Plus EVK 风格的验证,NXP 还记录了使用 imxaudioxcvr 卡进行环回式 Linux 测试的方法,例如从 imxaudioxcvr 录制音频并播放到 wm8960audio: arecord -Dsysdefault:CARD=imxaudioxcvr -c2 -r48000 -fS32_LE -twav | \ aplay -Dsysdefault:CARD=wm8960audio 简而言之:启用 i.MX S/PDIF / XCVR ALSA 驱动程序,配置 xcvr 设备树和板路由,然后使用 aplay、arecord、iecset 和外部光纤/同轴 S/PDIF 源或接收器验证 Tx/Rx。
View full article
Marking details Please advise the meaning of marking 04 01 616 for MPN : PCA9553DP/01,118
View full article
edge ai Suggest the EDGE AI app with imx93 Re: edge ai For i.MX 93, I’d suggest an edge-AI industrial vision / touchless HMI application as the strongest fit. Why it fits i.MX 93: i.MX 93 is intended for energy-efficient edge computing with ML acceleration and fast edge inferencing across industrial, automotive, and IoT markets. It integrates the Arm Ethos-U65 microNPU , which is designed to accelerate ML inference in embedded and IoT devices. NXP documentation specifically lists industrial HMI , industrial vision , industrial automation , touchless access control , and machine vision as i.MX 93 application areas. The platform supports AI use cases such as computer vision , voice recognition , object detection , facial recognition , and pose detection . A practical app concept: Smart Industrial Vision + Touchless Operator Interface Example features: Camera-based object detection for part presence, label checking, or defect screening. Gesture or pose detection for touchless machine control. Optional voice command interface for hands-free operation. Local inference on the i.MX 93, reducing cloud dependency and latency. Secure device identity and lifecycle support using the i.MX 93 security architecture, including EdgeLock-related capabilities referenced in the i.MX 93 materials. Other good i.MX 93 edge-AI app candidates: App idea Why it fits Smart doorbell / access control Uses face/object detection and local inference; smart doorbell and smart lock are listed i.MX 93 smart-home targets.  Driver monitoring system DMS is explicitly listed for i.MX 93 automotive-qualified parts.  Energy meter with anomaly detection Energy meter is listed for industrial/building-control use; ML can detect usage anomalies locally.  Smart fitness / pose-detection demo Pose detection and smart fitness examples are documented edge-AI use cases.  Best recommendation: build an industrial vision or touchless HMI edge-AI app on i.MX 93, because it aligns directly with the documented i.MX 93 NPU, industrial vision, HMI, and local ML inference use cases.
View full article
i.MX8M Plus — ECSPI/SPI NOR 接口上的辅助镜像启动 (IMG_CNTN_SET1_OFFSET):ROM 是否会回退到 OP 模式 i.MX8M Plus -- ECSPI/SPI 或非 上的辅助映像启动 (IMG_CNTN_SET1_OFFSET):ROM 是否会回退到 OPEN 配置? ==== 设置 ==== - SoC:i.MX8M Plus(定制SMARC模块) - 引导设备:ECSPI2 / CS1 上的串行 NOR(Winbond W25Q128,16 MiB)。这是传统的 eCSPI 控制器,不是 FlexSPI。 - 安全性:开放式配置(设备未关闭 HAB)。 - 熔丝 IMG_CNTN_SET1_OFFSET(熔丝读取 2 1)= 0x00000000。 - Flash 映射:主引导加载程序位于 0x000000,辅助副本位于 0x400000(4 MiB)。 根据已记录的SPI映射: “对于 SPI:如果熔丝位大于 10,则禁用辅助启动;n == 0 -> 偏移量 = 4 MB;n == 2 -> 1 MB;其他情况且 n <= 10 -> 1 MB * 2^n。” 当熔丝 n = 0(出厂默认值,无需烧录)时,二级偏移量应正好为 0x400000。 ==== 问题 ==== 我们在 0x400000 处放置了一个字节相同的、经 cmp.b 验证的主映像副本,然后使主启动头失效(sf erase 0 0x1000)并重置。 ROM 无法回退到备用映像——主板已变砖(只能通过 USB SDP 恢复)。 我们还尝试擦除主体内部的一个孔(sf erase 0x100000 0x40000),结果相同。 ==== 问题 ==== 1. 在 SPI/ECSPI NOR 上,是什么触发 ROM 在 IMG_CNTN_SET1_OFFSET 处切换到辅助映像? 是无效的主启动头/镜像解析失败,还是具体的 HAB 认证失败? 2. 辅助映像启动在开放(非安全)配置下是否有效,还是仅在设备 HAB 关闭时有效? 3. 是否恢复到之前的重置状态,还是需要断电重启/第二次重置(持久启动方式)? 4. 位于 0x400000 的辅助映像必须是单独构建的可引导映像(具有该偏移量的独立虚拟镜像/引导数据)吗? 或者,使用与原文件完全相同的字节副本就足够了? ==== 逻辑分析仪证据(RESET 期间捕获的 SPI 总线信号) ==== 我们使用 Saleae Logic Pro 16 以 500 MS/s 的速度探测 ECSPI2 总线(CLK、MOSI、MISO、CS),并在 RESET 期间解码每个 SPI 事务。为了进行比较,我们对从 FlexSPI 或非 启动并成功回退到辅助电源的 i.MX8QM 模块进行了同样的测试。 ---- i.MX8M Plus (ECSPI NOR),主控芯片已损坏 ---- ROM 只发出 0x03 READ 命令,严格从偏移量 0 开始顺序读取: 0x03 00 00 FC -> 读取 0x0000FC 0x03 00 04 EC -> 读取 0x0004EC 0x03 00 08 DC -> 读取 0x0008DC ……(每个 64 KiB 数据块约 50 次读取,呈严格递增趋势)…… 0x03 00 13 xx -> 读取计数在此处下降(擦除空洞 0x100000-0x140000,MISO=0xFF) 0x03 00 18 xx -> 线性地继续经过孔洞 ... 最高可达 ~0x1A69E8 ... ROM 会线性读取整个主区域,直接读取已擦除/无效区域(得到 0xFF),并且永远不会读取 0x400000 或 0x800000(辅助区域)。 在完整的捕获数据(2500 万个样本,654 个解码交易)中,任何地方都没有“0x03 40 xx xx”。 如果头完全擦除,ROM 会加载 0xFF,执行它,然后因同步中止而崩溃——没有任何回退机制。 作为对比,i.MX8QM(FlexSPI NOR)——备用方案确实有效—— 当仅主容器头失效(FCB 保持不变,地址为 0x000400)时,QM ROM 会执行以下操作: 0x0B 00 04 00 -> 快速读取 FCB @0x000400,MISO:46 43 46 42(“FCFB”魔数,FlexSPI 配置有效) 读取FCB配置数据…… 0x0B 00 10 00 -> 快速读取主容器 @0x001000,MISO:FF FF FF FF(无效!) 0x0B 40 10 00 -> 快速读取辅助容器 @0x401000,MISO:有效 <-- ROM 已切换,相同 RESET 0x0B 40 30 00, 0x0B 40 40 00, ... -> 加载整个二级镜像(在 0x40xxxx 处读取约 90 次) QM ROM 读取 FCB,配置 FlexSPI,检查 0x001000 处的主容器,发现为 0xFF, 然后立即(相同 RESET)切换到 0x401000 处的辅助容器。这样可行。 如果我们擦除前 4 MB 的全部数据(包括 FCB),QM ROM 只会进行 2 次读取操作。 在 0x000400 处,得到 0xFF,并且不会回退——因此需要有效的 FCB 才能启用回退。 - - 比较 - - i.MX8M Plus(本主板): 控制器:eCSPI(传统SPI) 读取操作码:0x03 读取 FCB 存在:否(eCSPI 没有 FCB 概念) 读取损坏的主服务器上的辅助服务器:否 -- 总线从未显示“0x03 40 xx xx” 结果:砖块(加载 0xFF -> 崩溃) i.MX8QM(参考): 控制器:FlexSPI 读取操作码:0x0B 快速读取 FCB 存在:是(0x400,魔法值“FCFB”) 读取损坏主盘上的辅助盘:是 -- "0x0B 40 10 00", 相同RESET 结果:辅助设备启动成功 ==== 摘要 ==== 从总线捕获信息来看,IMG_CNTN_SET1_OFFSET 辅助映像在 i.MX8M Plus 上启动。 似乎仅支持 FlexSPI,或者受 HAB 关闭配置的限制,并且无法启用。 适用于 OPEN 配置中的 eCSPI NOR。 NXP能否确认: - i.MX8M Plus 是否支持 eCSPI(而非 FlexSPI)或非 进行二次映像启动; - 触发条件是 HAB-auth-failure(仅限已关闭配置)还是任何无效标头(也包括已打开配置); - 回退方案是采用相同的重置方式还是需要断电重启; - 是否必须为该偏移量单独构建辅助副本,或者字节相同的副本也可以。 谢谢!
View full article
请求开启 SW32K14-MCAL421-RTMC-1.0.1 下载的访问权限 嗨,恩智浦支持团队、 我想申请SW32K14-MCAL421-RTMC-1.0.1 的下载权限。 目前,我的恩智浦软件许可页面中的 “税务摊销收益” 显示为灰色,我无法访问此版本。 我的用户名是Chefanqf。 该版本需要与基于S32K14x MCAL 4.2 的现有项目兼容。 能否请您帮助在我的账户下启用该软件的权限? 非常感谢你们的支持! 顺祝商祺! Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download 嗨,@Chefanqf、 你能试着在 nxp.com(搜索 | 恩智浦半导体)中搜索 " S32K1 MCAL " 然后用以下方式输入 flexera 吗? 然后,选择 Automotive SW - AUTOSAR MCAL / QM,就可以使用以前的软件了。 如果 " Previous " 税务摊销收益仍显示为灰色,你可以尝试通过直接链接进入:SW 32K14-MCAL421-RTMC-1.0.1。如果您要使用直接链接,请确认您已登录 nxp.com。 致以最诚挚的问候, Julián Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download 嗨,恩智浦支持团队、 我希望申请下载权限。 SW32K14-MCAL421-RTMC-1.0.1 。 目前,我的 NXP 软件许可页面中出现了“上一页”选项卡。 灰色 我无法访问此版本。 我的账号用户名是mianlongxu 为了与基于现有项目的兼容性,需要此版本。 S32K14x MCAL 4.2 。 能否请您帮助在我的账户下启用该软件的权限? 非常感谢你们的支持! 顺祝商祺! Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download 你好@mianlongxu , 请提交支持工单: NXP 支持。 此致, 朱利安
View full article
S32K358 多核数据共享 你好 , 我正在尝试在 s32k358 多核处理器中使用共享内存。 我正在学习用户自定义示例, 当我尝试在buzzer_state_shared_data_U32 中赋值时(目前只有核心 0 访问此内存),核心 0 挂起并 swt 重置控制器。 但是当我把代码烧录到调试闪存中时,它运行正常。上电复位后,核心 0 卡住。 为什么刷机时运行正常,而断电重启后却无法运行? Re: S32K358 multi core data sharing 你好@Julián_AragónM , 感谢您的快速回复。 我检查了启动文件,SRAM 初始化正在进行。 我已附上启动文件和链接器文件。请协助我解决这个问题。 Re: S32K358 multi core data sharing 你好@nirmal_masilamani , 但是当我把代码烧录到调试闪存中时,它运行正常。上电复位后,核心 0 卡住。 这很可能是由ECC RAM错误引起的。通常情况下,调试器会在易失性存储器上初始化 ECC,但是,在开机和关机时,调试器不会初始化 RAM,因此在尝试访问内存时会发生硬故障。 这通常是在启动代码中,在 main 函数之前完成的。 该部分还应配置为不可缓存。 关于你的第二个问题:但是当我尝试从定时器中断服务例程或操作系统任务访问它时,核心 0 会发生硬故障。 您可以尝试追溯硬故障。在 HardFault_Handler() 中停止内核,并在内核寄存器中找到 SP 值:如何调试 ARM Cortex-M(V7M) MCU(S32K3XX) 上的故障异常。 此致, 朱利安 Re: S32K358 multi core data sharing 你好, 当我在 main() 中访问共享内存时,即使在断电重启后也能正常工作,但是当我尝试从定时器中断服务例程或操作系统任务中访问它时,核心 0 会发生硬故障。 请支持我。 Re: S32K358 multi core data sharing 你好@Julián_AragónM , 请协助解答此问题。我到底漏掉了什么? Re: S32K358 multi core data sharing 你好@nirmal_masilamani , 在不使用调试器的情况下,能否在 POR RESET 后通过 main() 函数访问共享内存?问题是否出在内存初始化上? 但是当我尝试从定时器中断服务例程或操作系统任务访问它时,核心 0 会发生硬故障。 您是否能够像我上次回复中提到的那样,确定故障类型? 您是否也确保将变量放置在不可缓存的区域中,或者禁用了缓存? 建议如下: 对 core1Status 保持 volatile 状态,并在读取(Core0)和写入(Core1)两侧使用__DMB()/__ DSB() 屏障。 您的问题也可能是由 MPU 配置引起的,如果定义了 MPU_ENABLE,请在任何 ISR 或 OS 任务开始执行之前调用 MPU 配置。 您可以参考以下链接: Arm Cortex-M7 设备通用用户指南 r1p2和AN14715:S32K3XX 硬件资源隔离和保护。 此致, 朱利安 Re: S32K358 multi core data sharing 你好@Julián_AragónM , 谢谢你的回复。 很遗憾,我无法继续进行这项工作,我会仔细核查您提出的观点。
View full article
Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hello NXP Support Team, We are evaluating object detection on the FRDM i.MX95 platform using the Neutron SDK v3.1.3 and are unable to generate an NPU-compatible model. The Neutron converter successfully loads the model, but reports that 0 operators are mapped to the Neutron NPU. Environment Target Board: FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: Tested with both YOLO11 and YOLOv8 eIQ Toolkit: Used for ONNX → TFLite conversion Model: Custom single-class peg detector Training Command $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=models \ name=peg_detector_v8 Export Command $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml We also tested an alternative workflow: Export PyTorch → ONNX Convert ONNX → INT8 TFLite using the NXP eIQ Toolkit Both workflows produced the same result when compiled with the Neutron SDK.   Neutron Compilation ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter \ --target imx95 \ --input best_int8.tflite \ --output my_model_int8_npu.tflite   Converter Output The converter reports: Operators after import: 341 Operators after optimization: 367 Operators converted: 0 Operator conversion ratio: 0 / 367 Number of Neutron graphs: 0 Warnings: WARNING: None of the operators from the graph was mapped to Neutron. WARNING: The converted model is the same as the input model because no operators were mapped to Neutron. WARNING: Graph has FLOAT operators which are NOT supported! This can result in low conversion ratio. Additional Information We observed the same behavior with: YOLO11 YOLOv8 Direct Ultralytics TFLite export ONNX → eIQ Toolkit → INT8 TFLite All generated TFLite models result in 0 operators being mapped by the Neutron compiler. Questions Are YOLOv8 or YOLO11 object detection models officially supported by the Neutron compiler for the i.MX95? Is there a recommended export pipeline for YOLO models targeting the i.MX95 NPU? Are there any known limitations with the current Neutron SDK (v3.1.3) regarding YOLO detection heads? Does NXP provide a reference YOLOv8/YOLO11 model that successfully compiles for the i.MX95 NPU? Is there any additional compiler option or preprocessing step required to enable operator mapping? We would appreciate any guidance, recommended workflows, or reference models that are known to work with the i.MX95 Neutron NPU. Thank you. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Thank you for your response. I would like to inquire if there is a standard procedure available for training, exporting, and deploying models on the IMX95 board. As we currently have the ARA2, we are looking to fully utilize its capabilities and customize our models. We have upcoming demos for NXP Tech Days, and your assistance in this matter would be greatly appreciated. Thank you for your help. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Tried the yolo8m model from eIQ model zoo on imx95 board with LF 2026 Q2 release image. kernel version is 6.18.20 using neutron SDK 3.1.2. it works.     You can try it firstly by: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model --graph=yolov8n-det-int8-smart.imx95.tflite --external_delegate_path=/usr/lib/libneutron_delegate.so more info you can refer the README eiq-model-zoo/tasks/vision/object-detection/yolov8 at main · NXP/eiq-model-zoo What's more, you can attached model and details log of convert/complier. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Based on the converter log, the first issue to resolve is that the generated TFLite model still contains FLOAT operators:   WARNING: Graph has FLOAT operators which are NOT supported! For i.MX95 Neutron, the input to neutron-converter must be a TFLite model whose operators and quantization format are compatible with the Neutron compiler. In particular, the i.MX95 Neutron flow expects quantized TFLite and symmetric int8 weights. If the model still contains FLOAT operators/tensors after the Ultralytics export or ONNX-to-TFLite conversion, the converter may be unable to create any Neutron-compatible subgraph, which is consistent with the reported result:   Operators converted: 0   Number of Neutron graphs: 0 YOLOv8 has been evaluated on i.MX95 in some flows, but full end-to-end YOLOv8/YOLO11 offload should not be assumed for arbitrary Ultralytics exports. Depending on the exported TFLite graph, only part of the model may be converted to NeutronGraph and unsupported operators will remain on CPU. Therefore, the recommended next step is to inspect/profile the generated TFLite model and confirm: the graph is fully quantized, there are no FLOAT operators, weights are symmetric int8, input/output tensor types are compatible, or converted with the Neutron converter uint8-to-int8 options if applicable, YOLO post-processing such as decode/NMS is kept outside the NPU graph unless the exact operators are confirmed supported by the SDK. Please also ensure that the neutron-converter version and the Neutron runtime/firmware/delegate on the board are from the same compatible SDK/BSP release. As a recommended flow, please try the NXP/eIQ conversion path:   PyTorch -> ONNX with static input shape -> NXP/eIQ quantization with representative calibration data -> quantized TFLite -> neutron-converter --target imx95 If the model has uint8 input/output tensors, please also test:   --convert-inputs-uint8-to-int8   --convert-outputs-uint8-to-int8 If the conversion still reports 0 mapped operators after removing FLOAT operators, please share:   - the complete neutron-converter log with verbose/profiling output if available,   - the TFLite operator list,   - tensor data types and quantization parameters,   - the exact BSP/runtime Neutron delegate/firmware versions on the FRDM i.MX95 board,   - whether the YOLO detection head includes NMS or other post-processing inside the TFLite graph. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Hi  i am running ubuntu 24.04, but eiq_toolkit is avaialble for only 20.04.03.  how can i use eiqToolkit and Quantization Using eIQ Toolkit Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Recommended End-to-End Workflow Model Training (PC) Train using your preferred framework: Ultralytics YOLOv8 PyTorch TensorFlow ONNX-native workflows For object detection, NXP already provides YOLO reference recipes in the eIQ Model Zoo, including YOLOv8 object detection models. [github.com], [github.com] Example: Shell yolo detect train \ model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ epochs=100 ` Export to ONNX NXP generally recommends using ONNX as the interchange format before quantization and deployment. yolo export \ model=best.pt \ format=onnx The Neutron enablement presentations explicitly describe a flow based on: Plain Text PyTorch ↓ ONNX ↓ Quantization ↓ TFLite ↓ Neutron Converter rather than directly targeting deployment from training artifacts. Quantization Using eIQ Toolkit The Neutron workflow documentation recommends using the eIQ Toolkit quantization utilities: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: `` followed by: python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite Show more lines This flow is explicitly documented in the i.MX95 Neutron enablement material. Compile for i.MX95 Neutron NPU neutron-converter \ --target imx95 \ --input model_int8.tflite \ --output model_neutron.tflite The Neutron converter creates Neutron-specific graph partitions that can be offloaded to the NPU. Validate Conversion Ratio A successful NPU deployment should report something similar to: Number of operators converted > 0 Number of Neutron graphs > 0 If you see: Operators converted: 0 Number of Neutron graphs: 0 then the model is not being accelerated by the NPU. Your current issue falls into this category. Deploy on FRDM-i.MX95 Run using TensorFlow Lite with the Neutron delegate: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` or ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so The i.MX Machine Learning User Guide identifies the Neutron Delegate as the acceleration mechanism for i.MX95 TensorFlow Lite models. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU In my test I did not train or export the model myself. I used a pre-generated YOLOv8 model from the eIQ Model Zoo and verified that it runs on the i.MX95 platform. The only command I actually used was: ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so `` with the model: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite For custom models, the recommended NXP flow is: PyTorch ↓ ONNX (static input shape) ↓ eIQ Toolkit ONNX2Quant ↓ eIQ Toolkit ONNX2TFLite ↓ Quantized TFLite ↓ neutron-converter --target imx95 Since your model reports: Plain Text Operators converted: 0 Number of Neutron graphs: 0 WARNING: Graph has FLOAT operators which are NOT supported! I suspect your generated TFLite graph is structurally different from the eIQ Model Zoo reference model. The first thing I would recommend is comparing the two models for: Input/output tensor type (INT8 vs UINT8) Presence of FLOAT operators Decode/NMS layers inside the graph Operator list reported by Netron / TFLite analyzer Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Can you please tell me how did you convert yolov8m_full_integer_quant.tflite to be able to run on the imx95 NPU?  Step followed and environment setup data(HOST).. would greatly help us. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Since eIQ Toolkit was validated on Ubuntu 20.04, the safest approach is: Docker Run a Ubuntu 20.04 container on your Ubuntu 24.04 host: docker run -it --name eiq \ ubuntu:20.04 /bin/bash Then install the required dependencies and eIQ Toolkit inside the container. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Unable to preserve confidence output when converting custom YOLOv8 ONNX model using eIQ Toolkit (onnx2quant) Overview Hi NXP Team, I'm trying to deploy a custom YOLOv8 single-class object detection model on the FRDM i.MX95 using the eIQ Toolkit. The complete conversion pipeline runs successfully, but after onnx2quant, the confidence output becomes all zeros while the bounding box outputs remain valid. Environment - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX Runtime 1.21.1 - TensorFlow 2.21 - neutron-converter 3.1.3 - Target: FRDM i.MX95 (tflite_runtime 2.19 + Neutron delegate) Conversion Pipeline 1. Train yolo detect train model=yolov8n.pt data=dataset.yaml imgsz=640 epochs=50 2. Export ONNX yolo export model=best.pt format=onnx opset=13 3. Verify ONNX Input : (1,3,640,640) Output: (1,5,8400) ONNX Runtime inference: Confidence Channel Max = 0.773 4. Generate calibration dataset Shape : (1,3,640,640) dtype : float32 Range : 0.0 - 1.0 5. Quantize onnx2quant best.onnx -c "images;calibration/images" -o best_quant.onnx Also tested: onnx2quant best.onnx -u Both produce the same result. 6. Verify Quantized ONNX Output : (1,5,8400) Bounding box channels remain valid. Confidence: Min = 0 Max = 0 Mean = 0 Decoded detections = 0 7. Convert to TFLite onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron neutron-converter --target imx95 --input best.tflite --output best_neutron.tflite Compilation succeeds. Operator conversion: 278 / 325 (85.5%) Investigation Performed Verified: • PyTorch model works • ONNX export works • ONNX Runtime inference works • Calibration dataset is correct • Real and random calibration produce identical results • TFLite reproduces the Quantized ONNX output • Neutron reproduces the TFLite output The issue first appears after: ONNX ↓ onnx2quant ↓ Quantized ONNX (confidence becomes zero) Additional Observation NXP reference model: Input : (1,640,640,3) INT8 Output: (1,84,8400) INT8 My converted model: Input : (1,3,640,640) FLOAT32 Output: (1,5,8400) FLOAT32 Is there a recommended export or quantization workflow for custom YOLOv8 models that preserves the confidence output? Could this be a limitation or bug in onnx2quant for models with a (1,5,8400) output? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Discussing with the AE team. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Has end-to-end been evaluated for the Ara240? The datasheet mentions two vector cores that can execute post-processing ops such as sigmoid and NMS. Could the compiler map NMS ops to the vector cores? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Sorry for the delay. I am trying to reproduce the conversion workflow.  One question for now, why the converted model's data type is FLOAT32? Have you tried to convert to INT8? The Neutron NPU requires the INT8 type as input data. I met the similar error on other models conversion and the root cause is the data type. Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU The confidence output is lost due to a fundamental limitation of full INT8 quantization ( inference_output_type=tf.int8 ) applied to YOLOv8's output tensor. YOLOv8 packs bounding box coordinates and confidence scores into a single output tensor of shape  (1, 5, 8400) . The bbox values have a large dynamic range (~640 pixels), while the confidence scores are in the range of ~0 to 1. When the entire output tensor shares a single quantization scale, that scale is dominated by the large bbox values (~640), leaving only a fraction of one integer level to represent the entire confidence range (~1). As a result, all confidence values are effectively rounded to zero after INT8 quantization. Recommended Solution Instead of going through  onnx2quant , export INT8 TFLite directly from your trained  .pt  model using Ultralytics, then feed it into  neutron-converter : # Export INT8 TFLite directly (calibration uses your training dataset) yolo export model=best.pt \ format=litert \ imgsz=640 \ quantize=8 \ data=dataset.yaml \ fraction=0.1 # Compile for Neutron (unchanged) neutron-converter --target imx95 --input best_int8.tflite --output best_neutron.tflite For the input and output data type, please ensure they are np.int8: interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors() inp_d  = interp.get_input_details()[0] out_ds = interp.get_output_details() inp_scale, inp_zp = inp_d["quantization"] out_d = out_ds[0] out_scale, out_zp = out_d["quantization"] print(f"  Input  dtype={inp_d['dtype']}  shape={inp_d['shape'].tolist()}"       f"  quant=(scale={inp_scale:.6f}, zp={inp_zp})") print(f"  Output dtype={out_d['dtype']}  shape={out_d['shape'].tolist()}"       f"  quant=(scale={out_scale:.6f}, zp={out_zp})")# Determine input format from shape in_shape = inp_d["shape"].tolist()   # [1,3,640,640] or [1,640,640,3] if in_shape[1] == 3:     # NCHW     src=img_nchw else:     # NHWC     src=img_nhwcif inp_d["dtype"] == np.int8:     src_int8 = np.clip(np.round(src / inp_scale + inp_zp), -128, 127).astype(np.int8)     interp.set_tensor(inp_d["index"], src_int8) else:     interp.set_tensor(inp_d["index"], src.astype(np.float32))interp.invoke() raw_out = interp.get_tensor(out_d["index"])  # may be int8 or float32if out_d["dtype"] == np.int8:     dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale else:     dq_out = raw_out.astype(np.float32)dq_out = dq_out[0]   # (5, 8400) normalized# Rescale bbox back to pixel coords for display BBOX_SCALE = 640.0 tfl_bbox = dq_out[:4] * BBOX_SCALE   # (4, 8400) tfl_conf = dq_out[4]                  # (8400,)
View full article
连接到 USDHC1 的 eMMC 能否用作引导设备? 你好, 我正在检查 i.MX 8DualX/8DualXPlus/8QuadXPlus 系列的启动 ROM 行为。 根据参考手册,推荐的启动连接方式如下: USDHC0 上的 eMMC USDHC1 上的 SD/eSD/SDXC 然而,在图 5-17 “扩展设备(SD/eSD/SDXC)启动流程”中,当 SD 初始化失败时,流程会通过连接器2继续到图 5-16 中的 MMC 初始化流程。ROM 似乎在 SD 协议失败后,尝试在同一个 USDHC 接口上使用 MMC 协议。 这是否意味着可以检测到连接到USDHC1 的eMMC 并将其用作启动 ROM 启动设备,可能以 4 位模式运行? 或者说,此 MMC 回退路径仅用于协议检测,而官方并不支持从 USDHC1 启动 eMMC? 我还想确认一下,此时 ROM 是否从 USDHC1 切换到 USDHC0,还是继续使用相同的 USDHC1 接口。 谢谢! Re: Can an eMMC connected to USDHC1 be used as a boot device? 我正在尝试了解 i.MX 8DualX/8DualXPlus/8QuadXPlus 启动 ROM 的启动流程,特别是 SD 卡启动的流程。 我目前的理解如下。 主启动和辅助启动失败后,ROM 可能会进入 SD/MMC 制造模式,这被称为恢复启动。 在此模式下: ROM 扫描 USDHC1 上的 SD 或 MMC 设备。 无论正常的总线宽度 eFuse 设置如何,都使用 1 位数据总线。 如果找到有效的启动映像,则加载并执行该映像。 如果将 eMMC 设备连接到 USDHC1,并且 BOOT_MODE[3:0] 设置为 0011(通过 USDHC1 进行 SD 卡启动),则预期的启动顺序是否如下? ROM 首先尝试使用 SD 卡启动流程进行正常的主启动,但失败了。 ROM 随后尝试二次启动,但也失败了。 ROM 进入 SD/MMC 制造模式(恢复启动),使用 MMC 协议检测到 USDHC1 上的 eMMC 设备,并成功从该设备启动。 换句话说,在这种硬件配置下,系统是否只能在恢复/制造启动阶段从 eMMC 启动,而不能在正常的启动阶段(主启动或辅助启动)从 eMMC 启动? Re: Can an eMMC connected to USDHC1 be used as a boot device? 你好, USDHC1 上的 eMMC 不能作为引导设备,有记录的主要映射是 USDHC0 上的 eMMC,USDHC1 上的 SD。 USDHC1 回退/恢复行为由 SD/MMC 制造模式使用。您可以参阅参考手册第 5.11 节。 顺祝商祺! Re: Can an eMMC connected to USDHC1 be used as a boot device? 你好, 是的,你的理解是正确的。 请注意,采用该配置后,SD/MMC 制造模式将“作为默认启动模式”,您将失去恢复设备的选项。 顺祝商祺!
View full article
Wi-Fi Chipset MCU Control Hello everyone, I was browsing for some wifi modules with AP+STA functionalities. I found some modules from NXP, Microchip, and Infineon for example. However, most of the modules are only enabling wifi interface through PCIe and with advanced OS. However, I found a set of MCU+Wifi module from infineon called AIROC CYW55X (series). Do you have any experience integrating and controlling these type of modules? If so, can you share different modules that you have used before and were able successful to integrate with an external MCU? My intention is not to offload data to the microcontroller, only to control for example the mesh and AP capabilities. I want to use a MCU (STM for example) to perform some inference on some basic AI models while controlling the wifi module. Thanks guys Re: Wi-Fi Chipset MCU Control Dear @ajihu , Based on your description, especially for running basic AI models, RW61X (RW610/RW611/RW612) may already be sufficient for your application. RW61X integrates: - MCU - Wi-Fi - Bluetooth LE - (RW612 also supports 802.15.4 / Thread) For basic AI inference workloads, RW61X can run both the application and wireless connectivity stack on a single device, potentially eliminating the need for an additional MCU. However, it is important to clarify what you mean by "Mesh". RW61X does NOT support: - IEEE 802.11s Mesh - EasyMesh RW61X supports: - Matter - Thread - Zigbee (via 802.15.4 ecosystem) - STA + uAP concurrent mode [Note] If additional AI processing performance is required, you may consider: - i.MX RT700 + IW61X - i.MX RT1170 + IW61X - i.MX RT1180 + IW61X Please note that these solutions also do NOT support: - IEEE 802.11s Mesh - EasyMesh They support: - Matter - Thread - Zigbee - STA + uAP concurrent mode Thanks! Best Regards, Weidong
View full article
Python で ReadPipeUIntArray を使用するとセグメンテーション違反が発生します こんにちは、 現在、パイプを使用してターゲットからホストへデータパケット(ヘッダー+ペイロード)をストリーミングしようとしていますが、問題が発生しています。 ReadPipeUIntArrayを使用してバイナリデータを読み込む際に、fmliteが頻繁にクラッシュします。参考として、Pythonのサンプルコードとfmliteの出力結果を添付しました。 前もって感謝します Re: Segmentation fault when using ReadPipeUIntArray via Python こんにちは、 @tschue-nxt さん。 現在この問題について調査中です。進展があり次第、ご連絡いたします。 Re: Segmentation fault when using ReadPipeUIntArray via Python こんにちは、@tschue-nxt さん。 添付のFMLITEバイナリを確認して、あなたのケースで動作するか教えてもらえますか? Re: Segmentation fault when using ReadPipeUIntArray via Python こんにちは、 @iulian_stan さん。 見た目も良く、ここ数分間はスムーズに動作しています。迅速な対応ありがとうございました!
View full article
S32DSにおけるLLCE FlexRay構成 こんにちは、 S32DS 上で LLCE FlexRay の設定に関する問題が発生しています。 このパラメータをTRUEにしたいのですが、IDEで長い時間を費やしたのに、正しい変更場所が見つかりませんでした。何か手がかりをくれる方はいませんか? 私のIDEバージョンはS32DS3.5.10です。 事前に感謝いたします。 Re: LLCE FlexRay configuration on S32DS こんにちは、 Yang_C お問い合わせいただきありがとうございます。 使用しているLLCEのバージョンは何ですか?S32G2とS32G3のどちらを使用していますか? BR ジョーイ Re: LLCE FlexRay configuration on S32DS こんにちは、ジョーイ。 私はS32DS3.5.10でS32G399を使用しています。LLCE 1.0.7、RTD 4.0.2 BR、 ヤン Re: LLCE FlexRay configuration on S32DS こんにちは、ジョーイ。 ご協力ありがとうございます。 お返事をお待ちしております。 BR、 ヤン Re: LLCE FlexRay configuration on S32DS こんにちは、 Yang_C これはソフトウェア自体の問題のようです。社内のソフトウェア開発者と確認するのを手伝います! BR ジョーイ
View full article