355 Hacking the F1 TCU

I came across them some time ago when I had issues with a hydraulic block. I didn't think of my project back then. Thanks for the link, I will check them out again!

 

Part 14a of Hacking the F1 TCU

Meanwhile my project reached a stage where I had to take measurements in a car. Last time I went to my client for this. But it was impractical to repeat this each time, i.e. ask for his time, travel to him, install my equimpent and so on. Therefore my next ToDo was to get my own F355!

I set up a wish list. I noticed it was a bit different than usual. For example, I didn't care much about color, options, visual appearance or if there was a famous pre-owner. Instead my major point was that the car had to be in proper technical condition. Having this in mind I started my search. Unfortunately I found many cars that did not even match that standard. Maintanance was poor, parts were missing, mileage was "undocumented" or the overall shape was too bad for the price asked.

On a Friday morning I was checking the ads as usual when I suddenly noticed a new offer. The car looked promising and so I took my phone and called the owner. He told me a bit about his car and also sent me some documents. They proved that he took good care of his car, did all maintainances and everything the car asked for! I called him again and we agreed to meet. I still remember the moment when I arrived at his place and how I first saw his F355. It looked perfect! It was in wonderful shape, properly maintained, no missing parts, nothing customized! We went for a test drive, had a coffee, talked a lot, negotiated a bit - and few hours later I sat in my new F355 driving home. What a beautiful day!

Image Unavailable, Please Login

And what a beautiful car! What I like most about it is its pureness. There is no filter, no manipulation, no pretending. It is straight-forward. Todays cars try to match a specification. That is, they are designed not only to achieve a function, but also to provoke specific feelings. Take the most obvious example: Sound design. The way your engine sounds is not its true and native sound. Instead it is "corrected" by sound boxes, air ducts and loudspeakers. This way it formally meets the specification the car designers had in mind - but by the cost of feeling synthetic. The F355 is the opposite. It vibrates, roars and smells because things do this and there was no point to remove that. There is no sound generator in the loudspeakers of course. But also no speed-sensitive steering, no active engine mounts, no fake gauges and no Drive-by-wire. Well, except Shift-by-Wire...

Unfortunately, its driving performance is barely adequate by todays standards. The F129 engine is a high-revving engine. Up to mid RPM you're having a hard time to compete with modern cars, especially Diesels. There's too little torque. Only at high RPM you're in a gear offering enough wheel torque, so you can keep up with more powerful cars. But no matter what RPM, you still have no chance against modern Performance cars (BMW M3 etc.). I remember the "war" on horse power that went on in the (european) automotive industry at that time. In 1992, a BMW M5 (E34) had 340hp. A few years later its successor (E39) already had 400hp. (Both are heavier than the F355 though.) Again a few years later (2002) Mercedes launched its legendary M275. It is a V12 Bi-Turbo producing 1000Nm / 740lbft and was used e.g. in the S-Class. An S-Class which then was quicker on the straight than a recent (F355) or current (F360) Ferrari of that time!

Anyway, I finally had my own car for testing. The next step would be to prepare it for that purpose...

Image Unavailable, Please Login

 

That's a nicely spec'd 355. You're a lucky man! 98 or 99? Appears to have embossed fenders as well.

Let's see pics of the interior!

 

Very happy for you and hope your goals are met and the rest of us may benefit.

 

Great stuff Wolfgang! Cant wait to see what you can do with your own 355 now.

 

Nice to chat to you recently about your project and give you some help with the CAN decoding.

If I where going to re-produce a firmware/binary compatible TCU h/w these days I consider doing a protoype/feasibility of emulating the CPU32 683xx entirely in an FPGA soft-core. If you haven't seen it back in 2018 Jorge Cwik did a 68k cycle exact compatible core in verilog and released the source-code, which was designed to replace an actual chip on a real board. On Cyclone FPGA families it uses just over 5100 Logic Elements and about 5Kb internal ram, reaching a max effective clock frequency close to 40MHz which is faster than the original clock of these TCU's.

Note: For reference and to get started something like XILINX FPGA Spartan-6 XC6SLX16-FTG256, 256 pin has 14,579 LE's, it clocks to 50MHz and can be had with 2MB of storage and 32MB SDRAM chip on a ready made development board for around $30 ready to go from somewhere like Aliexpress.

Ofcourse you'd need to spend some further work and time on doing is the additional Toucan specific peripherals like internal CAN registers and UART's ,etc. I'm sure a lot of stuff could be ignored like the BDM interface, etc.
https://www.atari-forum.com/viewtopic.php?f=28&t=34730#p358139
and another project...
https://github.com/mattuna15/zed-68k/tree/arty-gd
and another
https://github.com/TobiFlex/TG68K.C

