# S32K144_QSAR

**Repository Path**: tom-embedded/S32K144_QSAR

## Basic Information

- **Project Name**: S32K144_QSAR
- **Description**: This project implements a cute software architecture (QSAR) for S32K144 automotive ECU, decoupled from the official S32DS IDE compilation workflow.
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2026-09-16
- **Last Updated**: 2026-09-16

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# S32K144_QSAR

This project implements a cute software architecture (QSAR) for S32K144 automotive ECU, decoupled from the official S32DS IDE compilation workflow. Designed with reference to AUTOSAR standards, QSAR features easy maintenance, layered design and simple integration.

## Software Version List

| Component          | Version                                    |
| ------------------ | ------------------------------------------ |
| EB tresos Studio   | 24.0.1                                     |
| AUTOSAR MCAL       | AUTOSAR 4.3.1 (S32K1XX_MCAL_4.3_RTM_1.0.5) |
| Compiler Toolchain | GCC ARM v6.3 (S32DS ARM v2.2)              |
| Real-Time OS       | FreeRTOS 202604.00 LTS                     |
| CMake              | 4.3.4                                      |
| Ninja              | 1.13.2                                     |

## Software Architecture

This layered software architecture runs on the S32K144 microcontroller. All modules adopt a one-way downward dependency to decouple the software logic from the underlying hardware.

1. **Application** implements business logic, relying on **Middleware** and **RTOS**. **Middleware** encapsulates **Communication Service Layer**, **Communication Abstraction Layer** and **Hardware Abstraction Layer** with unified public APIs.

2. Within **Middleware**, **Communication Service Layer** invokes **Communication Abstraction Layer** for communication logic processing.

3. **Communication Abstraction Layer** and **Hardware Abstraction Layer** depend on low‑level **MCAL** drivers to access peripheral hardware.

4. **RTOS** obtains the system clock from the **MCAL** to implement task scheduling.

![alt text](Documents/QSAR.png)

## Project File Structure

Project file structure is corresponding to the software architecture.

```
 S32K144_QSAR/ #Root 
 ├──App/ #Application Layer
     └──CMakeLists.txt 
 ├──Common/ #Common header files
     └──*.h 
     └──CMakeLists.txt  
 ├──Mcal/ #Microcontroller Abstraction Layer
     └──Mcal_Cfg/ #EB Tresos raw configuration files (*.xdm) & auto-generated MCAL code output 
     └──Mcal_Modules/ #Original MCAL source, which is not provided in the remote repository 
     └──Stub_SchM.c #AUTOSAR SchM stub for MCAL compile
     └──CMakeLists.txt 
 ├──Middleware/Intermediate Layer between App and low‑level MCAL drivers
     └──api/ #Public application‑oriented header files
     └──Cal/ #Communication Abstraction Layer
     └──Csl/ #Communication Service Layer
     └──Hal/ #Hardware Abstraction Layer
     └──CMakeLists.txt 
 ├──Platform/ #Platform files provided from S32DS 
     └──devices/ 
     └──Linker_Files/ 
     └──nvic/ 
     └──Startup_Code/ 
     └──CMakeLists.txt 
 ├──Rtos/ #Real-Time Operation System (FreeRTOS adopted) 
     └──CMakeLists.txt  
 ├──cmake/ #Compilation manner used by Cmake & Ninja
     └──build.bat
     └──clean&build.bat
     └──CMakeLists.txt
     └──gcc_arm_eabi_toolchain.cmake
     └──PreLoad.cmake
 ├──Documents/ #Reference for S32K144 
 ├──legacy_makefile_build/ #Compilation manner used in the Makefile (Make a backup copy here, and no longer used in this project)
```

## Building Environment

Two compilation manners are provided in this project: the primary **CMake & Ninja** build system and a legacy  **Makefile build**  solution.

The  **CMake & Ninja**  workflow is the official, maintained compilation method for the master branch. Users only need to double-click `build.bat` or `clean&build.bat` inside the `cmake/` directory to complete the full build process automatically. All core project configuration files, including CMakeLists.txt, cross-compiler toolchain definition and preload scripts, are stored under the `cmake/` folder.
Each software module is compiled separately and packaged into static library `.a` files. Compiled artifacts are output to module‑specific `*_out` folders. All static libraries are further linked to generate final firmware outputs: `.elf`, `.hex`, `.s19` and `.map`.

The  **Makefile build**  workflow in the `legacy_makefile_build/` directory only serves as a historical backup copy. It is based on the original Makefile build code (startup assembly, main.c, etc.) for cutting and adaptation, but is no longer used for routine compilation.

## Debugging Environment

- Debug Hardware: SEGGER J-Link Probe
- Debug Software: SEGGER Ozone GUI Debugger

## Reference and Copyright

- Reference for **CMake & Ninja** build system comes from author: https://gitee.com/qq353838430
- Reference for  **Makefile build**  solution comes from  _PlatformIntegration_TS_T40D2M10I1R0_  provided by  _S32K1XX_MCAL_4.3_RTM_1.0.1_  (no demo suppied after this version).
- The MCAL original source code under `Mcal/Mcal_Modules/` is supplied by NXP. It is not uploaded to the repository due to copyright restrictions.