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

I've thought about modding the nav ECU also; would need to figure out how it works (to complicate things, mine is more 'digital' and has draw commands send over the CAN bus I think, but earlier Gen II use a more 'basic' one which is like a computer monitor. The earlier one is more hackable as you could likely connect an alternate hardware such as a Raspberry Pi to it and maybe have a switch which flicks over to a super display mode. Will need to do more research into the differences between them and when the changeover occurred. My knowledge around this is from years ago, before I owned a Prius, and may well be totally wrong. But either way the nav ECU will still be a CAN-BUS device and be hackable!

I need to learn more about the HSD; as a 'thought experiment', around increasing performance, if there was a transaxle (and inverter etc), that was infinitely strong, could not overheat, but it still had the max power output of the motors in the Prius, then I do know that the engine is connected to the wheels via the transaxle, with no direct connection between engine and wheels. If one was to combine the 'infinitely strong' transaxle with a 2000BHP engine, then the engine would be able to overwhelm the motors, which would then charge the battery by generating power (in their attempt to provide resistance against the engine and turn the wheels).
- There would eventually be a point where the transaxle could not provide enough torque to 'counter' the engine; in addition to charging the battery a lot, there would be a point (ignoring overheating etc), where the transaxle would end up 'overspeeding' when the engine is at full throttle.
- The question is - at what point would this actually occur? I am sure there is a good amount of 'headroom' to make the car faster.
- If not, I wonder if anyone has swapped the biggest hybrid Camry engine into the Prius?

Regarding the ECU emulator, I have reached a milestone, and a challenge.....
1. I have managed to get to a point where all the setup code completes successfully and the ECU enters 'standard' mode
2. The standard mode consists of enabling interrupts, and going into a loop. Waiting for interrupts.
- This means I now need to examine the final state of the interrupt registers, setup etc, and start simulating interrupts, otherwise I can't get much further!

The standard Camry ECU ROM file I have also enters the same loop, right after enabling interrupts, so the setup is indeed very similar for quite different ECUs (HSD vs non-hybrid Camry).

 

I’ve got to the point where I have some text based tools to look at interrupts; also I can manually set an interrupt to ‘call’, then trigger the interrupt once the ECU is ‘ready’. Only 6 interrupts are initially enabled, 1.66 UARTs (UART one and 2/3 of UART 2) and another thing. However most interrupt handlers are in place in the jump table, so, it seems likely the ECU dynamically enables interrupts as needed. It takes about a second to get to the ready state (using non-optimised BASIC). The next step is to implement the ‘PREPARE instruction; I am definitely getting deeper into the code.

It would be amazing to get the simulator running, but, worst case scenario would be reverse engineering and flash reprogramming. Best case would be a simulation of the computers with sensors etc, and a way to reprogram over CAN with manual flash programming as fall-back. the lack of info on the system makes this a challenge but I am further than I thought I would get so far!

I still need to crack the bizarre encryption on the CUW files, as that could get me an engine computer ROM (I only have HSD so far). The battery ECU is the most challenging since it will require a manual flash read; there were never any updates for it, and hence no CUW files...

 

More instructions implemented (including PREPARE). Learning more about many things. Whatever happens with this code, even if it is impossible to get the info to fully emulate all the peripherals, it will be possible to make 'source code', particularly helpful when many jumps are calculated at run-time (jump to register), so the code isn't easy to understand with a simple debugger.

Current status:

I am adding features as needed; the status flags are still poorly emulated (better than before), but I refine areas of the emulation when I get infinite loops, or loops that overflow, or other things. I am going to use this simple UI for now as it helps to see what is going on. Currently, key '1' shows the active and inactive interrupts, and key '2' fires off an interrupt as 'hard coded' into the code (can be changed in seconds). I let it run in fast mode until the CPU is 'ready' (now takes about 1/3 of a second), then fire off said interrupt.

