News

355 Hacking the F1 TCU

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

  1. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    8
    Full Name:
    Wolfgang Schmidt
    Hello there,

    My name is Wolfgang. I own an engineering office in Germany. We offer solutions to the Automobile Industry, mainly in the field of Functional Safety. I like to start a blog here, which you might find interesting as it is related to the F355. If you enjoy it, I will update it once in a while.


    Everything started a few years ago, when a friend of mine called me. He told me about another friend that would need help with his F355. He asked if I could call him and gave me his contact details. I was busy on my job, but called him the next day.

    The guy told me that he's driving a F355. It was a present of his father when he was younger. He's in love with that car. He loves its shape, its smell, the way it drives and especially, as so many do, its beautiful sound. He explained that he often opens the exhaust flap to hear this symphony. Unfortunately he cannot keep it open all the time. In some situations he said it would be adequate to close it, e.g. when leaving his neighborhood, parking in the city or even when idling in general (it would smell bad then, he explained). Then on the other hand he likes to have the flap open constantly, e.g. when downshifting before hard acceleration, revving in idle and so on. Right now he always has to push a button which he thinks is annoying. He asked me if I would be able to develop a circuit that would do this automatically.

    Actually my clients are in the automotive industry and I initially thought to reject. I explained him that private clients are out of my scope as they're simply not profit-making. He was very friendly and asked for my usual fees. After I told him he indicated that he doesn't bother much about them. I added that there are more reasons I'm not doing business with private clients. But after some discussion he sorted out all of them. In the end I had him agreed to conditions that were very favorable to me. I had no reason left over why I should not accept the task. So I did it.

    We agreed on a prototype. The next weeks I developed a circuit according to his wishes. Then I sent it to him. He tried it out and was very pleased on the result. In the next months he came up with improvements, some of them quite challenging. He had a lot of ideas and I had to do a lot of modifications. But finally I was able to satisfy them all.

    During that time he sometimes also asked for special jobs. He had a problem with his heater ECU and asked me to repair it. Another time there was a problem with his exhaust temperature controller. The case was broken. I explained him that it would be way cheaper to buy a new unit. But he answered that he already did but it didn't last long. Therefore he now wants a custom solution. I helped him. Working with the industry can be a dry task and so with time I found his jobs somehow inspiring. Just as well I was pleased how easily he paid my fee (which I'd consider as reasonably high for private customers). Over time I became somewhat like a personal electronic engineer for his car.

    From time to time we chatted about personal stuff, too. A few times I emphasized how much I like the F355. He never disagreed - until he once replied: "Wolfgang, I love my F355 very much. But one thing annoys me. It's the gearbox. It's a robotized box and was cutting edge back in the 90s. But to be honest, it's dead slow! It was back then - and nowadays it’s even more!" Well, I didn't know the gearbox and kept quiet, so he continued: "What do you think, would it be possible improve it? I would really appreciate to have proper shift times!"

    I was aware that this task would be huge! Completely different than what we did before. Apart from the engine computer the TCU is the major powertrain computer. Hacking it would be very complex, time consuming and virtually unaffordable! I had the feeling he thought it would be similar to overclocking a computer, but that’s nonsense. Of course. I explained it to him. But to my surprise he didn't care much. Instead he asked, if it would technically possible. I confirmed it would be. Theoretically. But practically will exceed the price of several F355. He asked for an estimation. I confess, with my answer I also had the idea to impress him. Anyway I mentioned an amount of several hundreds of thousands Euros.

    Obviously money is not a thing to impress him. He suggested: "Let's do the following. You'll assign one employee to this task and I'll pay his salary. Plus some fee for tools etc. If we find out that we won't succeed, we will cancel the job. But let's try before!"

    I must admit I knew that my customer is very wealthy. Anyway I was very surprised how much money he's willing to spend on his hobby! For that amount I'd buy a flat in our city - but that's of course something he already has.

    We spent some more time on our discussion. It appeared that he was fully aware of all implications. Again the risk on my side was quite low as I would get paid by time. He also was not my usual clientele so I was not afraid to risk my reputation. Moreover the first steps wouldn't be much difficult. I could assign my new employee on the task. So in the end... I accepted!
     
    flat_plane_eddie likes this.
  2. nycbrose

    nycbrose Karting
    Rossa Subscribed

    Aug 11, 2014
    90
    Bellevue, WA
    Full Name:
    Ambrose
    Very interesting! Please do share updates and would love to see videos of the resulting work per your client's approval!
     
  3. SoCal1

    SoCal1 F1 Veteran
    Owner

    Jun 14, 2011
    7,882
    SoCal LA/OC
    Full Name:
    Tim Dee
    They are reproduced already. An adjustable one would be insane :)

    Rod Drew, Costa Mesa CAlifornia

    http://ferrarioc.com/
     
  4. Skippr1999

    Skippr1999 F1 Rookie
    Silver Subscribed

    Dec 22, 2009
    2,614
    Charlotte, NC
    Full Name:
    Skipp
    This would be fantastic.
     
  5. JazP

    JazP Rookie

    Feb 23, 2013
    22
    Who's reproducing them?
     
  6. Drock28

    Drock28 Formula 3

    Jan 13, 2013
    1,311
    Montreal
    Full Name:
    Tony
    appreciate your post and enthusiasm, but if I'm understanding correctly, you are charging the guy "several hundred thousand" to retune the 355 F1 TCU..?
     
  7. johnk...

    johnk... F1 Veteran
    Owner

    Jun 11, 2004
    7,168
    Just a thought but it would seem to me that the speed of a shift on these gen 1 F1s is more a function of mechanical limitations than the TCU. Things like clutch dis/engagement and gear engagement, hydraulic pressures and ram sizes, etc.
     
  8. Qavion

    Qavion Formula 3

    Feb 20, 2015
    2,481
    Sydney
    Full Name:
    Ian Riddell
    You mean like the standard F355 does it automatically?

    Wouldn't it be cheaper to fit a later model F1 system to the car rather than attempt a software fix? I think there would be software and hardware improvements required.

    See this thread on Ferrari F360 F1 upgrades:

    https://www.ferrarichat.com/forum/threads/faq-how-to-upgrade-a-360-f1-tcu-to-a-360-cs-tcu.239882/
     
  9. SoCal1

    SoCal1 F1 Veteran
    Owner

    Jun 14, 2011
    7,882
    SoCal LA/OC
    Full Name:
    Tim Dee

    LOL yeah they are clunky by todays standards. Lets do a 458 trans swap maybe the engine too well maybe just get a 458

    :) Image Unavailable, Please Login
     
    Steve355F1, BOKE, ernie and 2 others like this.
  10. Subarubrat

    Subarubrat Formula 3
    Silver Subscribed

    Apr 1, 2009
    2,054
    VA
    Full Name:
    Scott
    Lets see some pictures.
     
  11. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    8
    Full Name:
    Wolfgang Schmidt
    The point is not my fee. I'm doing business with the industry and for my best specialists I'm charging a daily rate of well over two thousand. And they are worth it! But the point is that there is an enthusiast, which is capable of doing business on that level! I was really impressed (and still am).


    I learned that the standard F355 opens the flap simply according to engine load. The circuit for my client instead has four modes: Permanently open, permanently closed (with component protection when used excessively), stock and intelligent. In intelligent mode it considers vehicle speed, engine speed, accelerator position, gear engaged, shift direction, coolant temperature and engine on time. Based on that a driving situation is estimated and the flap is set to open or close.


    I would say my client has a sense of classic cars. His idea is to improve it but keeping it authentic.


    Good point! I also had the same thoughts back then and can go into this next time.


    Just lean back and enjoy the story. I will update from time to time. Comments and questions are always welcome!
     
    ksim and Qavion like this.
  12. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    8
    Full Name:
    Wolfgang Schmidt
    #12 Wolfgang72, Jul 22, 2019
    Last edited: Jul 22, 2019
    Part 2 of Hacking the F1 TCU

    I think there are two approaches to improve things. First you can change the concept. Thinking of engine tuning this would be like adding a turbocharger, installing NOS or even swaping the engine to a more powerful one. You change the car fundamentally and along with that its character. That is not the target here and thus it is no option to take a gearbox of the 458 or whatsoever.
    The other approach is optimization. To stay with above example this would be like increasing intake port size, optimizing camshafts or increasing boost pressure. The essential character of the car is kept. This is the way to go here!

    I started by doing a search of what shift times are for the 355F1 at all. I couldn't find any official figures, but according to a contemporary article in the NY times the quickest time possible is 250 ms. Obviously this refers to the most aggressive driving scenario (sport mode activated, high revs, full throttle) and for shifts that stay in the same gate (i.e. 1-2, 3-4 or 5-6).

    What is it that limits shift time? I considered three aspects:
    - First the limitations due to gearbox hardware. Sync discs, clutch characteristic, travel paths and distances of the control arm etc. Even though very effective, improvements here are quite costly and require a lot of experience. Which I do not have, so I had to skip this.
    - Next there are limitations due to the hydraulic actuation. Hydraulic pressure level, reponse time of the solenoids, dimensions of the hoses etc. I started some discussions with a friend which has good knowledge of these things. But he testified that the system is designed quite well here.
    - Finally there are limitations due to the TCU. Let's make an estimation. The overall shift time is 250 ms. This includes management of the engine, so the time budget for just the TCU reduces to roughly 200 ms. Is that a lot?
    Common OS divide their time budget into slices, like 1 ms, 10 ms, 100 ms and background task. As an example torque calculation today typically runs in 10 ms or even 1 ms. But 20 years ago computation power was not that advanced. I assumed that in our TCU the parts relevant for shifting run in the 10 ms task - best case. That would mean 20 runs per shift. 20 runs where the TCU has to open clutch, disengage current gear, (select target gear, if necessary) engage target gear and close clutch again. Including everything that goes along with that like monitoring for shift errors, diagnosis and so on. This is a bottle neck for sure!



    So my goal clearly was to optimize the TCU. And for that I needed to get one. I tried the obvious and called a Ferrari dealer. Unfortunately I was told that the part is unavailable. Same for a website which offers used Ferrari parts. Finally I found a used one on eBay and bought it.
    While I was waiting for the part I spent my time to become familiar with the F1 system. Ferrari offers a great user manual with a lot of information! There is a full chapter dedicated to the F1 system with valuable information. It was also during that time when I discovered this great forum.

    About a week later the TCU arrived. I dissassembled it (I love this special moment when you reveal something for the very first time) and had a closer look. The board is not that complicated. It appears as if it still would be a prototype halfway. The PCB has only two layers, it is not heavily populated, each signal has its dedicated test pad and - to my delight - there are even three test headers! I wondered what they would be for.
    Next I checked the components. I realized that there are only few special ones. For nearly all of them I was able to find the data sheets. There is an external Flash, which stores the Software. Good for my purpose! The CPU is a Motorola. First I couldn't identify the model, because it is labelled with a custom part number. After a quick search I found out that it's a CPU32.
    In the 70s and 80s processors were complex but small and thus comprehensible. In the 90s they grew bigger and bigger while keeping their complexity. This perfectly applies to the CPU32 as well: it features powerful CISC instructions, offers techniques like virtual memory or an advanced external bus and incorporates a highly specialized Co-Processor for timing functions. Not the best conditions for my task!
    At least its a derivative of the well known 68k series, which is nice as that one is quite popular. Plus it is one of the first CPUs that offers an integrated debug interface. How fortunate! My plan was to try it immediately for reading out the software.

    Doing a short search I found out how to do that. Everything needed for that job is available for free. But unfortunately it is expecting technology of the 90s all-around. That is the debug adapter connects via a parallel port. The software tool is running in MS-DOS only. And in the config file there are timing parameters for a 286 PC.

    I decided to buy an old 286 PC. Good old times...
     
  13. Subarubrat

    Subarubrat Formula 3
    Silver Subscribed

    Apr 1, 2009
    2,054
    VA
    Full Name:
    Scott
    If you build an open source TCU that allows the end user to adjust the calibration values, command solenoids, display telem, execute actuator centering etc... so that we are no longer married to the Ferrari service diagnostic computer or a Leonardo aftermarket you would sell a ton of these to 355/360 F1 owners. There is a guy allegedly selling a replacement TCU but there is nothing more than a pic of a stock TCU and apparently you are still dependent on the SD system. https://www.ebay.com/itm/Ferrari-355-F1-transmission-computer-TCU-174526-ECU/254271778794?hash=item3b33c76fea:g:kiAAAOSwXAxb~LJz

    Right now the only task that cannot be manually executed is actuator centering, but I would still buy an aftermarket TCU in a second.
     
  14. Skippr1999

    Skippr1999 F1 Rookie
    Silver Subscribed

    Dec 22, 2009
    2,614
    Charlotte, NC
    Full Name:
    Skipp
    Love this whole idea.
     
  15. J. Salmon

    J. Salmon F1 Rookie
    Silver Subscribed Owner

    Aug 27, 2005
    4,181
    VA
    I just removed my car's F1 trans to have it inspected (we think bad bearing). I am going to have to reprogram it when it is finally all back together. I have been looking for some way to be able to do this on my own, as it is the only thing that keeps me from being able to do everything myself. I was disappointed to learn that the SD systems that are semi-affordable typically do not manage the 355F1.
    If there is anything I can do to help here, you let me know. I am all in on a solution for setting up and managing the 355F1 system without a dealer.

    As for me and the performance of the system, I have always like that it is the most analog of any paddle shift system I have used. I like that I have to manually blip the throttle on downshifts to rev match. I don't care much about the shift times, although I don't like the clutch to slip on engagement. A way to tune the speed of clutch engagement would be incredible!
     
    tres55 and Skippr1999 like this.
  16. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    8
    Full Name:
    Wolfgang Schmidt
    You can use any standard OBDII adapter to connect to the TCU. All you need to know is the protocol used. I admit that it's quite difficult to understand. But that's not even necessary though:
    All you have to do is take one of these commercial adapters (like SDx or Leonardo) and sniff the communication. Run each command and record your sniffing. Once you are finished repeat the desired command by simply replaying your recording.

    If this is not yet available to the community, I'll come back to it later. But it may take some time. I am still bound to my client and thus dedicated to his task.
     
  17. Subarubrat

    Subarubrat Formula 3
    Silver Subscribed

    Apr 1, 2009
    2,054
    VA
    Full Name:
    Scott
    It is not at all difficult to understand, it is well understood. Leonardo did exactly what you described, they sniffed the comms and captured the command and response to reverse engineer the factory diag computer. What they did with that information was to totally ignore the individual owner and produced a unit designed and marketed only for service centers.

    I think creating a service computer solution is missing the mark anyway since there is a shortage of TCUs and they are selling for silly prices, and once you have one you are still tied to the existing service computers. Creating a new TCU that needs the same existing service solutions is helpful but why not solve the TCU shortage and the service computer solution in one shot? If given my wish list I'd like to see something running on VxWorks with all the diags and calibration data manipulation built in, then all you would need is a terminal program/web browser/pearl script interface to command actions and read/update data and the TCU is where all the action takes place.
     
  18. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    8
    Full Name:
    Wolfgang Schmidt
    I like to think out of the box! You could even develop it as a platform and open it to all the other derivatives of the F1. Moreover computation power is cheap today so you are not even tied to any legacy hardware. You could copy the existing driver part and marry it with a powerful and generic computation platform.

    Only trouble is that a single person cannot shoulder this. You need a community with the right skills and the same vision. Like there was for Megasquirt.
     
  19. e21jason

    e21jason Rookie

    Jul 27, 2015
    44
    Dubai
    Full Name:
    Jason
    Just an idea

    but a modern ecu like a motec 150/emtrin/syvecs could be used to run the engine and the gear box rather than develop an new TCU

    J
     
  20. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    8
    Full Name:
    Wolfgang Schmidt
    Part 3 of Hacking the F1 TCU

    So here is my latest toy: A Nixdorf 286 Laptop with monochrome display! Manufactured back in 1986.
    Image Unavailable, Please Login

    I turned it on and it began to boot. Shortly after I found myself at the DOS prompt. I remembered the beautiful old time! Sadly my reminiscent mood didn't stay long. Even installing the debugger software was a pain! The disk I had prepared had the wrong density (HD instead of DD) and thus was rejected. Of course I couldn't use any other interface as there was none (no USB, no network). Luckily a friend was able to help. His floppy worked and I was able to install the software. After some fiddle with LPT settings and the timing parameters and the cable pinning and... well after some time I finally could connect to the processor!

    Image Unavailable, Please Login


    My first action was to dump the content of the TCU Flash. I entered the corresponding command and curiously checked the result. The reset and interrupt vectors looked plausible. Wow, obviously my download was successful! Great! I couldn't wait to have a closer look. But for that, how should I get the data back to my regular computer? I would have to ask my friend... this time and again each time I would have new data.

    I realized that I need a computer with at least an USB port. One with which I can boot into DOS mode for running the debugger and into Windows mode for transferring data. I decided to try a Pentium III Laptop. I hoped it would be slow enough that some timing parameters would work. I bought one and I was lucky: After some trial and error I found a working configuration! Excellent, now I finally had proper debug acces!

    Image Unavailable, Please Login


    I transferred the dump and opened it in my disassembler. I started an automatic disassembly, but noticed that many parts stayed unrecognized. Apparently there are many cross-references which are resolved via branch tables. That would mean a lot of manual work! But basically the disassembly looked solid. I also couldn't see any nasty tricks to complicate reverse engineering. The Flash is about 80% full, so there are still 20% left for my own purposes (monitor routines, patches ect.). That's enough. However for future functional extensions it might get tight.



    Allright, so there I had the disassembly. But how should I proceed? It's good if you know some principles of embedded software design. Commonly software consists of several parts:
    • The bootloader. It allows you to update the firmware. Therefore it checks for a specific entry condition at startup. If it is met it waits for you to upload the firmware data. This way you can run custom code.
    • The main functionality. This is where all the desired functionality is realized, like shifting, display, diagnosis ect. This is what I wanted to analyze!
    • A test part (optionally). It is there to run function tests of the hardware and is typically used at production.
    Functionwise these parts have nothing in common. Thus my plan was to separate them and concentrate on the main functionality. I checked the disassembly and could easily figure out the bootloader. It resides in a dedicated memory section. However I could not recognize a test part at first sight (which doesn't mean that there is none).

    Next I searched for the initialization routines. They are easy to locate (as they are executed at first) and offer valuable information. On the one hand there is the processor core, e.g speed settings (the CPU32 features a PLL) and privilege levels used. On the other hand there are the peripherals, e.g. which units are used and how they are set up. These are fundamental informations as they tell which resources are used by the application software. I thoroughly examined them. I knew I would use them throughout the entire hack.

    There is one rule at reverse engineering: use as many reliable sources as possible! When I have to make assumptions and use them as a basis for other assumptions - this might collapse like a house of cards! That's very frustrating. But also risky as some assumptions can be ramified in a way I cannot trace them back and revise them. The advantage of the steps mentioned so far is that they are standardized and thus quite reliable. Moreover I do not need to know anything specific to the TCU yet. Of course I couldn't continue like that. I needed to understand the TCU better and gather more (reliable) information.

    Thus the next step was clear: I would reverse engineer the hardware!
     
    flat_plane_eddie and Skippr1999 like this.
  21. Wolfgang72

    Wolfgang72 Rookie

    Jul 12, 2019
    8
    Full Name:
    Wolfgang Schmidt
    Part 4 of Hacking the F1 TCU

    Reverse engineering a hardware board is incredibly boring. There is nothing to it, it works exactly as you would imagine: map components, unsolder them and scan the empty board. Next load the scan into your EDA tool, create the components, place them and then trace all tracks. I went to work. There was zero creativity and it was tedious. I saw tracks all day long (and sometimes even at night in my dreams). But after countless days the time had come: I completed the last track and the layout was complete!

    Of course I also needed the schematic. Fortunately, my EDA tool is able to automatically create it from a layout. So I ran the corresponding script. The result was not very satisfying: the components were arranged randomly and for that - although being electrically correct - all connections ran criss-cross everywhere. What a chaos. I started to rearrange them logically. Again it was a lot of work, but countless versions later I finally completed the schematic, too!

    What does it look like? Well, basically a few output drivers, a few input circuits and the logic part. I was a bit surprised about the external CAN controller, as the processor is also available with an internal one. Why did they decide for an external one? Hmm, maybe that version wasn't yet available when they were prototyping. But apart from that there was nothing special. Well, maybe the output drivers for the solenoids are a bit complex. I took a closer look and roughly guessed how they work.



    Allright. I had checked my copy and it seemed plausible. But would it really work? I was curious and wanted to find out! Therefore I decided to rebuild a TCU based on my data.

    I sent the data to our PCB manufacturer and asked them to produce a board. A few weeks later I received it.

    Image Unavailable, Please Login


    I thought it would be unwise to build up everything right away. Instead, I decided to only solder the power supply at first. Once I did I applied voltage, pulled my voltmeter and checked the voltages. All of them were within their expected range. That looked promising!

    Image Unavailable, Please Login


    Next, I soldered the logic part with processor and memory. For the latter I used a socket, of course. Again I applied voltage and did my measurements. Everything still looked fine. Next I tried to connect to the processor with my debug adapter. And... yes, it worked!

    Image Unavailable, Please Login


    After that I continued with the rest of the assembly, as the remaining parts are rather robust. When I was done, I ran a thorough functional test. Everything worked as expected.


    So my tests looked good and I found no issues. But I knew that a meaningful test was only possible on the car. How should I do that? Unfortunately the only F355 I knew of was that of my client. Only he could reliably tell if my copy is fully functional or not. I called him and explained my idea. He asked me if there would be any risk. I replied that I'm confident nothing would break! What else should I have answered?

    He agreed and so I sent him the copied TCU. After a few days he gave me the call I was waiting for so eagerly. He said: "I just tested your TCU, Wolfgang. Well, the gearbox works as always. That means it's all right, isn't it?" Wow, that's awesome, I thought! It works! He continued: "Well done! Can I keep this one or else can you build me another one?"

    Not a problem! As many as you want.
     
    flat_plane_eddie and Qavion like this.
  22. ttforcefed

    ttforcefed F1 World Champ
    Rossa Subscribed

    Aug 22, 2002
    10,472
    very cool experiment - congrats!
     
  23. Qavion

    Qavion Formula 3

    Feb 20, 2015
    2,481
    Sydney
    Full Name:
    Ian Riddell
    So when do the experiments on improving the gearchanges come? :D
     
  24. mello

    mello F1 Rookie
    Silver Subscribed

    Jul 12, 2013
    2,833
    CA Bay Area
    Full Name:
    Steve
    Great work! After reverse-engineering the board, did you place the components exactly the same as the original board? Surely the header connectors should be the same, but what about the other components? And I don't see a component ID silk screen mask.
     
  25. flat_plane_eddie

    flat_plane_eddie Formula 3
    Silver Subscribed Owner

    Mar 30, 2013
    2,371
    Los Angeles
    Full Name:
    Eddie
    Very interesting to read all this. Keep it coming!
     

Share This Page