R&D Testing and ECU Reverse Engineering

[JoshDank]

Hey guys, I wanted to start a thread about what I'm working on for tuning the RC390/Duke 390. I'll start with a little about me before I get into the details so you know my background.

I finished school in 2008 and was excited to start a career at a major tuning company. Since then I've worked for 3 different automotive/motorcycle tuning companies as an ECU Reverse Engineer and also own my own LLC where I do mostly e-tuning for German cars and Subarus. I love what I do, so the first thing I look at with a new vehicle is tuning options. I bought a Audi A4 about 2 years ago and immediately got to work on the ECU so I could tune it. As of now, it is running around double the stock horsepower with all upgrades, tuning, and ECU work done by myself. Fast forward to 3 weeks ago... I bought a 2016 RC390. I was excited to pull it apart and find a Bosch ME17 ECU, so I decided to start working on it as a side project.

First step was to get a read of the factory ECU image. Full disclosure, I actually bought a Duke 390 ECU on Ebay to try it on first:



Next, I started working on the assembly code and finding tables. I'm extremely familiar with Bosch ECUs, so I made pretty quick work of the main things I was looking for and started on defining some of the less obvious (but no less important) tables. So far I've done pretty well, but there are still quite a few things to test. As a side note, the Duke 390 ECU had exactly the same tuning and addressing as the RC390 (expected, but nice to verify). Here's a sample of what I've found so far:







Next, I wanted to verify as much as I could without having a real logging option for RAM values. I created a base flash, calculated the proper checksums, and wrote it to the ECU. The bike started and I was able to verify the rev limit and fan temp tables. Always satisfying when a vehicle fires up after an initial test flash, so I wanted more. In order to have some external control and logging, I decided to install a Power Commander 5, Auto-Tune with Wideband, and a POD device to log injector duty cycle, AFR, etc.



Watching the Wideband AFR at idle, I could see that everything was working, but the ECU was trying to fight a bit while in closed loop. I decided that I trust a wideband a lot more than an OEM narrowband O2, so I created a new ECU file which forced the ECU into open loop all the time. I also set the ECU AFR targets to what I thought would be as close as possible to perfect without dyno testing. I then set the PC5/Auto-tune AFR targets to the same and enabled auto-tune. This means that my bike is now running full-time open loop through the ECU, but the Auto-tune is providing full time closed loop fuel control with wideband O2 feedback. So far I'm very happy with the changes.

My plan is to throw the bike on the dyno Sunday and see where she sits as a baseline for further tuning/mods. I have an exhaust on the way thanks to Superpacman13 so I'll want to calibrate for that once installed. I also haven't played with ignition advance at all yet, so I'm sure that will net some gains once I'm on the dyno and can do some solid testing.

Anywho, just wanted to share my little project. Happy to answer questions if you have any. Also, I've only had the bike for a few weeks, so let me know of any quirks I should look out for that could be fixed via ECU tuning.

 

[JoshDank]

Spent a little time on the dyno today.

Picked up a solid 2 whp from around 6000-9500 RPM over my ECU base flash (fuel target changes only) by using the Dynojet Auto-tune and Power Commander 5. Also smoothed the curve out quite a bit. Bike is completely stock other than tuning changes. Actually targeting a bit leaner now than what's in these runs, but I didn't save that graph since there wasn't a major gain (probably a little MPG lol).

I will do a full base run before I start tuning with exhaust, but I didn't feel like pulling the tank cover to get to the ECU to reflash back to a full stock file today.




Red- ECU flash only (just target AFRs and rev limit)

Blue- ECU Flash plus auto-tune enabled

Pink- ECU Flash, auto-tune, and timing changes via PCV

P.S. I'm at 4800ft of altitude and DA was 7550ft today... its hot today. :/





So, what does this mean in the real world? Well, the bike feels a lot smoother than stock for sure. No more odd surging at part throttle and smoother power delivery in general. Also, the time for a single 4th gear pull from 30 mph to 70 mph was reduced from 6.16 seconds to 5.922 seconds. Not bad for a stock bike. For a more realistic measurement of where you'd actually ride, 45 mph to 70 mph in 4th gear was reduced from 3.56 seconds to 3.4 seconds.

 

