When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
Just wanted to update this thread with some new information:
I've been working on a new GUI ROM Editor/Viewer that will incorporate fenugrec's flash kernel directly. I talked with AK_Eyes a while back about it, but due to a loss of a job it kind of got put on hold. But over the last month or so I've been working on completing it, and I only have a few more things to work on before it is completed. See the photo for a view of the current progress.
So here's what I have left:
1) Combine the fenugrec's kernel with the C#/WinForms ROM viewer/editor I made. I'm attempting to use InteropServices to do this, but I've been having some trouble due to lack of experience. I'm personally debating whether to just write a class that runs the kernel in the background instead of trying to use Interop to access the C methods. If anyone can contact fenugrec and ask him to help me with this that would speed things along tremendously, or if no one else has experience with this i'll just figure it out for myself.
2) Create a better GUI. I mean just look at the photo lol nobody will want to use the software with the tables looking like that. I'm terrible at programming GUI stuff though. I was thinking about incorporating some heat mapping into the tables to make it look better (similar to pretty much every tuning software out there), but idk.
3) Currently I've been testing the software by simplifying things in the sense of hard coding table addresses for a specific 350Z ROM. I've already written an XML parser for definitions, I just need to switch the hard code with xml parsing code I already have. Shouldn't take too long.
4) Right now if you edit a table, there is a save button which allows you to save the edited ROM. However if you close out of the table edit view, the ROM isn't saved. I need to code something that allows you to make temporary edits and save all of those edits at one time. Saving the ROM every time you edit the table is extremely inefficient and I want to change that.
5) Finally definitions. I've only defined a select few tables for a couple ROMs to test the software. I don't plan on doing this all myself, I'm sure other people can step in and write more definitions with more tables, but that's where it currently stands. I'm also working on a disassembly tool strictly for our ECU's that makes a best guess at where common tables are for undefined ROMs.
I updated the Github repo a little earlier, but I migrated over to a new project so the current public repo doesn't contain all the code. I'll create a new repo soon and post the new link.
Whoah! That is AWESOME.
Just another thought if you're going to do this, you need to incorporate the checksum correction part as well.
Also, you will need to be able to edit the table axis as well, as many of those are needed for certain tuning tasks.
Fenugrec hangs out on the freenode IRC in the #freediag channel.
I'll let him know to pop over here as well, but it seems he's on there a bit so if you do irc it might be worth popping in and finding him.
I'm not sure if I put enough emphasis on this, but that work is AMAZING. It's definitely a huge step forward, because the rom raider software is becoming antiquated and hard to work with due to using java and older 32 bit at that.
I certainly welcome it.
Last edited by murphys_law; 01-07-2017 at 01:32 PM.
Just another thought if you're going to do this, you need to incorporate the checksum correction part as well.
Also, you will need to be able to edit the table axis as well, as many of those are needed for certain tuning tasks.
Fenugrec hangs out on the freenode IRC in the #freediag channel.
I'll let him know to pop over here as well, but it seems he's on there a bit so if you do irc it might be worth popping in and finding him.
I'm not sure if I put enough emphasis on this, but that work is AMAZING. It's definitely a huge step forward, because the rom raider software is becoming antiquated and hard to work with due to using java and older 32 bit at that.
I certainly welcome it.
Thanks a lot! It's great to hear that my work is appreciated. I sent you a PM back, but I already spoke to fenugrec on the IRC and we came up with a decent solution that I think i could make work.
BTW the table axes are editable. The data is displayed using a DataGridView in which all of the cells are editable cells.
Thanks a lot! It's great to hear that my work is appreciated. I sent you a PM back, but I already spoke to fenugrec on the IRC and we came up with a decent solution that I think i could make work.
BTW the table axes are editable. The data is displayed using a DataGridView in which all of the cells are editable cells.
Great, I just wanted to make sure that was something you had considered.
I'm not really sure about how to make the gui really user friendly or anything, but there is quite a bit of tuning software out there to look at and get examples from I would think. A few that come to mind that are pretty simple are:
ROM editor portion of the software getting a lot better. I added the XML parsing code in, added in a form that allows you to select your definition so you don't have to hard-code the file path, cleaned up the GUI (only a little lol, it's still awful), added temporary table saving so you can save the entire ROM at one time instead of having to save a new file every time you edit a table, cut down on some code to reduce the file size, added ROM overwriting capability. Currently only supports timing main and fuel target tables, but adding new support for other defined tables is about as simple as copying and pasting. Same code, different variable names.
A few notes about the definition file format:
fromromexpr=expression to convert ROM byte to base 10 format in the editor
toromexpr=expression to convert base 10 format to ROM byte
roundat=number of significant digits to display, set it to whatever you want
storagetype=enter "byte" for an unsigned 8 bit integer, enter "short" for an unsigned 16 bit integer
startaddress/endaddress=the start and end hex addresses for each table. Make sure you include the 0x prefix in the XML attribute or the application will crash.
I will upload the combined flashing/rom dumping application by the weekend. If you have the ability to test I'd love to get your feedback.
HUGE step forward made today. I have integrated the nisprog program with my NisROM tuner GUI application, just need to manually set a few more commands in my code. This means NisROM Tuner now has access to the npkern kernel, and will be able to reflash very soon (if I'm lucky within a couple days). By tomorrow night I'm hoping ROM dumping will be fully supported.
Dam dude your putting in some serious time and effort!
Appreciate it man, it's been a lot of fun though so it hasn't felt like it.
Big thanks to murphys_law for helping me tonight to test out and confirm the fast ROM dumping through my GUI application has been confirmed as working. It's a very good feeling when things end up working correctly after you put a lot of time into it
My NisROM Tuner application will no longer be worked on by me as I have been recently hired by UpRev as a software developer. It was an opportunity i couldn't pass up. Good luck to all of you working on open source options though!
Nisprog/kern and Rom Raider Nissan Ecu editing/flashing
Alright guys, since there hasn't been much activity on this I made a couple of videos walking through the dumping and(as of yesterday) flashing.
There are a few command line tools that I used to do this, but the main one is fenugrecs "nisckfix2" which you see me using to correct the checksums in the rom. I also used his "nisrom" program to find the security keys for the rom that I flashed along with the checksum locations that are in the definition file for the maxima ecu that I have on the bench and am flashing.
His repo with the tools are at the link below, and they do need to be compiled from source with a c complier.
My definition files that are being used with Rom Raider are at the link below(which should be linked above as well, but I thought it would be nice to have it all together.)
Videos below, let me know if there are any questions as I would love for guys to start using this and contributing to the project.
One final note, it currently works on approximately 2004-2009 Nissan/Infinity and hopefully when the second part is released it will support the earlier Nissans(03 g35, 2002/3 maxima, sentra, and others that aren't supported by other tuning companies.
Alright guys, since there hasn't been much activity on this I made a couple of videos walking through the dumping and(as of yesterday) flashing.
There are a few command line tools that I used to do this, but the main one is fenugrecs "nisckfix2" which you see me using to correct the checksums in the rom. I also used his "nisrom" program to find the security keys for the rom that I flashed along with the checksum locations that are in the definition file for the maxima ecu that I have on the bench and am flashing.
His repo with the tools are at the link below, and they do need to be compiled from source with a c complier.
My definition files that are being used with Rom Raider are at the link below(which should be linked above as well, but I thought it would be nice to have it all together.)
Videos below, let me know if there are any questions as I would love for guys to start using this and contributing to the project.
One final note, it currently works on approximately 2004-2009 Nissan/Infinity and hopefully when the second part is released it will support the earlier Nissans(03 g35, 2002/3 maxima, sentra, and others that aren't supported by other tuning companies.
I hope to see this develop into a great open source tuning tool for our cars just like the Subaru community has turned into. Currently I am working on a megasquirt setup for my twin turbo z, but I've always wished for a rom tune for our cars.
I think uprev is the biggest road block to our community as their greed has gone a long way into preventing a open source community from thriving here. The free software available for the Subaru guys is leaps and bounds better then the crap they charge hundreds of dollars for our cars.
I have some limited coding and electronics experience and I hope to contribute to this thread over the next few months.
I was thinking about this a lot over the winter months but had too many other projects going on to start on it. I did however chip in $100 toward fenugrec's crowd sourced reflash kernel. I do still want to get him a dump of my 2010 370z.
I'm going to work on a dump asap. I'd love to contribute. Uprev and even Ecutek are a nightmare. I'm not paying $900 for a flash that I cannot control.
I have a background in UI design, development and some electronics, microcontroller experience. I created the CAN hacking device the CanBus Triple. http://canb.us
I was thinking about this a lot over the winter months but had too many other projects going on to start on it. I did however chip in $100 toward fenugrec's crowd sourced reflash kernel. I do still want to get him a dump of my 2010 370z.
I'm going to work on a dump asap. I'd love to contribute. Uprev and even Ecutek are a nightmare. I'm not paying $900 for a flash that I cannot control.
I have a background in UI design, development and some electronics, microcontroller experience. I created the CAN hacking device the CanBus Triple. http://canb.us
Look forward to contributing. Good work so far!
The later ecus are all canbus. I've got some information on dumping if you get that far. However the flashing won't work at this point as the developed solution is all via k-line.
We really need to try and get logging working as that would enable a lot more development along with being able to make it a complete package.
The later ecus are all canbus. I've got some information on dumping if you get that far. However the flashing won't work at this point as the developed solution is all via k-line.
We really need to try and get logging working as that would enable a lot more development along with being able to make it a complete package.
Agreed, and +1000 on logging. It wouldn't even be that hard to add to RomRaider, it's already built for this.
On the plus side, reflashing over CAN shouldn't require a kernel at all, "just" some PC software.
01-07-2017, 12:49 PM
