Developing a Steering System with Model-Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction The steering system is an essential and safety-critical component of any vehicle, responsible for controlling the direction of wheel movement and guiding the vehicle along the intended path. In our Hello World with MBDT project, the Steering subsystem delivers this capability by driving a steering motor to a desired angle and direction, transmitting the resulting torque to the road wheels through the steering column and rack-and-pinion assembly. Figure 1. Hello World with MBDT Demo – Steering system This article series presents the Electric Power Steering (EPS) system in Electric Vehicle (EV) architecture and covers the hardware, software, code generation, and vehicle network integration needed to implement the system using a Model-Based Design (MBD) workflow with MathWorks tools and NXP hardware. 3 Overview 2.1. What will this series of articles cover? The articles in this series will present the Steering System within an EV architecture and cover the following topics: Software and Hardware Environment Overview of the MathWorks and NXP tools used to develop, test, and validate the EPS control system. Logic Control Description of the model architecture, signal interfaces, and core control algorithms implemented in the Steering System. Deployment on Real Hardware Integration with physical hardware, the stepper motor, and configuration of the NXP MCU peripherals required for motor control. CAN Integration Definition of the CAN communication interface, including database design and integration on the target NXP platform. System Validation Presentation of the final implementation results and validation of the complete system behavior. 2.2. What is the Electric Power Steering System? Electric Power Steering (EPS) eliminates the hydraulic pump found in conventional steering systems, instead relying on an electric motor driven by an Electronic Control Unit (ECU). Torque and position sensors mounted on the steering column feed real-time measurements to the ECU, which computes the required assist level and commands the motor accordingly. This on-demand assist approach improves energy efficiency, enables precise tuning of steering feel, and provides a programmable interface for Advanced Driver Assistance Systems (ADAS). Figure 2. Electric Steering Rack and Pinion EPS systems are classified based on where the electric motor is mounted on the steering mechanism. Column Assist Type (C-EPS) - The electric motor and control unit are mounted directly on the steering column inside the cabin. Pinion Assist Type (P-EPS) - The electric motor is attached to the pinion shaft within the steering gear box. Dual-Pinion Assist Type (DP-EPS) - This system separates the assist function from the steering mechanism. One pinion gear connects the steering wheel, while the electric motor applies assistance to a second, separate pinion gear directly on the steering rack. Rack Assist Type (R-EPS) - The electric motor is mounted directly onto the main steering rack, either via a concentric motor around the rack or a belt drive. Steer-by-Wire (SbW) - The mechanical connection (steering column and intermediate shaft) between the steering wheel and the wheels is entirely removed. Key Characteristics of Steer-by-Wire EPS: The wheel's movement is handled completely by electronic sensors, algorithms, and actuators It allows for completely customizable steering ratios Frees up interior cabin space Relies heavily on redundant electronics and fail-safes 2.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric power steering systems, including the following audiences: Mechanical and Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Model-Based Design and Simulink Developers Academic and Research Communities 4 Context In the example vehicle architecture used throughout this series, the Steering System is located in the front zone of the vehicle. The Steering ECU is built around the NXP S32K312 microcontroller, which provides both CAN and LIN connectivity. Note: The NXP S32K312 microcontroller provides the processing performance, peripheral set, and communication interfaces (CAN, LIN) required for automotive steering control applications. The ECU drives the stepper motor to the commanded position and communicates desired angle and direction requests over CAN to the Zonal Controller, which coordinates these signals with the central vehicle control node. 5 References Steering column - Wikipedia Power steering - Wikipedia Electric Power Steering (EPS) System Parts Solutions | NXP Semiconductors Electric power steering system (EPS) Clemson Vehicular Electronics Laboratory: Electric Power-Assisted Steering Electric Steering Rack and Pinion 6 Conclusion This article introduced the Electric Power Steering system architecture, its core components, and its position within a modern EV platform. It outlined the Model-Based Design approach using MATLAB/Simulink and NXP hardware as the development foundation, from algorithm modeling through automatic code generation and hardware deployment. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the EPS control system using MathWorks and NXP solutions.

DOC_S32K3x1_S32K3x2_S32K3x4_eMCEM_DCM_Mapping_v1_0_SPD1.0.5_Unofficial Mapping between SPD eMCEM and DCM for S32K311, S32K312, S32K314, S32K322, S32K324, S32K341, S32K342, S32K344.

