#S32K388 Enhanced RX FIFO + eDMA: Continuous Circular Buffer Reception Without CPU Interrupts Hi NXP Support, I am using an S32K388 with the FlexCAN Enhanced RX FIFO and RTD. I would like to implement a continuous DMA-based CAN reception without any CPU interrupt. My requirements are: MCU: S32K388 CAN: Classical CAN, CAN FD disabled CAN payload: 8 bytes FlexCAN Enhanced RX FIFO enabled DMA reception enabled I need to receive CAN messages with any CAN ID, without filtering. I want DMA to automatically transfer every received CAN frame into a RAM software ring buffer. I do not want a FlexCAN RX interrupt. I also do not want a DMA major-loop-complete interrupt. DMA should continue running automatically without the CPU having to call FlexCAN_Ip_RxFifo() again. Ideally, each received FIFO element should trigger a DMA transfer immediately, so I do not want to wait for a large FIFO watermark. I checked the RTD source code. In FlexCAN_StartRxMessageEnhancedFifoData(), I found that the driver configures DMA approximately as follows: Source address = Enhanced RX FIFO output Source transfer size = 4 bytes Source offset = 4 bytes Destination transfer size = 4 bytes Destination offset = 4 bytes Minor loop size = 80 bytes Major loop count = num_enhanced_watermark EnMajorInt = TRUE DisAutoHwRequest = TRUE I understand that the current RTD implementation performs a finite DMA transfer and then stops, requiring FlexCAN_Ip_RxFifo() to be called again. My question is: Is it possible on S32K388 to configure the eDMA TCD so that the FlexCAN Enhanced RX FIFO DMA request continuously transfers received FIFO elements into a circular RAM buffer, without any CPU interrupt or software re-arming? In particular, can Destination Modulo and/or another eDMA TCD feature be used to implement this continuous ring buffer? If this is possible, could you please provide an example configuration or point me to an NXP example/reference implementation? I am willing to modify the RTD FlexCAN driver or configure the eDMA TCD directly if necessary. Thanks! Re: #S32K388 Enhanced RX FIFO + eDMA: Continuous Circular Buffer Reception Without CPU Interrupts Hello @zhangyu5454, The driver is written in a way that requires FlexCAN_Ip_RxFifo() to be called in order to re-arm reception inside the FLEXCAN_EVENT_DMA_COMPLETE event. It should be possible to have a continuous transfer from DMA to buffer; however, you will need to modify the RTDs or create your own driver. Unfortunately, this is out of our support scope, and if done, verification and functionality should be tested by you. You would have to set TCDn_CSR[D_REQ] = 0 (DisAutoHwRequest = FALSE) & TCDn_CSR[INTMAJOR] in order to keep the channel armed and disable interrupts, as well as configure your circular data queue. You can refer to S32K3's DMA Training Presentation, under S32K3 Product Page and 'Secure Files'. Best regards, Julián

KW45B41Z-EVKへのAI/MLの実装 こんにちは、NXPコミュニティの皆さん、 私はKW45B41Z-EVK(Cortex-M33)向けのエッジAIアプリケーションを開発しており、このボード上で機械学習モデルを展開する際にアドバイスをいただきたいです。 KW45 SDKにはデフォルトでeIQ/TFLMミドルウェアが含まれていないため、私の計画は以下の通りです: モデルトレーニング:eIQ Time Series Studio(eIQ TSS)を用いて時系列データのnクラス分類モデルを訓練します。KW45はeIQ TSSのターゲットとしてリストされていないため、モデルをエクスポートするターゲットプラットフォームとしてFRDM-MCXN947(Cortex-M33)を選択しました。 ランタイムデプロイ:FRDM-MCXN947 SDKのmiddleware/eiq/tensorflow-liteフォルダを私のKW45 SDKプロジェクトにポートし、CMSIS-NNと連携させます。 私の質問： MCXN947 SDKからKW45 SDKへのeIQ TFLMミドルウェアの移植は有効でサポートされている方法でしょうか? eIQ TSSでFRDM-MCXN947を選択することは、KW45上で動作するモデルを生成するのに適していますか? KW45B41Z-EVKにAI/MLを実装するための、他に推奨されるワークフローやネイティブなワークフローはありますか？ ご協力いただきありがとうございます！ KW45B41Z-EVK KW45 EIQ-TFLITE-MICRO EIQ-ツールキット#AIML Re: Implementing AI/ML on KW45B41Z-EVK こんにちは、お元気でお過ごしでしょうか。 eIQ Time Series Studio (TSS) を使用している場合は、FRDM-MCXW71 からプロジェクトを移植することをお勧めします。eIQ TSSで公式にサポートされているターゲットであり、KW45ともソフトウェア互換性があります。両デバイスは同じCortex-M33コアアーキテクチャと似たメモリプロファイルを共有しているので、生成されるライブラリはあなたのハードウェアにかなり近いはずです。 FRDM-MCXN947のようにハードウェアプロファイルが大きく異なるデバイスをポーティング対象として使用する場合、両デバイス間の利用可能なRAMの違いや、MCXN947特有のNPU加速モデルの生成などにより互換性のないモデルを生成するリスクがあります。 お役に立てば幸いです！ よろしくお願いします、 ソフィア。

MCU SDKにI2Cドライバを追加 NXPチームの皆様、こんにちは。 MCU SDKに24cxxシリーズのeeprom i2cドライバを追加したいと考えています。どうやって追加できるのでしょうか? ありがとうございます。 Re: Add I2C driver to MCU SDK こんにちは、 @taw さん。 あなたが共有してくれた情報からすると、カスタムSDKを探しているのだと思います。 このプロセスは使っているIDEによって異なります。 MCUXpresso for VS Codeについては、以下のドキュメントを参照してください。 MCUXpresso SDK：カスタムマニフェストの作成 MCUXpresso IDEについては、以下のドキュメントを参照してください。 カスタム基板サポートパッケージの作成 |NXP半導体 もしこれがあなたの言及でなければ、申請の詳細を教えていただけますか? よろしくお願いします、 パブロ

