S32K311 LCU 上升/下降滤波器死区时间偶尔会从 2 µs 缩短至 1 µs 您好，NXP团队： 我正在使用带有RTD 5.0的S32K311 。 PWM信号由eMIOS0生成，并直接路由至LCU0输出端： eMIOS0_CH0 -> LCU0_OUT0 eMIOS0_CH1 -> LCU0_OUT1 eMIOS0_CH2 -> LCU0_OUT2 eMIOS0_CH3 -> LCU0_OUT3 eMIOS0_CH4 -> LCU0_OUT4 eMIOS0_CH5 -> LCU0_OUT5   LCU 配置为使用上升/下降滤波器插入死区时间。   配置 MCU：S32K311 RTD 版本：5.0 PWM源：eMIOS0 死区生成：LCU 上升/下降滤波器 高侧通道上升滤波器 = 192 低侧通道的跌落滤波器 = 192 配置的死区时间 = 2 微秒 观察到的行为 大多数切换事件都会产生预期的2 µs 死区时间。 然而，偶尔会出现一个转换（上升沿或下降沿）只有大约1 µs死区时间，而不是 2 µs。这种情况会间歇性地发生，而 PWM 频率和占空比保持不变。 附件中的逻辑分析仪捕获图像显示了这种现象。 问题 使用 LCU 上升/下降滤波器时，这种变化是否正常？ eMIOS 输出和 LCU 滤波器之间是否存在同步要求？ LCU滤波器是否会因内部同步或时钟功能域交叉而偶尔缩短编程延迟？ S32K311 的上升/下降滤波器是否存在任何已知的限制或错误？ 任何指导都将不胜感激。 谢谢！ Re: S32K311 LCU Rise/Fall Filter Deadtime Occasionally Reduced from 2 µs to 1 µs 您好@Esakki 1. 您的值 192 = 2 µs  这意味着 LCU 滤波器的滴答时间约为： 2微秒 / 192 = 10.4167 ns -> 1/ 10.4167 ns = 96MHz, 如果有效的 LCU/外设时钟或预分频器发生变化，或者选择的时钟与假定的时钟不同，则实际延迟会发生变化。 2.使用示波器进行测试更加准确，波形与外部容抗有关；较大的容抗也会导致波形不稳定。

MX8-DSI-OLED1 显示屏部件号和序列号。 大家好， 我们也计划在我们的定制板中使用 MX8-DSI-OLED1 配件。 请问能否提供一下显示屏的零件编号，以及是否有任何需要保持的电源顺序？ Re: MX8-DSI-OLED1 Display part No and sequence. 你好， 您能告诉我您想了解哪方面的信息吗？ MX8-DSI-OLED1A（raydium rm67199）的显示屏是支持触摸的 MIPI-DSI OLED 显示屏。以下是一些主要特点： • 5.49 英寸 FHD (1080p@60fps) AMOLED 显示屏 • 1670万色（RGB*8位）显示颜色 • 触摸屏 • 用于显示器的 4 通道 MIPI-DSI 接口 • 用于触摸和控制的 I2C 接口 另外，请注意，关于这部分内容，我们能分享的信息不多。 此致敬礼/Saludos， 阿尔多。 Re: MX8-DSI-OLED1 Display part No and sequence. 大家好， 这件事有任何进展吗？ Re: MX8-DSI-OLED1 Display part No and sequence. 嗨@AldoG 我想了解这些轨道上电是否有任何需要遵循的顺序。 VDD_1V8 VEXT_3V3 VDD_5V

