Problemwith MCU P062F

Mitsubishi i-MiEV Forum

Help Support Mitsubishi i-MiEV Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

bezzeb

Active member
Joined
Sep 17, 2020
Messages
33
Hello
My car arrived with a non-original inverter (MCU)

It did not start until I reflashed the VIN number in the EEPROM (MCU).

After this, the car started but with an error and after 60 km / h i have a turtle

The problem with the turtle can be solved if I delete the error in MCU (P062F) and EVC (P1A1E)
but after shutdown the problem appeared again

Apparently, in addition to the vin number, something else needs to be corrected in EEPROM

Tell me how to change the EEPROM correctly so that there is no error



Also I have a second MCU with another vin number

I can use it, but now, and the immobilizer does not give it to me
He shows the old vin number and the lexia does not allow me to change it, since it changes only 1 time

Please help me solve this problem
 
Which car make/model do you have miev, czero, Ion ?

How did you reflash the VIN into the MCU eeprom, using an external programming device or with the OEM tool?
 
kiev said:
Which car make/model do you have miev, czero, Ion ?

How did you reflash the VIN into the MCU eeprom, using an external programming device or with the OEM tool?

mitsubishi i-miev 2012

i have external programming device
i change 2 vin number in hex EEPROM

8b9bffab580b.jpg
 
Thank you for posting the contents of the eeprom.

What are the 2 bytes at the end of the line after the VIN--is that a checksum?

What is the part number of your MCU? Is it 9499A620 ?

What about the serial number, does it match the MCU in the car? CF1101004920 and 2 bytes for check sum?
 
kiev said:
Thank you for posting the contents of the eeprom.

What are the 2 bytes at the end of the line after the VIN--is that a checksum?

What is the part number of your MCU? Is it 9499A620 ?

What about the serial number, does it match the MCU in the car? CF1101004920 and 2 bytes for check sum?

sorry but i dont know

9499A620 its a calculator (MCU program) number

i dont know
I have not found this number anywhere
 
If you look at the label on the MCU, there will be a part number and serial number.

9499A620 is a Mitsubishi part number for the MCU, and the C... number is the serial number.

i suspect that those must also match in the eeprom in addition to the VIN; also if these are changed then the checksum will be different also, so if you didn't calculate a new checksum and program it also, then the controller will detect that as an error.
 
kiev said:
If you look at the label on the MCU, there will be a part number and serial number.

9499A620 is a Mitsubishi part number for the MCU, and the C... number is the serial number.

i suspect that those must also match in the eeprom in addition to the VIN; also if these are changed then the checksum will be different also, so if you didn't calculate a new checksum and program it also, then the controller will detect that as an error.

yes, you are completely right.
This number is on the MCU sticker.

How can a checksum be calculated when parameters are changed?
 
What was the Old VIN and the new VIN?

What was the Old and New Part Numbers and Serial Numbers?

Did you happen to capture the hex/ascii screens, or the hex files for both versions of eeprom (before and after making changes)?

Coulomb may be able to help decode if this is some sort of checksum, CRC field, parity, etc.

Unused bytes are Blank (x00)
It appears to be using a 32-byte page with the CS in the last 2 bytes of the page.

Here is data from Stan051 eeprom starting @ address x0800
VIN in ASCII: VF71NZKZZBU901984
Hex representation: 56 46 37 31 4E 5A 4B 5A 5A 42 55 39 30 31 39 38 34
last 2 hex bytes CS?: 8B F0
VIN search returned as 2011 Citroen CZero

Here is Bezzeb data from screenshot same address
VIN in ASCII: VF31NZKZZBU801988
Hex representation: 56 46 33 31 4E 5A 4B 5A 5A 42 55 38 30 31 39 38 38
last 2 hex bytes CS?: 8B F1
VIN search returned as 2011 Peugeot iOn

Bezzeb MCU Part Number and Serial Number data starting @address x0A02
PN and SN ASCII string: 9499A620 CF1101004920
Hex representation: 39 34 39 39 41 36 32 30 20 20 43 46 31 31 30 31 30 30 34 39 32 30
last 2 hex bytes CS?: BE CB

i tried several online checksum and CRC calculators but had no success matching the codes.

Does anyone know the vendor of the eeprom? U6 on my board is etched somewhat but i can read "L64" on the first line, with an unusually large circle at pin 1, followed by "2071".

Microchip makes a 24LC64 that comes erased with all locations filled with 'FF' and a 32-byte page buffer. ONsemi has a similar device, as does Atmel, Catalyst, Fairchild, Philips, Rohm, ST, Xicor.
[edit: i think it is a Rohm device, BR24L64]

