S32K388 with MC33771B SPI BMS: MBDT, code generation, and AI deployment

[SonHyunTaek]

Hello NXP Community,

I am developing an integrated BMS using S32K388-Q289 and FRDM-MC33771B-SPI-EVB via SPI communication, targeting a real lithium-ion battery pack. While researching, I noticed that there are relatively few BMS-specific example projects and reference implementations available for the S32K3 series, so it has been challenging to confirm the recommended workflow and supported toolchain for this type of application.

My goal is to implement the full embedded BMS stack on the MCU, including:

Cell voltage / temperature monitoring (via BCC)

Cell balancing control

SOC / SOH estimation algorithms (including deep learning-based approaches)

Real-time operation on the MCU

Model-Based Design workflow if possible (otherwise an S32DS C project)

I plan to use MATLAB/Simulink Model-Based Design Toolbox (MBDT) first, and if full support is not available for my setup, I will proceed with S32 Design Studio (S32DS).

I would appreciate guidance on the questions below:

1) MBDT support and training materials for S32K3 BMS applications
Is there any official documentation, user guide, training course, or application note for using MBDT with the S32K3 series specifically for BMS-related development (e.g., SPI-based BCC communication, sampling/processing, protection logic, and real-time monitoring)?

2) Integrating MBDT models with Deep Learning models and code generation
If I develop the BMS logic in Simulink (MBDT) and add a SOC/SOH model built using Deep Learning Toolbox:

- Can these be combined into a single integrated Simulink model?

- If yes, can the integrated model be automatically generated into C code (or other supported embedded code) using Embedded Coder for deployment on S32K388?

3) Real-time inference feasibility on S32K388
If code generation in (2) is feasible:

- Can the deployed model perform real-time inference (SOC/SOH estimation) using live battery data (voltage/current/temperature) on the MCU?

- Are there recommended constraints or best practices (e.g., fixed-point vs floating-point, supported layer types, model size limits, inference timing considerations) for S32K388?

4) Safety constraints / protection logic in MBDT
For safety, I need to implement protection logic such as:

- Over-voltage / under-voltage thresholds

- Over-temperature / under-temperature thresholds

- Fault handling and safe-state behavior

Is it possible to implement these limits and protection logic directly in MBDT/Simulink and include them in the generated embedded code?
If there are any reference examples (BMS or safety logic) for S32K targets, please share.

5) S32K388 compatibility with FRDM-MC33771B-SPI-EVB and alternatives
Is S32K388-Q289 officially supported/recommended to work with MC33771B via SPI for BMS applications?
If this combination is not recommended, could you suggest an officially supported BCC + reference platform (SPI or TPL) for S32K3-based BMS development?

6) On-device training (online learning) vs inference-only workflow
From an embedded AI perspective:

- Is on-device training (online learning using real-time battery data) supported or recommended on S32K3 MCUs?

- Or is the recommended approach offline training on PC + inference-only on the MCU?

If offline training is recommended, are there any official references describing a recommended workflow?

7) Performance / memory guidance for AI inference on S32K388
Are there any benchmarks or guidelines for running AI inference on S32K3 (especially S32K388) regarding:

- Flash/RAM usage expectations

- Typical inference latency ranges

- Optimization approaches (fixed-point, quantization, lightweight architectures)

Preferred alternative workflow if MBDT + DL integration is not recommended
If full integration and auto code generation are not recommended/supported, what is the preferred workflow to deploy an AI model on S32K3? For example:

- Converting the model to lightweight C inference code manually

- Using CMSIS-NN-like approaches (if applicable)

- Using any NXP middleware / recommended libraries / examples (e.g., eIQ)

Thank you for your support. Any documentation links, training references, SDK examples, or best-practice recommendations would be very helpful.

Best regards,

[mariuslucianand]

Hello @SonHyunTaek,

Thank you for posting your detailed questions regarding your project on our community forum. Please note that the answers below are provided from the MBDT software perspective; from a hardware standpoint, there might be better approaches in terms of component combinations. It would also help to know the target voltage for your BMS and whether pack current sensing is required. Since you plan to use a single AFE connected via SPI, I assume you are targeting a maximum 48V BMS system.

Regarding the combination of devices you proposed: at the hardware level, the S32K3 is fully compatible with the MC33771B. However, from the software perspective, things are more complex. The MBDT for S32K3 is built to generate code on top of the NXP Real-Time Drivers (RTD) at the MCAL layer, while the MBDT for BMS generates code on top of the BMS SDK, which is also compatible with RTD. The BMS SDK includes an external configuration tool for pins, clocks, and peripherals, accessible from Simulink, along with ready-to-run examples.
Please note:

