BMS Details

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Turbo3

Well-known member
Leaf Supporting Member
Joined
Jul 19, 2010
Messages
2,014
Location
San Jose, CA
I was fortunate enough to be loaned a BMS board that had been burnt out while trying to converted a Leaf battery pack into a 4 x 100 volt configuration for use in another vehicle.

This is the first time I have looked into a battery controller so some of what I say may be common knowledge. To me it is all new but I though it could be useful to others to know more about the inner working of the battery balancing circuits and how it interfaces with the Leaf.

The board consists of two sections. The first section is common to all ECUs in the Leaf with a CAN interface and RISC processor. This is the part that Leaf Spy communicates with to get battery voltages and shunt settings. The second section is almost totally isolated from the first and consists of 24 custom ASICs that monitor the 96 cell pairs. This is the section I have been looking into in detail.

The most interesting part is that the custom ASIC part is coupled to the first section through three photocouplers. Communications with the ASICs is through a serial link starting with a UART pin on the RISC processor and going through the first photocoupler. The output of that photocoupler is looped through the first 12 ASICs then another photocoupler then 12 more ASICs and finally through the last photocoupler back to the RISC processors input UART.

Each ASIC is actually an island onto itself. It gets its power from the four cells it is monitoring and only has a single input signal from its neighbor which with a zener diode is prevent from going negative.

All this isolation is required because the full battery voltage of up to 393 volts is being monitored on a standard circuit board. There is a clear insulating over coating on this section to prevent any leakage that could result in a catastrophic failure of the board.

I am guessing that the zener diodes on the inputs serve two functions. One to dampen any voltage spikes above 6.2 volts. Second to allow the ASIC to function even if one cell is open/shorted. This is important as the command and status must go through all 24 ASICs so they all need to be powered up.

Here is a schematic of the last two ASICs in the chain before the data is shifted back to the processor. Note that the shunt resistor appears to be the 430 ohm 250 mw resistor. So any balancing is going to take a long time at less than a 10 ma load.

Warning: If you are going to try to rewire the BMS to operate with a different battery configuration best to really study this wiring diagram so you understand the voltages your rewiring will put on the ASIC. These are custom chips and as far as I know are only available internally to Nissan or by stripping them off another BMS board.

This shows the last two ASICs in the string before sending data back to the processor through the photocoupler.
BNS5dy.jpg


The Service Plug that opens the high voltage circuit requires that the BMS also be split into two isolated sections. This page shows the photocoupler used to isolate the serial control signal between the two groups of 12 ASICs. Note that the negative side of cell 48 is not connected to the positive side of cell 49. If this was not done then when the Service Plug was pulled all the power would try to pass through that connection on the BMS board burning it out in a short order.
TDwVTe.jpg


This shows the first two ASICs in the string with the right one getting commands from the processor through the photocoupler.
Not sure of the purpose of TR450. It seems to allow the ASIC to put a load on the ASIC generated Vcc used to power the photocoupler.
zTtdPQ.jpg
 
One minor correction which I will fix on the next update of the schematics is that what I list for part numbers of the ASICs are actually different between sides.

There are actually two numbers on each ASIC and the one I had assumed was the part number is the one that is different. For the top side it is 1240KX200 as listed on the current schematic but on the back side it is 1239KX219. Cells 1 thru 4 are handled by the top and 5-8 on the back side. This pattern alternates down the board. The top number on each chip is D15120 and is the same on all 24 ASICs on the board I have. So perhaps that is the real part number and the other is a date/production code.

If anyone else has access to a BMS board please post all the numbers you see on the chips and their location on the board (top/bottom).

I see no reason why there would be a need for two different chips as their location on the board is programmed with the 5 ID pins and all the wiring is the same.

======================
After thinking about it I am now pretty sure the 1239KX219 and 1240KX200 are date/production codes. Dates would be 2012 39th week and 2012 40th week. The other characters are probably planet (KX) and batch. I will update the schematic with D15120 as the Nissan internal part number for the ASIC.

