Building An Engine Control Unit With The STM32F4

If you’re looking to soup up your whip, the first place you’ll probably look is the engine control unit. This computer shoved in the engine compartment controls just about every aspect of your car’s performance, from the air/fuel ratio, the ignition timing, and the valve controls. Upgrading the ECU usually means flashing new firmware on the device, but [Andrey] is taking it one step further: he’s building his own ECU using the STM32F4 Discovery dev board.

[Andrey]’s ride is a 1996 Ford Aspire, but while he was developing his open source ECU, he wanted to be able to drive his car. No problem, as going down to the junkyard, picking up a spare, and reverse engineering that was a cheap and easy way to do some development. After powering this spare ECU with an ATX supply, [Andrey] was able to figure out a circuit to get sensor input to his microcontroller and having his dev board control the fuel injector.

With a few additional bits of hardware [Andrey] has his open ECU controlling the fuel injection, ignition, fuel pump, and idle air valve solenoid. Not a bad replacement for something that took Ford engineers thousands of man hours to create.

[Andrey]’s ECU actually works, too. In the video below, you can see him driving around a snow-covered waste with his DIY ECU controlling all aspects of the engine. If the engine sounds a little rough, it’s because a wire came loose and he was only using two cylinders. A bit of hot glue will fix that, though.

