[theshadow27]

Picked up a CEM on eBay specifically to destroy it (carefully)... For science! Will eventually correlate this with the design/function info from ViDA, but for now, enjoy the pictures :beer:

Top of CEM (when installed in vehicle) - this is the power board side.


Bottom of the CEM (when installed in vehicle) - this is the logic board side.


ITS A FORD?!1?/!?>

jk

Fuses and relays removed.


The best way to open this case without breaking anything is to carefully disengage one locking tab at a time with a thin spudger (or screwdriver) and insert a zip tie such that it can't re-lock. Once all tabs are shimmed out, the case will just fall apart.


Bottom of case removed, exposing logic board. There is a small power board structurally attached with jumpers for the Floor-1 connector, presumably due to limitations on their pick-and-place or reflow setup (or cost savings by reducing multilayer footprint, or for better noise isolation).


Close up of logic side, still in case. This is a 4 or 5 layer PCB with a conformal coating, making following traces and identifying components a huge pain (see below).


Power side, removed from case. Note there are 5 different, non-replaceable mechanical relays (in addition to the two replaceable relays R15 and R16). This is a 2 layer (top and bottom) PCB making it super easy to follow traces. There is no conformal coating, and all contacts are tin plated as would be expected for an interior component (opposed to Ag/Au found in corrosive environments like the engine bay).


The complete CEM internal assembly. No additional fasteners or fly leads - it's self supporting including all electrical contacts. The upper and lower halves are structurally connected using thick jumpers which provide the majority of the support in both compression and tension. There is a plastic spacer which provides additional compression strength towards the center for better rigidity.


Closeup of sandwich assembly, including insulator/spacer.


Reverse of logic board, with attached power connector.


Reverse of power board.


All the parts are belong to us. Yep, this CEM isn't going back together


Logic board isolated.


Neither heat nor solvent would affect the conformal coating, so I resorted to good-old-fassion scraping away. Several hours later, I was able to expose and identify all of the major components (click to enlarge!!):


CPUs
NXP MC9S12DG256 @ 4 MHz (2 CAN modules) -> low speed only
NXP MC9S12DT256 @ 8 MHz (3 CAN modules) -> high speed and low speed

Dual Inline
1 - Infineon BTS443P 25A Smart Highside Power Switch
2 - Infineon BTS724G 4 x 3.3A Smart High-Side Power Switch
3 - Infineon BTS5210G 2 x 2.4A Smart High-Side Power Switch
4 - Infineon TLE4269 5V 150mA Automotive Qualified Regulator
5 - Infineon TLE4299 3.3V 150mA Automotive Qualified Regulator
6 - ON Semi MC14538B Dual Precision Retriggerable/Resettable Monostable Multivibrator
7 - NXP MC33399 LIN Physical Layer Interface
8 - NXP TJA1040 CAN Physical Layer Interface
9 - NXP HEC4013B Dual D-Type Flip-Flop
10 - NXP HCF4081 Quad 2-Input AND Gate
11 - ST Micro L9823 Octal low-side driver for bulb, resistive and inductive loads with serial input control, output protection and diagnostic
12 - ON Semi MC74HC4851A Octal analog mux/demux with injection current effect control (Automotive)

SOT
1 - BCP53 -1.2A PNP GP Transistor
2 - Infineon BSP78 3A Smart Low Side Power Switch
3 - BCP55 1.5A NPN GP Transistor
4 - Infineon BSP75N 1A Smart Low Side Power Switch

 

[quadcamsix]

Wow,

This is great! What do you plan to do? I may be able to lend a hand. I am a EE with some CAN experience. It would be really cool to add some capabilities such as press and hold for window roll down or approach lights also turn on headlamps etc..

 

[theshadow27]

What do you plan to do?

Objective 1: Identify cause of closed-loop error condition with DRL/ABL and HID retrofits during daytime with LSM in position 0. Reached the limits of what the docs, VIDA and DiCE could get at, and I wasn't going to take mine apart. Halfway through that, the SOT-23s on the reverse of the logic board are a lot more delicate than the big ICs so it's really tedious to get identification off them, and the multilayer+conformal really sucks for tracing. Slowly but surely.

Objective 2: Extract the CEM design/function info from VIDA (done) and correlate it with the VWD (tbd) and the actual CEM circuitry (in progress) to determine actual software-upgradeable capabilities and allow others to collaborate. Eventually get a flash dump of both ICs and post that too so someone with more time than me can disassemble it

Objective 3: My eventual goal is still a working DIM LCD boost / AFR gauge, along with other arbitrary information display. That project stalled when I found out that the CEM was not bridging the required values from HS to to LS CAN (without polling, which is only supported on the OBD-II port)

