Glad to be here.

Hi All,

I am looking at how to remove an ECU from the ÎŜ†Ä control unit tree so that the car no longer looks for it. 

I have a Canadian G30 but fitted some EU seats in it. My passenger seat no longer has a control unit but only the seat heating module. But the car is still looking for the ecu "SMBF". It shows in red in the ÎŜ†Ä unit tree and BDC registers an error because it cannot talk to it.

What I tried to do is:

TAL Calculation:
1 - Read SVT IST from car (the ECU is not listed there since its not connected)
2 - Calculate SVT SOLL (the ecu re-apears, in red)
3 - Edit SVT SOLL to delete that ECU and save

VCM:
1 - load the modified SVT SOLL in both SVT Current and SVT target
2 - write SVT target to VCM

But when I read the car with ÎŜ†Ä the ecu show up in red again.

The only thing that comes to mind is that because my typekey is still the Canadian/US one the car expects a passenger seat control unit. So wondering if I also need to write a modified FA with European typekey then re-do the SVT steps in VCM.

If anyone can comment I'd appreciate your input.

Thanks!


EDIT:

I forgot to mention I also tried to enable VCM update after TAL processing in options and run a TAL processing without checking any of the ECU's. 
Likewise also tried to load the SVT target in VCM then just code any ECU to force VCM update.

Neither of these make the ECU go away either.

Hi everyone,

I’m currently dealing with a persistent swirl flap issue on my 2020 BMW X5 M50d (B57S Quad-Turbo) with 170k km. I am planning a full physical delete, but want to handle the software side myself using BimmerUtility and ė-šÝ§. I'm afraid of the flaps and snapping ruining engine.

The Problem:
I am getting fault code 2F8500 (Swirl-flap controller, position sensor, signal: Too low).
Live data under WOT confirms the severity — at 2930 RPM boost reads 3280 hPa against a nominal of 3859 hPa. At 4234 RPM it's 3431 hPa vs 4037 hPa nominal. Consistently ~600 hPa under target at full throttle. At partial load the actuator tracks fine (30° commanded = 30.21° actual, no fault). Failure only at the full-open extreme

The Hardware Plan:
Full removal of the rod and plastic flaps from the aluminum intake manifold.
Plugging the manifold hole.

The Software Questions:
I am looking for the specific FDL parameters in the DDE (DDE8) to permanently suppress these monitoring functions via OBD without a bench unlock.
After the physical delete I plan to do the ÎŜ†Ä adaptation reset (Vehicle Management → Service Functions → Powertrain → DDE → Adaptations → ABL) followed by FDL coding via ė-šÝ§ + BimmerUtility to permanently suppress the 2F8500 monitoring.

BimmerUtility Experience: Has anyone successfully used BimmerUtility to code out these specific checks on a 2020 G05? Is this DDE usually write-protected for FDL changes via OBD?

What I need specifically:
Confirmed FDL parameter names inside the B57S DDE CAFD to disable swirl flap fault monitoring — the master enable switch and any position plausibility checks
Whether anyone has done this successfully on a 2020 G05 via OBD without a bench unlock
Whether there are any secondary parameters I need to address to avoid blocking DPF regeneration after the delete
Has anyone done this on a G05 M50d or similar B57 platform? Any confirmed parameter list would be hugely appreciated — happy to post full results back here once complete.


Thanks in advance!

Hi everyone, I accessed my BMW F10 CIC Professional via FTP using FileZilla to copy into my pc the servicehistorie.bin file located inside the \HBpersistence\Hmi\data\rw 

The method I used was: 

1. Set my laptop's wired connection IP to 192.168.0.1; subnet mask as 255.255.255.0 and default gateway 192.168.0.1. Left DNS blank.
2. Opened Tftpd64 application and did the following:

* Went to DCHP tab
* Set IP pool start address to: 192.168.0.2
* Set size of pool to: 10
* Set default router to: 192.168.0.1
* Set mask to: 255.255.255.0
* Pressed "OK" button
* Selected 192.168.0.1 (ethernet connection) from the "Server interfaces" dropdown

3. I then connected the ethernet to ODB2 cable to the car and started the car engine.
4. I pressed and held down the radio power/volume button for 30 seconds
5. The iDrive screen restarted
6. I then noticed that the tftp32 application indicated that it had assigned 192.168.0.2 and 192.168.0.3
7. I visited ftp://192.168.0.2/ in my web browser and was promoted for a username and password
8. I entered "root" and "Hm83stN)" and logged in successfully for testing.
9. open filezilla and connect with ip 192.168.0.2, user root and password Hm83stN)
10. navigate to \HBpersistence\Hmi\data\rw
11. transfer file servicehistorie.bin
12. open SHMLITE
13. open file, select *.* and open servicehistorie.bin

Now, with SHMLITE i can see all service history, but in reverse mode.

If I add a new service, it will be placed at the beginning, not the end, in chronological order. 

Is that possible to developers create an application for edit that bin file, like SHMLITE with more options , like to reverse order, etc.. etc.. ?

Via ftp we can replace a saved file with all service history with filename servicehistorie.bin .

Hi everybody!

My name is Dario, I´m a german engineer and driving 6-cylinder BMWs only since 20 years. Fun fact: I´v never driven anything other than a six‑cylinder BMW, even my driving school car was a 320i :-)
On my E46, I started doing some coding with a Maxdiag 2 and would love to expand my knowledge on the F06.

Happy coding! 

I’m troubleshooting a KAFAS camera issue on a BMW E-series (E70 platform) using ÎŜ†Ä+ and ÏÑÞÀ.

The original problem was multiple KAFAS-related faults in ÎŜ†Ä, including no communication with headunit, lane departure warning, and all-round view camera, along with a general KAFAS malfunction.

I first tested the original camera module. In ÎŜ†Ä it showed an internal hardware fault and calibration failed. In ÏÑÞÀ the module responds normally and all voltages (1.8V, 3.3V, 5V, vehicle voltage) are within range, so power supply and wiring appear OK. However, the VIN from the camera shows as “yyyyyyyy” and VIN status says no access, which is not normal.

Based on that, I replaced the camera with a used unit (Continental KAFAS, similar part number). After installation, the replacement module behaves almost exactly the same. It communicates fine, shows proper hardware/software information, and all voltages and current are normal. But again in ÏÑÞÀ the VIN camera shows as “yyyyyyyy” and VIN status says no access.

I then attempted calibration in ÎŜ†Ä with both the original and the replacement module. In both cases calibration fails with the same message (camera dirty/covered, no movement in front of camera, or camera defective). There is no difference in behavior between the two units.

So currently:

• Power supply to KAFAS is OK
  
• Communication with the module is OK
  
• Calibration fails on both units
  
• Both show invalid VIN (“yyyyyyyy”) in ÏÑÞÀ
  

Hello, how do I extract the file according to the vin configuration with ėšÝ§?

Dme encoding….

Привет всем! Я автоэлектрик BMW из Украины, работаю в этой сфере с 2018 года. Я постоянно совершенствую свои навыки и хочу узнать больше о программировании и кодировании BMW.
I drive a G30 540 LCI
Хотел бы присоединиться к сообществу.