pcmhacking.net

This post is about a deeper dive into the E38 Slave/ETC Motor Control Processor. Started out playing with the ETC limp mode challenges doing LS conversions 15+ years ago. Could not get that deep as apart from HPT with E40 (R&W), only GM could write the ETC (& HPT post 2009). ULink-NT is a tool that has helped make things clearer given it can write the ETC via CAN & R/W via BDM.

One thing for sure was that the Slave OS needs to be compatible with main OS, & the Slave Cal needs to be compatible with Slave OS & main cal/s & sometimes the TCM. Incompatibility could lead to limp mode throttle events, features like 08+ C6 Vette A6 rev matching on manual downshift not working.

Most will be familiar with these background details, but for those that aren’t:

GM Gen III LS’s originally had cable operated throttle bodies. Late in the Gen III lifecycle (MY2004?) a stand-alone TAC module was added into the picture to electronically control the throttle via an electronic pedal & UART serial communication/control/monitoring with the LS1 PCM.

For MY2005 the E40 ECM (24x crank – 1Mb flash) was introduced which moved the TAC module “inside” the engine controller with its own separate CPU – the MCP – motor control processor, a Motorola MC68F375 along with its own flash memory & RAM. A “slave” to the main MC68377 processor. While it is called the Slave, it supervises & provides limits to throttle control. The E40 supported the Gen 4 engines like 05 LS2’s, but the crank & cam were still 24x/1x.

MY2006 saw the introduction of the Gen 4 LS range via E38 (&E67?) (for 58x cranks/4x cam – 2Mb flash) ECM’s again with the ETC MCP (Motorola/FS MC9S12/HCS12) embedded in the controller alongside the main MPC561/5 CPU as a “slave” processor. Linkage between the main & slave was via an SPI link the same as E40.

With the back off an E38 it is pretty straight-forward to hook up a ULink-NT in BDM mode and explore the Slave flash (read & write).

The 32k binary image of the Slave flash comes out reverse to the main flash.

Operating System: 0x0000 to 0x67FF (0x6800 – 26k)
Calibration Segment: 0x6800 to 0x6DFF (0x0600 – 1.5k)
Non Volatile Mem 1: 0x6E00 to 0x6FFF (NVM/NVRAM/EEPROM/Long Term Mem – 0x0200 – 512bytes)
Non Volatile Mem 2: 0x7000 to 0x71FF (NVM/NVRAM/EEPROM/Long Term Mem – 0x0200 – 512bytes)
Boot block: 0x7200 to 0x7FFF (0x0E00 – 3.5k)

Guessing this boots from the boot block at 0x7FFF (Seg ID 12589243). Similar format to the main flash, just mapped in reverse.

The NVM is similar to the main CPU NVM, 2 banks, 4 blocks per bank (13 or more blocks in main NVM). Blocks get saved per key off cycle and when 4 used the bank is switched. Contains the OS & cal ID’s, Alpha Codes, and other bytes which are probably throttle learn values, status & error codes. No CVN’s or checksums stored.

The OS & Cal have Checksums & CVN’s the same as the main OS/Cals but CVN’s are 1 byte earlier.

Flashing the ETC/slave via CAN requires the OS to be as provided by GM with the duplicated header/index block which is deleted during the flash routine (similar to main OS), whereas the BDM read is just the flash image. (i.e. don’t try and edit out the OS from the BDM image and flash via CAN – ULink NT knows this and caters for it.)

thanks for the info. these e38's must have different segment addresses? looking at my slave OS segment I have in the header:

9b 32 20 07 20 00 c0 a7 e4 41 41 00 01 31 32 36 32 35 38 39 32 00 00 00 00 00 00 00 00 36 f2 00 02 03 02 40 00 7f ff c0 00 e7 ff 40 02 40 1c 40 1f 7f ff c0 00 e7 ff 40 02 7f ff c0 00 e7 ff 01 01 02 01 e8 00 ed ff e8 02 e8 1c e8 1f ed ff e8 02 ed ff

So my OS should be 0x4000-0x7fff and 0xc000-0xe7ff and my cal segment would be 0xe800-0xedff correct? I did throw the segments into ghidra and decompiled it successfully, but there are no references to the cal segment in the OS segment that I can see. I have no experience with this architecture. Is there a register setting I need to assign possibly?

gmtech825 wrote: ↑Thu May 29, 2025 10:19 pm Is there a register setting I need to assign possibly?

r2 & r13 if you haven't already.

ghidra didnt list r2 and r13 as options for this architecture (HCS-12)

gmtech825 wrote: ↑Thu May 29, 2025 10:19 pm thanks for the info. these e38's must have different segment addresses? looking at my slave OS segment I have in the header:

9b 32 20 07 20 00 c0 a7 e4 41 41 00 01 31 32 36 32 35 38 39 32 00 00 00 00 00 00 00 00 36 f2 00 02 03 02 40 00 7f ff c0 00 e7 ff 40 02 40 1c 40 1f 7f ff c0 00 e7 ff 40 02 7f ff c0 00 e7 ff 01 01 02 01 e8 00 ed ff e8 02 e8 1c e8 1f ed ff e8 02 ed ff

So my OS should be 0x4000-0x7fff and 0xc000-0xe7ff and my cal segment would be 0xe800-0xedff correct? I did throw the segments into ghidra and decompiled it successfully, but there are no references to the cal segment in the OS segment that I can see. I have no experience with this architecture. Is there a register setting I need to assign possibly?

Great point! I should have checked the header to clarify/confirm how the memmap is addressed.

Should have posted the bin as well. Some more work to do.

Apologies don't have enough Ghidra experience to guide on register settings yet.

I've just been looking at E55 and new to Ghidra and getting no data references and was reading this thread thinking this is a subject I need to learn about as well. I did a bit of reading this morning and was planning on having a go before I asked anything, but just thought I'd chime in and let you know you are not the only one looking to learn about this subject right now.

Any one got a bin they can throw up?

Here is a collection of slave bins by ID. I'm not sure what is what and it covers most platforms. If you have the cal id you want check in here and see how you go.

Heck, quite the collection! I'll load 1 up in Ghidra for a peek.

Attached is the BDM extracted image 0x0000 to 0x7FFF as read with OS starting at the top at 0x0000 etc.

Operating System: 0x0000 to 0x67FF
Calibration Segment: 0x6800 to 0x6DFF
Non Volatile Mem 1: 0x6E00 to 0x6FFF
Non Volatile Mem 2: 0x7000 to 0x71FF
Boot block: 0x7200 to 0x7FFF
(Boot block runs backwards from 0x7FFF)
(starting at the pre seg ID jump (?) table.)

The OS is an earlier 12617980 vs the later header posted above 12625892. OS Header memmap is the same for both so it looks like the BDM read is offset 0x8000 / 32k into the device flash map (etc?). The ULink config XML now that I check it points to the read starting at 0x8000. Silly me should have checked earlier.

Though I gotta confess my head is not fully around the possibilities of the boot block starting where it does yet LoL. Maybe an M68k guru has an idea? HCS12 spec sheet shows 32k, 64k, 128k flash versions, and this is likely to be some specific automotive spec version.