i.MX8M Mini support suspend to disk Hi, we would like to know whether the i.MX8M Mini supports "suspend-to-disk" (i.e hibernation to eMMC or others storage media)? command is "echo disk > /sys/power/state" i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8M Mini support suspend to disk Unfortunately, it is not supported in the current NXP BSP. For general reference, please refer to Suspend To Disk For ARM - eLinux.org . Thanks.

RT1176 无法对 MT25QL256ABA8E12 闪存进行编程 尝试对新的 3.3V 或非 闪存 MT25QL256ABA8E12 进行编程时，出现“20107 (0x4e8b) FlexSPINOR: SFDP Not Found.”错误。 之前，我们在上一版硬件中已经能够通过 USB 成功对 或非 Flash 进行编程。 电动汽车设计的关键区别在于 或非 Flash 设备：我们改用了 MT25QL256ABA8E12-0AAT，它虽然属于同一闪存系列，但却是 3.3V 的汽车级设备。 旧版闪存：MT25QU256ABA8E12-1SIT 新固件：MT25QL256ABA8E12-0AAT 此次更改会向 NVCC_SD2 提供稳定的 3.3V 电压，并且 3.3V 电源轨也会更新以适应新的 3.3V 或非 Flash。 请看一下，如果还有其他刷机设置需要调整，请告诉我。 Re: RT1176 Not able to program MT25QL256ABA8E12 flash 嗨，加文， 谢谢。 请查看附件，其中包含完整的 高效密码学标准\(SEC\) 日志中的 FCB 配置信息。请看一下，然后告诉我结果。 我想分享的一个数据点是，当我探测 或非 信号时，我注意到 RESET# 网络被拉高至 1.1-1.3V。这出乎我的意料，我目前还没有对此现象的合理解释。 Chris Re: RT1176 Not able to program MT25QL256ABA8E12 flash 谢谢。已确认该设计包含了所有3.3V电源轨的更新。 Re: RT1176 Not able to program MT25QL256ABA8E12 flash 除了SFDP之外，电源电压的变化可能会导致不同的原理图设计，因为1.8V需要改为3.3V。请将相关的或非 VCC 原理图和 PCB 布局中的电压从 1.8V 修改为 3.3V。 Re: RT1176 Not able to program MT25QL256ABA8E12 flash 嗨@chryao ， 感谢您的联系！ “完整 FCB”测试仅使用 FCB 内部的参数初始化 FlexSPI 控制器。没有对闪存执行擦除、编程或读取操作，因此不能确认闪存是否真的有响应。相比之下，简化选项 (0xC0000005) 需要从闪存读取 SFDP 表，这也是两个日志中唯一真正的闪存访问。它在 20107 年失败了。 请您在不使用 XMCD 的情况下，使用完整的 FCB 配置在 高效密码学标准\(SEC\) 中运行一次完整的写入操作，并分享完整的日志？此外，建议先在正常启动模式下进行测试，让 RAM 代码访问（读取/写入）闪存，以排除任何潜在的硬件相关问题。 此致， 加文 Re: RT1176 Not able to program MT25QL256ABA8E12 flash 附件是日志文件。 闪断故障日志 completeFCB 测试连接通过日志。 Re: RT1176 Not able to program MT25QL256ABA8E12 flash @Gavin_Jia请问NXP是否有RT1176 3.3V 或非 Flash（BGA-24封装）的认证供应商名单？

NXP SDKを用いたSPDIF出力ジッター spdif_edma_transfer MIMXRT1170-EVKBでの こんにちは、NXPサポートチームの皆さん、 私はSPDIFの問題を調査しています。 MIMXRT1170-EVKB開発ボード。 このプロジェクトは公式のNXP SDKに基づいています spdif_edma_transfer例です。 テスト構成: - 取締役会:MIMXRT1170-EVKB - コア:Cortex-M4 - SPDIF入力:J46(GPIO_AD_15) - SPDIF出力:J45(GPIO_AD_16) - サンプリングレート:48 kHz - 転送方法:eDMA - モード:連続的なSPDIF入力-出力転送 確認された問題: SPDIF入力信号は正常に受信されました。 DPLLが正しくロックされ、SPDIF伝送が開始されます。 しかしながら、SPDIF出力信号にはジッターが観測される。 期待される行動: SPDIF出力は受信したものを再現すべきです 安定したタイミングのSPDIFオーディオ信号。 私は完全な修正SDKデモプロジェクトを準備しました この問題を再現しています。 NXPのエンジニアがプロジェクトを確認して助けてもらえますか? SPDIF出力ジッターの原因を特定しますか? また、アタッチしてもよいかも知りたいです この議論のための完全なプロジェクトZIPファイル。 再開まで今しばらくお待ちください。 Re: SPDIF Output Jitter on MIMXRT1170-EVKB Using NXP SDK spdif_edma_transfer Example こんにちは、 @yp_wang さん。 ご連絡いただきありがとうございます！ SDKのバージョン番号を教えていただけますか?また、可能であれば最新バージョンのSDKに基づく最小限の再現可能なプロジェクトを共有してください。観測されたジッターの波形を添付していただけると助かります。これは、問題の再現と原因特定に役立ちます。 よろしくお願いいたします！ よろしくお願いします、 ギャビン Re: SPDIF Output Jitter on MIMXRT1170-EVKB Using NXP SDK spdif_edma_transfer Example よろしくお願いします。 spdif.pdfとmp4ファイルを参照してください。NXPアカウントに何か問題があります。テストコードが必要な場合は、メールアドレスを教えてください。 Re: SPDIF Output Jitter on MIMXRT1170-EVKB Using NXP SDK spdif_edma_transfer Example ファイルが添付されています Re: SPDIF Output Jitter on MIMXRT1170-EVKB Using NXP SDK spdif_edma_transfer Example こんにちは、 @yp_wang さん。 添付ファイルありがとうございます。 しかし、アプリケーションコードなしでは問題に対処できません。可能であれば、公式のチャネルを通じてチケットを提出していただけませんか?こうすることで、アップロードしたコードや最小限の複製プロジェクトはプライベートなままで、外部ユーザーにはアクセスできません。 リンク： https://support.nxp.com/s/ よろしくお願いします！

