私の現在の運転免許証は、あと6日で期限切れになります。延長申請をしたいと思います。 私の現在の運転免許証は、あと6日で期限切れになります。延長申請をしたいと思います。

从用户空间读取安全启动生命周期 如何在 imx8dxp 中从用户空间读取生命周期寄存器。有什么驱动程序可以使用吗？ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Secure-boot life cycle reading from userspace 你好@Ajaybajpai980 目前，电路板支持包。中没有这样的驱动程序。 此致， 志明

周辺DMA TCD「START」フィールド S32Z2リファレンスマニュアルのバージョン5は1399ページの1に記載しています。 「1. ユーザーがTCDn_CSR[START]フィールドに書き込み、チャネルサービスをリクエストする。」 同じ文書の1354ページにあるTCD CSRのメモリマップには、「START」という名前のCSRのフィールドは表示されていません。TCDn_CSRのどのビットがSTARTビットですか？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] であることを示しています。 これで、登録簿マップと詳細な登録簿の説明との間の明らかな違いが明確になったことを願います。 よろしくお願いします、 アルド。 Re: Peripheral DMA TCD "START" FIELD ああ、なるほど。ご説明ありがとうございます。

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.

外围设备 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] 。 我希望这能澄清登记册地图和详细登记册描述之间的明显区别。 此致， 阿尔多。 Re: Peripheral DMA TCD "START" FIELD 啊，明白了。谢谢你的解释。

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 Re: ST25R500 Library Integration with NXP MWCT2016S こんにちは、VaneBさん。 ご意見をお寄せいただきありがとうございます。 初期設定を完了し、STファイルをNXPのソフトウェアパッケージに統合しました。 しかし、ST25R500のIRQ信号に対するGPIO割り込みの設定と実装について、ガイダンスが必要です。 添付のスクリーンショットに示すように、 PTA18（EIRQ0）の初期設定の一部を完了しました。 しかし、割り込みが正しくトリガーされ処理されるよう、必要な構成やアプリケーションレベルの実装についてさらに指導が必要です。 現在の設定を確認し、 GPIO割り込みを適切に有効化・処理するための手順を教えていただけませんか? 皆さんのサポートをいただけると大変ありがたいです。 BR、 ラキー Re: ST25R500 Library Integration with NXP MWCT2016S こんにちは、 @rakYps21さん 設定は問題なさそうです。 SIUL2外部割り込みについては、 AUTOSARなしのS32K3 RTDを使ったThread SIUL2外部割り込みの例プロジェクトを確認することをお勧めします。この問題への対処方法について、より詳しく説明されています。例では古いRTDバージョンが使われていますが、基本的な考え方や構成方法は同じです。 また、RTDパッケージには異なるS32K3バリアントの Siul2_Icu_Ip_BlinkLed_S32K3xx 例が含まれています。これらの例はGPIOを外部割り込みとして構成するため、参照として非常に役立ちます。 これら2つの資料は、外部割り込みの仕組みと設定方法をより深く理解するための良い出発点となるでしょう。

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)ワイヤレス接続パワープロファイルツール よろしくお願いいたします。 リカルド

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 电压。 顺祝商祺！ 刘梅 Re: 24MHz clock issue RT1052 1)上电期间，VDD_SNVS_IN、VDD_HIGH_IN、DCDC_IN、DCDC_PSWITCH 和 POR_B 均被触发。这些信号正确，且顺序正确： 黄色：VDD_SNVS_IN。 绿色：VDD_HIGH_IN 和 DCDC_IN 红色：VDD_SOC 蓝色：POR DCDC_PSWITCH 和 VDD_SOC。DCDC_IN 稳定后 30 毫秒启用 PSWITCH。 2) 我使用 CL = 7 pF 和 stray = 3 pF 重新计算了电容。 负载电容设置为 8.2 pF，但示波器上仍然看不到振荡。 3) 我无法直接测量 NVCC_PLL 引脚，因为它位于 BGA 封装之下。但是，它直接连接到 VDD_HIGH 和 DCDC_IN。关于使用外部时钟源的问题：是否应该将其注入到 XTALI 引脚，而不是 XTALO 引脚？ 我还能怎么办呢？ 谢谢你的想法。   Re: 24MHz clock issue RT1052 这很令人困惑，因为 NVCC_PLL 与其他 NVCC_x 端口的名称相同。最好将其命名为 NVCC_PLL_CAP Re: 24MHz clock issue RT1052 嗨@JBA ， 感谢您提供的最新信息。 关于您提出的“关于使用外部时钟源的问题：是否应该将其注入到 XTALI 引脚，而不是 XTALO 引脚？”这个问题 我指的是 RT1050 数据手册中描述的配置：外部 24 MHz 振荡器驱动 XTALO，XTALI 上有一个 18 pF 电容。所施加的时钟电平不得超过 NVCC_PLL。 我还想澄清一下您所说的“NVCC_PLL 直接连接到 VDD_HIGH 和 DCDC_IN”。你的意思是说 NVCC_PLL、VDD_HIGH_IN 和 DCDC_IN 都连接到同一个 3.3V PCB 网络吗？请检查原理图或PCB网络连接以确认这一点。NVCC_PLL 是内部 LDO_1P1 的约 1.1 V 输出，而 VDD_HIGH_IN 和 DCDC_IN 是电源输入。如果 NVCC_PLL 直接连接到 3.3V 电源，则在进行进一步的振荡器测试之前，需要纠正此连接。 顺祝商祺！ 可能 Re: 24MHz clock issue RT1052 嗨，May， 我们还发现了 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のクロックに関する説明も参考になるかもしれません。 よろしくお願いいたします。 アルド。 Re: i.MX7D UART5 in DTE mode using I2C4 こんにちは、 TXDCは、TX FIFOとシフトレジスタが空であることを示します。文字送信後にUSR2[TXDC]が1になるかどうか確認してください。値が0のままの場合は、送信前後のUTS、USR1、USR2の値と、UART5のTXピン波形も併せて取得してください。 2線式構成の場合は、ハードウェアCTS/RTSフロー制御が無効になっていることも確認してください。対応する信号が接続されていない状態でCTS/RTSを有効にしている場合、トランスミッタはブロックされたままになることがあります。また、選択したパッドを駆動しているI2C4やSAI1ペリフェラルが有効でないかも確認してください。 よろしくお願いいたします。 アルド。 Re: i.MX7D UART5 in DTE mode using I2C4 こんにちは、AldoGさん。 DTEモードによる混乱を避けるため、基板の配線を変更してDCEモードに設定しました。 U-Bootでの初期化後、IOMUXCのプルアップ/プルダウン設定を切り替えながら、オシロスコープを使用してピン電圧レベルを監視しました。 入力ピンはこれらの設定変更に正しく反応しました。 次に、UART5_UFCRレジスタのDTEビットを設定してテストを繰り返したところ、入力ピンは再び設定変更に正しく反応しました。 出力ピンはDCE/DTE構成に応じてスイッチし、いずれの場合も電圧レベルは「1」となります。 したがって、PADの設定は正しい。 UART5_UCR2レジスタのIRTSビットが「1」に設定されているため、RTS信号は無視する必要があります。 この問題を解決するために次に何を調査すべきか、具体的かつ詳細なサポートをいただけませんか? よろしくお願いいたします。 Re: i.MX7D UART5 in DTE mode using I2C4 こんにちは、AldoGさん。 問題は解決しました。 2線式DCEモードから3線式DTEモードに切り替えました。 使用されるピンは、I2C3_SCL、I2C4_SCL、およびI2C4_SDAです。 クロックはCCMを通じて「/arch/arm/mach-imx/mx7/clock.c'で設定されます。`init_clk_uart()` 関数内。 ピン配置は以下のとおりです。 static iomux_v3_cfg_t const uart5_pads[] = { MX7D_PAD_I2C3_SCL__UART5_DTE_RTS | MUX_PAD_CTRL(UART_PAD_CTRL) MX7D_PAD_I2C4_SCL__UART5_DTE_TX | MUX_PAD_CTRL(UART_PAD_CTRL) MX7D_PAD_I2C4_SDA__UART5_DTE_RX | MUX_PAD_CTRL(UART_PAD_CTRL) }; imx_iomux_v3_setup_multiple_pads(uart5_pads, ARRAY_SIZE(uart5_pads)); writel(readl(0x30330158) | 0x10, 0x30330158); writel(readl(0x30330160) | 0x10, 0x30330160); writel(readl(0x30330164) | 0x10, 0x30330164); writel(0, 0x30330710); writel(0, 0x30330714); 次に、`serial_mx.c` を使用してシリアル初期化とボーレート設定を行います。参考として。 ただし、UCR2レジスタは次のように構成されます。writel(UCR2_WS | UCR2_TXEN | UCR2_RXEN | UCR2_SRST, &base->cr2); これはうまくいった。

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 不支持干冰和主动防篡改功能 顺祝商祺！

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電圧を超えないようにしてください。 よろしくお願いいたします。 メイ・リウ Re: 24MHz clock issue RT1052 1)電源投入時のVDD_SNVS_IN、VDD_HIGH_IN、DCDC_IN、DCDC_PSWITCH、およびPOR_B。これらは正しく、正しい順序で表示されます。 黄色: VDD_SNVS_IN。 緑色：VDD_HIGH_INとDCDC_IN 赤色: VDD_SOC 青: POR DCDC_PSWITCHとVDD_SOC。PSWITCHは、DCDC_INが安定してから30ミリ秒後に有効になります。 2) CL = 7 pF、stray = 3 pF を使用してコンデンサを再計算しました。 負荷コンデンサは8.2pFに設定されていますが、オシロスコープには依然として発振が見られません。 3) NVCC_PLLピンはBGAパッケージの下にあるため、直接測定できません。しかし、それはVDD_HIGHとDCDC_INに直接コネクテッドされています。外部クロックソースの使用に関する質問です。XTALOピンではなく、XTALIピンにクロックを注入すべきではないでしょうか？ 他に何ができたでしょうか? ご意見ありがとうございます。   Re: 24MHz clock issue RT1052 こんにちは、メイさん。 NVCC_PLLに関する問題も発見しました。接続を解除したところ、発振器が正常に動作するようになりました。サポートありがとうございます。 Re: 24MHz clock issue RT1052 こんにちは、 @JBA さん。 最新情報をありがとうございます。 「外部クロックソースの使用に関する質問：XTALOピンではなくXTALIピンに注入すべきではないでしょうか？」というご質問について。 私が言及していたのはRT1050のデータシートに記載されている構成です:外部24MHzの発振器ドライブXTALOに、XTALIに18pFのコンデンサを搭載しています。印加されるクロックレベルはNVCC_PLLを超えてはならない。 また、NVCC_PLLが「VDD_HIGHとDCDC_INに直接コネクテッドしている」というあなたの主張についても明確にしたいと思います。つまり、NVCC_PLL、VDD_HIGH_IN、DCDC_INがすべて同じ3.3VのPCBネットにコネクテッドされているということですか?回路図または基板上のネット接続を確認して、この点を確認してください。NVCC_PLLは内部LDO_1P1の約1.1Vの出力であり、VDD_HIGH_INとDCDC_INは電源入力です。NVCC_PLLが3.3V電源に直接接続されている場合は、発振器のテストを進める前にこの接続を修正する必要があります。 よろしくお願いいたします。 5月 Re: 24MHz clock issue RT1052 NVCC_PLLは他のNVCC_xポートと同じ名前なので、非常に紛らわしい。NVCC_PLL_CAPと呼ぶ方が良いでしょう

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

