[smilo]

Hi guys,
For those who are expert on flash with Esys, maybe you could have an idea for this headache -


During FRM3 flash, the process fails then the HWEL name changed ! of course, the TAL used has the correct HW-IDs from SVT (all others ECU flashed OK) - Strange !
After that, no way to flash again: Expected HWEL is then the new reference 
I tried to change manually expected HWEL reference in the Tal file, it allows the flash to begin: first BLTD flash line 0% appears, then fails again.
Anyone got this issue before ? maybe by using Tool32 or any manipulation with Esys -
Is there a way to write the correct HWEL (00000C7E_001_000_000 instead 00000D10_001_000_000)
The FRM is dead ?

[Breach]

Why did you flash with the wrong HWEL to begin with?

Recalculate SVT actual with 'Read ECU' instead of 'Read VCM' - that should give the real HWEL.

Changing just the HWEL in TAL won't work - the actual btld/swfl versions are different depending on the HWEL.

[smilo]

Why did you flash with the wrong HWEL to begin with?

Recalculate SVT actual with 'Read ECU' instead of 'Read VCM' - that should give the real HWEL.

Changing just the HWEL in TAL won't work - the actual btld/swfl versions are different depending on the HWEL.

No, I did not ! the flash has been accomplished with the correct HWEL of this FRM. This is why I really don't understand what happens..

Unfortunately, even with a recalculated SVT from ECU read, it matches the new HWEL reference. Then, it fails just after the first line of Bootloader flash. Because it tries to install a BTLD that matches the wrong new HWEL, but doesn't matches the ECU, I guess.

I tried changing the HWEL in TAL to keep the correct BTLD and SWFL expected to this FRM.

[Breach]

OK, somewhat confused though. How do you know the HWEL is actually different/has changed? When/where do you see 00000C7E_001_000_000 ? Do you still have your original SVT_ist? Did you use the correct istep shipment first time around? Were there any hwDeinstall/hwInstall operations? If you're sure it's 00000C7E_001_000_000 try putting it in SVT actual, not TAL - TAL is the final list of operations to be executed.

[smilo]

Yes, I store all information about the car before beginning the work (CAFD for all ECU, SVT from VCM and ECU read, FA, I-step Current and Ship, SVT_ist for each TAL, etc)
00000C7E_001_000_000 is the initial reference of HWEL of the FRM in the car from factory (with which was calculated the SVT for flash)
After the flash fails, the ECU HWEL switches to 00000D10_001_000_000 - this is what I can't explain the reason..
Yes, Istep used is the one stored in the VCM (shipment)
Champ to NBT retrofit done in the car two years ago
I think I also tried calculating a new SVT after changing SVT actual to the correct HWEL ref. of the FRM - but I will try again today.

[Breach]

So you had 00000C7E_001_000_000 in SVT_ist, SVT_soll and TAL before the flash, correct? And then it failed? And afterwards it changed to 00000D10_001_000_000 and fails again?

[smilo]

So you had 00000C7E_001_000_000 in SVT_ist, SVT_soll and TAL before the flash, correct? And then it failed? And afterwards it changed to 00000D10_001_000_000 and fails again?

Yes   it's exactly that -
I'm working on it right now (I'm on Esys)

---

I tried with new calculated SVT ECU read and after HWEL corrected to 00000C7E_001_000_000, but same error: expected HWEL does not match read HWEL (D10).

Then I changed it on the TAL, I have this error:

[FRM - 72 - btld_00000515-013_003_000] Transaction type: blFlash; Message: TA started [TRANSACTION]
[FRM - 72] performECUBLUpdate started with protocol UDS [PROGRESS]
MCDDiagService<id=56714, job=com.bmw.psdz.jobs.uds.MCD3_PerformECUFlashBL, service=RC_EM_IE - RoutineControl EraseMemory IndicatedErasing, description=error: negative response : generalProgrammingFailure, link=FRM_72_ETHERNET> [DIAGSERVICE]
[FRM - 72 - btld_00000515-013_003_000] Transaction type: blFlash; Message: 0% progress on ECUId:FRM_0x72 [0% of btld_00000515-013_003_000] [TRANSACTION]
[] job failed with negative response error:
code: repeat job
description: Service RC_EM_IE returned a negative response with response code generalProgrammingFailure; LinkName: FRM_72_ETHERNET
severity: ERROR
[THROWABLE]
[FRM - 72 - btld_00000515-013_003_000] Transaction type: blFlash; Message: TA finished [TRANSACTION]
[FRM - 72] There was an error during TAL execution, please check the log files. [WARN]
[FRM - 72] - [Exception - FRM - 72] job failed with negative response error:
code: repeat job
description: Service RC_EM_IE returned a negative response with response code generalProgrammingFailure; LinkName: FRM_72_ETHERNET
severity: ERROR

[Breach]

Bah, magic. I don't think the HWEL can change (outside of VCM anyway), and never saw a case when HWEL is changed that was not visible in the SVT comparison before the TAL execution. Are you sure that FRM is original, i.e. did you check the H/W on the ECU label ? What were the changes done to the FA at retrofit time? Especially, any related to the time criterion...?

[cursor]

Did You try to use option "HW id from svt" after calculate SVT_soll, and then flash?

[smilo]

Bah, magic. I don't think the HWEL can change (outside of VCM anyway), and never saw a case when HWEL is changed that was not visible in the SVT comparison before the TAL execution. Are you sure that FRM is original, i.e. did you check the H/W on the ECU label ? What were the changes done to the FA at retrofit time? Especially, any related to the time criterion...?

Yes, FA date is the thing I'm thinking about under this issue. It was set to 07/2013 instead 04/2011 - But SVT_ist calculated for the flash contains for 100% the HWEL from ECU.
The FRM is from factory with this car : in fact, there are several FRM versions ! supporting Xenon / adaptative LED / or Halogen. But in ETK, there is only one FRM reference for all F25 and even all F10 F07 F01 etc. I bought one on ebay retrieved from F25, but doesn't support Xenon.

I'm on ESys, any other idea to try ?

---

Did You try to use option "HW id from svt" after calculate SVT_soll, and then flash?

Yes tried, unfortunately without success