Moderators: EDS50, cgrey8, 2Shaker, Jon 94GT
GUFB System-Checksum Base Address
The default integer value for rom1 in the GUFB/A9L is 8192 but according to the pid description it states to set to 0. Should this truly be set to 0 and if so why is 0 not the default value?
1992 Mustang LX - 25.1c Chassis, Vortech Blown Dart 333 on Meth, Lentech Trans, TRZ Backhalf, A9P Tune, Moates QH/SL v1.9, BE, EA, TunerView
2003 Mach 1 - CoreTuning RYAK1/ZYA2 QH Tuned, Borla Atak Cat Back, Long Tubes/Off Road X-Pipe, Twin 65mm TB, JLT CAI, ICT Billet Intake Spacer, BMR Tubular K-Member and A-arms, Maximum Motorsports coil overs with Bilstein Suspension, Steeda Adj. Rear Upper/Lower Control Arms, QA1 Bump Steer, Steeda Short Throw Shifter, WOT Box, 315/35/17's.
2003 Mach 1 - CoreTuning RYAK1/ZYA2 QH Tuned, Borla Atak Cat Back, Long Tubes/Off Road X-Pipe, Twin 65mm TB, JLT CAI, ICT Billet Intake Spacer, BMR Tubular K-Member and A-arms, Maximum Motorsports coil overs with Bilstein Suspension, Steeda Adj. Rear Upper/Lower Control Arms, QA1 Bump Steer, Steeda Short Throw Shifter, WOT Box, 315/35/17's.
Re: GUFB System-Checksum Base Address
It's not a genuine parameter, it was introduced as a hack to get around the rom checksum routine in s/w that doesn't recalculate the checksum when parameters are changed. Do not change it if the s/w you use calculates the checksum.
Re: GUFB System-Checksum Base Address
So for others that may stumble upon this in the future QH/Tweecer Users with Binary Editor should leave this set as is.
1992 Mustang LX - 25.1c Chassis, Vortech Blown Dart 333 on Meth, Lentech Trans, TRZ Backhalf, A9P Tune, Moates QH/SL v1.9, BE, EA, TunerView
2003 Mach 1 - CoreTuning RYAK1/ZYA2 QH Tuned, Borla Atak Cat Back, Long Tubes/Off Road X-Pipe, Twin 65mm TB, JLT CAI, ICT Billet Intake Spacer, BMR Tubular K-Member and A-arms, Maximum Motorsports coil overs with Bilstein Suspension, Steeda Adj. Rear Upper/Lower Control Arms, QA1 Bump Steer, Steeda Short Throw Shifter, WOT Box, 315/35/17's.
2003 Mach 1 - CoreTuning RYAK1/ZYA2 QH Tuned, Borla Atak Cat Back, Long Tubes/Off Road X-Pipe, Twin 65mm TB, JLT CAI, ICT Billet Intake Spacer, BMR Tubular K-Member and A-arms, Maximum Motorsports coil overs with Bilstein Suspension, Steeda Adj. Rear Upper/Lower Control Arms, QA1 Bump Steer, Steeda Short Throw Shifter, WOT Box, 315/35/17's.
-
decipha
Re: GUFB System-Checksum Base Address
correct, if you have a strategy that the developer actually took the time to locate and calculate the checksum correctly then there is no need to disable it
SCT and many others use the 0 approach because they simply can not calculate a correct checksum due to the lack of having the full binary, they could have done it correctly on the eec-iv stuff but i guess since it was outdated at the time of their inception it just wasn't cost effective, the newer 2 bank and 4 bank ecu's checksum can not be calculated by most tuning software since their chips only contain partial bits of the calibration, they 'bypass' pats and other information which is served up from the stock eeprom, thats why you can get a mail order chip from diablo or SCT for example and not fail PATS
for example, its like only writing 2 banks on the chip instead of all 4 and just serving the other 2 from the stock calibration in the ecu, thats similar to how those chips function
SCT and many others use the 0 approach because they simply can not calculate a correct checksum due to the lack of having the full binary, they could have done it correctly on the eec-iv stuff but i guess since it was outdated at the time of their inception it just wasn't cost effective, the newer 2 bank and 4 bank ecu's checksum can not be calculated by most tuning software since their chips only contain partial bits of the calibration, they 'bypass' pats and other information which is served up from the stock eeprom, thats why you can get a mail order chip from diablo or SCT for example and not fail PATS
for example, its like only writing 2 banks on the chip instead of all 4 and just serving the other 2 from the stock calibration in the ecu, thats similar to how those chips function
-
86GT
- BE/EA Developer
- Posts: 5151
- Joined: Sat Feb 22, 2003 11:19 pm
- Location: Dixon, California
- Contact:
Re: GUFB System-Checksum Base Address
From what i have seen SCT and others do not calculate the checksum because they do not put the entire cal on a burnt chip. Maybe i should say not all of the time do they use the entire calibration. For example the Tweecer can be in "4 two bank" mode and only emulate bank 1 and 8 on a four bank processor. This saves space on the tweecer and thus they can not calculate the check sum because they do not have the other two banks of info. This is one of the main reasons i did not do this in BE. In BE you use the entire calibration, none of this using of 2 of the 4 banks stuff.
The Spanish oak stuff is totally different.
The Spanish oak stuff is totally different.
Re: GUFB System-Checksum Base Address
Yes it very common with SCT. Most guys running SCT will almost always be showing a DTC because of it. Usually 15 on our FoxBodys. Gives most the illusion that the ECM is loosing power or is toast.
89 Coupe- Canfield 195's, Holley Systemax II, CI cam, 24# Inj, 05 Slot MAF, 75mm TB
BBK 1 3/4 LT's, 3"Exhaust, 3"Spintech's, T-5 Trans, QH 1.4, AEM WB, BE/EA: A9L-GUFB
BBK 1 3/4 LT's, 3"Exhaust, 3"Spintech's, T-5 Trans, QH 1.4, AEM WB, BE/EA: A9L-GUFB
-
86GT
- BE/EA Developer
- Posts: 5151
- Joined: Sat Feb 22, 2003 11:19 pm
- Location: Dixon, California
- Contact:
Re: GUFB System-Checksum Base Address
liljoe07 wrote:Yes it very common with SCT. Most guys running SCT will almost always be showing a DTC because of it. Usually 15 on our FoxBodys. Gives most the illusion that the ECM is loosing power or is toast.
Very true code 15 is bad EEPROM, false indication but has no affect on operation.
Who is online
Users browsing this forum: No registered users and 49 guests