Using the HiFi DSP for Inferencing ML Models on i.MX RT Devices This article will describe how to use the HiFi modules found on certain NXP microcontrollers as an optional method for inferencing a model.  There are several ways of running a TFLite neural network model on NXP microcontrollers: Inference a model only using the main core of the device (CM33 or M7) MCX N i.MX RT1050 i.MX RT1060 i.MX RT1170 i.MX RT1180 i.MX RT595 i.MX RT685 i.MX RT700 Inference a model directly on the HiFi4 or HiFi1 core (on supported platforms) i.MX RT595 i.MX RT685 i.MX RT700 Use the Neutron NPU to accelerate inference of a model - with the CM33 controlling the NPU and acting as a fallback for any non-NPU supported layers i.MX RT700 MCX N Use the Neutron NPU to accelerate inference of a model - with the HiFi4 controlling the NPU and acting as a fallback for any non-NPU supported layers i.MX RT700   This article will cover options #2 and #4 which make use of the HiFi DSP module. Running a model on the HiFi4 (option #2) will be much faster than running a model just on the CM33/M7 (option #1). However using the NPU (options #3 and #4) will be significantly faster than only using the DSP due to the hardware optimizations that an NPU provides for neural network calculations. The exact performance gains will be model specific, and also depend on the layer(s) that may not have been converted to use the NPU as NeutronGraph nodes. The accuracy should remain the very similar regardless of method being used. Any type of TFLite neural network model can be ran on the HiFi1/HiFi4 as those DSP modules are just being used accelerate the neural network math that the model uses. Below are the inference times of a CIFAR10 model on i.MX RT700 with different hardware modules used to inference the model (using default MCUXpresso SDK projects).  CM33: 103.653ms HiFi1*: 19.007ms HiFi4: 12.312ms NPU w/ CM33 Fallback: 0.883ms NPU w/ HiFi4 Fallback: 0.883ms *HiFi1 max frequency is 250MHz. All others are run at 325MHz.   Software requirements: Go to the Cadence i.MX RT700 or Cadence i.MX RT685 pages to download the following software. Xtensa Xplorer IDE License Key HIFI DSP Configuration File (NEWLIB) If using a HiFi4 example then download the HiFi4 license and DSP configuration files. Likewise, if using a HiFi1, then will need the HiFi1 license and DSP configuration files. Also you will need to download the Windows or Linux version of these files depending on which host OS you are using on your PC. Finally add the following global system variables which should be set based on the location that Xtensa Explorer was installed (assuming RT700 with HiFi4): XCC_DIR= \XtDevTools\install\tools\RI-2023.11-win32\XtensaTools XTENSA_CORE= rt700_hifi4_RI23_11_nlib MCUXpresso SDK HiFi ML Examples: There are several HiFi related examples in MCUXpresso SDK for i.MX RT700: tflm_cifar10 – Uses Neutron NPU to inference the CIFAR10 model and uses the CM33 as the fallback for any non-NPU operators. tflm_cifar10_hifi1 – Uses HiFi1 to inference the CIFAR10 model. Does not use the Neutron NPU tflm_cifar10_hifi4 – Uses HiFi4 to inference the CIFAR10 model. Does not use the Neutron NPU tflm_cifar10_hifi4_neutron – Uses Neutron NPU to inference the CIFAR10 model and uses the HiFi4 as the fallback for any non-NPU operators. tflm_label_image – Uses Neutron NPU to inference the CIFAR10 model and uses the CM33 as the fallback for any non-NPU operators. tflm_label_image_hifi4 - Uses HiFi4 to inference the Mobilenet model. Does not use the Neutron NPU When using the HiFi eIQ projects provided in MCUXpresso SDK, ensure that the SDK is: Located in a short filename path (ie C:\nxp\RT700), as an excessively long filename path can cause compile issues Directory path contains no spaces If using VS Code import as a Repository project instead of Free Standing. Ensure using at least MCUXPresso SDK 26.09 as there are several important fixes in the 26.09 release for HiFi4 projects HiFi4 with Neutron: If using the cifar10_hifi_neutron example and you want to change the model, then the model needs to be converted using the --target imxrt700 option for Neutron Compiler. The Neutron libraries then need to be updated using the files in the \target\imxrt700\rt700\hifi4\RJ-2025.5 folder and copied into mcuxsdk\middleware\eiq\neutron\rt700\hifi4 The Neutron libraries in the hifi\RI-2021.6 folder are provided to provide compatibility with an older version of the Xtensa tools and are not recommended for new designs. Extending Memory Area in HiFi4 Examples for Larger Models: Open:  Github SDK Layout: \mcuxsdk\examples\_boards\mimxrt700evk\eiq_examples\tflm_cifar10_hifi4_neutron\linker\hifi4\gdbio\ldscripts\elf32xtensa.x Classic SDK Layout: \boards\mimxrt700evk\eiq_examples\tflm_cifar10_hifi4_neutron\linker\hifi4\min-rt\ldscripts\elf32xtensa.x  And make modifications below to extend the memory used for models.  dsp_core_seg :  org = 0x20200000, len = 0x200000  dsp_core_ncache_seg :  org = 0x20400000, len = 0x180000    _memmap_mem_dsp_core_start = 0x20200000;  _memmap_mem_dsp_core_end   = 0x20580000;  _memmap_seg_dsp_core_start = 0x20200000;  _memmap_seg_dsp_core_max   = 0x20580000;     Ensure that the stack heap is at 0x2058_0000:    PROVIDE(__stack = 0x20580000);    _heap_sentry = 0x20580000;      Now larger models will compile successfully in Xtensa.    Then after copying in the compiled HiFi4 binary files into the MCUXpresso IDE project, modify dsp_config.h file to update the DSP_SRAM_ADDRESS:  Github SDK Layout: \mcuxsdk\examples\_boards\mimxrt700evk\eiq_examples\tflm_cifar10_hifi4_neutron\dsp_config.h  Classic SDK Layout:  \boards\mimxrt700evk\eiq_examples\tflm_cifar10_hifi4_neutron\cm33_core0\dsp_config.h (or source\dsp_config.h in MCUXpresso IDE)  Then clean and build the project.  Mlongcalls (MCUXpresso SDK 26.06 or earlier): In older MCUXpresso SDK versions there was a compiler issue where -mlongcalls needs to be used to avoid issues when adding additional operators to the operators list. This modification is no longer needed in MCUXpresso SDK 26.09 or later.  Inside \mcuxsdk\examples\_boards\mimxrt700evk\eiq_examples\tflm_cifar10_hifi4\hifi4 edit the reconfig.cmake file in the mcux_add_xtensa_configuration options: mcux_add_xtensa_configuration( CC "-DXOS_CLOCK_FREQ=237500000 -std=c99 -mlongcalls" CX "-stdlib=libc++ \ -mlongcalls \ -std=c++17" )  HiFi Lab: See the attached lab document for more details on using the HiFi DSP modules to inference models.    