Eat-Sleep-Code-Repeat: Automotive Control Systems Using FRDM-A-S32K3XX Microcontrollers 1. Overview This article is the umbrella entry point for a series of automotive embedded workshops built on the FRDM-A-S32K3xx microcontroller family. It groups together five hands-on modules — Lights, Brakes, Steering, Comfort, and Transmission — each demonstrating a different real-world automotive function that a modern Body Control Module (BCM), Chassis ECU, or Powertrain ECU would implement in production vehicles. All five modules share the same educational philosophy: they take a simple, low-risk hardware setup (FRDM board + FRDM-K64 Click Shield + a few MikroE Click modules) and use it to teach the core embedded concepts that underlie automotive software: analog and digital signal acquisition, real-time processing, actuator control, and safety-aware system design. Together they cover the most common peripherals of the S32K3 family — ADC, GPIO, PWM, FlexIO, LPI2C, eMIOS — and expose students to the same tool-chain used by NXP customers: S32 Design Studio 3.6.5, the S32K3 Real-Time Drivers (RTD), the Application Code Hub (ACH), and the underlying Automotive Software Package. Learning philosophy — Eat-Sleep-Code-Repeat The whole workshop series is designed around the Eat-Sleep-Code-Repeat initiative — a learn-by-doing culture where students continuously iterate on real hardware, break things, fix them, refactor, and re-flash until the concepts stick. Every module is small enough to be completed in one lab session, yet rich enough to leave room for extensions (state machines, filtering, CAN networking, closed-loop control, safety fall-backs). Concepts covered across the series Analog sensing: potentiometers, force sensors, resistor-ladder buttons → ADC conversion, scaling, debouncing. Digital I/O: GPIO input handling (buttons, switches), GPIO output sequencing (stepper coils). Actuation: PWM-based motor speed control (DC motors, fans), PWM-based servo positioning, WS2812 LED driving through FlexIO. Communication: I²C configuration of external PWM drivers (Servo Click / PCA9685). Control patterns: continuous mapping, threshold-based decisions, state machines, safety interlocks. Automotive concepts: Body Control Module (BCM) behavior, functional safety (ISO 26262), fail-safe defaults, redundancy considerations. What this article gives you Each of the next five sections provides a short summary of one module — what it demonstrates, which hardware it uses, which peripherals are involved, and a direct link to the full detailed workshop article. Students should read this page first to understand where each module fits in the bigger picture, then dive into the individual articles for step-by-step instructions. 2. Vehicle Lighting Control The Lights module implements a simplified automotive lighting system that mirrors the behavior of a real vehicle Body Control Module. Six buttons on the Analog Key Click command different lighting functions — low beam, high beam, left/right turn signals, brake lights, and hazard lights — all displayed in real time on a 16-LED 4x4 RGB Click matrix. Key learning points Multi-button decoding on a single ADC channel (resistor-ladder input). Software debouncing and command decoding. Driving WS2812 LEDs through FlexIO (precise sub-microsecond timing without CPU load). BCM safety interlocks: high beam requires low beam ON; hazards synchronize left + right turn signals; high beam state preserved between blink cycles. Peripherals used: ADC0, FlexIO, GPIO. Boards: FRDM-A-S32K312 or FRDM-A-S32K344. Reference project:Automotive Lighting Control Using FRDM-A-S32K3XX Microcontrollers - NXP Community lighting_k344_gif.gif Demo: Vehicle Lighting Control on FRDM-A-S32K344 Automotive relevance: lighting is one of the most safety-critical driver-visibility functions in modern vehicles — this module teaches how a real BCM manages dependencies, blinking patterns, and fail-safe defaults. 3. Brake Status Monitoring The Brakes module implements a simplified brake status monitoring system where a Force Click sensor simulates the driver's brake-pedal pressure. As pressure increases, the ADC value grows and the application progressively lights up the 4x4 RGB Click LEDs in green → yellow → orange → red, providing immediate visual feedback of the current braking level. Key learning points Continuous analog sensor acquisition through ADC. Threshold-based decision logic: converting a raw ADC value into discrete alert levels. Driving the RGB LED matrix through FlexIO to reflect the current system state. Introduction to real-time monitoring and safety-oriented visual feedback. Peripherals used: ADC0, FlexIO. Boards: FRDM-A-S32K312 or FRDM-A-S32K344. Reference project: Automotive Brake Control Using FRDM-A-S32K3XX Microcontrollers - NXP Community brakes_k344_gif.gif Demo: Brake Status Monitoring on FRDM-A-S32K344 Automotive relevance: brake status is a core input for many downstream ECUs (ABS, ESC, hill-hold, brake lights). This module teaches the fundamental pattern of sensor → threshold → visual/electrical output that appears everywhere in automotive software. 4. Assisted Steering Control The Steering module demonstrates a simplified Electric Power Steering (EPS) / steer-by-wire concept. A POT Click potentiometer simulates the steering-wheel angle; the MCU reads it through ADC, scales it linearly, and generates a PWM command through the Servo Click (configured over I²C) that positions a Micro Servo SG 180° in real time. Key learning points Analog input scaling and linear mapping (ADC range → servo angle range). Using an external PWM controller configured over I²C (LPI2C1) — a common embedded pattern that offloads timing-critical work. Working with the Output Enable (OE) pin for safe-stop behavior. Understanding the actuation chain sensor → MCU → PWM → actuator. Peripherals used: ADC0, LPI2C1, GPIO. Boards: FRDM-A-S32K312 or FRDM-A-S32K344. Reference projects: Automotive Steering Control Using FRDM-A-S32K3XX Microcontrollers - NXP Community steering_k344_gif.gif Demo: PWM-Based Steering Control on FRDM-A-S32K344 Automotive relevance: steering is a strictly safety-relevant function (ISO 26262 typically classifies it as ASIL C or D). This module introduces the concepts behind EPS and steer-by-wire and lays the foundation for future work with redundant sensors and fault detection. 5. Vehicle Comfort Control The Comfort module implements two independent comfort functions typical of vehicle body electronics: cabin cooling (a 5 V fan driven through a DC Motor 2 Click using PWM) and electric window control (a NEMA17 stepper motor driven through an H-Bridge Click using full-step GPIO sequencing). On-board push-buttons act as the driver's HVAC and window switches. Key learning points PWM motor speed control (fan simulation). Stepper motor full-step sequencing (A → B → C → D and reverse) through four GPIO outputs. Handling multiple independent actuators from a single MCU without blocking. Introduction to window anti-pinch and other real BCM safety concepts. Peripherals used: GPIO, eMIOS (PWM). Boards: FRDM-A-S32K344 (only). Reference project: Automotive Comfort Control Using FRDM-A-S32K344 Microcontrollers - NXP Community comfort_k344_gif.gif Demo: Vehicle Comfort Control on FRDM-A-S32K344 Automotive relevance: comfort systems (HVAC, windows, mirrors, seats) form a huge share of modern body electronics. This module shows how one ECU can coordinate multiple actuators of different types (rotational-speed and positional) using the same S32K3 platform. 6. Transmission Control The Transmission module demonstrates a continuous, proportional transmission control concept. A POT Click potentiometer represents the driver's acceleration command; the MCU samples it, applies linear scaling, and simultaneously drives two actuators: a Servo Click + Micro Servo that simulates the transmission selector position, and a DC Motor 2 Click + DC motor whose speed reflects the powertrain response. Key learning points Dual-actuator control from a single analog input (one MCU commands both servo angle and DC motor speed in parallel). Linear signal mapping to two different PWM ranges simultaneously. Combining I²C-configured PWM (Servo Click) and eMIOS-generated PWM (DC Motor 2 Click) in the same application. Understanding continuous vs. discrete control and how continuous mapping better mirrors real automotive behavior. Peripherals used: ADC0, LPI2C1, eMIOS. Boards: FRDM-A-S32K344 (only). Reference project: Automotive Transmission Control Using FRDM-A-S32K344 Microcontrollers - NXP Community transmission_k344_gif.gif Demo: Transmission Control on FRDM-A-S32K344 Automotive relevance: transmission control is part of the powertrain domain and requires deterministic response and safety-aware design. This module introduces the concepts and prepares students for more advanced topics such as closed-loop control, transmission-mode logic (P/R/N/D), and CAN networking with the engine ECU. 7. Conclusion Together, these five modules give students a complete tour of what a modern Body Control Module, Chassis ECU, and Powertrain ECU actually do in a vehicle — from reading sensors and buttons, through processing and safety interlocks, to driving lights, motors, and actuators. Each module can be studied independently, but the real value emerges when they are viewed as pieces of one coherent picture: the same MCU family (S32K3), the same tool-chain (S32 Design Studio + Application Code Hub), the same hardware base (FRDM-A-S32Kxxx + FRDM-K64 Click Shield + MikroE Click modules), applied to five different automotive domains. The series is intentionally aligned with the Eat-Sleep-Code-Repeat philosophy: start with a working example, then experiment — add filtering, replace polling with interrupts, introduce a state machine, add CAN communication, or refactor for functional safety. Every extension is a step closer to the way production automotive software is actually written. Recommended learning path: Lights — simplest, teaches ADC, FlexIO and BCM logic. Brakes — introduces continuous sensor thresholds. Steering — adds I²C-controlled PWM and actuator positioning. Comfort — multi-actuator, dual-technology control (PWM + stepper). Transmission — combines everything into a proportional, dual-actuator system. If you have questions, suggestions for improvement, or ideas for new modules that could extend this series, please leave a comment below — feedback from students and instructors is what keeps the workshops relevant and up to date.

