Want to tune your Z4 yourself? Check out Renovelo ByteTuner for MS45.0

[pokeybritches]

Who?
2003-2005 Z4 owners with the Siemens MS45.0 ECU. ByteTuner for the Z4 3.0i has been released. Z4 2.5i software will be released shortly, pending beta testing. Contact Renovelo if you have tuning experience and want to beta test their 2.5i software.

What?
ByteTuner is an all-in-one software tuning suite. Using a $30 cable, a user can read and write to the ECU, tune the file (with thousands of parameters defined), and data log through OBD.

When?
Available now for $250. Black Friday and Cyber Monday discounts are in the works.

Where?
www.renovelo.com
@renovelotuning on social media

Why?
Other options are available, both paid and free. None offer the complete package that ByteTuner offers, and no other tuning suite has every single map defined.

Read/write: There are only a handful of options to flash the MS45 ECU:

1.) MS45 Flasher

2.) “Professional tuning tools” costing thousands of dollars (KTag, KessV2, CMD Flash, Dimsport Transdata and New Genius)

3.) ByteTuner

MS45 Flasher offers the ability to read and write the ECU, but not edit. It has partial checksum corrections. MS45 Flasher successfully corrects the checksums that cover the area of the ECU where the basic maps are located, but it does not correct the torque tables, which must be tuned when adding forced induction or major engine modifications. MS45 Flasher setup is similar in difficulty to INPA, and without support since the software is freeware. As a paid program, ByteTuner’s instructions are thorough and explain the rationale to certain steps. ByteTuner setup was similar in difficulty to the setup of my professional tuning tools- not hard. Words can’t explain how much I appreciated the simple install.

MS45 Flasher is freeware and comes with limited support via forums. My professional tuning tools cost $10k (plus $1800/yr in subscriptions) and allow unlimited cars to be written. ByteTuner is $250 and includes one vehicle license. Renovelo charges $200 to license additional vehicles. The cost of entry is significantly lower with ByteTuner.

There are more than 20 software versions of MS45.0, even though the hardware may be the same. While the maps may be made up of identical values, they are located at different addresses in the ECU. Many professional tuning tools can only perform a “partial write” through OBD. A partial write is like it sounds- only part of the ECU is written, typically the calibration section where the ECU looks for values/maps (“parameters”). They cannot perform a “full write”, which alters the software version of the car, without physically cutting open the ECU and writing directly to the processor. If a tune is flashed onto an ECU from a different software version, the car won’t function, because the maps are not where the ECU expects them to be. Therefore, the tuner must create a separate tune for each software version of the ECU, and all parameters must be found individually when using other tools. ByteTuner overwrites the ECU’s software version upon its initial tune, so a tuner can make a single tune and copy it onto any M54B30 tuned with ByteTuner. This is a big advantage for ByteTuner, and it saves a lot of extraneous rework on the tuner’s end… not to mention that it eliminates the risk that a map could be misidentified when translating the tune among software versions.

ByteTuner does not allow export of an unencrypted *.bin file (the standard ECU file format). It uses a proprietary *.dme2 format, which is encrypted and can only be read by ByteTuner. A tuner can’t pull a file from another source and write it to the ECU via ByteTuner. In order to remote tune a vehicle, both the tuner and customer need copies of ByteTuner. I don’t think I need to explain why giving a customer the ability to view or modify a tuned file isn’t the best idea. This is one of my two gripes, and fortunately Renovelo is already addressing it through the development of a limited, flash-only program to serve as an end-user tool. From what I understand, Renovelo has a functioning prototype, so I’d expect this to be a non-issue in short order.

