BMS63EN Diagnostics - How to?

[Orbiter]

I had a fine working setup with BMS63 for some hours. 

Than cell 12 showed 0V and the fault light in the ISO SPI came up. 

A short measurement showed, the cell was indeed empty (I am testing with very old cells). 

After replacing the cell cell 12 still shows 0V, and the fault light is still on. 

If I measure with the testpins on the BMS63EN itself, I can see that there is a cell voltage. So something went wrong with the BMS63EN I think. 

Do I need to reset the error/fault? In the manual its stated that software diagnostics need to be run in such case. But..how? 

And shouldn´t that be all reset after a complete disconnect and new init? 

[Max VIZZINI]

Hi Michael,

To check for bugs, you should refer to the official platform and use AEK-POW-BMSHOLD.

Then we would have an objective and shared tool that we can compare.

Not having a standard reference is very difficult to understand where the problem is.

I am not sure how you built the battery pack, and I am not sure if you properly connected all the unused sensing pins on L9963E.

If the serial chain of the sensing pins is broken, then the IC will not read the voltages properly.

In addition, in an Automotive system normally cells are pre-charged before being inserted in the battery pack and the charge is equalized with the balancing. Putting a 0V battery is not good, nor cells that maybe are in under-voltage state already.

If you do not want to buy AEK-POW-BMSHOLD, the other suggestion is to request one of our engineering partners for some consultancy support. The Community is not the place for a step-by-step follow-up of your design. If you are interested in the consultant let me know and I will pass you the contacts by email.

Best Regards,

AutoDevKit Team

[Max VIZZINI]

Hi Michael,

The team verified that there is no bug.

Our demo is implemented with 14 cells fully activated.

The driver considers the configuration written in the CFG file but our application (including the simulink model call) is written in the main(), therefore it needs to be modified to keep it coherent

Inside the function  void AEK_POW_BMSNOTX_ParameterConfiguration(void);

Defined in  AEK_POW_BMS63EN_id.c file 

There is a "cell enabling" section in line 224:

/* Cells Enabling */

//Enable Model Cells by reading configuration

The code in this section has to be replaced with the following one:

for(cell_idx = AEK_POW_BMS63EN_CELL1; cell_idx <= AEK_POW_BMS63EN_CELL14; cell_idx ++){

                      if(AEK_POW_BMS63EN_isEnabled(AEK_POW_BMS63EN_DEVICE_ID(j), cell_idx)){

                               AEK_POW_BMS63EN_EnableCell( AEK_POW_BMS63EN_DEVICE_ID(j),cell_idx);

                         }

                        else{

                                   AEK_POW_BMS63EN_DisableCell( AEK_POW_BMS63EN_DEVICE_ID(j),cell_idx);

                              }

               }

In this way we can bypass the configuration in the main function().

Best Regards,

AutoDevKit Team

[Orbiter]

Hi again!

Oh thanks- now it works with the readings! 

I do thow have one left: it still shows an fault, but I can´t find anything faulty - maybe that has something to do with the cell deactivation?

Here is the serial readout:

Error detected:

Fault 1:8 

Fault 2:0 

VCell 0V:0   

VCell UV:0

Overlatch:0

GPIO Faults:0

BallUV:0

VPack:24.1452

[Max VIZZINI]

Hi Michael,

In our main() function example we are calling just few functions dedicated to faults (VCell UV/OV, Fault1, Fault2, etc..). In reality, in page 80 of the L9963E datasheet you find all the possible detected faults.

For each condition in the datasheet, there is a specific function in the driver to plot the result. On top of that there is also a generic function to plot the faults.

You should try to plot each fault to try to find the condition that is generating the fault itself.

Please note that every time you change the code, you need to reset the L9963E to clear previously latched memory conditions (e.g. unplugging and re-plugging the battery pack when trying to mask the GPIO faults).

From your previous screenshot the VBatt Sum is not visible. Did you modify the code?

Best Regards,

AutoDevKit Team

[Orbiter]

Yes, I modified the code to print the VbattSum its just called VP. And yes, I unplug the BMS63EN from the pack and even the powersupply to the ISOSPI prior to flashing, also closing UDE prior to restart.  

All errors on Page 80 would set a latch, but the Overlatch shows = 0, which got me thinking.