or go full software on a cheap x86 board like RockPI X (Intel Cherry Trail quad core processor Z8350!)
https://github.com/ZopharsDomain/MC6800-MULTI-Starscream

Having spent a decade of my life writing millions of lines of Motorola 68K assembly language back in the late 80's and early 90's I can say its one of the most readable and enjoyable of all the assembly languages IMHO. Yes I'm probably a little bit sadistic about 68k..

 

Trev,
What’s your opinion on the feasibility of making the F1 system shift faster in the 355 ?

Thanks

 

Sure, I will gladly do it next time!

Yes, I also spent a lot of time thinking how I could improve the CPU. I like your idea a lot, Trevor! In my comany I have good expertise in FPGA design. We even did a very similar project some time ago, where we re-built an 80535. Back then we bought a softcore, added wishbone compatibility and attached our custom logic. It worked like a charm! (Trevor, you certainly have an idea of which ECU that project was about.)

With a softcore we could implement a faster CPU, add a diagnostic or calibration interface and even move time critical parts of the software to customized logic. There's virtually no limit!

Unfortunately, a CPU32 is more than the 68k core that is currently available. As you already mentioned, there are the peripheral units, too. Especially there is the Time Processor Unit (TPU). It's a complex beast! And you cannot skip that as the F1 TCU software really uses it. It would be a ton of work to re-built that! But even then you would still need to re-built the other peripherals, too. Timers, SCI, CAN etc. Moreover you would need to attach an external ADC as there is no FPGA available that can handle analog voltages.

So yes, it absolutely is possible to go this way. But it is complex, time consuming and error-prone. Which is not the best combination for a safety critical system like the TCU.

In my opinion, the best option would be to switch to the ST10 architecture that Magneti Marelli used starting with the CFC-3xx. For example, Maserati implements its SOFAST IV on a CFC-301, which does gear changes as fast as 60 ms.

 

$10 he ends up with a manual conversion

 

I'm sure implementing the peripherals isn't as difficult as you'd first imagine... I recall when the prospect of emulating the Amiga was first touted, people said ahh, the blitter, the 16-bit 4 channel sound chip (Paula) , the ciaa timers, the copper chip, etc. are super difficult but they all got perfectly emulated in the end! I'm certain a few hours with a high end logic analyzer and you'd be half way there

However I wasn't aware that MM moved over to the ST10 which itself traces its roots back to the C16x architecture used on the very same ME7 (!) that I've spent the best part of 5 years working on now and written my own disassembler and automated analysis tooling for. I'm sure it wouldn't take me too long to understand it with my experience of the C167 which is its not too distant cousin...

https://ecu.design/files/ecu_pinout/marelli_cfc319_fca.pdf

Here infact is a pdf showing exactly how to boot mode read a CFC319 on the bench... If anyone has any firmware dumps of this I'm sure I could modify its firmware so its possible to back port it to cars like the 360...

Here's one for sale if anyone is feeling like helping the cause...
https://www.ebay.co.uk/itm/313692247907?hash=item490983d763:g:m6EAAOSwOVdg9pai

 

I fear sadly that the gearbox hardware itself will be ultimately the "weak link" here and not the ability of the TCU's speed (raw MHz) to crunch through the algorithms and operate actuators, etc. fast enough.