Automotive Comfort Control Using FRDM-A-S32K344 Microcontrollers 1. Overview This module demonstrates how to implement a vehicle comfort control system using GPIO, PWM, and stepper motor sequencing on NXP S32K3 microcontrollers. The application reads user inputs from push-buttons and translates them into two independent comfort functions: a DC motor that simulates a cabin cooling fan (regulated through PWM) and a stepper motor that simulates an electric window mechanism (driven through GPIO coil sequencing). Both actuators react in real time, mimicking how comfort body-control modules work in modern vehicles. This example is based on the Application Code Hub demonstration for: Vehicle Comfort Control for FRDM-A-S32K344 In this workshop, on-board push-buttons simulate the driver's comfort commands. When the student presses a button, the MCU reads the input through GPIO, decodes the requested action, and drives the associated actuator: a PWM duty cycle is generated for the DC Motor 2 Click (regulating the fan speed), or a full-step coil sequence is generated through GPIO outputs to the H-Bridge Click (moving the NEMA17 stepper motor up or down). Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic vehicle comfort control system and the ideas behind HVAC regulation and electric window control. Use on-board push-buttons as simulated driver comfort commands. Read digital inputs using the GPIO peripheral and understand debouncing considerations. Generate PWM signals to regulate DC motor speed (fan simulation). Implement a full-step drive sequence (A → B → C → D) to control a stepper motor. Configure the DC Motor 2 Click and H-Bridge Click boards over the mikroBUS interface. Recognize the actuation data flow: user input → MCU processing → PWM / GPIO actuation. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why comfort functions are relevant in modern automotive body electronics. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Push-buttons (on-board buttons simulate driver comfort commands) Processing: S32K3 MCU (reads GPIO, decodes the command, drives the correct actuator) Output: Dual actuation (DC motor via PWM for the fan, stepper motor via GPIO sequencing for the window) This matches the classic flow of an embedded body-control system: user input → processing → actuator. Functional Flow The system operates continuously as follows: The user presses a button that corresponds to a comfort action The GPIO peripheral reads the button state The application decodes the command (fan control or window movement) Depending on the command, the MCU generates either a PWM signal or a stepper coil sequence The DC motor changes speed, or the stepper motor rotates in the requested direction This loop runs continuously to ensure real-time comfort control. Comfort_Control_Application.png Vehicle Comfort Control Application Architecture 4. Key Concepts 4.1 GPIO (General-Purpose Input/Output) The push-buttons on the FRDM-A-S32K344 board are connected to GPIO input pins. The MCU polls (or reads on interrupt) the pin state and interprets a logic transition as a user command. GPIO is also used as output for the stepper motor coil control signals, driving the H-Bridge Click inputs. GPIO handling is the foundation of automotive user-interface processing — used for buttons, switches, ignition detection, and many others. 4.2 PWM — Pulse-Width Modulation and Fan Speed Control PWM switches a digital output on and off at a fixed frequency, varying the duty cycle (the fraction of time the signal is high). A DC motor interprets the average voltage produced by this PWM as a proportional rotational speed. In this demo, the S32K344 generates PWM on a mikroBUS pin that drives the DC Motor 2 Click, which in turn powers the 5 V fan motor. Increasing the duty cycle increases fan speed; decreasing it slows the fan down — a typical pattern used in cabin ventilation and HVAC systems. 4.3 DC Motor Direction and H-Bridge Concept The DC Motor 2 Click integrates an H-Bridge driver that can be configured for forward, reverse, brake, or coast modes. The MCU controls the direction pins and applies PWM on the enable input to regulate speed. This is exactly the same principle used in real automotive fan modules, where a low-side or full-bridge driver is switched at kilohertz frequency to obtain smooth speed control without dissipating power in a series resistor. 4.4 Stepper Motor Full-Step Sequencing A stepper motor like the NEMA17 rotates in fixed angular increments (typically 1.8° per step) when its coils are energized in the correct order. The MCU generates a repeating four-phase pattern (A → B → C → D) on four GPIO pins connected to the H-Bridge Click. Reversing the sequence (D → C → B → A) reverses the direction. The step frequency directly determines rotation speed, and counting the number of steps gives an open-loop position estimate — the exact behavior needed to simulate an electric window moving up or down. 4.5 Push-Buttons as Comfort Commands The on-board buttons are a simplified, safe stand-in for the physical HVAC and window switches found in a real vehicle. The student presses them by hand, the GPIO state changes, the MCU decodes the command, and the corresponding actuator reacts. This isolates the student from real body-electronics wiring while preserving the full software logic. 4.6 Data Flow at a Glance Button press → GPIO input → command decoding → selection of actuator (fan or window) → PWM duty cycle update or stepper coil sequence advance → motor response. This direct chain from the student's finger to the actuator shaft is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 MCU platform used to run the comfort control application and drive the connected peripherals. FRDM-K64 Click Shield FRDM K64 click shieldFRDM K64 click shield mikroBUS expansion board used to connect Click modules to the FRDM platform. DC Motor 2 Click DC Motor 2 ClickDC Motor 2 Click H-Bridge driver board used to control DC motor speed and direction via PWM. H-Bridge Click H-Bridge ClickH-Bridge Click Dual H-Bridge driver used to sequence the stepper motor coils. 5 V Fan Motor 5V Fan Motor5V Fan Motor Actuator used to simulate the vehicle cabin cooling fan controlled through PWM. Stepper Motor NEMA17 Stepper Motor Nema17Stepper Motor Nema17 Actuator used to simulate the electric window mechanism through step sequencing. USB-C  — Provides power and enables programming and debugging of the system. The example application demonstrates how these peripherals are connected to the MCU pins and used to simulate cabin cooling and electric window control. Vehicle Comfort Control Full Setup on FRDM-A-S32K344 Comfort Full SetupComfort Full Setup Software Environment S32 Design Studio IDE S32K3 Real-Time Drivers (RTD) S32K3 Automotive Software Package Application Code Hub project import Vehicle Comfort Control for FRDM-A-S32K344 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for the vehicle comfort control demo Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB cable and external 12 V supply Attach FRDM-K64 Click Shield, DC Motor 2 Click and H-Bridge Click Wire the 5 V fan motor and NEMA17 stepper motor Verify wiring before powering the system Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously 5 Functional Validation Press the fan control buttons Observe DC motor speed change Press the window up/down buttons Observe stepper motor movement and direction Fan speed and window motion follow user commands in real time 7. Signal Behavior and Control Logic The Vehicle Comfort Control application drives two independent actuators from a single S32K344 MCU: a DC fan motor controlled through a PWM signal for cooling, and a stepper motor controlled through a 4-channel GPIO sequence for electric window movement. User inputs (SW2 and SW3) are read by the MCU, which then generates the appropriate signal type for each actuator. The two diagrams below describe the signal behavior and control logic for each subsystem. 7.1 Cooling System – Fan Speed Control (PWM) Comfort_Fan_PWM.png Figure: Fan speed control mapping. The MCU generates a PWM signal on the EMIOS channel to drive the DC fan motor through the DC MOTOR 2 Click board. Each SW2 press increments the duty cycle by one step (0 % → 33 % → 67 % → 100 %) and each SW3 press decrements it, so fan speed is directly proportional to duty cycle. Duty Counts represent the raw PWM compare values (period = 20000 counts). When the fan is fully stopped, the TB6593FNG driver is automatically put into low-power sleep mode to prevent wasted current through the windings. 7.2 Window System – Stepper Motor Full-Step Sequencing Direction Step # Coil A (PTA13) Coil B (PTD0) Coil C (PTA3) Coil D (PTC10) Active Pair UP (SW2 pressed) 1 ON OFF ON OFF AC 2 OFF ON ON OFF BC 3 OFF ON OFF ON BD 4 ON OFF OFF ON AD DOWN (SW3 pressed) 1 ON OFF OFF ON AD 2 OFF ON OFF ON BD 3 OFF ON ON OFF BC 4 ON ON OFF OFF AC Table: Stepper motor full-step sequencing for window control. The MCU drives the stepper motor through four GPIO lines connected to the H-Bridge Click board, using dual-coil activation (two coils energised per step) to maximise torque. Pressing SW2 executes the Up sequence AC → BC → BD → AD (window moves up), while SW3 executes the reversed Down sequence AD → BD → BC → AC (window moves down). Each press advances the motor by one full step with a 3 ms delay, and the coil pair remains energised as long as the button is held. When no button is pressed, all coils are de-energised to prevent motor winding overheating during idle periods. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB cable and drivers Verify debugger connection Restart IDE Fan Does Not Spin Verify PWM configuration and duty cycle Check DC Motor 2 Click wiring and enable pins Ensure the 5 V motor supply is present Stepper Not Moving Verify GPIO output configuration for coil pins Check H-Bridge Click wiring and coil order Confirm the step delay is not too short (motor stalls) Stepper Rotates Wrong Direction Invert the coil sequence in software (A→B→C→D vs D→C→B→A) Swap one coil pair on the H-Bridge output Buttons Not Responding Verify GPIO input configuration and pull-up/pull-down Add software debouncing Check that the correct button pins are mapped 9. Extending the Application The basic implementation can be extended in several ways: Feedback-Based Control Add temperature or Hall-effect sensors for closed-loop fan speed regulation Add end-stop switches or encoders for accurate window position tracking Automatic Comfort Modes Implement predefined climate or ventilation profiles Trigger comfort actions based on sensor thresholds CAN Communication Enable communication with other vehicle ECUs (e.g., HVAC master, door module) Receive comfort commands over the vehicle network Diagnostic Functions Add fault detection for stuck motors, over-current or open loads Expose diagnostic status via LEDs or debug UART Position Memory Store and restore window or fan positions in non-volatile memory Recall the last comfort state after each power-up State Machine Implementation A more advanced approach is to implement a state machine: Idle Active Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver commands Immediate response to control signals Reliable actuator control for both speed and position In real systems: Redundancy is required for safety-relevant functions (e.g., anti-pinch on windows) Fault detection mechanisms are implemented (over-current, stall, over-temperature) Systems must comply with ISO 26262 (functional safety standard) where applicable Modern comfort modules also implement anti-pinch protection on power windows, ensuring the motor stops or reverses when an obstruction is detected — a safety-critical requirement for real vehicles. 11. Conclusion This module demonstrates how a simple embedded system can implement vehicle comfort control using GPIO inputs, PWM outputs, and stepper motor sequencing on the S32K344 platform. It shows how: Digital user inputs are acquired through GPIO Commands are decoded and processed in real time A DC motor is controlled using PWM for smooth speed regulation A stepper motor is controlled using a full-step coil sequence for precise positioning Result on FRDM-A-S32K344 Comfort ResultComfort Result The course provides a strong foundation for more advanced systems, including feedback-based control, CAN networking, diagnostics, and safety-oriented designs typical of automotive body-control modules. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

