Introduction
This is a brief introduction explaining the powertrain domain controller reference design integrated the BMS and VCU in one ECU based on S32K376 MCU. BMS system monitors battery voltage, temperature and fault status, among other parameters of the vehicle. VCU sample simulates pedal position, gear, sensors, among other functions of the vehicle. Software is developed based on Real-Time Drivers (RTD). The reference design is intended to provide a mechanism for easy customer evaluation of the Arm Cortex-M7@320MHz four cores MCU, and to facilitate BMS and VCU hardware and software development. OTA and bootloader function are also integrated into this reference design which make program upgrade feasible. Fig1 shows the s32k376 system block diagram.
Fig.1: S32K37x system block diagram
Solution overview
The Figure 2 shows the system block diagram. Analog front-end(AFE) MC33774 is used to monitor battery status. Gateway MC33665 is used to transfer SPI signal to transport protocol link(TPL3). SBC FS2633 supply power for S32K376 and external devices. High-side device(HSD), low-side device(LSD) and Multiple Switch Detection Interface(MSDI) are used for vehicle control unit(VCU) function. CAN, LIN, UART are used to communicate with other ECUs. Real-Time clock(RTC) is used to read real time for BMS state of charge(SoC) calculation.
Fig.2: system block diagram
The Figure 3 shows the whole hardware battery monitor unit(BMU) board and lists each type of device. The detailed connector interface can be found in the schematic.
Fig.3: hardware BMU board
Hardware design
Please refer the doc AN747202-S32K39_37 MCUs Hardware Design Guidelines(0.2).pdf and S32K376 BMU and VCU Integration User Manual.pdf for the detailed hardware design.
MC33774: 18 Channel Li-Ion Battery Cell Controller IC ASIL D
MC33665: General Purpose BMS Communication TPL Transceiver and CAN FD Gateway
Software design
S32K376 BMS&VCU software is based on AUTOSAR drivers, including SW32K3 RTD, MC33774 BCC, MC33665 TPL PHY and SBC. It provides a series of AUTOSAR specific API to facilitate the BMS application designer to implemented the BMS application.
The Figure 4 shows the S32k376 BMS&VCU solution software block diagram. BMS function run on function core CM7_0, VCU function runs on lockstep core CM7_2, and monitor another two cores through IPCF. OTA and reserved OBC function run on the function core CM7_1. Bootloader and hardware OTA update application firmware. GUI display BMS and VCU information. All driver are based on AUTOSAR RTD.
Fig.4: BMS and VCU software block diagram
- Startup process and project structure
BMS, VCU and OTA run on different cores. The core0 is startup core, it starts up first than core1 and core2. The core0 initial all of system and peripheral clock and setup GPIO status. Using the CM7-x-ENABLE field of IVT boot configuration word(BCW) to disable core1 and core2 for avoiding core1 and core2 to execute any uninitialized peripheral. The core1 and core2 start up after core0 writes the correct address to the MC_ME module and enables clock.
The three cores projects are completely independent. Each core has by itself a startup file, linker file and memory layout. After compiling, three core's elf file will be generated. One elf file with three cores project is feasible, but we don't implement it here.
Inter-Platform Communication Framework (IPCF) is a subsystem which enables applications, running on multiple homogenous or heterogenous processing cores, located on the same chip or different chips, running on different operating systems (AUTOSAR, Linux, FreeRTOS, Zephyr, etc.), to communicate over various transport interfaces (Shared Memory etc.)
IPCF is designed for NXP embedded systems and features low-latency and tiny-footprint. It exposes a zero-copy API that can be directly used by customers for maximum performance, minimum overhead and low CPU load. The driver ensures freedom from interference between local and remote shared memory by executing all writing operations only in the local memory domain. CPU to CPU and directed interrupts are used to implement this function. BMS and VCU run in different cores, we use IPCF to send their framing data through CAN.
- Basic workflow of project
Figure 5 shows the project program work flow and lists the schedule time of each task.
Fig.5 Project programming flow diagram
The S32K396 Safety Software Framework (S32K396 SAF) is a software product which contains software components establishing the safety foundation for customer’s safety applications compliance with ISO 26262 functional safety. S32K396 SAF is a framework that implements the device safety concept system solution. Due to the SAF is not free for customer, for detailed information please refer S32K396_SAF_Safety_Manual.pdf and package S32K396_SAF_0.8.0. Figure 6 lists each component of SAF.
Fig.6 SAF component
- BMS safety library function
This is the S32K3 BMS SL SDK DEMO AUTOSAR 4.4 Version 1.0.0 release for the S32K3 platform. The Bcc_775a_SL, Bcc_774a_SL, Bcc_772c_SL and Bms_TPL3_SL_E2E libraries included in this release have DEMO quality status in terms of testing and quality documentation. Demo libraries are not qualified and contain partial feature set. It is not intended to be used in production This Demo version of the Safety Library is delivered in binary format and it's intended for evaluation purposes only. Due to the BMS safety library(SL) is not free for customer, for detailed information please refer RTD_BCC_774A_SL_UM.pdf and package SW32K3_BMS_SL_SDK_4.4_1.0.0_DEMO.
S32k376 BMS&VCU solution enables external safety mechanisms1, 2 , 3, 5 to monitor battery status. Customers cannot use it unless they purchase the BMS SL installation package. For detailed setup step, please refer to quick start guide document in NXP.com.
S32K376 has 6M flash space to store binary code that consist of three 2MB flash blocks. Bootloader is placed in the first flash block, and the three cores projects are divided into one flash block via link file and MPU. HSE is used for code switching in block 1 and block 2. A/B swap HSE firmware and secure boot assist flash(SBAF) is necessary to enable hardware OTA function.
Fig.7 s32k376 BMS and VCU project memory map
The project integrates OTA in Core1 and schedules it using FreeRTOS. The low level driver is based on Ethernet. For users of the S32K376 device with OTA enabled, the passive region can be read and written, and when an OTA update is performed, the new APP is always written to the passive region, but no program can execute in that region. The process of A/B swap is executed by hardware, no memory copy.
Fig.8: S32K376 hardware OTA update flow
- The OTA update agent-APP_V1 is first downloaded to the active block1(0x00600000) via the debugger and then starts running.
- When the OTA update is performed, the PC sends the new version of the OTA update agent-APP_V2, APP_V1 receives the binary file of APP_V2 and writes it to the block2(0x0800000) which is in passive.
- After partition swap and reset, the APP_V1 switchs to passive region, the new APP_V2 switchs to active region and runs.
Bootloader is provided to update the application via CAN bus in case there are no tools to download the application directly. S32k396_Bootloader is a standalone project which will be flashed on the flash block0, shown in Figure 28. The IVT information appears on the low address, so the code always starts up from the block0. Application is downloaded on flash block1 by bootloader.
GUI
This GUI displays data transmitted from BMS and VCU system via CAN bus. Hands-on instructions are listed below. For a detailed introduction, please refer to S32K376 BMU and VCU Integration User Manual.pdf.
Fig.9: S32K376 BMS and VCU GUI
S32K376 BMS and VCU demo platform
The figure 10 shows the s32k376 BMS and VCU demo platform. To see the detailed set up guide, please refer S32K376 BMSVCU_QSG.pdf and Getting started page.
Fig.10: S32K376 BMS demo platform
More information can be found here:
S32K376 Battery Management System (BMS) and Vehicle Control Unit (VCU)
S32K39/37 Microcontrollers for Electrification Applications