[_TB_]

Originally Posted by ChrizLoud

To get this in a 335D would be awesom. Alltough i know that its the same gearbox the gearbox control unit is different.
The same gearbox is used in X5M/X6M with another control unit. (it may have other mods to it)

This shows that it really got good potential but its reallt programmes/mapped really map from BMW

I'd love to get the software for the kombi in that video.. The rev counter moves waaay faster when changing gears than in the E91.


Try watching the video with the eyes closed, it does sound like it changes quickly - but looking at the visual movement of the rev counter makes us think it shifts faster than it really does. Perception is everything

The faster moving rev counter will make us think the shifts are faster than they really are.

[Works]

Originally Posted by _TB_

Well the Alpina works _really_ good in a 325d running 300BHp and 600Nm..

Upshifts fairly quick when just puddling around, but let's it rev to 5.000 when giving it the beans.

I do not see why you should shift manually more with the Alpina file.

Is one of you talking about the B3 Alpina file (gasoline engine, higher rev-limits, manual shifting required in a diesel) and the other about the D3?

Getting the D3 software to work with the gearbox in 330d or 335d would be the goal surely?

[ChrizLoud]

Originally Posted by _TB_

I'd love to get the software for the kombi in that video.. The rev counter moves waaay faster when changing gears than in the E91.


Try watching the video with the eyes closed, it does sound like it changes quickly - but looking at the visual movement of the rev counter makes us think it shifts faster than it really does. Perception is everything

The faster moving rev counter will make us think the shifts are faster than they really are.

