RomRaider

Yup, that make sense, got it now. You guys are hardcore !

I am sure more question will come but that will get me going for a little while. Just curious, do you guys ever run into issues with IDA confusing code section for data sections after automatic analysis ? I think I might be running into something like that, not sure yet. I'll dig into it some more

Constantly, yes - it's not perfect, there are large parts that may need to be converted manually by forcing code analysis.

You'll have to wait for KPIT as there is no other free comliper integrated into HEW. If you want the Renases compiler you'll have to buy it.

Ok got it and was able to step through NFSW code with the simulator, the package worked like a charm.

I have alot of work to do to catch up with you guys, I probably never will but if I can just end up patching in the CEL light trick from first principle with that tool chain. I am going to be satisfied

Thanks

Hi guys,

Quick question, I am trying to execute the unit test from MerpMod. To do this, I used NSFW ResetHandler.s to call up the main testing function. I do run into a problem, the code compile fine but for some reason, it doesn't seem to fill in the reset vector with the address of the reset handler. This is the code I am using for the reset handler, do I have to do anything to specify that .section Zero start at address 0 ?



My linker map puts that section at 16b8 ...




Thanks

Ok found it, the sections are defined in the GNUSH toolchain options

Hey Merp and others,

First of all, thank you for releasing all of that source. It's been quite the learning tool for me and I must say that I am quite impressed with how extensive the package it with the actual code, unit test etc. I actually caught some improperly mapped data section (for my project) using the unit test.

So, given the scale of what you have submitted, this is quite mundane but I just wanted to point out to what I think might be a small code logic bug in the CELflash routine (and I could be totally wrong btw).



I think that given the FBCK is negative, FBCKHiThreshold should be checked first otherwise you will never hit the else. I found that trying to increase the code coverage as a learning exercise.

Please let me know if I am missing anything. BTW, I do have a couple other questions if you don't mind :

1) How are ramholes found in IDA ? I tried to tell IDA to create a ram section starting at 0xFFFF0000 and of length 0xFFFF. For some reason, it doesn't seem to create any XREF in that area. Despite letting the tool to create a RAM area, mine seems pretty short. Any pointers ?

2) Your WGDC hook, what function is it replacing ? How did you guys find that the function above it is called on a timer based interrupt ?

3) The ram initializer hook. How did you guys find the original ram initializer function in the code

Anyway, don't feel like you have to answer all those questions. I am planning on simulating this a bit more and maybe submitting my patched ROM for peer review if you guys have any cycle. If you can't not sure if I will have the balls to load that into my ECU ... I might order all the stuff that I need to put my ECU in boot mode to unbrick it before I do if necessary, probably not a bad think to have anyway

Good catch! I was probably thinking about FBKC 1 byte, which is scaled inversely. However, IDATranslation.h converts the 1 byte (when used in the mapping) to the same format as 4 byte.



Hmm, even after re-analysis? Typically the ram sections are set up during the initial opening of the rom.



It hooks the WGDC table pull routine, and calls the original code when finished. Timer was determined by trial and error (logging a counter set to increment upon each execution).



Analysis of the first bunch of routines in the reset vector.



Github would be the best option for review. If you need any guidance getting set up on git I can assist with that.

A boot cable is highly recommended, and parts cost is only ~40usd. I will try to dig up my project link on mouser for you.

Hey, thanks for getting back so fast !

First, your answer to #2 allowed me to catch a mistake. Since I undefined everything that isn't relevant (or that I thought wasn't) to celhack, I ended up undefining #BOOST_HACKS which was removing the call the the hook wgdc table. I knew there was no further call to the ECU function hence why I asked my question, make sense now.

A link to your mouser project would be awesome, I might ask dshultz as I think we lives in the same city if he has a setup so that maybe I could use him as a safety while I wait for my parts as I may note have the patience to wait

I'll setup a github in the next couple days.

Again, this has been really entertaining, thank you

Here ya go: https://www.mouser.com/ProjectManager/P ... 9537de7256

For this project, I usually modify the protoboard to rotate it 90*