Tuning: The greatest feature of ByteTuner is that it has all maps defined. I was able to install Porsche 997tt injectors with the capacity to run flex fuel, and the car behaves like stock because I have access to the injector data. FYI, many tuning companies don’t adjust the injector values. They get away with it by using the smallest injectors possible that still get the job done. As a consequence, the tiny injectors leave minimal headroom for further power-adders. I’ve been able to solve the hesitation issues inherent in high boost MS45 applications, raise idle rpm to compensate for my lightweight flywheel, and tune out the SAP and rear O2 sensors. It’s even possible to modify the number of oxygen sensors the ECU uses for fuel trims down to a single primary O2 sensor (such as for a turbo manifold… hmmm…).

I’ve used BMW Editor / Bim-Tun, which has a great interface but a limited number of maps defined. ECM Titanium, another expensive professional tuning program, is meant for tuning a lot of cars a little bit (think “stage 1” with stock hardware). It only has about 20-30 maps defined. I haven’t used Dimsport Race Evo, but I understand it’s similar to ECM Titanium. There aren’t any WinOLS definitions (“Super Map Packs”) available through authorized resellers. I even purchased two files at $300+ each hoping that they would be similar enough to my Z4’s file that I could reverse engineer them, but there were too many differences. If you want to truly tune your ECU, there are certain maps that must be adjusted, and they aren’t defined with any other off-the-shelf software. There is one other way to define all of the maps in the ECU, and it takes proprietary files (which I have) and hundreds of hours of software engineering to build the definition file into an existing program like WinOLS. Or, you can spend $250 and buy a proven program that also flashes tunes, corrects checksums, data logs, and offers excellent support.

The next biggest advantage of ByteTuner is that it solves a checksum issue that arises when torque tables are modified. These tables must be tuned to have the car perform optimally, and a checksum has to be corrected when the tables are adjusted. If it’s not corrected, the car won’t start. To my knowledge, no other tuning software or tool corrects this checksum automatically. If you don’t know what a checksum is, don’t worry, because you won’t need to deal with them if you use ByteTuner.

ByteTuner is not a hex editor, meaning you can’t manipulate or search the raw data in your car’s file. Then again, there shouldn’t be a need to do so, since the maps are defined.

ECM Titanium does have some features that ByteTuner does not. Most importantly, ECM Titanium allows the tuner to load two files simultaneously. A “compare” function can be utilized to immediately find differences. Maps change color as they are modified, so the tuner can easily see which maps have been changed. This is helpful to ensure nothing is missed when tuning the 50+ maps necessary to build a good forced induction file. ECM Titanium offers the ability to revert to the original values at any time, as well as save maps. However, ByteTuner interfaces with Excel tables, and I’ve grown to like this method more because I can save all the maps into a single Excel file. ByteTuner has no subscription costs; ECM Titanium subscription costs are about $600/year, but the software is stored on a USB stick that can run on any computer. ByteTuner must be licensed for each computer on which it’s installed.

Data Logging: ByteTuner includes all of the features of ByteLogger, which is similar to BMWLogger. ByteTuner can log parameters that are essential to the tuning process, such as load (mg/stk), fuel pressure, and oil temperature. Load is an axis value on spark, Vanos, and injection maps; a tuner needs to know what cell the car is operating in to know which direction to modify the calibration. I monitored fuel pressure when I started running flex fuel, since ethanol requires up to 30% more fuel flow than straight gasoline, and I’m pushing 10 psi of boost on a stock fuel pump.

I prefer ByteTuner’s data logging features over BMWLogger, with the exception of one thing – Innovate LC-2 wideband integration. ByteTuner interfaces with a DATAQ multi-channel signal acquisition device, which is great for incorporating external sensors like boost pressure or WMI flow into data logs. However, I haven’t had good luck accurately capturing the analog voltage signal from the wideband. There seems to be too much noise to get a reliable reading, and I’ve tried it on multiple vehicles. This issue isn’t limited to the Z4, DATAQ, ByteTuner, or even the LC-2… a USB input directly into the laptop is generally superior to recapturing the analog output of a wideband controller. FWIW, HP Tuners has the same issue, and it’s considered to the gold standard among reflash tuning suites. Otherwise the DATAQ is a great feature, and it offers the tuner the ability to log almost any external sensor.

