As we learn of specific needs for specific use cases they will be noted here:

• PX4 BMS specification and working group discusses the need to provide 5V power to a drone before activating the actual battery power supply. The intent is to allow the host to identify the battery characteristics to avoid a catastrophic mismatch. Conceptually there is a need to supply 5V through the CAN /SBUS connectors to allow a host-side processor to power up and query the battery for compatibility with the drone. i.e. do not power up a 12S battery on a drone that only is designed for 3S or 4S

  • This functionality can be tested with the current revision of the board given a few jumper wires to the CAN/SBUS connectors. As built the +5V power is NC

  • Not clear if the battery can be asleep then woken up with a button press to supply power.

  • The 5V supply MAY only need to power a small MCU on the host side and not the complete host-side FMU. The small MCU could do the BMS query and then choose to power up the battery if in compliance.

• May be a trend toward 4 LEDS to show battery gauge status visually. We have one RGB led which we intend to flash a sequence and color to show battery status

  • Extra LEDs could be added on the expansion header

• The BMS itself doesn't regulate charging current or voltage, and needs a simple CC/CV charger. It can however balance it's own cells and disconnect the load. This situation could be improved by making a charger that talks with the battery over CAN and helps properly manage current and voltage, or even additional circuitry on board to manage this.

The RDDRONE-BMS772 integrates the following functions and features:

• LiPo Battery from 3s to 6s, with stack voltage ranging from 6V to 26V

• ambient temperature range from -20°C to 60°C

• measures battery stack and cell voltages with an accuracy of +/-5mV, battery charge or discharge current up to 200A peak and 90A* DC with an accuracy of 1% for the complete chain and cell temperature with an accuracy of +/- 2°C (including AFE, PCB and NTC inaccuracies)

• active cell balancing during charging

• offers a deep sleep mode (for transportation and storage) with <80μA leakage current, as well as an automatic sleep mode with <200μA current consumption on the battery.

• allows authentication of the battery

• allows diagnostics to verify the safe operation of the battery

• allows CAN, I²C and NFC communication

• implements SWD and JTAG debugging interfaces, works with standard Segger J-Link and other debuggers

• implements DCD-LZ combined debug and uart console interface for use with PX4 DroneCode and HoverGames platforms

Note: The 90A DC maximum current is obtained only when all MOSFETs and heatsinks are mounted. See Power MOSFETs and heatsinks.

The RDDRONE-BMS772 kit includes:

• Assembled and tested reference design in anti-static bag

• Unmounted cell balancing connectors for 3s, 4s and 6s

• CAN Bus Termination Resistor (DRONE-CAN-TERM)

• 4-pin JST-GH to 4-pin JST-GH 300mm cable

• Power input and power output connectors

• Quick start guide

• External thermistor with cable

• Small display

The RDDRONE-BMS772 is a standalone BMS Reference Design suitable for mobile robotics such as drones and rovers, supporting 3-6 cell batteries.

Other uses include portable electronics and equipment needing better battery management

• eScooters, ebikes

• high end power tools

• portable medical devices (Pulse oximeter, portable pumps, electric portable refrigerator)

• backup battery system

• outdoor monitoring/measuring equipment

It is an open hardware and software design and useful leverages components used in general purpose automotive and high-reliability industrial applications. The BCC device performs ADC conversion on the differential cell voltages and currents. It is capable of very accurate battery charge coulomb counting and battery temperature measurements.

The NXP MC33772 is a 6 cell BCC. If higher cell counts are required this could be redesigned to daisy chain multiple BCC chips or switch to a larger cell count BCC such as the MC33771. These parts are all automotive grade Li-Ion battery cell controller IC designed for automotive and industrial applications such as HEV, EV, ESS, UPS systems

The BMS772 also features an S32K146/144 automotive grade S32K Microcontroller. These are rugged M4 core processors part of a scalable family of AEC-Q100 qualified 32-bit Arm® Cortex®-M4F and Cortex-M0+ based MCUs

An NTAG5 Boost NFC NFC Forum-compliant I2C bridge is also onboard and appears as an NFC contactless tag to the external world, and interfaces internally in a simple manner similar to an EEPROM for easy secure query of status or setting of parameters using an external NFC device such as a cell phone. In a practical sense this allows an end user to check multitudes of batteries that may be in storage just by hovering their cell phone over them.

An A1007 is an enhanced version of A1006 secure authenticator IC which includes monotonic counters and secure flags. These can be used to prove the battery pack is genuine and has not been tampered with as well as securely count charge cycles, and permanently flag negative events such as over discharge. The Secure Authenticator IC is a secure tamper-resistant authentication IC, which offers a strong cryptographic solution intended to be used by device manufacturers to prove the authenticity of their genuine products

Finally, the BMS communicates with a host such as a Drone Flight Management Unit (FMU) through DRONECAN/CyphalCAN or I2C/SMBus.

The RDDRONE-BMS772 is a standalone BMS Reference Design suitable for mobile robotics such as drones and rovers, supporting 3-6 cell batteries. Other portable electronics and equipment, such as scooters, power tools, portable medical devices could also benefit from referencing this design. If higher cell counts are required this could be redesigned to daisy chain multiple BCC chips or switch to a larger cell count BCC.

The device performs ADC conversion on the differential cell voltages and currents. It is capable of very accurate battery charge coulomb counting and battery temperature measurements. Additionally, it communicates with a Flight Management Unit (FMU) through UAVCAN and/or an SMBus.

These boards have been designed and optimized for the operating conditions described below. Usage of these boards beyond these conditions can lead to malfunction and damage.

[1] These values are valid for a 4 pairs of power MOSFETs and 4 heatsinks configuration. See Configuring the hardware for more information

Featured devices

The board features several NXP ICs:

• MC33772: 6-Channel Li-Ion battery cell controller IC designed for automotive and industrial applications such as HEV, EV, ESS, UPS systems. The MC33772 allows ADC conversions on the differential cell voltages and currents as well as coulomb counting and temperature measurements. It features embedded balancing transistors and diagnostics to simplify applications. The device supports standard SPI and transformer isolated daisy chain communication (via MC33664) to an MCU for processing and control

• S32K144: AEC-Q100 certified microcontroller for general purpose automotive applications. The S32K144 features an Arm® Cortex®- M4F core, 512 KB of Flash, CAN/CAN-FD controllers, security module complying with SHE specification and is offered in LQFP-48, LQFP-64, LQFP-100 and MAPBGA-100 packages supporting an ambient temperature range from -40°C up to 125°C

• UJA1169: Mini high-speed CAN System Basis Chip (SBC) containing an ISO 11898-2:201x (upcoming merged ISO 11898-2/5/6) compliant HS-CAN transceiver and an integrated 5V or 3.3V 250 mA scalable supply (V1) for a microcontroller and/ or other loads. It also features a watchdog and a Serial Peripheral Interface (SPI). The UJA1169 can be operated in very low-current Standby and Sleep modes with bus and local wake-up capability

• A1007: A1007 authentication IC is a secure solution built with many tamper resistant features and security countermeasures to deter common invasive and non-invasive attacks

• NTAG5: NXP’s NTAG 5 boost shrinks the NFC footprint while adding AES security, so designers can deliver ultra-compact devices for use in IoT, consumer, and industrial applications

IC board location identifiers

The main ICs featured are listed in the table below:

Connectors

The following figure shows the location of the connectors on the board.

All connectors implemented on RDDRONE-BMS772 are detailed in the table below:

Note: Hardware configuration of the board is done via 16 jumpers to solder (SJxx). See Cell terminal connection, Shunt resistor and External NFC antenna for more details.

Communication with Flight Management Unit

The RDDRONE-BMS772 board can communicate with a host device such as a PX4 Flight Management Unit (FMU) using the SMBus bus (can also be used as a simple I²C bus, connector J18) or the UAVCAN bus (can also be used as a simple CAN bus, connectors J3 and J20).

Note: For further information about UAVCAN, look for enablement in PX4.io software.

Programming and debug

There are two ways to program and debug the RDDRONE-BMS772 board:

• through the DCD-LZ connector (J19)

• through the JTAG connector (J2)

Note: The DCD-LZ combines a debug interface with a debug serial console. It is used on RDDRONE-FMUK66 (HoverGames). For more information see the HoverGames gitbook.

LED

The RDDRONE-BMS772 implements a programmable RGB LED. Various color combination and blink patterns can be used to indicate the state of the battery and system.

Button

The side button is a wake button, it connects the WAKE pin of the SBC to the ground when pressed. The J22 header placed in parallel of the side button can be used as an alternative if an extended or panel mount button is needed.

