S32K358 高速スタンバイ こんにちは、 S32K358で高速スタンバイ機能をテストしたいです。S32DSでIPレイヤーのデモを作成しました。このプログラムは起動後5秒で高速スタンバイ状態に入り、3秒後にRTC-APIによって起動されます。これは問題なく動作します。 そこで、このプロジェクトを参照して、MCALレイヤーのデモを作成するためにEBプロジェクトを設定しましたが、失敗しました。高速スタンバイ状態になってから3秒後、電流が増加した。これはデバイスが起動したことを示唆しているが、メイン機能には移行しなかった。PE Microで接続した後、以下のエラーメッセージが表示されます。 割り込みコマンドを受信しました。執行を停止します。 UsageFault: 無効な EPSR.T または EPSR.IT フィールドで実行された命令。 バスフォールト:不正確な(非同期)データアクセスエラーが発生しました。 ハードフォールト：障害がハードフォールトにエスカレートしました。 ウェイクアップ後のベクトルテーブルを以下に示します。 1.png PCレジスタは0x0です。スタックの内容を確認すると、FastWkup_EntryAddressが入力されており、ハードフォールトはReset_Handlerにジャンプした後に発生します。 2.png 3.png 4.png FastWkup_EntryAddress に while(1) ループを追加しても、ハードフォルトは依然として発生します。 5.png スタンバイモードに入ると、単語が出てきます。 このプロジェクトでは、PMIC_PGOOD_HNDSHK_BYPが有効になっています。この基板には外部水晶発振器が搭載されていないため、コアクロックとしてFIRCが使用されています。 S32K358 RTD6.0.0 S32DS3.6.3 EB29.0 BR、 ジェイソン Re: S32K358 FAST STANDBY こんにちは、@Jason07 さん。 高速スタンバイ起動時、sBAFはVTORをカスタムベクターテーブルアドレスに設定します。 しかし、あなたのベクターテーブルには3つのエントリしか定義されていません。 初期SP、 リセットハンドラ (FastWkup_EntryAddress)、 NMIハンドラー。 つまり、ハードフォールトベクトルが抜けているのです。 何らかの故障が発生すると、CPUは定義されていないハードフォールハンドラーアドレスを取り出し、これがPC値の原因となる可能性があります。 この問題をさらにデバッグするには、ベクターテーブルに適切なハードフォルトハンドラを追加してください。それらが設定されると、ハンドラーが0x0にクラッシュする代わりに呼び出され、スタックされたPC、LR、そして元の故障の構成可能な故障状態レジスタ(CFSR/BFAR)にアクセスできます。 ありがとうございました。 BR、ダニエル

正在寻找适用于 FRDM-IMX8MPLUS 板的 Robotics Edge Image 1.0.0 大家好， 我正在寻找适用于 FRDM-IMX8MPLUS 板（不是 IMX8MP-EVK）的 Robotics Edge Image 1.0.0 的发布包。 可以找到适用于 IMX8MP-EVK 或 IMX95EVK 的预编译镜像，但没有找到适用于 FRDM-IMX8MPLUS 的镜像。该开发板受支持（ https://mcuxpresso.nxp.com/RoboticsEdgePlatform/latest/html/gsd/prebuilt-images.html ）。 从源代码（Yocto）构建它简直是噩梦，因为它需要大约 1 TB 的空间，而且在此过程中会出现很多错误。 希望能得到满意的答复。 顺祝商祺！ Re: Looking for robotics Edge Image 1.0.0 for FRDM-IMX8MPLUS board 好的，我的错，FRDM-IMX8MPLUS 文件打包在 IMX8M-EVK 压缩包里。 同一个名字，却涉及两个董事会。

TapLinxを使っている人はいますか？ 誰かNXPのTapLinx SDKを使ってMIFAREカードと連携していますか? 最小限のコンソールアプリの例に興味があります。サンプルアプリは、多数の機能を備えたGUIアプリなので、動作させるのに少し手間がかかります。 カードへのデータの読み書き、認証などを行うだけの、最小限の機能しか持たないコンソールアプリを探しています。 Kotlinの例であればなお良いですが、Javaの例でも構いません。 はじめに Re: Anyone using TapLinx? こんにちは、@reid88さん TapLinx SDKはMIFARE DESFire、Plus、Classic、Ultralight、NTAGなどに対応しています。デザインリソースは以下から確認できます: MIFARE、NTAG、ICODE、UCODE用のTapLinx SDK |NXPセミコンダクターズ

