Firmware for charger, BMU, CMUs

[coulomb]

Sigh. There is a .csv (basically, ascii readable) file in the RPGDATA folder that I somehow managed to ignore all this time. It tells me a little story about what all the .RPG files are for. In short, I've been largely wasting my time looking at the RPG files, at least the ones I have so far. [ Edit: and at least for the present goal of iMiev firmware. ] [ Edit 2: I suspect now that .RPG files potentially carry several firmware updates; if so, all would be related to a single issue / TSB (technical service bulletin). ]

I've still found no relationship whatsoever between .RPG and .CFF files, though I still suspect that a given .RPG "carries" inside it a .CFF, along with a very complex program to upload it via the VCI.

In case it's of interest to anyone, here is the data on what's in the .RPG files that I have from the 2012 distribution.

Code: Select all

VE03071.rpg  Carisma - Countermeasure for smoke & engine hesitation when high speed
VE03072.rpg  Ditto
VE03073.rpg  Ditto
VE03074.rpg  Ditto
VE03076.rpg  Galant - Countermeasure for smoke/fuel consumption display & magnet
VE03077.rpg  Ditto
VE03078.rpg  Space wagon, as above
VE03079.rpg  Ditto
VE0307A.rpg  Ditto
VE0307B.rpg  Ditto
VE0307C.rpg  Space wagon - Countermeasure for output decline/smoke/fuel consumption display & magnet
VE0307D.rpg  Ditto
VE0307E.rpg  Space runner / wagon, as above
VE0307F.rpg  Ditto
VE0307G.rpg  Galant as above
VE0307H.rpg  Ditto
VE0307I.rpg  Space wagon as above
VE0307J.rpg  Ditto
VE0307K.rpg  Space wagon - Countermeasure for smoke/fuel consumption display & magnet
VE0307L.rpg  Ditto
VE0307M.rpg  Ditto
VE0307N.rpg  Ditto
VE0307O.rpg  Space runner, as above
VE0307P.rpg  Ditto
VE0307U.rpg  Colt/Lancer - Countermeasure for cold hesitation
VE03081.rpg  Ditto
VE03082.rpg  Ditto
VE03083.rpg  Ditto
VE03085.rpg  Pajero - Countermeasure for miss MIL light ON/engine hesitation when cold...
VE03086.rpg  Pajero - Addition ETV position gap detection
VE0308A.rpg  PAJERO/MONTERO - Countermeasure for the high boost
VE0308B.rpg  Ditto
VE0308C.rpg  Ditto
VE0308J.rpg  Carisma - Correct fuel consumption display
VE0308K.rpg  Ditto
VE0308L.rpg  Ditto
VE0308M.rpg  Ditto
VE0308N.rpg  Ditto
VE0308O.rpg  Space Star - Countermeasure for error MIL light ON
VE0308P.rpg  Ditto
VE0308Q.rpg  Ditto
VE0308R.rpg  Space Star - Correct fuel consumption display
VE0308S.rpg  Ditto
VE0308T.rpg  Ditto
VE0308U.rpg  Ditto
VE03091.rpg  Ditto
VE03092.rpg  Carisma - as above
VE03093.rpg  Ditto
VE03094.rpg  Space Star - Correct fuel consumption display
VE03095.rpg  Ditto
VE0309C.rpg  L200 - Countermeasure over heat
VE03101.rpg  Space Star - Shock countermeasure of during slow driving with first gear
VE04061.rpg  PAJERO/MONTERO - Countermeasure of hydraulic flywheel
VE04062.rpg  Ditto
VE04063.rpg  Ditto
VE04064.rpg  Ditto
VE04065.rpg  Ditto
VE04066.rpg  Ditto
VE04067.rpg  Ditto
VE04069.rpg  Ditto
VE0406E.rpg  Ditto
VE04091.rpg  Carisma - Countermeasure for engine hard start at extremely cold condition
VE04092.rpg  Ditto
VE04093.rpg  Ditto
VE04094.rpg  Ditto
VE04095.rpg  Ditto
VE04096.rpg  Ditto
VE05021.rpg  Space Star - Countermeasure for engine hunting around 1500RPM on slight down hill
VE05022.rpg  Ditto
VE05051.rpg  L200 - Countermeasure for high idling
VE05052.rpg  Ditto
VE05053.rpg  Ditto
VE05054.rpg  Ditto
VE05055.rpg  Pajero Sport - Countermeasure for high idling
VE06111.rpg  Lancer - Change data related to engine startability at low temperature(for Russian fuel)
VE06112.rpg  Ditto
VE06113.rpg  Ditto
VE06114.rpg  Ditto
VE06115.rpg  Lancer - Delete intermittent control of A/C. Change IG timing for knocking suppression...
VE07041.rpg  Lancer Evolution - Change F/C to prevent over rpm limit resulting in catalyst damage
VE08111.rpg  Pajero - Judgement value of the overboost was changed. Judgement time of the overboost was changed
VE08112.rpg  Ditto
VE08113.rpg  Ditto
VE08114.rpg  Ditto
VE08115.rpg  Ditto
VE09021.rpg  Pajero/Montero - Optimization of fuel control on deceleration. Changed ISC control on engine starting
VE09022.rpg  Ditto

