NefMoto

Hi
I have tried to do a ME7.5, no problem.
But at a 032CN ME7.1.1 if I trie to change some maps engine dies.
Do some one know what I must do?

Many thanks

Regards

512kb file? do you need to load it in twice?

No 1mb file
After do change engine idles bad an go off

Disable checksums in the ECU.

Over the eeprom or in flash?
I have tried noromcheckreset, but it was no help.

code patch in flash

Will still do it sometimes, regardless.

I dont know how I can do this.

Yes, but very very rarely.

1. Search for "47 F8 55 00 CC 00 CC 00" (1 match)
2. Search forward for "E6 F4 FF DF", notice the address, save the last 4 bytes (0x69E0A -> 9E0A)
3. Change "47 F8 55 00 CC 00 CC 00" to "47 F8 55 00 EA 00 0A 9E" (use the last 4 bytes loHi)

In EEPROM change 69 C1, A5 to 8E 5A, D2. On page 01 and 02.

This approach works on pretty much everything. Technically if WinOLS is correcting checksums you can only do the EEPROM.
The first patch is to check checksum when ECU is powering up (IGNITION ON). The EEPROM mod is to disable checksums while ECU is running, which is the really important part.

Never had problems running ols300 with this ecu...

interesting, what do you mean by 'simulator?'

will that allow on-the fly tuning?

google ols300

hi
for step 1 it is clear, but step 2 i have many matches with other adress but not at 0x69E0A
so which one should i choose?

the eeprom change i have know it.

many thanks for share knowledge.

please look at the attachment, i have put some files and a pic of the 032 cn adresses.

Search forward

I can confirm this patch also. Got it not from here, but from a friend of mine years ago. But now I know what was changed in the EEPROM file - I did not have a clue before  :D it was just working.

Thanks to prj for enlightment.

Had sporadic trouble with OLS300 simulator when switching ignition off and on again. Result was error in EERPOM. Engine does not start anymore.

Writing a new dump to EEPROM solved the issue. After patching the EEPROM the issues where gone.

I never had  issues using OLS300 with ME7.1.1 but the ME7.1.1 engine always had one single hiccup when changing a value.

i think i got it..

can some one please check if i am right with chages at the 032CA file, please?

E6 F4 FF DF found on adress $C0244

ori        47 F8 55 00 CC 00 CC 00

changed 47 F8 55 00 EA 00 44 02

If you did it correctly the engine will run. If you didn't it won't.

The above hex values could not be found on the ST10 (ME7.1.1 G). Is that expected?

Just checked ME7.8 from Porsche, based on ST10 - it looks exactly the same, but the code is located in MPC. Did you dump both the MPC and flash?
You could also try searching for "47 F8 55 00 EA 00" in case it's already patched for some reason.

+1.

Hello ,
I have attached my FIle with Patch.
What am I doing wrong ,I can not work with the engine running with OLS300.
Ask for help

Did you contact EVC?

Yes I have, Have the Current CHKS.
Therefore I Wolte with the patch the CHKS examination shutdown.
Unfortunately, I have not understood the EEPROM, Flash Solte agree?
Could that please view someone?

The instructions are extremely simple. If you can not follow them, I do not understand what business you have tuning cars.

Hello ,
Unfortunately, I did not understand this sentence

In EEPROM change 69 C1, A5 to 8E 5A, D2. On page 01 and 02.


Could you please tell me to help?

My A3 always dies when I make a change to the OLS300.
In FLash should agree I suppose.

Lg

Would it be possible that me someone please help?
Unfortunately, I can no assembler code.
Now I have often tried to no avail.

lg.

This has nothing to do with assembler code. It's a plain instruction. If you get even the easiest things handed to you, you won't learn much.

It means that you have to replace those HEX values 69, c1 a5 with 8e 5a d2 on page 01 "first line on a hex editor" and 02 "second line of the hex editor".

In order to understand the eeprom search a little bit on this forum about the structure and the data pages.on 95040 there are 32 pages 0 - 31 .

It is all described also on numerous FRs and by your post i understand that you speak German....So do yourself a favor and read them...