How to Update eIQ Projects with the Latest eIQ Neutron SDK Libraries eIQ Neutron SDK is a new software package that includes the Neutron Compiler tool and eIQ Neutron libraries to run Neutron converted neural network models on devices that have an eIQ Neutron NPU like MCX N, i.MX RT700, or i.MX95 Previously the Neutron Compiler tool was part of eIQ Toolkit. However going forward, new versions of the Neutron Compiler tool will be released as part of the eIQ Neutron SDK. This change will allow for more frequent updates to provide better performance and additional operator support. The Neutron Compiler tool was previously named the Neutron Converter tool, but the name was changed in August 2026 with the release of eIQ Neutron SDK 3.2.1. The functionality is the same, just the name changed.  MCUXpresso SDK and Linux BSP use Neutron libraries as part of the eIQ examples included in those software releases. However to use the latest Neutron Compiler, an eIQ project will need to be updated to use the latest Neutron software libraries. This post walks through where to place the updated Neutron libraries and header files.  If the version of the Neutron Compiler tool that was used to convert a model does not match the Neutron libraries used by the eIQ project, then during inference you will see the following error(s) printed on the serial terminal and may get incorrect results: Microcode version mismatch Or Internal Neutron NPU driver error 281b in model prepare Or Incompatible Neutron NPU microcode and driver versions The version of the Neutron Compiler tool that was used to convert a model can be found by either viewing the converted model in Netron or by looking at the generated header file:   Here is a table showing where you can find the matching version of the Neutron Compiler tool for the default Neutron libraries found in different versions of MCUXpresso SDK: MCUXpresso SDK Default Neutron Library Version in MCUXpresso SDK Default Compatible Neutron Compiler/Converter Can Be Found In 24.12 1.2.0+0x6f710a6d eIQ Toolkit 1.17 25.03 1.2.0+0X1b86b19d eIQ Toolkit 1.17 25.06 2.0.2 eIQ Toolkit 1.17 25.09 2.1.3 eIQ Toolkit 1.17 25.12 2.2.2 eIQ Neutron SDK 2.2.2 26.03 3.0.0 eIQ Neutron SDK 3.0.0 26.06 3.1.1 eIQ Neutron SDK 3.1.1 26.09 3.2.2 eIQ Neutron SDK 3.2.2 Manually Update SDK Libraries To Use Latest Version eIQ Neutron SDK 3.2.3 Since Neutron library v3.2.0, the Neutron library used in a project can be determined with the neutronGetSdkVersion API: #include "NeutronDriver.h" NeutronSdkVersion version=neutronGetSdkVersion(); PRINTF("Neutron Library Version %d.%d.%d\r\n", version.major, version.minor, version.patch);   It is highly recommend to always use the latest Neutron Compiler tool and to update the libraries in your eIQ project to match the latest Neutron Compiler tool. The libraries can be updated by overwriting the original files. You may wish to make a backup first though as the default eIQ examples in that SDK will use models that were converted to match those original Neutron libraries. The Neutron file structure in eIQ Neutron SDK and MCUXpresso SDK are now the same so that the entire Neutron folder can be overwritten directly.  Updating Neutron Libraries in MCUXpresso SDK 25.12 and later: File Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\imxrt700\ rt700\cm33\ \middleware\eiq\neutron\rt700\cm33\ libNeutronFirmware.a target\imxrt700\ rt700\cm33\ \middleware\eiq\neutron\rt700\cm33\ NeutronDriver.h target\imxrt700\ driver\include\ \middleware\eiq\neutron\driver\include\ NeutronErrors.h target\imxrt700\ common\include\ \middleware\eiq\neutron\common\include\ Note: The target\imxrt700\driver\include\NeutronEnvConfig.h and the libraries in target\imxrt700\cmodel are used by the ExecuTorch inference engine and so are not needed for TFLM eIQ projects.  Note: If updating the HiFi4 Neutron libraries use the ones in the RJ-2025.5 folder Note: In MCUXpresso SDK 26.03 there are two sets of Neutron libraries in imported projects. It's the files in the /middleware/eiq folder that need to be updated.  Updating Neutron Libraries in MCUXpresso SDK 25.09 or before: File Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\imxrt700\ rt700\cm33\ \middleware\eiq\tensorflow-lite\third_party\neutron\rt700\ libNeutronFirmware.a target\imxrt700\ rt700\cm33\ \middleware\eiq\tensorflow-lite\third_party\neutron\rt700\ NeutronDriver.h target\imxrt700\ driver\include\ \middleware\eiq\tensorflow-lite\third_party\neutron\driver\include\ NeutronErrors.h target\imxrt700\ common\include\ \middleware\eiq\tensorflow-lite\third_party\neutron\common\include\ Updating Neutron Libraries for MCUXpresso SDK 2.16 or before: Replace the entire middleware\eiq directory from the latest MCUXpresso SDK release into your project, and then the Neutron libraries can be updated per the instructions above. In older MCUXpresso SDK releases there were additional eIQ changes beyond just the four files above, so the easiest method to update those older projects is just to replace the entire eIQ middleware directory.  Updating Neutron Libraries for i.MX devices: To update the neutron runtime on a target device, upload the files to their designated directories, as follows: File Target Directory NeutronFirmware.elf /lib/firmware libNeutronDriver.so /lib/ libneutron_delegate.so /lib/

Example MCAL S32K312 PIT ADC BTCU DS3.5 RTD300 * ============================================================================ * Detailed Description: * * The purpose of this demo application is to demonstrate the usage of the * ADC High-Level Driver (HLD) on the S32K312 MCU. * * The example uses PIT timers to periodically trigger BCTU conversion lists * through the TRGMUX. Each conversion list consists of five ADC channels. * Conversion results are stored in BCTU FIFOs and automatically transferred * by eDMA into result arrays. * * Trigger paths: * PIT0_CH0 -> TRGMUX -> BCTU Trigger 23 -> ADC0 (5 channels) * -> BCTU FIFO1 -> eDMA (ch0) * * PIT1_CH1 -> TRGMUX -> BCTU Trigger 47 -> ADC1 (5 channels) * -> BCTU FIFO2 -> eDMA (ch11) * * Converted results from the BCTU FIFOs are moved by eDMA into dedicated * ADC result buffers. * * ADC1 channel S10 is connected to the on-board potentiometer. The converted * value is used to adjust the brightness of the BLUE LED * * ============================================================================ * Test HW: S32K312-T172 * MCU: S32K312 * Compiler: S32DS 3.5.x * RTD release: S32K3_RTD_3_0_0 P07 * Debugger: On-Board Debugger * Target: Internal_FLASH * ============================================================================ I used these channels on --> S32K312-T172 eval board ADC results :-- ALso  be sure you enable freeze for both PITs :--  

すべての例：MCAL S32K312 DS3.5 RTD-3.0.0  ------------------------------------------------------------------------------ * テスト用ハードウェア：S32K3X4EVB-Q172 * MCU：S32K312 * コンパイラ： S32DS3.5 * SDKリリース：RTD 3.0.0 * デバッガ：PE Micro * ターゲット：internal_FLASH ******************************************************************************** 例：MCAL S32K312 MEM_InFls DS3.5 RTD300 例：MCAL S32K312 MEM_InFls DS3.5 RTD300 - NXPコミュニティ 例：MCAL S32K312 FEE DS3.5 RTD300：-- 例：MCAL S32K312 FEE DS3.5 RTD300 - NXPコミュニティ 例：MCAL S32K312 FEEとMEM_InFls DS3.5 RTD300：-- 例：MCAL S32K312 FEEとMEM_InFls DS3.5 RTD300 - NXPコミュニティ 例：MCAL S32K312 PWM ICU、カスタムIRQ EMIOS DS3.5 RTD300を使用：-- 例：MCAL S32K312 PWM ICU、EMIOS DS3.5 RTD300を使用 - NXPコミュニティ 例：ASR S32K312 EMIO PWM Generation & Dutyキャプチャ、Interrupt DS3.5 RTD300を使用：-- 例：ASR S32K312 EMIO PWM Generation & Dutyキャプチャ、Interrupt DS3.5 RTD300を使用 - NXPコミュニティ  例：ASR S32K312 EMIO PWM Generation & Dutyキャプチャ、Polling DS3.5 RTD300を使用：-- 例：ASR S32K312 EMIO PWM Generation & Dutyキャプチャ、Polling DS3.5 RTD300を使用 - NXPコミュニティ

所有示例 MCAL S32K312 DS3.5 RTD-3.0.0 ------------------------------------------------------------------------------ * 测试硬件：S32K3X4EVB-Q172 * MCU：S32K312 * 编译器：S32DS3.5 * SDK 发布：RTD 3.0.0 * 调试器：PE Micro * 目标：internal_FLASH ******************************************************************************** 示例 MCAL S32K312 MEM_InFls DS3.5 RTD300：-- 示例 MCAL S32K312 MEM_InFls DS3.5 RTD300 - NXP 社区 示例 MCAL S32K312 FEE DS3.5 RTD300：-- 示例 MCAL S32K312 FEE DS3.5 RTD300 - NXP 社区 示例 MCAL S32K312 FEE 和 MEM_InFls DS3.5 RTD300：-- 示例 MCAL S32K312 FEE 和 MEM_InFls DS3.5 RTD300 - NXP 社区 MCAL S32K312 PWM ICU 使用自定义 IRQ EMIOS DS3.5 RTD300 的示例：-- MCAL S32K312 PWM ICU 使用 EMIOS DS3.5 RTD300 的示例 - NXP 社区 示例 ASR S32K312 EMIO PWM 生成与占空比捕获使用中断 DS3.5 RTD300 :-- 示例 ASR S32K312 EMIO PWM 生成与占空比捕获使用中断 DS3.5 RTD300 - NXP 社区  示例 ASR S32K312 EMIO PWM 生成与占空比捕获使用轮询 DS3.5 RTD300 :-- 示例 ASR S32K312 EMIO PWM 生成与占空比捕获使用轮询 DS3.5 RTD300 - NXP 社区 回复：所有示例 MCAL S32K312 DS3.5 RTD-3.0.0 Pe Micro 调试工具在每次重新烧录固件时都会擦除 DataFlash，导致 EEPROM 数据损坏。 在调试配置中完成以下修改后，问题得以解决。

