355 - Hacking the F1 TCU | Page 2 | FerrariChat

355 Hacking the F1 TCU

Discussion in '348/355' started by Wolfgang72, Jul 12, 2019.

This site may earn a commission from merchant affiliate links, including eBay, Amazon, Skimlinks, and others.

  1. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    45
    Munich, Germany
    Full Name:
    Wolfgang Schmidt
    Your feedback motivates, thanks!

    Oh well let's see! Even though my story is retrospective, it's not finished at present.
     
    Qavion likes this.
  2. tbakowsky

    tbakowsky F1 World Champ
    Consultant Professional Ferrari Technician

    Sep 18, 2002
    19,349
    The Cold North
    Full Name:
    Tom
    This is awsome stuff..great work.
     
  3. carnutdallas

    carnutdallas Formula 3
    Rossa Subscribed

    Nov 11, 2010
    1,685
    Dallas Burbs
    Full Name:
    Rob
    Subscribed.... if anything. Looks like the ability to make a new F1 TCU has been accomplished and we can expect the wealthy client to recoup some RD expense with the sale of Wolfgang’s TCU’s :)


    Sent from my iPhone using Tapatalk
     
  4. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    45
    Munich, Germany
    Full Name:
    Wolfgang Schmidt
    #29 Wolfgang72, Oct 24, 2019
    Last edited: Oct 24, 2019
    Part 5 of Hacking the F1 TCU

    Now that I had the schematic, I turned my attention back to the software. It consists of thousands of lines of code. All of them would fill over 850 pages! Each containing plenty of commands, operands, conditions and branches. The first pages might still be understood. But then you'd quickly get confused by cross-references, conditional branches, dependencies and recursions and would lose the thread.

    Here's an extract of what it looks like - for just 21 lines of code:

    Image Unavailable, Please Login


    Never mind. Whenever it's getting complex, just divide the thing into small pieces. In this case it is exactly what a software architecture is for. It will organize my confusing dump of code, divide it into small, comprehensible modules and specify their interaction.

    There is a standard for software architecture in automotive industry, called AUTOSAR. Here's the story: Back then, when the ECUs got more and more complex the car makers realized that they need a proper architecture! On the one hand it must be powerful enough to address the increasing complexity. But on the other hand they were aware that a custom solution would hardly bring any advantage over their competitors. It's just an architecture, no customer would ever notice any difference here. Thus they didn't want to spend much money on that. Therefore they combined their resources and formed a consortium with the target to develop a standard for automotive architecture. The supplier industry was also part from the beginning. They were suffering from the fact that even though their functions were generic, they needed to provide a tailored integration for each manufacturer. The name of this consortium and also of the architecture is AUTOSAR.

    Unfortunately the first AUTOSAR version dates to the year 2005. That is a decade too late for the development of our TCU. What a pity! Of course, our TCU has an architecture. But I do not know its structure. Probably it is not standardized at all, but instead an in-house solution of Magneti Marelli. I wish I could interview the development team from back then! If they could've imagine that 25 years later, someone spends serious effort to get on their track?


    There was no interview and no answer. So I had to continue on my own. First I decided it would be useful to examine the signal interfaces. The WSM was a very helpful resource here:

    Image Unavailable, Please Login

    I started with the inputs, i.e. clutch speed, shift paddle, key position, etc. I found out that the code is similar for each signal type. Much effort is spent for plausibility and signal conditioning. Especially the filters are complicated. One day I came across a differentiation function which was especially difficult. I spend many hours on that. But finally everything fit together.

    Next, I took the outputs, i.e. solenoid valves, starter release, display, lights, buzzers, etc. I discovered that each output has a self-diagnosis. If the output does not take the requested level, it is switched off. Nice! Wait... I wanted to try that! So I took my TCU and made a decent short circuit at the output of EV4 solenoid! And indeed: the driver switched off after a few ms! Nowadays there are dedicated drivers for such things, but those are not used here. Instead, the outputs are monitored by software. An expensive but good solution!


    This way I continued my analysis with all signals. Overall it took several weeks until I finished. But I liked that work, it was kind of fun! I translated everything into pseudo C code and documented my results. This is the foundation for all later work! "If I've made a mistake, I'll get in trouble later. But I had worked thoroughly and that's why it'll be fine!", I thought to myself.

    This is a small extract of how my result looks like for self-diagnosis of EV4 (see description above):

    Image Unavailable, Please Login
     
    tgaspl17, Donovan355, 601 and 7 others like this.
  5. tbakowsky

    tbakowsky F1 World Champ
    Consultant Professional Ferrari Technician

    Sep 18, 2002
    19,349
    The Cold North
    Full Name:
    Tom
    Don't understand it, but I'm glad you are doing it..
     
    tgaspl17 likes this.
  6. Skippr1999

    Skippr1999 F1 Rookie
    Silver Subscribed

    Dec 22, 2009
    4,212
  7. taz355

    taz355 F1 Veteran
    Owner Silver Subscribed

    Feb 18, 2008
    5,942
    Indio Ca/ Alberta
    Full Name:
    Grant
    Nice write up
    Definitely subscribed
     
  8. ruey220

    ruey220 Formula Junior
    Rossa Subscribed

    May 24, 2019
    312
    Sf bay area
    Full Name:
    RM
  9. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    45
    Munich, Germany
    Full Name:
    Wolfgang Schmidt
    Part 6 of Hacking the F1 TCU

    When I started the reverse engineering of our TCU, none of my employees knew about it. The project was too small and insignificant to appear anywhere recognizable. This led to them becoming particularly curious when they discovered it! Soon everyone was talking about it. And it didn't take long until the first joking questions came when we would get a Ferrari as a company car!

    This was what came into my mind when I continued the task. I knew that sooner or later I would need to test how our TCU behaves in real life. So far, I did all my tests in the lab, where I had connected it to power supply and generated individual signals with a signal generator. But that was cumbersome. It also caused the TCU to store error codes, e.g. when the engine speed didn't match the clutch speed. Moreover it was unclear to me whether it also switches into limp home mode then, where it would behave completely different from what I expected to observe.

    I needed a solution. To the regret of my employees I decided against a Ferrari pool car. Instead I went with a test bench. Test benches are widely used in the automotive industry. In my case a usual HiL would do the job. It would simulate a complete environment for the TCU. Unfortunately, such a HiL easily costs 100k€. And that's just the device itself. To use it, you still need someone who programs and maintains it.

    This was out of the question in this project. My only option was to develop a small customized HiL on my own. It wouldn't be that powerful and flexible, but it would also only cost a fraction. Unfortunately, this meant that I would be busy developing the customized HiL for some time. Actually, I dislike interrupting my main task and starting a new one. But in this case I had no other option.



    I developed my customized HiL in modular way. There are multiple intelligent slave modules, one per signal type (input / output, analog / digital, ...). They do nothing else than to process their dedicated signals. Moreover there is one module acting as the master. On the one hand this master controls all slave modules and exchanges data with them. On the other hand it connects to a PC. There a software is running, with which I can control and display all data.

    Here is the hardware. On the front left side are the slaves for the output signals (orange cables) and on the front right for the input signals (yellow cables). Above that is the master. All modules are connected via an SPI bus and the master as well via USB to the PC. The metal box on the left side is just the power supply. The TCU is connected to the two large connections at the front.

    Image Unavailable, Please Login

    Hmm, looking at this I think it would have been better to not use a transparent case!

    Below is the PC software. It keeps all signals consistent and plausible to each other. Thus, from now on, the speeds match each other, the control arm can only take valid positions, etc. But of course it is also still possible to manipulate signals randomly if desired.

    The dialog is divided into two halves. In the lower you can do all adjustments whereas in the upper all readings are displayed.

    Image Unavailable, Please Login



    If I plug in everything and start the software, I can play around with our TCU. Here's how to work with it:

    You start at the bottom. On the far left, you first turn on the ignition and start the engine. The TCU then activates the clutch and tries to find the PIS. Right next to it you adjust the main signals, i.e. speeds and accelerator pedal. Afterwards you use the shift paddles in the middle to let the TCU engage a gear. On the right side, you can set up some other stuff, if you like (transmission mode, engine temperature, etc.). Finally at the far right, you can select the positions of the control arm and the clutch. However you will usually leave that in automatic mode, in which the positions are simulated from the existing data.

    At the top left are the common display signals, like relay status etc. However most interesting is the display on the top right. You have an oscilloscope there! It shows you how your TCU drives the solenoid valves over time and how the control arm moves accordingly! That's great, because you can measure to the millisecond, which solenoid is activated when and to which extent...

    ...which, as you remember, is essential for the exercise: Improve shifting times!
     
    tgaspl17, brogenville, 601 and 5 others like this.
  10. Badabing!

    Badabing! Formula Junior

    Mar 30, 2014
    731
    NYC
    It's amazing to me that there are people in the world who can and are undertaking projects to use modern technology to improve the reliability and functionality of older cars such as our beloved F355.

    I have recently availed myself of two such products, the turn signal relay ecu from scud ing swiss and the SDL ecu from technistrada.

    The turn signal ecu allowed converting all lights to led improving visibility, and other benefits including instant illumination, reduction of heat generation, and reduction of electrical load on the system. The ecu also allows for modem functionality of turn signals as found in newer cars.

    The SDL ecu functions as the original but accomplishing the same task using modern components for improved reliability and lower cost.

    These types of projects give hope that there will be solutions for the growing list of replacement parts that are becoming unavailable to help keep these cars running.

    My car isn't even an F1 and I'm still very excited about this project!

    It did occur that you (or your client) could buy a fairly inexpensive F355 to be a test vehicle. I would think an F1 spider would be the least expensive. Of course it can be resold when you are done for most if not all that was paid.

    Also, could you provide some more detail on the other solutions you developed for your client?

    Thanks for sharing this. Your knowledge and expertise is impressive and your clients love and passion for this car is inspiring.
     
  11. tbakowsky

    tbakowsky F1 World Champ
    Consultant Professional Ferrari Technician

    Sep 18, 2002
    19,349
    The Cold North
    Full Name:
    Tom

    This is really cool stuff you are working on. However I think a 355 f1 in rough but running condition could be had in the 50k area. Do your testing with it, then sell it off afterwords. Nothing like having the real deal car in front of you to work out the bugs.
     
  12. Qavion

    Qavion F1 World Champ
    Silver Subscribed

    Feb 20, 2015
    11,484
    Sydney
    Full Name:
    Ian Riddell
    Buying a real car, however, comes with the risk that the modifications will activate components at inappropriate times which could lead to the destruction of those components.... or the car. Investment lost.

    On this point... https://www.ferrarichat.com/forum/posts/146938016/
     
  13. tbakowsky

    tbakowsky F1 World Champ
    Consultant Professional Ferrari Technician

    Sep 18, 2002
    19,349
    The Cold North
    Full Name:
    Tom
    Exactly why it is best to test on a real car rather then a bench simulation. Just think of the lawsuits..
     
    Qavion likes this.
  14. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    45
    Munich, Germany
    Full Name:
    Wolfgang Schmidt
    Oh yes, you're right! In fact I had several options, but I chose an HiL intentionally.

    Imagine I had decided for a car. So I had bought one and it is available for my tests now. Next let's say I want to examine the gear shifting behavior. Not a problem: get into the car, start the engine, drive off, shift gear and examine. Fine. But what if I want to check shifting at full load? That would be difficult because I'd need to accelerate hard and would have to concentrate on driving. And it would be even more difficult if I'd want to test a 4-5 or even 5-6 gearshift at higher engine speed. That would work only on the autobahn and only if there is little traffic. Finally I sometimes need to do misuse tests, e.g. opening the hood or drivers door while driving. Which is not so good in a real car.

    In addition, tests in the car are hardly reproducible. It is also difficult to install my equipment there and, as I already wrote, I am always distracted by driving. Tests in the car are great if I want to judge the overall behavior. For example, how comfortable a shift is or how smooth clutch engages. But this is nothing I needed in the current project phase.


    Alternatively, I could've opted for a component test bench. Which would be a fully working F1 gearbox, i.e. mechanics, hydraulic unit, control arm, pump, hoses etc. That would be a nice thing! But the sensors are limited to what is actually happening on the transmission. I couldn't simulate an overpressure or a misaligned shift gate without stressing the parts a lot.


    My HiL can simulate everything. I can specify any driving situation. With extremely high accuracy and for any duration. If I wish I can let the clutch slip for 10 min. or simulate an engine overspeed. I can turn sensors on and off with just one mouse click. I can decrease engine speed from 1150 rpm to 1149 rpm, e.g. to find out when the automatic downshift is triggered. Moreover it's a small box, which I can put on my desk.


    Of course, this does not mean that the other options cannot come in future ;)
     
  15. Badabing!

    Badabing! Formula Junior

    Mar 30, 2014
    731
    NYC
    Any updates on this project?


    Sent from my iPhone using FerrariChat
     
  16. taz355

    taz355 F1 Veteran
    Owner Silver Subscribed

    Feb 18, 2008
    5,942
    Indio Ca/ Alberta
    Full Name:
    Grant
    Keep it coming Wolfgang very interesting stuff and you obviously know your stuff.
    I see a launch control button coming up for my 99 as soon as you build it.
    A reverse option for long backups, would that not be nice, I could dream up all sorts of options, so you select 6th, neutral, 3rd , neutral, and then reverse, computer now knows to fully engage the clutch in reverse so you can back up your buddy’s 1/4 mile long driveway.
    Who wants to down shift into first and with a blip and have the revs come up to 7500 instead of just locking us out.

    It’s amazing how well the internet brings everything to all of us. Without it we would still be replacing a whole f1 system with the same old dated system and paying through the butt doing it.
    Again you are truly gifted. Gotta love it!!!
     
    tgaspl17 likes this.
  17. 601

    601 Karting

    Dec 19, 2010
    223
    California
    Eagerly awaiting chapter 7.
     
  18. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    45
    Munich, Germany
    Full Name:
    Wolfgang Schmidt
    Allright, here we go!


    Part 7 of Hacking the F1 TCU

    The HiL was a decent boost for my project! Together with my debugger it gave me major control over the software. I used that to stimulate the TCU with particular signal patterns and then examined which parts of the software got activated. By logging that I generated a kind of "heat map". Step by step I roughly found out where functions like Shift Logic, Auto Mode, Pump Control, OBD etc. are located. One day I came across the driver of the instrument cluster. I couldn't help but had to play around with it!

    How does it work? First of all the display as well as the three lights for low friction, auto mode and malfunction warning appear as a single unit to the TCU. They are all connected via the same serial data bus. It uses the RS-232 protocol, which is well known from the PC. Every 100 ms our TCU encodes all data to a frame of 8 bit size and then sends it to the cluster. That takes the frame, decodes it and then drives display and lights accordingly. The structure of the frame is as follows:

    Image Unavailable, Please Login


    Unfortunately the display is not able to display random characters. Instead the only supported characters are "R", "N", the numbers 1 to 6 and dark switching. For unsupported data it outputs "F". However for a little gimmick that should be just enough! Something I can present to my client to jolly him along. Like... a start screen! I was sure he would enjoy that one as it would customize his F355.

    Writing the software was simple and a quick test on my HiL showed no errors. But nevertheless I decided to do a proper test. What a disgrace if it wouldn't work for my client! So I bought a display unit.
    Image Unavailable, Please Login


    It was worth the money. Indeed it turned out that the display needs a few data frames before switching dark. I fixed the timing and ran a few tests again. Then I finally sent the improved TCU to my client. After a few days I received a message from him. And as expected: he loved it! Here is a small clip he made:





    But let's get back to more practical things. As you know your instrument cluster tells you in various ways about the status of the TCU. I am unsure if all of them are known to the community. At least I didn't find them in the WSM, so here is an overview.

    For one, there is the gear display. If the display is steady it simply shows you the engaged gear. But perhaps you once had the case that it flashes. This happens when the TCU detected that the control arm is outside its self-learned limits. The TCU then cannot determine the engaged gear position and considers it as invalid. To indicate this to the driver it makes the gear display flash.

    Next there is the malfunction light, of course. It is activated if the TCU detected a confirmed fault (a fault is considered as confirmed after it got debounced). But not all types of fault are relevant, only:
    -Digital and analog inputs (speed signals and signals of control arm, shift paddles etc.)
    -Digital outputs (solenoids, relays etc.)
    -Self-learned gear positions (result of what Ferrari calls "octopus" in their WSM).
    Additionally the buzzer will start to beep after around one second. When the fault is not present anymore, it stops (however the light stays on).
    The malfunction light can also flash. This is to indicate you that the hydraulic pressure is too low. If it drops below 42 bar (appr. 610 psi) for more than 300 ms, it starts to flash. If it raises above that level again, flashing stops.


    Allright, knowing all that will help you to find out what bothers your TCU. For example: If the malfunction light is activated continuously, a confirmed fault is stored. If the buzzer is also activated, the fault is currently present. You could now start to check all sensors, cables and whatsoever. If you're having a loose connection or a bad connector, chances are that you solve the issue temporarily by just touching the part. Which you will notice as the buzzer immediately stops.
    If on the other hand the buzzer is not making noise from the beginning, a fault is stored but currently not present. Which means it wouldn't make sense if you pull your voltmeter now. Instead you could try to (cautiously) stress the sensors, cables and connectors and check for which the buzzer starts to beep.
     
    tgaspl17, Donovan355, 601 and 2 others like this.
  19. Qavion

    Qavion F1 World Champ
    Silver Subscribed

    Feb 20, 2015
    11,484
    Sydney
    Full Name:
    Ian Riddell
    Lot of excellent tips, thanks!

    That startup display is cool (especially considering the limitations you had).

    Do you mean analog?

    I guess the buzzer is analog. It would be cool if the ECU actually told you what was wrong with the car, either by audio or codes on the instrument display (without requiring the use of an SD1 tool)
     
    Badabing! likes this.
  20. tres55

    tres55 F1 Rookie
    Rossa Subscribed

    Sep 18, 2012
    3,481
    Canada
    This is amazing work. Thank you for your continued efforts!
     
  21. Subarubrat

    Subarubrat Formula 3

    Apr 1, 2009
    2,072
    VA
    Full Name:
    Scott
    IF this manifests as a replacement TCU or some modification such as a daughtercard with new firmware and communication path for diags then we could all benefit, I would be a buyer.
     
  22. Skippr1999

    Skippr1999 F1 Rookie
    Silver Subscribed

    Dec 22, 2009
    4,212
    For one, there is the gear display. If the display is steady it simply shows you the engaged gear. But perhaps you once had the case that it flashes. This happens when the TCU detected that the control arm is outside its self-learned limits. The TCU then cannot determine the engaged gear position and considers it as invalid. To indicate this to the driver it makes the gear display flash.



    This is interesting because Dave Helms posted here in the past that the flashing gear light was just a apparition of some kind and wasn’t signaling anything wrong with the system. He stated the “Only signal going to gear indicator light is a “counter” signal”.
     
  23. taz355

    taz355 F1 Veteran
    Owner Silver Subscribed

    Feb 18, 2008
    5,942
    Indio Ca/ Alberta
    Full Name:
    Grant
    That was a long time ago but it’s definately low pressure as it’s happened to me
     
  24. taz355

    taz355 F1 Veteran
    Owner Silver Subscribed

    Feb 18, 2008
    5,942
    Indio Ca/ Alberta
    Full Name:
    Grant
    Excellent work still waiting for my new launch control ha ha
     
  25. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    45
    Munich, Germany
    Full Name:
    Wolfgang Schmidt
    Buzzer is digital as it's only on/off. There is an overview on all pins in the WSM starting at page D36. Even though it is not 100% accurate. The buzzer for example is listed as frequency output. Indeed it is connected to the TPU internally which is capable of generating frequencies. But in fact it is not configured like that and outputs only two states: on and off.


    I just checked that at the HiL and it definitely starts to flash as soon as the control arm position is out of range. For low hydraulic pressure the malfunction light starts to flash.


    Great ideas! Well, having a clutch which fully engages in reverse is simple. It's two data words, that's all. (Pretty sure, even though not verified: change addresses 0x14508 and 0x1457E both to 0x4E71.)

    However a launch control is a completely different story. Not only that you have to spend many hours on concept and coding. You also have to perform many tests which will stress your car a lot. The best approach certainly would be to take a look at the 360 CS TCU. Read out its software, find the corresponding code section, extract and modify it for the 355 TCU and then implement it.


    The existing solutions like Galileo are worth their money. Anyway I am not the right one to make existing solutions cheaper. There is no inspiration and no excitement. Apart from that - already this job is far from my usual business.
    Of course I understand your motivation. So if you have some skills and like to give it a try, just tell me and I will support you.


    Thanks to all, I appreciate your feedback!
     
    tgaspl17 and Qavion like this.

Share This Page