向MCU SDK添加I2C驱动程序 您好，NXP团队， 我们希望在MCU SDK中添加我们的24cxx系列eeprom i2c驱动程序。我们该如何添加它？ 谢谢 & 此致敬礼， Re: Add I2C driver to MCU SDK 嗨@taw ， 根据您提供的信息，我推测您正在寻找定制的 SDK。 具体过程取决于您使用的集成开发环境 (IDE)。 对于 VS Code 版 MCUXpresso，您可以参考以下文档： MCUXpresso SDK：创建自定义清单 对于 MCUXpresso IDE，您可以参考以下文档： 创建定制板支持包 | 恩智浦半导体 如果您指的不是这个，请您提供更多关于您的请求的详细信息好吗？ 此致， 巴勃罗

Plumber Fairfield CA Fast & Reliable Local Plumbers Plumber Fairfield CA provides professional plumbing services for homeowners and businesses dealing with everyday plumbing needs and unexpected emergencies. From leaking faucets and clogged drains to water heater problems and damaged pipes, having access to a dependable local plumber can help prevent small plumbing issues from becoming more serious and costly. The main idea behind choosing a Plumber Fairfield CA is simple: get reliable local help when you need plumbing repairs, maintenance, or emergency assistance. Professional plumbers can diagnose plumbing problems, recommend the appropriate solution, and complete repairs using the right tools and techniques. Whether you are dealing with a slow drain, a hidden leak, low water pressure, sewer problems, or a water heater issue, a qualified plumber in Fairfield, CA can help keep your residential or commercial plumbing system working properly.

S32DS activation code expired Hi: My license of S32 Design Studio for S32 Platform v.3.4 is about to expire. Could you help check and extend it for me?  Activation code: 533B-878B-88A9-C68F Thanks. Re: S32DS activation code expired Hi,  your S32DS license has been extended. 

S32DS激活码已过期 您好： 我的S32 Design Studio for S32 Platform v.3.4许可证即将到期。 您能帮我检查并延长一下吗？ 激活码：533B-878B-88A9-C68F 谢谢。 Re: S32DS activation code expired 你好， 您的S32DS许可证已延期。

科罗拉多州洛夫兰市水管工常见管道问题及何时寻求帮助 最后更新日期：2026年9月9日（官方网站链接见评论框） Loveland Co 管道公司指的是科罗拉多州 Loveland 市提供的专业管道服务，旨在帮助房主和企业处理常见的管道需求。从水龙头漏水、排水管堵塞到热水器问题以及更复杂的管道维修，经验丰富的管道工可以提供切实可行的解决方案，使管道系统正常运转。这就是为什么在科罗拉多州洛夫兰市选择一位可靠的水管工，以便在需要及时可靠的服务时非常重要的原因之一。 Plumber Loveland Co 的主要理念很简单：为客户提供专业的管道服务，包括日常维修、维护、安装和突发的管道问题。合格的当地水管工可以帮助找出问题的原因，推荐合适的解决方案，并安全高效地完成必要的工作。无论您需要小修小补还是大型管道工程方面的帮助，拥有值得信赖的管道专业人员都能帮助保护您的财产，并保持您家中管道系统的顺畅运行。

HSE: Error code 0x67030001 after first two resets following MU install I have followed the install procedure for installing through MU interface in FULL_MEM mode, as described in section 3.2.3.1 in Firmware Reference Manual version 2.7. Installing works exactly as described, but when I perform a functional reset (step 7) I get HSE error code 0x67030001. This persists after a second reset but reliably goes away after a third. I have a few questions: Is the particular value of uppermost bits (0x6703) significant? What could cause the HSE driver to enter an error state on startup but recover following exactly two resets? What is the most likely cause for the error in the first place? Re: HSE: Error code 0x67030001 after first two resets following MU install Hi @Emma_G-gbg  As indicated in the HSE_B Firmware Reference Manual, the GSR register logs fatal and warning events in its 16 least significant bits: Bits 0-7 indicate fatal errors. Bits 8-15 indicate warnings (non-fatal failures). The 16 most significant bits are reserved for NXP internal errors. Since bit 0 is set on your device, this indicates that a fatal error occurred, causing the HSE to shut down. In this state, a device reset is required to recover and exit the shutdown mode. Could you please share the values of the FSR register and HSE_CONFIG_GPR3 (0x4039C028)? Also, after performing the reset, did you wait until the HSE_STATUS_INIT_OK flag in GPR3 was set? Additionally, in the thread S32K3 recovery issue when install HSE fw via MU, a demo for HSE firmware installation via MU was shared. It may serve as a useful reference. BR, VaneB Re: HSE: Error code 0x67030001 after first two resets following MU install Hi @Emma_G-gbg  Resets 1 & 2: FSR = 0x00400000. Bit 24 (HSE_STATUS_INIT_OK) is not set, which indicates that HSE had not yet completed its initialization. The GSR value 0x67030001 shows that bit 0 (HSE_ERR_GENERAL) is set, which triggered an HSE sub-system shutdown. Reset 3: FSR = 0x09600000. Bit 24 (HSE_STATUS_INIT_OK) is now set, indicating that HSE completed its initialization successfully. The GSR value0x00000000 shows that no HSE errors/warnings were reported. A possible cause of this behavior could be that the application is performing clock initialization, XRDC configuration, or Flash operations before HSE initialization is fully completed. Re: HSE: Error code 0x67030001 after first two resets following MU install After the first two resets the values were as follows: HSE_CONFIG_GPR3: 0x10000081 DCMRWP1: 0xA5000400 GSR: 0x67030001 FSR: 0x00400000 Then after the third reset values were: HSE_CONFIG_GPR3: 0x000000C1 DCMRWP1: 0xA5000400 GSR: 0x00000000 FSR: 0x09600000   Re: HSE: Error code 0x67030001 after first two resets following MU install Hi @Emma_G-gbg  Regarding XRDC, refer to the note in Section 14.6.3 of the HSE_B Firmware Reference Manual, Rev. 2.7. For clock initialization, the relevant information can be found in Section 2.4.2.3.3 of the same document. Re: HSE: Error code 0x67030001 after first two resets following MU install Thank you, I'm looking into flash synchronization now. I was not aware that clock or XRDC init could affect HSE startup, where is this described?