All Example MCAL S32K312 DS3.5 RTD-3.0.0  ------------------------------------------------------------------------------ * Test HW: S32K3X4EVB-Q172 * MCU: S32K312 * Compiler: S32DS3.5 * SDK release: RTD 3.0.0 * Debugger: PE Micro * Target: internal_FLASH ******************************************************************************** Example MCAL S32K312 MEM_InFls  DS3.5 RTD300 :-- Example MCAL S32K312 MEM_InFls DS3.5 RTD300 - NXP Community Example MCAL S32K312 FEE DS3.5 RTD300 :-- Example MCAL S32K312 FEE DS3.5 RTD300 - NXP Community Example MCAL S32K312 FEE and MEM_InFls DS3.5 RTD300 :-- Example MCAL S32K312 FEE and MEM_InFls DS3.5 RTD300 - NXP Community Example MCAL S32K312 PWM ICU using Custom IRQ EMIOS DS3.5 RTD300 :-- Example MCAL S32K312 PWM ICU using EMIOS DS3.5 RTD300 - NXP Community Example ASR S32K312 EMIO PWM Generation & Duty capture using Interrupt DS3.5 RTD300 :-- Example ASR S32K312 EMIO PWM Generation & Duty capture using Interrupt DS3.5 RTD300 - NXP Community  Example ASR S32K312 EMIO PWM Generation & Duty capture using Polling DS3.5 RTD300 :-- Example ASR S32K312 EMIO PWM Generation & Duty capture using Polling DS3.5 RTD300 - NXP Community Example MCAL S32K312 PIT ADC BTCU DS3.5 RTD300 :-- https://community.nxp.com/t5/S32K-Knowledge-Base/Example-MCAL-S32K312-PIT-ADC-BTCU-DS3-5-RTD300/ta-p/2424542 Re: All Example MCAL S32K312 DS3.5 RTD-3.0.0 Pe Micro use to delete the Dataflash, on every new FLashing of firmware, which corrupts the EEPROM data. After making this changes in debug configuration it worked..

[S32K396] eFlexPWM configuration issues MCU: S32K396 Driver: S32K3 RTD 7.0.1 Config tool: EB tresos Studio 30.0.0 Use case: 3-phase motor control (FOC), SM0..SM2 as complementary A/B pairs,20 kHz center-aligned PWM, fault handling on FAULT0  Question1: Pwm (FlexPWM): Fault settings are only available for the A output of a complementary channel pair — no way to configure the fault mapping of PWMB When a FlexPWM submodule is configured with Channel Pair = COMPLEMENTARY in the EB tresos Pwm plugin, only one channel entry (PWMA) is created and PWMB is automatically generated as the inverted output. However, in the fault settings (FlexPwmFaultChannelSettings: fault channel selection, fault level, fault output state, etc.) only the PWMA channel can be configured - there is no configuration entry for PWMB. The fault setup writes only the DIS0A field of SMx_DISMAP0. DIS0B and DIS0X keep their reset value 0xF and cannot be changed. Is there a supported way in EB tresos to configure the DIS0B/DIS0X mapping, or should this be considered a limitation/defect of the Pwm plugin? Question2: Pwm (FlexPWM): Center-aligned mode - no GUI option to generate an ADC trigger from a VAL0/VAL1 match (mid-point / reload trigger) (SM[x].TCTRL) We use center-aligned complementary PWM (SM0..SM2, 20 kHz) for 3-phase current sampling. In this configuration the center of the low-side conduction window coincides with the counter reload point, i.e. the VAL1 match. Sampling exactly at that instant gives the average phase current and maximum margin to the switching edges, which is the standard trigger point for low-side shunt FOC. In the EB tresos Pwm plugin, the per-channel Output Trigger configuration only offers "rising edge" / "falling edge" selections, which correspond to the VAL2/VAL3 match events. There is no option to enable the trigger sources tied to VAL0/VAL1 matches (TCTRL[OUT_TRIG_EN] bits for OUT_TRIG0/OUT_TRIG1 based on VAL0/VAL1), and no option tied to the reload event. Is there a supported way in this RTD release to generate an ADC trigger from the VAL0/VAL1 match (or from the reload event) in center-aligned mode? Questions3:Pwm (FlexPWM): Fault notification function configured in EB is generated as NULL_PTR in the PostBuild configuration In the EB tresos Pwm plugin, under FlexPwmFaultChannelSettings, a fault notification function name can be entered. The expectation is that the generated PostBuild configuration fills the callback member so that FlexPwm_Ip_Init() registers it into FlexPwm_Ip_aFaultIrqCallback[], and the fault ISR (FlexPwm_Ip_ProcessFaultIrq) calls it when FFLAG is set. But FlexPwm_Ip_VS_0_PBcfg.c generates the fault channel configuration with NULL_PTR. Is this a known limitation of the Pwm plugin, or a defect? Re: [S32K396] eFlexPWM configuration issues Hi, Q1 – Fault mapping for complementary PWMA/PWMB For a complementary channel pair, only PWMA is configured and PWMB is generated according to the configured A/B relationship.  The Pwm configuration provides individual fault enable settings through FlexPwmChannelFaultSettings. However, when complementary mode is selected, PWMB is no longer available as a separate configurable channel, so there is no corresponding GUI option to customize its DIS0B fault mapping. With the default DISMAP reset configuration, the fault inputs remain enabled for the output. Therefore, from the application point of view, the required fault protection is preserved with the default configuration. I will nevertheless check with the RTD team whether the inability to separately configure DIS0B/DIS0X in complementary mode is intentional and whether there is a supported method for applications requiring a different fault mapping. Q2 – ADC trigger in center-aligned PWM mode The Pwm configuration allows the trigger source to be selected from PWMX, PWMA or PWMB, together with rising edge, falling edge or both edge selection. For center-aligned PWM, VAL1 determines the PWM period and therefore cannot be freely adjusted to move the ADC sampling point. There are several possibilities depending on the required sampling point: If sampling exactly at the PWM reload point is required, the FlexPWM reload pulse is directly available as a TRGMUX trigger source and can be routed through TRGMUX to BCTU/ADC. If local synchronization using PWMX and its VAL0/VAL1 resources is not required for the submodule, PWMX can be configured and used for ADC triggering through the standard Pwm trigger configuration. If the sampling point needs to be independently adjusted relative to the PWM center, a free VALx comparator can be configured through the FlexPWM IP APIs and used as an output trigger. Therefore, the preferred solution depends on whether the ADC sampling point needs to be fixed at the PWM reload point or independently adjustable relative to it. Q3 – Fault notification generated as NULL_PTR According to the Pwm User Manual, FlexPwmFaultNotification specifies the user callback function for fault detection, and a configured value different from NULL or NULL_PTR should be used as the callback function name.   I also tested this with RTD 7.0.1 using the S32 Design Studio configuration tool. In this case, the configured fault notification is correctly propagated into FlexPwm_Ip_VS_0_PBcfg.c, including the callback prototype and the corresponding entry in the FaultNotification[] array.   However, I have not yet verified the same configuration using EB tresos Studio 30.0.0. Therefore, I will check with the RTD team whether there is any known difference or limitation in the EB tresos generation path that could result in NULL_PTR being generated instead. BR, Petr 回复： [S32K396] eFlexPWM configuration issues I have also further questions as bellow: Q1.I would like to follow up on this statement: "With the default DISMAP reset configuration, the fault inputs remain enabled for the output. Therefore, from the application point of view, the required fault protection is preserved with the default configuration." This holds only if all four fault inputs are actually routed on the board. In our ECU only FAULT0 is connected (it carries the FS_FLAG of the gate driver, ST L9908). FAULT1..FAULT3 are not routed at all, so those pads are left floating / not configured as Port pins, and the IMCR does not route them - the fault inputs read a constant level. Since DISMAP0 resets to 0xFFFF (every fault input mapped to every output), the consequence is: --With FLVL = LOW for the unrouted channels, the constant low level is interpreted as a permanent fault and the outputs stay disabled forever. - With FLVL = HIGH for the unrouted channels, those fault channels are permanently inactive, but they are still mapped onto the A/B/X outputs. Therefore, we have to manually update the DISMAP0 register after 'Pwm_Init()', so that only FAULT0 is mapped to DIS0A / DIS0B / DIS0X. Whether the DIS0A/DIS0B/DIS0X fields can be exposed in the GUI for complementary mode (so that A and B can be mapped independently)?  Q2.  option1(FlexPWM reload pulse as a TRGMUX trigger source): We confirmed that TRGMUX_IP_INPUT_PWM0_MST_RELOAD is available. option2(PWMX for ADC triggering): This is actually the path we tried first, before opening this thread: we wanted a PWMX falling edge aligned to VAL1. But when Channel Pair = COMPLEMENTARY is selected, the EB tresos Pwm plugin does not allow creating a PWMX channel container for that submodule at all, so the trigger source PWMX cannot be selected. Could you confirm whether this restriction in the plugin is intentional, and whether PWMX-based triggering is supposed to be usable in complementary mode? If it is a plugin limitation, it would be worth reporting to the EB plugin team as well. Thanks again for the detailed answer. Re: [S32K396] eFlexPWM configuration issues Thank you for your response, and wait for your confirmation from RTD team.

