RhinoPower Ltd

Wow that is an in dept understanding of how the binary is functioning, the dissembler should come in handy if the eeprom can be pulled from the evo chip.

The way the table’s are set out and there functions are remarkably similar to the newer ecus, Mitsubishi did not stray to far from the mould.  

TechSupport wrote:

---

EF89 is the firmware version, that will be burnt in as Masked ROM, possibly a bootloader. Did this chip also have a different firmware version on it? I assume that this is a 76e56?

---

Yes it’s the 76e56.

Where is the firmware version printed?

That die is from an evo 4 or early evo 5 ecu.

The EF89 is interesting can it be used to calculate anything or is it only for reference?

TechSupport wrote:

---

That is cool, I'll have a proper look at that when I get the chance. It confirms what I've said for a long time and that is that these are Toshiba chips, the 1993 date is interesting, it means that they had EEPROM devices for quite a long time.

---

 Yeah it’s cool to get it confirmed, I might be able to get some high res pics if needed.

What do you think the “EF89” represents?

Pictures are not great because I can’t download any thing from the work computers so I took a picture of the screen , but I believe its Confirmed to be ” EF89    M   1993  Toshiba .

Edit the ”M”. Could be a “H”

TechSupport wrote:

---

I haven't tried it again. I have cleared all my outstanding projects but I'm working away at present, I should be back in a week or two but I don't have a project timescale for the rest of that work. I am minded to have another look at this when I get back.

---

 Oh projects tell me about it, im up to my eye ball’s in trying to figure out tunerpro xdfs and checksums ,coming from learning on flashable ecus has spoiled me.....

There is absolutely no panic on this the only reason I ask is that I never new it was possible to read information off the internal bus of a chip like you have done especially a chip that no one has ever been able to crack.

Cheers BOB.

Hi James,I hope you are well.

I was going through my collection of ecus the other day and came across the evo 4 ecu and wondered if you got around to trying your second booster adapter on this ecu as you had got so far with all the ports.

Hi James 

just wondering if you ever got around to having a last try at this?

Thanks

BOB

TechSupport wrote:

---

TechSupport wrote:

---

I couldn't find any reason why my code would not execute so I swapped the emulator for an EPROM, I can now see my code on the bus so I guess the emulator didn't have sufficient drive strength. The new problem is that the code is simply being stepped through without being executed, as if the bus isn't connected. I am in an area of memory that was reading blank, more investigation to do.

Edit: Emulator works if I use a booster socket, must have had that over 10 years - first time I've needed it! Code still doesn't execute.

---

 I'm working on another board at present and I ran into the same issue - it seems that the adapter that I was using for the logic analyser was adding too much capacitance to the bus. Once I've finished this job I will try mode 0 again.

---

That’s both good and bad news.

How do you go about solving that one? 

I don't know anything about the JECs parts, I've never dealt with one. That other chip looks like it says NFC, that may have been a fab house, the D number could be a Denso part number.

I couldn't find any reason why my code would not execute so I swapped the emulator for an EPROM, I can now see my code on the bus so I guess the emulator didn't have sufficient drive strength. The new problem is that the code is simply being stepped through without being executed, as if the bus isn't connected. I am in an area of memory that was reading blank, more investigation to do.
I can see the internal memory contents on the bus when I execute a reset from my external memory so if all else fails that is a vulnerability that I can exploit that to read out the internal memory.

Edit: Emulator works if I use a booster socket, must have had that over 10 years - first time I've needed it! Code still doesn't execute.

Bob wrote:

---

 

Off topic a bit,

I have been having a play with a micra k11 board and have come to the conclusion that the chip may be OTP as well, however there is external headers which i believe nistune do a board for.

How does the odd and even boards work? Is there 2 separate busses, one for odd and the other for even addressing ?

 

---

I'm not familiar with the Nistune boards, from what I understood they just place the processor into an external memory mode. In some applications people have used two chips to get enough memory, they are usually split high memory and low memory by usng the MSBs as the chip selects but it could be done as odd/even by using the LSB as the chip selects. What processor is it? 

