In the typical modern car, the Engine Control Unit (ECU) is used to:
[…] control a series of actuators to ensure optimal engine performance. It does this by reading values from a multitude of sensors, interpreting the data using multidimensional performance maps, and adjusting the engine actuators accordingly.
(adapted from: Wikipedia: Engine control unit )
ECU Overview / graphic from http://secu-3.org
Most ECUs are based on a microcontroller that uses on-board flash memory that contains all the required firmware, calibration data and various parameter maps.
For various reasons, there is usually a way to modify this flash ROM from the outside, usually through the diagnostics access port (OBD-II). Performance tuners, racers, and other avid car enthusiasts often are interested in modifying the ROM so they can achieve:
Until now, there was no fully open source method to reflash these ECUs. The only options were to:
This is not a trivial operation, requiring soldering skills (or a custom jig), a Windows PC for running Renesas software, and miscellaneous electronic hardware (signal generator, 5V UART, etc.). Not to mention that physically opening the ECU can easily go wrong with the sealed case and conformal-coated PCB.
Buy commercial tuning solutions, which can cost hundreds of dollars. These often come with many non-user-friendly usage restrictions and varying degrees of vendor lock-in.
Modify a factory firmware upgrade (not always available, and never free of charge), and reflash using dealership tools. The disadvantages of this are fairly obvious.
This project provides the low-level microcontroller code–both as GPL source code and as precompiled binaries–that can carry out the actual refreshing operation when used in combination with the Nisprog software running on the host machine.
Most gasoline Nissan / Infiniti ECUs from ~ 2002 onwards share very similar ECU hardware, based on SuperH microcontrollers manufactured by Renesas (previously Hitachi). This project supports ECUs that use the OBD-II “K line” signal for diagnostics communications.
The process is carried out entirely over the OBD-II “K Line” serial communications link through an undocumented set of manufacturer-defined extensions to the standard ISO14230 protocol. Recently, the necessary commands have been reverse-engineered revealing the required steps:
The basic reflashing kernel will support gasoline ECUs with:
Unfortunately CAN-only ECUs are not currently supported.
Note : J2534 devices are not currently supported by freediag.
The basic kernel is an implementation of an ISO14230-compliant protocol with extensions; it implements the following requests:
There are several important points to be aware of when using Nisprog:
It works! The process has been successfully tested on a 2005 Sentra (SH7058 mcu). However, the process is very manual:
Upon the campaign end-date, if the basic funding goal is reached, I will release the “current WIP” source code on github. Then, depending on stretch goals, a few weeks more development will be needed to get the features in.
Should the original funding goal be met and exceeded, here are some extra goals and associated features that would make this project even more useful:
Add SID27/36 key database and automatic guessing for unknown ECUIDs. (Short story: two keys are required for running a kernel, which is typically found by manual ROM dump analysis. It’s possible to automate most of this.)
This feature is now included in the Nisprog project, and is added to the list of features that will be available.
Add code for reflashing 0.35um SH7051 and SH7055 devices. These are older, and a bit tricky because the low-level erase and write cycles are quite different from the 0.18um and more recent devices.
Add generic code for writing to the external EEPROMs (bit-bang SPI). Note: the type, size, and mcu pins used by the EEPROM IC still need to be known.
Make a wxWidgets GUI that combines:
In addition to the benefits of the Benefactor level, this comes with an analysis of any eligible ROM dump (*), a massive headstart on analyzing a new ROM!
The analysis in question consists of everything I can identify in that ROM. The ROM must be an unencrypted dump of any gasoline Nissan or Infiniti model from ~2002 onwards, ideally 2002-2009 which are more familiar to me. The analysis will include some or all of the following:
Note: I cannot at this time identify the nature and units of the maps, only determine which areas are maps and which code accesses them.