Help Getting Started With Ghidra For MPC562 ME9.6.1 VE E77 LY7

[Gatecrasher]

You picked one messed up ECU to cut your teeth on

I think I'm finally making sense of this thing. I still can't quite square it up with the datasheet, but the code at least makes some logical sense now.

The ME 9.6.1 function reference had this to say about the memory layout.

E69 and E77 controllers have 3 data areas and only one internal flash. The internal flash however is splitted in two adress areas. This requires the definition of 5 areas in tc9con.h for SY_CVNSIZE=4. The first two areas specify the two code areas of the internal flash. The following three areas define the range of the three data areas.

We know what the 3 data areas are. That's the calibration segments for engine operation, system and speedometer. The two flash areas are likely boot and operating system.

Then I went and looked at the memory map from the A2L file. I'm pretty sure it's for an E55, but it gave me an idea of how the memory could be split up. It also gave me some ideas about the calibration region and why that doesn't match up.

Combine that with some comments other people have made, and some function pointer tables I found, and this seems to work.

E77_mem_map.jpg

Boot is just empty space since we don't have that. There are cross references into that area though.

Operating system uses data from the bin file. Load the bin file into Ghidra, set the base address to 0x20000, offset to 0x0 and length to 0x1A2000.

Open the file, skip the auto analyze for now, and set the registers as described before.

Now go to File > Add to Program, and select the bin file again. Set the block name to calibration, the base address to 0x5C2000, and the length to 0x3C000. This puts R13 nicely near the beginning of the calibration space.

Create the RAM addresses as shown in the screenshot. I think the ExtRAM might be an EEPROM.

The diagnostic mode table at 0x29194 should give a nice place to start looking at some standardized code. You don't need any weird offsets for the address pointers. They just work as-is. Here's a sample.

Code: Select all

                             Diag_Mode_tbl1_00029194                         XREF[1]:     00029298(*)  
        00029194 3e ff ff ff     undefined4 3EFFFFFFh
        00029198 ff ff ff ff     undefined4 FFFFFFFFh
        0002919c 00 0f 1f c8     addr       Diag_Mode3E_000f1fc8
        000291a0 00 00 00 00     undefined4 00000000h
        000291a4 00 00 00 00     undefined4 00000000h
        000291a8 1a 81 ff ff     undefined4 1A81FFFFh
        000291ac ff ff ff ff     undefined4 FFFFFFFFh
        000291b0 00 08 48 e0     addr       Diag_Mode1A_ECUID_000848e0
        000291b4 00 00 00 00     undefined4 00000000h
        000291b8 00 00 00 00     undefined4 00000000h
        000291bc 1a 8e ff ff     undefined4 1A8EFFFFh
        000291c0 ff ff ff ff     undefined4 FFFFFFFFh
        000291c4 00 08 48 e0     addr       Diag_Mode1A_ECUID_000848e0
        000291c8 00 00 00 00     undefined4 00000000h
        000291cc 00 00 00 00     undefined4 00000000h
        000291d0 1a ff ff ff     undefined4 1AFFFFFFh
        000291d4 ff ff ff ff     undefined4 FFFFFFFFh
        000291d8 00 0f 07 38     addr       Diag_Mode1A_general_000f0738
        000291dc 00 00 00 00     undefined4 00000000h
        000291e0 00 00 00 00     undefined4 00000000h

The diagnostic PID table starts at 0xA4960. That should yield a ton of useful info.

[Lucasperks06]

I’ll send some photos of a e77 92193636 ecu I got for free, I believe it’s from a 2007 omega LE0 VE
That’s how I confirmed it was a mpc562, and I doubt in a later e77 they would change it to anything else
Also this me9.6.1 function reference your talking about, would you be able to send that as I don’t have anything me9.6.1 related, same with function sheets, I’ve heard of a me9.6.1 function sheet but never been able to get my hands on one, I only have a Saab me9.6, which still gets the job done.
And I’ll reply to the rest of your message in a sec I thought I’d just show you those cause it may be helpful

IMG_8584.jpeg

IMG_8585.jpeg

IMG_8586.jpeg

[Lucasperks06]

