With very, very little information on the data exchange or really anything related to the 'port expander', I figured it is worth capturing the data on the SCC bus, the same bus the EEPROM is on as in the links you sent suggest that is the way both MCU's communicate with an internal /CS4 to select the second IC.

Attached are the waveforms. Unfortunately the only data is to and from the EEPROM, checking the status register, enabling writing then reading out the contents of the EEPROM, then silence.

Either both MCU's don't communicate with the ECU out of the car (unlikely), there is a secondary SCC bus internally, or there is no port expander in this MCU. Looking at the interrupt vector of the primary MCU, it doesn't appear to be executing any code when your typical interrupts are triggers, CCx's etc so I don't think it's doing any of the core ECU functions like handling injector and spark events.

I think the next step is to put the logic analyser onto the MCU's port pins and try toggling them from software to see if they are attached to the primary MCU's ports. If they don't as suspected then i'll need to start looking into the ME744's firmware to see how data is being passed.

I have looked at the board, and there is a smaller second ASIC labeled '30380'. This is said to contain the Knock IC and additional ADC channels. This is somewhat confirmed by Bosch's application pdf that says pretty much that. I suppose a quick IO test on one of the ports will confirm if there is a second MCU or not in the same die.

I've been looking through the firmware and I have found this small function:

seg009:00001B26 sub_81B26:
seg009:00001B26                 bset    P4_7
seg009:00001B28                 bset    DP4_7
seg009:00001B2A                 nop
seg009:00001B2C                 bset    P3_8
seg009:00001B2E                 bclr    DP3_8
seg009:00001B30                 extr    #1
seg009:00001B32                 bset    ODP3_8
seg009:00001B34                 bset    P3_9
seg009:00001B36                 bset    DP3_9
seg009:00001B38                 extr    #1
seg009:00001B3A                 bclr    ODP3_9
seg009:00001B3C                 bset    P3_13
seg009:00001B3E                 bset    DP3_13
seg009:00001B40                 extr    #1
seg009:00001B42                 bclr    ODP3_13
seg009:00001B44                 rets
seg009:00001B44 ; End of function sub_81B26
seg009:00001B44

Which is setting up port direction and state, and right after this function we are setting up SSCCON, and the following function:

seg009:00001C6C SSC_func4_PEC_dualcore?_:               ; CODE XREF: sub_81C64↑j
seg009:00001C6C                 mov     r4, #200h
seg009:00001C70                 or      r4, r12
seg009:00001C72                 mov     PECC4, r4
seg009:00001C76                 mov     r4, r13
seg009:00001C78                 mov     r5, r4
seg009:00001C7A                 shr     r5, #14
seg009:00001C7C                 shl     r5, #1
seg009:00001C7E                 mov     r5, [r5+0FE00h]
seg009:00001C82                 bmov    r4.14, r5.0
seg009:00001C86                 bmov    r4.15, r5.1
seg009:00001C8A                 shr     r5, #2
seg009:00001C8C                 mov     r14, r4
seg009:00001C8E                 mov     word_FCF2, r14
seg009:00001C92                 mov     r4, #0F0B2h
seg009:00001C96                 mov     word_FCF0, r4
seg009:00001C9A                 mov     r4, #400h
seg009:00001C9E                 or      r4, r12
seg009:00001CA0                 mov     PECC0, r4
seg009:00001CA4                 mov     r4, #0F0B0h
seg009:00001CA8                 mov     word_FCE2, r4
seg009:00001CAC                 mov     word_FCE0, r14
seg009:00001CB0                 and     SSCCON, #0F0FFh
seg009:00001CB4                 bclr    SSCEIR
seg009:00001CB6                 mov     SSCRIC, #7Ch ; '|'
seg009:00001CBA                 mov     SSCTIC, #0F8h
seg009:00001CBE                 mov     r4, #1
seg009:00001CC0                 rets
seg009:00001CC0 ; End of function sub_81C64

Which suggests the communication channel is similar as the dual core link you referenced earlier, PECC0 and PECC4 being used for SSC transfer direct to XRAM. I'll double check which port the EEPROM /CS is tied to be sure this isn't just an eeprom data handler function and is related to the Port Expander. I think we're getting somewhere.

I traced back the 4 injector outputs through the injector driver, then back into the C167 (PWM channels 0-3, P7.0 - P7.3). A few lines of code to set these pins as outputs and toggle them and we're seeing nice clean outputs on PWM0 and PWM1 channels.

There are test pads on the PCB for these channels, and other important signals. I'll find where they go and write some code to test them all. I don't think there's a secondary C167 or port expander in this ECU. At least not for the Injector driver anyway. I'll test spark outputs next, and VR/Analog inputs and if they're all accessible then I can get back on track and get some speed density code running.

The 30380 looks to have a parallel bus (8bit), /RD, /WR and a /CS line so that should be easy to spot in IDA. It looks to use /CS4 to select but not the standard external memory data lines that the SRAM and Flash share, so it probably isn't memory mapped.

Yes it is out of the case, and what do you mean trace things that aren't there? The port expander? d3irb suggested I look into how it works sending me down that dead end. There is no port expander in this ECU. I assumed from what was said, and info in the link provided that ME7's are all 'dual-core' so I assumed there may be two MCU's in one package.

From what I can see, it's a C167 MCU with 32k mask rom, external 512k flash + 32k sram, the CC650, a LDO power management IC, Injector driver, Discrete coil driver (with phase sensing), H-bridge driver, and a smaller unknown 16pin IC (sc551710mdw) which has its own 4mhz xtal and connects to the CC650. There's a few LM op-amps on the underside for analog stuff, and what I guess is a pair of VR IC's for crank/speed inputs. A very nice, well designed development board for engine management.

