RhinoPower Ltd

I have confirmed that CF = BRCLR INDX, I put that into the 56B code which is duplicated, and now commented, below:

; decrement counters

D6F4 CE0122    LDX #$0122              ;start address of counters
D6F7 C618       LDAB #$18                ; no. of counters
D6F9 8D6E       BSR LD769
D6FB 8A01       ORAA #$01                ; flag that this is done
;
; - code removed
;
D769 CF00FF02 BRCLR X, #$FF, LD76F ; bra if all bits are clear
D76D 6A00       DEC IND,X                   ; decrement counter
D76F 08            INX                            ; go to next counter
D770 5A            DECB                         ; decrement no of counters
D771 26F6        BNE LD769                  ; loop if not done
D773 39            LD773: RTS 

blocks of counters are: 

X: 122 B: 18
     13A     14
     14E     03
     151     04

X: D9        01                       ; D9 is Time From Start

So that block of code decrements a bunch of registers that are used as counters, D9 is known because that is read by the diagnostic interface. I will have a look in the E931 code to see if it is similar.

Edit: It is the same in the E931 code, it has the function name decTable.

Hello Jane

Can you point me to the disassembly that you found those op-codes in? it might help to see what else is going on.

I'm going to have a look at the unknown op-codes, what instructions do we need to look into? I had a laptop failure recently and a lot of the information is somewhat dispersed around various folders, drives and machines. At the moment I am missing the op-code map that I created.

I have a CF, 00? instructions in the 56B code which may be followed by some instructions using the X index register. I have a very old note that states
                            "CF - BRCLR INDX 6 BRA IF CLEAR INDEX REGISTER X *how is this six?"

I also have a CD, FE with a note that says:

                           "CD FE             4???? UNKNOWN? *Could be LDY,Y* "

Bob wrote:

---

Have to say I’m impressed with your work , what’s the Goal of your project Have you a project car that you want to add features too?

Thank you. I have a 92 Eclipse, I'm interested in pulling a masked ROM off of an MH6111, and making a couple of small changes too. That got me started on them, but at this point I'm mostly just interested in how these microprocessors work and building up the knowledge base on them. Project goal: figure stuff out, share knowledge.

Bob wrote:

---

Hi Jane,

Is that your dissembly on GitHub that Techsupport posted a link to ?

---

 Yes, I wrote that disassembler. I have a branch for the MH6311 that I am currently trying to run different binaries through to find undocumented instructions. Most recently I've been looking at the 95 Eclipse EPROM ECU MD312464 ROM which is MH6311 (PLCC) based, and a handful of new instructions showed up in it right away. It would be great hardware to learn about interfacing with the EPROM, if it weren't so pricy and hard to find. I do however have a 95 Eclipse EPROM TCU MD760927 which has the MH6311F (TQFP) on hand to learn from. For what I am doing right now, ECU or TCU doesn't make much of a difference, besides the actual ROM layout. I'm just looking for instructions, and lucky having a dissasembler makes building symbol files for unknown layouts fast and easy. 

Jane wrote:

---

I found a binary for an MH6311 (1996 Hyundai Accent ECU https://tech.mirage-performance.com/ECU/MB14B.html) just to put through the disassembler for fun. For one thing, the binary is 64k so it takes up the whole address space, with padding at the beginning like MH6111 images (~20480bytes of 0xFF). However unlike MH6111 ROM images which start at 0xD000 it starts at 0x0000. Second thing, it has a big vector table, 42 long. I'm used to MH6111 vector tables that are only 16 long. Otherwise, everything seems to decode no problem, doesn't seem to have any extra op codes (in this image at least.)

---

 Hi Jane,

Is that your dissembly on GitHub that Techsupport posted a link to ?

Jane wrote:

---

I found a binary for an MH6311 (1996 Hyundai Accent ECU https://tech.mirage-performance.com/ECU/MB14B.html) just to put through the disassembler for fun.

---

FYI, Based on the size of the connector and the resistors on the side that's a TCU not an ECU.

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.