外围设备 DMA TCD“开始”字段 S32Z2 参考手册第 5 版第 1399 页第 1 点规定： “1.用户向TCDn_CSR[START]字段写入请求通道服务。” 同一文档第 1354 页的 TCD CSR 内存映射中，没有显示名为“START”的 CSR 的任何字段。TCDn_CSR 的哪一位是起始位？我正在尝试从SW发起手动转账。 Re: Peripheral DMA TCD "START" FIELD 嗨，罗伯特， 谢谢你指出这一点。 寄存器映射表标识了 TCDn_CSR 寄存器及其偏移量，但没有列出各个位字段。有关字段定义，请参阅同一 S32Z2 参考手册第 1383-1385 页的第 45.3.2.18 节“TCD 控制和状态 (TCD0_CSR - TCD31_CSR)”。 本节表明 START 字段是 TCDn_CSR 的第 0 位，即 TCDn_CSR[0] 。 我希望这能澄清登记册地图和详细登记册描述之间的明显区别。 此致， 阿尔多。

P1020およびP2020のDDRCLK周波数 こんにちは P1020とP2020のDDRCLK周波数について質問があります。 データシートによると、P1020のDDRCLK最低周波数は66.66MHz、P2020は66.7MHzとされています。 このわずかな差は、仕様の違いや変更によるものですか、それとも単に小数点以下第1位への四捨五入の結果ですか？ よろしくお願いします Re: DDRCLK frequency of P1020 and P2020 これは端数処理による差にすぎません。 両デバイスとも、最大DDRCLK周期は15ナノ秒（約66.67MHz）と規定している。P2020では66.7MHzと丸められているのに対し、P1020では66.66MHzと記載されている。 よろしくお願いします。 Re: DDRCLK frequency of P1020 and P2020 June_Luさん、ご協力ありがとうございました。 BR、

ST25R500ライブラリとNXP MWCT2016Sの統合 こんにちは、 現在、 NXP MWCT2016S MCU と ST25R500 NFCリーダを統合したワイヤレス充電器プロジェクトに取り組んでいます。 NXPの非AUTOSARプラットフォームに ST25R500 ライブラリパッケージをどのように統合するかを理解したいです。 統合プロセスについてご案内いただき、関連するドキュメントやアプリケーションノート、またはプロジェクトの例を教えていただけますか? 皆さんのサポートをいただけると大変ありがたいです。 ご協力ありがとうございました。 よろしくお願いいたします。 ラク Re: ST25R500 Library Integration with NXP MWCT2016S こんにちは、 @rakYps21さん 以下のリンクでは、カスタムライブラリをS32DS/Eclipseに追加および統合する方法について説明しています。あなたのアプリケーションには役立つかもしれません。 HOWTO: S32DS GCC プロジェクトに静的ライブラリファイルを追加する方法 ARM gccとEclipseでのライブラリの作成と利用 |EclipseでのMCU GNU LinkerおよびEclipseでのカスタムライブラリ名の使い方 |EclipseのMCU ST25R500ライブラリの統合については、サードパーティ製ソフトウェアコンポーネントであり、NXPが開発・保守しているわけではないため、当社のサポート範囲外です。したがって、当該ライブラリの機能、実装、デバッグに関するガイダンスを提供することはできません。 しかし、MWCT2016Sの設定、ソフトウェアパッケージ、ドライバ、対応機能など、関連するトピックについてはお手伝いできます。 BR、VaneB

RW612用32.768kHz水晶発振子 こんにちは、 現在、u-bloxのIRIS-W10モジュールにRW612を内蔵したPCB設計プロジェクトに取り組んでいます。これはNXP MCUを使った初めてのデザインです。 RTC外部クリスタルの回路設計方法が迷っています。STM32などの他のMCUでは、水晶発振器のピン両方に外部負荷コンデンサが必要であることがわかっています。しかし、NXPのMCUの中には、内部で設定可能な負荷容量を備えているものもあるようだ。RW612レジスタリストで、RTC CTRLレジスタ、特にRTC_OSC_LOADCAPフィールドを見つけました。これはこのMCUに内部負荷上限があることを示していますが、この分野に関するドキュメントは見つかりませんでした。 SO 質問ですが、このレジスタで特定のコンデンサ値を設定するためのビットフォーマットは何でしょうか? 製品: WiFi RW6XX Re: 32.768kHz Crystal for RW612 以下は、32k XTALに関連するレジスタです。RTC_OSC_LOADCAPのレジスターはこの製品に当てはまらない可能性があるため謎のようです Re: 32.768kHz Crystal for RW612 ご返信よろしくお願いします。 RTC水晶発振器の構成は2つのセクションに分かれているようだ。あなたが見せてくれたのはPMUからのものです。私にとって頭痛の種はRTCセクションです。 下のスクリーンショットでは外部コンデンサは見当たりませんが、内部のコンデンサは見当たりません このスクリーンショットでは、私が質問で話していた特定のレジスターが見えます。 このMCUには内部コンデンサが全くないというあなたの言う通りかもしれませんが、もしそうならRTC_OSC_LOADCAPフィールドはレジスタのドキュメントに表示されないはずです。 一方、FRDM-RW612のこの水晶回路には、工場出荷時には負荷コンデンサが取り付けられていません。

