Posts: 106
Joined: Sun Jun 10, 2018 8:32 pm
Location: Brisbane, Australia

Firmware for charger, BMU, CMUs

Sat Aug 11, 2018 7:25 am

I'm feeling the need to upload some information from my brain to this forum. I'm a noob here, so please direct me to better places to store / discuss this information. I'm chasing some leads on MUT III update files. The MUT III is the Mitsubishi Multi-Use Tester, although MUT perhaps refers to the software rather than the machine itself. It seems to be the way that all Mitsubishi cars and trucks interface the various ECUs with a computer, for reading and clearing error codes, updating firmware, and much else. There are CDs with install files that go on the computer, and it seems that some of these, the .CFF files, may contain firmware for the various ECUs, such as the BMU and the charger. Unfortunately, my data source is not terribly reliable, and I only have firmware files at present for the BMU, MY 2010 and MY 2011.

The charger and BMU use totally different microcontrollers, though both are 32-bit Renesas RISC processors. Thanks to forum member @Kiev, we know what these processors are.

The charger seems to use this microcontroller: R5F71424AK64FPV . Kiev called it a R5F71424FPV (edit: missing the AK64 part), but that may be a shortened code to fit on the actual chip. The core is a member of the Super H RISC family, apparently SH-2. It's a member of the SH-7147 group.

Hardware manual, software manual.

This is a traditional RISC CPU, with a fixed 16-bit instruction length, delay slots, and not even traditional immediate addressing modes. To load an immediate value, you reference a constant relative to the PC. To call a function, you need to load that immediate constant with one instruction, and call with another. The return instruction is RTS. I use the return instruction, a moderately common one, as a sort of sanity test for firmware files. The opcode seems to be 000B. There are 16 general purpose registers.

The CMUs [ edit: was BMU] seem to use a V850F3612 microcontroller. I'll presume that this is a member of the V850 family, even though I can't find a part number that matches this in any way.
V850 family. V850 family architecture.

This is a more friendly (to the reverse engineer) processor. It has a mixture of 16 and 32-bit instructions, no delay slots, and 32 general purpose registers. The return from subroutine instruction seems to be the JMP instruction (!), with a binary opcode of 0000 0000 011r rrrr. I don't know what register is used to pass the return address. Initially I thought it was the link pointer register (r31), but this seems be be more of a base register (like ebp in the x86 architecture). Not knowing the register used, there are about 26 reasonable values, and none that I tried seem to occur frequently enough to indicate that I've found instructions in the .CFF files.

So now the bad news. CFF seems to stand for Common File Format. [ Edit: It may stand for Controller Firmware Files or Caesar Flash Format. There are files like CAESARCOMPDB in the install image. ] Common File Format seems very general. They all start with a bunch of text, including the author's name, various paths to files, but after a few kilobytes of that, it's all binary and no text at all. I tried disassembling a few files that had iMiev and BMU in them with both of the above microcontrollers, and nothing made any sense.

This could be due to many reasons. One, the CFF files might not actually contain the firmware that gets downloaded over the CAN bus into the charger or BMU, as I've been assuming. Two, the business end of the CFF files might be encrypted. There is talk on some forums about requiring passwords to use certain MUT III functions. Maybe the password is needed to decrypt the back end of the .CFF files. To me, the CFF files don't look random enough to be encrypted, but that's just a gut feeling. Three, I'm possibly overlooking something, like endianness issues.

The hope is that these files will allow reverse engineering of how the ECUs work, so that poorly documented trouble codes can be better understood, and perhaps, perhaps, firmware might be able to be patched to modify behavior. In particular, it may be possible to overcome VIN locking and other practices that make life miserable for people trying to maintain their vehicles and not be at the mercy of the manufacturer. Later, it may even be possible to change some performance limits, such as the motor power limit. But that's way in the future.

Edit: I've just realised that I have been confusing BMU and CMU (Battery Management master Unit, and the Cell Monitoring Units). There is probably yet another processor used in the CMUs, different from the other two, and that will likely explain the present lack of success. So the V850F3612 microcontroller is from the CMUs, not from the BMU. @Kiev, or anyone else, do you know the microcontroller used in the BMU?

Edit 2: I believe that I have a charger firmware file now. But it also makes no sense so far.
Last edited by coulomb on Sat Aug 11, 2018 11:55 pm, edited 5 times in total.

Posts: 794
Joined: Sun May 03, 2015 7:15 am
Location: The Heart o' Dixie
Contact: Website

Re: Firmware for charger, BMU, CMUs

Sat Aug 11, 2018 9:40 am

Here is a quick shot of the 2012 BMU board.

There are several empty thru-hole connector slots, possibly for JTAG and eeprom? programming

IC1 is Mitsubishi MH8106F 115A105 U0, 144-pins

IC2 is 20-pin 2338A1 SKA [TRIANGLE MARK] 1917 1917C00MDA

kiev = kenny's innovative electric vehicle

Return to “Batteries and Battery Management”