EZH-V use case for IMXRT700 Hi team NXP! From the spec of IMXRT700 it was said to be architected in the 3 domain of media, compute and sense domain, which each of the cores on chip would require their own separate image to run. But it seems that there are only very few documented usage of the EZH-V core. I have read the application notes AN14614, AN14618 and AN14654, but there are still very few information regarding this core and it roles in graphical processing for RT700. It was said that it is used to implement the smartDMA engine, but in other MCX family MCU there are no mentioning of the existence of this core and the smartDMA can be directly used by the Arm CM33 core via the mcuxpresso sdk provided APIs. So now I am extremely confused, can I still directly use the smartDMA on iMXRT700 directly or must I build the image for the EZH-V via LLVM as per AN14614 instruction? This seems quite counterintuitive though having to resort to RPMsg for IPC communication as supposed to be directly driven by the Cpu0. On top of this, I am not aware of any actual demo or use case that has been provided by NXP that explicitly utilized this EZH-V core. I have also review the some of the source headers available, and only some very intuitive basic operations have been provided. May I know what is the usage of the EZH-V? Re: EZH-V use case for IMXRT700 okay quick update, after taking a look of the smartDMA driver in the mainline Zephyr now I understand the situation. The smartDMA has always been/planned as a standalone subsystem with its own core that could have the potential to run firmware on its own, but never have been actually presented as a fully standalone RISC-V core. In the current existing example, the smartDMA has never really touched the custom firmware installation path and only used as a slightly special DMA IP. So now the question should pivot to if I could still use the smartDMA in the old fashion; directly invoked via the CM33 instead of doing the complex IPC setup, as of time of writing, the smartDMA IP is yet to be exposed as a supported IP of the official maintained mimxrt700_evk. Re: EZH-V use case for IMXRT700 Hi @mayliu1 , Thanks for the quick reply, so you mean the smartDMA is no longer coupled to the CM33 core and therefore must be used via the EZH-V core? In NXP's other MCU family like MCX the smartDMA is coupled to the CM33 and can be directly invoked via APIs, there are application notes documenting such use cases AN14172, AN14916, and they do not involve building the standalone image for the RISC-V core.  So what is the current architecture on the i.MXRT700? All documents about EZH-V are very ambiguous and I am not aware of any existing demo or guides that have thoroughly covered the usage of EZH-V.  Has NXP revised the architecture of smartDMA so it is no longer part of the core CM33 system and grouped to the RISC-V companion core instead? Can I still invoke the smartDMA directly via the CM33? Re: EZH-V use case for IMXRT700 Hi @TomC818 ， Thank you so much for your interest in our products and for using our community. According to AN14614 and the i.MX RT700 Reference Manual, my understanding is that the SmartDMA functionality on the i.MX RT700 is implemented through the EZH-V RISC-V core rather than as a conventional DMA peripheral such as eDMA. In general, eDMA is still the preferred solution for standard memory transfer operations and can be configured directly by the CM33 core. However, SmartDMA-related processing, such as certain graphics/data post-processing or data format conversion tasks, is typically implemented by firmware running on the EZH-V core. Based on AN14614, CPU0 is responsible for loading and booting the EZH-V firmware, after which the actual processing is performed by EZH-V. From this perspective, EZH-V behaves more like a programmable coprocessor than a traditional DMA engine. Therefore, SmartDMA on RT700 is better viewed as a programmable processing engine running on the EZH-V core, rather than a traditional DMA peripheral directly driven by CM33 alone. Wish it helps you Best Regards May Re: EZH-V use case for IMXRT700 hey umm... if NXP didn't actually prepare or have any planned support for "With the assistance of the EZH-V, the Cortex-M33 cores can be freed to perform other tasks. While the EZH-V is executing the assigned task, the CM33 cores can execute other tasks in parallel." as per the reference manual described, I think I will be pursuiting a different option from ST or Infineon, considering the fact that RT700 documentations and examples are still extremely unpolished and all over the place. Support for most of the marketted unqiue features of this MCU are very sparse and few between. With such a the complex heterogeneous architecture, such little examples and guides are just abyssal. Re: EZH-V use case for IMXRT700 On i.MX RT700, SmartDMA is not exposed in the same way as a conventional standalone DMA peripheral directly controlled by the CM33. The SmartDMA-style capability is provided through the EZH-V engine, so the typical usage model is for the CM33 to load and start the EZH-V firmware, then coordinate with it as needed.

S32K358 eMIOS ISR stuck at 85°C Dear NXP Support Team, we are facing an issue on S32K358 during temperature tests at around 85°C.   In our application we use 6 eMIOS channels, each one configured to generate interrupts on both PWM edges with a frequency of 200Hz.   At 85°C, the MCU sometimes gets stuck inside one eMIOS ISR. The ISR does not exit because the code checks the interrupt flag by reading the eMIOS registers, but the flag is 0 (file Emios_Mcl_Ip_Irq.c 😞   if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))    After debugging, we noticed that when the issue occurs, the variable containing the eMIOS base address is NULL (Emios_Ip_paxBase). When the application works correctly, the same pointer is valid and the eMIOS registers are read properly. It seems that, in some conditions, the reference to the eMIOS peripheral is corrupted or cleared during ISR execution.   Do you have any indication about possible known issues or root causes, such as stack overflow, memory corruption, concurrent accesses, ISR handling, or temperature-related behavior?   Best regards, Simon Re: S32K358 eMIOS ISR stuck at 85°C Hi vane, I'm currently using RTD 7.0.0 Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Which RTD version are you working with? Any additional information would be helpful. Also, in RTD versions prior to 6.0.0, there was a known issue related to the incorrect memory mapping of static variables within function scope (ARTD-159985). This issue describes a problem where the variable Emios_Ip_paxBase, defined in both Emios_Mcl_Ip.c and Emios_Mcl_Ip_Irq.c, is assigned inconsistent initialization characteristics. Further details are provided in the Software Release Notes. BR, VaneB Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Could you please provide a simple application that reproduces the observed behavior? Also, could you confirm whether you are working with a custom board or an evaluation board? Additionally, could you share how the testing is being performed to confirm that the issue occurs at 85 °C? Re: S32K358 eMIOS ISR stuck at 85°C Hi @VaneB , Currently i'm working with a custom board with S32K358 where i use these eMIOS_1 channels to generate PWM of 200 Hz: ch3, ch9,  ch11, ch12, ch13, ch19. Code is generated using SImulink  Putting my custom board into a climatic cell at 85°C i've observed the stucking behaviour after some time. While i was debugging with S32DS (3.6.7) I've found out that it stuck into the ISR(EMIOS1_1_IRQ) so i've put into it some custom counter near entry/exit function, and also into Emios_Pwm_IrqHandler and Emios_Pwm_Ip_IrqHandler functions, in order to detect what parts of the code are executed.  After some tests i've found out that, when it stucks, inside static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) {     /* Check that an event occurred on Emios channel */     if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))     {         /* Check that an event occurred on EMIOS channel */         if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))))         {             Emios_Pwm_Ip_IrqHandler(Instance, Channel);         }         else         {             /* Do nothing - in case of spurious interrupts, return immediately */         }     } }   the if condition: if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))   is always 0 because, for some reason, Emios_Ip_paxBase[Instance] points to 0. This means that nobody is clearing the interrupt flag so it enters in a loop where it cannot escape.   here's the code i've used to detect this probelm: static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) {     // uint32_t s;     // uint32_t c;     // uint32_t s_flag;     // uint32_t s_ovr;     dbg_pwm_last_instance = Instance;     dbg_pwm_last_channel = Channel;     dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance];     dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C;     dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S;         dbg_emiosipirq_static_state1++;     /* if (Instance == 1)     {         switch (Channel)         {             case 16:                 dbg_emiosipirq_static_cnt_ch16++;                 break;             case 17:                 dbg_emiosipirq_static_cnt_ch17++;                 break;             case 18:                 dbg_emiosipirq_static_cnt_ch18++;                 break;             case 19:                 dbg_emiosipirq_static_cnt_ch19++;                 break;             default:                 dbg_emiosipirq_static_cnt_oth1++;                 break;         }     }     else     {         dbg_emiosipirq_static_cnt_oth2++;     } */     /* Lettura reale dei registri vista dal codice */    /*  s = Emios_Ip_paxBase[Instance]->CH.UC[Channel].S;     c = Emios_Ip_paxBase[Instance]->CH.UC[Channel].C;     s_flag = s & (uint32)eMIOS_S_FLAG_MASK;     s_ovr  = s & (uint32)eMIOS_S_OVR_MASK;     dbg_pwm_last_s = s;     dbg_pwm_last_c = c;     dbg_pwm_flag_mask = (uint32)eMIOS_S_FLAG_MASK;     dbg_pwm_ovr_mask = (uint32)eMIOS_S_OVR_MASK;     dbg_pwm_last_s_and_flag = s_flag;     dbg_pwm_last_s_and_ovr = s_ovr;     if (s_flag != 0U)     {         dbg_pwm_s_flag_yes++;     }     else     {         dbg_pwm_s_flag_no++;     }     if (s_ovr != 0U)     {         dbg_pwm_s_ovr_yes++;     }     else     {         dbg_pwm_s_ovr_no++;     }     if ((s_flag == 0U) && (s_ovr != 0U))     {         dbg_pwm_flag0_ovr1_count++;     }     else if ((s_flag != 0U) && (s_ovr != 0U))     {         dbg_pwm_flag1_ovr1_count++;     }     else if ((s_flag != 0U) && (s_ovr == 0U))     {         dbg_pwm_flag1_ovr0_count++;     }     else     {         dbg_pwm_flag0_ovr0_count++;     } */     /* Check that an event occurred on EMIOS channel */     if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))     {         dbg_emiosipirq_static_state2++;         /* Check that an event occurred on EMIOS channel */         if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))))         {             dbg_emiosipirq_static_state3++;             Emios_Pwm_Ip_IrqHandler(Instance, Channel);         }         else         {             dbg_emiosipirq_static_state4++;             /* Do nothing - in case of spurious interrupts, return immediately */         }     }     else     {         dbg_emiosipirq_static_state5++;         //Emios_Pwm_Ip_IrqHandler(Instance, Channel);         //Emios_Pwm_Ip_IrqHandler(1, 19);     } } These are the global vars in which i've stored the addresses which Emios_Ip_paxBase should point to: dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; I've put also some custom code to read NVIC registers run time: attached you can find the file with Thread, general registers, NVIC registers and variables expressions, EMIOS registers, for 6 tests i made. Also i will provide you the S32DS project i used to test this behaviour in a private message. I hope all these information could be usefull. I remain at your disposal for any further information. BR, SImon Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Thank you very much for providing this information. Since the code appears to be getting stuck in EMIOS1_1_IRQ, which corresponds to eMIOS 1 Channel 19 based on your configuration, let’s try to narrow the analysis to this specific part. To simplify the debugging and rule out any interference from other modules, please create a minimal test project that only includes this eMIOS configuration. This will help us isolate the behavior and better understand the root cause. For guidance, you can review the examples provided in the thread S32M27x/S32K3 – eMIOS Usage. Does the same behavior still occur? Also, if you have an evaluation board, it would be great if you could try the same code there. Re: S32K358 eMIOS ISR stuck at 85°C Hi vane, I'll try this week to give you a simple project that replicate the behaviour Re: S32K358 eMIOS ISR stuck at 85°C Hi @VaneB , I tested the issue on my custom board using a simplified configuration that only includes the six eMIOS1 channels. Unfortunately, in this setup I am not able to reproduce the error. The application runs correctly and does not get stuck in EMIOS_1_IRQ. At the moment, I am looking into whether it is feasible to load the complete project developed for our custom board onto the EVB. Before proceeding, I would also like to understand if the hardware differences between the custom board and the EVB could potentially lead to any unexpected behavior or even damage to the EVB. BR, Simon Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Our evaluation boards are designed mainly for use at room temperature and have not been tested or qualified for very low or very high temperatures. You may still use the evaluation boards outside the room-temperature range, but we cannot guarantee their performance under those conditions. Re: S32K358 eMIOS ISR stuck at 85°C Hi @VaneB , After several attempts, I managed to create an EVB project that reproduces the application running on my custom board as closely as possible. In particular, I configured all the pins in the same way as in my custom project. I then tested this project on my custom board under 85°C conditions, and the eMIOS ISR issue still occurred: the application continued to get stuck. After that, I tested exactly the same project on the EVB under the same temperature conditions and over (90°C), but I was not able to reproduce the issue—the EVB continued to operate correctly without getting stuck. At this point, what would you recommend as the next steps to identify the root cause of the problem and find a possible solution? Please let me know if you need any additional information, measurements, or debugging data from my side. I have attached a ZIP file containing the complete EVB project and the pictures of the K358 on my custom board and on the EVB. Thank you for your support. BR Simone Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  As the issue is observed on your custom board but not on the EVB, it would be worthwhile to investigate whether the root cause could be hardware-related. I recommend comparing your hardware design against the EVB schematic and reviewing the S32K3 Hardware Design Guideline to verify that all relevant recommendations have been properly implemented. Re: S32K358 eMIOS ISR stuck at 85°C Hi @VaneB,   the HW design has been reviewed on our side and no evident hardware issue has been found. Also, the board is not directly comparable with the NXP EVB due to different hardware design and operating conditions.   If a customer observes temperature-related issues on a custom board, how could it be possible to obtain one-to-one support from NXP?   BR, Simon Re: S32K358 eMIOS ISR stuck at 85°C Hi @VaneB  I would like to gently follow up on this topic, as we are still investigating the issue on our side and would appreciate your feedback. In particular, if the root cause were related to RAM corruption (for example, an out-of-bounds write or stack overwrite), which registers or diagnostic information would you recommend checking on the S32K358? Are there any specific fault status registers, ECC/error reporting registers, MPU-related registers, stack monitoring features, or other debug registers that could help identify whether memory corruption has occurred before the eMIOS ISR gets stuck? Any guidance on the most useful registers to inspect during debugging would be greatly appreciated. Thank you for your support. Best regards, Simon Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Since this appears to be a hardware-related issue specific to your board and we can not reproduce it, it is difficult to accurately diagnose the root cause through this support channel. We recommend contacting your distributor or local NXP representative for further assistance,

CGM-RD (UM12423) — NHS2634 never asserts INTERRUPT pin, NHS2x34_Init() hangs forever NHS2x34_Init() hangs indefinitely waiting for the NHS2634's interrupt pin to go high. I'd like help determining whether this points to a hardware issue, a power-sequencing issue, or a firmware configuration problem. Sequence of events: 1. NHS2634_HOSTIF_InitSpiAndInterrupt() runs and returns success. 2. NHS2x34_PMC_ResetAFE() is called. This issues an SPI write to the PMC control register (setting the AFE reset bit). It returns success (status = 0). 3. The code then waits in the following loop, expecting the chip to assert its interrupt pin high once it is ready to accept further SPI commands. This loop never exits. while (!NHS2634_HOSTIF_GetInterruptPinLevel()) { } Diagnostics already run: 1. Confirmed via SEGGER RTT logging that the loop is genuinely spinning (a live poll counter increments continuously into the tens of millions), not frozen or crashed. The CPU is alive and actively re-checking the pin. 2. Attached a debugger (J-Link/GDB) and halted mid-loop twice. The program counter was inside NHS2634_HOSTIF_GetInterruptPinLevel() calling GPIO_PinRead() both times, consistent with active polling. 3. Read back the PMC control register immediately after writing it. Expected a non-zero pattern reflecting the reset bit plus the write-protection byte just sent, but got back 0x00000000. 4. Ran a raw SPI loopback test (shorting MOSI to MISO directly on the sensor connector, with the NHS2634 module fully disconnected). Still got 0x00000000 back on a distinctive test pattern, instead of an echo of the transmitted bytes. 5. Repeated all of the above with the NHS2634 module completely unplugged. Results were identical to when it is connected. What I am trying to determine: I am using the official NXP-provided SDK and have not modified the driver code. I need to determine whether this is a hardware issue, a power-sequencing issue, or a firmware configuration issue on my side, and whether this looks like a hardware fault specific to my unit. Any guidance on where to look next would be appreciated. MCU-LINK-PRO,  MCUXPRESSO-VSC,  BLOOD-GLUCOSE-MONITOR  @nxp, @nxp5  Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) MCXA MCXC MCXN Package and IO|GPIO Power Re: CGM-RD (UM12423) — NHS2634 never asserts INTERRUPT pin, NHS2x34_Init() hangs forever Since the SPI loopback failed to read 0x00, your host microcontroller's SPI peripheral/gpio routing is not actually transferring any data. Fix your host pin muxing, clocking, and GPIO initialization