Kinetis (KW3x/4x, MCX W7x and MCX W23) Wireless Connectivity Power Profile Tools This page is dedicated to the Kinetis (KW35/KW38/KW45/KW47) and MCX Wx (MCX W71/72 & MCX W23) Power Profile Tools. It will help you to estimate the power consumption in your application (Automotive, IIoT, Trackers/Tags and Continuous Glucose Monitoring [CGM]) and evaluate the battery life time of your solution. This page contains 4 market segments which provides dedicated power profile tool on standalone product or full system application for:    1. Automotive Kinetis (KW3x/4x) Power Profile Tools for Automotive - NXP Community Bluetooth LE for the KW35/36 products in standalone. Bluetooth LE for the KW37/38/39 products in standalone. Bluetooth LE for the KW45/KW47 products in standalone. SmartFob application (BLE/KW45; UWB Ranger4; SE; motion sensor)  SmartFob application (BLE/KW47; UWB Ranger5; SE; motion sensor)     2. IIoT Kinetis MCX Wxx (MCX W71/72 & MCX W23) Power Profile Tools for IIoT - NXP Community Bluetooth LE for the MCX W71/MCX W72 product in standalone. Bluetooth LE for the MCX W23 product in standalone. 802.15.4 Matter ICD SIT & LIT and ZED for the MCX W71 & W72 product in standalone (IIoT). Aliro Doorlock application    3. Localisation application (CCC CS) for Automotive & IIoT Kinetis MCX Wxx (KW47 & MCX W72) Power Profile Tools for Bluetooth Localization - NXP Community Product: JN518X Product: K32W0 Product: K32W1 Product: KW 34|35|36 Product: KW 37|38|39 Product: KW41Z |31Z | 21Z Product: QN9080|SIP Product: QN9090|30 Product: UWB NCJ29D5 Protocol: BLE -> connectivity Protocol: Matter Protocol: Zigbee Re: Kinetis (KW3x/4x, MCX W7x and MCX W23) One Wireless Connectivity Power Profile Tool Hi @stephen_t , Application Note is on the way to explain how to use this new tool. Find a draft version attached. It covers Bluetooth LE part for the moment. Re: Kinetis (KW3x/4x, MCX W7x and MCX W23) One Wireless Connectivity Power Profile Tool Hello , Suppose if we need to design a digital keyfob which combine KW45+NCJ29D5/6+SecureEngine how to use this tool. Any guidance document avatilable will be helpful. Re: Kinetis (KW3x/4x, MCX W7x and MCX W23) One Wireless Connectivity Power Profile Tool @christophe_menard  Thank you very much  for the draft document , will be interested in the final version also as it will help to correctly configure UWB and SE. Regards Stephen

KW45のTx出力出力の消費電力は:-15,-10,-5,-2 dBm(カリキュレータ1_4)で こんにちは、 KW45_WK47_MCXW71_MCXW72_BLE_power_profile_calculator_v1.40.xlsxでは、送信出力（dBm）が0dBmから10dBmまでの消費電力が示されています。 KW45に-15、-10、-5、-2 dBmを追加することは可能でしょうか？追加したファイルを完成させるために。 ありがとうございます。 Re: Consumption for KW45 function of Tx Output power for : -15,-10,-5,-2 dBm with calculator 1_4 こんにちは、 あなたの調子が良いといいのですが。この送信値は、 当社のKW45B(無線)およびKW45Z(MCU)データシートに示された典型的な値に対応しています。 また、すべてのプロファイルツールについては、当社のメイン投稿を参照することをお勧めします: Kinetis(KW3x/4x、MCX W7xおよびMCX W23)ワイヤレス接続パワープロファイルツール よろしくお願いいたします。 リカルド

S32G274 裸机代码 我想在 S32G274 开发板上使用裸机程序，包括用于启动 A53 处理器、LINFlexD 串口和以太网等模块的裸机驱动程序。我希望它能够开箱即用。S32DS 生成的驱动程序仅包含处理器启动功能。 我尝试自己实现 LINFlexD 串口（启用引脚、启用时钟、初始化串口接口），但我不太清楚如何正确处理时钟启用。 我希望您能提供一个可以直接在 S32DS 中编译的现成裸机程序。 Re: S32G274 baremetal code 你好， @Tatu_dd 感谢你的帖子。 1. NXP针对S32G274A的软件赋能策略主要将A53内核定位为Linux 电路板支持包。运行环境，而非裸机开发环境。S32 Design Studio 3.6.8中针对A53内核的示例代码特意限制为启动代码，因为其预期用途是在这些内核上运行完整的Linux发行版。 2. 对于裸机A53开发，目前公开的参考代码不多，只有一个演示版本，但它并非纯粹的A53裸机代码，而是一个异构实现。 因此，您可能需要根据自身需求实现或移植现有的 Linux 驱动程序或 RTD 驱动程序，很抱歉，NXP 没有提供任何直接的正式示例/软件版本。 BR 陈银 Re: S32G274 baremetal code 你好@chenyin_h ， 谢谢你的回复，我知道这条信息。 谢谢你！ BR Tatu_dd Re: S32G274 baremetal code 你好， @Tatu_dd 不客气。 如果您在使用 S32G 产品过程中需要任何其他支持，欢迎您为此开设新帖，我们很乐意提供帮助。 BR 陈银

24MHz时钟问题RT1052 你好， 我开发了一款定制的PCB，其中包括RT1052 MCU。 我使用的时钟配置如下： 其中 C57 和 C58 被替换为 4.7 pF，以符合评估板的要求。 但是，我无法启动芯片上的振荡器。 我觉得启动顺序是正确的： 1) SNVS 3V3 稳定 2) NVCC_x、DCDC_IN、VDD_HIGH（3V3_main）变为 3V3 稳定。 3) VDD_SOC 稳定在 1.1V，这没问题。 当所有电源线都正常且选项字节设置为串行下载时，POR 将被释放。 如果我打开电源，我在示波器上看到没有振荡开始，XTALO 稳定在 3V3。 黄色 XTALO，蓝色 XTALI，绿色 3V3_main，红色 POR（200 毫秒后变为高电平） 如果我关闭电源，我看到一些振荡，我假设振荡器参数正常。 另外，虽然引脚连接正确，但我没有SWD通信。我尝试注入 20 MHz 时钟信号，得到了一些响应，但没有可靠的通信。因此，我首先尝试修复 24 MHz 振荡器。 有人知道为什么振荡器不启动吗？ i.MX-RT1050 Re: 24MHz clock issue RT1052 嗨@JBA ， 非常感谢您对我们产品的关注以及对我们社区的使用。 根据您的描述，我建议您检查与振荡器相关的连接以及实际的上电波形。 1：请在上电期间测量 VDD_SNVS_IN、VDD_HIGH_IN、DCDC_IN、DCDC_PSWITCH 和 POR_B。尤其请检查 DCDC_PSWITCH 在 DCDC_IN 稳定后至少 1 毫秒是否上升。 2：请查阅晶体制造商的规格说明，了解其负载电容（CL ）和ESR，然后使用已安装的电容器值以及PCB和MCU引脚的寄生电容来计算有效负载电容。确认计算出的负载是否适合该晶体。除非晶体规格和板寄生参数相当，否则不应直接复制 EVK 的 4.7 pF 电容值。 3：请在电源稳定后测量 NVCC_PLL 处的电压。如果使用外部时钟源重复测试，请驱动 XTALO 并确保时钟的高电平电压不超过测量的 NVCC_PLL 电压。 顺祝商祺！ 刘梅

