Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
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のトレソベースの例が含まれていますが、完全なマルチコアプロジェクトは見つかりませんでした。 petervlna_0-1783669665552.png 添付のプレゼンテーションもご確認ください。 よろしくお願いいたします。 ピーター 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.  JozefKozon_2-1783678052638.png 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.  JozefKozon_0-1783672873300.png JozefKozon_1-1783672931555.png 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 Celeste_Liu_0-1783663550952.png 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セミコンダクターズ Celeste_Liu_0-1783663550952.png 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メッセージの範囲をぜひ教えていただけますか?タイミングと、書き込みおよび読み出しされたレジスタ/ビットを確認するため。 JozefKozon_2-1783678052638.png 敬具、 ヨゼフ 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です。 JozefKozon_0-1783672873300.png JozefKozon_1-1783672931555.png 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. dragostoma_0-1782905205237.png 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 dragostoma_1-1782905238932.png 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 以最高优先级传输? zhijie_0-1783478043907.png 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 Joey_z_0-1783569523008.png 希望这些信息对您有所帮助。 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”。 Joey_z_0-1783656314593.png 如果您还有任何疑问,可以随时联系我们。   BR 乔伊
查看全文
S32 Design Studio for Power Architecture® 2017.R1 - License activation issue Hello, I would like to kindly request assistance regarding my license activation. My previous request was processed, but the wrong version was reactivated. I now have access to S32 Design Studio for Power Architecture v2.1, whereas I actually need to use S32 Design Studio for Power Architecture 2017.R1 (S32DS-PA v2.0) for my current projects. Could you please correct the activation and restore the proper version of the license? Thank you very much for your support. Best regards, Alessandro Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue Hello, I have requested it for you, Once it is done I will inform you. Best regards, Peter Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue Hello Peter, Thank you for your help. I just wanted to let you know that I have not received any update yet, and my license is still expired. As a result, I am currently unable to use S32 Design Studio for Power Architecture 2017.R1 (v2.0), and I am unable to continue my work. Best regards, Alessandro Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue Hello, All should be set at this time. Best regards, Peter Re: S32 Design Studio for Power Architecture® 2017.R1 - License activation issue Thank you very much, Alessandro
查看全文
libcamera on imx8mp 恩智浦 FAE 你好: 我想知道恩智浦目前是否在 imx8mp 平台上支持 libcamera? https://libcamera.org/getting-started.html。 我明白在 yocoto kirkstone 电路板支持包中,配方 libcamera 位于 meta-openembedded/meta-multimedia/recipes-multimedia/libcamera/libcamera.bb 下当我在图像中添加目标 libcamera 并在 imx8mp-evk 板上运行时,libcamera 在检测捕获设备时什么也没报告。当运行 gst-launch 时,结果是一样的。 LIBCAMERA_LOG_LEVELS=*:DEBUG gst-device-monitor-1.0 Video IPAModule ipa_module.cpp:329 ipa_vimc.so: IPA module /usr/lib/libcamera/ipa_vimc.so is signed IPAManager ipa_manager.cpp:240 Loaded IPA module '/usr/lib/libcamera/ipa_vimc.so' Camera camera_manager.cpp:293 libcamera v0.0.0 Camera camera_manager.cpp:106 Starting camera manager DeviceEnumerator device_enumerator.cpp:224 New media device "mxc-md" created from /dev/media0 DeviceEnumerator device_enumerator_udev.cpp:95 Defer media device /dev/media0 due to 1 missing dependencies DeviceEnumerator device_enumerator_udev.cpp:320 All dependencies for media device /dev/media0 found DeviceEnumerator device_enumerator.cpp:252 Added device /dev/media0: mxc-md Camera camera_manager.cpp:149 Found registered pipeline handler 'PipelineHandlerUVC' Camera camera_manager.cpp:149 Found registered pipeline handler 'SimplePipelineHandler' Camera camera_manager.cpp:149 Found registered pipeline handler 'PipelineHandlerVimc' 当我回读 libcamera 代码时,发现相机需要在 libcamera 使用前注册。 bool PipelineHandlerRPi::match(DeviceEnumerator *enumerator) { DeviceMatch unicam("unicam"); MediaDevice *unicamDevice = acquireMediaDevice(enumerator, unicam); if (!unicamDevice) { LOG(RPI, Debug) << "Unable to acquire a Unicam instance"; return false; } DeviceMatch isp("bcm2835-isp"); MediaDevice *ispDevice = acquireMediaDevice(enumerator, isp); if (!ispDevice) { LOG(RPI, Debug) << "Unable to acquire ISP instance"; return false; } int ret = registerCamera(unicamDevice, ispDevice); if (ret) { LOG(RPI, Error) << "Failed to register camera: " << ret; return false; } return true; } 所以,我有以下问题。 1.恩智浦电路板支持包目前是否支持 libcamera,例如相机设备 ov5640? 2.如果没有,恩智浦是否有任何支持libcamera的计划或对此有任何建议/参考设计/指南/补丁? 3.在 libcamera 中为新相机添加支持功能有多复杂? 我是 libcamera 的新手,希望得到您的帮助/指导/信息。 致以最崇高的敬意 Johnson Re: libcamera on imx8mp 我对 VSI SDK 也很感兴趣。如果我能在外置摄像头捕获的帧上使用 Vivante ISP8000 的 3A 算法,那将非常有用 Re: libcamera on imx8mp 嗨,Sanket Parekh, 感谢您提供的信息。我会根据您提供的信息进行更多研究。 致以最崇高的敬意 约翰逊 Re: libcamera on imx8mp 你好@Sanket_Parekh、 请问 vsi SDK 是什么? 提前感谢你的帮助,顺祝商祺! Khang Re: libcamera on imx8mp 你好@张俊生 希望你一切都好。 如果客户没有自己的 3A 和其他模块算法,我们不建议他们使用 lib-camera、 VSI 软件包是个不错的选择。现在我们将支持 vsi SDK。 如果客户对 lib-camera 感兴趣,并且是 ISP 专家,GitLabhttps://gitlab.com/ideasonboard/nxp/libcamera上有开放源代码。 谢谢& 、 桑凯特-帕瑞克 Re: libcamera on imx8mp 你好@zhangjunsheng、 我找到了这个软件源:https://gitlab.com/ideasonboard/nxp/libcamera Re: libcamera on imx8mp 这里想强调的是——是的,libcamera 对 i.MX8MP 的支持非常好,但是你必须在 Linux 内核上启用正确的内核驱动程序。 libcamera 使用了 Linux 内核中看似不太明显的 RKISP1 驱动程序,因为 ISP 具有共同的传承,但该平台本身得到了非常强大的支持,在商业产品中得到应用,我们可以轻松支持许多用例和定制。 而且您无需签署任何许可协议,即可获得完整的源代码!(所有源代码均可在上游公开获取,网址为https://gitlab.freedesktop.org/camera/libcamera ))
查看全文
MC34GD3000 gate drive output voltage level when VPWR is 24 V Hello NXP Community, I am planning to use the MC34GD3000 to drive a 24 V, 26 W motor. In many reference circuits and examples, the VPWR supply of the MC34GD3000 appears to be connected to the same supply voltage as the motor supply. In my application, the motor supply voltage will be 24 V, so VPWR of the MC34GD3000 will also be 24 V. I would like to clarify the gate drive output voltage level of the MC34GD3000. In the datasheet absolute maximum ratings table, I found values such as: - PX_HS_G to PX_HS_S: 3.0 V to 16.5 V - PX_LS_G to PX_LS_S: 3.0 V to 16.5 V - PX_BOOT to PX_HS_S: 3.0 V to 16.5 V My question is: When VPWR is 24 V, what is the actual PWM gate drive output voltage level of the MC34GD3000? Does the gate drive output become 24 V because VPWR is 24 V, or is the gate drive output limited to approximately 16.5 V maximum with respect to each MOSFET source node? For example, for the low-side MOSFET, should I understand that PX_LS_G to PX_LS_S is driven up to around 15 V, not 24 V? And for the high-side MOSFET, should I understand that PX_HS_G is driven above the phase node, but the gate-to-source voltage PX_HS_G to PX_HS_S is still limited to around 15 V? I would appreciate your confirmation. Thank you. BLDC Driver Re: MC34GD3000 gate drive output voltage level when VPWR is 24 V Hello, Yes, your understanding is correct. Even when VPWR is connected to a 24 V motor supply, the MC34GD3000 does not drive the MOSFET gates to 24 V with respect to their source terminals. The device generates an internal gate-drive supply (VLS), which is regulated to approximately 15 V. ErikaC_1-1783696364130.png ErikaC_0-1783696304074.png Therefore: For the low-side MOSFET, PX_LS_G is driven to approximately 15 V above PX_LS_S. For the high-side MOSFET, PX_HS_G is driven above the phase node through the bootstrap circuit, but the gate-to-source voltage PX_HS_G − PX_HS_S remains approximately 15 V. ErikaC_2-1783696431300.png The limits shown in the datasheet (PX_HS_G to PX_HS_S and PX_LS_G to PX_LS_S) represent the effective gate-to-source drive voltage and indicate that the gate drive is not equal to the 24 V VPWR supply. Hope this helps!
查看全文
Zephyr の FlexSpi 1 台で 2 つの NOR フラッシュを構成できない こんにちは、 私は i.mx RT1050 ボードをベースにしたボードを使って作業しています。flexspi の 2 つのバンクには 2 つの NOR フラッシュがコネクテッド。XIP ブートにはバンク 1 も使用しています。フラッシュを 1 つだけ使用すると正常に動作します。しかし、2 番目のフラッシュを追加すると、LUT 用のスペースが不足しているように見える問題が発生します。私の 2 つのフラッシュは w25q128 と w25q64 で、それぞれ flexspi ポート A1 と B1 にコネクテッドされています。   これはオーバーレイ ファイル内の私の設定です。   / { chosen { zephyr,flash-controller = &w25q128jv; zephyr,flash = &w25q128jv; zephyr,code-partition = &slot0_partition; }; };   &flexspi { status = "okay"; rx-clock-source = <1>; pinctrl-0 = <&pinmux_flexspi1>; pinctrl-names = "default"; reg = <0x402a8000 0x4000>, <0x60000000 DT_SIZE_M(64)>; /delete-node/ is25wp064@0; w25q128jv: w25q128jv@0 { compatible = "nxp,imx-flexspi-nor"; size = ; reg = <0>; spi-max-frequency = <104000000>; status = "okay"; jedec-id = [ef 70 18]; erase-block-size = ; write-block-size = <16>; enter-4byte-addr = <0>; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; boot_partition: partition@0 { label = "mcuboot"; reg = <0x00000000 DT_SIZE_K(256)>; }; /* Adjusted slot sizes for 16MB total */ slot0_partition: partition@20000 { label = "image-0"; reg = <0x00040000 (DT_SIZE_M(3) + DT_SIZE_K(512))>; }; slot1_partition: partition@320000 { label = "image-1"; reg = <0x00320000 DT_SIZE_M(3)>; }; storage_partition: partition@620000 { label = "storage"; reg = <0x00620000 (DT_SIZE_M(1) - DT_SIZE_K(768))>; }; }; }; w25q64jv: w25q64jv@2 { compatible = "nxp,imx-flexspi-nor"; size = ; /* 8MB (64Mbit) flash */ reg = <2>; /* FlexSPI B */ spi-max-frequency = <104000000>; status = "okay"; jedec-id = [ef 40 17]; /* Winbond W25Q64JV JEDEC ID */ erase-block-size = ; write-block-size = <16>; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; data_partition: partition@0 { label = "data-storage"; reg = <0x00000000 DT_SIZE_M(8)>; }; }; }; };   そしてピンマックスは、   &pinctrl { pinmux_flexspi1: pinmux_flexspi1 { group_a { pinmux = <&iomuxc_gpio_sd_b1_06_flexspi_a_ss0_b>, <&iomuxc_gpio_sd_b1_07_flexspi_a_sclk>, <&iomuxc_gpio_sd_b1_08_flexspi_a_data0>, <&iomuxc_gpio_sd_b1_09_flexspi_a_data1>, <&iomuxc_gpio_sd_b1_10_flexspi_a_data2>, <&iomuxc_gpio_sd_b1_11_flexspi_a_data3>; drive-strength = "r0-6"; slew-rate = "fast"; nxp,speed = "200-mhz"; input-enable; }; group_b { pinmux = <&iomuxc_gpio_sd_b1_03_flexspi_b_data0>, <&iomuxc_gpio_sd_b1_02_flexspi_b_data1>, <&iomuxc_gpio_sd_b1_01_flexspi_b_data2>, <&iomuxc_gpio_sd_b1_00_flexspi_b_data3>, <&iomuxc_gpio_sd_b1_04_flexspi_b_sclk>, <&iomuxc_gpio_sd_b1_05_flexspi_b_ss0_b>; drive-strength = "r0-6"; slew-rate = "fast"; nxp,speed = "200-mhz"; input-enable; }; };     起動時にプログラムはこのwhileループに突入し、   if (flash_flexspi_nor_probe(data)) { if (memc_flexspi_is_running_xip(&data->controller)) { /* We can't continue from here- the LUT stored in * the FlexSPI will be invalid so we cannot XIP. * Instead, spin here */ while (1) { /* Spin */ } } LOG_ERR("SFDP probe failed"); return -EIO; }     ステップごとにデバッグしてみると、各フラッシュ デバイスが LUT で 40 ~ 48 のスペースを使用しているように見えます。したがって、フラッシュが 2 つあると、最大 LUT である 64 を超えてしまいます。   何か間違ったことをしているのでしょうか?これを実現するにはどうすればいいでしょうか i.MXRT 105x Re: Cannot configure two NOR flashes on single FlexSpi in Zephyr 2 つのフラッシュを並列モードではなく独立して使用していると理解しています。XIP に使用されるフラッシュの LUT を予約し、IP コマンドを使用して他のフラッシュにアクセスできます。もう 1 つのオプションは、2 つのフラッシュの LUT をリサイクルすることです (両者の差はサイズであるため)。そして、2 番目のフラッシュの SFDP を無効にします。 BR、 オマール Re: Cannot configure two NOR flashes on single FlexSpi in Zephyr こんにちは、 私も同じ問題に直面しています。 どうやって問題を解決したのか教えていただけますか?2つ目のフラッシュメモリにデータを保存する必要があるだけです。2回目のフラッシュだけにXIPを無効にするにはどうすればいいですか? ありがとうございました。 よろしくお願いいたします。 アドリアン・クレリス
查看全文