The wideband signal capture resolution is my only other big gripe with ByteTuner besides the lack of an end-user flash tool. If you’ve read any of my product reviews on the forums, you’ll know that I tend to be brutally honest; just two gripes with an all-encompassing tuning suite is pretty amazing. I’ve followed up with Renovelo, and they’re working to integrate LC-2 support once they finish their end-user flash tool. So, both gripes will soon be addressed.

Other Thoughts: Reflashing places an ECU in a vulnerable state; the first step is to erase the data that’s there. Having worked with many different tuning programs, nothing makes me more nervous than a buggy program with a half-finished interface. ByteTuner’s software is stable and aesthetically pleasing. The layout has been thought through. It’s obvious that considerable time was expended by talented people to develop the final product. The “feel” of the software is the cleanest and most polished of any tuning program I’ve used. It gives the tuner confidence that the program will perform as it should, and there’s no fear of bricking an expensive ECU.

Conclusion: It’s rare to come across software that is extremely powerful yet easy to use. ByteTuner is the ONLY program that has all maps defined, all checksums corrected, and data logs all critical parameters via OBD. Its features are beautifully integrated. Once the end user flash tool is released and LC-2 support is added, it will be the only program needed to tune a Z4. Even without these features, it’s the best tuning suite at any price point.

I’ve worked symbiotically with Renovelo for the past year or so, and I’ve been beta testing ByteTuner with success. I paid full price for the software. I was offered a partial reimbursement for my honest feedback and work as a beta tester, but I passed the discount on to a friend instead so that the forums could be assured an unbiased review. Overall score – 9.8/10!

[Steeler]

I can highly recommend the Renovelo software and whole heartedly recommend Josh at Severn Tuning for his abilities and systematic approach to tuning the MS45.0 ECU.

The owner of Renovelo during an exchange of emails regarding the tuning software said to me...” I am in good hands “Josh is sharp”

[Vanne]

Awesome to read and hear. My new tune is already in Josh's hands once my car is back together.

[Rekla]

Am I correct that there isnt a tune (hardware + software) for the E85/86 Z4M?
According to RealOEM my car has the following DME:
Z4 E86 Z4 M3.2 Programmed control unit DME / MSS70
There's no MSS70 in the ByteTuner Vehicle Compatibility List. A few E46M's as well as S54's are available but they require a MSS54-type DME.

Any development timeline for the MSS70?

[pokeybritches]

Originally Posted by Rekla

Am I correct that there isnt a tune (hardware + software) for the E85/86 Z4M?
According to RealOEM my car has the following DME:
Z4 E86 Z4 M3.2 Programmed control unit DME / MSS70
There's no MSS70 in the ByteTuner Vehicle Compatibility List. A few E46M's as well as S54's are available but they require a MSS54-type DME.

Any development timeline for the MSS70?

ByteTuner doesn't currently support MSS70 / Z4M. Feel free to contact Renovelo and request support. The only way to tune the Z4M yourself is to do what I've unfortunately had to do- spend $10k for a KessV2, ECM Titanium, WinOLS, and an MSS70 definition file. You could possibly get away with purchasing a PowerGate decoder and PowerGate reflasher instead of the KessV2, but the PowerGate isn't as robust as a full-on KessV2- especially for R&D work. Avoid the Chinese copies of KessV2/KTag. They will brick your ECU and come with zero support.

[Terraphantm]

Originally Posted by Rekla

Am I correct that there isnt a tune (hardware + software) for the E85/86 Z4M?
According to RealOEM my car has the following DME:
Z4 E86 Z4 M3.2 Programmed control unit DME / MSS70
There's no MSS70 in the ByteTuner Vehicle Compatibility List. A few E46M's as well as S54's are available but they require a MSS54-type DME.

Any development timeline for the MSS70?