[88W8997] WLAN RFテスト こんにちは、 Toradex imx8mp SOMに搭載されている88W8997モジュールについて、WIFI/BTの規制適合性試験を実施したいと考えています。 私たちはここに記載されている手順に従っています： https://www.nxp.com/docs/en/application-note/AN14114.pdf ドライバ作成については、UM11675ドキュメントに従っていました。そこには https://github.com/nxp-imx/mwifiex (ドライバ)そして https://github.com/nxp-imx/imx-firmware (関連するファームウェアパッケージ) ドライバとファームウェアをデバイスにビルドしてインストールし、RFテストモードに入ろうとしました。前述のドライバは、/proc/mwlan/adapter0インターフェースを使う可能性を提供しており、Echoの「rf_test_mode=1」>/proc/mwlan/adapter0/configコマンドでテストモードにスイッチしようとしました。 残念ながら、ドライバのプリントはRFテストモードを設定できませんでした。なぜテストモードに直接切り替えられないのでしょうか? さらに調べたところ、drv_modeを2(drv_mode=2 >設定)に変更すると、「rf_test_mode=1」コマンドでテストモードに切り替えられることがわかりました。これは正しいですか？デフォルトのdrv_mode値（デフォルト：drv_mode=7）でモードに入ることは可能ではないでしょうか？ しかし、私は記述したコマンドを入力した文書の作成を続けました。 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 エコー「チャンネル=」+str(チャネル)) 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 -1 -1 {MAC_ADDRESS}" > /proc/mwlan/adapter0/config スペクトラムアナライザーで結果を確認しても、変化は見られません。テストモードが正常に動作しているかどうかを確認する別の方法はありますか？ もう一つ奇妙な点は、tx_frameで設定しているにもかかわらず、MACアドレスが常に00:00:00:00:00と表示されることです。 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 バンド=0 BW=0 チャネル= radio_mode[0]= radio_mode[1]= 総処方PKT数=0 RXマルチキャスト/ブロードキャストのPKTカウント=0 rx FCSエラー PKTカウント=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 その他の注記： どこかで読んだのですが、メーカー純正のファームウェアを使用する必要があるそうです。このファームウェアを /lib/firmware/nxp に追加し、wifi_mod_para.conf ファイルを修正し(fw_nameを製造ファームウェアに置き換え、SD8997セクションにmfg_mode=1を追加)、ドライバを再読み込み(rmmod moal.ko;insmod moal.komod_para=nxp/wifi_mod_para.conf。ドライバはファームウェアがすでに動作していることを印刷します。echo "fw_reload=1" > /proc/mwlan/adapterX/config を使うと、ドライバが FW 失敗のダウンロードを印刷します。その場合、再起動が必要です。 手伝ってもらえますか? よろしくお願いします。 Re: [88W8997] WLAN RF Test @sportzfy Toradex imx8mp SOMに搭載されている88W8997モジュールのWIFI/BT規制準拠テストを実施したいと考えています。 私たちはここに記載されている手順に従っています： https://www.nxp.com/docs/en/application-note/AN14114.pdf ドライバ作成については、UM11675ドキュメントに従っていました。そこには https://github.com/nxp-imx/mwifiex(ドライバ)そして https://github.com/nxp-imx/imx-firmware(関連するファームウェアパッケージ) ドライバとファームウェアをデバイスにビルドしてインストールし、RFテストモードに入ろうとしました。前述のドライバは、/proc/mwlan/adapter0インターフェースを使う可能性を提供しており、Echoの「rf_test_mode=1」>/proc/mwlan/adapter0/configコマンドでテストモードに切り替えようとしました。 残念ながら、ドライバのプリントはRFテストモードを設定できませんでした。なぜテストモードに直接切り替えられないのでしょうか? さらに調べたところ、drv_modeを2(drv_mode=2 >設定)に変更すると、「rf_test_mode=1」コマンドでテストモードに切り替えられることがわかりました。これは正しいですか？デフォルトのdrv_mode値（デフォルト：drv_mode=7）でモードに入ることは可能ではないでしょうか？ しかし、私は記述したコマンドを入力した文書の作成を続けました。 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 エコー「チャンネル=」+str(チャネル)) 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 -1 -1 {MAC_ADDRESS}" > /proc/mwlan/adapter0/config スペクトラムアナライザーで結果を確認しても、変化は見られません。テストモードが正常に動作しているかどうかを確認する別の方法はありますか？ もう一つ奇妙なのは、MAC アドレスが tx_frame で設定しているにもかかわらず、常に 00:00:00:00:00 と表示されることです。 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 バンド=0 BW=0 チャネル= radio_mode[0]= radio_mode[1]= 総処方PKT数=0 RXマルチキャスト/ブロードキャストのPKTカウント=0 rx FCSエラー PKTカウント=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 その他の注記： どこかで読んだのですが、メーカー純正のファームウェアを使用する必要があるそうです。このファームウェアを /lib/firmware/nxp に追加し、wifi_mod_para.conf ファイルを修正し(fw_nameを製造ファームウェアに置き換え、SD8997セクションにmfg_mode=1を追加)、ドライバを再読み込み(rmmod moal.ko;insmod moal.ko mod_para=nxp/wifi_mod_para.conf。ドライバはファームウェアがすでに動作していることを印刷します。echo "fw_reload=1" > /proc/mwlan/adapterX/config を使うと、ドライバが FW 失敗のダウンロードを印刷します。その場合、再起動が必要です。 手伝ってもらえますか? 88W8997に対して、正しい製造ファームウェアとmfg_mode=1の設定が有効になっているかどうか確認してみましたか？また、ドライバーバージョンに対応しているサポートdrv_modeやRFテストコマンドも確認してください。 Re: [88W8997] WLAN RF Test こんにちは、 私たちは現在、toradex wifi レイヤー ( https://github.com/toradex/meta-toradex-wifi/tree/kirkstone-6.xy ) を使用し、統合された labtool ユーティリティを利用しています。さらに、公式画像ではなく、Toradexの参考画像を使用しました。この設定で今はうまく動作しているようです。 ありがとうございます。 Re: [88W8997] WLAN RF Test こんにちは、@joschi2804さん さらに調べたところ、drv_modeを2(drv_mode=2 >設定)に変更すると、「rf_test_mode=1」コマンドでテストモードに切り替えられることがわかりました。これは正しいですか？デフォルトのdrv_mode値（デフォルト：drv_mode=7）でモードに入ることは可能ではないでしょうか？ --> drv_mode = 1;3;7で問題ありませんが、mlan0インターフェースを有効にすることを必ず確認してください。 スペクトラムアナライザーで結果を確認しても、変化は見られません。テストモードが正常に動作しているかどうかを確認する別の方法はありますか？ --> tx_frame = 1の後に「cat /proc/mwlan/adapter0/config」の出力を共有してもらえますか?すべてのパラメータが正しく設定されているか確認してください。スペクトラム出力も私たちに共有しても構いません。また、スペクトラムの設定もしっかりしてください。 どこかで読んだのですが、メーカー純正のファームウェアを使用する必要があるそうです。このファームウェアを /lib/firmware/nxp に追加し、wifi_mod_para.conf ファイルを修正し(fw_nameを製造ファームウェアに置き換え、SD8997セクションにmfg_mode=1を追加)、ドライバを再読み込み(rmmod moal.ko;insmod moal.komod_para=nxp/wifi_mod_para.conf。ドライバはファームウェアがすでに動作していることを印刷します。echo "fw_reload=1" > /proc/mwlan/adapterX/config を使うと、ドライバが FW 失敗のダウンロードを印刷します。その場合、再起動が必要です。 -->--これはRFテストの別の方法>、 UM11675のみ 参照してください。 Re: [88W8997] WLAN RF Test こんにちは、 私はこのリポジトリの最新ブランチを使用しています。https ://github.com/nxp-imx/imx-firmware/tree/lf-6.6.3_1.0.0/nxp/FwImage_8997_SD wifi_mod_param.conf ファイルは、sdiouart8997_combo_v4.bin ファームウェアを参照しています。 Re: [88W8997] WLAN RF Test こんにちは、@joschi2804さん ドライバとファームウェアのバージョンを教えてもらえますか? よろしくお願いいたします。 ショーン