This undefined instruction is currently annoying; the opcode '110010' would be simple, but the '00000' on either side mean that the manuals I have so far don't yet define it, at all. On an alternate note, I found a full documentation for the floating point instruction set, which is a bit more difficult to find. I don't yet have the SIMD instructions and they are only released to automotive manufacturers... [EDIT - it is the 'DISPOSE" instruction (one form of it), the opposite to PREPARE - 11001x and listed elsewhere hence the confusion!]

The SoC only has a small amount of RAM, and is interesting to see how the stack moves up, as stacks are inclined to do. As a simple embedded SoC, the stack shares the linear RAM space with the other RAM data. If the stack was to get too big, it wouldn't be too good.

There are already professional, and also open source, V850 simulators. However I will work on this one as it will be open source when it is worth anything to anyone (you need a Raspberry Pi, or just an Acorn Risc PC emulator) to use it. Also it is tailored to ECUs, and will allow several simulations to run at once to simulate a 'CAN' network. Maybe. One day.

 

I have found out some interesting thing about interrupts. Basically, they can be referred to in hex code, from &80 upwards (hardware ones are below this).

The V850 ROM has a jump table at the start; there are 4x 32-bit words for each interrupt; they are empty except for the first word (which branches to a 'handler'). I guess the 4 instructions allows for a super quick return in other applications?.

So. The interrupts of interest go from &80 to &750, in steps of &10 (being 4 x 32-bit words each). Each jumps to a handler.

The interrupt entry points in the ROM (from addresses to &750) all jump to one of only three handlers.....

HANDLER ONE
'Handler one' looks at a table stored at &9AC. This is a table of addresses. From here, it jumps directly to a routine.

Looking at the table of addresses (which actually covers all interrupt addresses from &80-&750)...
The addresses which are for interrupts for 'handler 2' branch to a series of unique addresses
The single address for the interrupt for 'handler 3' also branches to a unique address
All other addresses go to some code that is guaranteed to end in an infinite loop.

Thus 'Handler one' jumps to alternate code for those interrupts usually governed by handler two and handler three.

HANDLER TWO : This would appear to handle every interrupt that has a 'useful' function attached
- An exception is &5E0, which is under 'handler 1' in the initial ROM jump table, but has a unique address in the second table.
HANDLER THREE : This only hands a single interrupt, &6E0.

This is all complicated by the fact that the code disables all interrupts except &540 to &5B0, before the CPU 'stabilises' after the setup routines. This means that, in theory, it can only jump to the code that 'guarantees' an infinite loop.

Next steps:
1. Examine the infinite loop code. In particular, do more fixing on the instructions that affect status flags (including shift instructions, which seem to be vital to avoid that infinite loop, maybe).
2. Examine the startup code and see if it should be enabling other interrupts
3. Examine &5E0 and &6E0 among others. &6E0 seems interesting, having a unique handler.
4. Obtain battery ECU ROM (I am using the HSD ROM (Gen 2), which is probably one of the most complicated ROMs!).

One good thing, is that, of about 104 possible software interrupts, only 22 actually have unique code from the 'second table'. This reduced the workload down the line, I hope!

 

Some ideas I had for the battery ECU (these might be controlled by the HV ECU but, if so, that could still be manipulated by the battery ECU)
1. Big hill mode : you press a button, and the battery goes into assist mode; it will likely be at 60% SoC after driving around for a bit, but it drains down to 40% (the usual point when you go to two bars), and stays there. This then gives 40% to recharge down the hill to 80% SOC. This would be good for a few hills I do on my commute, which end up with >80% SoC and wasted energy each time. Technically this should cool the battery down compared to 'business as usual'. It would also ramp up the battery fan to '6' to make the battery cooler prior to the downhill charge mode.
2. Camping mode : usually, when car-camping (which I haven't done but like the idea of - the Prius is an awesome tent so to speak), if people leave the air-con running in summer, the AC runs until the battery reaches 2-3 bars. Then the engine periodically restarts and charges the battery (a bit). Usually still only to 2-3 bars, then starts every few minutes. Camping mode would drain the battery down to, say, 45% SoC, then start the engine, charge it to 70% SoC. This would result in fewer engine starts, and probably also reduced fuel usage as the engine will be running at optimal temperatures for longer if doing fewer, longer runs.

Both of these modes would come with no warranty of course!

(Of note, I'm not sure if the battery ECU 'asks' the HV ECU for more charge, or whether the HV ECU just reads the status of the battery from the battery ECU and decides whether, or not, to send charge. Hopefully it is the former. If it is the latter, an easy way to get around that is e.g. in camping mode, the battery ECU would monitor the SoC internally, but tell the HSD that the battery is at a 39.9% SoC, then tell it it has a 70% SoC when it is ready to stop the engine charging the battery. Charge rate control can be done by spoofing the battery temperature readings if needed. Big hill mode could do the same thing (report a 90% SoC until a true 40% SoC is reached, then report a 65% SoC to have minimal charging, then report the true SoC once it detects the car going downhill (or when you press / release a button or switch) - to allow the battery to charge down the hill).

 

I do agree it may be easy to blow up the Prius if doing bad mods (to the ECUs); There is a document (I think it was called 'the little Prius that could' or something like that; kind of a biography from the designers during the early prototype days. The car featured aggressive electric mode with the petrol engine as a backup assist. The inverters kept blowing up due to excessive current for prolonged periods. I'm sure the inverters are stronger now, but it does provide a warning that the car is designed within certain limits, and exceeding those could cause major failures.

I think an engine swap could be 'fairly' easy; if the engine ECU was of a similar vintage, all that is needed is for the engine swap ECU to talk to the HV ECU and not complain when it gets shut down etc. Admittedly no-one has yet modded an actual ECU as far as I know, on a Prius, but one day I might be able to!

 

For what it is worth, from my experience, the stock Prius doesn't charge at all at full throttle - it puts MG1 and MG2 to max power output, so that side of things should work fine, even without modifications. For an engine swap, the main issue would be to modify the ECU for the new engine to talk nicely to the rest of the car.

The SoCs used do not have any documentation available; they use a V850 processor, but all the add-on peripherals are unique to that SoC. The addresses will be different, as will protocols, and the on-chip peripheral IO maps are similar in some areas but totally different in others. The chip in the battery ECU has no mentions when you google it - it was obviously custom-made for Toyota so they never, ever released a data-sheet. I won't give up though

 

Thank you for posting this - I hadn't seen it (don't have the service manuals yet but have a techstream login for when I want to pay more money - I saved some other info last time and got all the CUW files for my car!). I agree the 'Transmit To' and 'Receive From' are essentially backwards!

It doesn't cover all the signals but is definitely very helpful in understanding how they all talk to each-other!

By the way way I have recently noted that the 2GR-FE engine is also available as the 2GR-FXE. In a few big hybrids (3.3-3.5l V6). Interestingly, this same engine does actually fit in a Corolla, renamed the 'Toyota Blade'. This could be interesting if one gets a crashed car with this hybrid system in (even then, things like the combo meter, smart key, and likely more, will still need some kind of mods, but it does give hope for other Prius mods!

 

In this thread:
P0A2B Red Triangle of death after transaxle replacement | PriusChat
Matt (@Texas Hybrid Batteries) posted photos including of the HV ECU, which is the ROM I am using for initial development of the emulator;

The V850 SoC will be the rectangular chip on the bottom of the board. While I can't read many details, it clearly says 'Toyota', as opposed to e.g. NEC, or having the usual codes. I can tell you it is a custom SoC with all the peripheral mappings, memory-mapped registers, and interrupts, in different places! This makes it tough to reverse engineer.

Looking at the accessory chips, it explains a few things, and I have found that (logically, in retrospect), it is possible to figure out a lot of the mapping by looking at published specs for 'mass market' chips, because they tend to be in 'blocks'. Yesterday I figured out quite a bit doing this (before seeing this photo, but I found the links for the two chips on the right of the picture in the code - no idea what they are for yet of course!!)

I have ordered a 'machine' that attaches to the JTAG port, which can be used to read the flash; I am going to use this on a battery ECU soon. The HV ECU really seems like something that shouldn't be messed with (that much), as it does so many unique things. The main changes I would make would really be if it is involved in the speed limit for the 'EV button' mode, and perhaps increasing the point when the engine spins up to protect MG1 from 65km/h to 71km/h (should still be safe, and would save a lot of fuel in my particular circumstances).

An option to change between MPH and KM/H would also be nice; it is 'disabled' on my car. That is probably in the instrument cluster.

 

I am rewriting my V850 emulator at this stage; it is being converted to a desktop GUI, but more importantly, the instructions are being converted into a microcode that I have created to reduce the risk of issues caused by coding each instruction manually (particularly with flags). This conversion will take a few weeks, as it is a hobby I do at home, rather than my day job.

If anyone ever comes across any binary, CUW, rom dump, etc, for the battery ECU for any Prius, (Gen 2 especially, but any Prius), please PM me!. I will be away for a few weeks while working on the conversion to 'version 3' of my emulator.

I will release my emulator when it is usable and doesnt crash all the time with errors reported in a format that only I understand! To use my emulator, you need to install an emulator, 'Risc PC Emulator', google 'RPCEmu Spoon Edition', which can be done on Linux, Windows, MacOS. Unlike most emulators, the operating system is RISC OS 5. this can be downloaded for free from http://www.riscosopen.org.

Easier, and definitely simpler, is a Raspberry Pi credit-card computer - I am using one, running RISC OS 5, and a VNC server via an ethernet cable. It can be used via WiFi but it messes up my wife's WiFi for some reason, so I reverted to the cable!.

(However, once the RPCEmu software is installed, and RISC OS is up and running, it is very simple from then on). I am happy to help anyone who wants to join in on this journey with either their Raspberry Pi, or RPCEmu install on any computer that supports it!

I will post again in a few weeks; if anyone could contribute, the CPU is a V850 (lots of documentation available), and the ECUs are all connected via CANbus 'ethernet'. I don't actually have the battery ECU ROM / any dumps, but it doesn't actually matter, because I have a long way to go with my emulator (I am working from the ground-up, which is pretty tough!)

 

Edit

 

PS If anybody, at any stage, can get me a Prius Battery ECU ROM (any generation), or a Leaf ECU ROM (any generation), or any Tesla ROMs at all, I would love to hear from them!

I have nearly cracked Toyota's ECU encryption so, the 'CUW' files will soon be 'open compiled' (not open source, but the raw machine code will soon be available. I will only release this far cars no longer under any warranty in California, or elsewhere worldwide; I respect Toyota for even making the Prius despite Caltex and their patent abuse, but want to help classic Prius owners keep their cars alive.

 

I hope you got it sorted! My Prius ran fine after the work I did, but I had a sudden hybrid system failure on a motorway! Triangle, 'Problem', and many other dashboard lights. I drove it another 60 miles with extreme caution, and in 2 weeks time it is booked into a Toyota garage for repair (and it is the hybrid / inverter cooling pump that failed, so literally i am getting it replaced with a new part for free, in 2021, despite it being a 2008 car).

If you are still having issues with your car, please post photos of the burnt pins - or anything / everything that is important. However, it is usually very easy to fix the 'burnt pins on battery ECU' problem - my Prius still has the *same* High-voltage battery it had from brand-new; it still performs well. So, if you get burnt pins on the battery computer, you can replace it and your car should be fine. But you need to get a new battery 'loom' - my battery had sulphuric acid pour on it, and dry out, causing sulphuric acid fumes every day for 2+ years - causing the failure of the battery ECU.

Please reply if you still have issues with your car! Otherwise I will keep working on the Gen2 Prius ECUs (to allow them to be re-used to reduce wastage in this throwaway society); this will extend to Gen3 Priuses very soon. Happy New Year 2021; keep safe!

 

Not really; I've been tinkering with emulation of systems with a view to return to this; reading through the datasheets for various V850 chips does show that the SoCs in the Prius, while custom, are probably designed (at a silicon level) in 'blocks' (e.g. 'bolt on x number of CAN controllers etc - for the SoC at hand).

The issue I faced ages ago was getting the binary files for the ROMs. The CUW files are encrypted, and it seems to be a variant of ('blowfish' encryption if I recall correctly). However... the official update mechanism involves booting up the car, attaching a 12v battery tender to prevent 12v failure during reprogramming (which would be bad); and then TechStream feeds the new ROM data to the ECU, which reprograms itself, and it can take a number of hours.

The ECU for the Gen 2 battery ECU (and probably the others) has a JTAG connector on it. This could be used for 'out-of-car' reprogramming. The barrier at the time was the expense of doing this 'the right way' (using a 'frame' type thing with pins that press onto the JTAG pins (which are flat bits of solder) on the ECU).

The other issue was that the documentation for similar NEC / Renesas SoCs show that you can flash the chip directly - and also read the data off the chip directly. However, there is a 'bit' that you can set when writing, which means 'you can't read what is already on the flash'.

I've heard that bit is set, but I've also seen ROM dumps for random Toyota cars, and today found one place that seems to have a binary dump of 'AN ECU' for the Prius PHEV, (which leads me to something that didn't exist earlier... time to investigate)...