[coulomb]

Another reverse engineering nerd specific post; feel free to skip if this isn't you.

It's taken me a while to learn the tricks of the CMU's compiler. It loves its register branch instructions, so some functions use the link pointer for the return address (as you'd expect), and others use random other registers. Why not, I suppose, when you have 32 to play with. It makes it very hard to visualise the control flow, and of course Ida Pro's guesses as to where the functions start and end are sometimes wrong, and tedious to fix. Most functions start with a branch to the end of the function, where there is a prepare instruction (a procedure prologue), then another branch back to the real start of the function (just after that first branch). I'm sure that there must be a really good reason to do that, but it eludes me.

In order to call functions from an array, which happens quite often, there is a problem: there is no call instruction that takes a register as the destination; it's always a constant. So they use this complex sequence; in this example, the address of the function to be called is in r16:

Code: Select all

movhi   1, r5, r1
movea   (loc_96DC & 0xFFFF), r1, lp
jmp     [r16]
loc_96DC:

So the movhi instruction moves 1 to the top half of r1, and adds the contents of r5. What's in r5? It was set waay back before the start of main to be zero. There's a perfectly good always-zero register (r0), but they always use r5. I can only imagine it's good for debugging or some such thing. The movea moves the lower half of the destination (0x96DC), and adds r1, and the result goes to the link pointer. So that's the return address. But wait: there is no one in the upper half of the address! Because the destination (0x96DC) has the sign bit (bit 15) set, the offset is sign extended to be a negative number. Negative offsets are wonderful to this compiler But this negative number added to the 0x10000 already in r1 results in the correct 0x96DC. I finally twigged to this when I got to some code where the destination really was above 0x10000 (64 KiB), and it actually made sense. In many cases, these weird sequences are the only way execution gets to the destination, so of course Ida Pro can't recognise that it's code, and it starts off as unexplored data. That causes a cascade of unexplored code that is called only by that code. At least there isn't much data interspersed between the code, so it's largely a matter of marking big blocks of data as actually code.

99% of references to RAM are via the global pointer register, gp. I've finally figured out how to use enough of Ida Pro's user-defined offset to get what I need, but RAM references end up looking like this:

ld.b (byte_3FFD88C - 0x4005000)[gp], r11

That's just loading the byte at 3FFD88C to r11. The global pointer always contains the strange value 0x4005000, which is 20 KiB past the end of RAM, so all the references to RAM are with negative offsets. But it can't reach all the way to the start of RAM (0x3FF8000), so it seems to me that the first 0x3000 (12 KiB) of RAM are special or different.
There is also some special hardware or external RAM mapped to 0x3FEC000-0x3FFFFFF, which are referenced with negative offsets from r1. Because... negative offsets are beautiful!

The code is also very heavy with its use of arrays. There are arrays in RAM and also plenty in flash memory as well. There are arrays of pointers to functions, pointers to RAM (which point to other parts of RAM, or act as indices into other arrays), or of course to other structures in flash or RAM. There are many "arrays" in flash with one entry, always accessed with index 0, so the value is always a constant.

While I'm at it, here are the two most useful manuals for CMU work:
R01US0037EJ0100: V850E2S User’s Manual: Architecture (for the instruction set)
U18743EE1V2UM00: User’s Manual V850ES/Fx3-L 32-bit Single-Chip Microcontroller
[ Edit December 2020: was R01UH0129ED0701: V850E/Dx3 - DJ3/DL3 32-bit Single-Chip Microcontroller (for the many special function registers). This seems to be the wrong manual. ]
Hopefully useful soon: Linear Technology Multicell Battery Stack Monitor manual; the command codes for the LTC6802 chip start about half way through the manual.

With these breakthroughs, I hope to finally get to the meat of the code. It's been frustrating to date, seeing lots of code, but none of it does much so far.

That's for the CMU (Cell Management Units). It would be better to reverse engineer the BMU code, or the charger, but I don't have a .CFF file for the charger, and I've made no headway at all with the code for the BMU, other than hopefully finding what looks to be the correct processor series (M32r series). My suspicion is that most CFF files are encrypted, but the CMU code may have fallen to a junior engineer, or the engineer simply forgot, or thought it wasn't worth the effort to encrypt. With that in mind, I've had a few quick passes over the MUT PC software, but I haven't hit on a reference to CFF files as yet.

Edit: I meant to add a paragraph about the PC-relative addressing. For a long time, I had no idea where the start of the code is; it turns out to be about 0x55AE, but perhaps the real start is 0x6000). All branch instructions are PC-relative, so they're no help. Often you can find interrupt vectors, but I still haven't found one that ends in a reti (return from interrupt) instruction. Eventually, I found some absolute addressing code, but it wasn't special enough to be able to find it in 384 KiB of flash memory. Eventually, I found one that had a particular "signature" (like an array of structures containing a pointer to RAM that was always followed by a byte), and was able to match it to such a pattern in flash memory.