使用计算器 1_4 计算 KW45 函数的发射输出功率在 -15、-10、-5、-2 dBm 时的功耗 你好， 在 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 你好， 希望你一切都好。Tx 与我们KW45B（无线电）和 KW45Z（MCU）数据表中所示的典型值相符。 此外，我建议您参考我们的主帖，了解我们所有的配置文件工具： Kinetis（KW3x/4x、MCX W7x 和 MCX W23）无线连接功率我的工具 顺祝商祺！ 里卡多

[88W8997] WLAN射频测试 你好， 我们希望对组装在 Toradex imx8mp SOM 上的 88W8997 模块进行 WIFI/BT 监管合规性测试。 我们正在按照此处的说明进行操作： https://www.nxp.com/docs/en/application-note/AN14114.pdf 构建驱动程序时，我们遵循了 UM11675 文档，其中提到了https://github.com/nxp-imx/mwifiex（驱动程序）和https://github.com/nxp-imx/imx-firmware（相关固件包）。 我在设备上构建并安装了驱动程序和固件，并尝试进入射频测试模式。上述驱动程序现在允许我使用 /proc/mwlan/adapter0 接口，我尝试使用 echo "rf_test_mode=1" > /proc/mwlan/adapter0/config 命令切换到测试模式。 很遗憾，驱动程序显示“无法设置射频测试模式”。为什么不能直接切换到测试模式？ 经过进一步调查，我发现如果我将 drv_mode 更改为 2（drv_mode=2 > 配置），则可以使用“rf_test_mode=1”命令切换到测试模式。这样对吗？是否可以使用默认的 drv_mode 值（默认值：drv_mode=7）进入该模式？ 但是，我继续在文档中输入了上述命令： 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 当我查看频谱分析仪的结果时，没有发现任何变化。还有其他方法可以检查测试模式是否正常工作吗？ 还有一点很奇怪，即使我用 tx_frame 设置了 MAC 地址，它始终显示为 00:00:00:00:00。 硬件状态=0 netlink_num=31 驱动模式=2 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 接收天线=1 band=0 bw=0 频道= radio_mode[0]= radio_mode[1]= 总处方药包数=0 接收多播/广播数据包计数=0 接收函数调用错误数据包计数=0 发射功率= tx_continuous=0 tx_frame=0 he_tb_tx=0 触发帧=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 antcfg=0x3 0x3 补充说明： 我之前看到过，必须使用厂商提供的固件。当我将此固件添加到 /lib/firmware/nxp 时，修改了 wifi_mod_para.conf 文件（将 fw_name 替换为制造商固件，并在 SD8997 部分添加了 mfg_mode=1），然后重新加载了驱动程序（rmmod moal.ko；insmod moal.komod_para=nxp/wifi_mod_para.conf。驱动程序显示固件已经在运行。当我使用 echo "fw_reload=1" > /proc/mwlan/adapterX/config 时，驱动程序打印出固件下载失败的信息。然后需要重启电脑。 你能帮帮我吗？ 谢谢！ Re: [88W8997] WLAN RF Test @sportzfy我们想对组装在 Toradex imx8mp SOM 上的 88W8997 模块进行 WIFI/BT 监管合规性测试。 我们正在按照此处的说明进行操作： https://www.nxp.com/docs/en/application-note/AN14114.pdf 构建驱动程序时，我们遵循了 UM11675 文档，其中提到了https://github.com/nxp-imx/mwifiex（驱动程序）和https://github.com/nxp-imx/imx-firmware（相关固件包）。 我在设备上构建并安装了驱动程序和固件，并尝试进入射频测试模式。上述驱动程序现在使我能够使用 /proc/mwlan/adapter0 接口，我尝试使用 echo "rf_test_mode=1" > /proc/mwlan/adapter0/config" 命令切换到测试模式。 很遗憾，驱动程序显示“无法设置射频测试模式”。为什么不能直接切换到测试模式？ 经过进一步调查，我发现如果我将 drv_mode 更改为 2（drv_mode=2 > 配置），则可以使用“rf_test_mode=1”命令切换到测试模式。这样对吗？是否可以使用默认的 drv_mode 值（默认值：drv_mode=7）进入该模式？ 但是，我继续在文档中输入了上述命令： 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 当我查看频谱分析仪的结果时，没有发现任何变化。还有其他方法可以检查测试模式是否正常工作吗？ 还有一件奇怪的事，即使我使用 tx_frame 设置了 MAC 地址，它仍然始终显示为 00:00:00:00:00。 硬件状态=0 netlink_num=31 驱动模式=2 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 接收天线=1 band=0 bw=0 频道= radio_mode[0]= radio_mode[1]= 总处方药包数=0 接收多播/广播数据包计数=0 接收函数调用错误数据包计数=0 发射功率= tx_continuous=0 tx_frame=0 he_tb_tx=0 触发帧=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 antcfg=0x3 0x3 补充说明： 我之前看到过，必须使用厂商提供的固件。当我将此固件添加到 /lib/firmware/nxp 时，修改了 wifi_mod_para.conf 文件（将 fw_name 替换为制造商固件，并在 SD8997 部分添加了 mfg_mode=1），然后重新加载了驱动程序（rmmod moal.ko；insmod moal.ko mod_para=nxp/wifi_mod_para.conf。驱动程序显示固件已经在运行。当我使用 echo "fw_reload=1" > /proc/mwlan/adapterX/config 时，驱动程序打印出固件下载失败的信息。然后需要重启电脑。 你能帮帮我吗？ 您是否检查过 88W8997 是否启用了正确的制造固件和 mfg_mode=1 设置？我还会验证您的驱动程序版本支持的 drv_mode 和 RF 测试命令。 Re: [88W8997] WLAN RF Test 你好， 我们现在使用的是 toradex wifi 层（ https://github.com/toradex/meta-toradex-wifi/tree/kirkstone-6.xy ），并利用了集成的 labtool 实用程序。此外，我们使用了 toradex 参考图像而不是我们官方的图像。这样设置后，现在似乎可以正常工作了。 谢谢。 Re: [88W8997] WLAN RF Test 你好@joschi2804 经过进一步调查，我发现如果我将 drv_mode 更改为 2（drv_mode=2 > 配置），则可以使用“rf_test_mode=1”命令切换到测试模式。这样对吗？是否可以使用默认的 drv_mode 值（默认值：drv_mode=7）进入该模式？ --> drv_mode = 1;3;7 没问题，只需确保 mlan0 接口已启用即可。 当我查看频谱分析仪的结果时，没有发现任何变化。还有其他方法可以检查测试模式是否正常工作吗？ --> 能否分享一下在 tx_frame = 1 之后运行“cat /proc/mwlan/adapter0/config”命令的输出结果？请确保所有参数配置正确。您也可以同时分享频谱输出结果。此外，请确保频谱配置正确。 我之前看到过，必须使用厂商提供的固件。当我将此固件添加到 /lib/firmware/nxp 时，修改了 wifi_mod_para.conf 文件（将 fw_name 替换为制造商固件，并在 SD8997 部分添加了 mfg_mode=1），然后重新加载了驱动程序（rmmod moal.ko；insmod moal.komod_para=nxp/wifi_mod_para.conf。驱动程序显示固件已经在运行。当我使用 echo "fw_reload=1" > /proc/mwlan/adapterX/config 时，驱动程序打印出固件下载失败的信息。然后需要重启电脑。 --> 这是射频测试的另一种方法，请仅参考 UM11675。 Re: [88W8997] WLAN RF Test 你好， 我正在使用此仓库的最新分支。https ://github.com/nxp-imx/imx-firmware/tree/lf-6.6.3_1.0.0/nxp/FwImage_8997_SD wifi_mod_param.conf 文件指的是 sdiouart8997_combo_v4.bin 固件。 Re: [88W8997] WLAN RF Test 你好@joschi2804 能否提供一下驱动程序和固件版本？ 顺祝商祺！ 肖恩

