Table of Contents
Introduction
This article focuses on the software and hardware environment required to build, deploy, and monitor the parking sensor node. On the software side, it presents the MATLAB/Simulink workflow, NXP's Model-Based Design Toolbox (MBDT) for S32K1xx devices, FreeMASTER, and the supporting build environment. On the hardware side, it describes the S32K144-Q100 evaluation board, the MaxBotix MB1020 ultrasonic sensors, the wiring approach, and the communication/debug interfaces used in the setup.
The goal is to provide a clear setup foundation before moving into the next article, where the internal model architecture, control flow, and application behavior will be described in more detail.
Required Software
The parking sensor application is developed using a model-based workflow built around MATLAB, Simulink, Stateflow, and NXP's MBDT for S32K1xx devices. The Simulink model remains the main development artifact, while the supporting toolchain is used to generate code, build the application, download it to the target board, and monitor the running system.
3.1 MATLAB, Simulink and Stateflow
MATLAB and Simulink provide the main environment for developing the parking sensor application model. Simulink and Stateflow are used to organize the application structure, configure the processing blocks, and prepare the model for deployment on the S32K144 target.
Figure 1. PSS top-level model in Simulink
3.2 NXP Model-Based Design Toolbox for S32K1xx
NXP's Model-Based Design Toolbox (MBDT) for S32K1xx acts as the bridge between the Simulink model and the S32K144 hardware. It provides dedicated blocks for configuring and using the microcontroller peripherals required by the parking sensor node.
In this project, MBDT is used for Analog-to-Digital Converter (ADC) acquisition, General-Purpose Input/Output (GPIO) control, Local Interconnect Network (LIN) communication, and FreeMASTER for real-time data visualisation. This allows the model to interact directly with the target hardware without requiring the developer to manually implement low-level peripheral code.
The key point for this article is that MBDT keeps the hardware configuration close to the model. The detailed usage of each block and how the blocks are arranged inside the application will be explained in the model architecture article.
3.3 Code Generation and Deployment Flow
The application is prepared for embedded deployment through the code generation flow supported by Simulink, Embedded Coder, ARM Cortex-M support, and NXP MBDT. From the developer's perspective, the main workflow remains inside Simulink: the model is configured, generated, built, and deployed to the S32K144 board.
NXP's toolchain environment integrated in MBDT provides the compiler and target support used by the build process. In this setup, it does not need to be treated as a separate development step. The generated application can be downloaded to the S32K144-Q100 evaluation board through the MBDT build/deploy workflow using the on-board JTAG debug interface.
This keeps the setup straightforward: once MBDT is installed, the application can be built and programmed from the Simulink workflow.
3.4 FreeMASTER
FreeMASTER is used as the runtime monitoring tool during development. It provides visibility into the embedded application while it is running on the S32K144 board.
In the Parking Sensors System (PSS) setup, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, processed distance values, and selected application variables. This helps during bring-up and validation because the developer can check the behavior of the generated application without adding custom debug code.
3.5 Toolchain Versions
The following software components are used for this demo setup:
| Component | Version / Variant |
|---|---|
| MATLAB / Simulink / Stateflow | R2024a or newer |
| Embedded Coder | Matching MATLAB release |
| ARM Cortex-M support | Matching MATLAB release |
| NXP MBDT for S32K1xx | 4.3.0 |
| FreeMASTER | 3.2 or newer |
These versions define the reference environment used to build and deploy the parking sensor application.
Required Hardware
The hardware setup is centered on the S32K144-Q100 evaluation board, which acts as the local parking sensor node. Four MaxBotix MB1020 ultrasonic sensors are connected to the board through analog inputs and control lines. The board also connects to the zonal controller over LIN and to the development PC through the FreeMASTER interface.
Figure 2. Parking Sensor Node Hardware Setup
4.1 NXP S32K144-Q100 Evaluation Board
The S32K144-Q100 evaluation board is the target hardware used for the parking sensor node. It provides the microcontroller platform required to run the generated application and includes the peripherals needed by the demo: ADC channels for the ultrasonic sensor outputs, GPIO pins for sensor control, LIN support for communication with the zonal controller, and a debug interface for programming and monitoring.
In this setup, the board performs the hardware-side interaction with the sensors and communication interfaces.
Figure 3. S32K144-Q100 Evaluation Board Used for the Parking Sensor Node
The board configuration used by the project is summarized below.
| Setting | Value |
|---|---|
| Device | S32K144 |
| Package | 100-LQFP |
| SRAM size | 64 KB |
| External crystal | 8 MHz |
| System clock | 80 MHz |
| Memory model | FLASH |
| Debug interface | JTAG |
The exact configuration is provided by the MBDT configuration block in the Simulink model.
4.2 MaxBotix MB1020 Ultrasonic Sensors
The demo uses four MaxBotix MB1020 sensors, also known as LV-MaxSonar-EZ ultrasonic sensors. Each sensor provides an analog voltage output that varies with the measured distance, which makes the device easy to connect to the S32K144 ADC inputs. The sensor also includes an RX pin that can be used as an enable or control input.
4.3 Sensor Wiring and Pin Mapping
Each MB1020 sensor is connected to the S32K144-Q100 board using two main signal types. The analog output pin is connected to one ADC input channel, while the RX pin is connected to a GPIO output and can be used by the application to control the sensor. Power and ground are distributed from the evaluation board through the breadboard.
The following pin mapping comes from the PSS model connection annotation.
| Sensor | Analog pin to S32K144 | RX enable pin to S32K144 |
|---|---|---|
| SONAR1 — Left | AN → PTB2, ADC0_SE6, J2.11 | RX → PTA11, J1.2 |
| SONAR2 — Center Left | AN → PTB3, ADC0_SE7, J2.9 | RX → PTA17, J1.4 |
| SONAR3 — Right | AN → PTA0, ADC0_SE9, J5.7 | RX → PTD10, J1.6 |
| SONAR4 — Center Right | AN → PTA1, ADC0_SE15, J5.5 | RX → PTD11, J1.8 |
Power and ground connections are defined as follows.
| Signal | Connection |
|---|---|
| GND | Breadboard black rail → J13.4 on S32K144-Q100 |
| VCC 5 V | Breadboard red rail → J3.9 on S32K144-Q100 |
Figure 4. Sensor Wiring Between the S32K144-Q100 Board and MB1020 Sensors
4.4 ADC Configuration
The MB1020 sensors provide analog voltage outputs, so the S32K144 ADC is used to convert these signals into digital values. In the project setup, ADC0 is configured for software-triggered acquisition and uses the channels assigned to the four ultrasonic sensors.
| Setting | Value |
|---|---|
| ADC instance | ADC0 |
| Resolution | 12-bit |
| Trigger source | Software trigger |
| Voltage reference | 5 V / 0 V |
| Used channels | ADC0_SE6, ADC0_SE7, ADC0_SE9, ADC0_SE15 |
| Averaging | Enabled, 4 samples |
This section describes only the peripheral setup. The timing of the acquisitions and the conversion from ADC values to distance measurements will be covered in the next article.
4.5 LIN Interface to the Zonal Controller
The parking node communicates with the zonal controller using LIN. In this setup, the parking node is configured as a LIN slave, while the zonal controller acts as the LIN master.
| Setting | Value |
|---|---|
| Peripheral | LPUART2 in LIN mode |
| Node function | Slave |
| Baud rate | 19200 bit/s |
| Checksum | Enhanced LIN 2.x |
| LIN TX pin | PTD7 |
| LIN RX pin | PTD6 |
The physical connection between the parking node and the zonal controller uses LIN and ground lines.
| Signal | Zonal board pin | Parking S32K144-Q100 pin |
|---|---|---|
| LIN | J31.8 | J11.1 |
| GND | J31.2 | J11.4 |
4.6 FreeMASTER Debug Channel
FreeMASTER uses a dedicated serial channel that allows the developer to monitor the application on the PC while the parking node continues to communicate with the zonal controller.
| Setting | Value |
|---|---|
| Interface | LPUART1 |
| Baud rate | 115200 bit/s |
| RX pin | PTC6 |
| TX pin | PTC7 |
| Usage | Runtime monitoring and variable visualization |
References
- Developing a Parking Sensor System with Model-Based Design Toolbox
- Model-Based Design Toolbox for S32K Community
- Model-Based Design Toolbox for S32K How To
- NXP Support Package for S32K1xx
- NXP Model-Based Design Toolbox for S32K1 Toolbox Download
- NXP S32K144 Reference Manual and S32K144-Q100 evaluation board user guide
- MaxBotix MB1020 / LV-MaxSonar-EZ1 datasheet
- MathWorks documentation: MATLAB, Simulink, Stateflow, Embedded Coder, ARM Cortex-M support
- FreeMASTER Run-Time Debugging Tool
Conclusion
This article described the software and hardware environment required to build and run the Parking Sensor System. The software side is based on MATLAB, Simulink, Stateflow, NXP MBDT, code generation support, and FreeMASTER. The hardware side uses the S32K144-Q100 evaluation board, four MaxBotix MB1020 ultrasonic sensors, ADC input channels, GPIO control lines, LIN communication, and a dedicated FreeMASTER serial channel.
With this environment in place, the PSS model can be built, downloaded to the S32K144 board, monitored in real time, and connected to the zonal demo setup.
The next article will move inside the model and explain the application architecture, including the sensor acquisition flow, model structure, distance conversion, and LIN communication behavior.