Oh, one last whinge. Ida Pro (which goes back to the glory days of 16-bit 8086s) talks about bytes (8-bit), words (16-bit) and longs (32-bit). Modern 32-bit machines such as this one talk about bytes (8-bit), half-words (16-bit), and words (32-bit). The number of times I've seen a load.w instruction and thought that it refers to a 16-bit thing like word_876C is... too many

[ Edit: added sentence about flash arrays with one entry. ]
[ Edit: Added link to LTC6802 manual. ]

[kiev]

Great work as usual, thanks for sharing. i know you have the knowledge, skills and abilities to solve complex codes such as this, and so encourage you to endeavor to persevere.

Makes you wonder who wrote the compiler with all the bizarre and complicated twiddling just to point to a jump address or a memory register.

And then to use different families of processors across various ECUs is a strange strategy. Seems that commonality would lower costs for development and testing, etc., but maybe it was done intentionally to avoid mistakes of loading the wrong code..?

[coulomb]

More information on the 2012 distribution. This is the starting post:

https://mhhauto.com/Thread-MUT-III-2012

In the first post of that topic, there is a .rar file. It just contains a .torrent file, which allows you to download a CD-Rom's worth of install data (about 800 MiB). I note that there are passwords mentioned in later posts, but I've not had the opportunity to use them as yet.

There are two main folders: PRE11121-00 and CD3E11121-COPY MASTER. I think you're supposed to install the first one first, then the second folder is a sort of add-on (edit: in fact, an update). Both folders have their own InstallShield executables. When I try to install the former, I get a message box with "The M.U.T.-III system has started. Please suspend a M.U.T.-III system, reboot a personal computer, and start UPDATE."