(http://i11.photobucket.com/albums/a162/laurentpotin/EEPROM/95040Beetle.jpg)

retard alert here LOL

what winols version u use?

Maybe a silly question. Will this work on Volvo ME7 ? They have the same problem.. when changing on the Fly with OLS 300 ECU dies.. (8bit values can be modified without ecu fuckup but 16 bit values can't)
I have searced for the Hex values in the Volvo files and not found the 47 F8 55 00 CC 00 CC 00. But E6 F4 FF DF can be found in numerous places.

I'm going to say if you aren't finding hex string "47 F8 55 00 CC 00 CC 00" in your binary, then there is another string of hex for your particular ecu. I'm positive there's a way to do it, but unfortunately, I don't know how. Time to get cozy with IDA.

This thread is the same problem i have on 2.7t ecu 4z7907551N, but i already tried the checksumfree mod on my emulator ecu (roadrunner) the car starts once, now i have the eeprom-error code in it. i think i need to reflash the mpc. can you give me a litte slap on my ass how to come clear with it?
i want to use tunerpro/roadrunner and neet to endian the file for using it with tunerpro, but it would be okay if its working like that.
thankyou! PS: your info about 550cc injectors works perfectly. i tuned them now on LTFT +0,8/-0,8 left/right bank. the car runs like stock and has beatiful idle. THANKALOT!

Your ECU does not have a flashable mpc. It only has ROM OTP.
To fix the additional problem with this checksum on this ECU search for "9A ?? ?? ?? DA ?? ?? ?? 49 81 3D 19" (question marks are wildcards).
Replace with "CC 00 CC 00 CC 00 CC 00 CC 00 CC 00".

The code should clear on next ignition and car should start.

I've attached a screenshot so people can understand a bit more all of these what look like magic numbers prj has been posting.

Its really not very difficult if you have a basic grasp of Siemens C167 Assembly language and the resultant conversion of those opcodes into hex codes. A lot is described in the free to download pdf of the instruction set from the web. I also wrote a c167 disassembler in C (part of the Swiss Army Knife tool) that I posted on github for free if you want to understand it more.

So the magic numbers;

47 F8 55 00

{ 47 opcode} { F8 register } { ?? ?? 16 bit data in little endian byte format }

which means;

cmpb    rl14, #55

or translated into c;

     if(CW_NOROMCHKRESET == 0x55)
     {
               // ... do something
     }
..

As you can see after the comparison opcode there are 2 nop's represented by ;

CC 00               nop
CC 00               nop

All this tells the processor to do is 'nothing'. I.e. idle. It can be used to pad or 'nop' out instructions and its used very commonly to modify binary code by patching the instructions.. 

What's going on here is that Bosch themselves disabled the use of the CW_NOROMCHKRESET control word feature which normally if it was set to 0x55 in hex then it would have disabled the rom checksum feature which forces a reset if the rom checksums fail. By modifying code in realtime the checksums fail and the code is designed to detect this and reboot.

In some Bosch ME7 roms I have seen this nop nop isn't present. What prj is doing is simply replacing to 2 nops with a JMP instruction to the address (offset) where its necessary to exit the checking. This way it bypasses the checking.
 
If anyone is really interested on how all of this works I am happy to write a few tutorials if there aren't any good ones already here. I must admit I haven't done too much searching.

I think all this searching for magic numbers doesn't really help peoples understanding. Just even having a basic knowledge of what's going on will help a lot of people and stop many of the what appears to be 'dumb' questions.

99% people have no idea about this. For those who know asm no explanation is necessary.

Just to close the loop, the noops look like this:


The nops can be replaced with goto out, which would make the 0x55 test actually bypass the checks.

I don't think it is immediately obvious to everyone (even those familiar with disassembly) that Bosch intentionally undermined their own checksum disable mechanism, in any case. When disassembling code, it is very confusing when the code you're trying to figure out does not do what you expect the original author wanted.

Yes but with every detail explanation, we are a step closer to understand it( at least in my case)

Agreed as most people would assume they would conditionally compile the feature out completely.

However I have seen this technique used before a few times. Way back when I was an embedded developer on RTOS's like VxWorks and pSOS, STOS, etc. in Assembly and C back in the 90's I saw this applied quite a bit. I.e. of inserting NOP's to remove a conditional branches for testing or forcing code to behave a certain way (e.g. in Safety critical systems like Medical, etc.). The rationale is its a defensive test strategy. The theory goes, you do multi-million dollar exhaustive testing on every route through the compiled code. By changing physical lines of code and re-compiling it could actually introduce other bug not seen before simply by the fact the code may have 'moved' or you did something you didn't mean to do. By simply removing the conditional branch on the original tested and already compiled branch of code its still the exact same code tested before except that single branched route through the code is no longer operational.
 

Very interesting that they left the mov and cmp intact and only killed the jmpa.

But it makes a lot of sense, looks like the customer wanted this to be disabled,
so they wont accidently ship out a version without checksumming or something else.

And the most predictive and pragmatic way to do that was to remove the jump,
as the binary could be intact and no code would move if they recompile it.

It could also be some old asm module they include like in every me7.
Looks like some code is already precompiled and included and some is compiled for every build.

The McMess routines for example are 99% identical in all ME7, even registers used match, so looks like it is legacy assembly.

Exactly as you've stated, I'm sure they exhaustively test on a per module basis.

Think about what can happen if they conditionally compile out code. The memory profile will change and some obscure bugs may end presenting themselves in subtle ways. I've seen this module disabled with nops and then enabled (jump left intact) and then subsequently disabled in newer versions of the same rom destined for same model year cars. Perhaps their testing strategy sometimes isn't as rigorous as they expect :)

I mistakenly thought this mod would remove the need to CRC check a file before flashing to the ECU, but it doesn't seem to do that for an ST10 7.1.1.
 I edited the code as described in this thread in the MPC for the ST10, and the EEPROM , then flashed a modded .bin. All went well, I had the motor running for 30 mins, then turned it off, had a break and it restarted a few times. Next day, the car would only engage the starter for half a second. VCDS showed that the ecu had the check sum error code.

Because it does not affect RSA.
To bypass RSA there's another mod that is required. Look where it's set (fault) and change the jump to always go the other way.
That will not only prevent it from getting set but will instantly clear if it was set previously.

RSA... far out, I have a lot of reading to do to locate the jump.  Meanwhile the problem seem to have been fixed by flashing the same 1MB  bin but after correcting it with winols. Only two bytes were corrected. I thought RSA signatures were bigger?  I'm worried that the modded MPC is a checksum time bomb as I cant find a way of correcting the checksum on that.
 I tried adding the original MPC to the original flash as an element in winols . It corrects a checksum in the flash binary. but it makes no sense as they are both originals there should be nothing to correct, so I don't trust it.

How about scrolling up a few posts and patching the mask besides only doing the 1st post?

Thanks prj, that did the trick!

I know is an old post but PRJ please let me know if for me7.5 8N0906018H - audi tt
I must modify
FLASH : "47 F8 55 00 CC 00 CC 00"
EEPROM PAGE 1 AND 2 : 69 C1, A5

and THIS TOO IN FLASH
"9A ?? ?? ?? DA ?? ?? ?? 49 81 3D 19"

THANKS

I tried this hack.
"In EEPROM change 69 C1, A5 to 8E 5A, D2. On page 01 and 02."

I tried on file modified with these modifications like PRJ said (but with my file address in step 3 what i found in step 2)
"
1. Search for "47 F8 55 00 CC 00 CC 00" (1 match)
2. Search forward for "E6 F4 FF DF", notice the address, save the last 4 bytes (0x69E0A -> 9E0A)
3. Change "47 F8 55 00 CC 00 CC 00" to "47 F8 55 00 EA 00 0A 9E" (use the last 4 bytes loHi)"
WORKS GREATE!

I left eeprom modified and i wrote a file without upstairs modifications , but i made checksum.
After some minutes i received error
16989 - internal control module - p0605 - 35-10 -  ROM ERROR - Intermitent

Can be because i left eeprom modified without modify ecu file with hack?

Thanks

Make sure to correct the eeprom checksum before writing as that can cause a lot of issues.