I suspect that the problem with Mode 0 is that it runs in extended multiplexed configuration and this board is configured for non-multiplexed extended operation. So I think that I've proved that Mode 0 works but I need a board like my old ROMReader board that I used on the smaller devices.

Edit: I'm beginning to think that Mode 0 is partially disabled - the reset vector is picked up correctly from the external memory but the code doesn't run, it looks like internal code is present on the bus and appears to run correctly. I will investigate some more tomorrow.

TechSupport wrote:

---

Bob wrote:

---

 

---

 Does that mean that pin 79 is not capable of being used to put the chip into boot mode.?

Is there anything I can be testing?

---

 

That depends on how boot mode works, it could be a simple signal that when present causes the code to jump to a bootloader routine. This weekend I'm going to try and put the MH6311 into mode 0 and see if that works, that will be the real test to see if this is a feasible project.

---

Looking forward to the result regardless of the outcome as it will either put this ecu to bed or open up another one to play with. 

TechSupport wrote:

---

Pin 79 is just a 12V digital input.
Pin 62 is bi-directional comms, which you would expect for K-Line, and goes to pin68 and 67 on the processor which is known to be the serial port on the MH6311, so that's good.
Pin 56 I have as a RX line which is also connected to pin 67 on the processor.

The two 165s are cascaded and work as a serial in (from the processor), parallel out shift register to drive a bunch of digital outputs.

---

 Does that mean that pin 79 is not capable of being used to put the chip into boot mode.?

Is there anything I can be testing?

TechSupport wrote:

---

Bob wrote:

---

 

---

 i thought the cam and crank go through the e310a chip to be conditioned first? Or am I think of the h8 ecus?

Did you see them two 74hc165a they are used in Mitsubishis k line communication on 56 and 62 they might be of interest.

i can send commands through the k line to switch on and off various things like injectors /fuel pumps/egr and purge etc, the program is call evoscan 

---

The E310A is a level translator, it converts the signals from 12V to 5V and from 5V to 12V. One of the inputs has two outputs, one of which is inverted, and that input is usually used for cam or crank. I have the pinout mostly defined, I will try and find that, for the 12V inputs you can just put a low frequency square wave on the ECU input and check the pins to see where the 5V output is, fro memory the threshold voltage is around 7V. The other way you need to force the processor into reset and then inject a 5V signal through a resistor and then look for the 12V output.

I had a look at 62, which I think is the K-line, I have 51 as the immobiliser pin, 56 is shown as unused? I would think they are using the shift registers to implement the serial port, there is most likely only one in the processor. Its an old trick that seems to have made a bit of a come back on some modern processors.

Is the Mitsubishi protocol described anywhere? if you know that then that makes reverse engineering the software much easier.

---

A lot of good info here as I’m currently working on the cam and crank on the h8 and am confused at finding the crank signal invert on 2 pins.

As you follow pin 79 take a look at my board for reference and you can see all the components are fitted.

Mut commands.

https://evoecu.logic.net/index.php?title=MUT_Commands&diff=839&oldid=838

Bob wrote:

---

 

---

 i thought the cam and crank go through the e310a chip to be conditioned first? Or am I think of the h8 ecus?

Did you see them two 74hc165a they are used in Mitsubishis k line communication on 56 and 62 they might be of interest.

i can send commands through the k line to switch on and off various things like injectors /fuel pumps/egr and purge etc, the program is call evoscan 

---

The E310A is a level translator, it converts the signals from 12V to 5V and from 5V to 12V. One of the inputs has two outputs, one of which is inverted, and that input is usually used for cam or crank. I have the pinout mostly defined, I will try and find that, for the 12V inputs you can just put a low frequency square wave on the ECU input and check the pins to see where the 5V output is, fro memory the threshold voltage is around 7V. The other way you need to force the processor into reset and then inject a 5V signal through a resistor and then look for the 12V output.

