sfuphantom / bms-fw

Battery Management System - Firmware written for TMS570LS1227

bms-fw

Battery Management System - Firmware written for TMS570LS1227

bms-fw's Issues

Update thermistor state machine

Query the thermistor status and determine what state it should be in from the following:
THERMISTOR_GOOD, // Thermistor working properly
THERMISTOR_LOST_COMS, // Communication dropped with thermistor board
THERMISTOR_STARTUP, // Initialization state
THERMISTOR_TEMPERATURE_FAULT, // Less than 3 cells over 60 degrees
THERMISTOR_CRITICAL_FAULT // Shutdown tier fault

HV Shutdown Board Interface

• BMS_FLT is the input pin on the HV Shutdown Board coming from the BMS master that indicates a fault that should shutdown the HV system
  TODO: How long to keep the pin on for?
  TODO: what GIO pin BMS_FLT corresponds to on BMS master
  TODO: what criteria are to put BMS back in running state after a fault occurs

State of charge estimation research

Research into the different methods of state of charge estimation and coming up with a method that can realistically be integrated into embedded C code. In our system we have the voltage of each cell as well as total current available to us.

Add in ability to continuously read a sensor reading at a user-specified rate through CLI

Wanna be able to read any sensor reading eg. voltage, temperature at any rate we want such as "allvoltages 10" to read all voltages every 10ms

Create Defines for pl455 registers

Go through pl455 datasheet and create defines for the registers we use instead of just using the number of the register

Update BMS state machine

Query BMS for faults and determine what state it should be in

Add a UARTprintf function to Phantom SCI driver

Implement basic SOC Coulomb Counting algorithm

Check every function call for errors

Eventually need to check every function we call for it's return value and properly check errors

1D: Implement relevant tasks and their logic

Most of this will be categorizing how to distribute the task(s) amongst all the sensor reads being done. Hopefully, most of the reading logic is taken care of in the drivers and the structure/skeleton of the task/queue system is done in 4A

Perform battery profiling to obtain Open Circuit Voltage - State of Charge curve and implement look up table in SOC driver

We need to do battery testing and record the state of charge at different open circuit voltages as the battery discharges in order to create a look up table in the firmware to obtain SOC from OCV during the operation of the car

4C: Implement BMS CLI

There’s gonna be a lot of sensors on the BMS. Would be nice to see them in real time by just pressing certain keys. VCU has the basics of this implemented https://github.com/sfuphantom/vcu-fw

https://github.com/sfuphantom/bms-fw/tree/BMS-4C-Implement-CLI

Output:

• Readme explaining commands
• Quick demo would be cool

Initial Integration of freeRTOS into BMS

2: Ability to balance cells

Develop Charger Driver

4B: Define queue mailbox wrapper

There needs to be communication between the sensors and the state machine, freertos queues are used for this.

The github for more information: https://github.com/sfuphantom/firmware/tree/Queue-Prototype/queue-pipeline

Integrate CAN into BMS

There has been a lot of work done on CAN, contact Elena and Xinglu. We need to finalize and fully test the CAN comms and setup the periodic messaging and message processing

Test balancing of BMS

Relates to integrating charging. Balancing only operates during charging state so task needs to be activated conditionally on the state of the BMS. Then we need to test if it works.

1B: Read HV current and voltage

Make sure the current running through the HV board is within range and if not, shutdown signal is sent to the VCU. Further explanations can be found in each test case

Update bms-fw to use hercules-phantom-lib

@rafguevara14 created a new repo where some drivers are located that can be shared between VCU and BMS. bms-fw needs to be updated to use this before continuing to develop code.

Refer to sfuphantom/vcu-fw#54 for changes to be made to project files.

Integrate thermistor board code into BMS code

1A: Read IMD sensor

In case the HV and/or LV systems do not function as intended, the IMD sensor will detect this and the BMS is also responsible for reading the same signal and initiating shut down. Input frequency and/or duty cycle and expect BMS to output same values.

BMS Slaves Test Setup

The BMS Slave chip is the LTC6811.

LTC6811 Data Sheet: https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6811-1-6811-2.pdf

The battery is 96S 5P lithium ion. This means there are 96 cells in series and 5 in parallel. Therefore the battery votlage is 96 times the individual cell voltage and the capacity in amp*hours (Ah) is five times that of an individual cell. The cells we use have a minimum votlage of 3.1 volts when fully empty and 4.2 volts when full. Therefore the battery is 297.6 V empty and 403.2 V fully charged.