Monitor the CPU loading using ebpf to reduce system call overhead A lightweight CPU utilization monitor built with eBPF + libbpf.   It hooks into the kernel scheduler (sched_switch tracepoint) to measure per-CPU active time with nanosecond precision — more accurate than polling-based tools like top, and with lower overhead at high process counts. How it works   Kernel (eBPF) User space (C + libbpf) ----------------------- ------------------------- sched_switch tracepoint poll BPF maps every 1 s -> record on-CPU time per core -> compute active % and idle % -> accumulate in BPF Array map print per-core + average   The sched_switch tracepoint context structure is defined manually in cpu_monitor_bpf.c. Output The monitor displays per-core active/idle percentages, with the idle column matching top's id field for easy comparison:   CPU Core   | Active %   | Idle % (=top id) ------------------------------------------- CPU 0      |     0.34%  |         99.66% CPU 1      |    21.89%  |         78.11% CPU 2      |     0.15%  |         99.85% CPU 3      |     0.03%  |         99.97% ------------------------------------------- TOTAL AVG  |     5.60%  |         94.40%   To compare with top, press 1 in top to show per-core stats, then compare the id column with the Idle % column above. Prerequisites Host (build machine) Package Purpose clang + llvm version 21 Compile BPF C source to BPF ELF bpftool Generate BFP skeleton headers aarch64 Poky Toolchain Corss-compile the user-space binary   Install on Ubuntu/Debian: wget https://apt.llvm.org/llvm.sh chmod +x llvm.sh ./llvm.sh 21 apt update apt install -y llvm-21 clang-21 lld-21 lldb-21 update-alternatives --install /usr/bin/llvm-link llvm-link /usr/bin/llvm-link-21 100 update-alternatives --install /usr/bin/clang clang /usr/bin/clang-21 100 update-alternatives --install /usr/bin/llc llc /usr/bin/llc-21 100 llvm-link --version clang --version # install bpftool apt install linux-tools-$(uname -r) Target board Tested Linux kernel == 6.18.20-2.0.0 Tested image == imx-image-full Most BPF configurations are enabled by default. In addition, you need CONFIG_FTRACE=y to enable tracepoint support (required for the sched_switch hook). Build Build the project on your host machine: TOOLCHAIN_PATH=/opt/fsl-imx-internal-wayland/6.18-whinlatter/environment-setup-armv8a-poky-linux ./build_and_deploy.sh   The script will: Source the Poky toolchain environment Run make clean && make all (compiles BPF object, generates skeleton, cross-compiles user-space binary) Install the binary to ./board_deploy/cpu_monitor Deploy and run   # Copy binary to the board scp board_deploy/cpu_monitor root@<board-ip>:/usr/bin/ # Run on the board (root required for eBPF) ssh root@<board-ip> ./cpu_monitor   Press Ctrl+C to exit.   Benchmarking: eBPF vs top A scheduler stress test script is included to compare monitoring overhead between cpu_monitor and top under high scheduling pressure. Run the stress test On the target board, open three terminals:   # Terminal 1: start scheduler pressure (200 threads, 30 seconds) ./stress_sched.sh -t 200 -d 30 # Terminal 2: measure eBPF monitoring overhead perf stat -e cpu-clock,task-clock,context-switches,cpu-migrations,instructions timeout -s KILL 10 ./cpu_monitor # Terminal 3: measure top monitoring overhead perf stat -e cpu-clock,task-clock,context-switches,cpu-migrations,instructions top -b -d 1 -n 10 Compare task-clock, instructions, and context-switches from perf stat output. Try different thread counts to observe scaling behavior:   ./stress_sched.sh -t 50 -d 30     # low pressure ./stress_sched.sh -t 200 -d 30    # medium pressure ./stress_sched.sh -t 500 -d 30    # high pressure Result Test environment: i.MX943 (4x Cortex-A55), Linux 6.18.20, 10-second measurement window. Comparison results in free system load: Indicator eBPF cpu_monitor top delta task-clock (CPU timing) 12.0 ms 263.9 ms 22x CPU usage 0.1% 2.8% 28x instructions 3.38M 197M 58x context-switches 12 17   sys time (kernel time) 5.0ms 199.5ms 40x user time 0 62.1ms     Comparison results in high scheduling pressure (200 threads): Indicator eBPF cpu_monitor top delta task-clock (CPU timing) 12.6ms 690ms 54x CPU usage 0.1% 6.1% 61x instructions 4.8M 538M 112x context-switches 122 9019 75x sys time (kernel time) 4ms 461ms 115x user time 0 206ms     Project structure ebpf_cpu_usage/ ├── cpu_monitor_bpf.c      # Kernel-side eBPF program (C, compiled to BPF) ├── cpu_monitor.c          # User-space program (C, cross-compiled to aarch64) ├── Makefile               # Build rules ├── build_and_deploy.sh    # One-shot build + package script ├── stress_sched.sh        # Scheduler stress test for benchmarking └── README.md   A lightweight CPU utilization monitor built with eBPF + libbpf.   It hooks into the kernel scheduler (sched_switch tracepoint) to measure per-CPU active time with nanosecond precision — more accurate than polling-based tools like top, and with lower overhead at high process counts. i.MX Processors