[JoshDank]

To add to this, here's what I have so far and what I'm thinking of adding:


Tested:
- Ignition Timing
- Rev limits
- Idle targets
- Forced full-time open loop
- Target AFR
- Sensor scaling
- Injector scaling
- Fan temps


To find:
- rollover sensor
- DTC disabling
- logging via diag port
- flashing via diag port


Custom code want list:
- Full time closed loop with wideband input
- launch control
- quickshift for upshifts (no clutch)
- quickshift for downshift (and/or throttle blip for downshifts)
- speedo correction
- ABS "modes"/Traction control
- Bluetooth device for flashing





Anything else should be on the list?

 

[JoshDank]

Reserved for future post 3

 

[streetfighter]

R&D Testing and ECU Reverse Engineering

Hi Josh

Very Interesting project indeed. A few questions.

1. Do you now have the duke ECU or the original RC ECU running on your RC? Are you getting any engine warning lights after the hack?

2. What tool do you use to write the modified flash into the ECU?

3. How did you determine the parameter names?

4. are you able to write a full fuel mapping table and ignition values directly to the ECU using the tool based on a PCV map?

5. Looking at the parameters, in theory you can install a wide band sensor and set the AFR value to a desired range and let the ECU work all close loop, like a true "autotune" correct?





Thanks.






Sent from my iPhone using Tapatalk

 

[JoshDank]

Hi Josh

Very Interesting project indeed. A few questions.

1. Do you now have the duke ECU or the original RC ECU running on your RC? Are you getting any engine warning lights after the hack?

2. What tool do you use to write the modified flash into the ECU?

3. How did you determine the parameter names?

4. are you able to write a full fuel mapping table and ignition values directly to the ECU using the tool based on a PCV map?

5. Looking at the parameters, in theory you can install a wide band sensor and set the AFR value to a desired range and let the ECU work all close loop, like a true "autotune" correct?

Great questions. I'll go through them one by one.

1. I am currently using the RC390 ECU with my changes applied. I will test with the Duke ECU, but I expect it to work just fine since I don't think there is an immobilizer feature on our bikes. If there is an immobilizer, I would need to disable it or yswapping ECUs is no feasible.
No engine warning lights, because I'm recalibrating tables just like the original calibrator at KTM did. Since I have the tools to properly checksum and sign the file before flashing, the ECU has no complaints.

2. I'm using software that was developed by myself and a co-worker for use on a different but similar ECU. I had to make a few additional changes to make it play nice with the RC390.

3. This is generally called "table discovery" in my line of work. I've been reverse engineering ECUs for 9+ years, so I have a pretty good idea of the main tables when I see them in the ECU. After that, I test and see if the bike reacts as I expect, then make up a name based on what happened. The ME17 ECU used on these bikes is extremely similar to other projects I've done for work, so I had a bit of head-start since I was able to line up code flow with other things I've done.

4. Yes and no. The PCV has different axis units for some tables vs what the ECU uses. Also, the tables themselves are different sizes, so you could totally translate the PCV changes into something usable for the ECU, but its not a copy and paste.

5. Again, yes and no. Since the ECU comes with a narrowband from the factory, it has no idea how to read a wideband. The O2 voltages would need to be calibrated in the ECU, then code changes would need to be made to keep the ECU in closed loop at all AFR targets. The factory code only tries to correct fueling in a very specific voltage range since that's how a narrowband works. Outside of stoich, the ECU just looks at the AFR target, and uses a Volumetric Efficiency table to calculate the desired injector pulse width to hit that target. Technically, if the Volumetric Efficiency table and associated atmospheric compensation were tuned perfectly for your bike and mods, it would be dead on target for AFR at all times even without O2 feedback. Answer to your actual question, its possible but a decent amount of work to have full-time closed loop in the ECU.

 

[Ryanthegreat1]

So how long before you have a turning package ready for market?

I have a PVC but not a huge fan of the piggy back. Would be nice to have full control just through the stock ECU.

 

[JoshDank]

So how long before you have a turning package ready for market?