i.MX7D UART5 in DTE mode using I2C4 Hi. This is the original i.MX7D board. The 2-wire UART5 circuit uses the I2C4 port. This UART5 is in DTE mode. I am configuring the CCM, IOMUXC ports, IOMUXC DAISY settings, and 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 After sending one character, UART5_UTS remains at 0x20 (having changed from 0x60). I do not know why UART5_UTS does not return to 0x60. Best Regards. Re: i.MX7D UART5 in DTE mode using I2C4 Spoiler (Highlight to read)     Hi. AldoG. There was an error in a portion of the information I sent. UART5_CLK_ROOT(0x30380b18)=0x10000000 The correct version is as follows. UART5_CLK_ROOT(0x3038b180)=0x10000000 Best regards. Re: i.MX7D UART5 in DTE mode using I2C4 Hi. AldoG. Upon startup, for some reason IPG_CLK_ROOT (0x30389080) was set to 0x1, so I changed it to 0x0. UART5_CLK_ROOT(0x30380b18)=0x10000000 UART5_CCM_CCGR=CCM_CCGR152(0x30384980)=0x3 It has been set up this way. I tried changing the pins used from I2C4 to SAI1, but the result was unsuccessful. I set the register to be checked to TXDC within USR2. Best regards. Re: i.MX7D UART5 in DTE mode using I2C4 Hello, For the i.MX7D UART status register, UTS[6] is the TX FIFO empty indication and UTS[5] is the RX FIFO empty indication. Therefore, 0x60 indicates that both FIFOs are empty, while 0x20 indicates that the RX FIFO is empty but the TX FIFO is not yet empty. Seeing 0x20 immediately after writing a character can therefore be expected. UTS[6] only reflects the FIFO state. If you need to determine when the character has completely finished transmitting, check USR2[TXDC], which indicates that the transmit FIFO and shift register are empty. For this two-wire configuration, please also verify the following: Hardware CTS/RTS flow control is disabled. If CTS/RTS is enabled without the corresponding signals being connected, transmission may be prevented. Both the UART5 functional clock and the IPG clock are enabled, and the UBIR/UBMR values are calculated using the actual UART5 clock frequency. The DTE pin mapping is checked against the i.MX7D Reference Manual. DTE mode changes the apparent RX/TX pin direction, so the signal names can be confusing. The I2C4 peripheral is not also enabled or driving the same pads. The UART5 TX pin is probed with an oscilloscope or logic analyzer. If a valid waveform is present, the 0x20 reading is likely only a status-sampling issue. If no waveform is present, check the clock, flow-control, and pin-mux configuration first. Please refer to the i.MX 7Dual Reference Manual (IMX7DRM), especially the UART and IOMUX sections. The NXP discussions iMX7 UART pin setup and i.MX7 IPG_CLK_ROOT and UART's clock may also be useful. Best regards/Saludos, Aldo. Re: i.MX7D UART5 in DTE mode using I2C4 Hello, TXDC indicates that the TX FIFO and shift register are empty. Please check whether USR2[TXDC] becomes 1 after the character is sent. If it remains 0, please also capture the UTS, USR1, and USR2 values before and after transmission, together with the UART5 TX pin waveform. For the two-wire configuration, please also verify that hardware CTS/RTS flow control is disabled. If CTS/RTS is enabled without the corresponding signals being connected, the transmitter may remain blocked. Also confirm that no I2C4 or SAI1 peripheral remains enabled and driving the selected pads. Best regards/Saludos, Aldo. Re: i.MX7D UART5 in DTE mode using I2C4 Hi AldoG, To avoid confusion caused by DTE mode, I modified the board wiring to set it to DCE mode. After initialization in U-Boot, I used an oscilloscope to monitor the pin voltage levels while toggling the IOMUXC pull-up/pull-down settings. The input pins responded correctly to these configuration changes. Next, I set the DTE bit in the UART5_UFCR register and repeated the test; the input pins again responded correctly to the configuration changes. The output pins switch according to the DCE/DTE configuration, and in both cases, the voltage level is '1'. Therefore, the PAD configuration is correct. Since the IRTS bit in the UART5_UCR2 register is set to '1', the RTS signal should be ignored. Could you please provide specific, detailed support on what I should investigate next to resolve this issue? Best regards. Re: i.MX7D UART5 in DTE mode using I2C4 Hi AldoG. The issue has been resolved. I have reverted from the 2-wire DCE mode to the 3-wire DTE mode. The pins used are I2C3_SCL, I2C4_SCL, and I2C4_SDA. The clock is configured via the CCM in `/arch/arm/mach-imx/mx7/clock.c` within the `init_clk_uart()` function. The pin configuration is as follows: static iomux_v3_cfg_t const uart5_pads[] = { MX7D_PAD_I2C3_SCL__UART5_DTE_RTS | MUX_PAD_CTRL(UART_PAD_CTRL), MX7D_PAD_I2C4_SCL__UART5_DTE_TX | MUX_PAD_CTRL(UART_PAD_CTRL), MX7D_PAD_I2C4_SDA__UART5_DTE_RX | MUX_PAD_CTRL(UART_PAD_CTRL), }; imx_iomux_v3_setup_multiple_pads(uart5_pads, ARRAY_SIZE(uart5_pads)); writel(readl(0x30330158) | 0x10, 0x30330158); writel(readl(0x30330160) | 0x10, 0x30330160); writel(readl(0x30330164) | 0x10, 0x30330164); writel(0, 0x30330710); writel(0, 0x30330714); Next, I will proceed with serial initialization and baud rate configuration, using `serial_mx.c` as a reference. However, the UCR2 register will be configured as follows: writel(UCR2_WS | UCR2_TXEN | UCR2_RXEN | UCR2_SRST, &base->cr2); This worked.