Does the S32K344's hardware QSPI support (Continuous Clock) configuration? As the title suggests, I want to continuously output a clock so that my downstream devices can process data based on this clock. Re: S32K344的硬件QSPI，是否支持（连续时钟/ Continuous SCK）的配置？ Hello @Zhangbohan, Unfortunately, S32K3 SPI module does not support continuous SCK. One option is to use the "Continuous Transfer": "In Master mode, CONT keeps the PCS asserted at the end of the frame size, until a command word is received that starts a new frame." Another option is using a GPIO to act as CS and controlled by software. In either way, the SPI SCK is generated when pushing data into the SPI TX buffer. If you use standard driver (MCAL or RTD), then the SCK pulse will be control by driver through pushing data to FIFO. The user can't control it. As far as I know, only S32K9-K7-K6 devices' DSPI module support continuous SCK mode. From S32K39 Reference Manual: Best regards, Julián Re: S32K344的硬件QSPI，是否支持（连续时钟/ Continuous SCK）的配置？ Thank you very much for your reply. I have re-evaluated my solution and have another question. Does the S32K344 support DMA transfer via QSPI? I see relevant registers at the register level; however, there are no enable or channel configuration options in QSPI_IP; it seems configurable at the MCAL layer. This makes me unsure whether QSPI+DMA is supported, and if there are any relevant examples. The existing example "Mem_43_EXFLS" doesn't seem to use DMA. Re: S32K344的硬件QSPI，是否支持（连续时钟/ Continuous SCK）的配置？ Hello @Zhangbohan, Yes, QSPI instance does support DMA usage, you can refer to chapter 78.5.4.1 from the S32K3XX Reference Manual for considerations.  However, I am not aware of any QSPI_IP + DMA examples. Best regards, Julián 

S32DS ARM 2018 R1 许可证延期申请 你好我的许可证已经过期，因此我想申请延期。

LS1046A 10GB SFP+ Configuration on kernel 6.12 Hello,  I have a custom board with the LS1046A, and I'm trying to use fm1-mac9 with a soldered SFP+ 10GB module.  My RCW in SERDES 1 is 0x1040:  So 10GB in fm1-mac9 is well covered from the RCW's perspective. Looking at the SFP power and laser everything seems healthy, but I can't seem to get it to talk/link with the sfp in front of it, so I suspect my DTB configuration is incorrect.  This is my current configuration for that MAC:  xfi10g: ethernet@f0000 {   status = "okay";   pcsphy-handle = <&pcsphy6>;   pcs-handle = <&pcsphy6>;   pcs-handle-names = "xfi";   phy-connection-type = "10gbase-r";   fixed-link {     speed = <10000>;     full-duplex;   }; }; mdio@f1000 {   status = "okay";   pcsphy6: ethernet-phy@0{     compatible = "fsl,lynx-pcs";     reg = <0x0>;   }; }; sfp_mac9: sfp {   compatible = "sff,sfp";   i2c-bus = <&i2c3>;   status = "okay"; }; For reference, I'm running linux-qoriq kernel 6.12, and the SFP probes correctly during boot reading its EEPROM. Do you have a proper example of running this type of connection in fm1-mac9?  Re: LS1046A 10GB SFP+ Configuration on kernel 6.12 How about changing per LS1046ARDB， as fm1-mac10 is SFP+, and the driver support the SFP+, too. https://github.com/nxp-qoriq/linux/blob/lf-6.12.49-2.2.0/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts#L156

LPC5514JBD64E Use for WS2812. Hi, Is LPC5514JBD64E suitable for working with WS2812 for a beginner. If yes Where Can I get The Code and other Details.  Thank you. LPC55xx Re: LPC5514JBD64E Use for WS2812. hi @Kishore02  Thank you for your post! There is not information about the implementation of WS2812 for the LPC551x, you could use the Programmable Logic Unit to do it, in another devices there are example using the FlexIO modules like in application code hub for the MCXA366: https://mcuxpresso.nxp.com/appcodehub?search=an-emulating-ws2812-bus-with-flexio-on-mcx366  Also, there is a post of a colleague that implement it for a Kinetis board: NXP FlexIO Generator for the WS2812B LED Stripe Protocol Hope this information help as a reference 

