Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Hello, I’m trying to establish communication between two Imx95 verdin EVK A1 Silicon version boards, through their Aquantia 10 Gbps interfaces. Both boards are running Debian 12 ( linux kernel 6.12.3) with the aquantia10 G firmware (AQR-G4_v5.6.D-AQR_Marvell_NoSwap_XFI_ID44834_VER2068.cld ) properly installed using the nxp installer (aquantia-firmware-utility/aq_api_2_9_7 at master · nxp-qoriq/aquantia-firmware-utility · GitHub). They are physically connected using a Cat6a Ethernet cable. When I run performance tests using iperf3, I get around 5 Gbps in TCP and 1.2 Gbps in UDP with 0% of loss, even when specifying a target bandwidth of 7 Gbps: # TCP Test iperf3 -s # on the first board iperf3 -c -t 30 # on the second board # UDP Test iperf3 -s iperf3 -c -u -b 7G -t 30 when i try to activate jumbo frame with ip link set dev enp1s0 mtu 9000 but i get an error that i exceded the limit (it’s weird that a 10Gbps interface does not accept jumbo frames) also i tried to to increase the UDP buffer size, but i get the same bitrame the CPU load does not exceed 40% when i run iperf3 in both sides Are there any specific n configurations to apply or additional tools to install in order to reach the maximum throughput (close to 10 Gbps)? is the Aquantia FW version is good? the linux kernel version? the FW installer version??? SOmeone have already tried to use the 10Gbps interface on this Targets??? Regards, Abdelmonaem Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 1. Try configuring following settings on both of your systems: cpufreq-set -g performance sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216' sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216' 2. If possible use a different reference system as iperf server (e.g. Intel Xeon) 3. iperf3 itself is single-threaded per test stream, try using  -P option: e.g. iperf3 -c -u -b 10G -t 30 -P 6 (6 streams) 4. Check both forward and reverse stream (-R) iperf3 -c 192.168.1.1 -t 10 -b 10G -u -R Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Hi, Thank you for your feedback, applying your configuration: cpufreq-set -g performance sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216' sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216' Now i'm able to achieve 10Gbps some times 8,8 or 9,8Gbps on emitter side only and with only iperf and not iperf3, on the receiver side i can only achieve 5.59Gbps with 36% of loss frames, could you help to resolve this issue Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp it will be a minor version upgrade to 6.12.49 BTW, you may also want to consider DPDK or AF_XDP for better throughput?  Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp => TCP vs UDP send performance When you are using iperf3 to send TCP packets, each TCP packet is 128KB, and the packet will be fragmented by the LSO feature of ENETC Hardware. So you see higher TCP transfer performance. iperf3 does not enable UDP_SEGMENT when creating UDP sockets. Therefore: - Each UDP packet is approximately MTU-sized (≈1500 bytes). - For the same data size, UDP requires to send many more packets than TCP. More packets → more kernel processing → lower performance compared to TCP with LSO. => Why receive is much lower in comparison to send for TCP? - The TX and RX paths are not symmetrical in the Linux kernel, so the processing time for each RX packet and each TX packet in the kernel is different. Also TCP is using LSO offload in send. - RSC is not enabled by default in kernel; We need to disable TCP timestamp so that the RSC of ENETC can work properly. Currently, the RSC of i.MX95 is disabled by default. a) Enable RSC of i.MX95 (receiver side): ethtool -K eth1 large-receive-offload on b) Disabled TCP timestamp (sender side) : sysctl -w net.ipv4.tcp_timestamps=0 sysctl -p /etc/sysctl.conf After enabling RSC, you will see the TCP performance at receiver side will be increased. Additionally you can try using Jumbo frames to get higher throughput. (Hope you are running latest release). # Change MTU to 9000 on both side ip link set dev eth1 mtu 9000 # Change RX buffer length in the ethernet driver. ethtool -G eth1 rx-buf-len 16384 We can see between 8 to 10 Gbps UDP RX/TX with multi-stream mode. Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Hi, I'm interested only on UDP for the moment and not TCP and i think that the offload mecanisms are not applicable for UDP I tried to activate the jumbo frames by setting mtu to 9000 but i get an error that i exceeded the limits which is 1500 (im using the kernel version 6.12.3) Regards, Abdelmonaem Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Ok i will try this and told you what i get, Could you precise the linux kernel version for LF-Q4?? As i told you i'm on 6.12.3 and i cannot go to a superior version because i have a A1 silicon revision, i need to know if i have to upgrade to B0 revision or not Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp The RSC settings will also improve UDP performance. The changes/fixes for Jumbo frames in ENETC should be available in upcoming LF-Q4 release in two weeks.  Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp With i don't have an issue i can go to 10Gbps sometime 9, 8Bps with iperf in parallel flows with only one flow i'm at 5Gbps , but my big issue is the Udp, in mono flow i'm at 2Gbps with no lost frame it's ok, but in parallel flows i'm at 5,5Gbps with 42% of loss Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp i don't think that AF_XDP or DPDK will help to reduce a 46% of loss to 0%, i verified also the IRQ affinty and i can see that on the 10G interface i have 6 IRQ each one is affected to a CPU, and i don't see any CPU load issue during the test, the maximum CPU load for 1 CPU is 40%, i still don't understand why i keep loosing frames , maybe the fact that the kernel version used does not support jumbo frames , did you have any performance tests on the 10G interface in your Side (NXP) i think you should test in your side and see if you have the same issue than mine Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp AF_XDP or DPDK do not use kernel networking stack.  DPDK specially have a different driver and work in userspace only. It is highly optimized for networking and packet processing.  It can provide really fast performance for all IP packets.  you may check it out at;  Chapter 10: https://www.nxp.com/docs/en/reference-manual/RM00293.pdf Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp this test is performed on which silicon revision A1 or B0?? do you confirm that the kernel version used for this test 6.12.49 is applicable only for B0 or could be applicable on A1??? i'm not seeing this kernel version in your bsp delivery, the last one is 6.12.34 https://www.nxp.com/pages/alpha-beta-bsps-for-microprocessors:IMXPRERELEASES Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp The new kernel tree and changes are available at: https://github.com/nxp-imx/linux-imx/commits/lf-6.12.49-2.2.0 A1 support has been dropped from newer LF release.  You have following options; 1.  Just build the kernel independently and replace the kernel only in your build. (It may work)   2. Ask your marketing contact to replace your boards with B0 - so that you can run LF-Q4'2025 release.  Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Ok got it, but just to be sure, could you do the test with MTU = 1500 at reception side i need to know if you have the same result than me on this new version and also i see on your test you put TX at 1500 and reception at 9000 but this does not change anything it's like you are in 1500 in both side if you need to test jumbo frames you need to be at 9000 in both sides , please redo the tests with following configuration: 1- RX/TX with MTU = 1500 in both sides with mono and muti streams 2- RX/TX with MTU = 9000 in both sides with mono and muti streams thank you in advance Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp i don't understand that frome those lines: Single UDP Stream send (1500 MTU): 2 Gbps(this seems at tx with MTU 1500 in single stream you are at 2Gbps) Multi UDP stream send (1500 MTU): 10 Gbps (this seems at tx with MTU 1500 in multi streams you are at 10Gbps) Single UDP Stream send (9000 MTU): 8.2 Gbps(this seems at tx with MTU 900 in single stream you are at 8.2Gbps) Single UDP Stream receive(9000 MTU): 3.9 Gbps(this seems at Rx with MTU 9000 in single stream you are at 3.9Gbps) Multi UDP Stream receive(9000 MTU): 10Gbps(this seems at Rx with MTU 9000 in Multi streams you are at 2Gbps) for me i don't see : Single UDP Stream receive(1500 MTU) Multi UDP Streams receive(1500 MTU) Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp yes, this how the results were tested. MTU was same on both side in all cases (either both 1500 or both 9000) Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp see attached,  Also note that I am also running it on A1 SOC UBOOT logs: -  U-Boot 2025.04-g8c1de2e1deca (May 09 2025 - 15:29:26 +0000) CPU:   i.MX95 rev1.1 at 1800MHz CPU:   Automotive temperature grade (-40C to 125C) at 30C LM Boot reason: sw, origin: 2, errid: 1 LM shutdown reason: sw, origin: 2, errid: 1 Model: NXP i.MX95 19X19 board DRAM:  15.8 GiB --- SM logs >$ info SM Version = Build 633, Commit c37b26da SM Config = mx95evk, mSel=0 Board = i.MX95 EVK, attr=0x00000000 Silicon = i.MX95 A1 Boot mode = normal Boot device = MMC1 Boot stage = primary Boot set = 1 ECID = 0x6E5F04BA0000000500041D0899123F81 PMIC 0 (0x08) = 0x20, 0x09, 0x10, 0x00, 0x01 PMIC 1 (0x2A) = 0x54, 0x22, 0x00, 0x0B PMIC 2 (0x29) = 0x55, 0x22, 0x00, 0x0A Compiler = gcc 14.2.1 20241119