PN7642EV/C100 与 PN7642EV/C102 第一个问题，我计划在新设计中使用PN7642EV/C102。我想添加PN7642EV/C100作为备选方案，因为它在主流代理商处有现货，可以减少潜在的长期供应链问题。在我看来，这两个PN7642EV/C100之间的唯一区别在于它们出厂时预装的固件版本。如果真是这样，那么安装PN7642EV/C100并更新到最新固件就相当于安装PN7642EV/C102并更新到最新固件。我的理解是否正确？ 第二个问题，对于此应用，我们将读取基本的 NFC 标签、Google 钱包和 Apple 钱包。我知道读取 Google 和 Apple 钱包需要很多认证和权限，但就硬件而言，C100 和 C102 型号是否能够做到这一点？ Re: PN7642EV/C100 vs PN7642EV/C102 你好@adamdoyle15 希望你一切都好。 PN7642 应具备 ECP 功能。另外，正如您所提到的，这些版本之间的主要区别在于C102出厂时预装了固件版本3.00。 问候， 爱德华多。 Re: PN7642EV/C100 vs PN7642EV/C102 您好， ECP 支持主要通过软件实现；硬件版本之间不应有区别。 问候， 爱德华多。 Re: PN7642EV/C100 vs PN7642EV/C102 感谢您的快速回复。 关于 ECP 功能，我从数据表中看到 PN7642 具备 ECP 功能，但我的问题是，从硬件角度来看，这是否足以兼容苹果钱包。

VCU controller hangs for 110 seconds and then recovers when using s32k312 MCU Dear NXP Technical Support, We have recently been using the S32K312 MCU, and we encountered a strange issue when using DFlash to emulate EEPROM for data read/write: the controller occasionally hangs for 110 seconds and then recovers. We currently suspect that during flash erase or write, for some unknown reason, Fls_GetJobResult is unable to update to the correct status for a long time (we use the following method to wait for the erase/write status): c do { Fls_MainFunction(); Fls_JobResult = Fls_GetJobResult(); } while (Fls_JobResult == MEMIF_JOB_PENDING); Because this occurs in a vehicle and is very sporadic, we cannot capture the exception through debugging. We would like to ask whether you have any good suggestions. Or has anyone else encountered a similar issue where a flash erase/write call hangs? We look forward to your reply. Re: VCU controller hangs for 110 seconds and then recovers when using s32k312 MCU Hi@zhaoning I have found an issue that may be similar to the one you are currently experiencing. https://community.nxp.com/t5/S32K/long-Fee-cluster-swap-times/m-p/1951280#M40791 Based on the information provided, we cannot yet pinpoint the exact cause of the problem; however, you could start your investigation by looking into "Cluster Swap."

PN7642EV/C100 vs PN7642EV/C102 First question, I am planning to use PN7642EV/C102 in a new design. I would like to add PN7642EV/C100 as an alternate part since it is in stock at main stream distributors and to reduce potential long term supply chain issues. It looks to me like the only difference between these PNs is the FW version they are shipped with. If this is the case then populating PN7642EV/C100 and updating to the latest FW is equivalent to doing the same with PN7642EV/C102. Is this an accurate assumption? Second question, for this application we will be reading basic NFC tags, Google wallet and Apple wallet. I understand there are many certifications and permissions needed to read Google and Apple wallets but as far as the HW is concerned are the C100 and C102 variants capable of doing this? Re: PN7642EV/C100 vs PN7642EV/C102 Thank you for the quick response. Wrt the ECP capability, I can see from the datasheet that the PN7642 is ECP capable but my question is whether or not, from a hardware perspective, this is sufficient for apple wallet compatibility. Re: PN7642EV/C100 vs PN7642EV/C102 Hello @adamdoyle15 Hope you are doing well. PN7642 should be ECP capable. Also, as you mention, the main difference between those variants is that C102 comes out of the box with FW v3.00.  Regards, Eduardo. Re: PN7642EV/C100 vs PN7642EV/C102 Hi, ECP support is mainly done in software; there should be no distinction between HW variants. Regards, Eduardo.

PNEV7642A Rev B board hello, i am thinking of buying PNEV7642A Revision B evaluation board. but do not find any link or page for this product, please can you provide me with a link for buying this board  also when searching the NFC library for this board i did found a NFC Reader Library for PN7462 not for PN7642. does this library support both targets ?? thanks.    Development Board Re: PNEV7642A Rev B board The board is : OM27642: Development Kit for PN7642 Secure Compact NFC Controller with Programmable Memory and Crypto Accelerationemory and crypto Acceleration | NXP Semiconductors You could download the PN7642 SDK from here: Best-in-Class NFC Frontend with Integrated MCU | NXP Semiconductors Re: PNEV7642A Rev B board @jimmychan  thanks for reply, can you tell me what debugger i can use with this development kit (OM27642EVK )?? can i use MCU-Link Debug Probe or PEmicro’s Multilink Universal as programmer/debugger?? please note that MCU-Link does not mention pn7642 as a supported IC here in this link  MCU Link thanks.