Automotive Lighting Control Using FRDM-A-S32K3XX Microcontrollers 1. Overview This module demonstrates how to implement a vehicle lighting control system using analog input acquisition and FlexIO-based LED driving on NXP S32K3 microcontrollers. The application reads analog inputs from the Analog Key Click module (six push-buttons, each generating a distinct voltage level) and converts them into commands that drive a 4x4 RGB LED matrix. Each button press activates a specific lighting function — low beam, high beam, turn signals, brake lights, or hazard lights — while safety interlocks and blinking patterns run continuously in the background, mimicking how a real automotive Body Control Module (BCM) manages vehicle lighting. This example is based on Application Code Hub demonstrations for: Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 In this workshop, the Analog Key Click simulates six vehicle lighting controls. When the student presses a button, an analog voltage proportional to the pressed key is read by the MCU through the ADC (with software debouncing), decoded into a specific lighting command, and translated into an RGB pattern generated by the FlexIO peripheral. The 4x4 RGB Click then displays the corresponding automotive lighting behavior in real time — warm white for low beams, cool white for high beams, blinking amber for turn signals and hazards, and red for brake lights. Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic vehicle lighting control system and the ideas behind an automotive Body Control Module (BCM). Use the Analog Key Click as a simulated multi-button user interface (six inputs on a single analog line). Acquire analog values (0–3.3 V) using the ADC and understand how multiple buttons share one channel through voltage division. Perform software debouncing and decode which button was pressed based on ADC value ranges. Drive an RGB LED matrix using the FlexIO peripheral, generating precise timing for WS2812-style LEDs. Implement safety interlocks between lighting functions (e.g., high beam requires low beam ON). Implement continuous background patterns such as blinking turn signals and synchronized hazards. Recognize the actuation data flow: analog input → ADC → command decoding → FlexIO LED output. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why lighting functions are relevant for automotive safety and driver visibility. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Analog Key Click (six buttons T1–T6, each generating a distinct analog voltage level) Processing: S32K3 MCU (reads the ADC, decodes the button, applies BCM logic, updates the LED state) Output: 4x4 RGB Click (16-LED matrix driven by FlexIO to display lighting patterns) This matches the classic flow of an embedded body-control system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The user presses a button on the Analog Key Click (T1–T6) Each button generates a distinct analog voltage on the shared output line The ADC samples the voltage and converts it into a digital value The application decodes which button was pressed (with debouncing) The BCM logic applies interlocks and dependencies (e.g., high beam requires low beam) The FlexIO peripheral drives the RGB Click LEDs with the corresponding color pattern This loop runs continuously to ensure real-time lighting control, with blinking patterns and safety interlocks maintained in the background. System_Architecture_Lights.pngVehicle Lighting Control Application Architecture  4. Key Concepts 4.1 ADC (Analog-to-Digital Converter) The Analog Key Click outputs 0–3.3 V on a single analog line, with each button generating a specific voltage step. The ADC samples this voltage on ADC0_P0 (pin PTD1) at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). Each button corresponds to a specific value range, allowing six digital inputs to be read through a single ADC channel. ADC acquisition is the foundation of automotive sensing — used for switches, buttons, sensors, and many others. 4.2 Analog Multi-Button Decoding Instead of using six separate GPIO pins, the Analog Key Click uses a resistor ladder that produces a different voltage for each button press. The application performs software debouncing (multiple ADC samples must agree before a press is confirmed) and then compares the ADC value against predefined thresholds to identify which button (T1–T6) was pressed. This technique is common in automotive steering-wheel controls, where many buttons share a single analog line to save wiring and pins. 4.3 FlexIO — Driving the RGB Click LEDs FlexIO is a highly flexible peripheral on S32K3 that can emulate serial protocols like WS2812/NeoPixel. The RGB Click uses individually addressable LEDs that require precise timing (~800 kHz with strict pulse widths). FlexIO on PTA13 (FlexIO_D8) generates this waveform in hardware, without loading the CPU. Each of the 16 LEDs receives its color data through a serial stream, allowing independent control of color and brightness per LED. 4.4 RGB LED Mapping and Lighting Zones The 16 LEDs of the RGB Click are logically grouped into automotive lighting zones: LEDs 13, 14 → Low Beam Headlights (warm white) LEDs 8, 9, 10, 11 → High Beam Headlights (cool white) LEDs 0, 12 → Left Turn Signal (blinking amber) LEDs 3, 15 → Right Turn Signal (blinking amber) LEDs 1, 2, 5, 6 → Brake Lights (red) LEDs 0, 3, 12, 15 → Hazard Lights (synchronized blinking amber) 4.5 BCM Safety Interlocks and State Dependencies The application implements safety logic typical of a real Body Control Module: high beam can only be activated when low beam is already ON; turning OFF the low beam automatically disables the high beam; hazard lights synchronize left and right turn signals simultaneously; high beam state is preserved during hazard blinking and restored between cycles. These interlocks illustrate how real automotive lighting logic prevents unsafe combinations and preserves driver intent. 4.6 Data Flow at a Glance Button press → analog voltage on shared line → ADC sample → software debouncing → button decoding → BCM logic (interlocks + dependencies) → FlexIO WS2812 output stream → RGB LED color update. This direct chain from the student's finger to the LEDs is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K312 FRDM-A-S32K312.png Alternative MCU platform used to run the lighting application and process user inputs. FRDM-A-S32K344 S32K344MINI-EVB.png Alternative MCU platform used to run the lighting application and control connected peripherals. FRDM-K64 Click Shield frdm-k64-click.jpg mikroBUS expansion board used to connect Click modules to the FRDM platform. Analog Key Click analog-click.jpg Six-button analog module used to simulate the vehicle lighting controls (headlights, indicators, brakes, hazards). 4x4 RGB Click 4x4-rgb-click.jpg 16-LED RGB matrix used to display the automotive lighting patterns in real time. USB-C / 12 V supply — Provides power and enables programming and debugging of the system through a single USB-C connection. The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate a complete vehicle lighting control system. Vehicle Lighting Control on FRDM-A-S32K312 Vehicle Lighting Control on FRDM-A-S32K344 Lights_k312.png Lights_k344.png Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio 3.6.5 Select “Import project from Application Code Hub” Search for “Lighting” Select the desired project for your FRDM board Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB-C cable (and 12 V supply for FRDM-A-S32K312) Attach FRDM-K64 Click Shield, Analog Key Click and 4x4 RGB Click Verify wiring on PTA13 (FlexIO) and PTD1 (ADC) Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously; LEDs perform startup test sequence 5 Functional Validation Press buttons T1–T6 on the Analog Key Click Observe corresponding LED patterns on the RGB Click Verify safety interlocks (high beam requires low beam) Verify continuous blinking on turn signals and hazards RGB LEDs display the correct automotive lighting patterns for each button 7. Signal Behavior and Control Logic   The following diagram illustrates how each user input on the Analog Key Click is mapped to a specific lighting function and to the individual LEDs of the 4×4 RGB Click matrix. Each button (T1–T6) triggers a unique combination of LEDs, colors, and patterns, reproducing the behavior of a simplified automotive lighting system.   Led_Matrix_Mapping.png  The MCU continuously monitors the analog input from the Analog Key Click and decodes which button is pressed. Based on the detected input, the application activates the corresponding lighting function by driving the assigned LEDs on the 4×4 RGB Click through the FlexIO serial interface. Steady functions (Low Beam, High Beam, Brake) keep the associated LEDs constantly ON, while directional functions (Left Turn, Right Turn, Hazard) toggle the LEDs at approximately 1 Hz to reproduce the blinking behavior of real vehicle indicators. Additional control rules — such as High Beam requiring Low Beam to be active, or Hazard Lights preserving and restoring the High Beam state — reflect the interdependencies found in a real automotive body control module. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB-C cable and drivers Verify debugger connection Restart IDE No LEDs Lighting Up Verify FlexIO configuration on PTA13 Check 3.3 V and GND wiring on RGB Click Confirm data-line wiring to IN1 Buttons Not Detected Verify ADC0_P0 configuration on PTD1 Check 3.3 V and GND wiring on Analog Key Click Confirm software debouncing thresholds Wrong Button Triggered Recalibrate ADC value ranges for each button Verify power supply stability (3.3 V) Check for noise on the analog line Incorrect LED Colors or Timing Verify FlexIO clock configuration (WS2812 timing) Check LED index → color mapping in code Ensure RGB order (GRB vs. RGB) matches the LED type High Beam Not Activating Ensure low beam (T1) is ON first — BCM interlock Check application logic for beam dependencies 9. Extending the Application The basic implementation can be extended in several ways: Additional Lighting Functions Add fog lights, parking lights, or daytime running lights (DRL) Simulate reverse lights that activate when a specific input is triggered Adaptive Front Lighting Integrate a steering angle input (e.g., POT Click) to swivel the headlights Simulate cornering lights that turn on when indicators are active Ambient Light Sensing Add a light sensor to automatically enable low beams at dusk Implement smooth dimming between day and night modes Brake Light Enhancements Add an emergency brake flashing pattern for hard braking Implement a third brake light (single LED, always ON with brakes) CAN Communication Enable communication with other vehicle ECUs (e.g., BCM master, doors) Receive lighting commands over the vehicle network State Machine Implementation A more advanced approach is to implement a formal state machine covering: Off DRL / Parking Low Beam High Beam Hazard / Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator (LED) control with predictable timing Safety interlocks between lighting functions (high beam requires low beam) In real systems: Redundancy is required for safety-relevant functions (e.g., brake lights, hazards) Fault detection mechanisms are implemented (open lamp, short circuit, overcurrent) Systems must comply with ISO 26262 (functional safety standard) Vehicle lighting is one of the most safety-critical automotive functions because it directly affects driver visibility and vehicle conspicuity. Modern Body Control Modules implement extensive diagnostics, backup lighting strategies, and fail-safe defaults (e.g., hazard lights activated on power-loss recovery). 11. Conclusion This module demonstrates how a simple embedded system can implement complete vehicle lighting control using ADC input and FlexIO output on the S32K3 platform. It shows how: Multiple digital inputs can share a single analog line through resistor-ladder decoding Analog data is acquired, debounced and processed in real time Complex automotive lighting patterns are controlled through FlexIO-driven WS2812 LEDs Safety interlocks and background blinking patterns are managed by BCM-style logic Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 FRDM-A-S32K312FRDM-A-S32K312 FRDM-A-S32K344FRDM-A-S32K344 The course provides a strong foundation for more advanced systems, including adaptive lighting, CAN networking, ambient sensing, and safety-oriented designs typical of automotive body-control modules.