i.MX7D UART5をI2C4を使用してDTEモードで使用 こんにちは。 これはオリジナルのi.MX7Dボードです。 2線式UART5回路はI2C4ポートを使用します。 このUART5はDTEモードです。 CCM、IOMUXCポート、IOMUXC DAISY設定、およびUART5を設定しています。 CCM_TARGET_ROOTn=0x10000000 CCM_CCGRn=0x3 IOMUXC_SW_MUX_CTL_PAD_I2C4_SCL=1 IOMUXC_SW_MUX_CTL_PAD_I2C4_SDA=1 IOMUXC_UART5_RX_DATA_SELECT_INPUT=1 UART5_UCR1=1 UART5_UCR2=0x7027 UART5_UCR3=0x784 UART5_UCR4=0x8000 UART5_UFCR=0x240 UART5_UBIR=0xF UART5_UBMR=0x271 1文字送信後、UART5_UTSは0x20のままです（0x60から変更されています）。 UART5_UTSが0x60に戻らない理由がわかりません。 よろしくお願いいたします。 Re: i.MX7D UART5 in DTE mode using I2C4 ネタバレ （ハイライトして読む）     こんにちは。AldoGです。 私が送信した情報の一部に誤りがありました。 UART5_CLK_ROOT(0x30380b18)=0x10000000 正しいバージョンは以下のとおりです。 UART5_CLK_ROOT(0x3038b180)=0x10000000 よろしくお願いいたします。 Re: i.MX7D UART5 in DTE mode using I2C4 こんにちは。AldoGです。 起動時になぜかIPG_CLK_ROOT(0x30389080)が0x1に設定されていたので、0x0に変更しました。 UART5_CLK_ROOT(0x30380b18)=0x10000000 UART5_CCM_CCGR=CCM_CCGR152(0x30384980)=0x3 このように設定されています。 使用するピンをI2C4からSAI1に変更してみましたが、うまくいきませんでした。 USR2内のTXDCにチェック対象のレジスタを設定しました。 よろしくお願いいたします。 Re: i.MX7D UART5 in DTE mode using I2C4 こんにちは、 i.MX7D UARTステータスレジスタの場合、UTS[6]はTX FIFOが空であることを示す値であり、UTS[5]はRX FIFOが空であることを示す値です。したがって、0x60は両方のFIFOが空であることを示し、0x20はRX FIFOは空だがTX FIFOはまだ空ではないことを示します。したがって、キャラクターを書いた直後にすぐに見0x20を見ることは予想できます。 UTS[6]はFIFO状態のみを反映しています。文字の送信が完全に完了したかどうかを判断する必要がある場合は、送信FIFOとシフトレジスタが空であることを示すUSR2[TXDC]を確認してください。 この2線式構成の場合、以下の点も確認してください。 ハードウェアCTS/RTSフロー制御は無効になっています。対応する信号がコネクテッドでない状態でCTS/RTSを有効にすると、送信が妨げられることがあります。 UART5の機能クロックとIPGクロックの両方が有効になっており、UBIR/UBMR値は実際のUART5クロック周波数を使用して計算されます。 DTEピンのマッピングはi.MX7Dリファレンスマニュアルと照合されています。DTEモードでは見かけのRX/TXピンの方向が変わるため、信号名が混乱しやすいことがあります。 I2C4ペリフェラルも有効化されておらず、同じパッドを駆動していません。 UART5のTXピンは、オシロスコープまたはロジックアナライザでプローブされます。有効な波形が存在する場合、0x20という読み取り値はステータスサンプリングの問題である可能性が高いです。波形が表示されない場合は、まずクロック、フロー制御、およびピン多重化の設定を確認してください。 i.MX 7Dualリファレンスマニュアル(IMX7DRM)、特にUARTとIOMUXのセクションを参照してください。NXPのiMX7 UARTピン設定およびi.MX7 IPG_CLK_ROOTとUARTのクロックに関する説明も参考になるかもしれません。 よろしくお願いいたします。 アルド。