CLRC66301B 掉电模式仍消耗 2 mA 而不是 nA 您好，恩智浦社区 我正在使用 CLRC66301B NFC 读卡器IC 并尝试通过将 PDOWN 引脚设为高电平来激活掉电模式 (3.3)V），详见数据手册。但是，电流消耗保持在2 mA，而数据表显示掉电时电流消耗应在8 nA至40 nA之间。 设置详情： PDOWN 引脚：3.3 V（恒定高电平） VDDs：VDD（TX）、VDD（AUX）、VDD（MCU）电压均为 3.3 V 接口：I²C（测试期间空闲） XTAL：连接 27.12 MHz 晶体 当前测量期间无通信或活动 测量电流： ~2 mA 问题 1.在断言 PDOWN 之前是否需要对寄存器进行配置？ 2。IRQ、XTAL、IFSEL 或其他 GPIO 能否阻止进入真正的掉电模式？ 3.PDOWN 是否需要使用 VDD 或 RESET 进行额外的定时或排序？ 如有任何见解或建议，我们将不胜感激。 谢谢！ 乌玛桑卡尔 NFC 控制器解决方案 Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA 您好， 当您提到当 SDA 和 SCL 物理断开时电流消耗会降低时，是指您移除了该引脚上的所有连接（同时移除主机 MCU 和上拉电阻器），还是指这些线路仅与主机 MCU 断开？ 另外，能否请您描述一下测量所用的方法、设备和测试点？ Eduardo。 Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA 亲爱的恩智浦团队 我使用带有 CLRC66303B 芯片的官方 CLEV6630ARD 板进行了掉电电流测试。只有在进行任何 I²C 通信之前物理断开 SDA 和 SCL 时，电流才会达到 ~40 nA。如果使用一次 I²C，即使将 PDOWN 设为高电平，电流也会保持在 2 mA 以上。 请说明在进入 PDOWN 之前，I²C 线路应该做些什么？具体来说 在断言 PDOWN 之前，MCU 是否应将 SDA 和 SCL 设置为高阻抗（输入，无拉）？ 之前的任何 I²C 通信是否会阻止芯片进入真正的硬掉电？ 谢谢！ Follow-Up: CLRC66303 – High Current in Hard Power-Down Mode (CLEV6630ARD-Based Design) 亲爱的恩智浦团队 我之前曾就 CLRC66301HN 的硬掉电电流提出过问题，你的回复建议迁移到 CLRC663 Plus 系列 (CLRC66303)。此后我改用 CLRC66303B，使用基于 CLEV6630ARD 参考设计的定制板，我想继续提供最新的测试结果。 你之前的回复侧重于 LPCD 行为和 AN11783，但这个问题仅涉及通过 PDOWN 引脚进行硬掉电，没有RF场或 LPCD 处于活动状态。 掉电电流测量 (CLRC66303B)： > 当 PDOWN 处于低电平时（芯片处于活动状态，RF场 开启）：~100 mA >当 PDOWN 为高电平且存在 I²C 上拉时：~1.2 mA >当 PDOWN 为高且 I²C 线路被驱动为低时： ~6.6 mA >当 PDOWN 为高电平且 I²C 线路在使用前已物理断开时：~40 nA 只有在进行任何 I²C 通信之前物理断开 SDA 和 SCL 连接时，芯片才会在 PDOWN 模式下消耗 ~40 nA 电流。如果只使用一次 I²C，则即使在 PDOWN 钳位高电平之后，电流仍保持高电平。 硬件设置摘要： 芯片：CLRC66303B，I²C 模式。 微控制器：TI CC2652R7，100 kHz I²C 电压：3.3 V 调节 上拉：SDA/SCL 上 4.7 kΩ 至 3.3 V 未使用的引脚：按照数据表拉动 未启用射频或 LPCD 功能 方案设计：基于 CLEV6630ARD（附后） 需要澄清的问题： 1.在 PDOWN 模式期间，SDA/SCL 是否内部偏置？ 2。即使后来将PDOWN设置为高电平，之前的任何I²C活动是否会阻止真正的掉电？ 3.在断言 PDOWN 之前，是否有必要将 MCU I²C 引脚设置为 Hi-Z（输入，无拉）？ 4.是否有恩智浦推荐的方法，可在硬 PDOWN 模式下可靠地实现<100 nA，而无需物理断开 I²C 线路？ 我们的目标是确保电池的使用寿命，并且必须实现数据手册中规定的低功耗性能。如果有任何专门关于 PDOWN 行为和 I²C 漏电流的指导或文档，我们将不胜感激。 IMG_20250715_182911.jpg 附上示意图以供参考。 顺祝商祺！ Umasankar C Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA 你好@Umasankarc 希望你一切顺利。 我知道你使用的是基于 CLRC66301HN（非增强版）的自定义板，对吗？如果是，请考虑我们建议改用 CLRC663 plus 系列 (CLRC66303)。 引脚 PDOWN 的高电平应启用硬掉电。数据手册中描述的掉电电流 (Ipd) 相当于 CLRC663 芯片中所有电源电流的总和；但是，嵌入在板中的外部元器件可能会消耗额外的功率。 AN11783 CLRC663 plus《电源卡检测》第 3.4 节中描述了一些低功耗设计建议。 Eduardo。

NFC reader library porting guide for LPC11u37h(Ver 5.12) - Switching the NFC frontend As NFC reader library 5.12 also supports PN5180, switching the NFC frontend from CLRC663 to PN5180 is quite easy based on previous porting. The porting also includes the hardware settings and software modification. Hardware Setup for porting: a) Remove resistors on PNEV5180B to disconnect the onboard lpc1769 from PN5180, following steps on page 16 of https://www.nxp.com/docs/en/application-note/AN11908.pdf  b) Connect LPCXpresso board for LPC11U37 with PNEV5180 as below: Software Modification for porting: 1. Make a copy of Board_Lpc11u37Rc663.h , and change its name to "Board_Lpc11u37Pn5180.h", and import it into the DAL/boards folder. 2.Change the source code in the header file as below: 3. Add two more pins' definition and configuration for BUSY and DWL pins of PN5180, and new configuration for reset pin. and modify the reset logic: 4.Change the IRQ interrupt trigger type to rising edge. 5.Include this header file in BoardSelection.h 6.Add this new configuration in ph_NxpBuild_App.h 7.Add this new configuration in phApp_Init.h 8.Add this new configuration in ph_NxpBuild_Platform.h 9.Add this new configuration in Settings. 10.Building result: Testing result: NFC Frontend Solutions NFC Reader Library Re: NFC reader library porting guide for LPC11u37h(Ver 5.12) - Switching the NFC frontend so far, just NFC Reader Library v4.040.05 R2 supports PNEV512B, but the main problem is this version just support LPCopen library, while KL17 is supported by SDK, so you have to refer to NFC reader library which support Kinetis as well. Re: NFC reader library porting guide for LPC11u37h(Ver 5.12) - Switching the NFC frontend Hi Mr. Kan Li, first of all congrats and thanks you for your post. I write a comment here because I'm having problems including the library in my project, how can I do it for a PN512 chip as frontend and a KL17 as MCU. Also I'm using MCUXpresso v10.2.1. Kind regards, JC.