Automotive Brake Control Using FRDM-A-S32K3XX Microcontrollers 1. Overview This article demonstrates how to implement a brake status monitoring system using NXP S32K3 microcontrollers. The solution is based on Application Code Hub examples for S32K344 and S32K312 platforms and showcases how real-time sensor data can be used to detect braking events and trigger visual feedback. This is based on the following Application Code Hub demonstrations: Brake-Control-Monitoring-FRDM-A-S32K312 Brake-Control-Monitoring-FRDM-A-S32K344 The application simulates braking conditions using a sensor input and provides immediate system response via an LED indicator. Such systems are commonly used in automotive environments to improve system awareness and support safety-related functionality.   Beyond teaching technical concepts, the course promotes the Eat-Sleep-Code-Repeat methodology as a core learning principle. Students are encouraged to continuously explore, implement, test, and enhance automotive embedded applications using real hardware and practical examples, reinforcing knowledge through repetition, experimentation, and hands-on problem solving. 2. Learning Scope This article covers both practical implementation and core embedded concepts, including: Reading analog signals using ADC Processing real-time signals Controlling outputs using GPIO Implementing decision logic based on thresholds Understanding signal flow in embedded systems 3. System Architecture The application is built around a simple but representative embedded system: Input: Analog sensor (force / brake simulation) Processing: S32K3 microcontroller Output: LED indicator Functional Flow The sensor generates an analog signal proportional to applied force The ADC converts the analog signal into a digital value The software evaluates the value against defined thresholds The system updates the output (LED) based on braking state Brake Monitoring Application ArchitectureBrake Monitoring Application Architecture 4. Key Concepts Analog Signal Acquisition (ADC) Sensors typically output analog values that must be digitized for processing. The ADC periodically samples this signal and produces a digital representation used by the application logic. Typical interpretation: Low value → no braking activity High value → braking detected Real-Time Signal Processing The system continuously reads sensor data and reacts immediately. This is essential in automotive contexts where delayed responses may impact system behavior. Output Control Using GPIO The LED output reflects the system state: OFF → no braking detected ON → braking condition detected In extended implementations, multiple states or patterns can be used. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K312 FRDM-A-S32K312FRDM-A-S32K312 Alternative MCU platform used to run the brake application and process brake inputs. FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 Alternative MCU platform used to run the brake application and control connected peripherals. FRDM K64 click shield                  frdm-k64-click mikroBUS expansion adapter that connects Click modules to the FRDM board Force Click (or similar analog sensor module)                          Force ClickForce Click Simulates the brake pedal by producing an analog signal proportional to applied pressure 4x4 RGB Click (LED output)                         4X4 RGB Click4X4 RGB Click Displays real-time brake status through colored LED patterns (green → yellow → orange → red) USB cable / power supply — Powers the FRDM board and provides debug connectivity to the PC The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate brake inputs and outputs. Brake Control Monitoring on FRDM-A-S32K312 Brake Control Monitoring on FRDM-A-S32K344 Brake Control Monitoring on FRDM-A-S32K312Brake Control Monitoring on FRDM-A-S32K312 Brake Control Monitoring on FRDM-A-S32K344Brake Control Monitoring on FRDM-A-S32K344 Software Environment S32 Design Studio S32K3 Automotive Software Package Application Code Hub project import Brake-Control-Monitoring-FRDM-A-S32K312 Brake-Control-Monitoring-FRDM-A-S32K344 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Use “Import project from Application Code Hub” Locate the brake monitoring example Import and configure the project Project is successfully loaded into the workspace 2 Build the Application Compile the project Resolve any dependency issues if needed No compilation errors 3 Connect Hardware Connect the development board via USB Attach sensor and LED modules Ensure correct pin connections Board is powered and detected by the IDE 4 Flash and Run Program the MCU Start execution Application runs continuously 5 Functional Validation Apply pressure to the sensor Observe LED behavior LED activates when braking condition is detected 7. Signal Behavior and Threshold Logic The application relies on threshold-based decision logic: If ADC value < threshold → no brake If ADC value ≥ threshold → brake active Signal vs Threshold Diagram Designer (4).png 8. Troubleshooting Issue Possible Actions Board Not Detected Verify USB cable and drivers Check debugger connection Restart IDE No Output Response Validate GPIO configuration Check LED connections Confirm code execution Incorrect Sensor Readings Verify ADC configuration Inspect sensor wiring Confirm scaling and thresholds 9. Extending the Application The basic implementation can be extended in several ways: Multi-Level Brake Detection Define multiple thresholds: Low → normal Medium → moderate braking High → emergency braking Noise Filtering Apply software filtering to stabilize readings Avoid false triggering from sensor noise Timing-Based Logic Add debounce or delay mechanisms Require sustained input before triggering State Machine Implementation A more advanced approach is to implement a state machine: Idle Braking Emergency 10. Safety Context Although simplified, this application reflects concepts used in automotive safety systems: Continuous monitoring of input signals Immediate response to changes Clear indication of system state In real systems, additional mechanisms are required: Redundancy Fault detection Compliance with safety standards (e.g., ISO 26262) 11. Conclusion This example demonstrates how a simple embedded application can model a real-world automotive use case. By combining ADC input, real-time processing, and GPIO output, it highlights the core principles behind monitoring functions in automotive ECUs. Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 Result on FRDM-A-S32k312Result on FRDM-A-S32k312 Result on FRDM-A-S32K344Result on FRDM-A-S32K344 The course provides a foundation for more advanced designs, including multi-state logic, filtering techniques, and safety-focused extensions. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

