Pages: 1 [2]
Author Topic: Reverse Engineering ME7.4.4 as a stand alone ECU  (Read 2172 times)
WillItBoost
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 14


« Reply #15 on: March 18, 2024, 03:06:37 PM »

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.
Logged
prj
Hero Member
*****

Karma: +903/-420
Online Online

Posts: 5787


« Reply #16 on: March 18, 2024, 04:58:27 PM »

I mean, have you looked at the board?
ME7.4.4 does not have two C167 IC's, just one.

If there's a port expander (which chould be what is next to the main chip on the board), then it's unlike anything found in ME7.1 and ME7.5.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
WillItBoost
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 14


« Reply #17 on: March 18, 2024, 05:15:18 PM »

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.




Logged
WillItBoost
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 14


« Reply #18 on: March 18, 2024, 05:51:17 PM »

I followed the traces from the eeprom to MCU:

eeprom CS - P4.7
eeprom clk - P3.13
eeprom Din - P3.9
eeprom Dout - P3.8

So that function appears to be EEPROM access, not necessarily the Port expander...

I might need to work backwards from the A2L file, find the ram location for coolant temp for example, work back to the function that populates that ram location and find where it sources its data from.

Logged
WillItBoost
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 14


« Reply #19 on: March 18, 2024, 06:34:12 PM »

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.

Logged
prj
Hero Member
*****

Karma: +903/-420
Online Online

Posts: 5787


« Reply #20 on: March 18, 2024, 07:28:57 PM »

Have you not removed the board from the case?
Why trace things that aren't there?

30380 is CC650. It's a knock IC + 16 channel ADC.
There's no other larger chips on the board = no port expander.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
WillItBoost
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 14


« Reply #21 on: March 18, 2024, 08:12:05 PM »

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
Logged
prj
Hero Member
*****

Karma: +903/-420
Online Online

Posts: 5787


« Reply #22 on: March 19, 2024, 02:55:58 AM »

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.
There's no two core C167 - does not exist, wrong assumption.
Quote
Do you have any information on the CC650? pinout, register mappings, datasheets?
No.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
d3irb
Full Member
***

Karma: +131/-1
Offline Offline

Posts: 185


« Reply #23 on: March 19, 2024, 12:00:30 PM »

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.
Logged
WillItBoost
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 14


« Reply #24 on: March 19, 2024, 01:27:16 PM »

No problem at all, It was worth looking into and made me take a closer look at the C167 peripherals and get a bit more familiar with how segments work in Ida so definitely not a waste of time.

I've written some code to read and write to the various ports and my aliexpress 'automotive sensor simulator' should be here today which can produce a bunch of 0-5v outputs, complementary outputs (as found in the throttle sender and the throttle body), variable resistance outputs (IAT, CLT), programmable VR trigger wheel simulator etc.

I need to look into what exactly SRST (software reset) does. The datasheet(s) aren't particularly helpful here and the maskrom does this after initializing the memory mapping. I'm assuming it'll soft reset the CPU without resetting most of the system registers. I also need to find the 'main' entry point into the flash.
Logged
WillItBoost
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 14


« Reply #25 on: March 19, 2024, 07:25:57 PM »

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.
Logged
sda2
Full Member
***

Karma: +19/-0
Offline Offline

Posts: 68


« Reply #26 on: March 21, 2024, 02:45:44 AM »

Or just flash ME7.1 with the Bosch MS4 stuff.
It talks CCP, the A2L came with the software if you can dig it out.

After that it is possible to use CCP for both live tuning and data logging.

I was able to find MS3 hex file, but that was missing in MS4 software CD you can find on Bosch Server. Could you please provide the binary for MS4 Sport (Turbo)?
Logged
WillItBoost
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 14


« Reply #27 on: Yesterday at 04:10:49 PM »

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.
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.024 seconds with 18 queries. (Pretty URLs adds 0s, 0q)