Display

An external display could be used to display important (battery) information. This display can be connected to J23, the I²C master bus. This header could be supplied with 3.3V (D34) or 5V (D35, default populated). By switching the diode, 3.3V or 5V could be used.

Example of 0.91 inch OLED display using SSD1306 I2C display controller

External and additional components

External components

An optional external temperature sensor can be added onto the RDDRONE-BMS772 board using connector J1. An example of application for this external sensor can be to monitor the cells temperature inside the battery pack.

Additional components

Some components are included in the design but are not mounted on the RDDRONEBMS772 original board. They are marked "DNP" on the schematics and the BOM. The following table is giving the list of additional components that can be implemented in the design as well as their use:

Test point definitions

The following figure shows the location of the test points on the board.

The following part of the schematic is copied here to assist users with wiring cell terminal connections based on custom battery packs. Typically hobby style LiPo Batteries are already wired correctly and will be plug and play. The key item to note is the JP1 pin 7 is the negative most CT on the battery pack. The next pin up JP1 Pin6 will be one cell voltage higher than JP7. Similarly Pin 5 will be one votage higher thatn Pin 6. This continues until the end of the cell count depending on how many cells you have configured the BMS for on the previous page,

Downloading J-link

Download J-Link Software and Documentation Pack

J-Link Commander is used to flash binaries onto the RDDRONE-BMS772 board. The latest (stable) release of the J-Link Software and Documentation Pack is available at the SEGGER website for different operating systems.

Connecting the programmer to the BMS

The software can only be written to the board using a debugger. The HoverGames drone kit includes a J-Link EDU Mini debugger. To use it, you need to install the J-Link Software Pack.

The debugger can be plugged into the BMS using a small adapter board. This small PCB comes with a 3D printed case that can easily be put together. The J-Link debugger can be connected using an SWD cable. The connectors have to be oriented such that the wires directly go to the side of the board, as shown in the picture below.

While you do not need it right now, the adapter board also has a 6-pin connector for a USB-TTL-3V3 cable, which you can use to access the system console (CLI) of the BMS. The 3D printed case has a small notch on one side of the connector. The USB-TTL-3V3 cable needs to be plugged in such that the black (ground) wire is on the same side as this notch in the case. Make sure the cables are plugged in as shown in the picture below. Connect the 7-pin JST GH to the programming header of the BMS, J19.

Flashing the firmware

A guide for flashing firmware to this board is outlined in one of our consolidated GitBooks for flashing a multitude of NXP hardware. The link to this GitBook is below. https://nxp.gitbook.io/mobilerobotics/software/flashing

Next steps

Once you're done flashing your board, you may continue to the Accessories and tools for development tutorial.

The board is organized as shown in the figures below:

The example starter software provided with the BMS uses the NuttX RTOS (real-time operating system ) for microcontrollers. NuttX RTOS has an emphasis on being standards compliance and small footprint. Scalable from 8-bit to 32-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. The POSIX compliance on embedded devices is what makes it attractive particularly to developers that are used to programming in a Linux environment. The NuttX code repository can be found here: https://github.com/NXPHoverGames/RDDRONE-BMS772 Please follow the step by step instructions in the github readme.md in order to get started with this code. We will update it and provide clarifications there as needed.

Currently the RDDRONE-BMS772 is supported in the Model-Based Design Toolbox (MBDT) for Matlab/Simulink. See https://community.nxp.com/t5/NXP-Model-Based-Design-Tools/Example-Model-RDDRONE-BMS772/ta-p/1550394.

First start-up

Before first start-up, make sure the board is configured properly:

1. Solder your power in and power out connectors or wires on the J4 and J5 footprints

2. Solder the correct cell terminal connector at the JP1 location. Ensure it is correctly positioned and aligned

3. Configure the board for your application by soldering the corresponding SJxx connectors

4. Configure the board with additional and/or optional components as described in Configuring the hardware to fit the application requirements

5. Power the board

If you make use of the NuttX BMS example:

1. Make sure you have the latest software (latest version is 6.0)

   1. See https://github.com/NXPHoverGames/RDDRONE-BMS772/tree/main/Binary

2. Configure the SW correctly, see First Time software configuration of the BMS

Powering the RDDRONE-BMS772 board on and off

Once the board is configured properly (see Configuring the hardware for more details about configuration), it is time to connect the board.

To power on the RDDRONE-BMS772 board, *first* connect the battery to the power input connector (J4) and then the cell terminal connector (JP1). This protects the boards form internal damage due to hot plugging.

Similarly, to disconnect the battery from the board, the cell terminal connector (JP1) should be disconnected first. Then the power input (J4) can be disconnected.

Software example

The software example being developed for the RDDRONE-BMS772 board will use a NuttX Real-Time Operating System (RTOS).

Note: NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 32-bit microcontroller environments, the primary governing standards in NuttX are Posix and ANSI standards.

CAUTION - WARNING

Lithium and other batteries are dangerous and must be treated with care.

NXP has battery emulators that may be used during testing: https://www.nxp.com/design/development-boards/analog-toolbox/6-cell-battery-pack-to-supply-mc33772-evbs:BATT-6EMULATOR

Important Notice

NXP provides the enclosed product(s) under the following conditions:

This reference design is intended for use of ENGINEERING DEVELOPMENT OR EVALUATION PURPOSES ONLY. It is provided as a sample IC pre-soldered to a printed circuit board to make it easier to access inputs, outputs, and supply terminals. This reference design may be used with any development system or other source of I/O signals by simply connecting it to the host MCU or computer board via off-the-shelf cables. Final device in an application will be heavily dependent on proper printed circuit board layout and heat sinking design as well as attention to supply filtering, transient suppression, and I/O signal quality.

The goods provided may not be complete in terms of required design, marketing, and or manufacturing related protective considerations, including product safety measures typically found in the end product incorporating the goods.

Due to the open construction of the product, it is the user's responsibility to take any and all appropriate precautions with regard to electrostatic discharge. In order to minimize risks associated with the customers applications, adequate design and operating safeguards must be provided by the customer to minimize inherent or procedural hazards. For any safety concerns, contact NXP sales and technical support services. Should this reference design not meet the specifications indicated in the kit, it may be returned within 30 days from the date of delivery and will be replaced by a new kit.

NXP reserves the right to make changes without further notice to any products herein. NXP makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does NXP assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages.

Typical parameters can and do vary in different applications and actual performance may vary over time. All operating parameters, including Typical, must be validated for each customer application by customer’s technical experts.

NXP does not convey any license under its patent rights nor the rights of others. NXP products are not designed, intended, or authorized for use as components in systems intended for surgical implant into the body, or other applications intended to support or sustain life, or for any other application in which the failure of the NXP product could create a situation where personal injury or death may occur. Should the Buyer purchase or use NXP products for any such unintended or unauthorized application, the Buyer shall indemnify and hold NXP and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges NXP was negligent regarding the design or manufacture of the part.

To use this BMS772 kit, you will need:

Additional items needed

• LiPo battery pack

  • 3S to 6S with cell balancing connector - Voltage range of 6V to 26V

• Suitable charger for the type of battery

• Soldering iron to configure the board

• External Thermistor temperature sensor with cable and JST-GH 2-pin connector (optional)

• Debugger:

  • Segger J-Link Mini debugger

  • PEMicro universal multilink

  • or other suitable JTAG/SWD debugger

Software tools and sources

• S32 Design Studio for ARM-based MCUs (recommended)

• Alternatively : PX4 or NuttX build environment depending on what code source is used.

• PX4/NuttX board target example code (optional, see Software guide)

Note: The RDDRONE-BMS772 board allows to open the charge circuit when the battery is overcharging , to perform cell balancing and to monitor all cell voltages. Therefore the charger does not need to have a cell terminal connector.

The DroneCAN documentation for this board can be found in the release notes version 6: https://github.com/NXPHoverGames/RDDRONE-BMS772/blob/main/BMS772_releaseNotes_6.0.pdf Be sure to download this to get the full PDF. See:

• Chapter 8.4: How to use the DroneCAN interface

• Chapter 8.4.1 How to set up the DroneCAN GUI tool and start dynamic node ID allocation

• Chapter 8.4.2 How to use the DroneCAN GUI tool to configure the BMS

• Chapter 8.4.3 How to use the DroneCAN GUI tool to monitor the DroneCAN messages

• Chapter 11.5.8.1 DroneCAN messages implemented

First make sure the BMS is connected to the UCAN board

