Title: 8d0907551A defn file Post by: spen on September 26, 2010, 04:30:43 PM Hi, I've been requested to pull out some A box info. I downloaded the A rom and ran it through my analysis executables.
As usual this is machine generated, and should be examined before being relied upon. NB maps / tables sometimes have axis data points immeadiately before the map data. In these cases my offset will start with the axis data. I've started to work on this problem and if any data exists in the 'offset due to axis' column then I have worked though it and given the start of data in the column named "first data byte". CSV file attached at the bottom. KFWKSTT(t) 0x815167 Weighting map for cold start factor (KFWKSTT) 0x81517b 20 TTEGA(c) 0x81c386 Tank_ventilation_time_for_basic_adaption_TTEGA 0x81c386 0 CWFA195A(c) 0x81ca56 Supplemental_codeword__short_strip_reqs_display_group_195_CWFA195A 0x81ca56 0 ELDOB(c) 0x819780 Regulation_deviation_threshold_for_starting_LDR_overboost_active_timer_ELDOB 0x819780 0 FNSA_0_A(t) 0x8144da Afterstart enrich (FNSA_0_A) 0x8144da 0 NMAXOG(c) 0x81f4f2 Raised_rpm_limit_NMAXOG 0x81f4f2 0 RPM(l) 0xf876 RPM 0xf876 0 IAT(h) 0x0 Intake Air Temp 0x0 0 IGN_TIMING(l) 0xf9f6 Ignition Timing 0xf9f6 0 REQ_BOOST(h) 0x38210c Requested Boost 0x38210c 0 ACTUAL_BOOST(h) 0x38210c ACTUAL Boost 0x38210c 0 ACTUAL_EGT_B1(h) 0x3823b4 Bank1 EGT 0x3823b4 0 ACTUAL_EGT_B2(h) 0x3814f0 Bank2 EGT 0x3814f0 0 N75_OUTPUT(h) 0x380c62 N75 Output 0x380c62 0 DTC_TABLE(c) 0x814914 DTC ENABLE BYTES 0x814914 0 SLOGIN(c) 0x812120 SLOGIN (SOME ROMS HAVE DIRECT PASSWORDS) 0x812120 0 KLOGIN(c) 0x81211e KLOGIN (SOME ROMS HAVE DIRECT PASSWORDS) 0x81211e 0 KFMSNWDK(t) 0x811196 Table:Normalized mass flow over DK (KFMSNWDK) 0x8111c6 48 KFPBRKNW(t) 0x81b976 Correction factor for combustion chamber pressure at NWS active (KFPBRKNW) 0x81b9a2 44 KFPBRK(t) 0x81b882 Correction factor for combustion chamber pressure (KFPBRK) 0x81b8ae 44 KFMIRL(t) 0x81194e Table: target load KFMIRL 0x81198a 60 KFWPFGR(t) 0x81b510 Inverse pedal map for cruise control (KFWPFGR) 0x81b54c 60 KFPRG(t) 0x81ba6a Internal exhaust partial pressure dependent on cam adjustment when sumode=0 (KFPRG) 0x81ba8e 36 KFURL(t) 0x81bb06 Conversion constant for ps->rl dependent on cam adjustment when sumode=0 (KFURL) 0x81bb2a 36 KFMLDMN(t) 0x81b71e Threshold for B_minflr diagnosis HFM/HLM (KFMLDMN) 0x81b742 36 KFMLDMX(t) 0x81b7c2 Threshold for B_maxflr diagnosis HFM/HLM (KFMLDMX) 0x81b7e6 36 NLLM(t) 0x8198e6 Desired idle speed (NLLM) 0x81990a 36 KFWDKSMX(t) 0x0 max_throttle_angle_KFWDKSMX 0x1e 30 KFKHFM(t) 0x814eda MAF_correction_table_KFKHFM 0x814ef8 30 KFLF(t) 0x818a23 Lambda map at partial load (KFLF) 0x818a41 30 KFWDKPP(t) 0x814c4e Default throttle plate angle from charge signal (KFWDKPP) 0x814c68 26 KFNWWL(t) 0x81896a Map for variable cam timing during warmup KFNWWL 0x818980 22 KFNW(t) 0x8188f4 Map for variable cam timing KFNW 0x81890a 22 LALIUSH(t) 0x8135a4 Table: Lambda linearization; sensor behind cat (LALIUSH) 0x8135ba 22 KFTSRL(t) 0x81a2d4 closing time (from load; RPM) (KFTSRL) 0x81a2e9 21 KFFWTBR(t) 0x81881e Weighting factor Tans/Tmot for combustion temperature model KFFWTBR 0x818832 20 KFVPDKLD(t) 0x8197d3 Maximum permissible pressure ratio DK for ldra diagnosis? (KFVPDKLD) 0x8197e5 18 KFLDRAPP(t) 0x8196fc Map for LDR application without Md-coordination (KFLDRAPP) 0x81970e 18 KFDLULS(t) 0x819781 Delta pressure for overboost protection diagnosis (KFDLULS) 0x819793 18 KFSZT(t) 0x81a282 closing time (from RPM; V) (KFSZT) 0x81a294 18 FWFTBRTA(t) 0x818801 Weight of ftbr dependent on IAT (FWFTBRTA) 0x818810 15 FPVMXN2(t) 0x81b868 Factor for maximum pressure ratio with auxilliary load signal (FPVMXN2) 0x81b876 14 KFLDRXO(t) 0x819642 Delta load (rl) under overboost condition (KFLDRXO) 0x819650 14 WDKPMXN(t) 0x814d13 Maximum throttle plate angle for plausibility with load signal (WDKPMXN) 0x814d20 13 VMAXTOL(t) 0x0 VMAX because of oil temperature (later code only)(VMAXTOL) 0xc 12 RLLRTMO(t) 0x819dfe Characteristic curve for tmot; upper rL control limit for controller before Kat (RLLRTMO) 0x819e07 9 KFZWMN(t) 0x8136ea Table: Minimum ignition angle KFZWMN 0x8136ea 0 FKSTT_1_A(t) 0x811d6a Cold start enrichment factor (FKSTT_1_A) NON STANDARD ACCESS, MANUAL DECODE REQUIRED 0x811d6a 0 DPBKVEVKEP(c) 0x0 Pressure_grad_factor_during_evac_of_the_brake_booster_via_electrical_pump_DPBKVEVKEP 0x0 0 LAMFA(t) 0x81c05c Lambda - driver desired LAMBDA 0x81c05c 0 WPEDKO(t) 0x816170 Pedal angle threshhold for compressor shutoff 0x816170 0 DLBTS(t) 0x81c13f delta lambda for component protection DLBTS 0x81c13f 0 KFNFSKHM(t) 0x81c330 Desired idle engine speed while cat heating with drive engaged KFNFSKHM 0x81c330 0 KFDYES(t) 0x0 Dynamic load detection threshold (KFDYES) 0x0 0 FQTEFR(t) 0x81e801 Characteristic curve for continuous limit value control (fr) (FQTEFR) 0x81e801 0 FRLFSDP(t) 0x81bfb8 Injection correction during RLFS (FRLFSDP) 0x81bfb8 0 KFTARX(t) 0x81d790 Maximum specified load IAT correction factor map (KFTARX) 0x81d790 0 NMAXDVG(t) 0x817038 Maximum engine speed on speed signal error detection (automatic transmission)? (NMAXDVG) 0x817038 0 KFFWLLDE(t) 0x81d710 Weighting factor for slow boost pressure intervention on rlmax via KR (KFFWLLDE) 0x81d710 0 KFFSLDE(t) 0x81d690 Factor for rapid LDR intervention (reduction) (KFFSLDE) 0x81d690 0 KFFLLDE(t) 0x81d610 Factor for slow LDR intervention on rlmax via KR (KFFLLDE) 0x81d610 0 KFFLDEO(t) 0x81d590 Factor for boost pressure intervention through KR (KFFLDEO) 0x81d590 0 LDRQ1ST(t) 0x81d558 LDR-control parameter Q1 in stationary operation (integration coefficient) (LDRQ1ST) 0x81d558 0 LDRQ1DY(t) 0x81d538 LDR-control parameter Q1 in dynamic operation (integration coefficient) (LDRQ1DY) 0x81d538 0 LDRQ0DY(t) 0x81d516 LDR-control parameter Q0 (LDRQ0DY) 0x81d516 0 KFLDRQ2(t) 0x81d4ac LDR-control parameter Q2 (KFLDRQ2) 0x81d4ac 0 KFLDRL(t) 0x81d36c Map for linearization of boost pressure N75? (KFLDRL) 0x81d36c 0 KFLDIMX(t) 0x81d21a LDR I-Regulator limit (KFLDIMX) 0x81d21a 0 KFLAMKRL(t) 0x818e12 Enrichment on ignition retard (KFLAMKRL) 0x818e12 0 KFDZWOB(t) 0x0 Delta ignition angle for overboost 0x0 0 AXIS(RPM_WORDS)(t) 0x81009a RPM Axis for Timing (words) 0x81009a 0 AXIS(LOAD_WORDS)(t) 0x8142b4 Load Axis for Timing (words) 0x8142b4 0 UNKNOWN_MAP(t) 0x81962f Unknown Map, near LOAD(map) deviation regulation 0x81962f 0 MAP_KFZWOP(t) 0x815602 Optimal ignition angle (KFZWOP) 0x815602 0 AXIS: IGNITION TIMING(LOAD)(t) 0x8132f6 Axis: Ignition Timing(load) 0x8132f6 0 MAP_KFZWOP2(t) 0x8156b2 Optimal ignition angle variant2 (KFZWOP2) 0x8156b2 0 MAP_NMXDAEF(t) 0x815764 Maximum engine speed for throttle body motor backup operation (NMXDAEF) 0x815764 0 MAP_KFMIZUNS(t) 0x8157b9 Allowable torque on afterstart extension (KFMIZUNS) 0x8157b9 0 MAP_KFMIZUFIL(t) 0x815779 Allowable indicated torque to torque limit before filter (KFMIZUFIL) 0x815779 0 MAP_KFZWMS(t) 0x815d8c Map with permanent latest possible ignition angle (KFZWMS) 0x815d8c 0 MAP_KFZW(t) 0x815f0e Ignition angle map (KFZW) 0x815f0e 0 MAP_KFZW2(t) 0x815e4e Ignition angle map (KFZW2) 0x815e4e 0 AXIS: RPM (PID)(t) 0x810078 Axis: RPM (PID) 0x810078 0 AXIS: RPM (MISFIRE DETECTION)(t) 0x8100bc Axis: RPM (misfire detection) 0x8100bc 0 MAP: KFTARXZK(t) 0x81d810 Maximum specified load IAT correction factor map under continuous knock (KFTARXZK) 0x81d810 0 AXIS: UNKNOWN(t) 0x814357 AXIS: Unknown, maybe IAT 0x814357 0 MAP_LDRXNZK(t) 0x81d8d2 Maximum specified load during continuous knock (LDRXNZK) 0x81d8d2 0 MAP_LDRXN_1_A(t) 0x81d890 Maximum specified load (LDRXN_1_A) 0x81d890 0 MAP_RLSALUN(t) 0x81469a Load threshold for surge recognition for misfire recognition attenuation (RLSALUN) 0x81469a 0 MAP_LDKTSO_0_A(t) 0x814bf8 Upper load curve for DKAT active _RLDKTSO_0_A 0x814bf8 0 MAP_KFDLUR(t) 0x814594 *Rough running deviation (dluts) reference value (KFDLUR) 0x814594 0 MAP_KFDLUR2(t) 0x814614 *Rough running deviation (dluts) reference value 2 (KFDLUR2) 0x814614 0 MAP_KFDLUR1(t) 0x8145d4 *Rough running deviation (dluts) reference value 1 (KFDLUR1) 0x8145d4 0 MAP_NGALU(t) 0x8101e8 Misfire detection: RPM deviation fade-out threshold (NGALU) 0x8101e8 0 MAP_KFMI_UM(t) 0x814098 map_Optimal_torque_under_monitoring_KFMI_UM 0x814098 0 AXIS:FOR_KFMI_UM(KFZW_UM)(t) 0x81407d Axis:for_KFMI_UM+KFZW_UM 0x81407d 0 MAP_KFZW_UM(t) 0x8140d8 map_Optimal_ignition_angle_under_monitoring_KFZW_UM 0x8140d8 0 MAP_KFMDZOF_UM(t) 0x814129 map_Offset_tolerance_depending_on_allowed_torque_KFMDZOF_UM 0x814129 0 MAP_KFMPED_UM(t) 0x814169 Map for allowable torque from pedal position in the functions monitoring (KFMPED_UM) 0x814169 0 MAP_KFMPNS_UM(t) 0x8141a9 Map for allowable torque from pedal position on cold motor (KFMPNS_UM) 0x8141a9 0 MLHFM(t) 0x810d72 MAF linearization (MLHFM) 0x810d72 0 KFWKSTAB(t) 0x811d90 Table: Repeated cold start factor of start count reduction KFWKSTAB 0x811d90 0 DZWTIN(t) 0x811f36 Table: Delta ignition angle with tip engaged DZWTIN 0x811f36 0 KFVPDKSD(t) 0x81253a Table: Desired pressure ratio DK dynamic KFVPDKSD 0x81253a 0 KFVPDKSE(t) 0x81265a Table: Desired pressure ratio stationary KFVPDKSE 0x81265a 0 AXIS: RPM FOR KFVPDKSD(t) 0x8100d8 Axis: RPM for KFVPDKSD and KFVPDKSE 0x8100d8 0 KFMDST_0_A(t) 0x8128a4 Table: Starting torque (KFMDST_0_A) 0x8128a4 0 KFPED_0_A(t) 0x812e42 Table: Relative torque request from pedal KFPED_0_A 0x812e42 0 KFMIOP(t) 0x813196 Table: Optimal engine torque map (KFMIOP) 0x813196 0 KFZWMNST(t) 0x813824 Table: Minimum ignition angle for start and warm up KFZWMNST 0x813824 0 AXIS: RPM(KNOCK REGULATION)(t) 0x81825f Axis: RPM(knock regulation) 0x81825f 0 AXIS: LOAD (UNKNOWN USE)(t) 0x81828a Axis: Load (unknown use) 0x81828a 0 AXIS: LOAD(EGT ENRICH)(t) 0x8182af Axis: Load(EGT enrich) 0x8182af 0 KFFMSML_0_A(t) 0x818358 EMBP correction of the secondary air mass (KFFMSML_0_A) 0x818358 0 KFWEE(t) 0x818b55 Injection cutoff angle (KFWEE) 0x818b55 0 KFWEEK(t) 0x818b95 Injection cutoff angle (cold) (KFWEEK) 0x818b95 0 KFFDLBTS_0_A(t) 0x818fac Factor delta desired lambda for component protection (KFFDLBTS_0_A) 0x818fac 0 KFLBTS_0_A(t) 0x81906c Desired Lambda for component protection (KFLBTS_0_A) 0x81906c 0 DWKRMSN(t) 0x819473 Delta angle knock regulation offset for average retard (DWKRMSN) 0x819473 0 KRDWSN(t) 0x8194b9 Knock regulation delta - angle safety (KRDWSN) 0x8194b9 0 KRFKLN(t) 0x8194c9 Ignition retard per knock event (KRFKLN) 0x8194c9 0 KRMXN(t) 0x8194d9 Maximum ignition retard (KRMXN) 0x8194d9 0 KFLDIOPU(t) 0x819597 TV correction due to altitude effect on ambient pressure (KFLDIOPU) 0x819597 0 KFWPLGTA(t) 0x8195d7 Map for weighting factor of reference boost pressure as a function of IAT (KFWPLGTA) 0x8195d7 0 LDIATA(t) 0x81961c LDR I-Regulator limit correction as a function of IAT (LDIATA) 0x81961c 0 TABLDOBN(t) 0x819670 Down regulation interval for LDR overboost (TABLDOBN) 0x819670 0 TLDOBAN(t) 0x819678 Time for LDR overboost active (TLDOBAN) 0x819678 0 TLDOBN(t) 0x819680 Off time for overboost (TLDOBN) 0x819680 0 KFLDHBN(t) 0x8196a4 LDR altitude limitation (maximum pressure ratio) (KFLDHBN) 0x8196a4 0 LDORXN(t) 0x8196e4 Maximum load at E_ldo LDR (overboost error) (LDORXN) 0x8196e4 0 LDPBN(t) 0x8196ec LDR pressure limit at too high a temperature engine (LDPBN) 0x8196ec 0 RLKRLDA(t) 0x8196f4 rl threshold for slow LDR-intervention (adaptation) (RLKRLDA) 0x8196f4 0 TVFSREM(t) 0x819983 Motor temperature dependent delay time for drive in (R) (TVFSREM) 0x819983 0 NFSM(t) 0x8198e6 Desired idle speed when in gear (NFSM) 0x8198e6 0 KFFWL_0_A(t) 0x818c7b Warm up enrichment factor (KFFWL_0_A) 0x818c7b 0 KFFWL_1_A(t) 0x818d0b Warm up enrichment factor (KFFWL_1_A) 0x818d0b 0 DPVDKDWG(t) 0x816fa0 Min delta pressure before throttle plate for wastegate diagnosis (DPVDKDWG) 0x816fa0 0 AXIS: FOR DPVDKDWG(t) 0x816f97 Axis: for Min delta pressure before throttle plate for wastegate diagnosis (DPVDKDWG) 0x816f97 0 DPLSDWG(t) 0x816f86 Max delta plsol for wastegate diagnosis (DPLSDWG) 0x816f86 0 AXIS: FOR DPLSDWG(t) 0x816f7d Axis: for Max delta plsol for wastegate diagnosis (DPLSDWG) 0x816f7d 0 KFZWWLNM(t) 0x816017 Delta timing during warmup 0x816017 0 KFZWWLNM(t) 0x816017 Delta timing during warmup 0x816017 0 FKKVS(t) 0x81bd42 Correction factor for fuel supply system (FKKVS) 0x81bd42 0 FWWDKMSN(t) 0x8117f0 desired throttle plate angle (KFWDKMSN) 0x8117f0 0 KFHSTT(t) 0x818bb3 Table:Hot start enrichment factor (KFHSTT) 0x818bb3 0 KFZWWLNM(t) 0x816017 Delta timing during warmup 0x816017 0 MDIMX(c) 0x815763 Max_indicated_engine_torque_MDIMX 0x815763 0 VMAX(c) 0x0 VMAX 0x0 0 DSLGRAD(c) 0x8116d2 MAP_sensor_gradient 0x8116d2 0 DSLOFS(c) 0x8116d4 MAP_sensor_offset 0x8116d4 0 KUMSRL(c) 0x814fc3 Conversion_constant_from_MAF_to_relative_charge_KUMSRL 0x814fc3 0 MLOFS(c) 0x811174 MAF_offset_MLOFS 0x811174 0 KVNPZ(c) 0x8143ff Normalized_fuel_consumption_per_cylinder_for_DIS_KVNPZ 0x8143ff 0 DMDDLU(c) 0x814694 Min_RPM_for_misfire_recognition_fade_out_DMDDLU 0x814694 0 NWPMBBR(c) 0x814c2d Min_RPM_for_acc_pedal_value_lockout_on_brake_operation_NWPMBBR 0x814c2d 0 VWPMBBR(c) 0x814c46 pedal_lockout_on_brakes_activation_speed_VWPMBBR 0x814c46 0 TWPMBBR(c) 0x814c37 Delay_time_for_acc_pedal_value_lockout_on_brake_operation_TWPMBBR 0x814c37 0 UPWGVG(c) 0x814c45 Pedal_volts_for_full_throttle_UPWGVG 0x814c45 0 VNMX(c) 0x815772 Speed_before_rpm_limit_raised 0x815772 0 TMOTNMX(c) 0x813324 Water_temp_before_rpm_limit_raised_TMOTNMX 0x813324 0 TNMXH(c) 0x813328 Max_duration_of_raised_rpm_limit_TNMXH 0x813328 0 NMAX(c) 0x81331a Main_RPM_Limit_NMAX 0x81331a 0 ITNMXH(c) 0x813318 Time_under_rpm_limit_before_activating_raised_rpm_limit_ITNMXH 0x813318 0 DNMAX(c) 0x813310 Max_rate_rpm_change_DNMAX 0x813310 0 NMAXDZ(c) 0x81331c Max_RPM_with_doubled_ignition_detected_NMAXDZ 0x81331c 0 DNMAXDZ(c) 0x813312 delta_for_rpm_limit_for_double_ignition_DNMAXDZ 0x813312 0 NMAXDZ(c) 0x81331c Max_rpm_on_doubled_ignition_detection_NMAXDZ 0x81331c 0 NMXDKPU(c) 0x813322 Max_rpm_on_safety_fuel_cutoff_SKA_NMXDKPU 0x813322 0 NMAXNL(c) 0x81331e Max_rpm_on_rpm_gauge_fail_NMAXNL 0x81331e 0 DNMAXH(c) 0x813314 rpm_deviation_above_limit_for_all_cyl_cut_DNMAXH 0x813314 0 TNMAXP(c) 0x813326 Dwell_time_in_NMAX_before_change_over_in_calibration_TNMAXP 0x813326 0 ITNMAXP(c) 0x813316 Duration_for_active_alternative_calibration_of_maximum_rpm_ITNMAXP 0x813316 0 CW_NOROMCHKRESET(c) 0x815c02 Codeword_No_ROM_check_reset_CW_NOROMCHKRESET 0x815c02 0 NMIALU(c) 0x814697 Min_rpm_for_misfire_recognition_fade_out_NMIALU 0x814697 0 RLSALULL(c) 0x814699 Load_threshold_for_surge_recognition_for_misfire_recognition_attenuation_during_idle_RLSALULL 0x814699 0 MSALLMN(c) 0x814fc6 Min_idle_air_mass_adaption_for_exhaust_gas_MSALLMN 0x814fc6 0 CWLAMKH(c) 0x8150aa CW_Lambda_coordination_during_cat_warmup_CWLAMKH 0x8150aa 0 VKO(c) 0x81616d Speed_before_AC_control_active_VKO 0x81616d 0 TKOMBKOA(c) 0x816155 engine_temp_from_cluster_for_AC_cutoff_TKOMBKOA 0x816155 0 TKOMBKOE(c) 0x816156 engine_temp_from_cluster_for_AC_activation_TKOMBKOE 0x816156 0 TMKOAO(c) 0x816168 temp_limit_before_AC_cutoff_TMKOAO 0x816168 0 TMKOAU(c) 0x816169 temp_limit_before_AC_activated_TMKOAU 0x816169 0 NMAXF(c) 0x810ae8 RPM_exceeded_threshold_for_cut_NMAXF 0x810ae8 0 TMSTMAD(c) 0x81616a Temp_during_start_for_requirements_adaption_TMSTMAD 0x81616a 0 KOAO(c) 0x81616e max_speed_before_AC_cutoff_VKOAO 0x81616e 0 TANSKOB(c) 0x816123 IAT_threshold_for_AC_cutoff_TANSKOB 0x816123 0 VKOB(c) 0x81616f Speed_threshhold_for_AC_control_during_acceleration_VKOB 0x81616f 0 SLOGIN(c) 0x812120 SLOGIN 0x812120 0 GRAONLOGIN(c) 0x81211c GRAONLOGIN 0x81211c 0 ADRLOGIN(c) 0x812118 ADRLOGIN 0x812118 0 GRAOFLOGIN(c) 0x81211a GRAOFLOGIN 0x81211a 0 VARDEF(c) 0x812122 Default coding for varient coding 0x812122 0 THLDUVD(c) 0x812538 Dwell_time_for_dynamic_BPV_N249_control_THLDUVD 0x812538 0 TDPDK(c) 0x81277a Down_control_time_constant_for_fmvp_w_factor_TDPDK 0x81277a 0 RAMPASR(c) 0x8101c2 Ramp_slope_during_devation_regulation_of_ASR_torque_RAMPASR 0x8101c2 0 UADPLMN(c) 0x8187c4 Min_voltage_for_diagnosis_MAP_sensor_limp_UADPLMN 0x8187c4 0 UADPLMX(c) 0x8187c5 Max_voltage_for_diagnosis_MAP_sensor_limp_UADPLMX 0x8187c5 0 UADPUMN(c) 0x8187c6 Min_voltage_for_diagnosis_MAP_sensor_UADPUMN 0x8187c6 0 UADPUMX(c) 0x8187c7 Max_voltage_for_diagnosis_MAP_sensor_UADPUMX 0x8187c7 0 TKHLLAB(c) 0x819240 Debounce_time_for_end_of_cat_heater_cycles_per_min_during_idle_TKHLLAB 0x819240 0 KRALH(c) 0x8194b3 Knock_regulation_Load_hysteresis_KRALH 0x8194b3 0 KRANH(c) 0x8194b8 Knock_regulation_RPM_hysteresis_KRANH 0x8194b8 0 EDLDRP(c) 0x819780 Control_deviation_threshold_for_LDR_positive_deviation_diagnosis_EDLDRP 0x819780 0 LDEIAU(c) 0x81961a Lower_regulation_deviation_threshold_for_negative_adjustment_LDEIAU 0x81961a 0 LDEIAO(c) 0x819617 Upper_regulation_deviation_threshold_for_negative_adjustment_LDEIAO 0x819617 0 LDEIAP(c) 0x819618 Regulation_deviation_threshold_for_positive_adaption_I_Regulation_LDEIAP 0x819618 0 LDEIAS(c) 0x819619 Regulation_deviation_threshold_for_rapid_positive_set_point_tracing_LDEIAPS 0x819619 0 LDHIA(c) 0x81961b Hysteresis_for_LDR_I_Adaption_curve_LDHIA 0x81961b 0 UMDYLDR(c) 0x819637 Changeover_deviation_threshold_for_dynamic_LDR_UMDYLDR 0x819637 0 SDLDRL(c) 0x81982a Minimum_charge_LDR_for_DIA_LDR_maximum_permitted_pressure_SDLDRL 0x81982a 0 TDLDRA(c) 0x81982b Time_threshold_for_Dia_LDR_control_deviation_TDLDRA 0x81982b 0 TDLDRA2(c) 0x81982c Time_threshold_for_Dia_LDR_control_deviation_B_mxldra_TDLDRA2 0x81982c 0 TLDRA(c) 0x81982d Delay_time_for_Dia_LDR_control_deviation_detection_cycle_flag_TLDRA 0x81982d 0 TULV1(c) 0x81982e Overboost_cutoff_delay_step_1_TULV1 0x81982e 0 TULV3(c) 0x81982f Delay_time_for_overboost_failure_recovery_TULV3 0x81982f 0 KVB(c) 0x81a348 Constant_for_fuel_consumption_display_KVB 0x81a348 0 TDDBKV(c) 0x0 Debounce_time_for_setting_of_cycle_flags_TDDHBKV 0x0 0 MLSLMX(c) 0x81a4de Max_air_mass_b4_shutoff_secondary_air_injection_MLSLMX 0x81a4de 0 MLWDSLMN(c) 0x81a548 min_airmass_for_diagnosis_MLWDSLMN 0x81a548 0 MLLASH(c) 0x81b392 Airmass_threshold_for_dynamic_testing_behind_cat_MLLASH 0x81b392 0 DPDSVLU(c) 0x81bba4 Delta_pressure_value_for_signal_comparison_of_pressure_sensor_with_ambient_pressure_DPDSVLU 0x81bba4 0 MLMAX(c) 0x81bc10 max_airflow_for_load_calculation_MLMAX_SAE_J1979 0x81bc10 0 TABGBTS(c) 0x81c14a EGT_threshold_for_component_protection_TABGBTS 0x81c14a 0 TABGSS(c) 0x81c1ac target_EGT_B1_TABGSS 0x81c1ac 0 TABGSS2(c) 0x81c1ae target_EGT_B2_TABGSS2 0x81c1ae 0 TDATSO(c) 0x81bffe EGT_sensor_error_limit_TDATSO 0x81bffe 0 DTC_CONFIG_BITS1(c) 0x818d98 DTC_CONFIG_BITS1 0x818d98 0 EGT_THRESHOLD1_950(c) 0x81bffc EGT_threshold1_950 0x81bffc 0 EGT_THRESHOLD2_940(c) 0x81bff8 EGT_threshold2_940 0x81bff8 0 EGT_THRESHOLD3_1035(c) 0x81bffa EGT_threshold3_1035 0x81bffa 0 LDRQ0S(c) 0x81d536 LDR_control_param_Q0_in_stationary_operation_LDRQ0S 0x81d536 0 TVLDMX(c) 0x81d58e Upper_duty_cycle_limit_for_LDR_TVLDMX 0x81d58e 0 VAVMAX_VMAX(c) 0x0 max_vehicle_speed_VAVMX_VMAX 0x0 0 KRKTE(c) 0x818da8 Conversion_of_relative_fuel_mass_rk_to_effective_injector_time_te_KRKTE 0x818da8 0 Have fun. Spen Title: Re: 8d0907551A defn file Post by: turboskipper on September 27, 2010, 09:14:21 AM Wow, thanks!
Title: Re: 8d0907551A defn file Post by: Rick on September 28, 2010, 11:46:43 AM Nice one Spen :)
Title: Re: 8d0907551A defn file Post by: iznogoud on November 01, 2010, 09:12:24 AM Nice work spen (applaud).
I would like to verify the maps. what I am planning to do is look at the data that is in an Mbox bin, since for that one I have nyet's XDF file and a bin, and compare to what the addresses of your definitions give for the Abox bin, which I also have. Numbers may not be exactly the same, but they should be close enough where I should be able to tell. It is going ot be tedious, so I will do it slowly in what I rarely have for spare time. A couple of questions: 1. how do your analysis codes find the maps? 2. How can one go easily from a CSV to an XDF that TunerPro can read? Or should I use WinOLS? Title: Re: 8d0907551A defn file Post by: Rick on November 01, 2010, 03:35:03 PM The locations will be correct.
The easiest way I have found is to edit the M box XDF and replace with your new address. Rick Title: Re: 8d0907551A defn file Post by: iznogoud on November 01, 2010, 09:42:05 PM The locations will be correct. The easiest way I have found is to edit the M box XDF and replace with your new address. OK, so you mean that the new addresses wil be fine if replaced on an existing XDF file. I get that. So... I started the tedious conversion process of all 260 "Address =0x" patterns that I found in the Mbox XDF file that nyet has on his site to make an Abox XDF. I found that there is "Address" and "XAddress" and "YAddress" that are listed for some of the maps, like for example the "Engine load" map. The X and Y addresses may be pointing to other maps that form the axes... So, how do I know where to look? Do I dig up those addresses in their HEX form in the Mbox XDF file and see which are those maps and make the corresponding changes based on spen's CSV file? Ouph. This is going to suck... Title: Re: 8d0907551A defn file Post by: turboskipper on November 02, 2010, 07:08:23 AM OK, so you mean that the new addresses wil be fine if replaced on an existing XDF file. I get that. So... I started the tedious conversion process of all 260 "Address =0x" patterns that I found in the Mbox XDF file that nyet has on his site to make an Abox XDF. I found that there is "Address" and "XAddress" and "YAddress" that are listed for some of the maps, like for example the "Engine load" map. The X and Y addresses may be pointing to other maps that form the axes... So, how do I know where to look? Do I dig up those addresses in their HEX form in the Mbox XDF file and see which are those maps and make the corresponding changes based on spen's CSV file? Ouph. This is going to suck... Yes, you have to spend a lot of time with both hex's open to compare and search for axis and such. Normally once you are in the correct region you can spot matching byte sequences and piece things together. Title: Re: 8d0907551A defn file Post by: iznogoud on November 02, 2010, 02:05:26 PM Yes, you have to spend a lot of time with both hex's open to compare and search for axis and such. Normally once you are in the correct region you can spot matching byte sequences and piece things together. So you are saying that for every and each "axis" address (XAddress" or "YAddress" I will have to look into the binary of the known map location (address), get the byte-string that is of the specified length+type and find that string in the Abox file? That would seriously suck. I'd have to script that one... Title: Re: 8d0907551A defn file Post by: iznogoud on November 02, 2010, 08:37:47 PM Alright, so I started and tell me if I am crazy.
Attached is a C program that parses an XDF file for Tables and Constants. We really do not need the constants, so I am skipping all the reading of that data. From the table data that the XDF contains, I will have altered all the "Address" numbers (somehow) to replace them with what spen has on his CSV. The dirty work is going to be finding the "axis data" from the existing addresses, as I described above. So, I read the X and Y axes information from each table and I store it. Then, I will make a pass within the bin file for which the axes data is listed in the XDF and read those segments of data in the memory. Whatever the Xaxis and Yaxis variables are I will read according to how they are sized based on the information within the XDF. The hard part comes next. I will have to do a pattern match for each of those axes segments within the bin for for which I want to build the XDF. IN our case it is the Abox. If there is a match, I call it good and write that address in the XAddress and YAddress segment of the XDF file. The only assumption here is that the axes "data" in the bin file are the same across the two different bin files... Any ideas? Title: Re: 8d0907551A defn file Post by: turboskipper on November 03, 2010, 07:58:14 AM Alright, so I started and tell me if I am crazy. Attached is a C program that parses an XDF file for Tables and Constants. We really do not need the constants, so I am skipping all the reading of that data. From the table data that the XDF contains, I will have altered all the "Address" numbers (somehow) to replace them with what spen has on his CSV. The dirty work is going to be finding the "axis data" from the existing addresses, as I described above. So, I read the X and Y axes information from each table and I store it. Then, I will make a pass within the bin file for which the axes data is listed in the XDF and read those segments of data in the memory. Whatever the Xaxis and Yaxis variables are I will read according to how they are sized based on the information within the XDF. The hard part comes next. I will have to do a pattern match for each of those axes segments within the bin for for which I want to build the XDF. IN our case it is the Abox. If there is a match, I call it good and write that address in the XAddress and YAddress segment of the XDF file. The only assumption here is that the axes "data" in the bin file are the same across the two different bin files... Any ideas? Sounds like you are on the right track. Most of the base engine data is the same which is why you can pattern match from an mbox cal to an abox cal and be successful. Title: Re: 8d0907551A defn file Post by: iznogoud on November 03, 2010, 08:32:38 AM OK, cool. I will code up the rest of it tonight and run it.
can spen (or somebody else) tell me how they got the original MAP addresses? nyet's email just bounces back. Title: Re: 8d0907551A defn file Post by: Tony@NefMoto on November 03, 2010, 05:56:10 PM Nyet found the map addresses by comparing a G box damos file to his m box ECU file.
I found map addresses by going through assembler code and finding all references to the map lookup functions. Title: Re: 8d0907551A defn file Post by: iznogoud on November 03, 2010, 11:03:24 PM Nyet found the map addresses by comparing a G box damos file to his m box ECU file. I found map addresses by going through assembler code and finding all references to the map lookup functions. Corresponded with nyet all day today. He told me that he did exactly what I am doing for the Abox. He did all the hard work, as his Mbox .xdf adn .bin are what I am using. I offered big thanks. He also said that I should not bother... just get a Hitachi MAF sensor, recode the cluster and engine codes, and simply flash the Mbox file in there. Solid advice. I still will go after the Abox to prove myself that it can be done. You will all enjoy the benefits. Title: Re: 8d0907551A defn file Post by: spen on November 05, 2010, 07:28:07 AM I started out with an asap file and a ME 7 binary.
Then I found the G box data that was available and finally the M box data which Nyet posted. The scales are interesting! In some roms they are words, some bytes. It makes a translation hard. Some of the public data everyone is using has two errors in two scales in the ignition advance maps - when I am 100% certain I'll post more on this. I do all the conversions by disassembly, either manually or via an algorithm. Title: Re: 8d0907551A defn file Post by: iznogoud on November 05, 2010, 08:27:35 AM Can you share details of the algorithm? We do not necessarily need the code itself, but the principle of the operation. A few sentences like I did above will help.
I do not know what to do about assessing the quality of my work... or finding errors. Any information you can share is greatly appreciated. I trust Nye's work the best. He has a consistent XDF file and the standard BIN file from the Mbox (I verified that). Even there we have a problem. Tony#NM said that there are differences between some Mbox files... We do not know why Audi did this and not give it a different name. Nye said that he started from an Allroad Rbox, an A6 Gbox and an RS4 Rbox. He did not specify whether he had XDF-type data for either of the three. It worked for him. So my beacon now is his XDF and bin file. Also, for finding maps, I followed a link to a tune reverse engineering site from the TunerPro.net Resources page. Those people are mostly dealing with Porsche and BMW maps, but they explain the principles of the reverse engineering pretty well. In that spirit, I authored a little C routine last night to drop the contents of any bin file to an HTML table, complete with addresses in dec and hex and the printable set of the unsigned char data. I am attaching it below an will post a separate thread about it. Title: Re: 8d0907551A defn file Post by: spen on November 05, 2010, 09:47:09 AM Mine works along the same principal as a virus scanner. I known sig for a location which reads the target map. I then scan through a target rom and note any direct matches excluding absolute addresses. If that fails I move to byte / word swaps, using ram at page 0xe1, and finally a distance value from the current sig to the current chunk of the target rom - a bit like a spell checker. When I get a hit, I parse the code looking for the scanning routine call, then locate the register loaded with the offset and DPR of the table. Then I drop the result along with the program counter in to a data grid view. Sometimes it doesn't work out and I have to do it manually. Doing it automagically and getting the correct axis based on the machine code is hard, but I am getting there. Checking work - I create from D rom. I scan F, M, H and G roms and compare the results if there are any which don't line up I investigate. There's no way to be 100%. I catch errors in my own work. I catch errors in Nyes! There is even an error in an ASAP file out there. Only the machine code is 100% accurate. Title: Re: 8d0907551A defn file Post by: iznogoud on November 05, 2010, 01:02:48 PM I see. good work.
So your primary assumption is that the addresses are pointing to maps that are identical, more or less. The more-or-less part is where you do the distance checking (or inner-product test if you are a real geek) like a spell-checker. I see. I can also see how there are multiple sources of errors possible. Title: Re: 8d0907551A defn file Post by: spen on November 05, 2010, 01:27:02 PM I see. good work. So your primary assumption is that the addresses are pointing to maps that are identical, more or less. The more-or-less part is where you do the distance checking (or inner-product test if you are a real geek) like a spell-checker. I see. I can also see how there are multiple sources of errors possible. NO. You misunderstand I think, I don't expect that addresses are pointing to maps that are identical. I am assuming the code which looks for the specific map does not change much between revs of code. The code moves location - so the addresses change always, both program counter and target addresses, but the function structure remains almost static. When the structure of the routine changes the Levenshtein distance is not great FOR THE STRUCTURE OF THE FUNCTION AS A WHOLE, not it's location. I search for 0 distance in routine structure first as it is fast. I'm not assuming the map is identical, they aren't even if the function is the same. If I just assumed that because G rom, read data at program counter 0x88a43b, that in every rom a map is read at 0x88a43b I'd be off by miles on every single target. Title: Re: 8d0907551A defn file Post by: Tony@NefMoto on November 05, 2010, 02:10:07 PM There's no way to be 100%. I catch errors in my own work. I catch errors in Nyes! There is even an error in an ASAP file out there. Only the machine code is 100% accurate. I've found bugs in the assembly code too. Machine code is 100% accurate, but doesn't necessarily do what the Bosch engineering intended. ;D As for finding maps and data in binary files. I agree with how spen does it. Use a reference file as a template. For each piece of data you are interested in, find the assembly code that accesses that data. Then generate a pattern for that piece of assembly code. Then in your new binary file, search for the matching pattern of assembly code, ignoring absolute addresses. Once you have found the matching pattern of assembly code, grab the new memory address of the data you want from the memory reference in the piece of the code you matched. This is also the same way that Andy Whittaker's ECU Fix tool finds checksums in binary files. Title: Re: 8d0907551A defn file Post by: iznogoud on November 05, 2010, 02:38:51 PM OK. good discussion here.
Tangent question: do we want to write our own checksum-maker for files or keep using Andy's? I am hazy on the details of how to do all this right now, but if it is possible we'll find a way to do it. Title: Re: 8d0907551A defn file Post by: Tony@NefMoto on November 05, 2010, 02:43:47 PM OK. good discussion here. Tangent question: do we want to write our own checksum-maker for files or keep using Andy's? I am hazy on the details of how to do all this right now, but if it is possible we'll find a way to do it. After a few more small releases, I plan on working on a checksum tool. I already have the code to correct the checksums, and I just need to write the code to locate the checksums. So I will need to write some assembly code pattern matching to do that. Should be fun. ;D Title: Re: 8d0907551A defn file Post by: spen on November 06, 2010, 01:33:13 AM chksum shouldn't be hard. I can post the routines which calc the checksum blocks. Andy Whitaker posted most of the 'how'.
There is even a codeword to ignore the checksum routine. However someone inserted two NOP instructions over the jmp in the checksum routine, effectively breaking the codeword function. It shouldn't be too hard to work out where the jmp_nz should jump to, then we can forget about checksums - useful for those of us with an eprom emulator who want to map the car live. Title: Re: 8d0907551A defn file Post by: spen on November 06, 2010, 01:53:16 AM link to ignore checksum codeword thread: http://www.nefariousmotorsports.com/forum/index.php?topic=274.0title= |