Open source reflashing for >2002 ECUs

A place to discuss the systems and methods of tuning Nissan engines.
User avatar
fenugrec
Posts: 4
Joined: Wed Aug 10, 2016 5:15 pm
Car: Sentra B15

Post

Hi people,
I'm a total stranger here but I've been hacking on Nissan ECUs for over two years now. I've been figuring out the reflashing process for ~2002 onwards ECUs, specifically those with the K-line OBD2 interface since that's what I have on my 04 Sentra.

It's been done before by a few people and companies, but I figured it would be nice to have it documented and open-source. Here's some of what I've been up to : (arg, I can't post URLs due to me being in the "new poster baby sandbox") !!!
nissanecu.miraheze.org NissanECU wiki: lots of reverse-engineering info
"Nissan QR25DE ECU dumping tool " : (***) drawn out thread on RomRaider forums where I posted updates as I made slow progress during 2 years.

So now it's pretty much solved :
- use any software (RomRaider/winOLS/ even a hex editor really) to modify your ROM;
- use (***) freediag / nisprog (software I've been working on in parallel, some custom commands in there, and that's almost it.

The last missing piece was a "reflashing kernel" - the way this works is that the stock firmware doesn't hold the low-level routines for reflashing, so it needs to load a kernel to RAM, and execute it from there. The issue was then finding / writing a kernel...

Hopefully this doesn't count as advertising -- I'm not selling anything, but I'd like to promote a crowdfunding campaign I've set up to fund the final development of the reflashing kernel and associated tools. The result is a fully open-source kernel, which as far as I know is something very unusual on the tuning scene.

The campaign is set to begin very soon. Stay tuned on the crowdsupply website (***) ,project name is "nisprog reflashing kernel" !


ArmedAviator
Posts: 526
Joined: Tue Mar 22, 2016 5:28 pm
Car: 2012 M37x
Location: SW Ohio

Post

Did you write the kernel from scratch?
What license is it under?
Has this been tested on a running engine yet or still being hashed out?

User avatar
fenugrec
Posts: 4
Joined: Wed Aug 10, 2016 5:15 pm
Car: Sentra B15

Post

Hi,
ArmedAviator wrote:Did you write the kernel from scratch?
What license is it under?
Yes, I wrote all of it - mostly C code, and some SuperH assembly for the tricky startup code. Other than that, I've been the maintainer of freediag since ~2009 (didn't write all of that code though); and the "nisprog" additions are all mine too.

License will be GPLv3, so real open source, unlike certain products that have "open" in their name : )
Has this been tested on a running engine yet or still being hashed out?
So far, only tested on a bench ECU (05 Sentra QG18DE) as proof of concept. When I get back to my gear in a few days I'll be testing on a QR25DE ECU that still has a car attached P-) I'll try to take some videos or something.