We cannot allow the cells to go above or below these maximum/mimimum voltages for safety reasons. It is the BMS master's job to measure the voltage of the entire battery, but the BMS slaves measure the votlage of the individual cells. Not every cell of the 96S 5P battery is being measured; each slave channel will connect to a bank of 5 cells in parallel and measure their temperature and voltage collectively.

Not every cell has the same internal resistance due to manufacturing variance, therefore they will discharge at different rates. Over multiple charge cycles, this effect can compound such that cell voltages are very different from eachother, even though the total battey voltage appears normal.

This is why we do balance charging. Every charge cycle, it is the BMS slaves' job to make sure all the cell voltages are equal. The BMS slaves report these cell votlages (and temperatures) back to the BMS master such that it can make decisions about whether to trigger an HV shutdown.

The BMS salve board is not finished as of 23/05/2024, but its functionality can be emulated much like the ADS7044 ADC which measures the total battery voltage This ADC communicates over SPI and its functionality was emulated using an SPI module on the launchpad itself. The goal is to do the same for the BMS slaves such that the code can be tested and ready for integration when the BMS slave board is complete.

Creating simulator for thermistor board using launchpad

Create Simulator for BMS Slaves using Launchpad

4A: Define APIs between modules

This task mainly focuses on refactoring at the module level and *defining responsibilities for modules.

• we should decentralize initialization code and dissolve it into separate modules where there is a single owner

Output:

• Task skeletons
• Queue modules

Adding timeouts to BMS Slave Communication

Right now if a message isn't processed properly the code will just hang in a loop waiting for it to finish. We want to implement a timeout such that if after 1 ms or so there is no message received then move on to the rest of the code. We also want the logic of if you timeout multiple times in a row then acknowledge that the comms are down.

Requirements Tracing for FSAE 2024

With the new rules released, we need to do a re-evaluation of the current BMS system and figure out what is still applicable vs what needs to be updated.

• Read Accumulator sections in FSAE 2024 rulebook
• Create UML diagram of BMS interactions
• Define unit tests

Detect and Handle CRC errors

Have some kind of mechanism to receive the CRC from SPI, UART, CAN, etc and verify the message integrity.

Move BMS read functions from sys_main to its own header+source file

Add blinking heartbeat LED to the BMS that changes color based on state

Have a blinking LED that changes color depending on the state.
Charging = blue
Running = green
Fault = Red

This would be done by finding which HET(High End Timer) pins are connected to LEDs and toggling them every half second or so to the required color refer to https://github.com/sfuphantom/vcu-fw/blob/master/VCU/Phantom/main.c ~line 336 vStateMachineTask for some examples on setting LEDs to different colors

Create define to display task timing in real time that's toggleable through CLI

Using freeRTOS API display how long each task takes to execute. Also flesh out profiling setup in general.

BMS Read no print functions array indexes are wrong

In BMS_Voltages struct we want to keep the voltages of the cells from the 4 slave boards but right now the arrays aren't being updated properly.

Integrate charger into BMS codebase

This involved doing the following things:

• Integrating the code
• Having checks to switch into charging mode because the battery charges outside the car, so customize which faults to activate based on BMS state

Implementing watchdog timer

We want to use the watchdog timer to make sure that the system is still up running. The watchdog timer will accomplish this by requiring to be pet periodically or else it would reboot the MCU.

Add in logic to convert BMS Slave AUX voltage to temperature

We are getting the voltage of the AUX ports back from the BMS Slaves. There will be thermistors connected to those ports and we need to convert the voltage we read into a temperature. Refer to the thermistor board code for an example on the conversion logic.

Save Current state of BMS into flash

Save things such as error flags, current state in the state machine, status of comms with other MCUs in the system

Make BMS FW build on launchpad

Create hardware defines for the BMS pins

define each pin we use in the code as it's use in the system, eg. BMS_WAKEUP_PIN = GPIOA1

Adding Command Line Interface

4D: Cleanup state machine

The state machine is really messy on there rn. For health monitoring, you probably don’t even need one. For battery management, you probably do but…it’s still messy. Let’s clean it up.

Output:
Explicit diagram characterizing the state machine (Mealy or Moore)

Handle temperature faults

We want to have something checking temperature fault flags and trigger shutdown of the car if necessary