Looking for robotics Edge Image 1.0.0 for FRDM-IMX8MPLUS board Hi everybody, I'm looking for a release package for a FRDM-IMX8MPLUS board (not IMX8MP-EVK) of Robotics Edge Image 1.0.0. It's possible to find a pre-built image for IMX8MP-EVK or IMX95EVK, but nothing was found for FRDM-IMX8MPLUS. The board is supported (https://mcuxpresso.nxp.com/RoboticsEdgePlatform/latest/html/gsd/prebuilt-images.html) Building it from source (Yocto) is a pure pain, as it takes around 1 TB of space and there are plenty of errors during the process. Hope to have a successful answer. Best regards, Re: Looking for robotics Edge Image 1.0.0 for FRDM-IMX8MPLUS board Ok, my bad, FRDM-IMX8MPLUS files are packaged in the IMX8M-EVK zip file.  A single name, but two boards addressed.

S32K358 FAST STANDBY Hello, I would like to test Fast Standby on the S32K358. I created an IP-layer demo in S32DS where the program enters Fast Standby 5 seconds after startup and is woken up by RTC-API after 3 seconds. This works without any issues. Then I referred to this project and configured an EB project to create an MCAL-layer demo, but it failed. After 3 seconds in Fast Standby, the current increased, which suggests the device woke up, but it never entered the main function. After attaching with PE Micro, the error messages are as follows: Interrupt command received. Halting execution. UsageFault: An instruction executed with an invalid EPSR.T or EPSR.IT field. BusFault: An imprecise (asynchronous) data access error has occurred. HardFault: A fault has been escalated to a hard fault. The vector table after wake-up is shown below: 1.png The PC register is 0x0. Checking the stack contents, I can see that FastWkup_EntryAddress was entered, and the HardFault occurs after jumping to the Reset_Handler. 2.png 3.png 4.png If I add a while(1) loop in FastWkup_EntryAddress, the HardFault still occurs. 5.png If I enter standby mode, it word. In the project, PMIC_PGOOD_HNDSHK_BYP is enabled. Since the board does not have an external crystal oscillator, FIRC is used as the core clock. S32K358 RTD6.0.0 S32DS3.6.3 EB29.0 BR, Jason Re: S32K358 FAST STANDBY Hello @Jason07, On Fast Standby wakeup, the sBAF sets VTOR to your custom vector table address. However, your vector table only defines three entries: Initial SP, Reset Handler (FastWkup_EntryAddress), NMI Handler. So the HardFault vector is missing. When any fault occurs, the CPU fetches the not defined HardFault handler address, which could explain the observed PC value. To debug this further, please add a proper HardFault handler to the vector table. Once those are in place, the handler will be invoked instead of crashing to 0x0, giving you access to the stacked PC, LR, and the Configurable Fault Status Register (CFSR/BFAR) of the original fault. Thank you, BR, Daniel

Zone Node Software & Hardware Environment 1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion 2 Introduction This article is part of the Zone Node series and describes the software and hardware environment used throughout the project. The purpose of this article is to describe the software and hardware setup required to follow the series and reproduce the results. Before examining communication routing, control logic, or integration challenges, it is important to understand the tools and platforms that support the development and execution of the zonal node application. This article introduces the software components used to develop, configure, and deploy the application, as well as the hardware platforms used to demonstrate the zonal controller functionality. This information provides the foundation required for the remaining articles in the series. Overview of the development flow The zonal node application presented in this series is developed using a combination of Model-Based Design tools, NXP software components, and automotive-grade hardware platforms. At a high level: Application modeling starts in MATLAB® and Simulink®, where communication routing and control logic are implemented graphically. Code generation converts the model into production-ready embedded software using the code-generation tools provided by MathWorks and NXP. Deployment compiles the generated software and loads it onto the target hardware, where it is used to demonstrate communication between multiple vehicle networks. This environment was selected to support rapid development, easier validation, and improved traceability between model design and generated software. By using a Model-Based Design approach, algorithm development, communication integration, and application verification can be performed within a common framework. The software and hardware presented here are used consistently throughout the series and will be referenced when discussing communication routing, system behavior, and integration scenarios. ㅤ Figure 1. Development flow diagram The workflow begins with application development in Simulink. Communication routing logic, control functions, and software configuration are implemented within the model. The NXP Model-Based Design Toolbox (MBDT) provides hardware-specific blocks that enable integration with S32K3 peripherals and communication interfaces. Following code generation, the application is compiled and deployed to the target hardware, where communication routing functionality can be validated. This article is intended for: Engineers interested in reproducing the zonal node demonstration Simulink users developing automotive communication applications Developers evaluating Model-Based Design workflows Engineers working with NXP automotive microcontrollers and evaluation boards By understanding the software and hardware environment early in the series, readers will be better prepared to follow the implementation details presented in subsequent articles. 3 Required Software The following software components are used throughout the project: MATLAB® and Simulink® – model development and simulation Embedded Coder® (required MATLAB toolbox) – automatic code generation from the model Simulink models – the zonal node routing application model referenced throughout the series NXP Model-Based Design Toolbox (MBDT) – S32K3 support and peripheral configuration NXP additional tools – FreeMASTER and S32 Design Studio for build, deployment, and debugging CAN analysis software – monitoring and validating CAN communication LIN analysis software – monitoring and validating LIN communication 3.1 MATLAB® and Simulink® MATLAB® and Simulink® form the foundation of the development environment. They are used to create the zonal node application, implement communication routing logic, configure software behavior, and perform model-based verification activities. The application described throughout this series is developed as a Simulink model and later translated into embedded software using automatic code-generation tools (Embedded Coder®). 3.2 NXP Model-Based Design Toolbox (MBDT) The NXP Model-Based Design Toolbox (MBDT) extends Simulink with hardware-specific support for NXP automotive microcontrollers. For this project, MBDT for S32K3 version 1.8.0 is used. The toolbox provides blocks and configuration interfaces for communication peripherals, timers, digital I/O resources, and other hardware modules available on the target device. It also integrates with the code-generation workflow, allowing Simulink models to be converted into software that can run directly on the S32K3 microcontroller. Note: Installation and configuration instructions are provided in the dedicated article series (How to install .MLTBX). Readers who have not yet installed the toolbox should complete that step before continuing with this series. 3.3 CAN Analysis Software CAN analysis tools are used during development and validation to observe CAN and CAN FD traffic exchanged between the zonal node and other network participants. Typical use cases include: Monitoring transmitted and received CAN frames Verifying CAN-to-CAN routing behavior Measuring message timing and bus utilization Troubleshooting communication issues Examples of commonly used software include PCAN-View, CANalyzer, and CANoe. 3.4 LIN Analysis Software LIN analysis tools are used to monitor communication between the zonal node and LIN-connected edge devices. Typical use cases include: Verifying LIN schedule execution Monitoring frame transmission and reception Validating signal timing and integrity Testing LIN-to-CAN routing scenarios Examples of commonly used software include PLIN-View and LINalyzer. 4 Required Hardware The following hardware components are used throughout the project: S32K344 automotive microcontroller – used to execute the zonal node application S32K344-WB Evaluation Board – used as the development and validation platform CAN analysis hardware – used to monitor and verify CAN/CAN FD communication LIN analysis hardware – used to monitor and verify LIN communication 4.1 S32K3 Microcontroller The S32K3 family provides: Arm® Cortex®-M7 processing cores CAN FD communication interfaces LIN communication support Safety-oriented automotive features Low-power operating modes Rich peripheral connectivity These capabilities make the device suitable for implementing communication aggregation and routing functions within the scope of this project. 4.2 Evaluation Hardware The zonal node application runs on the S32K344-WB Evaluation Board, a development platform based on the NXP S32K344 microcontroller. The board provides access to the communication interfaces and processing capabilities of the target device while offering an integrated platform for software development, debugging, and validation activities. Within the scope of this project, the board is used to execute the routing application and exchange messages with nodes connected through CAN and LIN networks. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating zonal communication architectures and routing scenarios. ㅤ Figure 2. S32K344-WB evaluation board 4.3 Communication Networks The examples presented throughout this series use CAN and LIN networks to demonstrate message forwarding, routing, and protocol translation scenarios. These networks provide the communication backbone between the zonal node, central controller, and edge nodes, and are referenced throughout the upcoming routing and integration articles. 4.4 Network Analysis Hardware Additional hardware tools are used during development and validation to observe network traffic and verify communication behavior. CAN analysis interfaces can be connected to the network to monitor transmitted and received CAN/CAN FD frames, validate routing functionality, and troubleshoot communication issues. LIN analysis interfaces can be used to monitor LIN schedules, frame exchanges, and LIN-to-CAN routing scenarios. These tools provide visibility into network activity and support verification of the communication flows presented in later articles of this series. 5 References Model-Based Design Toolbox (MBDT) Embedded Coder® Documentation MATLAB® and Simulink® Documentation S32K3 Microcontrollers S32K344-WB Evaluation Board 6 Conclusion This article introduced the software and hardware environment used throughout the zonal node project. It presented the development tools, code-generation workflow, and target hardware that support the implementation of the communication routing application. The next article will build on this foundation by examining the internal logic control mechanisms used within the zonal node and how they contribute to communication handling across multiple networks.

From Simulation to Vehicle Control: Real-Time Decision Making on the S32N55 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction Modern vehicle development increasingly relies on digital validation before physical prototypes are available. Simulation enables rapid testing and iteration, but engineering teams also need to demonstrate how virtual behavior maps to real hardware. In the Hello World demonstrator, this connection is handled by the Main Node application running on the NXP S32N55. The Main Node acts as the central execution point of the demonstrator, transforming vehicle information generated inside MATLAB ® and Simulink ® into decisions and actions that can be observed on physical hardware. By combining Model-Based Design, CAN communication, and centralized decision making, the system creates a bidirectional link between the virtual vehicle and the physical demonstrator. This article explains how the Main Node converts simulation inputs into coordinated vehicle behavior while maintaining synchronization between the digital and physical domains. 3 Overview As introduced in the previous article, the S32N55 functions as the communication hub of the demonstrator, aggregating information from distributed modules and distributing commands throughout the system. Beyond communication, however, the Main Node also serves as the decision-making layer responsible for interpreting vehicle state and translating it into actionable control signals. Developed using the NXP Model-Based Design Toolbox (MBDT), the application is entirely modeled in Simulink and deployed directly onto the target hardware. This workflow enables engineers to focus on vehicle functionality and system behavior while leveraging automated code generation and integrated CAN communication support. The Main Node receives data from simulated and physical sources, maintains a coherent vehicle-state view, runs vehicle-level control logic, and sends commands to the actuator nodes that make up the demonstrator. This centralized architecture reflects the direction of modern software-defined vehicle platforms, where coordination moves from isolated ECUs toward higher-level compute nodes. Figure 1. Main Node overview showing how the S32N55 coordinates simulation inputs, vehicle-state processing, and commands to distributed hardware modules. 4 Context The Main Node is positioned between the virtual vehicle environment and the physical hardware modules that form the demonstrator. Driver inputs generated through the Driver-in-the-Loop simulation environment are transmitted over CAN and received by the S32N55, where they are processed alongside feedback arriving from multiple distributed nodes. Commands such as vehicle speed, steering angle, gear selection, braking requests, and lighting controls enter the Main Node from the simulation environment. These inputs are then evaluated by the application and translated into CAN messages that drive the corresponding hardware modules. This architecture enables the physical demonstrator to mirror the behavior of the virtual vehicle. When the simulated vehicle accelerates, the speed command is interpreted by the Main Node and forwarded to the motor control subsystem. Steering-wheel movements are translated into steering-angle commands for the steering module, while lighting commands activate headlights, fog lights, hazard lights, and turn indicators on the physical hardware. Figure 2. System context illustrating the Main Node as the bridge between the virtual vehicle environment and the physical demonstrator hardware. The Main Node can be driven either by the Driver-in-the-Loop simulation or by the External Control model. In both cases, the command source publishes the same DBC-defined CAN frames, so the S32N55 receives speed, steering, brake, gear, and lighting commands through the same interface. This allows the same deployed application to be exercised from two sources without changing the Main Node software. This approach is especially useful during integration, demonstrations, and incremental validation. Engineers can exercise the Main Node and the downstream actuator modules even when the complete virtual environment is not active, while still preserving the exact communication contract used by the full system. As a result, the application can be validated against two different input sources without changing the deployed software on the board. Rather than acting as a simple gateway, the Main Node continuously evaluates received information and executes vehicle-level decisions. One example is the processing of motor feedback data, where information from multiple motors is combined to derive a representative vehicle speed used throughout the system. Centralizing this functionality simplifies system coordination while ensuring consistency across all connected modules. Gear selection is handled as part of this centralized decision layer. The incoming gear command is interpreted as a driving mode that affects how the requested speed is applied: Park and Neutral block motion commands, Reverse changes the sign of the velocity reference, and Drive or Sport propagate the requested speed as a forward-driving command. This keeps speed-control behavior aligned with the selected driving mode while preserving the same driver-input signal set. The target-speed command is computed from the requested speed reference, the selected gear mode, the reported vehicle speed, and the effective brake command. Motor feedback is fused into a representative reported speed, which provides the actual-speed reference used during braking decisions. Under normal driving conditions, the requested target speed passes through the gearbox-aware logic and is converted into the motor-speed command sent over CAN. When braking is active, the Main Node bases the outgoing command on the detected speed and brake value, reducing the command until the vehicle is considered stopped. The Main Node also hosts the demonstrator's automated emergency braking functionality. Parking sensor nodes continuously report obstacle distances over CAN. The application evaluates these measurements and determines whether an object has entered a predefined safety zone. When this condition is met, the braking command issued by the driver can be overridden and replaced with an emergency braking request generated by the system. Figure 3. Parking sensors in action detecting nearby obstacles and providing distance feedback used by the Main Node to support emergency braking decisions. An important aspect of this implementation is that the braking behavior is reflected across both domains. The physical hardware responds to the braking request, while the simulation environment can receive corresponding vehicle-state updates through the same CAN-based loop. This closed-loop behavior demonstrates bidirectional interaction between simulation and embedded execution, allowing safety-related functionality to be validated in a realistic environment before a full vehicle prototype is available. Figure 4. Closed-loop emergency braking flow showing how parking sensor feedback can trigger an automated braking request across both the physical and simulated domains. CAN communication is the key enabler of this architecture. Every subsystem communicates through DBC-defined interfaces, allowing functionality to be distributed across multiple independent nodes while preserving a consistent and scalable communication framework. The shared DBC approach ensures that signal definitions remain synchronized across all parts of the demonstrator. To support this workflow, MathWorks Vehicle Network Toolbox ™ provides direct integration between MATLAB ® , Simulink ® , and CAN communication interfaces. DBC files can be used directly throughout the development process, simplifying signal management and ensuring consistency across the virtual vehicle, the Main Node, and all peripheral modules. As the demonstrator grows to include additional functionality, the same network definition can be reused across all participating systems, reducing integration effort and helping accelerate development. Note: The combination of NXP Model-Based Design Toolbox and MathWorks Vehicle Network Toolbox creates a workflow in which vehicle behavior, communication interfaces, and deployed software remain aligned from modeling through system integration. Figure 5. CAN and DBC workflow showing how shared signal definitions keep the virtual vehicle, Main Node, and distributed hardware modules synchronized. 5 References NXP Model-Based Design Toolbox (MBDT) NXP S32N Vehicle Super-Integration Processors Vehicle Network Toolbox ™ NXP Model-Based Design Toolbox Community 6 Conclusion The Main Node demonstrates how a centralized compute platform can act as more than a communication gateway. Running on the NXP S32N55, it combines signal aggregation, decision making, and command distribution into a single application that coordinates the entire demonstrator. By transforming simulation-generated inputs into physical vehicle behavior and feeding real-world information back into the virtual environment, the Main Node creates a practical closed-loop development platform. Together, NXP Model-Based Design Toolbox, MathWorks Vehicle Network Toolbox, and CAN-based communication enable rapid iteration, simplified integration, and efficient validation of vehicle functionality across simulated and physical domains.

Zone Node Logic Control (Main model overview) 1 Table of Contents • Introduction • Black-Box Overview • Simulink Model Overview • Inputs • Algorithm • Outputs • References • Conclusion 2 Introduction This article explains the internal behavior of the Zone Node by opening the component "black box" and describing how information flows through the application. The objective is to provide a functional understanding of the model, starting from the incoming inputs, continuing through the internal processing logic, and concluding with the generated outputs. The Zone Node acts as an intermediary between the Central Controller and the Edge Nodes located within a vehicle zone. While previous articles introduced the component and the development environment, this article focuses on the application's behavior and the responsibilities performed by the embedded software. This article focuses on the functional behavior of the Zone Node and explains how information flows through the component. Detailed aspects such as CAN routing implementation, LIN scheduling mechanisms, peripheral configuration, and communication stack integration will be covered in dedicated articles later in the series. 3 Black-Box Overview From a system perspective, the Zone Node behaves as a communication gateway and data aggregation component. It receives information from different communication networks, processes that information according to predefined routing rules, and forwards the resulting data to other parts of the system. At a high level, the component can be represented as: ㅤ Figure 1. Black-Box Overview The Zone Node does not implement vehicle-level control strategies. Functions such as braking decisions, steering calculations, or vehicle state management remain the responsibility of higher-level controllers. Instead, the Zone Node focuses on: Receiving messages from the Central Controller Receiving messages from Edge Nodes Acquiring data from local LIN-connected devices Routing information between networks Aggregating and forwarding data Providing monitoring and diagnostic information The result is a reusable communication component that can be deployed in different vehicle zones while maintaining the same overall behavior. 4 Simulink Model Overview The Zone Node functionality is implemented as a Simulink model organized around communication, routing, scheduling, and diagnostic subsystems. From a model perspective, the application can be divided into four logical areas: Input handling Routing and processing Communication scheduling Outputs and diagnostics ㅤ Figure 2. Main Simulink Application The input layer receives information from CAN and LIN communication interfaces and makes it available to the application logic. The processing layer evaluates incoming messages and determines how they should be handled. The scheduling layer manages periodic communication activities, while the output layer is responsible for forwarding messages and generating diagnostic information. This separation helps keep the model modular and makes it easier to extend the application with additional communication paths or Edge nodes without changing the core routing behavior. 5 Inputs The Zone Node receives information from three main categories of inputs. 5.1 CAN Network Inputs CAN communication represents the primary source of information processed by the Zone Node. Messages can originate from: Central Controller Lighting modules Steering modules Motor control modules Other Edge Nodes within the zone Typical examples include: Vehicle commands Status reports Diagnostic information Fault indications Actuation requests The exact set of messages depends on the specific Edge Nodes connected to the zone. 5.2 LIN Device Inputs The Zone Node also acquires information from LIN-connected devices. In the reference implementation, LIN communication is used to retrieve parking sensor information. The Zone Node periodically requests data from the LIN device and receives measurement values in response. Examples include: Front parking distances Rear parking distances Other LIN-based sensor information From the perspective of the Zone Node, LIN data behaves similarly to any other external input source. 5.3 Configuration Inputs Before normal operation begins, the Zone Node initializes its communication interfaces and loads the required configuration information. Examples include: CAN interface configuration LIN interface configuration Communication schedules Routing rules These parameters define how the application interacts with the surrounding networks. 6 Algorithm Internally, the Zone Node performs three main processing activities. 6.1 Message Reception The first step consists of collecting incoming communication data. Whenever a message arrives, the application captures: Communication source Message identifier Data payload Message length This information becomes available to the routing and aggregation logic. ㅤ Figure 3. CAN Reception Pipeline 6.1.1 Model Representation of Message Reception Within the Simulink model, message reception is implemented using communication interface blocks and dedicated processing subsystems that capture incoming network events and make the received information available to the rest of the application. ㅤ Figure 4. CAN Reception Main Flow ㅤ Figure 5. CAN Reception Subsystem At a high level, the reception subsystem performs three actions: Detects incoming communication events Stores the received information Makes the information available to the routing logic This allows the routing algorithm to operate independently from the physical communication interface. 6.2 Message Routing Message routing represents the primary responsibility of the Zone Node. The routing logic determines the origin of each incoming message and forwards it to the appropriate communication interface. The behavior can be simplified as: ㅤ Figure 6. Bidirectional CAN Routing Messages received from the Central Controller are forwarded toward the Edge Nodes, while messages originating from Edge Nodes are routed back toward the Central Controller. The routing mechanism remains independent of the actual application payload, allowing the same software architecture to support different message sets and vehicle functions. 6.2.1 Model Representation of Routing Logic The routing functionality is implemented as a dedicated subsystem responsible for deciding where each received message should be forwarded. ㅤ Figure 7. Message Routing Main Flow ㅤ Figure 8. Message Routing Subsystem The routing subsystem evaluates the origin of the received message and selects the appropriate destination interface. At this level, the application does not interpret individual signal meanings; it simply ensures that information reaches the correct communication network. This approach keeps the routing layer independent from application-specific functionality and allows the same architecture to be reused across different deployments. 6.3 LIN Scheduling and Data Acquisition In parallel with CAN routing, the Zone Node periodically acquires data from LIN-connected devices. The sequence follows a simple request-response model: ㅤ Figure 9. LIN Parking Acquisition Cycle This mechanism allows information originating on a LIN network to become available to the rest of the vehicle through CAN communication. 6.3.1 Model Representation of LIN Scheduling Periodic LIN communication is implemented using a dedicated scheduling subsystem. ㅤ Figure 10. LIN Scheduling Main Flow The scheduler periodically requests data from LIN-connected devices, waits for a response, and updates the application data used by the rest of the system. Depending on the communication requirements, the scheduler may manage one or more request-response sequences while maintaining a deterministic execution pattern. 6.4 High-Level Data Flow The internal data flow implemented by the Zone Node can be summarized as follows: ㅤ Figure 11. Zone Node Data Flow 7 Outputs The Zone Node produces several categories of outputs that are consumed by different parts of the vehicle architecture and by development tools used during validation and debugging. 7.1 Routed CAN Messages The primary outputs of the Zone Node are CAN messages forwarded between communication networks. Examples include: Commands sent from the Central Controller to Edge Nodes Status information returned from Edge Nodes Diagnostic messages Fault reports Configuration updates By routing these messages between communication domains, the Zone Node maintains communication between the central controller and the devices located within its assigned vehicle zone. 7.2 Aggregated Device Data In addition to forwarding CAN traffic, the Zone Node generates CAN messages containing information acquired from locally connected devices. One example is parking sensor data collected through a LIN interface and republished on CAN. This allows the Central Controller to access the information without requiring direct interaction with the LIN-connected device. The process can be summarized as: ㅤ Figure 12. LIN-to-CAN Data Path This approach creates a unified communication interface while hiding the complexity of the underlying network topology. 7.3 Diagnostic Outputs The Zone Node generates diagnostic information that is useful during development, system integration, and troubleshooting activities. Examples include: Communication counters Status variables Network activity indicators Communication statistics Device data used for monitoring purposes These outputs provide insight into the current behavior of the application and can be accessed through development tools such as FreeMASTER. 7.4 Visual Indicators In addition to communication outputs, the Zone Node drives visual indicators available on the evaluation hardware. The on-board LEDs provide immediate feedback regarding: Message reception activity Message transmission activity LIN communication activity Application execution status Although these indicators are not used by the vehicle itself, they simplify application bring-up and validation by providing a quick visual confirmation that the software is operating correctly. 7.5 Output Destinations The outputs generated by the Zone Node are consumed by several different system components. Central Controller Receives: Status information from Edge Nodes Aggregated sensor data Diagnostic information generated within the zone Edge Nodes Receive: Commands originating from the Central Controller Configuration and control messages forwarded through the Zone Node Local Devices Receive: Periodic requests issued by the Zone Node Communication messages required to acquire local measurements Development Tools Receive: Monitoring variables Communication statistics Diagnostic information used for debugging and validation 7.6 High-Level Output Flow ㅤ Figure 13. System Topology This output structure allows the Zone Node to act as a communication intermediary while simultaneously providing visibility into the behavior of the system during development and validation. 8 References NXP Model-Based Design Toolbox (MBDT) S32K3 Microcontroller Documentation S32K344-WB Evaluation Board Documentation 9 Conclusion This article described the internal behavior of the Zone Node by examining its inputs, processing logic, and outputs. By presenting the component as a functional black box, it explained how information is received, routed, aggregated, and distributed throughout the system without focusing on implementation-specific details. The next articles in the series will build upon this foundation by examining individual communication paths in more detail, including CAN-to-CAN routing, LIN-to-CAN routing, and the techniques used to validate and troubleshoot communication behavior.

Ara2_Model_Zoo_Compilation_Deployment_Testing_Guide This document provides an end-to-end example for setting up the Ara2 compilation environment, compiling the YOLOv8L ONNX model with the Model Zoo, deploying the compiled model to an i.MX95 target, running inference and performance tests, and reviewing the key YAML fields that must be updated when adapting the flow to another model of the same type.

Demystifying the PCIe and CPU address space translation in Linux lspci output on iMX95EVK as PCIe RClspci output on iMX95EVK as PCIe RC Please take a good look at the snippet above. It is taken from the console of iMX95 after executing 'lspci' on a specific PCIe device[iMX8MM as PCIe EP] that gets enumerated as BDF[Bus Device Function] 01:00.0. This blog attempts to debunk the mystery revolving around the "Memory at " info of the lspci output. We will discuss what this address is, why it is used and its relevance in the PCIe world. This blog will focus on the following agendas: - 1. PCIe parent and child relationship in Linux Device Tree 2. What is CPU and PCIe address space and the need for address space translation?  3. Assigning resources to a PCIe device in Linux 4. How is address space translation carried out in Linux PCI Subsystem?   PCIe parent and child relationship in Linux Device Tree In the Linux device tree, PCIe parent and child relationship defines how PCIe Root Complex and Endpoints are positioned in the system. A PCIe parent node in the device tree represents a PCIe controller (Root Complex / Host-Bridge). Taking reference from a PCIe node present in the device tree source of imx95: -   pcie@4c300000 {                         compatible = "fsl,imx95-pcie";                         reg = <0x00 0x4c300000 0x00 0x10000 0x00 0x4c360000 0x00 0x20000 0x00 0x60100000 0x00 0xfe00000>;                         reg-names = "dbi\0atu\0config";                         #address-cells = <0x03>   …  } pcie@4c300000 represents a Designware PCIe controller Root Complex which is a parent to the devices/bridge that will be connected to it. -- 'compatible' property identifies the specific PCIe controller. Its corresponding driver resides in drivers/pci/controller/dwc/pci-imx6.c -- 'reg' property specifies the memory mapped registers of the PCIe controller. Child nodes under PCIe RC represent devices on the PCIe bus. They can be fixed function devices like Wi-fi, Ethernet, NVMe or they can be PCIe bridges which further can have devices connected to it. Taking reference from 'arch/arm64/boot/dts/freescale/imx95.dtsi'   pcie_4ca00000: pcie@4ca00000 {                         compatible = "pci-host-ecam-generic";                         reg = <0x0 0x4ca00000 0x0 0x100000>;                         /* Must be 3. */              …              …              enetc_port0: ethernet@0,0 {                                 compatible = "fsl,imx95-enetc";                                 reg = <0x000000 0 0 0 0>;                                 clocks = <&scmi_clk IMX95_CLK_ENET>,                                          <&scmi_clk IMX95_CLK_ENETREF>;                                 clock-names = "ipg_clk", "enet_ref_clk";                                 nvmem-cells = <&eth_mac0>;                                 nvmem-cell-names = "mac-address";                                 status = "disabled";                         }; }   ethernet@0,0 is a PCIe device at bus 0, device 0, function 0. It is a child of PCIe RC which is memory mapped at 0x4ca00000   These child devices/bridges can either be dynamically discovered using PCI enumeration or they can be statically described in a device tree as seen in the device-tree snippet above in which "ethernet@0,0" entry statically tells the RC that the ethernet child device is connected to it. These child nodes are nested within a PCI parent node of the device tree as seen in the above example.   What is CPU and PCIe address space and the need for address space translation ? CPU address space is the system's physical memory map as seen by the processor. Example of CPU Physical Address Space viewed by Cortex-A55 on iMX95:-   Start address      End address    Module 0x48000000       0x4812FFFF    GIC Programming registers 0x4AA00000      0x4AAFFFFF    Neutron SRAM 0x4AC10000      0x4AC1FFFF    Camera domain block control 0x4E080000       0x4E08FFFF    DDR Controller This address space is kind of a global system view which is managed by system firmware/OS. These addresses are fixed by hardware-design. On the other hand, PCIe address space is local to PCI bus, managed by PCIe subsystem. The  addresses in this space are dynamically assigned. An example of PCIe address space that could look like the following:- 0x00000000   -    0x0FFFFFFF 0x10000000   -    0x1FFFFFFF 0x20000000   -    0x2FFFFFFF It is evident from the above explanation that CPU and PCIe address space operate in a separate and independent address domains. So the CPU cannot access the space of PCIe device unless a translation mechanism is in place. In one of the upcoming sections we will get to that as well but please spare a few minutes and ponder the question below:- Question : Why do you need separate address spaces for CPU and PCIe? Answer : One of the major reasons is modularity. We have separate spaces so that PCIe devices can be designed independently of the CPU architecture. Same card will work in different system. It will always have the flexibility of CPU remapping the PCIe space as and when needed. Also, different address spaces prevent devices to access arbitrary system memory. Based on the discussion in this section, it is evident that the PCIe address space is inherently different from the CPU address space and truth be told- it has its advantages. Therefore we need an entity to translate to/fro these address spaces. Here comes 'iATU' - Internal Address Translation Unit. On iMX SOCs, these hardware units are responsible for carrying out the address translation. These units are a part of Synopsys DesignWare PCIe Controller, providing programmable address translation windows for inbound and outbound transactions. For the readers who are uninitiated on the inbound and outbound transactions in pcie, please spare some time go through this technical blog - Understanding PCIe Outbound/Inbound windows with a use-case - NXP Community Note: - Address translation simply ensures that the CPU can access a PCIe device's memory and vice-versa. Up until here, the readers must have got a basic picture of PCIe Address Translation. Before jumping into the nitty-gritty of this translation in the Linux PCI subsystem, let's discuss how the resources are assigned to a PCIe device.   Assigning resources to a PCIe device in Linux PCIe devices do not have a direct CPU instruction interface so they communicate through memory-mapped regions. Devices need memory for DMA operations or for MSI/MSIX interrupts. Different devices have different needs, so resources in PCIe could be MMIO where device registers are mapped or memory regions needed for DMA transfer. In linux, pci_assign_resource function of PCI subsystem is responsible for assigning IO and memory resources to the PCIe devices during system initialisation after PCIe devices are enumerated. It is called for all the devices on a PCI bus and based on the PCI devices' resource requirement, it assigns them. But how does the PCI subsystem in linux figure out what resources does the PCIe devices need ? - Every PCIe device has a configuration space defined by the PCIe specification. This includes   BAR[Base Address Registers] - To indicate what type of resource[IO/Mem] does  the device needs and the size of resource. Capabilities - To broadcast the device capabilities such as MSI Interrupts, ASPM low power states etc. Reading the BARs from the PCIe device will tell us what kind and size of the resources are needed by the device. // To determine the size of resource from the BAR of PCIe device:- Step-1: Write all 1's to the target BAR register. Step-2: Read back the value and clear the lower 4 bits (for a memory BAR) or 2 bits (for an I/O BAR), as these are status bits, not part of the size calculation Step-3 Perform Bitwise NOT on the value and add 1 to it. Step-4: The returned value indicates the size. Taking an example to understand this:- Let's assume that after reading back the value in Step-2 above, the BAR returns 0xFFFFF000. The lower 4 bits are already cleared. Step-3  we perform bitwise NOT on the value -> ~(0xFFFFF000) = 0x00000FFF Adding 1 to it : 0x00000FFF + 1 = 0x00001000 The obtained value 0x1000 = 4096 bytes indicates the size, meaning the BAR requires a 4KB memory region. // To determine the type of resource from the BAR of PCIe device:-   A Base Address Register (BAR) in PCI configuration space: Bit 0 → Resource type: 1 = I/O space 0 = Memory space For memory BARs: 00 = 32-bit 10 = 64-bit Bits 1–2 → Addressing type: Bit 3 → Prefetchable flag Interpreting the value 0xFFFFF000, we get:-   Bit 0 = 0 → Memory space Bits 1–2 = 00 → 32-bit address Bit 3 = 0 → Prefetchable Upper bits → Base address (after masking)   pci_read_bases [drivers/pci/probe.c] in linux PCI subsystem is responsible to figure out the BAR memory size and type requirement during device enumeration. Needless to say, the above sequence of writing to the Endpoint's BAR and identifying the size and type of resource is executed on the PCIe RC. We have the following setup :- iMX95 <------> iMX8MM [RC]                     [EP] After PCIe RC has the size of the BAR that is required, the pci_assign_resource function allocates a memory range and then sets up translation from this memory range to the PCIe address space. we started this blog with a snippet, that shows the following lspci log:-   2.png Referring to the above, please note that the RC driver has allocated: - 0x910100000 - 0x910110000 as the non-prefetchable memory address range, size=64KB The above memory address range is in the PCIe 1 Outbound space memory mapped on iMX95 SoC: -   3.png The range 0x910100000 - 0x910110000 will be mapped to the PCIe address space of the End-point. This essentially means that if the cpu generates any address in between this range [inclusive of start and end-address], a PCIe TLP will be sent by the PCIe controller on the RC to the End-point on the bus. It could be a read or write to the memory of Endpoint. The address to write/read would be decided based on the address space translation. We shall discuss in-detail how this translation is exercised in the linux kernel in the next section.   How is address space translation carried out in Linux PCI Subsystem?   We start with some important questions: - Where is the range 0x910100000 - 0x910110000 specified ? How does the kernel know that it has to map the PCIe 1 Outbound space and not PCIe2 Outbound space or any other address space for that matter? -- Like all good things in Linux, this also starts with a 'device tree binary'. A dtb is passed by Uboot to the kernel so that it could get the hardware description of our board. Since we are using Torradex 's Verdin iMX95 EVK Board as Root Complex, this is the dtb that we are using - imx95-19x19-verdin-adv7535.dtb I will be attaching a working dtb with this blog so that the readers can use it if needed. This dtb includes - arch/arm64/boot/dts/freescale/imx95.dtsi Let's have a look at a particular pcie node of interest: -   4.png 'ranges' property is the answer to the questions that were asked in this section earlier.  - This property defines the address translation rules between the parent's address space and the child PCI address space.   Note:- This blog focuses only on 'ranges' property since it is relevant to our discussion. So the readers are advised to look elsewhere if they want to understand other device-tree properties of the PCIe node.  Let's decode the ranges property : It has the following format:-      3 cells               2 cells             2 cells             So one entry will have 7 cells. In our dtsi we have 2 entries. 1st is for IO space translation and the 2nd is for Mem space translation. Referring to the second entry  :-   0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000 |------PCI address---------------| |-CPU address-| |---PCI size---|   The above gives us the following info: - MEM Space prefetchable <   0x82000000 0x00 0x10000000   // PCIe address: 0x10000000   0x09 0x10000000              // CPU/system address: 0x910000000   0x00 0x10000000              // Size: 256MB >; 0x82000000 = 1000 0010 0000 0000 0000 0000 0000 0000   Bits 31–30 (10) → Configuration space type: This indicates memory space. Bit 29 (0) → Non-relocatable Bit 28 (0) → Non-prefetchable  (0 means non-prefetchable) Bits 27–24 (0010) → Address space type = Memory So, 0x82000000 means: PCI memory space Non-prefetchable 32-bit address space Note:- For those of you wondering why lspci output mentions [size=64K] and dts says 256 MB. This is because 256MB is the maximum address space available for the PCIe devices. It is upto the Endpoint device, how large address space does it require and accordingly it gets allocated. Similary IO space translation is also created from the 1st entry in 'ranges':- < 0x81000000 0x00 0x00 → PCI I/O address: 0x00000000 0x00 0x6ff00000 → CPU/system address: 0x6ff00000 0x00 0x100000 → Size: 1MB >;   we observe the same in the dmesg output of iMX95 Verdin EVK Linux console:-   5.png So the MEM Space mapping is from CPU Address 0x910000000 - 0x091fffffff translated to PCIe Address 0x10000000 - 0x1fffffff It is only fair that we mention the driver that uses the 'ranges' property. The 'ranges' property get parsed in "pci_parse_request_of_pci_ranges -> devm_of_pci_get_host_bridge_resources" of "drivers/pci/of.c" devm_of_pci_get_host_bridge_resources, for each range automatically  manages the memory allocated for these resources. It ensures that the resources are freed when the device is detached or the driver is removed. We have got the answer what & why is the cpu and pci address range the way it is. But in the lspci, you see 0x910100000 and not 0x910000000 which is what the intended start range is supposed to be as per the dtb. Why is that ? To answer this - we need to go back to the PCIe device enumeration. During PCIe enumeration, in the linux PCI driver the bar resources were determined like we had discussed earlier and then the PCI core driver may assign addresses keeping alignment requirements in mind that is why EP's BAR0 was assigned a PCI bus address as 0x10100000 with a 1MB[0x100000] offset from 0x10000000. And keeping the device tree pci translation window in mind:- 0x10100000 translates to 0x910100000 This translation doesn't happen on its own. Device tree binary just mentions the translation window specifics such as the CPU address space to translate to and the PCI address space to translate from. The actual translation is done via iATU. This is done in the dw_pcie_iatu_setup function of drivers/pci/controller/dwc/pcie-designware-host.c by creating the outbound window using dw_pcie_prog_outbound_atu function. Translation is configured on the RC successfully but there is still something missing. .. .. Inbound window !! Without an inbound window on the Endpoint i.e iMX8MM, the writes/reads to 0x910100000 would be meaningless. On iMX8MM we are using PCI Endpoint test driver which is quite popular in linux community and I would urge the readers to visit this page if they want more info - 9. PCI Endpoint Framework — The Linux Kernel documentation pci_epc_map_addr function in drivers/pci/endpoint/pci-epc-core.c creates inbound window by mapping PCI address [0x10100000] to physical address in EP's memory. That's how the reads and writes go through. If there's no Inbound window configured, something like this unfolds in case of read:-   6.png So now everything is set up. Translation windows are configured in the PCI drivers and you are at linux console. The following sequence unfolds when the CPU issues a memory read:-   7.png In case of memory writes:- 8.png The following happens on the Endpoint: - 9.png The beauty is that this entire translation happens transparently in hardware - your driver just reads/writes to the CPU address, and the PCI host controller handles all the translation automatically! -- How do we test the Address Translation ?   To test reads and writes, either we can make some changes in the driver itself or use devmem5 user-space binary. We are going to make minor driver side changes on iMX8MM and use devmem5 on the RC. iMX8MM is the PCIe Endpoint and we are using end-point test driver to configure it as such. If  you want to do the same, please follow this blog - Enabling PCIe End-point framework on iMX95 torradex board and iMX8MM EVK - NXP Community On the contrary if you want to make iMX95 as RC and iMX8MM Endpoint, feel free to follow this blog - How to configure iMX95EVK as PCIe Endpoint and test it using PCIe Endpoint Test Framework - NXP Community Two things we are going to do next: - 1. On iMX8MM EP, we are going to write some random values  in the drivers/pci/endpoint/pci-epf-core.c, make the following changes in pci_epf_alloc_space function: -     10.png 'space' is the virtual address and 'phys_addr' is the physical address that is contiguous. Please note that it is a crude way to test this translation. There are better ways to do it. Build the kernel after the changes and boot the board with it. Make iMX8MM an Endpoint using PCI Endpoint Test Framework. 2. On iMX95 Verdin EVK [PCIe RC], we are going to read the address 0x910100000 using devmem5 to verify that we can observe the same data on the RC.   11.png That's it for today. This was a long blog and if you feel overwhelmed by the details, please feel free to drop in the DMs or comments so that I can try to make it easier. Until next time! Gaurav Sharma   IMX95EVK

KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) Hello, I am reading the KW47 Reference Manual and I am confused about the relationship between the WDOG low-power modes and the system power modes. In the WDOG chapter, the Control and Status register contains the following bits: - WAIT: "Enables WDOG to operate when the chip is in Wait mode." - STOP: "Enables WDOG to operate when the chip is in Stop mode." The WDOG chapter also states that: - The selected WDOG clock source must remain active in Stop mode. - For Debug and Stop modes, a clock source other than the bus clock must be used. On the other hand, the Power Modes chapter describes: Sleep mode: - CPU execution halted - Core clock gated off - System clock and bus clock may continue running Deep Sleep mode: - Core clock gated off - System clock gated off - Bus clock gated off Based on these descriptions, it seems reasonable to interpret: - Wait mode ≈ Sleep mode - Stop mode ≈ Deep Sleep mode However, I have not been able to find any explicit statement in the Reference Manual confirming this mapping. My questions are: 1. Does WDOG Wait mode correspond to the Power Mode Sleep mode on KW47? 2. Does WDOG Stop mode correspond to the Power Mode Deep Sleep mode on KW47? 3. Or are Wait/Stop WDOG-specific CPU states that are different from the SoC power modes? 4. Is there any Reference Manual section or Application Note that explicitly describes this relationship? Thank you for your help. Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) Hello, hope you are doing well.   The terminology used in the KW47 Reference Manual is consistent with interpreting the WAIT and STOP fields in the WDOG control register as references to chip/core low-power states, rather than as WDOG-specific CPU states. I would describe the relationship as functional correspondence rather than a strict equivalence. In that sense, WDOG WAIT corresponds to the Wait/Sleep class condition, where CPU execution is halted but the system and bus clocks may remain available. WDOG STOP corresponds to the Stop/Deep-Sleep class condition, where the core, system, and bus clocks are gated and the watchdog can continue only if it is configured to use a clock source that remains active in that mode.   Best regards, Sofia. Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) Hello Sofia, Thank you for your previous explanation. Based on your reply, my understanding is: - WDOG WAIT corresponds to a Wait/Sleep-class low-power condition. - WDOG STOP corresponds to a Stop/Deep-Sleep-class low-power condition. - The relationship is a functional correspondence rather than a strict one-to-one mapping. After reviewing the KW47 Reference Manual again, I found the following section: 28.4 Module operation in low power modes Table 225: Cortex M33 core module operation in low power modes For WDOGx, the table shows: - Sleep : ON - Deep Sleep : Optional - Power Down : Optional - Deep Power Down : OFF From this table, I interpreted that WDOG operation can be configured in at least Deep Sleep and Power Down modes. To better understand the behavior, I performed a test using a KW47-Loc evaluation board. Test conditions: - WDOG enabled - WDOG refresh is performed from vApplicationIdleHook() - PWR_EnterLowPower() is executed from FreeRTOS vPortSuppressTicksAndSleep() - Observe whether a watchdog reset occurs after entering the low-power state Test results: Case 1 WAIT=0, STOP=0 → No watchdog reset occurred Case 2 WAIT=1, STOP=0 → Watchdog reset occurred Case 3 WAIT=0, STOP=1 → No watchdog reset occurred My interpretation is that when a watchdog reset occurred, the device entered a low-power state where vApplicationIdleHook() was no longer executed while the watchdog continued running and eventually timed out. However, a watchdog reset occurred only when WAIT=1 and STOP=0, while no watchdog reset occurred when STOP=1. Because of this result, I am having difficulty understanding how the WAIT and STOP bits are actually applied to watchdog operation during low-power modes. Could you please clarify the following points? 1. When the device enters a low-power mode through PWR_EnterLowPower(), is WDOG operation controlled by the WAIT bit or the STOP bit? 2. Does the observed result indicate that the device is actually entering Sleep mode rather than Deep Sleep mode, or should it be interpreted as entering Deep Sleep mode? 3. Does the STOP bit correspond to the Deep Sleep mode described in the Power Modes chapter, or does it refer to a different low-power state? 4. How should the following entries in Table 225 be interpreted with respect to the WDOG WAIT and STOP control bits? - WDOGx : Optional (Deep Sleep) - WDOGx : Optional (Power Down) Thank you for your support. Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) @sofiaurueta  I performed some additional testing and updated the post with my findings above. Could you please let me know if my interpretation is correct? Thank you. Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) Hi @hyama , I apologize for the late reply.   Are you testing with any example from the SDK? How are you confirming that the device is entering Deep Sleep mode? From the behavior you described, it is possible that the device is only entering Sleep mode. If the device were entering Deep Sleep, the results would be the opposite: STOP=1 (Case 3) should have caused the timeout, and WAIT=1 (Case 2) should have had no effect. The fact that it is WAIT=1 that triggers the reset is consistent with the device entering Sleep mode, not Deep Sleep.   Answering your questions: 1. When the device enters a low-power mode through PWR_EnterLowPower(), is WDOG operation controlled by the WAIT bit or the STOP bit? CS[WAIT] and CS[STOP] are independent controls for independent modes where CS[WAIT] controls WDOG operation in Sleep mode, and CS[STOP] controls WDOG operation in Deep Sleep mode. In the case that the device enters Sleep mode, CS[WAIT] is the active control. CS[STOP] has no effect here because Deep Sleep is not entered. If the device were instead configured to enter Deep Sleep, CS[STOP] would be the active control.   2. Does the observed result indicate that the device is actually entering Sleep mode rather than Deep Sleep mode, or should it be interpreted as entering Deep Sleep mode? The results are consistent with Sleep mode entry and are inconsistent with Deep Sleep. Based on the three test cases, Sleep mode is being entered.   3. Does the STOP bit correspond to the Deep Sleep mode described in the Power Modes chapter, or does it refer to a different low-power state? Based on the documentation, CS[STOP] corresponds to Deep Sleep, and the behavior observed in the tests is consistent with this (assuming that Deep Sleep was not entered).   4. How should the following entries in Table 225 be interpreted with respect to the WDOG WAIT and STOP control bits? The "Optional" for Deep Sleep means the WDOG can operate in Deep Sleep if CS[STOP]=1 and a clock source other than the bus clock is configured. For Debug and Stop modes, a clock source other than the bus clock must be used. Using the bus clock the watchdog can be "enabled" architecturally but its clock is gone, unless a different clock source is selected, for example, 32K_CLK. Best regards, Sofia. Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) Hi @sofiaurueta  Thank you for your previous explanation. >Are you testing with any example from the SDK? How are you confirming that the device is entering Deep Sleep mode? Regarding your question, the test was not performed on an SDK example project. It was performed on our application based on the NXP SDK. To verify whether the device enters Deep Sleep mode, I performed some additional investigation and found that the following path is executed when entering low-power mode: vPortSuppressTicksAndSleep() -> PWR_EnterLowPower() -> PM_EnterLowPower() -> PM_EnterLowPowerMode() -> CMC_EnterLowPowerMode() In CMC_EnterLowPowerMode(), the SDK sets the SLEEPDEEP bit in the SCB->SCR register before executing WFI. Our understanding is that setting the SLEEPDEEP bit and executing WFI means that the device enters Deep Sleep mode. Could you please confirm whether this understanding is correct for KW47? I am asking because my WDOG test results appear to depend on the WAIT bit rather than the STOP bit. Thank you for your help.

FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault HI Dear I set FS32K144WAT0WLFT PTD3 to ADC, will lead mcu to hardfault. I've encountered this issue with the 146 before—could you check it out for me? _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=5985335687075369917&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=3466386037717124085&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=4296127546010911231&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=1072804753289865017&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault I have never encountered a hardfault on the MCU caused by selecting PTD3 as ALT0 (ADC1_SE3). Regarding hardfault, I recommend reading: Fault handling on S32K14x. Or tell me which line of the function triggers the hardfault during debugging. I have checked the schematic you attached: Debug and programing interface: Please read section "4 Debug and programing interface" of AN5426 Hardware Design Guidelines for S32K1xx Microcontrollers (Rev. 6 December, 2021).pdf: For PTC4 (SWD_CLK), an external pull-down resistor is recommended rather than a pull-up resistor. Clock circuitry: I can't comment on the XTAL circuit, the Rs and load capacitors values are dependent on the specifications of the crystal and on the board capacitance. It is recommended the customer develops evaluation and characterization of the crystal on their PCB with the part manufacturer. However, the resistance value (470Ω) of R44 (Series resistor for current limitation) shown in your screenshot appears to be on the high side. Please refer to the section "3.2 Suggestions for the PCB layout of oscillator circuit" of AN5426 Hardware Design Guidelines for S32K1xx Microcontrollers (Rev. 6 December, 2021).pdf. In the S32K1xx datasheet, you can find min. required Vpp at EXTAL (Table 27. External System Oscillator electrical specifications), so I would recommend measuring it. Also, you need to ensure gmXOSC > 5 * gm_crit. Regarding feedback resistor for oscillator, it can be eliminated if SOSC is used at "low-gain" mode (SCG_SOSCCFG[HGO]=0). It's customer's choice which they want, lower power consumption (HGO=0) or higher noise immunity (HGO=1). Need to populate feedback resistor when SOSC is used at HGO=1 high-gain mode. ADC: The ADC input voltage range (VADIN) should be between VREFL and VREFH. Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault Hi Robin PTD3 selected ALT0 (ADC1_SE3), Have you ever encountered a situation like this, which causes the MCU to enter Hardfault Thanks! Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault Hi  Sorry, I didn't understand why you attached the schematic. Could you clarify whether you selected ALT0 (ADC1_SE3) or ALT7 (NMI_b) for the PORT_PCR[MUX] setting of PTD3? PTD3 MUX ALT0 ALT7.png Best Regards, Robin