Back in the day most of these companies like MM had already migrated away from assembly as a weapon of choice and wrote the majority of their code in C language. Sadly they used hopelessly bad unoptimized "proprietary" C compilers which produced terribly slow machine code. I recall when I was "really" proficient on developing 68k assembly code back in the 80's my own hand written assembly language could run rings around any C compiler. As a reference I was bench marking my hand crafted optimized code @ around 400% faster due to use of registers and not relying on slow stack operations as a calling convention between functions. So I'm sure with a bit of re-work I could dramatically improve the performance of the existing code base (I'd just profile the sections taking the most cpu cycles and optimize them) without even having to revert to changing the tcu hardware or moving to a faster chipset... What all this means in a nutshell is that there is scope to improve the weakest link (the software itself) inside the TCU which if its part of the "slowness" could be sped up considerably. All of this these days is firmly in the black magic "niche" of yesteryear of museum micro-controllers of years long gone...

Whether any of this optimization is significant enough to notice is would indeed require some deep analysis first and foremost.

 

@Wolfgang72 Congrats for your F355!

Looking forward to hear about it and still with the research & development of the upgraded TCU software, it will be awesome to have it available soon, you come along way with this topic, I'm pretty sure it will finished with epic results.

As a kindly reminder stay in touch with these guys, with all the path you have in this project it will be more "easy" to work with them, also build an armored/ultimate F1 gearbox for the F355, among many features like a better LSD, launch control, torque by gear, better grip, no slip, lower temperatures, faster shifts (50ms or less will be the sweet spot), better sound, etc.

https://tvsengineering.com/en/
http://www.gte-engineering.com/f1-actuator-rebuild.html

For some inspiration, in case you wanna restore some parts of your F355, check these links:

https://instagram.com/carplastix
https://www.instagram.com/p/B4UgFqJnx4p
https://instagram.com/restored_by_elliott

Cheers!

 

Wolfgang. It’s Great for you to join the brotherhood. You will love it I guarantee it. They are not for the faint of heart though as a properly running 355
Does need a fair amount of TLC. Ha ha
They run fine without but it’s a whole new ball game when they are on and you know it.

Congrats

 

Part 14b of Hacking the F1 TCU

Next I prepared my F355 for testing. My aim was that I could take my laptop, get into the car and take measurements and calibrate data. For that I would use a heavily modified Software and its in the matter of things that a lot could go wrong here. I had to prepare my car for that.

Usually our test vehicles are equipped with kill switches. If anything goes wrong you quickly press it and your car enters a safe state. For example, imagine you are cruising around and decide to upshift. But unfortunately, for some reason the TCU fails and shifts into first gear instead. Then using the kill switch would immediately open the clutch and save you. Of course you would loose acceleration, but that's better than loosing traction at the rear wheels due to engine overspeed.

Unfortunately, activating a kill switch takes hundreds of ms. In the above scenario things would escalate too quickly. That is, a kill switch wouldn't help. Luckily our TCU already includes a safety concept that avoids many hazardous malfunctions by itself! Its main part is a dedicated Safety CPU, whose only task is to monitor the correct functioning of the Main CPU (that's where all the shift functions are processed) and to jump in if anything bad happens.

Image Unavailable, Please Login

This is how it works: The Main CPU generates a so-called Alive Signal and sends it to the Safety CPU. The generation of the Alive Signal is deeply embedded in the Software and connected to those parts that perform safety critical tasks. If any safety critical task is not executed (e.g. due to bad scheduling, memory corruption, failed clock, ...) the Alive Signal stops. The Safety CPU detects this and immediately demands safe state.

Image Unavailable, Please Login

By the way: The definition of safe state depends on whether you're driving or not. At driving the clutch is forced to close. To achieve this, the Safety CPU overwrites any command to EV0 coming from the Main CPU. Moreover it also cycles power in an attempt to recover from the fault. If the fault was transient, your chances are good that everything works fine again.
At standstill the safe state is to disconnect torque from the engine. The Safety CPU energizes EV1 and EV2 to disengage gear. Additionally, it drives EV0 to open the clutch. There is no recovery strategy though as the clutch would drop during the power cycle and it cannot be verified that the gear successfully got disengaged before.


Besides the aspects of Functional Safety I also had an eye on protection of my precious new car. At testing I would need to use Breakpoints in the Software code from time to time. When the CPU reaches a Breakpoint, it pauses execution and maintains all internal states. This includes the state of the output pins, too. Thus, if the Hydraulic Pump is active at that time, it will stay active. It will continue to charge my hydraulic system and put a lot of stress on the components until the relief valve opens. Therefore, I designed a simple circuit to protect against a stuck pump signal.

Image Unavailable, Please Login



The rest of my interior is as you probably expect it: Laptop holder, power supply, OBD2 device, CAN-Bus measurement tool etc.

Image Unavailable, Please Login

 

Part 15 of Hacking the F1 TCU

Having my own F355 was marvelous! I loved the car - and so did my employees. It quickly became the most desired car in our pool. Even my clients were taken with it, although they all shifted to E-Mobility meanwhile.

Now, to examine a shift process in my F355, I was in need of proper measurement access. The typical interfaces, that I bet come to your mind, have some serious disadvantages. They are slow or inaccurate, but above all that have one thing in common: They only offer access to few and predefined signals.
Image Unavailable, Please Login

Brief digression: In the 90s the (european) automobile industry faced a problem. Its not that they had no solution to measure signals in their ECUs. But their problem was that it was purpose-built for each manufacturer. This meant a major disadvantage for the suppliers, which had to implement individual interfaces for each customer. Consequently, it led to increased costs, although having no positive effect (no USP). That's how the carmakers agreed to cooperate and founded a working group named ASAM. The result was a standard called ASAM ASAP, which defines a measurement protocol called CCP.

