Firmware for charger, BMU, CMUs

I was going to say the same about Kolyandex - but it may be that sufficient payment would persuade him to publish what he knows

From his point of view it shouldn't be a high risk. Those who want to hack on the things will improve the code and he can still sell his software to load those improvements

It may be hard to convince him of mutual benefit though

Piev sent me a link to the hardware manual for the SH-2 family of chip that is thought to be used in Mitsubishi gasoline cars, formerly an NEC device.
SH7052 hardware manual

[edit] 208 pins...so probably not our MH device

When comparing with the CMU processor's manuals, I noticed that all the links to the manuals are now dead. It may be possible to still chase them down, but just in case I saved the two main CMU processor manuals to my Google Drive, and added links to this post to them (about 2/3 of the way down the post).

The CMU is definitely a very different beast. Formerly a Hitachi chip I think; the others are formerly NEC chips. The CMU processor has 32 registers, variable instruction length (2, 4, or 6 bytes), and no delay slots. This other processor has 16 registers, fixed 2 byte instruction length, delay slots, and is very RISC.

Then there is the MH8106F from the BMU; I have found nothing about it except one cheesy chip selection brochure and the M32r family.

coulomb said:

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.

Click to expand...

I don't know the answer to most of you questions but I will tell you that I have been working with him and he can read the BMU firmware and reflash it using the Tactrix 2.0 and his VCI_bridge software. He read mine a few weeks ago and said he had to reverse engineer it and then he would flash the new Capacity over the internet like he did the read..... So that leads me to believe there is no extra pin you need. I can tell if he is using just CAN or if he uses the k-line as well.

piev said:

I have been working with him and he can read the BMU firmware and reflash it using the Tactrix 2.0 and his VCI_bridge software.

Click to expand...

Wow, interesting.

He read mine a few weeks ago and said he had to reverse engineer it and then he would flash the new Capacity over the internet like he did the read...

Click to expand...

I don't suppose that you end up with a copy of the firmware after it's done?

If you don't mind my asking, why do you need a new capacity set? Upgraded battery perhaps?

Edit: Oops, I see that Kiev has discussed this in the Battery topic. Well done!

coulomb said:

I don't suppose that you end up with a copy of the firmware after it's done?

Click to expand...

No, he deletes everything before disconnecting. He uses the same program called VCI_bridge as I have on my computer but on my version these options are grayed out.

piev said:

No, he deletes everything before disconnecting.

Click to expand...

Not a big surprise.

He uses the same program called VCI_bridge as I have on my computer but on my version these options are grayed out.

Click to expand...

If I wasn't so bad at reverse engineering Windows code, I'd have a go at VCI_bridge. Maybe one day.

I have made a few more observations using the MUT3.

Commands to CMU7 use 0x67E and it responds on 0x67F.
0x76E 02 21 01
0x76F 10 18 61 01 19 A0 19 9F
0x76F 21 0D 01 03 34 03 34 03
0x76F 22 33 03 34 03 34 03 34
0x76F 23 03 34 03 34 00 00 00
0x76E 02 21 02
0x76F 10 0A 61 02 00 00 80 00
0x76F 21 00 10 01 C0 03 34 03

(BX *256 + Bx+1) / 200 or (3 * 256 + 52) / 200 = 4.1

Cells were all 4.1 Volts and this was a data request.

This is ECU information for the CMU
0x76E 02 1A 87
0x76F 10 16 5A 87 04 64 00 01
0x76F 21 FF 00 06 00 03 01 39
0x76F 22 34 39 39 41 37 39 34
0x76F 23 20 20 00 00 00 00 00
0x76E 02 1A 9C
0x76F 10 15 5A 9C 01 04 64 00
0x76F 21 01 FF 00 03 01 39 34
0x76F 22 39 39 41 37 39 34 30
0x76F 23 41 20 00 00 00 00 00

origin 04
supplier 64
ID 00
HW Ver 01
SW ver 0006
HW PN 000301
Module # 9499A7940A
SW PN01 9499A7940A