NXP開発ボード ARM Cortex-A53、FRDM-IMX8MPLUS電源オンスイッチが動作しません こんにちは NXP開発ボード(ARM Cortex-A53、FRDM-IMX8MPLUSを購入しました しかし、スイッチをスライドさせてみると電源が動かなくなりました。マザーボードかスイッチの欠陥でしょうか?スイッチを交換しましたが、それでも動作しません。スイッチ NXP Development Board ARM Cortex-A53, FRDM-IMX8MPLUSNXP Development Board ARM Cortex-A53, FRDM-IMX8MPLUSNXP Development Board ARM Cortex-A53, FRDM-IMX8MPLUSNXP Development Board ARM Cortex-A53, FRDM-IMX8MPLUSNXP Development Board ARM Cortex-A53, FRDM-IMX8MPLUSNXP開発ボードのARM Cortex-A53、FRDM-IMX8MPLUS電源オンのエンバレーリング方法を教えていただけますか i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: NXP Development Board ARM Cortex-A53, FRDM-IMX8MPLUS power on switch not working こんにちは 私はSamsung モバイル Adpoterの5対3Aスペックを使っています Re: NXP Development Board ARM Cortex-A53, FRDM-IMX8MPLUS power on switch not working こんにちは、 @nalini さん。 FRDMには12V以上の入力電圧が必要です。5Vの充電器では動作しません。PDサポートの別の充電器を試してみるのもいいでしょう。 よろしくお願いします、 志明 Re: NXP Development Board ARM Cortex-A53, FRDM-IMX8MPLUS power on switch not working こんにちは、 @nalini さん。 お使いの電源ユニットの消費電力は何ワットですか？ よろしくお願いします、 志明 Re: NXP Development Board ARM Cortex-A53, FRDM-IMX8MPLUS power on switch not working やあ、ジュミンさん 5Vのモバイル電源アダプターを使うと、基板がオンになっています。しかし、スライド電源スイッチは基板の電源を切っていません。基板はスライド電源スイッチのどの位置(オンまたはオフ)でも電源がオンのままです。スイッチを交換しましたが、それでも動作しません

Tamper detection function in iMX6ULL I would like to enable the active tamper detection feature on the i.MX6ULL processor in order to detect when the device enclosure is opened. A switch has been added to the hardware and connected to the external tamper pins, as shown in the attached figure. Do you have any examples or documentation on how to support tamper detection on the software side? Is there an example implementation or a sample function that demonstrates how to configure and handle this feature? Re: Tamper detection function in iMX6ULL Hello, The tamper feature on i.MX 6ULL is controlled by a Fuse which is currently provisioned by NXP to disable this feature on all production part numbers for i.MX6ULL. Several customer-facing documents incorrectly state that i.MX 6ULL supports external tamper. Since the fuse is programmed to disable this feature on all i.MX 6ULL part numbers, a customer will not be able to use the tamper feature even though the tamper pins are documented in the current documentation. Documentation will be updated to reflect that tamper is not Supported. Please also note that the derivative product i.MX 6ULZ also does not support Tamper Feature i.MX 6UL -3 i.MX 6ULL/6ULZ Comments Tamper Detection Signal Yes  No Active Tamper only on i.MX 6UL  Volt/Temp/Freq Detect (DRY-ICE) Yes  No DRY-ICE & Active Tamper features not supported on i.MX 6ULL/ULZ Best regards.

[88W8997] WLAN RF Test Hello, we want to perform the WIFI/BT regulatory compliance test for the 88W8997 module, which is assembled on the Toradex imx8mp SOM. We are following the instructions described here: https://www.nxp.com/docs/en/application-note/AN14114.pdf For building the driver we were following the UM11675 document, where it refers to https://github.com/nxp-imx/mwifiex (driver) and https://github.com/nxp-imx/imx-firmware (related firmware packages). I build and installed the driver and the firmware on my device and tried to get into the rf test mode. The mentioned driver offers me now the possibility to use the /proc/mwlan/adapter0 interface, where I tried to switch to test mode with the echo "rf_test_mode=1" > /proc/mwlan/adapter0/config" command.  Unfortunately, the driver prints Could not set RF test mode. Why is it not possible to switch directly to test mode?  After further investigation I figured out that if I change the drv_mode to 2 (drv_mode=2 > config), I am able to switch to test mode with "rf_test_mode=1" command. Is this correct? Shouldn't it be possible to get into the mode with the default drv_mode value (default: drv_mode=7)? However, I continued the documents where I entered the described commands: echo "tx_frame=0" > /proc/mwlan/adapter0/config echo "tx_antenna=2" > /proc/mwlan/adapter0/config echo "band=0" > /proc/mwlan/adapter0/config echo "bw=0" > /proc/mwlan/adapter0/config echo "channel=" + str(channel)) echo "tx_power=10 0 1" > /proc/mwlan/adapter0/config echo "tx_frame=1 0x3 0xB496DEB6 0x400 1 100 0 0 0 0 0 0 0 -1 -1 -1 -1 -1 -1 -1 -1 {MAC_ADDRESS}" > /proc/mwlan/adapter0/config When I check the results on the spectrum analyzer, I cannot see any change there. Is there another possibility to check the test mode is working? Another strange thing is, that as MAC address it always shows 00:00:00:00:00, even though I am setting it with tx_frame.  hardware_status=0 netlink_num=31 drv_mode=2 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 rx_antenna=1 band=0 bw=0 channel= radio_mode[0]= radio_mode[1]= total rx pkt count=0 rx multicast/broadcast pkt count=0 rx fcs error pkt count=0 tx_power= tx_continuous=0 tx_frame=0 he_tb_tx=0 trigger_frame=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 antcfg=0x3 0x3 Further notes: I read somewhere, that a mfg firmware must be used. When I add this firmware to /lib/firmware/nxp, modify the wifi_mod_para.conf file (Replaced the fw_name with the mfg firmware and added mfg_mode=1 to the SD8997 section) and reloaded the driver (rmmod moal.ko; insmod moal.ko mod_para=nxp/wifi_mod_para.conf. The driver prints that the firmware is already running. When I use echo "fw_reload=1" > /proc/mwlan/adapterX/config, the driver prints the download of FW failed. A reboot is then required. Can you help me out here? Thanks Re: [88W8997] WLAN RF Test @sportzfy we want to perform the WIFI/BT regulatory compliance test for the 88W8997 module, which is assembled on the Toradex imx8mp SOM. We are following the instructions described here: https://www.nxp.com/docs/en/application-note/AN14114.pdf For building the driver we were following the UM11675 document, where it refers to https://github.com/nxp-imx/mwifiex (driver) and https://github.com/nxp-imx/imx-firmware (related firmware packages). I build and installed the driver and the firmware on my device and tried to get into the rf test mode. The mentioned driver offers me now the possibility to use the /proc/mwlan/adapter0 interface, where I tried to switch to test mode with the echo "rf_test_mode=1" > /proc/mwlan/adapter0/config" command. Unfortunately, the driver prints Could not set RF test mode. Why is it not possible to switch directly to test mode? After further investigation I figured out that if I change the drv_mode to 2 (drv_mode=2 > config), I am able to switch to test mode with "rf_test_mode=1" command. Is this correct? Shouldn't it be possible to get into the mode with the default drv_mode value (default: drv_mode=7)? However, I continued the documents where I entered the described commands: echo "tx_frame=0" > /proc/mwlan/adapter0/config echo "tx_antenna=2" > /proc/mwlan/adapter0/config echo "band=0" > /proc/mwlan/adapter0/config echo "bw=0" > /proc/mwlan/adapter0/config echo "channel=" + str(channel)) echo "tx_power=10 0 1" > /proc/mwlan/adapter0/config echo "tx_frame=1 0x3 0xB496DEB6 0x400 1 100 0 0 0 0 0 0 0 -1 -1 -1 -1 -1 -1 -1 -1 {MAC_ADDRESS}" > /proc/mwlan/adapter0/config When I check the results on the spectrum analyzer, I cannot see any change there. Is there another possibility to check the test mode is working? Another strange thing is, that as MAC address it always shows 00:00:00:00:00, even though I am setting it with tx_frame. hardware_status=0 netlink_num=31 drv_mode=2 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 rx_antenna=1 band=0 bw=0 channel= radio_mode[0]= radio_mode[1]= total rx pkt count=0 rx multicast/broadcast pkt count=0 rx fcs error pkt count=0 tx_power= tx_continuous=0 tx_frame=0 he_tb_tx=0 trigger_frame=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 antcfg=0x3 0x3 Further notes: I read somewhere, that a mfg firmware must be used. When I add this firmware to /lib/firmware/nxp, modify the wifi_mod_para.conf file (Replaced the fw_name with the mfg firmware and added mfg_mode=1 to the SD8997 section) and reloaded the driver (rmmod moal.ko; insmod moal.ko mod_para=nxp/wifi_mod_para.conf. The driver prints that the firmware is already running. When I use echo "fw_reload=1" > /proc/mwlan/adapterX/config, the driver prints the download of FW failed. A reboot is then required. Can you help me out here? Have you tried checking whether the correct manufacturing firmware and mfg_mode=1 settings are enabled for the 88W8997? I’d also verify the supported drv_mode and RF test commands for your driver version. Re: [88W8997] WLAN RF Test Hello, We are using now the toradex wifi layer (https://github.com/toradex/meta-toradex-wifi/tree/kirkstone-6.x.y) and utilizes the integrated labtool utility. Additionally, we used the toradex reference image instead of our official one. With this setup it seems to work now. Thanks. Re: [88W8997] WLAN RF Test Hello @joschi2804  After further investigation I figured out that if I change the drv_mode to 2 (drv_mode=2 > config), I am able to switch to test mode with "rf_test_mode=1" command. Is this correct? Shouldn't it be possible to get into the mode with the default drv_mode value (default: drv_mode=7)? --> drv_mode = 1;3;7 is fine, just make sure mlan0 interface enable.  When I check the results on the spectrum analyzer, I cannot see any change there. Is there another possibility to check the test mode is working? --> Could you share output of "cat /proc/mwlan/adapter0/config" after tx_frame = 1? You should make sure all parameters are configured correctly. You may also share spectrum output to us as well. Also make sure spectrum configured well.  I read somewhere, that a mfg firmware must be used. When I add this firmware to /lib/firmware/nxp, modify the wifi_mod_para.conf file (Replaced the fw_name with the mfg firmware and added mfg_mode=1 to the SD8997 section) and reloaded the driver (rmmod moal.ko; insmod moal.ko mod_para=nxp/wifi_mod_para.conf. The driver prints that the firmware is already running. When I use echo "fw_reload=1" > /proc/mwlan/adapterX/config, the driver prints the download of FW failed. A reboot is then required. --> this is another way for rf test, please refer to UM11675 only. Re: [88W8997] WLAN RF Test Hello, I am using the latest branch of this repository.https://github.com/nxp-imx/imx-firmware/tree/lf-6.6.3_1.0.0/nxp/FwImage_8997_SD The wifi_mod_param.conf file refers to the sdiouart8997_combo_v4.bin firmware. Re: [88W8997] WLAN RF Test Hello @joschi2804  Could you share driver and firmware version?  Best Regards Shaun

iMX6ULL中的防篡改检测功能 我希望在 i.MX6ULL 处理器上启用主动防篡改检测功能，以便检测设备外壳何时被打开。 如图所示，硬件中增加了一个开关，并将其连接到外部防拆引脚。 您是否有关于如何在软件端支持篡改检测的示例或文档？是否有示例实现或示例函数来演示如何配置和处理此功能？ Re: Tamper detection function in iMX6ULL 你好， i.MX 6ULL 的防篡改功能由一个熔丝控制，目前 NXP 已对该熔丝进行了配置，以禁用 i.MX6ULL 所有生产部件号的此功能。 一些面向客户的文档错误地指出 i.MX 6ULL 支持外部篡改。由于所有 i.MX 6ULL 部件号的熔丝都被编程为禁用此功能，因此即使防篡改引脚在当前文档中有记录，客户也无法使用防篡改功能。 文档将更新，以反映不支持篡改。 另请注意，衍生产品 i.MX 6ULZ 也不支持篡改功能。 特性 i.MX 6UL -3 i.MX 6ULL/6ULZ 备注 防篡改检测信号 是 不 仅在 i.MX 6UL 上启用主动防拆功能 电压/温度/频率检测（干冰） 是 不 i.MX 6ULL/ULZ 不支持干冰和主动防篡改功能 顺祝商祺！

S32G274 ベアメタルコード S32G274の開発ボード上でベアメタルプログラムを使いたいと思っています。A53プロセッサの電源供給、LINFlexDシリアルポート、イーサネットなどのモジュール用のベアメタルドライバも含めて。箱から出してすぐに正常に動作させたいです。S32DSで生成されるドライバには、プロセッサの電源アップ機能のみが含まれています。 自分でLINFlexDシリアルポートの実装(ピンの有効化、クロックの有効化、シリアルインターフェースの初期化)を試みましたが、クロックの有効化の適切な扱い方がよくわかりません。 S32DSで直接コンパイルできる、すぐに使えるベアメタルプログラムを提供していただければ幸いです。 Re: S32G274 baremetal code こんにちは、 @Tatu_dd 投稿ありがとうございます。 1. NXPのソフトウェア支援S32G274A戦略では、A53コアは主にベアメタル開発ではなくLinux BSP運用に割り当てられています。A53コア向けのS32 Design Studio 3.6.8の例は、意図的に起動/起動コードに限定されており、意図された使用ケースはこれらのコア上で完全なLinuxディストリビューションを実行することが目的です。 2. ベアメタルA53開発に関しては、公開されているリファレンスコードはほとんどなく、デモは存在するものの、それはA53上の純粋なベアメタルコードではなく、異種実装である。 そのため、既存のLinuxドライバやRTDドライバを必要に応じて実装または移植する必要があるかもしれません。申し訳ありませんが、NXPによる直接的な例やソフトウェアリリースは提供されていません。 BR チェイン Re: S32G274 baremetal code こんにちは@chenyin_h さん、 ご返信ありがとうございます。このメッセージは知っていました。 ありがとう！ BR Tatu_dd Re: S32G274 baremetal code こんにちは、 @Tatu_dd どういたしまして。 S32G製品の使用中に他のサポートが必要な場合は、新しいThreadを開いてください。喜んでお手伝いします。 BR チェイン

24MHzクロックの問題 RT1052 こんにちは、 RT1052 MCUを含むカスタマイズされたPCBを開発しました。 私が使用しているクロック設定は以下のとおりです。 ここでC57とC58は評価ボードに適合するために4.7 pFに置き換えられています。 しかし、チップ上の発振器を起動することができません。 電源投入の手順は正しいように思われます。 1) SNVS 3V3が安定 2) NVCC_x、DCDC_IN、VDD_HIGH (3V3_main) が 3V3 で安定する。 3) VDD_SOCが1.1Vで安定し、これは正常です。 PORは、すべての電源ラインが正常であり、オプションバイトがシリアルダウンロードに設定された後にリリースされます。 電源を入れると、オシロスコープ上で発振が始まらず、XTALOが3V3で安定していることが確認できます。 黄色：XTALO、青色：XTALI、緑色：3V3_main、赤色：POR（200ms後にハイレベルになる） 電源を入れると、発振器のパラメータが正常と思われる振動が見られます。 また、ピン留めが正しく行われているにもかかわらず、SWD通信ができません。20MHzのクロックを注入してみたところ、多少の反応はあったものの、安定した通信は得られませんでした。そこで、まずは24MHz発振器の修理を試みました。 発振器が起動しない理由を知っている人はいますか？ i.MX-RT1050 Re: 24MHz clock issue RT1052 こんにちは、 @JBA さん。 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 あなたの説明に基づくと、発振器関連の接続と実際の電源投入時の波形を確認することをお勧めします。 1:  電源投入時に、VDD_SNVS_IN、VDD_HIGH_IN、DCDC_IN、DCDC_PSWITCH、およびPOR_Bを測定してください。特に、DCDC_INが安定してから少なくとも1ms後にDCDC_PSWITCHが上昇することを確認してください。 2:結晶メーカーの負荷静電容量(CL)​およびESRの仕様を確認し、搭載されたコンデンサ値とPCBおよびMCUピンの寄生静電容量を組み合わせて有効負荷静電容量を計算してください。計算された負荷が水晶にとって適切であることを確認してください。EVKの4.7pFのコンデンサ値は、水晶発振器の仕様と基板の寄生容量が同等でない限り、そのままコピーすべきではありません。 3：電源が安定した後、NVCC_PLLの電圧を測定してください。外部クロックソースを使用してテストを繰り返す場合は、XTALOを駆動し、クロックのハイレベル電圧が測定されたNVCC_PLL電圧を超えないようにしてください。 よろしくお願いいたします。 メイ・リウ

