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
1. CANBUS Implementation.
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.