coulomb
Posts: 114
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.

kiev
Posts: 815
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

Image
kiev = kenny's innovative electric vehicle

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

Re: Firmware for charger, BMU, CMUs

Fri Dec 07, 2018 8:52 am

I need to upload again; please pardon the stream of consciousness.

I was browsing the 2018 MUT-III DVD I found in a torrent. The main executable seems to be MUT3_SE.exe (MultiUseTester three Second Edition). Someone pointed me to the second edition for iMievs; thanks. It and its dozen or so DLLs (Dynamic Link Libraries) are .NET assemblies. That means they decompile nicely; I use the free and very useful JetBrains dotPeek. MutVciUpdate.dll contains the class FirmwareUpdate, which has functions like Download(). It calls functions like this.m_FirmWareControl.EraseSector() and this.m_FirmWareControl.Update(). Along the way, there are functions:
* this.m_FirmWareControl.GetDataOffset()
* this.m_FirmWareControl.GetDataByteLen(), and
* this.m_FirmWareControl.GetDataRecord()
which pull important numbers from the .RPG file.

I've been looking at the .CFF files so far, but someone mentioned that the .RPG files are also important. So this looks good.

In the RPG file, the first two bytes (little endian) are the number of "fields" of various kinds. Each field record is a fixed length (usually 6), which is in the next 2 bytes. Then follows an array of three 16-bit words, with "id code", "offset", and "size". The important id codes are:
* 01 20 for DataOffset (big endian, 2 bytes)
* 02 30 for DataByteLen (big endian, 4 bytes)
* 03 30 for DataRecord (big endian, 4 bytes) (number of records, which seem to be the number of flash segments).
These three starred fields are read by the three starred functions mentioned above.

For the .RPG files I looked at, DataOffset was always 0x203, the DataByteLen was always 0x400 (=1024), and the DataRecord was around 0xEE (238) to 0xF0 (240). So these files contained about 240 KiB (Kibibytes, 1024 bytes) of actual data.

At the DataOffset is a 0x3A (ascii colon), followed by what appears to be an big endian 8-byte address. This is followed by the DataByteLen bytes of actual flashable data, and this triplet (colon, address, data) repeats DataRecord times. In the RPG files I examined, the addresses of flashable data ranged from 0x200000 to often 0x23BC00 (ending at one less than 0x23C000).

The first two bytes of data have so far always been 0x55 0xAA, which looks like a "tag" indicating program presence. Soon after, in ascii, comes the name of the file (e.g. "00E08114" for file VE08114.RPG, and what appears to be a version number, like "2.02", followed by a several bytes of 0x20 (ascii spaces). Next is a string like "20081215", which suggests the date 2008/Dec/15. Even more spaces follow, then many FFs.

After a block of FFs (several flash sectors), there follows what looks like a set of addresses or vectors, the some random-looking bytes that could well be code. In this last random looking section, there are 0B 00 sequences often enough to suggest the end of subroutines. (As mentioned in my first post, the RTS instruction of the SH-2 family, as used in the charrger, has an opcode value of 000B, which might be represented in little endian form as 0B 00.

I'll write a small program to extract the binary data next, and attempt to disassemble it. Unfortunately, I can't see the word "miev" in any RPG files, and the years seem wrong, but I think I'm making progress.

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

Re: Firmware for charger, BMU, CMUs

Sat Dec 08, 2018 3:17 am

coulomb wrote: I'll write a small program to extract the binary data next, and attempt to disassemble it.

Source code for a very simple console mode C program is here. Compile with GCC for Cygwin or similar.

So I've gotten an RPG image to disassemble, and it's not what I had hoped for. This seems to be the firmware for the VCI, the dongle that sits between the PC and the vehicle:

Image

It happens to use a similar processor to the BMU, though there seem to be a few differences. But there seems to be a way of getting firmware to to (e.g.) the ECU, since there are text strings like "ECU same as VCI ". I assume that means that whatever firmware image is downloaded to the VCI, it's the same version as the ECU has now, so there is no point flashing it again. Hopefully I'll get to where those images come from.

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

Re: Firmware for charger, BMU, CMUs

Sat Dec 08, 2018 4:04 pm

Is there anyone who owns a MUT-III VCI (Lite or not), who is prepared to open up their unit? It would really help me to know the exact processor that they use. In other words, please tell me all the numbers and letters printed on the big chip on the CPU board. Renesas make of the order of a hundred CPUs, and Google doesn't seem to search their PDF files, or if they do, I can't find the right keywords to get what I want. I tried guessing a model and downloading the manual for that, and it wasn't even close. I realise now I've been very lucky that the processor in the VCI is so similar to the one in the BMU, but there are differences that mean that hundreds of memory references are completely opaque to me. With a manual for the right processor, all these would instead become valuable clues about what the bits of code are doing.

Thanks in advance.

Ooh - I just realised, from the few photos that I can find on the web, that the main CPU may not be visible without taking out a board on top of the CPU board. That seems like a big risk, so don't do it if you're not confident with electronics. I certainly don't want to put people out of pocket by hundreds of dollars, for some undefined possible future benefit.

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

i909 pcb and info

Sat Dec 08, 2018 8:51 pm

i don't have a VCI, but a "clone" from iCarsoft, the i909. It only seems to be able to read data list items, DTCs, and clear some DTCs. It has no capability to upload firmware updates that i know of.

It uses SHENZHEN LAUNCH TECH chips, a DPU 431 [U1] and a JV 700 [U3], mentioned in USPTO Patent Application 20170046884, Personal vehicle diagnosis system and method based on mobile intelligent terminal. Both are proprietary chips with little to no information available on the websticle. These chips are made by JVD Inc, which was founded by Jerry VanDierendonck and takes pride in keeping custom chip secrets.

"Jerry graduated from University of Cincinnati in 1966 with his undergraduate degree in Electrical Engineering. After graduation, he continued to work for his co-op company Avco Electronics before moving to Texas Instruments where he began work with the now famous team, Boone, Cochran, & VanDierendonck, the team that developed the world’s first microcontroller. He also became one of a few individuals worldwide that could create programmable chips for calculators at Texas Instruments. Jerry received 9 patents for his work at TI. Later Jerry was lured to Silicon Valley where he worked at Litronix, Fairchild Semiconductor, Monosil, and LSI Logic before founding JVD Inc in 1982 where he served as the company’s president until his retirement in 2010."

If i get my hands on a VCI it will be opened immediately.

Image
kiev = kenny's innovative electric vehicle

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

Re: Firmware for charger, BMU, CMUs

Sun Dec 09, 2018 5:19 am

It looks like it has some of the characteristics of the SH7705 group. I get more than half of the I/O on-chip registers from that manual.

Return to “Batteries and Battery Management”