Shift Pointers

• Author: Michel Schmets
• Subject Matter: Programming
• Issue: Programming components

---

Why Do We Need to Reprogram/Update Modules?

Part 2 in a series

To answer the question in the headline, we need to look at the programming of modules. Not the actual program, but the foundation on which it is based on.

As we discussed in the previous chapter, the memory contains the program that the CPU executes. This programming is often called software, which can be misleading, as the program running on your laptop to perform programming is also called software. Sometimes it’s also referred to “firmware” or simply “program.” In this section we will refer to it as “program.”

So let’s break down the program in its various “components.”

Routines: For the CPU to know what to do, the program contains “routines.” These will tell the CPU what kind of tasks to perform. For example, calculating the amount of TCC slip (subtracting input speed from engine speed) is a routine. But communication with other modules or adaptation is also a routine. These routines are run constantly, some more often than others as they have a higher priority.

Mapping: This piece of the program will determine operating parameters. As the routine is responsible for completing a shift, the question whether a shift is desired, is answered by the mapping. This mapping is a table that the routine uses to determine whether a shift is permitted. For example, the engine load is 30% and my current speed is 34 km/h, but I am still accelerating.

The routine then accesses the base upshift table and looks in the column of 30% throttle. The number in this box is the speed at which an upshift is permitted. If this would be 42 km/h, the upshift routine will not be executed. This is a very crude example as this upshift routine will also check the oil temp, water temp, etc. These are also tables and are known as “adders” and will add or subtract a value from the base table discussed earlier. These adders are also a part of the mapping.

Watchdog timer: In the first section we talked about how big programs are these days. This is due to more and more “maps” that are implemented, but also routines. As these routines are very complex, and impossible to test every single possible option while running this program, it might be possible for the routine to become stuck in a loop or stop working all together. A watchdog is a simple program that will start a timer in which a routine should be completed. If the routine gets stuck, the watchdog will take action to start a failsafe program to minimize the chance of damage and retain function of the transmission.

Cyclic redundancy check or CRC-check: To determine whether the program in the flash is valid and the program isn’t corrupted or altered without permission, it performs a CRC check to ensure data integrity. While this is a routine, it’s a priority routine, and it’s important to understand its function. Since the data in the program is binary, you could sum up all bits and see if the outcome would be an odd or an even number. If you would write this down, you can determine if the integrity is valid by always performing this check. The actual CRC check is way more invasive and complex, but follows this principle. When this CRC check fails, the TCM could stop working completely and inhibit starting the engine, or only perform in limp mode or anything in between. So if you ever have a car that has a CRC check error, the data in the memory is corrupted, either by a manipulation attempt, a bad programming or simply a defective flash chip.

Diagnostic and trouble codes: While this is a routine with a part of mapping (to determine the maximum operating values), it gets its own notification. This is because the diagnostic routines are different from the normal operating routines. When a diagnostic routine determines that the transmission is operating outside of the normal parameters, it can change the operating mode, overrule previously determined routines (TCC operating mode to reduce temp, for example), set codes or even put the module in limp mode.

Immense & complex

So you see, this is a very complex program that has to be written by the manufacturer. While the compiled computer code may fit into a 4 MB memory, the actual programming code written by the programmers is much bigger as it contains notes and additional info that is lost after it is compiled to computer code that the control module understands (Figure 1). Since the program is immense and complex, it’s almost impossible to be written by one person or even comprehended completely by a single person. And even though the code is checked by several programmers and computer programs, it might still have errors that would cause issues during certain operating conditions. These problems are known as “bugs” and can cause several complaints, including erratic shift behavior without a clear cause. These bugs are fixed throughout the lifetime of a module and are covered with the updates we use to reprogram the module.

So it’s wise to update the software (Figure 2) of the control module whenever you can to eliminate issues that might simply be a software issue.

Next to bug fixes, these updates cover much more. Known drivability or comfort issues are also addressed. But the new program can also contain improvements that will help to reduce wear or fuel consumption, and can even add functions.

The mapping in the program is pretty much untouched (unless it’s the cause of a problem), so that the drive experience is pretty much unchanged.

So you see that updating the programming can help you solve problems you didn’t even know you had, and can protect you from chasing problems you might think are caused by something you did during the rebuild.

Pitfalls

There are also some downsides on programming you have to keep in mind.

While most updating is done using online access, you don’t have actual access to the files that contain the programming. And unlike with tuning, the programming isn’t first read completely before it’s altered. This means that you can only update the software to a newer version, but can’t downgrade back to the old version (some exceptions are possible). So if the customer notices changes in the way his transmission drives now, you can’t revert back to the old software. Luckily this happens in very rare occasions.

The other thing you have to keep in mind is the fact that you could cause damage to the module when the programming fails. To minimize this to almost zero, please read the instruction from the manufacturer.

Also keep in mind that programming isn’t something that you do in between. These processes can last between 3 minutes to 24 hours. Especially BMW takes a long time as it has a different strategy when it comes to programming.

The number of modules in a modern car can go as high as 100, all working in harmony, each containing a piece of software and communicating with each other. If you would say that a car has only eight modules and for each module there are two software versions available, you can come up with 256 different combinations. That equals to 256 unique combinations with only two software versions for eight modules. If you would have the ability to test a car completely in two hours, and you would have 256 unique combinations, which means you would be busy for 512 hours.

Testing all these combinations to see if they work is nearly impossible and immensely time consuming. So BMW puts their money on “known good combinations.” So they update several if not all modules in one reprogramming session. That’s why it can take as long as 24 hours to reprogram a BMW as its complete software configuration is being rebuilt during programming, and you are not able to update the car if a module that is registered in the Vehicle Order from the car is not responding, or there are modules added to the car, but not registered to it (Figure 3).

So please make sure you don’t do this as a rush job and give it your undivided attention to ensure success.

The information being provided in these articles were originally presented at Choice Tech seminar held prior to the 2017 ReMaTec show at the RAI in Amsterdam for Automatic Choice.