POWER consumption at runtime on NXP i.MX93 & i.MX8MPLUS EVK I am using NXP i.MX93 & i.MX8MPLUS EVK and want to monitor the POWER consumption at runtime how can I get this data ? The agenda is to monitor the power during the inference of AI-models. How can I monitor the power metrics ?  How can I monitor power metrics using only software, without any external hardware? Re: POWER consumption at runtime on NXP i.MX93 & i.MX8MPLUS EVK Thank you for this detailed information and reference to ANI3054. This is very helpful. Does the i.MX93 EVK also have a similar power measurement setup , or is there a different approach recommended for i.MX93? Re: POWER consumption at runtime on NXP i.MX93 & i.MX8MPLUS EVK Please refer to the document AN13054 i.MX 8M Plus Power Consumption Measurement To measure the power consumption, the PWR CPU board is designed with current sense resistors of suitable value inserted between the PMIC and CPU for each key power rail. The power data is obtained by sampling the average voltage drop across the sense resistors using power monitor chip PAC1934. The voltage drop for each power supply is divided by its sense resistor value within the BCU PC software tool to calculate the current.

LSDK 21.08 OP-TEE breaks boot Custom board using LS1043AE have it secure booting just fine with no OP-TEE. Trying to introduce OP-TEE to the system and console outputs and hangs at: NOTICE: 2 GB DDR4, 32-bit, CL=11, ECC off NOTICE: BL2: v2.4(release):LSDK-21.08-1-ga08bfddba-dirty NOTICE: BL2: Built : 22:39:20, Aug 31 2026 NOTICE: Initializing & configuring SEC block. NOTICE: Sec is already initialized and configured. NOTICE: Verifying RSA NOTICE: Verifying hash NOTICE: Verifying RSA NOTICE: Verifying hash NOTICE: Verifying RSA NOTICE: Verifying hash NOTICE: BL2: Booting BL31 NOTICE: BL31: v2.4(release):LSDK-21.08-1-ga08bfddba-dirty NOTICE: BL31: Built : 22:39:48, Aug 31 2026 NOTICE: Welcome to ls1043aerb BL31 Phase According to Google/Gemini it thinks there is a problem with GIC. ATF and OP-TEE appear to be using 64k page aligned, but in a uboot dts it has it at a 4k page aligned. I don't think it's this issue, or at least not yet. Because it doesn't appear to Initialize OP-TEE at all. Thoughts? QorIQ LS1 Devices Re: LSDK 21.08 OP-TEE breaks boot It seems that there is problem with your u-boot. Would you please try whether it can work to boot normal u-boot(not secured) with OPTEE enabled? Re: LSDK 21.08 OP-TEE breaks boot I don't mind trying that, but what is that testing for? What are you currently thinking is possibly wrong with uboot? Since it works without optee I'm curious as to what could be wrong or what I should look for? Re: LSDK 21.08 OP-TEE breaks boot What I would check first: Rebuild TF-A in debug mode and confirm the exact stop point. Use DEBUG=1 LOG_LEVEL=50 if practical, or add NOTICE() breadcrumbs in early BL31 platform code around: platform setup entry GIC init TZC/TZASC/TZPC setup secure payload dispatcher / OP-TEE setup BL32 entry-point preparation NXP support guidance for similar LS1043A hangs is to add ATF/U-Boot debug prints or use CodeWarrior/JTAG to inspect where execution is stuck. Verify the FIP actually contains BL32 and that BL31 was built with OP-TEE support. For OP-TEE in TF-A, the build must include SPD=opteed and BL32=  ; for secure boot/NXP CoT, the secure TF-A build flow also includes TRUSTED_BOARD_BOOT=1 , CST_DIR=... , BL32=$TEE_BIN , SPD=opteed , and BL33=$UBOOT_SECURE_BIN . Run something like:  fiptool info fip.bin and confirm BL31, BL32/OP-TEE, and BL33 are all present. If BL32 is missing or BL31 was not built with SPD=opteed , OP-TEE will never be entered. Check LS1043A secure-boot reserved-memory handling. There is a reported LS1043A secure-boot issue fixed by changing plat/nxp/soc-ls1043a/soc.def NXP_ROM_RSVD from 0x5900 to 0x8000 . Since you are already secure-booting and now adding another signed FIP component, this is worth checking early. It is more plausible than a later U-Boot DTS GIC alignment issue. Do not assume “RSA/hash verified” means the image layout is good. Your BL2 log proves authentication reached success for the components it validated, but it does not prove the runtime addresses, reserved-memory overlap, BL32 load address, or BL31 secure-payload configuration are correct. BL2 is documented as loading BL31/BL32/BL33 to DDR after validation before handing control to BL31. If the hang moves to BL31: Initializing BL32 , then shift focus to OP-TEE proper. At that later stage I would look at OP-TEE load address, secure DDR carveout, pager/non-pager layout, CAAM/SEC configuration, and OP-TEE console. There is NXP guidance in a related OP-TEE/crypto context to try disabling crypto/CAAM in OP-TEE with CFG_NXP_CAAM=n and CFG_CRYPTO_DRIVER=n when early OP-TEE crypto initialization is suspected. But your current log does not yet prove OP-TEE is being entered. My strongest hypothesis: BL31 is built/configured differently when OP-TEE is enabled and is hanging in early BL31 platform/SPD setup before the OP-TEE banner or BL32 entry. I would first instrument BL31 around GIC/platform setup and verify FIP/ SPD=opteed / BL32=tee.bin /secure-boot CSF layout, then check the LS1043A NXP_ROM_RSVD=0x8000 issue. Re: LSDK 21.08 OP-TEE breaks boot So I built atf with debugging and the final message I get before silent hang is: INFO: BL31: Initializing BL32 So if I understood your recommandation correctly, I should focus on OP-TEE specifically now, correct? Re: LSDK 21.08 OP-TEE breaks boot Yes, please verify OP-TEE with normal boot(not secured) first to make sure there is no problem with your building and deployment procedure with OP-TEE. Re: LSDK 21.08 OP-TEE breaks boot I believe I was using the wrong tee.bin. I was using the tee.bin that was generated during a manual build of OP-TEE and not the objcopy version I needed to generate. That appears to allow the system to initialize and boot into linux. I do have more kernel logging messages about optee that I need to look into, but I will close this thread because this specific issue is resolved.

ハードウェアシミュレーションには、システムVerilogやVAMS、またはPCA9698DGG,512(GPIOエキスパンダー)のspiseモデルが必要です。 システム用Verilog、VAMS、またはIOエクスパンダーの部品番号のSPICEモデルが必要です - PCA9698DGG,512。重要な業務に必要なため、至急ご提供ください。 データシートリンク - PCA9698 40ビットFm+ I2Cバス:RESET、OE、INT対応の高度なI/Oポート