I had a look at 62, which I think is the K-line, I have 51 as the immobiliser pin, 56 is shown as unused? I would think they are using the shift registers to implement the serial port, there is most likely only one in the processor. Its an old trick that seems to have made a bit of a come back on some modern processors.

Is the Mitsubishi protocol described anywhere? if you know that then that makes reverse engineering the software much easier.

I haven't had a lot of time to work on this over the last week. I did take a look at the EVO4 ECU (MH6371), the power pins map to the MH6311, the analogue pins look to be in the right place, the E clock is present and there is activity on the R/W pin so that all looks good. I traced out the circuitry for the crank and cam inputs and the ignition and injector drivers. I'm hoping they will map to the timer pins on the MH6311 but I haven't succeeded in getting the output compare channels to work yet, there must be enable bits somewhere but its not obvious from the code; I've been through setting registers to FFh, which normally works, but so far no success.

Looking at the code how would you know if it was paged or not is there a giveaway or a tell tale?

Also I’d like to ask what is the next step once you have identified as much as possible, like are you looking for something in particular at the moment or going for a complete map?

I did some more hunting through the code - found a timer module, nowhere near the normal registers, my first thought was that it was external but it clearly maps to the interrupt vectors. This is my summary of the registers, looks like one 16-bit timer with at least eight output compares and at least five input captures:

; Timer module - internal or external ?????
; suspect external in 100-pin port expander
;
L080F  ; OC? - add a number and store
L0810  ; init then all in intvec9 OC? - add a number store here
L0811  ; init then all in intvec8 - fetched and stored, also load 113 add 323 store here
L0812  ; init then all in intvec10
L0813  ; init then load, add store here, also intvec6
L0814  ; init then load, add store here, also intvec5
L0815  ; init then intvec4, load 815 add 1FE0, store 815
L0816  ; init then load, add and store , controls PORT3 bits, also intvec3
L081F  ; written twice to 00h
L0820  ; written twice to E0h
L0821  ; 16-bit write twice to 00h
L0823  ; 16-bit write twice to 00h
L0825  ; 16-bit write twice to 00h
L0827  ; 16-bit write twice to 00h
L082D  ; 16-bit timer
L082E  ; read once in init and overwritten
L082F  ; read once in init and overwritten 
L0830  ; read once in init and overwritten
L0831  ; read once in init and overwritten 
L0833  ; 16-bit read in intvec15 and stored L000A bit0 selects interrupt??
L0834  ; 16-bit read in intvec16 and stored, L000A bit1 selects interrupt??
L0835  ; 16-bit read in intvec13 and stored, L000A bit2 selects interrupt??
L0837  ; 16-bit read in intvec12 and stored, L000A bit3 is toggled = edge??
L0839  ; 16-bit read in intvec11 and stored, L000A bit4 is toggled = edge??
L083A  ; read once in init
;

Edit:

L082D confirmed as a free-running 16-bit timer.

I've started to compile a register map available here: http://www.rhinopower.org/76xxx/docs/76C55_Register_Map.txt

That looks like fantastic work.

You must have quite a bit of experience to be able to figure out how to go about setting up a rig like that, Do you do much of that type of work for a day job ?

Also how come you use eprom and not eeprom chips ?

So let me get this right.

If a pin is set to read as an input you can actually access the data on the internal upper and lower buses?

Does this hold true for all ic’s ?

what kind of logic analyser are you using, as I seen then on eBay for as little as 50 quid?

 

TechSupport wrote:

---

Its usually on the sticker on the front, the non-flash OTP devices can still be read, if the flash version supports mode 0 then it will be possible to read it n the same way.
I have a logic analyser on the bus, for input pins the code just reads the ports and copies them to RAM locations, on a read the data is exposed on the bus, then I just inject a signal onto the pin to cause it to change state; for output pins I just toggle the output and then look for the pin.
I will look for the higher order ports next, the code is different to that on the MH6211 so they may not be in the same locations.

---

I found an EVO5 ECU that should have the MH6371 processor and it was cheap so I don't mind if I accidently wreck it. It should be identical to this one: 

https://forum.carlabimmo.com/viewtopic.php?t=14895