HOWTO: Install GHS Compiler Plugin S32 Design Studio (S32DS) supports Eclipse plug-in of Green Hills Software (GHS) compiler to compile S32DS projects via GHS compiler. This document describes how to install this plug-in and enable GHS in the new project wizard. After the GHS Eclipse plug-in is installed successfully, you can be able to create and build S32DS project using GHS compiler under S32DS Eclipse environment if the device and SDKs support GHS compiler. Installation instructions To able to use GHS compiler, you need to make sure that GHS compiler is installed with a valid license. Follow the steps below to install eclipse plugin: Install GHS Eclipse plug-in On S32DS graphical user interface, go to menu "Help" -> "Install New Software" DanielBarbu_0-1724323738892.jpeg In the "Install" dialog appears, click on "Add" button. In the "Add Repository" dialogappears, click on "Local". Navigate to the eclipse directory located in your MULTI compiler installation(eg: C:\ghs\comp_202114\eclipse) DanielBarbu_1-1724323981927.png In the Name box, enter "GHS Eclipse". Click on "Add" button. DanielBarbu_2-1724324072313.png  In the Name/Version list, expand the Green Hills MULTI for Eclipse item. Select GreenHills MULTI for Eclipse corresponding to your target architecture(eg: Green Hills MULTI for Eclipse(ARM) and Green Hills MULTI for Eclipse(ARM64)). If you have MULTI licenses for more than one architecture, you can select all the targets you are licensed for. Click Next until you see the license acceptance page. DanielBarbu_3-1724324146518.png  If you accept the terms of the feature license, select I accept the terms in the license agreement. And click on "Finish" button. DanielBarbu_4-1724324257519.png If the Security Warning window appears, click on "Install anyway". DanielBarbu_5-1724324310392.png In the "Software Updates" dialog box appears, click on "Restart Now" to restart S32DS.- Go to "Window" -> select "Preference" -> "S32 Design Studio for S32 Platform" -> "S32DS Variables". Set your GHS installation path for S32DS_GHS_PATH variable (ex "C:\ghs\comp_202114"). DanielBarbu_6-1724324374973.png Create new S32DS project using GHS in the project wizard. Now you can create a new S32DS project and select GHS toolchain for the device andSDKs support GHS toolchain. DanielBarbu_7-1724324414370.png And you can see the GHS settings are showed in the S32DS project properties. All_options_white_bg.png Re: HOWTO: Install GHS Compiler Plugin Hello NXP team, I have tried the above procedure and its not working, It is a simple test project. Created a simple project, using pins tool, updated the code , and tried to build all. here is the commander and linker options generated with new project. GHS C Compiler for ARM Standalone-  ccarm Options- -preprocess_assembly_files -list --no_slash_comment -C99 --no_exceptions --gnu_asm --unsigned_fields --unsigned_chars --no_short_enum --ghstd=last --prototype_errors -Wimplicit-int --incorrect_pragma_warnings -Wshadow -Wtrigraphs -Wundef -G -dwarf2 -Osize -DS32K344 -DGHS -DENABLE_FPU -DMPU_ENABLE -DI_CACHE_ENABLE -DD_CACHE_ENABLE -DCPU_S32K344 -DS32K3XX -DCPU_CORTEX_M7 -IC:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/generate/include -IC:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/RTD/include -I"C:\NXP\S32DS.3.5\eclipse\../S32DS/software/PlatformSDK_S32K3/RTD/BaseNXP_TS_T40D34M30I0R0/header" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/BaseNXP_TS_T40D34M30I0R0//header/" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/BaseNXP_TS_T40D34M30I0R0//include/" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/Platform_TS_T40D34M30I0R0//include/" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/Platform_TS_T40D34M30I0R0//startup/include/" -I"C:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/board" -keeptempfiles -littleendian -cpu=cortexm7 -fpu=vfpv5_d16 -fsingle -thumb --no_commons GHS C Linker for ARM Standalone ccarm options -  --gnu_asm -g -dwarf2 -Wl,-keep=C40_Ip_AccessCode -Wl,-v -T "C:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/Project_Settings/Linker_Files/linker_flash_s32k344.ld" -e Reset_Handler -delete -ignore_debug_references -map -keepmap -Mn -nostartfiles -I"C:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/board" -larch -lstartup -lind_sd -L"C:\ghs\comp_202354_1fp_x64_ForNXP\lib\thumb2" -cpu=cortexm7 -thumb

HOWTO: GHSコンパイラ・プラグインのインストール方法 S32 Design Studio（S32DS）は、Green Hills Software（GHS）コンパイラのEclipseプラグインをサポートしており、GHSコンパイラを使用してS32DSプロジェクトをコンパイルできます。本ドキュメントでは、このプラグインをインストールする方法と、新規プロジェクト・ウィザードでGHSを有効にする方法を説明します。 GHS Eclipse プラグインが正常にインストールされると、デバイスと SDK が GHS コンパイラをサポートしている場合、S32DS Eclipse 環境で GHS コンパイラを使用して S32DS プロジェクトを作成およびビルドできるようになります。 インストール手順 GHS コンパイラを使用するには、有効なライセンスでインストールされていることを確認する必要があります。Eclipse プラグインをインストールするには、以下の手順に従ってください。 GHS Eclipseプラグインのインストール S32DSのグラフィカル・ユーザー・インターフェースで、メニューの「Help（ヘルプ）」->「Install New Software（新規ソフトウェアをインストール）」を選択します。 DanielBarbu_0-1724323738892.jpeg 表示される「Install（インストール）」ダイアログで、「Add（追加）」ボタンをクリックします。表示される「Add Repository（リポジトリを追加）」ダイアログで、「Local（ローカル）」をクリックします。MULTIコンパイラのインストール先にあるeclipseディレクトリに移動します（例： C:\ghs\comp_202114\eclipse） DanielBarbu_1-1724323981927.png 「Name（名前）」ボックスに「GHS Eclipse」と入力します。「Add（追加）」ボタンをクリックします。 DanielBarbu_2-1724324072313.png 名前/バージョンのリストで、Green Hills MULTI for Eclipseの項目を展開します。ターゲットのアーキテクチャに合致するGreen Hills MULTI for Eclipseを選択します（例：Green Hills MULTI for Eclipse（ARM）とGreen Hills MULTI for Eclipse（ARM64））。複数のアーキテクチャに対してMULTIライセンスを保有している場合は、ライセンスが適用されるすべてのターゲットを選択できます。「Next（次へ）」をクリックして、ライセンスの同意ページまで移動します。 DanielBarbu_3-1724324146518.png 機能ライセンスの条項に同意する場合は、「I accept the terms in the license agreement（ライセンス契約の条項に同意します）」を選択します。「Finish（完了）」ボタンをクリックします。 DanielBarbu_4-1724324257519.png セキュリティ警告ウィンドウが表示された場合は、「Install anyway」をクリックしてください。 DanielBarbu_5-1724324310392.png 表示される「Software Updates（ソフトウェア・アップデート）」ダイアログ・ボックスで、「Restart Now（今すぐ再起動）」をクリックして、S32DSを再起動します。「Window（ウィンドウ）」->「Preference（環境設定）」->「S32 Design Studio for S32 Platform」->「S32DS Variables（S32DS変数）」を選択します。S32DS_GHS_PATH変数にGHSのインストール・パスを設定します（例：「C:\ghs\comp_202114」）。 DanielBarbu_6-1724324374973.png プロジェクトウィザードでGHSを使用して新しいS32DSプロジェクトを作成してください。 こうして、GHSツールチェーンをサポートするデバイスを対象として、S32DSプロジェクトを新規作成し、GHSツールチェーンを選択できるようになりました。 DanielBarbu_7-1724324414370.png また、画面を見ると、S32DSプロジェクトのプロパティにGHS設定が表示されています。 DanielBarbu_8-1724324493234.png Re: HOWTO: GHSコンパイラ・プラグインのインストール方法 NXPチームの皆様、こんにちは。 上記の手順を試しましたが、うまくいきません。簡単なテスト・プロジェクトで試しています。 ピンツールを使用して簡単なプロジェクトを作成し、コードを更新し、すべてをビルドしようとしました。 新規プロジェクトで生成されたコマンドとリンカのオプションは次のとおりです。 GHS C ARMスタンドアロン用コンパイラ ccarm Options- -preprocess_assembly_files -list --no_slash_comment -C99 --no_exceptions --gnu_asm --unsigned_fields --unsigned_chars --no_short_enum --ghstd=last --prototype_errors -Wimplicit-int --incorrect_pragma_warnings -Wshadow -Wtrigraphs -Wundef -G -dwarf2 -Osize -DS32K344 -DGHS -DENABLE_FPU -DMPU_ENABLE -DI_CACHE_ENABLE -DD_CACHE_ENABLE -DCPU_S32K344 -DS32K3XX -DCPU_CORTEX_M7 -IC:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/generate/include -IC:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/RTD/include -I"C:\NXP\S32DS.3.5\eclipse\../S32DS/software/PlatformSDK_S32K3/RTD/BaseNXP_TS_T40D34M30I0R0/header" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/BaseNXP_TS_T40D34M30I0R0//header/" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/BaseNXP_TS_T40D34M30I0R0//include/" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/Platform_TS_T40D34M30I0R0//include/" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/Platform_TS_T40D34M30I0R0//startup/include/" -I"C:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/board" -keeptempfiles -littleendian -cpu=cortexm7 -fpu=vfpv5_d16 -fsingle -thumb --no_commons GHS C ARMスタンドアロン用リンカー ccarm オプション - --gnu_asm -g -dwarf2 -Wl,-keep=C40_Ip_AccessCode -Wl,-v -T "C:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/Project_Settings/Linker_Files/linker_flash_s32k344.ld" -e Reset_Handler -delete -ignore_debug_references -map -keepmap -Mn -nostartfiles -I"C:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/board" -larch -lstartup -lind_sd -L"C:\ghs\comp_202354_1fp_x64_ForNXP\lib\thumb2" -cpu=cortexm7 -thumb