lowlight opensource ai-isp test on imx95       There are many open-source low-light AI-ISP models. The table below is a comparison table provided by Copilot.  Algorithm GitHub Type i.MX95 NPU Suitability FPGA Suitability MSR (Retinex) jsrsinchana/.../MSR-algorithm Non-AI (ISP) Medium Very High Zero-DCE++ arnabroy734/low_light_enhancement Lightweight CNN + Curve Very High Very High RetinexNet weichen582/RetinexNet CNN (Retinex) Medium High EnlightenGAN VITA-Group/EnlightenGAN GAN (CNN) Very High (lite) Low FLOL cidautai/FLOL Lightweight CNN High Low SNR-aware JIA-Lab-research/SNR-Aware Transformer + CNN Low Low KinD zhangyhuaee/KinD Retinex + CNN Medium Medium RetinexNet-lite Derived Light CNN Medium High EnlightenGAN-lite Derived Small CNN Very High Low Fast LLIE CNN Various Small CNN High Medium We selected some open-source models and used UVC to perform performance tests on the exip-os08a20 module with no HDR mode. We found that SCI（GitHub - vis-opt-group/SCI: [CVPR 2022] This is the official code for the paper "Toward Fast, Flexible, and Robust Low-Light Image Enhancement". · GitHub） computation is relatively small, low-light performance is good in subjective evaluations, and it can basically run on the IMX95. The testing method involves copying the tflite file and test script to the /root/ directory of the IMX95 and running the following command: `python3 test_sci_cvpr_illu_imx95_int8.py --model sci_tpami_illu_imx95_int8.tflite`. The comparison interface shown below is displayed.

Boot uses C40 to erase and rewrite flash. Hello, I'm having trouble writing to flash memory using the C40 chip in the bootloader. I'm writing a 300KB binary program, and it frequently fails at the 9th data packet (the second block), with only a 1/10 chance of succeeding completely. Could you please check if there's a problem with my C40 chip? The main program I'm writing... Flash_UnlockSectorIfProtected ( cur_sector ) ; DisableAllInterrupts () ; DisEnableIrq1 () ; if ( Flash_Write ( flash_write_addr + offset , & payload [ 2 ] , FIXED_PACKET_DATA_LEN ) != 0 ) { EnableIrq1 () ; EnableAllInterrupts () ; } EnableIrq1 () ; EnableAllInterrupts () ; Is there a problem with my use of Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE) for resetting? How can I prevent consecutive resets after 8 attempts, and what function should I use for jumps? func = * ( uint32_t volatile * )( ADDR_APP + 0xC ) ; func = * ( uint32_t volatile * )((( uint32_t ) func ) + 0x4 ) ; func = (((( uint32_t ) func ) & 0xFFFFFFFF U )) ; // Reset_Handler+1 --> required to avoid hard fault After resetting and jumping , will there be any residual data from the previous program? Is it necessary to clean up the RAM? If so , how? Thank you . 回复： boot使用C40擦写flash Hi@ LJH1 Please provide me with a simple demo that can reproduce the problem so I can reproduce your issue. I don't need your complete product project or scattered driver files. 回复： boot使用C40擦写flash RTD Company uses version 4.0.0 as standard. 回复： boot使用C40擦写flash Subsequent testing revealed that C40 writes were intermittently successful. The `status = C40_Ip_MainInterfaceWriteStatus(); ` command returned a value of 2. ErrorFlags = C40_Ip_pFlashBaseAddress -> MCRS & ( FLASH_MCRS_PEG_MASK | FLASH_MCRS_PEP_MASK | FLASH_MCRS_PES_MASK ) ; ErrorFlags eventually equals 0; returns an error. 回复： boot使用C40擦写flash Offline burning of two programs allows for faster reproduction: the first boot directly jumps to the app, the app flashes for 30 seconds to enter boot, the erase/write cycle flashes for 1 second, a total of 300 times. If there are no problems, it resets; if there are problems, it stays on or off. 回复： boot使用C40擦写flash Hi@ LJH1 Your program is too messy; I have no way of testing it for you. I wrote a test program based on the logic of your test. The 8KB space starting from address 0x1000A000 is written in 128 bytes each time, and the address is written 64 times consecutively, totaling 8KB, for a total of 300 times. (128 * 64 * 300). You need to change the clock, because I'm using an S32K311EVB-Q100 with a 16MHz external clock crystal.

How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? I am using the eIQ Toolkit to train an image classification model with a dataset of approximately 6,000 images. My target is to generate a TensorFlow Lite (TFLite) model that is smaller than 800 KB so that it can run on the MCXN947. My current training configuration is: Model: MobileNetV2 Alpha: 0.35 Pruning: Enabled Output format: TFLite The issue is that the training process takes nearly 24 hours to complete. I would like to know if there are any recommended settings or optimizations that can reduce the training time to around 1–2 hours while still keeping the final model size below 800 KB. Has anyone faced a similar situation? Are there any best practices in the eIQ Toolkit for reducing training time without significantly affecting model accuracy or increasing the model size? Any suggestions would be greatly appreciated. Thank you! FRDM-Training MCXN Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? Hi @sivamankomb  A 24-hour run for ~6,000 images is not expected for a small MobileNetV2-alpha-0.35 transfer-learning job unless training is running on CPU, using a large input size, too many epochs, heavy dynamic augmentation, or doing pruning/QAT throughout the full training run. I think you can refer to the following. Verify CUDA + cuDNN are installed and being used. Use the smallest input resolution that still gives acceptable accuracy; if you are at 224×224, try 128×128 first. Start with a low epoch limit plus early stopping, not a fixed long training run. Disable pruning for the initial training run; Use INT8 TFLite quantization for deployment; Avoid QAT in the first speed-optimized run; Start with “No Augments,”  You can refer to eIQ Toolkit User Guide for specific content BR Harry

Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage Hello NXP Team, I am bringing up a custom board based on the i.MX9596 processor with LPDDR5 memory using the i.MX OEI bootloader. I generated the DDR configuration for my custom board using MCUXpresso Config Tools version 26.3. The generated files are: lpddr5_timing.c lpddr5_config.ds peripherals.c peripherals.h pin_mux.c pin_mux.h In the OEI source under boards/mx95lp5/ddr, I found these files: MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c I would like to confirm the correct integration procedure for a custom LPDDR5 board. Should the generated lpddr5_timing.c be used in place of MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c, with OEI_DDR_CONFIG updated to reference the new timing file? Is XIMX95LPD5EVK19_6400mbps_train_timing_a1.c a silicon-specific training file provided by NXP that should remain unchanged for a custom board? OEI uses the following DDR PHY firmware binaries: lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin Can these same firmware binaries be reused on a custom LPDDR5 board as long as the firmware version matches the generated DDR timing configuration? Is the ECC-enabled timing file required only when LPDDR5 ECC is enabled? If ECC is not used on the custom board, is the normal timing file sufficient? Please let me know if any additional files need to be regenerated or modified when migrating from the EVK DDR configuration to a custom LPDDR5 board. Thank you. Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage Hello, 1. Yes, you need to replace the MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c with your custom configuration. 2. That is a different configuration for that specific silicon revision, it can be used as a reference if is your case. If you are not using this configuration, you can leave it untouched. 3. Yes, those binaries can be reused for similar configurations and normal timing file sufficient if you are not using ECC. Best regards.

