NefMoto

I need a couple of aftermarket ECU's for some project cars and engine swaps. I've been using older Delco ECU's in the past with modified firmware but I'm looking for something a little more capable.

Why the ME7.4.4?
They are the cheapest OEM ECU available ($50 shipped, new) with no apparent limit in availability (alibaba/aliexpress/ebay/amazon).
New ECU connectors and looms are available just as readily ($50 shipped, 3plugs with labeled wiring/pigtails included).

End goal?
Real time tunable ECU with loom for under $100. GUI front end for tuning/logging.
VAG-KKL or similar interface for PC connection
Speed Density preferred but MAF isn't a deal-breaker.

The bare minimum:
Remove all IMMO code and any CANbus dependencies usually required to keep the ECU happy.
Remove any security/seed/key code to make flashing easy.
Identify all maps, RAM variables and tables.
Real time tunable - Depending on RAM availability, copy a target map to RAM to allow changes in real time. If we're short on RAM, we can always add FRAM to the motherboard and map it into the address space (as done in the older Delco ECU's for real time tuning)

Qualifications:
My day job is working with 8bit and 32bit assembly on various CPU families and reverse engineering hardware and firmware. I have no experience with the C167 but glancing over the instruction set, it's nothing too out of the ordinary. Some experience with Windows GUI/CPP programming. I've got a chassis dyno in the shed and have a bit of experience with tuning.

Where I'm at:
I've ordered a K-tag, VAG-KKL, 2 new ME744's (chinese manufactured), and one used ME744(German manufactured). I'm waiting on a quote for the ECU connectors with a 2meter loom so I can bench test full I/O, injectors, spark, etc. K-tag and ecu's should arrive in around 2 weeks.

I've found multiple flash dumps online but as these are all missing the CPU's boot-rom, there's not a lot of work I can do in IDA until I get hold of the ECU. Unless someone here has a Ktag and ME744 they could dump the bootrom/flash/eeprom out of?

The hard parts:
Identifying functions - There's some great tools in this forum to help with this, hopefully 360trev's ME7RomTool will help here.
Identifying RAM Variables - reversing the diagnostics protocol the ECU usually uses will help find the basics. Finding RAM references from the various functions will fill in the gaps.
Reverse engineering the CC650 Knock IC ASIC. To make good use of the hardware we really need a full understanding of how to tune the center freq and bandwidth.
Map out all available IO - I've read in some threads here that the narrowband input is wideband compatible (0-5v). The SpeedDensity thread is interesting too.

So that's the plan! I'll keep you updated with any progress. If anyone has a dump of the bootrom, or info on functions, memory maps, variable addresses, CC650, the bosch comms protocol or anything else that could make this project easier please send it over!

Why not ME7.5.10 wich has lot of A2l floating around  and can be write by OBD with a bunch os tools ?

I'd strongly recommend you start with a slightly newer ECU for this, because you can get an A2L (all RAM and calibration variables) a leaked ELF with DWARF (all function symbols), or in some cases all source code. Also newer ECUs generally offer much higher flexibility in terms of knock calibration so you don't need to reverse the sensor acquisition and could probably just calibrate the knock model.

CAN with CCP/XCP, your own patched UDS handlers, or custom-handler based logging like prj's infamous tool will be significantly faster and better for logging and live tuning than KWP serial, even with DDLI hacks (ME7Logger/APR) or McMess.

On the flip side with a newer ECU comes more complexity in number of maps and overall control model, but I'd rather have more complex models to short circuit than be stuck tediously reversing map addresses any day of the week. Just an idea, if you are serious about trying to make your own software.

If you aren't serious about trying to make your own software, you could also just find a hardware/software version of ME7 that is already properly defined and you're set, no RE work needed, just edit the calibration. I think Marty, nameless_, and many others have used ME7 as standalone in the past on all kinds of cars using just calibration changes.

You will lose too much time.
Time=money
That only worth if you have too many cars to install those ECUs
Be ready to spent a year for get it working right. ME7 is torque based ECU, and that gives a lot of mindblowing problems when you want to make standalone ECU

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.

Where can I find it? Which ME7.1 is compatible with MS4?

http://nefariousmotorsports.com/forum/index.php?topic=15215.0title= (http://nefariousmotorsports.com/forum/index.php?topic=15215.0title=)

Here is some info.

Not sure if it is possible to get the files anywhere. And you will need INCA probably.

I found the software and found the topic about MS4 on this forum
http://www.nefariousmotorsports.com/forum/index.php?topic=15215.0title=
But how can I flash ME7.1 ECU with MS4 software? Just flash in boot mode?

Thanks for the input guys, you've given me a fair bit to consider.

I was leaning towards the 7.4.4 mainly due to price and availability (~$35 brand new, with $50 brand new looms available too). Newer ECU's have a better selection of decompilers/debugging/compilers but over here (Australia) they're not all that common or cheap. I'll look into the 7.5.10, if it's more suitable then I'll probably go with that instead. There's a dozen secondhand units overseas for about the same price as a 7.4.4 plus shipping. Thanks for the suggestion!

I've found an A2L file for this ecu and it's largely all mapped out in terms of maps and ram variables. That should make tuning and replacing functions a little easier.

Time=Money, I completely agree but at the same time this is a hobby and we (mostly) never get back what we pour into a hobby so I'm not too worried about this taking longer than expected.