Definitions files for the MSS70 are public and match the latest revision - so you're in a better position there compared to most BMW DMEs. Search for 9R20840S.a2l to find it.

Trick is the software. KessV2 is what most people use today I think. I've been toying with the idea of releasing MSS70 flashing software (I'm the author of the MS45 flasher, it wouldn't be a whole lot of work for me to make an MSS70 version). I'm not sure I want to release the RSA bypass method just yet, though it's not hard to figure out if you study what the paid tools do, or even freeware tools for other DMEs.

Also regarding MS45 flasher, you can disable that secondary checksum by setting val_mo3_swi_cal_cks to 0xA5. I'd be happy to look up the exact address for the newest revisions MS45 if people really want (no point in looking it up for all 20 something versions when anyone can update via WinKFP. Or I guess I could just patch it in, it's not that hard.

[pokeybritches]

Originally Posted by Terraphantm

Definitions files for the MSS70 are public and match the latest revision - so you're in a better position there compared to most BMW DMEs. Search for 9R20840S.a2l to find it.

Trick is the software. KessV2 is what most people use today I think. I've been toying with the idea of releasing MSS70 flashing software (I'm the author of the MS45 flasher, it wouldn't be a whole lot of work for me to make an MSS70 version). I'm not sure I want to release the RSA bypass method just yet, though it's not hard to figure out if you study what the paid tools do, or even freeware tools for other DMEs.

Also regarding MS45 flasher, you can disable that secondary checksum by setting val_mo3_swi_cal_cks to 0xA5. I'd be happy to look up the exact address for the newest revisions MS45 if people really want (no point in looking it up for all 20 something versions when anyone can update via WinKFP. Or I guess I could just patch it in, it's not that hard.

Agreed on the MSS70 A2L and latest software revision, as it matches the WinOLS super map pack I purchased. You could go that route. Only thing is, I'm not sure many enthusiasts are at the level where they can line up an A2L and matching *.bin file with something like ASAP2, and then know which parameters are appropriate to modify via hex editor. Enthusiast tuners will find the learning curve to be challenging, and I wish there had been more information out there when I was first learning. My expertise is in engineering and recalibration, and what I know of CRCs/checksums and the computer science realm has been self-taught. A holistic how-to guide which describes how to take an A2L and bin file and turn it into a set of maps that can be recalibrated is non-existent, and those that know how to do it learned from other industries (so far as I can tell).

WinOLS doesn't provide map explanations beyond the A2L either, so I guess WinOLS just offers an improved UI and tuning functions to do the same thing you could do with ASAP2 (or import the A2L into WinOLS if you have the paid add-on). One of the things I like about ByteTuner for MS45 is that there's no need to dig around the internet to find an A2L and *.bin for MS45. The maps are organized and laid out as soon as the software starts up.

Like with MS43, at one point I experimented with setting val_mo3_swi_cal_cks to 0xA5 in MS45. I couldn't find val_mo3_swi_cal_cks with the first software version I tried, because there weren't any identifying patterns I could use to determine the offset of that specific parameter. Its address did not seem to be relative to other maps' addresses; rather it was "buried" somewhere in the file. I found it in the second version I tried, but disabling it didn't completely solve the checksum issue.

Disabling val_mo3_swi_cal_cks did offer a roundabout solution though, which I was making due with until ByteTuner solved the checksum. Disabling val_mo3_swi_cal_cks allows the tuner to modify the load axis (mg/stk) in ip_tqi_ref__n__maf and ip_tqi_ref_mon, but not the actual values in the tables (newton-meters), so I was able to trick the ECU into calculating that it was making less torque. I'm not sure if the tables couldn't be modified because there's an additional checksum; or if one checksum's solution is included in the area monitored by another checksum (and so the order the solutions are determined makes a difference)... or something else. I was digging for a means to solve it myself when ByteTuner solved it. I assume it's a 32-bit CRC. Knowing how to do it would be useful, because MSS70 has similar tables and the same checksum issue. This is likely part of the reason why all aftermarket FI companies use alpha-n when they tune the Z4M: they can't modify the torque tables without figuring out the checksum, and alpha-n eliminates a lot of the background compensations. Only G-Power has figured it out in MSS70 AFAIK.