Connect the CypahlCAN device (like the RDDRONE-UCANS32K146) to the BMS using JST GH 4 pin connectors with 1 on 1 wires. End the CAN bus with a 120Ω terminator resistor between CAN high and CAN low.

Get the BMS draft using the UCAN board in linux:

1. Connect the UCAN board with a USB-TTL-3V3 cable to the laptop.

2. Install the can utils with the following terminal command:

   • sudo apt install can-utils

3. Install python 3.7 with the following terminal command:

   • sudo apt install python3.7

4. Install pyuavcan with the following terminal command:

   • python3.7 -m pip install pyuavcan

5. Start the deamon on UART <-> SLCAN to use SLCAN0 use the command (for ttyUSB1):

   • sudo slcand -o -s8 -t sw -S 115200 /dev/ttyUSB1

1. Enable the interface (up)(same as ifup can0 in nuttx) write the following command:

   • sudo ip link set up slcan0

2. Clone the cannode v1 tools:

   • git clone https://github.com/PetervdPerk-NXP/cannode-v1-tools

3. Make sure the sub modules are in the git repository write the following command in the cannode-v1_tools directory:

   • git submodule update --init

4. Find this line in print_bmsstatus_topic.py:

   • media = pyuavcan.transport.can.media.socketcan.SocketCANMedia('can0', mtu=8)

5. Change it to the right can device, for example:

   • media = pyuavcan.transport.can.media.socketcan.SocketCANMedia('slcan0', mtu=8)

6. Run the pyuavcan tool by typing the following in a terminal where the print_bmsstatus_topic.py file is located:

   • python3.7 print_bmsstatus_topic

Keep in mind that the BMS needs to be configured correctly, see the CyphalCAN chapter of the SOFTWARE GUIDE - NUTTX.

To use the command line interface, connect the debugger to the BMS using the 7-pin JST-GH connector from the debug adapter board to J19 and plug the USB coming from the debugger converter board into your computer. Open a UART terminal like minicom on a Linux machine or PuTTY or Tera Term for a windows machine.

Type “bms help” to get the help for the CLI. The CLI works only with lowercase commands.

The settings are:

• 115200 Baud

• 8 data bits

• 1 stop bit

First start-up messages

When first starting the BMS with the latest software the command line interface could look like the code snipping at the end of the page.

You can see that the version number is: bms6.0-11.0. this comes after "BMS version: ". Than it will begin doing self-tests.

• START means it will start testing that part or component

• PASS means that the test succeeded

• FAIL means the test did not succeed

Be sure to check the error messages as it could help finding out what is wrong, some errors explain why it went wrong and how you could fix it. It could be that you will get these messages:

CRC of saved data doesn't match!
Setting old values!
nothing/wrong saved!

These messages mean that the CRC of the saved data (the parameters) in flash doesn't match. This could happen when nothing is saved or when a new program is flashed in the microcontroller (and thus cleared the flash). Than it could be that you get the message "NVMS registers don't have the right value!". This means a register in the SBC needs to be written, but before this could take effect, it needs to restart the SBC, "Restarting!" is stated when it does this. Since the SBC supplies the microcontroller with its power, the microcontroller will restart as well.

NVMS registers don't have the right value!
SBC_CONF: 8 != 4
MTPNV_STATUS: RX0: 225, RX1: 1
overwritting NVMPS registers
START_UP_CTRL W: RX0: 230, RX1: 0
SBC conf ctrl W: RX0: 232, RX1: 8
Restarting!
CRC W: RX0: 234, RX1: 0

It could be that you get the message that the stackvoltage is too different from sum of cells, so there is a wrong n_cells number. This means that the actual connected cells are different than the entered number of cells (n-cells). To fix this, check what the current n-cells value is with "bms get n-cells" and make sure it corresponds with the number of cells in the attached battery. To configure the correct number of cells type "bms set n-cells x" where x the number of cells of the battery, that can be 3-6. After that type "bms reset" or press the button to reset the fault. In version 3.4 there is something wrong, n_cells should be n-cells.

bcc_monitoring ERROR: stackvoltage too different from sum of cells! stack:   19.160V cells:    9.601V
batManagement: ERROR: wrong n_cells!
Please set the correct cells! using "bms set n_cells x"

You will get a warning if the battery temperature sensor is not enabled, "WARNING: battery temperature sensor is disabled!". To enable the battery temperature sensor see How to enable the battery temperature sensor.

If you see the text that the BCC overvoltage set to <number>mV. That number should be slightly higher than the actual set cell-ov in the software. This is because the overvoltage threshold register of the BCC is an 8-bit register, compared to the floating point variable in the software this has a lot less resolution. The value in the BCC is set slightly higher to not falsely trigger on it, but have it as a backup trigger since the software will react on the overvoltage as well with the measured cell voltage.

BCC overvoltage set to 4218mV

It could be that you see the following line: "NOTICE: Disabling 5V regulator (CAN transceiver) briefly!". This happens when the SBC needs to switch modes, because it can only be done in the standby mode where the 5V regulator is disabled.

NOTICE: Disabling 5V regulator (CAN transceiver) briefly!

"BMS main loop!" means the BMS has entered the main loop and will continue according to the main state diagram.

Each time the BMS enters a new mode, it will output this with "<mode> mode"

Here we see the output for version 4. but it should still be similar.

nsh> B�EG                                                                       
Starting BMS                                                                    
             total       used       free    largest                             
Umem:        40528      11328      29200      29200                             
Starting can0                                                                   
ifup can0...OK                                                                  
BMS version: bms4.0-10.1                                                        
SELF_TEST mode                                                                  
SELF-TEST LEDs: START                                                           
SELF-TEST LEDs: PASS                                                            
CRC of saved data doesn't match!                                                
Setting old values!                                                             
nothing/wrong saved!                                                            
SELF-TEST GPIO: START                                                           
SELF-TEST SBC: START
NVMS registers don't have the right value!
SBC_CONF: 8 != 4
MTPNV_STATUS: RX0: 225, RX1: 1
overwritting NVMPS registers
START_UP_CTRL W: RX0: 230, RX1: 0
SBC conf ctrl W: RX0: 232, RX1: 8
Restarting!
CRC W: RX0: 234, RX1: 0
nsh> B�EG                                                                       
Starting BMS                                                                    
             total       used       free    largest                             
Umem:        40528      11328      29200      29200                             
Starting can0                                                                   
ifup can0...OK                                                                  
BMS version: bms4.0-10.1                                                        
SELF_TEST mode                                                                  
SELF-TEST LEDs: START                                                           
SELF-TEST LEDs: PASS                                                            
CRC of saved data doesn't match!                                                
Setting old values!                                                             
nothing/wrong saved!                                                            
SELF-TEST GPIO: START                                                           
SELF-TEST SBC: START                                                            
Setting SBC to normal mode!                                                     
SELF-TEST SBC: PASS                                                             
SELF-TEST BCC: START                                                            
WARNING: battery temperature sensor is disabled!                                
If this needs to be enabled write: "bms set sensor-enable 1" in the terminal    
BCC overvoltage set to 4218mV                                                   
SELF-TEST BCC: PASS                                                             
SELF-TEST GATE: START                                                           
SELF-TEST GATE: PASS                                                            
SELF-TEST CURRENT_SENSE: START                                                  
SELF-TEST CURRENT_SENSE: PASS                                                   
SELF-TEST NFC: START                                                            
SELF-TEST NFC: PASS                                                             
SELF-TEST A1007: START                                                          
SELF-TEST A1007: PASS                                                           
SELF-TEST GPIO: PASS                                                            
ALL SELF-TESTS PASSED!                                                          
BMS main loop!                                                                  
NOTICE: Disabling 5V regulator (CAN transceiver) briefly!                       
INIT mode                                                                       
NORMAL mode                                                                     
Started                                                                         
                                                                                
NuttShell (NSH) NuttX-10.1.0                                                    
nsh> 

The help command

To view the help of the commands of the bms, type "bms help" in the terminal (CLI). Than you will see this window:

nsh> bms help                                                                   
This is the bms cli (command line interface) help                               
These commands can be used with the bms:                                        
bms help                  --this command shows this help                        
bms help parameters       --this command shows the <parameter> list             
bms help show-meas        --this command shows the <show-meas> list             
bms get <parameter>       --this command gets a parameter value.                
                            parameter is the parameter you want                 
bms get all               --this command gets all the parameters                
                            including the values                                
bms set <parameter> <x>   --this command can be used to set a parameter         
                            WARNING this could lead to unsave operations!       
                            WARNING only use this command in a safe manner!     
                            parameter is the parameter you want to set          
                            x is the new value of the parameter you want to set 
                            to enter a decimal value use "." as seperator       
                            to enter a string with spaces use "input string"    
