[Sergio828]

I know very little about coding but I'm finding this thread fascinating to follow. Based on my experience with tuners, I've found very little appetite to fix lingering issues or provide much, if any, support for this platform. I'm running an emissions on tune currently, and while it is OK, there are some areas for improvement.

Thanks for detailing your adventure, will be watching!

 

[NavyCuda]

Last few days have been hectic. Today I managed to put in a couple hours since the last time I posted.

Mapping the winols to ecmParameter first has proven to be hugely beneficial. In two hours I'm close to halfway ready to start testing my converter. Being able to see how the data is supposed to flow really makes it easier to write the methods. I'm rather disappointed in myself I didn't do it sooner.

I'm hoping to get a few hours in tomorrow, ideally get to the point of testing the map converter and if successful I can go back to applying a complete configuration against the calibration.

I'm sure I've covered it before but a quick recap:

A Calibration is the file that contains the data that will physically be installed to the engine computer. A Configuration is a file that contains the details about each of the parameters stored in the table of contents. The table of contents is an area of the calibration that lists all of the engine parameters.

The engine parameters are stored in the ecm as a binary, the calibration stores the binary as hexadecimal, the configuration provides the name, description and correct conversions for the datatype that parameter represents.

 

[NavyCuda]

I didn't need my sanity, right?! he. hehehe.

So, I wrote a whole bunch of code and to my surprise it only had a couple minor bugs but otherwise worked as intended. The problems associated with mismatched calibrations and maps are starting to show their ugly head again. So far I have been able to extract over half of the x-axis itns from the y axis and verify them with the table of contents. However, because some things are in slightly different places, not all of the offset math works.

In the configuration file a y-axis is a single dimensional table that has an associcated x-axis of the same element count that is used as the header. ie:

rpm  :    0 |   600 |  1000 |  <- x axis
mm^3 :  0.1 |   1.1 |   1.7 |  <- y axis

It does very much appear as though the WinOLS map pack I have was generated from a genuine Cummins configuration for the ISV. However, because winols stores a direct reference to the address of the y-axis parameter, that map is tied to the bin it was made for. This means that winols strips away the id number for that parameter. It also means their file is storing that parameter multiple times.

Since I do know the itn number of the Y axis, that means I have the absolute address for where that parameter is stored in the xcal. WinOLS uses a different addressing method, so I have to take their address for the y axis, then subtract the address for the x axis to find the offset. Then I go back to my table of contents and search for an itn that starts at that address. If I find one and the byte count matches, assign the parameter to that itn.

One of the parameters I looked at, the table was supposed to start 84 bytes before the data, and on that bin, that's the right answer. On my xcal however, it's a few hundred bytes away...

I'll get there.

 

[NavyCuda]

I have been so busy with life and school work, it's pained me that it's been so long since the last update.

So shortly after my last update I basically hit a brick wall. I needed the correct calibration to go with the map pack I'm using so that I can get all of the itns lined up correctly. I looked into getting it, but the way nissan names the .xcals is different than how cummins does it, so I couldn't match the filenames that way. I can't afford to buy every xcal for every ecm part number. This stumbling block plagued me.

Finally Rawze thumped it into my head to just use the bin that came with the mappack, it has the itn table of contents in it, all I need to do is use that table of contents. So I did just that. I still have a fair amount more code to go, but now I'm pulling out Y and X axis data successfully. More importantly I'm getting all the itn numbers which will make it a snap to apply to the correct xcal.

To visualise where I am, I'm at the point in the tunnel where there isn't just light at the end of the tunnel, the exit is getting bigger. I have so much competing for my time, and I have so many more hours of coding to go before I can document the engine... back at it for as long as I can!

 

[NavyCuda]

I've learned some interesting things trying to map the last few hundred parameters...

What I thought was the ecm part number is actually the part number of the calibration. It does not appear as though the ecm itself was ever changed. Another, very interesting thing... the binary in the winOLS map pack and the binary that I know works, they are the same part number. The binary in the winols map pack was extracted from a truck and came with all the fault tables, injector calibrations, etc. The binary in WinOLS and the binary that works are also assembled slightly differently.

I'm guessing here, but this must have to do with either instructions or flags in the binary to signal the end of a block.

Think of the ecm like the industrial area of your town. A block of addresses might be where all the lumber is stored, another block is where all the steel is stored, another where the machine shops are. Well the memory of the ecm is like that too, the parameters and program are stored in blocks. When the ecm is flashed, the tool must install the xcal or the binary to the correct addresses or the ecm will not work. In terms of binarys, I don't understand how these blocks are identified. In the oem calibrations, due to the way intel hex files are written, the block addresses are clear as daylight.

In our trucks there are four address blocks. One really big one that contains the vast majority of the parameters and three smaller ones. The last few hundred itns are in the last block. In winols, and its map pack the addresses are applied to the bytes sequentially starting from 0x00 (0). With intel hex, all the bytes are broken down into records. The record contains its starting address, the number of bytes in that record, the type of record it is and the checksum for that record. This means that the with an intelhex file, the physical address that byte is going to occupy in the microcontroller is specified. The calibration starts at 0x80020000 (2147614720), so that offset is easy. Add the starting offset to the address and you have the correct location. However, the block I'm working in has a different starting address, but there is an unknown number of extra bytes included that tells... something.... something... and I haven't got a clue what they are, what they do... thus my guess at their purpose. This means that even with the correct starting address for that block, there is an additional shift of bytes I haven't figured out how to calculate yet.

I'm thinking these last few hundred will be easier to figure out manually than to try and program something to find the offsets.

School goes to full speed tomorrow and I'll be lucky to get an hour or two a week on this project for the next three months. I'll keep you updated!

 

[Bikerndiver]

This is one of the bedt posts on this forum for sure. Im happy to see someone dig into the truck like this. Keep updating as you can!

 

[NavyCuda]

So I've been trying to find an original xcal (23701EZ45C.XCAL) in the few minutes of spare time I've had. Which isn't much sadly. I haven't been able to find the xcal but I have figured out how to convert the one good binary I have into an xcal. I've started on a binary to xcal converter but my school work is taking up too much of my time and I just can't do anything with it. I wanted to work on it this weekend... but yesterday was all house/family stuff... today is catching up with homework then back to school tomorrow.

Not getting time to work on my big blue turbo diesel makes me sad!

 

[rickk33]

Just read through this entire thread and I am very impressed in your perseverance and drive to self teach yourself this stuff. Regardless of how it turns out well done!

 

[NavyCuda]

So many ideas... no time. School is going decently. only another 10 weeks to go!

I'm almost completely sure this will be a web app when it's complete and offer the ability to document the engine, edit all the parameters and produce a valid xcal or bin. Given how all the cummins engines do the same thing... I'll get our trucks working first then I might attempt expanding out into the dodge rams.