Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
DSPの実装:マイクロコントローラまたはFPGA こんにちは、このサブで何度も話題になっている話題だと知っていますが、この分野の方々からドメイン特有のアドバイスが欲しかったのです。私が知りたかったのは、通信分野のDSPアプリケーションに興味があり、その実装に関わりたい場合、マイクロコントローラプログラミングを学ぶことに時間を費やす価値があるのかということです。私はECEの学部生なので、正直なところFPGAの方が興味があるので、直接集中すべきか悩んでいます。混乱しています。なぜなら、最近ますます使われているSOCを扱うには組み込みソフトウェアのスキルが必要だと勧める人を見たからです。 重複した質問でしたら、本当に申し訳ありません!それに関して適切な答えが見つからず、今は少し優先順位をつけなければならない状況にある。どんなアドバイスでもいただけると大変ありがたいです! Re: DSP Implementation: Microcontrollers or FPGAs こんにちは、 @endros さん。 通信分野のDSPに興味があるなら、特に高スループットやリアルタイムの実装にはFPGAに注力する価値があります。とはいえ、基本的な組み込みCスキルは依然として有用です。なぜなら、多くのSoC/FPGAプラットフォームはソフトウェア制御、ドライバ、システム統合を伴うからです。FPGA/DSPの基礎を優先しつつ、組み込みワークフローに慣れるためにMCUプログラミングにも十分な時間を割くべきです。純粋な組み込みソフトウェアエンジニアになる必要はありませんが、完全に無視すべきではありません。 お役に立てば幸いです。 BR セレステ
記事全体を表示
Radar – Processing Chain – NXP Radar SDK 1 Table of Contents • Introduction • FMCW Radar Signal • The Radar Cube • Processing Chain Overview • Mapping the Processing Chain onto the S32R45 • Range FFT • Doppler FFT • Non-Coherent Combining • CFAR Detection • Clustering (DBSCAN) • Angle Estimation (MUSIC DoA) • NXP Radar SDK Integration • Tools and Ecosystem • Conclusion 2 Introduction In the previous articles of this series, we introduced the fundamentals of automotive radar in the Radar Overview and the hardware/software setup in Radar SW & HW Environment. Building on that foundation, this article follows the radar data on its journey through the complete processing chain — from digitized ADC samples to a final target list describing each object’s range, velocity, and angle. The chain is modeled and prototyped in MATLAB® using Radar Toolbox™ and deployed on the NXP S32R45 radar processor through the NXP Model-Based Design Toolbox for RADAR. The key processing stages are distributed across the S32R45 Cortex-A53 cores, the SPT accelerator, the BBE32 DSP accelerator, and the LAX accelerator, using optimized kernels from the NXP Radar SDK. 3 FMCW Radar Signal Frequency-Modulated Continuous Wave (FMCW) radar transmits a continuous chirp whose frequency increases linearly over time. The received echoes are mixed with the transmitted signal, producing a beat frequency (also called intermediate frequency, IF) proportional to the round-trip delay, which directly encodes target range. Figure 1: FMCW Radar Transmit and Receive Chirp Diagram The diagram plots frequency (vertical axis) against time (horizontal axis) and shows two piecewise-linear signals. The transmitted signal Tx (blue) rises linearly across the chirp, while the received signal Rx (orange) has the same shape but is delayed in time: Tx(t) = A Tx · cos( 2π f c t + 2π (f B / 2T) t² + φ 0 ) Rx(t) = A Rx · cos( 2π f c (t − t d ) + 2π (f B / 2T) (t − t d )² + φ 0 ) The relevant variables are summarized below: Symbol Meaning Tx(t) Transmitted signal (blue curve) Rx(t) Received signal (orange curve) t d Propagation delay between Tx and Rx IF Frequency difference between Tx and Rx during the chirp T Chirp (ramp) duration f c Chirp starting frequency f B Chirp bandwidth R 0 Range of detected target v Velocity of detected target The three key physical intuitions of FMCW radar are: Range comes from the beat frequency, since the propagation delay t d = 2(R 0 + v·t)/c produces a frequency offset IF = (2 f B )/(T·c) · R 0 during the linear ramp. Velocity comes from the phase evolution across successive chirps via the Doppler effect. A moving target introduces a Doppler frequency f v = (2 f c / c) · v. The chirps repeat at a fixed pulse repetition frequency (PRF), which must be high enough to capture this Doppler shift. Angle comes from the phase differences introduced across multiple receive antennas, enabling direction estimation and spatial separation of targets. Chirp parameters are chosen according to sensing requirements: the chirp duration must exceed the round-trip time to the farthest target plus the additional time needed for mixing and signal formation. 4 The Radar Cube After mixing and sampling, the acquired data is organized into a 3D structure called the radar cube, which is the input to the entire digital processing chain. For a single antenna, each chirp produces a sequence of time samples (fast time) arranged into a column — one column per chirp. Stacking chirps side by side forms a 2D matrix (samples × chirps), and repeating this for every receive antenna and stacking along a third dimension produces the cube: samples × chirps × antennas. Figure 2: The radar cube Every subsequent stage operates on this cube, progressively collapsing its dimensions and transforming raw echoes into higher-level target information. 5 Processing Chain Overview The FMCW processing chain converts the radar cube into a compact target list through a sequence of well-defined stages. Before looking at each block in detail, the table below provides a roadmap of the inputs and outputs at every step: Stage Input Output Range FFT Radar cube Range cube Doppler FFT Range cube Range–Doppler cube Non-Coherent Combining Range–Doppler cube Range–Doppler map CFAR Detection Range–Doppler map Detections DBSCAN Clustering Detections Target clusters MUSIC DoA Clusters + antenna data (range, velocity, angle) Figure 3: Processing Chain Overview The process begins at the ADC, where analog signals are digitized. Range and Doppler FFTs extract distance and velocity, forming a range–Doppler representation. Data from multiple antennas is then combined to improve robustness, CFAR detects potential targets using adaptive thresholding, DBSCAN groups detections into individual targets, and MUSIC DoA estimates each target’s angle — converting raw samples into structured outputs of range, velocity, and angle. 6 Mapping the Processing Chain onto the S32R45 A key advantage of the NXP platform is that each stage of the chain is mapped onto the most suitable compute resource of the S32R45. The FFT-based stages and Non-Coherent Combining run on the SPT accelerator, the CFAR detection runs on the BBE32 DSP, the clustering runs on the Cortex-A53 cores, and the linear-algebra-heavy MUSIC estimation is offloaded to the LAX accelerator: Figure 4: Radar processing chain hardware mapping This mapping is what allows developers to prototype the entire chain in MATLAB and then deploy each stage to dedicated radar hardware without leaving the Model-Based Design environment. 7 Range FFT The first stage operates on the radar cube by processing the fast-time samples within each chirp. For every antenna and chirp, the time-domain signal — containing superimposed beat frequencies from multiple targets — is transformed into the frequency domain using an FFT, separating the frequency components that each correspond to a distinct propagation delay, and therefore a specific range. In this application, the radar front end does not perform in-phase and quadrature (I/Q) demodulation, so the acquired signal is purely real-valued. The resulting FFT spectrum is therefore symmetric, carrying redundant positive and negative frequency components. Since only the positive frequencies correspond to physically meaningful beat frequencies here, the negative-frequency half of the spectrum is discarded. The radar cube is thus converted into a set of range profiles, where each sample index becomes a range bin. The output preserves the chirp and antenna dimensions but now contains complex values indexed by range — magnitudes indicating reflection strength, and phases retained for later processing. Figure 5: Range FFT output On the S32R45, this stage is executed on the SPT accelerator using the rangeFFT kernel provided by the NXP Radar SDK and exposed through the NXP Model-Based Design Toolbox for RADAR. 8 Doppler FFT Building on the range-transformed data, the second stage processes the slow-time dimension by examining how the complex samples evolve across consecutive chirps. For a given range bin, a moving target produces a small phase difference between the corresponding Range FFT outputs of consecutive chirps. This progressive phase shift is a manifestation of the Doppler effect and encodes the target’s radial velocity. By analyzing these phase variations over time using a second FFT, the processing chain extracts the Doppler frequency components associated with motion. This step converts the phase evolution observed across successive Range FFT outputs into velocity information, effectively mapping stationary and moving targets into different Doppler bins. The output is a set of range–Doppler maps, one per antenna, where each cell represents a specific combination of distance and radial velocity and holds a complex value describing the target echo. The Doppler FFT output is shifted (typically via an FFT-shift operation) so that the zero-Doppler component is centered and negative Doppler frequencies appear first, giving a more intuitive velocity axis: negative values for targets moving in one direction, positive for the other. Figure 6: Doppler FFT output As with the Range FFT, this stage is accelerated on the SPT accelerator through the Radar SDK dopplerFFT kernel. 9 Non-Coherent Combining At this point, each antenna provides its own range–Doppler map, differing mainly in phase due to the direction of arrival. These maps are combined across the antenna dimension, typically by computing magnitudes and aggregating them through averaging. The input is a set of complex-valued maps; the output is a single range–Doppler magnitude matrix in which the antenna dimension has been collapsed. This suppresses uncorrelated noise and reinforces consistent target reflections, producing a cleaner, more robust representation well suited for detection. Figure 7: Non-Coherent Combining output Note: the pre-combining per-antenna data is retained, because it is required later for MUSIC direction-of-arrival estimation. This stage corresponds to the Non-Coherent Combining kernel ( NonCohComb ) of the NXP Radar SDK, executed on the SPT accelerator. 10 CFAR Detection The combined range–Doppler magnitude matrix is then scanned to identify potential targets. Each cell is evaluated against a locally adaptive threshold derived from its surrounding neighborhood: nearby training cells estimate the noise level, while guard cells are excluded to avoid contaminating the estimate with the target’s own energy. Through this process, the continuous-valued matrix becomes a discrete set of detections — cells whose magnitude significantly exceeds the estimated noise background. These are effectively points in range–velocity space representing likely target reflections. CFAR runs on the BBE32 DSP accelerator. 11 Clustering (DBSCAN) CFAR detections often include several neighboring points from the same physical target, as well as isolated points caused by noise. To organize them, DBSCAN clustering is applied in the range–velocity domain, grouping points based on spatial density. Taking the detection coordinates as input, DBSCAN forms clusters where dense regions correspond to real targets, while sparse detections are discarded as noise. The output is a set of target clusters, each consolidating a single target’s range and velocity. This stage runs on the Cortex-A53 cores. 12 Angle Estimation (MUSIC DoA) For each cluster, the detections are traced back to the complex per-antenna data from the range–Doppler stage. These per-antenna samples form vectors encoding the phase differences related to the direction of arrival. Combining multiple detections within a cluster, a covariance matrix is estimated to capture the spatial characteristics of the received signals. An eigenvalue decomposition separates signal and noise subspaces, and criteria such as AIC determine the number of significant sources. The MUSIC algorithm then scans possible directions and identifies those that best match the signal subspace. MUSIC has important practical limitations: the number of detectable signals must be strictly smaller than the number of antennas, otherwise the covariance matrix cannot be properly decomposed. It is also sensitive to low signal-to-noise ratio, correlated reflections, and array calibration errors — constraining its use in scenarios with many closely spaced targets or too few antenna elements. On the S32R45, the MUSIC implementation is offloaded to the LAX accelerator through the NXP Model-Based Design Toolbox for RADAR, demonstrating how computationally intensive linear-algebra operations can be accelerated directly from MATLAB-generated code. The result is a direction-of-arrival estimate for each clustered target, completing its spatial characterization. 13 NXP Radar SDK Integration The NXP S32R45 Radar SDK (RSDK 1.2.0) provides optimized radar processing kernels designed for the S32R45 radar processor. Through the NXP Model-Based Design Toolbox for RADAR, these kernels are callable directly from MATLAB and are automatically integrated into the generated application, so developers work at the algorithm level while the toolbox handles deployment to the accelerators. In the processing chain presented in this article, the Radar SDK supplies optimized implementations for: Range FFT — SPT accelerator ( rangeFFT ) Doppler FFT — SPT accelerator ( dopplerFFT ) Non-Coherent Combining — SPT accelerator ( NonCohComb ) CFAR — BBE32 DSP accelerator This lets developers prototype and validate the full chain in MATLAB while leveraging the S32R45 SPT, BBE32 DSP, and LAX hardware accelerators in the final deployed application, and it supports both standalone and Processor-in-the-Loop (PIL) execution. 14 Tools and Ecosystem This processing chain brings together products from both MathWorks and NXP. MathWorks MATLAB® Radar Toolbox™ MATLAB Coder™ Embedded Coder® NXP S32R45 radar processor (Cortex-A53 + SPT + BBE32 DSP + LAX) NXP S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 NXP Model-Based Design Toolbox for SPT 1.9.0 S32 Design Studio 3.6.1 S32R45 – High-Performance Processor for Imaging Radar 15 Conclusion The FMCW radar processing chain transforms the raw radar cube into a compact set of target descriptors through a sequence of well-defined stages. Starting from time-domain samples, range and velocity are extracted with FFT operations, detections are found through adaptive thresholding and grouped into targets, and angle estimation leverages antenna diversity to determine direction. Each final target is characterized by the tuple (range, velocity, angle). By mapping these stages onto the S32R45 Cortex-A53, SPT, BBE32 DSP, and LAX resources through the NXP Radar SDK and the NXP Model-Based Design Toolbox for RADAR, the entire chain can be prototyped in MATLAB and deployed to dedicated radar hardware within a single Model-Based Design workflow.
記事全体を表示
Radar - SW & HW Environment 1 Table of Contents • Introduction • Reference Architecture • Hardware Environment • Software Environment • Radar Signal Chain • From Simulation to Target • Installing the NXP Toolchain • Next Article in the Series • References 2 Introduction This article presents the NXP hardware platforms and the MathWorks and NXP software tools used to build an automotive radar application. The development workflow is anchored in the MathWorks example "Radar Signal Simulation and Processing for Automated Driving," which provides a reference architecture spanning driving-scenario simulation, radar modeling, and signal processing. The resulting signal-processing chain is then adapted and deployed onto NXP radar hardware using NXP-specific toolboxes and hardware accelerators. This article is part of the Radar Application Development Series, which describes the complete workflow for developing, deploying, and optimizing automotive radar applications on NXP radar platforms. The purpose of this article is to introduce the overall software and hardware environment and show how the different tools, hardware components, and processing engines fit together within a radar development workflow. The next article in this series, "Radar - Processing Chain," will explore in depth each processing block presented in the Radar Signal Processing section: Range FFT, Doppler FFT, Non-Coherent Combining, CFAR Detection, Clustering, and Direction-of-Arrival (DoA) estimation. 3 Reference Architecture The starting point for the radar application is the MathWorks reference example, which models a complete automotive radar system end to end. The workflow begins by defining a highway driving scenario using the Automated Driving Toolbox ( drivingScenario ), where vehicles and traffic participants are modeled. The ground-truth generated data then feeds the radar model.   Figure 1: MathWorks example bird's-eye plot with Radar detections A 77 GHz FMCW radar is parameterized from high-level system requirements such as: Maximum detection range, typically 250-300 m for long-range radar Range resolution, around 1 m Velocity resolution Maximum relative target velocity, up to around 230 km/h The example then builds a transceiver model with antenna arrays, transmitter/receiver components, and signal-propagation effects, generating synthetic detections that estimate the position and velocity of surrounding vehicles. For the NXP application, the reference architecture is divided into two domains: Environment Simulation Executes entirely within MATLAB, and is responsible for: Driving scenario generation Vehicle motion simulation Target ground-truth generation FMCW signal generation Radar channel and propagation modeling Radar Signal Processing Contains the processing chain deployed on the S32R45 platform: Range FFT processing Doppler FFT processing Non-Coherent Combining CFAR detection Clustering Direction-of-Arrival (DoA) estimation The Radar Signal Processing domain forms the basis of the embedded radar application deployed on the S32R45 Evaluation Board. 4 Hardware Environment 3.1 S32R45 Evaluation Board The primary processing platform is the NXP S32R45 Evaluation Board, a development platform for high-performance 77 GHz radar applications such as adaptive cruise control, autonomous emergency braking, and cascaded imaging radar. It integrates several specialized processing engines optimized for radar workloads. Processing engine Role 4x Arm® Cortex®-A53 cores Application-level processing, radar control, clustering, and object management SPT Accelerator Optimized FFTs and high-throughput radar signal-processing kernels BBE32 DSP Vectorized signal processing, detection algorithms, and custom radar kernels LAX Accelerator Matrix and linear-algebra operations for accelerated angle estimation   Figure 2: S32R45 block diagram 3.2 TEF82xx Customer Application Board The TEF82xx is a fully integrated 76-81 GHz RFCMOS automotive radar transceiver providing the RF front end for signal generation and capture. It integrates 3 transmit channels, 4 receive channels, ADCs, a low-phase-noise VCO, and a phase rotator, and is fully compatible with the S32R45. In the current application, the input signal is sourced from simulation rather than hardware, so the TEF82xx is not actively used. It is included as a placeholder for future hardware-in-the-loop and real-sensor integration. 5 Software Environment The radar application combines MathWorks toolboxes for algorithm development with NXP toolboxes and tools for deployment and accelerator integration. 4.1 MathWorks Tools Tool Role in the workflow Radar Toolbox FMCW waveform generation, propagation modeling, detection, and analysis Automated Driving Toolbox Scenario modeling, road/vehicle simulation, and ground-truth generation 4.2 NXP Tools Tool Version Role in the workflow S32 Design Studio for S32 Platform 3.5 IDE, compiler, debugger, and deployment environment for the S32R45, including its accelerators NXP Model-Based Design Toolbox for SPT 1.9.0 Bit-exact SPT simulator integration and rapid prototyping in MATLAB NXP Model-Based Design Toolbox for RADAR 1.0.0 MATLAB integration for S32R45; SPT/LAX kernel execution, code generation, and PIL workflows NXP Radar SDK (S32R45) 1.2.0 Optimized radar algorithms, accelerator libraries, SPT/LAX kernels, and embedded deployment infrastructure Together, these tools act as the gateway between the MathWorks and NXP ecosystems, enabling algorithm development, simulation, code generation, deployment, and SIL/PIL validation within a common workflow. 6 Radar Signal Chain Once the FMCW echoes are generated or captured, the signal-processing chain transforms the radar cube into a list of detected objects. The application currently implements the following stages. # Stage What it does Runs on 1 ADC Acquisition Digitizes the beat signal into a radar data cube, using samples x chirps x antennas TEF82xx ADCs → S32R45 2 Range FFT Fast-time FFT converts beat frequency into target range SPT accelerator 3 Doppler FFT Slow-time FFT resolves velocity, producing the processed radar cube SPT accelerator 4 Non-Coherent Combining Combines the magnitude of the range/Doppler-processed radar cube across channels, producing the range-Doppler magnitude matrix SPT accelerator 5 CFAR Detection Applies Constant False Alarm Rate thresholding on the range-Doppler magnitude matrix to detect possible targets BBE32 DSP 6 Clustering Groups neighboring detections, for example using DBSCAN, into physical objects Cortex-A53 cores 7 Angle / DoA Estimation Estimates azimuth/elevation across the antenna array, using methods such as beamforming or MUSIC LAX accelerator The output of the chain is a list of detected objects with range, relative velocity, and angle of arrival. Future Improvements The current application focuses on signal processing and object detection. Planned enhancements include: Multi-target tracking, including Kalman filtering and track-to-track association Hardware-in-the-loop testing using the TEF82xx front end 7 From Simulation to Target The MathWorks reference example executes entirely within MATLAB. During deployment, the example is partitioned into the Environment Simulation block and the Radar Signal Processing block, where the computationally intensive signal-processing functions are replaced with NXP-optimized implementations from the Radar SDK. This delivers faster execution, reduced CPU utilization, and accelerator offloading on the S32R45. 8 Installing the NXP Toolchain 7.1 Installation Order The development tools must be installed in the following order to ensure that all external dependencies required by the NXP MBDT for RADAR are available before it is configured: S32 Design Studio for S32 Platform 3.5 S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for SPT 1.9.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 7.2 Integrating the Development Environment After NXP MBDT for RADAR is installed, the integration of S32 Design Studio and S32R45 Radar SDK is performed using the MATLAB Live Script: mbd_lax_dependencies_path.mlx The script is located at the root of the NXP MBDT for RADAR installation. Running this script configures the required dependency paths and establishes the connection between MATLAB, the NXP Model-Based Design Toolbox for RADAR, S32 Design Studio, and the S32R45 Radar SDK. Once the script is completed successfully, the environment is ready for simulation, code generation, accelerator kernel execution, and Processor-in-the-Loop (PIL) validation. 7.3 Installation Methods The NXP toolboxes ship as MATLAB Toolbox packages (.mltbx) and can be installed in three ways: Manual install (.mltbx) - Double-click the .mltbx file, or right-click and select Install in MATLAB. The Add-On Manager installs and registers the toolbox automatically. Via NXP Support Package - Install NXP_Support_Package_RADAR from MATLAB Add-Ons, then follow the guided steps to download and install MBDT for RADAR and generate/activate the free license. Via the Automotive Software Package Manager - A bundle installer that walks through toolbox installation, dependency configuration, and license activation. 9 Next Article in the Series This article introduced the software environment, hardware environment, deployment workflow, and high-level radar signal-processing architecture. The next article, "Radar - Processing Chain - RSDK," will provide a detailed analysis of each processing block presented in Section 5: Range FFT Doppler FFT Non-Coherent Combining CFAR Detection Clustering Direction-of-Arrival (DoA) Estimation It will also explain how these algorithms are mapped onto the S32R45 processing resources and how the NXP Radar SDK accelerates the execution of each stage. 10 References MathWorks Radar Signal Simulation and Processing for Automated Driving Radar Toolbox Automated Driving Toolbox NXP S32R45 High-Performance Processor for Imaging Radar S32R45 Evaluation Board TEF82xx 77 GHz Radar Transceiver Model-Based Design Toolbox MBDT for RADAR - Knowledge Base NXP Support Package for RADAR How to install .MLTBX
記事全体を表示
Implementing MCUboot Using SEC Tool This video is currently being processed. Please try again in a few minutes. (view in My Videos) announcement Re: Implementing MCUboot Using SEC Tool This video shows how to implement MCUboot using the SEC Tool on the FRDM-MCXN947 board, step by step.
記事全体を表示
Processor-in-the-Loop (PIL) 1 Table of Contents •Introduction •Overview •Context •Component Overview •Design and Implementation •Results •Common Pitfalls & Troubleshooting •Summary & Next Steps •References 2 Introduction A virtual vehicle can reproduce vehicle dynamics, driver inputs, road scenarios, sensor stimuli, and network communication long before the complete physical vehicle is available. However, a successful desktop simulation answers only one part of the engineering question: does the algorithm behave correctly as a model? Processor-in-the-Loop (PIL) adds the target processor to the validation loop. The plant, scenario, and test harness remain in MATLAB ® and Simulink ® , while selected generated algorithm code is cross-compiled, downloaded, and executed on the NXP processor. Inputs are sent from the host to the target, and the computed outputs are returned to the simulation for comparison and analysis. This makes PIL the bridge between a virtual vehicle that behaves correctly on the development computer and embedded software that must produce equivalent results on its intended processor. It also provides target-based execution-time measurements, helping engineers assess whether an algorithm is not only functionally correct, but also suitable for its timing budget. 3 Overview This article presents how Processor-in-the-Loop fits into a Model-Based Design workflow for virtual vehicle development. The goal is to show where PIL adds value between desktop simulation and deeper hardware integration, and how the same virtual vehicle and scenario can be reused to validate generated code on the target processor. In this workflow, the model remains the starting point. The virtual vehicle provides the plant behavior, the simulated environment provides repeatable driving conditions, and the selected algorithm is generated and executed on target hardware. PIL therefore supports a controlled transition from model behavior to target implementation behavior. Figure 1. PIL connects virtual vehicle simulation with generated algorithm execution on target hardware. 4 Context The practical context for this article is the Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. project. In that setup, driver inputs come from a physical steering wheel and pedals, the vehicle is driven through a RoadRunner simulated environment, and an S32N processor communicates with the host simulation while making vehicle-level decisions. The virtual vehicle is created with MathWorks tools and reused as the common integration point for driver inputs, vehicle behavior, RoadRunner scene interaction, Unreal Engine visualization, CAN communication, and closed-loop feedback from the physical setup. From that perspective, PIL is not used to move the entire virtual world to the processor. Instead, the virtual vehicle and simulated scenario remain on the host while selected generated algorithms are executed on the target. This keeps the environment flexible and repeatable while bringing processor behavior into the validation loop. 5 Component Overview A PIL-enabled virtual vehicle workflow combines the following elements: Virtual vehicle - represents vehicle dynamics, driver interaction, powertrain, steering, braking, CAN communication, and feedback paths. Virtual scene and scenario - provides roads, lanes, signs, intersections, actors, traffic movement, and repeatable test conditions using RoadRunner and Unreal Engine. PIL component - contains the selected generated algorithm code that is cross-compiled and executed on the target processor. S32N main node - acts as an aggregator and decision-maker, receiving information from sensing nodes and sending high-level commands to actuator nodes. S32N positioning: S32N is a suitable solution for running complex central-compute algorithms in PIL because it is positioned at the point where vehicle-level decisions, aggregated data, CAN communication, and actuator commands come together. 6 Design and Implementation A practical PIL workflow starts by selecting a bounded algorithm and keeping the plant, scene, and test harness on the host. This makes the test setup easier to control and keeps the comparison focused on the generated target implementation. 6.1 Select the algorithm boundary Relevant candidates include data aggregation, vehicle-level decision logic, Automated Emergency Braking logic, actuator command generation, CAN signal processing, and telemetry preparation. 6.2 Create repeatable virtual tests Use the simulated environment to define controlled driving conditions such as road geometry, actors, traffic movement, obstacle placement, and driver commands. The same scenario can be replayed for model and PIL execution. 6.3 Establish the model baseline Run the selected scenario with the original Simulink implementation and log the component inputs, outputs, and vehicle-level signals required for comparison. 6.4 Run the generated implementation in PIL Generate and build the selected component for the supported S32N5 target configuration. During the PIL run, Simulink sends test vectors to the target and receives the target results while the rest of the virtual vehicle continues to execute on the host. 6.5 Compare and profile Compare model and PIL outputs using the acceptance criteria defined for the algorithm. Where supported, collect target-side execution-time data to evaluate whether the generated component fits its timing budget. (function() { var wrapper = document.getElementById('lia-vid-6401636318112w386h386r961'); 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) PIL Setup on S32N5. 7 Results The result of this workflow is a direct comparison between model behavior and generated code running on the target. A useful result set shows whether target outputs remain equivalent to model outputs, whether decision thresholds and state transitions occur under the same scenario conditions, and whether the target-side execution time fits the assigned budget. Because the virtual scenes are controlled and repeatable, failing cases can be preserved as regression scenarios and rerun after model, configuration, or implementation changes. (function() { var wrapper = document.getElementById('lia-vid-6401636809112w960h540r168'); 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) 8 Common Pitfalls & Troubleshooting The PIL boundary is too large - keep the virtual world, visualization, and detailed plant on the host. Simulation time is confused with target execution time - use target-side profiling for algorithm timing conclusions. Model and target interfaces differ - keep signal definitions, data types, scaling, units, and sample times consistent. CAN definitions are inconsistent - reuse the same DBC definitions across the simulation and physical network. PIL is treated as complete system validation - PIL validates selected generated code on the processor; full distributed-system behavior still requires later integration stages. 9 Summary & Next Steps PIL connects the virtual vehicle, simulated scenarios, and S32N5 target execution into one validation flow. The host continues to simulate the driver, vehicle, road, actors, and environment, while selected generated main-node algorithms execute on the S32N5. A practical next step is to select one bounded S32N5 function, define its acceptance criteria, and replay a representative RoadRunner scenario first with the model and then in PIL. Suitable starting points include data aggregation, AEB decision logic, high-level actuator command generation, or CAN signal processing. 10 References Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. Creating virtual vehicle with MathWorks - Overview Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine) MathWorks: Processor-in-the-Loop Simulation
記事全体を表示
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. 新手搭载autosar环境 Thank you very much for the teacher's support. The environment has been set up.
記事全体を表示
新手搭载autosar环境 下载S32 Design Studio for ARM 2.2 – Windows/Linux 的时候,提示如上 希望能官网能重置一下,可以进行正常下载  谢谢 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环境 你好, 请立即尝试。应该可以正常运行了。 顺祝商祺! Peter S32K新手搭载autosar环境 非常感谢老师 ,第一个问题解决了,但是在安装S32DS_ARM_Win32_v2.2.exe集成开发环境时,提示激活失败,查明原因是Activation Code过期导致,特申请延期   谢谢 新手搭载autosar环境 非常感谢老师支持    环境已经搭建完成
記事全体を表示
初心者が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統合開発環境をインストールする際に、アクティベーションエラーメッセージが表示されました。原因はアクティベーションコードの有効期限切れであることが判明しました。つきましては、有効期限の延長をお願いいたします。よろしくお願いいたします。 新手搭载autosar环境 先生のご支援に心より感謝申し上げます。環境は整いました。
記事全体を表示
i.MX RT1010 フラッシュの問題 カスタムボードで@i.MX RT1010を使っていて、フラッシュの問題に直面しています。 すべての電源レールは安定しており、仕様を満たしています。 リセットピンは安定しています(電源投入後HIGH)。 デバッガーはターゲットを検出するが、フラッシュ書き込みは必ず失敗する。 既にハードウェアのショートやはんだ付け不良がないか確認済みです。 開発ボード Re: i.MX RT1010 Flashing Issue こんにちは、 @keerthisri123。 より良くサポートするために、次の情報を教えてもらえますか? -RT1010-EVKと同じ外部フラッシュ機器を使っていますか?もしなければ、カスタムボードに使われているフラッシュデバイスの部品番号を教えていただけますか? -どの画像をプログラムしようとしているのですか?SDKの例ですか、それともご自社のカスタムアプリケーションですか? -デバイスのプログラミングにはどのツールを使用していますか?例えばMCUxpresso IDEやSecure Provisioning Toolなどはどうでしょうか? -JTAGかSWDで繋がっていますか? もし他に役立ちそうな詳細があれば、遠慮なくお知らせください。 BR ハビブ Re: i.MX RT1010 Flashing Issue こんにちは、 @keerthisri123 さん、 UARTインターフェースを通じてデバイスに接続できるか確認していただけますか?もしそうなら、Secure Provisioning Tool ユーザーガイド v26.03のセクション6.15.2「RT10xx/RT116x/RT117xデバイスの基板接続」に記載されている手順に従い、結果を教えていただけると助かります。これにより、問題がSWD接続に関連しているのか、それとも別のハードウェアの問題なのかを判断するのに役立ちます。 Secure Provisioning Toolから「Help → User Guide」から直接ユーザーガイドにアクセスできます。 さらに、ハードウェア開発ガイドの第5章「デバッグとプログラミング」の復習 MIMXRT1010 プロセッサをおすすめします。この章では、ハードウェア設計の検証や信頼性の高いデバッグ動作の確保に役立つデバッグコネクタ実装に関するいくつかの推奨事項やベストプラクティスを提供します。 電源投入時に測定したブートモードピンとブート構成ピンの状態はどうなっていますか?彼らは安定していますか? 最後に、パワーアップシーケンスのオシロスコープキャプチャを提供してもらえますか?これにより、電源投入タイミングと初期化シーケンスが正しく実行されていることを確認できます。 BR ハビブ Re: i.MX RT1010 Flashing Issue こんにちは、ハビブさん。 ご返信ありがとうございます。 詳細は下記をご覧ください。 外部フラッシュ:カスタムボードにはAT25SF128A-SHB-T QSPI NORフラッシュを使用しています。EVKと同じです。 画像: evkmimxrt1010_igpio_input_interrupt SDKの例 をプログラムしようとしています 。 プログラミング ツール: SEGGER J-Link Commander V9.56およびSEGGER J-Flash Lite V9.56 。 デバッグインターフェース:JTAGで、RT1010-EVKと同じインターフェースを使用します。 参考のために画像も添付しました。 すべての電源シーケンスリセットラインは正常に動作しています。 Re: i.MX RT1011 Flashing Issue こんにちは、ハビビさん、 私が使用しているセキュアプロビジョニングツールの参考画像をいくつか添付しました。 JTAGとUARTの両方のインターフェースを使っていますが、下のエラーログに示されているように 「接続、電源、ISPモードへのリセットを確認」 というメッセージが出続けます。 この問題のトラブルシューティングの次のステップについてアドバイスをいただけますか? セキュアなプロビジョニングプロセスにおいて、従うべき特定の手順はありますか?また、これらの手順を進める前に、実施しておくべきハードウェアのチェックはありますか? サポートにあらかじめ感謝いたします。 Re: i.MX RT1011 Flashing Issue こんにちは、 @keerthisri123。 このThreadは公開されているので、よりプライベートなコミュニケーションチャネルで調査を続け、設計図を安全に確認できるようにサポート チケット を開いていただけませんか?これにより、問題のさらなる分析が可能になり、ハードウェア接続に関する潜在的な問題を排除することができます。 チケットを開く際は、この投稿を参照して私の名前をお知らせください。引き続きサポートいたします。 初期レビューを円滑に進めるため、基板の回路図一式を添付してください。特に以下の点にご注意ください。 -ブートモードピンとブート構成ピン。 外部フラッシュ接続。 -コアとデバッグインターフェース接続。 電源回路。 -クロック接続。 -電源投入シーケンス、および電源投入中のブートモードピンとブート構成ピンの状態をオシロスコープでキャプチャします。 BR ハビブ Re: i.MX RT1011 Flashing Issue こんにちは、ハビブ ご回答ありがとうございます ブートオプションが正しく設定されておらず、Qspiが動作していないという問題が見つかりました。この問題を解決します。 よろしくお願いします。 マハラジャM
記事全体を表示
MIMXRT1186:首次 LPIT 触发未能进入 ADC 中断。 我正在使用 FRDM MIMXRT1186 EVK 板,SDK V26.03。我烧录了 LPIT ADC 演示项目,以学习外设触发的 ADC 触发信号转换。但是,当我更改 LPIT 触发频率时——具体来说,是通过将 app.h 中的宏定义 LPIT_PERIOD 修改为 50,从而得到 20 kHz 的触发速率——我遇到了一个问题:第一个 LPIT 触发无法进入 ADC 中断。 为了找出根本原因在于 LPIT 还是 ADC 外设,我进行了两项测试: 交换了ADC和LPIT模块的初始化顺序(先初始化ADC,再初始化LPIT); 在 ADC1_IRQHandler 函数中增加了 GPIO 切换操作,并通过 XBAR (kXBAR1_OutputIomuxXbarInout19) 将 LPIT 触发信号路由到外部引脚。然后捕获引脚上的波形。 示波器测量结果证实 LPIT 触发信号已正确生成,但 ADC 没有响应,没有进入其中断服务程序。 我无法理解为什么提高触发信号频率会引入这个问题。请问有人能提供一些故障排除方面的建议吗?提前致谢。测试代码附后供参考。 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. 嗨@ChandlerY , 感谢分享代码。 我目前正在进行一些测试,稍后会将测试结果反馈给您。 此致, 巴勃罗 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. 嗨@ChandlerY , 仅在第一次中断时看到的额外延迟是由 CM33 向量表和 ISR 代码位于非 TCM 存储器(通过缓存访问的 XSPI 闪存/OCRAM)中引起的。 您能否帮我测试一下,将所有 CM33 代码(向量表和 ISR)放入 TCM 后,该行为是否仍然存在? 此致, 巴勃罗 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. 嗨@ChandlerY , 由于这种行为与外围设备无关,而是与代码所在位置有关,因此一种选择是在非 XIP 模式下运行应用程序,这意味着图像存储在 Flash 中,而代码从 RAM 执行。 您可以通过以下链接中的安全配置工具找到配置步骤: 处理器特定工作流程 — 安全配置工具 26.06 此致, 巴勃罗 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. 嗨,帕布罗 感谢您的回复,我已经测试过了,当 cm33 代码在 TCM 中运行时,第一次 LPIT 触发并进入 ADC 中断,它是有效的。但是当 cm33 代码在 flash 中运行时,如何解决这个问题?能否提供一些解决方法?非常感谢。
記事全体を表示
Android 16:なぜNXPはvendor_bootでデバイスツリーを処理する独自の方法を考案したのか Android 16 1.4.0リリースに含まれていた最後のu-bootブートローダーを調べたところ、設定オプション「CONFIG_INCLUDE_DTB_TO_VENDOR_BOOT」がブートローダーに追加されていることがわかりました。 古いAndroidバージョンでは「dtbo」パーティションを使ってメインデバイスツリーを保存していたという問題が解決すると思っていました。私の理解ではそれは間違いでした。なぜなら、メインデバイスツリーは「vendor_boot」パーティション(少なくともvendor_boot v4では)に配置されるべきで、DTBOパーティションはデバイスツリーのオーバーレイで埋められ、それをメインデバイスツリーに適用してハードウェアバリアントをサポートするからです。 S32デバッグ・プローブのセットアップの詳細については、 https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions 文書化されているように、vendor_boot 内には 1 つのデバイス ツリーのみが存在する必要があります。 しかし現在、NXPは「dtbo」パーティションを廃止し、vendor_boot内の「dt_table_header」構造体を使用して、複数の完全なデバイスツリーをvendor_bootに直接追加する実装を行っています。このヘッダーは通常、「dtbo」パーティション内で複数のデバイスツリーオーバーレイを整理するために使用されますが、「vendor_boot」内では使用されません。 このNXP特有のデバイスツリー処理方法は、DTBOからのメインデバイスツリーとデバイスツリーオーバーレイを使った標準的なAndroid方法と矛盾しています。これにより、デバイスツリーオーバーレイの概念を使ってAndroidポートを維持するユーザー(私のような)にとっては難しいです。 NXPはなぜデバイスツリーのバリアントをそのような方法で実装することを選んだのでしょうか? この挙動をAndroidで記録されているやり方に戻す予定はありますか? Android Re: Android 16: Why has NXP invented an own way to handle device trees in vendor_boot こんにちは、 Androidでは複数のデバイスツリーは必須ではありませんので、OSのアーキテクチャに必須の変更がない限り、これまで多くのバージョンでデフォルトとなっているため、BSPの提供方法に変化はないと思います。 また、デバイスツリーを選択するには、ブートローダーが以下のことを行う必要があることに注意してください。 1> SoCを識別し、対応する.dtbファイルをロードします。ストレージからメモリへ。 2> ボードを識別し、対応する.dtboファイルをロードします。ストレージからメモリへ。 3> .dtb を重ね合わせる.dtbo はマージされた DT になります。 4> マージされたDTのメモリアドレスを指定してカーネルを開始します。 そのため、同じハードウェアを使用し、異なる実装/デモンストレーションのためにわずかな変更を加えるだけなので、どちらのデバイスツリーを使用すべきかを識別する方法がありません。同じSOM(同じ基本構成のSoC+DDR+電源IC)を使用しながら異なるハードウェアを扱っている場合にのみ、これが役立つと思います。つまり、これは私たちの作業・ソフトウェアの提供方法に合わず、追加してもメリットが見当たりません。 よろしくお願いいたします。 アルド。
記事全体を表示
RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL Hello, we are testing the signing and encryption process on RT1176 CPU. Our basic System setup is: UART/JTAG <-> RT1176 <-> SPI Nor Flash The Software we use for testing is: - RT1176 testfirmware (simple firmware which does active an LED after boot) - NXP MCUXpresso Secure Provisioning / blhost (for signing and encryption via UART) - Segger JFlash (for Flash access via JTAG) So far, we carried out the following tests: 1) While the CPU is unlocked and signing is off, the firmware (unsigned / not encrypted) boot as expected and we can access the flash without problems via JTAG. 2) While the CPU is unlocked and signing is active, the firmware (signed / not encrypted) boot as expected and we can access the flash without problems via JTAG. 3) While the CPU is locked and signing is on, the firmware (signed / encrypted) will not boot and access to the flash becomes unstable via JTAG. So, we have some kind of encryption issue. But before we examine the big encryption issue we want to understand the unstable flash behavior in step 3. During a few tests, it became apparent that the flash problem always occurs as soon as BT_FUSE_SEL is blown (BT_FUSE_SEL intact: full flash access via jtag, BT_FUSE_SEL blown: unstable flash access via JTAG). Since we're still testing, we haven't disabled JTAG via fuse setting. So the Question is: Why does BT_FUSE_SEL cause us to lose access to flash? (Is there some read-out-protection active when the CPU is locked? Does the segger jflash tool have problems with the locked CPU? ...) Also see: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/mxrt1176-quot-half-quot-bricked-after-programming-fuses-for/m-p/2044051 -> same issue: BT_FUSE_SEL > no flash access Thanks in advance. Best regards, Florian Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL Hi @florian_arndt , Thanks for your interest in NXP MIMXRT series! BT_FUSE_SEL does not directly enable SPI NOR read-out protection or disable JTAG. Its function is to force the Boot ROM to use the boot configuration stored in eFuse instead of the BOOT_CFG pins. If the OTFAD/encrypted-XIP configuration has also been programmed into eFuse, burning BT_FUSE_SEL makes that configuration effective on every boot and removes the possibility of bypassing it through the BOOT_CFG pins. An incorrect OTFAD context, key, address range, or encrypted image can therefore cause the Boot ROM to fail before the application starts. Therefore, I believe the most likely cause at this point is that the GPIOs related to boot have been bypassed, but the corresponding eFuse has not been properly configured. BT_FUSE_SEL itself does not affect the JTAG connection. I suggest you conduct an A/B test to quickly pinpoint the issue. Best regards, Gavin Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL Hello @Gavin_Jia, thanks for your answer! Today we fixed the encryption process (bug in our firmware). Our Firmware is now booting with signing/encryption activated in the CPU. So the big issue is fixed. Whats left is the spi-flash read out issue via JTAG after setting BT_FUSE_SEL. Attached you will find our fusemap. Do you see anything which could lead to our problem? Thanks in advance. Florian
記事全体を表示
MIMXRT1186:最初のLPITトリガーがADC割り込みに入るのに失敗しました。 私はFRDM MIMXRT1186 EVKボード、SDK V26.03を使っています。LPITのADCデモプロジェクトをフラッシュして、ペリフェラルでトリガーされたADC変換を学びました。しかし、LPITトリガー周波数を変更したところ(具体的には、app.hのマクロ定義LPIT_PERIODを50に変更し、20kHzのトリガーレートを実現したところ)、問題が発生しました。最初のLPITトリガーがADC割り込みに入らないのです。 根本原因がLPITにあるのかADCペリフェラルにあるのかを調べるために、2つのテストを行いました。 ADCモジュールとLPITモジュールの初期化順序を入れ替えました(最初にADCを初期化し、次にLPITを初期化)。 ADC1_IRQHandler関数内にGPIOトグル操作を追加し、LPITトリガー信号をXBAR(kXBAR1_OutputIomuxXbarInout19)を介して外部ピンにルーティングしました。次に、ピン上の波形をキャプチャした。 オシロスコープによる測定では、LPITトリガー信号が正しく生成されていることが確認されたが、ADCは割り込みサービスルーチンに入って応答しない。 トリガー周波数を上げるとなぜこの問題が起きるのか分かりません。どなたかトラブルシューティングのアドバイスをいただけませんか?どうぞよろしくお願いいたします。参考のためにテストコードを添付します。 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. こんにちは、 @ChandlerY さん。 コードを共有していただきありがとうございます。 現在、それを使っていくつかテストを行っており、結果が出次第ご連絡いたします。 よろしくお願いします、 パブロ Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. こんにちは@ChandlerY。 最初の割り込みでのみ見られる追加の遅延は、CM33ベクターテーブルとISRコードが非TCMメモリ(キャッシュ経由でアクセスされるXSPIフラッシュ/OCRAM)に存在していることが原因です。 すべてのCM33コード(ベクターテーブルとISR)をTCMに配置した後も、この動作が続くかどうかテストするのを手伝ってもらえますか? 敬具 パブロ Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. こんにちは、パブロさん。 ご返信ありがとうございます。テストしたところ、TCMでcm33コードを実行すると、最初のLPITがトリガーされてADC割り込みに入ると正常に動作しました。でも、cm33コードがflashで動くときにこの問題をどう解決すればいいのか、何か回避策を教えていただけますか?本当にありがとうございました。 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. こんにちは、 @ChandlerY さん。 この動作はペリフェラルではなく、コードの所在地に関係しているため、アプリケーションを非XIPモードで実行するという選択肢があります。つまり、画像はFlashに保存され、コードはRAMから実行されます。 以下のリンクでSecure Provisioning Toolを使って設定手順を確認できます: プロセッサ固有のワークフロー — Secure Provisioning Tool 26.06 敬具 パブロ
記事全体を表示
MPC5746C hangs (no boot, no UART) at 115°C ambient Part: MPC5746C (Power Architecture Z4, SDK: NXP MPC57xx platform SDK) During thermal chamber testing at 115°C ambient, our MPC5746C-based board becomes completely unresponsive on boot — no UART console output at all, and this happens on every boot attempt at that temperature. The part appears to fully recover after cooling: reflashing/rebooting at room temperature restores normal operation with no persistent damage. Interestingly, we can still successfully reprogram flash via PEMicro JTAG debug probe while the board is at 115°C — we've confirmed this by flashing a build with an incremented version string at temperature and reading back the new version after cooling down. So the debug-probe flash path works at 115°C; only the application boot path hangs/bad state. From manual it states MCU can with hold upto 125°C.  Could you please help us to root cause the issue and how fix this issue. Re: MPC5746C hangs (no boot, no UART) at 115°C ambient Hello, From manual it states MCU can with hold upto 125°C. Yes, that is not an issue. Could you please help us to root cause the issue and how fix this issue. Since this is your custom board and issue disappear after cooling I suspect: 1. Clock startup issue (highest probability) At 115°C: External crystal (FXOSC) startup time increases. Oscillator gain margin decreases. Load capacitors shift value with temperature. PCB leakage increases. The debugger can still access the part because debug logic uses its own infrastructure and does not depend on the application reaching main(). FXOSC status bits CMU clock-monitor faults FIRC-only boot experiment Run entirely from FIRC and disable external crystal temporarily The fact that JTAG programming continues to work at 115°C is the strongest clue that the core infrastructure remains alive and the failure is occurring very early in the application boot path rather than in the flash array itself best regards, Peter Re: MPC5746C hangs (no boot, no UART) at 115°C ambient Thank you for the insight @petervlna. Following up on this, my colleague @mnargund and me investigated further, we were able to get the MPC5746C booting successfully at 115°C. Here is a summary of what we found. Root Cause: During pre-initialization, we configured the system to bring up FIRC, FXOSC, and PLL, and then switched the system clock from FIRC to PLL. Following this, we triggered a mode transition to DRUN mode (even though the system was already in DRUN mode by default, a transition to the same mode is required for the new configuration to take effect, as mentioned in the manual), and polled MC_ME_GS.MTRANS to wait for the transition to complete. However, even after MC_ME_GS.MTRANS cleared, the code faulted with an IVOR1 exception, maybe indicating the transition had not fully stabilized by the time execution continued. At elevated temperatures (115°C), the transition appears to take longer than at room temperature, causing the system to be in an inconsistent state when the next instructions were executed. Workaround applied: We inserted an explicit software delay after the MC_ME_GS.MTRANS poll and before proceeding with the rest of initialization. With a 500 ms delay, the boot is consistently successful at 115°C. We also tested a 100 ms delay, which also works reliably in our setup.  Is there a maximum recommended software delay that can safely be inserted at this point in initialization? Is there a recommended practice to ensure reliable clock stabilization before proceeding, across the full operating temperature range up to 125°C?
記事全体を表示
RTCの例がfrdm_mcxw72ボード上でうまく構築できません こんにちは、 RTCの例は私のワークベンチではうまく構築できません。基本的な設定情報は以下のスナップショットで確認できます 以下はビルドプロセス中のログメッセージです: 設定タスク開始... ワークスペースはd:\ABC\rtcです Zephyrのデフォルトモジュール(Zephyrベース(キャッシュ))を読み込み中。 -- アプリケーション:D:/ABC/rtc -- CMakeバージョン:3.30.0 -- Python3 を見つけました:C:/users/Xpeng/.mcuxpressotools/.mcux-venv-3.12/Scripts/python.exe(適切なバージョン「3.12.12」が見つかり、最低必要条件は「3.12」です)発見されたコンポーネント:インタプリタ -- キャッシュファイルは以下のアドレスに書き込まれます:D:/ABC/zephyr/zephyr/.cache -- Zephyrバージョン:4.4.1(D:/ABC/zephyr/zephyr) -- Found west(適切なバージョン「1.5.0」が見つかり、最低必要条件は「0.14.0」) -- ボード:frdm_mcxw72、予選:mcxw727c -- ホストツールを見つけました:zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 発見ツールチェーン:zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 発見されたdtc: C:/Users/Xpeng/.mcuxpressotools/dtc-1.6.1/tools/usr/bin/dtc.exe(適切なバージョン「1.6.1」が見つかりました)最低必要値は「1.4.6」です。 -- BOARD.dts が見つかりました:D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72.dts -- デバイスツリーオーバーレイ発見:D:/ABC/rtc/boards/frdm_mcxw72.overlay -- 生成されたzephyr.dts:D:/ABC/rtc/build/zephyr/zephyr.dts -- 生成されたピクルドedt: D:/ABC/rtc/build/zephyr/edt.pickle -- 生成devicetree_generated.h: D:/ABC/rtc/build/zephyr/include/generated/zephyr/devicetree_generated.h Parsing D:/ABC/zephyr/zephyr/Kconfig ロード済み設定 'D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72_defconfig' マージされた構成 'D:/ABC/rtc/prj.conf' 設定は「D:/ABC/rtc/build/zephyr/.config」に保存されます Kconfigヘッダーは'D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h'に保存されています。 -- Found GnuLd: C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd.exe(foundバージョン「2.43.1」) -- Cコンパイラ識別はGNU 14.3.0です -- CXXコンパイラの識別はGNU 14.3.0です -- ASMコンパイラ識別はGNUです -- 見つけたアセンブラ:C:/ユーザー/Xpeng/Zephyr-SDKs-1.0.1/gnu/Arm-Zephyr-eabi/bin/Arm-Zephyr-eabi-gcc.exe -- D:/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/ でデバイスMCXW727Cを探しています -- デバイスフォルダーを見つけました:D:/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -- 見つけたgen_kobject_list:D:/ABC/Zephyr/Zephyr/scripts/build/gen_kobject_list.py -- 設定完了(26.9秒) -- 生成完了(1.8秒) -- ビルドファイルは以下の通りに書き込まれています: D:/ABC/rtc/build 終了コード0で終了する設定 * ターミナルはタスクで再利用されます。どのキーを押しても閉じてください。 * タスクを実行中: CMake: build ワークスペースはd:\ABC\rtcです ビルドタスク開始...... C:\ユーザー\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.EXE --build D:/ABC/rtc/build --target all -- [1/156] include/genated/zephyr/version.h 生成中 -- Zephyrバージョン:4.4.1(D:/ABC/zephyr/zephyr)、ビルド:v4.4.1 [2/156] 雑多/生成/syscalls.json、雑多/生成/struct_tags.json [3/156] include/generated/device-api-sections.ld、include/generated/device-api-sections.cmake を生成中 [4/156] include/generated/zephyr/driver-validation.h 生成中 [5/156] include/generated/zephyr/kobj-types-enum.h, include/generated/zephyr/otype-to-str.hを生成中,include/generated/zephyr/otype-to-size.h [6/156] include/generated/zephyr/syscall_dispatch.c、include/generated/zephyr/syscall_exports_llext.cの生成、syscall_weakdefs_llext.c、include/genated/zephyr/syscall_list.h [7/156] ビルドCオブジェクト zephyr/lib/heap/CMakeFiles/heap_constants.dir/heap_constants.c.obj [8/156] 生成中.../../include/generated/zephyr/heap_constants.h [9/156] ビルディングCオブジェクト zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj [10/156] include/genent/zephyr/offsets.h 生成中 [11/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/isr_tables.dir/isr_tables.c.obj [12/156] Cオブジェクトのビルディング CMakeFiles/app.dir/src/main.c.obj [13/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_packaged.c.obj [14/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/libc/validate_libc.c.obj [15/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/printk.c.obj [16/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/sem.c.obj [17/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/thread_entry.c.obj [18/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/heap/heap.c.obj [19/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/clock.c.obj [20/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/dec.c.obj [21/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/hex.c.obj [22/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_complete.c.obj [23/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/set.c.obj [24/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/timeutil.c.obj [25/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/bitmask.c.obj [26/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/assert.c.obj [27/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj [28/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/last_section_id.c.obj [29/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/rb.c.obj [30/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/ring_buffer.c.obj [31/156] ASMオブジェクトのビルディング zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/mcxw72_platform_init。S.obj [32/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt.c.obj [33/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/bitarray.c.obj [34/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt_common.c.obj [35/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/arch__common.dir/init.c.obj [36/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/soc.c.obj [37/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/subsys/mem_mgmt/mem_attr.c.obj [38/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/subsys/traceing/tracing_none.c.obj [39/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj [40/156] ASMオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi_on_reset をビルディングすること。S.obj [41/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/arch__common.dir/xip.c.obj [42/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault_s.S.obj [43/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/fatal.c.obj [44/156] linker_zephyr_pre0.cmd [45/156] ビルディング Cオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi.c.obj [46/156] ビルディング ASMオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/reset.S.obj [47/156] ビルディング Cオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/tls.c.obj [48/156] ビルディング ASMオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/vector_table.S.obj [49/156] ビルディング Cオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fpu.c.obj [50/156] リンクC静的ライブラリ zephyr\arch\common\libisr_tables.a [51/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/svc.S.obj [52/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/scb.c.obj [53/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault.c.obj [54/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/prep_c.c.obj [55/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_manage.c.obj [56/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread.c.obj [57/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/swap_helper。S.obj [58/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/__aeabi_read_tp。S.obj [59/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/cpu_idle.c.obj [60/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/exc_exit.c.obj [61/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_init.c.obj [62/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread_abort.c.obj [63/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/isr_wrapper.c.obj [64/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_core_mpu.c.obj [65/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/cmse/CMakeFiles/arch__arm__core__cortex_m__cmse.dir/arm_core_cmse.c.obj [66/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu_regions.c.obj [67/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/assert.c.obj [68/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu.c.obj [69/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/cbprintf.c.obj [70/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/chk_fail.c.obj [71/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/errno_wrap.c.obj [72/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/exit.c.obj [73/156] ビルディングCオブジェクト zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/time/time.c.obj [74/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/locks.c.obj [75/156] ビルディングCオブジェクト zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/fnmatch.c.obj [76/156] ビルディングCオブジェクト zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/abort.c.obj [77/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/stdio.c.obj [78/156] ビルディングCオブジェクト zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/malloc.c.obj [79/156] ビルディングCオブジェクト zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getentropy.c.obj [80/156] ビルディングCオブジェクト zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getopt_shim.c.obj [81/156] ビルディングCオブジェクト zephyr/drivers/clock_control/CMakeFiles/drivers__clock_control.dir/clock_control_mcux_scg_k4.c.obj [82/156] ビルディングCオブジェクト zephyr/drivers/console/CMakeFiles/drivers__console.dir/uart_console.c.obj [83/156] ビルディングCオブジェクト zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/common.c.obj [84/156] Building C object zephyr/drivers/gpio/CMakeFiles/drivers__gpio.dir/gpio_mcux.c.obj [85/156] ビルディングCオブジェクト zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/pinctrl_nxp_port.c.obj [86/156] ビルディングCオブジェクト zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_utils.c.obj [87/156] ビルディングCオブジェクト zephyr/drivers/serial/CMakeFiles/drivers__serial.dir/uart_mcux_lpuart.c.obj [88/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common.c.obj [89/156] ビルディングCオブジェクト zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/sys_clock_init.c.obj [90/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common_arm.c.obj [91/156] ビルディングCオブジェクト zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/mcux_lptmr_timer.c.obj [92/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k/fsl_ccm32k.c.obj [93/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc/fsl_cmc.c.obj [94/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu/fsl_elemu.c.obj [95/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr/fsl_lptmr.c.obj [96/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat/fsl_vbat.c.obj [97/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/system_MCXW727C_cm33_core0.c.obj [98/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart/fsl_lpuart.c.obj [99/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu/fsl_wuu.c.obj [100/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj [101/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [102/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj [103/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/banner.c.obj [104/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/busy_wait.c.obj [105/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/device.c.obj [106/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/version.c.obj [107/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/errno.c.obj [108/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/fatal.c.obj [109/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj [110/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/kheap.c.obj [111/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mem_slab.c.obj [112/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/float.c.obj [113/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/idle.c.obj [114/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mailbox.c.obj [115/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mutex.c.obj [116/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/msg_q.c.obj [117/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/queue.c.obj [118/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/sem.c.obj [119/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/system_work_q.c.obj [120/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/stack.c.obj [121/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/condvar.c.obj [122/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/work.c.obj [123/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/thread.c.obj [124/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/pipe.c.obj [125/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/timeslicing.c.obj [126/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/timeout.c.obj [127/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/sched.c.obj [128/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/timer.c.obj [129/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj [130/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/dynamic_disabled.c.obj [131/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mempool.c.obj [132/156] Cの静的ライブラリ app\libapp.a のリンク [133/156] Cの静的ライブラリ zephyr\libzephyr.a のリンク [134/156] リンクC静的ライブラリ zephyr\arch\arch\common\libarch__common.a [135/156] Linking C static library zephyr\arch\arch\arm\core\libarch__arm__core.a [136/156] リンクC静的ライブラリ zephyr\arch\arch\arm\core\cortex_m\cmse\libarch ARM__core__mpu.a__arm__core__cortex_m__cmse.a [137/156] Linking C static library zephyr\arch\arch\arm\core\mpu\libarch__ [138/156] リンクC静的ライブラリ zephyr\arch\arch\arch\arm\core\cortex_m\libarch__arm__core__cortex_m.a [139/156] Cの静的ライブラリ zephyr\lib\libc\common\liblib__libc__common.a のリンク [140/156] リンクC静的ライブラリ zephyr\lib\posix\c_lib_ext\liblib__posix__c_lib_ext.a [141/156] リンクC静的ライブラリ Zephyr\ドライバ\clock_control\libdrivers__clock_control.a [142/156] リンクC静的ライブラリ zephyr\lib\libc\picolibc\liblib__libc__picolibc.a [143/156] c静的ライブラリ zephyr\drivers\console\libdrivers__console.a [144/156] Linking C static library zephyr\drivers\gpio\libdrivers__gpio.a のリンク [145/156] リンクC静的ライブラリ Zephyr\ドライバ\pinctrl\libdrivers__pinctrl.a [146/156] Linking C static library zephyr\drivers\serial\libdrivers__serial.a [147/156] リンクC静的ライブラリ Zephyr\ドライバ\rtc\libdrivers__rtc.a [148/156] Linking C static library zephyr\drivers\timer\libdrivers__timer.a [149/156] C静的ライブラリ modules\hal_nxp\libmodules__hal_nxp.a をリンクしています。 [150/156] リンクC静的ライブラリ zephyr\kernel\libkernel.a [151/156] C実行ファイルzephyr\zephyr_pre0.elfのリンク 失敗:zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map D:/ABC/rtc/build/zephyr/zephyr_pre0.map C:\Windows\system32\cmd.exe /C "cd .&& C:\Users\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -gdwarf-4 -Os zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr\zephyr_pre0.elf zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj -T zephyr/linker_zephyr_pre0.cmd -Wl,-Map,D:/ABC/rtc/build/zephyr/zephyr_pre0.map -Wl,--whole-archive app/libapp.aZephyr/libzephyr.aゼファー/アーチ/コモン/リバルク__common.a zephyr/arch/arch/arm/core/libarch__arm__core.AZephyr/arch/arch/Arm/core/cortex_m/libarch__arm__core__cortex_m.AZEPHYR/ARCH/ARCH/ARM/CORE/cortex_m/CMSE/Libarch__arm__core__cortex_m__cmse.a zephyr/arch/arch/arm/core/mpu/libarch__ARM__core__MPU.AZephyr/lib/libc/picolibc/liblib__libc__picolibc.azephyr/lib/libc/common/liblib__libc__common.aZephyr/lib/posix/c_lib_ext/liblib__posix__c_lib_ext.aZephyr/ドライバ/clock_control/libdrivers__clock_control.AZephyr/ドライバ/Console/LibDrivers__console.a zephyr/drivers/gpio/libdrivers__GPIO.azephyr/ドライバ/pinctrl/libドライバ__pinctrl.a zephyr/drivers/rtc/libdrivers__rtc.aZephyr/ドライバ/serial/libdrivers__serial.a zephyr/drivers/timer/libdrivers__timer.amodules/hal_nxp/libmodules__hal_nxp.a-Wl,--no-whole-archive zephyr/kernel/libkernel.a -LD:/ABC/rtc/build/zephyr zephyr/arch/common/libisr_tables.a-fuse-ld=bfd -mcpu=Cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=降順 -Wl,--sort-section=alignment -Wl,-u,_OffsetAbsSyms -wl,-u,_ConfigAbsSyms -nostdlib -static -znoexecstack -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -Wl,-no-pie -Wl,--undefined=_sw_isr_table -Wl,--undefined=_irq_vector_table -specs=picolibc.specs -DPICOLIBC_LONG_LONG_PRINTF_SCANF -L"C:/ユーザー/Xpeng/Zephyr-SDKs-1.0.1/gnu/Arm-zephyr-eabi/bin/../lib/gcc/Arm-zephyr-eabi/14.3.0/thumb/v8-m.main/nofp/space」-lc -lgcc && C:\Windows\system32\cmd.exe /C "cd /D:\ABC\RTC\BUILD\ZEPHYR && C:\ユーザー\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.exe -E true"" C:/ユーザー/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe:app/libapp.a(main.c.obj): 関数「k_sleep」で: D:/ABC/rtc/build/zephyr/include/generated/zephyr/syscalls/kernel.h:185:(.text.main+0x94):`__device_dts_ord_92`への未定義の参照 collect2.exe:エラー: ld が終了ステータス 1 を返しました ninja: ビルドが停止しました: サブコマンドが失敗しました。 ビルドはエラーで終了しました。 * 端末プロセスは終了コード1で終了しました。 * ターミナルはタスクによって再利用されます。閉じるには任意のキーを押してください。 問題の確認にご協力いただき、誠にありがとうございました。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、RomanVRさん。 例:Zephyr/samples/ドライバ/counter/alarm は問題なく動作しましたが、 RTCの例 はスナップショットと同じオーバーレイファイルを作成してもビルド中に問題が発生します。 以下はビルドプロセス中に発生した主要なエラーメッセージです。このメッセージは、皆様のご協力のもと問題を解決するためのヒントとなるはずです。本当にありがとうございます! [5/64] ビルドCオブジェクト zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj 失敗:zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj C:\ユーザー\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DCPU_MCXW727CMFTA_cm33_core0 -DKERNEL -DK_HEAP_MEM_POOL_SIZE=0 -DNDEBUG -DPICOLIBC_LONG_LONG_PRINTF_SCANF -D_POSIX_THREAD_SAFE_FUNCTIONS=200809L -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -ID:/ABC/rtc/build/zephyr/include/generated/zephyr -ID:/ABC/zephyr/zephyr/include -ID:/ABC/rtc/build/zephyr/include/generated -ID:/ABC/zephyr/zephyr/soc/nxp/mcx -ID:/ABC/zephyr/zephyr/lib/libc/picolibc/include -ID:/ABC/zephyr/zephyr/lib/posix/c_lib_ext/getopt -ID:/ABC/zephyr/zephyr/soc/nxp/mcx/mcxw/mcxw7xx/。-ID:/ABC/zephyr/zephyr/soc/nxp/mcx/../common -ID:/ABC/zephyr/modules/hal/cmsis_6/CMSIS/Core/Include -ID:/ABC/zephyr/zephyr/modules/cmsis_6/。-ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/port -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/rtc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/periph3 -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCX/MCXW/MCXW727C/ドライバ -isystem D:/ABC/Zephyr/zephyr/lib/libc/common/include -Wshadow -fno-strict-aliasing -Os -imacros D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=常に -mcpu=Cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/Arm-zephyr-eabi/Arm-zephyr-eabi -imacros D:/ABC/zephyr/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-セキュリティ -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=D:/ABC/rtc=CMAKE_SOURCE_DIR -fmacro-prefix-map=D:/ABC/zephyr/zephyr=ZEPHYR_BASE -fmacro-prefix-map=D:/ABC/zephyr=WEST_TOPDIR -ffunction-sections -fdata-sections -mcmse -specs=picolibc.specs -std=c17 -MD -MT zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj -MF zephyr\ドライバ\rtc\CMakeFiles\ドライバ__rtc.dir\rtc_counter.c.obj.d-o zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj -c D:/ABC/Zephyr/Zephyr/ドライバ/rtc/rtc_counter.c In file included from D:/ABC/Zephyr/zephyr/include/zephyr/toolchain.h:52, from D:/ABC/Zephyr/zephyr/include/zephyr/kernel_includes.h:23, from D:/ABC/Zephyr/zephyr/include/zephyr/kernel.h:17, from D:/ABC/Zephyr/zephyr/include/zephyr/drivers/rtc.h:26, from D:/ABC/Zephyr/zephyr/drivers/rtc/rtc_counter.c:9: D:/ABC/Zephyr/zephyr/include/zephyr/toolchain/gcc.h:87:36: error: static assertion failed: "RTC init priority must be bigger than counter" 87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG) | ^~~~~~~~~~~~~~ D:/ABC/Zephyr/zephyr/drivers/rtc/rtc_counter.c:684:1: note: in expansion of macro 'BUILD_ASSERT' 684 | BUILD_ASSERT(CONFIG_RTC_INIT_PRIORITY > CONFIG_COUNTER_INIT_PRIORITY, | ^~~~~~~~~~~~ [6/64] ビルディング C オブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [7/64] ビルディング C オブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。お元気でお過ごしでしょうか。 現在のMCXW72のRTCドライバの実装はcounter.hと共に使用することを想定していますゼファー図書館。この点を踏まえて、例えば zephyr/samples/drivers/counter/alarmを使ってRTC機能をテストすることをお勧めします。下の画像に示すように: このプロジェクトテンプレートは、RTCをアラーム機能を備えたカウンターとして構成します。テストするには、 /boardsフォルダにオーバーレイファイル[frdm_mcxw72.overlay]を作成してください。そして、以下の内容をファイルに追加してください。 / { aliases { rtc=&rtc; }; }; &rtc{ status = "okay"; counter_rtc: counter_rtc { status = "okay"; }; }; これらの変更が開発に役立つかどうか、お知らせください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。 RTCのサンプルを正しくビルドするには、 prj.confファイルに以下の設定を追加する必要があります。 CONFIG_RTC_INIT_PRIORITY=70 これがあなたにとって有効かどうか教えてください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、RomanVRさん。 prj.conf ファイルの設定を追加しました CONFIG_RTC_INIT_PRIORITY=70 それでも建築は通過できず、エラープロンプトのメッセージも同じです。建築ログは添付ファイルで確認できます。問題のポイントを見つける助けになれば幸いです。 よろしくお願いいたします! Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。 prj.confというファイル内に設定を追加していただけますか?frdm_mcxw72.confという名前で作成されたファイルに追加しても、オーバーレイファイルのようにZephyrビルドシステムによって自動的に取得されません。 これが役に立つかどうか教えてください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。サンプルが正しくビルドできたようで良かったです。 RTC機能に関しては、現在Zephyr(rtc.h)のRTCドライバーはMCXW72のRTCノード(counter_mcux_rtc.c)で使用している低レベルのドライバーと互換性がなく、W72のRTCはcounter.h経由で使用すべきですAPIが下位レベルのドライバで定義されているものと互換性があるため、ドライバを選びます。 先ほど紹介したアラームの例(Zephyr/samples/drivers/counter/alarm)は、RTCドライバの現在の全機能を示しています。 この情報で疑問が解消されたかどうか、お知らせください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、RomanVRさん。 prj.confに設定を追加したらうまくいきました。ご協力ありがとうございました! しかし、EVKにイメージをフラッシュした後も、RTC機能がまだ壊れているように見えるという問題が残っています。これは、プリントメッセージからの時刻情報がそのままになっているためです。 チェックを手伝ってもらえますか?ありがとうございます!
記事全体を表示
ISP tuning in FRDM I am currently bringing up a Bayer sensor in Verdin iMX95 FRDM kit and have got stream and about to start the ISP tuning. The tuning here is totally different and has a vast difference from iMX8M Plus. Has anyone already done tuning with Verdin iMX95 kit.
記事全体を表示
RT1176 - 通过 JTAG 编程 BT_FUSE_SEL 后出现 SPI 或非 Flash 读取问题 你好, 我们正在 RT1176 CPU 上测试签名和加密过程。 我们的基本系统配置为:UART/JTAG <-> RT1176 <-> SPI Nor Flash 我们用于测试的软件是: - RT1176 测试固件(一个简单的固件,启动后会激活一个 LED) - NXP MCUXpresso 安全配置/blhost(用于通过UART进行签名和加密) - Segger JFlash(用于通过 JTAG 访问闪存) 到目前为止,我们进行了以下测试: 1)当 CPU 解锁且签名关闭时,固件(未签名/未加密)按预期启动,我们可以通过 JTAG 毫无问题地访问闪存。 2) 当 CPU 解锁且签名处于活动状态时,固件(已签名/未加密)按预期启动,我们可以通过 JTAG 毫无问题地访问闪存。 3) 当 CPU 被锁定且签名开启时,固件(已签名/加密)将无法启动,并且通过 JTAG 对闪存的访问变得不稳定。 所以,我们遇到了某种加密问题。但在深入探讨加密问题之前,我们想了解步骤 3 中不稳定的闪存行为。 在几次测试中,很明显,一旦 BT_FUSE_SEL 熔断,闪存问题总是会发生(BT_FUSE_SEL 完好:通过 JTAG 完全访问闪存,BT_FUSE_SEL 熔断:通过 JTAG 不稳定访问闪存)。由于我们仍在测试阶段,因此尚未通过熔丝位设置禁用 JTAG。 所以问题是: 为什么 BT_FUSE_SEL 会导致我们失去对闪存的访问权限?(CPU锁定时是否有读取保护机制?)Segger JFlash 工具在 CPU 锁定的情况下是否存在问题?……) 另请参阅: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/mxrt1176-quot-half-quot-bricked-after-programming-fuses-for/mp/2044051 ->同样的问题:BT_FUSE_SEL > 无闪存访问 提前致谢。 此致, 弗洛里安 Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL 嗨@florian_arndt , 感谢您对 NXP MIMXRT 系列产品的关注! BT_FUSE_SEL 不会直接启用 SPI 或非 读取保护或禁用 JTAG。它的功能是强制 Boot ROM 使用存储在 eFuse 中的启动配置,而不是使用 BOOT_CFG 引脚。 如果 OTFAD/加密 XIP 配置也已编程到 eFuse 中,则烧录 BT_FUSE_SEL 可使该配置在每次启动时生效,并消除通过 BOOT_CFG 引脚绕过它的可能性。因此,错误的 OTFAD 上下文、密钥、地址范围或加密映像可能会导致 Boot ROM 在应用程序启动之前失败。 因此,我认为目前最可能的原因是与启动相关的 GPIO 已被旁路,但相应的 eFuse 没有正确配置。BT_FUSE_SEL 本身不会影响 JTAG 连接。我建议您进行A/B测试,以便快速找出问题所在。 此致, 加文 Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL 你好@Gavin_Jia , 谢谢你的回答! 今天我们修复了加密过程(固件中的一个漏洞)。我们的固件现在已启动,CPU 中已激活签名/加密功能。 所以大问题解决了。 剩下的问题是设置 BT_FUSE_SEL 后通过 JTAG 读取 spi-flash 的问题。 附件是我们的保险丝图。 你觉得有什么因素可能导致我们遇到的问题吗? 提前致谢。 弗洛里安
記事全体を表示
MCUXpresso IDE 在 Ubuntu Linux 上的支持到底出了什么问题? 连在 Linux 系统上使用 MCUXpresso IDE 编写一个“Hello World”程序这样最简单的事情都做不到。我有一块RT700 EVKB板,那个IDE总是崩溃死机,我已经为此苦恼了两三天了,这到底是怎么回事?它明明应该有像样的支持才对,今天能用,明天就出问题了。也没有任何指南可以解决这个问题。即使创建了一些基本项目,打开外围设备配置选项卡时,它也会神奇地无法工作,奇怪地显示处理器核心不支持此功能或类似信息。如今我们看到的都是些垃圾,从微软的Windows到这个IDE,甚至在某种程度上还有Ubuntu。要在 Windows 系统上运行这个 IDE,您希望我们做什么?看在上帝的份上,请修复这些问题吧,我甚至都无法截图,系统卡得太厉害了。 Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux EVKB 本身的 BOM 文件使用的包与 ide 项目创建中使用的包相同。 Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux 请观看这段视频,并请制作一些关于如何使用此工具的培训视频。更别提使用 VS Code 扩展了,我简直不敢想象它的技术支持会有多糟糕。 Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux 这是我重启系统并打开IDE后得到的结果。 Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux 你好@prathamvora , 根据MCUXpresso 集成开发环境 (IDE)网页显示,支持的 Ubuntu 版本为 Ubuntu 22.04 LTS 和 Ubuntu 24.04 LTS。对于Visual Studio Code 的 MCUXpresso ,支持的 Ubuntu 版本为 Ubuntu 20.04.2 LTS、Ubuntu 22.04 LTS 和 Ubuntu 24.04 LTS。 我建议使用 MCUXpresso IDE 或 MCUXpresso for Visual Studio Code 支持的 Ubuntu 版本之一。 此致, 巴勃罗
記事全体を表示
RTC example can't build successfully in frdm_mcxw72 board Hi, the RTC example can't build OK in my workbench. you can find the basic setting information in below snapshot below is the log message during the build process : Config task started... Workspace is d:\ABC\rtc Loading Zephyr default modules (Zephyr base (cached)). -- Application: D:/ABC/rtc -- CMake version: 3.30.0 -- Found Python3: C:/Users/Xpeng/.mcuxpressotools/.mcux-venv-3.12/Scripts/python.exe (found suitable version "3.12.12", minimum required is "3.12") found components: Interpreter -- Cache files will be written to: D:/ABC/zephyr/zephyr/.cache -- Zephyr version: 4.4.1 (D:/ABC/zephyr/zephyr) -- Found west (found suitable version "1.5.0", minimum required is "0.14.0") -- Board: frdm_mcxw72, qualifiers: mcxw727c -- Found host-tools: zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- Found toolchain: zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- Found Dtc: C:/Users/Xpeng/.mcuxpressotools/dtc-1.6.1/tools/usr/bin/dtc.exe (found suitable version "1.6.1", minimum required is "1.4.6") -- Found BOARD.dts: D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72.dts -- Found devicetree overlay: D:/ABC/rtc/boards/frdm_mcxw72.overlay -- Generated zephyr.dts: D:/ABC/rtc/build/zephyr/zephyr.dts -- Generated pickled edt: D:/ABC/rtc/build/zephyr/edt.pickle -- Generated devicetree_generated.h: D:/ABC/rtc/build/zephyr/include/generated/zephyr/devicetree_generated.h Parsing D:/ABC/zephyr/zephyr/Kconfig Loaded configuration 'D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72_defconfig' Merged configuration 'D:/ABC/rtc/prj.conf' Configuration saved to 'D:/ABC/rtc/build/zephyr/.config' Kconfig header saved to 'D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h' -- Found GnuLd: C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd.exe (found version "2.43.1") -- The C compiler identification is GNU 14.3.0 -- The CXX compiler identification is GNU 14.3.0 -- The ASM compiler identification is GNU -- Found assembler: C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe -- Looking for device MCXW727C in D:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/ -- Found device folder: D:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -- Found gen_kobject_list: D:/ABC/zephyr/zephyr/scripts/build/gen_kobject_list.py -- Configuring done (26.9s) -- Generating done (1.8s) -- Build files have been written to: D:/ABC/rtc/build Configure finished with return code 0 * Terminal will be reused by tasks, press any key to close it. * Executing task: CMake: build Workspace is d:\ABC\rtc build task started.... C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.EXE --build D:/ABC/rtc/build --target all -- [1/156] Generating include/generated/zephyr/version.h -- Zephyr version: 4.4.1 (D:/ABC/zephyr/zephyr), build: v4.4.1 [2/156] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json [3/156] Generating include/generated/device-api-sections.ld, include/generated/device-api-sections.cmake [4/156] Generating include/generated/zephyr/driver-validation.h [5/156] Generating include/generated/zephyr/kobj-types-enum.h, include/generated/zephyr/otype-to-str.h, include/generated/zephyr/otype-to-size.h [6/156] Generating include/generated/zephyr/syscall_dispatch.c, include/generated/zephyr/syscall_exports_llext.c, syscall_weakdefs_llext.c, include/generated/zephyr/syscall_list.h [7/156] Building C object zephyr/lib/heap/CMakeFiles/heap_constants.dir/heap_constants.c.obj [8/156] Generating ../../include/generated/zephyr/heap_constants.h [9/156] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj [10/156] Generating include/generated/zephyr/offsets.h [11/156] Building C object zephyr/arch/common/CMakeFiles/isr_tables.dir/isr_tables.c.obj [12/156] Building C object CMakeFiles/app.dir/src/main.c.obj [13/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_packaged.c.obj [14/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/libc/validate_libc.c.obj [15/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/printk.c.obj [16/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/sem.c.obj [17/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/thread_entry.c.obj [18/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/heap/heap.c.obj [19/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/clock.c.obj [20/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/dec.c.obj [21/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/hex.c.obj [22/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_complete.c.obj [23/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/set.c.obj [24/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/timeutil.c.obj [25/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/bitmask.c.obj [26/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/assert.c.obj [27/156] Building C object zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj [28/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/last_section_id.c.obj [29/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/rb.c.obj [30/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/ring_buffer.c.obj [31/156] Building ASM object zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/mcxw72_platform_init.S.obj [32/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt.c.obj [33/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/bitarray.c.obj [34/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt_common.c.obj [35/156] Building C object zephyr/arch/common/CMakeFiles/arch__common.dir/init.c.obj [36/156] Building C object zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/soc.c.obj [37/156] Building C object zephyr/CMakeFiles/zephyr.dir/subsys/mem_mgmt/mem_attr.c.obj [38/156] Building C object zephyr/CMakeFiles/zephyr.dir/subsys/tracing/tracing_none.c.obj [39/156] Building C object zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj [40/156] Building ASM object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi_on_reset.S.obj [41/156] Building C object zephyr/arch/common/CMakeFiles/arch__common.dir/xip.c.obj [42/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault_s.S.obj [43/156] Building C object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/fatal.c.obj [44/156] Generating linker_zephyr_pre0.cmd [45/156] Building C object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi.c.obj [46/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/reset.S.obj [47/156] Building C object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/tls.c.obj [48/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/vector_table.S.obj [49/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fpu.c.obj [50/156] Linking C static library zephyr\arch\common\libisr_tables.a [51/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/svc.S.obj [52/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/scb.c.obj [53/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault.c.obj [54/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/prep_c.c.obj [55/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_manage.c.obj [56/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread.c.obj [57/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/swap_helper.S.obj [58/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/__aeabi_read_tp.S.obj [59/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/cpu_idle.c.obj [60/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/exc_exit.c.obj [61/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_init.c.obj [62/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread_abort.c.obj [63/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/isr_wrapper.c.obj [64/156] Building C object zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_core_mpu.c.obj [65/156] Building C object zephyr/arch/arch/arm/core/cortex_m/cmse/CMakeFiles/arch__arm__core__cortex_m__cmse.dir/arm_core_cmse.c.obj [66/156] Building C object zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu_regions.c.obj [67/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/assert.c.obj [68/156] Building C object zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu.c.obj [69/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/cbprintf.c.obj [70/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/chk_fail.c.obj [71/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/errno_wrap.c.obj [72/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/exit.c.obj [73/156] Building C object zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/time/time.c.obj [74/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/locks.c.obj [75/156] Building C object zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/fnmatch.c.obj [76/156] Building C object zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/abort.c.obj [77/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/stdio.c.obj [78/156] Building C object zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/malloc.c.obj [79/156] Building C object zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getentropy.c.obj [80/156] Building C object zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getopt_shim.c.obj [81/156] Building C object zephyr/drivers/clock_control/CMakeFiles/drivers__clock_control.dir/clock_control_mcux_scg_k4.c.obj [82/156] Building C object zephyr/drivers/console/CMakeFiles/drivers__console.dir/uart_console.c.obj [83/156] Building C object zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/common.c.obj [84/156] Building C object zephyr/drivers/gpio/CMakeFiles/drivers__gpio.dir/gpio_mcux.c.obj [85/156] Building C object zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/pinctrl_nxp_port.c.obj [86/156] Building C object zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_utils.c.obj [87/156] Building C object zephyr/drivers/serial/CMakeFiles/drivers__serial.dir/uart_mcux_lpuart.c.obj [88/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common.c.obj [89/156] Building C object zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/sys_clock_init.c.obj [90/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common_arm.c.obj [91/156] Building C object zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/mcux_lptmr_timer.c.obj [92/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k/fsl_ccm32k.c.obj [93/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc/fsl_cmc.c.obj [94/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu/fsl_elemu.c.obj [95/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr/fsl_lptmr.c.obj [96/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat/fsl_vbat.c.obj [97/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/system_MCXW727C_cm33_core0.c.obj [98/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart/fsl_lpuart.c.obj [99/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu/fsl_wuu.c.obj [100/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj [101/156] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [102/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj [103/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/banner.c.obj [104/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/busy_wait.c.obj [105/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/device.c.obj [106/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/version.c.obj [107/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/errno.c.obj [108/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/fatal.c.obj [109/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj [110/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/kheap.c.obj [111/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/mem_slab.c.obj [112/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/float.c.obj [113/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/idle.c.obj [114/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/mailbox.c.obj [115/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/mutex.c.obj [116/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/msg_q.c.obj [117/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/queue.c.obj [118/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/sem.c.obj [119/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/system_work_q.c.obj [120/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/stack.c.obj [121/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/condvar.c.obj [122/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/work.c.obj [123/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/thread.c.obj [124/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/pipe.c.obj [125/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/timeslicing.c.obj [126/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/timeout.c.obj [127/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/sched.c.obj [128/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/timer.c.obj [129/156] Building C object zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj [130/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/dynamic_disabled.c.obj [131/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/mempool.c.obj [132/156] Linking C static library app\libapp.a [133/156] Linking C static library zephyr\libzephyr.a [134/156] Linking C static library zephyr\arch\common\libarch__common.a [135/156] Linking C static library zephyr\arch\arch\arm\core\libarch__arm__core.a [136/156] Linking C static library zephyr\arch\arch\arm\core\cortex_m\cmse\libarch__arm__core__cortex_m__cmse.a [137/156] Linking C static library zephyr\arch\arch\arm\core\mpu\libarch__arm__core__mpu.a [138/156] Linking C static library zephyr\arch\arch\arm\core\cortex_m\libarch__arm__core__cortex_m.a [139/156] Linking C static library zephyr\lib\libc\common\liblib__libc__common.a [140/156] Linking C static library zephyr\lib\posix\c_lib_ext\liblib__posix__c_lib_ext.a [141/156] Linking C static library zephyr\drivers\clock_control\libdrivers__clock_control.a [142/156] Linking C static library zephyr\lib\libc\picolibc\liblib__libc__picolibc.a [143/156] Linking C static library zephyr\drivers\console\libdrivers__console.a [144/156] Linking C static library zephyr\drivers\gpio\libdrivers__gpio.a [145/156] Linking C static library zephyr\drivers\pinctrl\libdrivers__pinctrl.a [146/156] Linking C static library zephyr\drivers\serial\libdrivers__serial.a [147/156] Linking C static library zephyr\drivers\rtc\libdrivers__rtc.a [148/156] Linking C static library zephyr\drivers\timer\libdrivers__timer.a [149/156] Linking C static library modules\hal_nxp\libmodules__hal_nxp.a [150/156] Linking C static library zephyr\kernel\libkernel.a [151/156] Linking C executable zephyr\zephyr_pre0.elf FAILED: zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map D:/ABC/rtc/build/zephyr/zephyr_pre0.map C:\Windows\system32\cmd.exe /C "cd . && C:\Users\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -gdwarf-4 -Os zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr\zephyr_pre0.elf zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj -T zephyr/linker_zephyr_pre0.cmd -Wl,-Map,D:/ABC/rtc/build/zephyr/zephyr_pre0.map -Wl,--whole-archive app/libapp.a zephyr/libzephyr.a zephyr/arch/common/libarch__common.a zephyr/arch/arch/arm/core/libarch__arm__core.a zephyr/arch/arch/arm/core/cortex_m/libarch__arm__core__cortex_m.a zephyr/arch/arch/arm/core/cortex_m/cmse/libarch__arm__core__cortex_m__cmse.a zephyr/arch/arch/arm/core/mpu/libarch__arm__core__mpu.a zephyr/lib/libc/picolibc/liblib__libc__picolibc.a zephyr/lib/libc/common/liblib__libc__common.a zephyr/lib/posix/c_lib_ext/liblib__posix__c_lib_ext.a zephyr/drivers/clock_control/libdrivers__clock_control.a zephyr/drivers/console/libdrivers__console.a zephyr/drivers/gpio/libdrivers__gpio.a zephyr/drivers/pinctrl/libdrivers__pinctrl.a zephyr/drivers/rtc/libdrivers__rtc.a zephyr/drivers/serial/libdrivers__serial.a zephyr/drivers/timer/libdrivers__timer.a modules/hal_nxp/libmodules__hal_nxp.a -Wl,--no-whole-archive zephyr/kernel/libkernel.a -LD:/ABC/rtc/build/zephyr zephyr/arch/common/libisr_tables.a -fuse-ld=bfd -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=descending -Wl,--sort-section=alignment -Wl,-u,_OffsetAbsSyms -Wl,-u,_ConfigAbsSyms -nostdlib -static -znoexecstack -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -Wl,-no-pie -Wl,--undefined=_sw_isr_table -Wl,--undefined=_irq_vector_table -specs=picolibc.specs -DPICOLIBC_LONG_LONG_PRINTF_SCANF -L"C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/thumb/v8-m.main/nofp/space" -lc -lgcc && C:\Windows\system32\cmd.exe /C "cd /D D:\ABC\rtc\build\zephyr && C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.exe -E true"" C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: app/libapp.a(main.c.obj): in function `k_sleep': D:/ABC/rtc/build/zephyr/include/generated/zephyr/syscalls/kernel.h:185:(.text.main+0x94): undefined reference to `__device_dts_ord_92' collect2.exe: error: ld returned 1 exit status ninja: build stopped: subcommand failed. build finished with error(s). * The terminal process terminated with exit code: 1. * Terminal will be reused by tasks, press any key to close it. many thanks for your help to check the issue. Re: RTC example can't build successfully in frdm_mcxw72 board Hi RomanVR, The example: zephyr/samples/drivers/counter/alarm worked well,  but the RTC example still have problem during build even i created the overlay file the same as the snapshot. below is  the key error message during the build process, it should be the hint  to solve the issue under your help. many thanks! [5/64] Building C object zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj FAILED: zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj C:\Users\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DCPU_MCXW727CMFTA_cm33_core0 -DKERNEL -DK_HEAP_MEM_POOL_SIZE=0 -DNDEBUG -DPICOLIBC_LONG_LONG_PRINTF_SCANF -D_POSIX_THREAD_SAFE_FUNCTIONS=200809L -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -ID:/ABC/rtc/build/zephyr/include/generated/zephyr -ID:/ABC/zephyr/zephyr/include -ID:/ABC/rtc/build/zephyr/include/generated -ID:/ABC/zephyr/zephyr/soc/nxp/mcx -ID:/ABC/zephyr/zephyr/lib/libc/picolibc/include -ID:/ABC/zephyr/zephyr/lib/posix/c_lib_ext/getopt -ID:/ABC/zephyr/zephyr/soc/nxp/mcx/mcxw/mcxw7xx/. -ID:/ABC/zephyr/zephyr/soc/nxp/mcx/../common -ID:/ABC/zephyr/modules/hal/cmsis_6/CMSIS/Core/Include -ID:/ABC/zephyr/zephyr/modules/cmsis_6/. -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/port -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/rtc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/periph3 -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers -isystem D:/ABC/zephyr/zephyr/lib/libc/common/include -Wshadow -fno-strict-aliasing -Os -imacros D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi -imacros D:/ABC/zephyr/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=D:/ABC/rtc=CMAKE_SOURCE_DIR -fmacro-prefix-map=D:/ABC/zephyr/zephyr=ZEPHYR_BASE -fmacro-prefix-map=D:/ABC/zephyr=WEST_TOPDIR -ffunction-sections -fdata-sections -mcmse -specs=picolibc.specs -std=c17 -MD -MT zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -MF zephyr\drivers\rtc\CMakeFiles\drivers__rtc.dir\rtc_counter.c.obj.d -o zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -c D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c In file included from D:/ABC/zephyr/zephyr/include/zephyr/toolchain.h:52, from D:/ABC/zephyr/zephyr/include/zephyr/kernel_includes.h:23, from D:/ABC/zephyr/zephyr/include/zephyr/kernel.h:17, from D:/ABC/zephyr/zephyr/include/zephyr/drivers/rtc.h:26, from D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c:9: D:/ABC/zephyr/zephyr/include/zephyr/toolchain/gcc.h:87:36: error: static assertion failed: "RTC init priority must be bigger than counter" 87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG) | ^~~~~~~~~~~~~~ D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c:684:1: note: in expansion of macro 'BUILD_ASSERT' 684 | BUILD_ASSERT(CONFIG_RTC_INIT_PRIORITY > CONFIG_COUNTER_INIT_PRIORITY, | ^~~~~~~~~~~~ [6/64] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [7/64] Building C object modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj Re: RTC example can't build successfully in frdm_mcxw72 board Hello @anliu114036, hope you are doing well. The current implementation of the RTC driver of MCXW72 is meant to be used with the counter.h Zephyr library. Considering this, I'd suggest testing RTC functionality with the example: zephyr/samples/drivers/counter/alarm. As shown in the image below: This project template will configure the RTC as a counter with an alarm functionality. To test it, please create in the /boards folder an overlay file [frdm_mcxw72.overlay] and add the following contents to the file: / { aliases { rtc=&rtc; }; }; &rtc{ status = "okay"; counter_rtc: counter_rtc { status = "okay"; }; }; Please let me know if these modifications help on your development. Re: RTC example can't build successfully in frdm_mcxw72 board Hello @anliu114036, For the RTC example to build properly you have to add the following setting to your prj.conf file: CONFIG_RTC_INIT_PRIORITY=70 Please let me know if this works for you. Re: RTC example can't build successfully in frdm_mcxw72 board Hi RomanVR, i did add the prj.conf file with the setting  CONFIG_RTC_INIT_PRIORITY=70 but it still can't pass the building, and the error prompt message is the same, you can find the whole build log in the attachment. hope it can help to find the issue point. Best regards! Re: RTC example can't build successfully in frdm_mcxw72 board Hi @anliu114036, Would you please add the setting inside the file named prj.conf? As adding it in the created file named as frdm_mcxw72.conf will not be fetched automatically by the Zephyr build system like it does for an overlay file. Please let me know if this helps. Re: RTC example can't build successfully in frdm_mcxw72 board Hi RomanVR, it worked after add the setting in the prj.conf,  thanks for your help! but there is still a problem that after i flashed the image into the evk, the RTC function looks still broken, because the time information is keep the same from the print message can you help check it, many thanks! Re: RTC example can't build successfully in frdm_mcxw72 board Hi @anliu114036, glad to know you got the example built properly. Regarding the RTC functionality, currently, the RTC driver from Zephyr (rtc.h) is not compatible with our lower-level driver used for the MCXW72 RTC node (counter_mcux_rtc.c), the usage of the W72's RTC should be through the counter.h driver as the APIs are compatible with the defined in the lower-level driver. The alarm example I shared before (zephyr/samples/drivers/counter/alarm) demonstrates the full current functionality of our RTC driver. Please let me know if this information clears out your doubts.
記事全体を表示
MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. I am working with the FRDM MIMXRT1186 EVK board ,SDK V26.03. I flashed the LPIT ADC demo project to learn the peripheral triggered ADC conversions. However, I changed the LPIT trigger frequency—specifically by modifying the macro definition LPIT_PERIOD in the app.h to 50, which yields a 20 kHz trigger rate—I met a problem: the first LPIT trigger fails to enter ADC interrupt. To find whether the root cause lies with the LPIT or the ADC peripheral, I performed two tests: Swapped the initialization sequence of the ADC and LPIT modules (initializing the ADC first, followed by the LPIT); Added a GPIO toggle operation inside the ADC1_IRQHandler function, and routed the LPIT trigger signal to an external pin via XBAR (kXBAR1_OutputIomuxXbarInout19). then captured waveforms on pins. The oscilloscope measurements confirmed that the LPIT trigger signal is being generated correctly, yet the ADC does not respond by entering its interrupt service routine. I cannot figure out why raising the trigger frequency introduces this problem. Could anyone provide some troubleshooting insight? Many thanks in advance. The test code is attached for reference. Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. Hi @ChandlerY, Thanks for sharing the code. I am currently performing some tests with it and will get back to you with my findings. Best Regards, Pablo Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. Hi @ChandlerY, The extra delay seen only on the first interrupt is caused by the CM33 vector table and ISR code being located in non-TCM memory (XSPI flash / OCRAM accessed via cache). Could you help me test whether the behavior continues after placing all CM33 code (vector table and ISRs) into TCM? Best Regards, Pablo Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. Hi,Pablo,     Thanks for your reply, I had tested, it works when cm33 code run in TCM, the first LPIT trigger and enter ADC interrupt. But how to solve this problem when cm33 code run in flash, could you please provide some workaround? Many thanks to you.  Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. Hi @ChandlerY, Since this behavior is not related to the peripherals, but rather to where the code is being located, one option would be to run the application in non-XIP mode, meaning that the image is stored in Flash while the code executes from RAM. You can find the steps to configure this through Secure Provisioning Tool in the following link: Processor-specific workflows — Secure Provisioning Tool 26.06 Best Regards, Pablo
記事全体を表示