BMS communication error

[libresolar]

BMS communication error

[martinjaeger]

The pack looks really nice! And the firmware should also be almost ready.

1. EEPROM: Do you actually have one on your board? This looks like it's reading garbage from the bus, as the header and CRC information is always different in each attempt. Also looks like this doesn't work with the older firmware either.

2. BMS communication failure: Which exact part number do you have? Did you double-check that the I2C address is correct (see below table from the datasheet). The previous firmware auto-detected the I2C address and whether or not to use CRC, whereas the new version only detects the CRC and the address specified in devicetree must be correct.

If that's all correct, this may be a bug in the driver. I have tested it on my board after the refactoring, but maybe I missed something. Do you have a logic analyzer to check the bus traffic?

I can't really explain right now why it seems to be able to read some temperature values, but it's not able to read anything else.

Also the state machine shouldn't go into discharging state if it can't read proper voltages. I'll need to have a closer look why this is happening.

3. Error flags:

They can be found in the bms_common.h:

bms-firmware/include/bms/bms_common.h

Line 28 in fb078cc

* BMS error flags

The error flags are defined as individual bits. In your example 0x280 the bits 7 and 9 are set, which means discharge and charge overtemp.

I just realized that these defines are not rendered in the docs. Will have a look into that and fix it.

4. BMS state

This is defined in bms.h:

bms-firmware/include/bms/bms.h

Line 32 in fb078cc

enum bms_state

Enums always start at 0, so a BMS state of 3 means BMS_STATE_NORMAL.

6. Balancing status:

Same as error flags, but the individual bits indicate the balancing status of each cell. As an example, 0x0004 (in binary 0b0000_0000_0000_0100) means that cell 2 (starting to count from cell 0) is currently being balanced.

[Retro-Fitt]

@martinjaeger

Many many thanks for reply.

1-EEPROM: Yes i do have one on my hardware. It is not same brand and chip as your hardware design i believe. Here is it's datasheet. I modified devicetree according this datasheet but i might be wrong about "size", "pagesize", "address-width" and "timeout". I double checked my hardware design it seems OK. Which i believe i have a software issue rather than hardware issue. I don't know if it is related to EEPROM issue but State of Charge value starts from 0 if i turn off and turn again this bms? In a nutshell i am not sure if my EEPROM works properly with old firmware and new firmware.

2-BMS communication failure: I have BQ7693003DBTR, which i believe have 0x08 i2c address and also have CRC.
I have cheap Cypress EZ-USB FX2LP-based Logic Analyzer with sigrok and 4 channel Rigol DS1054Z scope which have i2c decoding capabilities. (I am not sure about scope can decode i2c traffic between MCU and bq chip since it is not exact i2c protocol) So i can check bus acticity and post here.

Here is my devicetree and schematic summary:

3-Error flags: I am so sorry but i couldn't understand how did you convert 0x280 to the bits 7 and 9? Could you please explain in detail?

4-BMS state: Understood very well.

5-Balancing status: I think i understand this. For example in my previous tests balancing value was 258. I converted decimal to binary and get 0000000100000010 which indicates CELL 1 and CELL 8 (starting to count from cell 0) are balancing right?

EDIT:
Now i tested with 0x18 address to see how it behaves now it gives:

E: Error reading current measurement
E: Failed to read data from BMS IC: -5

Which i assume 0x08 address is correct and it can communucate with bq chip but not in right way.

Side note: Also it behaves like this when i disconnect cell balance and main terminals and supply MCU from ST-LINK to program MCU which is understandable because bq chip is not powered with battery so it cannot respond to MCU.

[martinjaeger]

1. and 2. Ok, EEPROM and BMS devicetree all looks good then. So it must be a software issue, indeed. The communication is "normal" I2C and you should be able to analyze it with a Logic Analyzer.

3. It's the same as for the balancing status. Here is a screenshot from the Linux calculator I usually use:

5. Yes, the balancing status is correct.