Consumption for KW45 function of Tx Output power for : -15,-10,-5,-2 dBm with calculator 1_4 Hello,  In the KW45_WK47_MCXW71_MCXW72_BLE_power_profile_calculator_v1.40.xlsx, the consumption is given for a Tx outpower (dBm) between 0dBm to 10dBm Is it possible to add -15; -10, -5 -2 dBm for the KW45 ?  to complete the file added ?  Thank you  Re: Consumption for KW45 function of Tx Output power for : -15,-10,-5,-2 dBm with calculator 1_4 Hello, Hope you are doing well. The Tx corresponds to our typical values shown in our KW45B (radio) and KW45Z (MCU) Data Sheet. Also, I would recommend referring to our main post for all our profile tools: Kinetis (KW3x/4x, MCX W7x and MCX W23) Wireless Connectivity Power Profile Tools Best Regards, Ricardo

Androidカーヘッドユニット i.MX – 適合性、BSP 部品番号：i.MX 8M Plus / i.MX 95 / i.MX 8QuadXPlus / i.MX 8QuadMax こんにちは、 私たちは、Androidベースのアフターマーケットカーヘッドユニット用に、NXP i.MX アプリケーションプロセッサ(i.MX 8M Plus、i.MX 95、i.MX 8QuadXPlus / 8QuadMax)を評価しています。どの部品が最も私たちの要件に合っているのか、価格やサポート条件についても知りたいと思っています。これらのいずれも適切でない場合は、NXPの製品ポートフォリオの中から、弊社の開発に適した代替部品をご提案ください。 製品要件 プラットフォーム - Android (AOSP) 13以降、BSPソース(ブートローダー、カーネル、HALs)を使用 - 4GB DDR4/LPDDR4、64GB eMMC - オクタコアクラスCPU(または同等の性能) - インダストリアル(-40〜85°C)またはオートモーティブ(AEC-Q100)温度グレードが推奨されます 画面 - 9インチ、1280×800ピクセルのパネル、LVDS推奨（MIPI DSIも可） - I2C経由の静電容量式タッチ - ディスプレイの色調整（コントラスト、彩度、色温度） カメラとビデオ - 4台× AHD 720p/1080pカメラを、MIPI CSI-2(仮想チャネル)で外部4チャネルデコーダー経由で360°サラウンドビューを使用。 - CVBSバックカメラ、前後カメラ、CVBSデコーダーによるAV-INビデオ - H.264/H.265 1080pデコード;前後録画用のマルチストリームH.264エンコード(例:4×720p) - 2D/3Dの360°ステッチング対応GPU機能 オーディオ - I2S/TDM(少なくとも1つの8チャネルTDMポート、合計3ポート)はマルチチャネルコーデック、FM/AMチューナー、Bluetooth音声用 - S/PDIF出力 - 8バンドEQ、クロスオーバー、サブウーファーフィルター、エコーキャンセリングのオーディオプロセッシング(Android上でHiFi4 DSPおよびそのソフトウェアフレームワークが使用可能かご確認ください) コネクティビティとI/O - 3 × USB 2.0(1つのOTG)で電話プロジェクション、プレスリリース、製品ニュース、アクセサリ用 - Wi-Fi/Bluetoothモジュール用のSDIO(2.4/5 GHz、BT 5.0デュアル接続) - 5 × UART(車載インターフェースボックス、アクセサリ、BT HCI、GNSS、DEBUG) - 3 × I2C、1 × SPI、2+ SAR-ADCチャネル、3× PWM、~20 GPIO - オプション:4G LTE(統合型またはUSB/PCIeモジュール経由) アプリケーションの機能(プラットフォーム上で利用可能なまたはライセンス可能なソフトウェアを記載してください) - Apple CarPlayおよびAndroid 車載(有線/無線)、電話ミラーリング - 360°サラウンドビュー(AVM)ライブラリ - オーディオDSP/効果音パッケージ 情報提供 1. 上記の各部品が当社の要件および推奨する部分に適合していること 2. データシート、ハードウェアデザインガイド、参照回路図および推奨PMIC/メモリ 3. Android BSP:利用可能なバージョン(AOSPおよびAndroid オートモーティブ)、カーネルバージョン、ロードマップ、ソースの入手可能性、および提供方法(公開ダウンロード、NDA、ライセンス契約) 4. SDKsのライセンス料やユニットごとのロイヤリティ(HiFi4 DSPソフトウェアを含む) 5. 評価キット/SOMの入手可能性、価格およびリードタイム 6. SoC(またはSOM)のユニット価格(年間10K、50K、100Kユニット)、さらにMOQおよびリードタイム 7. 製品の耐久性/供給コミットメント 8. 技術サポートモデルおよびインドにおけるデザインパートナーまたは代理店 よろしくお願いします。 よろしくお願いします、 四条門トーマス Re: i.MX for Android car head unit – suitability, BSP こんにちは、 記載された要件に基づくと、 i.MX 95とi.MX 8QuadMaxを候補として挙げます。最適な選択は主にカメラ/映像性能かHiFi4/オーディオ・自動車ソフトウェアの成熟度のどちらが優先度が高いかによります。 i.MX95 i.MX 95は、カメラおよびビデオ撮影のワークロードにおいて最も有力な候補である。提供するもの： 最大6つのCortex-A55アプリケーションコア 4K H.264/H.265ビデオのエンコードとデコード 複数の1080pストリームと最大8台のカメラをMIPI仮想チャネル経由でサポートするISP 2つの4レーンMIPI-CSIインターフェース、LVDSディスプレイサポート、MIPI-DSIディスプレイサポート 複数のUARTおよびI2Cインターフェース、ADC入力、15レーンI2S/TDM、S/PDIF オートモーティブおよび拡張インダストリアル用の温度オプション これにより、選択されたデコーダーが対応するCSI-2/V4L2またはAndroidカメラインターフェースを通じてストリームを露出すれば、4チャネルAHDデコーダー、CVBSデコーダー入力、サラウンドビュープロセッシング、マルチストリーム録画に適しています。 選択する前に確認すべき点： 正確なAHD/CVBSデコーダーとAndroidカメラまたはEVSドライバのサポート カメラ構成が利用可能なレーン帯域幅内でCSI仮想チャネルを使用しているかどうか MIPI-DSIがディスプレイに選択された場合、MIPI-CSI/DSI多重化が行われます。LVDSを使用すると、より多くのCSIリソースが利用可能になる可能性があります。 プロセッサのドキュメントには2つのタイマー/PWMブロックが記載されているため、3つのPWM出力の要件があります HiFi4 DSPの利用可能性。i.MX 95のドキュメントにはHiFi4 DSPが記載されていないため、オーディオアルゴリズムはアプリケーションコアやリアルタイムコア、または外部オーディオDSP上で動作する必要がある場合があります 製品情報: i.MX 95 i.MX8QM i.MX 8QuadMaxは、自動車認証、HiFi4オーディオプロセッシング、ペリフェラルカバレッジ、Android オートモーティブのイネーブルメントが主な優先事項である場合により適しています。提供するもの： Cortex-A72 2基とCortex-A53アプリケーションコア4基、さらにCortex-M4Fコア 2基 オートモーティブAEC-Q100対応ご注文オプション ハードウェアビデオ、グラフィックス、カメラプロセッシング、複数のカメラ入力に対応しています HiFi4 DSP、複数のSAI/ESAIインターフェース、そしてマルチチャネルオーディオデザイン用のS/PDIF対応 車載インターフェース要件を満たすために十分なUART、I2C、SPI、PWM、ADCリソース NXP Android オートモーティブの i.MX 8QuadMax MEKサポート 主なトレードオフは、i.MX 95よりも古いアーキテクチャであるため、利用可能なビデオプロセッシングやCPUの余裕は、4カメラ、CVBS、サラウンドビュー、録画の全負荷と合わせて測定されるべきだということです。カメラのデコーダー、同時配信数、Androidカメラとの連携も確認する必要があります。 製品情報: i.MX 8アプリケーションプロセッサ i.MX8MPlus i.MX 8M Plusは、HiFi4、LVDS/MIPI-DSI、2つのMIPI-CSIインターフェース、1080pクラスのH.264/H.265ビデオサポートを含むため、インダストリアルマルチメディアデザインに魅力的です。しかし、4つのCortex-A53コアを搭載しており、オートモーティブではなく、インダストリアルの認証で、CSIカメラインターフェースは2つだけです。したがって、i.MX 95やi.MX 8QuadMaxに比べて、完全なマルチカメラヘッドユニットの要件には適していません。 製品情報: i.MX 8M Plus i.MX8QXP i.MX 8QuadXPlusは、4つのCortex-A35コアと1つのCortex-M4Fコアを備え、マルチメディア、ディスプレイ、カメラ、HiFi4機能を備えています。しかし、そのCPU性能は要求されたクラスを下回っている。また、i.MX 8QuadMaxや i.MX 95と比べて現在のAndroid Automotiveプラットフォームとしては推奨されていません。 Android BSP NXPの公開Android BSPページでは、現在 i.MX 8M Plus、i.MX 8QuadMax/8QuadXPlus、i.MX 95の評価プラットフォームに対するAndroid 16サポートが掲載されています。ビルドソースパッケージやドキュメントはNXPソフトウェアポータルを通じて提供されています。選択したリリースについて、正確なソースコードとバイナリの提供範囲、ライセンス条項、および製品版の再配布権を確認する必要があります。 現在公開されているAndroid オートモーティブの資料は、i.MX 8QuadMaxおよび i.MX 95プラットフォームに焦点を当てています。Android オートモーティブのサポートは、Android 車載の電話プロジェクションとは区別されるべきです。 i.MX アプリケーションプロセッサ向けAndroid BSP Android オートモーティブ BSP for i.MXアプリケーション・プロセッサ Apple CarPlay、Android 車載の電話プロジェクション、ワイヤレス・コネクティビティ、AVM/サラウンドビューライブラリ、オーディオエフェクトパッケージ、HiFi4ソフトウェアフレームワークは、別途認証、パートナーソフトウェア、プロフェッショナルサービス、または商用ライセンスを必要とする場合があります。SoCが必要なハードウェアインターフェースをサポートしているからといって、それらが含まれていると考えるべきではありません。 要約すると、選考プロセスは以下のようになります。 HiFi4、自動車資格、オーディオI/O、PWMリソース、確立されたAndroid オートモーティブの経路が主な判断要素であれば、8QuadMax i.MX 選択してください。 カメラ/映像性能、FUTUREのプロセッシング余裕、仮想チャネルカメラのサポートがより重要で、外部オーディオDSPやソフトウェアオーディオ実装が許容される場合は i.MX 95を選択してください。 カメラ数、性能、オートモーティブ要件が減った場合 i.MX、8M Plusと i.MX 8QuadXPlusは副次オプションとして残しておくのが良いでしょう。 よろしくお願いいたします。 アルド。