RW612 button multiplexed with ISP pin I would like to use a button to make the RW612 boot into ISP mode when power is first applied to the board while the button is pressed. But that button will also be pressed regularly during normal operation. The button is connected to both ISP0 and GPIO24. In the datasheet it is stated that the ISP0 pin will change its function to EXT_REQ when the bootloader starts the code execution from flash. I dont exactly know what happens when the EXT_REQ pin is pulled low during normal operation. What does happen when EXT_REQ is pulled low occasionally during normal operation? Is there a way to disable its function in software, do I have to isolate EXT_REQ from the button after boot or is there nothing I have to worry about? Product: WiFi RW6XX Re: RW612 button multiplexed with ISP pin Hi @Niwo, hope you are doing well. The EXT_REQ pin is used to coexist with an external radio through PTA interface as mentioned in section 6.3 of the RW612 Datasheet. However, please note that as stated in Table 45 of UM11865, GPIO[24] is used by the ROM code for UART ISP interface and such functionality cannot be changed. Therefore I'd suggest to consider another GPIO for your button functionality and isolate the ISP interface. Also, please consider that ISP can be permanently disabled or limited for a final product implementation to enhance security access to the MCU, therefore it is important to keep in mind this feature for your design. Hope this helps! Re: RW612 button multiplexed with ISP pin Thank you @RomanVR for your reply, To clarify my goals regarding the button; The button should also make the MCU wake up from deep sleep and if I understand the user manual correctly, only GPIO[24] and GPIO[25] support this functionality. You mentioned that GPIO[24] is used for UART functionality by the ISP and it cannot be changed. Does this mean that GPIO[24] will always be a UART pin and I can't change that in my own program? Or does it only mean that I cannot modify which pins the ISP uses while it is running, and afterwards I can do whatever I want with these pins? For the EXT_REQ pin I decided that I will use a solder jumper for development purposes and later use IAP software updates instead of connecting it permanently to the button. Best regards Re: RW612 button multiplexed with ISP pin Hi @Niwo, thank you for providing details on your implementation. I apologize if I was not clear before regarding GPIO[24] functionality; the function of this GPIO can be changed in your application. However, from a ROM code perspective the UART functionality is exclusive from GPIO[24] & GPIO[26] and cannot be changed to another Flexcomm instance or GPIOs. Hope this information clears out your doubts.