MS45 Flasher is a great tool, and it's hard to complain about a product that a subject matter expert has developed on their own and offered for free. ByteTuner has a few advantages IMHO in terms of ease of use and knowledge / time required to go from “stock to tuned”.

[Terraphantm]

It's not a CRC. It's a little bit hard to explain, but essentially the DME starts with an initial value of 0x123456789ABCDEF, and in the checked range 4 byte are added at a time as a 32-bit number. The final sum is what the stored checksum should be.

On the MS45, the pointers to the start of the range is stored at 0x60620, and the end pointer is at 0x60624. Trouble is the location of the checksum itself does not have a hardcoded pointer location within the binary. So to correct it, I would either need to manually go through every MS45 variant and just hardcode the correct location, or I would need to limit support to the latest version. I could do a pattern search too (IIRC the speedometer factor is near there), but if those values are changed, I’d lose the pattern. I didn't like any of the solutions.

On the MSS70 (and for that matter, the MSV70/80 and MSD80/81), BMW broke the 0xA5 bypass. So on those you either have to patch out the checksum routine in the program or calculate the checksum properly. The other way to cheat is to lookup what the DME *wants* to see by reading the correct ram addresses, and then writing that to the tune on a reflash. I used to do that until I figured out how to calculate the checksum.

I have been tempted to convert my E46 M3 to run off an MSS70 (and modify the software to run a MAP sensor -- the code is actually all buried in there), but ultimately I'm not sure how much I would gain from that over the MSS54 with CSL software (and I'd lose some fun stuff like shift lights).

[supergoat]

Holy giant wall of text!

Quick question, does it come with an "off the shelf" tune or is this JUST the ability to go in and do a tune yourself?

[pokeybritches]

Great info! You’ve probably saved me a lot of headaches.

Originally Posted by Terraphantm

It's not a CRC. It's a little bit hard to explain, but essentially the DME starts with an initial value of 0x123456789ABCDEF, and in the checked range 4 byte are added at a time as a 32-bit number. The final sum is what the stored checksum should be.

So it’s some sort of addition checksum? I’m assuming digits to the left of the 32-bit number are dropped (so for example, if the initial value is 0123456789ABCDEF, and the next 4-byte sequence was FFFFFFFFFFFFFFFF, then the resulting “sum” would be 0123456789ABCDEE)?

Originally Posted by Terraphantm

On the MS45, the pointers to the start of the range is stored at 0x60620, and the end pointer is at 0x60624. Trouble is the location of the checksum itself does not have a hardcoded pointer location within the binary. So to correct it, I would either need to manually go through every MS45 variant and just hardcode the correct location, or I would need to limit support to the latest version. I could do a pattern search too (IIRC the speedometer factor is near there), but if those values are changed, I’d lose the pattern. I didn't like any of the solutions.

How do you convert the values found at the pointer’s address to a range in the *.bin file? I’ve seen this in the A2L as well, where addresses of “FFExxxxx” are referenced. In my *.bin file, the values at both 0x60620 and 0x60624 start with “FFE”, but I’m not sure how to translate the 32-bit value into an address in the file.

Originally Posted by Terraphantm

On the MSS70 (and for that matter, the MSV70/80 and MSD80/81), BMW broke the 0xA5 bypass. So on those you either have to patch out the checksum routine in the program or calculate the checksum properly. The other way to cheat is to lookup what the DME *wants* to see by reading the correct ram addresses, and then writing that to the tune on a reflash. I used to do that until I figured out how to calculate the checksum.

MSS70 has a parameter similar to val_mo3_swi_cal_cks, it’s just called something different. I haven’t tested if the 0xA5 bypass works yet.

