NefMoto

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)

https://xyproblem.info/ (https://xyproblem.info/)

What is your end goal? Why do you need this?

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

If it takes you 10 minutes for a full flash on any of these, then you're doing something very wrong.
It takes way less time even if you flash raw hex, and even faster if you pack it correctly.

LIVE is not supported on TP2.0.
There is actually quite a bit of calram, and it is possible to make use of it, but I never bothered to develop it for TP2.0 due to low demand and the people tuning this old stuff not having money to pay for it in the first place.

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

Proper commercial flashtool will do calflash only. He wants per sector flashing.
Using commercial tools this is only possible in BSL or SBOOT mode, but not OBD.

EDIT:
That said, he is basing his 10 min flashtime probably on PCMFlash which does a RSA bypass flash every time, in effect flashing the ECU 3 times for each write.
Hence with a proper tool that does an unlock a full flash is under 5 minutes and a cal flash is under a minute iirc.

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. 

Between 7 to 8 minutes to be exact. I do write the first segment 3 times (that's about 1:30). One flash with the original data, second flash with the jump call for RSA bypass. Then I reboot the ECU and do a complete flash of all the segments. That would be on a fresh ECU with RSA active

I transfer chunks of 0xFFF with RLE compression. On a unlocked ECU, it takes about 6-7 minutes for a complete flash


I did use commercial tool, but for more flexibility, I'm using my own stuff


With PCMFlash on TP2.0, it is about 6-7 minutes

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.

For calibrations, are you refering to the CCP Protocol ?

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.

The bootloader is always executed from RAM, you can not execute from flash when it is being written.

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

Even for MEVD17 you can flash it once and then you can use live tuning after that.
I'm adding BMW soon.

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?

If you really need to do a lot of development then patch your code hooks and make them conditionally jump to ram if some bit is set in ram, if not just return back.
Then you can just load code into the running ASW on the fly.

You only have to flash if you need to add more hooks.

that seems like a better overall approach, thanks! feels cleaner than doing CAL flashes.

Thank you. I like those ideas, and I will look to use them in the meantime. Mainly looking to implement boost control and flex fuel capabilities on ME controllers

I also attached document that describe the CCP 2.1, if it can be of any use to someone. There is BypEtk_stAscet_C that has my interest at the moment, I have to study the code behind it and if B_ecudev is needed

https://mega.nz/file/tItyiCCa#w5LMN9FpTjFqmymp_8vfpbmQaqm2jGH6m4B-_hwvHw4

Keep in mind that CCP does not go through GW, so you will need to tap PTCAN directly (or change the CAN ID's to some other control unit not present in the car, but where the GW does not block comms).
You also need to bypass some checks in the ASW to enable it for calibration.