A complete recode vs just tuning the maps... I've been reading up about the torque based strategy these use and it's looking like there will be a lot of back and forward through different maps during tuning. Not ideal, especially with the limited RAM and the requirement of real time tuning. I'm leaning towards a full re-write of the code, just simple speed density.

I've read conflicting specs about the internal ram. The datasheets suggest 2k SRAM, 2k XRAM. Some forums suggest 64kbytes or even as much as 128kbytes of SRAM hidden away in there. I guess I won't know until I get an ECU here and code up a read/write test throughout the full memory map to see what is inside.

The Delco I'm using now is pretty basic, speed density, a dozen maps. It shouldn't take too long to port that code over once the basic IO's are all reversed. The Delco is slow, has limited resolution on injection and timing control, no knock support and is batch fire with a single spark output (dizzy). Even just getting this Delco code running on a newer CPU (with hardware division), 60-2 trigger wheel support, sequential injection, coil on plug etc I'll be happy. Add in a nice GUI front end for real time tuning and it'll be a pretty handy cheap aftermarket setup.

The Keil C166 IDE has a few nice examples for C167 CPU's including a simple monitor to read/write IO and read ADC values. That should make RE of the port IO a lot faster though I suspect a few analog signals are going through the Knock IC. Once I have the port address of the IC it shouldn't be too hard to reverse the Init code for the knock variables and the ADC channels.

The first ME7.4.4 ECU arrived (From Lithuania), connected up the Ktag, dumped the MCU boot rom, Flash and EEPROM. The Flash file says Checksum error in Ktag and is only 286kbytes instead of the 512kbytes. I'm not sure if its the Ktag clone or the ECU or something else. How does Ktag know the location of the external flash?

Anyway onto the Bootrom. It is 32kbytes in size and decompiles fine in Ida. The issue is I cannot modify the BootROM, flashing a blank file passes in Ktag but the contents are unchanged. I suspect it could be MaskROM in the C167 which really throws a spanner in the works... It could just be Ktag unable to rewrite the bootrom even though it says it can.

The BootROM does eventually jump to the external Flash and this may be ok if we can relocate the interrupt vector into the External Flash or SRAM areas. I recall reading the vector table can be relocated.

I'll connect up a FTDI and try get minimon running on the C167 and have a poke around in there.

My Chinese ME7.4.4 arrives tomorrow. I'm curious to see if there are any differences in the PCB, MCU and boot roms.

Yes, the so-called "MCU" aka Mask ROM aka onboard OTP is, indeed, not reprogrammable. You can definitely hack around this if you're building your own thing from scratch.

But, you just discovering this raises some questions in my mind... you are also aware of the port expander and how it works? It seems like you haven't dug all the way into ME7 before deciding to use it. I'm questioning your approach more the more I read, honestly - porting another OEM firmware across seems both overly ambitious and probably not efficient time wise, for a lot of reasons.

I've been interested in the idea of building a full standalone ECU software for cheap OEM ECUs for years, but there's a lot more to it than meets the eye, and it's so hard to actually follow through with this kind of idea when the shiny working OEM software is sitting right there. I'd really love to see an open source ECU firmware (RusEFI type thing) running on OEM hardware, but unfortunately the OEM hardware is always quite complicated and uses some undocumented hardware or another that becomes a very thorny RE effort to understand. I think the RusEFI folks were looking at some point at some unbelievably cursed Russian OEM ECUs which use Chinese knockoff STM32s (Artery, Nations, etc...) to repurpose, but that's the most work I've really seen in that direction.

The port expander, as in the ASIC comprised of the knock IC and extra ADC channels? I don't think I'd consider that a port expander unless there's something else i've missed? Otherwise the design is fairly simple, MCU, Flash, RAM, Injector drivers, Coil Drivers, H-bridge drivers, a couple of op-amps for analog signal buffering/filtering/scaling.

You are right in that I am not familiar with the ME7 but that isn't really important if I'm just using it as a 'dev board' and coding my own firmware.

The K-tag was faulty, the K-line should be 12v logic but it was not being pulled up which is why it was very flakey trying to connect and maintain a connection. A 10k pullup to 12v on the K-line did the trick. It's more or less useless though as whatever I try flash must include the ME7 checksums which I don't want or need so I'll need to make my own software to upload to the flash.

I need to read up more on the Buscon and address mapping registers in the C167 otherwise I think I'm on the right path.

I've coded up a small console app to send stage1 and stage2 bootloaders and I'm finally running my own code on the ECU. Next up is mapping in the SRAM and Flash and then onto reverse engineering the IO and ADC channels. My connectors and loom are arriving tomorrow and i'll set up lamps and potentiometers to help decode the IO.

also, how do I attach images/files to my messages?

It's actually another C167. This is why I was asking. Since you didn't look, here you go.

https://nefariousmotorsports.com/forum/index.php?action=printpage;topic=20322.0

Thanks for the link! That is really interesting!!!

So the generic port's of the main C167 can't be read or written to directly? There's no point me tracing the IO from MCU to injector driver for example?

I can't find any reference to a second CPU / Expander / co-processor in any of the infineon datahseets. Is it a custom addition for Bosch?

On ME7.5/ME7.1 etc there are 2x C167 on the board.

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 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.

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 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.

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.

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.

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

There's no two core C167 - does not exist, wrong assumption.
No.

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.

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.

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.

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)?

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.