I have a PVC but not a huge fan of the piggy back. Would be nice to have full control just through the stock ECU.

Right now it's just a personal project since I can't leave an ECU alone lol. But if there was enough interest, i would love to support all the 390s. We'll see...

 

[isaac_]

Subbed


Sent from my iPhone using Tapatalk

 

[JoshDank]

Updated second post with some dyno info from today.

 

[Chris The Welder]

Very cool. And interesting. 21st century gear head.

 

[streetfighter]

R&D Testing and ECU Reverse Engineering

Hi Josh

Thanks for your answers. Impressive work. More questions now that you have a dyno chart.

1.The RED (no PCV) has AFR between 13.0-13.5. What value did you use exactly?
2. I take it is the field "Target AFR for component protect" in your discovery table that you modified? is the value absolute value from zero ?
3. What was the original AFR value embedded in the stock ECU?
4. Which parameter is used to force the ECU to operate in open loop only?
5. Do you need to crack open the ECU's metal case every time you re-flash the ECU? Or only the first time for probing purpose only?

Again, great work. Looking forward to reading more

Thanks

 

[JoshDank]

Hi Josh

Thanks for your answers. Impressive work. More questions now that you have a dyno chart.

1.The RED (no PCV) has AFR between 13.0-13.5. What value did you use exactly?
2. I take it is the field "Target AFR for component protect" in your discovery table that you modified? is the value absolute value from zero ?
3. What was the original AFR value embedded in the stock ECU?
4. Which parameter is used to force the ECU to operate in open loop only?
5. Do you need to crack open the ECU's metal case every time you re-flash the ECU? Or only the first time for probing purpose only?

Again, great work. Looking forward to reading more

Thanks

1. First, these are not single values, they are large 3d tables. At WOT, I was targeting a 13.2 with a 13.0 above 7500 RPM. So the ECU is close, but with some adjustments to the VE table, I would expect to be able to keep the bike within a tenth of a point of the target.
2. All of the target AFR tables are actually target lambda, but I prefer AFR so I scale them for gasoline stoich. I changed several tables to make sure I covered all cases.
3. The values depend on the mode, but most values are stoich. It does request values richer than 13:1, but based on what I've seen, I don't believe the ECU actually hits these rows/columns in stock form. I need to log a few more things to verify that. If the ECU is actually hitting these cells, then the VE table is pretty far off from where it should be.
4. Target AFR needs to be set to something outside of the range of the narrowband sensor.
5. Currently I open the ECU every time, but I'll eventually get it flashing over the diagnostic port to make things more convenient.

 

[micahpearlman]

Wow this is a super cool project. You mind go over the software and hardware tools you are using? Calculating the CRC and signing I figure are proprietary (i.e., expensive and hard to get). I'm fairly technically minded but don't know a whole lot about reverse engineering an ECU. I looked into doing this myself but gave up when I realized (or assumed) that any new image would need to be signed.

 

[JoshDank]

Wow this is a super cool project. You mind go over the software and hardware tools you are using? Calculating the CRC and signing I figure are proprietary (i.e., expensive and hard to get). I'm fairly technically minded but don't know a whole lot about reverse engineering an ECU. I looked into doing this myself but gave up when I realized (or assumed) that any new image would need to be signed.

Checksum calculations and signing are done using proprietary tools either written by myself or a co-worker. I do this for a living (for different ECUs), so I have some experience dealing with these sorts of things. For determining ECU logic, data scaling, and how tables interact, I use IDA Pro to load the binary image and then convert the code areas into assembly language. From there I start with something I know and label everything I can as I figure things out. Next I build a template so I can view the ECU data/tables in something more user friendly. I could do this with TunerPro or some other opensource tune viewing software, but since I work for a tuning company, I took advantage of my resources and built my files to work with our very powerful tuning suite.

 

[micahpearlman]

Checksum calculations and signing are done using proprietary tools either written by myself or a co-worker. I do this for a living (for different ECUs), so I have some experience dealing with these sorts of things. For determining ECU logic, data scaling, and how tables interact, I use IDA Pro to load the binary image and then convert the code areas into assembly language. From there I start with something I know and label everything I can as I figure things out. Next I build a template so I can view the ECU data/tables in something more user friendly. I could do this with TunerPro or some other opensource tune viewing software, but since I work for a tuning company, I took advantage of my resources and built my files to work with our very powerful tuning suite.