How to Integrate a C++ TFLite Model into a C-Based MCUXpresso Project? Hello NXP Team, I am integrating a TensorFlow Lite Micro model into my MCUXpresso project for the MCXN947. My application is written in C, while the TensorFlow Lite Micro inference code and generated model are in C++. I am encountering compilation and linking issues when combining the C and C++ source files. I have already tried using "extern C", but the issue remains. Could you please advise on the following? Is it recommended to mix C and C++ source files in an MCUXpresso project? What is the recommended approach for integrating a C++ TensorFlow Lite Micro model into a C-based application? Are there any required compiler/linker settings or reference examples for this integration? Any guidance would be greatly appreciated. Thank you. Development Board MCXN Re: How to Integrate a C++ TFLite Model into a C-Based MCUXpresso Project? Hello @sivamankomb , Thanks for your post. Of course you can mix C and C++ source files in an MCUXpresso project. In fact, this is also the approach used in our SDK demos. For reference, you can review several eIQ-related example projects included in the SDK. The SDK is available for download from Select Board | MCUXpresso SDK Builder. The key points are as follows: - .c files are compiled as C code. - .cpp files are compiled as C++ code. - The final linking stage must use a toolchain that supports the C++ runtime and C++ symbol resolution. - C code should only call functions exposed through extern "C" wrappers and should not directly include or use TFLM C++ classes, templates, or namespaces. Therefore, the recommended approach is to encapsulate the TFLM inference implementation in a .cpp file and expose only a C ABI-compatible wrapper interface to the C application. For example, in the SDK's tflm_label_image demo, the core TFLM inference logic is implemented in common/tflm/model.cpp. This file uses the TFLM C++ APIs, such as #include "tensorflow/lite/micro/micro_interpreter.h" #include "tensorflow/lite/micro/micro_op_resolver.h" static const tflite::Model* s_model = nullptr; static tflite::MicroInterpreter* s_interpreter = nullptr; extern tflite::MicroOpResolver &MODEL_GetOpsResolver(); Then creating a tflite::MicroInterpreter instance and calling AllocateTensors() within MODEL_Init() to perform initialization. The externally exposed model.h,  provides a C-friendly interface. #if defined(__cplusplus) extern "C" { #endif status_t MODEL_Init(void); uint8_t* MODEL_GetInputTensorData(tensor_dims_t* dims, tensor_type_t* type); uint8_t* MODEL_GetOutputTensorData(tensor_dims_t* dims, tensor_type_t* type); void MODEL_ConvertInput(uint8_t* data, tensor_dims_t* dims, tensor_type_t type); status_t MODEL_RunInference(void); const char* MODEL_GetModelName(void); #if defined(__cplusplus) } #endif The function declarations are exported through extern "C", allowing C source files to simply #include "model.h" and call functions such as MODEL_Init() and MODEL_RunInference() without needing any knowledge of C++ types like tflite::MicroInterpreter or MicroMutableOpResolver. This architecture is also the approach adopted by our SDK examples and is generally recommended when integrating TFLM into a C-based application, as it cleanly isolates the C++ implementation details while preserving a pure C interface for the application layer. If you want to integrate customer ML model to SDK demo, you can refer to AN14241 . Hope it helps. BR Celeste

WhisperはNPU上で動作しています こんにちは、 私は95 i.MX でCPUに縛られたささやきを動かしています NPUを使ってプロセッシング速度を上げる方法はありますか?opsetは主にCNN向けのようですが、いずれにせよ聞いてみる価値はあるでしょう。 具体的な例を見たことがないので、可能かどうかは分かりません（NPUはCNN専用のようですが？）。 既にこれをやった人はいますか？何か例はありますか？

