Standalone ECU Implementation

This is a project. One which, I'm fairly certain has not been done (or perhaps not documented) before. It's in very early stages- currently, the overwhelming majority of my progress has been acquiring data, which will be shared below. I am an electronics moron. Perhaps you should take what you see below with a grain of salt.

As these cars age, our reliance upon Mopar for electronics/computer support must end, otherwise ownership of these cars into the far future is simply not feasible. Additionally, content discussed below can be useful for standalone ecu implementation for engine swap applications.

Standalone ECU Implementation - The Electronics

For this project, I decided to use an ECUMasters EMU Black. There wasn't much in the way of choice admittedly - as of now, there are only two standalone ECUs on the market, that I am aware of, that have Plug and Play support for the Fiat 500. One of them being a model from SCS Delta, and of course, the EMU Black (and Classic).

The plug and play adapter is indeed plug and play...for the car it is designed for, which is the Euro/Global market spec that uses a Bosch ME7.9.10. Our US spec cars, which use a Marelli8GMx, have quite a lot of differences under the hood, with changes to the: EVAP system, diverter valve, Oxygen sensor(s), the inclusion of MultiAir (and thus the power and gnd to the four, high current solenoids), and a couple other systems.

The different requirements of the US spec car, along with the use of an entirely unrelated ECU family, meant that Fiat had to change the pinout of the factory harness. Thankfully, however, the connector is the same - a variant of the TE284617. This means that, for the most part, the *cars own* harness can be easily repined. I hoped that there would be a way to modify the pinout of the PnP adapter itself, but this proved near impossible given the design.

As it stands, and without me (or someone) making a PnP adapter, modification to the cars wiring harnesses is very difficult to avoid. Personally, I didn't have the time to come up with a solution to that, and decided the harness would just be a casualty of attempting to pioneer something like this.

There are a few main things which stand out as incompatibilities (beyond simply repining).

• The Lambda sensor (Upstream Wideband Oxygen Sensor) is a part of the C2 connector on the T-jet model, whereas it is on the C1 connector for USA spec cars. A jumper of some form could be used, but you are at the mercy of the pinout of the PnP adapter. I suggest wiring the Lambda sensor directly to the EMU Black itself, in this instance.

• The diverter valve is wired differently on the T-jet model. However, this proves to be a non issue for one major reason: since Multiair being removed or made passive is a needed part of this swap, you don't really end up needing electronic control anyway. Since the engine will now be traditionally throttled, you can simply buy a pneumatic diverter valve and hook a single hose straight to the inlet manifold. No valves, no solenoids, no wires. Just air, and it works great provided the correct spring is used.

• The starter interlock relay, which is a physical means of preventing the engagement of the starter if the clutch has not triggered the downstop switch, is switched on the high side by the Marelli ECU, and seemingly on the low side by the Bosch ecu (and thus this PnP adapter). This can be resolved in two ways- one, the interlock function can be removed, by powering the relay any time the ignition switch is on, or, an additional relay can be added which serves to switch the OEM interlock relay on the high side. Alternatively, the oem interlock relay could be replaced entirely by the aforementioned external one- but that would likely involve further modification of existing wiring.

• The wiring of the brake, clutch, and reverse switches is a little messed up, at least it seems that way. In the US spec car, all three of the aforementioned switches operate at 12v. I thought that perhaps this is just because they were floating, but neither of the pulldown options made a difference for me. The EMU Black can support up to 12v on the analog inputs- though it will not read anything over 5v. The switch inputs, which are used by default, are not designed to be given power at all - they are supposed to be switched by closing a circuit to GND. Failure to repin this could lead to damage of your ECU. My short term solution for the reverse switch was to re-wire the reverse switch to go GND > REV SW > EMU Switch Input rather than the factory configuration 12V > REV SW > EMU Switch Input. This works just fine. For the brake pedal switch, I connected the signal wire (which, remember, operates at 12v) to a free analog input. I currently do not have a clutch switch input - but given I don't have control of the Interlock relay yet anyway, I guess it isn't critical. The EMU reads 5V on an analog input for any voltage 5-12v. Additionally, sending 12v does create a slight deviation of the EMUs sensing circuitry voltage, which I am not really happy with. My long term solution will likely be to make a MUX switch and use one analog input for all 3 inputs.

1. CANBUS Implementation. (incomplete, indefinitely)

Edit: While I was able to figure out quite a few parameters by logging the car's C CAN network - it ultimately proved to be unnecessary. Somehow, some way, Fiat changed very little in this regard when adapting the 500 to the US market, despite it having an entirely different ECU. As such, there is no need for me to know...pretty much any of this, though I guess being overprepared is better than underprepared. Regardless, I will list the parameters I know of below, even though I do not know enough of them to create an ECU translator that will satisfy every module on the car.

In order for a modern (lol, kinda) vehicle like the "New" 500 to function relatively normally, communication from the ECU over CANBus is vital. The instrument panel, ABS, electronic power steering, and even the BCM for controlling such minute things as the door locks, all receive vital information from the ECU over CAN. While the idea of implementing this communication in a custom application seems daunting, for the most part, it is thankfully not.

Reverse engineering CANBus comms is very time consuming, and at times, can be difficult or impossible to fully understand the contents. Thankfully, that does not always matter.

Below, the various messages and processes immediately related to the ECU will be broken up into sections, and my findings shared.

The Immobilizer

The Immobilizer function is the cause of headache for many, especially those looking to swap a stock multiair engine into another vehicle such as the X1/9. Thankfully, doing the opposite - implementing a standalone ECU with the stock BCM - is far easier, as the ECU itself is what handles most of the immobilizer function.

The process is quite simple, and is as follows.

Shortly after the ignition is switched on, once every node on the bus has woken, the ECU/PCM sends a message to the BCM with a status bit, four bits of generated data, and two bits of...something.

The BCM then takes in this data, applies some translation/adjustment to it using an internal code, and then replies to the ECU with the result of this translation/adjustment.

The ECU knows what changes the BCM should apply to this data, and thus it knows what response it should receive. The ECU then checks that the response received is what is expected- that the BCM is the one "married" to the ECU, and if it is, the ECUS own fuel cutoff immobilizer is disabled.

The ECU then sends one final message to the BCM, nothing more than a status bit (bit 0), telling the BCM that verification was successful.

Annotation of a recorded exchange is below.

•key is switched on•
ECU sends

0x0010A001 (message ID) , 05 A4 34 18 89 0A 2C ( where 05 is the status bit, A4 34 18 89 are the 'challenge' for the ECU, and 0A 2C are...something)

the bcm replies:

0x0010A000 (message ID) , AB 16 C1 00 00 00 00 ( where AB 16 C1 is the BCMs 'reply' to the ECUS challenge)

after successful verification, the ecu sends a final reply, likely disabling the Immobilizer light on the cluster, among other things:

0x0010A001 (message ID) , 06 00 00 00 00 00 00 ( where 06 is the status bit indicating successful verification)

•immobilizer exchange complete, engine start permitted•

So we can gather, the first (status) bit of 05 seems to indicate the immo is enabled, and is sending a challenge, and that a status of 06 indicates the ecus immo is satisfied. What is not known, is if sending the BCM the status bit 06 without previously sending a challenge will result in no complaints from the BCM. This will be tested soon.