- MBDT for BMS 1.2.0 works only with MBDT for S32K3 1.4.0, which does not support the S32K388.
- The BMS SDK is compatible only with RTD 3.0.0, used by MBDT for S32K3 1.4.0. At that time, the S32K388 was not available.
- MBDT for BMS and MBDT for S32K3 support only newer AFE parts such as MC33774, MC33775, MC33664, MC33665, and MC33772C, typically used in hardware designs with Battery Junction Box functionality.

These limitations come from the software packages (RTD and BMS SDK). The MC33771B you intend to use includes a C SDK driver, which you must integrate manually into MBDT using custom code, as there are no ready-to-run compatible C drivers for connecting S32K3 and MC33771B. In other words, the Embedded SW: Battery Cell Controller Software Driver for MC33771B/MC33772B  requires manual C coding and integration into MBDT. An article describing how to do this (based on MBDT for S32K1) can be found here.

I will address your questions below and propose some solutions at the end.

1. MBDT Support and Training
The best resources we offer are available on the MBDT Community page.  On the right-hand side, you will find the Beginner's Guide for Model-Based Design Toolbox, which explains how to perform basic tasks with MBDT for S32K3. Additionally, there are BMS Webinars that provide insights into Battery Management Systems.
Here is a link to our latest webinar on BMS, created in collaboration with MathWorks:
Streamlining Battery Systems Development for NXP S32 Devices.

2. Integrating Deep Learning Models
In previous collaborations with MathWorks, we successfully deployed a Deep Learning-based State of Charge (SOC) estimation algorithm directly from Simulink and tested it in PIL mode. Yes, Embedded Coder can generate the neural network directly from the Simulink model, and together with MBDT, it can be deployed on the S32K3.
Here is a link to the related webinar:
Deploying a Deep Learning-Based SOC Estimation Algorithm to NXP S32K3 Microcontrollers

3. Real-Time Inference Feasibility on S32K388
Yes, real-time inference is feasible. In previous work, we used cell voltage, current, and temperature as inputs. These values can be measured by the AFE at runtime and provided to the neural network. As a best practice, intensive testing in PIL mode can help evaluate performance. You can also experiment with optimization techniques to identify the best configuration.

4. Safety Constraints
The logic for your safety requirements can be implemented in Simulink, and the corresponding code can be automatically generated. MathWorks provides an example we have used and deployed on S32K3:
Design and Test Lithium-Ion Battery Management Algorithms 

5. S32K388 Compatibility with FRDM-MC33771B-SPI-EVB and Alternatives
To test your neural network application directly from Simulink, use MBDT for S32K3 the latest version. This allows you to verify deployment feasibility and perform benchmarking tests on all the available MCU at this time.
From a hardware perspective, you have several options:

a. Continue with the proposed solution (S32K358 + MC33771C)
Start with MC33771C instead of MC33771B, as it is newer, supports SPI, and includes current measurement. You can integrate the MC33771C driver directly in Simulink using custom code and use MBDT for BMS 1.8.0.

b. Use MBDT for BMS in Simulink with supported MCUs
For example, S32K358 with MC33774/MC33775 for cell monitoring and MC33772C for current measurement (all over SPI). This setup works with MBDT for BMS and MBDT for S32K3 1.4.0. However, first test that the neural network runs on S32K358.

c. Use any S32K3 with AFE parts or the newest BMA7318
Note: There is no direct support for deploying code from Simulink using MBDT for BMS in this case. You can still generate application logic and neural network C code in Simulink, then manually integrate with the AFE using S32 Design Studio.

6. On-Device Training vs Inference-Only Workflow
This depends on your application requirements. Our previous approach was inference-only: train the network in MATLAB, then deploy it on the MCU. Recommended resources:
Battery State Estimation Using Deep Learning Followed by the webinar mentioned in point 2 above.

7. Performance and Memory Guidance for AI Inference on S32K388
Performance depends on your application. If the neural network is already trained, test the generated code in PIL mode on the S32K3 family, profile execution, and decide if S32K388 meets your needs. For reference, the SOC algorithm mentioned earlier was successfully tested on S32K344 and S32K358.

In summary, you can use Embedded Coder to generate code from your neural network and test performance in PIL mode. After validation, import the generated code into S32 Design Studio and deploy it on S32K388 as required.

Hope this helps,

Marius