Yes you are absolutly right.. Altough it shiftes very very fast with sport button engaged except from 1st to 2nd that is still noticible shift/power loss. (other shifts higher upp in gears is not noticble att all.. full power all the way

[RBT-Tuning]

Originally Posted by _TB_

Well the Alpina works _really_ good in a 325d running 300BHp and 600Nm..

Upshifts fairly quick when just puddling around, but let's it rev to 5.000 when giving it the beans.

I do not see why you should shift manually more with the Alpina file.

Good to hear that! Maybe the maps are heavily altered by adaptions during driving, but out of the box the shift points look fairly high for the diesel engines.

Mik325tds The hex position of all maps i discovered (>100) are the same in both 0da files. The 0pa's are a 99,99% match bytewise. Or do you mean anything else?

[RBT-Tuning]

Flashing in expert mode works fine!

I would need someone with a 335i and 6AT box to execute the "status_system_supplier_ecu_hw_nr" with Tool32 on his car. I'd like to see, if the hw# is the same. -> 1034420207

[Mik325tds]

Originally Posted by RayBan81

Flashing in expert mode works fine!

I would need someone with a 335i and 6AT box to execute the "status_system_supplier_ecu_hw_nr" with Tool32 on his car. I'd like to see, if the hw# is the same. -> 1034420207

Ok! That's a good first step. So you didn't need to supply a NAAB file (bootloader) for expert mode to work?
Regarding your question before - even though the daten file looks very much the same and has the same length doesn't mean they will end up in the same memory sector. Robert told me, that from variant to variant there may be different memory allocation of the daten sectors. If you now flash a different variant you might overwrite some areas that you can't recover later. That's why we wanted to get a full memory dump first so it is recoverable.

[RBT-Tuning]

No, I didn't have to. You can flash all 3 files indepent from another in expert mode. (boot, program, data)

I'm curious about the memory locations....I would flash just the Alpina 0da file with the *.ipo and *.grp from the GKE195 unit. So the data should end up in the same place, as with the original file. But i guess i will wait for Roberts response too...or at least try it on the bench first.

[Mik325tds]

Hm, I didn't know you could flash just the daten file of the Alpina.
I thought it would look for the correct program version to run with. But maybe that's a function of WinKFP comfort mode.
Anyway, Robert showed me his collection of memory maps for some transmission variants - it was scary. Not sure on how WinKFP/ECU decides on what goes where.

[rjahl]

Originally Posted by Mik325tds

Hm, I didn't know you could flash just the daten file of the Alpina.
I thought it would look for the correct program version to run with. But maybe that's a function of WinKFP comfort mode.
Anyway, Robert showed me his collection of memory maps for some transmission variants - it was scary. Not sure on how WinKFP/ECU decides on what goes where.

If it's like the DME the data is copied into the address as spelled out in the Intel hex/ ODA file.

Every program file 0PA file should have its own matching data files for that program version. I would not mix data files from different programs OPA files.

The hardware and history files should show the relationships.

[DWR]

Hmm, this is starting to get interesting again. Mik325tds, any idea when Robert might get back to you?

[Mik325tds]

Originally Posted by rjahl

If it's like the DME the data is copied into the address as spelled out in the Intel hex/ ODA file.

This can't be the case for the TCU. The data file basically has three large sections and the addresses in each section starts with 0x100000. Somehow another intelligence needs to know where to put it into memory.

Originally Posted by rjahl

Every program file 0PA file should have its own matching data files for that program version. I would not mix data files from different programs OPA files.

Agreed, this could have unforseen consequenses if it isn't detected by the program to begin with.

[Mik325tds]

Originally Posted by DWR

Hmm, this is starting to get interesting again. Mik325tds, any idea when Robert might get back to you?

I think Robert is just too busy to get back to you by himself. I'll have to start bugging him again. Just have to get my lazy ass off the couch.

[rjahl]

Originally Posted by Mik325tds

This can't be the case for the TCU. The data file basically has three large sections and the addresses in each section starts with 0x100000. Somehow another intelligence needs to know where to put it into memory.

What ODA file are you looking at? I would like to look at the Intel hex? Can you post it?

[DWR]

Originally Posted by Mik325tds

I think Robert is just too busy to get back to you by himself. I'll have to start bugging him again. Just have to get my lazy ass off the couch.

You can't call from the couch?

[DWR]

Originally Posted by rjahl

What ODA file are you looking at? I would like to look at the Intel hex? Can you post it?

Give this a try. Thanks for the help, rjahl.

[rjahl]

Originally Posted by DWR

Give this a try. Thanks for the help, rjahl.

The file looks straight forward to me. Maybe I'm missing something. I've attached a converted file that had no duplicated addresses.

I am far from being a computer expert but could you be interpreting in the Intel hex conversion incorrectly. Intel was originally written for 8086 processors and has a limited the number of bytes referenced. To use extended addresses they added a data type/procedure. Once a data type of 04 is called all subsequent addresses are modified by the value referenced in the line that called the "04 extended linear address record".

:020000040005F5

This line would modify the following lines by adding a prefix of 5 to the four byte address.

the third data line in the ODA file you provided is;

:10000000000000203E3BB2EA196FC89673DA306AEE

Using the conversion this line converts to the following

50000 00 00 00 20 3E 3B B2 EA 19 6F C8 96 73 DA 30 6A


http://www.keil.com/support/docs/1584/



Having said this, I went back and compared the Intel Hex files for the MSV70 against the actual BDM reads and they are not a 100% match. The BDM read has a little more data and one block, mysteriously moves from 0x60000 to 0x20000. This data block and the extra bytes are within the OPA data areas. The ODA segements are 100% match to the BDM read.

I need to see if I can take a full ODB dump from my TCU using my existing tools. I hate using ODB as it's so slow.

Traveling this week, so the car is at long term parking at the airport and I'm living in hotel rooms.

[Mik325tds]

Originally Posted by rjahl

The file looks straight forward to me. Maybe I'm missing something. I've attached a converted file that had no duplicated addresses.

I am far from being a computer expert but could you be interpreting in the Intel hex conversion incorrectly. Intel was originally written for 8086 processors and has a limited the number of bytes referenced. To use extended addresses they added a data type/procedure. Once a data type of 04 is called all subsequent addresses are modified by the value referenced in the line that called the "04 extended linear address record".

:020000040005F5

This line would modify the following lines by adding a prefix of 5 to the four byte address.

the third data line in the ODA file you provided is;

:10000000000000203E3BB2EA196FC89673DA306AEE

Using the conversion this line converts to the following

50000 00 00 00 20 3E 3B B2 EA 19 6F C8 96 73 DA 30 6A


http://www.keil.com/support/docs/1584/



Having said this, I went back and compared the Intel Hex files for the MSV70 against the actual BDM reads and they are not a 100% match. The BDM read has a little more data and one block, mysteriously moves from 0x60000 to 0x20000. This data block and the extra bytes are within the OPA data areas. The ODA segements are 100% match to the BDM read.

I need to see if I can take a full ODB dump from my TCU using my existing tools. I hate using ODB as it's so slow.

Traveling this week, so the car is at long term parking at the airport and I'm living in hotel rooms.

Learned something new today. Never really looked up the Intel Hex format.
Good stuff. Thanks for sharing and adding to the knowledge base.

I'd be very interested to see your full memory dump of the TCU. Please also read the AIF/UIF so we know which calibration data set you are using. Then we can compare it to the dump that Robert took.

[Tiago]

I'm trying to retrofit a E60 LCI gearbox (6hp28) into my E60 non LCI which has the 6hp26. I bought a non sport gearbox version that has this software into mechatronic: ZB nr. 7582468. Can someone provide me the original bmw coding file for this gearbox version?*

I have all the bmw updates and can't find the specific file for this gearbox.

[Mik325tds]

Originally Posted by Tiago

I'm trying to retrofit a E60 LCI gearbox (6hp28) into my E60 non LCI which has the 6hp26. I bought a non sport gearbox version that has this software into mechatronic: ZB nr. 7582468. Can someone provide me the original bmw coding file for this gearbox version?*

I have all the bmw updates and can't find the specific file for this gearbox.

Sorry. No luck in my collection of SP-daten...

[Tiago]

Originally Posted by Mik325tds

Sorry. No luck in my collection of SP-daten...

Thank you very much for trying to help. It seems that this file is a rare gem into bmw coding files list.

[iaknown]

Originally Posted by Tiago

Thank you very much for trying to help. It seems that this file is a rare gem into bmw coding files list.

Did you try the INPA guru Pawel? PM me if you need his info. He may be able to locate it

[808AWD325xi]

Originally Posted by RayBan81

Flashing in expert mode works fine!

I would need someone with a 335i and 6AT box to execute the "status_system_supplier_ecu_hw_nr" with Tool32 on his car. I'd like to see, if the hw# is the same. -> 1034420207

The 6AT in my 2009 335i has a different HW-NR:


My ZF 6HP21 TCU is flashed with the 4/23/2009 Alpina B3 flash. (ZB 7603537)