关于 QNX 7.1 上 S32G274A PFE 的 PTP/IEEE 1588 支持和配置指南的请求 专家您好！ 我们计划在我们定制的 S32G274A 板的 PFE 以太网接口上实现 IEEE 1588/PTP 时间同步。 我们目前的软件配置如下： - SoC：NXP S32G274A - 电路板：基于 S32G274A 的客户电路板 操作系统：QNX 7.1 - PFE驱动程序：PFE-DRV_S32G_A53_QNX 1.9.0，io-pkt版本 - PFE固件：PFE-FW_S32G 1.12.0 - 正在测试的 PFE 接口：PFE EMAC0 和 PFE EMAC2 - 由于 PFE EMAC1 的外部 AQR113C PHY 的固件尚未编程，因此当前测试中未包含 PFE EMAC1。 我们检查了 PFE 驱动程序源代码，发现它包含 IEEE 1588 支持，并实现了以下 QNX 驱动程序特定的 PTP 命令： - PTP_GET_TIME - PTP_SET_TIME - PTP_GET_TX_TIMESTAMP - PTP_GET_RX_TIMESTAMP - PTP_SET_COMPENSATION - PTP_GET_COMPENSATION 当前默认版本配置禁用了此功能： PFE_CFG_IEEE1588_SUPPORT=0 PFE_CFG_IEEE1588_I_CLK_HZ=0 PFE_CFG_IEEE1588_EMAC0_O_CLK_HZ=0 PFE_CFG_IEEE1588_EMAC1_O_CLK_HZ=0 PFE_CFG_IEEE1588_EMAC2_O_CLK_HZ=0 我们的启动代码已经通过 SCMI 启用了 PFE_TS 时钟，但我们还没有在 PFE 驱动程序中配置 IEEE 1588 输入和输出时钟频率。 请问您能否就以下问题提供指导？ 1.在 QNX 7.1 上使用 PFE-DRV 1.9.0 和 PFE-FW 1.12.0 时，S32G274A 上的 PFE EMAC0/EMAC1/EMAC2 是否正式支持 IEEE 1588 硬件 TX 和 RX 时间戳？ 2. S32G274A 的预期 SCMI PFE_TS 时钟频率是多少？ 3. 以下构建参数建议取哪些值？ PFE_CFG_IEEE1588_I_CLK_HZ PFE_CFG_IEEE1588_EMAC0_O_CLK_HZ PFE_CFG_IEEE1588_EMAC1_O_CLK_HZ PFE_CFG_IEEE1588_EMAC2_O_CLK_HZ 4. 这三个 PFE EMAC 是否共享同一个 PTP 硬件时钟，还是每个 EMAC 都有一个独立的 PTP 系统时间计数器？ 5. 此驱动程序支持哪些 PTP 传输模式？ - 二层点对点传输协议 (PTP)，以太网类型 0x88F7 - UDP/IPv4 - UDP/IPv6 一步式时间戳 - 两步时间戳 端到端延迟机制 - 点对点延迟机制 6.启用 PTP 是否需要任何额外的 PFE 固件配置、固件功能、FCI 配置或启动初始化？ 7. NXP 或 QNX 是否有推荐的用户空间 PTP 守护程序或适用于此 PFE 驱动程序的示例应用程序？当前驱动程序通过 netdrvr/ptp.h 公开 PTP 功能。并且是 SIOCGDRVSPEC/SIOCSDRVSPEC，而不是 Linux 风格的 /dev/ptpX PHC 设备。 8. 是否存在与以下方面相关的已知勘误、限制或所需的初始化顺序： - PFE 时间戳时钟初始化； - 通过 HIF 进行 TX/RX 时间戳交付； - 时间戳补偿； - 在多个 PFE EMAC 上同时进行 PTP 操作？ 如果可以的话，能否提供 QNX 系统下 S32G274A PFE 芯片上符合 IEEE 1588 标准的参考配置、示例应用或验证程序？ 感谢您的支持。 BR， 怀特旺 Re: Request for PTP/IEEE 1588 Support and Configuration Guidance for S32G274A PFE on QNX 7.1 您好，专家 感谢您提供如此详细的信息。我们已经验证了 PFE0 和 PFE2 上的 PTP 时间和补偿接口在 PFE-DRV 1.9.0 和 PFE-FW 1.12.0 下能够正常工作。 在关闭此 NXP PFE 支持案例之前，能否请您澄清以下三个与 S32G274A 相关的具体问题？ 1. 我们目前对启用的 EMAC 使用 PFE_CFG_IEEE1588_I_CLK_HZ = 200 MHz 和 50 MHz 输出时钟。这种配置是否得到官方支持和推荐？ 2. 每个 PFE EMAC 是否有独立的 IEEE 1588 定时器，还是可以将一个 EMAC 配置为与另一个 EMAC 共享时间基准？ 3.所需的 400 MHz XBAR 时钟配置在哪里？可以使用哪个寄存器或运行时指示来验证它？ Re: Request for PTP/IEEE 1588 Support and Configuration Guidance for S32G274A PFE on QNX 7.1 嗨，韦特旺 感谢您与我们联系。希望以下信息对您有所帮助！ 1.IEEE 1588 时间戳功能（AAVB-2500）首次在 BETA_0.9.0 中引入。请注意，原始记录为 [PFE_QNX_DRIVER] 添加 IEEE1588 时间戳支持。（请参阅 PFE-FW_S32G_1.12.0_ReleaseNotes.pdf。）您的软件版本符合兼容性要求。 Joey_z_1-1788772191193.pngJoey_z_1-1788772191193.pngJoey_z_1-1788772191193.png Joey_z_0-1788772167682.pngJoey_z_0-1788772167682.pngJoey_z_0-1788772167682.png 2. PFE_TS 的时钟由 GMAC_TS_CLK 提供，范围为 5-200 MHz。最小值需要根据设定的模式来确定。 Joey_z_2-1788772339124.pngJoey_z_2-1788772339124.pngJoey_z_2-1788772339124.png Joey_z_3-1788772351660.pngJoey_z_3-1788772351660.pngJoey_z_3-1788772351660.png 3. 需要根据 GMAC0_TS_CLK 的值进行设置。请参考以下内容。 Joey_z_4-1788772395380.pngJoey_z_4-1788772395380.pngJoey_z_4-1788772395380.png 4. 是的，您可以参考下图。 Joey_z_5-1788772417926.pngJoey_z_5-1788772417926.pngJoey_z_5-1788772417926.png 5. 从代码和文档信息来看，PTP 在技术上统一标识传输层，支持（UDP/IPv4、UDP/IPv6、第 2 层 PTP），支持两步和 E2E/P2P。 6. 请注意以下事项：为确保时间戳功能可靠运行，XBAR 时钟频率需设置为 400 MHz，具体请参阅 S32G 参考手册。PFE_CFG_IEEE1588_EMACn_O_CLK_HZ 的值必须小于 PFE_CFG_IEEE1588_I_CLK_HZ。在执行加载过程之前，必须确认以下事项：所有相关的时钟、电源/复位以及 PFE 引脚均已按照 S32G 参考手册进行配置，并且固件二进制文件 s32g_pfe_class.fw 已部署到目标板。 7. 我们很抱歉，恩智浦半导体没有为QNX PFE驱动程序提供现成的PTP守护程序或示例应用程序。 8. 请参阅附件中的以下内容： PFE-DRV_S32G_QNX_1.9.0_发行说明.pdf/4已知问题 PFE-DRV_S32G_QNX_1.9.0_UserManual.pdf/5.2局限性 PFE-DRV_S32G_QNX_1.9.0_UserManual.pdf/5用法 我们目前不提供专用的应用示例。建议参考以下文档中的相关信息。(PFE-DRV_S32G_A53_QNX_1.9.0\doc) BR 乔伊 Re: Request for PTP/IEEE 1588 Support and Configuration Guidance for S32G274A PFE on QNX 7.1 嗨，维特旺 感谢您的回复。 1.根据 S32G RM，建议输入时钟为 100MHz。PFE_CFG_IEEE1588_EMACn_O_CLK_HZ 值必须小于 PFE_CFG_IEEE1588_I_CLK_HZ。 Joey_z_0-1788848856306.pngJoey_z_0-1788848856306.png 2.PFE EMAC 支持两种时间戳模式，内部时间戳模式和外部时间戳模式。详细信息请参阅 PFE-DRV_S32G_QNX_1.9.0_UserManual.pdf 的第 6.4.1 章“配置和启用 IEEE1588 定时器”。 3. XBAR时钟将在 ATF 中进行配置；您可以使用 uboot 中的“clk dump”命令来检查它。 希望这些信息对您有所帮助。 BR 乔伊