Exporting YOLO Models for NXP i.MX Platforms In this post, we will review the YOLO model export process for three popular NXP families: i.MX8MP, i.MX93, and i.MX95. These processors are increasingly used in edge AI applications such as smart vision, industrial automation, robotics, and intelligent HMI systems. Although they all support machine learning deployment, the export path, supported runtimes, and hardware acceleration options may differ depending on the device. The purpose of this guide is to provide a clearer starting point for developers who want to take a trained YOLO model and prepare it for execution on these i.MX platforms. Whether your workflow targets CPU, NPU. YOLO Model Export Workflow for i.MX Processors 1) Install Ultralytics Install or upgrade the Ultralytics package from PyPI: pip install -U ultralytics 2) Export the YOLO Model (TFLite INT8) Export your trained YOLO model to TensorFlow Lite (TFLite) format with INT8 quantization: yolo export model= .pt format=saved_model quantize=8 Example: yolo export model=yolov8n.pt format=saved_model quantize=8 Notes: The model must be exported in TFLite format and fully INT8 quantized. After the export process, a directory named " _saved_model" Inside this directory, you should use the following file as the input for the converter called " _full_integer_quant.tflite "  This is the fully quantized INT8 model required for NPU deployment. Using any other file from the export directory may result in compatibility issues or prevent proper NPU acceleration. After obtaining the *_full_integer_quant.tflite file, you can proceed with the needed conversion workflow to generate the final model optimized for execution on the NPU. For additional valid export options, please refer to the official Ultralytics documentation: https://docs.ultralytics.com/modes/export/ At this stage: The model can run on CPU for: i.MX8MP i.MX93 i.MX95 On i.MX8MP, this TFLite model can also be deployed to the NPU using the appropriate delegate. 3) i.MX93  Compile for Ethos-U NPU (Vela) For i.MX93, an additional compilation step is required to use the Ethos-U NPU. Run the Vela compiler to convert the TFLite model into an optimized format: vela .tflite --output-dir Notes: This step generates a model optimized for the Ethos-U NPU. The resulting output files are required for deployment using the NPU delegate on the i.MX93 platform. Please ensure that the model complies with the Ethos-U operator constraints, as only supported operations can be accelerated by the NPU. This command can be executed directly on the i.MX93 target, or alternatively by using the eIQ Toolkit (please refer to the eIQ Converter documentation for more details). 4)  i.MX95 Convert Model Using Neutron SDK For i.MX95, the model must be converted using the Neutron Converter, depending on the BSP version installed on your board. .\neutron-converter.exe ` --input " .tflite" ` --target imx95 ` --output " .tflite" ` --optimization-level OOpt Notes: The Neutron toolchain prepares the model for i.MX95 NPU acceleration. Supported formats and flags may vary depending on the Neutron SDK version. Always verify compatibility with your BSP release. You can check the compatibility details of the Neutron SDK in the "docs" folder of your downloaded Neutron SDK package. 5) Benchmark the Model After exporting and converting the model, you can validate performance using benchmarking tools. Typical options include: TFLite benchmark tool (CPU / delegate): benchmark_model --graph= .tflite --num_threads=X 6) Results iMX8MP CPU root@imx8mpevk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --mum_threads=4 INFO: STARTING! WARN: Unconsumed cmdline flags: --mum_threads=4 INFO: Log parameter values verbosely: [0] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 86.368ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=1 curr=1029584 p5=1029584 median=1029584 p95=1029584 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=986237 curr=985536 min=983921 max=993982 avg=985863 std=1497 p5=984152 median=985947 p95=986715 INFO: Inference timings in us: Init: 86368, First inference: 1029584, Warmup (avg): 1.02958e+06, Inference (avg): 985863 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=11.207 overall=40.918 root@imx8mpevk:~# NPU root@imx8mpevk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --num_threads=4 --external_delegate_path=/usr/lib/libvx_delegate.so INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [4] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [4] INFO: #threads used for CPU inference: [4] INFO: External delegate path: [/usr/lib/libvx_delegate.so] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Vx delegate: allowed_cache_mode set to 0. INFO: Vx delegate: device num set to 0. INFO: Vx delegate: allowed_builtin_code set to 0. INFO: Vx delegate: error_during_init set to 0. INFO: Vx delegate: error_during_prepare set to 0. INFO: Vx delegate: error_during_invoke set to 0. INFO: EXTERNAL delegate created. INFO: Explicitly applied EXTERNAL delegate, and the model graph will be completely executed by the delegate. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 39.515ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=1 curr=16831746 p5=16831746 median=16831746 p95=16831746 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=67167 curr=67190 min=67048 max=67366 avg=67187 std=64 p5=67094 median=67184 p95=67295 INFO: Inference timings in us: Init: 39515, First inference: 16831746, Warmup (avg): 1.68317e+07, Inference (avg): 67187 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=9.47266 overall=224.398 root@imx8mpevk:~# iMX93 CPU root@imx93evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --num_threads=2 INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [2] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [2] INFO: #threads used for CPU inference: [2] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 57.963ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=3 first=247896 curr=198973 min=198973 max=247896 avg=215381 std=22991 p5=198973 median=199275 p95=247896 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=199533 curr=198880 min=197719 max=205262 avg=199032 std=1005 p5=198344 median=198886 p95=199961 INFO: Inference timings in us: Init: 57963, First inference: 247896, Warmup (avg): 215381, Inference (avg): 199032 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=11.2539 overall=40.9961 root@imx93evk:~# NPU root@imx93evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant_vela.tflite --num_threads=2 --external_delegate_path=/usr/lib/libethosu_delegate.so INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [2] INFO: Graph: [yolov8n_full_integer_quant_vela.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [2] INFO: #threads used for CPU inference: [2] INFO: External delegate path: [/usr/lib/libethosu_delegate.so] INFO: Loaded model yolov8n_full_integer_quant_vela.tflite INFO: Ethosu delegate: device_name set to /dev/ethosu0. INFO: Ethosu delegate: cache_file_path set to . INFO: Ethosu delegate: timeout set to 60000000000. INFO: Ethosu delegate: enable_cycle_counter set to 0. INFO: Ethosu delegate: enable_profiling set to 0. INFO: Ethosu delegate: profiling_buffer_size set to 2048. INFO: Ethosu delegate: pmu_event0 set to 0. INFO: Ethosu delegate: pmu_event1 set to 0. INFO: Ethosu delegate: pmu_event2 set to 0. INFO: Ethosu delegate: pmu_event3 set to 0. INFO: EXTERNAL delegate created. INFO: EthosuDelegate: 8 nodes delegated out of 15 nodes with 8 partitions. INFO: Explicitly applied EXTERNAL delegate, and the model graph will be partially executed by the delegate w/ 8 delegate kernels. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 2.9511 INFO: Initialized session in 638.148ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=7 first=87215 curr=81264 min=81079 max=87215 avg=82056.4 std=2107 p5=81079 median=81187 p95=87215 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=81497 curr=81232 min=80887 max=81783 avg=81153.1 std=178 p5=80921 median=81148 p95=81497 INFO: Inference timings in us: Init: 638148, First inference: 87215, Warmup (avg): 82056.4, Inference (avg): 81153.1 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=7.36328 overall=8.73828 root@imx93evk:~# iMX95 CPU root@imx95evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --num_threads=6 INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [6] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [6] INFO: #threads used for CPU inference: [6] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 35.268ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=7 first=115073 curr=74468 min=74170 max=115073 avg=80310.4 std=14192 p5=74170 median=74581 p95=115073 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=74143 curr=74135 min=73657 max=76392 avg=74346.9 std=447 p5=73829 median=74307 p95=75020 INFO: Inference timings in us: Init: 35268, First inference: 115073, Warmup (avg): 80310.4, Inference (avg): 74346.9 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=11.5195 overall=40.8867 root@imx95evk:~# NPU: root@imx95evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant_neutron.tflite --num_threads=6 --external_delegate_path=/usr/lib/libneutron_delegate.so INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [6] INFO: Graph: [yolov8n_full_integer_quant_neutron.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [6] INFO: #threads used for CPU inference: [6] INFO: External delegate path: [/usr/lib/libneutron_delegate.so] INFO: Loaded model yolov8n_full_integer_quant_neutron.tflite INFO: EXTERNAL delegate created. INFO: NeutronDelegate delegate: 1 nodes delegated out of 33 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-7399a58e, zerocp enabled. INFO: Explicitly applied EXTERNAL delegate, and the model graph will be partially executed by the delegate w/ 1 delegate kernels. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.20989 INFO: Initialized session in 12.756ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=17 first=31509 curr=27588 min=27555 max=31509 avg=29101.2 std=1166 p5=27555 median=29071 p95=31509 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=28068 curr=29081 min=26573 max=31340 avg=29104.1 std=1204 p5=27306 median=29141 p95=31171 INFO: Inference timings in us: Init: 12756, First inference: 31509, Warmup (avg): 29101.2, Inference (avg): 29104.1 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=6.98438 overall=12.2344 root@imx95evk:~ Disclaimer: Ultralytics YOLO models have not been officially validated/supported by NXP. Therefore, compatibility with i.MX processors and their corresponding NPUs cannot be guaranteed. Some models or configurations may not work as expected depending on operator support and hardware limitations.

SynGas OBD 节油器是否合法？真实的深度 SynGas 评论 2026 SynGas 评论：SynGas OBD Fuel Saver 是否合法？这是我在亲自测试之前的第一个问题。2026 年的油价依然居高不下，很多驾驶员都在寻找提高燃油效率的现实方法，而不需要昂贵的汽车改装或复杂的改装系统。 SynGas是一款简单的即插即用设备，可连接到车辆的OBD2端口，并声称通过根据实际驾驶习惯使用汽车的ECU来优化燃油消耗。它的有趣之处在于，它并不承诺立竿见影的神奇效果。取而代之的是，该设备在最初的 150 英里内会经历一个学习阶段，以便更好地了解加速、制动和整体驾驶模式，然后才能更有效地调整燃油优化。 点击此处查看 SynGas 的最新详情和官方信息 2026 年，节油技术已成为一个热门话题，因为人们正在积极寻找经济实惠的方法来降低交通成本。SynGas通过提供即插即用的方法来直接利用这一趋势，而不是昂贵的ECU调整或持续购买燃料添加剂。 那么，SynGas OBD 节油器是否合法？ 根据研究、用户反馈和500英里后的真实驾驶观察，它似乎是真正的OBD2燃料优化设备，而不是另一个随机的互联网花招。然而，现实的期望很重要。这并不神奇，每辆车或每位驾驶员的结果也不尽相同。最大的价值似乎来自于长期的日常使用，尤其是对于通勤者和长时间在路上行驶的驾驶员来说。 点击此处查看 SynGas OBD 节油器的工作原理和当前供应情况：     Re: Is SynGas OBD Fuel Saver Legit? An Honest Depth SynGas Reviews 2026 您的问题似乎与恩智浦 QorIQ 系列（数字网络）处理器无关。 请在正确的社区区块中提交您的问题。

DMA MUX Currently I am using, S32 Platform 3.4 programming environment, RTD is 2.0.0 During my use of DMA I found that the RM module I created does not have a Dma Mux, how to solve this situation. Re: DMA MUX Thank you. Re: DMA MUX Hi @xuanming  The example was implemented using a newer RTD version than the one you are currently working with; therefore, changes were introduced to the driver implementation. As you are working with RTD 2.0.0, you should refer to the Dma_Ip driver. Starting from RTD 3.0.0, the DMAMux Source configuration was moved to the RM module at the MCAL layer, which explains the difference you are observing. Additionally, we recommend updating to the latest RTD version whenever possible. This helps avoid known issues and ensures you benefit from the most recent fixes, enhancements, and improvements. BR, VaneB