bms show <show-meas> <x>  --this command can be used to show the cyclic 
                            measurement results 
                            show-meas is the to measurement to enable or 
                            disable visibility
                            if x is 1 the measurement is shown, if 0 it will 
                            be disabled
bms reset                 --this command will reset the fault when in the 
                            fault state
bms sleep                 --with this command it will go to the sleep state     
                            from the normal or the self_discharge state         
                            NOTE: if current is drawn it will transition to 
                            the normal state
bms wake                  --this command will wake the BMS in the sleep state   
bms deepsleep             --with this command it will go to the deep sleep state
                            from the sleep state or the charge state            
bms save                  --this command will save the current settings 
                            (parameters) to flash
bms load                  --this command will load the saved settings
                            (parameters) from flash
bms default               --this command will load the default settings         
bms time                  --this command will output the time since boot        
reboot                    --this command will reboot the microcontroller        
                            this command should be used without the word bms 
                            in front of it
                                                                                
some parameters have a letter in front of the "-", this indicates the type of 
parameter
a - capacity                                                                    
c - temperature (celcius)                                                       
e - energy                                                                      
i - current                                                                     
m - mass                                                                        
n - number                                                                      
s - status                                                                      
t - time                                                                        
v - voltage 

What parameters are there?

When you type "bms help parameters", you will get a list with all the parameters with its unit, if it is Read Only (RO) or Read Write (RW) and what the data type is it. These are useful parameter properties that help with filling in parameters correctly.

How can I see the cyclic update of the parameters?

The "bms help show-meas" command shows you which parameters you can view in cyclically in the CLI when the measurement happens. These commands should be used with the "bms show". To show them all, use "bms show all 1". if you want the measurements to be outlined and updated at the top of your terminal, use "bms show top 1". Keep in mind that if this is active, it could be that typed in characters disappear in this update.

How do I get parameter values?

To get a single parameter value, you could use the bms get command. If for example you would like to get the state of charge, type "bms get s-charge" in the terminal. It will provide you with the value and its unit. If you want to check a lot of parameters, use the "bms get all" command, this will give you the full list of parameters, with the value and its unit. When you wish to load the parameters from flash, type "bms load".

How do I set parameter values?

To adjust parameter values, you need to use the bms set command. If for example you would like to set the number of cells to 4, you need to enter the following command: "bms set n-cells 4". To make sure parameters are saved to flash, type "bms save". If you would like to set the default parameters, type "bms default".

What parameters can I use to change the state?

To get out of the FAULT_* state the BMS needs to reset the fault, type "bms reset". To get in the SLEEP state (if you are able to enter it), type "bms sleep". To wake-up from the sleep state, type "bms wake". To go to the DEEP_SLEEP state, type "bms deepsleep", it could be that it first self-discharges.

The display shows all kinds of battery information presented on an optional local I2C LCD display (e.g. SSD1306 type). The display should be connected to J23.

There is a framebuffer which makes sure the data is transferred to the display. Information like SoC, SoH, output status, BMS mode, battery voltage, average current, temperature and ID can be seen on the display.

By default the temperature sensor is not enabled. To configure the temperature sensor to be used, this temperature sensor need to be connected to J1 using a 2-pin JST-GH connector. The maximum length of the cable that leads to the temperature sensor is 20cm. This temperature sensor needs to be a 10k NTC, like the NTCLE100E3103JB0 from Vishay. With the CLI type:

“bms set sensor-enable 1”.

this will enable the temperature sensor measurement to be done together with the rest of the measurements in the BMS software.

The main state machine

In Figure 2 the main state machine that will be implemented in the BMS can be found. This state diagram will be implemented in the BMS main loop.

Main state machine explained

SELF TEST state

The SELF TEST state is entered at power-up of the microcontroller. In this state the microcontroller initializes everything and performs the self-test, for example check if communication with a component is possible or check if the set output can be read. If everything is OK, it will go to the INIT state. If a watchdog reset has occurred not every self-test will be done to make sure the power is not turned off. The LED will be solid red in this state.

INIT state

The INIT state is typically entered from the SLEEP state. In this state the microcontroller unit (MCU) will wake up and it will verify configurations, fault registers and functions. This is needed because it can enter the INIT state when the user resets from a fault in one of the FAULT states as well. When everything is OK, it will close the power switch if not already closed and proceed to the next state depending on the current direction. The LED will be steady green in this state.

NORMAL state

This is the state where the battery operates how it should be, it is being discharged by the connected device, for example a drone. Meaning that the power switches are closed. The LED will be blinking green to indicate the state of charge. In this state the BMS performs the following tasks:

• Battery voltage, cell voltage and current is measured and calculated every measurement cycle.

• SoC and SoH are estimated every measurement cycle.

• The DroneCAN/CyphalCAN BMS battery status will be send over the CAN bus every measurement cycle.

• The user can read the BMS status and parameters with NFC and the CLI. The user may change the state to SLEEP.

• A timer will monitor if the current is below the sleep current for more than the timeout period. If this happens, it will go to the SLEEP state.

• It will monitor if the current flows in the battery and if the current is more than the sleep current for more than the charge detect time, the state will change to the CHARGE state.

• If the current is less than the sleep current while the button is pressed for 5 seconds, it will transition to the SELF DISCHARGE state.

CHARGE state

During this state the same functions as in the NORMAL state are implemented. The charging of the battery is done in different stages and is reflected in the charging state diagram in Figure 3. These are the states and their description:

• CHARGE START: in this state the charging will begin, and a timer will start. The LED will be blue to indicate charging. After a set time (default 120sec) or if the voltage of one of the cells reaches the cell overvoltage level (to make sure there is no cell overvoltage error) the state will change to CHARGE WITH CB.

• CHARGE WITH CB: in this state the cell balancing (CB) function will be activated. This function will calculate the estimated cell balance minutes per cell, which is based on the cell voltages, the difference compared to the lowest cell voltage, the balance resistor and the OCV-slope. The formula to calculate this estimated balance time is: Estimated balance minutes = (Vcell - Vcell_min ) * Rbal / (Vcell * ocvslope) Other than this calculated time, the BMS will check if the voltage of a cell that is being balanced, has reached the desired voltage as well. When the voltage of one of the cells reaches the cell overvoltage level or the charging current is less than the charge complete current, it will go to the RELAXATION state. The LED will stay blue and will blink if cell balancing is active. Balancing is finished if all the calculated cell balance minutes are expired or it has reached the lowest cell voltage.

• RELAXATION: in this state the power switches are set open, disconnecting the charger from the battery. The MCU will be put in a very low power run (VLPR) mode (BMS application STANDBY mode), SBC in standby mode and the BCC to measure only at 10Hz. This will reduce the power in this state. The battery will relax for the specified relax time (default 300 sec). During this relaxing, the cells can still be balanced since this happens with a low balancing current. At the end of the relaxation period, the system will check whether the balancing is done. If balancing is not finished, the BMS will re-estimate the balance minutes. If balancing is finished and the highest cell voltage is lower than the cell overvoltage minus the voltage margin, it will return to the CHARGE WITH CB state to continue the charge process. If the highest cell is within this margin, the charging is complete, and it will go to the CHARGE COMPLETE state. To make sure it won’t endlessly go through this cycle with the CHARGE WITH CB state (this can happen if the end of charge current is met but the voltage requirement is not met), after 5 times it will just not check if the highest cell voltage is within this margin and will go to the CHARGE COMPLETE state

• CHARGE COMPLETE: in this state, the charging is done, and the LED will be steady green. If the lowest cell voltage decreases again below the cell overvoltage minus the recharge voltage margin, it will go to the CHARGE WITH CB state again. The power switches will remain open and if the charger is disconnected it will go to the SLEEP state after the defined period of time.

If at any time the current flows from the battery to the output and this current is higher than the sleep current, the BMS transitions to the NORMAL mode. If a charger is disconnected, the state will transition to the SLEEP state. If the go to deep sleep command has been given or the button is pressed for five seconds there are two options: If one cell voltage is less than the storage voltage it will complete charging until each cell has reached the storage voltage, after this is done the BMS will transition to the SELF DISCHARGE state and this will then transition to the DEEP SLEEP state. The other option is that no cell voltage is less than the storage voltage, than the BMS will transition to the SELF DISCHARGE state.

SLEEP state