i.MX8M Plus：同时运行 VIP8000 时出现间歇性帧向下偏移和绿色顶带闪烁 1. 系统和环境 参数配置 SoC NXP i.MX 8M Plus 四核处理器 芯片版本 A1 / B0 核心 6.12.20-lts-next-g604d4ef7a1e4 BSP NXP linux-imx / LTS-Next Vivante / Galcore 司机 6.4.11.p3.1049711 Galcore 位置 drivers/mxc/gpu-viv/galcore（内置） 2D引擎 Vivante GC520L (imxvideoconvert_g2d / libg2d.so) 纳米物理大学 VeriSilicon/Vivante VIP8000 NPU性能 2.3 顶级 视频编码器 Hantro VC8000E (v4l2h264enc) 内存 约 5.7 GB LPDDR4 CMA 总计 约960 MB 2. 问题描述 我们观察到，当VIP8000 NPU 推理与使用 GC520L G2D 引擎的硬件缩放/颜色转换同时运行时，会出现间歇性视频损坏问题。 受影响的 H.264 流不会完全变成绿色。相反，个别帧偶尔会出现以下情况： 当前图像似乎向下移动了少量像素/扫描线。 画面顶部出现一条水平的绿色条带。 下一帧立即恢复到正确位置。 结果是画面间歇性向下跳帧/绿色顶部边缘闪烁。 该问题在并发加速器工作负载期间可以重现，但当单独测试 NPU 或 G2D 工作负载时则无法可靠地重现。 3. 主要观察结果 3.1 仅 G2D 工作负载稳定 我们可以同时运行最多三个 G2D 视频分支： 主屏幕：1080p 字幕：360p MJPEG：480p 已禁用NPU。 视频长时间保持稳定，未观察到绿帧或帧偏移。 3.2 仅使用 NPU 的工作负载稳定 当 G2D 处理不活跃时，VIP8000 NPU 的重型推理以大约15–30 FPS 的速度持续运行，没有观察到推理错误或视频损坏。 3.3 用 CPU 处理代替 G2D 处理可以消除该问题。 当硬件 G2D 处理被以下方式取代时： videoscale ! videoconvert 即使 NPU 持续满负荷运行，系统仍保持稳定。 不再出现绿带/帧偏移问题。 3.4 并发 NPU + G2D 会触发该问题 当 NPU 处于活动状态且 G2D 同时用于视频/AI 处理时，就会出现数据损坏。 引入额外的 G2D 工作负载时，频率会增加。 这表明该问题与并发加速器活动有关，而不是与单个 NPU 或 G2D 工作负载本身有关。 4. 测试矩阵 我们进行了以下测试以找出故障原因。 测试 NPU AI 处理视频 G2D 结果 1 关 无 主 + 子 + MJPEG（3 个 G2D 分支） 通过——无闪烁 2 关 SHM附件 主字幕 + MJPEG 通过——无闪烁 3 ON 状态 G2D 功能 主要 G2D 故障——观察到间歇性绿带/帧偏移 4 ON 状态 CPU（视频缩放！视频转换） 主要 G2D 通过——主流清洁 5 ON 状态 CPU 主+子 G2D 失败——当引入额外的 G2D 工作负载时出现此问题。 6 ON 状态 CPU 所有视频分支均已转换为 CPU 缩放 通过——所有溪流均保持清洁 注意：我们目前正在准备一个较小的独立组网 \\(SA\\) 复现程序，以确定触发该问题所需的最小并发 G2D 客户端数量。 5. 当前调查 根据以上结果，我们想了解这种行为是否可能与以下某个领域有关。 A. Galcore / 加速器并发 在我们的设备树中，GPU/NPU 组件是同一个 GPU/ML 子系统的一部分： mix_gpu_ml@40000000 { compatible = "fsl,imx8mp-gpu", "fsl,imx8-gpu-ss"; cores = <&gpu_3d &ml_vipsi &gpu_2d>; reg-names = "phys_baseaddr", "contiguous_mem"; memory-region = <&gpu_reserved>; }; 中断也由 galcore 处理： 34: 520 0 0 0 GICv3 35 Level galcore:0 35: 13583 0 0 0 GICv3 45 Level galcore:3d-1 36: 1737916 0 0 0 GICv3 57 Level galcore:2d 我们想了解： galcore 是否在 GC520L、GC7000 和 VIP8000 之间共享同步原语或锁？ G2D 和 NPU 命令队列是否完全独立？ 当 VIP8000 推理处于活动状态时，多个 G2D 客户端/进程提交工作是否存在任何已知限制？ 在并发工作负载下，命令提交、上下文管理、中断处理或资源锁定是否会引入延迟？ B. 片上网络/DDR带宽或服务质量 GC520L G2D 和 VIP8000 NPU 都是主动总线主控器，可访问外部 LPDDR4 内存。 我们想确定高负载NPU推理是否可能： 大幅增加NoC/DDR流量。 增加 G2D 的内存访问延迟。 导致 G2D 交易延迟。 找出 G2D 与下游消费者之间的时序/同步问题。 受NoC/DDR QoS优先级的影响。 NXP能否就i.MX8MP上可用于调查此类工作负载的推荐NoC/AXI/DDR性能监控和QoS功能提供指导？ C. G2D 缓冲区同步/栅栏/步长问题 这种视觉瑕疵特别有趣，因为整个画面并没有损坏。 受影响的帧大致如下所示： +----------------------------------+ | GREEN HORIZONTAL BAND | +----------------------------------+ | | | | | IMAGE SHIFTED DOWN | | | | | +----------------------------------+ 这让我们不禁怀疑，这个问题是否可能涉及以下方面： G2D目标缓冲区同步。 DMA-BUF 所有权/重复使用。 围栏信号/完工。 临时 G2D 目标偏移/步长状态。 G2D内存写入延迟。 在 G2D 操作完全完成之前，下游 VPU 访问就已经发生。 具体来说，延迟的 G2D 完成或同步事件是否会导致 v4l2h264enc / VC8000E 在所有 G2D 写入完成之前消耗目标 DMA-BUF？ NXP G2D/V4L2 流水线中是否存在已记录的同步机制，以保证在 VPU 消耗目标 DMA-BUF 之前 G2D 完成？ D. 内存 / CMA 我们在重现问题时监控了内存使用情况： Total RAM : ~5.7 GB CmaTotal : ~960 MB CmaFree : ~677 MB 因此，在故障期间，CMA 并未接近耗尽。 但是，我们想了解是否还有其他与内存相关的因素会影响并发的 NPU/G2D/VPU 工作负载，例如： DMA-BUF 同步。 缓存一致性。 内存功能域映射。 物理缓冲区对齐。 缓冲区重复使用。 IOMMU/MMU映射。 保留内存交互。 6.其他诊断实验 我们目前正在准备一个最小的独立组网 (SA) 复现程序，以消除应用程序层面的复杂性。 计划中的复制器将包含： Thread 1 → VIP8000 NPU inference Thread 2 → GC520L G2D processing Thread 3 → Additional GC520L G2D processing 我们还计划测试以下配置： NPU OFF + G2D NPU ON + G2D NPU ON + 2 × G2D NPU ON + G2D → buffer inspection NPU ON + G2D → VPU encoder 这应该有助于确定损坏是发生在 G2D 输出缓冲区本身，还是仅在缓冲区被 VPU 消耗之后才发生。 7. 向恩智浦提出的问题 我们希望恩智浦能就以下方面提供指导。 1. 已知的硬件/软件限制 是否同时进行以下操作： VIP8000 NPU + GC520L G2D + VC8000E VPU i.MX8M Plus 完全支持，包括多个同时运行的 G2D 客户端？ 对于这种组合，是否存在已知的硬件限制、勘误或软件限制？ 2. Galcore VIP8000 和 GC520L 同时运行时是否存在已知的 galcore 问题？ 具体而言，是否存在以下方面的已知问题： 共享锁 命令队列， 上下文切换， 中断处理 同步， 或者资源管理？ 3. DMA缓冲区/同步 在下游 V4L2/VPU 组件消耗目标 DMA-BUF 之前，使用什么机制来保证 G2D 完成？ 在并发加速器工作负载下，imxvideoconvert_g2d / libg2d 是否存在已知的围栏或缓冲区所有权问题？ 4. 片上网络/服务质量 NXP 推荐使用哪些调试寄存器、调试文件系统节点、性能计数器或工具进行测量？ GC520L AXI 流量， VIP8000 AXI 流量， VPU流量， DDR带宽， NoC 争议， 以及服务质量/仲裁行为？ 5. 驱动程序版本 我们目前使用的是： Kernel: 6.12.20-lts-next-g604d4ef7a1e4 Galcore: 6.4.11.p3.1049711 这种组合是否是 i.MX8MP 的验证/推荐配置？ 是否有更新的 galcore / G2D 驱动程序或补丁集可以解决并发 NPU/G2D 工作负载的问题？ 6. 硅勘误表 请问我们A1/B0版本的i.MX8M Plus芯片勘误表中是否存在以下问题？ G2D， VIP8000 VPU， AXI/NoC仲裁， DDR， 缓存一致性 或者同时进行加速器操作？ 7. 推荐配置 对于需要以下条件的应用程序： VIP8000 NPU inference + multiple G2D scaling/color-conversion pipelines + VC8000E H.264 encoding NXP推荐哪种配置？ 是否有具体规定： 驱动程序参数 QoS设置， 内存/缓冲池配置， 同步机制 或 GStreamer 流水线实践 应该遵循什么？ 8. 我们可以提供的信息 如有需要，我们可以提供以下服务： 完整的 GStreamer 流水线。 设备树配置。 内核配置。 重现过程中的 dmesg 输出。 /proc/中断。 G2D/NPU 工作负载详情。 v4l2-ctl 信息。 最小 NPU + G2D 复现器。 包含损坏帧的视频样本。 驱动程序版本和内部版本信息。 我们非常感谢您提供任何关于推荐的调试程序或附加跟踪/寄存器的指导，以帮助确定根本原因是否与G2D/NPU 同步、DMA-BUF/fence 处理、NoC/DDR 竞争、galcore 或芯片限制有关。 谢谢！ 毗湿奴 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano

HSE: MUインストール後の最初の2回のリセット後にエラーコード0x67030001が発生しました 私はFirmware Reference Manual version 2.7の3.2.3.1節に記載されている通り、FULL_MEMモードでMUインターフェース経由でインストールする手順に従っています。 インストールは説明どおりに正常に動作しますが、機能リセット（手順7）を実行すると、HSEエラーコード0x67030001が表示されます。これは2回目のリセット後も続くが、3回目のリセット後には確実に解消される。 いくつか質問があります。 最上位ビットの値（0x6703）は意味を持つのでしょうか？ HSEドライバーが起動時にエラー状態に入り、正確に2回リセットすると回復する原因は何でしょうか? そもそも、このエラーが発生した最も可能性の高い原因は何でしょうか？ Re: HSE: Error code 0x67030001 after first two resets following MU install こんにちは、 @Emma_G-gbgさん HSE_Bファームウェア リファレンス・マニュアルに記載されているように、GSRレジスタは致命的および警告イベントを16ビットの最下位ビットでログ付けします。 ビット0～7は致命的なエラーを示します。 ビット8～15は警告（致命的ではない障害）を示します。 上位16ビットはNXPの内部エラー用に予約されています。 お使いのデバイスでビット0が設定されている場合、致命的なエラーが発生し、HSEがシャットダウンしたことを示しています。この状態では、シャットダウンモードから復旧して終了するには、デバイスのリセットが必要です。 FSRレジスタとHSE_CONFIG_GPR3(0x4039C028)の値を教えていただけますか?また、リセットを実行した後、GPR3のHSE_STATUS_INIT_OKフラグが設定されるまで待ちましたか？ さらに、 スレッドのS32K3でMU経由でHSEファームウェアをインストールする際の回復問題で、MU経由でHSEファームウェアをインストールするデモも共有されました。参考資料として役立つかもしれません。 BR、VaneB Re: HSE: Error code 0x67030001 after first two resets following MU install 最初の2回のリセット後、値は以下のとおりでした。 HSE_CONFIG_GPR3: 0x10000081 DCMRWP1: 0xA5000400 GSR: 0x67030001 FSR: 0x00400000 そして3回目のリセット後の値は次の通りでした。 HSE_CONFIG_GPR3: 0x000000C1 DCMRWP1: 0xA5000400 GSR: 0x00000000 FSR: 0x09600000   Re: HSE: Error code 0x67030001 after first two resets following MU install こんにちは、 @Emma_G-gbgさん リセット1と2：FSR = 0x00400000。ビット24（HSE_STATUS_INIT_OK）が設定されていないということは、HSEの初期化がまだ完了していないことを示しています。GSR値0x67030001は、ビット0（HSE_ERR_GENERAL）が設定されていることを示しており、これによりHSEサブシステムのシャットダウンがトリガーされました。 リセット 3: FSR = 0x09600000。ビット24（HSE_STATUS_INIT_OK）が設定され、HSEの初期化が正常に完了したことを示します。GSR値0x00000000は、HSEエラー/警告が報告されなかったことを示しています。 この挙動の原因としては、アプリケーションがHSE初期化が完全に完了する前にクロック初期化、XRDC設定、またはフラッシュ操作を行っている可能性があります。 Re: HSE: Error code 0x67030001 after first two resets following MU install こんにちは、 @Emma_G-gbgさん XRDCについては、HSE_BファームウェアリファレンスマニュアルRev. 2.7のセクション14.6.3の注を参照してください。 クロックの初期化については、同文書のセクション2.4.2.3.3に記載されています。 Re: HSE: Error code 0x67030001 after first two resets following MU install ありがとうございます。現在、フラッシュ同期について調べています。 クロックやXRDC initがHSEの立ち上げに影響を与えるとは知りませんでしたが、これはどこで説明されていますか?

