ROM disassembly questions

Initial Z · **Joined:** Thu May 20, 2021 3:15 pm **Posts:** 42

Quote:

Your best bet would be to cross reference with CF48D, as it cross references nicely with all Z/G ROMs. (03-06) The main thing to keep in mind is SH7055 has half the ROM space as SH7058, so a lot of the empty space found within CF48D won't be there within your ROM. So things won't look as pretty for your ROM since everything's typically just crammed together haha

In order not to clutter pytrex' thread with my beginner questions, I thought of starting this thread and gathering them here. Maybe they'll also help someone in the future who's also just beginning tinkering with ecu ROMs.

So, I've followed this https://nissanecu.miraheze.org/wiki/Rom_an_cf48d#wols guide, and I'm comparing an -03 jdm CD415 vs the -06 usdm CF48D. Started with the ignition maps even though they are already defined for the cd415.xml just to get my feet wet and for learning the tools before trying to find undefined maps.

I've connected the two maps in wols, and with an offset of -2688, the High Temp Fuel Compensation maps line up. The CF48D has three ignition maps after that, which are very distinct in the hexdump. CD415 also has three maps at similar spots, two of which are nearly identical vs CF48D. So in the CD415.xml definition the first one is defined as cold ignition timing map and its axes are defined as well. I don't doubt that it's that map, as what I've read from the forums here, the 350z ROMs seem to line up very nicely. But I'm curious as to how were the axes' addresses looked up and the map verified that it indeed is the timing for cold ignition.

Opening the rom in Ghidra, with SH4 bigendian specification (correct me if this is wrong for the SH7055) and scrolling down to DAT_00006749 has one cross reference to function(?) LAB_000243d4 and a couple of rows above the cross referenced line 00024404, there is this instruction

000243fc d5 24 mov.l PTR_DAT_00024490 ,r5 => DAT_00008447 = 08h = 00008447

The xml has 0x8447 as the Y axis for the cold ignition timing map, but I don't quite grok how someone previously determined from the assembly that this is indeed the memory address for the Y axis data.
My knowledge of assembly language is pretty much restricted to handwritten x86 blitter functions that I had to debug at one point. A short crash course specifically into verifying maps and finding axes using Ghidra would be much appreciated! And sorry for the wall of text.

PS. I know of the youtube vids fenugrec made about reverse engineering ecu roms with IDA, but haven't had the chance to go through them just yet.

Pytrex · **Posted:** Mon May 24, 2021 3:28 pm

Initial Z wrote:

Opening the rom in Ghidra, with SH4 bigendian specification (correct me if this is wrong for the SH7055)

Eh, it's what I've always done.

Quote:

map verified that it indeed is the timing for cold ignition.

Analyzing the actual logic and coming to a conclusion based off said logic. So if it only utilizes a certain map when coolant temperature is below a certain threshold, then that would indicate that the map is only used when the vehicle is cold/below a set temperature.

Quote:

The xml has 0x8447 as the Y axis for the cold ignition timing map, but I don't quite grok how someone previously determined from the assembly that this is indeed the memory address for the Y axis data.

So when you locate the map/table within a function, it'll have the address be copied to r4. The X-Axis will be copied to r6, while the Y-Axis will be copied to r5. So whoever defined CD415 originally just copied over the addresses from r5 and r6.

Initial Z · **Joined:** Thu May 20, 2021 3:15 pm **Posts:** 42

Pytrex wrote:

Analyzing the actual logic and coming to a conclusion based off said logic. So if it only utilizes a certain map when coolant temperature is below a certain threshold, then that would indicate that the map is only used when the vehicle is cold/below a set temperature.

Ah, but that then leads me to yet another question! How does one determine that a certain variable is the coolant temperature, when all I see in Ghidra are LAB_000xxxx functions, 000xxxx memory addresses and xVarx variables?

Pytrex wrote:

So when you locate the map/table within a function, it'll have the address be copied to r4. The X-Axis will be copied to r6, while the Y-Axis will be copied to r5. So whoever defined CD415 originally just copied over the addresses from r5 and r6.

Are those three registers always used in such a way for a map and its axes? So I could determine the axis addresses without even knowing what the map is just yet simply by looking at what gets loaded into r5 & r6? What about figuring out the units for an axis and the factor and offset for wols?

I'm trying not to get utterly overwhelmed, but I've got 3 brand new to me programs in front of me, all of which I can barely use yet and I keep running into walls about the most basic things right now. There are so many things that I don't even know that I don't know at the moment!
I get that it's not gonna happen over just a few hours, but my main goal is to be able to tune my car. If I don't know the bare necessities on how to find and verify a map, it's gonna be real hard to do that. :lol:

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

Initial Z wrote:

Are those three registers always used in such a way for a map and its axes?

Do watch my YT vids, they're not complete tutorials and they assume some basic knowledge, but it should give you a better idea of what you're looking at.

In short, the best way is to cross-reference from either the most well-known ROMs that have an A2L (e.g. ZB060) or one where someone spent ridiculous amounts of time on (CF48D).
Without those, making a def is much harder. You start with some easy-to-find vars like the loggable parameters (CID tables), or OBD-reported values, then work from there. I did that a fair amount and it's a lot more work than having a well-defined ROM to look at. Don't do that.

If you take say CF48D and it looks very different, there will still be more similarities than differences. Sometimes you can even search for certain values (say the first row of a map) and find the exact same map (or 90% identical) in your ROM. Once you have a few footholds it gets easier.

kalisto2002 · **Joined:** Tue May 05, 2015 9:01 pm **Posts:** 38

fenugrec wrote:

Initial Z wrote:

Are those three registers always used in such a way for a map and its axes?

Do watch my YT vids, they're not complete tutorials and they assume some basic knowledge, but it should give you a better idea of what you're looking at.

In short, the best way is to cross-reference from either the most well-known ROMs that have an A2L (e.g. ZB060) or one where someone spent ridiculous amounts of time on (CF48D).
Without those, making a def is much harder. You start with some easy-to-find vars like the loggable parameters (CID tables), or OBD-reported values, then work from there. I did that a fair amount and it's a lot more work than having a well-defined ROM to look at. Don't do that.

If you take say CF48D and it looks very different, there will still be more similarities than differences. Sometimes you can even search for certain values (say the first row of a map) and find the exact same map (or 90% identical) in your ROM. Once you have a few footholds it gets easier.

now if only there was a way i could incorporate that first row of map data (Within 10%) into my nifty map lookup tool for hondas.

Are the Nissan Densos not like the subarus (in the way the maps are defined with 2d table lookup and 3d table lookup?)
Denso subarus have this neat little structure prior to table data that define, axis,data, scalars,etc
is that not applicable here?

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

kalisto2002 wrote:

Denso subarus have this neat little structure prior to table data that define, axis,data, scalars,etc
is that not applicable here?

No such luck. Otherwise we'd have already a tool to make defs automatically by now...

Until we have an insider at Nissan/Renault that can leak some A2Ls, we clowns are stuck with the long method.

Initial Z · **Joined:** Thu May 20, 2021 3:15 pm **Posts:** 42

fenugrec wrote:

Initial Z wrote:

Are those three registers always used in such a way for a map and its axes?

Do watch my YT vids, they're not complete tutorials and they assume some basic knowledge, but it should give you a better idea of what you're looking at.

If you take say CF48D and it looks very different, there will still be more similarities than differences. Sometimes you can even search for certain values (say the first row of a map) and find the exact same map (or 90% identical) in your ROM. Once you have a few footholds it gets easier.