NXP S32 配置工具如何添加更多端口引脚 大家好。 我的项目刚开始使用 FRDM Automotive S32K344 开发板和 Simulink (MBDT)。 但是，当我尝试创建额外的端口引脚时遇到了困难，因为我没有创建更多端口引脚/端口容器的选项。 请问有人能告诉我我的设置哪里出了问题吗？或者我需要先做一些事情吗？ Rizqu_0-1789455084038.png Re: NXP S32 Config Tools How to add more port pin 你好@Rizqu ， 端口/引脚容器不是手动管理的，这意味着如果您想添加一个额外的引脚，则必须在“引脚”视图中进行配置，该引脚将自动链接到端口/引脚容器。 端口配置与功能组名称相关联，请参阅以下社区帖子了解更多信息： 功能组问题 港口集装箱和功能组问题 已解决：外设配置 - NXP 社区 了解 S32 平台 IDE 中 S32 设计工作室的功能组的资源 如果您在使用 MBDT 时遇到其他问题，请将您的问题提交到基于模型的设计工具箱 (MBDT) - NXP 社区，以帮助我解决问题。 此致， 朱利安

NXP S32 Config Tools How to add more port pin Hello everyone. I just started using FRDM Automotive S32K344 Development Board and simulink (MBDT) for my project. But I have difficulties when try to make additional port pin because I don't have the option to make more portpin / portcontainer. Can anyone tell me what's wrong with my setting or maybe there are some things that I need to do first? Rizqu_0-1789455084038.png Re: NXP S32 Config Tools How to add more port pin Hello @Rizqu, The Port/Pin container is not managed manually, meaning that if you want to add an additional pin, you must configure it in the 'Pins' view, which will be automatically linked to the Port/Pin container. The Port configuration is linked with the functional group names, please refer to these community thread for more information:  functional group issue Port Container and Functional Group issue Solved: Peripherals configuration - NXP Community Resources to understand functional groups in S32 Design Studio for S32 platform IDE If you have further issues with MBDT specifically, please help me by submitting your question to the Model-Based Design Toolbox (MBDT) - NXP Community. Best regards, Julián

