NefMoto

hey guys. edited a file and wanted to check sums before flashing. ME7Sum says there is an uncorrectable error.
preedit file is working fine. 0 errors.
Can some1 tell me what I did wrong?


ME7Sum (v1.0.5) [Management tool for Bosch ME7.x firmwares]
Inspiration from Andy Whittaker's tools and information.
Written by 360trev and nyet [BSD License Open Source].

Attempting to open firmware file 'golf_mod.bin'

Step #1: Reading ROM info ..
 Searching for EPK signature...OK
 Searching for ECUID table...OK
 EPK         : '40/1/ME7.5/5/4019.02//24C/Dst02o/220202//'
 Part Number : '06A906032HN '
 Engine ID   : '1.8L R4/5VT     '
 SW Version  : '0002'
 HW Number   : '0261207440'
 SW Number   : '1037363908'

Step #2: Reading ROMSYS ..
 Startup section: word[0x008000]+word[0x00FFFE]
 @08038 Add=0x0000F6B5 CalcAdd=0x0000F6B5  ADD OK
 All param page: word[0x010000]+word[0x01FFFE]
 @01bef0 Add=0x00971D CalcAdd=0x00971D  ADD OK

Step #3: Reading RSA signatures ..
 Searching for RSA offset #0...OK
 Searching for RSA offset #1...OK
         Signature: @8f5e4-8f664
           Modulus: @168d4-16954
          Exponent: @16954 = 3
 Searching for MD5 ranges...OK
 MD5 Block Offset Table @168b0 [32 bytes]:
 1) 0x00010002-0x00013FFE
 2) 0x00014252-0x00017F4E
 3) 0x00018192-0x0001FBDC
 4) 0x00026A00-0x0002FFFC
 EncrMD5: len mismatch: 16+10!=128-1
 CalcMD5: 86 94 9c 67 a2 4e c4 bf 09 91 5a 6d af cd f1 84
 ** FIXED **

Step #4: Finding CRC table(s) ..
 Searching for CRC table(s)...OK
 CRC table(s) OK

Step #5: Reading Main Data Checksums ..
 Searching for main data CRC pre block...missing
 Searching for main data CRC/csum blocks...OK
 Searching for main data CRC offsets...missing
 Searching for main data checksum offsets...OK
 Main Checksums:
 1) 0x010002-0x013FFE CalcCSM: 00133BB8
 2) 0x014252-0x017F4E CalcCSM: 00275F37
 3) 0x018192-0x01FBDC CalcCSM: 00450365
 4) 0x026A00-0x02FFFC CalcCSM: 00C177BA
 @8fe2a CSM: 00C16A97 CalcCSM: 00C177BA ** FIXED **

Step #6: ROMSYS Program Pages
 Program pages: 8k page first+last in 0x0000-0xFFFF and 0x20000-0xFFFFF
 @00803c Add=0xA3B1F1 CalcAdd=0xA3B1F1  ADD OK

Step #7: Reading Main Program Checksums ..
 Searching for main program checksum..OK
 ROM Checksum Block Offset Table @1fb74 [16 bytes]:
 1) 0x000000-0x00FBFF CalcChk: 48D184BF
    0x00FC00-0x01FFFF CalcChk: 21B781AE CalcCRC: 6C4366BF SKIPPED
 2) 0x020000-0x0FFFFF CalcChk: 323626E4
 @fffe0 Chk: 3236017F CalcChk: 323626E4 ** FIXED **

Step #8: Reading Multipoint Checksum Blocks ..
 Searching for multipoint block descriptor #1...missing
 Searching for multipoint block descriptor #2...OK
 1) <1fbde>  0x000000-0x003FFF Chk: 0FA0F5CF Boot: (whitelisted) OK
 2) <1fbee>  0x004000-0x007FFF Chk: 0F4716B3 Boot: (whitelisted) OK
 3) <1fbfe>  0x000000-0x003FFF Chk: 0FA0F5CF CalcChk: 0FA0F5CF OK
 ..........
64) <1ffce>  0x0F4000-0x0F7FFF Chk: 1FFFE000 CalcChk: 1FFFE000 OK
65) <1ffde>  0x0F8000-0x0FBFFF Chk: 1FFFE000 CalcChk: 1FFFE000 OK
66) <1ffee>  0x0FC000-0x0FFFFF Chk: 1FFDE002 CalcChk: 1FFDE002 OK
 Multipoint #2: [66 blocks x <16> = 1056 bytes]