iMX6ULLの改ざん検知機能 i.MX6ULLプロセッサのアクティブ改ざん検出機能を有効にして、デバイスのエンクロージャーが開いたときに検出したいと思っています。 スイッチがハードウェアに追加され、添付図に示されているように外部タンパーピンに接続されています。 ソフトウェア側で改ざん検知をサポートする例やドキュメントはありますか?この機能の設定方法や操作方法を示す実装例やサンプル関数はありますか？ Re: Tamper detection function in iMX6ULL こんにちは、 i.MX 6ULLの改ざん防止機能はヒューズによって制御されていますが、NXPは現在、i.MX6ULLのすべての量産部品番号においてこの機能を無効にするように設定しています。 いくつかの顧客向け文書では、i.MX 6ULLが外部改ざんをサポートしていると誤って記載されています。ヒューズは i.MX すべての6ULL部品番号でこの機能を無効にするようにプログラムされているため、タンパーピンは現在のドキュメントに記載されているものの、お客様はタンパー機能を使用できません。 改ざんはサポートされていないことを反映するドキュメントが更新されます。 また、6ULZ i.MX 派生製品もタンパーをサポートしていないことにご注意ください 特長 i.MX 6UL -3 i.MX 6ULL/6ULZ コメント 改ざん検知信号 はい いいえ i.MX 6ULのみでアクティブタンパー機能が有効です。 電圧/温度/周波数検出（ドライアイス） はい いいえ i.MX 6ULL/ULZでは、ドライアイスおよびアクティブタンパー機能はサポートされていません。 よろしくお願いいたします。