Originally Posted by Terraphantm

I have been tempted to convert my E46 M3 to run off an MSS70 (and modify the software to run a MAP sensor -- the code is actually all buried in there), but ultimately I'm not sure how much I would gain from that over the MSS54 with CSL software (and I'd lose some fun stuff like shift lights).

I’m not convinced speed density is the best way to run an engine with individual throttle bodies. Some RB26’s run a MAP + alpha-n, where load is determined by throttle position, and a fuel compensation table is layered based on boost pressure. The MAP sensor is tapped into the intake manifold, prior to the individual throttle bodies. I haven’t looked into where S54 MAP sensors are located, but if it’s post-throttle bodies, I’d be surprised if readings were as accurate as a MAF sensor. The challenge is the stock MAF maxes out at 1024 kg/hr, which is only about 350 hp (similar to MS45). I’m experimenting with scaling the input to allow for a high-flow MAF to be installed.

IMHO, the big advantage of MSS70 is the wideband O2 sensors.

Originally Posted by supergoat

Holy giant wall of text!

Quick question, does it come with an "off the shelf" tune or is this JUST the ability to go in and do a tune yourself?

It comes with a base file, which is the same as a stock file. It doesn't come with a "performance tune" unless someone decides to create one and make it freeware.

[Terraphantm]

Originally Posted by pokeybritches

Great info! You’ve probably saved me a lot of headaches.


So it’s some sort of addition checksum? I’m assuming digits to the left of the 32-bit number are dropped (so for example, if the initial value is 0123456789ABCDEF, and the next 4-byte sequence was FFFFFFFFFFFFFFFF, then the resulting “sum” would be 0123456789ABCDEE)?


How do you convert the values found at the pointer’s address to a range in the *.bin file? I’ve seen this in the A2L as well, where addresses of “FFExxxxx” are referenced. In my *.bin file, the values at both 0x60620 and 0x60624 start with “FFE”, but I’m not sure how to translate the 32-bit value into an address in the file.

Yeah that's the gist of it. I made a proof of concept python script that can correct the checksum ages ago, I'll see if I can dig it up.