"UPDATE" probably refers to the other folder, see below.

All the folders in PRE11121-00\INSTALL have encrypted cabinet files; they seem to have customised InstallShield individually for each folder. I see talk of PUBLIC_KEY, and I may have stumbled onto one of the private keys. It could take decades to sort all that out.

But I think that the interesting part for iMiEV users is in the second folder, CD3E11121-COPY MASTER. One subfolder, CAESARCOMPDB, seems to have encrypted cabinet files, and may contain information about the CFF files. So I might make an effort to install that one day. I get "M.U.T.-3 system has started. Please perform after ending M.U.T.-3 system" for the CD3E11121-COPY MASTER update. Maybe it's OK to have the 2018 MUT system, and still use the CD3E11121-COPY MASTER update files.

However, one folder of CD3E11121-COPY MASTER doesn't seem to be part of an encrypted cabinet; it's MUT3\RPGDATA. It contains some 88 .RPG (ReProGram) files, and a similar number of .cff files in CD3E11121-COPY MASTER\RPGDATA\CFF. In my earlier head-slap post, I mentioned how the .RPG files seem to be all for other vehicles. Only four files, all starting with 9499 (this seems to be a product code for iMiEVs), seem to be iMiEV related. I have one other iMiEV file from another source, and it appears to be another version of two of these four. Of these five iMiEV related files, only one, which appears to be the firmware for the CMUs, seems to be unencrypted. Given the paranoia associated with all the other MUT-III files, this seems to be a miracle. Unfortunately, it's looking very much like the CMU processors don't do all that much, despite their quite complex firmware. All they seem to do is to send data to the LTC6802 battery stack monitor chips, copying the commands downstream, and sending the data upstream to the BMU. I don't see any of the commands, since these would come to the first CMU from the BMU. There doesn't seem to be any interpretation of the results; that seems to all happen in the BMU.

So at present, I'm stuck. I need to figure out how to decrypt the four encrypted .CFF files (three are for the BMU, one for the EVECU). It also appears that out of all this data, no file contains the charrger firmware, encrypted or otherwise. Hopefully, I'll get some inspiration soon.

[ Edit: added sentence about passwords mentioned in later posts from the first link. ]

[coulomb]

CAN bus messages on the BMU to CMU private bus

I'll attempt to give these messages in the format of Decyphering iMiEV and iON CAR-CAN message data . Since these messages are only on the private BMU to CMU CAN bus, and seem to be modified when they reach the BMU and the main vehicle CAN bus, this will only be of interest to those wanting to use the CMUs that come with the iMiEV battery, without using the iMiEV BMU. Since the CMUs are buried inside the battery, it makes sense to make use of them.

I have not used these, or captured data from a real iMiEV; this is all from reverse engineering the CMU firmware. I'm finally making some progress in that direction.

Cell and temperature sensors will be numbered from one as the lowest number. It may be of interest to some to compare these with the 6D1-4 / 6E1-4 messages documented over 6 years ago by garygid in this post.

From CMUs to BMU

6n1, where n is the CMU ID, 1-C, for the 12 CMUs:
6n1:D1 = 0x20 (if boolCan1) + CMU ID. So either 21 to 2C or 01 to 0C.
6n1:D2 = bypass bits. Each bit will be set if the cell was actually bypassing at least sample.
6n1:D3, D4: Temperatures 1 and 2. I believe that these are in whole °C with a -40°C offset. So temperature = value - 40. Limits 20 - 130 representing -20°C to +95°C. I can't be certain about the offset (-40).
6n1:D5 & D6 as ((D5 * 256) + D6) / 200 + 2.1 = cell voltage 1
6n1:D7 & D8 as ((D7 * 256) + D8) / 200 + 2.1 = cell voltage 2