045-1299-001ZNT // NXP : AFT09MS015NT1 >>> Please advise meaning marking of part Hello Freescale team, ​Please help to advise the meaning marking* " ( ) B "* of NXP : AFT09MS015NT1 what is it? Thanks, ​ Thanks & Best regards. Re: 045-1299-001ZNT // NXP : AFT09MS015NT1 >>> Please advise meaning marking of part ( ) means circular recess on the top of the package. Please look at the AFT09MS015NT1 Datasheet, page 14. N & B is internal trace code. Have a great day, TIC   ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! -----------------------------------------------------------------------------------------------------------------------

FS32K144WAT0WLFT 将 PTD3 设置为 ADC，导致硬故障 你好呀亲爱的 我将 FS32K144WAT0WLFT PTD3 设置为 ADC，这将导致 MCU 发生硬故障。 我之前也遇到过146型电脑出现这个问题——你能帮我检查一下吗？ _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=5985335687075369917&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=3466386037717124085&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=4296127546010911231&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=1072804753289865017&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault 我从未遇到过因选择 PTD3 作为 ALT0 (ADC1_SE3) 而导致 MCU 出现硬故障的情况。关于硬故障，我建议阅读： S32K14x 上的故障处理。或者告诉我调试过程中函数中的哪一行触发了硬故障。 我已查看您提供的原理图： 调试和编程接口： 请阅读AN5426 S32K1xx 微控制器硬件设计指南（2021 年 12 月第 6 版）.pdf中的“4 调试和编程接口”部分： 对于PTC4 (SWD_CLK)，建议使用外部下拉电阻而不是上拉电阻。 时钟电路： 我无法对晶体振荡器电路发表评论，电阻和负载电容值取决于晶体的规格和电路的板的电容。建议客户与零件制造商一起，对PCB上的晶体进行评估和表征。 但是，您截图中显示的R44 （限流串联电阻）的电阻值（ 470Ω ）似乎偏高。 请参阅“3.2”部分AN5426 S32K1xx 微控制器硬件设计指南（2021 年 12 月修订版 6）中的振荡器电路 PCB 布局建议.pdf 。 在 S32K1xx 数据手册中，您可以找到最小值。EXTAL 所需的 Vpp（表 27。外部系统振荡器的电气规格），所以我建议测量一下。另外，您需要确保 gmXOSC > 5 * gm_crit。 关于振荡器的反馈电阻，如果SOSC工作在“低增益”模式（SCG_SOSCCFG[HGO]=0），则可以省略。客户可以根据自身需求选择更低功耗（HGO=0）或更高抗噪性（HGO=1）。当 SOSC 以 HGO=1 高增益模式使用时，需要安装反馈电阻。 ADC： ADC 输入电压范围 (VADIN) 应介于 VREFL 和 VREFH 之间。 Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault 嗨，罗宾 PTD3 选择 ALT0 (ADC1_SE3)，您是否遇到过这种情况，导致 MCU 进入硬故障状态？ 谢谢您！ Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault 你好 抱歉，我不明白你为什么要附上原理图。 请您澄清一下，您在 PTD3 的 PORT_PCR[MUX] 设置中选择的是 ALT0 (ADC1_SE3) 还是 ALT7 (NMI_b)？ PTD3 MUX ALT0 ALT7.png 此致敬礼， Robin

