Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
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.
記事全体を表示
PN7642 - ULPCD evaluation in NFC Cockpit This article describes how to evaluate ULPCD feature together with PN7642 EVK (OM27642EVK) and NFC Cockpit.  1// Disable DC-DC in EEPROM  OM27642EVK does not required any HW changes for ULPCD (**). User is only required to change the following settings in EEPROM  (disable DC-DC converter). Address: 0x0000 (Secure_Lib_Config) Value: 0x21  Reset the board after writing the value.  **Note: To ensure an accurate and reliable ULPCD evaluation—particularly for ULPCD current measurements. We strongly recommend implementing the following hardware modifications on the OM27642EVK. Note: New revision of the board already have R4=DNP, R8=0Ω. Kindly check this on your board. 2//Set required ULPCD settings in EEPROM  ULPCD VDDPA -> Typically 1.5V. If the HF attenuator is 0x00, increase e.g. to 1.8V. Since the detection range does not significantly depend on the power level, there is no need to set VDDPA above 2 V. Higher VDDPA results in increased current consumption in ULPCD, but does not significantly improve detection performance. RF On Guard time -> This value can be reduced to the minimum -> 5.2 us RSSI Guard time -> Recommended value is 25 RSSI Threshold -> Typically 4~6 Number of RSSI samples -> Typically -> 0 (4 rounds) 3// Perform "Reads HF Attenuator"  Once the required ULPCD settings is set (Guard times, Threshold....). Then User has to perform "Reads HF Attenuator". Make sure that the "HF Attenuator" option is checked.  As written above, the value must not be 0x00. If so, increase VDDPA. 4// Perform ULPCD Calibration and check RSSI Value  For OM27642EVK, the RSSI value for unloaded antenna is typically around 1400dec - 1600dec. 5//Enter ULPCD mode  User can enter the ULPCD mode. The board will again be connected once the load change is detected (e.g. NFC card or smartphone in the antenna proximity). 6// Typical detection performance for 65 mm x 65 mm Antenna tuned to 35Ω. MIFARE DESFire EV3: Class 1 Antenna  ICODE SLIX: Class 1 Antenna  ICODE 3: Class 6 Antenna  NFC Controller Solutions
記事全体を表示
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.
記事全体を表示
Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine)   1 Table of Contents • Introduction • Context • Component Overview • Design and Implementation • Results • Common Pitfalls & Troubleshooting • Summary & Next Steps • References 2 Introduction This article explains how virtual scenes and driving scenarios can be created and used within a Model-Based Design workflow using MathWorks tools. It focuses on how MATLAB® and Simulink® integrate with RoadRunner and Unreal Engine to enable realistic, repeatable, and scalable simulation environments for developing and validating advanced automotive systems. The article is aligned with the NXP Model-Based Design Toolbox (MBDT) workflow and targets users working on control, perception, and system-level validation. In our demo setup, the same workflow presented in this article was applied to build a Driver-in-the-Loop simulation scenario. By leveraging MATLAB®, Simulink®, RoadRunner, and Unreal Engine, we created a realistic virtual environment that allowed direct interaction with the system running on NXP hardware. This approach highlights the practical value of these simulations, not only for early validation and testing, but also for closing the loop between model-based design and real-time execution on target hardware, enabling faster iteration, safer validation, and improved system reliability. 3 Context As automotive systems become more complex, early validation is increasingly important. Engineers must assess advanced functionality under tight development timelines, often before hardware is available. Model-Based Design supports this need by enabling system logic and behavior to be verified early using executable models. Virtual scenes extend this approach by embedding those models in realistic, controlled environments that reflect real-world operating conditions. Within an NXP-based development workflow, virtual scenes enable teams to explore a wide range of driving situations quickly, safely, and repeatably. Complete applications can be evaluated at Model-in-the-Loop (MIL), Software-in-the-Loop (SIL), and Processor-in-the-Loop (PIL) stages, helping uncover issues early and reducing risk before hardware integration. This structured use of virtual validation supports smoother transitions from simulation to deployment on automotive microcontrollers. 4 Component Overview Creating and using virtual scenes with MathWorks relies on several tightly integrated components: MATLAB and Simulink – used for algorithm development, control logic, and system modeling. RoadRunner – a dedicated environment for building detailed road networks, traffic infrastructure, and driving scenarios. Unreal Engine – responsible for high-fidelity 3D visualization and sensor realism. Simulation interfaces – enabling data exchange between Simulink, RoadRunner, and Unreal Engine during runtime. 5 Design and Implementation This section describes the design principles and implementation flow used to create virtual scenes and scenarios. The process emphasizes modularity, repeatability, and tight integration with control and system models. 5.1 System Requirements The following prerequisites must be satisfied to build and execute virtual scenes with MATLAB and Simulink and follow our path: MATLAB and Simulink with Automated Driving Toolbox and Simulink 3D Animation Toolbox installed. RoadRunner. Adequate GPU resources for real-time rendering and sensor simulation. These requirements ensure smooth interaction between simulation models and the visualization environment. 5.2 Architecture & Model Description At a higher level, the architecture consists of a Simulink model acting as the system under test, connected to a virtual world generated by RoadRunner and Unreal Engine. The Simulink model publishes vehicle states and receives environmental feedback, such as lane boundaries, traffic participants, or sensor detections. Clear interface definition between the model and the virtual environment is essential. Signals representing vehicle position, velocity, and actuator commands are exchanged at each simulation step, enabling closed-loop execution. 5.3 MATLAB/Simulink Implementation Connecting to RoadRunner and Loading a Scenario MATLAB connects directly to RoadRunner to open projects and load driving scenarios: % Launch RoadRunner and open a project rrApp = roadrunner('C:\RoadRunnerProjects\VirtualScenes'); openProject(rrApp, 'HelloWorld_Project'); % Open a RoadRunner scenario and start simulation scenarioName = 'Intersection_CrossTraffic'; openScenario(rrApp, scenarioName); rrSim = createSimulation(rrApp); start(rrSim); Integrating RoadRunner with Simulink Once configured, Simulink and RoadRunner run synchronously. RoadRunner updates the virtual environment, while Simulink computes vehicle behavior and control actions. sim('ConfiguredVirtualVehicleModel'); close(rrApp); 5.4 Integration (RoadRunner ↔ Unreal Engine) RoadRunner is used to design road geometry, traffic signs, intersections, and actor paths. These assets are exported to Unreal Engine, which provides photorealistic rendering and sensor simulation. % Open the Simulink model open_system('ConfiguredVirtualVehicleModel'); % Path to the RoadRunner project containing the scene scenarioPathFull = 'C:\RoadRunnerProjects\VirtualScenes\HelloWorld_Project'; % Configure the Simulation 3D Scene Configuration block set_param('ConfiguredVirtualVehicleModel/Visualization/3D Engine/3D Engine/Simulation 3D Scene Configuration', ... 'RoadRunnerProjectPath', scenarioPathFull); 5.5 Creating a Custom Scene from Real Map Data Custom scenes can be created by importing real-world map data into RoadRunner. Geographic information such as road layouts and elevation profiles can be converted into editable road networks. This is an example of how to create a custom scene for recreating the Silverstone Racing Circuit in RoadRunner, using OpenStreetMap and Driving Scenario Designer. (function() { var wrapper = document.getElementById('lia-vid-6399904467112w960h540r872'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) And the result using Simulink 3D with Unreal Engine. 5.6 Testing & Validation Once scenarios are defined, automated simulation runs can be executed to validate system behavior across multiple variants. Key metrics such as trajectory tracking, sensor coverage, and control stability can be evaluated offline. This systematic testing approach increases confidence before integrating software with NXP hardware targets. (function() { var wrapper = document.getElementById('lia-vid-6399905825112w960h540r143'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) 6 Results Using virtual scenes significantly reduces development time. Engineers can identify functional issues early, explore edge cases, and refine algorithms without hardware constraints. In practice, this results in higher software quality at the time of hardware deployment and a smoother transition to real-world testing. 7 Common Pitfalls & Troubleshooting Simulation time overhead can become noticeable when RoadRunner scenes are used directly in the Simulation 3D Scene Configuration block, as Unreal Engine re-imports RoadRunner assets at the start of each simulation. While this is well suited for iterative development and scene refinement, it can slow down repeated runs. Note: For final validation or deployment-oriented testing, improved performance can be achieved by using a precompiled Unreal Engine project, which avoids repeated asset import and significantly reduces startup time. In addition, repeatedly launching RoadRunner for each simulation introduces unnecessary overhead. A recommended practice is to keep RoadRunner running across multiple simulations and reuse the existing connection. This can be achieved using the RoadRunner roadrunner.connect API, allowing MATLAB and Simulink to reconnect to an active RoadRunner instance instead of restarting it for every run, thereby improving iteration speed and overall workflow efficiency. 8 Summary & Next Steps Virtual scenes turn simulation into experience. Combined with an NXP Model-Based Design workflow, MathWorks tools enable engineers to innovate faster, validating complex behavior early while reducing risk, cost, and development effort. Next, these environments can be expanded with high-fidelity sensor models, automated regression testing, and hardware-in-the-loop execution, closing the gap between virtual validation and real-world deployment. 9 References Import OpenStreetMap Data into Driving Scenario — MathWorks Help Driving Scenario Designer App — MathWorks Help RoadRunner — MathWorks Product Page Simulink 3D Animation Toolbox — MathWorks Help OpenStreetMap Automated Driving Toolbox — MathWorks Product Page Visualize 3D Scenes with Unreal Engine — MathWorks Help roadrunner.connect API — MathWorks Help NXP Model-Based Design Toolbox — Community
記事全体を表示
FRDM-i.MX93はM33準備完了以降に起動できません。LinuxとWindowsでUUU SDPSの起動がタイムアウトします。 こんにちは、NXPサポート様 FRDM-i.MX93ボードの復旧についてご協力をお願いします。ボードは、SPLブートの初期段階で「M33 prepare ok」の直後に一貫して停止し、BL31または完全なU-Bootに進みません。UUUリカバリもSDPSの起動中にタイムアウトで失敗します。 役員の詳細: ボード: FRDM-i.MX93 シリアルログに表示されるSoC:0xa1009300 シリアルログに表示されたLC: 0x2040010 PMIC: PCA9451A DDR: 3733MTS 典型的なシリアル出力: U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK 再構築された2025 SPLでも、同じ停止ポイントが発生します。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK 使用したハードウェア構成: P1 = 外部電源、45W USB-Cウォールアダプターでテスト済み P16 = デバッグ用シリアルコンソール P13 = microSDカードスロット P2 = UUU / シリアルダウンローダーモード用のUSB-C接続 PCのUSB電源ではなく、壁のコンセント用アダプターから電源を供給するテストも行いました。行動に変化は見られなかった。 テスト対象のホストシステム: Linux Mint / Ubuntu ホスト Windowsホスト UUUのバージョンをテストしました: ううう 1.5.141 ううう 1.5.243 主な問題は、ボードがSPLに到達し、PMICとDDRを初期化して「M33 prepare ok」と出力した後、何も起こらないことです。「Normal Boot」、「Trying to boot from BOOTROM」、「NOTICE: BL31」、または完全な U-Boot に到達しません。これは、SDカードとeMMCの両方から起動した場合に発生します。 USBシリアルダウンローダーモードでは、ボードはUUUによって検出されます。 sudo ./uuu-lsusb コネクテッド Known USB Devices パスチッププロビデオPID Bcdバージョン 5:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 しかし、SDPSの起動中にUUUが失敗します。使用されたコマンドは次のとおりです。 sudo ./uuu-V -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst Linuxでは、以下のエラーが発生します。 開始コマンド:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 HID(W)エラー:LIBUSB_ERROR_TIMEOUT Windowsでは、以下のエラーが発生します。 開始コマンド:SDPS: boot -scanterm -f .\imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 14% HID(W)エラー: LIBUSB_ERROR_TIMEOUT (-7) これはLinuxとWindowsの両方でテストされ、同じ結果が得られました。 テスト対象画像: NXP公式FRDM-i.MX93 Rev 4.0デモイメージパッケージをテストしました。 LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 ブートイメージのハッシュ値は次のとおりです。 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f imx-boot-imx93frdm-sd.bin-flash_singleboot 私は、同じブートイメージハッシュを使用するimx93frdm用の独自のYoctoイメージもテストしました。 SDカードからの起動選択が機能することを確認しました。SDカードが挿入されていないSDブートモードでは、シリアル出力はありません。SDカードを挿入したSDブートモードでは、SPLは起動して「M33 prepare ok」で停止します。SDカードブートスイッチは正常に動作しているようです。 また、公式のNXP .wicファイルも確認しました。イメージには、想定される32 KiB / 0x8000オフセットにブートイメージが含まれています。使用したコマンド: WIC=nxp.wic BOOT=imx-boot-imx93frdm-sd.bin-flash_singleboot xxd -l 64 -s $((32*1024)) "$WIC" xxd -l 64 -s 0 "$BOOT" cmp -n "$(stat -c%s "$BOOT")" -i $((32*1024)):0 "$WIC" "$BOOT" && echo "NXP WICには32Kにブートイメージが含まれています" || echo "NXP WICには32Kにブートイメージは含まれていません" 結果: NXP WICには32Kのブートイメージが含まれています つまり、SDカードイメージにはブートコンテナが正しく含まれているようです。 2024.04 SPLイメージだけが問題の原因ではないことを確認するため、Flexbuild/U-Bootを使用してより新しいブートイメージを作成しました。構築されたイメージ内のSPLは以下を示します。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) NXP FRDM-IMX93 私は以下の方法で、この新しい flash.bin ファイルを SD カードの 32 KiB オフセットに書き込みました。 sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync 同期 その後、ボードは新しいSPLバナーを印刷し、新しいSDブートイメージが実行されていることを確認した。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK しかし、それでも同じ箇所で停止し、BL31/完全なU-Bootまでは進みませんでした。 eMMCの状態: 当初、eMMCはLinuxログイン画面まで起動したが、ルートファイルシステムに/bin/shが存在しなかったため、rootログインができなかった。復旧試行中に、eMMCは.wicファイルを使用してSD Linuxから書き換えられた。画像。その後、eMMCブートも「M33 prepare ok」の後に停止します。しかし、同じ停止ポイントは、公式のNXPイメージを使用したSDブートと、再構築された2025 SPLを使用した場合にも発生するため、現在の問題はLinux/rootfsよりも前の段階にあるようです。 私が除外されたと考えること: シリアルポートが間違っています:シリアル接続は正常に動作し、SPL出力が表示されます。 PCの電源不良:45Wの外部ACアダプターを使用してテストしました。 SDカードブートスイッチの設定が間違っています:SDカードが入っていない状態でSDブートモードにすると、何も出力されません。 SDイメージにブートイメージがありません:公式NXP WICの0x8000 / 32 KiBにブートイメージが存在することが確認されています。 Linux/rootfsの問題:BL31/完全なU-Boot/Linuxの前に障害が発生します。 UUUのホストOSの問題:UUU SDPSの起動タイムアウトがLinuxとWindowsの両方で発生します。 古い2024 SPLだけが問題で、再構築された2025.04 SPLも「M33 prepare ok」の後に停止します。 これがFRDM-i.MX93の既知の早期起動問題かどうか、確認にご協力いただけますでしょうか? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 弊社がリリースしたBSPバージョンをご利用ですか? i.MXアプリケーション・プロセッサ向け組み込みLinux | NXP Semiconductors どのバージョンのBSPを使用していますか?また、どのバージョンを選択していますか? 労働者の休暇から戻り次第、当社のボードでテストしてみます。来週の水曜日にオフィスに戻り、テストを実施してから、テスト結果をご報告します。 素敵な一日をお過ごしください よろしくお願いいたします。 リタ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私はLF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93を使用しています。画像 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows オフィスに戻りましたので、ボードでテストを行い、結果をお知らせします。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 解決できましたか? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang 同じ問題が発生しています... 私のimx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgapビルドでは、BL31が起動を開始したのを見たことがありません。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows こんにちは、私も現在同じ問題を抱えています。解決策は見つかりましたか?
記事全体を表示
S32K388 MemAcc 消去 PFLASH がフリーズ こんにちは!MemAcc_Example_S32K388を使用し、DFLASHをPFLASHに変更しました。しかし、pFlashを消去すると、MEMACC_JOB_PENDING == MemAcc_GetJobStatus(TEST_AREA)で処理が停止してしまいます。 TEST_AREAを1に設定することで、比較プログラムを修正しました。 こちらが修正されたプログラムです。私のミスを見つけて指摘してくれることを願っています。とても感謝します。 S32K3 Re: S32K388 Use MemAcc Erase PFLASH Stuck こんにちは@zhangyu5454さん 一つ問題があります。接頭辞が間違っています。正しくは Mem_43_INFLS です。 Re: S32K388 Use MemAcc Erase PFLASH Stuck Mem_43_INFLSに変更しようとしましたが、それでも動作しませんでした。ルーチンのDFLASHでMem_43_INFLSをabc123に変更したら、普通に動作します。ついにMemAcc Mem InvocationのDIRECT_STATIC それをINDIRECT STATICに変えれば問題が解決します
記事全体を表示
MPC574xP BCTRL こんにちは: 私のお客様はMPC5741Pを車載ESCのアプリケーションに使っています。 現在、エンドOEMからBCTRLピンの特性(電圧領域など)について問い合わせを受けている。 確認と確認を手伝ってもらえますか?ありがとう。 下は波形で、三角形で、OEMからMCU側からベースコントロール出力ピンのCap.デカップルを追加してほしいと依頼されました。 Re: MPC574xP BCTRL データシートでは異なるトランジスタを推奨しており、以下の通りです。 また、適切にバイパス/分離する必要がある。VDD_LV_CORに特に注意してください。 Re: MPC574xP BCTRL こんにちは、デビッドさん。 了解しました、ありがとうございます。
記事全体を表示
Newbie setting up an autosar environment When downloading S32 Design Studio for ARM 2.2 – Windows/Linux, the above message appears. Hopefully, the official website can be reset so that downloads can proceed normally. Thank you. When downloading S32 Design Studio for ARM 2.2 – Windows/Linux, the above message appears. Hopefully, the official website can reset this so that the download can proceed normally. Thank you. Re: 新手搭载autosar环境 Hello, Please try it now. It should be working. Best regards, Peter S32K新手搭载autosar环境 Thank you very much, teacher. The first problem is solved. However, when installing the S32DS_ARM_Win32_v2.2.exe integrated development environment, an activation failure message appeared. The cause was found to be an expired Activation Code. Therefore, I am requesting an extension. Thank you.
記事全体を表示
S32K3 bootloader and HSE - best practice ? Hi NXP team, We are implementing a robust OTA update architecture on an S32K312 using HSE full-block A/B swap. Our target architecture is: - S32K312 with 2 MB PFlash split into two 1 MB physical blocks. - HSE AB_SWAP is used via the passive-block activation service. - OTA package is received over Modbus/serial. - Bootloader stages the signed image into the passive PFlash block. - HSE verifies the passive image/SMR. - Bootloader requests AP_SWAP. - After reset, the newly swapped bank boots provisionally. - A confirm command makes the swap permanent; otherwise the device rolls back. Originally we tried to keep one global bootloader in DFlash, outside the two PFlash banks. That bootloader would receive OTA, program the passive PFlash bank, request HSE AP_SWAP, and then continue to manage confirm/rollback. We ran into architectural and runtime complexity with that approach: 1. HSE AB_SWAP appears to operate on full PFlash block boundaries, not arbitrary app partitions. 2. A single DFlash bootloader is outside the swapped/authenticated bank image. 3. The active PFlash bank still needs valid boot/IVT/reset structure after swap. 4. We had difficult execution hazards when DFlash was also involved in bootloader runtime/record handling. 5. It became unclear whether a global DFlash bootloader is compatible with a clean full-bank HSE AB_SWAP production design. We therefore moved to a duplicated PFlash bootloader mode for now: - Each 1 MB PFlash bank contains its own IVT + bootloader + application. - The bootloader has a reserved slot at the base of each bank. - The application starts after the bootloader slot. - The signed OTA image is a full bank image containing bootloader + application. - After HSE AB_SWAP, the newly active bank is self-contained and bootable. This appears much cleaner for HSE full-block A/B swap, but I would like to confirm the intended/production-safe approach. This is suboptimal as it partially defeats the purpose of a factory bootloader. Questions: 1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture? 2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path? 3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met? 4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3? 5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design? We have seen that code and IVT can be linked into DFlash by modifying the linker script (and we tried that), but our question is specifically about whether that is appropriate when using HSE full-block A/B swap and secure boot/SMR verification. Thank you. Re: S32K3 bootloader and HSE - best practice ? Hi @coratron  1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture? There are no limitations from HW point of view. Both options are possible. If the size of data flash is sufficient and you do not plan to use it for your data, the bootloader can be placed in the data flash. If you need data flash for other purposes then having two copies of the bootloader in both partitions is common practice. 2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path? No, there’s no such requirement. It is sufficient to have valid IVT only in data flash (bootloader’s IVT). Common practice is that bootloader is always started after reset and then then the bootloader jumps to user application. 3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met? There are no specific requirements coming from SBAF or HSE. Once bootloader is started, it can decide if it should jump to application or if it should download new application or if it should do rollback, etc. and then it should reset the device (in case of rollback/swap) or jump to the application. 4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3? We don’t have such example. 5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design? I would not classify either approach as universally safer. The suitability of a particular architecture depends on the overall system design, security requirements, OTA workflow and rollback strategy. Both concepts can be implemented in a robust production solution. Regards, Lukas Re: S32K3 bootloader and HSE - best practice ? Thanks for your prompt reply @lukaszadrapa . That clarifies and helps substantially - we have been able to re-evaluate our bootloader implementation in DFlash and were successful. The team is used to the documentation / accessibility from other vendors and finds NXP to be surprisingly confusing compared to them despite being a leader in automotive applications. Your prompt feedback makes up for these gaps, so thanks again for your help - much appreciated. I will mark your reply as the solution, with the following feedback directed at your team: - A Dflash bootloader + HSE demo would have been great to save time (yours included). I am sure this is the natural setup for people that use AB_SWAP. - NXP should unify and get the documentation and software stack organised (long term) - compatibility / versions are scattered, there is no one source of information which leads to confusion. Regards 
記事全体を表示
WhisperはNPU上で動作しています こんにちは、 私は95 i.MX でCPUに縛られたささやきを動かしています NPUを使ってプロセッシング速度を上げる方法はありますか?opsetは主にCNN向けのようですが、いずれにせよ聞いてみる価値はあるでしょう。 具体的な例を見たことがないので、可能かどうかは分かりません(NPUはCNN専用のようですが?)。 既にこれをやった人はいますか?何か例はありますか?
記事全体を表示
RT1064:引脚配置,用于从内部闪存启动 你好, 这可能听起来像个愚蠢/新手问题,但我无法确定必须对 BOOT_MODE1/BOOT_MODE0 和 BT_CFG[11..0] 引脚进行哪些操作才能将 RT1064 配置为从其内部闪存启动。 参考手册中的表 9.9 只列出了 3 种启动源(通过 FlexSPI 的 NOR 闪存、SD 卡和 eMMC),但没有列出内部闪存,就好像这部分内容是从 RT1060 复制粘贴过来的一样…… AN12290 提到了 FlexSPI2 内部总线到此内部闪存,但没有说明如何从上述 3 个启动源中选择它。 MIMXRT1060/1064 评估套件板硬件用户指南中的表 5 指出,只有两种启动模式可用(QSPI 或 SD 卡),并且还声称不支持 QSPI 启动(参见 2.7 段),因此 SD 卡是唯一的启动源…… 非常感谢您的帮助! i.MX RT106x Re: RT1064 : pin configuration to boot from internal flash 嗨@batmat , 如 AN12290 中所述,MIMXRT1064 只能从 FlexSPI2 启动,FlexSPI2 专用于内部 QSPI 闪存。您仍然可以通过 FlexSPI1 接口连接外部闪存,该接口可用于保存数据或其他功能,但不能用于启动。这就是为什么参考手册中的表 9.9 只列出了 3 个启动源,即通过 FlexSPI 的 NOR 闪存、SDCARD 或 eMMC;通过 FlexSPI2 的 NOR 闪存是唯一可用于启动的 FlexSPI,并且默认情况下它已经路由到板载闪存。 为了能够从内部 QSPI 闪存启动,引导设备开关 (SW7) 设置应为: SW7-1 关闭,SW7-2 关闭,SW7-3 打开,SW7-4 关闭。 BOOT_CFG1[7:4] 引脚必须设置为 0,才能选择通过 FlexSPI 的串行 或非 启动作为引导设备。同时,BOOT_CFG2[2:0]引脚也必须设置为0,以便选择内部QSPI Flash。MIMXRT1064-EVK 默认具有这些引脚设置。 BR, 埃德温。 Re: RT1064 : pin configuration to boot from internal flash 你好,埃德温, 确实有道理。我感到很困惑,因为外部闪存和内部闪存都是 QSPI 接口的,很难确定哪个是哪个。 我建议对 RT1064 的表 9.9 进行文档改进。 应该将“通过 FlexSPI 启动 NOR 闪存”改为“通过内部 FlexSPI2 启动内部 NOR 闪存”,并补充说明“RT1064 不支持通过 FlexSPI 从外部 NOR 闪存启动”。 我认为这样可以避免混淆。 再次感谢您提供的出色且及时的支持。
記事全体を表示
RT1064:内部フラッシュから起動するためのピン構成 こんにちは、 これは初心者や初心者の質問に聞こえるかもしれませんが、RT1064を内蔵フラッシュメモリから起動させるためにBOOT_MODE1/BOOT_MODE0とBT_CFG[11..0]ピンで何をすべきか正確にはわかりません。 参考マニュアルの表9.9には、3つのブートソース(FlexSPI経由のNORフラッシュ、SDCARD、eMMC)のみが記載されていますが、内部フラッシュは記載されていません。まるでこのセクションがRT1060からコピー&ペーストされたかのようです... AN12290はこの内部フラッシュへのFlexSPI2内部バスについて言及していますが、上記の3つの起動ソースで選択する方法は示していません。 MIMXRT1060/1064 Evaluation Kit Board Hardware ユーザーガイドの表5では、起動モードはQSPIかSDCARDの2種類のみが利用可能であり、QSPIブートは利用できないと主張しています(2.7段落からの注釈)、SDカードのみが唯一の起動源となっています... どんなご支援でも大変ありがたく思います。 i.MXRT 106x Re: RT1064 : pin configuration to boot from internal flash こんにちは、 @batmat さん。 AN12290で述べたように、MIMXRT1064では、内部QSPIフラッシュ専用のFlexSPI2からのみブートが可能です。外部フラッシュはFlexSPI1インターフェース経由で接続でき、起動以外のデータ保存やその他の機能に使えます。このため、リファレンス・マニュアルの表9.9には、3つのブートソースのみが記載されています。NORフラッシュ(FlexSPI、SDCARD、またはeMMC)、FlexSPI2経由のNORフラッシュが起動時に唯一利用可能なFlexSPIで、デフォルトでオンボードフラッシュにルーティングされています。 内部QSPIフラッシュから起動するためには、ブートデバイススイッチ(SW7)の設定は以下の通りであるべきです。 SW7-1 オフ、SW7-2 オフ、SW7-3 オン、SW7-4 オフ。 ブートデバイスとしてFlexSPI経由のシリアルNORブートを選択するには、BOOT_CFG1[7:4]ピンを0に設定する必要があります。また、BOOT_CFG2[2:0]ピンも0に設定しなければならず、内部のQSPIフラッシュが選択されます。MIMXRT1064-EVKは、デフォルトで以下のピン設定になっています。 BR、 エドウィン。 Re: RT1064 : pin configuration to boot from internal flash こんにちは、エドウィンさん。 確かにその通りだ。外部フラッシュと内部フラッシュの両方がQSPI対応なので、どちらがどちらなのか判別しづらくて混乱しました。 RT1064の表9.9のドキュメント進化を提案します。 「FlexSPIを経由したNORフラッシュ」ではなく、「FlexSPI2を経由した内部NORフラッシュ」と記載し、「FlexSPIを経由した外部NORフラッシュからの起動はRT1064では利用できません」と付け加えるべきです。 こうすれば混乱を避けられると思う。 改めて、素晴らしく迅速なサポートに感謝します。
記事全体を表示
マイルストーン搭載の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での正確なエンコードコマンド/パイプラインを教えてください。 よろしくお願いします、 志明
記事全体を表示
JLink Debug Authentication Hello all, Im following a project based on the MCXN947 (frdm_mcxn947 board) and we need to setup the debug authentication and signed firmware validation before sending it to the client for testing, but im very unsure about two things. Is the debug authentication restricted to the "in-field" case? where the MCU is permanently locked with keys and security configuration burned in OTP? I dont want to risk permanently breaking the only board i have If i set up the debug authentication feature, then is it still possible to connect and debug code with the on board debugger? Im debugging with VSCode with a Jlink debug .launch config, how do i add the security artefacts for enabling the debug authentication? It would be great if someone that has already tackled the thing can shed some light on how to proceed, because i only see the AN14162 being referred to and not much else in terms of documentation MCXN Security(Edgelock | secure boot | OTP) Re: JLink Debug Authentication Hello @raimbowgeddon  1. Is the debug authentication restricted to the "in-field" case? where the MCU is permanently locked with keys and security configuration burned in OTP? I dont want to risk permanently breaking the only board i have ->>No, the debug authentication is not only for "in-fileld" casse. It can be tested during development. Config it on CMPA part, not in OTP. 2. If i set up the debug authentication feature, then is it still possible to connect and debug code with the on board debugger? Im debugging with VSCode with a Jlink debug .launch config, how do i add the security artefacts for enabling the debug authentication? ->>Yes. After debug authentication is enabled, you normally cannot just start a normal J-Link session as before. You must first run the debug authentication challenge-response flow, then connect your debugger. There is a video that shows the steps for configuring and using Debug Authentication on the MCXN947. I'm not sure whether you can access it: https://www.bilibili.com/video/BV13EhAzdEzV/?spm_id_from=333.1387.homepage.video_card.click  Thank you. BR Alice Re: JLink Debug Authentication Hello @Alice_Yang, Sorry for the delayed response, i've been caught up with some other urgent work. I just followed the directions given by the video you linked, and it seems to be working! I was missing the piece about unlocking the device from the tool and then simply attaching with the debugger. I also tried to overwrite the image with another one and it works, besides a warning about CFPA region not being written, but i cannot seem to be able to do a flash erase, even if debug authentication step was done, is this expected? Does it mean that now the board will permanently be secured? Is there no way to make the board return to the factory settings now? Thank you so much for the help FS
記事全体を表示
MPC574xP BCTRL Hi: My customer is using MPC5741P for Auto ESC application. Currently, they were asked by the end OEM about BCTRL pin characteristics, such as voltage region.  Could you help check and confirm it? Thanks. Below is the waveform, it's triangle, and  OEM asked to add decouple Cap. on base control output pin from MCU side.  Re: MPC574xP BCTRL Datasheets recommend different transistor as you can see below: Also it needs to be properly bypassed/decoupled. Pay attention mainly to VDD_LV_COR: Re: MPC574xP BCTRL Hi David: Got it, thanks.
記事全体を表示
S32K3ブートローダーとHSE - ベストプラクティスとは? こんにちは、NXPチームの皆様、 当社は、HSEのフルブロックA/Bスワップを使用して、S32K312上で堅牢なOTAアップデートアーキテクチャを実装しています。 我々の目標とするアーキテクチャは以下のとおりです。 - S32K312は、2MBのPFlashを2つの1MBの物理ブロックに分割して搭載しています。 - HSE AB_SWAPは、パッシブブロックのアクティベーションサービスを介して使用されます。 - OTAパッケージはModbus/シリアル経由で受信されます。 - ブートローダーは署名付きイメージをパッシブPFlashブロックに段階化します。 - HSEは受動イメージ/SMRを検証します。 - ブートローダーがAP_SWAPを要求します。 リセット後、新しく交換されたバンクは暫定的に起動します。 確認コマンドを実行すると、スワップが永続的に適用されます。そうでない場合は、デバイスはロールバックされます。 当初は、2つのPFlashバンクとは別に、DFlashに1つのグローバルブートローダーを配置しようと試みました。そのブートローダーはOTAを受信し、パッシブPFlashバンクをプログラムし、HSE AP_SWAPを要求し、その後、確認/ロールバックの管理を継続します。 そのアプローチでは、アーキテクチャと実行時の複雑さという問題に直面しました。 1. HSE AB_SWAP は、任意のアプリケーション パーティションではなく、PFlash ブロックの境界全体で動作するようです。 2. 単一のDFlashブートローダーは、スワップ/認証済みバンクイメージの外にあります。 3. アクティブなPFlashバンクは、スワップ後も有効なブート/IVT/リセット構造を必要とします。 4. DFlashがブートローダーの実行時/レコード処理にも関与していた場合、実行時に重大なハザードが発生しました。 5.グローバルDFlashブートローダーがクリーンなフルバンクのHSE AB_SWAP生産設計と互換性があるかどうかは不明瞭になりました。 そのため、当面はPFlashブートローダーを複製したモードに移行しました。 - 各1MBのPFlashバンクには独自のIVT + ブートローダー+アプリケーションが含まれています。 - ブートローダーは、各バンクの底部に予約済みのスロットを持っています。 - アプリケーションはブートローダースロットの後に起動します。 - 署名付きOTAイメージは、ブートローダー+アプリケーションを含むフルバンクイメージです。 - HSE AB_SWAP実行後、新たにアクティブになったバンクは自己完結型でブート可能です。 HSEのフルブロックA/Bスワップには、この方法の方がはるかにクリーンに見えますが、意図された、かつ生産上安全な方法であることを確認したいと思います。これは、工場出荷時のブートローダーの目的を部分的に損なうため、最適とは言えません。 質問: 1.S32K312 HSE AB_SWAPの場合、スワップされたPFlashバンクの外に単一のグローバルDFlash常駐ブートローダーを配置するアーキテクチャは、サポート/推奨されていますか? 2. あるいは、HSE AB_SWAPは、交換された各PFlashブロックが、独自のIVT/ブートローダー/リセットパスを持ち、独立してブート可能であることを実質的に要求/推奨しているのでしょうか? 3.もしDFlashブートローダーが可能なら、SBAF/HSEブートの期待に応えられるように、スワップ後のブートフローはどのように構成すべきでしょうか? 4. S32K3上でDFlashブートローダーがフルブロックHSE AB_SWAPを管理することを示したNXPの参考例はありますか? 5.ロールバックや確認セマンティクスを持つ本番OTAの場合、複製されたPFlashブートローダーモデルの方が安全な設計でしょうか? コードとIVTをリンカースクリプトを改変することでDFlashにリンクできるという話は見ており(私たちも試しました)、しかし私たちの質問は、HSEのフルブロックA/Bスワップやセキュアブート/SMR検証を使う場合にそれが適切かどうかについてです。 よろしくお願いします。 Re: S32K3 bootloader and HSE - best practice ? こんにちは、 @coratron さん。 1.S32K312 HSE AB_SWAPの場合、スワップされたPFlashバンクの外に単一のグローバルDFlash常駐ブートローダーを配置するアーキテクチャは、サポート/推奨されていますか? ハードウェアの観点からは、何の制限もありません。どちらの選択肢も可能である。データフラッシュのサイズが十分で、データに使う予定がない場合は、ブートローダーをデータフラッシュに配置できます。データフラッシュを他の用途で使用する必要がある場合は、両方のパーティションにブートローダーのコピーを2つずつ用意するのが一般的な方法です。 2. あるいは、HSE AB_SWAPは、交換された各PFlashブロックが、独自のIVT/ブートローダー/リセットパスを持ち、独立してブート可能であることを実質的に要求/推奨しているのでしょうか? いいえ、そのような要件はありません。データフラッシュ(ブートローダーのIVT)に有効なIVTがあれば十分です。一般的な慣習としては、リセット後にブートローダーが起動され、その後ブートローダーがユーザーアプリケーションにジャンプします。 3. もしDFlashブートローダーが可能なら、SBAF/HSEのブート期待を満たすように、スワップ後のブートフローはどのように構成すべきか? SBAFまたはHSEからの具体的な要件はありません。ブートローダーが起動すると、アプリケーションにジャンプするか、新しいアプリケーションをダウンロードするか、ロールバックを行うかなどを判断し、その後(ロールバックやスワップの場合に)デバイスをリセットするか、アプリケーションにジャンプします。 4. S32K3上でフルブロックHSE AB_SWAPを管理するDFlashブートローダーを示すNXPのリファレンスサンプルはありますか? そのような例はありません。 5. ロールバック/確認セマンティクスを持つ本番OTAの場合、複製されたPFlashブートローダーモデルは意図された設計の方が安全なのでしょうか? どちらの方法も、普遍的に安全だと断言することはできません。特定のアーキテクチャの適性は、全体のシステム設計、セキュリティ要件、OTAワークフロー、ロールバック戦略に依存します。両概念は堅牢な本番環境で実装可能です。 よろしくお願いいたします。 ルーカス Re: S32K3 bootloader and HSE - best practice ? @lukaszadrapa さん、迅速なご返信ありがとうございます。これにより状況が明確になり、大いに役立ちました。DFlashにおけるブートローダーの実装を再評価することができ、成功しました。 チームは他のベンダーのドキュメントやアクセス性に慣れており、オートモーティブ アプリケーションのリーダーであるにもかかわらず、NXPは意外にも分かりにくいと感じています。 あなたの迅速なフィードバックがこれらの穴を補っています。改めてご助言ありがとうございます。とても感謝しています。あなたの回答を解決策としてマークし、あなたのチームに以下のフィードバックを送ります。 - DflashブートローダーとHSEのデモがあれば、(あなたの時間も含めて)時間を節約できたでしょう。これはAB_SWAPを使用する人にとって自然な設定だと確信しています。 - NXPはドキュメントやソフトウェアスタックを統合し、長期的に整理すべきです。互換性やバージョンが散在しており、情報源が一つにないため混乱が生じます。 よろしくお願いいたします
記事全体を表示
JLink调试身份验证 大家好, 我正在做一个基于 MCXN947(frdm_mcxn947 板)的项目,我们需要在将固件发送给客户进行测试之前设置调试身份验证和签名固件验证,但我对两件事非常不确定。 调试认证是否仅限于“现场”情况?MCU是否使用密钥永久锁定,并且网络安全配置已烧录到OTP中?我不想冒着彻底损坏我唯一一块板的风险。 如果我设置了调试认证功能,是否仍然可以连接并使用板载调试器调试代码?我正在使用 VSCode 和 Jlink debug .launch 进行调试。配置中,如何添加网络安全组件以启用调试身份验证? 如果已经处理过这个问题的人能提供一些指导就太好了,因为我只看到有人提到了AN14162 ,其他文档方面就很少了。 MCX N 安全(Edgelock | 安全启动 | OTP) Re: JLink Debug Authentication 你好@raimbowgeddon 1. 调试身份验证是否仅限于“现场”情况?MCU是否使用密钥永久锁定,并且网络安全配置已烧录到OTP中?我不想冒着彻底损坏我唯一一块板的风险。 不,调试认证不仅适用于“文件内”情况。可以在开发过程中进行测试。请在 CMPA 部分进行配置,而不是在 OTP 部分。 2. 如果我设置了调试认证功能,是否仍然可以连接并使用板载调试器调试代码?我正在使用 VSCode 和 Jlink debug .launch 进行调试。配置中,如何添加网络安全组件以启用调试身份验证? 是的。启用调试认证后,通常不能像以前那样直接启动普通的 J-Link 会话。必须先运行调试认证质询-响应流程,然后再连接调试器。 有一个视频演示了在 MCXN947 上配置和使用调试身份验证的步骤。我不确定你是否可以访问它: https://www.bilibili.com/video/BV13EhAzdEzV/?spm_id_from=333.1387.homepage.video_card.click 谢谢! BR 爱丽丝 Re: JLink Debug Authentication 你好@Alice_Yang , 抱歉回复晚了,我一直忙于其他紧急工作。我按照你提供的视频里的步骤操作了,好像奏效了!我之前漏掉了需要先用工具解锁设备,然后再用调试器连接的步骤。我还尝试用另一个镜像覆盖原有镜像,虽然出现了 CFPA 区域未写入的警告,但似乎无法执行闪存擦除操作,即使调试认证步骤已经完成,这是预期行为吗?这是否意味着该板将永久受到保护?现在没有办法将主板恢复出厂设置吗? 非常感谢您的帮助 FS
記事全体を表示
初心者がAUTOSAR環境をセットアップする S32 Design Studio for ARM 2.2 – Windows/Linux をダウンロードする際に、上記のメッセージが表示されます。 公式サイトが復旧し、ダウンロードが正常に行えるようになることを願っています。よろしくお願いいたします。 S32 Design Studio for ARM 2.2 – Windows/Linux をダウンロードする際に、上記のメッセージが表示されます。公式サイトがこの問題を解決し、ダウンロードが正常に進むようにしてくれることを願っています。ありがとう。 Re: 新手搭载autosar环境 こんにちは、 今すぐお試しください。動作するはずです。 よろしくお願いいたします。 ピーター S32K新手搭载autosar环境 先生、どうもありがとうございました。最初の問題は解決しました。しかし、S32DS_ARM_Win32_v2.2.exe統合開発環境をインストールする際に、アクティベーションエラーメッセージが表示されました。原因はアクティベーションコードの有効期限切れであることが判明しました。つきましては、有効期限の延長をお願いいたします。よろしくお願いいたします。
記事全体を表示