无法调试 i.mxrt1064 自定义板。 您好， 在尝试以调试模式运行我的代码时，我收到"Break at address"0x20d102" with no debug information available" 信息。 我正在使用 i.mxrt1064 自定义板并使用 LinkServer LPC-Link2 进行编程。 这个主板以前可以正常工作了，但现在突然间，出现了这个消息。 我试过版本模式。我可以成功地用版本代码刷新我的主板，但是程序似乎无法运行。无论是从串行终端还是从显示屏，我都看不到任何输出。 我还尝试过使用安全配置工具对这个板进行编程，但它仍然无法正常工作。 有谁能帮助我们找到这个问题的重点或线索？ Re: Unable to debug i.MXRT1064 custom board. 你好，MayLiu、 感谢您的回复。 早些时候，我确实按照你的建议尝试了这种设置，但在尝试调试时，集成开发环境提示错误（未能执行 MI 命令：-target-download）。我附上了该错误的快照供你参考。 回到上一条信息，我想补充的是，当我检查当前程序的执行地址时，显示代码位于 ROM 区域（地址 0x20E35A）。因此，不知何故，代码无法到达/启动应用程序代码，并被卡在 ROM 中。我的假设正确吗？会有这种情况吗？ Re: Unable to debug i.MXRT1064 custom board. 你好@nxpsachve、 非常感谢您关注我们的产品并使用我们的社区。 1: 请尝试选择将应用程序链接到 RAM，然后重新调试。 mayliu1_1-1768964548758.png 如果您的应用程序可以从 RAM 成功运行，请将板设置为串行下载器模式，然后使用安全配置工具通过 UART1 或 USB1 对您的板进行编程。   如果你的应用程序无法运行，我建议你使用示波器来检查主板的开机顺序。   希望它能帮到你。 顺祝商祺！ MayLiu Re: Unable to debug i.MXRT1064 custom board. Hi MayLiu, 感谢您的建议。 我想检查一下 MCUXpresso 中是否有任何可以改变或影响启动 Conf 的设置/配置？只是为了排除 IDE 的可能性。 在串行下载模式下，链接服务器能够检测目标。 Re: Unable to debug i.MXRT1064 custom board. 你好@nxpsachve、 感谢您提供的最新信息。 根据您提供的信息，CPU 当前可能正在执行来自启动 ROM 的代码，而不是您的应用程序代码。   我建议检查启动CFG和启动模式引脚设置，确保设备配置为从用户闪存启动。   你也可以尝试将板设置为串行下载器模式，然后通过J-Link进行连接以确认调试器是否可以检测到目标并与目标通信。   顺祝商祺！ MatLiu Re: Unable to debug i.MXRT1064 custom board. 你好@nxpsachve、 我认为MCUXpresso IDE不会更改启动配置，恩智浦RT的启动行为由硬件启动配置和启动模式引脚决定。 由于可以在串行下载模式下检测到目标，这表明 ROM 仍在正常运行。下一步，您可以 执行全芯片擦除、 将板切换到内部启动模式，然后 尝试重新连接 MCUXpresso IDE 进行调试。 或者，您也可以使用 MCUXpresso 安全配置工具对应用程序映像进行编程。 顺祝商祺！ MayLiu

问题使用统一引导加载程序演示在 S32K144EVB 上安装 CAN + UDS 引导加载程序 你好，恩智浦社区、 我目前正在使用 S32K144EVB 板和 S32 Design Studio v3.4。我对汽车引导加载程序还不熟悉，我想实现一个基于 CAN + UDS 的引导加载程序。 我在这里找到了 " Unified Bootloader 演示 "： （参考：在恩智浦社区发布的统一引导加载程序演示 ） 统一引导加载程序演示 我的问题 如何使用 S32DS 3.4 为 S32K144EVB 目标正确移植/构建这个 Unified Bootloader？ 演示版是否已经支持 UDS 服务，如 RequestDownload (0x34)、TransferData (0x36) 和 RequestTransferExit (0x37)，还是需要手动扩展？ 在 S32K144 上进行此演示时，推荐的 CAN 传输层是什么（ISO-TP 与自定义）？ 是否有任何通过 CAN 实现 UDS 刷新的 S32K144 的官方恩智浦引导加载程序示例或 AN（应用笔记）？ 对于初学者来说，统一引导加载程序是推荐的方法还是 S32K144 引导加载程序还有其他更简单的参考设计？ 我的目标是使用 UDS 服务，通过 CAN 从 PC 工具执行固件刷新。任何文档方面的指导、示例或设置说明都将不胜感激。 目标详情： MCU：S32K144EVB IDE：S32DS 3.4 通信：CAN 所需的协议：UDS 传输 感谢您的支持。 谢谢、 Re: Question: CAN + UDS Bootloader on S32K144EVB using Unified Bootloader Demo 在不使用统一引导加载程序演示堆栈的情况下，是否有其他资源或方法可以实现这一任务，请为我提供指导。 Re: Question: CAN + UDS Bootloader on S32K144EVB using Unified Bootloader Demo 嗨，@NagulMeera、 很抱歉，社区上分享的统一引导加载程序只是非官方演示，不提供任何保证和支持。目前，我们还没有支持该演示的资源。我将尝试通过他们的文档回答您的问题，但如果出现后续问题，请联系他们的支持页面。 Q1.统一引导加载器演示项目发布已经有一段时间了。它将 S32DS 用于 ARM 2018.R1 和 SDK 2.0.0。如果您需要将其移植到 S32DS v3.4、你需要手动操作，或者尝试 " migrate " 选项，如以下视频所示：视频：将 S32K1 项目从 ARM 和 SDK 3.0.x 的 S32DS 迁移到 S32DS 3.4 和 SDK 4.0.2。 请注意，这是针对 SDK SW 的，如果使用 RTD，该选项可能无法正常工作。 Q2. & Q3. 您是否阅读过 统一引导加载器 - 用户指南& 它们的《UDS 引导加载器实施指南》？我可以从中看到，0x34、0x36& 0x37 服务已经实现： Julin_AragnM_0-1768933386437.png 此外，UBLUG 还提到以下内容："TP：当前版本的 TP 包括 CAN 和 LIN。CAN TP 基于 ISO15765-2，LIN TP 基于 ISO17987-2。" 。ISO15765-2 即 ISO-TP。 Q4。& Q5。有关基于 CAN 的固件更新，您可以参考以下应用笔记：AN12323：S32K1xx 固件更新 — 应用笔记。具体而言，场景（1）显示了如何通过CANFD接收新固件来处理固件更新的步骤。 致以最诚挚的问候， Julián Re: Question: CAN + UDS Bootloader on S32K144EVB using Unified Bootloader Demo 嗨，@NagulMeera、 是的。我在上次回复中分享了它们：AN12323：S32K1xx 固件更新 — 应用笔记。 它包括第 7.1.1 节中的引导加载程序演示。 该应用笔记还附带了 S32K144 开发板的可下载软件。请阅读有关项目的应用笔记。 致以最诚挚的问候， Julián

CSEC GenerateMACAddrMode アドレス範囲 メリークリスマス こんにちは CSECのGenerateMACAddrMode関数を使用していたところ、アドレス値が0x7DFFFを超えるとエラーが発生します。これは普通ですか？ Re: CSEC GenerateMACAddrMode address range 私のせい つまり512KBからCANができない CSEC_DRV_GenerateMACAddrMode(CSEC_RAM_KEY、(uint8_t *)0x0007FFFC、0x00000080、(uint8_t *)cmacout); ただし、addr = 0x0007FFFC、len = 0x00000080 を使用します エラーもありませんが、範囲外です Re: CSEC GenerateMACAddrMode address range こんにちは@SaLan これは、Addr モード（ポインター方法とも呼ばれます）の CMD_GENERATE_MAC コマンドの制限です。 lukaszadrapa_0-1767118666499.png パーティション（つまりブロックサイズは派生に応じて128KB、256KB、または512KBになります。 lukaszadrapa_1-1767118711782.png よろしくお願いいたします。 ルーカス

S32K3XXドライバ構成 S32K3XXシリーズチップの新規構築プロジェクトについてお伺いします。ドライバを使用する際に、各ドライバ（各ドライバタイプはポジション1に対応）の設定インターフェースにある各設定項目（ポジション3に表示）について解説したドキュメントやチュートリアルはありますか？実際のエンジニアリングアプリケーションでは、どのような情報を参考に設定すればよいでしょうか？設定するたびに設定項目名を見て機能を推測し、設定内容を決めています。公式の根拠が不足しているように感じ、それぞれの設定が非常に不確実で根拠がないと感じています。 Re: S32K3XX的drivers配置 こんにちは@Aaron_LL AN13435 の次のセクションでは、さまざまなコンポーネントについて説明します。 Senlent_0-1766973809123.png さらに、公式 Web サイトには周辺機器の設定トレーニング チュートリアルが多数用意されており、そこから見つけることができます。 https://www.nxp.com/products/S32K3 Senlent_1-1766973935410.png