Step #9: Looking for rechecks ..
    <1fc6e>  0x01C000-0x01FFFF Chk: 064879F6 CalcChk: 064879F6 OK (recheck)

*** Found 70 checksums in golf_mod.bin

*** ABORTING! 1 uncorrectable error(s) in golf_mod.bin! ***

Thanks!

wheres the file lol?

 ;)

post ori and modified... looks like a me7sum bug, will test.

I will release 1.1.1 shortly

https://nyetwurk.github.io/ME7Sum/
v1.1.1 is released

ran threw ecufix

Okay, i thought i didnt something wrong. I'll check with 1.1.1 later and see if it works.

@Marty Thanks for the fix. me7check says it has an error tho.

----------------------------------------------------------------------EDIT-----------------------------------------------------------------

when I use 1.1.1 me7sum to correct the file it says there is no error but afterwards me7check says 1 error. confusing...

*** No errors were found and so no "golf_mod_correct.bin" was generated.

C:\Users\timo1\Desktop\Tune\checksum>ME7Check golf_mod.bin
==============================================================================
ME7Check v1.12 (c) mki, 06/2004-05/2012
Checking file golf_mod.bin (size=1048576)
Reading Version Strings...
-> Bootrom Version = 05.12
-> EPK = 40/1/ME7.5/5/4019.02//24C/Dst02o/220202//
-> Contents of ECUID data table:
   - '0261207440'         (SSECUHN)
   - '1037363908'         (SSECUSN)
   - '06A906032HN '       (VAG part number)
   - '0002'               (VAG sw number)
   - '1.8L R4/5VT     '   (engine id)
-> Contents of ECUID data table:
   - 'HW_MAN004'


RSA signature failure found
-> Found 1 error!!!   *******************************


Its the rsa signature? so i can use the file anyway?

plz post stock bin

ecu fix should have fixed any issues with that file

That is confusing the issue since
1) ecufix patches out the RSA check entirely
2) if there is a padding issue on the ORI, me7check might always report an error.

i've attached the stock file from auq and the file i took from the car.

what is the RSA signature? could find anything specific related to the context... is it some kind of encryption? the file on the car has some kind of read protection. i wasn't able to open it in winols.

Both of those files are padded correctly.

Do not read tunes you didn't write.

Also have seen similar problems with "tuned" files, don't even bother most likely garbage file start from stock lol.

okay. Thanks. I'll keep that in mind.

So I'll start to go from a base file and copy the values from bam file for the k04 build? Like MLHFM, KRKTE etc pp

Well yes, I'd say that's an excellent place to start from if you're fitting a k04-023 with 386cc bam injectors @ 4 bar.

Or perhaps looking at BFV 240 binary is also worth your time (same hardware as BAM225).

Okay, I'll take a deeper look.

Are you sure the BAM is running @4bar FP? I've read 3bar so often in BAM context, so I didn't even think about that one.

I've started comparing BAM and AUQ stock files a while ago. I'll go on with that now. Thanks!

Oh and to be specific, atm its k04-022 (no egt probe), BAM injectors and 3bar FPR

Actually I'm not sure about that I'd have to check.

Either way you can easily calculate theoretical KRKTE so it doesn't matter really.

022 and 023 are otherwise identical so that's fine.

i started by comparing stock auq file with the file that was on the car, because i knew how the car behaved. now for the k04 install i compared both with bam values so far.
so in conclusion to our last posts, i will start over with the auq base file and put in the necesarry bam values.
I've attached my compare file, in case you'd like to check it and tell me if i'm missing something.

I'd like to do the same with bfv file, but to be honest I'm to lazy to make a proper xdf

thanks so far

This is as said your best bet to start with, and also probably the easiest. Just read S4wiki and copy over everything you deem necessary.

For example: KRKTE, TVUB, MLHFM, LDRXN, IRL/IOP

I think KFLDIMX and KFLDRL are also interesting maps to look at.

Look at fuelling too, BAM for example never uses BTS.

Thats what I did, I've read S4Wiki step by step, checked in the FR to get a understanding what var is for what. Pasted the tables side by side into excel and let excel mark the differences in the tables.
So far I compared IRL, IOP, LDRXN, KFLDRXO, KFLDHBN, KRKTE, KFMLDMX, KFLBTS, MLHFM, MLMAX and a few more.