MCU Motor Control Unit or Inverter

Data List
0x755 02 21 03
0x756 10 0F 61 03 03 E8 03 E8
0x756 21 64 64 42 43 42 42 42
0x756 22 4B 43 42 31 31 35 20

Haven't sorted this out yet
Motor current 1 & 2 0 Amps
Motor current diff 1 & 2 0 Amps
IGBT Temp 1 & 2 26 C 27 C 66- 40 and 67 - 40
Coil temp (u) 26 C 66 - 40
Coli temp Est (v) 26 C 66 - 40
Coil temp (w) 26 C 66 - 40
CPU temp 35 C 75 - 40
IGBT temp (est) 27 C 67 - 40
Motor Torque 0 Nm
Motor Speed 0 r/min
Condensor voltage 4v
Initial Phase pos 840
CPU operation time 8244 hours
MCU run mode Initialize
Ready condition EV No

Self test No DTC's Found
0x755 04 18 00 FF
0x756 03 7F 18 78 00 00 00 00
0x756 02 58 00 79 00 00 00 00

ECU Info
0x755 02 1A 9C
0x756 10 15 5A 9C 01 04 9B 00
0x756 21 02 FF 00 00 04 39 34
0x756 22 39 39 42 34 31 35 20
0x756 23 20 20 00 00 00 00 00

Origin 04
Supplier 9B
ID 00
Diag ver 02
HW PN 0000
HW PN 000004
Module # 1
SW PN01 9499B415

OBC always gives me... comm discontinuation

0x765 02 1A 87
0x765 02 1A 9C
0x766 03 7F 1A 11 FF FF FF FF

Seems like the 02 1A 87 and 02 1A 9C commands are common between all ECU's
Asking for their Identification, version numbers and other info.

Apparently, the charger doesn't have this capability.

piev said:

OBC always gives me... comm discontinuation

Click to expand...

Maybe you need to be charging for the OBC to wake up? That's how it is for the MG.

What would be really great for me is if you can monitor the CAN bus while the MUT requests the internal diagnostic code of the on-board charger. It's not clear to me how this is obtained from the MUT-3, as "data list" for the OBC or perhaps EV-ECU, or as freeze frame data from a diagnostic code like P1A12. But of course you likely don't have such a DTC lying around ready to be interrogated. Or perhaps it's obtained some other way. There is also "extended data" for DTCs; it's not clear to me how these differ from freeze frame data. I suppose freeze frame data is measurements at the time of the DTC, whereas extended data might be more the causes rather than actual measurements.

coulomb said:

What would be really great for me is if you can monitor the CAN bus while the MUT requests the internal diagnostic code of the on-board charger. It's not clear to me how this is obtained from the MUT-3, as "data list" for the OBC or perhaps EV-ECU, or as freeze frame data from a diagnostic code like P1A12.

Click to expand...

So, when I click on OBC is gives me an comm error. Apparently it doesn’t respond on CAN. At least not in my version of the MUT. The button don’t work on that screen. I’ve been told that kolyandex has another version of his VCI bridge with more functionality maybe I’ll try to buy that.

i don't know if this is the right place but it can be moved if need be.

The early Nissan Laef OBC, which uses the same power board circuits and waffle plate as the miev, has 2 CAN buss transceiver chips [NXP TJA1050] on the control board; the miev OBC control board only has 1 .

Under the miev rear seat near the EV-ECU there are some CAN Buss junction connectors; i haven't traced them out but from memory it seems that one goes up to the front [ETACS and Instrument Panel] and one goes back to the rear [MCU and OBC], and maybe another goes to the pack [BMU, CMU].

The EV-ECU has several CAN Buss pairs. i'm guessing that the Diagnostic Port is on a CAN buss that goes directly to the EV-ECU, but not to some of the other devices; The MUT would send a command to the EV-ECU and it would have to translate/forward the request to the MCU, OBC, BMU, CMU, etc. If everything was on the same Buss, then why would the EV-ECU need to have so many transceivers?

