[user0086]

The argument that the converted file contains rubbish is not that relevant.

If it is not rewritten, it only takes up 1 or 2 of the 128 blocks of the dflash. The dflash does not get corrupted due to the static data, but due to the changing data. And the parts that are deleted by the Russian tool probably gets overwritten very quickly. So I think the argument from the Russian tool is made up.

Note that xprog and acdp create the exact same file as my converter. I expect that hexprog also does not delete any data.

I'll re-run the checks to see if I can see more X1s, but I think this is also not the case either.

I've also recently had 3 FRMs that could not even be formatted. The sector that contains the partition information was apparently broken. Tried with xprog and upa-usb (both original) and got exactly the same error.

Other than that, I think i've had a few that failed within 2 years and also a fair share of FRM3s that were repaired earlier judging from the tinned pads.

I think most of the time people don't even know that their FRM is repaired since the workshop who "broke" it by disconnecting the battery never informed the owner.

[jaki]

Let's continue with mysterious FRM problems:
Now I have two cases as follows.
1. normal FRM repair (ddd to eee). After repair in my bench (the car is in miles a way) light etc working ok, with tool32 read clear codes etc. So it looks like work 100%
2. When putting in car, every thing works 100%, lights, blinkers, windows etc, but:
cluster says (red car) that something is wrong in car. Also it gives error for all lights in car eventough everything works 100%.
How this is possible? Eg battery reset didn't help either.
The first case was solved witn an other helper (I don't know what he did). I assume there is something wrong in ddd also and that creates this problem.
I guess i have to find good eee dump and write that to frm. No problem if the car is in my garage, but how an earth i can assure this kind of problems in bench only?

EDIT: my misstake, again. I probable didn't code FRM at all after flash. There was a error code saying that coding index didn't match. After coding all good!

[HaakonA]

Jaki, you have repaired a large No of FRM3 perhaps you have an answer to my question, I would appreciate your thoughts

ACDP works well for repair on the 16 or so FRM3 we have done, when fitting a repaired FRM3 into a different vehicle we can code it into the vehicle & all works however the old VIN remains, any simple solution to changing the VIN before I waste a lot of time ?

[BimmerExperts]

Jaki, you have repaired a large No of FRM3 perhaps you have an answer to my question, I would appreciate your thoughts

ACDP works well for repair on the 16 or so FRM3 we have done, when fitting a repaired FRM3 into a different vehicle we can code it into the vehicle & all works however the old VIN remains, any simple solution to changing the VIN before I waste a lot of time ?

If you want to change UIF vin of FRM, you need to flash it with winkfp and make sure UIF write in comfort mode is checked in config. Tool32 will not change UIF vin you read in inpa. You don't need to change the vin of the FRM though, coding with ncs expert is enough.

[user0086]

Actually the VIN shall also be coded to the FRM using NCS Expert, and the integration level needs to be written with tool32. This information is used by ISTA to identify the car.
The VIN in the UIF, written by WinKFP is irrellevant, but the one written by NCS is important.

[jaki]

Actually the VIN shall also be coded to the FRM using NCS Expert, and the integration level needs to be written with tool32. This information is used by ISTA to identify the car.

What? I have understood that ISTA uses CAS to identify the car. I'm I right?

[BimmerExperts]

Actually the VIN shall also be coded to the FRM using NCS Expert, and the integration level needs to be written with tool32. This information is used by ISTA to identify the car.
The VIN in the UIF, written by WinKFP is irrellevant, but the one written by NCS is important.

Ista uses the CAS to identify the car and pull VO. Tool32 is not necessary for replacement frm modules, all you need to do is write VO and code with ncs. The person I was responding to was most likely inquiring about the vin you see in INPA > UIF which cannot be changed with ncs or tool32, but I mentioned it’s not necessary to change the UIF vin. But if he insists, must be done with winkfp

[user0086]

I have personally experienced incorrect identifications by ISTA/P after replacing just the FRM (with original and fully functional CAS3), and I have had customers with the same issue.

So I am positive that ISTA/P (at least my versions) by default pulls the VO and I-level from FRM on R56. That's why I recommend disconnecting the donor FRM when ISTA/P is identifying the car. That way, you force ISTA/P to pull the VO and I-level from CAS.