ブート時にはC40を使用してフラッシュメモリを消去し、書き換えます。 こんにちは。ブートローダーでC40チップを使用してフラッシュメモリへの書き込みに問題が発生しています。300KBのバイナリプログラムを作成しているのですが、9番目のデータパケット（2番目のブロック）で頻繁に失敗し、完全に成功する確率は10分の1程度です。C40チップに問題があるかどうか確認していただけないでしょうか？作成中のメインプログラムは… Flash_UnlockSectorIfProtected ( cur_sector ) ; DisableAllInterrupts () ; DisEnableIrq1 () ; if ( Flash_Write ( flash_write_addr + offset , & payload [ 2 ] , FIXED_PACKET_DATA_LEN ) != 0 ) { EnableIrq1 () ; EnableAllInterrupts () ; } EnableIrq1 () ; EnableAllInterrupts () ; Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE) を使用したリセットに問題がありますか？ 8 回試行した後に連続リセットを防ぐにはどうすればよいでしょうか？また、ジャンプにはどの関数を使用すればよいでしょうか？ func = * ( uint32_t volatile * )( ADDR_APP + 0xC ) ; func = * ( uint32_t volatile * )((( uint32_t ) func ) + 0x4 ) ; func = (((( uint32_t ) func ) & 0xFFFFFFFF U )) ; // Reset_Handler+1 --> ハードフォールトを回避するために必要 リセットとジャンプの後、以前のプログラムの残留データは残りますか？ RAMをクリーンアップする必要はありますか？ もし必要なら、どのようにすればよいですか？ よろしくお願いいたします。 回复： boot使用C40擦写flash こんにちは@ LJH1 問題を再現できる簡単なデモを提供してください。そうすれば、私もあなたの問題を再現できます。製品プロジェクト全体や、散在するドライバファイルは必要ありません。 回复： boot使用C40擦写flash RTD社は標準バージョンとして4.0.0を使用しています。 回复： boot使用C40擦写flash その後のテストで、C40 の書き込みが断続的に成功していることが判明しました。`status = C40_Ip_MainInterfaceWriteStatus(); ` コマンドは値 2 を返しました。 ErrorFlags = C40_Ip_pFlashBaseAddress -> MCRS & ( FLASH_MCRS_PEG_MASK | FLASH_MCRS_PEP_MASK | FLASH_MCRS_PES_MASK ) ; ErrorFlagsが最終的に0になった場合、エラーを返します。 回复： boot使用C40擦写flash 2つのプログラムをオフラインで書き込むことで、より迅速な再現が可能になります。最初の起動ではアプリに直接ジャンプし、アプリが30秒間点滅してブートモードに入り、消去/書き込みサイクルが1秒間点滅します。これを合計300回繰り返します。問題がなければリセットされ、問題がある場合はオンまたはオフの状態が維持されます。 回复： boot使用C40擦写flash こんにちは@ LJH1 あなたのプログラムはあまりにも複雑で、私にはテストする方法がありません。 あなたのテストのロジックに基づいてテストプログラムを作成しました。 アドレス0x1000A000から始まる8KBの領域に、128バイトずつ書き込みが行われ、このアドレスは64回連続して書き込まれ、合計8KB、合計300回書き込まれる。 （128 * 64 * 300） クロックを変更する必要があります。なぜなら、私は16MHzの外部クロック水晶を搭載したS32K311EVB-Q100を使用しているからです。

6,000枚の画像データセットでeIQツールキットのトレーニング時間を短縮するにはどうすればいいですか? 私はeIQ Toolkitを使って、約6,000枚の画像からなるデータセットで画像分類モデルを訓練しています。目標は 、800KB 未満のTensorFlow Lite(TFLite)モデルを生成し、 MCXN947上で動作させることです。 現在のトレーニング構成は以下の通りです: モデル:MobileNetV2 アルファ: 0.35 剪定：有効 出力形式: TFLite 問題は、トレーニングの完了にほぼ 24時間 かかることです。最終モデルサイズを800KB未満に抑えつつ、トレーニング時間を1〜2時間程度に短縮できるおすすめの設定や最適化があれば知りたいです。 同じような状況に直面した方はいらっしゃいますか？eIQツールキットには、モデルの精度を大きく損なわずにトレーニング時間を短縮したり、モデルサイズを大きく変えたりするベストプラクティスはありますか? 何かご提案があれば大変ありがたいです。ありがとう！ FRDMトレーニング MCX N Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? こんにちは、 @sivamankomb さん。 小規模なMobileNetV2-alpha-0.35の移行学習ジョブで、6,000枚以上の画像を24時間かけて実行することは、CPU上でトレーニングが行われている場合、入力サイズが大きい場合、エポックが多すぎる場合、強い動的拡張がある場合、またはトレーニング中ずっとプルノングやQATを行っている場合を除きます。 以下の点を参照できると思います。 CUDAとcuDNNがインストールされ、使用されていることを確認してください。 許容できる精度を維持できる最小の入力解像度を使用してください。224×224を使用している場合は、まず128×128を試してみてください。 固定の長期トレーニングランではなく、低いエポックリミットと早期停止から始めましょう。 初期のトレーニングランでは剪定を無効にし、 展開にはINT8 TFLite量子化を使用します。 最初の速度最適化実行ではQATを避ける。 「強化なし」から始めましょう。 具体的な内容についてはeIQ Toolkitユーザーガイドを参照してください BR ハリー