i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Hi, These are my yocto build parameters: Release: imx-linux-walnascar BSP Version: imx-6.12.49-2.2.0 MACHINE: imx8mpevk DISTRO: fsl-imx-xwayland I have been using this build environment successfully for the past couple of months. However, I suddenly started encountering the attached error. To troubleshoot, I completely cleaned the build environment, reinitialized the repository (repo init), synced everything again, and performed a fresh build. Unfortunately, I am still facing the same issue. Please find the attached log file for your reference. I would appreciate your help in identifying the root cause and suggesting a solution. i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) bitbake imx-image-core Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) What "bitbake command" are you using? I will do verification. Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Thank you for your response. I verified my build environment, and it already matches the configuration you recommended. Host OS: Ubuntu 22.04.5 LTS (Jammy) GNU tar version: GNU tar 1.34 $ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.5 LTS" ... $ tar --version tar (GNU tar) 1.34 However, I still encounter the same failure Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Please check the tar version, if the host is Ubuntu 24.04 and tar is 1.35 Build inside a container or VM with: Ubuntu 22.04 LTS GNU tar 1.34 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Please find file below,  Here i am pasting the some lines of error  DEBUG: Executing python function extend_recipe_sysroot NOTE: Direct dependencies are ['/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/gcc/gcc-cross_14.3.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.68.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-core/coreutils/coreutils_9.6.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/flex/flex_2.6.4.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/rpm/rpm_4.20.0.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-extended/bc/bc_1.08.1.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kmod/kmod_34.1.bb:do_populate_sysroot'] NOTE: Installed into sysroot: [] NOTE: Skipping as already exists in sysroot: ['gettext-minimal-native', 'binutils-cross-aarch64', 'cmake-native', 'gcc-cross-aarch64', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'kern-tools-native', 'linux-libc-headers', 'file-native', 'openssl-native', 'coreutils-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'zlib-native', 'bison-native', 'dwarfsrcfiles-native', 'elfutils-native', 'flex-native', 'git-native', 'gnu-config-native', 'json-c-native', 'libedit-native', 'lua-native', 'make-native', 'patch-native', 'perl-native', 'pkgconfig-native', 'pseudo-native', 'python3-native', 'rpm-native', 'bc-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'lzlib-native', 'xz-native', 'zstd-native', 'kmod-native', 'acl-native', 'attr-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libmpc-native', 'libunistring-native', 'mpfr-native', 'nettle-native', 'p11-kit-native', 'popt-native', 'sqlite3-native'] DEBUG: Python function extend_recipe_sysroot finished DEBUG: Executing python function sstate_task_prefunc DEBUG: Python function sstate_task_prefunc finished DEBUG: Executing python function do_package DEBUG: Executing python function package_setup_pkgv DEBUG: Python function package_setup_pkgv finished DEBUG: Executing python function package_convert_pr_autoinc DEBUG: Python function package_convert_pr_autoinc finished DEBUG: Executing python function package_prepare_pkgdata NOTE: Installed into pkgdata-sysroot: [] DEBUG: Python function package_prepare_pkgdata finished DEBUG: Executing python function perform_packagecopy ERROR: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/vvdn/LWT_Build/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.10/subprocess.py', lineno: 421, function: check_output 0417: else: 0418: empty = b'' 0419: kwargs['input'] = empty 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): File: '/usr/lib/python3.10/subprocess.py', lineno: 526, function: run 0522: # We don't call process.wait() as .__exit__ does that for us. 0523: raise 0524: retcode = process.poll() 0525: if check and retcode: *** 0526: raise CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/linux-imx/6.12.34+git/image -p -S . | tar -xf - -C /home/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/linux-imx/6.12.34+git/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address tar: ./usr/lib/modules: Cannot mkdir: No such file or directory Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) It seems that I don't have the permission to download the attachment. Would you please resend it again? Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Hi @yipingwang  Awaiting for your prompt support in further debugging. Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) On your ubuntu PC, use the command "sudo apt install tar=1.34+dfsg-1build3" Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) @Sanjiv_MnsDid this resolve the issue ? Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Hi @abannish  Please try below commands this works for me... wget http://archive.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1build3_amd64.deb sudo dpkg -i tar_1.34+dfsg-1build3_amd64.deb  sudo apt-mark hold tar

Flash configuration confusion RT1176 Octal DDR Hello NXP I got some issues configuring the flash memory for Macronix Octal DDR mode. I am using the PX4 code stack on a custom board based on the NXP FMU-6XRT reference design. I am using the MX25UM51245G instead of the MX25UM51345G, but the part differences are minimal. I am trying to run it in Macronix Octal DDR mode with DQS external sampling at atleast 100MHz. Reference design is running it at 200MHz. The Boot Memory Configuration succesfully tests the memory with the desired configuration even at 166MHz. The configuration I have tried is the following default config. The first one, "g_flash_config" succesfully boots, writes, read, etc, but is not ideal for the software. "g_flash_fast_config" fails. I have tried reducing the frequency to 166MHZ, 133MHz, 50 MHz, and 30MHz without results in the DTR mode in the "fast_config". I have tried using the FCB generated from the Boot Memory Configuration, but there is some struct layout differences which have made it hard to apply to the PX4 code.  I am tried different combinations of csHoldTime, csSetupTime and dataValidTime without results aswell. I tried DQS interal in low freq DTR Octal, but it did not work either. What could I try next? #include /**************************************************************************** * Public Data ****************************************************************************/ locate_data(".boot_hdr.conf") const struct flexspi_nor_config_s g_flash_config = { .memConfig = { #if !defined(CONFIG_BOARD_BOOTLOADER_INVALID_FCB) .tag = FLEXSPI_CFG_BLK_TAG, #else .tag = 0xffffffffL, #endif .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally, .csHoldTime = 1, .csSetupTime = 1, .deviceModeCfgEnable = 1, .deviceModeType = kDeviceConfigCmdType_Generic, .waitTimeCfgCommands = 1, .controllerMiscOption = (1u << kFlexSpiMiscOffset_SafeConfigFreqEnable), .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_1Pad, .serialClkFreq = kFlexSpiSerialClk_100MHz, .sflashA1Size = 64ul * 1024u * 1024u, .dataValidTime = { [0] = {.time_100ps = 0}, }, .busyOffset = 0u, .busyBitPolarity = 0u, .lookupTable = { /* Read Dedicated 3Byte Address Read(0x03), 24bit address */ [0 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x03, RADDR_SDR, FLEXSPI_1PAD, 0x18), //0x871187ee, [0 + 1] = FLEXSPI_LUT_SEQ(READ_SDR, FLEXSPI_1PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0),//0xb3048b20 }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, .ipcmdSerialClkFreq = 1, .serialNorType = 2, .reserve2[0] = 0x7008200, }; const struct flexspi_nor_config_s g_flash_fast_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally, .csHoldTime = 3, .csSetupTime = 3, .deviceModeCfgEnable = 1, .deviceModeType = kDeviceConfigCmdType_Spi2Xpi, .waitTimeCfgCommands = 1, .deviceModeSeq = { .seqNum = 1, .seqId = 6, /* See Lookup table for more details */ .reserved = 0, }, .deviceModeArg = 2, /* Enable OPI DDR mode */ .controllerMiscOption = (1u << kFlexSpiMiscOffset_SafeConfigFreqEnable) | (1u << kFlexSpiMiscOffset_DdrModeEnable), .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_8Pads, .serialClkFreq = kFlexSpiSerialClk_133MHz, .sflashA1Size = 64ul * 1024u * 1024u, .dataValidTime = { [0] = {.time_100ps = 10}, }, .busyOffset = 0u, .busyBitPolarity = 0u, .lookupTable = { /* Read */// EEH+11H+32bit addr+20dummy cycles+ 4Bytes read data /* Macronix manual says 20 dummy cycles @ 200Mhz, FlexSPI peripheral Operand value needs to be 2N in DDR mode hence 0x28 */ [0 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0xEE, CMD_DDR, FLEXSPI_8PAD, 0x11), //0x871187ee, [0 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, DUMMY_DDR, FLEXSPI_8PAD, 0x28),//0xb3288b20, [0 + 2] = FLEXSPI_LUT_SEQ(READ_DDR, FLEXSPI_8PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0x00), //0xa704, /* Read status */ [4 * 2 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x05, CMD_DDR, FLEXSPI_8PAD, 0xfa), [4 * 2 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, DUMMY_DDR, FLEXSPI_8PAD, 0x04), [4 * 2 + 2] = FLEXSPI_LUT_SEQ(READ_DDR, FLEXSPI_8PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0x00), /* Write enable SPI *///06h [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP_EXE, FLEXSPI_1PAD, 0x00),//0x00000406, /* Write enable OPI SPI *///06h [4 * 4 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x06, CMD_DDR, FLEXSPI_8PAD, 0xF9), /* Erase sector */ [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x21, CMD_DDR, FLEXSPI_8PAD, 0xDE), [4 * 5 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, STOP_EXE, FLEXSPI_1PAD, 0x00), /*Write Configuration Register 2 =01, Enable OPI DDR mode*/ //72H +32bit address + CR20x00000000 = 0x01 [4 * 6 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x72, CMD_SDR, FLEXSPI_1PAD, 0x00),//0x04000472, [4 * 6 + 1] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x00, CMD_SDR, FLEXSPI_1PAD, 0x00),//0x04000400, [4 * 6 + 2] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x00, WRITE_SDR, FLEXSPI_1PAD, 0x01),//0x20010400, /*Page program*/ [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR, FLEXSPI_8PAD, 0x12, CMD_DDR, FLEXSPI_8PAD, 0xED),//0x87ed8712, [4 * 9 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, WRITE_DDR, FLEXSPI_8PAD, 0x04),//0xa3048b20, }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, .ipcmdSerialClkFreq = 1, .serialNorType = 2, .reserve2[0] = 0x7008200, }; Re: Flash configuration confusion RT1176 Octal DDR Hello @SimonHugr, If you plan to use DDR mode, please keep in mind that the byte swapping configuration must also be considered. this post provides useful information about why important take in mind the byte swapping on the MX25UM51245GXDI00 when you are using DDR mode.  I highly recommend use the Boot Memory Configuration to generate the FCB, the Secure provisioning tool v26.6 offers a template of the MX25UM51245G, which can serve as a good starting point for your configuration. Also, as you may know, this tool allows you to test your configurations. Additionally, I recommend see this community post, particularly the steps starting from point 15. That section provides a more detailed explanation of how the Secure Provisioning Tool generates the boot memory configuration and may help clarify the parameters and output produced by the tool. Finally, you can use the flexspi_nor_polling_transfer_cm7 example to validate the generated FCB and verify that read and write operations are functioning correctly before proceeding with the boot configuration. BR Habib Re: Flash configuration confusion RT1176 Octal DDR No results yet sadly, I still think it has something to do with some data order swap is done and I am missing some configuration byte somewhere... Re: Flash configuration confusion RT1176 Octal DDR Thank you Masmiseim Indeed, I noticed that the data should be swapped for example. I will go through my LUT once more. Re: Flash configuration confusion RT1176 Octal DDR Refering to this thread: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Internal-Boot-from-Flash-memory-not-starting-on-imxRT1176-custom/m-p/1830699 I should swap the data order by editing the misc option and according to zephyr RTOS https://github.com/zephyrproject-rtos/hal_nxp/blob/3a36ee1f8b9fc2168fc0bf80377ace8298292993/mcux/mcux-sdk-ng/devices/RT/RT1170/MIMXRT1176/drivers/romapi/fsl_romapi.h#L340-L355 the dataswap byte goes in, but I think I am missing something. .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, .ipcmdSerialClkFreq = 1, .isDataOrderSwapped = true .serialNorType = 2, .reserve2[0] = 0x7008200, Re: Flash configuration confusion RT1176 Octal DDR Hey @SimonHugr, One thing I would verify first is the actual difference between the MX25UM51245G and MX25UM51345G. Although the part numbers are very similar, they are not identical devices. According to the Macronix datasheets, the MX25UM51345G explicitly supports DOPI (Double Transfer Rate OPI) Byte Mode data sequence, while the MX25UM51245G belongs to a different product variant. This can affect the command format, byte ordering and LUT configuration used by the FlexSPI controller. You can also compare my configuration which works with MX25UM513 and MX25UW6345G: https://github.com/Masmiseim36/Coremark_iMXRT/blob/master/XiP/flexspi_flash_OSPI_Macronix.c Regars Re: Flash configuration confusion RT1176 Octal DDR Hello Habib For our firmware I am not able to use the secure provisioning tool to generate the FCB, and instead the FCB needs to be loaded on boot in firmware and therefor I need to create the mem_config and flash_config struct and configure it myself. I found the zephyr project referenced a isDataOrderSwapped byte in the flash_nor_config https://github.com/zephyrproject-rtos/hal_nxp/blob/3a36ee1f8b9fc2168fc0bf80377ace8298292993/mcux/mcux-sdk-ng/devices/RT/RT1170/MIMXRT1176/drivers/romapi/fsl_romapi.h#L347-L348 and Claude reference a padSettingOverride bit on bit 5 and a dataSwap bit on bit 7 in the controllerMiscOption, but I am not sure if the LLM is heavily hallucinating this information. When generating the FCB using the Secure Provisioning tool and converting it into a C-struct using this tool https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/i-MX-RT-FLEXSPI-booting-guide/ta-p/1669262 I do not get bit 5 or 7 set so I think the LLM is wrong, but the isDataSwapped is set and is referenced as reserved0[0] in the FCB normally. I can not find a template for the MX25UM51245G in the secure provisioning tool, only the MX25U51245G (which is a Quad flash), the MX25UM51345G and the MX25UMxxx45G. But any config Octal DDR config that I have tried have not worked to boot. Interestingly often the MCU goes automatically into ISP mode after certain configuration despite BT_FUSE_SEL = 1 and having pins BOOTMODE0/1 = 0. This has not been consistent and I am not sure what configuration causes this. Does the MCU go into ISP mode after failing to read the flash or something? Thank you BR Re: Flash configuration confusion RT1176 Octal DDR Hello @SimonHugr, I apologies there is not a template to MX25UM51245G, only are available the MX25U51245G and MX25UM51345G. Based on your description, it seems that communication with the flash device is working correctly using your current Boot Memory Configuration settings. When you click "Convert to Complete FCB", the tool programs the configuration into the flash and then reads it back using the parameters you specified, as described below: If any of the selected settings are not supported by the flash device, the tool should report an error similar to the following: To further verify that the LUT generated using the FCB converter from the community post is functioning correctly, could you please test it with the flexspi_nor_polling_transfer_cm7 SDK example while running the application from internal RAM? Please let me know if you have questions about the example. In addition, could you provide me a few more details about the application you are trying to boot? -Is an SDK example or if your own application? -Which IDE you are using? -Is your application performing XIP or NON-XIP? -Are you accessing the flash at any point other than during the boot process? Regarding to entering in ISP mode, could you please make sure that the boot pins on your custom board followed the recommendations mentioned in the chapter 5 "Boot, reset, and miscellaneous" of the Hardware Development Guide for the MIMXRT1160/1170? This to avoid any hardware issue regarding the boot pins.   Answering your question, you can enter in ISP mode if is not available a valid image, as shown the figure 10-1 "boot flow" of the RM: BR Habib  Re: Flash configuration confusion RT1176 Octal DDR Hello Habib. I got octal SPI STR mode working at 200MHz now atleast. The problem was some magic non-described "reserve2" bytes that was being set. I also opted to set a config cmd sequence ontop of the device mode sequence setting an additional byte. Setting the byte swap did not accomplish anything, but I am happy with the speed I am able to achieve at 200MHz STR Octal Best regards

