Landspeed's HV battery + ECU teardown, analysis, experiment, upgrade thread

Since my Gen II Prius battery did the 'burnt orange connector' thing, as has happened to other people :

The battery fires at ECU sense connector thread | PriusChat
- I posted some info on pages 4 and 5 of this thread before I found the actual burnt connector.

I then posted two threads as I started exploring the problem on my car, then came across another issue:
Troubleshooting HV ECU burnt connector (causes P0AFA, red triangle, 'replace hybrid battery' etc | Page 2 | PriusChat
Different cell capacities after battery ECU short circuit - advice re: fix? | PriusChat

(I will ask for my two threads to be closed, after I point them to this thread)

I have learnt a lot about the batteries and have some interesting theories about what is happening (check my avatar for a photo from a known good ECU I took yesterday!). I now have three Gen II batteries total, two mostly good, one the original.

My plans are to do a few things;
1. Investigate my original battery + the associated Battery ECU; I'm removing the battery from the car after positing this thread so I can strip it down at my leisure and do experiments. I will attempt to repair my ECU as well.
2. Reverse-engineer the battery ECU. Examining my damaged ECU, I can see that pin 22 has some extra circuitry, which I expect is related to the HV ground fault detection system. Overall I plan to make a block diagram, accepting that it won't be possible to figure out the exact functions of some of the ICs (which are literally black boxes and probably won't allow the firmware to be read back out).
3. Experiment as suggested in another thread re: the resistance of the ECU HV sample / hold circuit. It is known there are 1000 ohm resistors in place to protect against short circuits (the placement is a design fault, unfortunately). This experiment will actually be quite easy and I will get it done once I get a working battery pack and non-burnt battery ECU installed.

I am hopeful that the information will be helpful to others. I will put it all here as it had become spread across a number of threads - I will link those threads to this thread below.

The main aim I have is to understand the battery ECU better, and to figure out the best way to prevent these short-circuits from happening, no matter how bad the corrosion gets. And hopefully to help people prevent these short-circuit events before they happen.

 

To start, I will post a picture from one of the good ECUs I have (90,000km car bought from dealer, one owner - this is from the battery pack that has one weak module that I bought 2-3 days ago). This is the orange connector, on the inside. It had never been opened at all. The metal whisker was malleable, but couldn't be blown off (e.g. not dust), and when looking at it in 'live video' mode on my USB microscope, it glints etc and is firmly attached to the pin from which it has grown. I have bent it flush to the pin for now!
This kind of thing makes me worry about the safety of my car - hence the reason for going all-out investigating this - this ECU has no corrosion anywhere so this is a scary finding.

(PS the connector pins are dipped in tin as a coating, so they are all pure tin-plated)...

 

I checked the secondhand battery of unknown status - four bad blocks (each having somewhere a 1.2v cell with 10-30 seconds of charge max). I charged up that battery moderately and it is now ready for a stripdown / test with my hobby charger. My plan is to recondition it, and, just for the sake of it, see if I can rehydrate the totally failed modules - it can't hurt!

I am about to check the 'secondhand battery with a failed module, 90,000km, looks immaculate'. Toyota did the placement; Techstream printout shows one low-voltage module. Of course, Toyota didn't do any kind of load testing but I will do that in my car (gently).