I may be able to lend a hand. I am a EE with some CAN experience. It would be really cool to add some capabilities such as press and hold for window roll down or approach lights also turn on headlamps etc..

Sweet - another EE. Seems like you have a lot more mechanical experience than I do though... V8 is very ambitious

 

[avenger09123]

And im overe here just like why the hell does my CEM and my DDM keep giving me the same no communication error!

Jk, good teardown and info, doing ET right now, gonna follow your post. Not a pure EE guy like some of you out there, Ive enjoyed few too many volts in my younger days, just enjoy how it all works together.

On a side note, since the HS and LS canbusses dont cross their data for you in terms of what you wanted, how come you didnt just seaech for the PID for the AFR and program that in for a custom PID value in an app like Torque or OBDLink? Im sure some of these dudes at the tune shops like Hilton will have the engine computer map and can tell you which one it is and then focus on adding that data to one of the empty blocks in the DIM set(or you might have to make an empty block, considering those rat bastards and their instant MPG sucks nards)

 

[theshadow27]

On a side note, since the HS and LS canbusses dont cross their data for you in terms of what you wanted, how come you didnt just seaech for the PID for the AFR and program that in for a custom PID value in an app like Torque or OBDLink? Im sure some of these dudes at the tune shops like Hilton will have the engine computer map and can tell you which one it is and then focus on adding that data to one of the empty blocks in the DIM set(or you might have to make an empty block, considering those rat bastards and their instant MPG sucks nards)

I'm not sure I completely understand what you are suggesting.... The DIM does not use "PIDs" in the OBD-II sense - this is polling (or "pull") and would be too slow for the speedo/tach values.

The CEM is hardcoded to take some signals off of the HS CAN (speed from BCM/TCM, temp and tach from ECM) and copy them to the LS CAN. These are broadcast at a regular rate so that the gauges update smoothly. This is "push" if you will, compared to the "pull" of OBD-II PIDs. As to reduce collisions and allow other modules to talk, the "push" values are grouped together in a burst as to maintain the sample rate. Some signals (fuel level, engine temp, MPG) are updated at a much slower rate (about 0.5hz) to conserve bandwidth.

Not all high-speed signals can be transmitted on the LS network without saturating it, so to implement a boost gauge or AFR gauge, the CEM needs to be modified to copy the additional value and include it in this burst. The timing is very important, otherwise other modules could get shut out completely without a chance to transmit on the network.

One step at a time though

 

[mgm7890]

Very interested. Just glanced through this but can't wait to read it all. Good job!

Thanks for taking the time to do this.

 

[Slasher]

Dang. You guys are wicked smaht. Btw - good to see you shadow.

 

[avenger09123]

I'm not sure I completely understand what you are suggesting.... The DIM does not use "PIDs" in the OBD-II sense - this is polling (or "pull") and would be too slow for the speedo/tach values.

The CEM is hardcoded to take some signals off of the HS CAN (speed from BCM/TCM, temp and tach from ECM) and copy them to the LS CAN. These are broadcast at a regular rate so that the gauges update smoothly. This is "push" if you will, compared to the "pull" of OBD-II PIDs. As to reduce collisions and allow other modules to talk, the "push" values are grouped together in a burst as to maintain the sample rate. Some signals (fuel level, engine temp, MPG) are updated at a much slower rate (about 0.5hz) to conserve bandwidth.

Not all high-speed signals can be transmitted on the LS network without saturating it, so to implement a boost gauge or AFR gauge, the CEM needs to be modified to copy the additional value and include it in this burst. The timing is very important, otherwise other modules could get shut out completely without a chance to transmit on the network.

One step at a time though