The RISC processor has a code of 1216KP400 plus a part number of 70F3236BM. With the part number above the date code. So the format is the same. First part number then date code below.

======================
Numbers from a different board confirm that the part number of the ASIC is 15120 and the other numbers are the date codes.
 
Yesterday I added a second schematic page to the first post covering the first two ASICs in the string and the logic that gets commands from the processor.

Today I powered up the BMS on the bench. At first no CAN or attempt to communicate with the ASICs. After I provided the "PWR" signal (Leaf on or charging) the CAN came alive and the processor tried to communicate with the ASICs.

ASIC serial link runs at 19,200 baud or 52 usec per bit. Have only looked at it on an Oscilloscope to see the general protocol. There is a 10 msec start pulse then three bursts of around 4.5 msec, 9.28 msec and 9.63 msec. This repeats at an 80 msec rate. This is probably not the typical behavior since no data is ever coming back to the processor. Later I will capture the data on a logic analyzer and dump the serial bit stream for further hand analysis.

I also connected up the CAN to an OBDII connector and plugged in an ELM so I could run Leaf Spy Pro and dump the DTCs. This immediately showed the current limits of Leaf Spy Pro in that there are 30 DTCs reported and Leaf Spy Pro is only able to handle four correctly. This is actually a bug in the code as it should handle more but I never had a way to test the code before. Looking at the code right now so should have a fix shortly. The 30 DTCs are bad CAN communications, bad ASIC communications, 24 bad ASICs, 3 bad temp sensors, bad current sensor,

Later I will try to add a dummy set of batteries to power up the first ASIC in the chain and verify data comes out. Once I get data I can try feeding it directly back to the processor which should clear one of the DTCs.
 
Today's experiment was to get two ASICs working so that the communications link with the processor could be completed.

To do this I needed 8 batteries, four for eash ASIC. The solution was to use two 9 volt batteries and 8 resistors to make a voltage divider.

After removing two resistors from the board to break the serial link to the unpowered ASICs an external resistor was added to connect the OUT from ASIC 24 to the IN of ASIC 1.

Here is what the completed test setup looks like on the bench. OBDII adapter to the left. Temperature sensor cable off bottom left to some resistors and a pot.
VsScnV.jpg


Once everything was connected and powered up Leaf Spy Pro was used to read the "Leaf's" battery voltages. 18volts/8 cells = 2.25 volts per cell.
3fT0IL.png


Next the DTC were reset and read again and as expected ASICs 1 and 24 are no longer listed as being bad.
CwZ3Xy.png


Now that I have a "working" BMS I can start taking traces of the serial link and work on decoding its format.
 
Can you do a log of the can "bus" with just the BMS on it to see what messages show up? Should confirm which messages we know are from the BMS and learn any that we don't know.
 
Surprising that no one has been able to clone Consult III+ and build an interface multiplexer.
This has been done with M/B, BMW, & Porsche factory testers by major companies, e.g. Autologic,
and of course the Chinese. This would definitely help in further LeafSpy development and when
analyzing Leaf sub-systems' electronics or reflashing/recoding module firmware. Additionally,
the Leaf CAN system is rather basic when compared to either BMW or M/B, which should facilitate
a design of a Leaf interface multiplier, i.e. what basically the LeafSpy has done to an extent in software.
 
In the context of the CAN interface, what do you mean by an interface multiplexer?

There is nothing special about the Consult III+ hardware.

It is the Consult III+ software that has all the smarts (knows the requests and response formats).
 
Turbo3 said:
In the context of the CAN interface, what do you mean by an interface multiplexer?

There is nothing special about the Consult III+ hardware.

It is the Consult III+ software that has all the smarts (knows the requests and response formats).

Great reverse engineering effort on your part!

"In the context of the CAN interface, what do you mean by an interface multiplexer?"