what i don't really get into my head is the relation between iop and irl.  ???

Why does the BAM not use BTS? The values I see seem normal to me, 1.01 at low rpm and load and going to 0.8 up top.

Read the forums on KFMIOP logic

http://nefariousmotorsports.com/forum/index.php?topic=970.0 this is a very good thread to get the idea.

It's basically just mathematical inverse of IRL and that's it.

As for why BAM doesn't use BTS idk, maybe the Audi engineers like messing with us. The only BAM file I've looked at is a Cupra R 225 where BTS is just filled with 1.001 (14.7 afr).

inverse like square and root for example?

those are the bts values in the TT bam file i have (8N0906018BP)

Rl % / RPM800   1000   1480   1720   2000   2200   2520   3000   3520   4000   4520   5000   5520   5800   6040   6520
24,75   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,00   1,00   0,99
34,50   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,00   0,98
47,25   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,00   0,98   0,95
60,00   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   0,98   0,96   0,92
69,75   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,00   1,00   0,98   0,95   0,90
90,00   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   0,99   0,96   0,91   0,88
107,25   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,00   1,00   0,97   0,93   0,88   0,84
135,00   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   0,98   0,95   0,91   0,86   0,81
150,00   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,00   0,98   0,96   0,92   0,88   0,84   0,80
165,00   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,01   1,00   0,95   0,94   0,91   0,88   0,85   0,82   0,80
179,25   1,01   1,01   1,01   1,01   1,00   0,99   0,98   0,97   0,94   0,91   0,90   0,88   0,85   0,83   0,80   0,80
191,25   1,01   1,01   1,01   1,00   0,99   0,96   0,93   0,90   0,87   0,85   0,84   0,84   0,83   0,81   0,80   0,80

Another BAM File i found online has BTS set to 1.00 all the way through...  ???

No, not really inverse that way either.

"mathematical inverse" isn't it at all. More like "reverse" process, as in one is torque to load and the other is load to torque.

That's what I meant. I find this a very interesting OEM approach. Though using BTS and zeroing out KFFLDBTS is also a logical approach imo.

ah okay. now I kinda get it. So the ecu is using it as some kind of backup calculation right?



when the lowest value is used for target afr and bts is 1.0 all the way and LAMFA is 0.95 up top the target afr will be 0.95 without KR activated, right? How does the KR apply? Do I have to expect the engine to knock or is it some kind of backup in case it starts knocking due to high temps/boost/compression/fuel quality? I guess a retail software wont run at KR limit?

I want to understand what is my best way to approach my AFR tuning. I guess I have to get this right first before playing with torque/boost etc pp

Not quite, IOP and IRL are sort of like related. For a given IRL value you need a certain IOP value and that's that. (That's my understanding at least)

I'm actually not too sure how a file with BTS filtered out works i can make a hundred guesses but testing and logging would tell. I suppose those files use KR based fuelling indeed while not on WOT

So in my opinion its not that smart to use KR for fueling in open loop, because i dont want my engine to knock, right?
And I guess I'm driving in closed loop most of the time any way so why use KR for fueling here? Maybe I'm not really understanding how its applied but as I see it, it would be a good approach to use LAMFA in closed and BTS in open loop?? ???

open/closed loop is irrelevant, plus you likely have a wideband unless you're running ME7.1, so there is no openloop.

Long story short: use a combination of LAMFA, KR, and BTS.

They are all useful.

Oh okay thanks.  :D

The reason on BAM BTS is not used is because it has wideband EGT and it runs LAMFA and then ATR to control exhaust temps.

If you are not using a such strategy and don't have wideband EGT then zeroing KFFDLBTS is a really shit idea.
It ensures that once you get a batch of bad fuel you will have engine damage on a long WOT run.

DLBTS should be set so that under normal conditions there is no additional enrichment, and after that it SHOULD enrich otherwise you're going to melt something.

Thanks for the explanation. AUQ engines have wideband hardware. Though i don't really understand the correlation between KFFDLBTS and BTS fuelling. What is the point of the first one and what does it exactly do?

Which is why i opt for zeroing the map out and just use BTS.

Yeah ok makes sense. the temp for BTS is the calculated EGT and there is no reason to use it, when you have real EGT via EGT sensor. Thanks! :)