Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
[i.MX8MM] DDR PHY 训练固件日志级别:“最大调试”值并集成到 U-Boot 中 尊敬的恩智浦技术支持团队: 我们目前正在使用 MSC DDR 工具/DDR 测试工具调试我们定制的 i.MX 8M Mini 平台上的 DDR 训练问题,并希望澄清 PHY 日志级别配置。 1. 关于配置值 在 DDR 工具 GUI 中, “PHY 日志级别”下拉菜单包含以下选项: 固件已完成 断言消息 阶段完成 粗略调试 详细调试 最大调试 我们检查生成的 .ds 文件。我们注意到脚本中包含一些关于 TrainInfo 设置的注释: # 以下内容仅供工厂内部使用,强烈建议不要更改。 ddrparam 设置 TrainInfo 0x04 # 0x05 = 详细调试(例如眼部延迟) # 0x0A = 粗略调试信息(例如排名信息) # 0xC8 = 阶段完成 # 0xC9 = 断言消息 # 0xFF = 固件完成 # 其他 = 已预留 我们希望直接在 U-Boot SPL 中配置此 PHY 日志详细程度,以便在启动初期通过 UART 捕获完整的训练日志。 2. 将 PHY 日志级别移植到 U-Boot / SPL (lpddr4_timing.c) TrainInfo 日志详细程度参数能否在 DDR 时序结构中定义(例如,在 lpddr4_timing.c 或 SPL 中的 DDR PHY 初始化序列中)? 如果可以,能否请您指导我们如何将 `ddrparam set TrainInfo 0x04` 正确地集成到我们的 U-Boot 代码库中?如果您能指出 lpddr4_timing.c (或 PHY 消息块)中应该映射此参数的具体结构或寄存器,我们将不胜感激。 谢谢你的帮助。 Re: [i.MX8MM] DDR PHY Training Firmware Log Level: Value for "Maximal Debug" and Integrati 你好, Train Info 是一个 PHY 固件参数,通常不是 LPDDR4 时序结构的一部分。我不会直接添加 0x04。 Re: [i.MX8MM] DDR PHY Training Firmware Log Level: Value for "Maximal Debug" and Integrati 你好, 感谢您的回复。 在最近的测试中,我们需要使用以下PHY固件参数启用DDR训练调试信息: ddrparam 设置 TrainInfo 0x04 能否指导我们如何将此命令转换为 U-Boot SDK 中的 C 代码或将其集成到 U-Boot SDK 中(例如,特定的驱动程序结构、API 或配置定义)? 多谢。
View full article
S32K31XEVB-Q100 (S32K311) "Locked device" / Debug Authentication ID Code prompt on first debug I just received a new S32K31XEVB-Q100 board and connected a Segger J-Link to it for the very first time (via the external 10-pin SWD header, not the onboard debugger). This is a completely fresh board — the only thing I tried so far is a default RTD-generated project (Mcal.h include, stock empty main() loop), nothing related to HSE or security. On connecting, both SEGGER J-Flash and S32 Design Studio report the device as locked and pop up an "ID Code" authentication prompt:   - Unknown SDA AP Id detected: 0x00000000 - Connect failed. Trying connect under reset... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - Unlocking device if necessary... - Locked device detected. Proceeding with the unlock procedure... J-Flash then asks: "Please input the ID Code required for the authentication" (32 hex digits or 16 ASCII chars). I've never set a password on this chip. Setup: MCU shows correctly as NXP S32K311 / Cortex-M7 in J-Flash, SWD @ 4000 kHz, J-Flash V9.74, J-Link V9.74/V9.26. For comparison, my S32K144 EVB works fine with the same J-Link — no such prompt ever appears there, which I understand is because S32K1 and S32K3 use very different security models. J-Flash then asks: "Please input the ID Code required for the authentication" (32 hex digits or 16 ASCII chars). I've never set a password on this chip. Setup: MCU shows correctly as NXP S32K311 / Cortex-M7 in J-Flash, SWD @ 4000 kHz, J-Flash V9.74, J-Link V9.74/V9.26. For comparison, my S32K144 EVB works fine with the same J-Link — no such prompt ever appears there, which I understand is because S32K1 and S32K3 use very different security models. I found earlier thread with the same symptom on an S32K311, where NXP support explained there's no mass-erase-unsecure path for K3 (unlike K1) and pointed to the HSE_B Firmware Reference Manual (via Secure Files) for recovery. Questions for the community / NXP: Has anyone else seen a brand-new S32K31XEVB-Q100 arrive already debug-locked like this? Is this a known factory-test artifact on some batches? Is there a documented default/recovery password for evaluation boards specifically, as opposed to production silicon? Any pointers on requesting the HSE_B Firmware Reference Manual? Regards Any support will be appreciated:
View full article
NXP-PORT GMBHによるIMX94キットのポーティング こんにちは、 NXP-PORT GMBHのPROFINETスタックをIMX94キットに移植する予定です。 資料を探してみましたが、ほとんどがRT1180に関するものでした。 LinuxやM7、M33コアへの移植に関するドキュメントを教えてください。 ありがとう ビジャイ・ラナ ACLデジタル Re: NXP-PORT GMBH Porting on IMX94 Kit 以下のリンクをご参照ください。 https://www.nxp.com/design/design-center/software/development-software/software-for-industrial-networking/profinet-industrial-ethernet-protocol-software:PROFINET-INDUSTRIAL-COMMUNICATIONS-SOFTWARE?_gl=1*rqpmy3*_ga*MTk0NjI5NzAyNi4xNzg4NzQ0MDgx*_ga_WM5LE0KMSH*czE3ODg3NTg2ODkkbzIkZzEkdDE3ODg3NjM1MTYkajYwJGwwJGg5ODc1Nzg5NA .. Linuxルートでは、まずPROFINETFORLINUXFS、UM12408、UM12463、RN00389/RN00434、そしてPROFINETスタックライブラリパッケージから始めましょう。Linuxのファクトシートだけが、Linux用のPROFINETエンドポイントを明確に言及している唯一の情報源であり、その配信モデルはサポートNXPデバイス向けの事前コンパイル済みユーザー空間オブジェクトライブラリとプラットフォーム固有のドライバーソースとして説明されています。 i.MX94 上のM7/M33ルートについては、i.MX94 RM と PROFINET/GOAL/ICC ドキュメントを併用しますが、 AN13933 は参照パターンとしてのみ扱います。i.MX94はCortex-M7コア2基とCortex-M33コア2基を持ち、PROFINETを含む産業用イーサネットプロトコル向けに設計されていますが、Cortex-Mポーティングに関する詳細なアプリノートは、FreeRTOSとlwIPを使った8M Mini Cortex-M4 i.MX 専用です。
View full article
NXP S32M276CHABMKHSR 構造に関する質問 NXPの技術者さん、こんにちは。 こちらはMelecs Wuxiのテッドです。お会いできて嬉しいです。 S32M276 ICの構造について質問があります。(お願いします。添付ファイル(回路図 - S32M276)を参照してください。 設計はデータシートの推奨通りに行い、9ピンVDD_AE10、12ピン、25ピン、37ピンVDD_HV_Aをビーズで接続しました。私の理解では、9ピンVDD_AE10 P5V出力電圧は内部レギュレーターで生成され、その後VDD_HV_AピンのMCUダイに供給されます。 しかしL300を外したところ、その後PCBAは通常通り動作できました。 そこで質問ですが、VDD_AE10ピンとVDD_HV_Aピンは内部で接続されているのでしょうか?そうでなければ、L300システムを取り外した後もシステムが動作し続けることになり、それは理にかなっていません。 Re: NXP S32M276CHABMKHSR Structure question こんにちは、テッドさん。 L300を取り外した場合、VDD_HV_Aで測定される電圧はいくつになりますか? MCU側の電源領域VDD_HV_Aは、すべてのGPIOがVDD_HV_Aにクランプされているため、MCU側とAE側で共有されるGPIOを通じて電力供給されている可能性が高いです。言い換えれば、VDD_HV_Aはどのピンにも電圧がVDD_HV_Aより高ければ電源を供給できます。したがって、VDD_HV_A = VDD_AE10 - Vf と測定するべきであり、VDD_HV_A = VDD_AE10 と測定するべきではありません。 ありがとうございました。 BR、ダニエル Re: NXP S32M276CHABMKHSR Structure question こんにちは、ダニエルさん。 ご返信ありがとうございます。 つまり、VDD_AE10とVDD_HV_Aは内部的に繋がっているということですか? そして私はこの文の意味が理解できませんでした [そして、VDD_AE10を測ってください。- VDD_HV_Aで心室計を測定してください。- これは装置を傷つける可能性があります。] もう少し説明していただけますか? Re: NXP S32M276CHABMKHSR Structure question こんにちは、テッドさん。 AEダイはVDD_AE10を生成します。 AE側では、VDD_AE10はAEポートの電源であり、すべてのポートはVDD_AE10にクランプされます。 MCU側では、VDD_HV_AはMCUポートの電源で、すべてのポートはVDD_HV_Aにクランプされています。 これら2つの金型は相互に接続されている。 もし任意のMCUポートの入力電圧がクランプのVDD_HV_A + Vfより高ければ、VDD_HV_A領域は注入された電流によって電力供給されます。そしてVDD_AE10を測定してください。VDD_HV_AのVfを測ってください。これはデバイスを傷める可能性があります。 よろしくお願いいたします。 ダニエル Re: NXP S32M276CHABMKHSR Structure question こんにちは、ダニエルさん。 ご返信ありがとうございます。 L300を取り外した状態で、VDD_HV_Aの電圧を測定したところ4.98V、VDD_AE10の電圧を5.02Vと測定しました。 ですから、VDD_HV_AとVDD_AE10は内面的に繋がっていると言ってもいいでしょうか。 そして、それらを接続して低インピーダンスにする必要があります。 Re: NXP S32M276CHABMKHSR Structure question こんにちは、 @Ted_Qiao さん。 デザインチームにも確認しました。2つのダイ間で共有されるGPIOを介した電流注入経路に加えて、両者の間には内部監視のための接続も存在する。しかし、これらの経路は動作電流に耐えられるよう設計されていないため、外部のPCB接続が必要です。 BR、ダニエル
View full article
TJA1445:中断配置 你好, 我们使用 S32K358,搭配 TJA1445。 我们正在将 NXP TJA1145 驱动程序迁移到 NXP TJA1445,并使用 EB tresos 进行配置。 我们不使用 RXD 作为中断,但在 EB tresos 中配置 TJA 驱动程序时,我无法将其停用。 我已将唤醒支持设置为“不支持”。 我设置的是总线唤醒,我们希望通过 CAN 模式唤醒。 我们使用 INH 输出。 但在配置文件 CanTrcv_TJA14XX_PN_Ip_Cfg.h 中,有这样一条 #defineCANTRCV_TJA14XX_PN_IP_USE_IPV_ICU 它强制在依赖于“Icu_Cfg.h”的文件CanTrcv_TJA14XX_PN_icu_external_access.h中包含“Icu.h”。 但就我们而言,我们的配置中没有 ICU 模块(不需要)。 如何在不使用 RXD 中断的情况下使用驱动程序 TJA1445? 苏菲 Re: TJA1445 : interrupt configuration 你好, 为了更好地了解对 ICU 的依赖性以及生成的配置,请您提供以下信息? 目前使用的RTD版本和EB Tresos版本。 谢谢! Re: TJA1445 : interrupt configuration 你好, 我正在使用 RTD SW32K3_S32M27x_RTD_R23-11_7.0.1 TJA驱动程序:S32K3_CANTRCV_TJA14XX_PN_R21-11_1.0.0
View full article
S32K31XEVB-Q100(S32K311)「ロックされたデバイス」/デバッグ認証IDコードプロンプトが最初のデバッグで表示されます 新しい S32K31XEVB-Q100 ボードを受け取り、初めてSegger J-Linkを接続しました(オンボードデバッガではなく、外部10ピンSWDヘッダー経由で)。これは完全に新しいボードで、今のところ試したのはデフォルトのRTD生成プロジェクト(Mcal.h)だけです含まれているのは、空のメインループで、HSEやセキュリティには関係ないということです。 接続すると、SEGGER J-FlashとS32 Design Studioの両方がデバイスをロックしたと報告し、「ID Code」認証プロンプトが表示されます。   - Unknown SDA AP Id detected: 0x00000000 - Connect failed. Trying connect under reset... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - -- Identifying target device... - -- SWD selected. Executing JTAG -> SWD switching sequence... - Unlocking device if necessary... - Locked device detected. Proceeding with the unlock procedure... J-Flashは次に「認証に必要なIDコードを入力してください」(32桁の十六進数または16文字のASCII文字)を尋ねます。私はこのチップにパスワードを設定したことは一度もありません。 セットアップ:MCUはJ-Flash、SWD @ 4000 kHz、J-Flash V9.74、J-Link V9.74/V9.26でNXP S32K311 / Cortex-M7として正しく表示されます。比較のために、私のS32K144 EVBは同じJ-Linkで問題なく動作します。S32K1とS32K3はセキュリティモデルが大きく異なるため、そのようなプロンプトは一度も表示されません。 J-Flashは次に「認証に必要なIDコードを入力してください」(32桁の十六進数または16文字のASCII文字)を尋ねます。私はこのチップにパスワードを設定したことは一度もありません。 セットアップ:MCUはJ-Flash、SWD @ 4000 kHz、J-Flash V9.74、J-Link V9.74/V9.26でNXP S32K311 / Cortex-M7として正しく表示されます。比較のために、私のS32K144 EVBは同じJ-Linkで問題なく動作します。S32K1とS32K3はセキュリティモデルが大きく異なるため、そのようなプロンプトは一度も表示されません。 以前のスレッドで同じS32K311症状があり、NXPのサポートがK3には大量消去・アンセキュアパスはないと説明し(K1とは異なり)、回復のためにHSE_Bファームウェア**リファレンス・マニュアル**(Secure Files経由)を指し示していました。 コミュニティ/NXPへの質問: 新品のS32K31XEVB-Q100が、このようにデバッグロックされた状態で届いたのを見た人は他にいますか?これは一部の製造ロットで発生する、工場検査時の既知の不具合でしょうか? 評価ボード専用のデフォルトやリカバリーパスワードは文書化されていますか?生産用シリコンとは違います。 HSE_Bファームウェアリファレンスマニュアルをリクエストする際のアドバイスはありますか? よろしくお願いします。 どんなサポートでも感謝します:
View full article
S32K1 EEprom RTD 您好, 我不明白为什么我使用的 Eep_Ftfc_Example_S32K144 可以正常工作。 但如果我删除擦除和写入代码,只想读取先前存储的数据,则会出现错误"FTFC_EEP_IP_STATUS_BLOCK_INCONSISTENT" 。 我已经为设备设置了 " 保留分区 " 和 " 保留这个范围 " 从 0x100000000 到 0x1000fff。 因此,第二轮代码是 /* 初始化时钟 */ Clock_Ip_Init(&Clock_Ip_aClockConfig[0]); /* 仅在 EERAM 未分区时进行分区,代码为 0x4 */ Eep_DepartParitition(T_EEEPROM_SIZE); /* 初始化 Eep 驱动程序 */ Ftfc_Eep_Ip_Init(&EepFtfcCfg_VS_0); ///* 通过写入擦除值擦除内存 *///for (i=0; i < EEP_WRTESTPATT_SIZE; i+=4U) //{ //retjobResultType = ftfc_EEP_Ip_Ip_EP_EEP_ADD + i,FTFC_EEP_IP_PAGE_LONGWORD,FALSE);//if (FTFC_EEP_IP_IP_IP_IP_PAGE_IP_PAGE_IP_FALSE); //if (FTFC_EEP_IP_IP_IP_IP_IP_STATUS_OK! = retjobResultType) //{//Exit_Example (FALSE);//返回 0;//} //}///* 向 eeprom 设备写入一个或多个完整的 eeprom 页面 * ///for (i=0; i < EEP_WRTESTPATT_SIZE; i+=4U)/ /{/ /retjobResultType = Ftfc_EEP_Ip_Write (EPRESULTTYPE (E+=4U)//{/ /retjobResultType = Ftfc_Eep_Ip_Write EP_ERASE_START_ADD + i,dataWRTestPatt + i,FTFC_EEP_IP_PAGE_LONGWORD,FALSE); //if (FTFC_EEP_IP_STATUS_OK! = retjobResultType) //{/ /Exit_Example (FALSE);/ /返回 0;//}//} /* 比较 eeprom 内存区和应用程序数据缓冲区 */ for(i=0; i { retJobResultType = Ftfc_Eep_Ip_Compare(EEP_ERASE_START_ADD + i, dataWrTestPatt + i, FTFC_EEP_IP_PAGE_LONGWORD); if(FTFC_EEP_IP_STATUS_OK != retJobResultType) { Exit_Example(FALSE); return 0; } } 提前谢谢您。 Re: S32K1 EEprom RTD "FTFC_EEP_IP_STATUS_BLOCK_INCONSISTENT" 可能是由块加法对齐引起的,除了在初始分区时保留此范围" 从 0x10000000 到 0x1000ffffff 以外,您能否提供更多有关 EEPROM 地址设置的信息? Re: S32K1 EEprom RTD 嗨,@ck182、 一旦在 FlexNVM 上启用 EEE,应用内核就不再能直接访问 FlexNVM(备份)。此时,只能访问作为 EEPROM 的 FlexRAM。 如果 FlexNVM 是使用 EEP_FTFC_LOAD_AT_RESET_ENABLED 进行分区的,则在 RESET 后,备份闪存的内容会自动复制到 FlexRAM(EEPROM)中,并设置 EEERDY 标志。 在 main() 开始时,请确认一下: EEERDY == 1, DEPART 包含有效的分区代码,且 有效数据存在于 FlexRAM(EEPROM)中? 此致, 丹尼尔 Re: S32K1 EEprom RTD 你好 db16122, 感谢您的重播。 ck182_0-1777878996851.pngck182_0-1777878996851.pngck182_0-1777878996851.png 我对"Eep_Ftfc_Ip_Example_S32K144" 原始示例未作任何改动。 此外,我还注意到,在执行这段代码时 retJobResultType = Ftfc_Eep_Ip_Write(EEP_ERASE_START_ADD + i, dataWrTestPatt + i, FTFC_EEP_IP_PAGE_LONGWORD, FALSE); 在示例中,它在 RAM 地址 0x14000000 处写入,这是正确的,但从未在 Flex Memory 中写入"某处" 。 我希望"somethings" 不仅在 ram 中写入,而且从地址 0x10000000 开始在 Flex 内存中写入,但我从未看到任何变化。 我不明白我错在哪里 我使用的是 DS3.4 和 RDT 1.01。 谢谢! Re: S32K1 EEprom RTD 请分享用于数据闪存和 EEPROM 设置的 FlexNVM 分区代码。它可能需要知道在 1000000 和 1000FFFF 之间哪个部分被设置为 EEPROM。您可能需要根据设置读取 EEPROM 数据。 更多详情,请参阅 AN11983 使用 S32K1xx EEPROM 功能 Re: S32K1 EEprom RTD @danielmartynek,抱歉回复晚了。由于其他工作,我已经停止了 RTD EEPROM 的相关工作。 现在我已经解决了这个问题。 所有代码和 S32K144 示例都能正常工作,但问题是 PEmicro 调试器每次都会进行大规模擦除。 所以我改用了 sector erase alrgortim 算法,而不是 pflash_dflahs_eeprom algortim 算法,现在可以正常工作了。 我也尝试过保留 pflash_dflahs_eeprom 算法并保留 FlexNMV 内存,但这个方法行不通。 对你来说是否正确? 提前感谢,再次为我的回复过长道歉。 Re: S32K1 EEprom RTD 你好@ck182 , 我明白了,谢谢你的更新。 这些是PE Micro的专有算法。 请联系PE Micro技术支持。 BR,丹尼尔
View full article
MPF5301AMMA0ESのウェハー製造拠点はどこですか? MPF5301AMMA0ESのウェハー製造拠点はどこですか? 裏付けとなる書類が必要です。 Re: Where is the wafer fabrication site for MPF5301AMMA0ES お客様へ、 ウェハー製造現場に関する情報は公開できません。サポートチケット(https://support.nxp.com/)で送らせてください。あなたがどの資料のことを指しているのか分かりません。製品ページをご確認ください: https://www.nxp.com/part/MPF5301AMMA0ES;https://www.nxp.com/products/PF53 もし納品ドキュメントのことを言っているなら、部品を購入した代理店に協力してください。ありがとう。良い1日を。よろしくお願いします パブラ
View full article
Ara240 Runtime Support on x86 Linux Hi NXP Team, I am evaluating the possibility of running an Ara240 module directly on an x86 Linux host over PCIe for validation and performance testing. During my investigation, I found indications that x86 runtime support may exist: dvapi.py contains references to: art/linux/x86/lib/libaraclient_x86_64.so Optimum-Ara documentation references: $DV_TGT_ROOT/art/linux/x86/proxy/ The UIO DMA driver repository includes x86 support. Historical Kinara runtime recipes package architecture-specific runtime components using: art/linux/${TARGET_ARCH}/... However, the current imx-nxp-ara2 runtime package available through the i.MX BSP contains only AArch64 runtime binaries:   1 libaraclient_aarch64.so 2 proxy_ara240 3 nnapp 4 hardware utilities   I could not locate the corresponding x86 runtime artifacts. Could you please clarify: Is direct Ara240 runtime execution on an x86 Linux host officially supported? Is there an x86 Runtime SDK package available? Where can I obtain the following x86 runtime components? libaraclient_x86_64.so x86 proxy binary x86 dvapi runtime package Is there an integration guide or reference flow for: x86 Host ↓ UIODMA Driver ↓ Ara240 PCIe ↓ Runtime SDK ↓ Inference Execution Any guidance on obtaining the required x86 runtime components would be appreciated. Thanks, Yuvraj Solanki Re: Ara240 Runtime Support on x86 Linux Hi Yuvraj, I can confirm that Ara240 can actually run on a standard x86_64 Linux host over PCIe. I am currently using an Ara240 in a Lenovo ThinkCentre with Intel x86_64 Linux. My working stack is: x86_64 Linux → UIODMA → Ara240 PCIe → proxy_x86_64 → libaraclient / DVAPI → DVM model → inference I obtained the x86_64 runtime components from an older Geniatech/Kinara "customerReadyPackage_v3". I have also developed a native Ara240 detector integration for Frigate NVR, and inference works correctly with the YOLOv8n DVM supplied with that package. However, I have run into another compatibility problem which may be directly related to what you are investigating. The old supplied DVM works correctly with the old x86_64 runtime, but DVM models generated with the newer Kinara/Geniatech compiler and with NXP Ara SDK 2.1.1 fail during "dv_model_load_from_file". So in my case: old DVM + old x86_64 runtime = WORKS new DVM + old x86_64 runtime = FAILS I am therefore also looking for a newer Ara240 Runtime SDK for x86_64, preferably the runtime generation with proxy 1.3.x / support for cnn_model 2.1.x, or alternatively an older compiler capable of generating DVMs compatible with the existing x86_64 runtime. So x86_64 Ara240 execution definitely exists and works — the missing piece appears to be access to a current x86_64 runtime package compatible with models generated by the newer SDK. I would also be very interested in any response from NXP regarding availability of the current x86_64 runtime. Regards, Jacek Re: Ara240 Runtime Support on x86 Linux Hi Jorge, Thank you — this confirms exactly what I was looking for. My problem is obtaining the rt-sdk-ara2_x86_64.deb package. I do not currently have an assigned NXP FAE, and unfortunately I am also unable to create a technical support case because my NXP account is not associated with a company. I previously contacted NXP support, but I was redirected to the technical Cases portal, which I cannot access for this reason. Is there another way for an individual developer/researcher to request access to rt-sdk-ara2_x86_64.deb? I already have a fully working Ara240 PCIe setup on x86_64 Linux using the older Geniatech/Kinara runtime, including a working native Frigate detector integration. I specifically need the current x86_64 Runtime SDK to test DVM models generated with Ara SDK 2.1.1. If the package requires an NDA or another access procedure, I would be happy to follow it. Thank you, Jacek Re: Ara240 Runtime Support on x86 Linux Hello, The software stack architecture is the next: User Application ├── Optimum-Ara (Python, HuggingFace integration for LLM/VLM) ├── GStreamer Plugins (gstdvInf, for vision pipelines) └── dvapi.py (Python bindings for direct inference) │ ▼ libaraclient.so (Client library) │ ▼ Proxy Daemon (rt-sdk-ara2.service) │ ▼ uiodma.ko (UIO DMA kernel driver, PCIe only) │ ▼ ARA-240 NPU Hardware ARM64 or x86 Linux host with PCIe should work, provided the uiodma.ko driver can be compiled for that kernel. Platform Package Notes x86 Linux rt-sdk-ara2_x86_64.deb Requires building  uiodma.ko  for the host kernel ARM64 Linux (non-i.MX) RT-SDK ARM64  .deb  + platform-specific  uiodma.ko Demonstrated on NXP S32G3 and S32N79 (ARM Cortex-A cores, not i.MX) The  uiodma.ko  driver source code is open (GPL-2.0) and available on GitHub. It has two variants: uiodma/  — for x86 (cache-coherent systems) uiodma_cache_management/  — for ARM (explicit cache management) The imx-nxp-ara2 package distributed through the i.MX Embedded Linux BSP is intentionally built for AArch64, as it is integrated into the i.MX platform. To get access into missing binaries, please contact your FAE. Best regards Re: Ara240 Runtime Support on x86 Linux Hello, Thank you for the update. Unfortunately, we do not have access to these files and cannot be shared through this support channel. I suggest you check it directly with your sales-person. Best regards.
View full article
射频发生器 你好。我计划使用 NXP MRF101AN LDMOS 晶体管制作一个实验室用 13.56 MHz 射频发生器,并希望复现 NXP MRF101AN-13MHZ 参考电路。 在购买两台 MRF101AN 设备之前,我需要 MRF101AN-13MHZ 参考设计的完整文档,特别是原理图、包含制造商零件编号的物料清单、PCB/Gerber 或制造文件、元件布局图、空芯电感器详细信息、PCB 规格、铝底板/散热器图以及偏置/调谐说明。 请问您能否提供这些文件,或者指引我联系恩智浦半导体(NXP)相应的射频应用/支持工程师? 我身在印度,打算通过印度的授权代理商采购元器件。 Re: RF Generator 你好, 请访问https://www.nxp.com/products/radio-frequency-rf/legacy-rf/legacy-rf-power/mrf101an-reference-circuits:MRF101AN-REFCirc 向下滚动到“设计文件”,您将找到 MRF101AN 13.56 MHz 参考电路设计文件。 请注意,NXP 提供的此设计文档包中不包含原理图。由于大多数射频设计对电路板布局都很敏感,因此这是我们的常规做法。因此,布局视图加上物料清单比单纯的原理图能提供更具可重复性的结果。如果需要,您可以自己使用布局图和物料清单绘制原理图。 希望这能帮到你!
View full article
RF Generator Hello. I am planning a laboratory 13.56 MHz RF generator using the NXP MRF101AN LDMOS transistor and would like to reproduce the NXP MRF101AN-13MHZ reference circuit. Before purchasing two MRF101AN devices, I need the complete documentation for the MRF101AN-13MHZ reference design, particularly the schematic, BOM with manufacturer part numbers, PCB/Gerber or fabrication files, component-placement drawing, air-core inductor details, PCB specification, aluminium baseplate/heatsink drawing, and bias/tuning instructions. Could you please provide these files or direct me to the appropriate NXP RF applications/support engineer? I am located in India and intend to source the components through authorized distributors in India. Re: RF Generator Hello, Please go to https://www.nxp.com/products/radio-frequency-rf/legacy-rf/legacy-rf-power/mrf101an-reference-circuits:MRF101AN-REFCirc Scroll down to Design files and you will find the MRF101AN 13.56 MHz Reference Circuit Design File. Please note that 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. Hope this helps!
View full article
eIQ Neutron 是否支持 i.MX 上的 NPU 加速的 Vision Transformer (RF-DETR / DETR) 转换 目标 部署 RF-DETR Nano (视觉变压器+DETR头)开启 NXP FRDM-IMX95 运行推理 eIQ Neutron NPU 通过 libneutron_delegate.so 需要确认: eIQ 是否支持基于视觉转换器的 NPU 加速模型? 我的板详情 板: NXP FRDM-IMX95 (imx95-15x15-lpddr4x-frdm) 核心: Linux 6.18.2-1.0.0-gf49f45233f7b (aarch64,2026年2月) 中央处理器: 6 个 ARM Cortex-A55 处理器(500–1800 MHz) NPU: eIQ Neutron-S ( libneutron_delegate.so ) 使用的指南: FRDM i.MX95 入门指南 – NPU 部分 模型和管道试验 模型: RF-DETR Nano (DINOv2 ViT 主干网 + DETR 解码器) 输入: 384×384,COCO 80 类 流动: PyTorch → ONNX(选项集 18) ONNX → TFLite onnx2tf (-fdosm 对于 SavedModel) TFLite 动态范围量化(float32 I/O)— CPU推理工作正常 主持人: neutron-converter --input model.tflite --output model_neutron.tflite --target imx95 板:TFLite + Neutron 代表 哪些方法有效 ✅ ONNX导出成功 TFLite转换成功(约30MB模型) CPU推断正确 — 检测结果与 PyTorch 匹配(测试图像中的狗/人/汽车) 该模型在 FRDM 上运行,无论是否使用委托。 失败/阻塞的原因 ❌ 转换后未创建 NPU 图 检查转换 .tflite : 不 中子图 / 中子操作员 标记 中子代表似乎卸载 0 个节点 → 完整 CPU回退 完整的 INT8 量化失败 关于变压器操作(范围, (例如,除法) 用过的 动态范围量化 改为(权重量化,float32 I/O) 为什么我认为它不受支持(需要确认) RF-DETR 是 transformer-heavy :注意,BatchMatMul,Softmax,LayerNorm,Gather 等。 Neutron 文档列表主要 CNN运营 (Conv2D、DepthwiseConv2D、池化、加法……) 中子变流器 支持的运营商 需要采用类似的拆分模型方法 瑞芯微NPU (主干部分在NPU上,解码器在CPU上): rfdetr-on-rockchip-npu 我的具体问题 i.MX95 上的 eIQ Neutron 是否支持端到端视觉转换器模型(ViT / DETR / RF-DETR)? 如果 不,那是什么? 建议拆分 (例如DNOv2 主干网位于 NPU 上,DETR 头位于 CPU 上)? 是 批量多头注意力 当前 SDK 中是否支持 Neutron-S for i.MX95? 哪个 eIQ 工具包版本 匹配 BSP 内核 6.18.2-1.0.0 适用于 FRDM-IMX95? 我们应该使用恩智浦半导体吗? tflite-profiler + tflite-quantizer 为了更好地兼容NPU,为什么不使用onnx2tf动态范围量化呢? 模型部署快速入门 任何 参考示例 适用于 i.MX95 Neutron 上的变压器或 DETR 型型号 使用的命令(用于复现问题) 主机(转换): 中子变流器 \ --输入rf_detr_nano_full_int8.tflite \ --输出rf_detr_nano_neutron_imx95.tflite \ --target imx95 板(推断): python3 redetr_test_neutron_imx95.py \ --model rf_detr_nano_neutron_imx95.tflite \ --image dog.jpg \ --delegate /usr/lib/libneutron_delegate.so 预期问题: 转换后的模型没有 中子图 → 不支持NPU加速。 请确认: 是 支持视觉转换器 NPU 加速 今天在 i.MX95 上? 如果不是,那又是什么呢? 官方解决方法 (模型拆分、不同的导出路径,还是未来的路线图)? Re: Does eIQ Neutron support Vision Transformer (RF-DETR / DETR) conversion for NPU acceleration on 你好, Q1- Neutron N3.2 引入了专用硬件功能,可高效支持现代 GenAI 工作负载,包括语言模型 (LLM)、视觉 Transformer (ViT) 和 Transformer 派生算子。它还指出:“视觉转换器不需要动态形状,因此可以自然地集成到现有的 Neutron 变流器管道中。”它们的实现主要得益于扩展的运算符集和改进的量化选项(仍在开发中)。 Q2- 是的,不支持的操作会自动回退到 CPU。 Q3- 所有张量量化必须为 INT8,而不是 float32。Neutron 上的 BatchMatMul 仅对量化的 INT8 张量进行操作 第四季度 - 升级到最新的 电路板支持包 + SDK 3.2.2,以获得最佳的变压器运营商覆盖率。 Q5- 没错,这是推荐的做法。 Q6- 目前还没有公开的端到端DETR示例。 此致问候
View full article
x86 Linux 上的 Ara240 运行时支持 您好,NXP团队: 我正在评估通过 PCIe 直接在 x86 Linux 主机上运行 Ara240 模块的可能性,以便进行验证和性能测试。 在调查过程中,我发现有迹象表明可能存在 x86 运行时支持: dvapi.py 包含对以下内容的引用: art/linux/x86/lib/libaraclient_x86_64.so Optimum-Ara 文档参考资料: $DV_TGT_ROOT/art/linux/x86/proxy/ UIO DMA 驱动程序库包含 x86 支持。 历史上的 Kinara 运行时配方使用以下方式打包特定于架构的运行时组件: art/linux/${TARGET_ARCH}/... 然而,目前可通过 i.MX BSP 获取的 imx-nxp-ara2 运行时软件包仅包含 AArch64 运行时二进制文件:   1 libaraclient_aarch64.so 2 proxy_ara240 3 nnapp 4 硬件实用程序   我找不到相应的 x86 运行时环境文件。 请问您能否澄清一下: 官方是否支持在 x86 Linux 主机上直接执行 Ara240 运行时? 是否有可用的 x86 运行时 SDK 包? 我可以在哪里获取以下x86运行时组件? libaraclient_x86_64.so x86 proxy binary x86 dvapi runtime package 是否有集成指南或参考流程? x86 Host ↓ UIODMA Driver ↓ Ara240 PCIe ↓ Runtime SDK ↓ Inference Execution 任何关于如何获取所需 x86 运行时元器件的指导都将不胜感激。 谢谢, 尤夫拉杰·索兰基 Re: Ara240 Runtime Support on x86 Linux 你好,尤夫拉杰, 我可以确认 Ara240 实际上可以通过 PCIe 在标准的 x86_64 Linux 主机上运行。 我目前使用的是联想ThinkCentre电脑,电脑配置为Intel x86_64 Linux系统,显卡是Ara240。我的工作技术栈是: x86_64 Linux → UIODMA → Ara240 PCIe → proxy_x86_64 → libaraclient / DVAPI → DVM模型 → 推理 我从较旧的 Geniatech/Kinara“customerReadyPackage_v3”中获得了 x86_64 运行时组件。 我还为 Frigate NVR 开发了原生 Ara240 检测器集成,并且与该软件包提供的 YOLOv8n DVM 的推理功能正常。 然而,我遇到了另一个兼容性问题,这可能与您正在调查的问题直接相关。 旧版提供的 DVM 与旧版 x86_64 运行时配合使用正常,但使用较新的 Kinara/Geniatech 编译器和 NXP Ara SDK 2.1.1 生成的 DVM 模型在“dv_model_load_from_file”期间失败。 就我而言: 旧版 DVM + 旧版 x86_64 运行时 = 可用 新DVM + 旧x86_64运行时 = 失败 因此,我也在寻找更新的适用于 x86_64 的 Ara240 运行时 SDK,最好是带有代理的运行时生成版本 1.3.x。/ 支持 cnn_model 2.1.x,或者,也可以使用能够生成与现有 x86_64 运行时兼容的 DVM 的旧编译器。 所以 x86_64 Ara240 的执行肯定存在并且有效——缺失的部分似乎是访问与新 SDK 生成的模型兼容的当前 x86_64 运行时包。 我也很想知道 NXP 是否对当前 x86_64 运行时的可用性做出任何回应。 此致, 雅采克 Re: Ara240 Runtime Support on x86 Linux 嗨,豪尔赫, 谢谢——这正是我要找的答案。 我的问题是如何获取 rt-sdk-ara2_x86_64.deb 软件包。 我目前没有分配 NXP FAE,而且很遗憾,由于我的 NXP 帐户未与公司关联,我也无法创建技术支持案例。我之前联系过 NXP 支持,但是被重定向到技术案例门户,由于这个原因我无法访问该门户。 个人开发者/研究人员还有其他方法可以申请访问rt-sdk-ara2_x86_64.deb吗? 我已经在 x86_64 Linux 上使用较旧的 Geniatech/Kinara 运行时环境搭建了一个完全可用的 Ara240 PCIe 系统,其中包括一个可用的原生护卫舰探测器集成。我特别需要当前的 x86_64 运行时 SDK 来测试使用 Ara SDK 2.1.1 生成的 DVM 模型。 如果该资料包需要签署保密协议或其他访问程序,我将乐意遵守。 谢谢你,杰克 Re: Ara240 Runtime Support on x86 Linux 你好, 接下来是软件栈架构: User Application ├── Optimum-Ara (Python, HuggingFace integration for LLM/VLM) ├── GStreamer Plugins (gstdvInf, for vision pipelines) └── dvapi.py (Python bindings for direct inference) │ ▼ libaraclient.so (Client library) │ ▼ Proxy Daemon (rt-sdk-ara2.service) │ ▼ uiodma.ko (UIO DMA kernel driver, PCIe only) │ ▼ ARA-240 NPU Hardware ARM64 或 x86 Linux 主机(带 PCIe)应该可以工作,前提是能够为该内核编译 uiodma.ko 驱动程序。 平台 封装 说明 x86 Linux rt-sdk-ara2_x86_64.deb 需要建造  uiodma.ko  对于主机内核 ARM64 Linux (非 i.MX) RT-SDK ARM64  .deb  + 平台特定  uiodma.ko 已在 NXP S32G3 和 S32N79(ARM Cortex-A 内核,而非 i.MX)上进行演示。 这  uiodma.ko  驱动程序源代码是开源的(GPL-2.0)并可在以下平台获取: GitHub 。它有两种变体: uiodma/  — 适用于 x86(缓存一致性系统) uiodma_cache_management/  — 适用于 ARM(显式缓存管理) 通过 i.MX 嵌入式 Linux 电路板支持包 分发的 imx-nxp-ara2 软件包是专门为 AArch64 构建的,因为它集成到了 i.MX 平台中。 要获取缺失的二进制文件,请联系您的 FAE。 顺祝商祺! Re: Ara240 Runtime Support on x86 Linux 你好, 谢谢你的更新。 很遗憾,我们无法访问这些文件,也无法通过此支持渠道共享这些文件。 我建议您直接向销售人员确认。 顺祝商祺!
View full article
Does eIQ Neutron support Vision Transformer (RF-DETR / DETR) conversion for NPU acceleration on i.MX Goal Deploy RF-DETR Nano (vision transformer + DETR head) on NXP FRDM-IMX95 Run inference with eIQ Neutron NPU via libneutron_delegate.so Need confirmation: Does eIQ support vision-transformer-based models for NPU acceleration? My Board Details Board: NXP FRDM-IMX95 (imx95-15x15-lpddr4x-frdm) Kernel: Linux 6.18.2-1.0.0-gf49f45233f7b (aarch64, Feb 2026) CPU: 6× ARM Cortex-A55 (500–1800 MHz) NPU: eIQ Neutron-S (libneutron_delegate.so) Guide used: FRDM i.MX95 Getting Started – NPU section Model & Pipeline Tried Model: RF-DETR Nano (DINOv2 ViT backbone + DETR decoder) Input: 384×384, COCO 80 classes Flow: PyTorch → ONNX (opset 18) ONNX → TFLite via onnx2tf (-fdosm for SavedModel) TFLite dynamic-range quant (float32 I/O) — CPU inference works Host: neutron-converter --input model.tflite --output model_neutron.tflite --target imx95 Board: TFLite + Neutron delegate What Works ✅ ONNX export succeeds TFLite conversion succeeds (~30 MB model) CPU inference is correct — detections match PyTorch (dog/person/car on test image) Model runs on FRDM with and without delegate What Fails / Blocked ❌ No NPU graph created after conversion Inspecting converted .tflite: no neutronGraph / NeutronOperator markers Neutron delegate appears to offload 0 nodes → full CPU fallback Full INT8 quantization fails on transformer ops (RANGE, DIV, etc.) Used dynamic-range quant instead (weights quantized, float32 I/O) Why I Think It’s Unsupported (Need Confirmation) RF-DETR is transformer-heavy: attention, BatchMatMul, Softmax, LayerNorm, Gather, etc. Neutron docs list mainly CNN ops (Conv2D, DepthwiseConv2D, Pooling, Add…) Neutron Converter Supported operators Similar split-model approach needed on Rockchip NPU (backbone on NPU, decoder on CPU): rfdetr-on-rockchip-npu My Specific Questions Does eIQ Neutron on i.MX95 support end-to-end vision transformer models (ViT / DETR / RF-DETR)? If not, what is the recommended split (e.g. DINOv2 backbone on NPU, DETR head on CPU)? Are BatchMatMul / Multi-Head Attention supported on Neutron-S for i.MX95 in current SDK? Which eIQ Toolkit version matches BSP kernel 6.18.2-1.0.0 for FRDM-IMX95? Should we use NXP tflite-profiler + tflite-quantizer instead of onnx2tf dynamic-range quant for better NPU compatibility? Model Deployment Quick Start Any reference example for transformer or DETR-style models on i.MX95 Neutron Commands Used (for reproducibility) Host (convert): neutron-converter \ --input rf_detr_nano_full_int8.tflite \ --output rf_detr_nano_neutron_imx95.tflite \ --target imx95 Board (inference): python3 redetr_test_neutron_imx95.py \ --model rf_detr_nano_neutron_imx95.tflite \ --image dog.jpg \ --delegate /usr/lib/libneutron_delegate.so Expected issue: converted model has no neutronGraph → no NPU acceleration. Please confirm: Is vision-transformer NPU acceleration supported on i.MX95 today? If not, what is the official workaround (model split, different export path, or future roadmap)? Re: Does eIQ Neutron support Vision Transformer (RF-DETR / DETR) conversion for NPU acceleration on Hello, Q1- Neutron N3.2 introduces dedicated hardware features to efficiently support modern GenAI workloads including Language Models (LLMs), Vision Transformers (ViTs), and transformer-derived operators." It further notes: "Vision Transformers do not require dynamic shapes, and thus integrate naturally into the existing Neutron converter pipeline. Their support is primarily enabled through the extended operator set and improved quantization options (still under development). Q2- Yes, unsupported ops fall back to CPU automatically Q3- All tensor quantization must be INT8, not float32. BatchMatMul on Neutron only operates on quantized INT8 tensors Q4- Upgrade to the latest BSP + SDK 3.2.2 for best transformer operator coverage Q5- It is correct, that is the recommended path to follow Q6- There are no public end-to-end DETR examples yet.  Regards.
View full article
RFジェネレーター こんにちは。NXP MRF101AN LDMOSトランジスタを使用した実験室用13.56 MHzのRFジェネレーターを計画しており、NXPのMRF101AN-13MHZ基準回路を再現したいと考えています。 MRF101ANデバイスを2台購入する前に、MRF101AN-13MHZリファレンスデザインの完全なドキュメントが必要です。特に回路図、メーカー部品番号付きBOM、PCB/Gerberまたは製造ファイル、部品配置図、エアコアインダクタの詳細、PCB仕様書、アルミニウムベースプレート/ヒートシンク図面、バイアス/チューニング指示などです。 これらのファイルを提供していただけるか、適切なNXP RFアプリケーションやサポートエンジニアの連絡先を教えていただけませんか? 私はインドに拠点を置いており、部品はインドの正規代理店を通じて調達する予定です。 Re: RF Generator こんにちは、 https://www.nxp.com/products/radio-frequency-rf/legacy-rf/legacy-rf-power/mrf101an-reference-circuits:MRF101AN-REFCircにアクセスしてください。 設計ファイルまでスクロールすると、MRF101AN 13.56 MHzのリファレンス回路設計ファイルが見つかります。 この設計のNXPドキュメントパックには回路図が含まれていないことにご注意ください。ほとんどのRFデザインは基板の配置に敏感であるため、これが私たちの一般的な運用です。したがって、レイアウト図と部品表を組み合わせることで、純粋な回路図よりも再現性の高い結果が得られる。必要なら、レイアウトとBOMを使って自分で回路図を描くこともできます。 お役に立てば幸いです!
View full article
NXP-PORT GMBH IMX94 套件移植 您好, 我计划将 NXP-PORT GMBH 的 profinet 协议栈移植到 IMX94 开发板上。 我尝试查找相关文件,但大多数都与 RT1180 有关。 请帮我查找一下在 Linux 或 M7 和 M33 内核上移植该程序所需的文档。 谢谢 维杰·拉纳 ACL 数字 Re: NXP-PORT GMBH Porting on IMX94 Kit 请参考以下链接。 https://www.nxp.com/design/design-center/software/development-software/software-for-industrial-networking/profinet-industrial-ethernet-protocol-software:PROFINET-INDUSTRIAL-COMMUNICATIONS-SOFTWARE?_gl=1*rqpmy3*_ga*MTk0NjI5NzAyNi4xNzg4NzQ0MDgx*_ga_WM5LE0KMSH*czE3ODg3NTg2ODkkbzIkZzEkdDE3ODg3NjM1MTYkajYwJGwwJGg5ODc1Nzg5NA .. 对于Linux方案,首先需要PROFINETFORLINUXFS 、 UM12408 、 UM12463 、 RN00389/RN00434以及 PROFINET 堆栈库软件包。在我找到的所有资料中,只有 Linux 情况说明书明确提到了Linux 的 PROFINET 端点,它将交付模型描述为预编译的用户空间对象库加上受支持的 NXP 设备的特定于平台的驱动程序源。 对于 i.MX94 上的M7/M33路线,请使用 i.MX94 RM 以及相同的 PROFINET/GOAL/ICC 文档,但仅将AN13933视为参考模式。i.MX94 具有两个 Cortex-M7 内核和两个 Cortex-M33 内核,专为工业以太网协议(包括 PROFINET)而设计,但我找到的关于 Cortex-M 移植的详细应用笔记是专门针对使用 FreeRTOS 和 lwIP 的 i.MX 8M Mini Cortex-M4 的。
View full article
Where is the wafer fabrication site for MPF5301AMMA0ES Where is the wafer fabrication site for MPF5301AMMA0ES? I need supporting documents.  Re: Where is the wafer fabrication site for MPF5301AMMA0ES Dear customer, the information about a wafer fabrication site cannot be shared publicly. Let me send it via support ticket (https://support.nxp.com/). I am not sure what supporting documents you refer to. Kindly check the product pages: https://www.nxp.com/part/MPF5301AMMA0ES; https://www.nxp.com/products/PF53 If you mean the delivery documentation please cooperate with a distributor where you bought the parts. Thank you. Have a nice day. Best regards Pavla
View full article
NXP S32M276CHABMKHSR 结构问题 您好,NXP技术员, 我是来自无锡美莱克斯公司的Ted,很高兴与您联系。 我有一个关于S32M276集成电路结构的问题。(请解答。)请参阅附件文件:原理图-S32M276)。 我按照数据手册的建议进行了设计,用磁珠将 9pin-VDD_AE10、12pin、25pin、37pin-VDD_HV_A 连接在一起。据我了解,9pin-VDD_AE10 P5V 输出电压由内部稳压器产生,然后通过 VDD_HV_A 引脚为 MCU 芯片供电。 但我移除了 L300 之后,PCBA 仍然可以正常工作。 所以我的问题是,VDD_AE10引脚和VDD_HV_A引脚内部是否连接在一起?否则,移除L300后系统仍然可以运行,这就说不通了。 Re: NXP S32M276CHABMKHSR Structure question 嗨,泰德, 当移除 L300 时,VDD_HV_A 上测得的电压是多少? MCU 侧电源功能域 VDD_HV_A 很可能是通过 MCU 侧和 AE 侧共享的 GPIO 供电的,因为所有 GPIO 都被钳位到 VDD_HV_A。换句话说,如果某个引脚上的电压大于 VDD_HV_A,则可以通过该引脚为 VDD_HV_A 供电。因此,你应该测量大约 VDD_HV_A = VDD_AE10 - Vf,而不是 VDD_HV_A = VDD_AE10。 谢谢! BR,丹尼尔 Re: NXP S32M276CHABMKHSR Structure question 嗨,丹尼尔, 感谢您的回复。 1、所以这意味着VDD_AE10和VDD_HV_A内部是连接的吗? 我无法理解这句话的意思。 [另外,您应该测量 VDD_AE10 - Vf 到 VDD_HV_A 之间的电压——这可能会损坏设备。] 如果您能再解释一下就太好了。 Re: NXP S32M276CHABMKHSR Structure question 嗨,泰德, AE芯片产生VDD_AE10。 在 AE 侧,VDD_AE10 是 AE 端口的电源,所有端口都钳位到 VDD_AE10。 在 MCU 端,VDD_HV_A 是 MCU 端口的电源,所有端口都被钳位到 VDD_HV_A。 这两个模具是相互连接的。 如果任何 MCU 端口上的输入电压高于钳位电路的 VDD_HV_A + Vf,则 VDD_HV_A 功能域将由注入电流供电。你应该测量 VDD_AE10 - Vf 在 VDD_HV_A 上 - 这可能会损坏设备。 问候, 丹尼尔 Re: NXP S32M276CHABMKHSR Structure question 嗨,丹尼尔, 感谢您的回复。 移除 L300 后,我测量到 VDD_HV_A 为 4.98V,而 VDD_AE10 为 5.02V; 所以,我可以这样说吗?VDD_HV_A 和 VDD_AE10 是内部连接的。 应该将它们连接起来以降低阻抗。 Re: NXP S32M276CHABMKHSR Structure question 你好@Ted_Qiao , 我已经和设计团队确认过了。除了通过两个芯片之间共享的 GPIO 进行的当前注入路径外,它们之间还有一个用于内部监控的连接。但是,这些路径并非设计用于承受工作电流,因此需要外部 PCB 连接。 BR,丹尼尔
View full article
NXP-PORT GMBH Porting on IMX94 Kit Hi, I'm planning to port NXP-PORT GMBH profinet stack on IMX94 kit. I have tried looking for the documents but most of them are related to RT1180. Please help me with the documents available for porting it on linux or M7 and M33 core. thanks Vijay Rana ACL Digital Re: NXP-PORT GMBH Porting on IMX94 Kit Please refer to the following link. https://www.nxp.com/design/design-center/software/development-software/software-for-industrial-networking/profinet-industrial-ethernet-protocol-software:PROFINET-INDUSTRIAL-COMMUNICATIONS-SOFTWARE?_gl=1*rqpmy3*_ga*MTk0NjI5NzAyNi4xNzg4NzQ0MDgx*_ga_WM5LE0KMSH*czE3ODg3NTg2ODkkbzIkZzEkdDE3ODg3NjM1MTYkajYwJGwwJGg5ODc1Nzg5NA.. For the Linux route, start with PROFINETFORLINUXFS , UM12408 , UM12463 , RN00389/RN00434 , and the PROFINET Stack Library package. The Linux factsheet is the only source I retrieved that specifically calls out a PROFINET endpoint for Linux , and it describes the delivery model as a precompiled user-space object library plus platform-specific driver source for supported NXP devices. For the M7/M33 route on i.MX94, use the i.MX94 RM plus the same PROFINET/GOAL/ICC documents, but treat AN13933 only as a reference pattern. i.MX94 has two Cortex-M7 and two Cortex-M33 cores and is designed for industrial Ethernet protocols including PROFINET, but the detailed app note I found for Cortex-M porting is specifically for i.MX 8M Mini Cortex-M4 using FreeRTOS and lwIP.
View full article
MPF5301AMMA0ES的晶圆制造厂在哪里? MPF5301AMMA0ES的晶圆制造基地在哪里? 我需要一些证明文件。 Re: Where is the wafer fabrication site for MPF5301AMMA0ES 尊敬的用户, 晶圆制造厂的相关信息不能公开分享。我将通过支持工单发送( https://support.nxp.com/ )。我不确定您指的是哪些证明文件。请查看产品页面: https://www.nxp.com/part/MPF5301AMMA0ES;https://www.nxp.com/products/PF53 如果您指的是交货单据,请与您购买零件的代理商合作。谢谢。祝你今天过得愉快。此致 帕夫拉
View full article