i.MX95 OEIおよびDDR PHYファームウェアへのカスタムLPDDR5タイミングの統合に関する説明 NXPチームの皆様、こんにちは。 i.MX9596プロセッサをベースにしたカスタムボードを、i.MX OEIブートローダーを使ってLPDDR5メモリを導入します。 MCUXpresso Config Toolsバージョン26.3を使用して、自作ボード用のDDR構成を生成しました。生成されたファイルは以下のとおりです。 lpddr5_timing.c lpddr5_config.ds ペリフェラル.c ペリフェラル.h pin_mux.c pin_mux.h OEIソースのboards/mx95lp5/ddrディレクトリ内に、以下のファイルが見つかりました。 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c カスタムLPDDR5ボードの正しい統合手順を確認したいのですが。 生成されたlpddr5_timing.cMIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c の代わりにこれを使用し、OEI_DDR_CONFIG を更新して新しいタイミングファイルを参照するようにしますか？ XIMX95LPD5EVK19_6400mbps_train_timing_a1.cはNXPが提供するシリコン専用のトレーニングファイルで、カスタムボードでは変更されないべきでしょうか? OEIは以下のDDR PHYファームウェアバイナリを使用します。 lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin これらの同じファームウェアバイナリは、生成されたDDRのタイミング設定とファームウェアバージョンが一致していれば、カスタムLPDDR5ボード上で再利用できますか? ECC対応タイミングファイルは、LPDDR5 ECCが有効になっている場合にのみ必要ですか？カスタムボードでECCを使用しない場合、通常のタイミングファイルで十分でしょうか？ EVK DDR構成からカスタムLPDDR5ボードに移行する際に、再生成または変更が必要な追加ファイルがあればお知らせください。 よろしくお願いします。 Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage こんにちは、 1. はい、MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c をカスタム構成に置き換える必要があります。 2. それはそのシリコンリビジョンごとに異なる構成なので、あなたのCASEであれば参考にCAN。この構成を使っていない場合は、そのままにしておいても構いません。 3. はい、これらのバイナリは類似の構成に再利用でき、通常のタイミングファイルで十分で、ECCを使わない場合は十分です。 よろしくお願いいたします。

マイルストーン搭載のimx8mp h264/h265エンコーダーを緊急募集 mimx8mp h264ビデオエンコーダーはマイルストーンでは実行されません ffprobe -v error -show_streams -i でビデオをテストしたとき 出力の1つにhas_b_frames=2 、SPS/PPSがあり、これがマイルストーンがビデオを表示しない原因になっていると推測されます。 これはHantroエンコーダーによって生成されたものですが、 has_b_frames=0に設定する方法が見つかりませんでした。 他のH264エンコーダーでは問題なく動作します エンコードストリームを に has_b_frames=0 にする方法について教えてください Re: Urgent imx8mp h264/h265 encoder with milestone こんにちは、 @itamarlevit さん。 i.MX8MPでの正確なエンコードコマンド/パイプラインを教えてください。 よろしくお願いします、 志明

如何缩短 eIQ Toolkit 对包含 6000 张图像的数据集的训练时间？ 我正在使用 eIQ Toolkit 训练一个图像分类模型，数据集大约有 6,000 张图像。我的目标是生成一个小于800 KB的 TensorFlow Lite (TFLite) 模型，以便它可以在MCXN947上运行。 我目前的训练配置是： 型号：MobileNetV2 Alpha：0.35 修剪：已启用 输出格式：TFLite 问题在于，整个培训过程需要近24小时才能完成。我想知道是否有任何推荐的设置或优化方法，可以在将最终模型大小保持在800 KB以下的同时，将训练时间缩短到1-2 小时左右。 有人遇到过类似的情况吗？eIQ Toolkit 中是否有任何最佳实践可以在不显著影响模型准确率或增加模型大小的情况下减少训练时间？ 任何建议都将不胜感激。谢谢你！ FRDM 培训 MCX N Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? 嗨@sivamankomb 对于小型 MobileNetV2-alpha-0.35 迁移学习作业来说，除非训练是在 CPU 上运行、使用较大的输入规模、过多的 epoch、大量的动态增强，或者在整个训练过程中进行剪枝/QAT，否则预计不会出现 24 小时运行约 6,000 张图像的情况。 我认为你可以参考以下内容。 确认已安装并正在使用 CUDA + cuDNN。 使用能够保证可接受精度的最小输入分辨率；如果您使用的是 224×224，请先尝试 128×128。 首先设定较低的训练轮数限制并提前停止，而不是进行固定的长时间训练。 初始训练运行禁用剪枝； 部署时使用 INT8 TFLite 量化； 在第一次速度优化运行中避免使用 QAT； 首先选择“无增强功能”， 具体内容请参阅 eIQ Toolkit 用户指南。 BR 哈里

