Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
NAFE13388 水晶の仕様 RIOP RevB2では、NAFE13388 XTAL(X1、18.432 MHz)にどの水晶発振器仕様(ppm/負荷)を使用していますか? Re: NAFE13388 crystal spec こんにちは、 部品番号: ECS-184-12-33Q-JES-TR PPM:20 PPM 負荷: 12 pF これがお役に立てば幸いです。 Re: NAFE13388 crystal spec ご回答をお待ちしています。
記事全体を表示
PN7221+Android16 EDLA认证问题 PN7221,Android 16   经 EDLA 认证的版本仅支持部分 NFC 功能。我们的测试表明卡片检测功能正常,但 EMVCo、固件升级和其他功能尚不可用。通过对比分析确定的根本原因如下:   EDLA 版本使用 Google 预构建的 NFC 服务,而 AOSP 版本则编译时集成了 NXP 补丁。   以下是与 EDLA 相关的版本配置片段:   apex_set {   名称:“com.google.android.nfcservices_compressed”,   apex_name: "com.android.nfcservices",   覆盖:["com.android.nfcservices"],   所有者:“谷歌”,   设置:“com.google.android.nfcservices_compressed.apks”,   文件名:“com.google.android.nfcservices_compressed.apex”,   exported_bootclasspath_fragments: ["com.android.nfcservices-bootclasspath-fragment"],   } 请问在这种情况下如何导入NXP补丁?是否有其他解决方案?对于其他使用 NXP NFC 芯片的客户,他们采取了哪些方法来通过 EDLA 认证,同时保持完整的 NFC 功能? Re: PN7221+Android16 EDLA certification issues 你好@zhangkai 根据我们的分析,该问题很可能是由使用谷歌预构建的 NFC APEX (com.android.nfcservices) 的 EDLA 版本引起的。而不是集成了 NXP Android 中间件的 NFC 模块。 NXP Android 16 解决方案扩展了 Android NFC 协议栈的多个层,包括 NFC 框架、NFC 服务、EMVCo 框架、HAL 和相关库。如果使用 Google 预置的 NFC 服务,则可能仅保留标准 NFC 功能,而 NXP 特有的功能(例如 EMVCo 功能、固件更新支持和其他中间件扩展)可能无法激活。 目前,NXP 的 Android 16 移植文档没有描述直接修补或修改 Google 预构建的 EDLA NFC APEX 的方法。NXP 的典型集成方法是基于 AOSP 源代码集成,并使用 NXP 中间件重建 NFC 协议栈。 对于需要完整 PN7221 功能的客户,我们建议评估是否可以在包含 NXP NFC 中间件的情况下重建 NFC APEX,或者咨询 Google/OEM 支持,了解如何在保持 EDLA 合规性的同时定制 EDLA NFC 模块。
記事全体を表示
如何在 S32DS 上测量 S32G399 裸机应用程序的 CPU 负载 大家好, 我想知道如何在 S32G399 运行时测量其 CPU 负载。 背景:我的 S32G399 项目是一个四核 M7 裸机项目,只有一个 ELF 文件,是在 S32DS3.5.10 上开发的。我使用自定义引导加载程序来启动 A53 和 M7,该程序已经实现。我的需求是测量M7端的CPU负载。我手头有 S32 调试探针,因此我可以在我的 M7 应用程序运行时将其连接到该应用程序。但是,我不知道测量负载的具体步骤/方法。我甚至不知道仅使用 S32 调试探针是否能够实现此目标。 希望有人能提供相关文件或指导。 谢谢! Re: How to measure CPU load for S32G399 baremetal application on S32DS 你好, @Yang_C 感谢你的帖子。 1. 据我了解,仅仅依靠调试器可能无法准确获取运行时 CPU 负载。 2. 可以向自己的应用程序添加一些代码,例如启用计时器,然后测量执行主要任务的时间。计算(执行时间)/(运行时间)的比例,以评估 CPU 的大致负载。 BR 陈银 Re: How to measure CPU load for S32G399 baremetal application on S32DS 非常感谢。我将尝试从代码端进行测量。
記事全体を表示
提供一下基于eb29.0 双核启动的S32K358例子,最好rtd4.0这种 你好:       提供一下基于EB29.0 双核启动的S32K358例子,最好rtd4.0这种;如果没有rtd4.0,没有也行,其他版本也可以 Hello: I'd like to provide an example of an S32K358 system based on a dual-core EB29.0 processor, preferably with RTD4.0; however, if RTD4.0 is unavailable, other versions are also acceptable. Re: 提供一下基于eb29.0 双核启动的S32K358例子,最好rtd4.0这种 你好, 多核处理器有很多例子。 例如直接在: https://community.nxp.com/t5/S32K/S32K324-Multi-Core-Example-Project-based-on-Whiteboard/mp/1547771 或者: S32DS软件包中直接包含演示程序。 由于 EB Tresos 不是 NXP 的工具,我不知道这里是否有直接的多组件演示。您可能需要从 S32DS 演示程序进行移植。RTD 驱动程序包含基于 EB tresos 的示例,但我没有找到完整的多核项目。 您还可以查看附件中的演示文稿。 顺祝商祺! Peter Re: 提供一下基于eb29.0 双核启动的S32K358例子,最好rtd4.0这种 https://community.nxp.com/t5/S32K/S32K324-Multi-Core-Example-Project-based-on-Whiteboard/m-p/1547771 我打开此链接发现起其中例子(s32k324_dualcore_demo),是基于   S32K3_RTD_1_0_0_D2110_ASR_REL_4_4_REV_0000_20211007,rtd是1.0,我现在是s32 ds v3.5,rtd 4.0,不能正确打开例程。我在官网找不到此版rtd,可以发我一下吗,另外我使用s32 ds   v3.5 。rtd1.0支持吗? 是不是需要安装v3.4,我可以同时安装v3.4和v3.5吗?
記事全体を表示
NAFE13388 crystal spec Which crystal spec (ppm/load) does RIOP RevB2 use for the NAFE13388 XTAL (X1, 18.432 MHz)? Re: NAFE13388 crystal spec Hello, Part number: ECS-184-12-33Q-JES-TR PPM: 20 PPM Load: 12 pF Hope this helps. Re: NAFE13388 crystal spec Thank you!
記事全体を表示
S32DS S32G399ベアメタルアプリケーションでCPU負荷を測定する方法 こんにちは、皆さん S32G399が動作している際のCPU負荷を測定する方法を知りたいです。 背景:私のS32G399プロジェクトは、S32DS3.5.10上で開発された1つのELFファイルを持つ4コアM7ベアメタルプロジェクトです。私は、実装済みのカスタムブートローダーを使用してA53とM7を起動しています。私の依頼は、M7側のCPU負荷を測定することです。S32 Debug Probeを手元に持っているので、M7アプリケーションが動いている間に接続できます。しかし、負荷を測定するための詳細な手順や方法はわかりません。S32デバッグプローブのみを使用してこの目標を達成することが実現可能かどうかさえ分かりません。 誰か関連する書類や指針を提供してくれるといいですね。 よろしくお願いします。 Re: How to measure CPU load for S32G399 baremetal application on S32DS こんにちは、 @Yang_C 投稿ありがとうございます。 1. 私の理解では、デバッガーだけに頼ると、実行時のCPU負荷を正確に取得できない可能性があります。 2. 例えば、自分のアプリケーションにタイマーを有効にするコードを追加し、最終的にメインタスクを実行する時間を測定することも可能です。(実行時間)/(実行時間)の割合を計算して、おおよそのCPU負荷を評価します。 BR チェイン Re: How to measure CPU load for S32G399 baremetal application on S32DS どうもありがとうございます。コード側での計測を試してみます。
記事全体を表示
S32K358システムがデュアルコアEB29.0マザーボードから起動する例(できればRTD4.0を使用した場合)を提供してください。 こんにちは: 以下は、デュアルコアEB29.0システム上で動作するS32K358の例です。RTD4.0が望ましいですが、RTD4.0が利用できない場合は、他のバージョンでも構いません。 こんにちは: デュアルコアEB29.0プロセッサを搭載したS32K358システムの例を提示したいと思います。できればRTD4.0を搭載したものが望ましいですが、RTD4.0が入手できない場合は、他のバージョンでも構いません。 Re: 提供一下基于eb29.0 双核启动的S32K358例子,最好rtd4.0这种 こんにちは、 マルチコアの例は複数存在する。 例えば、直接以下のように: https://community.nxp.com/t5/S32K/S32K324-Multi-Core-Example-Project-based-on-Whiteboard/mp/1547771 または: S32DSパッケージには直接デモが収録されています。 EB tresosはNXPのツールではないため、ここに直接的なマルチCREデモがあるかどうかは分かりません。おそらくS32DSのデモから移植する必要があるでしょう。RTDドライバにはEBのトレソベースの例が含まれていますが、完全なマルチコアプロジェクトは見つかりませんでした。 添付のプレゼンテーションもご確認ください。 よろしくお願いいたします。 ピーター Re: 提供一下基于eb29.0 双核启动的S32K358例子,最好rtd4.0这种 https://community.nxp.com/t5/S32K/S32K324-Multi-Core-Example-Project-based-on-Whiteboard/mp/1547771このリンクを開いて、S32K3_RTD_1_0_0_D2110_ASR_REL_4_4_REV_0000_20211007 をベースにしたサンプル (s32k324_dualcore_demo) を見つけました。RTD は 1.0 です。現在、S32 を使用しています。DS v3.5とRTD 4.0でサンプルコードを開く際に問題が発生しています。公式ウェブサイトでこのバージョンのRTDが見つかりません。送っていただけないでしょうか?また、S32 DS v3.5を使用していますが、RTD 1.0はこのバージョンをサポートしていますか?バージョン3.4をインストールする必要がありますか?バージョン3.4とバージョン3.5を同時にインストールできますか?
記事全体を表示
IMX219 (RPi Cam v2) probes but does not stream on FRDM-IMX93 with stock imx93-11x11-frdm-imx219 over Environment - Board: FRDM-IMX93 (i.MX93 11x11) - BSP: Yocto Scarthgap, linux-imx-6.6.36-2.1.0 (kernel commit 20d9f5efabdd), MACHINE=imx93frdm, DISTRO=fsl-imx-xwayland - Sensor: Raspberry Pi Camera Module v2 (Sony IMX219), on the P6 MIPI-CSI connector - Device tree: stock arch/arm64/boot/dts/freescale/imx93-11x11-frdm-imx219.dtso Summary The BSP ships an IMX219 device-tree overlay for this board, and with it the sensor powers up and is detected correctly on I2C (chip ID at 0x10 reads 0x0219). However, the V4L2 capture pipeline never delivers frames. Tracing it down, there appear to be three independent issues in the downstream staging camera drivers. The mainline sony,imx219 driver follows the modern V4L2 subdev model, whereas the NXP staging CSI/ISI stack still assumes the older ov5640-style model. Issue 1 — media graph teardown ("Sensor register failed") drivers/staging/media/imx/imx8-media-dev.c : mxc_md_create_links() calls media_entity_call(sensor, link_setup, ...). The mainline imx219 driver does not implement .link_setup, so the call returns -ENOIOCTLCMD (-515) and is treated as fatal. The sensor->CSI link is never created and the whole media device is torn down: mx8-img-md: Registered sensor subdevice: imx219 2-0010 (1) mx8-img-md: created link [mxc_isi.0] => [mxc_isi.0.capture] mx8-img-md: created link [mxc-mipi-csi2.0] => [mxc_isi.0] mx8-img-md: subdev_notifier_complete error exit mxc-md 42800000.bus:camera: Sensor register failed mxc-md: probe of 42800000.bus:camera failed with error -515 (ov5640 works because ov5640.c provides a no-op .link_setup.) Issue 2 — streamon aborts ("Call subdev s_power fail!") drivers/staging/media/imx/imx8-isi-cap.c : mxc_isi_cap_streamon() calls v4l2_subdev_call(src_sd, core, s_power, 1) and treats failure as fatal. imx219 uses runtime PM and does not implement the deprecated .s_power, so the call returns -ENOIOCTLCMD and streaming aborts: mxc_isi.0: Call subdev s_power fail! (ov5640 works because ov5640.c provides .s_power.) Issue 3 — CSI hardcoded to YUV422, cannot parse RAW10 (links up but 0 frames) drivers/staging/media/imx/dwc-mipi-csi2.c is effectively YUV422-only: - dwc_csi2h_formats[] lists only SBGGR Bayer codes, not SRGGB (IMX219 is SRGGB10). find_csi2h_format() therefore fails and the format silently reverts to YUYV. - dwc_mipi_csi2_set_fmt() never stores csi2h->format, so disp_mix_gasket_config() sees the default YUYV code. - dwc_mipi_csi2_param_init() hardcodes ipi_cfg->data_type = DT_YUV422_8. The CSI then reports the wrong datatype and no frames are captured even though all links are ENABLED and VIDIOC_STREAMON returns 0: mxc-mipi-csi2.0: format: 0x2008 <- YUYV; expected 0x300f (SRGGB10) What made it work for us (for your validation) After (a) making imx8-media-dev / imx8-isi-cap treat a missing optional op (-ENOIOCTLCMD from link_setup / s_power) as non-fatal, and (b) teaching dwc-mipi-csi2 about SRGGB8/10/12 (store the negotiated format and set the IPI data_type from it), the pipeline comes up correctly:- mxc-mipi-csi2.0: format: 0x300f imx219 -> mxc-mipi-csi2.0 -> mxc_isi.0 -> /dev/video0 ~27 fps, live frames captured. Fix (a) is sensor-agnostic and would help any modern mainline sensor on this stack; fix (b) adds RAW Bayer support to the CSI. Secondary note — module load ordering On a fresh boot the graph also fails to register because imx8_media_dev runs its async notifier before the imx219 module is loaded; the video node registers and is then unregistered. A manual "modprobe -r imx8_media_dev imx219; modprobe imx219; modprobe imx8_media_dev" rebuilds it. A softdep / load-order hint would make this work out of the box. Questions 1. Is IMX219 an officially supported/validated camera on FRDM-IMX93 in this BSP, or is the intended/validated path the AP1302 ISP module? The shipped imx219.dtso suggests bare-IMX219 is meant to work. 2. Are the three behaviors above considered bugs you would accept fixes for, or is there a recommended/known-good configuration we are missing? 3. If useful, I am happy to share the patches as clean commits. Thanks! FRDM-i.MX93 #IMX219 RPI-CAM-MIPI  Yocto Project Re: IMX219 (RPi Cam v2) probes but does not stream on FRDM-IMX93 with stock imx93-11x11-frdm-imx219 Hello, Thank you for reaching out, I will check with software team and will double check if there is some fix in later BSP about this, will update as soon as possible. Best regards/Saludos, Aldo. Re: IMX219 (RPi Cam v2) probes but does not stream on FRDM-IMX93 with stock imx93-11x11-frdm-imx219 Hello, Unfortunately the i.MX93 FRDM BSP was not oficially supported in our BSP until later on, as I was investigating this issue, the image may be a beta BSP for the same. We have support for the FRDM boards from 6.12.34-2.1.0 and later releases, I apreciate your finding and it should be useful for anyone validating using the default image included in the board, I will track it with software team. Best regards/Saludos, Aldo.
記事全体を表示
PN7221+Android16 EDLA certification issues PN7221, Android 16   The EDLA-certified build only supports partial NFC functions. Card detection works in our tests, but EMVCo, firmware upgrade and other features are unavailable. Root cause identified via comparison is as follows:   The EDLA build uses Google's prebuilt NFC service, while the AOSP build is compiled with NXP patches integrated.   Below is the EDLA-related build configuration snippet:   apex_set {   name: "com.google.android.nfcservices_compressed",   apex_name: "com.android.nfcservices",   overrides: ["com.android.nfcservices"],   owner: "google",   set: "com.google.android.nfcservices_compressed.apks",   filename: "com.google.android.nfcservices_compressed.apex",   exported_bootclasspath_fragments: ["com.android.nfcservices-bootclasspath-fragment"],   } Could you advise how to import NXP patches under this scenario? Are there alternative solutions? For other customers using NXP NFC chips, what approaches are adopted to pass EDLA certification while retaining full NFC functionality? Re: PN7221+Android16 EDLA certification issues Hello @zhangkai  Based on our analysis, the issue is likely caused by the EDLA build using Google's prebuilt NFC APEX (com.android.nfcservices) instead of the NFC module integrated with NXP Android middleware. The NXP Android 16 solution extends multiple layers of the Android NFC stack, including the NFC framework, NFC service, EMVCo framework, HAL, and associated libraries. If the Google prebuilt NFC service is used, only standard NFC features may remain available, while NXP-specific features such as EMVCo functionality, firmware update support, and other middleware extensions may not be active. At present, NXP's Android 16 porting documentation does not describe a method to directly patch or modify Google's prebuilt EDLA NFC APEX. The typical NXP integration approach is based on AOSP source integration and rebuilding the NFC stack with NXP middleware. For customers requiring full PN7221 functionality, we recommend evaluating whether the NFC APEX can be rebuilt with the NXP NFC middleware included, or consulting Google/OEM support regarding customization of the EDLA NFC module while maintaining EDLA compliance.
記事全体を表示
PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Hi everyone, I am currently integrating the PCA2131 Automotive RTC into a Battery Management System (BMS). I am encountering a persistent issue where the Alarm Flag (AF, bit 4 of Control_2 register 01h) is stuck high. Basic SPI communication is functioning perfectly-I can successfully set and read the time registers without issue. However, I cannot clear the AF flag during initialization. Important Context: I have already ensured that all Alarm Enable (AE_X) bits in the alarm registers (0Ah through 0Eh) are set to 1 (disabled) prior to attempting to clear the AF flag. The sequence I am executing: Read Control_2 (Register 01h). The AF bit reads as 1. Clear the flag by setting AF = 0 and AIE = 0 in my local struct. Write the modified byte back to Control_2. Read Control_2 again. The AF bit is still 1. I have attached screenshots from my debug session showing the register states before clearing, during the clear operation, and after reading it back. My Questions: Given that all AE_X bits are disabled, what other internal conditions could force the AF flag to immediately re-assert (or prevent it from clearing)? Any insights or recommendations would be greatly appreciated! Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Hi Jozef, Thank you for your support and for pointing me in the right direction. I checked the SPI messages using the picoscope and verified that the hardware values were correct. Following your suggestion, I debugged my code further and confirmed that the root cause was indeed a bitfield ordering mismatch. I have fixed the mismatch, and the issue is now fully resolved. Thanks again for your help! Best regards, Vikas Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Hi Vikas, thank you for confirmation. Given the PCA2131 behavior described in the datasheet, and assuming AE_S/AE_M/AE_H/AE_D/AE_W are all 1. it does not look the RTC is legitimately re-triggering AF. Most likely cause is bitfield ordering mismatch. Could you please catch and share the scopes of the three reading, writing SPI messages? To confirm the timing and registers/bits written and read.  With Best Regards, Jozef Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Oops, sorry for the typo! The correct address is 0Eh to 12h. I just double-checked, and I did have it correct in my code, so it was just a mistake in my message. Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Hi Vikas, please double check the Alarm registers. These registers have address 0Eh to 12h.  Please try to set all the AE_x bits to 1 again.  With Best Regards, Jozef
記事全体を表示
Utility software issues How do I download the NXP MCUXpresso IDE development software used for the LPC1765FBD100? Thank you. Analog (ADC|CMP|DAC|OpAmps) Core and Memory Development Board Re: 工具软件问题 Hello, you can find the MCUXPresso download link here: Free Professional ARM Development Tools | NXP Semiconductors BR Celeste
記事全体を表示
S12X 串行 MCU,如何知道代码的起始地址 现在我有一个 Can 启动 Demo,它可以分析 S19 文件并将数据和偏移地址发送到 S9S12G64,MCU 只需要将数据写入主计算机发送的指定地址即可。我需要知道APP代码的起始地址,这里有一个app项目的prm文件,如何获取起始地址? Re: S12X serial MCU ,how to know the Code's START ADDRESS 你好@李乐 能否请您提供 MAP 文件或 S19 文件以供参考?谢谢。 BR 爱丽丝 Re: S12X serial MCU ,how to know the Code's START ADDRESS 以下是应用程序和启动代码 Re: S12X serial MCU ,how to know the Code's START ADDRESS 嗨@李乐 APP 的起始地址为 0xC000。 谢谢! BR 爱丽丝
記事全体を表示
PN7221+Android16 EDLA認証に関する問題 PN7221、Android 16   EDLA認証を受けたビルドは、部分的なNFC機能のみをサポートしています。当社のテストではカード検出機能は正常に動作しましたが、EMVCo、ファームウェアのアップグレード、その他の機能は利用できません。比較によって特定された根本原因は以下のとおりです。   EDLAビルドはGoogleの既製NFCサービスを使用する一方、AOSPビルドはNXPのパッチを統合してコンパイルされている。   以下は、EDLA関連のビルド構成の抜粋です。   apex_set {   名前:「com.google.android.nfcservices_compressed」   apex_name:「com.android.nfcservices」   オーバーライド: ["com.android.nfcservices"],   所有者: "google"、   セット:「com.google.android.nfcservices_compressed.apks」   ファイル名:「com.google.android.nfcservices_compressed.apex」、   exported_bootclasspath_fragments: ["com.android.nfcservices-bootclasspath-fragment"],   } このシナリオでNXPパッチをインポートする方法を教えてもらえますか?代替案はありますか?NXP NFCチップを使用している他のお客様に対して、完全なNFC機能を維持しつつEDLA認証に合格するためにどのようなアプローチが取られていますか? Re: PN7221+Android16 EDLA certification issues こんにちは、 @zhangkai さん。 私たちの分析によると、この問題はGoogleのプリビルドNFC APEX(com.android.nfcservices)を用いたEDLAビルドが原因である可能性が高いですNXPのAndroidミドルウェアと統合されたNFCモジュールの代わりに、 NXP Android 16ソリューションは、NFCフレームワーク、NFCサービス、EMVCoフレームワーク、HALおよび関連ライブラリを含むAndroid NFCスタックの複数層を拡張しています。GoogleのプリビルトNFCサービスを使用する場合、標準的なNFC機能のみが利用可能になり、EMVCo機能、ファームウェアアップデートサポート、その他のミドルウェア拡張などのNXP固有の機能はアクティブでない場合があります。 現時点でNXPのAndroid 16移植ドキュメントには、Googleの既製品EDLA NFC APEXを直接パッチまたは修正する方法について説明されていません。NXPの一般的な統合アプローチは、AOSPソースコードの統合と、NXPミドルウェアを用いたNFCスタックの再構築に基づいています。 PN7221のフル機能を必要とするお客様には、NXP NFCミドルウェアを含んでNFC APEXを再構築できるか、EDLA準拠を維持しつつEDLA NFCモジュールのカスタマイズについてGoogleやOEMのサポートに相談することをお勧めします。
記事全体を表示
ユーティリティソフトウェアの問題 LPC1765FBD100で使用するNXP MCUXpresso IDE開発ソフトウェアはどのようにダウンロードできますか? よろしくお願いします。 アナログ(ADC|CMP|DAC|オペアンプ) コアとメモリ 開発委員会 Re: 工具软件问题 こんにちは。MCUXPressoのダウンロードリンクはこちらです:無料のプロフェッショナルARM開発ツール|NXPセミコンダクターズ BR セレステ
記事全体を表示
S12X serial MCU ,how to know the Code's START ADDRESS Now I have a Can Boot Demo , it can analysis S19 file and send data and offset address to S9S12G64 , MCU just need to write flash on Specify address which master Computer send. I need to know the start address of the APP code ,there is the app project 's prm file ,how to get the start address?  Re: S12X serial MCU ,how to know the Code's START ADDRESS Here is APP and Boot Code Re: S12X serial MCU ,how to know the Code's START ADDRESS Hello @李乐  Could you please send the MAP file or the S19 file for reference? Thank you. BR Alice Re: S12X serial MCU ,how to know the Code's START ADDRESS Hi @李乐  The start address of APP is 0xC000. Thank you. BR Alice
記事全体を表示
在 i.MX8M Plus 和 TIM-VX/VSINPU 上,GC7000UL 通用计算推理路径似乎仅支持 NPU。 板/电路板支持包。: i.MX8M Plus,aarch64 Galcore 版本 6.4.11.p2.745085 ONNX 运行时,带有 VSINPUExecutionProvider(静态链接到 libtim-vx.so) Vivante OpenCL ICD 已存在且功能正常(Vivante.icd → libVivanteOpenCL.so) 目标: 专门在 GC7000UL 3D GPU 核心上运行 ResNet50 推理基准测试(MLPerf loadgen 测试框架),以便与已收集的现有 NPU(VIP8000Nano)和 CPU 基准测试结果进行比较。 已确认有效的功能: 通过 Vivante OpenCL ICD 使用 clGetPlatformIDs/clGetDeviceIDs 可以清晰地枚举同一平台下的两个独立设备: 设备 0:GC7000UL.6204.0000 设备 1:VIP8000Nano-S+I.8002.0000 两者都报告 CL_DEVICE_TYPE_ACCELERATOR,没有错误,通过链接到 libOpenCL.so → libGAL.so 的最小 C 测试程序确认。 是什么阻碍了通过 ORT 进行 GPU 调度: ort.get_available_providers() 仅返回 ['VSINPUExecutionProvider', 'CPUExecutionProvider'] — 没有基于 OpenCL 的 EP。 VSINPUExecutionProvider 静态链接到 libtim-vx.so(OVXLIB/vsi_nn_* API)。libtim-vx.so 和 libGAL.so 的符号/字符串转储显示没有 DEVICE_INDEX/DEVICE_ID 风格的环境变量或配置表面——只有行为切换(VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_* 等)。 libGAL.so 确实在原始 HAL 层导出了 gcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndex,但是从 OVXLIB/TIM-VX 到该调用没有明显的管道,这表明 VSINPU 使用的图形编译器可能被硬编码为仅针对 NPU 核心,而不管设备索引如何。 具体问题: 此电路板支持包 (galcore 6.4.11.p2) 上的 TIM-VX / OVXLIB 是否支持将图编译并分发到 GC7000UL 作为通用计算目标?或者,此版本中的图编译器是否设计为仅限 NPU?我如何验证是否可以以这种方式运行它? 如果 TIM-VX 上游支持 GPU 目标图编译,但 NXP 提供的版本中未启用,是否有构建标志/SDK 元器件可以启用它? 如果无法通过 TIM-VX/ORT 获得支持,NXP 是否有推荐的方法可以直接在 GC7000UL 上运行通用推理(例如通过 OpenCL/OpenVX 层,因为该部分协议栈已被确认功能正常),或者是否有示例应用程序、SDK 组件或参考实现可供我们参考? 我目前是一名学生,正在尝试进行这项实现,并在 GPU 上运行 ORT,请问是否有任何方法或途径可以使用 GPU 进行推理? 非常感谢 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 嗨@WaleedO , 感谢您联系恩智浦技术支持。 要在 GPU 上运行推理,您应该使用 GPU 委托,它允许由 GPU 加速支持的操作,而不是完全在 CPU 上运行。 我建议您查看我们的机器学习用户指南,以便更好地了解可用的执行后端、委托配置、支持的框架和示例应用程序。该指南还包含逐步示例,可以帮助您验证 GPU 委托是否已正确加载以及您的模型是否按预期执行。 如果在安装或执行过程中遇到任何问题,请分享您的模型、BSP 版本以及您正在使用的命令,我将很乐意为您提供进一步的帮助。 此致, 亚历杭德罗·加西亚 Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 你好@Chavira 很高兴见到你。 查阅文档后发现,GPU 委托和 OpenCL 路径是在 i.MX 95/952 GPU(Arm Mali G310)中使用。我目前正在研究IMX8MPLUS。IMX8M Plus 的架构如下:VX 代理 ==> TIM-VX ==> GPU/NPU(统一驱动程序) ==> I.MX 8 系列 NPU 和 GPU(GC7000、GC7000L、GC7000UL)。根据文件记载。 目前我正在使用 ONNX 和 ORT。当我运行该程序时,它默认在 NPU 上运行。是否有办法使用 OpenCL 在IMX8MPLUS GPU 上工作?或者是否有任何手动覆盖或我可以实现的技术,以便我可以手动将编译目标设置为 NPU 或/和 GPU? 非常感谢您的回复。 亲切的问候, IMX8MPLUS #TIM-VX #VX-delegate
記事全体を表示
PCA2131: コントロールレジスタ2のAF(アラームフラグ)はクリアできません こんにちは、皆さん 現在、 PCA2131 オートモーティブ RTCをバッテリー・マネジメント・システム(BMS)に統合しています。 アラームフラグ(AF、Control_2レジスタ01hのビット4)がハイのままになるという問題が継続的に発生しています。基本的なSPI通信は完璧に動作しており、タイムレジスタの設定や読み込みは問題なくできます。しかし、初期化時にAFフラグをクリアできません。 重要な背景情報: AFフラグをクリアする前に、アラームレジスタ(0Ah~0Eh)内のすべてのアラーム有効化(AE_X)ビットが1(無効)に設定されていることを既に確認済みです。 私が実行しているシーケンス: Control_2(レジスタ01h)を読み取ります。AFビットは1と読み取られます。 ローカル構造体でAF = 0とAIE = 0に設定してフラグをクリアします。 変更したバイトをControl_2に書き戻す。 Control_2をもう一度読み込んでください。AFビットはまだ1です。 デバッグセッションのスクリーンショットを添付しました。クリア前、クリア操作中、および読み出し後のレジスタの状態を示しています。 私の質問: すべてのAE_Xビットが無効化されている場合、他にAFフラグを即座に再アサートさせる(またはクリアを妨げる)内部条件は何でしょうか? ご意見やご提案をいただければ大変ありがたいです! Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear こんにちは、ヨゼフさん。 あなたのサポートと正しい方向への教えてくださり、ありがとうございます。 私はピコスコープを使ってSPIメッセージを確認し、ハードウェアの値が正しいことを検証しました。ご提案に従い、さらにコードをデバッグし、根本原因がビットフィールドの順序の不一致であることを確認しました。 不一致を修正しましたので、問題は完全に解決しました。ご協力ありがとうございました! よろしくお願いします、 ヴィカス Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear こんにちは、ヴィカスさん。 ご確認いただきありがとうございます。データシートに記載されている PCA2131 の動作を考慮すると、AE_S/AE_M/AE_H/AE_D/AE_W がすべて 1 であると仮定すると、RTC が AF を正しく再トリガーしているようには見えません。最も可能性の高い原因はビットフィールドの順序ミスマッチです。3つの読み書きSPIメッセージの範囲をぜひ教えていただけますか?タイミングと、書き込みおよび読み出しされたレジスタ/ビットを確認するため。 敬具、 ヨゼフ Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear おっと、タイプミスでごめんなさい!正しいアドレスは0Ehから12hです。再確認したところ、コードに正しく記載されていたので、メッセージの誤りでした。 Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear こんにちは、ヴィカスさん。 警報記録を再度確認してください。これらのレジスタのアドレスは0Ehから12hです。 AE_xビットをすべて1に再度設定してみてください。 敬具、 ヨゼフ
記事全体を表示
GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only Board/BSP: i.MX8M Plus, aarch64 Galcore version 6.4.11.p2.745085 ONNX Runtime with VSINPUExecutionProvider (statically linked against libtim-vx.so) Vivante OpenCL ICD present and functional (Vivante.icd → libVivanteOpenCL.so) Goal: Run ResNet50 inference benchmarks (MLPerf loadgen harness) on the GC7000UL 3D GPU core specifically, as a comparison point against existing NPU (VIP8000Nano) and CPU benchmark results already collected. What's confirmed working: clGetPlatformIDs/clGetDeviceIDs via the Vivante OpenCL ICD cleanly enumerates two independent devices under one platform: Device 0: GC7000UL.6204.0000 Device 1: VIP8000Nano-S+I.8002.0000 Both report CL_DEVICE_TYPE_ACCELERATOR, no errors, confirmed via a minimal C test program linked against libOpenCL.so → libGAL.so. What's blocking GPU dispatch via ORT: ort.get_available_providers() returns only ['VSINPUExecutionProvider', 'CPUExecutionProvider'] — no OpenCL-based EP. VSINPUExecutionProvider is statically linked to libtim-vx.so (OVXLIB/vsi_nn_* API). Symbol/string dump of both libtim-vx.so and libGAL.so shows no DEVICE_INDEX/DEVICE_ID-style env var or config surface — only behavior toggles (VIV_VX_ENABLE_SHADER, VSI_NN_ENABLE_*, etc). libGAL.so does export gcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndex at the raw HAL layer, but there's no visible plumbing from OVXLIB/TIM-VX down to that call which is  suggesting the graph compiler used by VSINPU may be hardcoded to target the NPU core only, regardless of device index. Specific question: Does TIM-VX / OVXLIB on this BSP (galcore 6.4.11.p2) support compiling and dispatching a graph to the GC7000UL as a general-compute target, or is the graph compiler NPU-only by design in this build, and how can I verify if it is possible to run it that way ?  If GPU-target graph compilation is supported upstream in TIM-VX but not enabled in this NXP-shipped build, is there a build flag / SDK component that exposes it? If there is no supported path through TIM-VX/ORT, is there an NXP-recommended way to run generic  inference on the GC7000UL directly (e.g. via the OpenCL/OpenVX layer, since that portion of the stack is confirmed functional) ,  a sample app, SDK component, or reference implementation we should be building against instead? as a currently a student, and trying to work on this implementation and running an ORT on TOP of the GPU, is there any way, or any other way to be able use the GPU for inference ?  Thank you very much  IMX8MPLUS  #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only HI @WaleedO, Thank you for contacting NXP Support. To run inference on the GPU, you should use the GPU delegate, which enables supported operations to be accelerated by the GPU instead of running entirely on the CPU. I recommend reviewing our Machine Learning User Guide to better understand the available execution backends, delegate configuration, supported frameworks, and example applications. The guide also includes step-by-step examples that can help you validate that the GPU delegate is being loaded correctly and that your model is executing as expected. If you encounter any issues during setup or execution, please share the model, BSP version, and the commands you are using, and I will be happy to assist further. Best regards, Alejandro Garcia Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only Hello @Chavira  Nice to meet you. After checking the documentation, the GPU delegate and the OpenCL path is used within  i.MX 95/952 GPU (Arm Mali G310). I am curently working on The IMX8MPLUS .  the imx8m Plus have this stack:  VX delegate ==> TIM-VX ==>  GPU/NPU (unified driver)  ==> I.MX 8 series NPU and GPU (GC7000,GC7000L, GC7000UL).  as per the documentation.  Currently, I am working with ONNX and ORT. When I run the execution, It is per default running on the NPU. Is there any way to use the OpenCL to work ont the IMX8MPLUS  GPU ? or if there is any manual override, or technique that I can implement, so that I can manually set the compilation toward either NPU or/And  GPU ?  Thank Your very much for your reply.  Kind regards,  IMX8MPLUS  #TIM-VX #VX-delegate
記事全体を表示
Zone Node Overview 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article series explains the role and behavior of a zonal controller communication component in a modern automotive electrical/electronic (E/E) architecture. This first article provides a short, high-level introduction to the zonal node and establishes a common understanding of its main responsibilities. The series gradually explains how this component enables message exchange between in-vehicle communication networks, with a particular focus on routed and broadcast communication over CAN and LIN. Later articles move from these concepts into more detailed design and implementation topics. As the entry point to the Zonal Communication and Control series, this article focuses on the zonal node from an architectural perspective. It does not cover system-level use cases or application-specific configurations, which are addressed in later articles. 3 Overview This article introduces an S32K3-based zonal node and explains how it connects to several in-vehicle networks. In practice, the zonal node sits between central vehicle controllers and local devices such as sensors, actuators, or small control modules, helping messages move between them. The zonal node receives messages from the central controller and forwards them to local nodes, while also sending status information and responses back to the central side. Depending on the system design, it can distribute the same message to multiple nodes or route specific messages only to the intended recipients. In addition to message forwarding, the zonal node may perform limited local processing, such as message filtering, signal aggregation, data validation, or basic decision-making related to communication handling. However, higher-level functional decisions are typically managed by central controllers, with the zonal node focusing primarily on efficient and reliable data exchange. This role becomes clearer in the context of evolving automotive E/E architectures. Traditional designs relied on many purpose-specific electronic control units (ECUs) connected through dedicated wiring. As system complexity increased, that approach added wiring weight, raised cost, and limited scalability. Figure 1. Zonal controller highlighted within the EV architecture Zonal architectures address these limitations by grouping nearby functions within the same physical area of the vehicle and moving more processing into central computing units. In this model, the zonal controller manages local communication and forwards relevant information to the central system. In this context, the S32K3 MCU family supports the required functionality by providing automotive communication interfaces such as CAN FD and LIN. On devices that include the necessary interfaces, the zonal node can connect different network types and handle message traffic between them. Within the scope of this project, the S32K3 platform is suitable for implementing the zonal node due to its available communication peripherals, processing capability, and automotive safety features, which are sufficient for the number of connected nodes and the complexity of the communication tasks considered. This article is intended for: System architects evaluating zonal or domain-based vehicle designs Embedded software engineers implementing communication routing logic Engineers evaluating MCU platforms for multi-network automotive applications By reading this series, you will understand why zonal communication components matter, how they fit into modern vehicle architectures, and how the S32K3 platform can support this role. 4 Context In a complete vehicle system, the zonal node sits between the central control system and local hardware. Its main job is to pass, route, or translate messages, not to make application-level decisions. Keeping these roles separate helps the system remain predictable, reliable, and easier to scale. The zonal node may receive messages from central controllers that manage vehicle-wide functions or from local devices such as sensors, actuators, and smaller control modules. It then exchanges this information across different networks in a controlled and time-aware way. Note: CAN and LIN remain important because they are widely used in automotive systems and are well suited to many control tasks. The S32K3 family supports these needs with integrated CAN FD and LIN interfaces and Arm® Cortex®-M7 CPU cores for routing and control tasks. It also includes automotive safety features aligned with ISO 26262 and low-power modes that are useful in some system designs. Together, these features allow the zonal node to handle several communication channels at the same time while keeping the network interfaces clearly separated. High-Level Architecture Diagram Figure 2. Diagram concept for S32K3 Zonal Node Figure 2 shows where the zonal node sits in the system: between the central control side and the local edge nodes, acting as the bridge between networks. Later articles will expand this context in a structured way. The series will first present the overall system, then describe the software and hardware environment that supports the zonal node. It will also cover internal control logic and key communication topics such as CAN-to-CAN routing, LIN-to-CAN routing, and Ethernet-to-CAN communication. Finally, it will discuss common challenges in multi-network routing and zonal integration. 5 References NXP Body Domain and Zonal Controller S32K3 for Zonal Aggregator 6 Conclusion This article provided a high-level introduction to the S32K3-based zonal node as a communication component in modern automotive architectures. It explained what the node does and where it fits in the system, creating a basis for the more detailed topics covered later in the series. Instead of focusing on implementation details, this introductory article explained why zonal nodes are needed and which problems they help address. The next articles in the series will build on this foundation by exploring system structure, configuration, communication routing strategies, and design challenges in greater detail.
記事全体を表示
如何确保 gPTP 二层数据包通过 S 上的 GMAC0 以最高优先级传输 你好 如何确保 gPTP 第 2 层数据包通过 S32G399 上的 GMAC0 以最高优先级传输? Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t 确保 gPTP 帧进入 Q4 区。 如何实现这一点? Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t 嗨,志杰 感谢您的回复和提供的信息。 您可以参考 BSP 用户手册,按照下图所示的方式尝试实现此功能。可以考虑为第四季度设定一个单独的时间窗口,并给予其更高的优先级。此外,确保 gPTP 帧进入 Q4。以下命令可用于设置第二层时间窗口,供参考: tc qdisc add dev eth0 root taprio \ num_tc 5 \ 地图 0 1 2 3 4 \ 队列 1@0 1@1 1@2 1@3 1@4 \ 基准时间 0 \ 计划条目 S 10 50000 \ 调度条目 S 0f 450000 \ 计划条目 S 1f 96 \ 标志 0x2 希望这些信息对您有所帮助。 BR 乔伊 Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t 您在 M 核或 A 核上使用 GMAC0 时是否使用 gPTP? A:在 A 核上 您目前是否正在使用GMAC的TSN功能?是否使用了VLAN? A:利用 GMAC 的 TSN 功能:gptp;gptp 数据包上没有 VLAN。 GMAC控制器提供五个发送/接收队列, 我需要将所有 gPTP 流量路由到优先级最高的 Tx/Rx 队列(q4)。 请问在Linux系统中,相应的寄存器配置、代码实现方法以及如何配置(例如:tc、ip)? Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t 嗨,志杰 感谢您与我们联系。您能提供更多信息吗? 您在 M 核或 A 核上使用 GMAC0 时是否使用 gPTP? 您目前是否正在使用GMAC的TSN功能?是否使用了VLAN? BR 乔伊 Re: How to ensure that gPTP Layer 2 packets are transmitted with the highest priority via GMAC0 on t 嗨,志杰 感谢您的回复。 您可以尝试在设备树的 gmac0 部分配置队列信息。 其中包含 arch\arm64\boot\dts\freescale\s32cc.dtsi 文件。         gmac0 :以太网@4033c000 { 状态 = "已禁用" ; compatible = "nxp,s32cc-dwmac" ; mtl_rx_setup_gmac0 : rx-queues-config { snps,要使用的 rx 队列 = < 5 >; #address-cells = < 1 >; #size-cells = < 0 >;                 queue@0 { };                 queue@1 { };                 queue@2 { };                 queue@3 { };                 queue@4 { }; };             mtl_tx_setup_gmac0 : tx-queues-config { snps,要使用的交易队列 = < 5 >; #address-cells = < 1 >; #size-cells = < 0 >;                 queue@0 { };                 queue@1 { };                 queue@2 { };                 queue@3 { };                 queue@4 { }; }; 另外,可以在 GMAC 驱动程序中找到 RX 队列数据包路由配置,您可以尝试将节点设置为 Q4 的“snps,route-ptp”。 如果您还有任何疑问,可以随时联系我们。   BR 乔伊
記事全体を表示