操作方式：安装 GHS 编译器插件 S32 设计工作室（S32DS）支持 Green Hills Software（GHS）编译器的 Eclipse 插件，可通过 GHS 编译器来编译 S32DS 项目。本文档介绍如何安装该插件以及在新建项目向导中启用 GHS。 GHS Eclipse 插件成功安装后，若器件和 SDK 支持 GHS 编译器，你就可以在 S32DS Eclipse 环境下使用 GHS 编译器创建并构建 S32DS 项目。 安装说明 要使用 GHS 编译器，您需要确保 GHS 编译器已安装并拥有有效的许可证。请按照以下步骤安装 Eclipse 插件： 安装 GHS Eclipse 插件 在S32DS图形用户界面中，进入菜单"Help" -> "Install New Software" DanielBarbu_0-1724323738892.jpeg 在弹出的 “Install”（安装）对话框中，点击 “Add”（添加）按钮。在弹出的 “Add Repository”（添加仓库）对话框中，点击 “Local”（本地）。导航至您的 MULTI 编译器安装目录下的 eclipse 文件夹（例如：C:\ghs\comp_202114\eclipse）。 DanielBarbu_1-1724323981927.png 在 “名称” 框中，输入 “GHS Eclipse”。点击 “添加” 按钮。 DanielBarbu_2-1724324072313.png 在 “名称 / 版本” 列表中，展开 “Green Hills MULTI for Eclipse” 项。选择与您的目标架构对应的 “Green Hills MULTI for Eclipse”（例如：Green Hills MULTI for Eclipse (ARM) 和 Green Hills MULTI for Eclipse (ARM64)）。如果您拥有多个架构的 MULTI 许可证，可以选择所有已获得许可的目标架构。点击 “下一步”，直至出现许可协议接受页面。 DanielBarbu_3-1724324146518.png 如果您接受该功能许可条款，请选择 “我接受许可协议中的条款”，然后点击 “完成” 按钮。 DanielBarbu_4-1724324257519.png 如果出现 “安全警告” 窗口，请点击 “仍然安装”。 DanielBarbu_5-1724324310392.png 在弹出的 “软件更新” 对话框中，点击 “立即重启” 以重启 S32DS。-依次进入 “Window”-> 选择 “Preference”-> “S32 Design Studio for S32 Platform”-> “S32DS Variables”。为 S32DS_GHS_PATH 变量设置您的 GHS 安装路径（例如 “C:\ghs\comp_202114”）。 DanielBarbu_6-1724324374973.png 在项目向导中使用GHS创建新的S32DS项目。 现在，您可以创建一个新的 S32DS 项目，并为支持 GHS 工具链的器件和 SDK 选择 GHS 工具链。 DanielBarbu_7-1724324414370.png 您可以看到GHS设置显示在S32DS项目属性中。 DanielBarbu_8-1724324493234.png 回复：如何安装 GHS 编译器插件 您好，NXP团队， 我已尝试上述步骤，但无法正常运行，这只是一个简单的测试项目。 创建了一个简单的项目，使用 pins 工具，更新了代码，并尝试构建所有。 以下是新项目生成的编译器和链接器选项。 ARM 独立式 GHS C 编译器 - ccarm 选项- -preprocess_assembly_files -list --no_slash_comment -C99 --no_exceptions --gnu_asm --unsigned_fields --unsigned_chars --no_short_enum --ghstd=last --prototype_errors -Wimplicit-int --incorrect_pragma_warnings -Wshadow -Wtrigraphs -Wundef -G -dwarf2 -Osize -DS32K344 -DGHS -DENABLE_FPU -DMPU_ENABLE -DI_CACHE_ENABLE -DD_CACHE_ENABLE -DCPU_S32K344 -DS32K3XX -DCPU_CORTEX_M7 -IC:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/generate/include -IC:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/RTD/include -I"C:\NXP\S32DS.3.5\eclipse\../S32DS/software/PlatformSDK_S32K3/RTD/BaseNXP_TS_T40D34M30I0R0/header" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/BaseNXP_TS_T40D34M30I0R0//header/" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/BaseNXP_TS_T40D34M30I0R0//include/" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/Platform_TS_T40D34M30I0R0//include/" -I"C:\NXP\S32DS.3.5\eclipse\/../S32DS/software/PlatformSDK_S32K3/RTD/Platform_TS_T40D34M30I0R0//startup/include/" -I"C:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/board" -keeptempfiles -littleendian -cpu=cortexm7 -fpu=vfpv5_d16 -fsingle -thumb --no_commons ARM 独立式 GHS C 链接器 ccarm 选项 - --gnu_asm -g -dwarf2 -Wl,-keep=C40_Ip_AccessCode -Wl,-v -T "C:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/Project_Settings/Linker_Files/linker_flash_s32k344.ld" -e Reset_Handler -delete -ignore_debug_references -map -keepmap -Mn -nostartfiles -I"C:\Users\ganheg1\workspaceS32DS.3.5\GHS_Test/board" -larch -lstartup -lind_sd -L"C:\ghs\comp_202354_1fp_x64_ForNXP\lib\thumb2" -cpu=cortexm7 -thumb