关于将自定义 LPDDR5 时序集成到 i.MX95 OEI 和 DDR PHY 固件使用中的说明 您好，NXP团队， 我正在开发一款基于 i.MX9596 处理器和 LPDDR5 内存，并使用 i.MX OEI 引导加载程序的定制电路板。 我使用 MCUXpresso 配置工具 26.3 版为我的定制板生成了 DDR 配置。生成的文件如下： lpddr5_timing.c lpddr5_config.ds 外围设备.c peripherals.h pin_mux.c pin_mux.h 在 OEI 源代码目录 板/mx95lp5/ddr 下，我找到了以下文件： MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c 我想确认一下定制LPDDR5板的正确集成流程。 生成的 lpddr5_timing.c是否可以用此文件代替 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c，并更新 OEI_DDR_CONFIG 以引用新的时序文件？ XIMX95LPD5EVK19_6400mbps_train_timing_a1.ca 是 NXP 提供的芯片专用训练文件，定制板需要保持不变吗？ OEI 使用以下 DDR PHY 固件二进制文件： lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin 只要固件版本与生成的 DDR 时序配置匹配，这些相同的固件二进制文件是否可以在定制的 LPDDR5 板上重复使用？ 是否只有在启用 LPDDR5 ECC 时才需要启用 ECC 的时序文件？如果定制板上未使用 ECC，则普通时序文件是否足够？ 从 EVK DDR 配置迁移到定制 LPDDR5 板时，是否需要重新生成或修改任何其他文件？请告知。 谢谢！ Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage 你好， 1. 是的，您需要将 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c 替换为您的自定义配置。 2. 这是该特定硅片版本的一种不同配置，如果这是你的情况，可以将其用作参考。如果您不使用此配置，则可以保持不变。 3. 是的，这些二进制文件可以重复用于类似的配置，如果您不使用 ECC，则普通的计时文件就足够了。 顺祝商祺！

reliability data request dear NXP As part of our component evaluation process, we would appreciate receiving the reliability report for the MMX9352XVVXMAC this information is crucial for our design considerations. thank you for your support Re: reliability data request Hi Mike, Thank you for your inquiry. Since you are contacting us using a Gmail address rather than a company email address, could you please provide the following information? Your company name Project details End customer name If you prefer not to share these details here, please feel free to reply directly to the email I sent you. I will need this information when requesting the reliability report from our internal quality team. Thank you in advance for your cooperation. I look forward to your reply. Thank you and have a nice day. Re: reliability data request Dear bar mike,   Thanks for reaching out.   Based on the confirmation: the correct part# should MiMX9352XVVXMAC, not MMX9352XVVXMAC you mentioned.   For the reliability report of MiMX9352XVVXMAC, it is not public, I need to check with our internal quality engineer, will provide it to you once I got it.   Thanks in advance for your patience.  Re: reliability data request Dear mike,    I got our engineers reply, pls advise me if you have signed the NDA (Non disclosure agreement) with NXP?   And we need below information as well.   Your company name Project details End customer name   Look forward to your reply.   Thank you and have a nice day. Re: reliability data request Dear Mike, Could you pls advise us if your company has signed the NDA (Non disclosure agreement) with NXP? If yes, pls provide the NDA # and let me check in our database. If you do not have an NDA , for the assistance please create a Support Request in our ticket system. You need to use your company e-mail. https://www.nxp.com/support/support:SUPPORTHOME?tid=sbmenu Our NDA team will assist you with the NDA process. Look forward to your reply. Otherwise this ticket will automatically close in 7days. ​​​​​​​​​​​​​​Have a wonderful day!  BR Lina 

可靠性数据请求 尊敬的恩智浦半导体 作为我们元器件评估过程的一部分，我们希望收到 MMX9352XVVXMAC 的可靠性报告，该信息对我们的设计考虑至关重要。 感谢您的支持 Re: reliability data request 您好，迈克， 感谢您的咨询。 由于您使用的是Gmail地址而不是公司电子邮件地址与我们联系，请您提供以下信息？ 您的公司名称 项目详情 最终客户姓名 如果您不希望在此处分享这些细节，请直接回复我发送给您的电子邮件。 我在向内部质量团队索取可靠性报告时需要这些信息。 感谢您的合作。 期待您的回复。 谢谢，祝您愉快。 Re: reliability data request 亲爱的酒吧迈克，   感谢您的联系。   根据确认信息：正确的零件号应为 MiMX9352XVVXMAC， 不是 MMX9352XVVXMAC 你提到了。   对于 可靠性报告 关于 MiMX9352XVVXMAC，它不是公开的，我需要向我们内部的质量工程师确认，一旦我得到它，就会提供给您。   感谢您的耐心等待。 Re: reliability data request 亲爱的迈克，   我收到了我们工程师的回复，请问您是否已与恩智浦半导体签署了保密协议（NDA）？   此外，我们还需要以下信息。   您的公司名称 项目详情 最终客户姓名   期待您的回复。   谢谢，祝您愉快。 Re: reliability data request 亲爱的迈克： 请问贵公司是否已与恩智浦半导体签署保密协议（NDA）？ 如果可以，请提供保密协议编号，以便我在数据库中查询。 如果您没有保密协议，请在我们的工单系统中创建支持请求以获得帮助。您需要使用公司邮箱。https://www.nxp.com/support/support:SUPPORTHOME?tid=sbmenu 我们的保密协议团队将协助您完成保密协议流程。 期待您的回复。 否则，此工单将在7天后自动关闭。 祝您度过美好的一天！ BR 莉娜