The C167's ADC channels are all routed too so I'm not sure how much of the CC650 is being used for ADC.

Do you have any information on the CC650? pinout, register mappings, datasheets?

Right now I'm working on my monitor program to help map out all the I/O to the respective external inputs and outputs, the fault detection signals from the driver IC's and enable signals and anything else that is required to control an engine with my own code. At a bare minimum, if I can read battery voltage, map, tps, iat, clt, detect the teeth from the VR circuit, and control injectors, IAC and coils, I can write some speed density code as a proof of concept

Sorry for leading you astray on ME7.4 - I didn't realize it didn't have the second C167, what an odd duck!

Yes, there's no hidden core or anything. It sounds like you're back to your original plan, and carry on... (and also, good luck figuring out the CC650, although I think you're on the right track with it I suppose).

I'm excited to see what you come up with.

Some notes on the 30380 IC:

*=Not connected to CPU, possibly ADC or Knock inputs (26 total, assumed 16ch ADC, 4pins Knock input, 6 unaccounted for)

30380-
Pins:
1=CPU /CS2 ~ P6.3
2=*
3=*
4=*
5=*
6=*
7=gnd
8=gnd
9=gnd
10=gnd
11=*
12=*
13=*
14=*
15=*
16=*
17=*
18=gnd
19=gnd
20=gnd
21=* (routed to test pad)
22=*
23=gnd
24=*      //end of row

25=*
26=GND
27=GND
28=GND
29=5V
30=GND
31=GND
32=GND
33=GND
34=GND
35=GND
36=GND
37=GND
38=GND
39=P5.15
40=*      //end of row

41=Connected to 43
42=*
43=Connected to 41
44=GND
45=5v
46=*
47=P8.0
48=NMI
49=RSTOUT (from CPU)
50=SC551710WDM Pin11
51=SC551710WDM Pin2
52=*
53=*
54=*
55=SC551710WDM Pin1
56=GND
57=5v
58=GND
59=/CS2 ~P6.3
60=SRAM /CS
61=*
62=GND
63=*
64=*      //end of row


65=*
66=GND
67=AD7
68=AD6
69=AD5
70=AD4
71=AD3
72=AD2
73=AD1
74=AD0
75=ALE
76=/RD
77=/WR
78=XTAL2 (clk)
79=5v
80=GND      /end of row

SRAM /CS is routed through the 30380 IC, perhaps the 30380 is memory mapped above the SRAM.

Reverse engineering the security module...

There is a small 16pin MCU attached to the ASIC but also generating an IO enable signal for the Hbridge and coil drivers. It is this IC that issues a reset request to the ASIC, which then issues a System Reset signal resetting the ECU. It does this 100ms after a response to its challenge isn't received. If an invalid response is received, it will instantly issue a reset. This was a fun one to crack!

It works like this:

The CPU and the security IC (I'll call a watchdog) is connected by a single data line (Port 2.5). It is connected as open collector with a weak pull up so both watchdog and CPU can pull the line low.

It is the low pulse duration that contains the challenge and response. The high pulse width is simply 20mS minus pulsewidth, maintaining a 50hz data rate.

The protocol works like this:

CPU-Init1, WDT_Query1, CPU-Init2, WDT_Query2, CPU-Response1, WDT_Query3, CPU-Response2, WDT_Query4, CPU_Response3 etc....

It continues indefinitely. The Queries are 1 of 16 unique pulse widths. The responses are paired to the query. Every 16th response must be invalid as an extra bit of comfort that the CPU is still executing code correctly. A correct response on the 16th query will = an incorrect response. Internally to the WDT there is a counter of correct responses. It maxes out at 8. If you issue the wrong response, it will decrement the counter and ask the same query. So you get up to 8 wrong replies before a full system reset, or reply correctly to the 16th query 8 times and a reset.

There is a fairly large window of what is accepted as a pulsewidth. 0.2mS or so variation is OK it seems.

CPU-Init1 pulse width = 4.81484mS
CPU-Init2 pulse width = 5.68516mS

The responses to the 16 challenges are as follows:

         //calculate the appropriate response to the WDT's query
         //8.44534mS > 7.7576
         // 8.86936 >> 5.99528
         // 4.22638 >> 8.15802
         // 4.74308 >> 6.65572
         // 6.9078 >> 4.29354
         // 9.30801 >> 4.55406 
         // 6.56086 >> 4.81456
         // 8.03452 >> 5.68488
         // 6.2243 >> 7.0065
         // 5.01306 >> 5.38508
         // 5.5979 >> 8.56748
         // 4.48566 >> 5.0945
         // 7.26654 >> 6.31584
         // 5.29926 >> 8.99806
         // 5.902 >> 9.4388
         // 7.6425 >> 7.37702
         ResponseCounter++;
         if (ResponseCounter==16){ //we need to send a bad response every 16th to keep it happy
            ResponseCounter=0;
            WDTResponse=7.208mS;
         }

I'm using CC5 and T2 and this code is all running in interrupt driven functions so there is no main code intervention needed. Interrupt priority can be low.

We're now no longer stuck in a reset loop, and we can enable IO drivers.

Next up the ASIC.

Unfortunately that's normally what happens. Guys will start a topic  and start reversing and throw some leads out to try and bring others on board and then it all goes closed source. That or they give up due to the daunting take being too much to accomplish. I mean for what it's worth I don't understand why guys don't do more with the 1.8t ecus, I have a Subaru setup on me7 that makes 470 to the wheels and a d series civic that's like 230-240 to the wheels. Also the price for standalone ecus these days it doesn't really make sense trying to use a stock ECU from another engine unless you can get it all for free or really cheap and have a really good idea of what's involved.