There are a lot of ways to help a motor run better – I’m a big fan of keeping things as close to OEM as possible, as the OEM systems often have significantly more capability tucked away in them than is exposed to the consumer, and piggyback units tend to fail in annoying ways over time, as you’re often tapping wires, installing wiring harnesses that aren’t built to the OEM standards, don’t have the same vibration / anti-chafing attachment points, etc. The less complexity you can add to a system to achieve your goal, the better. 

Also, modern ECUs are significantly more powerful than most people give them credit for. The OEMs have to tune their systems not just to address the variability present in mass production, but the broad variety of international emissions controls, a massive range of riding conditions, gas quality, etc, all while being reliable for an extended period of time and in conditions of neglect. I also come from a roadracing background, where the race ECUs are commonly available and often used, and where companies like Woolich and others will reflash the ECU to add capabilities like quickshifters and the like. As KTM uses a more modern canbus system, with separate control system for the ABS (Bosch), motor control(Bosch), Gauges(KTM proprietary), immobilizer, headlight (KTM proprietary), etc, it’s important to make sure you’re changing the right parts of the system. It’s all one system to the rider, but when you get into the weeds, it’s much more complex than that. 

With all of that said, this is primarily focused on KTM Bosch ME17.9.21 ECUs, with some correlaries to other ECUs. I wasn’t able to find a primer on these specific ECU systems anywhere online, so I figured I’d write one and hopefully sharing that knowledge will come back to me in some way in the future. I’d really appreciate insight from anyone who understands more authoritatively what the sub-maps are for in the KTM systems, as this is all reverse engineering, and reverse engineering is fraught with assumptions. I’ll lay out my assumptions, which areas I’m confident in, and which areas still need additional exploring. 

Terminology

• ECU: This is the processor / brain of the unit. It contains a few types of memory, but we’re primarily concerned with the Flash memory, which contains the specific programming for that ECU for a given use case. An ECU is generic until it is programmed – KTM uses the same Bosch ECU as Hyundai uses on their EU i20 1.2l 4 cylinder motors. 
• Flashing/Chiptuning: This is the process to change the programming on an ECU.
• Binary: When you dump the contents of an ECU, you’re dumping the physical ones and zeros stored in memory into a binary file. That binary file can then be modified and reflashed into the ECU to change specific settings. 
• Maps: There are a large number of maps in the ECU that help the ECU understand what to do during driving. The ones we’ll primarily talk about will be: Volumetric Efficiency, Manifold Air Pressure, Driver Wish/Throttle Request Maps, Lambda Maps, Torque Monitoring maps. Naming on all of these maps is incredibly inconsistent between ECU flashing software, and there’s a large degree of inference around each one. 
• CANBUS: How the raw communications are done between control systems on the bike – ie, the ABS needs to talk to the gauges, which talks to the ECU – they use CANBUS to communicate via the bike’s wiring harness. 
• OBD2: An industry standard interface for datalogging/error reporting – polls from CANBUS systems. 
• J2534: A communication protocol for communicating with with ECUs – used to dump and reflash binaries. 
• Checksums / validation: The ECU checks before it runs that the code hasn’t been corrupted. We are effectively “corrupting” the ECU maps when we change them away from OEM specifications, so depending on design, you may need to generate a new checksum. 

The process for tuning an ECU: 

1. Dump the binary from the ECU.
2. Identify the relevant parts of the ECU memory for your use case, and adjust them to achieve your tuning goal. 
3. Reflash the modified binary into the ECU. 

Dumping the Binary

There are a number of ways to do this, but for the Bosch ECUs, the easiest way is what is called a “bench flash”, where you provide power to the ECU, and then dump the binary from the ECU via manually connecting to the CANBUS and GPT pins on the ECU. 

I’m using Scanmatik 2 with the Bench cable as a J2534 interface, PCM Flash with Module 71 for Bosch ECUs to dump and reflash the binary, a Rigol power supply, and a custom built bench cable from a compatible wiring harness. You can see my labels on the ECU connector wires that show which wires are which. 

All that leads to this:

I’ve also used AlienTech’s KSS v3 to dump binaries, it works fine but I prefer this setup as it is a fair bit simpler. However, they provide a lot of the relevant information, including pinouts, and a lot of process support for people doing it for the first time. It is also pretty expensive, and requires an ongoing subscription, although they are constantly releasing new stuff. 

Tuning

I’m using a combination of TunerPro, WinOLS, and ECM Titanium. TunerPro has a much more straightforward interface, but WinOLS is much, much more powerful, and very useful for identifying and tagging maps. ECM Titanium is much more constrained, but also a lot less intuitive for me. While these systems allow you to interact with the binary, you need a separate definition file (TunerPro calls this an XDF, WinOLS calls this a OSLX) to understand which maps mean what. ECM Titanium includes the definition files, and you can reach out to AlienTech for support. 

I’m a fan of OldSkullTuning, who makes TunerPro and sells definition files for TunerPro and WinOLS, so I use their XDFs – reverse engineering isn’t an easy thing and they provide a good baseline. 

Reflashing

This goes back to the PCMFLash setup, where you take the binary you modified in step 2, and write to the ECU instead of reading to it. 

I purchased my tuning software and hardware through ecutools.eu, and have been quite happy with them. Power supply is a Rigol supply, as I expect to be doing some additional software / hardware development in the future. Anything that can provide 13.8-ish volts to the barrel connector on the bench harness for the Scanmatik 2 will do, though. They have a cigarette lighter adapter, so they expect you to use Scanmatik primarily for OBD2/CANBUS monitoring – I just cut that off and wired the leads into my power supply banana plugs. 

Following the reflash, either using a dyno, datalogging while riding, or other monitoring tools, you can go and validate if your changes were successful. 

Okay, now that we’ve got all this laid out, the next step is to actually change the binary and test the changes!