FS32K144WAT0WLFTがPTD3をADCに設定し、ハードフォルトにつながる こんにちわ、あなた PTD3 FS32K144WAT0WLFT ADCに設定しました。MCUはハードフォールトに導きます。 146で以前この問題に遭遇したことがありますが、試していただけますか? _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=5985335687075369917&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=3466386037717124085&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=4296127546010911231&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=1072804753289865017&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault PTD3をALT0(ADC1_SE3)として選択したことでMCUでハードフォルトが起きたことはありません。ハードフォルトに関しては、 「S32K14x でのフォルト処理」を読むことをお勧めします。もしくは、デバッグ中にハードフォルトが発生する関数の行を教えてください。 添付いただいた回路図を確認しました。 デバッグおよびプログラミングインターフェース: AN5426 S32K1xxマイクロコントローラ向けハードウェア設計ガイドライン(2021年12月6日改訂)の「4 デバッグおよびプログラミングインターフェース」セクションをお読みください.pdf: PTC4 （SWD_CLK）の場合、プルアップ抵抗ではなく、外部プルダウン抵抗の使用を推奨します。 クロック回路: XTAL回路についてはコメントできません。Rsや負荷コンデンサの値は、結晶の仕様や基板の静電容量に依存します。顧客は部品メーカーと共にPCB上の結晶の評価と特性評価を行うことが推奨されます。 しかし、スクリーンショットに示されているR44 （電流制限用の直列抵抗）の抵抗値（ 470Ω ）は、やや高い値であるように思われます。 「3.2」の項を参照してください。発振回路のPCBレイアウトに関する提案」は、 S32K1xxマイクロコントローラ向けAN5426ハードウェア設計ガイドライン(2021年12月6日改訂).pdf。 S32K1xxのデータシートには、最小量が記載されています。EXTAL で必要な Vpp (表 27)。外部システム発振器の電気仕様なので、測定することをおすすめします。また、gmXOSC > 5 * gm_crit であることを確認する必要があります。 発振器用のフィードバック抵抗については、SOSCを「低利得」モード(SCG_SOSCCFG[HGO]=0)で使用すれば廃止可能です。顧客の選択は、消費電力を抑える(HGO=0)か、高いノイズ耐性(HGO=1)かです。SOSCをHGO=1の高利得モードで使用する場合は、フィードバック抵抗を接続する必要があります。 ADC: ADCの入力電圧範囲（VADIN）は、VREFLとVREFHの間である必要があります。 Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault こんにちは、ロビンさん PTD3がALT0を選択しました(ADC1_SE3)、このような状況に遭遇したことがありますか?MCUがハードフォールに入る原因になります。 よろしくお願いします！ Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault こんにちは 申し訳ありませんが、なぜ回路図を添付されたのか理解できませんでした。 PTD3のPORT_PCR[MUX]設定でALT0(ADC1_SE3)かALT7(NMI_b)を選んだのか、もう少し詳しく教えていただけますか? PTD3 MUX ALT0 ALT7.png よろしくお願いいたします ロビン