S32DS ARM 2.2 issue After installing S32DSARM 2.2 on Windows 11, the following error message appears. The default project cannot be opened either. Re: S32DS ARM 2.2 issue Hi@ yeSerrui After installing S32 DS, you also need to install the RTM SDK, as shown below. Senlent_1-1785739865237.png In the project browsing box on the left, right-click "new" to select the included example. Senlent_0-1785739821338.png

インターネットにコネクテッドではないコンピュータでGUI Guiderを起動できない こんにちは。私の開発用コンピュータはインターネットに接続されていません。GUI Guider をダウンロードし、プログラムを起動すると、インターネット接続を探し、NXP アカウントにログインするように求められます。GUI Guider を実行するにはなぜインターネット接続が必要なのですか?インターネットに接続されていないコンピューターでツールを起動する方法はありますか? ありがとうございます ジョー Re: Unable to Launch GUI Guider on non-internet connected computer こんにちは@joseph_lindula すでにメールで返信させていただきました。 ご理解いただきありがとうございます。 BR ハリー Re: Unable to Launch GUI Guider on non-internet connected computer また、インターネット接続していないパソコンからGui Guiderを動かしたいとも思っています。 CAN 解決策を公に共有していただき、皆がSO恩恵を受けられるようにしてください。 よろしくお願いします。

NFC Cockpit 下载 大家好！不好意思问个傻问题，请问哪里可以下载适用于我的CLRC 663的NFC Cockpit？ 软件页面上找不到相关信息： Screenshot_474.png

NXP MIMXRT1062DVL6Bに関するヘルプ/質問 NXP MIMXRT1062DVL6B おもちゃのデザインについて。 ユニット番号：NXP MIMXRT1062DVL6B に関して 強力な600MHz CortexM7を搭載しているので、私には必要以上の性能かもしれません。 私はそれを2語のフレーズを認識するためだけに利用しています。VIT + 2つのマイク+カスタムウェイクフレーズを安定して動作させる、最も安価なNXPプロセッサはありますか? ご相談のため、[email protected]までメールをいただければ幸いです。 Re: NXP MIMXRT1062DVL6B help/questions こんにちは、 @toy_maker さん。 ご質問ありがとうございます！ VITが提供するサポート対象部品番号のリストを参照してください。 Gavin_Jia_0-1785724846969.png また、このスレッドの議論も参考になるはずです:https://community.nxp.com/t5/MCX-Microcontrollers/Wake-Word-and-Voice-command-engines/m-p/2054222 MCXNに関する詳細情報については、関連するコミュニティフォーラムに質問を投稿することをお勧めします。ありがとう！ よろしくお願いします、 ギャビン

LPC55xx API Hello, for a new project I want to use LPC550x microcontroller with IAR Embedded Workbench: in the past I have used other LPC MCU (LPC1317, LPC1788, LPC1788) Now i read everywhere that some functions can be managed only by using API but I don't understand how to use them; are these function available only with MCUXPRESSO? I would like to avoid API and write my own code but I don't fine the C code of these API. For example CAP BANK for oscillators are only documented with API so if I don't use API I can't use these CAP BANK. Is it correct? I have a big confusion in my mind about this. Can anyone help me? It's for my job Best regards. Re: LPC55xx API Hello @Lor75  For newer NXP MCUs, including the LPC55xx series, we recommend using the MCUXpresso SDK drivers, which include both APIs and source code. You can download the SDK from: https://mcuxpresso.nxp.com/builder?hw=LPCXpresso55S06&rel=943  For detailed instructions, please refer to: https://www.nxp.com/document/guide/getting-started-with-the-lpc55s06-evk-evaluation-board:GS-LPC55S06-EVK?section=get-software   Additionally, the LPC55xx series is supported by MCUXpresso IDE, which is free to use with no restrictions on functionality or code size. You can download MCUXpresso IDE from: https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE  If still have any question, please feel free to contact me. Thank you.  BR Alice

LPC55xx API こんにちは、 新しいプロジェクトでは、LPC550xマイクロコントローラとIAR Embedded Workbenchを使いたいと考えています。過去には他のLPC MCU(LPC1317、LPC1788、LPC1788)を使っていました どこでも「APIでしか管理できない関数もある」と読んだのですが、どう使えばいいのか分かりません。これらの機能はMCUXPRESSOでしか使えないのでしょうか? APIを使わずに自分でコードを書きたいのですが、これらのAPIのC言語コードが見つかりません。例えば、オシレーター用のCAP BANKはAPIでしかドキュメント化されていないので、APIを使わなければこれらのCAP BANKは使えません。それは正しいですか？ これについて、私は大きな混乱を抱えています。 どなたか助けてくれませんか?仕事のためです よろしくお願いいたします。 Re: LPC55xx API こんにちは、 @Lor75さん LPC55xxシリーズを含む新しいNXP MCUでは、APIとソースコードの両方を含むMCUXpresso SDKドライバの使用を推奨します。 SDKは以下からダウンロードできます: https://mcuxpresso.nxp.com/builder?hw=LPCXpresso55S06&rel=943  詳細な手順については、以下を参照してください。 https://www.nxp.com/document/guide/getting-started-with-the-lpc55s06-evk-evaluation-board:GS-LPC55S06-EVK?section=get-software さらに、LPC55xxシリーズはMCUXpresso IDEでサポートされており、機能やコードサイズに制限なく無料で使用できます。 MCUXpresso IDEは以下からダウンロードできます: https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE  もし質問があれば、どうぞ気軽にお問い合わせください。ありがとう。 BR アリス

NXP MIMXRT1062DVL6B 帮助/问题 NXP MIMXRT1062DVL6B 关于玩具设计。 关于您的设备编号：NXP MIMXRT1062DVL6B 它配备了强大的 600MHz CortexM7 处理器，这可能超出了我的需求。 我用它来识别两个单词的短语。NXP 是否有价格最低的处理器能够可靠地运行 VIT + 两个麦克风 + 自定义唤醒词？ 欢迎通过电子邮件联系，以便我们进一步讨论：[email protected] Re: NXP MIMXRT1062DVL6B help/questions 嗨@toy_maker ， 谢谢你的提问！ 请参考VIT提供的受支持零件编号列表。 Gavin_Jia_0-1785724846969.png 此外，这个帖子里的讨论应该会有帮助： https://community.nxp.com/t5/MCX-Microcontrollers/Wake-Word-and-Voice-command-engines/mp/2054222 有关 MCXN 的更多信息，我们建议您在相关的社区论坛中发布您的问题。谢谢你！ 此致， 加文

NXP MIMXRT1062DVL6B help/questions NXP MIMXRT1062DVL6B regarding toy design. In regards to your unit number: NXP MIMXRT1062DVL6B a powerful 600MHz CortexM7 and it may be more then I need. I am using it to only to recognize a two word phrase. IS there a least expensive NXP processor that can reliably run VIT + two microphones + a custom wake phrase? Would appreciate an email to discuss: [email protected] Re: NXP MIMXRT1062DVL6B help/questions Hi @toy_maker , Thanks for your questions! Please refer to the list of supported part numbers provided by VIT. Gavin_Jia_0-1785724846969.png Also, the discussion in this thread should be helpful: https://community.nxp.com/t5/MCX-Microcontrollers/Wake-Word-and-Voice-command-engines/m-p/2054222 For more information about MCXN, we recommend that you post your question in the relevant community forum. Thank you! Best regards, Gavin

NFC Cockpit download Hi all! Sorry for stupid question, but where i can download NFC Cockpit  for my CLRC 663? Cant see on software page : Screenshot_474.png

NXP layoffs? Apparently a lot of people were laid off yesterday and more layoffs are coming this week and next. Anyone know anything about this? Power

S32DS ARM 2.2 issue windows 11 安装S32DSARM 2.2安装后提示以下错误  也打开不了默认的 工程 Re: S32DS ARM 2.2 issue Hi@yeSerrui 安装完S32 DS，还需要安装RTM SDK，如下所示 Senlent_1-1785739865237.png 在左侧工程浏览框中，右键new可选择自带的例程 Senlent_0-1785739821338.png