Having the ability to off-load a PC's software from generating all the interface protocol necessary like
when using the ELM327. Typically a PC via a USB/serial port just sends basic commands to a hardware
interface multiplexer to generate the lower level protocols necessary to interact with various modules
on the multiple CAN buses. Such a device is typically called a "pass-through device". An example of
such a device is the SAE J2534 produced by a number of manufacturers.

Utilizing a J2534 device one can, for daily/monthly/annual fee, download an OEM's, e.g. BMW/Porsche,
diagnostic application and have access to a vehicle's modules for either diagnostics or reflashing.
Basically all OEMs are now required to provide an application to interface to the J2534 standard,
which runs on a PC and interfaces with a generic interface (a J2534 device). At the present most
OEMs just provide an application to only access their ECMs which may require field reflashing because
of emissions and/or running problems for their ICE vehicles

Nissan, as many OEMs have, provides a on-line application to access their ICE ECMs and a few other modules.
Obviously since the LEAF is a ZEV, Nissan doesn't need to provide any application to access the Leaf's
modules.

Having observed Nissan Leaf techs when doing a Leaf update, they use a Panasonic Toughbook
with an interface cable/module with an OBDII connector. Most likely their app runs under WinXp,
like most OEMs, and relies on the interface cable/module to function similar to a J2534. Not having
access to the Consult III+, I'm assuming that it would be setup very similar to my diagnostics systems
I use for BMW, Porsches, & M/Bs.
 
Sorry, I still have no idea what you are asking for.

J2534 has nothing to do with an electric vehicle. The Consult III+ hardware is not much different than an ELM. It receives frames to send on to the Leaf CAN and returns frames back to the attached computer.

There is no higher level function that is off loaded or an API. The only interface protocol is that needed to send/receive standard CAN frames. You give it an ID and up to 8 bytes of data and get an ID and up to 8 bytes of data back. That's all there is. The ID selects the ECU and the data contains the command and any modifiers. If you want to sound the horn just send the right command to the Body Control ECU.

So there is no such thing as an interface multiplexer for the Leaf unless you are calling what the ELM does an interface multiplexer. To the Leaf the Consult III+ just looks like another ECU that can send and receive CAN frames. The only difference is that the Leaf ECUs do not send data to the Consult III+ unless the Consult III+ has asked for it. The Consult III+ seems to make no attempt to capture any of the normal traffic on the CAN bus. It is only attached to the CAR-CAN so could not monitor any traffic on the EV-CAN even if it wanted to.

ICE have government mandated functions that must be implement. The Leaf being electric does not. They are very different. The Leaf CAN is a closed system only intended for access by Nissan service through the Consult III+. It is not an open spec. It is a proprietary interface know only to Nissan. Nissan does provide an interface box under NDA to interface to the Leaf which does isolate the CAN and provides a higher level interface but it provides a very limited set of information.
 
Turbo3 said:
The Consult III+ seems to make no attempt to capture any of the normal traffic on the CAN bus. It is only attached to the CAR-CAN so could not monitor any traffic on the EV-CAN even if it wanted to.
Hmm, that's news to me. I don't think I've seen that mentioned before on MNL. Interesting.

Also, to be fair, ALL current EV's are proprietary with respect to CAN messages and such. It's not just the leaf.
 
1. Turbo3 asked:

"In the context of the CAN interface, what do you mean by an interface multiplexer?"

I answered:

"Having the ability to off-load a PC's software from generating all the interface protocol necessary like
when using the ELM327. Typically a PC via a USB/serial port just sends basic commands to a hardware
interface multiplexer to generate the lower level protocols necessary to interact with various modules
on the multiple CAN buses. Such a device is typically called a "pass-through device". An example of
such a device is the SAE J2534 produced by a number of manufacturers."

2. Turbo3 stated:

"Sorry, I still have no idea what you are asking for. J2534 has nothing to do with an electric vehicle. "

