No there isn't. And if you just modify a random unused area of the flash then this does not cause a crash, your problem is elsewhere.

What you Consider empty might not be empty or even exist. As fknbrkn said this can be a jump with the wrong offset.It might be a good idea to check the structure and the mapping of the areas you are working on.Easy way to check is to put your code without the jump or the call.


When i was working on my ST10 stuff i was using MPC for extra functions and storing the variables to Flash.

I've been testing the problem on the bench now, using vcds to communicate with the ECU as a check.

ECU is all back to stock except for the checksum off mods mentioned here

 http://nefariousmotorsports.com/forum/index.php?;topic=10926.0.

These mods have worked well so far, had no problem with either patched code in the mpc or modded maps, but with big modded chunks something isnt right.

I edit the bin directly with hexedit and upload it with galletto. If I copy some random maps and paste them on the free FF area after the last map at 8FEFD0 (also gave 8F1600 a go from above) , the ECU still boots and communicates via kwp2000, but VCDS cant get any info from it. No VAG number, no Component ID etc.
No fault codes show up either.
My logger also connects and disconnects straight away.
Its as if some part of the stock code is checking that area and partially crashes but the kwp2000 part still works??  A small amount of mod is tolerated but many bytes screw it up.
I will get rid of the checksum patches next and see if the same happens.....

+1

I may have missed something, but verifying even a 32-bit checksum takes time. So I believe that even with a bad checksum the ECU will work for a while.
If you are not changing CRC area everything will be fine for a couple of minutes.

Reset occurs for many reasons and usually it's a bad program code.

No, I'm talking about normal crc32. I tested it on MED17 and it takes a while for the ECU to detect the incorrect CRC.