Aha, seems your vids did have answers to plenty of my questions. Thank you for those!
I'll definitely check against the CF48D bin and definitions since that allows me to leverage the huge amount of work pytrex has done. The CD415 actually seems to have most of the very basic maps already defined for tuning a car. I'll want to double check them before modifying and uploading a new rom to my car, but at least it should give me a nice headstart. Time to start learning how to use Ghidra at least passably.

Are there any specific maps I should focus on, when my plan is to first install bigger injectors, adjusting the RE5R05 shifts faster, and ultimately supercharging the car with a modest power goal of 350-380hp? If that can be done with the factory ECU, it would save quite a chunk of money for not needing to get an aftermarket ECU.

Another thing I'm very curious of is the possibility of taking advantage of the high octane timing map. My car is currently set up as flexfuel car with a piggyback control box that adjusts the injector's open duration depending on the amount of ethanol in the fuel. I pretty much run E85 exclusively, and I could always remove the flexfuel box and tune it purely for E85, but if it's possible it would be really neat if I could take advantage of E85 higher knock limit via the high octane timing up and still retain the possibility of using regular gas. Is something like that feasible with the factory ECU and its maps?

Current maps found in the cd415.xml are

Code:

<rom base="A2L">
    <romid>
   <xmlid>CD415</xmlid>
   <hwid>2WLM1D13</hwid>
      <internalidaddress>8163</internalidaddress>
      <internalidstring>CD415</internalidstring>
      <ecuid>CD415</ecuid>
      <year>03</year>
      <market>JDM</market>
      <make>Nissan</make>
      <model>350Z</model>
      <submodel>??</submodel>
      <transmission>AT</transmission>
      <memmodel>SH7055</memmodel>
      <flashmethod>nisprog</flashmethod>
      <filesize>512kb</filesize>
    </romid>


   \\Values, Tables, and Maps w/o Axes//
   <table name="K-Value" storageaddress="0x6428" />

   <table name="Target Idle Table" storageaddress="0x8993" />
   <table name="MAF Table" storageaddress="0x913e" />
   <table name="Engine Torque Map" storageaddress="0x7DF4"/>

   <table name="Bosch Fuel Cut Table" storageaddress="0x8957"/>
   <table name="JECS Fuel Cut Table" storageaddress="0x897B"/>
   <table name="TCS Fuel Cut Prohibition Speed Table" storageaddress="0x8D59" />

   <table name="Speed Limiter" storageaddress="0x64E8" />
   <table name="mVSPCT2 Speed Limiter (cut)" storageaddress="0x621A"/>
   <table name="mVSPRC2 Speed Limiter (restore)" storageaddress="0x6224"/>

   <table name="Rev Limit (Fuel Cut - 3D)" storageaddress="0x6486" />
   <table name="No Load Rev Limit (Fuel Cut)" storageaddress="0x648a" />


   \\Maps and Tables w/ Axes//
    <table name="Cold Ignition Timing Map (16x16)" storageaddress="0x6749">
      <table type="X Axis" storageaddress="0x8437" />
      <table type="Y Axis" storageaddress="0x8447" />
    </table>
    <table name="High Octane Ignition Timing Map (16x16)" storageaddress="0x6849">
      <table type="X Axis" storageaddress="0x8437" />
      <table type="Y Axis" storageaddress="0x8447" />
    </table>
    <table name="High Detonation Ignition Timing Map (16x16)" storageaddress="0x6949">
      <table type="X Axis" storageaddress="0x8437" />
      <table type="Y Axis" storageaddress="0x8447" />
    </table>

    <table name="Fuel Compensation Map (16x16)" storageaddress="0x6c09">
      <table type="X Axis" storageaddress="0x836D" />
      <table type="Y Axis" storageaddress="0x8437" />
    </table>

    <table name="Target AFR Map (8x8)" storageaddress="0x6E19">
      <table type="X Axis" storageaddress="0x81C0" />
      <table type="Y Axis" storageaddress="0x8309" />
    </table>

   <table name="Intake Cam Timing Map (16x16)" storageaddress="0x6F99">
      <table type="X Axis" storageaddress="0x8DF5" />
      <table type="Y Axis" storageaddress="0x8E05" />
   </table>

   <table name="QH0/ Torque Conversion Map" storageaddress="0x7974">
      <table type="Y Axis" storageaddress="0xA2CC" />
      <table type="X Axis" storageaddress="0xA35C" />
   </table>

   <table name="QH0/ Torque Conversion Map 2" storageaddress="0xA088">
      <table type="Y Axis" storageaddress="0xA2CC" />
      <table type="X Axis" storageaddress="0xA35C" />
   </table>


   \\Flags//


   \\DTCs//


   \\Supmasks//


   <checksum type="std" start="0" end="0x7FFFF" sumloc="0x6640" xorloc="0x6638" />