Is there any way that a moderator can grant me permission to edit my first-post in this thread? As I want to add stuff as time goes by? I will 'report' this post so a moderator sees it and see if they can give me that permission (I can't edit the first post due to the limited time available to edit posts).

In the meantime, I would add the following initial tasks (basically getting a working car, then doing lots of experiments and reverse engineering)
- Check what happens if I stick a 1000 ohm resistor between the battery and sense harness on a good working battery, in the car, and see what happens (given that both internal resistance and voltage are checked using a sample-and-hold capacative system, it could be that the battery ECU thinks the IR has gone up, or the voltage has dropped, leading to either codes, or, worse, chronic overcharging of the module with the 1000 ohm resistor. If there are disparities, I will remove all the 1000 ohm resistors from an ECU and make a custom loom with the 1000 ohm resistors right next to where they connect to the battery.
- Using pair of modules, charged to approx 60-80% SoC, short-circuit using a very fine piece of wire, and see if an arc is sustained. This is an experiment for later, but will test my hypothesis about metal whiskers (this will be recorded at 240 fps on an iPhone!)
- Repair my damaged ECU (while the corroded pins cannot be found, the simple fact is that the NWH20 ECU has a number of blank pins - which can be transplanted to replace the melted / arced pins.

- (Side note - I found someone selling a good 2014 Nissan Leaf battery ECU for cheap and bought it; this will be reverse engineered at some point in the future, so I can have Tesla cells in my Leaf).

More to follow (if you see news of a healthcare professional in New Zealand being killed when messing with Prius battery packs, say a prayer for me lol!!!)

 

I survived; the 'good battery with a single dead module' turned out to be a good battery with a single bad module - the battery was very well balanced, had a good state of charge. When force-charging it (with air-con on, and watching battery temperatures and so on), it was interesting to watch what happened when then sitting in the car with the air-con on (on medium), no other power drain, and the car in neutral. Basically, the SOC slowly dropped to 0%, then jumped to 80 or 100%, then quickly dropped to 0%. This repeated many times. Basically because the battery ECU was confused at the 'dead' module, combined with the rest of the pack being very healthy (the deltas were maybe 0.05 across the whole range). The battery has been left at approx 50% (true) SoC and stored for refurbishment soon.

I have installed my original battery (complete with partially burnt orange connector but new ECU). I am ordering a new voltage sense loom to fit ASAP, and will inspect for corrosion every 3 months.

I will start reverse engineering the battery ECU soon. In the meantime I post what is, to me, an interesting photo:


This shows my other good ECU, held up to the light. I have much better photos of the front and back which I will use to map stuff out.

However, this photo is interesting because it shows how the input from the orange connector is isolated until it gets to the optoelectronic relays (the black modules 'shining through' at the lower central portion of the board. It is also interesting that you can see through the board around the orange connector and all the way until the high voltage gets 'processed' by the opto-electronic chips. The rest of the ECU (dark portion) is the low-voltage side. This shows the steps that Toyota took, to remove all masking on both sides of the battery ECU, to prevent problems with HV leaking from the orange voltage sense connector to the low voltage portions of the ECU.

The other interesting thing about this photo, is the infamous pin 22 of the orange connector. It is the top right pin on this photo. All of the pins go down and to the left to the voltage sense area (on the other side of the board - so you can see shadows of this on this photo). However, pin 22 has another track on this side of the board, which goes to the two large capacitors, in series, then goes to some sort of matrix made up of (capacitors or resistors, I haven't looked yet). A feed is then taken off and goes to the large resistor on the other side of the board. After this, it goes all the way across the board to the through-board via, attaching to an opto-electronic relay.

-> This shows pin 22 has an 'extra' function above all the others, which is interesting given this is the pin that usually goes bad. I think it is probably the ground-fault circuit. Part of this extra pin-22 circuit actually connects to the low-voltage (dark) part of the ECU motherboard.

I need to do more research but I do wonder if this somehow results in a higher rate of corrosion (when combined with other factors such as galvanic factors, electrolyte leakage in the battery, environmental humidity, salts in the air, even presence of acids for any reason). I also wonder whether there is any 'constant voltage' (perhaps a constant 12v, and 0.0000000001 amps) in this circuit as part of the (ground fault detection or whatever it is for). If so, that could have a role to play in the pin-22 mystery.

More to follow

 

I should have posted the thread, in my first post, that makes it possible to realise that one can actually reverse-engineer such closed-source black-boxes as car ECUs. Specifically, pEEf's thread (he now has a Tesla, but made his own custom battery ECU to make a PHEV). The thread is :

Battery ECU secrets and teardown (warning: geek content) | PriusChat

From the first post of that thread, I have made a slightly modified picture of the ECU: (c) pEEF from the above thread!!

The changes I have made are:
1. The area 'circled' in red near connector B is the other side of the 'extra' circuitry attached to pin 22. on the other side of the board, it goes right to the far side. This will be explored later.
2. The area circled in red, to the bottom right, is *probably* the sample-and-hold part of the voltage sensing circuit from looking at the board close-up. The other similar black PhotoMOS chips are the ones that select the voltage to be sensed; under the board is a pretty clever three-wire circuit that seems to sample two voltages at once (again, very preliminary investigation). The 74AC138 powers up at least some of these PhotoMOS chips as needed. The 74AC138 is connected to the main CPU in the middle of the board. I am not sure if the 74AC138 controls all the 8 PhotoMOS chips not circled in red - there are some trace that come out from under that chip, and 3 pins seem to be 'empty'. Will do some work with a voltmeter later to see if perhaps those empty pins actually trace back under the chip and come out to the left of it.

3. The best things I found :
- The previously identified chip in the centre of the board is actually an NEC 76F0027GF(A1). This is a custom microcontroller with GPIO, A/D convertor, UART, hardware timers, dedicated CAN support, maybe other networking. It contains an NEC V850 RISC processor with a Harvard architecture. It contains a small amount of RAM, and also has internal flash ROM. It uses a 4-5 MHz crystal (as seen on the board), and similar chips can run at 20MHz (not sure of the speed of this one).
- If I can get hold of the contents of the flash on this chip, I can reverse engineer the code. This is really my forte, a I have previously reverse engineered a laptop (Psion Netbook Pro) which nobody could do (at the time - years ago) and made my own custom OS for it. Basically, machine code, especially 32-bit RISC, makes sense. The flash ram will be up to 512K, much of which will be various lookup and other tables. The instruction set of the CPU is documented.
-> However, the flash is not available from any 'sources' on the internet
-> The chip has the ability to refuse attempts to read from it, if Toyota set that flag...
-> On many other Toyotas (and Lexuses), people have read the flash from very similar chips (since very similar chips are used in the main ECU on other Toyotas). This makes me hopeful the flash can be read.

-> The ability to make custom firmware for the battery ECU would be amazing. In particular, custom firmware could be designed which 'reverts' to standard behaviour when the 12v battery is disconnected (in case you mess up), but lets you change lots of parameters via the CAN-bus / OBD-2 port.

If it is possible to make custom firmware (it is possible even without Toyota's firmware, but a copy of the original firmware is needed, at the very least in case of a bad flash / debug testing etc), then many options become available. Such as:

Prolong life of dead battery
When a HV battery is properly 'dead' (e.g. a single cell of the 168 cells has gone bad), that cell will be constantly overcharged and reversed and will promptly die.
Even if this isn't the case, sometimes the HV battery can have most modules with much lower capacity, or different capacities, so that the usable capacity is tiny, resulting in a code being thrown and the car becoming unstartable.

If the owner decides to buy the new cylindrical cells available on Priuschat, or a new OEM battery, they could, in the meantime, activate a backup mode which keeps their car running, while they save up the money (preventing wasting money on a 'refurb' battery, most of which are dodgy (except for ones from some members here).

The rules of this mode could be:
-> The HV battery is used to start the ICE quickly;
-> The ICE stays running constantly (to prevent sudden current draws on the dying HV battery)
-> The driver can use the EV mode button to shut down the engine in bad traffic jams, if they wish
-> The HV battery is charged a little after starting the ICE, with the Battery ECU being 'aware' to not overcharge lower-voltage cells etc.
-> The HV battery is then no longer charged or discharged. The car runs slower; regen is disabled, but the car still works
-> Full throttle does use the HV battery so you can get out of sticky situations easily.
-> The HV fan runs full all the time.

This mode could keep a car going for a lot longer, and could allow someone to use a supply of dead batteries to keep their car going for years. A variant of this mode could be used for batteries that only have 10% of the original capacity - allowing the engine to start, allowing a little regen and motor assist, without over-stressing the battery.

Change battery capacity, chemistry etc
This has been done before, and can be done without reprogramming the battery ECU. However, adding a Li-Ion pack, with a small CAN ECU which can just hook into the CAN-bus before the battery ECU terminates the bus, would allow (with custom firmware in the battery) for a second battery to be properly integrated, and would allow the second battery to provide power to the HV voltage rails (and stopping this boost when not needed e.g. when doing regen braking). It would also allow extra batteries to be programmed to keep the HV battery at a good state of charge, but not 'full green bars' which can't be good for the HV battery long-term. Finally, with good communication between a small ECU for a Li-Ion battery and a reprogrammed Toyota battery ECU, there is no reason that the Li-Ion pack could not be recharged by the ICE. The benefit would be when driving long distances, cruising, the ICE is often under-utilised, and a slow top-up of the Li-Ion battery would allow a lot of driving in towns and cities with no emissions. In my case, I live near several mountains that can literally, several times, recharge a normal HV battery from '1 bar' to 'full', and then waste the rest of the energy. A small Li-Ion pack could improve mileage in hilly areas. A larger Li-Ion pack could be used for a DIY PHEV (which can recharge itself in mountainous terrain).


DEBUG PORT

-> The debug port is actually a 20-pin standard JTAG port. There are some very expensive rigs that let you attach to the port, but I found a source of surface-mount connectors and have a few on order of the correct pitch (the challenge is that most are through-hole connectors and this circuitboard isn't built like that). I am going to solder one on when it arrives, and see what I can do. (This debug port is labelled Connector 'E'; I haven't been able to find Connector D anywhere yet!). The debug port has the ability to read the firmware of the ECU (unless Toyota blocked it.....)

-> Of note, this chip does NOT have the ability to erase itself if it detects attempts to read the flash, if the flash has been protected, which is reassuring.

(Also of note; the NWH20 'Main ECU' (I am not sure if that means engine or hybrid control) uses the 78F0040GD chip, and earlier models used the 76F0038GD chip. The ROMs for these can be found (in some iterations). Also, there is an EPROM hidden somewhere else in the car that can be used to do good things like convert to and from KM / MPH, to reset the mileage (good if upgrading once you get to 299,999km or miles), and change a few other things. It is also possible to reprogram the immobiliser to a new key if you lose all your keys; the procedure involves soldering, programming an EPROM, and also involves leaving the car sitting for a long time in a certain state with a battery charger connected ideally - so reduces the risk of 'hot-wiring' the car
-> The fact that the NWH20 ECUs use very similar chips means that reverse engineering the battery ECU (in particular the main CPU) will be very helpful for reverse engineering the other two main ECUs (engine + power control).

My current plans are, therefore:
1. Experiment with the 1000 ohm resistor - this will be done by getting a voltage reading, removing the battery cover in situ, and literally jury-rigging the resistor between the battery sense connector wire and the battery itself on one of the blocks, then powering up and seeing what happens to the reported voltage and reported internal resistance. If it causes no problem, that I will make a loom with 1000 ohm resistors in each sense wire, and that will be the end of battery ECU shorts / burnt connectors.
2. Await the JTAG connectors to arrive, solder one on, and have some fun!

 

Toyota actually did us a favour (sort of!) - the Toyota Battery ECU is 'overly sensitive' and panics early. This technically saves the battery pack; I bet the GM hybrids would keep trying to 'charge' up the bad module, and end up overcharging all of the other modules (slightly, but chronically), trashing the whole pack by the time the third cell fails in one of the modules.


========NISSAN LEAF NOTES=======
Since I am posting I will use the opportunity to dump some info I found (I ordered a good condition second-hand Nissan Leaf Battery computer and it arrived today. It actually has tiny, tiny metal whiskers all over the high-voltage side (very tiny - no risk at all). Yet. It also has a lot of nice protective resistors to reduce any possible current from the HV sense connector, to prevent short circuits. I haven't opened my actual Leaf, but I believe there are no resistors between the actual Li-Ion cells and the HV sense connector. I haven't researched enough, so this is just a belief. I hope it is a false belief, because otherwise, in a few (ten?) years, Nissan Leafs (Nissan Leaves?) in humid / salty / warm climates might get more exciting.

As a side note, the Nissan Leaf BMS also uses a very similar microcontroller to the Prius BMS. Specifically the Leaf uses an NEC UPD70F3236 chip (although NEC is now called Renesas but I will probably use 'NEC' for a few years as I know that name!). The chip has the same instruction set as the Prius Gen 2 battery computer (and likely others, as the processor was made in the 90's and is still being made now). The Leaf BMS is made by Calsonic Kansei rather than Denso (which makes sense as Denso is a Toyota subsidiary). I just searched for the codes on the chips (24 of them) which are linked to the high voltage sensor modules. I won't waste my time on these any further, since I found this thread:
BMS Details - My Nissan Leaf Forum
Like the Toyota battery ECU, the motherboard is double-layered, and the HV side is 'transparent' when shining a light through. The LEAF BMS computer is quite simply designed - the layout looks 'simple'. The result is a much larger circuitboard than the Prius, but this makes sense as the Prius means 'first' and Toyota went all-out in all aspects of the car.

The Leaf ECU is known to be disgustingly locked down (so much so that if you swap another one into your car, it will say 'invalid battery' on the error codes). Many used imports come with hacked battery ECUs showing the Li-Ion state of health as being much better than it really is, so the hackers already know what to do. But, for normal people, if you need to replace the battery ECU, it is actually paired to the other ECUs, and only Nissan dealers can 'activate' the BMU so it works. (at least, with the current firmware).
=======END NISSAN LEAF NOTES=========

Strawbrad : you are operating at a much higher paygrade than I am! Reading your post again, I realise I basically re-iterated what you meant earlier in this post - the GM ECU allows a fault in one module to trash the whole battery before the check-engine light or equivalent comes on. That means less warranty claims but much more damage to (customer wallet, environment, etc!). The only skill I would claim to have in this area is assembly language programming; if I can get into the flash of these battery ECUs, I could (as a hobby), maybe do some interesting things. It could be possible to make the Prius give a warning when you get the battery voltage alternating positive and negative (before the plasma arc happens), but also make the Prius have a way to have a long-term 'limp-home' mode that doesn't destroy the other modules even when one goes bad. I have a few ideas re: the similarities between the Leaf and Prius ECUs but these are way beyond my knowledge level at the moment

 

Current status of Battery ECU project:
I have managed to 'redraw' most of the ECU circuitry into a circuit diagram on my computer - the HV side is quite simple.
My research has shown that Toyota ECUs are *extremely* locked down. They are basically the iPhones of car ECUs.

My current focus will be to see what happens if I insert a 1k ohm resistor into one of the voltage sensor leads, and if it makes no difference, to design a loom (e.g. purchase and cut / solder 1k resistors into an OEM HV loom) to prevent the electrical arc failure mode. Thinking of it logically, my main aim would be to prevent electrical arcs in the battery ECU which cause risk and which cost money for no good reason.

In the background, I am studying Toyota ECUs in great detail

 

Still looking for a spare loom that isn't overpriced! I am likely to repair my original burnt ECU and insert a 1k ohm resistor into the repair of one of the blown pins, and can use that to experiment (using EngineLink to read the cell modules, and swap the BMS over with the battery in a 'known' state; this should allow an observation of what happens when there is 2k ohm in a voltage sense line (if it makes a difference, the difference will be an under-estimate of the state of charge, and a consequent over-charging of the battery). It all depends on how much time Toyota have given the sample-and-hold circuit to charge the sampling capacitors - if they can become charged to the same voltage as the module-pair being sampled, it would be fine.

I am continuing to write a V850 + associated peripherals emulator. This is progressing; one thing that interests me is that the Nissan Leaf BMS just so happens to have a SoC which, unlike the Prius ones, has the entire datasheet, but also the entire user manual with memory map and so on, downloadable. What would be awesome would be to reprogram a Leaf BMS to communicate across the CAN and pretend it was a Prius BMS. It would require a lot of reprogramming as, among other things, fewer modules would be involved to bring the voltage into 'Prius' ranges. But custom code could easily tell the Prius that the battery is at 81% SoC until it gets down to, say, 30% SoC, and to tell the Prius the battery is at 15% SoC to allow the Leaf battery to charge all the way to actual 80% SoC, and so on. This would be particularly useful in mountainous areas, but could also be useful after a long cruise on a motorway, allowing zero or near-zero emissions once in town and so on. Charging 'externally' would be more complex. Fan control would use a DIY controller attached to the Prius fan, given the Leaf has no cooling at all anyway. The problem with Leaf batteries is that Nissan have locked down the supply so much, and they won't even import them to NZ, and they refuse to work on imported Leafs in NZ (although the imports are for a number of reasons including that Nissan stopped selling the Leaf for several years in NZ!).

I will give this more thought. The V850 emulator is key to everything at this stage so I will keep doing that and when I am next near the appropriate shop, will grab some 1k resistors, and see if I can repair the 'blown' Prius battery ECU (if I can, that too will be interesting).

The main update at this stage is that in my Prius, I am using the battery which 'blew' the battery ECU, and yet, with a new ECU, it is working fine. So, whatever happened in the ECU wasn't due to a sudden failure in the HV battery. That said, any ECU attached is going to be more prone to corrosion as I am still using the burnt connector so it does require frequent inspections of the batttery ECU.

 

I have a Leaf (but not a DeLorean; one day!). My UK bluebirds however have an interesting design;
My friends always used to call it a DeLorean. Anyway!

I would love to be able to sell my Leaf, get a used battery pack, and just use my Prius; my commute is about 21 miles total, although downhill enough to go from 1 bar on my Prius battery to 'overload' (engine running to drain battery). If I could put a Leaf pack in, and if I could get it to charge it would be very cool. I should admit, here in NZ, my Leaf is trapped in the biggest city. I could track across New Zealand, but I would rely on hypermiling to charging stations which I literally fully rely on to be working, and many destinations are simply off limits as there are no charging stations (or, they would take many hours to charge - Type 2 etc). In the UK, USA, my Leaf would be perfect and I would drive everywhere with the Chademo port and charge it up. I would also attach a fan on a manual switch for the battery pack!

The Prius plug-in tempts me a *lot* but they are still very expensive second-hand here in NZ

 

What kind of a harness is that? You don't mean the high voltage sense harness and orange connector?

 

That was the part that got fried; I would be very happy to buy one from you; will send a PM!

 

Things have been very busy, so I haven't done much. However, I can report that I am still using the same battery, and the same loom (with the burnt connector) with the new battery computer, and the car is running just fine. However I am due to remove the computer and check for corrosion.

In terms of battery ECU analysis, I continue to work on my emulator; I only have ROMs for a Camry ECU, and the Prius HSD computer (interestingly they both have very similar code initially - likely because the code actually runs on top of a proprietary RTOS).

I still need to figure out the sensing stuff as mentioned by ChapmanF above - I need a new oscilloscope as the CRT in mine got knocked out of line when in hold luggage a few years ago.

I am using the Prius as my main car which is another reason for being more cautious experimenting with it. However, swapping the HV battery in and out is easy, and I have a spare good battery (with one dead module), so I might add a 1k resistor to the loom on that battery, on one of the good cells, and see what happens (this battery really is a good battery, with all the modules having a good capacity, and being balanced, except the one module that seems to have a 1.2v cell that 'charges' and 'discharges' in a few seconds, causing all kinds of errors).

 

Yesterday, the V850 emulator made the leap from finding undefined instructions, and not having working branch instructions, and not having much of a memory map, to having all of these. I made a simple UI, and will now work on full support for 'status flags' beyond the rudimentary version I have now. So far I can get several 10,000s of instructions in. Still in the early stages; basically it copies data into the RAM (for faster access I guess), sets all the interrupt registers to their 'reset' values (very helpful and saves me having to do it), and a few other things.

I made an initial UI to allow me to see in detail what is going on. It is and will be in text-mode, as I don't want to waste time on a GUI (yet). I will do that once it is running properly - as I will need to run a few emulators in multi-tasking mode. However, the current progress is as follows:

The status flags are probably not completely correct (but still work up until about 25,000 instructions in). At the moment, they are only set for 'ANDI' and 'CMP' instructions, and then only the 'Z' and 'S' flags. It won't be tough to sort them out but I am adding functionality as it is required - hence the UI to assist in where things begin to break down. Also, I am using slightly different conventions for those who program machine code; 0x0125AEF2h, for example, is written as &0125AEF2, and the instruction at &0000CD56 (BT) - Branch if True - has (EQ), because in ARM code, that would be 'BEQ'. The emulator is actually running on an ARM-based Raspberry Pi running RISC OS, connected via a VNC server to my laptop

 

Improving the text UI;
Processor flags still need to be 'improved' (they are about 10% emulated only); showing the system registers is helpful however. It will take a week or two to move the core emulation to machine code, only after improving status flag control. BRB 2-3 weeks!