6n2, where n is the CMU ID, 1-C, for the 12 CMUs:
6n2:D1 = 0x20 + CMU ID. So 21 to 2C.
6n2:D2, D3: Temperatures 3 and possibly 4. Same encoding as above. D3 will be zero if n=6 or n=12 (4-cell CMUs).
6n2:D4 = 0.
6n2:D5 & D6 as ((D5 * 256) + D6) / 200 + 2.1 = cell voltage 3
6n2:D7 & D8 as ((D7 * 256) + D8) / 200 + 2.1 = cell voltage 4

6n3, where n is the CMU ID, 1-C, for the 12 CMUs:
6n3:D1 = CMU ID. So 01 to 0C.
6n3:D2, D3: Temperatures 5 and 6. Same encoding as above.
6n3:D4 = 0.
6n3:D5 & D6 as ((D5 * 256) + D6) / 200 + 2.1 = cell voltage 5
6n3:D7 & D8 as ((D7 * 256) + D8) / 200 + 2.1 = cell voltage 6
I believe that CAN IDs 663 and 6C3 (for CMUs 6 and 12) will not appear (unverified at present).

6n4, where n is the CMU ID, 1-C, for the 12 CMUs:
6n4:D1 = CMU ID. So 01 to 0C.
6n4:D2, D3, D4: All 0.
6n4:D5 & D6 as ((D5 * 256) + D6) / 200 + 2.1 = cell voltage 7
6n4:D7 & D8 as ((D7 * 256) + D8) / 200 + 2.1 = cell voltage 8
I believe that CAN IDs 664 and 6C4 (for CMUs 6 and 12) will not appear (unverified at present).

6nF, where n is the CMU ID, 1-C, for the 12 CMUs:
To be completed.

From BMU to CMUs
3C3:D1&D2 as ((D1 * 256) + D2) / 200 + 2.1 = bypass voltage (bypass if cell voltage exceeds this value, and bypassing is enabled)
3C3:D3 =0 to disable all bypass bits; =1 or -3 to bypass when cell voltage exceeds the threshold voltage; =2 to set all bypass bits.
With value 1 but not 3, if the threshold voltage (NOT cell voltage) is < 2.5 V or > 4.3 V, then turn bypass bit off.
With all values of this byte, if the cell voltage is > 4.3 V, the bypass bit is turned off.
3C3:D4[0-2]: other flags, use not determined as yet. But bit 2 may enable auto-renumbering.

6F0: Similar to 6Fn below, but manipulates many flags, possibly including the stopping and restarting of CMU data to the BMU. At one point, calls the same code that handles 6Fn messages.
6Fn, where n is the CMU id (1-C): Still unknown, but seems to result in some data sent over 3-wire SPI. These connect to the EEPROM, the S93C76A part.
D1[7-4] is an opcode, 0-3.
Opcode 0 has a 4-bit data length in the lower nibble of D1. I'm guessing the data, if <= 7 bytes, is in the rest of the message (D2-D8).
Opcode 1 has 24-bit length, upper 4 bits in lower nibble of D1, rest of length in D2.

There appears to be another CAN packet, or possibly serial packet, that mimics the above (i.e. it provides alternative bypass threshold and enable bit). I have yet to determine where this comes from (handler at 0x0E3C0).

To be completed.

[ Edited December 2020: Added mention of 6F0 and 6Fn. ]

[kiev]

Posted wiring harness details in my CMU circuits thread.

The HV digital isolator chip, AD UM1402W, passed 4 signals across an ~4mm isolation gap in the copper, which i will refer to as the HV (pack side) and LV (module side).

Two signals across the gap into the LV side: the CMU pin 3 serial comm into micro pin 37; and the RxD output (pin13) of the TLE6250G CAN transceiver chip to pin 16 of micro.

Two signals from the LV side: micro pin 18 to the TxD pin 1 of CAN Tran; and micro pin 36 out to CMU connector pin 7