Subtract the FFE (and sometimes it'll be FFF). With the MS45, the FFE and FFF prefixes are for the external flash while the internal flash is mapped directly. Of course when disassembling most addresses are derived by adding/subtracting from a table of contents, but that's a bit outside of the scope here.

FFE47340 (made up address) would map to 0x47340 in the external flash, or 0x7340 if you extracted the tune alone. Generally speaking I've found that the FFE prefixes are used to reference data within the parameter section and FFF for everything else on the external flash, but that's not a hard and fast rule.

Originally Posted by pokeybritches

MSS70 has a parameter similar to val_mo3_swi_cal_cks, it’s just called something different. I haven’t tested if the 0xA5 bypass works yet.

The parameter exists, but the code is no longer functional - it no longer bypasses the checksum.

Originally Posted by pokeybritches

I’m not convinced speed density is the best way to run an engine with individual throttle bodies. Some RB26’s run a MAP + alpha-n, where load is determined by throttle position, and a fuel compensation table is layered based on boost pressure. The MAP sensor is tapped into the intake manifold, prior to the individual throttle bodies. I haven’t looked into where S54 MAP sensors are located, but if it’s post-throttle bodies, I’d be surprised if readings were as accurate as a MAF sensor. The challenge is the stock MAF maxes out at 1024 kg/hr, which is only about 350 hp (similar to MS45). I’m experimenting with scaling the input to allow for a high-flow MAF to be installed.

IMHO, the big advantage of MSS70 is the wideband O2 sensors.

It works pretty well with the CSL setup, better than straight alpha-N would. The factory map input is on the idle rail. Technically CSL does alpha-N with a MAP and EGT based correction. Can't run a MAF when the inlet diameter is like 10 inches anyway.

And yes I agree the main advantage is wideband O2s, which I would like to run.

[pokeybritches]

Originally Posted by Terraphantm

Yeah that's the gist of it. I made a proof of concept python script that can correct the checksum ages ago, I'll see if I can dig it up.

Subtract the FFE (and sometimes it'll be FFF). With the MS45, the FFE and FFF prefixes are for the external flash while the internal flash is mapped directly. Of course when disassembling most addresses are derived by adding/subtracting from a table of contents, but that's a bit outside of the scope here.

FFE47340 (made up address) would map to 0x47340 in the external flash, or 0x7340 if you extracted the tune alone. Generally speaking I've found that the FFE prefixes are used to reference data within the parameter section and FFF for everything else on the external flash, but that's not a hard and fast rule.

No need to dig up the script, because I'm happy to report I've solved it! I built an Excel file that will solve for the checksum, and I verified it on several different software versions of MS45. THANK YOU!!! The information you gave me was the last critical piece.

[Terraphantm]

Originally Posted by pokeybritches

No need to dig up the script, because I'm happy to report I've solved it! I built an Excel file that will solve for the checksum, and I verified it on several different software versions of MS45. THANK YOU!!! The information you gave me was the last critical piece.

Nice! And for whatever it's worth, on both the MSV70 (N52 cars) and MSS70, the start/end pointers are located at 0x803B4 and 0x803B8. In this case you would subtract 0x800000 from the values stored there to get the real addresses.

Calculation is done the same way (start with 0x0123456789abcdef and add the values), but the high/low are flipped compared to the MS45. Using the example of adding 0xFFFFFFFF to the initial value, the checksum would be stored as 89ABCDEE 01234568

On the MSS70 820S/840S software, the checksum location appears to be 0x48ea8 / 0x8ea8

[pokeybritches]

Originally Posted by Terraphantm

Nice! And for whatever it's worth, on both the MSV70 (N52 cars) and MSS70, the start/end pointers are located at 0x803B4 and 0x803B8. In this case you would subtract 0x800000 from the values stored there to get the real addresses.

Calculation is done the same way (start with 0x0123456789abcdef and add the values), but the high/low are flipped compared to the MS45. Using the example of adding 0xFFFFFFFF to the initial value, the checksum would be stored as 89ABCDEE 01234568

On the MSS70 820S/840S software, the checksum location appears to be 0x48ea8 / 0x8ea8

Funny you mention it, I was trying to figure how to find the pointers in MSS70 last night via referencing the MS45 A2L and its pointers, and the MSS70 A2L. Thanks!

For some reason I can't get the checksum calculator to work with the MSS70 *.bin files I have. The pointers make sense, and the data section they reference makes sense (which includes the torque-related tables, and a nice 00 start/end byte). c_rom_cks_cal_l is obviously a mess, but c_rom_cks_cal_h is only off by one increment: I'm calculating 012345FC when it should be 012345FD. It's the other way around in another MSS70 *.bin file I have, where my calculation is slightly higher than what the ECU wants to see. I've tried increasing/reducing the data area, reversing the start/end of the calculation, and reversing the byte pattern (so instead of adding ABCD1234, I tried reversing it to 4321DCBA)... pretty much any combination I could think of within that data section. Do you know if there's a 4-byte section of data that regularly changes in the section?

[Terraphantm]

I'm not sure, I haven't looked that closely. This script has consistently generated valid data for me:

import struct
import sys

def CalcMO3CS(binary):
    CSLocation = 0x48EA8 #Location of checksum
    cs = ''

    for i in range (0, 2):
        binary.seek(CSLocation + 4*i)
        cs += format(struct.unpack('>L',binary.read(4))[0],'02x').rjust(8,'0') #Reads high/low checksums, returns MSB first
    print ('Stored CS: ' + cs)

    binary.seek(0x803B4) #Location of MO3 start pointer
    start = struct.unpack('>L',binary.read(4))[0] # '>L' = Read as Big Endian Long Unsigned
    binary.seek(0x803B8) #Location of M03 end pointer
    end = struct.unpack('>L',binary.read(4))[0] 
    index = start
    csCalc = 0x123456789ABCDEF

    while index < end : 
        binary.seek(index - 0x800000)
        csCalc += struct.unpack('>L',binary.read(4))[0]
        index += 4


    print ('Calculated CS: ' + format(csCalc,'02x').rjust(16,'0')[8:16] + format(csCalc,'02x').rjust(16,'0')[0:8])


if len(sys.argv) == 1:
    if sys.version_info[0] < 3:
        filename = raw_input("Enter path/filename: ")
    else:
        filename = input("Enter path/filename: ")
    print ("Note: You can also give filename as a command line argument\n")
else:
    filename = sys.argv[1]

data = open(filename,"rb")
CalcMO3CS(data)

[pokeybritches]

Originally Posted by Terraphantm

I'm not sure, I haven't looked that closely. This script has consistently generated valid data for me:

import struct
import sys

def CalcMO3CS(binary):
    CSLocation = 0x48EA8 #Location of checksum
    cs = ''

    for i in range (0, 2):
        binary.seek(CSLocation + 4*i)
        cs += format(struct.unpack('>L',binary.read(4))[0],'02x').rjust(8,'0') #Reads high/low checksums, returns MSB first
    print ('Stored CS: ' + cs)

    binary.seek(0x803B4) #Location of MO3 start pointer
    start = struct.unpack('>L',binary.read(4))[0] # '>L' = Read as Big Endian Long Unsigned
    binary.seek(0x803B8) #Location of M03 end pointer
    end = struct.unpack('>L',binary.read(4))[0] 
    index = start
    csCalc = 0x123456789ABCDEF

    while index < end : 
        binary.seek(index - 0x800000)
        csCalc += struct.unpack('>L',binary.read(4))[0]
        index += 4


    print ('Calculated CS: ' + format(csCalc,'02x').rjust(16,'0')[8:16] + format(csCalc,'02x').rjust(16,'0')[0:8])


if len(sys.argv) == 1:
    if sys.version_info[0] < 3:
        filename = raw_input("Enter path/filename: ")
    else:
        filename = input("Enter path/filename: ")
    print ("Note: You can also give filename as a command line argument\n")
else:
    filename = sys.argv[1]

data = open(filename,"rb")
CalcMO3CS(data)

The high/low flip threw me off, but I figured it out now… solved for both MSS70 and MSV70! I programmed a bit in C back in college, but I’m not familiar with Python. I downloaded it and was able to get the script to start. It may be a dumb question, but what file format is the script looking for? I tried entering the name of the *.bin file which I saved in the same folder as the *.ps1 file, but the window immediately closed. FWIW, the *.bin I have starts at 0x00000 rather than 0x80000. My Excel file gets the job done, but I think your script is a lot more elegant and less prone to introducing human error.

[Terraphantm]

I’m not sure how your tool would organize it, but the script is operating under the assumption that the file loaded is a dump of the external flash.

[pokeybritches]

Originally Posted by Terraphantm

I’m not sure how your tool would organize it, but the script is operating under the assumption that the file loaded is a dump of the external flash.

I'll keep working with it. Thanks for your time!! I greatly appreciate the help!

[mrtumnus]

Hi folks, sorry for resurrecting an old post, but.

I have a Z4 E85 2.5i 192hp M54B25. I would like to DIY flash it if at all possible.

I used to have a Saab 93 turbo, I took the ECU out, downloaded a hex file and flashing tool from the forum, wired up the recommended £30 CAN cable, and presto I had a great new map.

Can the same be done here? Are there known good compiled/hex files and free or cheap software tools with recommended hardware and instructions to do this?

I'm familiar with this type of work being an electronics and computer engineer all my life, but due to time limitations I basically need a file, a flasher and a cable I can join up and press flash.

Thanks!