Hi, I have been trying lately to do partial OBD2 flashes on VAG MED17 controllers. On older controllers that uses the Inkonsistenz bit check, I was able able to disable it by using the subroutines that are intended for ETK device (Development purpose)

The inkonsistenz bit is reset by a "check programming dependencies" subroutine located in the customer block (CB) which I haven't been able to locate yet

I am wondering if anyone has bothered with this and might want to chime in. I'm seeking any informations or ideas. I'm trying to re-use the VAG subroutine to disable the inkonsistenz bit check and be able to go into ASW when doing partial programming

If anyone have those documents, I would be interested :
Partielle Flashprogrammierung MEDC17 (VW_AUDI_00155_REQ)
Partielle Programmierung von UDS−Steuergeräten, Nagler, VW AUDI (VW_AUDI_00127_REQ)

End goal is to be able to flash only the segments I alter to accelerate development on custom subroutine implementations or tuning on the dyno for instance. Going from 10 minutes flashes to 30s - 2 minutes flashes just like the MED17 on MB. I know the solution is to disable the inkonsistenz bit check at startup and I know on development version with ETK, there is a subroutine for that and it is stored in the CB. I haven't found it yet and I'm unsure if it is present in the production versions

For example on older Bosch controllers, there is a check for the following string "ETK71" and if it is present in the file, it will bypass the check and go directly to ERCOS

I am also aware VehiCAL offer a live tuning feature, but I'm working wth ME17.5 units (TC1766, TC1767) and there isn't enough cal ram for it to be useful. I also made a flasher and implementing partial flash capability for distributions would be an improvement overall

My X problem would be that if I erase and write only 1 segment on a flashing session, the ECU will not boot to normal operation due to the inkonsistenz bit

I think every better flashtool will do this from alone. Did you use any commercial tool or only your own stuff?

PCM Flash takes 3 minutes for a full write... Not too sure where you are getting 10min from? Alientech sure, pcm is one of the faster ones imo. 

So anyway, XY Problem.

For calibration use the built in live tuning into the ASW.
For development, OBD flashing is useless since you're most likely gonna brick the ECU anyway, hence it's much better to flash the ECU in sboot in the first place.
Also for development most of the code can be tested on the bench.

I can give some hints which may or may not be useful:

I did a similar job for MED9.1, and was able to patch in the functionality for writing only small blocks of the flash.

Start with setting up the code in Ghidra and set up the Memory Map and globals.
Next step would be to find the entry points in the ASW, just search for the service handler-table which goes like this:
"<Service-ID>ff ff ff"
"00 00 00 XX"
"<Address of corresponding service handler>"
"00 00 00 00"
"00 00 00 00"

I know for sure that this table exists in MED9.1 and also in MED17.x. Depending if its a UDS or a KWP over TP20 ECU, the Service ID will be UDS or KWP2000.

There will be multiple instances of this table in the file, one of the is responsible for normal diagnostics, the second one will be for the flashing process. Afterwards, you can look at the documentation which parameters go in and then document the parameters. This will help you to get a overview over the process.

You will notice a lot of calls like this:
FUNCTION (<eeprom-byte-nr>, buffer1,buffer2) - this is on both MED9 and MED17 the Save/Read Routines for the EEPROM. Document them usign the EEPROM layout mentioned in the FR and you get a overview where its exactly setting this inconsistency byte. Then you can remove the "setting inconsistency process" and you reached your goal. Next step would be to deactivate CRC-Checks to allow to flash small cal-area changes - this is something which i havent done yet.

However there is a catch(at least on MED9.1):
There is another different code, which is having a completely different style, and being copied to ram and then executed. This is being done to allow to flash the ASW area where this code resides normally. It does not contain this table from above, and uses a lot of crazy If-Statements. They had to cut corners to allow it to fit into the ram. If you spot it(usually a lot of references which do not make sense at all), leave it alone. For my custom code flasher, it was not required, as its only triggered if you use the factory process of flashing.

I guess Elias is suggesting that these bits are set in the ASW before it shuts down and the control is handed over to the bootloader?
On another note, how do you find what exactly is getting loaded into the RAM and when does that happen? I.e., does ASW load it before it shuts down, or more likely, customer block loads it and passes control to it? I am also not happy with factory bootloader, in my case it's MEVD17, there's no compression of any kind and full flash to unlocked ECU is 20 minutes.
P.S. well, looks like MED17.5 has a table like below for copying bootloader to RAM:
MEVD looks similar

that would be great! I'm not changing calibrations at the moment and doing some ugly "custom code" right now, but this still will be helpful.
In a mean time, I relocating some parts of the routines I wanted to hijack into CAL area, this way, I don't have to do the entire asw flash too often and make do with quick CAL flashes. perhaps this can be a solution for OPs problem?
P.S. when talking about MEVD17, are you talking only about F-series DMEs or are you planning to include E series DMEs as well?