The sleep state is typically entered when the current is very low for an amount of time. This SLEEP state is used to preserve power. The MCU will be put in VLPR mode, the SBC in standby mode, the BCC in sleep mode with measurement on to check for a sleep overcurrent and other faults. This is the BMS application VLPR mode. The power switches will be closed to make sure the battery could be used. If any threshold is met during a cyclic measurement or the button is pressed, it will wake the MCU and the BMS will transition to the INIT state to check status. If the button is pressed for five seconds, the state will change to the SELF DISCHARGE state, in order to go to the DEEP SLEEP state. If the t-sleep-timeout happens the BMS will go to the SELF DISCHARGE state and will discharge the battery to storage level. After this it will go to the DEEP SLEEP state. In this state the LED will be off.

OCV state

The OCV state will allow to record the latest open cell voltage (OCV) of the battery which is used in the state of charge (SoC) computation. Cyclically the Battery will enter this mode when the Battery stays in the SLEEP state. The period the system will go from the SLEEP state to the OCV state will depend on the time since the battery has entered the SLEEP state in the first place, without going to another state except the OCV state. The time to enter the OCV state will gradually increase each time with 50% from the set begin time until the set end time is reached. If for example the set begin time is five minutes and the set end time is twenty-four hours, it will take fifteen times to have a period of is twenty-four hours. When entering this mode, the MCU will wake up the AFE and measure. After it has calibrated the SoC, it will go to the SLEEP state again. The LED will blink green in the OCV state.

FAULT_ON state

The FAULT_ON state is entered when a critical fault has been detected (over-current, over-voltage, cell over-temperature) and requires evaluating if the battery needs to disable the output power. In this state the power will remain ON. With the flight-mode-enable and the i-flight-mode parameter, the user can make sure that the battery will not be disconnected from the power out connector and the BMS will stay in this state. If the s-in-flight parameter is high, it will stay in this state and not disconnect the power. Except, when the i-peak-max threshold is reached.

The s-in-flight parameter is high if the i-batt-avg (1s) is higher than i-flight-mode and the i-batt-avg (1s) is less than the i-out-max AND the flight-mode-enable is high.

The s-in-flight will be low again when: the i-batt-10s-avg is lower than the i-flight-mode and the i-batt-avg (1s) is less than the i-flight-mode. OR s-in-flight will be low when the flight-mode-enable is set to 0 OR when there is a i-batt-avg (1s) charge current higher than the i-sleep-oc ((1s_current_avg - i-sleep-oc) > 0). If the BMS is in the FAULT_ON state and s-in-flight will become false, it will go to the FAULT_OFF state.

If the BMS needs to turn off the power, it will go to the FAULT_OFF mode. Other ways to exit this FAULT_ON state is that the user can manually force the BMS to go to the INIT state via the reset fault command with the CLI or by activating the push button. If there is an undervoltage fault, it could transition to the DEEP SLEEP state after the t-fault-timeout time. In this state the LED will be solid RED to indicate the power is still on.

FAULT_OFF state

The FAULT_OFF state is entered when there is a fault and it needs to turn off the output power. In this state the power will be turned OFF. Usually, this state is entered because in the FAULT_ON state it noticed that it needs to turn off the power. It will go directly in the FAULT_OFF state if the emergency button is used and this button is active or if a hardware overcurrent is detected. To exit this FAULT_OFF state is that the user can manually force the BMS to go to the INIT state via the reset fault command with the CLI or by activating the push button. If there is an undervoltage fault, it could transition to the DEEP SLEEP state after the t-fault-timeout time. In this state the LED will be blinking RED to indicate the power is off.

SELF DISCHARGE state

This state is used to discharge the cells to the cell storage voltage in order to improve its life duration, when storing the battery for long time. In this mode, the power switches are open, the MCU is powered and the balancing functions are activated. When the storage voltage is reached for each cell or if cells have a lower voltage, it will transition to the DEEP SLEEP state. CAN communication is disabled. To get a better SoC estimation, the OCV is measured and this will update the SoC measurement of the battery. To exit this state and to go back to the INIT state, the button needs to be pressed. The LED will blink blue in this state

DEEP SLEEP state

This state is used for transportation and storage. In this state, the power switches are open, disconnecting the battery, all protections are turned off, there are no cyclic measurements done, the LED is off, and it will set everything to sleep or off to ensure the lowest power usage (<100uA). Only the button can wake everything in this state. When the button is pressed, it will transition to the SELF_TEST state. When entering this mode, the MCU will check if at least one configuration parameter has changed. If configuration parameters have changed, it will save the parameters to flash to make sure they are loaded at startup. The LED will be white for 1 second before going off for the rest of the time in this state.

Software block diagram

Figure 1 the software block diagram can be found. The BMS application consists of several tasks that run semi parallel (since it is still a single core processor). These tasks use functions from software components. The NuttX RTOS will take care of switching between tasks. The CLI part is called by calling the BMS application from the nuttshell interface with commands. The nuttshell is the serial (or UART) communication to the NuttX RTOS and can be used to communicate with the BMS application. The explanation of the blocks can be found in below in Component description.

Component description

CLI

The command line interface (CLI) component takes care of communication with the user through the NuttX nutshell, it can be used during debugging of the smart battery application or a specific battery under test. The communication is mapped to use a universal asynchronous receiver-transmitter (UART) also known as the root console. The CLI can output messages in colors if the ANSI escape sequences are enabled in the terminal.

The application command may be followed by optional arguments such as:

· sleep

· deepsleep

· wake

· reset

· help

· show

· set

· get

With the set or get command the user can read and write every value, including the configuration parameter list. These values can be read/written by calling the BMS application followed by a set or get command followed by the name of the variable. In the case of a set command this would instead be followed by the new value of the variable. Try the command “bms help” to see the help of the CLI. For more information on using the parameters, see chapter https://app.gitbook.com/o/-L9GLsni4p7csCR7QCJ8/s/4sYITYOw8lqjlbpxfe9d/~/changes/1/software-guide-nuttx/untitled-1

DroneCAN / CyphalCAN

There can only be one of these two CAN components active at the same time, either the DroneCAN component or the CyphalCAN component. This can be set via the parameter “can-mode”. After setting this, do a “bms save” and a “reboot” to apply the change.

The DroneCAN module manages the DroneCAN communication as the name already suggested. There are 2 parts of this communication, the synchronous and the asynchronous communication. For that reason, there is a task running to take care of both communications.

The synchronous communication is the updates of the different battery information messages. This is done with a certain update rate, depending on the message. If the BMS measurement interval is more than 1 second, it will influence this as well. These messages can then be sent regularly to the DroneCAN bus. Other devices connected to this bus can then read the messages, these devices could for example be an FMU/VMU for a drone or rover or other devices. This update with new data gets triggered via the updater task.

The asynchronous communication is when another DroneCAN device on the DroneCAN bus is requesting data. This can be battery data or a BMS parameter. Or another DroneCAN device would like to change a parameter of the BMS. When this happens, it is not triggered by the updater task, but the DroneCAN task will take care of this.

For the CAN communication, it will use the CAN PHY in the SBC (UJA1169).

If configured corrected, you could see the battery information in PX4, ArduPilot or QGroundControl.

CyphalCAN is supported as well, please see chapter "CyphalCAN".

LED state

The LED state module can be used to control the RGB LED. It can set an RGB color on or off and blink the LEDs at given intervals. If a LED needs to blink a blinker task will be used to ensure it blinks. This module is used to inform the user visually of various states and status.

This part is used implement the LED states given below

SMBus

SMBus is an alternative way to communicate BMS information to a host device that has I2C, like an FMU/VMU. The BMS could be seen as an I2C peripheral device. Reading from specified BMS I2C registers allows the device to read BMS data. Data like voltages, temperatures, state of charge, average current could all be read from these registers. The SMBus needs to be enabled with the variable “smbus-enable” to work.

NFC - NTAG5

The NFC module manages NFC communication. NFC communication can be used to read all kind of battery parameters. Via NFC a device should be able to read the values with a refresh rate of once a second. The updater task will be used to update the data in the NTAG5 NFC device. It can operate in a similar manner to a double ported EEPROM, and NFC records can include standardized messages for HTTP or text records. In this way the NFC tag could be updated regularly with status information. That information could be added to text message, and for example a smartphone would be capable of reading the message with data attached, this is done with minimal coding effort. This method removes the need for any custom software on the reading device.

Authentication - A1007

The authentication module will take care of the authentication using the A1007 chip. The A1007 is capable of secure asymmetric key exchange and storage as well as secure monotonic counters and flags for use in such things as counting charge or discharge cycles or permanently flagging under-voltage or over-temperature conditions.

