Shift Pointers
- Author: Michel Schmets
- Subject Matter: Programming
- Issues: Definitions & memory
First in a series
The automotive sector is rapidly following the IT sector and becoming more complex by the minute. To shed some light on this trend, I will discuss programming in a series of articles.
Where we used to have just a few basic electronic control units (ECUs) in a car, we are now seeing a “computer” for almost each aspect. The main reason for this is simply because over the years it got cheaper to produce a small module to handle every control in a door for example, then making a loom that will cover every switch and control we see in a door nowadays. Next to that, it was done to reduce weight and to reduce the types of different looms they needed for every model.
Different models use the same loom and the options are basically just programmed into the module.
These advantages do come with a price. It’s not only more vulnerable for (programming) errors, but diagnosing it almost looks like a job for an IT guy. This means that you are not only investing in the latest software and hardware to do the job, but you are also investing time in knowledge and skills more than ever.
I hope that these articles will not only educate you on the “how” and “why” we need to cover programming, but also hope to make you enthusiastic about programming and inspire you to get started with it tomorrow.
In this article, I will begin with the basics of control units. I will eventually get into subject matters like the differences between programming and tuning as well as cloning modules.
The basics of control units
Before we can discuss why we should start reprogramming units, or even perform an actual reprogramming, it’s best to understand the basics of ECU’s and TCU’s.
Since we started to replace governors and carburetors with solenoids, actuators and sensors, we’ve opened a door to a new era. Instead of a mechanical device using the laws of physics, we now have a computer that will make a shift or inject an amount of fuel calculated from a various amount of sensor data inputs and a piece of programming.
The complexity of these controllers has grown exponentially over the years. Not only did the amount of sensors tripled, but the accuracy and the resolution of the sensors are beyond anything we started with.
Alongside this, the program/firmware running these controllers may be the biggest change in this field. Where the first 4L60E computers worked with a 27c128 EPROM (erasable programmable read-only memory) with 16 KB, the latest TCUs use flash memory as big as 4 MB. Let’s put this in perspective.
The program running the first 4L60E fitted in a 16 KB memory. When you would print this on a paper, the program would be about five pages. With the latest TCU’s, the memory is as big as 4 Megabytes and is 256 bigger then the 4l60E program. So the coding behind this got massive. Instead of 5 pages, it’s now more than 1,000 pages of coding. This is accompanied with a drastic improvement of raw computing power. This draws so much power, that is needed to be cooled in oil.
So it’s without a doubt a big evolution of these systems. Where we normally would just make the transmission shift, we now incorporate an immense program that will calculate the best shift strategy for any condition, making the best fuel economy possible and deliver the smoothest ride imaginable while constantly measuring and determining the condition of the transmission and adapting where needed. And this can be very overwhelming. There are a lot of terms emerging in diagnostics that might not make sense to a typical technician. To help you with this, we explain some common terms below. Please keep in mind that the next list isn’t something you need to memorize, but knowing about it will help you get more comfortable with programming and understanding why this isn’t something we can’t ignore any longer, and it could help you whenever something goes south. When we look at any controller, you will see that it will have at least these basic components:
Processor/CPU: This is the main component on which everything around it is based. The CPU will run the program that is written for it and perform tasks like calculating loads, driver wishes and control outputs.
Memory: The program that needs to be run and all of the mapping are located in the memory. Nowadays this is mostly done by flash chips, as they can be programmed easily and are cheap. In the future, we will most likely see this memory to be incorporated in the CPU to prevent tampering with the program for tuning purposes.
Analog Digital Converter (ADC): As we know, computers are digital and they are binary-based. This means they can only work with a “0” or “1.” But an analog signal, for example a temp sensor, is anything but binary. So they use ADC to convert an analog signal into a digital binary signal that can be read by the ECU/TCU.
Digital inputs: We use al lot of different sensors, some of them are digital, others are analog. Digital signals can be used directly by the CPU without the need of a conversion. The transmission range switch, for example, is a digital signal that is fed to the CPU.
Outputs/drivers: Depending on the make and application, a controller can have many different outputs. These outputs are originally digital. But with the use of converters, we can output an analog signal, or use pulse-width modulation (PWM) to have more control, even though the processor is normally controlling the outputs.
Communication line: There are some controllers from the early ages that didn’t have a communication line. Those were the ones that would use blink codes to diagnose. But since those are ancient, we can say that every controller has a form of communication line. This can be a simple K-line or a high-speed CAN bus. This isn’t only for diagnostics, but more and more controllers will use sensors data from other modules to perform their duties. Converter slip for instance can be calculated by using the internal input speed sensor, and the engine rpm data found on the can bus.
Voltage regulators: This is often forgotten as it is so basic to have. But a lot of sensors operate on a 5-volt power supply.
For this, you have a voltage regulator in the controller to make sure the sensors get a nice stable voltage suited for their needs. If you have multiple errors concerning sensors, make sure this 5-volt power is stable and performing well over a period of time.
Memory
We discussed memory a little bit in the list earlier, but this is actually the center of attention when it comes to programming.
The CPU is basically a mule that has power but has to be instructed what to do. This is where the memory comes in. This memory contains the actual program the CPU will run for the operation.
In the old days this memory would be an EPROM with a size from 16 KB to 128 KB. They did their job perfectly in the old days, but in order to change the programming of an EPROM, you had to desolder it, erase the memory with a specific type of ultraviolet light, program it again, and solder it back in.
Today they use flash memory for this job. The speed of this memory exceeds EPROM by miles and it comes in very high capacity while still being dirt cheap.
One of the advantages of the flash memory is the fact that it can be erased electrically without the use of a different tool.
This makes it perfect for controllers that need to be reprogrammed with new software. But there is also a big disadvantage in this. In order to reprogram new software in a flash, it needs to be erased first. If you have a power failure during this, you might render the module useless. As said before, the CPU can only perform tasks, and to do this, it will have the program written in the memory. When this memory is empty due to a failure during programming, it will not have any instructions to start with.
These instructions also tell it to communicate, so in most cases you can’t communicate with the module afterward and will have turned the module into a paperweight. Whenever you encounter a program failure, don’t power-cycle. As long as the module is powered on, there is still a program for communication running inside the CPU. A power cycle would erase this program and might make it harder to recover the module.
Next to some flash memory, most TCUs and ECUs also have a little electrically erasable programmable read-only memory (EEPROM) in the controller. Like the flash-chip, this can be written and erased without special tools. This EEPROM contains vehicle information such as the VIN, immobilizer data and mileage. This information has to be preserved even when the software is updated and therefore is written in a different type of memory. This is also the reason why you can’t exchange TCUs in certain cars anymore. The immobilizer data is different, and the car won’t start/accept the used module.
There are specialists who can copy this information from one controller to another and it is called cloning. Another option is writing an unused or virgin program in this EEPROM.
Basically all vehicle data is removed out of the memory and the module will now accept syncing/marrying with the car.
Having a separate flash chip did make it more acceptable for tuning. One could remove the flash chip, read it with a programmer, modify the data and put it back in. This also makes the module repairable when it breaks down, or was “bricked” during programming. To counteract at least the tuning or software mods from third parties, the newer generation TCU’s have the memory incorporated into the CPU. This has several advantages. Since the memory is now inside the CPU, the data access is even faster. It’s also harder to read out the memory with a programmer, as you will need to have “permission” from the CPU to read/write the memory. We’ll discuss more details about this process are in the tuning section.
The biggest advantage for the manufacturer is the deletion of the removable/replaceable EEPROM, which contains the vehicle information. This part of the memory is now inside the CPU as well. While this piece of memory is writeable many times, the CPU is instructed to be one-time programmable (OTP) memory.
This means once that piece of memory is programmed with the vehicle information, you can’t erase or overwrite it and the module is permanently married to that particular vehicle. Not even the dealer can help you out with that. Only the manufacturer can reset the state of the memory and erase it by putting the CPU in a specific service mode. But like we’ve seen with previous attempts to discourage us to use second-hand modules, there are specialists who can indeed reset this memory state or even clone these units. But in most cases it means you will have to send the computer for repairs and miss it for a few days. So be careful and make sure you can re-use a second-hand module before blindly buying a unit.