LS1046A RDB：用于测试 linux gpio 中断处理性能的 GPIO 您好， 我正在使用 LS1046ARDB，想测量中断延迟。我的目标是通过外部信号发生器（输入 GPIO）触发信号中断，然后切换另一个引脚（输出 GPIO）作为响应，用示波器测量延迟。 我正在寻找板接头上可以混合为 GPIO 的可访问引脚。 我的想法是使用 IEEE-1588 接头 (J11)，但不确定这是否可行，也不知道需要做些什么。 参考手册指出，可以通过 RCW（EC2=1）将 EC2 引脚配置为 GPIO3。 如果我在 RCW 中设置 EC2=1，这些信号是否会路由到 J11？ LS1046A RDB 上是否有其他易于访问的引脚可供使用？ 感谢您的帮助 QorIQ LS1设备 Re: LS1046A RDB: GPIOs for testing gpio interrupt handling performance of linux 谢谢您的帮助！这应该行得通。我发现GPIO_2[1]、GPIO_2[2]、GPIO_2[3] 与 TP14、TP13 和 TP11 相对应。 Re: LS1046A RDB: GPIOs for testing gpio interrupt handling performance of linux 您可以使用与 SPI 信号复用的GPIO。 GPIO_2[1]、GPIO_2[2]、GPIO_2[3] SPI 接口在 RDB 上未使用，并终止到测试点。 请参阅"表 3-8。详情请参阅 LS1046ARM 中的 SPI 信号配置" 。

K344 中心点対 PWM 中心点起動 ADC BCTU サンプリング https://community.nxp.com/t5/S32K-Knowledge-Base/RTD400-K344-Center-Aligned-PWM-Trigger-ADC-BCTU/ta-p/2034211に基づき、BCTU ウォーターマークをトリガーするのに 3 つの BCTU トリガー割り込みが必要な理由を知りたいです。割り込みを 1 回だけトリガーし、その後、割り込み内で PWM 周期の変更、ADC 値の読み取りなどを実行したいと考えています。EB MCAL 開発に基づいて、同じ機能を実現するための優れたソリューションやサンプルルーチンは何ですか? Re: K344中心对齐PWM中心点触发ADC BCTU采样 当社製品にご興味をお持ちいただき、また当社コミュニティに貢献していただき、ありがとうございます。 投稿に直接返信して、投稿の所有者からのフィードバックを得ることができます。 一方、単一の BCTU トリガーを使用した別のアプローチを参照することもできます。 S32M27x/S32K3 – eMIOS/BTCU/ADC/DMA – [RTD600] -> https://community.nxp.com/t5/S32M-Knowledge-Base/S32M27x-S32K3-eMIOS-BTCU-ADC-DMA-RTD600/ta-p/2155542 MCAL 実装については、ハードウェア抽象化レイヤーのADC から PWM の例を参照してください。 S32K3ページへ移動-> 設計リソース -> ソフトウェア -> S32K3リファレンスソフトウェア -> オートモーティブソフトウェア - S32K3 - ハードウェア抽象化レイヤー -> S32K3 HAL統合例 2025.07 次の ADC トリガーを実行します。 _Leo__0-1764612607002.png 同時に、キャプチャされた ADC 値に応じてデューティ サイクルを更新します。 この情報が役に立つことを願います。 Re: K344中心对齐PWM中心点触发ADC BCTU采样 解決策をありがとうございます。複数のトリガー中断が発生する理由と、そのような中断を回避する方法を知りたいです。または、設定によってこの割り込みソースを無効にすることは可能ですか? Re: K344中心对齐PWM中心点触发ADC BCTU采样 こんにちは、 BCTU トリガー通知が有効になっている場合、BCTU が ADC をトリガーしたときに呼び出されます。例では、BCTU CL に 3 つの項目が含まれているため、ADC は入力 (eMIOS) トリガーごとに 3 回トリガーされます。 この通知を無効にするには、トリガー通知オプションに NULL を設定します。 BR、ペトル