045-1299-001ZNT // NXP : AFT09MS015NT1 >>> 请告知零件标记的含义 您好，Freescale团队， 请帮忙解释NXP的标记*“（）B”*的含义： AFT09MS015NT1 是什么 对吧？ 谢谢！ ​ 谢谢 & 此致敬礼。 Re: 045-1299-001ZNT // NXP : AFT09MS015NT1 >>> Please advise meaning marking of part <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> （ ）表示包装顶部的圆形凹槽。请参阅 AFT09MS015NT1 数据手册第 14 页。 N&B 是内部跟踪代码。 祝你有美好的一天， 信息通信技术   ----------------------------------------------------------------------------------------------------------------------- 注：如果此回复解答了您的问题，请点击“正确答案”按钮。谢谢你！ -----------------------------------------------------------------------------------------------------------------------

045-1299-001ZNT // NXP : AFT09MS015NT1 >>> 部品のマーキングの意味を教えてください フリースケールチームの皆様、こんにちは。 NXPの「( ) B」という表記の意味についてご教示ください。 AFT09MS015NT1とは 向上するのですよね？ ありがとうございます ​ ありがとうございます。よろしくお願いいたします。 Re: 045-1299-001ZNT // NXP : AFT09MS015NT1 >>> Please advise meaning marking of part <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ()はパッケージ上部の円形のくぼみを意味します。AFT09MS015NT1のデータシートの14ページをご覧ください。 NとBは内部トレースコードです。 良い一日をお過ごしください。 TIC   ----------------------------------------------------------------------------------------------------------------------- 注：この記事があなたの質問への回答になっている場合は、「正解」ボタンをクリックしてください。ありがとう！ -----------------------------------------------------------------------------------------------------------------------