Also there are I2C and SPI versions of serial eeproms--which is used here?
[edit: Looking at the board it seems I2C since pins 1-4 are all connected to Gnd, so can't be SPI version]

The reason i bring this up is because the data shows the unused locations with blanks, x00. So did they come that way or were they cleared when programmed?

Also the eeprom used in the CMU boards seems to have a common part number but only the vendor datasheet has the correct information for pins and programming. So there may be subtle differences to be aware.
 
I took off my mcu from the car today
Here are the data that was in my first mcu
47d36de67d8b.jpg

421e87065252.jpg

13c3aca27342.jpg

cd498dfaebf3.jpg


I only changed the vin number here.
Unfortunately the old one I did not write down

Checksum for old vin number is "AB 11"

Chip is 24C64
 
To help understanding, please confirm or correct the following:

1. Your car is a 2012 Mitsubishi iMiev with VIN# JMBLDHA3WCU00610 ?

2. When you got the car it came with an MCU from a 2011 Peugeot iOn (VIN ..801988) with MCU serial# CF1101004920 ?

3. In the 24C64 eeprom, the VIN and Serial Number are contained in two 32-byte address locations?
VIN is at x0800 and x1000
Serial Number is at x0A02 and x1nnn ?

4. There is no other data on the eeprom from beginning address x0000 to the end at x1FFF ?

5. You have reprogrammed the eeprom in the Peugeot MCU to have the correct VIN of your car and the correct serial number of the MCU in all the address locations?
 
kiev said:
To help understanding, please confirm or correct the following:

1. Your car is a 2012 Mitsubishi iMiev with VIN# JMBLDHA3WCU00610 ?

2. When you got the car it came with an MCU from a 2011 Peugeot iOn (VIN ..801988) with MCU serial# CF1101004920 ?

3. In the 24C64 eeprom, the VIN and Serial Number are contained in two 32-byte address locations?
VIN is at x0800 and x1000
Serial Number is at x0A02 and x1nnn ?

4. There is no other data on the eeprom from beginning address x0000 to the end at x1FFF ?

5. You have reprogrammed the eeprom in the Peugeot MCU to have the correct VIN of your car and the correct serial number of the MCU in all the address locations?

1)Yes
2012 Mitsubishi iMiev with VIN# JMBLDHA3WCU00610

2) i got with mcu serial number CO1101022909 but with another VIN number
But now i have 2 mcu
CO1101022909 (installed in the car) and CF1101004920(bought, for repair, if it does not work out with the first mcu )

3)yes,2 vin number and 2 serial number
Yes ,800-810 and 1000-1010 VIN
Serial number 0A00-0A10 and 1A00-1A10

4)

5)I changed only the VIN number in the eeprom
The serial number of the mcu remains old
It matches the sticker on the lid

The only thing that I have not changed and that may give an error is the crc sum at the end of the number VIN


113f94423c3a.jpg


f9a413814383.jpg


74f8b400e072.jpg


03d067e0daac.jpg


712dfaa67288.jpg


b649e10ac9fe.jpg


9cf4c558838f.jpg


973dfbc7a7aa.jpg


f90dc246ca54.jpg
 
Thank you for the answers and for posting the full eeprom contents.

It appears to be other data stored which we do not know the purpose, or if it is corrupted or correct.

But we need to figure out how to calculate the correct check sum for your VIN.
 
kiev said:
Thank you for the answers and for posting the full eeprom contents.

It appears to be other data stored which we do not know the purpose, or if it is corrupted or correct.

But we need to figure out how to calculate the correct check sum for your VIN.

I took as a basis the second MCU with unchanged eeprom
and tried many crc calculators
none were able to calculate the checksum correctly
 
So comparing the eeprom data between the two MCU--in all the other addresses with the random/unknown values other than the VIN and SERIAL Number, Are they identical?
 
kiev said:
So comparing the eeprom data between the two MCU--in all the other addresses with the random/unknown values other than the VIN and SERIAL Number, Are they identical?
there are differences in multiple lines

but there is an opportunity to somehow reprogram the immobilizer in order to install a second MCU ?
 
There are members who have discussed programming the VIN in the P1A15 threads started by Lic and Gencis who may be able to give you some advice.

Did you remove the eeprom when reading and programming, or try to do it while still on the board? What voltage did you use for Vcc and for the serial lines?

i would be concerned that the Vcc to the board powered up or tried to power up the U1 microcontroller chip, marked 64F7047F40V, and may have corrupted or introduced errors in the eeprom.

A quick check showed continuity to the same power source for numerous pins on the top side (pins 27,46,77,84,85,89) and thru vias to several pins on the bottom side.

There is discussion about an error in reading the eeprom on the CMU boards in the BMU CMU thread.

i know less about the immobilizer and its functions than even the little bit known of the MCU so cannot recommend that approach.
 
kiev said:
There are members who have discussed programming the VIN in the P1A15 threads started by Lic and Gencis who may be able to give you some advice.

Did you remove the eeprom when reading and programming, or try to do it while still on the board? What voltage did you use for Vcc and for the serial lines?

i would be concerned that the Vcc to the board powered up or tried to power up the U1 microcontroller chip, marked 64F7047F40V, and may have corrupted or introduced errors in the eeprom.

A quick check showed continuity to the same power source for numerous pins on the top side (pins 27,46,77,84,85,89) and thru vias to several pins on the bottom side.

There is discussion about an error in reading the eeprom on the CMU boards in the BMU CMU thread.

i know less about the immobilizer and its functions than even the little bit known of the MCU so cannot recommend that approach.


Before programming, the microcircuit was removed from the board
I am more inclined to believe that the problem is in the checksum
 
That's good to hear.

i couldn't find anything about a CRC for the SH-2 32-bit RISC microcontroller used in the MCU in either the hardware or software manuals, which seems very strange. i did find this discussed in connection with the RL78 16-bit series devices and it includes using forward and reverse schemes for reading bytes (LSB vs MSB) which obviously would affect the result. Here is link to English language version, others may be available:
https://www.renesas.com/us/en/document/apn/rl78-family-rl78-hardware-crc-functions?language=en

It could be that the "user" of the VIN data is in a device that uses the RL78 processor and is looking for this checksum; The MCU processor doesn't need this value to do it's task and doesn't care?
 
Hi,

I'm also interested in this topic. I found this program --> https://reveng.sourceforge.io/
I tried to use the VIN/CRC combination posted in this thread to find the algorithm, but I didn't get any results. I think it needs at least 4 samples.
Maybe if you could find more samples then it would be possible to figure out the algorithm.
 
Did you try the RL78 method?

i think there are several examples of both the VIN and the Part Number sequence with the check sum in this thread on the first page.
 
Back
Top