Problem with MAF definition...

Cougar5.0 · Post by **Cougar5.0** » Sun Jan 22, 2006 7:56 am

The A9L.xdf definition file has the Y axis "output type" set up as "integer" - it should be "floating point". If the drop-down is changed to "floating point" the bin will load into CalEdit fine with just the usual round-off/conversion errors (that weren't so bad), otherwise CalEdit will not load the file.

Post by **dex** » Sun Jan 22, 2006 12:43 pm

Sorted in the latest update, to be posted very soon, along with a general tidying up that I hope is going the right way for everyone. Keep the comments coming.

Post by **dex** » Mon Jan 23, 2006 12:10 pm

Updated xdf now in the download section

Cougar5.0 · Post by **Cougar5.0** » Sat Jan 28, 2006 8:56 am

dex wrote:Updated xdf now in the download section

How come all the calculated values are nonsense now? Is it because of the note on "padding" the file? I don't know how to do this.

OK, I stuck a "base offset" of -2000 and it seems to be in alignment again...

Was that the correct thing to do - please explain this "offset"

Post by **dex** » Sat Jan 28, 2006 10:16 am

Cougar5.0 wrote:How come all the calculated values are nonsense now? Is it because of the note on "padding" the file?

Yes.

Cougar5.0 wrote:I don't know how to do this.

I use a hex editor (in this case HHD Software's) which has an 'insert' tool that allows you to insert blocks of data (with the same value) into binary files.

Cougar5.0 wrote:Was that the correct thing to do - please explain this "offset"

Putting in the offset is fine, this is what it's meant for

The 'offset' value is added or subtracted from the xdf item's address to compensate for binary files that start at a different address to the rom address in the ecu. My files aren't set up like this because of problems with the checksum calculation in earlier versions of TunerPro (it also simplifies chip burning because you don't have to remember to set an offset into the programmer).

Cougar5.0 · Post by **Cougar5.0** » Sat Jan 28, 2006 10:40 am

dex wrote:
Cougar5.0 wrote:How come all the calculated values are nonsense now? Is it because of the note on "padding" the file?
Yes.

Cougar5.0 wrote:I don't know how to do this.
I use a hex editor (in this case HHD Software's) which has an 'insert' tool that allows you to insert blocks of data (with the same value) into binary files.

Cougar5.0 wrote:Was that the correct thing to do - please explain this "offset"
Putting in the offset is fine, this is what it's meant for The 'offset' value is added or subtracted from the xdf item's address to compensate for binary files that start at a different address to the rom address in the ecu. My files aren't set up like this because of problems with the checksum calculation in earlier versions of TunerPro (it also simplifies chip burning because you don't have to remember to set an offset into the programmer).

Thanks for the reply - kinda makes sense now. I don't suppose you know how us Tweecer users can convert the damned ccf files it creates back to a bin format so that I can recreate my tune in TunerPro? I can cut and paste tables and I figured out how to paste in the MAF by extracting it from another program (EEC Analyzer), but I'm still left with manually editing all the other functions and scalars by hand - which, of course, is prone to errors. Any ideas on this?

Post by **dex** » Sat Jan 28, 2006 11:07 am

Sorry, I don't know how to convert ccf to bin files. On the Quiksnake forum thread 'New Binary Editor', Dale McPeters says he can but he doesn't elaborate on how.

Cougar5.0 · Post by **Cougar5.0** » Sat Jan 28, 2006 11:09 am

dex wrote:Sorry, I don't know how to convert ccf to bin files. On the Quiksnake forum thread 'New Binary Editor', Dale McPeters says he can but he doesn't elaborate on how.

He like to tell us he can do all sorts of things

Wish he would tell us all

Post by **Mangus** » Sun Jan 29, 2006 6:11 pm

If you guys figure out the magic potion needed to convert the files, let me know and I'll integrate the conversion into TunerPro.

Cougar5.0 · Post by **Cougar5.0** » Sat Feb 04, 2006 10:14 am

Mangus wrote:If you guys figure out the magic potion needed to convert the files, let me know and I'll integrate the conversion into TunerPro.

I'm wish I had the time to study the files & try to figure out how they are put together - it would be very convienient.

BTW, any progress on the issue I was having last week?

Post by **Mangus** » Sat Feb 04, 2006 9:18 pm

Which one? Item Finder/Item Difference? If so, yes, it's fixed in the next release (out tomorrow, probably).

Cougar5.0 · Post by **Cougar5.0** » Sun Feb 05, 2006 6:21 am

Mangus wrote:Which one? Item Finder/Item Difference? If so, yes, it's fixed in the next release (out tomorrow, probably).

I would call the problem "wrong addresses filled when certain 16 bit function X and/or Y axis points are filled"

The "Item Difference" tool was correctly pointing out that the wrong addresses were being filled. I verified this using a different binary editor immidiately after filling a certain cell using your "Edit Item Bin", saving, then opening the binary in another editor. I hope this is what you are fixing. Addresses completely unrelated to the function being edited were being written to. Other editors don't write to these addresses so I assume it's not correct. I also had my ECU corrupted using bins from TunerPro where I had changed these Functions, but not when I only changed Scalars or other functions that seem to write correctly.

If you want to see the issue, simply open the "MAF Transfer" function in the A9L definition & change Y-axis point 30 from "16" to "10" - you will see that 4 bytes will be written to (6DE2, 6DE3, 0000, 0001)! It's also true that the addresses it's writing to are incorrectly identified with other functions - so maybe it's all related.

Post by **dex** » Sun Feb 05, 2006 8:13 am

Sounds like we're back to the bin size/offset problem again. From the posts above, you are not using a 64k bin and are using the offset function (set to 0x2000, subtracted) to get around this. I have tried to reproduce this error by trimming my bin to 56k and using the offset and I didn't get a problem. It seems odd that TunerPro is reading the correct address but writing to an address some 0x2000 less. Have you tried the latest xdf from this site (latest version uploaded yesterday)?

Cougar5.0 · Post by **Cougar5.0** » Sun Feb 05, 2006 9:05 am

dex wrote:Sounds like we're back to the bin size/offset problem again. From the posts above, you are not using a 64k bin and are using the offset function (set to 0x2000, subtracted) to get around this. I have tried to reproduce this error by trimming my bin to 56k and using the offset and I didn't get a problem. It seems odd that TunerPro is reading the correct address but writing to an address some 0x2000 less. Have you tried the latest xdf from this site (latest version uploaded yesterday)?

I will try the latest xdf, but as I stated on another site, I have used your xdf with the offset and others that don't require it (from Clint) and both definitions write in the same incorrect way.

Based on previous bug fixes listed on this site, it seems that there is still an issue with certain functions. I may be wrong, but there is a problem of some sort that needs fixing as my ECU can attest too

I'm your beta site

EDIT:

MAF Transfer is still doing it, BAP Transfer is also. Injector Timing table works fine. EGR multiplier for ECT wrote to two bytes though.

Post by **dex** » Sun Feb 05, 2006 12:01 pm

Let us know how you get on. It sounds like this may be problem that Mangus is best qualified to look into, what OS and version of TunerPro are you using?

Cougar5.0 · Post by **Cougar5.0** » Sun Feb 05, 2006 2:33 pm

dex wrote:Let us know how you get on. It sounds like this may be problem that Mangus is best qualified to look into, what OS and version of TunerPro are you using?

Well, as I said in the PM, I have been able to get datalogging working again and I was able to see the result of writing to the scalar TTNOV in TunerPro, so the potential is there

I had timing pull to as low as 0 degrees during take-off! So at least I can do that until this issue with functions is resolved.

I'm using XP on my desktop, Win2k on my laptop - same issue on either machine.

TunerPro is 4.13.0183 - only version I know of that writes Ford binaries

Post by **Mangus** » Sun Feb 05, 2006 7:23 pm

Cougar5.0 wrote:
Mangus wrote:Which one? Item Finder/Item Difference? If so, yes, it's fixed in the next release (out tomorrow, probably).
If you want to see the issue, simply open the "MAF Transfer" function in the A9L definition & change Y-axis point 30 from "16" to "10" - you will see that 4 bytes will be written to (6DE2, 6DE3, 0000, 0001)! It's also true that the addresses it's writing to are incorrectly identified with other functions - so maybe it's all related.

Ah, yes. Also fixed in the next release. Good find!