Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
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 配置文件已上传。
記事全体を表示
IO Expansion for LEDs I am currently designing on a switch matrix board for custom measurement equipment. To route the signals I plan on using optical relays, the G3VM-61DR1 to be precise. So I need to control >250! LEDs (1,5-1,8V 6-8mA) somehow. Only <25 will be turned on at the same time Supply voltage will be 3.3V or lower, temperature should be around 40°C We just need to turn them on or off, no dimming or PWM I don't want to use an LED driver because of the noise it might/will introduce I can't use a classic matrix arrangement since it is unknown which switches will be on at the same time So the only option is to have a discrete output for each relay/LED, your IO Expanders look promising for this, eg. the PCAL6524. Because of the high channel count I want to reduce the components per channel as much as possible, so I have some questions: Can I rely on the 7,5mA current setting of the Agile IO devices and omit the LED series resistor? If this is ok, what are possible side effects? Since the devices start configured as Input some experience high currents when they are used to control LEDs(eg. PCA9535A  Datasheet page 14/15). The classic fix with a pullup for each channel is not cool for so many channels. Does this also affect the Agile IO devices? Can this be circumvented by supplying the LEDs with 3.3V and the expanders with 1.65V? Thank you in advance Otto Re: IO Expansion for LEDs PCAL6524 is well suited for driving a large number of optical relays and LEDs. However, the Agile I/O drive strength is not intended to replace the required series current-limiting resistors. To mitigate the risk of unintended current during power-up when the I/Os are still in their input state, options such as using a 3.3 V LED supply with a lower VDD(P), or implementing a global LED power switch, may be considered. Nevertheless, individual current-limiting resistors should always be retained for each LED channel.
記事全体を表示
Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping Hi everyone, We are currently setting up a prototyping and test bench for a 12V automotive project. Following NXP's recommendation, we selected the MC33XS2410 (eFuse) for our protection circuit. However, since we are in an assembly workshop and cannot design or manufacture custom PCBs at this stage, handling the HTSSOP28 package (with its 0.65mm pitch and thermal pad) is physically challenging for hand-wiring. While we are aware of the full-featured FRDM-XS2410EVB evaluation board, it is too complex, too large, and too expensive for our immediate needs on this specific test bench. We only need a minimal way to access the pins. Before we purchase a generic third-party adapter (like the Aries Electronics LCQT-TSSOP28 breakout board), we wanted to ask the NXP community: Does NXP offer a low-cost, minimal breakout board or prototyping adapter specifically designed to convert the HTSSOP28 package of the MC33XS2410 into standard 2.54mm DIP pins? If not, does NXP officially recommend any specific third-party adapter or socket brand that has been proven to work well with this chip (considering the ground and thermal dissipation requirements of the exposed center pad)? Thank you very much for your time and help! Evaluation Board StarCore DSPs Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping Thank you Tomas for the clarification and the precautions , i think that's the solution that i will do for my cards Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping Hello Mohamed, Currently we do not offer a dedicated low-cost breakout or adapter board that converts the MC33XS2410 HTSSOP28 package directly to a standard 2.54 mm DIP-style footprint. You are right that we offer the FRDM-XS2410EVB, which is intended for full functional evaluation rather than simple package adaptation. One important consideration is the exposed thermal pad of the MC33XS2410 package which should be soldered to GND for both thermal and electrical performance. We also recommend connecting the exposed pad to a ground plane and, for production designs, using thermal vias to improve heat dissipation. Please also note that generic breakout boards are generally suitable for functional prototyping and low-power bench testing. However, they typically do not provide the thermal performance achievable with a properly designed PCB, which may limit the maximum continuous current that can be tested.  If your application requires operation near the device's current limits, I recommend evaluating the thermal performance carefully or using the official evaluation board. BRs, Tomas
記事全体を表示
27MHzリファレンス・デザインにおけるC16コンデンサ定格に関する質問MRF300AN こんにちは、NXPサポートチームの皆さん、 現在、MRF300AN 27MHzのリファレンスデザインをレビューしており、出力側のコンデンサC16について質問があります。 私が持っているBOM(例:Farnellのデータシート)によると、C16は39,000 pF(39 nF)/50Vチップコンデンサ(ATC部品200B393KT50XT)と指定されています。MRF300ANは50Vのドレイン電圧で動作し、出力段は高RFパワー(最大300W+)を処理するため、この位置で50V定格のコンデンサでは長期的な安定した動作には不十分ではないかと懸念しています。 私の質問は以下のとおりです。 BOMのC16の50V定格は正しいのでしょうか、それとも誤字かもしれませんか? この回路におけるC16の正確な役割は何ですか?それは出力整合回路の一部ですか?それとも直流阻止コンデンサですか?あるいはバイパス/デカップリングコンデンサですか? もし本当にRF出力経路にDCを遮断したりコンデンサを合わせているなら、電圧の過渡現象や定在波を処理するには、より高い電圧定格(例えば100V以上)の方が適切ではないでしょうか? この件についてご説明いただけると大変ありがたいです。お時間をいただき、サポートありがとうございます。 よろしくお願いいたします。 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design こんにちは、フォンユチー 良い一日! 300Wという電力は、コンデンサにかかる電圧ストレスを直接決定するものではありません。 コンデンサの電圧定格は、そのコンデンサ両端の実際のRF電圧と比較し、アンプ出力電力と比較するのではありません。 C16は必ずしもRF出力電圧を完全に受信しているわけではありません。 リファレンス・デザインBOMによると、C16は電源デカップリング/RFバイパスネットワークに属しており、50 Ω出力コネクタを直接挟んでいたわけではありません この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 親愛なるRafaR様、 詳細かつ有益なご回答をありがとうございました。コンデンサにかかる電圧ストレスについて時間をかけて説明していただき、本当に感謝しています。 あなたの言う通り、C16両端の電圧はフルRF出力電圧ほど高くありません。なぜなら電圧ストレスはアンプの出力電力ではなく、部品両端の実際のRF電圧に依存しているからです。この点については全面的に同意します。 しかし、C16に関して一点明確にしておきたいことがあります。持っているPCBレイアウトを再確認したところ、C16はすべてのトレースが最上層に配線されていると仮定して、RF出力の前にDCブロッキングコンデンサが設置されているようです。これはあなたのドキュメントにおけるBOMの指定とは異なるかもしれませんが、私が現在アクセスできるレイアウトファイルから判断すると、私が観察しているのはこうです。 これまでにダウンロードした資料にはPCBレイアウトファイルと簡単な要約文書のみが含まれており、完全な回路図やコンポーネント機能付きの詳細なBOM、または完全なリファレンスデザインユーザーガイドにはアクセスできません。 このリファレンスデザインのより詳細なドキュメントを共有できるでしょうか。例えば: 完全な回路図 コンポーネント機能記述を含む完全なBOMです リファレンスデザインユーザーマニュアルまたはアプリケーションノート 追加の資料をいただけると大変ありがたいです。これらのファイルの共有に制限がある場合は、適切なチャネルを通じてリクエストできるように、私にもお知らせください。 ご指導いただき、改めて感謝申し上げます。お返事をお待ちしております。 よろしくお願いします、 豊玉旗 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design こんにちは、フォンユチー 良い一日! 残念ながら、この設計のNXPドキュメントパックには回路図が含まれていません。ほとんどのRFデザインは基板の配置に敏感であるため、これが私たちの一般的な運用です。したがって、レイアウト図と部品表を組み合わせることで、純粋な回路図よりも再現性の高い結果が得られる。必要なら、レイアウトとBOMを使って自分で回路図を描くこともできます。 残念ながら、27MHz帯のMRF300に関するリファレンスデザインは存在しません。 私たちが推奨できるドキュメントは、公式ウェブサイトの「デザインリソース」セクションにあります。 RafaR_0-1784737806340.png しかし、この設計はかなり前から実装されているため、提供するドキュメントに記載されているBOMは正しいと保証できます。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 ご迷惑をおかけして申し訳ございません。 良い一日をお過ごしください。幸運を祈ります。 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 親愛なるラファーへ、 前回のご返信とデザインリソースの共有、本当にありがとうございます。ご指摘いただいたとおり、レイアウトと部品表を確認しましたので、現在、試作品の製作準備を進めています。先に進む前に、部品の選定と潜在的な変更点に関して、いくつか具体的な質問をさせてください。 コンデンサの代替品 – 部品表に記載されているATC製コンデンサの中には、私の地域では入手が困難なものがあります。例えば、39 pF、C0G/NP0誘電体、同じ電圧定格のVishay RFコンデンサの使用を検討しています。あなたの経験から、ESR、Q値、自己共振周波数などの他のパラメータが同等である場合、これは安全な代替品と言えるでしょうか?他に特に注意すべき隠れた特徴はありますか? C10の値の変更 – 私のADSシミュレーションでは、C10を200pFのコンデンサに交換すると、効率が著しく向上することがわかりました。この変更を実際のボードで行うことをお勧めしますか?もしそうなら、その前に安定性や熱的な懸念点はありますか? デバッグのアプローチ – 回路図が提供されていないため、レイアウトとBOMを主な参照として使う予定です。回路の理解における小さな不一致は、試作機の実用的なチューニングや測定によって解決できると考えています。これは妥当なアプローチだとお考えですか?それとも、何か大きなリスクを懸念されていますか? お時間を割いてご指導いただき、本当に感謝しております。これらの質問についてさらに詳しい説明が必要な場合は、遠慮なくお知らせください。 良い一日をお過ごしください。よろしくお願いいたします。 豊玉旗 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design こんにちは、フォンユチー 良い一日! コンデンサ置換 残念ながら、NXPには推奨される代替品がなく、BOOMに記載されている以外の部品を試す機会もなかったため、その機能を保証することはできません。 しかし、私の調査に基づくと、先に述べたパラメータが同等である場合に限り、代替案は実現可能であると思われます。可能であればパッケージの形状や散熱も考慮すべきです。 C10の値変更 既にシミュレーションを実行して改善が見られた場合は、そのまま続行してください。 デバッグ方法 確かに、それは良いアプローチだと思います。小さなミスでもレイアウトを少し修正すれば直せることが多いので、この方法でやってもリスクはないと思います。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。
記事全体を表示
S32 Design Studio for ARM 2018.R1 已过期。 S32 Design Studio for ARM 2018.R1 的许可证已过期。 另外,请与我们联系是否有单独的许可证续期或重新激活程序。 Re: S32 Design Studio for ARM 2018.R1 has expired. 你好, 您的S32DS许可证已延期。 Re: S32 Design Studio for ARM 2018.R1 has expired. 它与之前的许可证激活码相同。 但它仍然没有通过。
記事全体を表示
RT1170 NVCC_XXX電源シーケンスと未使用のIOバンク こんにちは、 1 - 未使用の IO バンク NVCC_XXX の電源を、DCDC_IN と Pswitch がオン (コアもオン) の状態でオフにしても安全かどうかを尋ねています。未使用の IO バンク ピンは外部から駆動されていないものとします。 2 - また、他のIOバンクをオフにした状態で、IO状態を維持するためにIOバンクを1つだけオンにしておくことは問題ないでしょうか? 前もって感謝します Re: RT1170 NVCC_XXX power sequence and unsued IO banks こんにちは、@Marwan。 未使用の電源グループの電源を切断しようと考えていると理解しています。私の理解は正しいでしょうか? 最適な方法は、対応するNVCC_xxx電源を常時供給し、使用されていないGPIOをフローティング状態にしておくことです。しかし、RT1170は柔軟なPower Architectureを備えており、特定のドメインをダウンして全体の消費電力を削減できます。 RT1170の電源アーキテクチャと低消費電力アーキテクチャ設計について詳しく説明されているAN13148を参照することをおすすめします。AN13104も有用な参考資料であり、電力ドメインとLP状態に関する有用な情報を提供しています。 さらに、カスタムボードを開発する場合は、 MIMXRT1160/1170 のハードウェア開発ガイドを参照することを強くお勧めします。この文書は、ファーストパス成功を確保し、ボードのブランクアップ問題を避けるためのボードレイアウト推奨事項やデザインチェックリストに関する情報を提供します。 BR ハビブ Re: RT1170 NVCC_XXX power sequence and unsued IO banks ご返信と参考資料をありがとうございます。 その通りです。使用しないIOバンクはオフにしておきたいのですが、推奨されないとは明確に記載されていませんが、参照した文書の行間から私が理解した内容はそういうことです。 2つ目の質問について: DCDC_IN と DCDC_PSWITCHが オフ(接地)になっている間(SNVSとIOバンクを除くすべてのドメインがオフになっている間)、IOバンクを 常にオン (IOの状態を維持し、外部から駆動されないようにするため)にしておくのはどうでしょうか? MCUはホストではないので、この質問をするのは、MCUがSNVSモードの間、IOが外部から駆動されるのを防ぐためです。 敬具 マルワン Re: RT1170 NVCC_XXX power sequence and unsued IO banks こんにちは、 @Marwan さん。 ご説明ありがとうございます。 ご質問をよりよく理解するために、「IOバンクを常にオンにする」という言葉で、具体的に何を指しているのか教えていただけますか?各I/Oバンクに関連付けられたNVCC_xxx電源レールに継続的に電力を供給することを指しているのでしょうか? 最適な方法は、対応するNVCC_xxx電源を常時供給し、使用されていないGPIOをフローティング状態にしておくことです。Setpoint機能を使うことを強くおすすめします。パワーモードスイッチがより簡単で安全になります。 DCDCを無効にしつつ、SNVS電源のみをアクティブにする可能性について。もしあなたのアプリケーションがM7を使う必要があり、外部PMICを使わない場合は、DCDCを無効にすることはできません。M7はWAKEUPMIXドメインに属しており、このドメインはVDD_SOC_INによって電源供給され、 AN13104の第2章「RT1170電源ドメイン」で述べられているようにDCDCによって直接供給されているからです。 消費電力を最小限に抑えることが目的であれば、SNVSドメインのみに電力を供給したまま、デバイスを低電力状態に移行させるためにSetpointsを使用することを検討してください。詳細については、表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 詳しい説明をありがとうございます。 添付の図をご確認ください。 power diagram.png 私の目標は SNVSモード(スイッチ以降はすべてオフ)にして、他の回路の状態を維持するためにNVCC_XX SNVSもオンにしておくことです。 これは可能でしょうか、それとも RT1170のMCUにダメージを与えますか? NVCC_XXをオンにしたままにする場合、余分なリーク電流を防ぐためにIOを適切に設定する必要があることは理解しています。 よろしくお願いいたします。ご協力に感謝いたします。 Re: RT1170 NVCC_XXX power sequence and unsued IO banks こんにちは、 @Marwan さん。 外部PMICを使用する予定だと理解しています。私の理解は正しいでしょうか? その場合は、外部PMICをRT1170、特にPF5020と外部PMICのインターフェース方法を説明している AN13213を参照してください。PF5020は、Hardware開発ガイドMIMXRT1160の第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 こんにちは、 @Marwan。 はい、NVCC_xxxレールは外部電源から電力を供給し続けることができます。図14-2「RMのPower Architecture」に示されています。   Habib_MS_1-1785189559143.png ただし、この構成では、CM7が存在するWAKEUPMIXドメインに電力を供給するため、DCDC電源も引き続き必要となることにご注意ください。さらに、予期せぬ動作を避けるため、データシートのセクション4.2.1「電源の要件と制限」に記載されている電源投入シーケンスが正しく実装されていることを確認してください。 最後に、 MIMXRT1160/1170のハードウェア開発ガイドを参照することを強くお勧めします。この文書には、成功するボード設計を確保し、故障を防ぐための重要な設計ガイドライン、レイアウト推奨事項、ハードウェアチェックリストが含まれています。 BR ハビブ Re: RT1170 NVCC_XXX power sequence and unsued IO banks いいえ、外部PMICは使いません。共有されたブロック図は私には合っています。ただ、DCDC_IN中は 電源がオンで、MCUがSNVSモードNVCC_XXX時はオフ(接地)されているか確認したいだけです。 これは可能ですか? 敬具 Re: RT1170 NVCC_XXX power sequence and unsued IO banks 私の理解では、一部のIOバンクはオンにして他はオフにするのは推奨されていません。 また、スリープ時の消費電力を抑えるためには、すべての機器の電源を切り、SNVSバンクだけをオンにしておく方が良いでしょう。 ご尽力いただきありがとうございます。
記事全体を表示
S32K148EVB-Q176 received with UJA1131 instead of UJA1132 Hi, I recently bought an S32K148EVB-Q176 board. According to the documentation and schematics, I expected it to come with a UJA1132, but the board I received has a UJA1131. Because of this, I only have one LIN interface, while I was expecting the features of the UJA1132. I just wanted to ask if this is normal. Are there different versions of the S32K148EVB-Q176 with different SBCs, or did I receive the wrong board? Thank you! Re: S32K148EVB-Q176 received with UJA1131 instead of UJA1132 Hello @sousou54, Thank you for the report. This issue is currently under investigation. Could you please provide a photo of the large white label located on the product box? The information on this label can help us identify the manufacturing details of the board. Since the label may contain product-specific information, you can share the photo through a private message or by opening a support case (Support) rather than posting it publicly. Best regards, Julián Re: S32K148EVB-Q176 received with UJA1131 instead of UJA1132 Hello @sousou54, Just to inform you, I've received your pictures, and I have forwarded to the appropriate team. I am waiting for a response. Thank you for your understanding and cooperation. Best regards, Julián Re: S32K148EVB-Q176 received with UJA1131 instead of UJA1132 Hi @sousou54, For further information on this matter, please contact your NXP representative, or distributor from which you bought this kit. They should be able to provide assistance. Best regards, Julián 
記事全体を表示