1. Introduction
The article presents a basic application in Simulink® for the MR-BMS771 that can be used as a starting point for a Battery Management System application. The configuration provided covers most of the peripherals available on the MR-BMS771 reference design.
1.1. Board Overview
The MR-BMS771 is a standalone Battery Management System reference design, suitable for mobile robotics projects (drones, rovers) which require from 8 up to 14 cells. These cells can be LiPo cells, but other chemistries, like LiFePO4, work as well.
The main components are:
MCU: S32K146 (S32K1 Microcontroller for Automotive General Purpose)
Battery Cell Controller: MC33771C (14 Channel Li-Ion Battery Cell Controller IC)
System Ba Chip: UJA1169A (Mini High-Speed CAN System Basis Chip)
SIC Transceiver: TJA1463 (CAN Signal Improvement Capability Transceiver)
1.2. Board pinout
(High quality images can be found in the 'MRBMS771_PINOUT.zip' achieve at the bottom of this article)
1.3. Prerequisite software
MATLAB® R2016A
Simulink®
MATLAB® Coder™
Simulink® Coder™
Embedded Coder® Support Package for ARM® Cortex®-M Processors
S32K1xx MBDT Toolbox Version 4.3.0
FreeMASTER Run-Time Debugging Tool
1.4. Prerequisite hardware
MR-BMS771
CAN Bus Terminator Resistors (DRONE-CAN_TERM)
OLED Display 128x32 pixels
External Thermistor with cable
Serial to USB converter
CAN interface for USB
14-cell Battery Emulator
12V DC Power Supply
Multilink Debug Probe
1.5. Hardware connections
Connect the followings:
OLED display to J23
CAN Terminator to J28
CAN interface for USB to J3
Serial to USB converter to J19[2] and J19[3]
J27 to J20 (connect both CAN instances to the same bus)
Debug probe to J2
2. Model configuration
2.1. Initialize the model
The first step that must be done when creating an application using the S32K1xx toolbox is to create a blank Simulink model and add the MBD_S32K1xx_Config_Information block. To add a block from S32K1xx toolbox to a model, open the Library Browser and search for NXP Model-Based Design Toolbox for S32K1xx MCUs, then select the desired block and drag and drop it into the canvas of the Simulink model previously created.
The configuration block must be configured for the MR-BMS771: select the Target MCU->Family to S32K146 and CLOCK->XTAL Frequency MHZ to External 32. Depending on the deploying method used, settings must be modified in Target Connection. In this example, the download on the target is done via JTAG using the USB Multilink PEMicro.
2.2. System Basis Chip – UJA1169ATK
The System Basis Chip (SBC) is an external component that integrates a CAN transceiver and various functions, such as an external watchdog, a serial peripheral interface or LIMP output. In the MR-BMS771 design, the UJA1169ATK is used to provide a High-Speed CAN transceiver and a configurable watchdog.
Out of the box, the SBC is running in Forced Normal Mode, which means that the watchdog is disabled, but the CAN transceiver is operation. The SBC is initialized and configured via Low Power Serial Peripheral Interface 0 (LPSPI0).
Important! If the SBC is running in Normal Mode, the MCU must reset the watchdog, otherwise, the SBC triggers a hardware reset. Therefore, if the user wants to debug the application in S32Design Studio for ARM, the SBC must be either running in Forced Normal mode or in Software Development mode.
Note! To enable the Software Development Mode, the SBC must be running in Forced Normal Mode. Consult UJA1169A datasheet (7.12.2 Restoring factory preset values) for further details about restoring factory preset values.
Since the SBC is configured by the MCU via the LPSPI, the LPSPI0 must be initialized before the SBC config block. Drag and drop a LPSPI_Config block in the model and configure it as below:
Since the UJA1169 is an external IC, the configuration block can be found in External Devices:
2.3. Signal Improvement Capability Transceiver – TJA1463
Signal Improvement Capability (SIC) transceiver is an external component that allows the MCU to send/receive via high-speed classical CAN and CAN-FD. To put the transceiver in Normal mode, the following conditions must be met:
Enable pin (PTA6) must be set to high
Standby pin (PTB12) must be set to high (Note! Standby pin is active low)
2.4. FlexCAN
The Controller Area Network (CAN) is a standard communication protocol used in automotive world. Multiple devices can join the same CAN bus and transmit data to each other using only two differential signals: CAN high and CAN low. It is mandatory to use termination resistors to passively pull the state of the signals to a recessive state.
The configuration block for FlexCAN can be found in S32K1xx Core, System, Peripherals and Utilities -> Communication Blocks -> CAN Blocks.
In this example, both CAN interfaces are using to the same CAN bus, by the cable that connects the J27 to J20. Since the CAN interfaces are relatively close to each other and connected to the same CAN bus, only one pair of termination resistors are required.
The FCAN instance 0 is connected to the UJA1169 SBC via RX:PTE4 and TX:PTE5. The configured bitrate is 500Kbit/s.
The FCAN instance 1 is connected to the TJA1463 via RX:PTA12 and TX:PTA13. The configured bitrate must be similar to the CAN0’s bitrate (500Kbit/s).
2.5. Gate Driver
The gate driver is an interface between microcontroller and high-power components. It is controlled by a D-type flip flop, and it allows the MCU to disconnect the electrical loads attached to Power OUT pads from the power supply (Power IN pads).
To toggle the gate driver, a precise sequence must be followed. The Data Input pin of the D-type flip flop (U10) is active low and must be set to the desired state of the gate driver (set to low to enable the gate driver, respectively to high to disable it). The CLK pin of the flip flop is a rising edge triggered clock signal input pin. In order to propagate the state of the data input pin, the CLK must be set to low, then high and finally low again.
Note! To assure that this sequence is kept in order, it is recommended to manually set the priorities of each GPIO write block. To set the priority of a block, right click on the block then select ‘Properties’. The lower the number written in ‘Priority’ field represents the higher the priority of the block when the code is being generated.
2.6. SSD1306 OLED
The OLED display used in this example is a 128 x 32 pixels display. The data is sent from the MCU via the LPI2C0 (J23). This means that before adding the LCD_Config block, the configuration block for LPI2C0 must be added to the model. It can be found in S32K1xx Core, System and Peripherals and Utilities -> Communication Blocks -> I2C blocks.
This type of display is supported by the S32K1xx toolbox. The configuration block can be found in External Devices (in Library Browser).
To configure the display, select he LPI2C instance 0 and SSD1306 address to 60 (represented in decimal format, hex: 0x3C). It might be possible that the address of your display might differ.
Note! MCU configures the OLED via the I2C. Therefore, the LPI2C0 must be initialized before the OLED Config block.
Note! It is possible that height of the display might not be properly set. If the text on the screen doesn’t appear correctly, try to set the height to 64 pixels.
2.7. Battery Cell Controller (BCC) – MC33771C
The battery Cell Controller MC33661C is a Li-Ion battery cell controller IC designed for automotive and industrial applications. It supports both standard SPI and transformer isolated daisy chain communication (TPL). In the MR-BMS771 reference design, the SPI interface is used to communicate with the BCC.
Like the UJA1169 SBC, the first step is to add an LPSPI_Config block to the model. The only thing to configure now is to set the interface to LPSPI1 and make sure the correct pins are selected. The baud rate, role and other advanced settings are going to be configured later, directly from the BCC block.
The MC33771C is an external component, and the configuration block can be found in External Devices -> Battery Management System -> BMS_3377xC.
The following settings must be configured in MC3377xC_Config block:
Configuration tab:
General Settings:
Instance: 0
Mode: SPI
SPI Mode:
Device: MC33771C
Cell number: 14
SPI tab:
SPI instance: 1
SPI CS Selection: LPSPI1_PCS0
Pack settings tab:
Shunt resistance: 500 uOhm (shunt resistor R1 is mounted on the MR-BMS771)
Note! In the Configuration tab, the Instance dropdown refers to the BCC instance and not to the SPI instance used to communicate with the BCC.
After the MC3377xC_Config block is properly configured (especially after the SPI instance is selected), you need to click on the Config SPI for BCC as Master button from the SPI tab (highlighted by the orange rectangle in the image above). This way, the LPSPI1 is automatically configured to allow the MCU to properly communicate with the BCC.
Note! MCU configures the BCC via the SPI. Therefore, the LPSPI1 must be initialized before the MC33771C_Config block.
2.8. FreeMASTER
FreeMASTER is an user-friendly real-time debug monitor and data visualization tool that enables runtime configuration and tuning of the embedded software applications. The connection between MCU and FreeMASTER application can be done via the following interfaces:
UART
CAN
Debugger Probe/On-board debugger interface
In this example, the LPUART1 interface is used to exchange data with the FreeMASTER application. LPUART1 interface is accessible via the J19 connector.
The FreeMaster_Config block can be found in Utility Blocks category.
In the FreeMaster_Config block, the LPUART1 instance must be selected. The RX pin is PTC6 and TX pin is PTC7.
Note! In case the right cable is not available to be connected to the J19, the FreeMASTER can be used over the debug probe. In this case, the FreeMASTER config block is not required.
3. Structure of the application
The recommended workflow when developing an application using S32K1xx toolbox is to divide the application in 3 main parts:
Inputs
Algorithm
Outputs
The Inputs and Outputs parts are hardware depended (should include mostly S32K1xx blocks) and ideally, should only handle the peripherals connected to the MCU (e.g., read data from sensors/ICs, toggle LEDs, show data on a display etc.).
On the other hand, for a better reusability, the Algorithm should be kept hardware independent, it shouldn’t include any S32K1xx blocks. This part receives data from the Input part, does its computations, and then send the results to the Output part to take the corresponding actions.
The main advantage of this approach is that the Algorithm can be validated in simulation scenarios, such as Software-in-the-Loop (SIL) or Processor-in-the-Loop (PIL). Edge cases can be consistently reproduced in simulation environments, without risking to damage the actual hardware. For example, when working with Li-Ion cells, overtemperature or overvoltage real-world scenarios can damage the cells and might even start a fire.
Another advantage of keeping the Algorithm hardware independent is that it can use algorithms developed by other experts in MATLAB ecosystem, drastically reducing the prototyping time.
Moreover, in case the application must be ported to another NXP hardware platform, only the Input and Output must be updated with the new blocks, but the already validated Algorithm part can be moved to the new model without any modifications.
Taking all these suggestion into consideration, the application looks like this:
Input
MC3377xC_Get_Values block reads data from MC33771C Battery Cell Controller and stores it in multiple variables
MC3377xC_Fault_Get_Status block reads the error codes from the BCC, in case any fault is detected
Algorithm
Increment a variable and generate the message (subsystem GenerateFCANMessage) that needs to be sent via both FCAN interface
Generic_Algorithm is a dummy subsystem and formats the PackVoltage and PackCurrent to be properly displayed on the OLED display
toggleLED variable is negated at every step execution to toggle the onboard LED_GREEN
Output
UJA1169_Reset_Watchdog resets the SBC’s watchdog to avoid the forced restart of the MCU
FCAN0_Send_ID_0x3FE and FCAN1_Send_ID_0x3FE blocks send messages over the CAN interfaces. Messages with ID 0x3FE are sent over FCAN0 (UJA1169), whereas messages with ID 0x3FF are sent over FCAN1 (TJA1463)
LCD_Display_Current block displays the PackCurrent value on the first line of the OLED display
LCD_Display_Voltage block displays the PackVoltage value on the second line of the OLED display
Toggle_Green_LED block toggles the onboard green LED
4. Deployment
The application is now complete. The next step is to deploy it onto the target, MR-BMS771. To generate the code and download the generated files on the target, the Embedded Coder needs to be open, then the Build button should be clicked.
Right after the build process is started, the View diagnostic button becomes available, and it is a good practice to always have it open. It displays valuable information about the build process, such as various warnings or errors.
Note! The debug probe drivers are not bundled in the S32K1xx toolbox. Please visit the debug probe manufacturer to download and install the required drivers.
If the build process is successfully completed, the .mot and .elf files should be generated in the _rtw folder (automatically created next to the model). In the Diagnostic Viewer, the sizes for each section of the .elf file are displayed in Berkeley format.
Now, all the required files are generated and compiled. Depending on the settings from the MBD_S32K1xx_Config_Information block (Target Connection -> Mode -> Download code after build), the download process can be triggered. In the figure below is an example of a Diagnostic Viewer log of a complete deploy procedure (files generation, compilation and download).
Note! It is important that the SBC watchdog is not enabled, otherwise the MCU is restarted during the download procedure.
5. Validation
Once the application is deployed onto the target, FreeMASTER project can be opened (.pmpx file) to set up the communication protocol and to select the file (.elf) that contains all the information about the variables present in the model.
The communication interface used in this example is a USB-to-Serial convertor (step 3 in the image below). If the UART port used by the MR-BMS771 is not known, all ports can be checked and scanned (step 5). If a target is detected, a dialog appears to confirm the port and baud rate used.
Note! If an USB-to-Serial converter is not available, a debug probe can be used as a communication interface. At step 3, select the third option: Connect Through a debugger probe or on-board debugger interface. The next steps depend on the type of the debugger probe.
The next step is to verify that the .elf file used to read variables’ addresses has the correct path. Open the project’s Options and under the MAP Files tab, the path to the .elf file is shown.
Note! The .elf file is always generated in the _rtw folder created next to the model.
Finally, the data should be visible in the Variable Watch (as raw data) or in the Cell Voltages oscilloscope view.
Note! In order to access the variables in FreeMASTER application, they must be declared as volatile.
To read the messages sent on the CAN bus by both CAN interfaces, a CAN to USB converter is required. Message are sent in pair at each execution step. Messages with the ID 3FE are sent by CAN0 interface, while messages with ID 3FF are sent by CAN1 interface. The fifth byte of the message is incremented at each step.
5. Conclusion
This article presents an overview of the workflow when using the NXP Model Based Design Toolbox for S32K1xx. It enables most of peripherals available on a custom hardware design (MR-BMS771) and guides the user from the model creation up to application deployment and validation.
NXP is a trademark of NXP B.V. All other product or service names are the property of their respective owners. © 2023 NXP B.V. Arm, Cortex are trademarks and/or registered trademarks of Arm Limited (or its subsidiaries or affiliates) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. MATLAB, Simulink, Stateflow and Embedded Coder are registered trademarks and MATLAB Coder, Simulink Coder are trademarks of The MathWorks, Inc. See mathworks.com/trademarks for a list of additional trademarks.
View full article