KW47：WDOG 等待/停止模式与电源模式（睡眠/深度睡眠）之间的关系 你好， 我正在阅读 KW47 参考手册，但我对 WDOG 低功耗模式和系统电源模式之间的关系感到困惑。 在 WDOG 章节中，控制和状态寄存器包含以下位： - 等待： “使 WDOG 在芯片处于等待模式时也能运行。” - 停止： “使 WDOG 在芯片处于停止模式时也能运行。” WDOG章节还指出： - 在停止模式下，选定的 WDOG 时钟源必须保持活动状态。 - 对于调试模式和停止模式，必须使用总线时钟以外的时钟源。 另一方面，“电源模式”章节描述了： 睡眠模式： CPU执行已停止。 - 核心时钟已关闭 系统时钟和总线时钟可能会继续运行 深度睡眠模式： - 核心时钟已关闭 系统时钟已关闭 总线时钟已关闭 基于以上描述，可以合理地解释如下： - 等待模式 ≈ 睡眠模式 - 停止模式 ≈ 深度睡眠模式 然而，我尚未在参考手册中找到任何明确说明来证实这种映射关系。 我的问题是： 1. WDOG 等待模式是否对应于 KW47 的电源模式睡眠模式？ 2. WDOG 停止模式是否对应于 KW47 的电源模式深度睡眠模式？ 3. 或者说，Wait/Stop WDOG 是 CPU 特有的状态，与 SoC 电源模式不同？ 4. 是否有参考手册章节或应用笔记明确描述了这种关系？ 感谢您的帮助。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) 你好，希望你一切都好。   KW47 参考手册中使用的术语与将 WDOG 控制寄存器中的 WAIT 和 STOP 字段解释为对芯片/内核低功耗状态的引用，而不是对 WDOG 特定 CPU 状态的引用是一致的。我会将这种关系描述为功能对应，而不是严格的等价关系。 从这个意义上讲，WDOG WAIT 对应于等待/睡眠类条件，其中 CPU 执行停止，但系统和总线时钟可能仍然可用。WDOG STOP 对应于停止/深度睡眠类条件，其中内核、系统和总线时钟被门控，看门狗只有在配置为使用在该模式下保持活动的时钟源时才能继续工作。   此致， 索菲亚。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) 你好，索菲亚， 感谢您之前的解释。 根据您的回复，我的理解是： - WDOG WAIT 对应于等待/睡眠类低功耗状态。 - WDOG STOP 对应于停止/深度睡眠级别的低功耗状态。 - 这种关系是一种功能对应关系，而不是严格的一对一映射关系。 再次查阅KW47参考手册后，我发现了以下章节： 28.4 模块在低电源模式下的运行 表 225：Cortex M33 核心模块在低电源模式下的运行情况 对于 WDOGx，表格显示： - 睡眠：开启 - 深度睡眠：可选 - 关机：可选 深度关机：关闭 从这张表中，我了解到 WDOG 操作至少可以在深度睡眠和关机模式下配置。 为了更好地了解其行为，我使用 KW47-Loc 评估板进行了测试。 测试条件： - 已启用 WDOG - WDOG 刷新由 vApplicationIdleHook() 执行 - PWR_EnterLowPower() 由 FreeRTOS vPortSuppressTicksAndSleep() 执行 - 观察进入低功耗状态后是否发生看门狗复位 测试结果： 案例 1 等待=0，停止=0 → 未发生看门狗RESET 案例 2 等待=1，停止=0 → 看门狗复位发生 案例3 等待=0，停止=1 → 未发生看门狗复位 我的理解是，当看门狗复位时，设备进入低功耗状态，vApplicationIdleHook() 不再执行，而看门狗继续运行，最终超时。 但是，只有当 WAIT=1 且 STOP=0 时才会发生看门狗 RESET，而当 STOP=1 时则不会发生看门狗 RESET。 由于这个结果，我很难理解在低功耗电源模式下，WAIT 和 STOP 位是如何实际应用于看门狗操作的。 请您澄清以下几点？ 1.当设备通过 PWR_EnterLowPower() 进入低功耗模式时，WDOG 操作是由 WAIT 位控制还是由 STOP 位控制？ 2. 观察到的结果表明设备实际上进入了睡眠模式而不是深度睡眠模式，还是应该解释为进入了深度睡眠模式？ 3. STOP 位是否对应于电源模式章节中描述的深度睡眠模式，还是指不同的低功耗状态？ 4. 表 225 中的下列条目应该如何解释与 WDOG WAIT 和 STOP 控制位相关的内容？ - WDOGx：可选的（深度睡眠） - WDOGx：可选的（掉电） 感谢您的支持。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) @sofiaurueta 我进行了一些额外的测试，并将我的发现更新到了上面的帖子中。 请问我的理解是否正确？ 谢谢！ Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) @hyama你好，很抱歉回复晚了。   您是否使用 SDK 中的示例进行测试？您如何确认设备已进入深度睡眠模式？ 根据你描述的情况，设备可能只是进入了睡眠模式。如果设备进入深度睡眠状态，结果则相反：STOP=1（情况 3）应该会导致超时，而 WAIT=1（情况 2）应该不会产生任何影响。WAIT=1 触发 RESET 这一事实表明设备进入了睡眠模式，而不是深度睡眠模式。   回答您的问题： 1.当设备通过 PWR_EnterLowPower() 进入低功耗模式时，WDOG 操作是由 WAIT 位控制还是由 STOP 位控制？ CS[WAIT] 和 CS[STOP] 是独立模式的独立控制，其中 CS[WAIT] 控制睡眠模式下的 WDOG 操作，CS[STOP] 控制深度睡眠模式下的 WDOG 操作。 如果设备进入睡眠模式，则 CS[WAIT] 为活动控制。CS[STOP] 在这里不起作用，因为没有进入深度睡眠状态。如果设备配置为进入深度睡眠状态，则 CS[STOP] 将是活动控制。   2. 观察到的结果表明设备实际上进入了睡眠模式而不是深度睡眠模式，还是应该解释为进入了深度睡眠模式？ 结果与进入睡眠模式相符，与深度睡眠不符。根据三个测试用例，系统进入睡眠模式。   3. STOP 位是否对应于电源模式章节中描述的深度睡眠模式，还是指不同的低功耗状态？ 根据文档，CS[STOP] 对应于深度睡眠，测试中观察到的行为与此一致（假设没有进入深度睡眠）。   4. 表 225 中的下列条目应该如何解释与 WDOG WAIT 和 STOP 控制位相关的内容？ 对于深度睡眠，“可选”意味着如果 CS[STOP]=1 并且配置了总线时钟以外的时钟源，则 WDOG 可以在深度睡眠中运行。对于调试模式和停止模式，必须使用总线时钟以外的时钟源。使用总线时钟，看门狗在架构上可以“启用”，但它的时钟就消失了，除非选择不同的时钟源，例如 32K_CLK。 此致， 索菲亚。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) 嗨@sofiaurueta 感谢您之前的解释。 > 您是否使用 SDK 中的任何示例进行测试？您如何确认设备已进入深度睡眠模式？ 关于您的问题，该测试并非在 SDK 示例项目上进行。这是在我们基于 NXP SDK 的应用程序上执行的。 为了验证设备是否进入深度睡眠模式，我进行了一些额外的调查，发现进入低功耗模式时会执行以下路径： vPortSuppressTicksAndSleep() -> PWR_EnterLowPower() -> PM_EnterLowPower() -> PM_EnterLowPowerMode() -> CMC_EnterLowPowerMode() 在 CMC_EnterLowPowerMode() 中，SDK 在执行 WFI 之前设置 SCB->SCR 寄存器中的 SLEEPDEEP 位。 我们理解，设置 SLEEPDEEP 位并执行 WFI 意味着设备进入深度睡眠模式。请问您对KW47的理解是否正确？ 我这样问是因为我的 WDOG 测试结果似乎取决于 WAIT 位而不是 STOP 位。 感谢您的帮助。