</rom>

Initial Z · **Joined:** Thu May 20, 2021 3:15 pm **Posts:** 42

I may have found an error on the available CD415 definition. Fuel compensation Map Y-axis is defined as 0x8437 but in Ghidra, 0x8311 is loaded into r5 just before the actual map is loaded into r4. The raw axis values and length are the same at both addresses, so it's worked so far, but it was still neat to notice that. If I'm correct, that is. :lol:

bradsm87 · **Joined:** Thu Apr 14, 2011 8:16 am **Posts:** 425

I'm quite stuck with mine. Larger maps have always been easy to find without disassembly. Finding the axes to suit is now fairly easy with very basic disassembly from what I've learnt slowly over time. Most single value items are not too bad to find due to things generally being in the same order as the Renault A2L. Some things however just don't seem to be there. All of the loose candidates based on layout in the ROM just don't seem to check out when comparing against the A2l ROM in Ghidra (with very very limited disassembly knowledge I might add).

I'm just not sure where to go from here to confirm what I suspect is mTEMIN, confirm a rough suspicion of mQUNIT as well as find mQAOOFST and mMKINJM for which I have no candidate addresses. I'm getting pretty desperate to find these for VC264. I've spend many hours looking.

Pytrex · **Posted:** Thu May 27, 2021 8:01 pm

Initial Z wrote:

I may have found an error on the available CD415 definition. Fuel compensation Map Y-axis is defined as 0x8437 but in Ghidra, 0x8311 is loaded into r5 just before the actual map is loaded into r4. The raw axis values and length are the same at both addresses, so it's worked so far, but it was still neat to notice that. If I'm correct, that is. :lol:

If I remember correctly, I believe I found the same thing to be true.

Bradsm87 wrote:

I'm just not sure where to go from here to confirm what I suspect is mTEMIN, confirm a rough suspicion of mQUNIT as well as find mQAOOFST and mMKINJM for which I have no candidate addresses. I'm getting pretty desperate to find these for VC264. I've spend many hours looking.

You're really gonna have to grab an instruction set and start getting deeper into ROM disassembly. It's really the only way. I'd be nowhere close to where I am today if it wasn't for taking the time and learning how to disassemble SH705X. There just aren't any shortcuts available. UpRev doesn't really have much public information on functionality nor have they had much time to spend on some of the more interesting things. Say, Ignition timing functionality haha You can checkout Nissan's patents, but there are a multitude of maps/tables/values that aren't found in ANY public Nissan patent. On top of this, the logic isn't fully explained all the time and it'll be missing critical information (check their ETC patent, which is missing a crap ton of actual ETC functionality that takes place within the ECU)

Initial Z · **Joined:** Thu May 20, 2021 3:15 pm **Posts:** 42

Well I'll be. Datacable arrived today and not only did I not brick my ECU, I managed to finally fix my high idle after three years! First set the target to 800, which the calibration could reach and it stuck. Adjusted it down to 750 and the car reached it without calibration.
Speed limiter is now also set to 155 mph instead of the default 112 mph.

Pytrex · **Posted:** Wed Jun 02, 2021 11:18 pm

Initial Z wrote:

I managed to finally fix my high idle after three years! First set the target to 800, which the calibration could reach and it stuck. Adjusted it down to 750 and the car reached it without calibration.

Errr, not sure if that could necessarily be considered a fix. I would assume you have a vacuum leak given the vehicle's failure to idle at +/- 50 RPM from 650 RPM. So by raising the idle, you're just decreasing the vacuum enough so that the ECU is able to overcome the unmetered air. I'd recommend trying to find said vacuum leak (IF there is one) and seeing if you can then get it to idle smoothly at 650 RPM.

Initial Z · **Joined:** Thu May 20, 2021 3:15 pm **Posts:** 42

I've gone through the engine plenty in three years, looking for a vacuum leak with starting spray and have been unable to find any. My fuel trims are not indicative of an air leak either. LTFTs are dead on at 100 % and STFTs are hovering around 99-105 % at idle and do not drop when slowly raising the rpms. If there was a leak, my understanding is that it would show up as high STFT in idle, which slowly transfers to LTFT when the car adjusts the trims, and then when you raise the rpms, essentially making the vacuum leak's contribution to total air smaller, the STFTs will drop and the car will then correct LTFT given enough time for adjustment.

It all started after cleaning the throttle body when converting the car to flexfuel. The internet is chock full of VQs with high and erratic idle problems after either cleaning or touching the throttle body while taking the intake apart and the fixes are equally diverse, ranging from disconnecting the battery to changing out the ECU. I have a friend who got the exact same issue on his HR after cleaning his throttle bodies and was unable to successfully complete idle air volume relearn until he flashed a newer, compatible ROM with upRev to his car. Symptoms were identical to mine and no air leak with him either.

I only raised the idle target to 800 rpm so the calibration completed successfully, and have since dropped it to 700 rpm, which the ecu could reach without any issues or the need to do the relearn again. It idles smoothly and the annoying hickup at the on/off threshold of throttle input at light loads is gone. During the faulty calibration it would never drop to those rpms.

It would actually be interesting to look for the idle air volume relearn routines in the disassembly and see how it's actually coded, because I have a strong suspicion that code either has a bug or overly tight limits for the adjustment due to how fragile the throttle body calibration is. Another thing about it that made me tear my hair out, was that it would completely disregard a calibration attempt that was not in spec, even if the new idle was much closer to actual target than the starting point. With mine, it would idle at 933 rpm, throwing no DTCs and calibration would only bring it to a hair under 800 rpm, something like 780 rpm if I remember right. IMO it would've made more sense to accept a closer result to target and throw high idle DTC, instead of returning back to a higher idle and throwing no codes.

bradsm87 · **Joined:** Thu Apr 14, 2011 8:16 am **Posts:** 425

Initial Z wrote:

It would actually be interesting to look for the idle air volume relearn routines in the disassembly and see how it's actually coded, because I have a strong suspicion that code either has a bug or overly tight limits for the adjustment due to how fragile the throttle body calibration is. Another thing about it that made me tear my hair out, was that it would completely disregard a calibration attempt that was not in spec, even if the new idle was much closer to actual target than the starting point. With mine, it would idle at 933 rpm, throwing no DTCs and calibration would only bring it to a hair under 800 rpm, something like 780 rpm if I remember right. IMO it would've made more sense to accept a closer result to target and throw high idle DTC, instead of returning back to a higher idle and throwing no codes.

I need to find out more about the idle air relearn process and limits too. Many TB48 owners can never get an idle air relearn to complete and they're stuck with a bad idle or 0 timing at idle. I suspect they just need some limits loosened a bit.

Initial Z · **Joined:** Thu May 20, 2021 3:15 pm **Posts:** 42

Hi

I wonder if someone more knowledgeable would be able to confirm whether 0x5f98 is the electronic throttle control flags for CD415, as I suspect they are

RomRaider

Forum rules

ROM disassembly questions

Who is online