51 thoughts on “Building An Engine Control Unit With The STM32F4

    1. I’m rather pleased to see an ECU based off a development board, I don’t think it’s “wow” worthy though. Lets look at another open ECU like the Megasquirts which run on a whole lot less. V1 Megasquirt uses a 8Mhz 8bit Motorola 68HC908, V2 uses a 24Mhz 16bit MC9S12C64 and V3 uses 50mhz 16bit MC9S12XEP100. The 168mhz 32bit STM32F407VGT6 used in the Discovery is virtually overkill considering what even the Megasquirt V2 can do with what it has.

      An FPGA based open ECU might be pretty cool though, speaking of overkill.

          1. who cares ;-) MS was created long ago and it was based on now outdated chip which is pricey and difficult to obtain today.
            meanwhile, rtos offers portability, so when the production of these chips is ceased, it won’t be difficult to transfer the project to the other platform. anyway, now this is my preferred choice for a custom MCU

      1. Yes, you are right – MS does the job with 8Mhz, but have you seen their source code? Trust me, you would not enjoy changing it you choose to do so.

        Sometimes you need CPU power to get a user-friendly product. Think Newton vs iPhone :)

          1. Do you have any android device around? Any chance you can make a picture of Newton next to an Android phone? There is one on the internet where Newton is placed next to an iPhone, but for my point I need Newton next to Android phone (as in modern, smaller and open-source)

      2. I run MS in my car and there is a particular situation in which I feel a faster ECU would provide finer resolution/timing during light load o2 corrected areas. So I’m considering upgrading to the later version. WOT is great though.
        So I’m not gonna fault anyone for using an “overkill” processor. Especially if they intend to fold in additional features for the software to fuss about.

      3. So what exactly is the downside of using the bigger, faster, better chip? Is it prohibitively more expensive (my quick googling show the cost difference is negligible for a hobby project)? Less reliable? If it is the same-ish cost, and just as reliable, why wouldn’t you use the more capable chip?

        1. I’m not saying any of that. I’m just saying it’s not remotely worthy of a “wow” since it’s not doing anything substantially lesser hardware made by enthusiasts isn’t already doing.

          Bust out an ECU using 7400 logic and I’ll “wow” the shit out of that. Use a board that’s 4x the hardware that already exists I’ll give it a seriously solid “meh”

          Don’t get me wrong, I’m not discouraging this project at all. I fully support it and would probably kick in on a kickstarter if such a project was undertaken. Unfortunately I’m not sure there’s enough market for such a kickstarter jobby unless it had feature parity with a MegaSquirt v3 including tuning etc. Maybe set a really low bar and just kickstart making boards? Next Developed on HAD? I dunnno.

          1. ECU based on 7400?

            I guess you are one of these crazy “artists” which are all for things no one would get or reuse?

            By using a x4 hardware I gain x4 simplicity which should eventually means x4 features. If x4 features are needed is a separate question :)

  1. The reason Ford spent “thousands of man hours to create” their ECU,
    is not so much the actual hardware box – but the “calibration tables” that
    balance fuel economy vs. performance.

    HP Tuners is just one software package that can tweak the cal tables.
    Of course you need to empirically test the results on a dyno.

    Sounds like this guy is not familiar with those packages. In a modern
    engine, screwing around with the various parameters and not knowing
    how and why they interact with each other is a recipe to grenade the

    1. If you do care about getting the best fuel economy and the cleanest emissions possible it can be done. The other thing Ford had to do is make it work well in North Dakota in February, Nevada in August, Florida at sea level in June, and on top of a mountain pass in Colorado in January. As long as the keep the air to fuel ratio good it should work. The optimizations can come later.

    2. Hard to tell if you’re a true believer or a shill for “HP Tuners”

      Building calibration data is a simple task compared to the actual coding of the ECU. See the analysis of the Toyota ECU for an example

      1. “simple task” ? Tell that to the owner of turbo diesel engines
        that were destroyed by an incompetent “tuner” screwing around
        with the cal-tables.

        EFI Live is another package, I just happen to use HP Tuners
        for GM LSx series engines. A Tech2 is also a good thing to have.
        It’s not easy to tune the complete vehicle package to run low
        10’s (many parameters, intake system, headers, etc).

        I think the street racers in L.A (the ‘fast and furious’ fanboys)
        are pretty good with “tuning” their rice burners.

    3. The time spent creating the hardware is so it can handle abuse. You want the computer to survive a few hundred thousand miles of potholes and jump-starts without breaking. It’s got to last at least as long as the factory warranty, longer if you want people to buy your cars again.

    4. This is a great project but give credit where credit is due. Andrey reverse engineered a existing system and reverse engineering is far different than actually designing something. Even Megasquirt mentioned elsewhere in this thread took a team many years to develop and they leveraged a lot of existing Engineering.

      And even Ford Leveraged work done by others. It was BOSCH, not Ford, who invented & launched modern electronic fuel injection. And they have poured millions of Engineering man-hours into design & development over the years. Their first viable system was the D-Jtronics launched in the late 60’s, followed by the CIS system launched in the late 70’s and then the K-Jtronics. Their ground work layed the path to all other systems.

  2. Now do it with the F3 board. It has an accelerometer that ought to be usable as an input for adjusting engine control parameters during acceleration and braking.

  3. Minor detail but the writing on this got to me. Replacing ECU with a DIY solution is pretty involved. Even a plug-n-play aftermarket ECU is not the 1st go-to for most people! For most modest upgrades a chip tune will adjust things just fine. I installed a megasquirt on mine because I added a turbo, and switched from MAF to MAP type sensor in the process. A turbo is a little above what I’d consider a modest project but if the car was newer and had a MAP sensor to begin with a chip tune would have been ok.
    Adjusting every corner of the fuel map and spark advance map is a tedious process… then there’s warmup tables, etc. You really have to learn a fair amount about how every controllable system of the engine works to understand the settings and getting things going. And troubleshooting of course.

    That said, the freedom it gives you is nice, even if a turbo was not involved it’s nice to have the control. But it’s a highly involved project and not entry level by any means. And you certainly don’t want a dev board with flimsy connectors that need hot glue.. even megasquirt has a few things i could nitpick in this area. If something is intermittent or unreliable it will ruin your day.

    oh, and whip is what’s in the nightstand. WIP is a work in progress. lol

    1. All true. But WIP :)

      I hope that with simpler source code & getting the foundation ready I would open the door for smarted algorithms which would reduce the amount of manual labor while tuning. But these are mostly dreams now, a lot of stuff still has to be done.

    2. Back in the day the steering wheel in a car was called the whip, likely named after the device used to steer a horse. The term evolved to mean a luxury automobile. Then it was applied to any customized automobile. Nowadays it seems to mean “my ride”, custom or otherwise…

    1. Short answer no, long answer is if you shield all wires and the case of the computer from EMP (Electro Magnetic Pulse) weapons as this is what they use to disable a vehicle, probably be easier to just convert over to non electronic ignition or an older car read pre 70’s most likely..

      quick look at that second link saw some more information no clue its accuracy though..

      1. I was thinking more along the lines of the OnStar style shutdowns, rather than the EMP. But it would be interesting to try to build an EMP-proof car…

        1. If you don’t want them to be able to remotely disable your car you should buy a car that doesn’t have that capability.

      2. Nobody’s yet successfully deployed an EMP to shut down a vehicle. The biggest problem is that there aren’t any non-nuclear sources for EMP’s powerful enough to disable an engine given how well shielded it is on account of being made of metal. I know research has been done, but they’re obviously not past that point as we haven’t seen any deployments of it.

        When police remotely shut down engines, they do it using installed systems like Lo-Jack.

    1. Yes and no. I believe there are potential advantages in rusEfi – but yes, FreeEMS is a more mature open source EMS

  4. This is awesome stuff here, in around 2003/4 I worked on an ECU for my Nissan Pulsar, because the one in it was not functioning, I managed to drive the throttle body injector, eventually I got the engine to even fire, pointlessly worked on a one button start protocol, that failed .. but I never got the car to drive – under moderate load it would stall and it always smelled like it was running really REALLY rich… which was confirmed by the sudden loss of my muffler – my “MCU” of choice was a DOS based 386/40mhz all-in-one motherboard using an ISA based port expander thing for IO – it was HUGE, and bulky and horrible, but it was fun – my real success of that project was I found out why the computer wasn’t working, the wiring harness had 4 or so wires cut and shorted at the firewall, one of the grommets wore out.

    1. FreeEMS is great and at first I was considering doing a FreeEMS. It’s just that I’ve realized that now, five years after the start of FreeEMS, stuff could be easier and more user-friendly.

  5. While it’s cool to be able to hack and tinker with your car, I think it’s important to understand the risks of doing this. Sure it “mostly works”, but the hardware is not reliable or redundant, and (probably) neither is the software. Most of the time, even if something fails, your engine will just stall out. But there’s a small chance that the software or hardware fails in a way that causes, for example, the throttle to stick wide open. In this case, you may not be able to stop the car before it crashes into something. Depending on the car, the brakes may not be able to override the engine. If you have vacuum assist on the brakes, the throttle may need to close for the vacuum to recharge, so you may lose the vacuum assist the first time you pump the brakes.

    What are failure modes that could cause this to happen? What about program memory corruption due to a voltage spike? A bad entry in your control table, or a buffer overrun in the software that reads the table? A stuck-at fault on the processor pins? Many others?

    The chances of this happening are small in commercial vehicles with commercial hardware because the design is rigorously tested. Even Toyota’s ECU problems were very rare considering the billions of operating hours they see (That doesn’t make their mistakes okay, either). But if you stick hobby hardware with home-brew code in your car? You put other people, not just yourself at, at a much higher risk. At least do us a favor and stay away from school zones.

    1. Nice rant – some of it may be true,but the whole throttle thing makes me think the rest of your post is probably rubbish. The throttle on a 1996 ford aspire can’t be held wide open by the ECU – it’s connected to the gas pedal.

      Regarding the Toyota incident, the NHTSA found no electronic faults with Toyota’s system, it was a mechanical issue.

      You’d make a much better argument if you didn’t spout a bunch of crap that just isn’t true.

      1. Actually nearly everything he said was pure drivel. Find me a car who’s brakes cannot stop the car at WOT and I’ll be quite surprised. Vac assist going away at one pump?! Umm NO. When in doubt turn it off or throw it into neutral.

        I used to beta test software for AEM many years ago. I DID actually find a problem once that held up one of their biggest software releases. The ECU would somehow lockup under certain conditions and so long as I didn’t make any big throttle movements it would be fine but the ignition and fueling were locked in at whatever point the ECU locked up. As soon as the car stalled from a throttle movement it couldn’t be restarted. The fuel pump continued to run and so did the injectors – I had to quick hop out of the car and pull a fuse to reset it! That was a fun one for the engineers to find but they revamped a good bit of the code to prevent it from ever happening again – even flew an engineer out to my home coast to coast to see the issue himself. AEM makes a pretty good system, I’m happy to see so many others now making PnP them as well.

        Having done as much tuning as I did on my car I began to spot BUGS in other car’s OEM tunes. Driveability is the hardest thing to tune, WOT is easy. I would drive cars that were stock and notice weirdness with certain throttle movements, stumbles, or sometimes even issues with the injectors shutting down properly for coast down. Tuning a standalone teaches you a great deal about how the stuff all works and gives you a great deal more flexibility over modding the stock ECU. It’s not for everyone for sure but it’s fun for some of us and I look forward to doing it again sometime soon :-)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s