The Nisprog Reflashing Kernel campaign was successfully funded and is no longer active. However, you can access all the available source code and binaries here: https://github.com/fenugrec/npkern

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:

• Performance gains
• Fine tuning after carrying out engine modifications (turbo addition, air/fuel/exhaust system upgrades, etc.)
• Feature customization (RPM limiter, idle settings, etc.)

Until now, there was no fully open source method to reflash these ECUs. The only options were to:

• Physically open the ECU, tap into the factory testpoints directly on the PCB, and reflash.

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.

Which ECUs Will This Work On?

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.

How Does the Reflash Process Work?

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:

1. Establish connection to the ECU.
2. Send the first stage data payload: this is the "kernel", a simple program that will receive commands and data for the reflash.
3. Make the ECU run the kernel. From this point on, the kernel runs from RAM and effectively takes control of the whole ECU.
4. Send the reflash commands and new firmware data to the kernel.
5. Reset the ECU: the new firmware will now be executed, and the kernel will be completely removed.

Requirements

The basic reflashing kernel will support gasoline ECUs with:

• SH7055 or SH7058, 0.18um microcontrollers (the most common types)
• K line wired to the OBD-II connector pin 7

Unfortunately CAN-only ECUs are not currently supported.

Host computer:

• OS: Linux and Windows are known to work; Nisprog is based on freediag source code which is cross-platform and should run on most Linux/UNIX flavors.
• Connectivity: a simple USB-OBD adapter is required. These are the "Generic dumb serial adaptors" described in the freediag docs.

Note : J2534 devices are not currently supported by freediag.

Kernel Features

The basic kernel is an implementation of an ISO14230-compliant protocol with extensions; it implements the following requests:

• fast ROM dump (tested up to 5.4 kB/s; typical speed is ~100 B/s without a kernel)
• Read ROM/RAM/external EEPROM
• Write to RAM
• Erase flash ROM block
• Write flash ROM block

Limitations

There are several important points to be aware of when using Nisprog:

• The ECU is a safety-critical system in a car. Reflashing an ECU can void warranties, reduce the vehicle's reliability, and cause a whole variety of undesirable consequences.

Use of this project and any associated tools (freediag, Nisprog, etc) is of course entirely at the user’s risk. Standard disclaimers apply.

• Reflashing an ECU may be illegal in some areas. Responsibility in this matter lies again with the user.
• Diesel ECUs are not supported, they are entirely different.
• Tuning and modifying ROMs are complex skills that can only be acquired through significant investments of time and effort!

Project Status

It works! The process has been successfully tested on a 2005 Sentra (SH7058 mcu). However, the process is very manual:

• Modify ROM with external tool (hex editor etc)
• Fix checksum(s) inside the ROM with command-line utilities
• Extract desired blocks (7055 and 7058 ROMs are divided in 16 blocks; each modified block needs to be specified individually)
• Connect to ECU + run kernel
• Erase desired block
• Write desired block
• Repeat erase + write cycle for every block

Next steps

kernel

• Test on 0.18um SH7058 ECU
• Improve the build system to make the kernel easier to customize and compile.
• Structure the source code to make it easier to add more device support (0.35um SH7051 and SH7055, SH7059, SH72533 to name a few).
• 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).

nisprog

• Split Nisprog out of the freediag source tree into a standalone, command-line tool
• Implement full ROM reflash so that per-block splitting will not be required
• Implement automatic speed adjustment if communication errors occur
• Increase robustness and improve error recovery to avoid bricking the ECU

Fulfillment

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.

Stretch goals & extra features

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:

$800: Level 1, "autokey"

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.

$1000: Level 2, "0.35um"

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.

$1100: Level 3 : "EEPROM"

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.

$1500: Level 4 : "GUI"

Make a wxWidgets GUI that combines:

• ROM information query
• Checksum tools (identification, verification, and adjustment)
• Dump/Reflash functions

ROM Fortune Pledge Level

Details

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!

Production and delivery schedule

• Delivery will take place a few weeks after campaign end, depending on reached goal(s) and number of ROMs I need to analyze!
• The analysis will be published on forums and websites for the benefit of the community.

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:

• general ROM structure: interrupt vectors, metadata (LOADER / FID structures), reflashing keys, etc.
• function addresses: call tables, iso14230 decoding tree, main SID handlers, checksums, EEPROM read/write.
• map-related info: code confirmed maps, associated axis data, interpolation functions, etc.

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.