没有规则可以设定目标 我尝试在 imx8mp 处理器上构建 Yocto 镜像。文件位于指定位置，我已经验证过，并且在 imx8mp_evk_defconfig 文件中也提到了这一点。 | make[3]: *** 没有规则可以创建目标“arch/arm64/boot/dts/freescale/imx8mp-evk-delta.dtb”。停止。 Re: No rule to make target 请参考以下步骤重新构建Linux内核。 1.请在 sources/meta-freescale/conf/machine/imx8mp-lpddr4-evk.conf 文件中，将“freescale/imx8mp-evk-delta.dtb”添加到变量 KERNEL_DEVICETREE:append:use-nxp-bsp 中。 2. 请获取 Linux 内核源代码。 $ bitbake virtual/kernel -c cleansstate $ bitbake virtual/kernel -c patch 3. 请前往 Linux 内核源代码文件夹 tmp/work/imx8mp_lpddr4_evk-poky-linux/linux-imx/6.6.52+git/git，添加 dts 文件 arch/arm64/boot/dts/freescale/imx8mp-evk-delta.dts 4. 重建 Linux 内核。 $ bitbake virtual/kernel Re: No rule to make target 但它仍然在 bitbake 虚拟/内核之后。 Re: No rule to make target 适用于 Linux 内核： 请在 sources/meta-freescale/conf/machine/imx8mp-lpddr4-evk.conf 文件中的 KERNEL_DEVICETREE:append:use-nxp-bsp 变量中添加“freescale/imx8mp-evk-delta.dtb”。 然后运行“bitbake virtual/kernel”。 对于 u-boot： 请参考以下步骤在 u-boot 中添加和使用新的 dts 文件。 $ bitbake u-boot-imx -c cleansstate $ bitbake u-boot-imx -c patch 进入 u-boot 源代码文件夹 tmp/work/imx8mp_lpddr4_evk-poky-linux/u-boot-imx/2024.04/git，请将 dts 文件 imx8mp-evk-delta.dts 添加到 arch/arm/dts/ 文件夹中。 请按如下方式修改configurations/imx8mp_evk_defconfig。 CONFIG_DEFAULT_DEVICE_TREE="imx8mp-evk" 修改为： CONFIG_DEFAULT_DEVICE_TREE="imx8mp-evk-delta" 然后重新构建 u-boot： $ bitbake u-boot-imx