[S32K396] eFlexPWMの設定に関する問題 MCU:S32K396 ドライバ:S32K3 RTD 7.0.1 設定ツール：EB tresos Studio 30.0.0 ユースケース:3相モーター制御(FOC)、SM0など。SM2を補完的なA/Bペアとして、20 kHzのセンターアラインドPWM、FAULT0の故障処理 質問1:Pwm(FlexPWM):補完チャネルペアのA出力のみにフォールト設定が可能で、PWMBのフォールトマッピングを設定する方法はありません FlexPWMサブモジュールがチャネルペア=補完的な設定の場合 EB tresos Pwmプラグインは、チャネルエントリ(PWMA)が1つだけ作成され、PWMBは 反転出力として自動生成されます。しかし、故障設定では (FlexPwmFaultChannelSettings: 故障チャネル選択、故障レベル、故障出力 状態など)PWMAチャネルのみを設定可能で、設定は存在しません PWMBのエントリー。障害設定では、SMx_DISMAP0のDIS0Aフィールドのみに書き込みます。 DIS0BとDIS0Xはリセット値を保持し0xF、変更できません。 EB tresosでDIS0B/DIS0Xマッピングを設定するサポートされている方法はありますか？ それともこれはPWMプラグインの制限事項／欠陥と考えるべきでしょうか？ 質問2：PWM（FlexPWM）：中央揃えモード - VAL0/VAL1の一致（中間点/リロードトリガー）からADCトリガーを生成するGUIオプションはありません（SM[x].TCTRL） 3相電流にはセンターアライメント相補PWM(SM0..SM2、20 kHz)を使用しています サンプリング。この構成では、低側伝導窓の中心は カウンターの再ロードポイント、つまりVAL1の一致と一致する。正確にサンプリングする その瞬間、平均位相電流と最大余裕が与えられ、 スイッチングエッジは、ローサイドシャントFOCの標準的なトリガーポイントです。 EB tresos Pwmプラグインでは、チャネルごとの出力トリガー設定のみです 「ライジングエッジ」/「フォーリングエッジ」の選択肢を提供し、これらは VAL2/VAL3のマッチイベント情報。トリガーソースをタイドするオプションはありません VAL0/VAL1のマッチング(OUT_TRIG0/OUT_TRIG1のTCTRL[OUT_TRIG_EN]ビットは VAL0/VAL1)、リロードイベントに紐づくオプションもありません。 このRTDリリースで、ADCトリガーを生成するサポート方法はありますか? VAL0/VAL1のマッチ(またはリロードイベント情報からのセンターアライメントモード)? 質問3：PWM（FlexPWM）：EBで設定された障害通知機能がPostBuild構成でNULL_PTRとして生成される EB tresos PwmプラグインのFlexPwmFaultChannelSettingsの中に、 通知関数名を入力できます。期待値として、 生成されたPostBuild構成はコールバックメンバーを埋め、 FlexPwm_Ip_Init()はそれをFlexPwm_Ip_aFaultIrqCallback[]に登録し、 フォルトISR(FlexPwm_Ip_ProcessFaultIrq)はFFLAGが設定されたときにこれを呼び出します。しかしFlexPwm_Ip_VS_0_PBcfg.cはNULL_PTRでフォルトチャネル構成を生成します。 これはPWMプラグインの既知の制限事項ですか、それとも不具合ですか？ Re: [S32K396] eFlexPWM configuration issues こんにちは、 Q1 – 補完的なPWMA/PWMBの故障マッピング 補完的なチャネルペアの場合、PWMAのみが設定され、PWMBは設定されたA/B関係に基づいて生成されます。 PWM構成では、FlexPwmChannelFaultSettingsを通じて個別の障害有効化設定を提供します。しかし、補完モードを選択するとPWMBは別の設定可能なチャネルとして利用できなくなり、DIS0Bの故障マッピングをカスタマイズする対応するGUIオプションはありません。 デフォルトのDISMAPリセット設定では、出力に対する障害入力は有効なままになります。したがって、アプリケーションの観点からは、デフォルトの構成でも必要な故障保護が維持されます。 それでも、DIS0B/DIS0Xを補完モードで個別に設定できないのは意図的なものか、また異なる故障マッピングを必要とするアプリケーションに対応した方法があるか、RTDチームに確認してみます。 Q2 – センターアライメントPWMモードでのADCトリガー PWM設定では、トリガーソースとしてPWMX、PWMA、PWMBから選択できるほか、立ち上がりエッジ、立ち下がりエッジ、または両方のエッジを選択できます。 センターアライメントPWMの場合、VAL1はPWM周期を決定するため、ADCサンプリングポイントを自由に移動させることはできません。 必要なサンプリングポイントに応じて、いくつかの可能性が考えられます。 PWMリロードポイントで正確にサンプリングが必要な場合、FlexPWMリロードパルスはTRGMUXトリガーソースとして直接利用可能で、TRGMUX経由でBCTU/ADCへルーティングできます。 サブモジュールでPWMXおよびそのVAL0/VAL1リソースを用いたローカル同期が不要な場合、PWMXは標準のPWMトリガー構成を通じてADCトリガに設定・使用可能です。 サンプリングポイントをPWMセンターに対して独立に調整する必要がある場合は、FlexPWM IP APIを通じて自由なVALxコンパレータを設定し、出力トリガーとして使用できます。 したがって、最適な解決策は、ADCのサンプリングポイントをPWMのリロードポイントに固定する必要があるか、それともそれに対して独立して調整可能である必要があるかによって異なります。 Q3 – NULL_PTRとして生成された故障通知 Pwmユーザーマニュアルによると、FlexPwmFaultNotificationは故障検出用のユーザーコールバック関数を指定しており、NULLやNULL_PTRとは異なる設定値がコールバック関数名として使用されるべきです。   また、S32 Design Studioの設定ツールを使ってRTD 7.0.1でもテストしました。この場合、設定されたフォールト通知は正しくFlexPwm_Ip_VS_0_PBcfg.cに伝播され、コールバックプロトタイプやFaultNotification[]配列内の対応するエントリも含まれます。   しかし、まだEB Tresos Studio 30.0.0を使って同じ構成を確認できていません。したがって、RTDチームにEB Tresosの生成パスにNULL_PTRが生成される可能性のある既知の違いや制限がないか確認します 。 BR、ペトル Re: [S32K396] eFlexPWM configuration issues ご回答ありがとうございます。RTDチームからの確認をお待ちください。 回复： [S32K396] eFlexPWM configuration issues 以下にさらに質問があります。 Q1。この発言について続けておきたいと思います。 「デフォルトのDISMAPリセット構成では、故障入力は出力に対して有効化されたままです。したがって、アプリケーションの観点からは、デフォルトの構成でも必要な故障保護が維持されます。」 これは、4つの障害入力すべてが実際に基板上に配線されている場合にのみ当てはまります。私たちのECUではFAULT0のみがコネクテッドであり(ゲートドライバのST L9908のFS_FLAGを承載しています)。FAULT1..FAULT3は全くルーティングされておらず、これらのパッドは浮動したままポートピンとして設定されておらず、IMCRもルーティングしません。フォールト入力は一定レベルを読み取ります。 DISMAP0 は0xFFFF(すべての故障入力がすべての出力にマッピングされる)にリセットされるため、結果は次のようになります。 --未ルーティングチャネルのFLVL = LOWの場合、一定の低レベルは恒久的な故障と解釈され、出力は永遠に無効化されたままです。 - 未ルーティングチャネルのFLVL = HIGHの場合、これらの故障チャネルは永久に非アクティブですが、A/B/X出力にはマッピングされます。 したがって、「Pwm_Init()」の後に手動でDISMAP0レジスタを更新し、FAULT0のみをDIS0A / DIS0B / DIS0Xにマッピングします。 DIS0A/DIS0B/DIS0XフィールドをGUIで補完モードとして公開できるかどうか(AとBを独立してマッピングできる)、 Q2。 option1(TRGMUXトリガーソースとしてのFlexPWMリロードパルス):TRGMUX_IP_INPUT_PWM0_MST_RELOADが利用可能であることを確認しました。 option2(PWMX for ADC triggering):実はこのThreadを開く前に最初に試した経路です:PWMXの落ち込みエッジをVAL1に合わせたかったのです。しかし、チャネル Pair = COMPLEMENTARYを選択すると、EB tresos Pwmプラグインはそのサブモジュール用のPWMXチャネルコンテナを作成することを一切許可せず、トリガーソースPWMXを選択することはできません。 プラグイン内のこの制限は意図的なものか、またPWMXベースのトリガーは補完モードで使えるものなのか確認していただけますか?もしそれがプラグインの制限によるものであれば、EBプラグインチームにも報告する価値があるでしょう。 詳細なご回答をありがとうございました。

BMA7426TBユーザーマニュアルおよび こんにちは、 BMA7426TB AFEを使用して燃料電池の電圧を監視したい。しかし、長いデータシートがなく、長いデータシートやユーザーマニュアル、そして助けが必要です。 1.バランス機能が不要なら、CBxのピンはどのようにコネクテッドすればよいのでしょうか?フローティングしているのか、それともセルにコネクテッドしなければならないのか? 2. もしCBxをセルにコネクテッドする必要がある場合、このピンは短時間-3Vに耐えられるのか?(<1秒) 3. 電源ピンVBATおよびVBATSWを24V DC/DCのような絶縁されたDC/DCにコネクテッドできるか。 ありがとうございます。 Re: BMA7426TB user manual and こんにちは、 BMA7426xBの完全なデータシートおよびリファレンスマニュアルは以下で入手可能です: https://www.nxp.com/products/BMA742X これらは機密文書であり、秘密保持契約（NDA）の締結が必要となることにご注意ください。 https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS これらの文書には、あなたの質問に対する回答が記載されています。 BRs、トーマス

