coulomb
Posts: 135
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, CMUs, 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 CMUs 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 V850ES family, even though I can find few manuals for it.
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.

The BMU uses MH8106F, 144 pins (see post below). Unfortunately, little seems to be known about this processor, though various vendors seem to offer ECU updates. They may be part of the M32r series, per this page.

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.
Edit 3: Added small paragraph about BMU processor.
Last edited by coulomb on Sun Dec 23, 2018 7:26 pm, edited 10 times in total.

kiev
Posts: 842
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: 135
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. [ Edit: it turned out to be no use, at least for the RPG files available so far, for iMiev related firmware; see this post. ]

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.
Possibly important:
* 02 20 for Pass (password?). Typically 5 bytes; seen values of 85 0 0 0 0, 92 0 0 0 0, and 10 0 0 0 0 (all hex).

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.
Last edited by coulomb on Tue Dec 25, 2018 5:58 am, edited 2 times in total.

coulomb
Posts: 135
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 CMU, 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.

Edit: it looks like all the VE*.RPG files are firmware for various models and revisions of the VCI.
Edit: BMU -> CMU again. Sigh.
Last edited by coulomb on Tue Dec 18, 2018 4:01 am, edited 3 times in total.

coulomb
Posts: 135
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: 842
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: 135
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 [Edit: i.e. The VCI processor] has some of the characteristics of the SH7705 group. I get more than half of the I/O on-chip registers from that manual.

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

Re: Firmware for charger, BMU, CMUs

Wed Dec 19, 2018 6:55 pm

coulomb wrote: 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...
Edit: it looks like all the VE*.RPG files are firmware for various models and revisions of the VCI.

It's finally dawned on me: these aren't the main firmware for the VCI module; these are special ReProGram images, hence the .RPG file extension. They are special images with just one purpose: to reprogram an ECU image. There are various sizes of .rpg files; these carry larger or smaller images as "payloads".

This explains why one of the first things it does is display the message "Reprogramming ECU", and at the end of main, it says "Press Enter to restart VCI", and branches to 0xA000 0000. Presumably, 0xA000 0000 is the address of the boot loader, and the RPG image gets overwritten by its usual image, which does all the other things *except* for ECU programming.

It seems that not all MUT3 images (I have them for years 2012, 2016, 2017, and 2018) have iMiev specific files. In fact, the 2018 distribution doesn't seem to have RPG or CFF files at all. So I'm concentrating on the 2012 distribution for now.

I still can't find any clues to the CFF file format; it's certainly nothing like the RPG file format. By ignoring the first part of one CFF file, I can get it to make sense, [ edit: was "except for a series of pairs of 32-bit instructions that make no sense". I had the wrong processor variant; these are dispose and prepare instructions. ]

The RPG file payloads may not be so encoded, but I haven't had time to analyse any as yet. In the 2012 distribution, there is a folder with 89 RPG files, and it has a subfolder called CFF with 89 .cff files. So I thought that with one exception, surely the CFF images would match with the payloads of the RPG images. And perhaps (this seems like wishful thinking now that I type this), the RPG payloads might not be mangled as the CFF files appear to be.

But I can't seem to match them up. The four iMiev related .cff files all start with 9499; this seems to be a model code for the iMiev, and the string "miev" appears in all four of them (in paths to files in the header at the start of the .cff files). There are various version numbers embedded in the .rpg files, but so far I can't line them up.

I actually have five .cff files (one sent to me privately, the other four from the 2012 distribution). Three of these seem to be for the BMU, one for CMUs, and one (the largest) for the VCU. Nothing for the charger. However, as part of the image upload process, blocks of code ending in many FFs and with binary-round sizes (like 0xA60, or 0x1000) are sent. It's possible that one of these images is for the charger, and others for other small ECUs about the place. 0x1000 (4 KiB) is still pretty small for a charger; for comarison, the Elcon/TC chargers have 8 KiB.

It feels like I'm close, but that could be the Dunning-Kruger effect :-)

The BMU image is for a Mitsubishi MH8106F, which I can't find any data on. Maybe I'm just poor at searching, but It seems to me that this is supposed to be some big IP secret, at least in comparison to other architectures where the manufacturer wants you to be familiar with the features of their product. But I'm amused by the number of companies that seem to be offering "tuned" versions of engine ECUs. You have to use these with special tuning tools, and the drop-down list of these is about 20 different units. So some people out there know about these things, but since there seems to be a cottage industry in reprogramming these things, they don't release the information. Frustrating.

[ Edit: Deleted "Some RPG files seem to carry two payloads." I had some indices calculated wrongly. ]
[ Edit: Removed paragraph about pair of instructions that made no sense. ]

datom
Posts: 9
Joined: Wed Apr 11, 2018 8:01 am

Re: Firmware for charger, BMU, CMUs

Fri Dec 21, 2018 6:00 am

Hi coulomb,

I found an older discussion about the cff file format here: https://www.evoxforums.com/forums/showthread.php?s=38fc007e2715f4242994a3bb60b6a73d&t=180681. It seems that cff files are encrypted.
There's a lot of interesting stuff to be found there. I didn't know for example about the Pass-Thru CAN Software
that can be used instead of MUT III for certain tasks (does it work for iMievs?).


Best,
datom

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

Re: Firmware for charger, BMU, CMUs

Fri Dec 21, 2018 5:50 pm

datom wrote: I found an older discussion about the cff file format here: https://www.evoxforums.com/forums/showthread.php?s=38fc007e2715f4242994a3bb60b6a73d&t=180681.

Yes, I'd come across that discussion in my travels. I think at the time I was a bit dismissive, since it seemed to be very specific to a particular model of car, and didn't seem to publish the CFF "decryption" script (only the results of one application of it). Perhaps I should comb through it for more detail.

It seems that cff files are encrypted.

Actually, I'm getting some frustratingly near-reasonable results just chopping off the first part of the .CFF file, the mostly-text part, that ends in a null. So maybe some are encrypted, and some aren't. Or maybe it's encrypted in such a way as to appear reasonable, yet it's not, just to waste the time of people like me :x

There's a lot of interesting stuff to be found there. I didn't know for example about the Pass-Thru CAN Software
that can be used instead of MUT III for certain tasks

That surprises me. The .rpg images are really quite complex. It seems unlikely that whatever the VCI is doing during ECU reprogramming can be readily "bypassed".

(does it work for iMievs?)

An excellent question. Maybe I'll eventually be able to answer that.

[ Edit: truncating -> chopping off ]

Return to “Batteries and Battery Management”