The campaign is now up (sorry for the mangled link, I'm still not allowed to post URLs)
www crowdsupply_dot_com/nisprog/reflashing-kernel

ArmedAviator
Posts: 526
Joined: Tue Mar 22, 2016 5:28 pm
Car: 2012 M37x
Location: SW Ohio

Post

This is really cool if successful, and there's no reason it can't be.

I like digging into how things work and how they can be changed or improved. I only took a few C++ classes as college electives years ago, so I'd not be of any help in terms of coding in C, but I do other coding so understand programming logic.

I think the ultimate goal would be to remove factory firmware, upload your opensource firmware/kernel with near-normal functionality (as best as can be programmed) with stock AFR and spark tables, shift points and pressures, and stuff like that and then have a very easy way to modify those basic things for super cheap custom-tuning.

One big consideration comes to mind, though. There's a chance that any 3rd party firmware, or even factory firmware, can cause some sort of issue at the least opportune time (corner cases) that can cause serious issues. In this case, a serious ECU issue at 75MPH can be deadly. Your programming must be rock solid, and anyone that uses, redistributes, and contributes to these related projects must really be careful and test well, as should always be the case.

User avatar
fenugrec
Posts: 4
Joined: Wed Aug 10, 2016 5:15 pm
Car: Sentra B15

Post

Well, writing ECU code from scratch would be quite an undertaking. There's a few open source projects that do this already. For these ECUS however, some of the hardware is undocumented (custom ICs). Plus, there are many different hardware revisions; probably hundreds of hours of work just to reverse engineer the hardware enough to write code.

I think that effort is better spent analyzing the existing firmware, which already has a proven track record of reliability and is backed by thousands/millions of hours of testing in actual use. This also has the benefit of starting from a known good starting point, making it easier to make incremental changes instead of having to come up with maps and compensation data for absolutely everything.

Note that this kernel is a small piece of code that runs in RAM (erased on the next reboot / power cycle), and only provides a way to reflash the ROM -- it's just a tool. You're absolutely right, the user needs to be extra careful when modifying stock programming.

User avatar
fenugrec
Posts: 4
Joined: Wed Aug 10, 2016 5:15 pm
Car: Sentra B15

Post

Here's a minor video update on the project -
https://www.crowdsupply.com/nipsrog/ref ... /poc-video

The campaign is 50% funded, only 3 weeks to go !

HollywoodJackson
Posts: 262
Joined: Thu Oct 23, 2014 1:35 pm
Car: 2004 Infiniti G35
1990 Nissan 240SX Hatchback
1990 Nissan 240SX Coupe
Location: Hollywood, CA
Contact:

Post

Very interesting!

Altima.Coupe
Posts: 1
Joined: Tue Jul 21, 2020 5:56 pm
Car: 2009 Nissan Altima 3.5 2d

Post

Hoping you're still active because I am pretty stuck trying to dump by 09 altima 3.5 I have the VAG-COM 409.1 cable is this still viable for my model any help would help a lot i like working on this car on my own screw uprev but I have tried everything I can think of and cant find anyone else as stuck as I am thank you
nisprog with debug on
diag_os_gethrt() resolution <= 0us, avg ~0us
diag_os_getms() resolution: ~16ms.
diag_os_chronoms() : resolution: ~15ms
Calibrating timing, this will take a few seconds...
Calibration done.
nisprog v1.02
nisprog: Interface set to default: DUMB
nisprog: Type HELP for a list of commands
nisprog: Type SCAN to start ODBII Scan
nisprog: Then use MONITOR to monitor real-time data
nisprog: **** IMPORTANT : this is beta software ! Use at your own risk.
nisprog: **** Remember, "debug all -1" displays all debugging info.
interface is now DUMB
Note concerning generic (dumb) interfaces : there are additional
options which can be set with "set dumbopts". By default
"K-line only" and "MAN_BREAK" are set.
port set to: \\.\COM3
dumbopts set to: 72
testerid: using 0xFC
destaddr: using 0x10
L1 debug is 0x8C: READ WRITE DATA
now using 7055.
diag_l1.c:156: _send: len=5 P4=5 l0flags=0x1011; 0x81 0x10 0xFC 0x81 0x0E
diag_l1.c:254: _recv request len=1024, timeout=70;
diag_l2_iso14230.c:736: Read/Write timeout.
diag_l2.c:438: Read/Write timeout.
L2 StartComms failed
p3 set to 0 (0x0).
Must be connected normally (nc command) !
nisprog: Settings loaded from nisprog.ini

nisprog> debug all -1
Debug values: L0 0xFFFFFFFF, L1 0xFFFFFFFF, L2 0xFFFFFFFF L3 0xFFFFFFFF CLI 0xFFFFFFFF
nisprog> nc
diag_l2.c:237: l2_open Generic dumb serial interface on 00F50E90, L1proto=1
diag_l1.c:100: diag_l1_open(0x00F50E90, l1 proto=1
diag_l0_dumb.c:202: open port \\.\COM3 L1proto 1
diag_tty_win.c:62: Device \\.\COM3 opened, fd 000000D0
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1024, t=30
diag_l2.c:349: _startCommunications dl0d=00F50E90 L2proto 3 flags=0x1 10400bps target=0x10 src=0xFC
diag_l2_iso14230.c:529: _startcomms flags=0x1 tgt=0x10 src=0xFC
diag_l2.c:607: diag_l2_ioctl 00F56A50 cmd 0x2101
diag_tty_win.c:168: dev 000000D0; 10400bps 8,1,3
diag_l2.c:607: diag_l2_ioctl 00F56A50 cmd 0x2202
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1024, t=30
diag_l2.c:607: diag_l2_ioctl 00F56A50 cmd 0x2201
diag_l0_dumb.c:591: device link 00F50E90 info 00F50EA8 initbus type 1
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1024, t=30
diag_l0_dumb.c:275: dl0d=00F50E90 fastinit
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1024, t=10
diag_l2_iso14230.c:858: _send: dl2conn=00F56A50 msg=0066F854 len=1
diag_l2_iso14230.c:932: _send: 0x81 0x10 0xFC 0x81 0x0E
diag_l1.c:156: _send: len=5 P4=5 l0flags=0x1011; 0x81 0x10 0xFC 0x81 0x0E
diag_l0_dumb.c:655: l0_send dl0d=00F50E90 len=1; 0x81
diag_l0_dumb.c:689: _recv dl0d=00F50E90 req=1 bytes timeout=200
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1, t=200
diag_l0_dumb.c:698: Got 0x81
diag_l0_dumb.c:655: l0_send dl0d=00F50E90 len=1; 0x10
diag_l0_dumb.c:689: _recv dl0d=00F50E90 req=1 bytes timeout=200
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1, t=200
diag_l0_dumb.c:698: Got 0x10
diag_l0_dumb.c:655: l0_send dl0d=00F50E90 len=1; 0xFC
diag_l0_dumb.c:689: _recv dl0d=00F50E90 req=1 bytes timeout=200
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1, t=200
diag_l0_dumb.c:698: Got 0xFC
diag_l0_dumb.c:655: l0_send dl0d=00F50E90 len=1; 0x81
diag_l0_dumb.c:689: _recv dl0d=00F50E90 req=1 bytes timeout=200
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1, t=200
diag_l0_dumb.c:698: Got 0x81
diag_l0_dumb.c:655: l0_send dl0d=00F50E90 len=1; 0x0E
diag_l0_dumb.c:689: _recv dl0d=00F50E90 req=1 bytes timeout=200
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1, t=200
diag_l0_dumb.c:698: Got 0x0E
diag_l2_iso14230.c:214: _int_recv dl2conn=00F56A50 offset=0x0, tout=70
diag_l2_iso14230.c:262: before recv, state=1 timeout=70, rxoffset 0
diag_l1.c:254: _recv request len=1024, timeout=70;diag_l0_dumb.c:689: _recv dl0d=00F50E90 req=1024 bytes timeout=70
diag_tty_win.c:347: tty_read: ttyh=00F511D0, fd=000000D0, len=1024, t=70

diag_l2_iso14230.c:279: after recv, rv=-8 rxoffset=0
diag_l2_iso14230.c:736: Read/Write timeout.
diag_l2.c:434: protocol startcomms returned -8
diag_l2.c:438: Read/Write timeout.
diag_l2.c:298: Entered diag_l2_close for dl0d=00F50E90;
closing dl2link 00F51200.
diag_l2.c:203: l2_closelink 00F51200 called
diag_l1.c:117: entering diag_l1_close: dl0d=00F50E90
diag_l0_dumb.c:250: l0 link 00F50E90 closing
diag_tty_win.c:120: diag_tty_close : closing fd 000000D0
L2 StartComms failed
nisprog>


Return to “Engine Tuning”