i.MX7D UART5 in DTE mode using I2C4 Hi. This is the original i.MX7D board. The 2-wire UART5 circuit uses the I2C4 port. This UART5 is in DTE mode. I am configuring the CCM, IOMUXC ports, IOMUXC DAISY settings, and UART5. CCM_TARGET_ROOTn=0x10000000 CCM_CCGRn=0x3 IOMUXC_SW_MUX_CTL_PAD_I2C4_SCL=1 IOMUXC_SW_MUX_CTL_PAD_I2C4_SDA=1 IOMUXC_UART5_RX_DATA_SELECT_INPUT=1 UART5_UCR1=1 UART5_UCR2=0x7027 UART5_UCR3=0x784 UART5_UCR4=0x8000 UART5_UFCR=0x240 UART5_UBIR=0xF UART5_UBMR=0x271 After sending one character, UART5_UTS remains at 0x20 (having changed from 0x60). I do not know why UART5_UTS does not return to 0x60. Best Regards. Re: i.MX7D UART5 in DTE mode using I2C4 Spoiler (Highlight to read)     Hi. AldoG. There was an error in a portion of the information I sent. UART5_CLK_ROOT(0x30380b18)=0x10000000 The correct version is as follows. UART5_CLK_ROOT(0x3038b180)=0x10000000 Best regards. Re: i.MX7D UART5 in DTE mode using I2C4 Hi. AldoG. Upon startup, for some reason IPG_CLK_ROOT (0x30389080) was set to 0x1, so I changed it to 0x0. UART5_CLK_ROOT(0x30380b18)=0x10000000 UART5_CCM_CCGR=CCM_CCGR152(0x30384980)=0x3 It has been set up this way. I tried changing the pins used from I2C4 to SAI1, but the result was unsuccessful. I set the register to be checked to TXDC within USR2. Best regards. Re: i.MX7D UART5 in DTE mode using I2C4 Hello, For the i.MX7D UART status register, UTS[6] is the TX FIFO empty indication and UTS[5] is the RX FIFO empty indication. Therefore, 0x60 indicates that both FIFOs are empty, while 0x20 indicates that the RX FIFO is empty but the TX FIFO is not yet empty. Seeing 0x20 immediately after writing a character can therefore be expected. UTS[6] only reflects the FIFO state. If you need to determine when the character has completely finished transmitting, check USR2[TXDC], which indicates that the transmit FIFO and shift register are empty. For this two-wire configuration, please also verify the following: Hardware CTS/RTS flow control is disabled. If CTS/RTS is enabled without the corresponding signals being connected, transmission may be prevented. Both the UART5 functional clock and the IPG clock are enabled, and the UBIR/UBMR values are calculated using the actual UART5 clock frequency. The DTE pin mapping is checked against the i.MX7D Reference Manual. DTE mode changes the apparent RX/TX pin direction, so the signal names can be confusing. The I2C4 peripheral is not also enabled or driving the same pads. The UART5 TX pin is probed with an oscilloscope or logic analyzer. If a valid waveform is present, the 0x20 reading is likely only a status-sampling issue. If no waveform is present, check the clock, flow-control, and pin-mux configuration first. Please refer to the i.MX 7Dual Reference Manual (IMX7DRM), especially the UART and IOMUX sections. The NXP discussions iMX7 UART pin setup and i.MX7 IPG_CLK_ROOT and UART's clock may also be useful. Best regards/Saludos, Aldo. Re: i.MX7D UART5 in DTE mode using I2C4 Hello, TXDC indicates that the TX FIFO and shift register are empty. Please check whether USR2[TXDC] becomes 1 after the character is sent. If it remains 0, please also capture the UTS, USR1, and USR2 values before and after transmission, together with the UART5 TX pin waveform. For the two-wire configuration, please also verify that hardware CTS/RTS flow control is disabled. If CTS/RTS is enabled without the corresponding signals being connected, the transmitter may remain blocked. Also confirm that no I2C4 or SAI1 peripheral remains enabled and driving the selected pads. Best regards/Saludos, Aldo. Re: i.MX7D UART5 in DTE mode using I2C4 Hi AldoG, To avoid confusion caused by DTE mode, I modified the board wiring to set it to DCE mode. After initialization in U-Boot, I used an oscilloscope to monitor the pin voltage levels while toggling the IOMUXC pull-up/pull-down settings. The input pins responded correctly to these configuration changes. Next, I set the DTE bit in the UART5_UFCR register and repeated the test; the input pins again responded correctly to the configuration changes. The output pins switch according to the DCE/DTE configuration, and in both cases, the voltage level is '1'. Therefore, the PAD configuration is correct. Since the IRTS bit in the UART5_UCR2 register is set to '1', the RTS signal should be ignored. Could you please provide specific, detailed support on what I should investigate next to resolve this issue? Best regards. Re: i.MX7D UART5 in DTE mode using I2C4 Hi AldoG. The issue has been resolved. I have reverted from the 2-wire DCE mode to the 3-wire DTE mode. The pins used are I2C3_SCL, I2C4_SCL, and I2C4_SDA. The clock is configured via the CCM in `/arch/arm/mach-imx/mx7/clock.c` within the `init_clk_uart()` function. The pin configuration is as follows: static iomux_v3_cfg_t const uart5_pads[] = { MX7D_PAD_I2C3_SCL__UART5_DTE_RTS | MUX_PAD_CTRL(UART_PAD_CTRL), MX7D_PAD_I2C4_SCL__UART5_DTE_TX | MUX_PAD_CTRL(UART_PAD_CTRL), MX7D_PAD_I2C4_SDA__UART5_DTE_RX | MUX_PAD_CTRL(UART_PAD_CTRL), }; imx_iomux_v3_setup_multiple_pads(uart5_pads, ARRAY_SIZE(uart5_pads)); writel(readl(0x30330158) | 0x10, 0x30330158); writel(readl(0x30330160) | 0x10, 0x30330160); writel(readl(0x30330164) | 0x10, 0x30330164); writel(0, 0x30330710); writel(0, 0x30330714); Next, I will proceed with serial initialization and baud rate configuration, using `serial_mx.c` as a reference. However, the UCR2 register will be configured as follows: writel(UCR2_WS | UCR2_TXEN | UCR2_RXEN | UCR2_SRST, &base->cr2); This worked.