Also, for git on win: http://code.google.com/p/msysgit/downlo ... ficial+git

Tell me about a turn key solution ! Awesome, components ordered, hopefully I never have to use them Allright, I'll look at checking stuff in over the next couple of days.

Thank you sir

Ok,

So here we are, I checked everything in github over here : https://github.com/whitewater69/merpmod_custom

So my goal is just to have the cell flash when the engine is knocking, nothing else. In order to do that here is how I abused the codebase that you submitted

- Removed call to functions and files that I don't need. I know I am not done doing this clean up but getting there
- Changed the if/else order in cell flash
- Removed the EGT related flash warning
- Added a bit of test coverage
- Used NFSW patching program instead of sharp tune. No real reason here, from what I could find, merp had slightly more doc's on how to use his stuff from first principle.
- Used NFSW reset handler to call the unit test

I am running into a problem when running the simulation, I end up getting an invalid instruction when I call the MemoryReset ECU function in the brickbuster at the end of generic test. Removing the call allow me to complete the program. I will continue to chase this down but its a bit weird, I checked my patched rom with IDA and some binary difference tool and my change are contained only inside the rom hole and the two function hooks (one of the initializer and the other for the celflash). So nothing in that part of the ROM was touched, any pointer on how to debug this would be appreciated. Right now, i'd like to ability to see where the PC was before the invalid instruction was trapped, not quite sure how to do that. Is there a way for recording an history ?

While I am at it I have a question for you merp. The WGDCHack hook function has a different return type compared to the WGDCHooked function. Does that matter ? Maybe the returned floating point value from WGDCHooked would be stored in a FP register that won't get overwritten so it doesn't matter but I wanted to get your feedback on this one.

If you guys have some spare cycles that would be great. I just received all my parts from mouser. I'll go build my cable while I wait for you guys to shime in

Thanks

I'll write up some instructions for git. Ideally, you'll want to clone my repo locally, create a new branch for your work, then clobber everything with the work you've done, and start committing the changes, pushing to github for review or pull requests.

Regarding sub-features you don't need: simply changing the default value for the parameters (flash count, or egt threshold) will effectively disable them, it isn't necessary to gut the code. Just about all of the features I have in there can be enabled/disabled this way.

For full-features you don't need: rather than deleting references, includes, and calls, use preprocessor commands, surrounding blocks of code with #if <featurenamehere> #endif and corresponding #define <featurenaehere> 0 in the configuration header. Most of these are already in place.

The API for SharpTune definitely needs some docs..

I don't have a simulation in front of me to look at right now, but I know invalid instructions show some information in the output window. You may have to set breakpoints to narrow it down. Perhaps some exception handlers are missing. Also, some of those tests run into an infinite loop in the OEM initialization routines (waiting for a peripheral signal). I just skip over the branch manually when running a final test.

Good catch with WGDCHook(ed). In any case, they should be the same, but I think it hasn't been a problem because AFAIK WGDCHooked should be a void anyway.

Thanks Merp,

Yeah, I know replicating the codebase makes it hard to compare against yours, I just wanted to reduce the scope of what gets compiled and patched so it would be easier for me to follow. I'll see what I can do in order to get something closer to the method you suggest.

I found a way to get HEW to capture a instruction trace so at least I can know where think started to get haywire. I'll start digging.

I assume on your side, everything runs flawlessly ? You don't run into issues calling the ECU memory initialization function ?

Ok,

That trace tool was pretty handy, once I used it took me 5 minutes to figure out where the issue was. My reset handler which I use to call the test was overwriting a function that the initializer is calling oops. It wouldn't have been an issue because its not part of the patch but anyhow its kinda cool that the test caught it.

Allright ... I pretty much did all I could to test this :

- Compared the difference with a binary diff tool and confirmed only the two hooks and the rom hole have new stuff
- Double checked with IDA and made sure that my rom hole code wasn't truncated for what ever reason
- Ran all the unit test not 100 % code coverage but pretty much everything I care about has been hit

Should I flash it ?

I'll have a beer and reflect on the matter