信頼性データ要求 NXP様 部品評価プロセスの一環として、この情報が設計上の考慮事項に不可欠なMMX9352XVVXMAC信頼性報告書をいただけるとありがたいです。 ご支援ありがとうございます Re: reliability data request こんにちは、Mikeさん お問い合わせいただきありがとうございます。 会社のメールアドレスではなく Gmail アドレスでご連絡いただいているので、以下の情報を教えていただけますか? あなたの会社名 プロジェクトの詳細 最終顧客の名前 これらの詳細をここで共有したくない場合は、私が送信したメールに直接返信してください。 この情報は、社内の品質チームに信頼性レポートを依頼する際に必要になります。 ご協力ありがとうございます。 ご返信をお待ちしております。 ありがとうございました。良い一日をお過ごしください。 Re: reliability data request バーマイク様、   ご連絡ありがとうございます。   確認に基づくと、正しい部品番号はMiMX9352XVVXMACです。 ない MMX9352XVVXMAC あなたが言及しました。   MiMX9352XVVXMACの信頼性レポート  は公開されていません。社内の品質エンジニアに確認する必要があります。届い次第お渡しします。   ご理解とご協力に感謝いたします。 Re: reliability data request マイク様、   エンジニアから返信がありましたので、NXP社とNDA（秘密保持契約）を締結済みかどうか教えていただけますでしょうか？   また、以下の情報も必要です。   あなたの会社名 プロジェクトの詳細 最終顧客の名前   ご返信をお待ちしております。   ありがとうございました。良い一日をお過ごしください。 Re: reliability data request マイク様、 御社がNXPとNDA(秘密保持契約)に署名しているかどうか、教えていただけますか? はいの場合、NDA番号をお知らせください。弊社のデータベースで確認いたします。 NDAがない場合は、サポートを申請するためにチケットシステムでサポートリクエストを作成してください。会社のメールアドレスを使う必要があります。https://www.nxp.com/support/support:SUPPORTHOME?tid=sbmenu 当社のNDAチームがNDA手続きをサポートいたします。 ご返信をお待ちしております。 そうでない場合、このチケットは7日後に自動的にクローズされます。 素敵な一日をお過ごしください！ BR リナ

在 NPU 上运行的 Whisper 你好， 我一直在 i.MX 95 上运行 Whisper，它受限于 CPU 性能。 是否有办法利用NPU来加快处理速度？看起来这个算式集主要是给 CNN 用的，不过还是值得一问。 我没见过任何例子，而且我不确定这是否可行（NPU 似乎只适用于 CNN？） 有人已经做过这件事了吗？有例子吗？

boot使用C40擦写flash 你好，我这边使用boot里面使用C40写flash大概率失败，我写300K左右的bin程序，经常在第9包数据，也就是第二个块就失败，1/10可能性完整通过，请帮我看一下是不是C40是不是使用有问题，写的主要程序 Flash_UnlockSectorIfProtected(cur_sector); DisableAllInterrupts(); DisEnableIrq1(); if (Flash_Write(flash_write_addr + offset, &payload[2], FIXED_PACKET_DATA_LEN) != 0) { EnableIrq1(); EnableAllInterrupts(); } EnableIrq1(); EnableAllInterrupts(); 我使用Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE);复位有没有问题，怎么避免8次后连续复位，跳转函数 func = *(uint32_t volatile *)(ADDR_APP + 0xC); func = *(uint32_t volatile *)(((uint32_t)func) + 0x4); func = ((((uint32_t)func) & 0xFFFFFFFFU)); // Reset_Handler+1 --> required to avoid hard fault (* (void (*) (void)) func)();复位和跳转后会不会有之前程序的数据残留，需要清理ram吗，如果需要怎么清理。麻烦了 回复： boot使用C40擦写flash Hi@LJH1 做一个最简单可以复现问题的demo给我，方便我复现你们的问题，我不要你们的完整产品工程或者是零散的驱动文件。 回复： boot使用C40擦写flash RTD公司统一使用的4.0.0 回复： boot使用C40擦写flash 离线烧录两个程序，一起复现快：首次boot直接跳app，app快闪30s进入boot，擦写1s闪烁，一共300次，没问题复位，有问题就常亮或长灭。 回复： boot使用C40擦写flash 后续测试 ，C40写时好时坏        status = C40_Ip_MainInterfaceWriteStatus();status结果等于2； ErrorFlags = C40_Ip_pFlashBaseAddress->MCRS & (FLASH_MCRS_PEG_MASK | FLASH_MCRS_PEP_MASK | FLASH_MCRS_PES_MASK); ErrorFlags最终等于0；返回error 回复： boot使用C40擦写flash Hi@LJH1 你的程序太乱了，我完全没办法帮你测试。 我按照你测试的逻辑，写了一个测试程序 从地址0x1000A000开始的8KB空间，每次写入128byte,地址连续写入64次共8KB，连续300次。 （128 * 64 * 300）。 你要改一下时钟，因为我用的是S32K311EVB-Q100，外部时钟晶振是16MHz.