There are 4 electrolytic caps on the board that share same ground plane on their respective sides:

2 on the HV side
100uF 35V holds 12VDC
47uF 16V holds regulated 5VDC

and 2 on the LV side
100uF 35V holds the module voltage (depending upon 4- or 8-cell module)
47uF 16V hold regulated 5VDC

Schematic-type circuit drawings can be found there also.

[coulomb]

I'm going to post a photo of the EV-ECU board here, just because I confused a BMU with this one.

It's easy to tell them apart (when your brain is working, as mine was not): the EV-ECU has 4 3-level connectors; the BMU has 2 2-level connectors. The EV-ECU seems to be a fair bit bigger, maybe almost twice the linear dimensions (almost 4 times the area). Duh.

They both have the same main processor: MH8106F.

[coulomb]

It seems that it may be possible to read the firmware of a BMU, using Russian software that costs US$60 and a little hardware. I'm very hazy on the details, but it seems that we need to find the BOOT signal. It's not marked on any schematic that I'm aware of. My suspicion is that it will connect to a particular pin of the MH8106F microcontroller, probably via some buffering or at least protection.

From Facebook page MMCodingWriter - tool for manage ECU coding on Mitsubishi vehicles:

"World first. Recovery mode for MH8115F & MH8106F via CAN-bus. Later also will be added repair for MH8601 (Eclipse Cross) and old k-line. (Recovering and reading ECU from any state - bricked, locked, etc)
https://forum.kolyandex.su/viewtopic.php?f=14&t=281"




The pin diagram will be from some common Mitsubishi engine and transmission ECU. It looks like we'll need to find the BOOT pin.

On Facebook, I asked:

"I see the above is intended for ECUs for engines and transmissions. Is there any chance that the same techniques can be used to extract BMU (Battery Management Unit) firmware from Mitsubishi iMiEVs, and possibly Mitsubushi Outlander PHEVs? They use an MH8106F microcontroller.
Or is every CMU firmware access completely unique?
In your opinion, what are the chances that one of the known bootloaders from an engine or transmission would be used in the BMU? I'm guessing that this is critical to success in reading firmware."

The reply from the author:

"I think bootloaders are same and that method will work."

I'll have to try and get my hands on a BMU to try to read it, the VCI hardware, and this software. In the meantime, does anyone have any clues on how to find the BOOT pin? Do we have any data on the MH8106F processor? It seems they deliberately are keeping it obscure, presumably because they don't want people messing with engines and causing danger and/or pollution.

We know a few connections to the BMU from this schematic:



Anyone know what KSIG on the BMU is about? Could this be "K-line" communications, that ends up at the OBG-II port?

[kiev]

i wonder if there might be a Boot pin on the JTAG interface on the BMU board?

There seems to be 2 approaches to modification of the battery capacity for upgrading or replacing the pack with larger cells, either spoof it with a CAN bridge (man in the middle) or change/reprogram the value in the BMU.

Do you have any thoughts or opinions about those approaches and the likelihood of success?

[coulomb]

i wonder if there might be a Boot pin on the JTAG interface on the BMU board?

Could be. But the BMU firmware seems to be encrypted; only the CMU firmware seems to be unencrypted.

There seems to be 2 approaches to modification of the battery capacity for upgrading or replacing the pack with larger cells, either spoof it with a CAN bridge (man in the middle) or change/reprogram the value in the BMU.

Do you have any thoughts or opinions about those approaches and the likelihood of success?

I had pretty much given up on making sense of the CMU code, and have not even been able to start on the BMU, because of the encryption.

But Kolyandex seems to have a way of getting to the firmware, and has "reversed" it:
viewtopic.php?p=44300#p44300

But he seems to be more of a "buy a solution from me" than a "share what I know" kind of person.

Given the difficulty of dealing with Russian companies in the present circumstances, it seems to me that the CAN bridge solution is far more practical at present.