imx8mmevk ov5640 mediactl こんにちは、 mediactlを以下のように使用しようとしています。 Linux imx8mmevk 6.6.52-lts-next-g90192c5d29cb#1 SMP PREEMPT 2025年7月8日火曜日 12:00:06 UTC aarch64 GNU/Linux mipe cam ov5640 を使用。 カメラはGstreamerとPipewireで使えますが、Mediactlは使えません。 dmsegログはこちらです。 DMESG |グレップov5640_mipi [ 0.059215] プラットフォーム32e30000.mipi_csi:/soc@0/bus@30800000/i2c@30a40000/ov5640_mipi@3cの固定依存サイクル [ 2.409821 ov5640_mipi 2-003c: センサーリセットピンなし [ 2.415630] ov5640_mipi 2-003c: ダミーレギュレーター使用中の供給DOVDDが見つかりません [ 2.422901] ov5640_mipi 2-003c: ダミーレギュレーター使用でDVDを供給できません [ 2.429995] ov5640_mipi 2-003c: ダミーレギュレーター使用で供給AVDDが見つからない [ 2.446514] ov5640_mipi 2-003c: レジグエラーを読み込み:reg=300a [ 2.451845] ov5640_mipi 2-003c: カメラは見つかりません そしてmediactlの出力： media-ctl -p /dev/media0 (-2) を列挙できませんでした デバイスでメディアクトルを使うのを手伝ってもらえますか? どうもありがとう Re: imx8mmevk ov5640 mediactl こんにちは、 これらのエラーにもかかわらず、カメラがGStreamerとPipeWireで動作するとおっしゃったのは興味深いですね。 ov5640_mipi 2-003c: Read reg error: reg=300a ov5640_mipi 2-003c: Camera is not found 通常、センサードライバーがプローブに失敗した場合、対応するV4L2サブデバイスは正常に登録されず、期待されるカメラパイプラインが完全に利用可能でないはずです。 あなたのログを踏まえると、まず最初に調べるべきは、OV5640センサードライバーが実際にプローブに成功しているか、そして両方のケースで同じカメラデバイスを使っているかどうかです。 それが問題でなければ、メディアコントローラのインターフェースが有効でサポートされているか確認しましたか?「/dev/media0 を列挙できません」というエラーは、/dev/media0が見つからないことを示しています。メディアコントローラデバイスの利用可能性はカーネルの設定とドライバの実装に依存します。 より具体的なサポートが必要な場合は、以下を共有してください。 - 動画のキャプチャに成功したGStreamerパイプライン。 - 関連するOV5640デバイスツリー構成。 - NXP BSPカメラドライバーを使用している場合でも、修正・カスタム実装を使用している場合もあります。 よろしくお願いいたします。 カロリーナ・トレホス RidgeRunの組み込みソフトウェアエンジニア Re: imx8mmevk ov5640 mediactl こんにちは 、 私はnxp bspドライバでこのパイプラインを使っています: root@imx8mmevk:~# gst-launch-1.0-v v4l2src device=/dev/video0 !video/x-raw、format=YUY2、width=1280、height=720、framerate=30/1 !vpuenc_h264 !h264parse !rtph264pay pt=96 config-interval=1 !udpsink host=10.49.24.30 port=5000 sync=false root@imx8mmevk:~# DMESG |グレップov5640_mipi [ 0.059279] プラットフォーム 32e30000.mipi_csi:/soc@0/bus@30800000/i2c@30a40000/ov5640_mipi@3cの固定依存サイクル [ 2.405481 ov5640_mipi 2-003c: センサーリセットピンなし [ 2.411300] ov5640_mipi 2-003c: 供給DOVDDが見つからず、ダミーレギュレーターを使用 [ 2.418588] ov5640_mipi 2-003c: ダミーレギュレーター使用で供給DVD(未確認) [ 2.425685] ov5640_mipi 2-003c: ダミーレギュレーター使用中、供給AVDDが見つからない [ 3.057823] mxc_mipi-CSI 32e30000.mipi_csi:登録センサーサブデバイス:ov5640_mipi 2-003c [ 3.067382 ov5640_mipi 2-003c: カメラ発見 エラーメッセージが消えました！ dtsi : ov5640_mipi: ov5640_mipi@3c { 互換性 = "ovti,ov5640_mipi"; reg =<0x3c> �; ステータス = "正常"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_csi_pwn>, <&pinctrl_csi_rst>; クロック = <&clk IMX8MM_CLK_CLKO1>; クロック名 = "csi_mclk"; 割り当てられたクロック = <&clk IMX8MM_CLK_CLKO1>; 割り当てられたクロックの親要素 = <&clk IMX8MM_CLK_24M>; <24000000><0> <24000000> 割り当てられたクロックレート<0> =; csi_id =; pwn-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>; mclk =; mclk_source =; ポート { ov5640_mipi1_ep: エンドポイント { リモートエンドポイント = <&mipi1_sensor_ep>; }; }; }; }; media-ctl -p /dev/media0 (-2) を列挙できませんでした 手伝ってくれてありがとう Re: imx8mmevk ov5640 mediactl こんにちは、@Thierry49_49 お元気でお過ごしのことと思います。 ログによると、センサはアドレス0x3cのI2Cバス2上にあります。ストリーミングが停止したら、以下を確認してください。 i2cdetect -y 2 i2ctransfer -y 2 w2@0x3c 0x30 0x0a r1 i2ctransfer -y 2 w2@0x3c 0x30 0x0b r1 期待されるチップIDがログに記録されるはずです。 また、アクティブなドライバの確認も以下の通りです: v4l2-ctl --list-devices readlink -f /sys/class/video4linux/video0/device/driver dmesg | grep -Ei 'mxc_md|mx8-img-md|imx7-csi|mxc_mipi|mx6s' 出力がmxc_mipi-csiとmx6s_captureのみを表示する場合、media-ctlはこのキャプチャパスで使用できません。 よろしくお願いいたします。 サラス。 Re: imx8mmevk ov5640 mediactl こんにちは ~@Manuel_Salas ありがとう、私は元気です。あなたは？ 以下はコマンドの出力結果です。 i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@imx8mmevk:~# i2ctransfer -y 2 w2@0x3c 0x30 0x0a r1 エラー:メッセージ送信に失敗:そのようなデバイスやアドレスはありません root@imx8mmevk:~# i2ctransfer -y 2 w2@0x3c 0x30 0x0b r1 エラー:メッセージ送信に失敗:そのようなデバイスやアドレスはありません root@imx8mmevk:~# root@imx8mmevk:~# root@imx8mmevk:~# v4l2-ctl --list-devices i.MX6S_CSI(プラットフォーム:32e20000.csi1_bridge): /dev/video0 vsi_v4l2dec(プラットフォーム:vsi_v4l2dec): /dev/video2 vsi_v4l2enc(プラットフォーム:vsi_v4l2enc): /dev/video1 root@imx8mmevk:~# readlink -f /sys/class/video4linux/video0/device/driver /sys/bus/platform/drivers/mx6s-csi root@imx8mmevk:~# dmesg |grep -Ei 'mxc_md|mx8-img-md|imx7-csi|mxc_mipi|mx6s' [ 1.820962] MX6S-CSI 32e20000.csi1_bridge:初期化中 [ 1.827181] mxc_mipi-csi 32e30000.mipi_csi:mipi-phy供給が見つかりませんでした。ダミーレギュレータを使用します。 [ 1.835931] mxc_mipi-csi 32e30000.mipi_csi:MIPI CSI v4L2デバイス登録済み [ 1.842911] CSI:登録センサーサブデバイス:mxc_mipi-csi.0 [ 1.848595] mxc_mipi-csi 32e30000.mipi_csi:レーン数: 2、hs_settle: 13、clk_settle: 2、wclk: 1、周波数: 333000000 手伝ってくれてありがとう ティエリー

Anyone on here use Smart Cards in their environment? I ask because I rarely see threads about it but I would imagine there has to be people out there who enforce Smart Card auth in their organization. Smart Cards on Mobile Re: Anyone on here use Smart Cards in their environment? Hello @ferio23 Hope you are doing well. Smart Cards are widely used in applications implementing authentication, access control, among others. To develop a complete solution and operate smart cards, you will need appropriate middleware or enablement software. For additional guidance, please refer to our Partner Directory for recommended vendors and solution providers. Regards, Eduardo.

Looking for DDR2 Register Parameter Architecture (RPA) Calculator for PQ2 Pro (MPC830x) The MPC830x pages here at NXP have a number of design documents, but I've been led to believe there is some sort of calculator (spreadsheet?) which helps with computing DDR2 register settings, possibly named: MPC830x_DDR2_RPA.xls or some variation of that.  Even if it's for some other PowerQuicc 2 (i.e. not exactly MPC830x) that used DDR2, it might be useful. Any chance it's stored away in an archive or with an eval board collateral? Thank you!