No rule to make target I was trying to build an yocto image on an imx8mp processor.The file was in the spectified locations,i have verified and also mentioned it in the imx8mp_evk_defconfig file as well. | make[3]: *** No rule to make target 'arch/arm64/boot/dts/freescale/imx8mp-evk-delta.dtb'. Stop. Re: No rule to make target Please refer to the following procedure to rebuild Linux Kernel. 1. Please add "freescale/imx8mp-evk-delta.dtb \" in variable KERNEL_DEVICETREE:append:use-nxp-bsp in file sources/meta-freescale/conf/machine/imx8mp-lpddr4-evk.conf 2. Please fetch Linux Kernel source code. $ bitbake virtual/kernel -c cleansstate $ bitbake virtual/kernel -c patch 3. Please go to Linux Kernel source code folder tmp/work/imx8mp_lpddr4_evk-poky-linux/linux-imx/6.6.52+git/git to add dts file arch/arm64/boot/dts/freescale/imx8mp-evk-delta.dts 4. Rebuild Linux Kernel. $ bitbake virtual/kernel Re: No rule to make target still it comes after bitbake virtual/kernel Re: No rule to make target For Linux Kernel: Please add "freescale/imx8mp-evk-delta.dtb \" in variable KERNEL_DEVICETREE:append:use-nxp-bsp in file sources/meta-freescale/conf/machine/imx8mp-lpddr4-evk.conf Then run "bitbake virtual/kernel". For u-boot: Please refer to the following procedure to add and use new dts file in u-boot. $ bitbake u-boot-imx -c cleansstate $ bitbake u-boot-imx -c patch Go to u-boot source code folder tmp/work/imx8mp_lpddr4_evk-poky-linux/u-boot-imx/2024.04/git, please add dts file imx8mp-evk-delta.dts in folder arch/arm/dts/. Please modify configs/imx8mp_evk_defconfig as the following. CONFIG_DEFAULT_DEVICE_TREE="imx8mp-evk" Modify to: CONFIG_DEFAULT_DEVICE_TREE="imx8mp-evk-delta" Then rebuild u-boot: $ bitbake u-boot-imx

HSE：MU 安装后前两次重置后出现错误代码 0x67030001 我已按照固件参考手册 2.7 版 3.2.3.1 节中所述的通过 MU 接口在 FULL_MEM 模式下进行安装的安装程序进行操作。 安装过程完全按照说明进行，但是当我执行功能 RESET（步骤 7）时，出现 HSE 错误代码 0x67030001。第二次重置后问题仍然存在，但第三次重置后就会稳定消失。 我有几个问题： 最高位（0x6703）的特定值是否有意义？ 什么原因会导致 HSE 驱动程序在启动时进入错误状态，但在两次 RESET 后恢复？ 导致该错误的最可能原因是什么？ Re: HSE: Error code 0x67030001 after first two resets following MU install 嗨@Emma_G-gbg 如 HSE_B 固件参考手册中所述，GSR 寄存器在其最低 16 位中记录致命事件和警告事件： 第 0-7 位表示致命错误。 第 8-15 位表示警告（非致命故障）。 最高 16 个有效位用于 NXP 内部错误。 由于您的设备上第 0 位已设置，这表明发生了致命错误，导致 HSE 关闭。在此状态下，需要重置设备才能恢复并退出关机模式。 请问能否提供 FSR 寄存器和 HSE_CONFIG_GPR3 (0x4039C028) 的值？另外，在执行重置后，您是否等到 GPR3 中的 HSE_STATUS_INIT_OK 标志被设置？ 此外，在“通过 MU 安装 HSE 固件时出现 S32K3 恢复问题”主题中，分享了一个通过 MU 安装 HSE 固件的演示。它或许可以作为有用的参考资料。 BR，VaneB Re: HSE: Error code 0x67030001 after first two resets following MU install 嗨@Emma_G-gbg 重置 1 和 2：FSR = 0x00400000。第 24 位（HSE_STATUS_INIT_OK）未设置，这表明 HSE 尚未完成初始化。GSR 值 0x67030001 表示位 0 (HSE_ERR_GENERAL) 已设置，这触发了 HSE 子系统关闭。 RESET 3：FSR = 0x09600000。位 24 (HSE_STATUS_INIT_OK) 已设置，表明 HSE 已成功完成初始化。GSR 值 0x00000000 表示未报告任何 HSE 错误/警告。 造成这种行为的一个可能原因是应用程序在 HSE 初始化完全完成之前执行时钟初始化、XRDC 配置或 Flash 操作。 Re: HSE: Error code 0x67030001 after first two resets following MU install 前两次重置后的值如下： HSE_CONFIG_GPR3: 0x10000081 DCMRWP1: 0xA5000400 GSR: 0x67030001 FSR: 0x00400000 第三次 RESET 后的值为： HSE_CONFIG_GPR3: 0x000000C1 DCMRWP1: 0xA5000400 GSR: 0x00000000 FSR: 0x09600000   Re: HSE: Error code 0x67030001 after first two resets following MU install 谢谢，我正在研究闪存同步问题。 我之前并不知道时钟或 XRDC 初始化会影响 HSE 启动，请问哪里有相关说明？ Re: HSE: Error code 0x67030001 after first two resets following MU install 嗨@Emma_G-gbg 关于 XRDC，请参阅 HSE_B 固件参考手册第 2.7 版第 14.6.3 节中的注释。 有关时钟初始化的相关信息，请参阅同一文档的第 2.4.2.3.3 节。

For hardware simulation need system verilog or vams or spice model of PCA9698DGG,512(GPIO expander) Need system verilog or vams or spice model of the IO expander part number- PCA9698DGG,512. Please provide urgently as it is required for a critical work. Datasheet link- PCA9698 40-bit Fm+ I2C-bus advanced I/O port with RESET, OE and INT

硬件仿真需要PCA9698DGG,512（GPIO扩展器）的SystemVerilog、VAMS或SPICE模型。 需要 I/O 扩展器部件号 PCA9698DGG,512 的系统 Verilog、VAMS 或 Spice 模型。请尽快提供，这是关键工作所需。 数据手册链接- PCA9698 40 位 FM+ I2C 总线高级 I/O 端口，带 RESET、OE 和 INT 功能