Thats what I figured. Not particularly do able for a weekend hacker with only open source tools. Curious, I understand with your tools it's fairly trivial to tweak the lookup tables, but I'm assuming there are PIDs controlling the injectors/timing, do you guys ever tweak on the PID gains or even the PID code itself? Apologies if I'm going off topic or requesting proprietary knowledge but I'm genuinely curious about the subject of ECU hacking in general.

 

[JoshDank]

Thats what I figured. Not particularly do able for a weekend hacker with only open source tools. Curious, I understand with your tools it's fairly trivial to tweak the lookup tables, but I'm assuming there are PIDs controlling the injectors/timing, do you guys ever tweak on the PID gains or even the PID code itself? Apologies if I'm going off topic or requesting proprietary knowledge but I'm genuinely curious about the subject of ECU hacking in general.

Sure, we make custom tuning software, so I expose as many tables as possible for end-user software. That includes pretty much anything needed to calibrate for parts that have been changed. If you check out the list of tables in the first post, you'll see there are 6 tables for just the injector characterization... that doesn't include any of the actual fueling code, just the calibration parameters for the injector itself. I also create new custom assembly code to change behaviors in the ECU as needed. There is always more to find, so I start with the known-needed basics and then I look for more tables and tuning parameters as it becomes obvious that something isn't responding as expected.

Also, the actual tuning is much easier than the reverse engineering. Even if you find a table in the ECU, you have to figure out what it does, when its active, what other tables it works in conjunction with, etc. The other difficult part is figuring out scaling for all possible datatypes. the hexadecimal number in a raw binary file needs to have a scalar applied to it to give a human readable value that makes sense in a real unit (like RPM, temp, etc).

 

[streetfighter]

Sure, we make custom tuning software, so I expose as many tables as possible for end-user software. That includes pretty much anything needed to calibrate for parts that have been changed. If you check out the list of tables in the first post, you'll see there are 6 tables for just the injector characterization... that doesn't include any of the actual fueling code, just the calibration parameters for the injector itself. I also create new custom assembly code to change behaviors in the ECU as needed. There is always more to find, so I start with the known-needed basics and then I look for more tables and tuning parameters as it becomes obvious that something isn't responding as expected.

Also, the actual tuning is much easier than the reverse engineering. Even if you find a table in the ECU, you have to figure out what it does, when its active, what other tables it works in conjunction with, etc. The other difficult part is figuring out scaling for all possible datatypes. the hexadecimal number in a raw binary file needs to have a scalar applied to it to give a human readable value that makes sense in a real unit (like RPM, temp, etc).

Hi Josh

Would love to see you creating a simple software and hardware package that allows the RC390 owners to read and modify AFR, ignition timing and close loop On/Off via the bike's diagnostic connector. I hope that day won't be too far away. Good work





Sent from my iPhone using Tapatalk

 

[JoshDank]

Hi Josh

Would love to see you creating a simple software and hardware package that allows the RC390 owners to read and modify AFR, ignition timing and close loop On/Off via the bike's diagnostic connector. I hope that day won't be too far away. Good work

Thanks dude. If I think it's feasible and there is interest, I'll definitely see what I can do. I have enough defined to do tuning for a pretty serious build already... in fact it should be totally possible to tune for a turbo kit at this point other than it really needs to be capable of logging and flashing via the diag port.

 

[JoshDank]

To add to this, here's what I have so far and what I'm thinking of adding:


Tested:
- Ignition Timing
- Rev limits
- Idle targets
- Forced full-time open loop
- Target AFR
- Sensor scaling
- Injector scaling


To find:
- rollover sensor
- DTC disabling
- logging via diag port
- flashing via diag port


Custom code want list:
- Full time closed loop with wideband input
- launch control
- quickshift for upshifts (no clutch)
- quickshift for downshift (and/or throttle blip for downshifts)
- speedo correction



Anything else should be on the list?

**Added to post 3 so I can update the list as things get finished or added**