True, forgot about that one, PID's do tend to be slow. But this is why I asked it, as far as I know, the ECM would be the only unit with the live AFR, unless I'm wrong. Is there another module with it? Personally, I am not sure which would be easier, subsituting a signal that's already in the burst (like the ECM calculating the instantaneous MPG's), but this would also require the changing the ECM's burst value instructions from the MPG calc's results to the AFR values. So modifying the ECM instructions, not the CEM, and editing the single data block or two that read's MPG in the DIM to AFR since I'm guessing only the number is sent from the CEM to the DIM and not the rest of it (since the rest of it's static). Just what I thought of. The Instantaneous would still be accurate ha.

 

[theshadow27]

True, forgot about that one, PID's do tend to be slow. But this is why I asked it, as far as I know, the ECM would be the only unit with the live AFR, unless I'm wrong. Is there another module with it? Personally, I am not sure which would be easier, subsituting a signal that's already in the burst (like the ECM calculating the instantaneous MPG's), but this would also require the changing the ECM's burst value instructions from the MPG calc's results to the AFR values. So modifying the ECM instructions, not the CEM, and editing the single data block or two that read's MPG in the DIM to AFR since I'm guessing only the number is sent from the CEM to the DIM and not the rest of it (since the rest of it's static). Just what I thought of. The Instantaneous would still be accurate ha.

My understanding of Volcano is: At design time, the non-networked sensor (signal), actuator (output) and activation (boolean flag) are defined for each electronic module. The Volcano Network Architect (VNA) design software does a static timing analysis of all signals and their required update rate and packs them into frames which are transmitted in time slots to meet the requirements. When modules need a signal, they get a configuration file which tells the Volcano Target Package (VTP) which frames to decode, and what type of data is in those frames (if a expected signal is missing from the timeslot, the module stores a DTC).

In the case of AFR, because the O2 sensor reading is available as a parameter in ViDA, it's value is being transmitted in some timeslot by the ECM on HS CAN. Therefore, with modification to only the CEM (as the HS-LS bridge) the signal can be relayed when required to the DIM.

Using the MPG field is an interesting approach, but I don't think this value comes from the ECM - I believe that it is calculated in the CEM from on the (ever present) ECM and BCM signals. There is no fuel flow signal that I could find, but the ECM sends fuel pressure (FPS), temperature (FPS), and injector duty cycle (output) which can determine l/min assuming the injector flow is known. Alternately (or in addition), the MAF + O2 signals could be used to roughly determine injected fuel mass. The CEM tracks odometer based on BCM speed signal, so for a given instantaneous MPG reading, it would divide distance traveled by the integrated fuel consumption over the sample period. Average MPG is either an FIR low-pass of the instantaneous (more likely) or a true accumulating average (less likely due to the large accumulators required).

This theory is based on the (very sparse) Trip Computer information in VIDA:

The language in the combined instrument panel can be changed. This is done by ordering new software for the driver information module (DIM) from the replacement parts catalogue. In the replacement parts catalogue there is software for reloading the driver information module (DIM) (Reloading DIM) and software for changing to a number of different languages. Reloading reloads the same software that was installed before the control module was replaced.

So yes, the actual static message text is stored in the DIM, numeric values are transmitted over CAN. To change the static text "Average MPG" to "Air-Fuel Ratio" would require a DIM flash, but this would not be so hard considering it's a fixed-length string replace.

There are other functions in the combined control module which can be ordered. However, these are not downloaded into the driver information module (DIM) but into the central electronic module (CEM). These are functions such as the trip computer.

So the trip computer is CEM software, because no ECM flash is required the necessary signals must already be available. From this, and the documents describing Volcano, I assume that *all* signals are available - need to do testing to confirm if this is actually the case.

A number of customer parameters can be programmed into the driver information module (DIM). This is not done using software downloads but using VIDA vehicle communication.
To change these customer parameters, the car configuration file must be updated so that the market code for the driver information module (DIM) is reset to "User Defined". This update is made through a software download. This only needs to be done once.
The following customer parameters can be programmed into the driver information module (DIM):

[ul]
[*]Conditions for the service message to be displayed, mileage, time and engine hours
[*]Unit of temperature. The options are Fahrenheit and Celsius
[*]Units in the trip computer (only applies to vehicles with trip computers). Fuel consumption can be displayed in liters per 100 km, miles per GB Gallon, miles per US Gallon and kilometers per liter
[*]12 or 24 hour clock display.
[/ul]

Now the annoying part - there is numerical conversion math in the DIM - this would need to be accounted for if that field was used for something else in an unmodified DIM, and could reduce the precision of measurement due to rounding.

 

[avenger09123]

I remember reading the DIM programming and it was definitely connected to the CEM in terms of what VIDA told me, but I didn't envision it being that much, especially considering a second trip meter is available through a DIM reprogram and not through a CEM reprogram. But what you said absolutely would make sense since the CEM is what sends the messages and to the DIM on that screen. I could be mistaken here, been a while since I got into VIDA.
As for the available things for the DIM programming, I remember when I redid mine (I was trying to figure out how to change it from KM and *C to Mi and *F) that the "additional options was moreso the availability of the 2 individual trip meters, the menu options that came with mine, show MPG, show AVG MPG, show Temp and and clock (and the subsequent choices from imperial to metric). It didn't offer anything other than those options, but I am assuming something without the Apple like lockdown and Android like detail (an independent program with a DICE or a JP727 passthrough or whatever it's called) would be able to adjust the data blocks independently.

As for the math, are sure it does the rounding? I am wondering if it is just a three digit buffer and throws the rest of it away when it overflows, since when I plug in an ODBII and read gas mileage I can get two to three digits after the decimal point, and for example while the DIM reads 15.9mpg, the PID will show me 15.98 or 15.91, but it won't round up or down from there...

 

[Elvis_Presley]

Sorry to revive this. Would it work to transfer the IC chip(s) from one board to another. My board is badly corroded. I could hire someone who is a good solderer.

 

[avenger09123]

Sorry to revive this. Would it work to transfer the IC chip(s) from one board to another. My board is badly corroded. I could hire someone who is a good solderer.

If I recall correctly, this is possible and has been done before with success, but you will need to pull both canbus modules (the larger chips) out and replace them onto the newer board. Depending on corrosion and function level, it could be a very hard and even worthless task to do. Personally, I'd get the rom dumped first before attempting this, as it would at the very least verify the integrity of the information that allows your components to agree and start the car.

 

[AvechuchoAxel]

Can test procedure

Hello,
This is my first post... Thank you for the time and effort you throw in this post...I'm amazed with the content. I'm stuck dealing with a CEM for weeks.
I need to test CAN in/out of this CEM. Actual vehicle is a ASTON MARTIN DB9 V12. It use the very same part. I have no can to the transmission control module (inside tranny), therefore, I have no start condition, no tranny communication and KEY error.

I identified already can lines @ transmission, but I need some help with CEM testing and identifying CAN H/L transceivers..

Any help will be very appreciated....
Thanks!

 

[theshadow27]

Hello,
This is my first post... Thank you for the time and effort you throw in this post...I'm amazed with the content. I'm stuck dealing with a CEM for weeks.
I need to test CAN in/out of this CEM. Actual vehicle is a ASTON MARTIN DB9 V12. It use the very same part. I have no can to the transmission control module (inside tranny), therefore, I have no start condition, no tranny communication and KEY error.

I identified already can lines @ transmission, but I need some help with CEM testing and identifying CAN H/L transceivers..

Any help will be very appreciated....
Thanks!

Very interesting, Ford divested Aston in 2006 but the DB9 began in 2004 so it's possible. And I thought *I* was embarrassed to have FoMoCo stamped parts... Anyway, so a couple of things;

First, I doubt it is the "very same part" - the Mazda 3 and Ford Focus use a similar *looking* part (and connectors) but the PC boards inside are different as is the software. To make an analogy to a desktop PC, think of this as Ford's standard ATX case - The motherboard, CPUs, and OS are different, even though it has USB connectors.

Second, it's highly unlikely that your transmission connects directly to the CEM - if it's anything like the Volvo setup (or the rest of the P1 platform that share related electronics) there is a dedicated high-speed link between transmission, engine (ECM), and brake (ABS) control modules. The CEM only talks to the ECM, over a secondary, low-speed link. The reason for this is that those three modules (ECM, TCM, and ABS) form a life-critical real-time control system and that network needs to be as tight and fast as possible.

In any case, your best bet is to find a wiring diagram, which will denote the wires colors and pin #s for the various CANs.

Good luck

 

[AvechuchoAxel]

Very interesting, Ford divested Aston in 2006 but the DB9 began in 2004 so it's possible. And I thought *I* was embarrassed to have FoMoCo stamped parts... Anyway, so a couple of things;

First, I doubt it is the "very same part" - the Mazda 3 and Ford Focus use a similar *looking* part (and connectors) but the PC boards inside are different as is the software. To make an analogy to a desktop PC, think of this as Ford's standard ATX case - The motherboard, CPUs, and OS are different, even though it has USB connectors.

Second, it's highly unlikely that your transmission connects directly to the CEM - if it's anything like the Volvo setup (or the rest of the P1 platform that share related electronics) there is a dedicated high-speed link between transmission, engine (ECM), and brake (ABS) control modules. The CEM only talks to the ECM, over a secondary, low-speed link. The reason for this is that those three modules (ECM, TCM, and ABS) form a life-critical real-time control system and that network needs to be as tight and fast as possible.

In any case, your best bet is to find a wiring diagram, which will denote the wires colors and pin #s for the various CANs.

Good luck

Thank you for your input...
I'm working on the can lines... having a wire diagram is quite difficult but not impossible I hope I can find it soon.. Having access to a "similar hardware" might allow me to rip off some replacement parts to fix the original one. Software is not a big deal to transfer between units. So you pointed me to check comm between both ECM's, ABS & TCM...... leaving aside CEM ... I'll check and post results. /tks !
Axel