[S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi NXP Experts, There was an abnormality in the use of the LLCE can function of the S32G399A in our project. Occasionally, there was an issue with the reception of a certain CAN message reported by the ECU, while the transmission was normal. After debugging, it was found that the can interrupt could be triggered normally, but the u32Word0 read from Can_SharedMemory changed from 0x18008 to 0x1800f, which was an abnormal value. The calculated u32MbMessageId was 0.This led to message loss. The RxMbDescIdx had a value and was changing, and word1 sometimes was 0 but was also changing. This situation occurred sporadically, and the affected CAN line was also random. Please help analyze this situation,The debugging screenshots are provided below. How should I proceed with the next debugging steps, or what solutions are there? The LLCE version is: 1.0.10 . Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey_z Yes, we use our own boards and software. We employ LLCE in the M core and have integrated the MICROSAR com protocol stack of vector. RTD version:RTD_4.4_5.0.0_QLP03 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe Thank you for contacting us. Could you tell us more information? 1. Which version of RTD are you using? 2.Are you using your own boards and your own software? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi NXP Experts, Syncing the information: In an abnormal situation, we read the controller status through Can_Llce_GetControllerMode as "start", and then executed a "stop->start" transition through the Can_43_LLCE_SetControllerMode interface. The abnormal CAN can recover. From the value of word0, it seems that there was an error in the internal DTE kernel of LLCE when transferring data to the shared memory. Currently, the abnormality probability is still quite high at around 20%-30%. Our team has signed the relevant NDA documents. Could you please prioritize the handling of this issue? Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi，canhe   Ok, we will raise the priority of your questions! 1.Could you please tell me whether the CAN frames you received originated from an external device or from such the CANoe device? Is it receiving CAN or CANFD frame? 2.What is the set baud rate? Which port are you using? 3.is the frame be processed by the internal core or routed via CAN2CAN? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe It seems that you have made some changes to Can_Llce_ProcessRxMb. Did you have any issues before the changes were made? Could you share the modified code? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey Thank you for your reply. This issue occurred before I added the debugging code. I added the debugging code to confirm the specific cause. The debugging code merely reads certain states. It seems that the value of the shared memory is abnormal. The patch has been provided to you. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi，canhe Thank you for your information. 1.In the scenarios where you encountered problems, what was the Busload of the CAN bus? Is the Busload too high? 2.When frame loss occurs, does the Notification report any errors? If you have any error messages, please share them with me. 3.When does the error occur - during the Routing process or when the frame is sent to the Host? Is it CAN or CAN FD frame that is being used? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey 1. The bus load rate is between 40% and 50%, which doesn't seem very high. 2. BCAN_RXFIFO_OVERRUN has occurred under abnormal conditions, but I also observe this notification during normal operation. 3. Currently, LLCE does not have routing functionality enabled; it only forwards data to the host. Most frames used are CAN FD, with a small number of CAN frames. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,joey Thank you for your reply. I will reduce the load rate and conduct the test again. Regarding the second point you mentioned about the MB size, I have tried increasing it from 20 to 300, but there were still abnormalities. Furthermore, do you know if LLCE has any internal logic regarding the handling of shared memory? Under what circumstances would an abnormal value occur for the "word0" field? For instance, if the value of "word1" is written to "word0". Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe 1.Test to reduce the bus load and observe whether the frequency of the problematic frames decreases. 2.Also, try to increase the number in the parameters shown in the picture. BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,joey 1. The received CAN frames originated from the external ECU. Currently, the abnormality is replicated in the test bench using the CANOE device for simulation. In reality, the abnormality has occurred in both situations. The majority of the received messages are CANFD frames, while a small number are CAN frames. 2. The baud rate is set at 500k for the arbitration segment, 2M for the data segment, and 80% for the sampling rate. The controller uses BCAN1-BACN5. 3. The frames are processed by the internal core. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi，canhe Thank you for your detail information. Are all of you using BCAN1-BACN5 to perform the receiving frame operation? I use the same version of LLCE and the same configuration as yours in a receiving testing on one port, and not encounter the similar error as yours. BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey We mainly use BCAN1-BCAN3 to receive most of the application message frames. BCAN4 is currently not capable of sending or receiving data. BCAN5 is connected to the internal bus and transmits a small number of messages. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe According to the previous tests. Will reducing the CAN busload and using a single CAN channel cause any problems for you? BR Joey Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,joey Thank you for your help. I have completed this case. The tracking number is: 00997151. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey Could I kindly ask if it's convenient for you to contact the local FAE (Field Application Engineer) for on-site support or online support in China? I think this would help us solve the problem more quickly. Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi，canhe Please try to create a case through the link below. https://support.nxp.com Regarding this issue, please fill in the relevant case information, I will help you contact the software team and LLCE experts through internal channels. BR Joey

Deep Sleep Mode of iMX937 I am using iMX95lpddr5 evk, triggered the deep sleep mode want to know about the state, clock frequency and power consumption of suspended and non suspended cores among A55, M7 and M33. Re: Deep Sleep Mode of iMX937 On i.MX95 LPDDR5 EVK, “deep sleep” maps to the i.MX 95 Suspend / DSM-style low-power cases . The A55 is suspended/power-gated; M33 is not running application workload, typically shown as clock-gated/idle ; M7 depends on whether you suspend it too or keep it as the wake/real-time core. The power numbers in AN14449 are SoC rail/group totals , not per-core power. Low-power case Cortex-A55 state / freq Cortex-M33 state / freq Cortex-M7 state / freq DDR state Reported power System in DSM Suspend; clock not detectable Clock gating; clock not detectable Suspend; clock not provided Retention 25.65 mW GROUP_SOC_FULL total  Linux Suspend + CM7 WFI Suspend / 0 Clock gating or idle / 0 WFI / 400 MHz Retention 178.48 mW GROUP_SOC_FULL total  Linux Suspend + CM7 CoreMark (TCM) Suspend / 0 Clock gating or idle / 0 CoreMark / 400 MHz Retention 197.24 mW GROUP_SOC_FULL total  Linux Suspend + CM7 FlexCAN transaction Suspend / 0 Clock gating or idle / 0 FlexCAN / 800 MHz Active, 6400 MT/s 659.71 mW GROUP_SOC_FULL total  Linux Suspend + CM7 NETC / Ethernet Suspend / 0 Clock gating or idle / 0 NETC / 800 MHz Active, 6400 MT/s 956.17 mW GROUP_SOC_FULL total  Linux Suspend + WoL A55 suspended M33 idle/low-power context wake-capable configuration; exact core table not in the retrieved chunk depends on WoL setup 342.72 mW GROUP_SOC_FULL total  A few interpretation notes: The i.MX 95 Reference Manual describes Suspend as the maximum-power-saving mode where unnecessary clocks/supplies are off, the Cortex-A55 CPU is fully power-gated, PHYs that can be powered down are off, and VDD_SOC is reduced to suspend voltage. In System in DSM , AN14449 explicitly says the usage is CA55=Suspend, CM33=Clock gating, CM7=Suspend, DDR=Retention , and also notes that because CA55 and CM33 are not working, clocks cannot be detected. For Linux suspend with M7 kept active, the non-suspended core is CM7 ; its clock is either 400 MHz for WFI/CoreMark retention cases or 800 MHz for FlexCAN/NETC cases, while A55 and M33 show 0 MHz in the case tables. The published power data is not isolated per A55/M7/M33 core . AN14449 reports rail/group measurements such as GROUP_SOC_FULL and GROUP_DRAM; for example, DSM reports vdd_arm as 0 mW and vdd_soc as 3.85 mW within a GROUP_SOC_FULL sum of 25.65 mW, but that is still rail-level, not individual-core power. Takeaway: if M7 is also suspended, DSM is about 25.65 mW; if M7 stays alive during Linux suspend, total SoC power rises from about 178–197 mW at 400 MHz to about 660–956 mW at 800 MHz depending on the peripheral workload. Re: Deep Sleep Mode of iMX937 For I.Mx95, there are several power mode including RUN mode, Lower power RUN mode, IDLE mode, SUSPEND mode and Battery Backed Secure Module mode. For detailed power consumption data, please refer to IMX95AEC datasheet. For i.Mx937, the device is at preproduction phase and only factsheet is available right now. Not sure about how the test data come from and what the deep sleep mode you refer to...

关于GUI Guider v2.0.0的UI编辑器Bug反馈 我在使用GUI Guider v[你的版本号]时，遇到了几个影响开发效率的Bug，想向开发团队反馈一下： 拖动布局导致布局丢失：当我在UI编辑器中拖动控件进行布局调整时，操作偶尔会失败，并且最新的布局改动会丢失，界面回退到之前的状态。 控件名称重复且无法删除：在操作过程中，有时会出现多个控件名称一致的情况，并且这些控件无法通过右键菜单或Delete键删除。唯一能解决的办法是重新登录软件，这些“幽灵”控件才会消失。

CodeWarrior for LA1224 plugin Hello,  I am currently In the middle of evaluating LA1224-RDB and I have some questions regarding the software environment. As I understand I can have a Linux app running on the existing NxP image on LX2160A for evaluation purposes. Furthermore I suppose LA1224 is running baremetal with freertos. I saw that I can have firmware for LA1224 in a Linux directory on the LX2160A. Is this given from NxP? What does it support? I suppose that if I want to develop something further than the given firmware I have to get a codewarrior license and TAP. I have downloaded CW_ARMv8_v2020.06_b200629GA_Win_Setup.exe however the LP1224 is not available. After searching the NxP site I read that I need an extra toolchain on top of CW_ARMv8. What is the full url to download the add on?  I read CodeWarrior for LA1224 and only a partial url is given "com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip" Any further information on how to work on those processors is welcome. Kind Regards N. Alexopoulos

S32K312 temperature sensor inaccurate reading Hello NXP Team, I am working on the S32K312​ internal temperature sensor and need help with incorrect temperature readings. I have reviewed similar threads and confirmed the basic configurations, but the ADC results do not reflect the ambient temperature. What I have done so far： (1) TEMPSENSE clock enabled​-Screenshot attached  (2)ADC configuration ADC instance: ADC0 Channel: Temperature Sensor (TEMPSENSE) Trigger mode: Software trigger (3)Measurement routine Periodically start ADC conversion Wait for conversion complete flag Read ADC data register (4)Result However, the converted temperature value does not match the actual ambient temperature. Any guidance, clarification, or reference code for the S32K312 temperature sensor would be greatly appreciated.   Thanks in advance for your support!   Best regards, Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas The temperature channel requires a relatively long sampling time, with a minimum of 1.2 microseconds. Therefore, please check the sampling time settings. Re: S32K312 temperature sensor inaccurate reading I further switched the ADC voltage reference to 0x50, but the issue persists: The temperature readings deviate significantly from the ambient temperature (28°C). Temperature data retrieved via the API exhibits severe fluctuations, as shown in the attached plot. Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas Then you should set TempSense voltage supply to: 5V * 16 = 0x50 Re: S32K312 temperature sensor inaccurate reading The TempSense voltage supply is configured as 0x58, hardware's VDD_HV_A supply voltage is 5V Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas Please check the "TempSense Voltage Supply" and tell me what your current hardware's VDD_HV_A supply voltage is. Re: S32K312 temperature sensor inaccurate reading changed the sampling time division ratio from 2 to 4, but the collected temperature data is still incorrect. Please help me troubleshoot the root cause. The detailed configuration is as follows: Re: S32K312 temperature sensor inaccurate reading Hi@SunLucas You can send me your EB configuration file, and I'll check it for you. There are two points to note: first, the reference voltage of the Temper Sensor must match the onboard VDD_HV_A; second, the sampling time. Once you've verified that these two points are correct, then there are no other points to note for this module.

Issue: CONFIG_IMX_RPMSG_TTY is built as a module but appears as "not set" after flashing Android Hi NXP Team, I am working on the i.MX8M Mini LPDDR4 EVK with the Android 16 BSP and trying to enable RPMsg communication between the Cortex-A53 and Cortex-M4. Configuration I enabled the NXP RPMsg TTY driver in the kernel configuration: CONFIG_IMX_RPMSG_TTY=m I also added the module to SharedBoardConfig.mk: $(KERNEL_OUT)/drivers/rpmsg/imx_rpmsg_tty.ko The module is built successfully. The generated kernel configuration confirms it is enabled: grep CONFIG_IMX_RPMSG_TTY out/target/product/evk_8mm/obj/KERNEL_OBJ/.config Output: CONFIG_IMX_RPMSG_TTY=m The module is also generated successfully: out/target/product/evk_8mm/vendor_dlkm/lib/modules/imx_rpmsg_tty.ko and is packaged into the Android image. Runtime Observation After flashing the board, the running kernel configuration does not report the RPMsg module configurations. adb shell zcat /proc/config.gz | grep RPMSG Output: CONFIG_GKI_HIDDEN_RPMSG_CONFIGS=y # CONFIG_RPMSG_WWAN_CTRL is not set # CONFIG_RPMSG_TTY is not set # CONFIG_SND_SOC_FSL_RPMSG is not set CONFIG_RPMSG=y CONFIG_RPMSG_CHAR=y # CONFIG_RPMSG_CTRL is not set # CONFIG_RPMSG_NS is not set # CONFIG_RPMSG_QCOM_GLINK_RPM is not set # CONFIG_RPMSG_VIRTIO is not set Also, adb shell zcat /proc/config.gz | grep IMX_RPMSG returns no output. However, the corresponding RPMsg modules are loaded successfully: lsmod | grep -i rpmsg Output: snd_soc_imx_rpmsg snd_soc_rpmsg_ak4497 imx_audio_rpmsg snd_soc_fsl_rpmsg imx_pcm_rpmsg i2c_rpmsg_imx virtio_rpmsg_bus rpmsg_ns This indicates that the modules are built and loaded correctly, but /proc/config.gz does not reflect their configuration. Questions Is it expected that /proc/config.gz on the Android 16 BSP only reflects the base GKI kernel configuration and not the vendor module configuration? Why is CONFIG_IMX_RPMSG_TTY=m not visible in /proc/config.gz even though imx_rpmsg_tty.ko is built and packaged? Is there an additional configuration required for the running kernel configuration to include vendor module options? Could this behavior be related to Android GKI and vendor_dlkm module packaging? Any clarification would be appreciated. Android i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Issue: CONFIG_IMX_RPMSG_TTY is built as a module but appears as "not set" after flashi Hello @vp1  Hope you are doing very well. Could you please share what device tree are you using? Can you please try using the imx8mm-evk-rpmsg.dts? Best regards, Salas. Re: Issue: CONFIG_IMX_RPMSG_TTY is built as a module but appears as "not set" after flashi Hi @Manuel_Salas , Thank you for your response. Currently, my Android AOSP build is using the device tree imx8mm-evk.dts. I can see that imx8mm-evk-rpmsg.dts is also available and is built successfully. Could you please let me know how to configure the Android build to use imx8mm-evk-rpmsg.dts instead of imx8mm-evk.dts during boot? Is there any specific configuration in the Android BSP, U-Boot, or imx-mkimage that selects which device tree is packaged and loaded? Thank you for your guidance. Best regards, Vikas Patil

Android 14+ performance issues (Janky frames) Hello,  We are using a custom board based on IMX8MP and noticed some performance issues when upgrading from Android 11 to Android 14. We noticed that transitions and animations feel laggy when using the device.  For evaluation, we performed the same tests on the IMX8MP EVK board. We were taking a look at the gfxinfo of the device and saw that there are huge differences in Janky frames, Number High input latency, and GPU percentile.  Android 11:  Total frames rendered: 1372 Janky frames: 204 (14.87%) 50th percentile: 7ms 90th percentile: 34ms 95th percentile: 77ms 99th percentile: 200ms Number Missed Vsync: 91 Number High input latency: 274 Number Slow UI thread: 89 Number Slow bitmap uploads: 1 Number Slow issue draw commands: 61 Number Frame deadline missed: 145 50th gpu percentile: 2ms 90th gpu percentile: 3ms 95th gpu percentile: 3ms 99th gpu percentile: 4ms Android 14:  Total frames rendered: 1136 Janky frames: 429 (37.76%) Janky frames (legacy): 600 (52.82%) 50th percentile: 29ms 90th percentile: 73ms 95th percentile: 113ms 99th percentile: 250ms Number Missed Vsync: 130 Number High input latency: 755 Number Slow UI thread: 254 Number Slow bitmap uploads: 3 Number Slow issue draw commands: 376 Number Frame deadline missed: 429 Number Frame deadline missed (legacy): 342 50th gpu percentile: 4ms 90th gpu percentile: 23ms 95th gpu percentile: 23ms 99th gpu percentile: 24ms Android 15: Total frames rendered: 1093 Janky frames: 318 (29.09%) Janky frames (legacy): 639 (58.46%) 50th percentile: 18ms 90th percentile: 97ms 95th percentile: 105ms 99th percentile: 109ms Number Missed Vsync: 221 Number High input latency: 1028 Number Slow UI thread: 145 Number Slow bitmap uploads: 0 Number Slow issue draw commands: 317 Number Frame deadline missed: 318 Number Frame deadline missed (legacy): 309 50th gpu percentile: 11ms 90th gpu percentile: 4950ms 95th gpu percentile: 4950ms 99th gpu percentile: 4950ms Is this a known issue, or are there any hints on how we could solve this issue? Android Re: Android 14+ performance issues (Janky frames) Hello @JK-dev, Thanks for the data, we will do an internal research and get back to you when we find anything. Re: Android 14+ performance issues (Janky frames) Hi @JuanJorge_Mendoza ,  I did tests on A16 and A13. Android 16:  Total frames rendered: 946 Janky frames: 414 (43.76%) Janky frames (legacy): 631 (66.70%) 50th percentile: 30ms 90th percentile: 113ms 95th percentile: 200ms 99th percentile: 350ms Number Missed Vsync: 180 Number High input latency: 764 Number Slow UI thread: 265 Number Slow bitmap uploads: 7 Number Slow issue draw commands: 384 Number Frame deadline missed: 414 Number Frame deadline missed (legacy): 366 50th gpu percentile: 11ms 90th gpu percentile: 4950ms 95th gpu percentile: 4950ms 99th gpu percentile: 4950ms Android 13:  Total frames rendered: 1000 Janky frames: 284 (28.40%) Janky frames (legacy): 397 (39.70%) 50th percentile: 12ms 90th percentile: 69ms 95th percentile: 129ms 99th percentile: 250ms Number Missed Vsync: 122 Number High input latency: 446 Number Slow UI thread: 176 Number Slow bitmap uploads: 1 Number Slow issue draw commands: 242 Number Frame deadline missed: 284 Number Frame deadline missed (legacy): 248 50th gpu percentile: 3ms 90th gpu percentile: 23ms 95th gpu percentile: 24ms 99th gpu percentile: 4950ms Re: Android 14+ performance issues (Janky frames) Hello @JK-dev, Yes, please run the same test and forward the results. Regards, Juan Jorge Re: Android 14+ performance issues (Janky frames) Hi @JuanJorge_Mendoza , Thanks for the reply! As a test for the Janky frames, we just started the system and rebooted once, so we don't have issues caused by any first boot optimizations, and moved around inside the Settings App. Then we read out the gfxinfos through: adb shell dumpsys gfxinfo If you would say this is a valid test, I am happy to perform it on A12, A13, and A16. Re: Android 14+ performance issues (Janky frames) Hello @JK-dev, No, that shouldn't be an issue.  Could you share the test used to test the Janky frame? Also if possible, could you please run the same test on A12 and A13? It will help us to track down where the issue begins to appear. Regards, Juan Jorge Re: Android 14+ performance issues (Janky frames) Hi @danielchen , The Display only supports one resolution, which is 720p. I would guess this shouldn't be the issue. Re: Android 14+ performance issues (Janky frames) Hi @JK-dev   what display resolution you are using?   Could you check if lowering it  helps reduce GPU/CPU load and improves overall performance. Re: Android 14+ performance issues (Janky frames) @danielchen Thanks for the reply. I saw this post before, but for my understanding, it would mean that if we are using a user build instead of a userdebug build, the issue should be gone; however, this isn't the case. For us, it seems to be the same in user and userdebug images; is there a different way to turn off debuggable for the whole system? Re: Android 14+ performance issues (Janky frames) Hi @JK-dev  Yes,  this is a known issue on Android 14+ for i.mx8mp. Android 14+ enables more extensive tracing and memory tracking for debug apps,  which can slow down rendering by 1.5x-2x compared to previous versions.  This affects UI thread, GPU scheduling, and input latency. Please refer to below link for the quick workaround and more information. https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Low-Performance-on-Android-14/ta-p/1991262 Regards Daniel Re: Android 14+ performance issues (Janky frames) Hello @JK-dev, Sorry for the late response it took us a while to optimize the GUI for the 8MP. The patch "0001-MA-22638-Update-expected-present-time-to-optimize-re.patch" is used to optimize the refresh rate in framework/native. Another two patches need to be applied in vendor/nxp-opensource/imx   Please let us know if that solve your problem Re: Android 14+ performance issues (Janky frames) Hi @JuanJorge_Mendoza , Sorry for the late reply, I was on holiday. Thank you for the patches! We tested your patches, and we can see that there is a slight improvement when navigating around.  However, when it comes to higher loads or more Animations, the system remains very laggy, and most frames arrive way too late. To reproduce this, you could, for example, go to Settings -> Apps -> All Apps -> Include System Apps and scroll through that list. You will see that more than 50% of the frames are late.  Re: Android 14+ performance issues (Janky frames) Hey @joanxie , No, the performance is slightly better than before.  Without the patches:  Total frames rendered: 1015 Janky frames: 376 (37.04%) Janky frames (legacy): 731 (72.02%) 50th percentile: 31ms 90th percentile: 150ms 95th percentile: 200ms 99th percentile: 400ms Number Missed Vsync: 262 Number High input latency: 1167 Number Slow UI thread: 368 Number Slow bitmap uploads: 1 Number Slow issue draw commands: 26 Number Frame deadline missed: 376 Number Frame deadline missed (legacy): 386 50th gpu percentile: 4ms 90th gpu percentile: 11ms 95th gpu percentile: 11ms 99th gpu percentile: 12ms   With the patches:  Total frames rendered: 2078 Janky frames: 594 (28.59%) Janky frames (legacy): 1050 (50.53%) 50th percentile: 21ms 90th percentile: 133ms 95th percentile: 200ms 99th percentile: 400ms Number Missed Vsync: 367 Number High input latency: 2045 Number Slow UI thread: 567 Number Slow bitmap uploads: 4 Number Slow issue draw commands: 68 Number Frame deadline missed: 594 Number Frame deadline missed (legacy): 580 50th gpu percentile: 4ms 90th gpu percentile: 11ms 95th gpu percentile: 11ms 99th gpu percentile: 12ms   As you see, the patch reduces the number of Janky frames, and the 50% percentile is better, but still not sufficient. Re: Android 14+ performance issues (Janky frames) when it comes to higher loads or more Animations > is it worse than before? Is there any specific performance comparison data between using this patch and not using this patch? Re: Android 14+ performance issues (Janky frames) did your operation via UI? if yes, do you have any script or something specific steps? then I can forward to the android team to validate and debug further Re: Android 14+ performance issues (Janky frames) Hey @joanxie, It's basically the same test we did before. What would be a test for the Android team that is sufficient? Re: Android 14+ performance issues (Janky frames) they hope you can give them a script to run the performance test and show the detailed performance degradation data, then they can reproduce this, because they don't find the same issue on their side Re: Android 14+ performance issues (Janky frames) There is now a solution for this issue: https://www.linkedin.com/posts/kalkov_embeddedandroid-nxp-aosp-share-7490309949391089664-ifxq/?utm_source=share&utm_medium=member_desktop&rcm=ACoAADU1d0wBcGPG6tNYlHxJaSFzHqMEI3XBUJY https://emteria.com/blog/nxp-imx8m-plus-android-scroll-fix

S32DS license ActivationId Hello, When I opened the S32DS, I got the following information:  S32 Design Studio for ARM ActivationId: 1A99-90A8-2F06-339B Evaluation Days: 14 Feature Version: 2.2 Feature Status: Evaluation (14 days) What procedures are required to extend the license validity period? Wishing you good business wishes! 

How to Test TX PAUSE Frames with DPDK enetc4 VF Driver on i.MX95 / i.MX9x Series This post walks through end-to-end steps to enable and verify TX PAUSE frame (IEEE 802.3x flow control) generation on the i.MX95 / i.MX9x series using DPDK 25.11 with the enetc4 VF driver and a Spirent traffic generator. I also share an optional debug patch that lowers the PAUSE trigger threshold for quick lab reproduction and adds register readback prints to dmesg. --- Overview -------- On i.MX95 the ENETC4 Ethernet controller uses a PF/VF split: - The kernel PF driver (fsl_enetc4, Linux 6.18+) owns the MAC, PHY negotiation, and PAUSE configuration. - The DPDK VF driver (net/enetc, DPDK 25.11) owns the receive rings in the DPDK application. When the link partner negotiates PAUSE, the kernel PF configures the MAC and notifies the DPDK VF via a mailbox message. The VF then enables congestion signaling on its Rx rings. When incoming traffic fills those rings past the configured threshold, the hardware automatically emits PAUSE frames toward the sender. The trigger chain looks like this: High-rate ingress traffic fills VF Rx rings --> ICM fill level crosses PPAUONTR threshold --> MAC emits IEEE 802.3x PAUSE frame to link partner --> link partner pauses its transmitter --- Hardware Setup -------------- - i.MX95 EVK (or any i.MX9x board with ENETC4) - 10G SFP+ DAC cable or fiber between i.MX95 ENETC4 port and Spirent TestCenter port - Spirent TestCenter (or equivalent traffic generator with flow control capture) Software versions used in this guide: - Kernel: Linux 6.18+ with fsl_enetc4 PF driver - DPDK: 25.11 (net/enetc VF PMD) - ethtool: 6.x --- Step 1 — Enable PAUSE on the Kernel PF Interface ------------------------------------------------- The kernel PF interface (typically eth1 for ENETC4 port 1) must have TX PAUSE enabled before the link comes up so that phylink can negotiate it with the link partner. # Identify the kernel PF interface ip link show | grep -E "eth[0-9]" # Enable TX and RX PAUSE (autoneg lets the link partner also advertise PAUSE, it is off since we are using spirent) ethtool -A eth1 tx on rx on autoneg off # Bring the link up ip link set eth1 up # After link is up, verify PAUSE was negotiated ethtool -a eth1 Expected output: Pause parameters for eth1: Autonegotiate: off RX: on TX: on If TX shows "off" after link up, the link partner may not have advertised PAUSE capability. Try forcing it: ethtool -A eth1 tx on rx on autoneg off --- Step 2 — Verify ethtool Statistics Are Available ------------------------------------------------- Confirm that the ethtool stats interface is working before starting traffic: ethtool -S eth1 | grep -E "txpf|rxpf|pause" You should see counters like txpf_frames and rxpf_frames (both 0 at this point). If you see "no stats available", verify your kernel build includes the ethtool ops for enetc4. --- Step 3 — Bind the DPDK VF to igb_uio ----------------------------------- note bootargs: must have iommu_passthrough=1 # Load the VFIO driver modprobe igb_uio echo 1 > /sys/bus/pci/devices/0002\:00\:10.0/sriov_numvfs echo igb_uio > /sys/bus/pci/devices/0002\:00\:12.0/driver_override echo 0002:00:12.0 > /sys/bus/pci/drivers/fsl_enetc_vf/unbind echo 0002:00:12.0 > /sys/bus/pci/drivers/igb_uio/bind ip link set eth1 vf 0 trust on --- Step 4 — Allocate Hugepages ----------------------------- # 4 x 1 GB hugepages (recommended for 10G line-rate testing) echo 4 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages mount -t hugetlbfs none /dev/hugepages # Verify allocation grep HugePages /proc/meminfo # HugePages_Total: 4 # HugePages_Free: 4 --- Step 5 — Start testpmd ------------------------ For PAUSE testing the goal is to build up backpressure in the VF Rx rings so the ICM congestion threshold is crossed. Use rxonly mode with a small Rx descriptor count so the ring fills up quickly under load. testpmd \ -l 0-3 -n 4 \ -a 0002:00:12.0 \ -- \ --rxd=256 \ --txd=512 \ --nb-cores=2 \ --rxq=1 --txq=1 \ --forward-mode=rxonly \ --stats-period=5 Inside the testpmd prompt: testpmd> set fwd rxonly testpmd> start testpmd is now receiving and the DPDK VF Rx rings will fill under high-rate ingress traffic, generating the congestion signal that drives PAUSE frame emission. --- check stats via: ethtool --include-statistics -a eth1 Step 6 — Configure Spirent TestCenter --------------------------------------- Spirent port sending TO i.MX95 (ingress traffic): - Frame size: 64 bytes or smaller (smaller frames fill rings faster) - Rate: 100% line rate (10 Gbps) - Frame type: Ethernet II / IPv4 - Destination MAC: MAC address of the i.MX95 ENETC4 VF interface - Destination IP: IP address assigned to the i.MX95 interface Spirent port receiving FROM i.MX95 (PAUSE capture): - Port Properties → Flow Control → Enable IEEE 802.3x PAUSE - Enable Capture → Filter EtherType: 0x8808 - Results → Port Results → watch "Flow Control Frames Received" This counter increments every time a PAUSE frame arrives from i.MX95. - Optional: Results → Flow Analysis → check "Pause Duration (quanta)" Expected value: ~32767 (0x7FFF) Alternative capture without Spirent license: # On any PC with a tap on the wire tcpdump -i eth0 'ether proto 0x8808' -v # PAUSE frame: dst 01:80:c2:00:00:01, EtherType 0x8808, opcode 0x0001 --- Step 7 — Verify PAUSE Frames Are Being Sent --------------------------------------------- Start Spirent at 100% line rate, then on the i.MX95 host run: watch -n 1 'ethtool -S eth1 | grep -E "txpf|rxpf"' Expected output when PAUSE is active: txpf_frames: <-- TX PAUSE frames sent by i.MX95 On Spirent, "Flow Control Frames Received" should be incrementing at the same time. --- Optional — Debug Patch for Faster Lab Reproduction ---------------------------------------------------- I am attaching a patch file to this post. This useful for bring-up and debug — this is not required for production use. Adds dev_info() prints to enetc4_set_tx_pause() and enetc_set_congestion_mode() in the kernel driver. After link-up you will see in dmesg: fsl_enetc4 0000:00:00.0: enetc4_set_tx_pause: tx_pause=1 fsl_enetc4 0000:00:00.0: PPAUONTR = 0x00001000 fsl_enetc4 0000:00:00.0: PPAUOFFTR = 0x00000400 fsl_enetc4 0000:00:00.0: PM_CMD_CFG(0) = 0x000000c3 TX_EN=1 RX_EN=1 TXP=0 fsl_enetc4 0000:00:00.0: set_congestion_mode: enable=1 num_rx_rings=1 fsl_enetc4 0000:00:00.0: ring[0] readback rbmr=0x00000010 This confirms the kernel PF configured the MAC and set the RBMR congestion mode bit on the PF rings. The DPDK VF should receive the same setting via mailbox. also Lowers the PAUSE trigger threshold to PPAUONTR=4096 bytes so that PAUSE frames are generated at much lower traffic rates — useful for quick lab tests without needing a full 10G line-rate traffic generator. Also adds ICM register definitions (PRXBCR, PRXBCHWMR) so you can observe the ICM fill level via ethtool -S. After applying this patch, check ICM fill level during traffic: ethtool -S eth1 | grep -E "prxbcr|prxbchwmr" # prxbcr_bytes: # prxbchwmr_bytes: When prxbchwmr_bytes >= 4096, the threshold has been crossed and PAUSE should fire. --- Key Register Reference (ENETC4) --------------------------------- Note: ENETC4 register offsets start at 0x5000 for MAC/PM registers. This is different from ENETC v1 which uses 0x8000. Use ethtool -S for PM counters since PF BAR0 is IOMMU-protected on i.MX95. Register Offset Description PM_CMD_CFG(0) 0x5008 MAC config register (TXP = BIT 15) PM_TXPF(0) 0x5218 TX PAUSE frames sent (64-bit) PM_RXPF(0) 0x5118 RX PAUSE frames received (64-bit) PPAUONTR 0x108 ICM fill level threshold to START PAUSE PPAUOFFTR 0x10C ICM fill level threshold to STOP PAUSE PRXBCR 0x128 Current ICM RX fill level (live, read-only) PRXBCHWMR 0x12C ICM RX peak fill since boot (read-only) For VF Rx ring registers, VF BAR0 is accessible via devmem2: # Check RBMR of VF ring 0 — BIT 4 = CM (congestion mode) # Replace VF_BAR0 with your actual address (find via /sys/bus/pci/devices/.../resource0) devmem2 w # Expected when PAUSE is active: 0x00000010 --- Environment ----------- SoC: i.MX95, i.MX943 (i.MX9x series with ENETC4) Kernel: Linux 6.18+ (fsl_enetc4 PF driver) DPDK: 25.11 (net/enetc VF PMD) Tool: testpmd, ethtool 6.x, Spirent TestCenter Hope this helps. Happy to answer questions on the setup.

Lab 1 – Low Power is a Superpower

（TC358748）并行至CSI2视频桥接器出现故障 你好， 我正在做一个项目，需要将 FPGA 连接到我们定制的 i.MX8MP 板。我正在尝试修改 tc358746（并行 -> CSI2）驱动程序，以支持我们的 yocto lf-5.15.71 版本。 我希望视频管道（FPGA (YUV4:2:2) -> bridge (YUV4:2:2/4-lane) -> mipi_csi0 -> isi0）目前以 YUV4:2:2 格式输出 1920x1080@30Hz，但我无法使用 Gstreamer 或 v4l2-ctl 捕获任何帧。 v4l-subdev1 不会出现在 v4l2 设备列表中。 请查看网桥的 media-ctl 输出和 dmesg 日志，非常感谢您能提供任何故障排除方面的见解。 root@:~$ media-ctl -p Media controller API version 5.15.71 Media device information ------------------------ driver mxc-md model FSL Capture Media Device serial bus info hw revision 0x0 driver version 5.15.71 Device topology - entity 1: mxc_isi.0 (16 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 pad0: Sink <- "mxc-mipi-csi2.0":4 [ENABLED] pad1: Sink pad2: Sink pad3: Sink pad4: Sink pad5: Sink pad6: Sink pad7: Sink pad8: Sink pad9: Sink pad10: Sink pad11: Sink pad12: Source -> "mxc_isi.0.capture":0 [ENABLED] pad13: Source pad14: Source pad15: Sink - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: Sink <- "mxc_isi.0":12 [ENABLED] - entity 22: mxc-mipi-csi2.0 (8 pads, 2 links) type Node subtype V4L flags 0 device node name /dev/v4l-subdev0 pad0: Sink <- "tc358748 2-000e":0 [ENABLED,IMMUTABLE] pad1: Sink pad2: Sink pad3: Sink pad4: Source -> "mxc_isi.0":0 [ENABLED] pad5: Source pad6: Source pad7: Source - entity 31: tc358748 2-000e (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Source [fmt:UYVY8_2X8/1920x1080@1/30 field:none colorspace:srgb] -> "mxc-mipi-csi2.0":0 [ENABLED,IMMUTABLE] root@:~$ v4l2-ctl --list-devices (): /dev/v4l-subdev0 mxc-isi-cap (platform:32e00000.isi:cap_devic): /dev/video2 FSL Capture Media Device (platform:mxc-md): /dev/media0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video1 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video0 root@:~$ v4l2-ctl --device /dev/video2 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [3]: 'YUYV' (YUYV 4:2:2) Size: Discrete 1920x1080 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.033s (30.000 fps) root@:~$ v4l2-ctl -d /dev/video2 --all Driver Info: Driver name : mxc-isi-cap Card type : mxc-isi-cap Bus info : platform:32e00000.isi:cap_devic Driver version : 5.15.71 Capabilities : 0x84201000 Video Capture Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04201000 Video Capture Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : mxc-md Model : FSL Capture Media Device Serial : Bus info : Media version : 5.15.71 Hardware revision: 0x00000000 (0) Driver version : 5.15.71 Interface Info: ID : 0x03000014 Type : V4L Video Entity Info: ID : 0x00000012 (18) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000013 : 0: Sink Link 0x02000021: from remote pad 0x100000e of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled Priority: 2 Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'RGBP' (16-bit RGB 5-6-5) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : Default YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 Crop Capability Video Output: Bounds : Left 0, Top 0, Width 1920, Height 1080 Default : Left 0, Top 0, Width 1920, Height 1080 Pixel Aspect: 1/1 Selection Video Output: compose, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_default, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_bounds, Left 0, Top 0, Width 1920, Height 1080, Flags: Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 [ 15.547696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.966015] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 . . . [ 26.968164] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968181] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968195] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968210] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.971188] mxc_isi.0: Not match format, set default [ 26.971199] mxc_isi.0: Not match format, set default [ 27.305025] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305150] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305352] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305392] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305442] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305507] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.309455] enter tc358748_s_power = ON [ 27.309471] tc358748 2-000e: tc358748_enable_hw [ 27.311682] tc358748 2-000e: tc358748_set_pad_format [ 27.311696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.311705] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.316716] bypass csc [ 27.316724] input fmt YUV4 [ 27.316728] output fmt YUYV [ 27.667770] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667876] tc358748 2-000e: tc358748_set_pad_format [ 27.667882] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667889] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.672900] bypass csc [ 27.672909] input fmt YUV4 [ 27.672912] output fmt YUYV [ 27.672922] enter tc358748_s_power = OFF [ 27.672929] tc358748 2-000e: tc358748_disable_hw [ 27.701511] enter tc358748_s_power = ON [ 27.701530] tc358748 2-000e: tc358748_enable_hw [ 27.703406] tc358748 2-000e: tc358748_set_pad_format [ 27.703418] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.703427] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.708440] bypass csc [ 27.708451] input fmt YUV4 [ 27.708456] output fmt YUYV [ 28.035292] tc358748 2-000e: [tc358748_stream,1152]: Stream enable ... [ 28.035309] tc358748 2-000e: tc358748_set_pll [ 28.035313] tc358748 2-000e: tc358748_calc_pll [ 28.035382] tc358748 2-000e: PLL: refclk 10000000, fbd 88, prd 0, frs 1 [ 28.035388] tc358748 2-000e: PLL: pll_clk: 445000000, CSIClk 222500000, CSIByteClk 55625000 [ 28.035393] tc358748 2-000e: PLL: pclk 74166666 (FPGA(Hardcode=>: 74250000MHz)) [ 28.037869] tc358748 2-000e: tc358748_sw_reset [ 28.038566] tc358748 2-000e: tc358748_apply_misc_config [ 28.038902] tc358748 2-000e: DATAFMT: 0x60 [ 28.039301] tc358748 2-000e: CONFCTL[PDATAF]: 0x0 [ 28.039642] tc358748 2-000e: FIFOCTL: 0x20 [ 28.039976] tc358748 2-000e: WORDCNT: 0xf00 [ 28.039984] tc358748 2-000e: tc358748_enable_csi_lanes: 1 [ 28.040454] tc358748 2-000e: CLW_CNTRL: 0 0x140 [ 28.040777] tc358748 2-000e: D0W_CNTRL: 0 0x144 [ 28.041158] tc358748 2-000e: D1W_CNTRL: 0 0x148 [ 28.041538] tc358748 2-000e: D2W_CNTRL: 0 0x14c [ 28.041899] tc358748 2-000e: D3W_CNTRL: 0 0x150 [ 28.041908] tc358748 2-000e: tc358748_apply_dphy_config [ 28.041912] tc358748 2-000e: dsiclk_nsk: 4494 [ 28.041916] tc358748 2-000e: ui_nsk: 2247 [ 28.041920] tc358748 2-000e: csibclk_nsk: 17977 [ 28.041924] tc358748 2-000e: phy_delay_nsk: 26965 [ 28.042278] tc358748 2-000e: LINEINITCNT: 0x15ba [ 28.042661] tc358748 2-000e: LPTXTIMECNT: 0x2 [ 28.043043] tc358748 2-000e: TCLK_HEADERCNT: 0xa03 [ 28.043456] tc358748 2-000e: TCLK_TRAILCNT: 0xffffffff [ 28.043803] tc358748 2-000e: THS_HEADERCNT: 0xffffee03 [ 28.044156] tc358748 2-000e: TWAKEUP: 0x49e0 [ 28.044535] tc358748 2-000e: TCLK_POSTCNT: 0x7 [ 28.044914] tc358748 2-000e: THS_TRAILCNT: 0x1 [ 28.045298] tc358748 2-000e: HSTXVREGEN: 0x1f [ 28.045307] tc358748 2-000e: tc358748_enable_csi_module: 1 [ 28.045680] tc358748 2-000e: STARTCNTRL: 0x1 [ 28.046025] tc358748 2-000e: CSI_START: 0x1 [ 28.046407] tc358748 2-000e: CSI_CONFW_REG: 2734719110 (0x518) [ 32.176687] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.176772] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.178272] tc358748 2-000e: [tc358748_stream,1152]: Stream disable ... [ 32.240654] enter tc358748_s_power = OFF [ 32.240673] tc358748 2-000e: tc358748_disable_hw [ 60.422080] imx-sdma 30bd0000.dma-controller: firmware found. [ 60.422080] imx-sdma 30e10000.dma-controller: firmware found. [ 60.422326] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 66.531400] cfg80211: failed to load regulatory.db i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Trouble with (TC358748) Parallel to CSI2 video bridge @shaswath 你解决这个问题了吗？如果可以的话，能否分享一下您的TC358748 内核驱动代码和最新的设备树文件？因为我也遇到了同样的问题。非常感谢！ Re: Trouble with (TC358748) Parallel to CSI2 video bridge 你不能随意选择格式，这取决于你的桥接端设置。检查你的 TC358748 寄存器，看看你在那里设置的是什么格式，然后选择 imx8mp 端的正确格式。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 你好， 很抱歉回复晚了。我按照您建议的格式使用了数据，现在可以看到一些数据，但正如您从附件示例中看到的那样。它还不完美。我尝试了不同的 MEDIA_BUS_FMT 和 V4L2_PIX_FMT，也尝试了不同的频率（23.98、50、60 等）。 MEDIA_BUS_FMT_YUYV8_1X16 / UYVY8_1X16 / 2X8。 V4L2_PIX_FMT_YUYV / UYVY / YUV422P。 但从 dmesg 日志中可以看到，有很多 CRC 错误。另外，我注意到从 media-ctl -p 中，除了桥接节点之外，其他节点都没有格式信息。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 或许你需要考虑一下格式。我检查了 CHNL_IMG_CTRL，它是 100000 字节的 YUV422_1P8P 格式，每个颜色元器件 8 位；单平面，YUV 交错打包字节。 https://github.com/nxp-imx/linux-imx/blob/lf-5.15.y/drivers/staging/media/imx/imx8-isi-fmt.c { 。姓名= "YUYV-16", .fourcc= V4L2_PIX_FMT_YUYV， 。深度= { 16 }, 。颜色= MXC_ISI_OUT_FMT_YUV422_1P8P， .memplanes= 1， .colplanes= 1， 。对齐= 3， .mbus_code= MEDIA_BUS_FMT_YUYV8_1X16， } 你应该从 ISI 选择此格式作为默认格式，并且也要检查你的桥接端。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 我检查了您的 dts 文件设置，TC358748 有 4 个数据通道，但日志文件只显示 1 个通道（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1），请再次检查。 --> 这只是为了指示函数调用，在该行下面您可以看到启用 4 个数据通道和 1 个时钟通道的这些行。 tc358748 2-000e：CLW_CNTRL：0 0x140 tc358748 2-000e：D0W_CNTRL：0 0x144 tc358748 2-000e：D1W_CNTRL：0 0x148 tc358748 2-000e：D2W_CNTRL：0 0x14c tc358748 2-000e：D3W_CNTRL：0 0x150 在你的 csi&isi dump.txt 文件中，[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(硬编码>: 74250000MHz)) 但在 gst-lauch-1.0.txt 中，[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) --> 我们使用 148.5MHz。 那么你究竟设定的是哪个时间呢？我查看了你的DTS文件，你设置了74.25M像素时钟，我建议你测量一下时钟频率，并设置hs-settle和clk-settle。 --> hs-settle 值是根据以下公式设置的：（像素速率 * 每像素位数）/（通道数 * 2），即 148.5 pixclk * 16bpp / 2 * 4 通道 = 475.2 MBits/s所以 RX_HS_SETTLE 为 10。 此外，我们板上的数据通道也互换了。修改之后，当我使用 Gstreamer 或 v4l2-ctl 用上市，不用发布视频捕获时，会出现绿屏。 gst-launch-1.0 -e \ v4l2src device=/dev/video3 ! \ 'video/x-raw,format=YUY2,width=1920,height=1080,framerate=60/1' ! \ videoconvert ! queue ! waylandsink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... ^Chandling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Got EOS from element "pipeline0". EOS received - stopping pipeline... Execution ended after 0:00:09.751003250 Setting pipeline to NULL ... Total showed frames (544), playing for (0:00:09.750853750), fps (55.790) Re: Trouble with (TC358748) Parallel to CSI2 video bridge 我检查了您的 dts 文件设置，TC358748 有 4 个数据通道，但日志文件只显示 1 个通道（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1），请再次检查。 在你的 csi&isi dump.txt 文件中，[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(硬编码>: 74250000MHz)) 但在 gst-lauch-1.0.txt 中，[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) 那么你究竟设定的是哪个时间呢？我查看了你的DTS文件，你设置了74.25M像素时钟，我建议你测量一下时钟频率，并设置hs-settle和clk-settle。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 你好@joanxie ， 是的，TC358748 的输入信号正常，我看到 TC358748 有信号输出。 要开始使用 GStreamer 进行捕获： gst-用上市，不用发布-1.0v4l2src 设备=/dev/video2 ！video/x-raw，宽度=1920，高度=1080！自动视频接收器 另一个问题是，当在 dts 中启用 ISI 节点时，系统会在几分钟后挂起。    Re: Trouble with (TC358748) Parallel to CSI2 video bridge 目前我无法使用 Gstreamer 或 v4l2-ctl 捕获任何帧。 您使用的是哪种 GStreamer 命令？您收到了什么消息？能否确认一下来自 TC358748 的信号是否完全正常？你检查过TC358748那边了吗？ Re: Trouble with (TC358748) Parallel to CSI2 video bridge 请查找他的注册表转储文件。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 从imx8mp这边来看，我没有发现任何问题，连接设置正确。 [ 7.992257] mx8-img-md：已注册传感器子设备：tc358748 2-000e (1) [ 8.002921] mx8-img-md：创建链接 [mxc_isi.0]=> [mxc_isi.0.捕获] [ 8.018980] mx8-img-md：创建链接 [mxc-mipi-csi2.0] [[ ## completed ##]]=> [mxc_isi.0] [ 8.025519] mx8-img-md: 创建链接 [tc358748 2-000e] => [mxc-mipi-csi2.0] [ 8.032634] mxc-md 32c00000.总线:camera:mxc_md_create_links 实际上，isi0 是为 mipi csi0 设计的，在 mipi csi0 中添加 port@1 后，当前的 电路板支持包 应该会出现一些错误，所以你是否更改了任何 mipi 驱动程序？但由于您的设置正确，这应该不会影响您的数据捕获。您可以检查 FPGA 端，确认其是否设置了正确的时钟或发送了正确的数据，并仔细检查 TC358748 的寄存器。此外，请导出 MIPI CSI 和 ISI 寄存器，以检查是否存在任何错误位。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 请查收附件。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 能否将日志文件和DTS文件发送给我？