This component is not implemented yet. Only IC presence verification via I2C is implemented.

Display

The display module manages information presented on an optional local I2C LCD display (e.g. SSD1306 type). The display should be connected to J23. Both 3.3V and 5V are supported in the software. There is a framebuffer which makes sure the data is transferred to the display. Information like SoC, SoH, output status, BMS mode, battery voltage, average current, temperature and ID can be found on the display. This makes sure the user can easily see the battery information it needs.

Power (MCU power mode)

The power component is used to control the MCU power modes. There are 3 BMS application power modes that are made which each mode for its own purpose.

RUN mode

• RUN mode

  • In this mode, the MCU power mode is set to RUN mode. The MCU will run on an 80MHz clock. All needed peripherals are enabled.

  • This is the usual mode of the MCU.

• STANDBY mode

  • In this mode, the MCU power mode is set to (Very Low Power Run) VLPR mode. The MCU will run on an 2MHz clock. At this low clock speed, the BMS is saving a lot of power.

  • Both SPI modules and the serial interface (CLI) is active to still have communication with the BCC, SBC for the WD and potentially a user.

  • This mode is a lot slower, but it saves a lot of power while still maintaining a connection to be able to measure as well.

  • One use case of this mode is during the CHARGE-RELAXATION state. You need to monitor the voltages, but this does not need to be a fast loop as the power to the charger is disconnected and thus you make sure the cells are not drained as much as in the RUN mode.

• VLPR mode

  • In this mode, the MCU power mode is set to (Very Low Power Run) VLPR mode. The MCU will run on an 2MHz clock. At this low clock speed, the BMS is saving a lot of power.

  • Only the SBC SPI module and the serial interface (CLI) is active to still have communication with the SBC for the WD and potentially a user.

  • This mode is a lot slower, but it saves the most power. There is no monitoring of the battery. The MCU relies on an GPIO interrupt pin from the BCC for waking up.

  • One use case of this mode is during the SLEEP state. No power is drawn, and you want to drain the battery as little as possible, while still reacting on a use command to for example configure the BMS. If current is drawn, the mode will change to NORMAL or CHARGE and the MCU mode will change as well.

SBC (LDOs + CAN + W.D.) - UJA1169

The SBC module manages the power of the voltage regulators in the SBC. With this module the SBC can be set in normal mode, standby mode and sleep mode. In the normal mode both V1 (powers the MCU and more “VCC_3V3_SBC”) and V2 (powers internal CAN PHY and 5V “VCC_5V_SBC”) are powered. In standby mode, V2 is off and in sleep mode both regulators V1 and V2 are off. The sleep mode is needed for the DEEP SLEEP state. The SBC provides an external watchdog as well. The main loop will “kick” (reset) the watchdog at the end of the loop.

Bat management - MC33772B

The Bat management (battery management) part is the most important part, it will oversee the whole battery management. It will be used to monitor the battery, the PCB (temperatures) and calculate voltages, temperatures, current, SoC, SoH, average power and more. It will ensure the BCC chip (MC33772B) reacts if thresholds are exceeded. Functions of this part can be used to drive the gate driver IC, which allows it to disconnect or connect the battery from the BMS output power connector. Because this is such a large part of the system, the Bat management part has its own tasks. This task can not only utilize the functions in the batmanagement component, but has a configuration component to configure the BCC, a monitoring component to monitor the battery data and a balancing component to take care of balancing. All these components can access the BCC libraries. These libraries can access the NuttX drivers like the timers and the GPIO (reset BCC pin).

The batManag task will oversee the measurements and if triggered, it will do the calculations, check for errors, check for transition currents and handle the cell balancing / self-discharge. In the SW, the measured battery data and calculated battery data is put in two structs. It will save the newly made battery data and calculation data structs in the data part and trigger the updater task that there is new data available.

Data

Since different parts need to use the same data, a data library is made to take care of this. This library will make sure it is protected against usage at the “same” time by multiple tasks. If you set a parameter, it will make sure the system will act on it.

Power connectors

Because the RDDRONE-BMS772 board aims to be adaptable for many different battery types, the power connectors are not mounted on the PCB. This allows the user to configure the board with the connectors they choose, or solder battery wires directly to the board.

The power connectors footprints on the design correspond to an XT90 hobby type connector such as the DFRobot FIT0588 connector. These types of connectors are readily available at local and online hobby shops and may also be used for soldering typical silicone insulation heavy gauge power wires.

TE connectivity has created a line of UMP (Unmanned Power) connectors specifically for professional high power mobile systems. Some kits ship with this type of connector included as a promotional item.

Cell terminal connection

The RDDRONE-BMS772 board is configurable to fit 3s to 6s battery packs.

The correct cell terminal connector should be soldered as JP1 on the top side. Connectors for 3s, 4s, and 6s are provided unsoldered in the kit.

• the connection to the cell terminal circuit should be done by soldering the correct solder jumpers as given in the table below. All jumpers are open by default

Note: SJ13, SJ14, SJ15 and SJ16 are not used for cell terminal connection. See Shunt resistor and External NFC antenna.

Note: The other jumpers used for cell terminal connection (SJ1 - SJ12) should be open!

Note: The JP1 connector should be soldered on the top side of the board.

Shunt resistor

The shunt resistor (R1) can be disconnected from the overcurrent protection circuit and the BCC by unsoldering the SJ13 and SJ14 jumpers. Both jumpers are closed by default.

External NFC antenna

The on-board NTAG5 chip is designed to provide active antenna matching and amplification and will give enhanced performance when the battery is present and providing power. However, for extended range operation, the PCB antenna can be replaced by an SMD coil (L2). The coil is not mounted by default but the recommended part is SDR7045-2R2M. Also note that it is possible to solder wires and attach a remote NFC antenna to the same pads used for L2.

To use the SMD coil, the user must reconfigure the board using the following steps:

• remove both 0.75 Ω resistors R93 and R94

• solder close SJ15 and SJ16

• replace 82pF and 680pF capacitors C72 and C116 by a single 56pF capacitor

Power MOSFETs and heatsinks

The RDDRONE-BMS772 board allows placement of four pairs of power MOSFETs (PSMNR70-30YLH) and four heatsinks (FK 244 08 D2 PAK). Half of them is on the top side of the board and the other half is on the bottom side. By default, only the two pairs of MOSFETs of the top side are mounted.

The user may want to place additional MOSFETs and/or optional heatsinks to their board. This allows to widen the maximum DC current limit as described in the following table:

Note: Exceeding the given current limit can permanently damage the board.

Optional components

Depending on the application, the user may want to add some optional components onto the RDDRONE-BMS772 board.

External and additional components and their use are detailed in External and additional components.

This is about the following code repository: https://github.com/NXPHoverGames/RDDRONE-BMS772

Main

