TunerPro User Forum

I do not know the code well enough so I am afraid I have no idea why an invalid checksum in the $8D did not throw a code or go into limp home mode. Hopefully some one else may know and will chime in.

When changing the 0x6F to 0x3F are you updating the bin checksum or setting the engineering mode checksum bypass?

I am guessing you mean L4008 not L0048. You may not be seeing any data because I have a feeling that when the SCSR register is read the bits are cleared. This is because in the $74 code I can see where the register is read but nothing is done with the data which is kind of typical for clearing a reg...

If you change the 0x6F to 0x3F and something makes a request for 16 bit data using the address range 0x4000 to 0x6FFF then it will be treated as a request for 8 bit data. I cannot say if this will or will not happen as I am not familiar with the $8D ecu and do not know what communications will be po...

appears to be 0x6C22 in hex editor while 0xEC22 in the .LST file -- is that the same address? Yes, if you are using a 32k bin file. Given the change is in the transmit interrupt handler and will only be temporary while doing the Mode 3 request for 0x4008, would it be correct that while the 6F/3F ch...

I have briefly looked at the $8D ANHT code and it is the same as the $74 code with any data between the addresses 0x3000 and 0x6FFF being treated as a 16 bit data request. You could therefore alter the byte at 0xEC1A (0xEC22 for the $8D AUJP) from 0x6F to 0x3F to limit word sized data requests to 0x...

How is the request checksum being handled? I ask because it's not shown in the examples you give.

I suspect the problem is that any address in the 0x4xxx range is getting treated as a call for a word of data (for example in the $74 code any data between the addresses 0x3000 and 0x6FFF is treated as a 16 bit data request). So instead of the SCI status register the ecu is giving you whatever data ...

Group the items into different "Item List Views", you can then use the drop down box in the "Item Lists" window to select which group you wish to see.

It may be this issue http://forum.tunerpro.net/viewtopic.php?t=2215

These are not three different methods but show data from three different address ranges. 1) The size of the data is not dictating the addresses, it just happens to be that in the examples you cited they are from different address ranges. 2) A bin file typically only is comprised of the data in the r...

Here are a couple of bin files:

358892

357896

There are loads of bin file on the site, do you mean you cannot find the one you want?

Try the http://www.gearhead-efi.com site.

Also, could you please turn off the 'caps lock' when typing

dfddfd2 wrote:That might be "Item List Tracking" on General tab of Preferences.

Correct, it is.

TunerPro will always read the bin size you set it to but if the J3 is not clean it will read garbage. In addition to the protective grease most J3 connectors are protected with a clean conformal coating.

If you cannot get a good read then the J3 connector may require cleaning.

No, it will not. There is no easy way that I'm aware of, I think a plug-in would need writing.

No idea, IIRC an example of the hardware code is SME-505.

EFIDynoTuning wrote:the eec 4s do not have a flash ram chip

Some of the later eec-iv's do have flash memory

In the Windows save file dialogue window you need to select 'All Files' in the 'Save as type' drop down box. Make sure you have '.xdf' after the file name.

Each of the 4 banks needs 0x2000 of null data inserting before it. Additionally, you need to insert 0x2000 of null data at the end of bank 1.

AFAIK there is no other datalogging capable hardware for use with TunerPro on Fords.

You need to use a hexadecimal editor (such a HDD Software's 'Hex Editor' v2.0) to insert null data before each of the 4 banks of code/data in your bin so that the banks start at 0x2000. It's good practice to fill the null data with values of 0xFF.

I can open any bin apart from one with only null data in it when there's no xdf loaded.

Maybe TP is being smart

I've just opened a 32k bin file full of null data without a problem so I don't think it's the null data that's the issue.

Have you tried a different xdf?

I'm saying the equation is X/20. Assuming the value at 0x851B is 0x1C and the update timer is incremented every 0.05 seconds then looking at it simplistically: If the timer is 1.35 secs (or less) then the carry is set and a jump occurs. If the timer is 1.40 secs then the carry is clear and no jump o...

Looking at that snippet of $8D disassembly the minimum time that must elapse before an update is permitted is X/20. My reasoning being is that the BCS jump occurs when the update timer < 1.4 seconds and doesn't occur when the update timer is >= 1.4 seconds.

I disagree that the incrementing of the timer causes a "+1" to come into play, it's the choice of the branch instruction that determines the equation. The timer increment just means that the timer has a minimum value of 0.05 secs before it is compared against the KBLMCNT value.

To determine the minimum time that must elapse before an update is permitted it is down to what branch instruction the code uses, the order of the values and what the code executed next does. For example: if BLMTMR <= KBLMCNT then 'clear learn control enable flag' the equation would be X/20 yet for ...

You would have to look at the code to see how often the BLM update timer is incremented. From what you've posted it would appear to be every 1/20 second. Therefore the minimum time that must elapse before an update is permitted is either X/20 or (X-1)/20 depending on the branch instruction used.

Use the 'Check Internet for Updates' from the 'Help' drop down menu to get build 5.0.8075.

The ELM327 will allow reading of OBD-II data and clearing of error codes but not any tuning.

For use with a Mac you'll need MAC OS specific s/w such as 'Movi'.

The Ostrich is only an emulator and does not facilitate the transfer of datalogging information back to a pc.

1 kPa = 0.2952999 in Hg

Probably best to search for a datasheet for the part number you are using. For example the 12247571 two bar map sensor gives this for its transfer: At 25 deg C and 5.1 v supply the output is: 20 kPa = 0.199 v to 0.413 v 40 kPa = 0.755 v to 0.877 v 160 kPa = 3.815 v to 3.937 v 200 kPa = 4.814 v to 4....

Have you looked at the TunerPro help files? Everything you need is in there for what most people put into an xdf.

Not sure what type of ecu yours is but if it's a P4 type then you can use an adapter like this to read the eprom http://www.moates.net/hdr1-memcal-header.html

Out of curiosity, are people seeing this issue with ALDL -> USB or ALDL -> RS232 cables?

I'm getting glitches (no luck with using a variety of delays and the packet size is correct) with a ALDL -> USB cable and was wondering if it relates to the use of a virtual com port.

I'm sure it's possible, google "MR2" and "JMR_AW11" for ecu info by a guy who has delved extensively into the 16v ecu. I expect the 20v is very similar.

It is under the 'Properties' setting for the device in the Windows 'Device Manager'.

I'm not sure if the same applies to TunerPro but on another piece of tuning software you typically have to set the USB latency timer to 2 for Windows Vista, and Windows 7 and to 16 on Windows XP for the QH.

Have you tried this website http://www.fenixecu.com/

http://forum.tunerpro.net/viewtopic.php?t=530

The RS uses the KQTH7 strategy which is, AFAIK, only used by the Focus RS. No other 2.0l zetec definition will be of use.

I'm not aware of any definition available for this ecu.

Can you not add the checksum as an ADX item and log it with the other parameters?

You need to disassemble it, Bill Lawrence's disassembler can be found here http://autos.groups.yahoo.com/group/EEC ... r%20tools/

It looks like the ecu is from a diesel, strategy VHAE9.

To create a xdf you need to disassemble the code to figure out where (and what!) the parameters are. Once you have done that you can create your definition, see the TunerPro help section 'Editing Bin Definitions' on how to do this.

Use 'Save Link As...' in Firefox.

Increment and decrement are in there.

Search found 614 matches