okay so first off, thanks kur4o for those files, and if you could find a more complete e77 bin for that SW number that would be awesome, and if what your saying is true im guessing thats why the first 20000 of the bin is just ff, and why it skipped the first 20000 in my hpt converted bin.
could any e77 boot be useful, as other e77 reads seem to convert the first 20000 just fine. idk why this SW number only does it

and gatecrasher thanks for all the effort your putting in man i really appreciate it, and of course this ecu has to be a pain in the ass.
so i set the file up as you have, now im guessing your using the original bin i posted, i set my file up with the new bin that hjtrbo sent, and as antus said, its just nothing for that first 20000. which im guessing is just from an incomplete bin. so "technically" should the first 20000 of the new file be mapped as the boot?
and then OS should have a 20000 offset with that new bin and begin at 20000?

also another question, im unsure if im doing this wrong, but with the cal mapping, i saw that you said to import the bin, and set base address to 5c2000, which all makes sense, but what dosent make sense is arent we just starting the OS mapping but at 5c2000? shouldnt we set the offset of the bin to start at the cal region?
which thats where the 1c2000 offset that the other guy was talking about makes sense. im assuming this is how we should do it but if im wrong please let me know.

doing it like that i now get the same data showing up as my winols file, so all looks good, just no references yet, which weve already figured out there is most likely other problems, or as kur4o was saying, they just wont show up at all

[Lucasperks06]

this is also how i set my ghidra file up, using the new bin file, i believe its right but let me know if it looks wrong, im sure well be making changes regardless as we figure more out
also i set a 20000 offset and a 20000 base address on the OS memory map

Screenshot 2026-06-16 220813.png

[hjtrbo]

you will get xrefs into the cal switches / scalars / tables if you've set your offsets up right. About 6,545 distinct parameters.

[Lucasperks06]

Yeah so I’m guessing some adjustments still need to be made with the base addresses/offsets. I’ve been talking with a guy who does e55 me9.6 disassembly, and he said he set his base address at 40000, I’m not 100% but I’m assuming that’ll be mpc562 aswell.
And not sure if that 40000 is after the boot or before. But thought I’d mention it
But everything is going alright so far, hopefully the xrefs are there for the maps and not how kur4o said they were as that sounds like a pain in the ass

[Gatecrasher]

also another question, im unsure if im doing this wrong, but with the cal mapping, i saw that you said to import the bin, and set base address to 5c2000, which all makes sense, but what dosent make sense is arent we just starting the OS mapping but at 5c2000? shouldnt we set the offset of the bin to start at the cal region?

I'm using your original bin file. We're importing it twice and carving it up. First we take only the operating system data from the file, from 0 to 1A2000, and put it in the Ghidra project at 20000.

Then we import it again but this time we're only bringing in the calibration block. We take data from the file starting at 1A2000 until the end of the file, which ends up being a length of 3E000. We place that at 5C2000 in the Ghidra project.

I've been over the MPC datasheet a dozen times now and I can't figure out HOW it's doing this. I don't know if it really matters at this point. But it's bothering me.

Yeah so I’m guessing some adjustments still need to be made with the base addresses/offsets. I’ve been talking with a guy who does e55 me9.6 disassembly, and he said he set his base address at 40000, I’m not 100% but I’m assuming that’ll be mpc562 aswell.

Do not make the mistake of thinking you can just mix and match pieces from other ECUs. E55, E69 and E77 are very different hardware and software. They can have the same processor and still be configured in very different ways. You can use what you learn from one to guide you on the others, but you can't assume what works on one is exactly the same on the others. It's not. All this craziness with different memory maps and file offsets isn't making it any easier.

I'm sorry I've been talking about the function sheet like everyone knew what it was. I didn't realize it came from an expired Google drive link. I'll see if I can get it uploaded somewhere else.

[kur4o]