In the main source file, the BMS main can be found, this is the BMS application. This function will initialize each part and start the main loop task. This task will implement the battery main state machine as seen in Figure 2 (https://app.gitbook.com/o/-L9GLsni4p7csCR7QCJ8/s/4sYITYOw8lqjlbpxfe9d/~/changes/1/software-guide-nuttx/bms-application-state-machine). In the main source code, the state is changed. In this source file there is a function to handle a changed parameter as well. This function will call other functions from the needed parts to do something with the parameter that is changed. If for example a configuration changed, such that a configuration of the BCC needs to change, it will call the right function from the Bat management part to change the configuration of the BCC as well. At the end of the main loop, the watchdog in the SBC is kicked. If this is not done in time, it will reset the MCU.

Data

There is a lot of data that is needed or set by different tasks. Because it is not wise to move this big chunk of data through all the tasks there needs to be some sort of shared memory. Because NuttX is POSIX compliance there are shared memory functions that could be used. But for these shared memory functions a memory management unit (MMU) is needed and this microcontroller does not have an MMU. That is why the whole data management will be made in a data source file. This makes sure the data is only made once and is not global. With functions the data can be read or written, and these functions ensures protection against multiple threads accessing the data at the same time. These functions can be seen in Figure 5.

To protect the data from multiple threads trying to access it at the same time, a mutex is used. A mutex is an object that can be locked and unlocked in an atomic operation. Meaning that if both threads want to lock the mutex, the threads cannot lock the same mutex at the same time. A mutex is needed to prevent data race. The other thread needs to wait until the mutex is available.

The big data chuck is in a struct, together with a parameter info array. This array supports a fast access of the data type, the minimum, the maximum and the address of the data. This ensures it is faster to get and set data than with a large switch.

If a variable is set with the set parameter function. It will check if the variable is changed. If the variable is changed, it will call a handle parameter change function. This function will check which parameter has changed and will set other parameters if needed. At the end there is a callback to the main which will make sure the correct functions / reactions are being called. There are parameters that have an effect on the battery management and thus a function that handles changes in the battery management part is called as well to react on the parameter that changed. Next to handling the change of a parameter, this function will check if one of the savable parameters has been changed. If this is the case, it will remember this to save the parameters to flash when the DEEP SLEEP state is executed.

CLI

In NuttX there is a nuttshell, this is the UART communication with the MCU. In this nuttshell, applications can be called with or without arguments. There arguments will be given to the function it calls, in this case the BMS main. This means that a CLI can be created with calling the application with some arguments.

This CLI that is made, can be used by calling the BMS application in the nuttshell with a command and optionally up to 2 arguments for that command. When this happens the BMS main is called. Meaning that this main needs to be resistant against multiple calls, this should not restart the BMS application because than the battery power will be cut.

If there are commands given when calling the BMS application, the CLI process commands function will be called to handle it. It will parse the command and optionally the arguments and check if the inputs are valid. If it is valid, it will act based on which command has been given. The flowchart can be seen in Figure 6.

LED state

In order to set a color to the RGB LED, the set led color function should be used. The flowchart of this function can be found in Figure 7. Because this function can be used from different tasks, a mutex will be locked before it checks if the color and if blink is already set. This function will set the semaphore to start or stop the blink sequence. It will skip the semaphore timed wait function to ensure the blink sequence restarts if needed. It will begin with the new color. This function will use the NuttX userled functions.

GPIO

In order to use a GPIO in NuttX, these GPIO’s need to be defined in the board file and the board specific GPIO file. This will create devices for each GPIO pin. To use the GPIO in the application an IOCTL call needs to be used. IOCTL means input-output control and it is a device specific system call.

The IOCTL is used to give commands to a driver to control a device, in this case the GPIO pins. But for an IOCTL to work an open file descriptor needs to be given. This is obtained by giving the path to the device as a string. This is too much work to do in the application for setting or reading a GPIO, that is why a GPIO BMS application driver is made. This will make sure that a GPIO can be read or written with simple write/read pin functions and a define to indicate the pin. An input pin can be an interrupt pin On an interrupt it will generate a signal that will queue the action for the handler. Keep in mind that these signals can be very intrusive.

Bat management

The Bat management part can be used to monitor the battery and control the power switch. Because the Bat management part is quite large, there are other source files made to help with functions it needs to do and with utilizing the BCC. Like monitoring, to take care of measurements. Configuration, to take care of the whole configuration for the BCC. Balancing, to add easy to implement balancing function. For the main to implement the state machine, functions are made to let the main implement the functionality. Some functions are made to enable the measurements, to check for faults, to self-discharge etc.

The batManag task is created to handle the battery management. It will start the manual measurements with the BCC. Mostly it will calculate and check the current or it will measure and calculate every variable at t-meas interval. It will then perform a measurement, calculate the variables, save the values, it will check for software faults, it will calculate the new transition variables, handle the cell balancing if needed and it will trigger the callback that new measurements have been done. When saving the data, it will save the new measured and calculated variables in one go using the structs. Because the BCC will not check for an overcurrent, the current needs to be read and calculated every time to be compared with the current threshold. For short circuit protection there is a hardware circuit. If it measures a fault, it will trigger the main to act on it.

The sequence of the batManag task can be seen in Figure 8. The sem_wait and sem_post functions are called consecutively in the endless loop, this is used to start and stop the task with a function from the main. The meas task will check if the next measurement needs to be the measure everything or just the current and calculate the wait time to make sure the t-meas interval is met or with the remaining wait time. The task will wait for the next time or when the measurement is enabled, it will measure right away. To make sure the cyclic measurements does not drift, the time before the loop starts and the period t-meas are gained. The target time is calculated by adding the period with the previous target time. If t-meas should change, this is updated in the sequence using a global variable. This is left out of the sequence diagram because it is too detailed.

To calculate the state of charge (s-charge), the coulomb counter is used. The coulomb counter register holds the sum of the measured currents (until read). There is another register that holds the number of samples in the coulomb counter register. The average current is calculated by dividing the sum of the currents by the number of samples. When the time is known for which the average current is calculated, the difference in charge can be calculated with the following formula: ∆Q=I_avg*∆t. The new remaining charge is calculated by adding the difference in charge with the old remaining charge. The state of charge can then be calculated by dividing the full charge capacity by the remaining charge.

In order to provide the average power consumption over a time period of ten seconds, a constant moving average is taken. This moving average is constructed by removing the oldest measurement and adding the new measurement, which is than divided by the amount of measurements. This way the average will only be of the last ten seconds. In order to be memory efficient, the measurements used in the moving average will be sub-sampled if the measurement period is configured as less than one second. This way maximum ten old measurements need to be known. Measurements are not lost when sub-sampling, because the BCC chip will remember an average of it.

Since the user can change configurations in run time, sometimes a configuration needs to be changed in the BCC as well. When there is a change in the configuration, this is set with the setParameter function and a task in the main source file will handle the change. This function will call a function to handle the change in the bat management part. In this part it will call the right function from the configuration source file to change the configuration of the BCC.

The batManag task will check for software measured faults. The BCC chip will take care of hardware fault monitoring for the overvoltage, undervoltage, over temperature and under temperature. It will set the fault pin high when there is an error. If this happens it will trigger an interrupt in the main and it will check what fault happened. The main can than act on the fault. This ensures that the main is in control of what happens.

Since the user can change configurations in run time, sometimes a configuration needs to be changed in the BCC as well. When there is a change in the configuration, this is set with the setParameter function and a task in the main source file will handle the change. This function will call a function to handle the change in the bat management part. In this part it will call the right function from the configuration source file to change the configuration of the BCC.

SBC

The SBC part is used to control the power of voltage regulators V1 (The most used 3.3V (VCC_3V3_SBC)) and V2 (CAN PHY) (VCC_5V_SBC). With the setSbcMode() function the mode of the SBC can be set. In the normal mode both V1 and V2 are active, in the standby mode V2 is off, turning off the CAN transceiver and in the sleep mode both V1 and V2 are off, turning off almost the whole BMS board. In Figure 10 the simplified flowchart of this function can be seen. Besides power regulators, the SBC has a watchdog, which is used to reset the MCU if it doesn’t "kick" (reset) the watchdog within the set time. The reset of the MCU this is done via the NRST pin.

DroneCAN or CyphalCAN

This part works with a DroneCAN (or Cyphal) task that waits (it sleeps until a CAN transceiver signal comes in) for an incoming CAN transmission. It will also wake up if the main signals the task that new data needs to be send. When new data needs to be sent, the task will put the data that needs to be sent in the transmit buffer. It will check if the transmit buffer if it is filled and transmit the data if it is. Then it will wait for an incoming CAN transmission or signal again. To see the flowchart see Figure 10: DroneCAN flowchart below.

There are DroneCAN and Cyphal messages implemented. Keep in mind that you can only select one at the time. The DroneCAN messages can be seen below in "DroneCAN messages implemented".

The CyphalCAN messages are a snapshot of the CyphalCAN V1 with WIP DS-015. This consists of 3 messages, the energy source, the battery status and the battery parameters. These messages can be seen in "CyphalCAN messages implemented"

DroneCAN messages implemented

For information on the DSDL message definition used for DroneCAN, please see the .uavcan files:

• ardupilot_equipment_power_BatteryContinuous

  • DSDL/ardupilot/equipment/power/20010.BatteryContinuous.uavcan at master · dronecan/DSDL · GitHub

• uavcan_equipment_power_BatteryInfo

  • DSDL/uavcan/equipment/power/1092.BatteryInfo.uavcan at master · dronecan/DSDL · GitHub

• ardupilot_equipment_power_BatteryPeriodic

  • DSDL/ardupilot/equipment/power/20011.BatteryPeriodic.uavcan at master · dronecan/DSDL · GitHub

• ardupilot_equipment_power_BatteryCells

  • DSDL/ardupilot/equipment/power/20012.BatteryCells.uavcan at master · dronecan/DSDL · GitHub

• ardupilot_equipment_power_BatteryInfoAux

  • DSDL/ardupilot/equipment/power/20004.BatteryInfoAux.uavcan at master · dronecan/DSDL · GitHub

Table 1. DroneCAN battery continuous message

Table 2. DroneCAN battery info message

Typical publishing rate should be around 0.2~1 Hz.

Table 3. DroneCAN battery periodic message

Battery data to be sent statically upon request or periodically at a low rate

Recommend that this message is sent at a maximum of 1Hz and nominally 0.2 Hz (IE: once every 5 seconds.).

Table 4. DroneCAN battery cells message

Rate: set by parameter on smart battery (default off).

Table 5. DroneCAN battery info auxiliary message

CyphalCAN messages implemented

Table 6. Energy source 0.1 CyphalCAN udral

Table 7. Battery status 0.2 CyphalCAN udral

* not implemented in the BMS example code

Table 8. Battery parameter 0.3 CyphalCAN udral

How to use the (Cyphal)CAN interface

Connect the CyphalCAN device (like the RDDRONE-UCANS32K146) to the BMS using 2x JST-GH 4 pin connectors with 1 on 1 wires. End the CAN bus with a 120Ω terminator resistor between CAN high and CAN low.

Get the Battery status draft using the UCAN board in Linux:

1. Make sure you Connect the UCAN board with a USB-TTL-3V3 cable to the laptop.

2. Install the can utils with the following terminal command:

   o sudo apt install can-utils

3. Install python 3.7 with the following terminal command:

   o sudo apt install python3.7

4. Install pyuavcan with the following terminal command:

   o python3.7 -m pip install pyuavcan

5. Start the deamon on UART <-> SLCAN to use SLCAN0 use the command (for ttyUSB1): o sudo slcand -o -s8 -t sw -S 115200 /dev/ttyUSB1

Keep in mind that in this case the UART of the UCAN board needs to be connected to ttyUSB1. One can check which USB it is by disconnecting the USB-TTL-3V3 cable connected to the UCAN board, write “ls /dev” in the terminal, connect the USB cable and write “ls /dev” again. Only the USB of the UCAN board should be added in the list. If not check if the USB connection of the used virtual machine is passed through.

1. Enable the interface (up)(same as ifup can0 in nuttx) write the following command: o sudo ip link set up slcan0

2. Clone the cannode v1 tools:

   o git clone

3. Make sure the sub modules are in the git repository write the following command in the cannode-v1_tools directory:

   o git submodule update --init

4. Find this line in print_battery_service.py:

   o media = pyuavcan.transport.can.media.socketcan.SocketCANMedia('vcan0', mtu=8)

5. Change it to the right can device, for example:

   o media = pyuavcan.transport.can.media.socketcan.SocketCANMedia('slcan0', mtu=8)

6. Run the pyuavcan tool by typing the following in a terminal where the print_bmsstatus_topic.py file is located:

   o python3.7 print_battery_service

7. Make sure the BMS CAN mode is in cyphal mode:

   1. bms set can-mode cyphal

8. Check if the subject IDs of the messages are correct

   1. cyphal_es_sub_id should be 4096.

   2. cyphal_bs_sub_id should be 4097.

   3. cyphal_bp_sub_id should be 4098.

9. Check if the node id of the BMS is not 225

   o In the CLI of the BMS type “bms get cyphal-node-static-id”, if this is 255, it needs to be changed to another value (like 12). Do this with “bms set cyphal-node-static-id 12”

   o After that save it and reboot the bms with “bms save” and “reboot”.

The BMS is not able to limit the current. It can only disconnect the battery from the output. For charging make sure a current limited power source is used and set the limitation to the right value. The BMS is not able to limit the voltage. For charging, the charge voltage should be limited as well.

To get more information about the charging process see CHARGE state on the page.

The tasks of the BMS have different priorities, this is needed because some tasks/activities are more important than others. For example, one needs to react fast on a fault, so the system needs to prioritize a fault above blinking the LED. The BMS uses the NuttX preemption, which means that lower priority tasks get interrupted by a higher priority task. The task priorities can be seen in Figure 4.

When one of the BCC functions is called (via the spiwrapper), the task is locked so it can’t switch tasks. This way it makes sure it will execute the function OK, otherwise there could be CRC errors or NULL responses

This page will describe the variables of the BMS. There are 6 kind of parameters

1. The common battery variables

2. The calculated battery variables

3. The additional battery variables

4. The configuration variables

5. The CAN variables

6. The hardware parameters

The BMS parameter lists

The common battery variables list

Table 1. Common battery variables list

The calculated battery variables list

Table 2. Calculated battery variables list

The additional battery variables list

Table 3. Additional battery variables list

The configuration variables list

Table 4. Configuration variables list

The can variables list

Table 5. Can variables list

A line means this is not implemented yet.

* These parameters will only be implemented during startup of the BMS

The hardware parameters

Table 6. BMS hardware parameters list

A line means this is not implemented yet.

It is highly recommended that you check each parameters in and make sure to configure each parameter. Use "bms get all" to get each parameter and it's value, so you could configure each one for your battery. Some parameters you would like to configure are:

• battery-type (Which battery type do you have? 0=LiPo, 1=LiFePO4, 2=LiFeYPO4, 3=NMC, 4=Sodium-ion)

  • This will change the under- and over-voltage, storage voltage, nominal voltage and the OCV curve it uses to correct the state of charge

• n-cells (the amount of cells of the battery) [3 .. 6]

• sensor-enable (to enable the battery temperature sensor) [0=disable, 1=enable]

• a-rem (the remaining capacity) [Ah]

  • the BMS does a guess on what the remaining charge is based on a OCV(open cell voltage)/SoC (state of charge) table from one specific battery, but every battery is different.

    • It is advisable to insert the correct OCV/SoC table for the battery.

• a-factory (the factory capacity of the battery) [Ah]

  • What is the capacity stated on the battery?

• a-full (the full charge capacity of the battery) [Ah]

  • while charging, the BMS will calculate this based on a-rem

  • If unknown, set to the same value as factory capacity after the next step

• model-name (the name of the battery)

• i-charge-full (the end of charge current of the battery (could be 10% from i-charge-max)) [mA]

• i-charge-max (the maximum charge current) [A]

• i-peak-max (the maximum peak current threshold [A])

The NXP MBDT includes an integrated Simulink®-embedded target supporting NXP MCUs for direct rapid prototyping and built-in support for software- and processor-in-the-loop (SIL and PIL) development workflows, systems and peripherals device interface blocks and drivers, a target-optimized Math and Motor Control library set (AMMCLib) for efficient execution on the target automotive MCUs and Real-Time Control Embedded Software Motor Control and Power Conversion Libraries (RTCESL) for other MCUs, and bit-accurate simulation results in the Simulink® simulation environment.

The NXP MBDT helps to generate all the code required automatically (including initialization routines and device drivers) to start up the MCU and run complex applications such as motor control algorithms and sensor-based and communication protocols while supporting builds with multiple compilers. The NXP MBDT supports a wide range of applications development and helps enable control engineers and embedded developers to shorten project life cycles.

For a BMS772 MBDT example, see this article: https://community.nxp.com/t5/NXP-Model-Based-Design-Tools/Example-Model-RDDRONE-BMS772/ta-p/1550394

More information can be found here:

• https://www.nxp.com/design/design-center/software/automotive-software-and-tools/model-based-design-toolbox-mbdt:MBDT

• https://nl.mathworks.com/products/connections/product_detail/nxp-model-based-design-toolbox.html

• https://community.nxp.com/t5/NXP-Model-Based-Design-Tools/Model-Based-Design-Toolbox-for-S32K1xx-Automotive/ta-p/1107844

The MC33772B Battery Cell Controller (BCC) comes with a SW package. This package contains embedded SDK SW driver for NXP’s Battery Cell Controller products and example projects for S32K144 MCU and S32 Design Studio for Arm Version 2018.R1. It exists in a Lite and a Full version:

• The Lite version is implemented and used in the NUTT-PX4 software. It allows controlling the BCC and performing its main tasks, as: measuring Cell Terminal (CT) voltages, current, temperatures, analog inputs, etc.. It is available on NXP.com

• The Full version complements the Lite version by adding diagnostics and safety to it. This package can be useful for users wanting to add a safety layer on their applications. It is available under NDA on Docstore

There is a full safety library for the Battery Cell Controller (BCC) IC. This library is only available under NDA and thus has not been added to this example code.

This software is available to selected customers via a required non-disclosure agreement (NDA). For additional information contact support or your local sales representative.

To enable the update, be sure to set smbus-enable to 1 with “bms set smbus-enable 1”. If this is enabled, one can use the BMS as an I2C peripheral device to get the information. Use the J18 connector (I2C/SMBUS) on the BMS, hook up your I2C initiator device with pull-ups to this connector. The SMBus information is based on the SBS1.1 specification. These are the supported messages:

Table 1. SMBus variable list