異なる DDR サイズに応じて i.MX8MP の予約メモリを調整するにはどうすればよいでしょうか? NXPエキスパートの皆様、こんにちは。 コミュニティ全体を検索しましたが、満足のいく答えは見つかりませんでした。 以下はNXPのLinux 6.12のimx8mp.dtsiの予約メモリノードです。 予約メモリ { #アドレスセル = <2>; #size-cells = <2>; 範囲; /* * optee の使用のために予約されたメモリ。使用しないでください。 * OP-TEE がインストールされている場合は、これが dtb に自動的に追加されます。 * optee@56000000 { * reg = <0 0x56000000 0 0x2000000>; * マップなし; * }; */ /* 連続した割り当てのためのグローバル自動構成領域 */ Linux、cma { compatible = "共有DMAプール"; 再利用可能 サイズ = <0 0x3c000000>; 割り当て範囲 = <0 0x40000000 0 0xC0000000>; linux、cma-デフォルト; }; GPU予約済み: GPU予約済み@100000000 { マップなし; レジスタ = <0x1 0x00000000 0 0x10000000>; }; dsp_reserved: dsp@92400000 { レジスタ = <0 0x92400000 0 0x1000000>; マップなし; }; dsp_reserved_heap: dsp_reserved_heap@93400000 { レジスタ = <0 0x93400000 0 0xef0000>; マップなし; }; dsp_vdev0vring0: vdev0vring0@942f0000 { レジスタ = <0 0x942f0000 0 0x8000>; マップなし; }; dsp_vdev0vring1: vdev0vring1@942f8000 { レジスタ = <0 0x942f8000 0 0x8000>; マップなし; }; dsp_vdev0バッファ: vdev0バッファ@94300000 { compatible = "共有DMAプール"; レジスタ = <0 0x94300000 0 0x100000>; マップなし; }; }; 1.2GB/4GB/8GB DDR サイズの i.MX8MP の reserved-memory/linux,cma/size と reserved-memory/linux,cma/alloc-ranges を調整するにはどうすればよいでしょうか?(サイズ(960MB)は2GB DDRには大きすぎること、割り当て範囲も2GB DDRの範囲外であることは明らかです) 2.linux,cma/size と linux,cma/alloc-ranges を除いて、DDR サイズ 2GB/4GB/8GB に応じて変更する必要がある他のプロパティはありますか? 3. gpu_reserved ノードの reg が 2GB ddr の範囲外であることは明らかですが、どのように変更すればよいでしょうか? NXP の linux6.12 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts で、reserved-memory/linux,cma/size&alloc-ranges が変更されていることがわかります。 予約メモリ { #アドレスセル = <2>; #size-cells = <2>; 範囲; /* 連続した割り当てのためのグローバル自動構成領域 */ Linux、cma { compatible = "共有DMAプール"; 再利用可能 サイズ = <0 0x38000000>; 割り当て範囲 = <0 0x40000000 0 0xB0000000>; linux、cma-デフォルト; }; }; 4.この変更のきっかけは何ですか?これは DDR サイズの違いによるものでしょうか? また、NXP の Linux 6.12 arch/arm64/boot/dts/freescale/imx8mp-evk-root.dts では、node/reserved-memory がさらに変更されていることにも気付きました。 &{/予約メモリ} { jh_reserved: jh@fdc00000 { マップなし; レジスタ = <0 0xfdc00000 0x0 0x400000>; }; loader_reserved: loader@fdb00000 { マップなし; レジスタ = <0 0xfdb00000 0x0 0x00100000>; }; ivshmem_reserved: ivshmem@fda00000 { マップなし; reg = <0 0xfda00000 0x0 0x00100000>; }; ivshmem2_reserved: ivshmem2@fd900000 { マップなし; reg = <0 0xfd900000 0x0 0x00100000>; }; pci_reserved: pci@fd700000 { マップなし; レジスタ = <0 0xfd700000 0x0 0x00200000>; }; 受刑者予約: 受刑者@c0000000 { マップなし; レジスタ = <0 0xc0000000 0x0 0x3d700000>; }; }; &{/予約メモリ/linux,cma} { サイズ = <0 0x28000000>; 割り当て範囲 = <0 0x40000000 0 0x60000000>; }; 5. 新しく追加されたノード jh_reserved/loader_reserved/ivshmem_reserved/ivshmem2_reserved/pci_reserved/inmate_reserved はどのような状況で使用する必要がありますか? 上記の疑問について詳しく説明してください。 i.MX 8M | i.MX 8M ミニ | i.MX 8M ナノ Re: How to adjust i.MX8MP's reserved-memory accroding different DDR size? こんにちは、ホルヘ・カスさん。 ご協力誠にありがとうございます。Quction6についてはまだ疑問があります。 2GB/4GB/8GB DDR を搭載したカスタム imx8mp ボード (6GB DDR を搭載した imx8mpevk ボードに基づく) では、異なる DDR サイズの各ボードごとに個別の u-boot.imx があり、linux6.12 ソース コードの imx8mp-evk.dts から次の ' memory@40000000' ノードを変更せずに保持します。 メモリ@40000000 { device_type = "メモリ"; レジスタ = <0x0 0x40000000 0 0xc0000000>, <0x1 0x00000000 0 0xc0000000>; //3GB+3GB=6GB }; そして、弊社の imx8mp ボードは正常に動作します。また、彼らは一晩のテストに合格することもできます。 以下は 4GB DDR を搭載した imx8mp ボードです。 root@router:/#無料 使用可能な使用済み無料共有バフ/キャッシュの合計 Mem: 3686580 159528 2914044 19536 613008 3458156 // 4GB DDR の場合、合計 3686580 KB を認識するのが妥当です。 スワップ: 0 0 0 root@router:/# /プレスリリース、製品ニュース/MCB2/memtester 3G memtester バージョン 4.3.0 (32 ビット) 著作権 (C) 2001-2012 Charles Cazabon。 GNU General Public License バージョン 2 (のみ) に基づいてライセンスされます。 ページサイズは4096です ページサイズマスクは0xfffff000です 3072MB（3221225472バイト）必要 3072MB (3221225472 バイト) を取得しました。mlock を試行しています...ロックされました。 ループ1: スタックアドレス: テスト3[3326.210063] clean_cache.sh (100707): drop_caches: 1 [ 3326.277139] clean_cache.sh (100707): drop_caches: 2 [ 3326.316299] clean_cache.sh (100707): drop_caches: 3 わかりました ランダム値: OK XOR比較: OK 比較SUB：OK MULを比較: OK DIVを比較: OK 比較OR：OK ANDを比較: OK 順次増分: OK ソリッドビット：OK ブロックシーケンシャル：OK チェッカーボード：OK ビットスプレッド：OK ... // 一晩のテストでは問題は見つかりませんでした。 4GB DDRデバイスのカーネル起動段階のメモリ情報は次のとおりです。 [ 0.000000] マシンモデル: NXP i.MX8MPlus EVKボード [ 0.000000] efi: UEFI が見つかりません。 [ 0.000000] 予約メモリ: 0x00000000c4000000 に CMA メモリプールを作成しました。サイズは 960 MiB です。 [ 0.000000] OF: 予約済みメモリ: 初期化されたノード Linux、cma、互換ID 共有DMAプール [ 0.000000] OF: 予約済みメモリ: 0x00000000c4000000..0x00000000ffffffff (983040 KiB) マップ再利用可能 Linux,cma [ 0.000000] OF: 予約済みメモリ: 0x0000000057c00000..0x0000000057ffffff (4096 KiB) nomap 再利用不可 optee_shm@0x57c00000 [ 0.000000] OF: 予約済みメモリ: 0x0000000056000000..0x0000000057bfffff (28672 KiB) nomap 再利用不可 optee_core@0x56000000 [ 0.000000] OF: 予約済みメモリ: 0x0000000100000000..0x000000010ffffffff (262144 KiB) nomap 再利用不可 gpu_reserved@100000000 [ 0.000000] OF: 予約済みメモリ: 0x0000000092400000..0x00000000933fffff (16384 KiB) nomap 再利用不可 dsp@92400000 [ 0.000000] OF: 予約済みメモリ: 0x0000000093400000..0x00000000942effff (15296 KiB) nomap 再利用不可 dsp_reserved_heap@93400000 [ 0.000000] OF: 予約済みメモリ: 0x00000000942f0000..0x00000000942f7fff (32 KiB) nomap 再利用不可 vdev0vring0@942f0000 [ 0.000000] OF: 予約済みメモリ: 0x00000000942f8000..0x00000000942fffff (32 KiB) nomap 再利用不可 vdev0vring1@942f8000 [ 0.000000] 予約メモリ: 0x0000000094300000 に DMA メモリプールを作成しました。サイズは 1 MiB です。 [ 0.000000] OF: 予約済みメモリ: 初期化されたノード vdev0buffer@94300000、互換性のあるIDは共有DMAプール [ 0.000000] OF: 予約済みメモリ: 0x0000000094300000..0x00000000943fffff (1024 KiB) nomap 再利用不可 vdev0buffer@94300000 [ 0.000000] NUMA: [mem 0x0000000040000000-0x000000013fffffff] でノードを偽装しています [ 0.000000] NODE_DATA(0) 割り当て済み [mem 0x13f84a840-0x13f84d3bf] [ 0.000000] ゾーン範囲: [ 0.000000] DMA [メモリ 0x0000000040000000-0x00000000ffffffff] [ 0.000000] DMA32 空 [ 0.000000] 正常 [メモリ 0x0000000100000000-0x000000013ffffffff] [ 0.000000] 各ノードの移動可能ゾーンの開始 [ 0.000000] 初期メモリノード範囲 [ 0.000000] ノード 0: [メモリ 0x0000000040000000-0x0000000055ffffff] [ 0.000000] ノード 0: [メモリ 0x0000000058000000-0x00000000923fffff] [ 0.000000] ノード 0: [メモリ 0x0000000092400000-0x00000000943fffff] [ 0.000000] ノード 0: [メモリ 0x0000000094400000-0x00000000ffffffff] [ 0.000000] ノード 0: [メモリ 0x0000000100000000-0x000000010fffffff] [ 0.000000] ノード 0: [メモリ 0x0000000110000000-0x000000013ffffffff] [ 0.000000] 初期化メモリ セットアップ ノード 0 [メモリ 0x0000000040000000-0x000000013fffffff] [ 0.000000] ノード0のゾーンDMA: 使用できない範囲に8192ページ 1.実際には 4GB DDR デバイスの memory@40000000 ノードの6GB reg 構成によって発生した不合理なログを特定できますか? 2.SO、カーネルはDTSのmemory@40000000/reg構成のみに基づいてメモリ範囲を計算しているのではなく、U-BootからATAGを介してカーネルに渡される実際の物理メモリサイズと合わせて、包括的にメモリ範囲を決定しているのではないかと推測しています。つまり、2GB/4GB/8GBのメモリ構成ごとに別々のDTBファイルを用意する必要はないのではないかと考えています。この点についてご確認いただけますでしょうか？ 改めて感謝申し上げます。 Re: How to adjust i.MX8MP's reserved-memory accroding different DDR size? こんにちは、 1. デバイス ツリー内の予約済みメモリ ノードを調整するための具体的なドキュメントはありません。これらの値は DDR サイズとアプリケーションによって異なるためです。唯一の制限は、リファレンス マニュアルのメモリ マップに記載されているように、各モジュールに割り当てられた最大メモリ領域になります。 BSP のデフォルトの CMA サイズは 960 MB CAN が、2GB DDR の場合、960 MB は大きすぎるため、CMA を 256 MB ～ 512 MB 程度に減らすのが一般的です。有効な DDR スペースでの割り当てに重点を置く必要があります。 2. 追加のプロパティを追加する必要はありません。 3. 設計で使用可能なサイズに応じて各ノードを再編成できます。例: gpu_reserved: gpu_reserved@70000000 { no-map; reg = <0 0x70000000 0 0x10000000>; }; 他も同様です。 4. このデバイス ツリーは、ハイパーバイザーの予約済みメモリに使用されます。 5. これらのノードは Jailhouse/PCIe/仮想化に使用されますが、使用しない場合はこれらのノードを省略できます。 詳細については、このドキュメントをCAN参照できます。 i.MX 仮想化ユーザーガイド 6. はい、各 DDR サイズに一致するはずです。 よろしくお願いいたします。 Re: How to adjust i.MX8MP's reserved-memory accroding different DDR size? 質問6：（追加 ） メモリ@400000000ノード(arch/arm64/boot/dts/freescale/imx8mp-evk.dts内)のregプロパティはDDR容量（2GB/4GB/8GB）に応じて変更する必要がありますか？ メモリ@40000000 { device_type = "メモリ"; レジスタ = <0x0 0x40000000 0 0xc0000000>, <0x1 0x00000000 0 0xc0000000>; }; はいの場合、異なる DDR サイズのカスタム i.MX8MP ボードには個別の DTB ファイルが必要であることを意味しますか? 事前に考えます！ Re: How to adjust i.MX8MP's reserved-memory accroding different DDR size? こんにちは、ホルヘ・カスさん。 カーネルは U-boot から渡された DDR サイズを使用するので、DTS で memory@40000000/reg を構成する目的は何ですか? Re: How to adjust i.MX8MP's reserved-memory accroding different DDR size? こんにちは、 情報ありがとうございます。 1. エラーや警告などの重大なログはなく、カーネルは U-boot から利用可能なメモリ範囲を使用するだけです。 2. カーネルでは U-boot と DTS の両方の構成が使用されます。 デバイス ツリーでは、物理メモリが十分でない場合でも仮想メモリをさらに割り当てることができますが、RAM の使用量が多いとシステムがクラッシュする可能性があります。 よろしくお願いいたします。 Re: How to adjust i.MX8MP's reserved-memory accroding different DDR size? こんにちは、 社内チームに確認しました。 U-boot 構成には、使用可能な物理 DDR メモリに関する正しいデータが含まれていますが、DTS 予約メモリ ノードもカーネルに渡されます。あなたのCASE、ノードにさらに仮想メモリを割り当てることができますが、物理予約メモリをすべて使い切ると、使用可能なメモリがないためエラーが発生し、物理アドレスが存在しない、または他のモジュールによって使用される可能性があるためにリソースの問題が発生します。 予約メモリを各ボードに適合させる必要があります。おっしゃるとおり、これは機能しますが、RAM の使用量が多い場合は、エラーやカーネル パニックが発生する可能性があります。 前回の返信を訂正させていただきます。 よろしくお願いいたします。

S32G2 IPC通信 NXPコミュニティの親愛なるメンバーの皆様、 私はちょうどNXP S32G2 IPCフレームワークに取り組み始めました。私は次のアプリケーションノートAN13750ています:「S32G2でのマルチコアアプリケーションの有効化 using S32G2 Platform Software Integration」と題し、いくつかの疑問を抱きました。 まず、ドキュメントからの流れを正しく理解しているかどうか 1. IPCを使用してLinuxイメージをビルドし、SDカードを使用してA53コアを起動します。 2. Design Studio を使用して M7 の IPC イメージをビルドし、ブートローダーを使用して M7 を SRAM に読み込みます。ブートローダーはEB Tresosによって提供されます。 3. A53からM7でIP通信を開始します。 上記の理解が正しいことを前提として、 1. デバッガを使用して、デザインスタジオからM7アプリケーションを直接実行できますか。 2. LinuxイメージをA53のSDカードから起動させます。 3. A53 linuxからM7とのIPC通信を開始します。 これは可能ですか?私は今のところEBブートローダーを扱いたくありませんが、プロセス全体についての私の理解が間違っていて、このブートローダーがIPCの機能にとって重要である場合を除きます。どんなコメント/提案も大歓迎です。 PS:アプリケーションノートで使用されている3つのコアではなく、1つのM7コアのみを使用したいです。 最良 ヴィシュヌ Re:S32G2 IPC通信 編集:「Description.txt」

Latest version of AN4581 Hi, There is a AN4581 (i.MX Secure Boot on HABv4 Supported Devices) Rev. 4 from 2020: https://de.scribd.com/document/811030804/AN4581 However If I search your website or the internet, I can only find outdated versions from 2012 or 2018. Can you tell me where I can find the latest revision of AN4581? Thanks Re: Latest version of AN4581 Thank you for your support. I was able to download the 2020 version here: https://www.readkong.com/page/an4581-i-mx-secure-boot-on-habv4-supported-devices-2622907 The old versions are available without NDA here: https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/225997/1/AN4581.pdf (2012) https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/194321/1/AN4581_2018.pdf (2018) Re: Latest version of AN4581 This AN for secure boot is confidential, you need to sign an NDA with NXP. It's better to create an internal ticket from https://support.nxp.com/s/?language=en_US

Kinetis 器件的复位引脚建议 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嘿，Kinetis 爱好者们！我们 Kinetis 微控制器系统工程团队了解客户遇到的各种情况，但没有一种情况像复位引脚的处理那样特别麻烦。本文档的目的是提供我们在 Kinetis 系统工程部门收到的常见问题 (FAQ) 列表。这是一个动态列表，因此可能并不完整。然而，我们希望您发现以下问题和答案很有用。 问：我需要连接复位信号才能调试 Kinetis 设备吗？ 这是一个常见的问题。严格来说，您不需要将 Kinetis 设备的设备复位线连接到调试连接器即可进行调试。调试端口 MDM-AP 寄存器允许通过仅使用 SWD_CLK 和 SWD_DIO 线设置系统复位请求位来使处理器保持复位状态。 但是，在决定从调试连接器中省略复位线之前，您应该仔细考虑这可能会如何影响在某些情况下对设备进行编程和调试的能力。 调试器/闪存编程器或外部调试器是否需要复位引脚？您使用的特定工具可能仅支持通过重置线重置设备，而不提供通过 MDM-AP 重置设备的功能。 您是否更改了调试信号的默认功能？您可能需要在应用程序中使用 SWD_CLK 和/或 SWD_DIO 信号来实现其他功能。对于低引脚数封装来说尤其如此。一旦功能发生变化（通过 PORTx_PCRy 寄存器），您将无法再通过这些信号访问 MDM-AP。如果您无法访问重置信号，那么您就无法阻止核心执行禁用引脚 SWD 功能的代码。因此您将无法重新编程该设备。为了防止这种情况，您需要： 设置您的代码以在复位释放几秒钟后更改 SWD 引脚的功能，以便调试器可以在发生这种情况之前停止核心。 在您的代码中放置某种“后门”机制，不会在这些引脚上重新编程 SWD 功能或重新启用 SWD 功能。例如，通过 UART 或 SPI 接口发送的特定字符序列。 一些 Kinetis 设备允许禁用复位引脚的复位功能。在这种情况下，您只能使用 SWD 信号作为通过 MDM-AP 重置设备的一种方式。如果您除了禁用复位引脚之外还更改了 SWD 引脚功能，那么如果您想对设备进行重新编程，就必须提供重新启用 SWD 功能的后门方法。 Kinetis硬件支持 Kinetis K系列MCU Kinetis L系列MCU Kinetis V系列MCU/单片机 Kinetis W系列MCU

PHY3250ブートローダーの復元 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Phytec LPC3250ボード上の キックスタート または S1L ブートローダーを誤って消去し てしまった場合は、この手順を使用してそれらを復元できます。 この復元方法で提供されるブートローダーは、Phytecボードに付属するバージョンよりも新しい可能性があることに注意してください。ブートローダーのオリジナルバージョンは、PhytecのWebサイトからもダウンロードできます。 ボード上のブートローダの復元には特別なハードウェア(JTAGなど)は必要なく、LPC32x0共通ドライバライブラリにビルドまたは含まれているブートローダとツールを使用して実行されます。ただし、アップデート手続きを行うには、シリアルポート付きのPCが必要です。 キックスタート ローダーと S1L の復元 は、2段階のプロセスです。 キックスタート ローダーが最初に復元され、次に S1L が復元されます。シリアルローダーは、アプリケーションとバーナーイメージ(アプリケーションをNANDFLASHにプログラムするために使用されます)を転送するために使用されます。LPC32x0は、ダウンロード後に画像を自動的にNANDフラッシュに書き込み、ステータスを提供します。 ステップ1:リソースページのビルド済みブートソフトウェアと復元イメージをダウンロードします。 ステップ2:WindowsベースのPCでファイルを抽出します ステップ3:Phytecボードの下部シリアルコネクタとPCの間にシリアルケーブルを接続します ステップ4:シリアルローダーソフトウェアを起動します(LPC3250_Loader.exe)ビルド済みのブートソフトウェアパッケージに含まれています。 ステップ5:シリアルローダーの「プライマリブート(IRAM)」ファイルをburner_kickstart_nand_small_block_rvw.binファイルに設定します。シリアルローダーの「Secondary Executable (SDRAM)」ファイルをkickstart_nand_small_block_rvw.binファイルに設定します。Comport コントロールの選択が、Phytec ボードに接続されている PC の COM パーツと一致していることを確認します。 注: ビルド済みのバイナリの名前は、バイナリのビルドに使用したツールによっては、手順 5 と 7 に記載されている名前と若干異なる場合があります。バイナリが Realview ではなく GNU でビルドされた場合、各名前の 'rvw' フィールドには、代わりに識別された 'gnu' が含まれます。必要に応じて、お持ちのバイナリのファイル名を変更してください。   ステップ6:シリアルローダーの「Load bin's / Start primary」ボタンを押して、ボードの電源を入れます。バーナー イメージとキックスタート ローダー イメージがボードに転送され、キックスタート ローダーはバーナー アプリケーションによってブート ROM からブートするために NAND FLASH ブロック 0 にプログラムされます。ファイルが転送されたら、「ターミナルモードを有効にする」ボタンを押してプログラムのステータスを確認します。シリアルローダーツールの[ステータス/ターミナル出力]ウィンドウに、次の出力が表示されます。   BootIDを待っていますか?..þ5 ..設立する！「A」を送信しています。完成です！2番目のBootIdを期待しますか?..5 ..設立する！'U','3'..完成です！「R」を期待してください.。R ..設立する！startaddress .. を送信しています。完成です！送信サイズ ..完成です！コードを送信しています..完成です！--- セカンダリ実行可能ファイルのロード--- 「X」を待ちます。X ..設立する！-- コマンドを送信しています ..p ..完成です！ startaddress .. を送信しています。完成です！送信サイズ ..完成です！プライマリブートからの受け入れを待ちます..o ..わかりました！ コードを送信しています..完成です！最終的な 't' を期待してください ..t ..設立する ---- セカンダリ実行可能ファイルがロードされました。--- --- ターミナルモードの有効化 --- ブロックをフォーマットしています... フォーマットが完了 キックスタートをフラッシュに書き込んでいます... データの検証......首尾良く NANDフラッシュが正常にプログラムされています ステップ7:シリアルローダーの「プライマリブート(IRAM)」ファイルをburner_s1app_nand_small_block_rvw.binファイルに設定します。シリアルローダーの「Secondary Executable (SDRAM)」ファイルをs1l_from_kick_full_rvw.binファイルに設定します。Comport コントロールの選択が、Phytec ボードに接続されている PC の COM パーツと一致していることを確認します。   ステップ8:シリアルローダーの「Load bin's / Start primary」ボタンを押して、ボードをリセットします。バーナーイメージと S1L イメージがボードに転送され、 S1L はキックスタートローダーからブートするためにNANDFLASHブロック1(およびそれ以降)にプログラムされます。ファイルが転送されたら、「ターミナルモードを有効にする」ボタンを押してプログラムのステータスを確認します。シリアルローダーツールの[ステータス/ターミナル出力]ウィンドウに、次の出力が表示されます。   BootIDを待っていますか?..5 ..設立する！「A」を送信しています。完成です！2番目のBootIdを期待しますか?..5 ..設立する！'U','3'..完成です！「R」を期待してください.。R ..設立する！startaddress .. を送信しています。完成です！送信サイズ ..完成です！コードを送信しています..完成です！--- セカンダリ実行可能ファイルのロード--- 「X」を待ちます。X ..設立する！-- コマンドを送信しています ..p ..完成です！ startaddress .. を送信しています。完成です！送信サイズ ..完成です！プライマリブートからの受け入れを待ちます..o ..わかりました！ コードを送信しています..完成です！最終的な 't' を期待してください ..t ..設立する ---- セカンダリ実行可能ファイルがロードされました。--- --- ターミナルモードの有効化 --- ブロックをフォーマットしています... フォーマットが完了 S1 画像をフラッシュに書き込みています... NANDフラッシュが正常にプログラムされています ステップ8:シリアルローダーを閉じてターミナルプログラムを開き、ボードをリセットします シリアルローダツールを閉じて、Teratermなどのターミナルプログラムを開きます。ボードをリセットすると、 S1L が起動するはずです。   5 Phytec 3250ボード ビルド日: May 21 2010 12:43:21 PHY3250>

FTF-ACC-F1259 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 同步多线程 (SMT) 是一种先进的处理器微架构功能，它允许独立执行线程更有效地利用超标量 CPU 管道组织。双向超标量流水线中的 SMT 实现以相对较小的增量动态功耗最大化双线程并发性。本次会议重点关注下一代 Power Architecture e200z9 处理器核心中包含的 SMT 功能，以及通过该微架构可实现的改进的性能/功率指标。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 同步多线程 (SMT) 是一种先进的处理器微架构功能，它允许独立执行线程更有效地利用超标量 CPU 管道组织。双向超标量流水线中的 SMT 实现以相对较小的增量动态功耗最大化双线程并发性。本次会议重点关注下一代 Power Architecture e200z9 处理器核心中包含的 SMT 功能，以及通过该微架构可实现的改进的性能/功率指标。 回复：FTF-ACC-F1259 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 新款e200z9什么时候上市？

FTF-INS-F1277 Automotive integrated circuits are requiring high temperature and high voltage application environments. High temperature and high voltage impose severe constraints on the design of IC interconnect and the materials used in the assembly and packaging processes. The use of fine gauge copper wire bonding has been growing very rapidly in consumer, portable, and industrial electronics. Freescale has made significant inroads in introducing and accelerating the adoption of fine gauge copper wire in the high reliability automotive space. The molding compounds were studied and reformulated to accommodate high voltage up to 65V. This presentation will discuss key learnings in copper wire bonding process and molding compound formulation development, and present an exciting update on Freescale strategy on gold to copper wire conversion. Automotive integrated circuits are requiring high temperature and high voltage application environments. High temperature and high voltage impose severe constraints on the design of IC interconnect and the materials used in the assembly and packaging processes. The use of fine gauge copper wire bonding has been growing very rapidly in consumer, portable, and industrial electronics. Freescale has made significant inroads in introducing and accelerating the adoption of fine gauge copper wire in the high reliability automotive space. The molding compounds were studied and reformulated to accommodate high voltage up to 65V. This presentation will discuss key learnings in copper wire bonding process and molding compound formulation development, and present an exciting update on Freescale strategy on gold to copper wire conversion.

【恩智浦微控制器简介】【电机控制】【实践篇 2】永磁同步电机的机理及控制方法（日文博客） [实验0_2] 环境搭建 + 运行电机示例代码②   目录   5. 软件安装 5-1。启动 MCUXpresso 5-2。从 SDK 导入示例演示 5-3。从调试模式切换到发布模式 5-4. 建设项目 5-5. Flash编程 6. 连接到实时调试工具 运行演示 7. 操作检查和故障经验 8. 调试 9. 部分软件代码的解释 10. 总结与预览   5. 软件安装 接下来，我们将从工程师的角度详细解释实际设置开发环境和运行示例代码的过程。 为了帮助即使是第一次来的游客也能避免迷路，我们将介绍一些常见的陷阱和有用的技巧。 5-1。启动 MCUXpresso 首先，启动 IDE（MCUXpresso）。 安装完成后，会立即出现“欢迎屏幕”，请从这里开始。 image-12.png 提示 ：首次启动可能需要一些时间，请耐心等待！ 5-2。从 SDK 导入示例演示 SDK（软件开发工具包）包含许多示例项目。 这次我们将使用名为“mc_pmsm_enc”的示例来控制带编码器的永磁同步电机。 image-13.png 选择“MCXA156” 选择“frdmmcxa156” 点击“下一步” 在“示例”列中搜索“pmsm”，并选中“mc_pmsm_enc”。 点击“完成”以完成导入！ image-14.png 提示 ：如果您不确定样品名称，请尝试搜索“pmsm”或“motor”，以便更容易地找到它。   5-3。从调试模式切换到发布模式 项目导入完成后，首先切换到“发布”版本。 调试版本也能用，但发布版本优化得更好，更适合在真机上运行。 使用 USB 电缆将 MCU-Link 连接器连接到 PC。 点击“建造”图标开始建造！ 接下来，点击“GUI Flash Tool”图标 image-21.png 点击 在写入闪存之前，请确保调试器已被正确识别。 image-22.png image-23.png 故障排除 如果调试器无法识别，拔下并重新插入 USB 电缆或重新启动电脑可能会解决问题。   5-4. 建设项目 构建完成后，将在项目的“Release”文件夹中生成一个二进制文件。 如果出现错误，请再次检查 SDK 版本和导入步骤。   5-5. Flash编程 使用“GUI Flash Tool”向目标板写入数据。 编写完成后，您终于可以在实际设备上运行示例了！ 6. 连接到实时调试工具 接下来，我们将使用 FreeMASTER (MCAT) 实时观察电机状态。 在 IDE 的“项目资源管理器”中，双击 motor_control 文件夹中的 pmsm_float_enc.pmpx 以启动 FreeMASTER。 image-24.png 体验 当我第一次看到波形实时移动时，我惊叹不已，脱口而出“哇！”   与董事会沟通 点击左上角的绿色“开始！”按钮即可开始通讯。 如果您无法正常沟通， 在“项目”菜单→“选项”→“通信”选项卡中选择正确的 COM 端口（115200bps）。 image-26.png 尖端 如果您不知道 COM 端口，请尝试“COM_ALL”，它可能会自动检测！ 运行演示 演示终于开始了！ 按下主机板上的SW2按钮，电机就会开始旋转。 速度屏幕以图表形式显示实际旋转速度，以便您可以一目了然地看到运动情况。 image-27.png image-28.png 令人印象深刻的是 ：当马达第一次转动时，我忍不住大喊：“耶！” 实时观察图表的变化也很有趣！ 7. 操作检查和故障经验 关闭演示程序，然后断开电机电源（DC24V）。 MCAT屏幕将显示故障原因，主机板上的红色LED指示灯将闪烁。 image-30.png image-31.png 重新接通电源，LED 停止闪烁后，点击“M1 故障清除”清除故障。 重要提示 ：如果故障仍然存在，电机将无法运转，因此请务必清除故障。 自由控制电机转速！ 当您在“速度”屏幕上打开“M1应用程序开关”时， 应用程序启动后，您可以根据需要更改速度。 如果你想朝相反的方向旋转，只需输入一个负值，例如“-1000”！ image-32.png 玩法说明： 您可以尝试不同的速度和反转旋转，体验电机控制的乐趣！ 如果我与董事会沟通出现问题怎么办？ 如果您无法使用 FreeMASTER 与电路板通信， 转到“项目”菜单 → “选项” → “通信”选项卡，设置正确的 COM 端口和波特率 (115200bps)。 如果您不知道 COM 端口，可以尝试“COM_ALL”！ 8. 调试 调试功能允许您详细观察程序的运行情况。 设置断点以检查变量值和处理流程。 给初学者的建议 我们建议您从行为容易理解的区域开始调试，例如“主函数”或“中断处理”。 9. 部分软件代码的解释   项目详情 接下来，我们将向工程师们解释实际的项目结构和主要源代码。 image-15_.png 项目结构 自由大师 一款实时调试监视器和数据可视化工具，支持运行时配置和调优。通过 UART/USB 通信，并包含 MCAT 插件。 电机控制 包括电机状态机、矢量控制代码、电机识别程序和底层驱动程序。 rtcesl 一系列用于复杂实时控制应用（包括电机控制）的数学库，涵盖从高级变换到观察器等各种功能。 来源 主要处理、初始化、配置等。 主处理和中断 main.c 执行初始化、中断设置和 FreeMASTER 通信等后台任务。 中断处理程序有两种类型：高速（ADC 同步）和低速（定时器同步）。 高速回路是矢量控制算法，低速回路是速度控制和 LED 状态管理。 要点 ： “motor_control” 文件夹包含电机控制逻辑。 如果您发现感兴趣的函数或变量，请务必查看注释和文档！ 10. 总结与预览 这次，我们有机会体验使用 NXP 的开发环境运行电机控制示例。 在下一期中，我们将深入研究示例代码，并尝试修改参数来创建您自己的电机控制系统！ （预计四月发布） 如果您有任何疑问或不理解的地方，请在评论区留言！ 这是一个汇总了有关恩智浦电机控制文章的网站： NXP电机控制 - 概要页面 - （日语博客） ============================​ 进行咨询时，请同时参考“如何就技术问题联系 NXP（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有业务往来，您可以直接联系负责人。） 本文将以浅显易懂的方式讲解如何使用NXP FRDM控制板“FRDM-MCXA156”进行电机控制。文章分为基础知识部分和实践部分，您可以先选择感兴趣的部分进行阅读。 ・基础知识①～⑦，实践①～③ 这次，作为实践部分的第二部分，我们将介绍从软件设置到实际运行电机控制示例代码的所有内容。 MCUXpresso 配置工具 MCUXpresso IDE MCUXpresso SDK MCX 电机控制 技术聚焦 日本博客