You wrote: "For each condition in the datasheet, there is a specific function in the driver to plot the result. On top of that there is also a generic function to plot the fault" -> I can´t find those in the API list, do you mean the functions in the BMS63EN_diag.c?

I already read the errors that are defined in the diag.c but nothing shows. So I read all registers and printed them over serial. (See below) 

Register 3E shows "Balancing open detected" on all odd cells 101010101010000  (21840) - even on cells not active, thats why I think it maybe has something to to with the issue above, deactivation of cells? 

Error detected:

3E:21840 

3F:0

42:0

45:196608

46:0

48:0

49:0

4A:0

4B:0 

Fault 1:8
Fault 2:0

VCell 0V:0

VCell UV:0

Overlatch:0

GPIO Faults:0

BallUV:0

VP:24.0990
DEV:1
S01:000 S02:000 S03:000 S04:000 S05:000 S06:000 S07:000 S08:000 S09:000 S10:000 S11:000 S12:000 S13:000 S14:000
B01:000 B02:000 B03:000 B04:000 B05:000 B06:000 B07:000 B08:000 B09:000 B10:000 B11:000 B12:000 B13:000 B14:000
V01:2.818 V02:3.067 V03:3.118 V04:3.134 V05:0.000 V06:0.000 V07:0.000 V08:0.000 V09:0.000 V10:0.000 V11:2.930 V12:2.954 V13:3.114 V14:2.963
C:0.0003

[Max VIZZINI]

Hi Michael,

The value you read on in register 0x45 is correct and it is related to the gpios.

The value you read on register 0x3E is detecting an open in the balancing circuit. The circuit connection both on sensing and balancing is not related to the activation. Despite a cell could be de-activated, the physical electric connection has to be correct or the error will be detected.

The deactivation is something at logical level and not physical level, because the cells remain connected to the circuit.

I would explore the HW more than the SW in this case...

Best Regards,

AutoDevKit Team

[Orbiter]

I triple checked and even rebuild the complete setup, but I can´t find any HW issue. 

I also wonder how I can have a HW error without having a Cell error latched?

I am using the BMS63EN, so I do not see how I could have affected the balancing circuit or how I can solve the issue. 

Any hints where to look? 

Still the same reading on serial:

Error detected:
3E:21840
3F:0
42:0
45:196608
46:0
48:0
49:0
4A:0
4B:0
Fault 1:8
Fault 2:0
VCell 0V:0
VCell UV:0
Overlatch:0
GPIO Faults:0
BallUV:0
VP:24.1332

[Orbiter]

An update:

The condition has worsened. I did not change anything other than letting it run for some time. 

Now I got the HWSC terminated (does this mean HWSC failed?) and the VTREF comparator failed BIST.

Its also latched right now, Current measurement is floating around like random readings (no load connected).

Is that internal destruction of the L9963E or is it something external?  The datasheet does not say what this actually means. 

Error detected:
3E:21840
3F:0
42:0
45:196608
46:0
48:21840
49:16384
4A:0
4B:0
Fault 1:8
Fault 2:0
VCell 0V:15375
VCell UV:15375
Overlatch:1
GPIO Faults:0
BallUV:15375
VP:23.8690

DEV:1

S01:000 S02:000 S03:000 S04:000 S05:000 S06:000 S07:000 S08:000 S09:000 S10:000 S11:000 S12:000 S13:000 S14:000

B01:000 B02:000 B03:000 B04:000 B05:000 B06:000 B07:000 B08:000 B09:000 B10:000 B11:000 B12:000 B13:000 B14:000

V01:2.914 V02:3.129 V03:2.885 V04:2.927 V05:0.000 V06:0.000 V07:0.000 V08:0.000 V09:0.000 V10:0.000 V11:3.115 V12:2.738 V13:3.053 V14:3.107

C:0.0005

[Orbiter]

@Max VIZZINI ?

[Max VIZZINI]

Hi Michael,

I apologize but I have no smart suggestion to give to you.

If you fear that the L9963E is destroyed, then the best is to replace the IC or the entire node board, whichever is easier for you.

Other is to remove the batteries verify again your electrical connections, including verifying the batteries are ok.

The only thing I can say is that faults should be eliminated one by one.

Sorry not to be able to help further.

Best Regards,

AutoDevKit Team