kiev said:

i don't know if this is the right place but it can be moved if need be.

Click to expand...

Yes, these CAN related posts seem to be scattered over several topics.

The early Nissan Laef OBC, which uses the same power board circuits and waffle plate as the miev, has 2 CAN buss transceiver chips [NXP TJA1050] on the control board; the miev OBC control board only has 1 .

Click to expand...

Interesting. Do we know where the extra chip leads to in the Laef?

Under the miev rear seat near the EV-ECU there are some CAN Buss junction connectors; i haven't traced them out but from memory it seems that one goes up to the front [ETACS and Instrument Panel] and one goes back to the rear [MCU and OBC], and maybe another goes to the pack [BMU, CMU].

Click to expand...

They (the junction connectors) are present in the schematics.

The EV-ECU has several CAN Buss pairs. I'm guessing that the Diagnostic Port is on a CAN buss that goes directly to the EV-ECU, but not to some of the other devices; The MUT would send a command to the EV-ECU and it would have to translate/forward the request to the MCU, OBC, BMU, CMU, etc.

Click to expand...

That's how I thought it worked too. However, when you look at the schematic here:

http://mmc-manuals.ru/manuals/i-miev/online/Service_Manual/2012/90/html/M190102110327000ENG.HTM

it seems that the same CAN bus goes to all the ECUs and the diagnostic connector (OBD-II port pins 14 and 6).

If everything was on the same Buss, then why would the EV-ECU need to have so many transceivers?

Click to expand...

Great question. It's hard to follow such things when parts of the EV-ECU appear on many schematic diagrams.

Edit: I thought for a while that there was a page missing in the CAN bus schematic linked above; it seems to go from page 1 to page 3. And I thought that perhaps the missing page 2 would show the different ports of the EV-ECU. But I see a 2 in a square (a bit like [2]) in the right corner of the first schematic that has 1 in a square in the top left corner. So I think that these numbers are area references, not page numbers. So that sems to say that all the CAN buses are commoned, i.e. there is only one CAN bus on the iMiEV.

Here is a comprehensive manual and there are no OBC error codes listed. They all come from the EV ECU.

https://online.anyflip.com/cqfwu/chfh/mobile/?fbclid=IwAR15zq9r631sHlOzyRjeH8rV3EOLE8qu9RwC2BXuFjFqgcNvmB6l9x_LGec#p=53

There is a list of OBC troubles that the MUT can find and report as 2-digit decimal number codes, not as Regulated DTC P-codes; the EV-ECU translates these and reports them as P-codes as shown in the flipbook.
The decimal number codes are shown in the FSM here:
http://mmc-manuals.ru/manuals/i-miev/online/Service_Manual/2012/54/html/M154950060003800ENG.HTM

[Note: Code number 30 should read On-Board Charrger Circuit Abnormal]

The MCU also has Freeze Frame data and a separate Data Items List in the FSM, in addition to the P-codes for faults.

piev said:

Here is a comprehensive manual...

Click to expand...

Wow! Thanks.

kiev said:

There is a list of OBC troubles that the MUT can find and report as 2-digit decimal number codes, not as Regulated DTC P-codes; the EV-ECU translates these and reports them as P-codes as shown in the flipbook.

Click to expand...

What sort of codes would these translate to? I don't see any that look like good candidates.

#01 could cause the EV-ECU to throw P1B08
#02 could " " " " " "

i started going thru the list to find a 1-to-1 relation of decimal codes to DTC P-codes, then remembered that there is a Mits Service Bulletin, MSB-18EXML54-002, with updated information on troubleshooting the OBC and DCDC for Model Years 11-14, and seems to match up P-codes to the symptoms of the decimal codes.

http://mmc-manuals.ru/msb/BASE/003/2018/MSB-18EXML54-002/E/MSB-18EXML54-002.pdf