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_<x>_<y> 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_<x>_<y> , 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.   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_<exampleX>_<exampleY> ; 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.  

  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.

  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.

  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.

  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.

    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. 2. Build, debug, and analyze memory usage for a FreeRTOS Hello World project with Copilot. 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.

  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.