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
View full article