I didn't state nor implied that J2534 was intended for use with an electric vehicle, only that it exemplifies an interface multiplexer.

3. Turbo3 stated:

"The only interface protocol is that needed to send/receive standard CAN frames. You give it an ID
and up to 8 bytes of data and get an ID and up to 8 bytes of data back."

That's a very very limited functionality and is what the LeafSpy does, but really can't be considered
on the same level of an OEM diagnostic tool like the Consult III+, or what BMW/Porsche provides to
their service techs.

4. Turbo3 stated:

"The Consult III+ seems to make no attempt to capture any of the normal traffic on the CAN bus.
It is only attached to the CAR-CAN so could not monitor any traffic on the EV-CAN even if it wanted to."

That statement is rather confusing in that it implies that the Consult III+ is totally useless. In fact,
it has the same functionality/utility as any propriety automotive field diagnostic tool provided by any
ICE OEM with the exception that it's for the Leaf. The Consult III+ should have and has the capability to
access any module on any CAN to; read/erase fault codes, recode functionalities, e.g. when doors auto
lock, or when a replacement module is installed, read actual module sensor data, e.g. ABS wheel speeds,
and reflash modules when a major module update is required. Without that functionality, Nissan dealers
could not adequately field support their vehicles.

5. Turbo3 stated:

"ICE have government mandated functions that must be implement. The Leaf being electric does not. They are very different."

Most are aware of this!

My post:

"Nissan, as many OEMs have, provides a on-line application to access their ICE ECMs and a few
other modules. Obviously since the LEAF is a ZEV, Nissan doesn't need to provide any application to
access the Leaf's modules."

6. Turbo3 stated:

"The Leaf CAN is a closed system only intended for access by Nissan service through the Consult III+.
It is not an open spec. It is a proprietary interface know only to Nissan. Nissan does provide an
interface box under NDA to interface to the Leaf which does isolate the CAN and provides a higher
level interface but it provides a very limited set of information."

1. All OEM vehicle CAN systems, whether ICE or not, are proprietary systems ("closed systems"),
with the exception of OBDII and ECMs.
2. So Nissan does utilize an interface box (a multiplexer).

Hardly any great insight provided.
 
You know, if you EVER want people to actually take you seriously and/or provide any help to you, you MIGHT want to try being a little nicer and less snarky... :roll:

lorenfb said:
Hardly any great insight provided.
 
lorenfb,

This has gotten way off topic for this thread.

You should start a new thread under Leaf Ownership/Accessories/Mods >>CANBus if you would like to continue to discuss this. Once you do that I will move my comments over to it and clear them from here. Please do the same to clean up this thread.

Only BMS comments should be posted here, Thanks.

Jim
 
TonyWilliams said:
Awesome work. What is the CAN message that is the "PWR" signal ?
The "PWR" signal comes from a relay that closes when you press the Power Button. If you look closely by the ELM adapter there is a small switch to 12 volts that I use to generate this signal.
 
JeremyW said:
Can you do a log of the can "bus" with just the BMS on it to see what messages show up? Should confirm which messages we know are from the BMS and learn any that we don't know.
I see the following message IDs on the EV-CAN coming from the BMS board.

0x1db, 0x1dc, 0x55b, 0x59e, 0x5bc, 0x5c0
 
Updated the first post with a third (page 2) schematic showing the isolation between the two groups of 12 ASICs.

Added a "Notes" section to the first schematic.

Here is a sample trace of the serial link running at 19,200 baud. The processor sends an address followed by a string of pulses used by the addressed ASIC to send data back (lower trace).

j4H9Yx.jpg


Because only 2 ASICs are powered up the processor spends most of its time in retry (2 seconds per ASIC). So a full trace takes over 40 seconds to capture.

The data captured in the above trace should be the voltages for the 4 "cells" it thinks are attached. Actually it must be the voltages as that is the only data coming back to the processor from the powered ASIC.
 
Back
Top