This CCP (or respectively its successor XCP) is exactly what any development engineer uses today when taking measurements. And as you might've suspected, my target was to implement exactly this in our TCU as well! This way I could use all my standard equipment, tools and processes. Moreover, I could ask any random employee to take measures. They would all know how that stuff works and what to do. That's the beauty of a standard.
Image Unavailable, Please Login
Unfortunately, CCP needs a software implementation in the TCU. That is, it will consume memory and runtime. You need to know your ECU very well to not mess things up. But having spent so much time with the TCU, that wasn't a problem anymore. And so I started the implementation of CCP.

The task itself was simple, however it took some time until it ran efficiently and smoothly. Finally I succeeded. Now I am able to jump into my F355, connect a regular engineering Laptop and start a measurement with any random signal I like to record!


Below is what it looks like in reality. The measurement screen shows the most basic signals. We add it to any "experiment" before adding more specific variables as desired.

Image Unavailable, Please Login

The three gauges at the top show your engine, clutch and vehicle speed. The graphs below display the engagement and selection positions, whereas the green bars to the right show various clutch positions. The right pane is reserved for the solenoids, i.e. target currents and states for EV0 to EV5. Finally, there are a few additional displays (e.g. gear, hydraulic pressure, throttle position etc.). This screen offers a good overview of how the TCU feels. Therefore, we usually select this view when doing any unspecific (test) driving.

Like the one in the video below. At the beginning the car is in standstill in neutral gear. Then I pull the gear lever to engage gear 1. What would you think will happen? Well, obviously the gear lever status changes. Then the solenoids are activated. And finally the gear engages as selection and engagement positions change. In parallel, EV0 is activated and opens the clutch, as you'll notice when looking at the green bars. Then I accelerate and the clutch starts to close...




The next video is more specific. It shows the clutch behaviour when moving off from standstill. Initially I accelerate gently, then harder with each attempt. You can easily see how the clutch closes more and more progressively in return. This is why the WSM suggests to accelerate properly, especially when the clutch is hot.




Our TCU offers hundreds and thousands of signals! I can sample all of them in a very convenient update rate (as fast as 10 ms)! I can see exactly what the TCU sees and thus perfectly retrace the decisions it takes!

 

Wolfgang72 this a fascinating project and I'm very impressed with the way you have progressed over time. Just spent quite a bit of time reading through all your posts, cannot help myself as an ex professional programmer and hardware nut. I'm embarrassed to ask this but I stumbled across your project whilst looking for a pin-out for the CFC 101, we are a repair company in the UK and have been asked to come up with a means of repairing these ECU's, despite being fascinated by the project I haven't found an actual pin-out of this ECU yet. Is there any chance that I could press you into posting the pin-out for the main 55 pin connector? Thanks ahead of time - Antony Moore Avilec Ltd

 

There are 2 Ferrari wiring schematics available, but, oddly, neither show the gearbox input shaft sensor.

https://www.dropbox.com/t/9nO8ipS7rU1aw8pT

https://www.dropbox.com/t/6s984I7vOLWZinbd

Links expire in 6 days.

Perhaps Wolfgang knows which pins/wire colours are used for the input shaft sensor.

 

Thank you very much for the links, just what I was after - Antony

 

Thanks a lot!

Sure, pins 13 (+) and 32 (-). Not sure about the wire colours though.

 

Strange... My wiring diagrams already show these pins used by the "Clutch Control Actuator".

 

Hello. Great post by Wolfgang and great work being done. By any chance does anyone have the parameters for the 355 F1 TCU on ignition switched on and engine off. Would just like to compare with the parameters displayed for me. Thank you.

 

This is a little off-topic but I'd be curious if anyone knows on an F1 car what signal the ECU wants to see from the TCU. When you convert an F1 355 to manual, you get a P0600 code (serial communication link malfunction) that trip a CEL. It's $$$$ to get the ECU reprogrammed so it's not looking for the TCU. If we knew what signal the ECU needs to see, maybe there's a simple way to provide it and avoid the ECU reprogramming.

 

There is no one “input” both use a bi directional C.A.N. line to communicate to each other on when a shirt is going to occur and to limit the torque of the engine during that shift
As well as other info needed

The ECU is looking for a “State of Health Message “ from the TCU and a reprogram of your ECU is your only option

Best beat to to try to locate a used ECU for a manual transmission car if any still are around


Sent from my iPhone using FerrariChat

 

Or… buy a CAN sniffing tool, isolate the message from the TCU to the ecu with some simple comparative analysis, then program a small off the shelf module to transmit this signal on a loop. Would be pretty easy really. In fact I bet Wolfgang already has the required can message that you would need to program.


Sent from my iPhone using FerrariChat

 

This is way beyond my skills (I can use wrenches, not computers) but if someone wanted to build this, there is a market for it. A small one, to be sure. But I bet you sell a few modules a year. I would buy one.