MCUXpresso for VS Code: Combine MCUXpresso or Zephyr projects using AI Introduction This tutorial shows how GitHub Copilot AI, along with the MCUXpresso Combine Projects agent, delivered in the MCUXpresso for VS Code extension, can drive the creation of new projects based on selected examples. MCUXpresso SDK and Zephyr examples from NXP provide a great starting point for learning, but often developers want to combine these examples to rapidly develop prototypes. Instead of manually merging files and resolving build conflicts by hand, an engineer describes the intended combined application in plain language and the agent orchestrates every step.   In this scenario, the engineer asks the agent to accomplish an end-to-end task: Target the FRDM-iMXRT1186 (CM33) board with Zephyr 4.4. Combine the blinky, shell_module, and hello_world examples, all imported fresh from the repository as Freestanding. Add shell commands to turn LED blinking on/off and control the blink rate from the UART console. Clean up the source examples after a successful build. The agent decomposes this request into a sequence of ordered phases – verifying tool availability, selecting and importing examples, enforcing constraints, detecting conflicts, scaffolding a combined project, merging configuration and source, building, and cleaning up. The sections below follow that same order.   The agent supports both Zephyr (prj.conf + devicetree overlays, Zephyr ARM toolchain) and MCUXpresso SDK (SDK components + linker scripts, Arm GNU Toolchain) project types. The scenario shown here uses Zephyr; MCUXpresso SDK projects follow the same flow with the appropriate SDK repository and toolchain.   The agent only performs actions through the extension's own tools, so every step it takes maps directly to functionality you could also trigger manually from the MCUXpresso for VS Code UI. For all structured choices – SDK type, board confirmation, appType , conflict resolution, and cleanup options – the agent uses the #askQuestion tool to surface clickable buttons in the chat UI to reduce the need to type a letter or number by hand. System Architecture   MCUXpresso Combine PROJECTS Agent End-to-End Workflow Overview 📄 Source Projects blinky, shell_module, hello_world (imported or in workspace)     Merge 🤖 Combine Agent MCUXpresso Skills Copilot chat agent     Build 📦 Combined Project combined_ _ single built applicatione   Component Description Source Projects Two or more MCUXpresso Zephyr or MCUXpresso SDK projects targeting the same board. May already be in the workspace or imported fresh by the agent using importExampleFromRepo . Combine Agent The MCUXpresso skill files allow the Copilot agent to orchestrate the full workflow: tool verification, example selection and import (Zephyr or MCUXpresso SDK), constraint enforcement, conflict detection,  project scaffolding, configuration application, source merge, build with DTS regression check(Zephyr only), and cleanup. Uses #askQuestion for all structured choices. Combined Project A new project named combined_ _ , scaffolded from a fresh hello_world example for the same board. The agent merges configuration and source so both functionalities run in the combined app. Getting started   The engineer describes the combined application in a single natural-language prompt, and the agent carries out the ordered phases below – starting the agent, selecting examples, enforcing constraints, resolving conflicts, scaffolding, merging, building, and cleaning up. Prerequisites   Before starting you should have: Visual Studio Code with the MCUXpresso for VS Code extension installed and activated, and GitHub Copilot Chat available. The MCUXpresso tool set enabled in Copilot Chat – click Configure Tools in the bottom-left corner of the chat input window and make sure MCUXpresso is toggled on. At least one SDK or Zephyr repository registered in the extension. A Zephyr / Zephyr NXP repository requires a Zephyr ARM toolchain; an MCUXpresso SDK repository requires an Arm GNU Toolchain. A compatible toolchain installed and reachable from the project's MCUXpresso integrated terminal (installed via the MCUXpresso Installer or the extension's toolchain management). Examples do not need to be imported beforehand – the agent can import them for you during the flow.   Step 1 – Start the agent Open Copilot Chat, select the MCUXpresso Combine Projects agent from the agent picker, or type /mcuxpresso-combine-projects in the chat input. The agent immediately verifies that the MCUXpresso extension tools are accessible in this session by calling listProjectsFromWorkspace . Select the Combine Projects agent or run the /mcuxpresso-combine-projects prompt to start the flow. Phase 0 passes and the agent asks for the SDK type.Select the Combine Projects agent or run the /mcuxpresso-combine-projects prompt to start the flow. Phase 0 passes and the agent asks for the SDK type. Select the Combine Projects agent or run the /mcuxpresso-combine-projects prompt to start the flow. Phase 0 passes and the agent asks for the SDK type.   Alternatively, you can include all required details in the opening prompt and the agent will proceed without asking for them one by one: Providing board, SDK version, example names, appType, and cleanup preference in one prompt lets the agent skip the individual selection questions and go straight to board confirmation.   If the tool call succeeds, the agent proceeds to example selection. If it fails – because the MCUXpresso tool set is not enabled – it stops and tells the user how to enable it via Configure Tools.   Throughout the flow the agent uses the #askQuestion tool to present structured choices (SDK type, board confirmation, appType , conflict resolution, cleanup options) as clickable buttons in the chat UI. You never need to type a letter or number by hand. Plain text is accepted as a fallback when #askQuestion is unavailable.   Constraint: the agent will not advance past this point until the MCUXpresso tools are confirmed available in the current chat session.   Step 2 – Select examples The agent asks for the SDK type (Zephyr or MCUXpresso SDK), then lists the projects currently in the workspace. The engineer chooses which examples to combine – by picking from the workspace list, by naming examples to import fresh, or by mixing both approaches. When more than one matching repository is installed, the agent asks which one to use, then collects the example names and target board.   For any example not yet in the workspace, the agent runs the full import discovery chain: listRepositories → filter to the chosen SDK type → repository selection (if more than one matching repository is found, the agent presents them as a numbered list and asks which one to use for all imports in this session) → listSupportedBoards → explicit board confirmation → listSupportedExamples → user chooses appType → importExampleFromRepo . After each import, listProjectsFromWorkspace is called to confirm the project is registered. If the project files exist on disk but do not appear in the workspace list, the agent automatically falls back to importProject to register the on-disk folder. The agent always asks the user to explicitly confirm the resolved board before listing or importing any examples.   The agent resolves the exact template IDs for each requested example and asks for confirmation before importing.   The agent imports all confirmed source examples into the workspace.   Constraints: the SDK type must be chosen explicitly; appType must be chosen by the user for every import – the agent never assumes a default. The board is always confirmed with the user before any example is listed or imported. The chosen repository is reused consistently for every import in the session, including the hello_world scaffold.   Step 3 – Verify constraints Before any merging begins, the agent enforces three hard constraints across all selected examples: At least two examples must be in the confirmed set. Same SDK type – all examples must use the SDK type chosen in the previous step (Zephyr or MCUXpresso SDK). Same board and core – the BOARD id and variant/core qualifier must be identical across all examples. Different cores of the same SoC do not match.   Constraint: if any gate check fails, the agent stops immediately, reports exactly what is wrong, and waits for the user to correct the problem. It will not fabricate a board match or SDK-type match.   Step 4 – Detect conflicts The agent scans all selected examples for devicetree, Kconfig, and memory-layout conflicts – pin or pinctrl reuse for different functions, chosen nodes pointing at different UARTs, the same CONFIG_* symbol set to incompatible values, and overlapping flash partitions or memory regions.   Non-conflicting settings – distinct peripheral enables, independent Kconfig flags, additional aliases, non-overlapping memory regions – are auto-merged into the combined project without asking. They appear in an Auto-merged summary. The conflict report lists auto-merged settings and presents any true conflicts as numbered options for the user to choose from.   Conflicting settings are presented as a numbered list: option A keeps the value from example X, option B keeps the value from example Y, and option C provides a safe combined value where one genuinely exists. The agent records every decision before continuing.   When no true conflicts are found, the agent says so explicitly, lists the full auto-merged configuration union, and continues straight to scaffolding the combined project without asking for any resolution choices.   Constraint: the agent never resolves a conflict silently – every conflict requires an explicit user choice. Non-conflicting settings are always auto-merged without prompting. Step 5 – Create the combined project The agent imports a fresh hello_world example for the same board – following the same import discovery chain and asking the user for appType – and uses it as the scaffold for the combined application. The default name is combined_ _ ; the user can accept the default or provide a custom name. The agent asks for both the project name and the appType for the scaffold before importing it. The agent confirms the combined project name and appType, then imports the fresh hello_world scaffold as the base for the merge.   The agent then applies the conflict resolutions chosen in the previous phase and auto-includes all non-conflicting configuration from every source example – every peripheral enable, Kconfig flag, alias, and memory region that was listed as auto-merged is added without further prompting.   Constraint: the agent never silently drops a setting a source example needed, and never adds settings that were not present in at least one source example. Step 6 – Merge sources The agent merges the application source from every example into the combined project so both functionalities run. It inventories each example's source files and CMakeLists.txt entries, then: Copies source and header files into the combined project, renaming collisions (e.g. main.c → app_blinky.c ) and prefixing any clashing symbols. Refactors each example's main() into a callable init/run function. Writes a combined main() that runs both workloads – using separate Zephyr threads if either example blocks or loops forever, cooperative calls if both are short. Merges CMakeLists.txt source lists, component dependencies, include directories, and linked libraries, removing duplicates. The merged main.c combines both workloads; prj.conf reflects the union of all required Kconfig settings.   Shared resources – console, GPIO, timers – are reconciled according to the conflict-resolution decisions from the previous phase. Both examples' output is routed to the single chosen console.   Step 7 – Build and verify The agent builds the combined project using the MCUXpresso for VS Code extension build tools ( buildProject / rebuildProject ). It monitors compile and link errors, iterates on fixes, and reports the final FLASH and RAM usage from the build output.   Build restriction: the agent never invokes cmake , ninja , make , or west build directly in a terminal. All builds, cleans, and rebuilds go exclusively through the MCUXpresso extension tools ( #buildProject , #cleanProject , #rebuildProject ). Running build commands in a raw terminal bypasses the extension's environment and toolchain configuration and will produce incorrect results.   After a successful build the agent provides a full summary: what was combined, the conflicts and their resolutions, the new project name and location, and how to flash the firmware to the target board.   Step 8 – Clean up Once the build succeeds, the agent asks what to do with the source examples used for combining. It never touches the combined project itself: A. Keep all source examples in the workspace. B. Remove all source examples from the workspace (with a separate confirmation for disk deletion). C. Choose per example – the agent asks about each one individually. The agent offers three cleanup options for the source examples and asks for explicit confirmation before any disk deletion.   For any removal the agent calls removeProject , asks a follow-up question confirming whether the files should also be deleted from disk, and then re-checks the workspace list to confirm the cleanup is complete.   Constraint: the agent never deletes files from disk without explicit user confirmation. The combined project is never offered for removal. Verifying the Result   The workflow is successful when all of the following hold: The verification gate passed: at least two examples, all sharing the same SDK type and the same board and core. All conflicts were resolved by explicit user choice; all non-conflicting settings were auto-merged. The combined project (e.g. combined_blinky_shell_module_hello_world ) appears in the workspace (confirm with listProjectsFromWorkspace ). The build completed without errors and produced a firmware artifact. The build summary reports the expected FLASH and RAM usage for both combined workloads. Source examples were handled per your chosen cleanup option Troubleshooting   Most issues fall into one of the categories below.   Symptom Likely cause Suggested action MCUXpresso tools not available The MCUXpresso tool set is not enabled in Copilot Chat Click Configure Tools in the bottom-left corner of the chat input, enable the MCUXpresso tool set, then restart the conversation. Verification gate fails – board mismatch Selected examples target different boards or core variants Re-import the mismatched example targeting the correct board, or replace it with a compatible one. Import did not register in workspace importExampleFromRepo succeeded but the project is not listed by listProjectsFromWorkspace The agent automatically falls back to importProject to register the on-disk folder. If this also fails, manually add the project folder via the MCUXpresso Projects view. Configure fails after import Board revision in CMakePresets.json uses the wrong case (e.g. @b instead of @B ) The agent detects and corrects the board revision in CMakePresets.json , cleans the build directory, and re-runs configure and build automatically. Build fails with stale CMake cache A previous failed configure left a partial build directory The agent cleans the build/ directory and re-runs configure before rebuilding. You can also delete the build/ folder manually and run configure again from the MCUXpresso terminal.   Examples

MCUXpresso for VS Code: Create, Build, and Debug a new Project using AI     A step-by-step walkthrough of how to use Copilot chat to import a multi-task FreeRTOS example for the LPCXpresso55S69, building it, debugging it, and analyzing memory usage – all driven from a single natural-language prompt. Introduction This tutorial shows how GitHub Copilot AI, along with the MCUXpresso for VS Code extension, can drive a complete FreeRTOS workflow from natural-language prompts: importing an SDK example, building it, debugging it, and analyzing the resulting artifact.   Instead of clicking through views, wizards, and commands, an embedded software engineer describes the intended outcome in plain language and the agent orchestrates the extension's language model tools to carry out each step.   In this scenario, the engineer asks the MCUXpresso agent to accomplish an end-to-end task: Get started quickly with a FreeRTOS example from MCUXpresso SDK. Target the LPCXpresso55S69 board. Import the new project as a freestanding example into the VS Code workspace, then build it. Freestanding will prompt for a folder to save the project. Start debugging and automatically resume execution after 10 seconds. Analyze the build artifact to see how much memory is used. Open the linker file used to build the artifact. The MCUXpresso agent decomposes this request into a sequence of tool calls – discovering boards and SDK revisions, listing suitable examples, importing the chosen example, building all configurations, launching and resuming the debug session, opening the Image Info view, and finally opening the linker script. The sections below follow that same order. The MCUXpresso agent leverages skill files that outline how to perform actions through the extension's own tools, so the steps it takes maps directly to functionality you could also trigger manually from the MCUXpresso for VS Code UI. System Architecture FreeRTOS Multi-Task Example — LPCXpresso55S69 System Architecture Overview Hardware 💻 Host PC MCUXpresso for VS Code MCUXpresso Agent/Skills     USB 🔗 Debug Probe On-board LinkServer CMSIS-DAP     SWD TARGET 📟 LPCXpresso55S69 Runs FreeRTOS example   Component Description Host PC Runs VS Code with the MCUXpresso for VS Code extension and the Copilot AI agent and skills. The agent properly imports the SDK example, builds it, launches the debug session, and opens the Image Info and linker views. Debug Probe The on-board LinkServer / CMSIS-DAP debug probe on the LPCXpresso55S69. Bridges USB from the Host PC to the SWD debug interface of the target MCU, and hosts the GDB server used during debugging. LPCXpresso55S69 Target evaluation board (LPC55S69 dual-core Arm Cortex-M33). Runs the FreeRTOS example with multiple tasks. Getting started The engineer describes the whole goal to the MCUXpresso agent in a single natural-language prompt, and the agent carries out each step below in order. Prerequisites This tutorial assumes the environment has already been prepared with the MCUXpresso Installer, which was previously used to install all required dependencies. Before starting you should have: Visual Studio Code with the MCUXpresso for VS Code extension installed and activated, and GitHub Copilot Chat available. All toolchain and tooling dependencies installed via the MCUXpresso Installer: the Arm GNU toolchain, LinkServer debug probe support, CMake and Ninja, and the west / SDK management tooling. MCUXpresso SDK v26.06 installed via the extension. One LPCXpresso55S69 board connected to the Host PC over USB (using the on-board LinkServer / CMSIS-DAP debug probe). If any dependency is missing, the MCUXpresso agent can open the MCUXpresso Installer for you (see Troubleshooting).   Step 1 – Import a FreeRTOS example The engineer opens Copilot Chat and describes the whole goal to in a single prompt – the board, the preferred kind of example (FreeRTOS, multiple tasks), the SDK version, and the follow-up actions. The engineer states the complete goal in natural language.   To satisfy the request, the agent first establishes the context and locates a suitable example using the extension's discovery tools: mcuxpresso_listSupportedBoards – confirms the LPCXpresso55S69 is a supported board. mcuxpresso_listRemoteRevisions – selects the requested MCUXpresso SDK v26.06 revision. mcuxpresso_listSupportedExamples – finds a FreeRTOS example with multiple tasks (for example a freertos_generic example). mcuxpresso_browseFolder – lets the engineer pick the destination folder for the imported example. Choosing where the example will be imported.   The agent confirms the example selection before importing.   The example is fetched and imported into the workspace.   Step 2 – Build the project Once the example is imported, the agent builds it using mcuxpresso_buildProjectAllConfigs , which compiles all configured build configurations for the project. The agent triggers a build of all configurations.   After a successful build, the imported project is visible in the extension's Projects view, ready for debugging and further analysis. The built project appears in the Projects view.   Step 3 – Debug the project The agent starts a debug session with mcuxpresso_startDebug . This launches the GDB server against the LPCXpresso55S69 through the on-board LinkServer / CMSIS-DAP debug probe, flashes the artifact, and halts at the program entry.   Because the engineer asked to automatically resume execution after 10 seconds, the agent then calls mcuxpresso_continueDebug to resume the program, letting the FreeRTOS tasks run on the target. The debug session starts, then execution is resumed automatically. The complementary tool mcuxpresso_pauseDebug can halt the running program again if you want to inspect state after resuming.   Step 4 – Open Image Info To analyze how much memory the firmware uses, the agent opens the Image Info view with mcuxpresso_openImageInfo . This inspects the build artifact and reports the memory footprint – the sizes of the code and data regions and how they map onto the device's flash and RAM. Image Info reports the artifact's memory usage; the linker script is opened alongside it.   Step 5 – Open the Linker Script Finally, the agent opens the linker file used to build the artifact with mcuxpresso_openLinkerScript . The linker script defines the memory regions and section placement referenced by the Image Info analysis, so the engineer can correlate the reported memory usage with the actual linker configuration (shown in the same screenshot above). Verifying the Result  The workflow is successful when all of the following hold: The FreeRTOS example was imported and appears in the Projects view (you can also confirm with mcuxpresso_listProjectsFromWorkspace ). The build completed without errors and produced a build artifact. The debug session started and execution was resumed after the requested delay. The Image Info view shows the artifact's memory usage. The linker script used for the build is open in the editor. Videos The following videos capture the steps for creating and debugging a project using AI in the MCUXpresso for VS Code extension. 1. Create and import a freestanding SDK project for your NXP board using Copilot in VS Code. (function() { var wrapper = document.getElementById('lia-vid-6405639429112w960h540r214'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) 2. Build, debug, and analyze memory usage for a FreeRTOS Hello World project with Copilot. (function() { var wrapper = document.getElementById('lia-vid-6405639049112w960h540r139'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) Troubleshooting Most issues in this workflow come from missing or incomplete dependencies. In almost all cases the fix is to (re)run the MCUXpresso Installer – the MCUXpresso agent can open it for you with mcuxpresso_openInstaller .   Symptom Likely cause Suggested action Project was not imported A west tooling issue (missing or misconfigured SDK management tooling) Start the MCUXpresso Installer ( mcuxpresso_openInstaller ) and (re)install the SDK / west dependencies, then retry the import. Build error A west issue, or no Arm GNU toolchain installed Start the Installer to install or repair the Arm GNU toolchain and build tooling, then rebuild. No debug probe support LinkServer / debug probe support is not installed Start the Installer and install LinkServer / debug probe support, then reconnect the board. Debug session does not start GDB server failed to launch, or probe/toolchain support is missing Inspect the GDB server terminal output for errors. If probe or toolchain support is missing, start the Installer to install it, then start debugging again. Examples

Getting Started: MCUXpresso for VS Code Installation & Setup for AI Introduction This Getting Started guide explains how to configure MCUXpresso for VS Code so GitHub Copilot agents can use available AI skills and MCP servers effectively when developing with MCUXpresso software and tools. If you already have MCUXpresso for VS Code installed, you can skip to Step 2 to enable Agentic AI features.  Note: The AI support in the MCUXpresso for VS Code extension is currently an experimental option. Users must enable the support after the extension is installed. Install the Tools The MCUXpresso Installer installs everything you need from a single application. Work through the prerequisites and the two steps below to reach a system that is ready to evaluate the NXP Agentic AI features with GitHub Copilot in VS Code. Prerequisites   Prerequisite Version Link MCUXpresso Installer 26.09+ Download   Note: The MCUXpresso Installer will install ALL software required – VS Code, the extension, and other software dependencies. Follow the instructions below and a single step will establish the base setup.   Step 1 – Install MCUXpresso for VS Code Installer options Enter Administrator mode. On Windows, you may need to run the installer as an administrator to avoid permission-related installation issues. Download and install the MCUXpresso Installer utility.  Launch MCUXpresso Installer from your desktop. Select the following components to install: MCUXpresso SDK Developer Arm GNU Toolchain Standalone Toolchain Add-ons LinkServer MCUXpresso Configuration Tools Note: All other components in the Installer are not required for initial development but can be added later based on other use cases. Click the Install button. Note: The Show details button will expand the selected kits to reveal other items installed as dependencies.   A green check mark will appear next to each item once installation has successfully completed. Step 2 – Enable Experimental AI in MCUXpresso for VS Code Open VS Code Settings Open Settings for the MCUXpresso for VS Code extension to enable the experimental features that support Agentic AI development: Launch VS Code. Open Settings with the shortcut Ctrl + , (Ctrl and comma). Filter by typing mcupresso experimental copilot . Click the box to enable the MCUXpresso Agentic AI resources. Close and relaunch VS Code to finish Agentic AI setup. Done: Your system is now ready to begin evaluating the NXP Agentic AI features using GitHub Copilot in VS Code.   Step 3 – Set up GitHub Copilot AI in VS Code AI features in VS Code require the user to log in to a valid GitHub account. You can use a personal account and receive a Free license, or use a corporate account that may provide Business-level Copilot access.   Display the GitHub Copilot Chat pane. Click on the Right Pane icon in the upper-right corner. Click on the GitHub Copilot icon in the lower-right corner. Log in to a valid GitHub account and authorize VS Code to link with the account. Done: The GitHub Copilot AI features are now active in the Chat pane. Videos The following videos help cover the Getting Started process with GitHub Copilot in VS Code:  1. Connect a GitHub account to Copilot in VS Code and verify it with a simple AI prompt. (function() { var wrapper = document.getElementById('lia-vid-6405641613112w960h540r180'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) 2. Use Copilot Chat agents, models, context, dictation, history, targets, and permissions in VS Code (function() { var wrapper = document.getElementById('lia-vid-6405640756112w960h540r272'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) 3. Configure Copilot tools, skills, workspace access, models, and privacy settings in VS Code. (function() { var wrapper = document.getElementById('lia-vid-6405642238112w990h540r360'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) Getting Started

NXP Model-Based Design Toolbox : From Simulink to NXP Hardware in 5 Prompts using AI This video is currently being processed. Please try again in a few minutes. (view in My Videos) Introduction What if you could go from an idea to a running application on an NXP target using just a few prompts? In this tutorial, an AI agent takes a button-controlled RGB LED application from hardware understanding to a validated Simulink and Stateflow model, then to code generation and deployment on the FRDM-A-S32K312 using Model-Based Design Toolbox (MBDT). The workflow continues into generated-code debugging with S32 Design Studio and finishes by adapting the same application to a hardware change, without redesigning the application logic. The application logic is simple: every valid button press advances through Red > Green > Blue. The selected color remains active for one second, turns off, and the application waits for the next button press. Estimated time: ~60 minutes. System Architecture FRDM-A-S32K312 – Target board used throughout the tutorial for the button-controlled RGB LED application. Prerequisites What you need before starting MATLAB, Simulink, and Stateflow – MATLAB product page MATLAB Agentic Toolkit – MATLAB Agentic Toolkit Simulink Agentic Toolkit – Simulink Agentic Toolkit NXP Model-Based Design Toolbox (MBDT) – MBDT product page MBDT AI Support – GitHub repository S32 Design Studio IDE – S32 Design Studio IDE product page S32 Design Studio AI Support – GitHub repository One FRDM-A-S32K312 evaluation board and a USB cable – FRDM-A-S32K312 board page Important: The initial on-board GPIO assignments and active levels are intentionally discovered from the board documentation in Step 2. Those results become the source of truth for later modeling and target configuration. Steps Run the prompts in sequence. Each stage reuses the model, hardware facts, or configuration produced by the previous stage. Step 0 - Set up the project location Before the first development prompt, the project workspace is already established so the AI agent has a defined location for the files and artifacts used throughout the workflow. Set MATLAB workspace to C:/helloworld. Set the AI agent working directory for this project to C:/helloworld. Use this folder to store and create all additional dependencies for this project. Step 1 - Discover the hardware Before building the model, establish the board-level details: GPIO assignment, pins direction, active level, and the exact logical values required for button detection and LED control. The first engineering task is to understand the hardware. The board schematic is provided to the AI agent so it can identify the RGB LED pins and user-button connections together with the logic values required to control and read them. I want to build a simple demo on the FRDM-A-S32K312 board using the onboard button and RGB LED. Each button press should advance through a color sequence. The first press turns the RGB LED Red for 1 second, the second press turns it Green for 1 second, the third press turns it Blue for 1 second, and then the sequence repeats. After each 1-second indication, the LED should turn off and wait for the next button press. Please analyze the board documentation and schematics, identify the button and RGB LED connections, determine whether they are active-high or active-low, and tell me exactly what logic values are required to detect a button press and turn each LED color on and off. Also confirm that the board can support this application without any hardware modifications. Summarize the GPIO assignments and signal behavior so they can be reused in the next development steps. AI Agent will do the following: Identify the GPIO assignment for BTN_ADVANCE, RGB_RED, RGB_GREEN, and RGB_BLUE. Determine signal direction and active-high or active-low behavior. Capture explicit logic values for button press/release and LED ON/OFF. Confirm whether the initial application can use the existing board hardware without modification. Step 2 - Build the Stateflow application Using the hardware information discovered in the previous step, the AI agent creates the initial Simulink model and implements the application behavior in Stateflow, organizing the LED-control logic in a clear and structured way. Using the hardware information from the previous step, create a Simulink model called s32k312_rgb_led. Do not set a target yet, use plain Simulink for this step. Build the Simulink application logic in Stateflow. Every BTN_ADVANCE button press should advance through a repeating color sequence. The first press shows Red for 1 second, the second press shows Green for 1 second, the third press shows Blue for 1 second, and the sequence repeats. After each 1-second indication, the LED color turns off and the application waits for the next button press. Organize the model cleanly and generate a Stateflow implementation that is easy to understand and ready for the next stages of the workflow. Step 3 - Simulate, test, and fix the logic With the Simulink model available, the next goal is to validate the Stateflow behavior. A 15-second scenario with seven button presses, including a three-second idle interval, is used to exercise the logic while observing button activity, LED transitions, and internal Stateflow state changes. Using the model created in the previous step, prepare a simulation scenario to validate the application behavior. Configure a 15-second simulation and generate a sequence of 7 button press events distributed over the simulation time. At least one interval in between presses shall be 3 seconds long. Create a comprehensive testcase to identify any possible errors in the Stateflow. Run the simulation, verify that the color sequence behaves as expected, and create suitable visualizations showing the button activity, color transitions, and internal Stateflow state changes. Debug the Stateflow and fix any issues. Summarize the simulation results and highlight any issues found. Validation target: One valid press advances exactly one color, the selected output stays active for one second, all LED outputs then return to OFF, and the sequence continues Red > Green > Blue > Red.   Step 4 - Integrate the FRDM-A-S32K312 target Once the application is validated in simulation, the model is prepared for deployment on the NXP target. The existing Stateflow logic is preserved while the hardware I/O and target-specific configuration are added. The validated Simulink model is then prepared for the real evaluation board. The AI agent configures the S32K3 target, integrates the MCU peripherals, connects the application logic to the physical hardware, generates code, builds the application, and deploys it to the FRDM-A-S32K312. Using the validated s32k312_rgb_led model from the previous step, prepare it for deployment on the FRDM-A-S32K312 board. Configure the hardware board as NXP S32K3xx and then set the board as FRDM-A-S32K312 with the S32 Configuration Tools. Add the required Dio blocks for the signals discovered by the hardware analysis and rename the configured signals to RGB_RED, RGB_GREEN, RGB_BLUE and BTN_ADVANCE. Use the GPIO pin names discovered during the hardware analysis, take into account the logic levels to turn the LEDs on or off and detect the button, and preserve the signal names RGB_RED, RGB_GREEN, RGB_BLUE and BTN_ADVANCE. Connect the hardware I/O blocks to the existing application logic and add a variable that counts the number of valid button presses inside Stateflow. When the hardware integration is complete, verify the model configuration, generate the code, build the application, and deploy it to the target board. Step 5 - Debug the generated application After deployment, the generated code is exported into an S32 Design Studio project. The AI agent opens the project, places a breakpoint after the button press is detected on the Red LED path, prepares the debug session, and the breakpoint is reached when the corresponding button event occurs. Application code is generated and it is currently running on the target. Open the generated code in S32 Design Studio, add a breakpoint in the code right after the line where the application is checking that the button is pressed and the Red LED needs to be turned on, and start the debug session. Once the debug session is started, run the application on the board. Optional Step - Adapt the application to the hardware change The final stage demonstrates how the existing application can be adapted when the hardware changes. The RGB LED is rerouted to PTA0, PTA1, and PTA2, while the original signal names, Stateflow logic, and application behavior are preserved as the hardware configuration is updated. RGB LED pins were rerouted in the hardware. Hardware schematic has been changed and the RGB LED has been added externally to the board on the pins PTA0 - RGB_RED; PTA1 - RGB_GREEN and PTA2 - RGB_BLUE. Back up first the S32 Configuration Tools project associated with the model, then modify the S32 Configuration Tools external project to use the new LED configuration. De-initialize the previous pins for the RGB LED and initialize the new pins. Preserve the application logic and preserve the naming from the previous prompts. Why this matters: the application behavior does not change when the physical RGB routing changes. The target configuration moves the outputs to PTA0, PTA1, and PTA2 while the validated Stateflow logic and signal names remain unchanged. Verifying the Result Final check The project and dependencies are organized under C:\helloworld. The board GPIO assignments, polarity, and required logic values are captured from the hardware-analysis stage. The s32k312_rgb_led application implements the repeating Red > Green > Blue behavior. The 15-second simulation with seven button events validates the Stateflow behavior after any necessary fixes. The model uses the discovered hardware I/O and retains the signal names RGB_RED, RGB_GREEN, RGB_BLUE, and BTN_ADVANCE. A Stateflow variable counts valid button presses. The application is generated, built, and deployed to the target. The generated application is opened in S32 Design Studio for source-level debugging. After the hardware change, the previous RGB pins are de-initialized and PTA0/PTA1/PTA2 are configured while application logic is preserved. Troubleshooting Symptom What to inspect Wrong color or inverted LED behavior Recheck the hardware-analysis result and the discovered active levels used at the hardware interface. One press advances more than once Inspect the button stimulus and Stateflow press-event handling so that one valid press produces one sequence advance. Color does not turn off after one second Inspect Stateflow temporal logic and the output assignments on the transition back to the waiting state. Simulation differs from hardware Compare the deployed Dio mapping and polarity handling with the GPIO facts established during hardware analysis. Breakpoint is not visible in the Breakpoints GUI Document the observed GUI limitation and verify the intended debug location using the generated source and actual debugger behavior. Problems after rerouting the LEDs Verify that the former RGB pins were de-initialized and PTA0, PTA1, and PTA2 were initialized in the updated S32 Configuration Tools project. What This Demo Shows The application is simple, but the workflow captures a larger Model-Based Design pattern: understand the hardware, build an executable application model, validate the behavior before target integration, deploy it to real hardware, inspect generated code when needed, and absorb a late hardware change without rewriting the application logic. From prompt to hardware application using AI Agent: understand the board, model the behavior, validate the application, deploy, debug, and adapt the hardware without rewriting the application. Examples Getting Started

S32 Design Studio: Add UART to the Imported Project using AI Introduction In Tutorial 1, the AI agent imported the GPIO Blinking LED Demo and ran it on the FRDM-A-S32K312 board. This second article extends that project with two new features: a multi-color LED sequence, and a UART output that reports what the board is doing.   Using S32 Configuration Tools, you will map LPUART6 pins (PTA15 / PTA16), configure the peripheral at 115200 baud, regenerate code, and flash the firmware so the board echoes the current LED color over UART to a serial terminal.  Estimated time: ~20 minutes. System Architecture   Add UART to the Imported Project – system architecture overview   The components involved are:   FRDM-A-S32K312 – Target evaluation board. Runs GPIO Blinking LED firmware with LPUART6 enabled on PTA15 (RX) / PTA16 (TX). Transmits the current LED color over UART at 115200 baud. Host PC – Runs S32 Design Studio and the S32 Design Studio AI Support. A serial terminal (e.g. VS Code Serial Monitor) receives and displays the LED colour echo at 115200 / 8N1. Prerequisites   What you need before starting   Tutorial 1 completed — the GPIO Blinking LED Demo for FRDM-A-S32K312 must already be imported and building in S32 Design Studio One FRDM-A-S32K312 evaluation board + USB cable A serial terminal application (e.g. PuTTY, Tera Term, or VS Code Serial Monitor) S32 Design Studio AI Support configured (download, install and configure it following the steps from Installation & Usage Guide)   Note: This tutorial uses these paths: Installation: C:\NXP\2026\K3_kit\S32DS_3.6.8 Workspace: C:\NXP\2026\K3_kit\workspace_S32DS_3.6.8_K3_kit You can use any location. If you do, update the paths in the prompt to match. Connect the FRDM-A-S32K312 board to the PC via USB. Open Device Manager → Ports and note the virtual COM port number – you will need it for the serial terminal. Steps   Send the following prompts to your AI assistant in order. Each prompt is a complete, self-contained instruction.   Step 1 – Add RGB LED cycling (red → green → blue) In S32DS, use the dm-gpio-blinky-s32k312 project on a S32K312 FRDM board. Add pins PTA30 and PTA31 in the Pins tool (green and blue of the on-board RGB LED; red is the existing PTA29). In the existing blink cycle where the red LED is toggled, replace it with a switch-case that lights one color at a time, cycling red -> green -> blue, ~500 ms each. Important: these RGB LEDs are active-low. Confirm the polarity from the board schematic/user guide before writing GPIO values. Map: red=PTA29, green=PTA30, blue=PTA31. Then generate code and build (report any errors) and flash/run it. Use the s32ds-agentic-ai MCP server for all IDE/config/flash actions; if the MCP server disconnects at any point, stop immediately and notify me. AI will:   Open Pins Tool and add PTA30 (green) and PTA31 (blue) alongside existing PTA29 (red) Replace the existing blink loop with a switch-case cycling red → green → blue, ~500 ms each Respect active-low polarity, confirmed from board schematic/user guide Click Generate Code, build and report any errors Flash and run the firmware on the FRDM-A-S32K312 board Stop and notify the user immediately if the s32ds-agentic-ai server disconnects   Step 2 – Add UART functionality to echo the LED colour Add UART functionality to echo the color of the LED (RED, GREEN, BLUE) but keep it lightweight by using the LPUART IP-layer: - In Pins tool: map the PTA15 as LPUART6_RX and PTA16 as LPUART6_TX pins - In Peripherals tool: set LPUART_6 channel configured for baudrate 115200 / 8 data bits / no parity / 1 stop bit Then generate code and build (report any errors) and flash/run it. Use the s32ds-agentic-ai MCP server; if the MCP server disconnects at any point, stop immediately and notify me. AI will:   Open Pins Tool and map PTA15 → LPUART6_RX and PTA16 → LPUART6_TX Open Peripherals Tool and configure LPUART6: 115200 baud / 8 data bits / no parity / 1 stop bit Click Generate Code, build and report any errors Flash and run the firmware on the FRDM-A-S32K312 board Stop and notify the user immediately if the s32ds-agentic-ai server disconnects Verifying the Result   Work through this final check to confirm that both prompts completed successfully.   Final check Build completes with zero errors. Firmware is flashed and running on the FRDM-A-S32K312 board (RGB LED is blinking). Open a serial terminal at 115200 baud / 8N1 on the board's COM port. Confirm messages such as LED: RED, LED: GREEN, LED: BLUE appear in sync with the physical LED colour changes. Troubleshooting   Symptom Fix No UART output in serial terminal Open Pins Tool. Confirm PTA15 → LPUART6_RX and PTA16 → LPUART6_TX are routed. Regenerate code after any change. LPUART6 not found or not initialised Open Peripherals Tool. Verify LPUART6 is enabled and configured: 115200 baud / 8 data bits / no parity / 1 stop bit. Regenerate code if you make changes. LPUART6 absent at runtime Open Peripherals Tool › McuPartition. Enable LPUART6 in the partition configuration, then regenerate and rebuild. Garbled characters in serial terminal Baud rate mismatch. Confirm the terminal is set to 115200 and the peripheral configuration matches. Regenerate code after any baud rate change. Build errors after Generate Code Check that the generated LPUART6_init() call is present in main.c and that the correct header is included. Re-run Generate Code if source files are missing. LED colour not echoed over UART Confirm the UART transmit call is placed after each LED colour change in the main loop. Verify LPUART6_init() is called before the loop starts. Wrong COM port in serial terminal Open Device Manager → Ports and identify the virtual COM port assigned to the FRDM-A-S32K312 board. Use that port number in your terminal application. s32ds-agentic-ai server disconnects during operation Stop immediately and restart the MCP server following the setup instructions. Do not continue until the server is confirmed connected. File Reference   File Step Description src/main.c 2 Main firmware file — contains LED loop and LPUART6 transmit calls generate/src/Lpuart_Uart_Ip_PBcfg.c 1 Generated LPUART6 peripheral configuration generate/include/Lpuart_Uart_Ip_Cfg.h 1 Generated LPUART6 configuration header *.mex 1 S32 Configuration Tools project file (Pins, Clocks, Peripherals)   Map the pins, configure LPUART6 and regenerate – your board now reports every LED colour change over UART in about 20 minutes. Examples

S32 Design Studio: Add FreeMASTER Lite Configuration to Existing UART Project using AI Introduction In Tutorial 2, the application was extended to cycle the FRDM-A-S32K312 board's RGB LED through red, green, and blue, while sending corresponding status messages to a serial terminal. This third article shows how to add a FreeMASTER Lite server configuration using S32 Design Studio AI Support to an existing UART project on the FRDM-A-S32K312 board and create a browser dashboard that displays the current LED color – replacing the plain UART color echo.   Estimated time: ~20 minutes. System Architecture Add FreeMASTER to existing UART project – system architecture overview   The components involved are:   FRDM-A-S32K312 – Target evaluation board. Runs the existing UART project extended with FreeMASTER TSA, streaming the LED colour variable to the host over USB at 115200 baud. Host PC – Runs FreeMASTER Lite (fmlite.exe) on the board's COM port, 115200 baud, port 8090. Serves the LED colour dashboard to the browser. Prerequisites   What you need before starting   Tutorial 2 completed — the GPIO Blinking LED Demo with UART must already be imported and building in S32 Design Studio One FRDM-A-S32K312 evaluation board + USB cable Download and install FreeMASTER Lite (fmlite.exe) from LINK  Any modern browser (Chrome / Edge / Firefox) S32 Design Studio AI Support configured in your agent (download, install and configure it following the instruction from Installation & Usage Guide)    Note: This tutorial uses these paths: S32 Design Studio Installation: C:\NXP\2026\K3_kit\S32DS_3.6.8 Workspace: C:\NXP\2026\K3_kit\workspace_S32DS_3.6.8_K3_kit FreeMASTER Installation: C:\NXP\2026\K3_kit\FM_32 You can use any location. If you do, update the paths in the prompt to match. Connect the FRDM-A-S32K312 board to the PC via USB, open Device Manager → Ports (COM & LPT) and note the virtual COM port number. You must know this port before sending the prompt below — replace every COM# in the prompt with your own port (for example COM7), otherwise FreeMASTER Lite cannot open the serial connection to the board. Steps   Send the following prompt to your AI assistant. It is a complete, self-contained instruction. Replace COM# with the COM port of your board before sending.   Step 1 – Create FreeMaster Lite dashboard and server configuration Using FreeMaster Lite create a self contained web dashboard and the server configuration file in the project folder called dashboard. FreeMaster Lite is installed at c:\NXP\2026\K3_kit\FM_32\FreeMASTER Lite\fmlite.exe The dashboard should have a volatile variable that will be used to reflect the color of the RGB LED At the top should have the controls for the board serial connection, default: connection name "S32K312 RGB Board", COM#, 115200 baud, 8 data bits, no parity, 1 stop bit The board is connected on COM# - use this serial port for the FreeMaster Lite connection The project is a plain GPIO demo with no FreeMASTER driver - add whatever is needed on the target side so it can talk to FreeMaster Lite, then build and flash it in S32DS and confirm the color actually changes from the dashboard. Start FreeMaster server and run the dashboard at the end Use the s32ds-agentic-ai MCP server; if the MCP server disconnects at any point, stop immediately and notify user. AI will:   Create a self-contained web dashboard in the dashboard project folder Create a FreeMASTER Lite server configuration file in the same folder Add a volatile variable to reflect the RGB LED colour in the dashboard Add serial connection controls at the top (name: S32K312 RGB Board, COM#, 115200 baud, 8N1) Start the FreeMASTER Lite server and open the dashboard in the browser Stop and notify the user immediately if the s32ds-agentic-ai server disconnects Verifying the Result   Work through this final check to confirm that the prompt completed successfully.   Final check FreeMASTER Lite server is running with no errors. Open http://localhost:8090 in your browser. The LED colour dashboard loads and shows the current LED colour within ~5 seconds. The displayed colour changes in sync with the physical LED on the board. Troubleshooting   Symptom Fix ReadTSA returns count=0 TSA not enabled (FMSTR_USE_TSA 1) or FMSTR_Poll() missing. StartComm times out Wrong COM port in .fmcfg, baud mismatch, or board not powered. fmlite.exe exits immediately Activation code not entered, or path has spaces — wrap in quotes. LPUART0 baud rate wrong or peripheral not running Open Peripherals Tool. Verify LPUART0 is enabled and its clock source is set to AIPS_PLAT_CLK. Regenerate code if you change anything. LPUART0 absent at runtime Open Peripherals Tool › McuPartition. Enable LPUART0 in the partition configuration, then regenerate. FreeMASTER host times out or drops connection FMSTR_Poll() must be called frequently — place it in the main loop or a fast periodic task. The host requires low-latency responses. LPUART6 interrupts conflict with FreeMASTER Open Peripherals Tool (Platform). Disable LPUART6 interrupts — FreeMASTER operates in polling mode and does not use interrupt-driven UART. File Reference     File Step Description dashboard/led_color.html 1 LED colour dashboard dashboard/board_115200.fmcfg 1 FreeMASTER Lite server configuration src/main.c 1 Firmware with FreeMASTER TSA and LED colour variable   Add the FreeMASTER Lite configuration and dashboard – watch your board's LED colour live in the browser in about 20 minutes. Examples

S32 Design Studio: Import, Build, and Monitor a Motor Control Project using AI Introduction This tutorial demonstrates an end-to-end, AI-assisted motor control workflow using S32 Design Studio AI Support. You'll find a motor control application for the FRDM-A-S32K312 on the NXP Application Code Hub, import it into S32 Design Studio, generate code, build and flash the project, and then create a FreeMASTER dashboard with motor controls, speed selection, and live parameter monitoring. The tutorial uses the NXP PMSM Low Voltage Motor Control Accessory Kit as the motor hardware.   Everything is done through two prompts – jump straight to the steps if you already have the tools installed.   Estimated time: ~35 minutes. System Architecture S32K312 Motor Control + FreeMASTER – system architecture overview   The components involved are:   Motor – NXP PMSM Low Voltage Motor Control Accessory Kit is connected to the FRDM-A-S32K312 board. The Motor is driven by PWM output from the MCU. FRDM-A-S32K312 – Runs motor control firmware with FreeMASTER TSA enabled. Streams live data to the host PC over USB (UART). Host PC – Runs FreeMASTER Lite (fmlite.exe) on COM#, 115200 baud, port 51234. Serves the HTML5 dashboard to the browser. Prerequisites   What you need before starting   Download the FRDM Automotive S32K3 + S32M27 Board Installation Package from the Automotive Package Manager – LINK Install S32 Design Studio (version 3.6.5 or newer) from the above bundle along with the S32K3 SDK  Install the S32 Design Studio MCP REST Server (bundled with S32 Design Studio 3.6.11+ or available for installation via Extensions and Updates in older versions starting with 3.6.5) Install the AMMCLIB for S32K3xx/S32M27x (Automotive Math and Motor Control Library) using S32DS Extensions and Updates required by the motor control demo Install the NXP GCC for Arm Embedded Processors v10.2 toolchain using S32DS Extensions and Updates — this is the toolchain used to build the motor control example Install FreeMASTER Lite into your working directory – download from LINK One FRDM-A-S32K312 evaluation board + USB cable One NXP PMSM Low Voltage Motor Control Accessory Kit (motor and driver hardware for the FRDM-A-S32K312) Connect the board to the PC via USB and find out which COM port it was assigned — open Device Manager → Ports (COM & LPT) and note the port of the board's USB-serial interface (it can be any COMx ). You will hand this value to the AI agent, which uses it for the FreeMASTER Lite serial connection Any modern browser (Chrome / Edge / Firefox) Download, install and configure your agent to use the S32 Design Studio AI Support following the Installation & Usage Guide   Note: This tutorial uses these paths: S32 Design Studio Installation: C:\NXP\2026\K3_kit\S32DS_3.6.8 Workspace: C:\NXP\2026\K3_kit\workspace_S32DS_3.6.8_K3_kit FreeMASTER Installation: C:\NXP\2026\K3_kit\FM_32 You can use any location. If you do, update the paths in the prompt to match. Connect the FRDM-A-S32K312 board to the PC via USB before starting, then tell the agent the COM port of the board — for example: "the board is connected on COM7, use it for FreeMASTER Lite". Everywhere this tutorial shows COMx , replace it with your own port number. The AI will search the Application Code Hub and select the most suitable motor control demo automatically. Steps   Send the following prompts to your AI assistant in order. Each is a complete, self-contained instruction.   Step 1 – Import motor control demo, build and run You are a software developer that needs to use S32K312 FRDM board to control a motor. I have the NXP PMSM Low Voltage Motor Control Accessory Kit available for my application. Check NXP Application Code Hub for an application that can be used and import the selected application into S32 Design Studio IDE. S32DS is installed at C:\NXP\2026\K3_kit\S32DS_3.6.8. Run S32 Configuration Tools to generate code, build it, load into the flash memory and run the project. Use the s32ds-agentic-ai MCP server; if the MCP server disconnects at any point, stop immediately and notify user. AI will:   Search NXP Application Code Hub for a motor control application suitable for the FRDM-A-S32K312 and compatible with the NXP PMSM Low Voltage Motor Control Accessory Kit Import the selected project into S32 Design Studio at C:\NXP\2026\K3_kit\S32DS_3.6.8 Open S32 Configuration Tools and click Generate Code (Pins, Clocks, Peripherals) Build the project and confirm zero errors Flash the .elf binary into the board's flash memory and run the project Stop and notify the user immediately if the s32ds-agentic-ai MCP server disconnects   Step 2 – Create FreeMASTER dashboard and run it Using FreeMaster Lite create a self contained web dashboard and the server configuration file in the project folder called dashboard. FreeMaster Lite is installed at c:\NXP\2026\K3_kit\FM_32\FreeMASTER Lite\fmlite.exe The dashboard should define and connect all the variables for the 4 panels and contained components: - top panel: contains the controls for the board serial connection, default: connection name "S32K312 Board", COM#, 115200 baud, 8 data bits, no parity, 1 stop bit - left panel: contains the motor control panel: motor state (on/off), actual RPM and desired RPM, slider for selecting the RPMs in both directions, a 0 RPM button, and +- 10/100 RPMs buttons - middle panel: contains a graphical representation of the motor, spinning the NXP logo in sync with the motor actual speed - right panel: contains all the board\motor parameters that you can find relevant Start FreeMaster server and run the dashboard at the end Once the JS client confirms that the board is connected it should start reading desired and actual RPMs Use the s32ds-agentic-ai MCP server; if the MCP server disconnects at any point, stop immediately and notify user. AI will:   Create a FreeMASTER configuration file in the project subfolder dashboard/: COM#, 115200 baud, 8 data bits, no parity, 1 stop bit, connection name "S32K312 Board" Generate a self-contained HTML5 dashboard saved to the project subfolder dashboard/ with all FreeMASTER variables defined, organised in four panels Once the JS client confirms the board is connected, automatically start reading desired and actual RPMs Start the FreeMASTER server and open the dashboard in the browser Stop and notify the user immediately if the s32ds-agentic-ai MCP server disconnects   Verifying the Result   Work through this final check to confirm that both prompts completed successfully.   Final check Motor control project imported and visible in S32DS Project Explorer. S32 Configuration Tools ran – code generated with no errors. Build completes with zero errors. Firmware flashed and running – motor responds as expected. PMSM kit connected and motor responds to commands from the dashboard. FreeMASTER configuration file created in dashboard/: COM#, 115200 baud, 8 data bits, no parity, 1 stop bit, connection name "S32K312 Board". FreeMASTER server is running. Dashboard opens in browser – all four panels visible. Once connected, the dashboard automatically starts reading desired and actual RPMs. Left panel shows motor on/off state, actual and desired RPM, slider for both directions, 0 RPM button, and ±10/100 RPM buttons. Middle panel shows the NXP logo spinning in sync with the actual motor speed. Right panel shows all relevant board/motor parameters updating in real time. Troubleshooting   Symptom Fix No motor control demo found on ACH Try broader search terms such as "motor", "PWM", or "BLDC". Confirm the s32ds-agentic-ai server is connected. Import fails or project missing from Project Explorer Try File › Import › Existing Projects into Workspace manually. Confirm S32DS path is C:\NXP\2026\K3_kit\S32DS_3.6.8. S32 Configuration Tools does not open Double-click the .mex file. Ensure the S32K3 SDK is installed and the project SDK is correctly configured. Generate Code produces errors Check Pins, Clocks, and Peripherals tabs for red validation markers. Resolve conflicts before regenerating. Build errors after Generate Code Ensure the generated src/ folder is in the build path. Try Project › Clean then rebuild. Motor does not respond after flashing Check hardware connections between board and motor driver. Verify correct PWM output pins per the demo schematic. FreeMASTER dashboard does not connect Confirm the FreeMASTER server is running and COM# / 115200 baud / port 51234 match the configuration file. Check that the board is powered and running. Dashboard does not auto-read RPMs after connect Check the JS connect callback in the dashboard HTML. Ensure the ReadVariable calls for desired and actual RPM are triggered after the WebSocket StartComm response confirms success. Actual/desired RPM shows 0 or stale Verify the variable names match those in the FreeMASTER project. Check that FMSTR_Poll() is called in the main loop and TSA is enabled. Right panel parameters not updating Verify FreeMASTER TSA is enabled (FMSTR_USE_TSA 1) and FMSTR_Poll() is called in the main loop. s32ds-agentic-ai MCP server disconnects Stop immediately and restart the MCP server following the Installation & Usage Guide. File Reference   File Step Description src/main.c 1 Main firmware – motor control loop with FreeMASTER TSA *.mex 1 S32 Configuration Tools project file (Pins, Clocks, Peripherals) generate/src/ 1 Auto-generated peripheral initialisation source files generate/include/ 1 Auto-generated peripheral configuration headers dashboard/board_115200.fmcfg 2 FreeMASTER server configuration: COM#, 115200 baud, 8 data bits, no parity, 1 stop bit, "S32K312 Board" dashboard/motor_dashboard.html 2 Self-contained HTML5 dashboard with all FreeMASTER variables, 4 panels (top: serial connection; left: motor control with slider, 0 RPM button, ±10/100 RPM buttons; middle: NXP logo spinning in sync with actual speed; right: board/motor parameters), auto-read on connect   Import the demo, build it and let your AI assistant generate the FreeMASTER dashboard – a complete motor control setup in about 35 minutes. Examples

S32 Design Studio: Import and Build an Application Code Hub Project using AI Introduction This tutorial shows how an AI agent, together with S32 Design Studio AI Support, can run a complete S32 Design Studio workflow from one natural-language prompt. The workflow covers importing an NXP Application Code Hub example, generating configuration code, building the project, and running it on hardware. Instead of clicking through wizards, configuration views, and debug settings, you describe the result you want in plain language. The agent then uses S32 Design Studio AI Support's MCP tools to carry out each step. In this scenario, you ask the agent to complete an end-to-end task: Start S32 Design Studio with a dedicated workspace. Import the GPIO Blinking LED Demo from the NXP Application Code Hub. Target the FRDM-A-S32K312 board. Generate code for Pins, Clocks, and Peripherals using S32 Configuration Tools. Build the project with zero errors. Flash and run the firmware on the connected board. The agent breaks this request into a sequence of tool calls. It starts the IDE, searches the Application Code Hub, imports the demo, runs code generation, builds the project, and flashes the board.  Estimated time: ~20 minutes. System Architecture GPIO Blinking LED Demo — FRDM-A-S32K312 – system architecture overview   The components involved are:   FRDM-A-S32K312 – Target evaluation board. Runs the GPIO Blinking LED Demo firmware. Host PC – Runs S32 Design Studio and the S32 Design Studio AI Support. Imports the project, generates code, builds, and flashes the firmware over USB. Prerequisites   What you need before starting Download the FRDM Automotive S32K3 + S32M27 Board Installation Package from the Automotive Package Manager – LINK Install S32 Design Studio (version 3.6.5 or newer) from the above bundle into working directory along with the S32K3 SDK  Install the S32 Design Studio MCP REST Server (bundled with S32 Design Studio 3.6.11+ or available for installation via Extensions and Updates in older versions starting with 3.6.5) One FRDM-A-S32K312 evaluation board + USB cable Download, install and configure your agent to use the S32 Design Studio AI Support from Installation & Usage Guide  Note: This tutorial uses these paths: Installation: C:\NXP\2026\K3_kit\S32DS_3.6.8 Workspace: C:\NXP\2026\K3_kit\workspace_S32DS_3.6.8_K3_kit You can use any location. If you do, update the paths in the prompt to match. Connect the FRDM-A-S32K312 board to the PC via USB before starting. The AI will detect the board automatically through the MCP server. Steps   Send the following prompt to your AI assistant. It is a complete, self-contained instruction that drives the demo.   Step 1 – Import GPIO Blinking LED Demo & build You are a software developer that needs to use S32K312 FRDM board, start S32DS that is installed at C:\NXP\2026\K3_kit\S32DS_3.6.8, import the GPIO Blinking LED Demo for FRDM-A-S32K312 from the NXP Application Code Hub into S32 Design Studio IDE. After importing, run S32 Configuration Tools to generate code (Pins, Clocks, Peripherals), build and run the project. Use s32ds-agentic-ai MCP server and if the server disconnects, stop and notify the user. AI will:   Start S32 Design Studio from C:\NXP\2026\K3_kit\S32DS_3.6.8 Search NXP Application Code Hub for GPIO Blinking LED Demo for FRDM-A-S32K312 and import it into S32DS Open S32 Configuration Tools and click Generate Code (Pins, Clocks, Peripherals) Trigger a full build and confirm zero errors Flash and run the project on the board Stop and notify the user if the s32ds-agentic-ai server disconnects Verifying the Result   Work through this final check to confirm that the prompt completed successfully.   Final check The project is imported and visible in the S32DS Project Explorer. S32 Configuration Tools ran successfully – Pins, Clocks, and Peripherals code was generated with no errors. Build completes with zero errors. Firmware is flashed and running on the FRDM-A-S32K312 board. The onboard LED should toggle with a 500ms cadence (500ms on, 500ms off). Troubleshooting   Symptom Fix Project not found in Application Code Hub Confirm the search term is GPIO Blinking LED Demo for FRDM-A-S32K312. Check that the s32ds-agentic-ai is connected and the ACH tool is available. Import fails or project does not appear in Project Explorer Try File › Import › Existing Projects into Workspace manually. Confirm the workspace path is C:\NXP\2026\K3_kit\workspace_S32DS_3.6.8_K3_kit. S32 Configuration Tools does not open Double-click the .mex file in the project root. Ensure the S32K3 SDK is installed and the project SDK is correctly configured. Generate Code produces errors Check the Pins, Clocks, and Peripherals tabs for validation errors (red markers). Resolve conflicts before regenerating. Build errors after Generate Code Ensure the generated src/ folder is included in the build path. Try Project › Clean then rebuild. Flash / debug fails Ensure the board is powered via USB and the J-Link / OpenSDA debugger is recognised. Try Run › Debug Configurations and re-select the correct debug probe. LED does not blink after flashing Confirm the correct binary was flashed. Check that the debug session started and the program counter advanced past main(). s32ds-agentic-ai server disconnects Stop immediately and restart the MCP server following the setup instructions. Do not continue until the server is confirmed connected. File Reference   File Step Description src/main.c 1 Main firmware entry point — GPIO LED blinking loop *.mex 1 S32 Configuration Tools project file (Pins, Clocks, Peripherals) generate/src/ 1 Auto-generated peripheral initialization source files generate/include/ 1 Auto-generated peripheral configuration headers   Import the demo, generate the configuration code and flash it – your first Application Code Hub project running on the FRDM-A-S32K312 in about 20 minutes. Examples

MCXN547 SC Timer0 SDK 驱动程序问题 我使用的是MCXN547VKL单片机和SDK版本26.06.00。 背景：我使用 SCT timer0 通过分割模式下的 COUNTER 生成两个不同的 PWM 波形，CONFIG[UNIFY] = 0；即 COUNT_L 用于一个 PWM 生成器，COUNT_H 用于另一个 PWM 生成器。 问题：当我使用驱动程序 API " SCTIMER_SetCOUNTValue(SCT0,kSCTIMER_Counter_H,0U);" 加载 COUNTER_H 时，发生总线故障。 我发现问题出在 SDK 驱动程序代码上。驱动程序代码使用 32 位写入同时写入 COUNT_H 和 COUNT_L，而不是仅使用 16 位写入 COUNT_H。在写入 COUNT_H 时，COUNT_L 正在运行，这导致了总线故障。我修改了 SDK 驱动程序代码，使其使用 16 位写入，总线故障就没有发生。我已附上驱动程序代码，并用颜色标记出导致问题的代码行和解决方法。如果这确实是问题所在，可以更新 SDK 驱动程序。- 谢谢 /*! * @brief 设置计数器的值。 * 该功能用于设置计数寄存器的值，写入 COUNT_L、COUNT_H 或统一寄存器。 只有当相应的计数器停止时（CTRL 寄存器中的 HALT 位设置为 1），才允许使用 *。 * * @Param base SCTimer 外设基地址 * @Param whichCounter 要使用的 SCTimer 计数器。在 16 位模式下，我们可以选择 Counter_L 和 Counter_H。 * 在 32 位模式下，我们可以选择 Counter_U。 * @Param value 计数器值更新到 COUNT 寄存器。 */ static inline void SCTIMER_SetCOUNTValue ( SCT_Type *base, sctimer_counter_t whichCounter, uint32_t value) { SCTIMER_StopTimer(base, ( uint32_t )whichCounter); 切换（whichCounter） { case kSCTIMER_Counter_L : assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* 当用户想要设置低计数器时，请使用 Counter_L 位 */ base-> COUNT_ACCESS16BIT.COUNTL = ( uint16_t ) value; 休息; case kSCTIMER_Counter_H : assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* 当用户想要设置高位计数器时，请使用 Counter_H 位 */ // base->COUNT = (uint32_t)base->COUNT_ACCESS16BIT.COUNTL | SCT_COUNT_CTR_H(value); base-> COUNT_ACCESS16BIT.COUNTH = ( uint16_t ) value; //修复 休息; case kSCTIMER_Counter_U : assert(1U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* 当计数器在 32 位模式下运行时，同时使用 Counter_L/Counter_H 位（统一计数器）。*/ 基本->计数= 值； 休息; 默认： /* 修复 MISRA C-2012 问题规则 16.4。*/ 休息; } SCTIMER_StartTimer(base, ( uint32_t )whichCounter); } 时钟|计时器 Re: MCXN547 SC Timer0 SDK driver Issue 你好@JawaharA 感谢您的反馈。您对总线故障原因的分析是正确的：更新 COUNT_H 需要对 COUNT 寄存器进行 32 位写入，但当前函数只会停止 H 计数器。如果 L 计数器仍在运行，则此写入访问会触发 SCT 总线错误。 然而，将对 COUNTH 的访问更改为 16 位写入不符合 SCT 硬件访问要求，因为 COUNT_H 必须与 COUNT_L 一起作为一个字写入。正确的软件解决方案是在对 COUNT 执行 32 位写入之前停止 L 计数器和 H 计数器，然后在之后恢复它们之前的运行状态。我们建议相应地审查和更新 SDK，而不是使用单独的 16 位写入 COUNT_H。 BR 哈里 Re: MCXN547 SC Timer0 SDK driver Issue 嗨，哈里， 感谢您的快速回复。 根据您在回复中引用的手册页，如果 CONFIG[UNIFY] = 0，则在相应的计数器未运行时，可以单独读取或写入 COUNT_L 和 COUNT_H 寄存器。SDK 对 COUNT_L 寄存器使用 16 位写入。无论 CONFIG[UNIFY] 设置如何，COUNT_H 寄存器都应该使用 32 位写入进行写入 - 这是未记录的条件吗？ 谢谢 - 贾瓦哈尔

PXP screen rotation issue based on i.MXRT1052 I'm using rt1052PXP to rotate a landscape view to a portrait view, but the overall display shifts downwards when I refresh the page. Why is this happening?   static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { lv_area_t dest_area = { .x1 = 0, .x2 = 480 - 1, .y1 = 0, .y2 = 800 - 1, }; lv_gpu_nxp_pxp_blit(((lv_color_t *)s_inactiveFrameBuffer), area, 800, color_p, area,480, LV_OPA_COVER, LV_DISP_ROT_270); DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)s_inactiveFrameBuffer); s_framePending = true;if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } }   i.MXRT 105x 回复： 基于i.MXRT1052的pxp屏幕旋转问题 I've noticed an offset issue when drawing with PXP. Is it because the default initialization `#define LV_USE_GPU_NXP_PXP_AUTO_INIT 1` generated by guiguider can't be used directly? void lv_disp_drv_init(lv_disp_drv_t * driver) { lv_memset_00(driver, sizeof(lv_disp_drv_t)); driver->hor_res = 320; driver->ver_res = 240; driver->physical_hor_res = -1; driver->physical_ver_res = -1; driver->offset_x = 0; driver->offset_y = 0; driver->antialiasing = LV_COLOR_DEPTH > 8 ? 1 : 0; driver->screen_transp = 0; driver->dpi = LV_DPI_DEF; driver->color_chroma_key = LV_COLOR_CHROMA_KEY; #if LV_USE_GPU_NXP_PXP // driver->draw_ctx_init = lv_draw_pxp_ctx_init; // driver->draw_ctx_deinit = lv_draw_pxp_ctx_deinit; // driver->draw_ctx_size = sizeof(lv_draw_pxp_ctx_t); driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); #else driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); #endif } 回复： 基于i.MXRT1052的pxp屏幕旋转问题 Hi  @dsd, The LV_USE_GPU_NXP_PXP_AUTO_INIT allows LVGL to leverage the user of PXP for internal widget rendering, which could definitely cause issues when the application also uses this PXP in parallel for whole screen rotation. However, it is likely not the source of the issue. From the initial code, it seems like you are not using dest_area, or rather you are using area as both source and destination for the PXP blit, which means that only the partial dirty region might be getting placed on different absolute positions rather than the intended. 回复： 基于i.MXRT1052的pxp屏幕旋转问题 I used the code generated by guiguider to test it, even without using pxp rotation. static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)color_p); s_framePending = true; if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } } Simply modify the macro /*Use NXP's PXP GPU iMX RTxxx platforms*/ #define LV_USE_GPU_NXP_PXP 1 #if LV_USE_GPU_NXP_PXP /*1: Add default bare metal and FreeRTOS interrupt handling routines for PXP (lv_gpu_nxp_pxp_osa.c) * and call lv_gpu_nxp_pxp_init() automatically during lv_init(). Note that symbol SDK_OS_FREE_RTOS * has to be defined in order to use FreeRTOS OSA, otherwise bare-metal implementation is selected. *0: lv_gpu_nxp_pxp_init() has to be called manually before lv_init() / #define LV_USE_GPU_NXP_PXP_AUTO_INIT 1 #endif /* LV_USE_GPU_NXP_PXP */ The same problem will occur, and the direction of the offset will be the same as after rotation. 回复： 基于i.MXRT1052的pxp屏幕旋转问题 What's even stranger is that there are two different results within the same project, even though I thought the configuration should be the same. No display offset occurred Display offset occurs    

基于i.MXRT1052的pxp屏幕旋转问题 我正在使用rt1052的pxp将横屏旋转成竖屏显示，但是在不断刷新的情况下，整体显示会向下偏移，这是为什么？   static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { lv_area_t dest_area = { .x1 = 0, .x2 = 480 - 1, .y1 = 0, .y2 = 800 - 1, }; lv_gpu_nxp_pxp_blit(((lv_color_t *)s_inactiveFrameBuffer), area, 800, color_p, area,480, LV_OPA_COVER, LV_DISP_ROT_270); DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)s_inactiveFrameBuffer); s_framePending = true;if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } }   i.MXRT 105x 回复： 基于i.MXRT1052的pxp屏幕旋转问题 我发现当我使用pxp绘制的时候就会出现偏移问题，是因为guiguider生成的默认初始化#define LV_USE_GPU_NXP_PXP_AUTO_INIT 1不能直接使用吗？ void lv_disp_drv_init(lv_disp_drv_t * driver) { lv_memset_00(driver, sizeof(lv_disp_drv_t)); driver->hor_res = 320; driver->ver_res = 240; driver->physical_hor_res = -1; driver->physical_ver_res = -1; driver->offset_x = 0; driver->offset_y = 0; driver->antialiasing = LV_COLOR_DEPTH > 8 ? 1 : 0; driver->screen_transp = 0; driver->dpi = LV_DPI_DEF; driver->color_chroma_key = LV_COLOR_CHROMA_KEY; #if LV_USE_GPU_NXP_PXP // driver->draw_ctx_init = lv_draw_pxp_ctx_init; // driver->draw_ctx_deinit = lv_draw_pxp_ctx_deinit; // driver->draw_ctx_size = sizeof(lv_draw_pxp_ctx_t); driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); #else driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); #endif } 回复： 基于i.MXRT1052的pxp屏幕旋转问题 嗨@dsd ， LV_USE_GPU_NXP_PXP_AUTO_INIT 允许 LVGL 利用 PXP 进行内部控件渲染，当应用程序还并行使用此 PXP 进行全屏旋转时，这肯定会导致问题。然而，这可能并非问题的根源。 从初始代码来看，你似乎没有使用 dest_area，或者说你将 area 同时用作 PXP blit 的源和目标，这意味着只有部分脏区域可能会被放置在不同的绝对位置，而不是预期的位置。 回复： 基于i.MXRT1052的pxp屏幕旋转问题 我用guiguider生成的代码去测试，即便我不使用pxp旋转 static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)color_p); s_framePending = true; if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } } 仅仅去修改宏/*Use NXP's PXP GPU iMX RTxxx platforms*/ #define LV_USE_GPU_NXP_PXP 1 #if LV_USE_GPU_NXP_PXP /*1: Add default bare metal and FreeRTOS interrupt handling routines for PXP (lv_gpu_nxp_pxp_osa.c) * and call lv_gpu_nxp_pxp_init() automatically during lv_init(). Note that symbol SDK_OS_FREE_RTOS * has to be defined in order to use FreeRTOS OSA, otherwise bare-metal implementation is selected. *0: lv_gpu_nxp_pxp_init() has to be called manually before lv_init() */ #define LV_USE_GPU_NXP_PXP_AUTO_INIT 1 #endif /* LV_USE_GPU_NXP_PXP */ 也会有同样的问题，并且偏移的方向与旋转后的一致 回复： 基于i.MXRT1052的pxp屏幕旋转问题 更奇怪的是在同一个工程下会有两种不同的结果，我认为配置应该是相同的 没有发生显示偏移 发生显示偏移    

MPXV7002DPはLPGおよびプロパンに対応しています。 こんにちは、 私は大学4年生です。現在、家庭用LPG配管の圧力差を測定するプロジェクトに取り組んでいます。配管内の通常の圧力は約2.30kPaから3.60kPaです。データシートを確認しましたが、LPGとの互換性については明確な記載がありませんでした。もし過去にこれを試した方や技術関係者がいれば教えていただけると助かります。 ありがとう 。 Re: MPXV7002DP compatibility with LPG and Propane こんにちは、 2026年2月2日現在、NXP MEMSセンサ製品はSTMicroelectronicsに移管されました。詳細についてはSTMicroelectronicsまでサポートまでお問い合わせください。

wifi驱动程序崩溃- 88w8997 我使用FN-Link L297B-SR模块（Wi-Fi 和蓝牙共用一个天线）时，遇到了间歇性 Wi-Fi 驱动程序崩溃的问题。该问题随机发生，有时在 1 天后，有时在 2 天后，偶尔在连续运行 4 到 5 天后才会发生。 请检查日志 [64622.321614]mwifiex_sdio mmc2:0001:1: 信息：已成功断开与 ca:c6:5c:cb:ad:7e 的连接：原因代码 3 [64624.050010]mwifiex_sdio mmc2:0001:1: 信息：尝试关联到 BSSID ca:c6:5c:cb:ad:7e [64624.072596]mwifiex_sdio mmc2:0001:1: 事件：未知事件 ID：0x95 [64624.085770]mwifiex_sdio mmc2:0001:1: 信息：已成功关联到 bssid ca:c6:5c:cb:ad:7e [64987.640381]蓝牙：hci0：帧重组失败（-84） [65060.466817]蓝牙：hci0：帧重组失败（-84） [65184.303423]mwifiex_sdio mmc2:0001:1: 信息：已成功断开与 ca:c6:5c:cb:ad:7e 的连接：原因代码 0 [65204.712100]ieee80211 phy0：sched_scan 开始：n_ssids=4 n_match_sets=4 [65204.725038]ieee80211 phy0：通道数=41，间隔=10，IE长度=13 [65259.046894]ieee80211 phy0：计划扫描停止！ [65259.067983]mwifiex_sdio mmc2:0001:1: 信息：尝试关联到 BSSID ca:c6:5c:cb:ad:7e [65260.594440]mwifiex_sdio mmc2:0001:1: ASSOC_RESP: 失败，状态码=2 错误=0xfffa a_id=0x3fff [65260.611662]mwifiex_sdio mmc2:0001:1: 关联失败：原因未知连接失败 [65260.624191]mwifiex_sdio mmc2:0001:1: 信息：与 bssid ca:c6:5c:cb:ad:7e 的关联失败 [65260.636278]ieee80211 phy0：sched_scan 开始：n_ssids=4 n_match_sets=4 [65260.645499]ieee80211 phy0：通道数=41，间隔=10，IE长度=13 [65271.191030]mwifiex_sdio mmc2:0001:1: mwifiex_cmd_timeout_func: 超时命令 ID = 0x6b，操作 = 0x1 [65271.199985]mwifiex_sdio mmc2:0001:1: num_data_h2c_failure = 0 [65271.205896]mwifiex_sdio mmc2:0001:1: num_cmd_h2c_failure = 0 [65271.211654]mwifiex_sdio mmc2:0001:1: is_cmd_timedout = 1 [65271.217064]mwifiex_sdio mmc2:0001:1: num_tx_timeout = 0 [65271.222454]mwifiex_sdio mmc2:0001:1: last_cmd_index = 0 [65271.227893]mwifiex_sdio mmc2:0001:1: last_cmd_id: 6b 00 28 00 16 00 12 00 6b 00 [65271.235303]mwifiex_sdio mmc2:0001:1: last_cmd_act: 01 00 13 00 01 00 ca c6 01 00 [65271.242862]mwifiex_sdio mmc2:0001:1: last_cmd_resp_index = 4 [65271.248670]mwifiex_sdio mmc2:0001:1: last_cmd_resp_id: 0c 81 28 80 16 80 12 80 6b 80 [65271.256568]mwifiex_sdio mmc2:0001:1: last_event_index = 3 [65271.262131]mwifiex_sdio mmc2:0001:1: last_event: 18 00 0b 00 0a 00 65 00 0a 00 [65271.269514]mwifiex_sdio mmc2:0001:1: 数据已发送=0 指令已发送=1 [65271.275248]mwifiex_sdio mmc2:0001:1: ps_mode=1 ps_state=0 [65271.281497]mwifiex_sdio mmc2:0001:1:忽略扫描。卡已移除或固件状态异常 [65271.290880]mwifiex_sdio mmc2:0001:1: ===mwifiex 驱动程序信息转储开始=== [65271.317907]mwifiex_sdio mmc2:0001:1: 信息: MWIFIEX 版本: mwifiex 1.0 (16.92.21.p76) [65271.326650]mwifiex_sdio mmc2:0001:1: 扫描失败: -14 [65271.350746]mwifiex_sdio mmc2:0001:1：SDIO 寄存器转储开始 [65271.369462]mwifiex_sdio mmc2:0001:1: SDIO Func0 (0x0-0x9): 43 03 02 02 03 02 00 02 03 00 [65271.385505]mwifiex_sdio mmc2:0001:1: SDIO Func1 (0x10-0x17): 00 00 00 00 00 00 e0 ff [65271.396619]mwifiex_sdio mmc2:0001:1: SDIO 功能1: (0x8) c3 (0x58) 00 (0x5c) 48 (0x5d) 00 (0x60) 07 (0x61) 0c (0x62) 00 (0x64) 10 (0x65) 00 (0x66) 00 (0x68) 00 (0x69) 00 (0x6a) 00 [65271.416154]mwifiex_sdio mmc2:0001:1: SDIO Func1 (0xe8-0xf2): dc fe 7e 00 62 00 3f a7 24 14 70 [65271.580586]mwifiex_sdio mmc2:0001:1: SDIO 功能1 (0xe8-0xf2): dc fe 8f 00 73 00 3f a7 24 14 70 [65271.594858]mwifiex_sdio mmc2:0001:1：SDIO 寄存器转储结束 [65271.610712]mwifiex_sdio mmc2:0001:1: ===mwifiex 驱动程序信息转储结束=== [65271.628592]mwifiex_sdio mmc2:0001:1: == mwifiex 固件转储开始 == [65271.666427]mwifiex_sdio mmc2:0001:1: 无法拉取 ctrl_data [65271.676062]mwifiex_sdio mmc2:0001:1:固件转储失败 [65271.693018]mwifiex_sdio mmc2:0001:1: == mwifiex 转储信息到 /sys/class/devcoredump 开始 [65271.710201]mwifiex_sdio mmc2:0001:1: == mwifiex 转储信息到 /sys/class/devcoredump 结束 [65271.723737]mwifiex_sdio mmc2:0001:1: PREP_CMD: 固件状态异常 [65271.735173]mwifiex_sdio mmc2:0001:1: 信息：mwifiex 已关闭... [65271.769056]mwifiex_sdio mmc2:0001:1: PREP_CMD: 卡已移除 [65271.812192]mwifiex_sdio mmc2:0001:1: PREP_CMD: 卡已移除 [65271.855652]蓝牙：hci0：帧重组失败（-84） [65271.870925]蓝牙：hci0：帧重组失败（-84） [65271.967852]蓝牙：hci0：帧重组失败（-84） [65272.068050]蓝牙：hci0：帧重组失败（-84） [65272.168010]蓝牙：hci0：帧重组失败（-84） [65272.268029]蓝牙：hci0：帧重组失败（-84） [65272.368215]蓝牙：hci0：帧重组失败（-84） [65272.468007]蓝牙：hci0：帧重组失败（-84） [65272.567994]蓝牙：hci0：帧重组失败（-84） [65272.668015]蓝牙：hci0：帧重组失败（-84） [65272.768055]蓝牙：hci0：帧重组失败（-84） [65272.839448]mwifiex_sdio mmc2:0001:1: 信息：固件下载完成，大小为 622240 字节 [65273.607175]mwifiex_sdio mmc2:0001:1: WLAN 固件已激活 [65273.641454]mwifiex_sdio mmc2:0001:1: 未知 api_id: 5 [65273.687228]mwifiex_sdio mmc2:0001:1: 信息: MWIFIEX 版本: mwifiex 1.0 (16.92.21.p76) [65273.713221]mwifiex_sdio mmc2:0001:1: driver_version = mwifiex 1.0 (16.92.21.p76) [65277.145122]mwifiex_sdio mmc2:0001:1: 信息：尝试关联到 BSSID ca:39:a3:cb:ad:7e [65278.668157]mwifiex_sdio mmc2:0001:1: ASSOC_RESP: 失败，状态码=2 错误=0xfffc a_id=0x3fff [65278.677711]mwifiex_sdio mmc2:0001:1: 关联失败：原因 CONNECT_ERR_ASSOC_ERR_TIMEOUT [65278.691251]mwifiex_sdio mmc2:0001:1: ASSOC_RESP: AUTH 超时 [65278.710528]mwifiex_sdio mmc2:0001:1: 信息：与 bssid ca:39:a3:cb:ad:7e 的关联失败 [65279.781236]mwifiex_sdio mmc2:0001:1: 信息：尝试关联到 BSSID ca:c6:5c:cb:ad:7e [65281.310722]mwifiex_sdio mmc2:0001:1: ASSOC_RESP: 失败，状态码=2 错误=0xfffa a_id=0x3fff [65281.320307]mwifiex_sdio mmc2:0001:1: 关联失败：原因未知连接失败 我在下面的 GitHub 链接中找到了同样的问题，但它显示该问题仍处于开放状态。 https://www.bing.com/ck/a?!&&p=6f8995a9ee8bc78d51549c45a34f5deee2c26e49fb129fa9306c277b1df3c48cJmltdHM9MTc5MDQ2NzIwMA&ptn=3&ver=2&hsh=4&fclid=28fe8c6f-37d9-6a8e-3ad5-9b0736ee6b90&psq=wifi+driver+crashes+while+trying+to+reconnect+-+88w8997&u=a1aHR0cHM6Ly9naXRodWIuY29tL254cC1pbXgvaW14LWZpcm13YXJlL2lzc3Vlcy81 提前致谢 Re: wifi driver crashes- 88w8997 您好， 感谢您提供的详细日志。根据崩溃信息，我们可以看到您正在运行固件版本 16.92.21.p76。 请注意，88W8997 已不再包含在标准的 imx 固件版本中。不过，我们有一个专门的热修复分支，其中包含最新的固件，可在此处获取： https://github.com/nxp-imx/mwifiex/tree/hotfix/lf-6.12.49_2.2.0_hotfix_w8997 https://github.com/nxp-imx/imx-firmware/tree/hotfix/lf-6.12.49_2.2.0_hotfix_w8997 我们建议您升级到该分支中提供的固件，该固件比您当前的版本新得多，并且包含稳定性修复程序，可以解决您遇到的命令超时和固件状态错误问题。 问候， 丹尼尔。 Re: wifi driver crashes- 88w8997 DanielRuvalcaba，谢谢你的支持。 我们将热修复固件加载到组合芯片上，并连续运行了大约一周。在此期间，我们遇到了另一个问题。与之前 Wi-Fi 固件崩溃的问题不同，这次 Wi-Fi 功能仍然可用，但 BLE 在连续运行 3-4 天后停止工作。 仅通过 RESET HCI 接口无法恢复 BLE 故障。为了恢复 BLE 功能，我们必须重新加载组合芯片上的固件。我们已附上 BLE 故障期间捕获的最新日志，以供进一步分析。 [308423.524163] Bluetooth: hci0: 命令 0x0406 发送超时 [308454.723609]蓝牙：hci0：命令 0x2011 发送超时 [308454.728959]蓝牙：hci0：操作码 0x2011 失败：-110 [308454.734354]蓝牙：hci0：无法添加到允许列表：-110 [308456.771606]蓝牙：hci0：操作码 0x200b 失败：-110 [308456.776986]蓝牙：hci0：命令 0x200b 发送超时 [308456.782265]蓝牙：hci0：启动后台扫描失败：-110 [308458.819547]蓝牙：hci0：操作码 0x2011 失败：-110 [308458.824925]蓝牙：hci0：命令 0x2011 发送超时 [308458.830210]蓝牙：hci0：无法添加到允许列表：-110 [308460.867534]蓝牙：hci0：操作码 0x200b 失败：-110 [308460.872908]蓝牙：hci0：命令 0x200b 发送超时 [308460.878263]蓝牙：hci0：启动后台扫描失败：-110 [308462.915455]蓝牙：hci0：操作码 0x2011 失败：-110 [308462.920957]蓝牙：hci0：命令 0x2011 发送超时 [308462.926341]蓝牙：hci0：无法添加到允许列表：-110 [308464.963435]蓝牙：hci0：操作码 0x200b 失败：-110 [308464.968817]蓝牙：hci0：命令 0x200b 发送超时 [308464.974104]蓝牙：hci0：启动后台扫描失败：-110 [308467.747431]蓝牙：hci0：命令 0x200a 发送超时 提前致谢。

MCXN547 SC Timer0 SDKドライバーの問題 私はMCUとSDK MCXN547VKLバージョン26.06.00を使っています。 コンテキスト: 私は SCT タイマー 0 を使用して、スプリット モードの COUNTER を使用して 2 つの異なる PWM 波形を生成しています。CONFIG[UNIFY] = 0、つまり COUNT_L を 1 つの PWM ジェネレーターに、COUNT_H を別の PWM ジェネレーターに使用しています。 問題はこうです:ドライバーAPI「SCTIMER_SetCOUNTValue(SCT0,kSCTIMER_Counter_H,0U)」でCOUNTER_Hを読み込むと、バスフォールトが発生します。 問題の原因をSDKのドライバーコードに突き止めました。ドライバコードはCOUNT_H単独で16ビットの書き込みではなく、COUNT_HとCOUNT_Lの両方を32ビット書き込みで行います。COUNT_H が書き込まれている間に COUNT_L が実行されていたため、バス障害が発生しました。SDKのドライバーコードを16ビット書き込みに変更したところ、バスの故障は発生しませんでした。ドライバーコードを添付し、問題の原因となったコードラインと修正方法を色で示しました。もし本当にこれが問題なら、SDKドライバーを更新できます。- ありがとう /*! * @brief カウンターの値を設定します。 * * この機能は、カウントレジスタの値を設定することであり、COUNT_L、COUNT_H、または統合レジスタに書き込みます。 * は、対応するカウンタが停止しているとき（CTRL レジスタの HALT ビットが 1 に設定されているとき）にのみ許可されます。 * * @param base SCTimer ペリフェラル ベースアドレス * @param whichCounter SCTimer カウンターを使います。16ビットモードでは、Counter_LとCounter_Hを選択できます。 * 32ビットモードではCounter_Uを選択できます。 * @Param value COUNTレジスタへのカウンタ値の更新。 */ static inline void SCTIMER_SetCOUNTValue ( SCT_Type *base, sctimer_counter_t whichCounter, uint32_t value) { SCTIMER_StopTimer(base, ( uint32_t )whichCounter); スイッチ (whichCounter) { case kSCTIMER_Counter_L: assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* ユーザーがLowカウンターを設定したいときにビットCounter_Lを使います */ base-> COUNT_ACCESS16BIT.COUNTL = ( uint16_t ) value; 壊す; case kSCTIMER_Counter_H: assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* ユーザーがHighカウンターを設定したいときにCounter_Hビットを使う */ // base->COUNT = (uint32_t)base->COUNT_ACCESS16BIT.COUNTL | SCT_COUNT_CTR_H(value); base- > COUNT_ACCESS16BIT.COUNTH = ( uint16_t )value; //修正 壊す; CASE kSCTIMER_Counter_U: assert(1U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* カウンタが 32 ビットモードで動作している場合 (カウンタを統合する場合) は、Counter_L ビットと Counter_H ビットの両方を使用します。*/ base-> COUNT = value; 壊す; デフォルト： /* MISRA C-2012 問題ルール 16.4 を修正します。*/ 壊す; } SCTIMER_StartTimer(base, ( uint32_t )whichCounter); } クロック|タイマー Re: MCXN547 SC Timer0 SDK driver Issue こんにちは、 @JawaharA さん。 ご意見ありがとうございます。バス障害の原因に関するあなたの分析は正しいです。COUNT_H の更新には COUNT レジスタへの 32 ビット書き込みが使用されますが、現在の関数は H カウンタのみを停止します。Lカウンタがまだ動作している場合、この書き込みアクセスはSCTバスエラーを引き起こします。 しかし、COUNTHへの16ビット書き込みへのアクセス変更はSCTハードウェアアクセス要件に適合しません。なぜなら、COUNT_HはCOUNT_L と一緒にワードとして書かなければならないからです。正しいソフトウェアの解決策は、32ビットのCOUNTへの書き込みを行う前にLとHの両方のカウンターを停止し、その後に以前の実行状態を復元することです。別途16ビットの書き込みを使わずにSDKをレビューし、適切に更新することを推奨COUNT_H。 BR ハリー Re: MCXN547 SC Timer0 SDK driver Issue こんにちは、ハリーさん。 迅速なご対応ありがとうございます。 ご回答で参照されたマニュアルページによると、CONFIG[UNIFY] = 0の場合、COUNT_LレジスタとCOUNT_Hレジスタの両方をそれぞれカウンタが動作していない間に個別に読み書きできます。SDKはレジスタに16ビット書き込みCOUNT_L使っています。COUNT_HレジスタはCONFIG[UNIFY]の設定に関係なく32ビット書き込みで書き込む必要がありますが、これは非公式な条件でしょうか？ ありがとう - ジャワハル

FRDM-MCXN236にはクーポンは適用されません NXPのウェブサイトでは、この無料ボードを使って始められると宣伝していた。しかし、在庫があるにもかかわらず、クーポンコードがチェックアウト時にまだ使えません。 評価ボード Re: Coupon not valid for FRDM-MCXN236 こんにちは、 PLACEHOLDER7 その場合は、 [email protected] までにショッピングカートチームまでメールをお送りください。 そのチームはオンライン注文を担当しています。 ご理解いただきありがとうございます。 ベッキー

「examples/freemaster_examples/fmstr_example_pdbdmにおけるアプリケーションコマンドの問題 親愛なるみんな sdk.sdk_2.x_lpcxpresso54114をダウンロードしましたFreeMASTERの例のみを使用します。アプリケーションコマンドセクションで奇妙な挙動が見つかる以外は、すべての面で正常に動作しています 詳細はGitHubに掲載されています。こちらをご覧ください。 https://github.com/nxp-mcuxpresso/mcuxsdk-examples/issues/10 敬具 パオロ Re: Application Command issue in 'examples/freemaster_examples/fmstr_example_pdbdm こんにちは、問題の理解が正しければ、例のアプリケーションでコマンド0x10がコード16を返す理由が見当たりません。 コマンド0x10はコールバック関数に登録されています。 したがって、FreeMASTERがコマンド実行をプロブリングすると、「my_appcmd_handler」関数は自動的に呼び出されます。このコールバックのサンプルコードは非常に単純です。 そのため、戻りコード16（=0x10）が回答として返されます。 また、ご報告いただいたように、ID 0x02 の app.command で、FreeMASTER に不明な応答に対するメッセージ表示に関する問題があることも確認しました。応答0xcdは「不明な応答」として報告されるべきだが、実際には何もメッセージが生成されない。 ありがとう、 ミハル

LS1046A カスタムデザインHRESET_Bリリースされていません <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 LS1046Aプロセッサーを活用したカスタムデザインを作ろうとしています。(基板設計ではRDBを基準にしていました。)すべての電源レール電圧が正しいことを確認し、電源シーケンスのタイミングを測定したところ、すべてデータシートに記載されている許容範囲内であることが確認されました。私が経験している問題は、プロセッサーをリセットから解除できないことです。測定したところ、プロセッサーがHRESET_B信号を放っていません。リファレンスマニュアルによると、初期化中はプロセッサがこのラインを低く保ち、RCWの読み込みやPLLのロック後はリリースするそうです。RCWにエラーがあるのかと思い、代わりに内蔵のRCW値を使いました。(プロセッサに0x9Eと0x9F RCWの両方を固定しましたが、結果は同じでした。) 今のところ、私は少し途方に暮れています。クロックは納期通りに納品され、スルーレートはすべて仕様範囲内であり、ストラップ値を解放する前に適切な時間保持しています。リファレンスマニュアルには、PBLがエラーに遭遇した場合にRESET_REQ信号を切り替えると書かれていますが、私はそのような現象は見ていません。私の現時点での結論は、PBLが実行されていないということです。これはプロセッサがまだリセット状態にあるサインです。 何か見落としている点があるのでしょうか？次にどこを探せばいいでしょうか？私のタイミングは仕様の範囲内ですが、RDBとは完全に一致しません（ボード上の関連信号をプローブしました）。LS1046の電源シーケンス制御はどの程度敏感ですか？ よろしくお願いいたします。 Re: LS1046A Custom Design HRESET_B not released こんにちは、ブライス 正しい方向にするためにどのシーケンスを変更したのか説明してもらえますか?現在、私もカスタムLS1046Aボードで同様の問題に直面しています。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 上記のご回答、ありがとうございました。 最後に、CPLDコードのパワーシーケンスの問題を解決しました。元のコードがこの問題を引き起こしていたため、コードを書き直したところ、問題は解消されました。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> プロセッサ接続の回路図を確認できるように、技術CASEを作成してください。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ハードウェアには、フラッシュメモリから取得したRCWではなく、ハードコードされたRCWを使用するように設定しました。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> RCWが外部フラッシュメモリから読み取られているかどうかを、デジタルオシロスコープを使用して確認してください。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 ご回答ありがとうございます。上記すべてが良好な状態であることを確認しました。ただし、最後の点について一つ質問があります。これは電源投入リセットシーケンスを完了するために必要な手順なのでしょうか？先ほど述べたように、RESET_REQ信号を観測できないため、PBLの実行はできないと考えています。SerDesリファレンスクロックは、PBLを実行するために必須ですか、それともPBLがシステムをセットアップしている段階で必要になりますか？ よろしくお願いします。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 最初の確認段階として、以下を点検してください。 1) QorIQ LS1046A、LS1026Aデータシートの表1の注記に明示的に記載されているすべての信号のPORレベル。バスごとのピン配置リスト。 2) HRESET_Bは外部からアサートされない 3) SerDesリファレンスクロックはデータシートの要件に準拠しています。 問題が解決しない場合は、次のブリングアップステージを技術ケースとして行う方が便利です。 https://community.nxp.com/thread/381898

LS1046A Custom Design HRESET_B not released Hello, I am working to bringup a custom design making use of the LS1046A processor. (Board design used the RDB as a reference).  I have verified that all power rail voltages are correct and have have measured the power sequencing timing which all appear to be withing the tolerances found in the datasheet. The issue I am experiencing is that I am not able to bring the processor out of reset. When measuring, I found that the processor is not releasing the HRESET_B signal. The reference manual indicates that the processor will hold this line low while it is performing initialization and will release it after loading the RCW and locking PLL's, etc. Thinking perhaps I had an error in my RCW, I used the built-in RCW values instead. (I strapped the processor with both the 0x9E and 0x9F RCW values with the same result). At this point, I'm at a bit of a loss. My clocks are provided on time, my slew rates are all within spec, and I am holding the strapping values for the correct amount of time before releasing them. The reference manual also indicates that the PBL will toggle the RESET_REQ signal if it has encountered an error, but I am not seeing this happen. So my conclusion currently is that the PBL is not even being executed which, to me, is a sign that the processor is still in a reset state. Is there something here that I am missing? Anywhere I should look next? My timings are within spec, but do not match the RDB exactly (I probed the relevant signals on the board). How sensitive is the power sequencing on the LS1046? Thanks in advance. Re: LS1046A Custom Design HRESET_B not released Hi bryce  Can you explain what sequence did you chnage to get it right? Currently I am also facing similar issue with cutsom ls1046a board Re: LS1046A Custom Design HRESET_B not released Thank you for your above answers. To tie off the thread, I have solved the issue with the power sequencing in my CPLD code. Because the original code I had was causing this issue, I re-wrote it and I no longer see the issue.  Re: LS1046A Custom Design HRESET_B not released Please create a Technical Case so I will be able to check the processor connection schematics. Re: LS1046A Custom Design HRESET_B not released We have strapped the hardware to use the hard-coded RCW, not the RCW from flash. Re: LS1046A Custom Design HRESET_B not released Please use a digital scope to check whether RCW is read from an external flash. Re: LS1046A Custom Design HRESET_B not released Hello, Thanks for your response.  I have verified that all of the above are in a good state. One question I did have about your last point, however: Is this required in order for the power-on reset sequence to complete? As I stated earlier, we are not able to observe the RESET_REQ signal, so I believe we are unable to execute the PBL. Are SerDes reference clocks required in order execute the PBL, or are they required later on while PBL is already setting up the system? Thanks Re: LS1046A Custom Design HRESET_B not released As first checking stage please inspect: 1) POR levels of all signals explicitly mentioned in the notes to the QorIQ LS1046A, LS1026A Data Sheet, Table 1. Pinout list by bus. 2) HRESET_B is not asserted externally 3) SerDes reference clocks conform to the Data Sheet requirements. If the issue will not be resolved, it is more convenient to perform next bring-up stage as Technical Case: https://community.nxp.com/thread/381898 

此优惠券不适用于 FRDM-MCXN236 NXP 网站宣传了这款免费板。但是即使商品有库存，结账时优惠券代码仍然无法使用。 评估板 Re: Coupon not valid for FRDM-MCXN236 你好PLACEHOLDER7 在这种情况下，请您发送电子邮件至[email protected]联系我们的购物车团队。 该团队负责处理线上订单。 谢谢您的理解 贝基

LS1046A 定制设计 HRESET_B 未发布 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好， 我正在努力开发一个使用 LS1046A 处理器的定制设计。（电路板设计参考了RDB。）我已经确认所有电源轨电压均正确，并且测量了电源时序时序，所有参数似乎都在数据手册规定的容差范围内。我遇到的问题是无法将处理器从重置状态中恢复。测量时，我发现处理器没有释放 HRESET_B 信号。参考手册指出，处理器在执行初始化时会将此线路保持低电平，并在加载 RCW 和锁定 PLL 等操作后将其释放。考虑到我的 RCW 设置可能有误，我改用了内置的 RCW 值。（我分别用 0x9E 和 0x9F RCW 值给处理器加装了 RCW 参数，结果相同）。 此时此刻，我有点不知所措。我的时钟按时交付，我的转换速率均在规格范围内，并且在释放之前，我会将捆扎值保持正确的时间。参考手册还指出，如果 PBL 遇到错误，它会切换 RESET_REQ 信号，但我没有看到这种情况发生。因此，我目前的结论是 PBL 根本没有执行，在我看来，这表明处理器仍处于 RESET 状态。 我是不是漏掉了什么？接下来我应该从哪里入手？我的时序符合规格，但与 RDB 不完全匹配（我探测了板上的相关信号）。LS1046的电源时序控制有多敏感？ 先行致谢。 Re: LS1046A Custom Design HRESET_B not released 嗨，布莱斯 你能解释一下你修改了哪些步骤才做对了吗？目前我也遇到了类似的问题，使用的是定制的LS1046A主板。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 感谢您之前的解答。 最后，我已经解决了 CPLD 代码中的电源时序问题。由于我之前的代码导致了这个问题，所以我重写了代码，现在问题已经解决了。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 请创建一份技术案例，以便我能够查看处理器连接原理图。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我们已经将硬件绑定到使用硬编码的 RCW，而不是来自闪存的 RCW。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 请使用数字示波器检查是否能从外部闪存读取 RCW。 Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好， 谢谢你的回复。我已经确认以上所有物品都处于良好状态。关于您最后一点，我还有一个问题：这是上电复位序列完成的必要条件吗？正如我之前所说，我们无法观察到 RESET_REQ 信号，所以我认为我们无法执行 PBL。SerDes 参考时钟是执行 PBL 所必需的，还是在 PBL 设置系统时才需要的？ 谢谢！ Re: LS1046A Custom Design HRESET_B not released <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 第一阶段检查请检查： 1) QorIQ LS1046A、LS1026A 数据表表 1 中明确提及的所有信号的 POR 水平。按总线列出引脚图。 2) HRESET_B 未被外部钳位 3) SerDes 参考时钟符合数据手册的要求。 如果问题无法解决，则更方便地将下一阶段的启动工作作为技术案例来执行： https://community.nxp.com/thread/381898