Code: Select all

  /begin MOD_PAR "400PXX000"
    VERSION "ME96"
    ADDR_EPK 0x4137B8
    EPK "48/1/ME96C/30/21.0//_400PXX000/400PXX000/050208/"
    ECU "ME96C"
    CPU_TYPE "GoldenOak"
    /begin MEMORY_SEGMENT PstC0000 "" CODE EPROM EXTERN 0xC0000 0x100000 -1 -1 -1 -1 -1 
    /begin IF_DATA ASAP1B_CCP ADDRESS_MAPPING /*orig_adr:*/0xC0000 /*mapping_adr:*/0xC0000 /*length:*/0x100000 /end IF_DATA
    /begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0xC0000 /*mapping_adr:*/0xC0000 /*length:*/0x100000 /end IF_DATA
    /begin IF_DATA ASAP1B_KWP2000 ADDRESS_MAPPING /*orig_adr:*/0xC0000 /*mapping_adr:*/0xC0000 /*length:*/0x100000 /end IF_DATA
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT Pst400000 "" CODE EPROM INTERN 0x400000 0x80000 -1 -1 -1 -1 -1 
    /begin IF_DATA ASAP1B_CCP ADDRESS_MAPPING /*orig_adr:*/0x400000 /*mapping_adr:*/0x400000 /*length:*/0x80000 /end IF_DATA
    /begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x400000 /*mapping_adr:*/0x400000 /*length:*/0x80000 /end IF_DATA
    /begin IF_DATA ASAP1B_KWP2000 ADDRESS_MAPPING /*orig_adr:*/0x400000 /*mapping_adr:*/0x400000 /*length:*/0x80000 /end IF_DATA
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT Dst1C2000 "" DATA EPROM EXTERN 0x1C2000 0x1E000 -1 -1 -1 -1 -1 
    /begin IF_DATA ASAP1B_CCP ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x5C2000 /*length:*/0x1E000 /end IF_DATA
    /begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x902000 /*length:*/0x1E000 /end IF_DATA
    /begin IF_DATA ASAP1B_KWP2000 ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x5C2000 /*length:*/0x1E000 /end IF_DATA
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT ExtRam900000 "" VARIABLES RAM EXTERN 0x900000 0x2000 -1 -1 -1 -1 -1 
        /* AsapMLXFm - CCP_V2_1 */
    /begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x900000 /*mapping_adr:*/0x900000 /*length:*/0x2000 /end IF_DATA
        /* AsapMLXFm - KWP2000 */ 
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT Ram7F8000 "" VARIABLES RAM INTERN 0x7F8000 0x8000 -1 -1 -1 -1 -1 
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT Ram800000 "" VARIABLES RAM INTERN 0x800000 0x8000 -1 -1 -1 -1 -1 
    /end MEMORY_SEGMENT

Some more info on memory layout

/begin IF_DATA ASAP1B_CCP ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x5C2000 /*
/begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x902000 /*
/begin IF_DATA ASAP1B_KWP2000 ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x5C2000 /*l

As you can see calibration is mapped at 3 different locations based.

I think e77 is little sister of e69 that is more widely used. Might be some crippled too, and basic concepts should apply to both.
And some files attached and a IDA diss for reference.

[Gatecrasher]

As you can see calibration is mapped at 3 different locations based.

0x1C2000 is the location in the flash chip or raw bin file. It's the same if you're using CAN calibration protocol or normal diagnostics.
0x5C2000 is where it's mapped within the running CPU's memory space. Also the same, regardless of debugging protocol.
0x902000 is only used if you have an ETAS ETK hooked up. That's a daughter card for the ECU that enables real time tuning and debugging during the early development process. The calibration segment gets remapped into the ETKs RAM.

E69 and E77 are both ME 9.6.1. The big difference is E69 uses direct injection.

That A2L is from an E55 so we can only draw some generalities from it.

BTW, I think the whole weird memory mapping thing is done by the 'dual mapping' function on the MPC56x.

[Tazzi]

0x1C2000 is the location in the flash chip or raw bin file. It's the same if you're using CAN calibration protocol or normal diagnostics.
0x5C2000 is where it's mapped within the running CPU's memory space. Also the same, regardless of debugging protocol.
0x902000 is only used if you have an ETAS ETK hooked up. That's a daughter card for the ECU that enables real time tuning and debugging during the early development process. The calibration segment gets remapped into the ETKs RAM.

E69 and E77 are both ME 9.6.1. The big difference is E69 uses direct injection.

That A2L is from an E55 so we can only draw some generalities from it.

BTW, I think the whole weird memory mapping thing is done by the 'dual mapping' function on the MPC56x.

This looks good to me.

I genuinely hate it when memory gets moved around outside of the standard expected locations, but it does happen in several different ECUs/modules, very common for anything Bosch.