Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
MPC5746C FXOSC output frequency Part: MPC5746C (Power Architecture Z4, SDK: NXP MPC57xx platform SDK). In the manual of MPC5746C, it is stated that FXOSC provides 8 -40 MHz output frequency. Please help me in finding the output frequency provided by FXOSC for the following configurations? 1. FXOSC_CTL: OSCBYP = 0 and OSCM = LCP 2. FXOSC_CTL: OSCBYP = 0 and OSCM = FSP 3. FXOSC_CTL: OSCBYP = 1 and OSCM = LCP 4. FXOSC_CTL: OSCBYP = 1 and OSCM = FSP Please consider default values for the other register fields. Thanks. Re: MPC5746C FXOSC output frequency Thanks for your response @petervlna.  How can we find the frequency provided by the crystal/resonator(OSCBYP = 0) and external clock(OSCBYP = 1)? Re: MPC5746C FXOSC output frequency Hello, The FXOSC module does not generate a specific frequency based on the OSCBYP and OSCM settings. The FXOSC output frequency is always equal to the frequency of the external source connected to FXOSC (crystal/resonator when OSCBYP=0, or external clock when OSCBYP=1), within the supported range of 8–40 MHz. Therefore, for all four configurations listed, the FXOSC output frequency is simply the external input frequency. The OSCM setting (LCP/FSP) affects the oscillator operating mode, but does not change the clock frequency. Best regards, Peter Re: MPC5746C FXOSC output frequency @petervlna please provide your support for my FXOSC query mentioned above.  Re: MPC5746C FXOSC output frequency How can we find the frequency provided by the crystal/resonator(OSCBYP = 0) and external clock(OSCBYP = 1)? Please let me know on the above question @petervlna. I want to use FXOSC as clock source for a timer. Based on the frequency it provides i can load a count value into the timer register Re: MPC5746C FXOSC output frequency Hello, The MPC5746C does not provide a way to measure or determine the FXOSC frequency from the FXOSC registers. The frequency must be known from the hardware design: OSCBYP = 0: FXOSC frequency equals the frequency of the external crystal/resonator fitted on the board. OSCBYP = 1: FXOSC frequency equals the frequency of the external clock signal applied to the FXOSC input pin. To use FXOSC as a timer clock source, the application must use the frequency specified in the board schematic or clock design (for example, 8 MHz, 16 MHz, 40 MHz, etc.) when calculating the timer count value. The OSCBYP and OSCM settings do not affect the frequency itself. Best regards, Peter
記事全体を表示
LLCEの例とU-boot こんにちは、 Goldbox上でLLCEのサンプルを動作させようとしています。 CAN2CANのサンプルコードを少し修正したところ、S32DSからデバッグすると正常に動作しました。 しかし、U-bootから実行しようとすると、実行はされるものの、U-boot自体がハングアップしてしまう。 私が実行しているコマンドは以下のとおりです。 dcache オフ; mw.q 0x34000000 0x0 0x100000; dcache オン fatload mmc 0:2 ${loadaddr} /llce.elf bootm7 ${loadaddr} VTABLE バス上でCANトラフィックは確認できているので例は実行中ですが、U-bootがフリーズしてコマンドを受け付けられなくなりました。 デバッグの結果、問題の原因はPlatformInit()呼び出し、特にクロックを設定するコードにあることが分かりました。 しかし、そのコードを削除すると、サンプルコードは動作しなくなります。 何かご提案はありますか? Re: LLCE example and U-boot こんにちは、 @GioMusto ご返信ありがとうございます。 はい、S32G2向けであってG3ではありませんが、導入された方法は似ています。 初期バージョンのソフトウェアパッケージに基づいているため、最近のバージョンのソフトウェアの組み合わせを使った際のステップバイステップガイドとは見なせません。 BR チェイン Re: LLCE example and U-boot こんにちは、 @chenyin_h さん、ご返信ありがとうございます。 あなたが投稿したガイドはS32G2用だと分かりました。S32G3でも同じですか?それとも何か違いがありますか? 注意すべき点について何かご提案はありますか?よくある問題などです。 Re: LLCE example and U-boot こんにちは、 @GioMusto 投稿ありがとうございます。 ご指摘の問題は、M側とA側の間のクロックまたはその他のリソースの競合が原因である可能性があります。 1. S32G製品では、デフォルト設定でA53側で動作するBSPがシステムへの排他的アクセス権を持つことを前提と設計されており、他のソフトウェアコンポーネントによる潜在的な競合を考慮しません。一方、Mコアアプリケーションではクロックやメモリなどの重要なリソースにも触れる可能性があります。重要なリソースに関して、起こりうる競合や再構成を避けるために、コードのあらゆる部分に注意を払う必要があります。 2. M7アプリケーションとLinux BSPを同時に動作させる場合、推奨される方法は、まずM7ブートローダーを起動してリソースを管理することです。これはAN13750で紹介されました BR チェイン Re: LLCE example and U-boot こんにちは、 @GioMusto ご返信ありがとうございます。 1. 一般的には、S32DS3.5.x(例えば3.5.14)の使用をお勧めします。S32Gと作業するためのもの(S32G RTDリリースのリリースノートに記載されています)。以下のパッケージが少なくともインストールされていることを確認してください:(RTDおよび開発パッケージ) chenyin_h_0-1786010049364.png 2. プロセスを簡略化するために、S32DSにサンプルプロジェクトをインポートし、IVTツールを開くことができます。例: chenyin_h_1-1786010241259.png それから、IVTツールで自分の画像を元にブロブを生成できるかどうか試してみてください。 BR チェイン Re: LLCE example and U-boot AN13750と「S32G3XX向けシステムレベルブートローダー統合例」に従って、M7ブートローダーを構築しようとしています。 SAFパッケージがないためブートローダーは少し苦労しながらもコンパイルできましたが、今はS32DSのIVTツールで動けなくなりました。 新しいプロジェクトを作成し、S32G399A、Cortex-M7_0を選択して設定を作成すると、「IVTツールは現在のプロセッサをサポートしていません。DCD、QuadSPI、DDR、eFuseについても同様です(スクリーンショットを参照)。 私は何が間違っているのでしょうか? IVT_error.png
記事全体を表示
MRF13750H 回路図 MRF13750H-915MHzボードを回路図に変換するにはどうすればよいですか?MRF13750Hのデータシートには、915MHz用のリファレンスボードのレイアウトは含まれていますが、回路図は含まれていません。 Luis_V_1-1784224999094.png
記事全体を表示
NFC读卡器库 大家好。 如何找到并下载支持 DESFire EV3 卡的 PN7642 NDA 版本示例和库?我已经签署了有效的 NDA。 感谢您的支持。 NFC读卡器库 Re: NFC reader library 你好@dbogovic 希望你一切都好。 如果您已经拥有有效的 NDA,则必须通过安全访问权限申请支持 MIFARE DESFire 的 PN7642 SDK,请按照此页面上的说明进行操作:安全访问权限 | NXP 半导体 。另外,我建议您查看NXP 半导体的“安全访问权限常见问题解答” 。 可在PN7642 产品页面的软件部分(安全)中找到可用的安全资源。 问候, 爱德华多。
記事全体を表示
HSE設置 S32K311 以下の内容はすべて添付ファイルからコピーしたものです。 S32DS バージョン: S32DS.3.5_b220726_win32.x86_64(1).exe RTDバージョン: SW32K3_RTD_R21-11_3.0.0_P07_D2306_DS_updatesite.zip S32K311 サポートパッケージ バージョン: SW32K3_S32DS_3.5.6_D2309.zip SBAFバージョン: SBAF_S32K311_0_0_15_0 ビン ファイル: s32k311_Secure_Baf_0.12.0_0.15.0.6_pb230804.bin.pink HSEバージョン: HSE_FW_S32K311_0_2_40_0 バイナリファイルはs32k311_hse_fw_0.12.0_2.40.0_pb230730.bin.pinkです。 FULL_MEMを使用する セーフブートなし 現在発生している問題 プログラムはここで停止します: `while ( FALSE == HSE_CheckStatus(HSE_STATUS_INIT_OK) );` 图片3.png   图片4.png 图片1.png 图片5.png   图片6.png   图片2.png     Re: HSE INSTALL S32K311 これは補足的なprintf情報です。 DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 Current_SBAF_Version-0x4039c020: 0x00000C00 LC構成ワード -0x4039C02C: 0x00000000 ライフサイクル関連情報 - 0x402AC200: 0x00000000 HSEステータス: 0x00000000 ネットで調べてみたところ、チップに付属しているSBAFは、私が現在使用しているHSEファームウェアを認識しないようです。 Re: HSE INSTALL S32K311 SBAFがHSEファームウェアをフラッシュメモリからHSE_NVMにコピーできなかったことが原因ではないかと疑っています。もしこれが原因であれば、どのように解決すればよいでしょうか? Re: HSE INSTALL S32K311 これが私が印刷したデータです。 DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 HSEステータス: 0x00000000 HSEファームウェアが起動していません(NVMが空であるか、ファームウェアが破損しています) 111.png Re: HSE INSTALL S32K311 こんにちは@iiiddd HSE_CONFIG_GPR3(0x4039C028)の価値について教えていただけますか?ビット0は、HSEファームウェアが存在するかどうかを示します。 BR、VaneB Re: HSE INSTALL S32K311 私が使用しているRTDライブラリは、UTESTを作成する際に呼び出されます。 gHsePort_FlsIf.writeApi(UTEST_BASE_ADDR,(uint8_t*)hseFwFeatureFlag,FW_FEATURE_FLAG_LEN); FLS_MAX_VIRTUAL_SECTOR 定義が使用されます。私のRTDライブラリはデフォルトで135ですが、アドレス0x1B000000ULにアクセスするには136が必要です。私が使用しているRTDライブラリはHSEと互換性がないのでしょうか? Re: HSE INSTALL S32K311 こんにちは@iiiddd HSE_CONFIG_GPR3[0]ビットが設定されていないということは、デバイスにHSEハードウェアが存在しないことを示しています。 参考までに、以下の画像は、S32K311 デバイスに HSE FW FULL_MEM をインストールするために構成されたリンカー ファイルの例を示しています。 VaneB_0-1784568701705.png Re: HSE INSTALL S32K311 デバッグ中に、pflashにhseファームウェアに対応するデータが存在することを発見しました。sbafがpflash内のファームウェアをhsenvmにコピーできなかったということですか?これが問題の原因だとすれば、何が原因だったのでしょうか?
記事全体を表示
IW612 蓝牙射频测试 大家好, 我正在尝试对基于 IW612 的模块执行射频测试。为此,我参考了几份文件,例如: AN14310 - NXP 蓝牙 UART 驱动程序集成 AN14114 - Linux 操作系统上的射频测试模式 AN14163 - 蓝牙直连测试模式 还有其他人。 我遇到了一些问题: - 在 5 GHz Wi-Fi 频段中,我无法看到低频信道(接近 5 GHz)生成的波形,只能看到高频信道生成的波形。 - 对于蓝牙,我无法生成经典蓝牙的波形,只能生成 BLE 的波形(使用 hcitool 进行扫描和获取配对信息的命令运行正常,因此我认为这不是硬件问题)。 我的配置中,我使用的是 SoM Variscite Dart IMX8M(版本 2.0),配备基于 IW612 的 2EL 无线电。为了获取波形,我使用了 HackRF。 我使用的是内核版本为 6.6.23 的系统。Yocto 定制版本,固件为 sduart_nw61x_v1.bin.se,默认版本 HCI 命令的反馈与文档相符,但我看不到波形。如果我在系统或生成流程中遗漏了什么,请您帮忙看看。这是认证流程的一部分,现在我卡在这里了。 非常感谢 Re: IW612 Bluetooth RF Test Hello 能否将测试命令和结果截图分享给我们? 顺祝商祺! 肖恩 Re: IW612 Bluetooth RF Test 你好,肖恩, 当然。我运行了这些 hcitool 和 wifi 命令,并将最终的配置文件附在后面。 适用于蓝牙经典 ------------------------------------ 这些指令直接摘自 UM11490(第 149 页)。 # RESET root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令:ogf 0x03,ocf 0x0003,plen 0 > HCI 事件:0x0e plen 4 01 03 0C 00 # 启用扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令:ogf 0x03,ocf 0x001a,plen 1 03 > HCI 事件:0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令:ogf 0x03,ocf 0x0005,plen 3 02 00 02 > HCI 事件:0x0e plen 4 01 05 0C 00 # 进入测试模式 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令:ogf 0x06,ocf 0x0003,plen 0 > HCI 事件:0x0e plen 4 01 03 18 00 # 启动TX变速器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令:ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件:0x0e plen 4 01 19 FC 00 # 停止TX传输 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令:ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件:0xff plen 6 19 01 39 00 00 00 -------------------- 在发送数据之前停止对蓝牙低功耗 (BLE) 和经典蓝牙 (Classic) 的扫描 ---------------- # RESET root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令:ogf 0x03,ocf 0x0003,plen 0 > HCI 事件:0x0e plen 4 01 03 0C 00 # 启用扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令:ogf 0x03,ocf 0x001a,plen 1 03 > HCI 事件:0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令:ogf 0x03,ocf 0x0005,plen 3 02 00 02 > HCI 事件:0x0e plen 4 01 05 0C 00 # 进入测试模式 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令:ogf 0x06,ocf 0x0003,plen 0 > HCI 事件:0x0e plen 4 01 03 18 00 # 禁用蓝牙扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCI 命令:ogf 0x03,ocf 0x001a,plen 1 00 > HCI 事件:0x0e plen 4 01 1A 0C 00 # 禁用经典扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCI 命令:ogf 0x08,ocf 0x000c,plen 2 00 00 > HCI 事件:0x0e plen 4 01 0C 20 00 # 启动TX变速器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令:ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件:0x0e plen 4 01 19 FC 00 # 停止TX传输 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令:ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件:0xff plen 6 19 01 63 07 00 00 ** 在进入测试模式前禁用扫描时,TX 传输停止会显示以下信息: root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令:ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件:0xff plen 6 19 01 ED 04 00 00 适用于 5 GHz Wi-Fi -------------------------------------------------------------------------------- 参数:连续发射,带宽 = 40 MHz,802.11ac无DFS,CH = 40,MCS0(13.5),功率 = 14 dBm root@oaslv:/home/hexagon# cat /proc/mwlan/adapter0/config 硬件状态=0 netlink_num=31 驱动模式=7 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 接收天线=1 band=1 bw=1 频道=44 radio_mode[0]=3 radio_mode[1]= 总处方药包数=0 接收多播/广播数据包计数=0 接收函数调用错误数据包计数=0 发射功率=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 触发帧=0 otp_mac_add_rd_wr= 00:00:00:00:00:00
記事全体を表示
S32 Design Studio for ARM 2018.R1 has expired. The license for S32 Design Studio for ARM 2018.R1 has expired. Please also let us know if there is a separate procedure for renewing or reactivating the license. Re: S32 Design Studio for ARM 2018.R1 has expired. Hi,  your S32DS license has been extended.  Re: S32 Design Studio for ARM 2018.R1 has expired. It is the same as the previous license activation code, and it still does not pass.
記事全体を表示
PN7221 fails to detect ISO 14443-3B We ported PN7221 in accordance with the document AN14880 PN7160/PN7220 - Android 16 porting guide. During testing, ISO 14443-3B (NfcB) cards cannot be detected. Moreover, after tapping such a card, the NFC function malfunctions and fails to recognize any cards. It is necessary to toggle NFC off and on again to restore normal operation. Relevant logs are attached below for your analysis. ❯ 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.515 530 6384 D NxpNciR : len = 26 > 61051701010001FF010C0B00000000D103860500808001000000 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.516 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: RF Interface = Frame RF 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: Protocol = Unknown 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: Mode = B Passive Poll 07-16 09:24:28.516 530 6387 D NxpHal : NCI NTF: RF_DEACTIVATED len=26 type=1 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.517 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id sent to lower =0 07-16 09:24:28.517 530 542 I android.hardware.nfc2-service.nxp: write 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - Write requested..... 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - Invoking I2C Write..... 07-16 09:24:28.519 530 6385 D NxpNciX : len = 12 > 0000091D0000000000080100 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - I2C Write successful..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - Posting Fresh Write message..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - Tml Writer Thread Running................ 07-16 09:24:28.519 530 6387 D NxpHal : write successful status = 0x0 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.520 530 6384 D NxpNciR : len = 6 > 600603010001 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.521 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.521 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.523 530 6384 D NxpNciR : len = 5 > 0000020000 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.523 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.524 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:WAIT_ENDEF_FILE_CTRL_TLV (17) 07-16 09:24:28.524 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id sent to lower =0 07-16 09:24:28.524 530 542 I android.hardware.nfc2-service.nxp: write 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - Write requested..... 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - Invoking I2C Write..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.525 530 6385 D NxpNciX : len = 8 > 0000050036000008 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - I2C Write successful..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - Posting Fresh Write message..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - Tml Writer Thread Running................ 07-16 09:24:28.525 530 6387 D NxpHal : write successful status = 0x0 07-16 09:24:28.527 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.527 530 6384 D NxpNciR : len = 6 > 600603010001 07-16 09:24:28.528 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.528 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.528 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.531 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.532 530 6384 D NxpNciR : len = 14 > 00000B21CBA4729CB97166900000 07-16 09:24:28.532 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.532 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.533 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:???? UNKNOWN SUBSTATE (18) 07-16 09:24:28.533 1599 6381 I libnfc_nci: nfa_rw_update_pupi_id: 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... Re: PN7221 fails to detect ISO 14443-3B We've upgraded to version 3.2.5, but the test results remain unchanged. 07-17 01:13:52.157 533 542 D NxpHal : FW version found on the device = 0x30205 Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  Please update to 3.2.5, you can get the FW file by going: nfc-NXPNFCC_FW/InfraFW/pn7220 at master · NXP/nfc-NXPNFCC_FW Re: PN7221 fails to detect ISO 14443-3B 06-24 10:20:33.259 390 401 D NxpHal : FW version found on the device = 0x302c4 Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  which is the version of FW? if it low 3.2.5, please update to the newest, and test again. If still has question, please provide full log to us. Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  Could you provide libnfc-nci.conf and libnfc-nxp.conf files? Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai This issue may be related to the changes in A16. Specifically: Prior to A15, NXP's mobile MWs relied on NFA_PROTOCOL_T3BT(80) to support ID cards, but A16 has directly included Chinese ID cards in its support scope through Google. However, the PN7xxx MWs still retain this code. Therefore, customers are trying to completely remove the T3BT logic from the PN7xxx MWs and directly use Google's native logic. KaiLi_0-1784790560099.png Re: PN7221 fails to detect ISO 14443-3B The configuration file has been uploaded.
記事全体を表示
LED 的 IO 扩展 我目前正在设计用于定制测量设备的开关矩阵板。 为了路由信号,我计划使用光中继器,准确地说是 G3VM-61DR1。 所以我需要控制超过 250 个!以某种方式使用 LED(1.5-1.8V 6-8mA)。 同时开启的设备数量将少于25台。 供电电压为3.3V或更低,温度应在40°C左右。 我们只需要打开或关闭它们,不需要调光或PWM调光。 我不想使用LED驱动器,因为它可能会引入噪声。 我无法使用传统的矩阵式电路,因为无法预知哪些开关会同时处于开启状态。 因此,唯一的选择是为每个继电器/LED 提供一个独立的输出,您的 IO 扩展器看起来很有希望实现这一点,例如PCAL6524 。 由于通道数量较多,我希望尽可能减少每个通道的元器件数量,因此我有几个问题: 我能否依赖 Agile IO 设备的 7.5mA 电流设置,而省略 LED 串联电阻? 如果可以的话,可能会有哪些副作用? 由于这些设备最初配置为输入,因此当它们用于控制 LED 时,某些设备会经历高电流(例如,PCA9535A数据手册第 14/15 页)。对于这么多通道来说,为每个通道使用上拉电阻的传统解决方法并不理想。这是否也会影响 Agile IO 设备? 能否通过给 LED 提供 3.3V 电压,给扩展器提供 1.65V 电压来解决这个问题? 先感谢您 奥托 Re: IO Expansion for LEDs PCAL6524 非常适合驱动大量的光继电器和 LED。然而,敏捷 I/O 驱动能力并不是为了取代所需的串联限流电阻器。为了降低上电时 I/O 仍处于输入状态时出现意外电流的风险,可以考虑使用 VDD(P) 较低的 3.3 V LED 电源,或者实现全局 LED 电源开关等方案。然而,每个 LED 通道都应该始终保留单独的限流电阻。
記事全体を表示
S32DS 3.4 ライセンスの問題 NXPチームの皆様へ S32DS 3.4の再アクティベーションを試みましたが、できず、下の画像のようなメッセージが表示されました。現在、古いコンピューターでライセンスを復元することができません。この問題を解決するお手伝いをしていただけないでしょうか?よろしくお願いいたします。 ben_chin_0-1784189249520.png Re: S32DS 3.4 License Problem こんにちは、 利用可能なライセンス数が増加しました。
記事全体を表示
i.MX8M Plus DDR4-3200 EVK 设计文件和 DDR4 布局指南 你好 , 我们希望采用 i.MX8M Plus+DDR4 设计我们的产品。 NXP能否向我们提供i.MX8M Plus+DDR4-3200的设计文件(sch和.brd)以及DDR4布局指南文档? Re: i.MX8M Plus DDR4-3200 EVK Design file and DDR4 layout guide 我正在尝试同样的方法。 供参考。基于 i.MX 8M Plus 的 AI 机器人平台 “ I-MX8MPLUS-ALROBOT-FORM”是DDR4参考设计。 您需要联系恩智浦半导体才能获得这些资源。 Re: i.MX8M Plus DDR4-3200 EVK Design file and DDR4 layout guide @seungyeon我已经通过邮件和附件发送给你了,请查收。
記事全体を表示
imx93でLPUART8を使用してコンソールを有効にする チームの皆さん、こんにちは。 i.MX93 EVKキットでは、 LPUART8をコンソールとして使用するボードを起動しようとしていますが、デフォルトのコンソールはLPUART1です。つまり、 u-boot dts、linux-imx dts、imx93_evk.c、imx93_evk.hで変更を行いました。 しかし、シリアルログを確認できず、EVKキットJ1001ヘッダーのピン32&33 (LPUART8のALTモード)を使用して確認しました。この設定も機能しません。変更内容と手順を教えてください。 よろしくお願いします。 ロビー Re: Enabling console using LPUART8 for imx93 こんにちは、 @AldoG さん。 LPUART8も使用しています 問題は、オプティーデバッグを有効にするとボードがハングアップして起動しないことです。CFG_TEE_CORE_LOG_LEVEL=3 U-Boot SPL 2024.04 (2026年3月27日 04:41:39 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: オーバードライブ電圧モード Vx読み取りカウント(2728)がVxしきい値(1763)を超えているため、起動を続行します。 DDR: 3733MTS M33準備OK 通常起動 BOOTROMから起動しようとしています ブートステージ:プライマリブート 画像オフセット 0x0、ページサイズ 0x200、IVT オフセット 0x0 ROM_APIを使用して0x54000からイメージをロードします よろしくお願いいたします。 ラク**ブリープ** Re: Enabling console using LPUART8 for imx93 こんにちは、 今は動作してよかったですが、画像互換性については無理だと思います。たとえプロセッサがほぼ他のプロセッサよりダウングレードであっても、i.MX91用のイメージを自分で作成する必要がありますが、変更したもののほとんどは再利用できます。 よろしくお願いいたします。 アルド。 Re: Enabling console using LPUART8 for imx93 @AldoG さん、ありがとうございます。 今は正常に動作しています。i.mx93 イメージは imx91 と互換性がありますか。 よろしくお願いします。 ロビー。 Re: Enabling console using LPUART8 for imx93 こんにちは、 変更はすべて正しいです。ペリフェラルでクロックを有効にする設定が見落とされています。起動時にはデフォルトで有効になっていないためです。 /arch/arm/mach-imx/imx9/native/clock.c にて mxc_get_clock(enum mxc_clock clk)関数では、次のように追加します: リターンccm_clk_root_get_rate(LPUART8_CLK_ROOT); In Void init_uart_clk(U32インデックス)関数加算: CASE LPUART8_CLK_ROOT: /* 24歳男性 */ ccm_lpcg_on(CCGR_URT8、偽); ccm_clk_root_cfg(LPUART8_CLK_ROOT、OSC_24M_CLK、1); ccm_lpcg_on(CCGR_URT8、真); 休憩; また、/board/freescale/imx93_evk/imx93_evk.c でもご覧ください。 関数 int board_early_init_f(void) 加算: init_uart_clk(LPUART8_CLK_ROOT); この変更は同僚によって行われ、EVKで正しく動作しています。 よろしくお願いいたします。 アルド。 Re: Enabling console using LPUART8 for imx93 @AldoG さん、ありがとうございます。 応答に関しては、i.MX93 EVK はデフォルトのコンソール ポートとして LPUART1 を使用しますが、私のカスタム ボードは LPUART8 に設定されています。コンソールをLPUART1からLPUART8に変更し、ヘッダーJ1001を確認する必要があります。そのため、私は以下の変更を行いました。 u-boot-imx: lpuart8ノードを追加し、lpuart1とiomuxを無効にしました。 /configs/imx93_evk.h 内の "console= ttyLP7 ,115200 earlycon\0" \ を "ttyLP0" に変更しました。ファイル。 追加した static iomux_v3_cfg_t const uart_pads[] = { // MX93_PAD_UART1_RXD__LPUART1_RX | MUX_PAD_CTRL(UART_PAD_CTRL), // MX93_PAD_UART1_TXD__LPUART1_TX | MUX_PAD_CTRL(UART_PAD_CTRL), MX93_PAD_GPIO_IO13__LPUART8_RX | MUX_PAD_CTRL(UART_PAD_CTRL) MX93_PAD_GPIO_IO12__LPUART8_TX | MUX_PAD_CTRL(UART_PAD_CTRL) }; /imx93_evk/imx93_evk.c 内ファイル。 Linux-IMX: lpuart8ノードを追加し、lpuart1とiomuxを無効にしました。 imx.atf: /include/platform_def.h ファイル内の IMX_LPUART_BASE U(0x426a0000) を U(0x44380000) に変更しました。 メタフレッシュスケール: /conf/machine/imx93-11x11-lpddr4x-evk.conf 内の SERIAL_CONSOLES = "115200;ttyLP7" を変更しました。このファイルには、ヘッダーファイル /conf/machine/include/imx93-evk.inc が含まれています。 optee-os: set(CFG_UART_BASE UART1_BASE) を set(CFG_UART_BASE UART8_BASE) に変更しました。 詳細情報については、変更内容の画像を含むzipフォルダを追加してください。内容を確認して、最新情報をお知らせください。 よろしくお願いします。 ロビー よろしくお願いします。 ロビー Re: Enabling console using LPUART8 for imx93 こんにちは、 変更点を教えてもらえますか?正しく行っているか確認したいので。 また、使っているLinuxバージョンも教えてください。 よろしくお願いいたします。 アルド。 Re: Enabling console using LPUART8 for imx93 この問題の解決にご協力ください。すべてのパスを変更しました。
記事全体を表示
关于 MRF300AN 27MHz 参考设计中 C16 电容额定值的问题 您好,NXP支持团队, 我目前正在审查 MRF300AN 27MHz 参考设计,对输出端的电容 C16 有一个疑问。 根据我手头的物料清单(例如,来自 Farnell 的数据手册),C16 被指定为 39,000 pF (39 nF) / 50V 的贴片电容(ATC 零件号 200B393KT50XT) 。鉴于 MRF300AN 的工作漏极电压为 50V,且输出级需处理高射频功率(高达 300W 以上),我担心在此位置使用 50V 额定值的电容可能不足以保证长期可靠运行。 我的问题是: 物料清单中 C16 的额定电压为 50V 是否正确,还是可能是笔误? 在这个电路中,C16 的具体作用是什么?它是输出匹配网络的一部分、直流阻隔电容,还是旁路/去耦电容? 如果它确实是射频输出路径中的直流阻隔或匹配电容,那么使用更高电压额定值(例如 100V 或更高)的电容来处理电压瞬变和驻波岂不是更合适? 非常感谢您能就此事作出澄清。感谢您的时间和支持。 顺祝商祺! Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 风雨绮你好 再会! 300W 并不能直接决定电容上的电压应力。 电容的额定电压必须与该电容两端的实际射频电压进行比较,而不是与放大器的输出功率进行比较。 C16 不一定能看到完整的射频输出电压。 根据参考设计物料清单,C16 属于电源去耦/射频旁路网络,而不是直接跨接在 50 Ω 输出连接器上。 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 祝你今天过得愉快,一切顺利。 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 亲爱的 RafaR, 感谢您详尽且有帮助的回复。我非常感谢您抽出时间解释电容的电压应力问题。 我想承认您说得完全正确——C16 两端的电压没有射频输出电压那么高,因为电压应力取决于元器件两端的实际射频电压,而不是放大器的输出功率。我完全同意这一点。 不过,关于 C16,我想澄清一点。仔细检查我手头的 PCB 布局后,假设所有走线都布线在顶层,那么 C16 看起来确实是位于 RF 输出之前的直流阻隔电容器。我知道这可能与您文档中的物料清单名称有所不同,但根据我目前可以访问的布局文件,这是我观察到的情况。 目前我下载的资料仅包括 PCB 布局文件和一份简要概述文档——我无法访问完整的原理图、包含元器件功能的详细物料清单或完整的参考设计用户指南。 能否提供该参考设计的更详细文档,例如: 完整示意图 包含元器件功能描述的完整物料清单 参考设计用户手册或应用说明 如果您能提供任何其他资料,我将不胜感激。如果分享这些文件有任何限制,也请告知我,以便我可以通过正规渠道申请获取。 再次感谢您的指导,期待您的回复。 此致, 风雨绮 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 风雨绮你好 再会! 遗憾的是,NXP提供的该设计文档包中不包含原理图。由于大多数射频设计对电路板布局都很敏感,因此这是我们的常规做法。因此,布局视图加上物料清单比单纯的原理图能提供更具可重复性的结果。如果需要,您可以自己使用布局图和物料清单绘制原理图。 遗憾的是,我们没有 27MHz 频段的 MRF300 参考设计。 我们推荐的文档位于我们官方网站的“设计资源”部分: RafaR_0-1784737806340.png 但是,这种设计已经实施了好几年,所以我可以向您保证,我们提供的文档中列出的物料清单是正确的。 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 由此给您带来的不便,我们深表歉意。 祝你今天过得愉快,一切顺利。 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 亲爱的 RafaR, 非常感谢您之前的回复以及分享的设计资源。我已经按照您的建议审查了布局和物料清单,现在正准备制作自己的原型。在继续之前,我想就元器件选择和可能的修改提出几个具体问题: 电容器替换——物料清单中列出的一些 ATC 电容器在我所在的地区很难找到。我正在考虑使用 Vishay RF 电容,其关键规格类似,例如 39 pF、C0G/NP0 介质和相同的额定电压。根据您的经验,如果其他参数(如 ESR、Q 值和自谐振频率)相当,那么这种替换是否安全?还有其他我应该特别注意的隐藏特征吗? C10 的值变化 – 在我的 ADS 模拟中,我发现用 200 pF 电容替换 C10 可以明显提高效率。您会建议在实际电路板上进行此项更改吗?如果是这样,在这样做之前我应该评估一下是否存在任何稳定性或散热方面的问题吗? 调试方法——由于没有提供原理图,我计划使用布局图和物料清单作为主要参考。我假设我对电路理解上的细微偏差可以通过对原型进行实际调整和测量来解决。您认为这种做法是否合理?或者您预见到是否存在任何重大风险? 我非常感谢您抽出时间给予指导。如果以上任何问题需要进一步澄清,请随时告诉我。 祝您今天过得愉快,并致以最诚挚的问候! 风雨绮 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 风雨绮你好 再会! 电容替换 遗憾的是,NXP 没有推荐的替代品,而且我也没有机会尝试 BOOM 中列出的元器件以外的元器件,因此我们无法保证它们的功能。 但是,根据我的研究,只有当您之前提到的参数相同时,这些替换方案才可行。如果可能的话,我还会考虑封装几何形状和散热情况。 C10 值变化 如果你已经运行过模拟并且看到了改进,那就继续吧。 调试方法 当然,我认为这是一个很好的方法;通常情况下,小错误可以通过对布局进行一些小的修改来修复,所以我认为这样做没有任何风险。 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 祝你今天过得愉快,一切顺利。
記事全体を表示
RT1170 NVCC_XXX 电源时序和未使用的 I/O 组 你好, 1 - 我想问一下,在 DCDC_IN 和 Pswitch 开启(内核也开启)的情况下,关闭未使用的 IO 组 NVCC_XXX 的电源是否安全,因为没有未使用的 IO 组引脚由外部驱动。 2 - 另外,为了维持 IO 状态,是否可以保持某个 IO 存储体开启,而其他存储体关闭? 提前致谢 Re: RT1170 NVCC_XXX power sequence and unsued IO banks 你好@Marwan , 我了解到您正在考虑断开一个未使用的电源组的电源。我的理解正确吗? 最佳做法是保持相应的 NVCC_xxx 电源供电,并将未使用的 GPIO 浮空。然而,RT1170 包含一个灵活的电源架构,允许关闭某些域的电源,以降低整体功耗。 我建议参考AN13148 ,其中详细解释了 RT1170 的电源架构和低功耗架构设计。AN13104也是一个有用的参考资料,因为它提供了有关功率域和 LP 状态的有用信息。 此外,如果您正在开发定制板,我强烈建议您参阅MIMXRT1160/1170 的硬件开发指南。本文档提供有关电路板布局建议和设计清单的信息,以确保一次性成功并避免电路板启动问题。 BR 哈比卜 Re: RT1170 NVCC_XXX power sequence and unsued IO banks 感谢您的回复和提供的参考资料。 没错,如果某些 IO 库不使用,我希望将其关闭。虽然没有明确说明不建议这样做,但这是我从相关文档的字里行间理解到的意思。 关于第二个问题: 如果将 IO 库始终保持开启状态(以保持 IO 状态,并且不被外部驱动),而将DCDC_IN和DCDC_PSWITCH关闭(接地),(除 SNVS 和 IO 库外,所有功能域都关闭),这样可以吗? MCU 不是主机,所以我问这个问题是为了防止 MCU 处于 SNVS 模式时 IO 被外部驱动。 此致敬礼, 马尔万 Re: RT1170 NVCC_XXX power sequence and unsued IO banks 你好@Marwan , 谢谢你的解释。 为了帮助我更好地理解您的问题,您能否解释一下您提到的“使 IO 库始终处于开启状态”指的是什么?您是指保持每个 I/O 组的 NVCC_xxx 供电轨持续供电吗? 最佳做法是保持相应的 NVCC_xxx 电源供电,并将未使用的 GPIO 浮空。我强烈建议使用设定点功能,因为它使电源模式切换更简单、更安全。 关于在禁用 DCDC 的同时仅保持 SNVS 电源处于活动状态的可能性。如果您的应用需要使用 M7 且不使用外部 PMIC。禁用 DCDC 是不可能的,因为 M7 位于 WAKEUPMIX 功能域中,该功能域由 VDD_SOC_IN 供电,并由 DCDC 直接供电,如AN13104的第 2 章“RT1170 功率域”中所述。 如果您的目标是最大限度地降低功耗,您可以考虑使用设定点将设备过渡到低功耗状态,同时仅保持 SNVS 域供电,请参阅表 4.1.5。请参阅数据手册中的“典型电源模式供电电流”,以了解不同的设定点配置。 此外, AN13104还包含一个实际示例,演示如何配置唤醒源。您可能会发现第 4.9 章“唤醒源配置”对您的实现很有用。 最后,关于维护 IO 状态,SSARC 可能很有用。默认情况下,如果外设所属的电源组合断电,则外设配置将丢失,必须重新初始化后才能直接使用。但是,使用 SSARC,您可以在断电前将功能模块的寄存器保存到内存中,并在模块上电后从内存中恢复寄存器,如 AN13104 的 4.14 章“唤醒后的外设状态”中所述。您可以找到一个名为“ssarc_software_trigger_cm7”的 SDK 示例,其中展示了外围设备的功能,您可以将其作为参考。 BR 哈比卜 Re: RT1170 NVCC_XXX power sequence and unsued IO banks 你好@Marwan , 我了解到您计划使用外部电源管理集成电路 (PMIC)。我的理解正确吗? 在这种情况下,请参阅AN13213 ,其中描述了如何将外部 PMIC 与 RT1170 连接,特别是 PF5020,这是 MIMXRT1160/1170 硬件开发指南第 3.2 章“使用外部 PMIC”中推荐的 PMIC。本应用说明中推荐的连接方式如下: Habib_MS_1-1784839522098.png 我还建议查阅硬件开发指南中的表 2 和表 3,因为它们提供了有关外部 PMIC 使用以及与 SNVS 域相关的建议的有用指导。 此外,您可能会发现 SDK 示例 power_mode_switch_bm_pmic_rt1xxx_core0 很有帮助。本示例演示了如何使用外部 PMIC 和设定点配置在不同的低功耗状态之间进行转换。请查看 README 文件,了解示例的详细工作原理。 最后,我建议复习AN13104的第 4.13 章“低功耗模式下的外设状态”,其中解释了设备处于低功耗状态时外设的行为。 BR 哈比卜 Re: RT1170 NVCC_XXX power sequence and unsued IO banks 感谢您的进一步解释。 请查看附图: power diagram.png 我的目标是进入SNVS 模式(开关关闭后的所有电路),同时保持 NVCC_XX 开启以维持其他电路的状态,这是否可行,或者是否会对 RT1170 MCU 造成损坏? 我知道,保持 NVCC_XX 开启时,需要正确配置 IO 以防止额外的漏电流。 此致敬礼,并感谢您的帮助。 Re: RT1170 NVCC_XXX power sequence and unsued IO banks 你好@Marwan , 是的,NVCC_xxx 轨可以保持由外部电源供电,如图 14-2“RM 的电源架构”所示:   Habib_MS_1-1785189559143.png 但是请记住,在此配置中,DCDC 电源也必须存在,因为它为 WAKEUPMIX 功能域(CM7 所在的域)提供电源。此外,请确保正确执行数据手册第 4.2.1 节“电源要求和限制”中描述的上电顺序,以避免出现任何意外情况。 最后,我强烈建议您参阅MIMXRT1160/1170 的硬件开发指南。本文档包含重要的设计指南、布局建议和硬件检查清单,可以帮助确保电路板设计成功并避免潜在的启动问题。 BR 哈比卜 Re: RT1170 NVCC_XXX power sequence and unsued IO banks 不,我不会使用外部 PMIC,共享框图对我来说就足够了,我只需要确保当 DCDC_IN 时 NVCC_XXX 电源可以开启,而当 MCU 处于 SNVS 模式时 NVCC_XXX 电源关闭(接地) 。 这种情况有可能实现吗? 此致敬礼 Re: RT1170 NVCC_XXX power sequence and unsued IO banks 所以我的理解是,不建议只开启部分I/O模块而关闭其他模块。 另外,为了在睡眠状态下获得更好的功耗,最好将所有设备都关掉,只保留 SNVS 存储设备继续运行。 感谢你的努力
記事全体を表示
Enabling console using LPUART8 for imx93 Hi team,                  I'm trying to boot a board which uses LPUART8 as console but LPUART1 default console in i.MX93 EVK kit. So I had done the changes in u-boot dts, linux-imx dts,imx93_evk.c and imx93_evk.h. But unable to watch serial logs and same I checked using EVK kit J1001 header pin32&33 which are ALT modes of LPUART8. This configuration also doesn't work. Please let me know the changes need to be applied and also let me know the path. Thanks  Robbi Re: Enabling console using LPUART8 for imx93 Hi @AldoG , We are also using LPUART8 the issue is when we enable optee debug board hangs does not bootup, CFG_TEE_CORE_LOG_LEVEL=3 U-Boot SPL 2024.04 (Mar 27 2026 - 04:41:39 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: Over Drive Voltage Mode Vx read count(2728) is greater than Vx threshold(1763) continue booting DDR: 3733MTS M33 prepare ok Normal Boot Trying to boot from BOOTROM Boot Stage: Primary boot image offset 0x0, pagesize 0x200, ivt offset 0x0 Load image from 0x54000 by ROM_API Thanks & Regards, Rak**bleep**h Re: Enabling console using LPUART8 for imx93 Hello, Glad that it is working now, regarding image compatibility I would say no, since even if the processor is practically a downgrade of the other it would require to create your own image for the i.MX91 but you may reuse almost all of your changes. Best regards/Saludos, Aldo. Re: Enabling console using LPUART8 for imx93 Thanks @AldoG ,                           It is working now. Is i.mx93 Image compactible for imx91. Thanks Robbi. Re: Enabling console using LPUART8 for imx93 Hello, All your changes are correct, you're missing some configuration for the clock to be enabled on the peripheral, since at boot time this is not being on by default. at /arch/arm/mach-imx/imx9/native/clock.c  in mxc_get_clock(enum mxc_clock clk) function add: return ccm_clk_root_get_rate(LPUART8_CLK_ROOT); in void init_uart_clk(u32 index) function add: case LPUART8_CLK_ROOT:  /* 24M */  ccm_lpcg_on(CCGR_URT8, false);  ccm_clk_root_cfg(LPUART8_CLK_ROOT, OSC_24M_CLK, 1);  ccm_lpcg_on(CCGR_URT8, true);  break; Also at /board/freescale/imx93_evk/imx93_evk.c in function int board_early_init_f(void) add: init_uart_clk(LPUART8_CLK_ROOT); This changes have been made and tested by a colleague and are working correctly on the EVK. Best regards/Saludos, Aldo. Re: Enabling console using LPUART8 for imx93 Thanks @AldoG ,                           For the response, i.MX93 EVK uses LPUART1 as default console port, but as my custom board is configured for LPUART8. I need to change my console from LPUART1 to LPUART8 and check in Header J1001. For that the modifications I had done: u-boot-imx: Added lpuart8 node and disabled lpuart1 along with iomux. changed "console=ttyLP7,115200 earlycon\0" \ from ttyLP0" in /configs/imx93_evk.h file. Added  static iomux_v3_cfg_t const uart_pads[] = { // MX93_PAD_UART1_RXD__LPUART1_RX | MUX_PAD_CTRL(UART_PAD_CTRL), // MX93_PAD_UART1_TXD__LPUART1_TX | MUX_PAD_CTRL(UART_PAD_CTRL),     MX93_PAD_GPIO_IO13__LPUART8_RX | MUX_PAD_CTRL(UART_PAD_CTRL),     MX93_PAD_GPIO_IO12__LPUART8_TX | MUX_PAD_CTRL(UART_PAD_CTRL), }; in /imx93_evk/imx93_evk.c file. linux-imx: Added lpuart8 node and disabled lpuart1 along with iomux. imx-atf: changed IMX_LPUART_BASE  U(0x426a0000) from  U(0x44380000) in /include/platform_def.h file. meta-fresscale: changed SERIAL_CONSOLES = "115200;ttyLP7" in /conf/machine/imx93-11x11-lpddr4x-evk.conf which includes header /conf/machine/include/imx93-evk.inc file. optee-os: changed set(CFG_UART_BASE UART1_BASE) to set(CFG_UART_BASE UART8_BASE). For more info add zip folder which contains images of changes done. Please go through it and let me know update. Thanks Robbi Thanks  Robbi Re: Enabling console using LPUART8 for imx93 Hello, Could you share the changes you have made, so I could check those are made correctly? Also, please share the Linux version you are working with. Best regards/Saludos, Aldo. Re: Enabling console using LPUART8 for imx93 Please help on this issue modified all paths.
記事全体を表示
为 imx93 启用使用 LPUART8 的控制台 大家好, 我正在尝试启动一块使用LPUART8作为控制台的板子,但 i.MX93 EVK 套件中的默认控制台是 LPUART1 。所以我修改了u-boot dts、linux-imx dts、imx93_evk.c 和 imx93_evk.h文件。 但是无法查看串口日志,我使用 EVK 套件J1001 接头引脚 32 和 33进行了检查,它们是 LPUART8 的 ALT 模式。这种配置也不行。请告知需要进行的更改以及更改路径。 谢谢  罗比 Re: Enabling console using LPUART8 for imx93 嗨@AldoG , 我们还使用了LPUART8 问题是,启用 Optee 调试后,开发板卡死,无法启动,CFG_TEE_CORE_LOG_LEVEL=3 U-Boot SPL 2024.04(2026 年 3 月 27 日 - 04:41:39 +0000) SOC:0xa1009300 LC:0x2040010 PMIC:过驱动电压模式 Vx读取计数(2728)大于Vx阈值(1763),继续启动 DDR:3733MTS M33 准备就绪 正常启动 尝试从 BOOTROM 启动 启动阶段:主启动 图像偏移量 0x0,页面大小 0x200,ivt 偏移量 0x0 通过 ROM_API 从 0x54000 加载镜像 谢谢,此致敬礼! Rak**bleep**h Re: Enabling console using LPUART8 for imx93 你好, 很高兴它现在可以正常工作了,至于图像兼容性,我认为不行,因为即使处理器实际上是另一个处理器的降级版,也需要为 i.MX91 创建自己的图像,但您可以重复使用几乎所有的更改。 此致敬礼/Saludos, 阿尔多。 Re: Enabling console using LPUART8 for imx93 谢谢@AldoG , 现在可以正常运行了。i.mx93 镜像是否可与 imx91 镜像兼容? 谢谢! 罗比。 Re: Enabling console using LPUART8 for imx93 你好, 你的所有更改都是正确的,你缺少一些配置,无法在外部设备上启用时钟,因为在启动时,默认情况下时钟是关闭的。 在 /arch/Arm/mach-imx/imx9/native/clock.c 在 mxc_get_clock(enum mxc_clock clk) 函数中添加: 返回 ccm_clk_root_get_rate(LPUART8_CLK_ROOT); 在 void init_uart_clk(u32 index) 函数中添加: case LPUART8_CLK_ROOT: /* 24M */ ccm_lpcg_on(CCGR_URT8, false); ccm_clk_root_cfg(LPUART8_CLK_ROOT, OSC_24M_CLK, 1); ccm_lpcg_on(CCGR_URT8, true); 休息; 另请参阅板 /freescale/imx93_evk/imx93_evk.c 在函数 int board_early_init_f(void) 中添加: init_uart_clk(LPUART8_CLK_ROOT); 这些更改已由同事完成并测试,在 EVK 上运行正常。 此致敬礼/Saludos, 阿尔多。 Re: Enabling console using LPUART8 for imx93 谢谢@AldoG , 对于响应,i.MX93 EVK 使用 LPUART1 作为默认控制台端口,但我的定制板配置为使用 LPUART8。我需要将控制台从 LPUART1 更改为 LPUART8,并在 J1001 头文件中进行检查。为此,我做了以下修改: u-boot-imx: 添加了 lpuart8 节点,并禁用了 lpuart1 和 iomux。 在 /configs/imx93_evk.h 中将“console= ttyLP7 ,115200 earlycon\0”从 ttyLP0 更改为“文件。 额外 static iomux_v3_cfg_t const uart_pads[] = { // MX93_PAD_UART1_RXD__LPUART1_RX | MUX_PAD_CTRL(UART_PAD_CTRL), // MX93_PAD_UART1_TXD__LPUART1_TX | MUX_PAD_CTRL(UART_PAD_CTRL), MX93_PAD_GPIO_IO13__LPUART8_RX | MUX_PAD_CTRL(UART_PAD_CTRL), MX93_PAD_GPIO_IO12__LPUART8_TX | MUX_PAD_CTRL(UART_PAD_CTRL), };在 /imx93_evk/imx93_evk.c文件。 linux-imx: 添加了 lpuart8 节点,并禁用了 lpuart1 和 iomux。 imx-atf: /include/platform_def.h 文件中的 IMX_LPUART_BASE 从 U(0x44380000) 更改为 U(0x426a0000)。 元尺度: 在 /conf/machine/imx93-11x11-lpddr4x-evk.conf 中更改 SERIAL_CONSOLES = "115200;ttyLP7",该文件包含头文件 /conf/machine/include/imx93-evk.inc。 optee-os: 将 set(CFG_UART_BASE UART1_BASE) 改为 set(CFG_UART_BASE UART8_BASE)。 如需更多信息,请添加包含更改图片的压缩文件夹。请仔细阅读并告知我最新情况。 谢谢! 罗比 谢谢  罗比 Re: Enabling console using LPUART8 for imx93 你好, 能否分享一下您所做的更改,以便我检查是否正确? 另外,请分享一下您正在使用的Linux版本。 此致敬礼/Saludos, 阿尔多。 Re: Enabling console using LPUART8 for imx93 请帮忙解决这个问题,我已经修改了所有路径。
記事全体を表示
RT1170 NVCC_XXX power sequence and unsued IO banks Hello, 1 - Im asking whether is it safe to power down unused IO banks NVCC_XXX while the DCDC_IN and Pswitch are ON(cores also are ON), given that none of the unused IO bank pins are driven externally.  2 - Also whether is it ok to keep an IO bank ON to maintain IO state, while the other banks off? Thanks in advance Re: RT1170 NVCC_XXX power sequence and unsued IO banks Hello @Marwan, I understand that you are considering disconnecting the power supply of an unused power group. Is my understanding correct? The best practice is to keep the corresponding NVCC_xxx supply powered and leave the unused GPIOs floating. However, the RT1170 includes a flexible power architecture that allows certain domains to be powered down to reduce overall power consumption. I recommend consult the AN13148, which provides a detailed explanation of the RT1170 power architecture and the low-power architecture design. AN13104 is also a useful reference, as it provides useful information about the power domains and LP states. Additionally, if you are developing a custom board, I highly recommend see the Hardware Development Guide for the MIMXRT1160/1170. This document provides information about board layout recommendations and design checklists to ensure first-pass success and avoid board bring-up issues. BR Habib Re: RT1170 NVCC_XXX power sequence and unsued IO banks Appreciate your reply and references, That's correct I would like to keep some IO bank off if not used, Although it is not clearly mentioned that it is not recommended, this is what I understand between the lines of the referred documents.  Regarding the second question: What about making the IO bank always on (to maintain the IOs state and not to be driven externally) while the DCDC_IN and DCDC_PSWITCH are off(grounded), (all domains are off except SNVS and the IO banks), is it ok? The MCU is not the host, hence why I ask this is to prevent the IOs to be driven externally while the MCU in SNVS mode. Kind regards, Marwan Re: RT1170 NVCC_XXX power sequence and unsued IO banks Hello @Marwan, Thank for the clarification. To help me better understand your question, could you please clarify me what you referring when you mention "making the IO bank always on"? Are you referring to keeping the associated NVCC_xxx supply rail continuously powered for each I/O bank? The best practice is to keep the corresponding NVCC_xxx supply powered and leave the unused GPIOs floating. I highly recommend use the Setpoint feature since it makes the power mode switch simpler and safer. Regarding the possibility of keeping only the SNVS supply active while disabling the DCDC. If your application requires to use the M7 and does not use an external PMIC. Disabling the DCDC is not possible, since the M7 resides in the WAKEUPMIX domain, which is powered by VDD_SOC_IN and is directly supplied by the DCDC, as mentioned in the Chapter 2 "RT1170 Power Domains" of AN13104. If your goal is to minimize power consumption, you may consider using Setpoints to transition the device into a low-power state while keeping only the SNVS domain powered, please refer to the table 4.1.5 "Typical power mode supply currents" of the datasheet to see different Setpoint configurations. Additionally, AN13104 includes a practical example demonstrating how configure a Wakeup source. You may find the chapter 4.9 "Wakeup source configuration", useful as a reference for your implementation. Finally, regarding to maintain the IO states, the SSARC could be useful. As default if the power mix which the peripheral belongs to is powered down, the peripheral configuration is lost and cannot be used directly until it is reinitialized. But with the SSARC you can save the registers of functional modules in memory before power-down and restores the registers from memory after the module is powered on, as mentioned the chapter 4.14 "Peripherals state after wakeup" of the AN13104. You can find an SDK example which shows the peripheral functionality called "ssarc_software_trigger_cm7" that you could take as reference. BR Habib Re: RT1170 NVCC_XXX power sequence and unsued IO banks Hello @Marwan,   I understand that you plan to use an external PMIC. Is my understanding correct? In that case, please refer to the AN13213, which describes how to interface an external PMIC with the RT1170, specifically the PF5020, the PMIC recommended in the chapter 3.2 "Using External PMIC" of the Hardware Development Guide for the MIMXRT1160/1170. In this app note the recommended connections are the following:   Habib_MS_1-1784839522098.png I would also recommend reviewing Tables 2 and 3 of the Hardware Development Guide, as they provide useful guidance on external PMIC usage as well as recommendations related to the SNVS domain. Additionally, you may find the SDK example power_mode_switch_bm_pmic_rt1xxx_core0 helpful. This example demonstrates the use of an external PMIC together with setpoint configurations to transition between different low-power states. Please take a look at the README files for details about how the example works. Finally, I recommend reviewing chapter 4.13 "Peripheral State in a Low-Power Mode" of AN13104, which explains the behavior of peripherals when the device is in low-power state. BR Habib Re: RT1170 NVCC_XXX power sequence and unsued IO banks Thanks for further explanation, kindly check the attached diagram: power diagram.png My goal is to go for SNVS mode(everything after the switch is off), and keep NVCC_XX also on to maintain state of other circuitry, is this possible or it will cause damage to the RT1170 MCU? I know that by keeping NVCC_XX on, I need to properly configure the IOs to prevent extra leakage currents. Kind regards and appreciate your assistance. Re: RT1170 NVCC_XXX power sequence and unsued IO banks No I will not use external PMIC the shared block diagram is good for me, I just need to ensure that NVCC_XXX power can be ON while DCDC_IN and is off (grounded) in when MCU is in SNVS mode.  is this possible? Kind regards Re: RT1170 NVCC_XXX power sequence and unsued IO banks Hello @Marwan, Yes, the NVCC_xxx rails can remain powered from an external supply, as shown in Figure 14-2, "Power Architecture" of the RM:   Habib_MS_1-1785189559143.png However, please keep in mind that in this configuration the DCDC supply must also remain present, as it provides power to the WAKEUPMIX domain, where the CM7 resides. Additionally, please ensure that the power-up sequence described in Section 4.2.1 "Power Supplies Requirements and Restrictions" of the datasheet is correctly implemented to avoid any unexpected behavior. Finally, I highly recommend see the Hardware Development Guide for the MIMXRT1160/1170. This document contains important design guidelines, layout recommendations, and hardware checklists that can help ensure a successful board design and avoid potential bring-up issues. BR Habib Re: RT1170 NVCC_XXX power sequence and unsued IO banks So what I understand, is that it is not recommended to power some IO Banks ON and leave the Others OFF.  Also, it is better to power everything down and keep SNVS bank on for better power consumption at sleep. Thanks for your effort
記事全体を表示
Question about C16 capacitor rating in MRF300AN 27MHz reference design Hello NXP Support Team, I am currently reviewing the MRF300AN 27MHz reference design and have a question regarding capacitor C16 on the output side. According to the BOM I have (e.g., from the Farnell datasheet), C16 is specified as a 39,000 pF (39 nF) / 50V chip capacitor (ATC part 200B393KT50XT). Given that the MRF300AN operates at a 50V drain voltage and the output stage handles high RF power (up to 300W+), I am concerned that a 50V-rated capacitor in this position might be insufficient for reliable long-term operation. My questions are: Is the 50V rating for C16 in the BOM correct, or could it be a typo? What is the exact function of C16 in this circuit? Is it part of the output matching network, a DC blocking capacitor, or a bypass/decoupling capacitor? If it is indeed a DC blocking or matching capacitor in the RF output path, wouldn't a higher voltage rating (e.g., 100V or higher) be more appropriate to handle voltage transients and standing waves? I would greatly appreciate your clarification on this matter. Thank you for your time and support. Best regards, Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design Hello fengyuqi Good day! The 300W does not directly determine the voltage stress on a capacitor. The capacitor voltage rating must be compared against the actual RF voltage across that capacitor, not against the amplifier output power. C16 is not necessarily seeing the full RF output voltage. From the reference design BOM, C16 belongs to the supply decoupling / RF bypass network, not directly across the 50 Ω output connector I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design Dear RafaR, Thank you for your detailed and helpful response. I truly appreciate the time you took to explain the voltage stress consideration on capacitors. I would like to acknowledge that you are absolutely right — the voltage across C16 is not as high as the full RF output voltage, since the voltage stress depends on the actual RF voltage across the component rather than the amplifier's output power. I fully accept this point. However, I would like to clarify one thing regarding C16. After double-checking the PCB layout I have, C16 does appear to be the DC blocking capacitor placed before the RF output, assuming all traces are routed on the top layer. I understand this might differ from the BOM's designation in your documentation, but based on the layout files I currently have access to, this is what I observe. The materials I have downloaded so far include only the PCB layout files and a brief summary document — I do not have access to the full schematic, detailed BOM with component functions, or the complete reference design user guide. Would it be possible for you to share more detailed documentation for this reference design, such as: The full schematic The complete BOM with component function descriptions The reference design user manual or application note I would be extremely grateful for any additional materials you could provide. If there are any restrictions on sharing these files, please also let me know so I can request them through the proper channel. Thank you again for your guidance, and I look forward to your reply. Best regards, fengyuqi Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design Hello fengyuqi Good day! Unfortunately NXP documentation pack for this design does not include a schematic. It is our general practice since most RF designs are sensitive to board layout. Thus, the layout view plus BOM provides more reproducible results than a pure schematic. If you need, you can draw the schematic by yourself using layout and BOM. Unfortunately we do not have a reference design for MRF300 in the 27MHz band. The documentation we can recommend is that found on our official website in the "Design Resources" section: RafaR_0-1784737806340.png However, this design has been implemented for quite a few years, so I can assure you that the BOM listed in the documentation we provide is correct. I hope this information has helped you, please let me know if you need help with anything else. We apologize for any inconvenience this may cause you. Have a great day and best of luck. Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design Dear RafaR, Thank you very much for your previous reply and for sharing the design resources. I have reviewed the layout and BOM as you suggested, and I am now preparing to build my own prototype. Before I proceed, I would like to ask a few specific questions regarding component selection and potential modifications: Capacitor substitution – Some ATC capacitors listed in the BOM are difficult to source in my region. I am considering using Vishay RF capacitors with similar key specifications, for example, 39 pF, C0G/NP0 dielectric, and the same voltage rating. In your experience, would this be a safe replacement, provided that other parameters like ESR, Q factor, and self‑resonant frequency are comparable? Are there any additional hidden characteristics I should pay extra attention to? Value change for C10 – In my ADS simulation, I found that replacing C10 with a 200 pF capacitor gives a noticeable improvement in efficiency. Would you recommend making this change on the actual board? If so, are there any stability or thermal concerns I should evaluate before doing so? Debugging approach – Since the schematic is not provided, I plan to use the layout and BOM as my primary references. I assume that minor discrepancies in my understanding of the circuit can be resolved through practical tuning and measurements on the prototype. Is this a reasonable approach in your view, or do you foresee any major risks? I truly appreciate your time and guidance. Please feel free to let me know if any of these questions need further clarification. Have a great day and best regards, fengyuqi Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design Hello fengyuqi Good day! Capacitor substitution Unfortunately, NXP doesn't have any recommended replacements, and I haven't had the opportunity to experiment with components other than those listed in the BOOM, so we can't guarantee their functionality. However, based on my research, the replacements sound feasible, only if the parameters you mentioned earlier are equivalent. I would also consider the package geometry and heat dissipation, if possible. Value change for C10 Go ahead if you've already run the simulation and see improvement, continue. Debugging approach Sure, I think it's a good approach; often, small errors can be fixed by making minor modifications to the layout, so I don't see any risk in doing it this way. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck.
記事全体を表示
i.MX8M Plus DDR4-3200 EVK Design file and DDR4 layout guide Hi , We want to design our product with i.MX8M Plus+DDR4.  Can NXP provide the design file(sch & .brd) of i.MX8M Pluse+DDR4-3200 and DDR4 layout giude doc to us? Re: i.MX8M Plus DDR4-3200 EVK Design file and DDR4 layout guide I am working on same approch.  FYI. The AI Robot Platform Based on i.MX 8M Plus  The "I-MX8MPLUS-ALROBOT-FORM" is DDR4 reference design.  You have to contact NXP to get access to those.  Re: i.MX8M Plus DDR4-3200 EVK Design file and DDR4 layout guide @seungyeon I already email and attach it to you, please have a check.
記事全体を表示
PN7221 无法检测到 ISO 14443-3B 我们按照文档AN14880 PN7160/PN7220 - Android 16 移植指南移植了 PN7221。测试过程中,无法检测到 ISO 14443-3B (NfcB) 卡。此外,轻触此类卡片后,NFC 功能出现故障,无法识别任何卡片。需要将 NFC 关闭再重新打开才能恢复正常运行。相关日志附在下方,供您分析。 ❯ 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.515 530 6384 D NxpNciR : len = 26 > 61051701010001FF010C0B00000000D103860500808001000000 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.516 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: RF接口 = 帧 RF 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: 协议 = 未知 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: 模式 = B 被动轮询 07-16 09:24:28.516 530 6387 D NxpHal : NCI NTF: RF_DEACTIVATED len=26 type=1 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... 07-16 09:24:28.517 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id 已发送至 lower =0 07-16 09:24:28.517 530 542 I android.hardware.nfc2-service.nxp:写 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - 写入请求..... 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - 调用 I2C 写入..... 07-16 09:24:28.519 530 6385 D NxpNciX : 长度 = 12 > 0000091D0000000000080100 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - I2C 写入成功..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - 发布新消息..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - Tml 写入线程正在运行................ 07-16 09:24:28.519 530 6387 D NxpHal : 写入成功 状态 = 0x0 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.520 530 6384 D NxpNciR:长度 = 6 > 600603010001 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.521 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.521 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.523 530 6384 D NxpNciR:长度 = 5 > 0000020000 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.523 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.524 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:WAIT_ENDEF_FILE_CTRL_TLV (17) 07-16 09:24:28.524 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id 已发送至 lower =0 07-16 09:24:28.524 530 542 I android.hardware.nfc2-service.nxp:写 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - 写入请求..... 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - 调用 I2C 写入..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... 07-16 09:24:28.525 530 6385 D NxpNciX : 长度 = 8 > 0000050036000008 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - I2C 写入成功..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - 发布新消息..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - Tml 写入线程正在运行................ 07-16 09:24:28.525 530 6387 D NxpHal : 写入成功 状态 = 0x0 07-16 09:24:28.527 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.527 530 6384 D NxpNciR:长度 = 6 > 600603010001 07-16 09:24:28.528 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.528 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.528 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... 07-16 09:24:28.531 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.532 530 6384 D NxpNciR : len = 14 > 00000B21CBA4729CB97166900000 07-16 09:24:28.532 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.532 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.533 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:???? 未知子状态 (18) 07-16 09:24:28.533 1599 6381 我 libnfc_nci: nfa_rw_update_pupi_id: 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... Re: PN7221 fails to detect ISO 14443-3B 我们已经升级到 3.2.5 版本,但测试结果仍然没有改变。 07-17 01:13:52.157 533 542 D NxpHal : 设备上检测到的固件版本 = 0x30205 Re: PN7221 fails to detect ISO 14443-3B 你好@zhangkai 请更新至 3.2.5 版本,您可以通过以下路径获取固件文件: nfc-NXPNFCC_FW/InfraFW/pn7220 at master · NXP/nfc-NXPNFCC_FW Re: PN7221 fails to detect ISO 14443-3B 06-24 10:20:33.259 390 401 D NxpHal : 设备上检测到的固件版本 = 0x302c4 Re: PN7221 fails to detect ISO 14443-3B 你好@zhangkai 固件版本是多少?如果版本低于 3.2.5,请更新到最新版本并再次测试。 如果还有疑问,请向我们提供完整日志。 Re: PN7221 fails to detect ISO 14443-3B 你好@zhangkai 能否提供 libnfc-nci.conf 和 libnfc-nxp.conf 文件? Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  此问题可能与A16的变更有关。具体而言:在A15之前,NXP的MW依赖NFA_PROTOCOL_T3BT(80)来支持身份证,但A16通过Google已将中国身份证直接纳入其支持范围。然而,PN7xxx的MW仍保留了该代码。因此,客户尝试将T3BT逻辑从PN7xxx MW中完全移除,并直接使用Google的原生逻辑。 KaiLi_0-1784790560099.png Re: PN7221 fails to detect ISO 14443-3B 配置文件已上传。
記事全体を表示