imx8mmevk ov5640 mediactl 您好， 我尝试在以下位置使用 mediactl： Linux imx8mmevk 6.6.52-lts-next-g90192c5d29cb#1 SMP PREEMPT 7 月 8 日星期二 12:00:06 UTC 2025 aarch64 GNU/Linux 使用 mipe cam ov5640。 我可以用GStreamer和Pipewire控制摄像头，但是不能用Mediactl。 以下是 dmseg 日志： dmesg | grep ov5640_mipi [ 0.059215] 平台 32e30000.mipi_csi:修复了与 /soc@0/bus@30800000/i2c@30a40000/ov5640_mipi@3c 的依赖循环 [ 2.409821] ov5640_mipi 2-003c：无可用传感器复位引脚 [ 2.415630] ov5640_mipi 2-003c：未找到 DOVDD 电源，使用虚拟稳压器 [ 2.422901] ov5640_mipi 2-003c：未找到供电 DVDD，使用虚拟稳压器 [ 2.429995] ov5640_mipi 2-003c：未找到电源 AVDD，使用虚拟稳压器 [ 2.446514] ov5640_mipi 2-003c：读取寄存器错误：reg=300a [ 2.451845] ov5640_mipi 2-003c：未找到摄像头 以及 mediactl 的输出： media-ctl -p 枚举 /dev/media0 失败 (-2) 你能帮我在设备上使用 mediactl 吗？ 非常感谢 Re: imx8mmevk ov5640 mediactl 您好， 有趣的是，你提到尽管存在这些错误，摄像头仍然可以与 GStreamer 和 PipeWire 配合使用。 ov5640_mipi 2-003c: Read reg error: reg=300a ov5640_mipi 2-003c: Camera is not found 通常情况下，如果传感器驱动程序探测失败，则相应的 V4L2 子设备将无法成功注册，预期的相机管道将无法完全可用。 根据你的日志，我首先要调查的是OV5640传感器驱动程序是否真的成功进行了探测，以及你是否在两种情况下都使用了同一台摄像头设备。 如果不是这个问题，您是否已确认媒体控制器接口已启用并受支持？错误“无法枚举 /dev/media0 (-2)”表示找不到 /dev/media0。媒体控制器设备的可用性取决于内核配置和驱动程序实现。 如需更具体的帮助，请分享： - 成功捕获视频的 GStreamer 管道。 - 相关的 OV5640 设备树配置。 - 无论您是使用 NXP 电路板支持包。 相机驱动程序还是修改/自定义实现。 顺祝商祺！ 卡罗琳娜·特雷霍斯 RidgeRun公司的嵌入式软件工程师 Re: imx8mmevk ov5640 mediactl 你好 ， 我使用这条管道配合 NXP 电路板支持包。 驱动程序： root@imx8mmevk:~# gst-launch-1.0-v v4l2src 设备=/dev/video0 ！video/x-raw,format=YUY2,width=1280,height=720,framerate=30/1 !vpuenc_h264！h264解析！rtph264pay pt=96 config-interval=1 !udpsink 主机=10.49.24.30 端口=5000 同步=false root@imx8mmevk:~# dmesg | grep ov5640_mipi [ 0.059279] 平台 32e30000.mipi_csi:修复了与 /soc@0/bus@30800000/i2c@30a40000/ov5640_mipi@3c 的依赖循环 [ 2.405481] ov5640_mipi 2-003c：无可用传感器 RESET 引脚 [ 2.411300] ov5640_mipi 2-003c：未找到 DOVDD 电源，使用虚拟稳压器 [ 2.418588] ov5640_mipi 2-003c：未找到供电 DVDD，使用虚拟稳压器 [ 2.425685] ov5640_mipi 2-003c：未找到电源 AVDD，使用虚拟稳压器 [3.057823]mxc_mipi-csi 32e30000.mipi_csi：已注册传感器子设备：ov5640_mipi 2-003c [ 3.067382] ov5640_mipi 2-003c: 已找到摄像头 错误信息消失了！！！！ dtsi： ov5640_mipi：ov5640_mipi@3c { 兼容=“ovti，ov5640_mipi”； reg =<0x3c> �; 状态 = "正常"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_csi_pwn>, <&pinctrl_csi_rst>; clocks = <&clk IMX8MM_CLK_CLKO1>; clock-names = "csi_mclk"; 分配时钟 = <&clk IMX8MM_CLK_CLKO1>; 已分配时钟父级 = <&clk IMX8MM_CLK_24M>; 分配的时钟速率<24000000> =; csi_id =;<0> pwn-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>; mclk<24000000> =; mclk_source =;<0> 港口 { ov5640_mipi1_ep：端点 { 远程端点 = <&mipi1_sensor_ep>; }; }; }; }; media-ctl -p 枚举 /dev/media0 失败 (-2) 谢谢你的帮助 Re: imx8mmevk ov5640 mediactl 你好@Thierry49_49 希望你一切都好。 根据日志显示，传感器位于 I2C 总线 2 的地址 0x3c 上。流媒体播放停止后，请检查： i2cdetect -y 2 i2ctransfer -y 2 w2@0x3c 0x30 0x0a r1 i2ctransfer -y 2 w2@0x3c 0x30 0x0b r1 它应该记录预期的芯片ID。 另外，请通过以下方式确认您的有效驾照： v4l2-ctl --list-devices readlink -f /sys/class/video4linux/video0/device/driver dmesg | grep -Ei 'mxc_md|mx8-img-md|imx7-csi|mxc_mipi|mx6s' 如果输出仅显示 mxc_mipi-csi 和 mx6s_capture，则 media-ctl 不能与此捕获路径一起使用。 顺祝商祺！ 萨拉斯。 Re: imx8mmevk ov5640 mediactl 你好 ~@Manuel_Salas 谢谢，我没事，你呢？ 以下是命令输出： i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 abcdef 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70：-- -- -- -- -- -- -- -- root@imx8mmevk:~# i2ctransfer -y 2 w2@0x3c 0x30 0x0a r1 错误：发送消息失败：没有这样的设备或地址 root@imx8mmevk:~# i2ctransfer -y 2 w2@0x3c 0x30 0x0b r1 错误：发送消息失败：没有这样的设备或地址 root@imx8mmevk:~# root@imx8mmevk:~# root@imx8mmevk:~# v4l2-ctl --list-devices i.MX6S_CSI（平台：32e20000.csi1_bridge）： /dev/video0 vsi_v4l2dec（平台：vsi_v4l2dec）： /dev/video2 vsi_v4l2enc（平台：vsi_v4l2enc）： /dev/video1 root@imx8mmevk:~# readlink -f /sys/class/video4linux/video0/设备/driver /sys/总线/platform/drivers/mx6s-csi root@imx8mmevk:~# dmesg | grep -Ei 'mxc_md|mx8-img-md|imx7-csi|mxc_mipi|mx6s' [ 1.820962] mx6s-csi 32e20000.csi1_bridge:初始化 [1.827181]mxc_mipi-csi 32e30000.mipi_csi：未找到 mipi-phy 供电，使用虚拟稳压器 [1.835931]mxc_mipi-csi 32e30000.mipi_csi：mipi csi v4l2 设备已注册 [ 1.842911] CSI：已注册传感器子设备：mxc_mipi-csi.0 [1.848595]mxc_mipi-csi 32e30000.mipi_csi：车道数：2，高速结算：13，时钟结算：2，工作时钟：1，频率：333000000 谢谢你的帮助 蒂埃里

PNEV7642A Rev B 板 你好， 我正在考虑购买PNEV7642A B版评估板。但我找不到这款产品的任何链接或页面，请问您能否提供购买这款滑板的链接？ 另外，在为该板查找 NFC 库时，我发现了一个适用于 PN7462 的 NFC 读取器库，而不是适用于 PN7642 的。这个库是否同时支持这两个目标平台？ 谢谢。 开发板 Re: PNEV7642A Rev B board 板是： OM27642：PN7642 安全紧凑型 NFC 控制器开发套件，带可编程存储器和加密加速功能 | 恩智浦半导体 您可以从这里下载PN7642 SDK： 集成MCU的顶级NFC前端 | 恩智浦半导体 Re: PNEV7642A Rev B board @jimmychan 谢谢回复。 请问我可以使用哪种调试器来调试这个开发套件（OM27642EVK）？ 我可以使用MCU-Link调试探针或PEmicro的Multilink Universal作为编程器/调试器吗？ 请注意，MCU-Link 在此链接中并未将 pn7642 列为支持的 IC。 MCU链接 谢谢。

iMX93における外部発振器の使用方法の明確化 こんにちは、 iMX93を使用したカスタムボードを開発しているのですが、24MHzの水晶発振器に関して少し混乱しており、外部発振器を使用できるかどうか疑問に思っています。 IMX93IECデータシートの表3には、「システムはXTALI/XTALOで24MHzを必要とします」と記載されています。外部の24MHz発振器では結晶を消す ことはできません 。」 しかし、リファレンス・マニュアルの発振器29.4.2節には次のように記されています。 「各XTALモジュールはレジスタ構成を通じて以下のモードをサポートしています: ノーマルオシレーターモード - XTALはクリスタルオシレーター入力に基づいて安定した方形波を生成します。 バイパスモード - 外部クロックはXTALパッド経由で入力可能です。" また、IMX93QSBの回路図には次のような注記があります。 「24MHz水晶発振器について」 バイパスモードを選択する必要があります。このモードでは、水晶発振器アンプはオフになり、「cosc_en_lv」、「osc_comp_enable_lv」、および「pwd_lv」は非アクティブ（論理0）になります。外部(XI)でのレールツーレール入力信号のみが必要で、XO(XO)は浮動信号または接地信号のいずれかで対応可能です。バイパスモードの設定は、FXOSCとSXOSCの両方のブロックガイドに記載されています。 参照されているレジスタ／コマンド／ビットとは何ですか？FXOSCとSXOSCのブロックガイドはどこにありますか？これらのものはリファレンス・マニュアルで検索しても見つからないのですか? では、iMX93で外部発振器を使うことは可能でしょうか(またはサポートされている)のでしょうか?