F30 - Problem coding an FLE for headlight retrofit (UNKN id, programming abort?)

[chambo622]

Hi folks,

I'm working on a retrofit of LED headlights on my car (2016 F31). I've successfully VO coded one of my FLE's and my FEM with 5A2 and that headlight works fine. However, the second FLE - currently in my car as FLE 44 - I haven't been able to successfully code.

As shown, the FLE currently has an UNKN_FFFFFFFF-255_255_255 value for HWEL. CAFD coding fails with the following errors:

Code:

[] SVK-Ist does not match expected SGBMIDs for ecu ECUId:FLE_0x44. Excpected (relevant process classes only): [btld_00002b41-007_000_000, swfl_00002b42-008_020_010], Actual (relevant process classes only): [unkn_ffffffff-255_255_255, btld_00002b41-007_000_000, swfl_00002b42-008_020_010], Missing SGBMID(s): [], Surplus SGBMID(s): [unkn_ffffffff-255_255_255] [THROWABLE]
[FLE - 44] There was an error during TAL execution, please check the log files. [WARN]
[FLE - 44] - [Exception - FLE - 44] SVK-Ist does not match expected SGBMIDs for ecu ECUId:FLE_0x44. Excpected (relevant process classes only): [btld_00002b41-007_000_000, swfl_00002b42-008_020_010], Actual (relevant process classes only): [unkn_ffffffff-255_255_255, btld_00002b41-007_000_000, swfl_00002b42-008_020_010], Missing SGBMID(s): [], Surplus SGBMID(s): [unkn_ffffffff-255_255_255]

Based on my research, this is due to the fact that the HWEL is not expected (UNKN_FFFFFFFF-255_255_255 is clearly some null/default value)?

I did some research and found that this can happen when the IStep versions are out of sync. This makes sense, because my car is F020-16-03-504, and the FLE in question is stamped with April 2016 (and I have no idea what the IStep version of the donor car was, it came from eBay). 

So, I tried following the ECU coding process to bring the FLE43, FLE44, FEM_GW, and FEM_BODY up to the same IStep version (using latest PSdZData files, 4.25.12, with ESys 3.30.1). So, I set my Ship and Target IStep versions as follows, generated the TAL, and then flashed only FEM_BODY, FEM_GW, FLE43, and FLE44 ECUs.

   
   

The first three worked fine, but FLE44 again failed with the exact same error as above. I also had to uncheck "hwDinstall" and "hwInstall" from the TAL-Processing list, otherwise it wouldn't attempt to flash them at all.

I also tried the process with clicking "HW-IDs from SVTactual" and then using that SVT to generate the TAL, but that doesn't work because there is no actual HW ID to read. 

After doing the above flash I again tried to do the CAFD injection technique from the "Coding" screen, but it still fails with the exact same error above.

I read elsewhere that this may be fixed by choosing the correct IStep shipment version for this donor ECU, but I have no idea how to figure that out.

How can I fix the UNKN_FFFFFFFF-255_255_255 ID on my FLE so that I can successfully flash and code it?

[chambo622]

Used ISTA+ to get some additional info and try to code that way

The FLER ECU shows up as blue - "programming abort" - in the map

There is a fault for "Programming abort detected." I'm assuming this was someone else, but it could have been me. I'm not sure what exactly a programming abort is, but it must cause an UNKN HWEL to be assigned to the device?

I tried to do a flash with ISTA+, but the process wont' start because it states that a hardware replacement is required. Presumably, this is the same "hwDeinstall" and "hwInstall" issue I saw when trying to run a TAL in ESys.

What else can I try to get this FLE back up and working? Will ISTA/P do anything different for me if I can get that running?

[chambo622]

For anyone who stumbles across this in the future, the solution was to just buy a new FLE. Worked on the first try after I swapped it out. If you have an ECU that shows "programming aborted" state in ISTA with UNKN HWEL in E-Sys, it's not easy to recover - there may be some way with Tool32 or WinFKP but nothing I could reasonably figure out. Save the trouble and replace it.

[Magustructor]

If the module is still responsive you could try to edit SVTist (actual) and set HWEL manually to the same as FLE43 (I guess both lamps comes from the same donor). Your have to change BTLD, SWFL and CAFD versions as well to something else (doesn’t matter what). Then based on that modified file calculate a new SVT target, which should let you reflash the FLE without the request for replacing it. I’d run just swDeploy on the first try of TAL execution. Then Read ECU again and if HWEL still wrong then run the others.
With a bit of luck with the HWEL guessing that way can recover the module.
Anyway it’s nothing to lose but a bit of time