This is part 4 of series "Kona EV Conversion":

  1. Salvaging a Kona
  2. Dismantling the Kona
  3. Kona CAN Decoding
  4. The motor turns (too much) (this post)

(Posting this one a while after it happened, due to holidays.)

This instalment is about the "Bench Kona" I've built in the shed. Behold its questionable integrity:

Mess of Kona components and wires on a bench

Different angle, can also see the motor and the battery

You can see the motor and drive unit stack in the foreground, and the battery pack in the background under some junk. These are all the same part assemblies that came out of the crashed Kona, with their original wiring. All of the high voltage connections are exactly the same as in the car, including interlocks and seals.

The bench holds other modules taken from the engine bay and the interior of the car, plus large segments of the original wiring (now unwrapped, cut, spliced, and converted into a tangled mess).

The green wooden bench was "obtainium" that my mate Oli donated. It's far from perfect, but it has the very attractive property that we can cut it, screw into it, and generally mess with it as much as we want.

Why would you do this?

Like every modern car, the Hyundai Kona Electric is absurdly complicated. More than five separate CAN buses, ten or more kilograms of low voltage wiring, probably over one hundred electronic modules (most with their own CPU and firmware), etc.

In order to re-purpose the Kona's powertrain into an EV conversion, we need to find the simplest subset of modules that can work together.

Hence, a reverse engineering experiment: the Bench Kona.

Plan

The rough plan has been:

  1. Wire together modules on the bench until the motor turns, and the traction battery can be charged.
  2. Progressively remove modules, replacing them with fake CAN messages or other signals. The goal is to find the minimum that will still work.
  3. Document this, and design some kind of "Kona meta-VCU" that allows the Kona's VCU (Vehicle Control Unit) to drive the motor in an EV conversion.
  4. Celebrate wildly, should this step ever be reached.

It's important to note that absolutely none of the techniques used to wire up the Bench Kona translate over to a real moving vehicle. This is strictly for reverse engineering purposes.

Looming

I was able to drape most of the engine bay wiring loom and some of the cabin loom over the bench. The strategy was to find particular wires in the inter-loom connectors and cut them out when needed. Hopefully, once everything works then it'll be straightforward to remove what's left and dramatically reduce the rats nest qualities of this setup:

Different angle of the bench showing even more wires

A special mention for these lever-action wire connectors:

A four wire lever-action wire connector on the bench

They're very easy to connect and disconnect, and so far they've been reliable.1 These ones are from Taobao, but looks like they're also on Aliexpress.

Elsewhere crimp ferrules and screw terminals were used, instead. The label maker came in particularly handy!

Gateway Antics

Hoping that the Kona had been engineered in a modular fashion, I was counting on finding some integration points that could be "sliced" apart without too much impact. This turned out to be partly true, although the Law of Leaky Abstractions seems to also apply to cars.

The first module to eliminate was the Integrated Gateway and Power Module (IGPM):

Integrated Gateway Power Module

You may remember this module from Part One, when one of its connectors was accidentally damaged by forward probing...

Bench Kona has to to replicate at least two functions of the IGPM:

  1. Switching power to some modules, especially "IG3" which seems to be the power when the car is "half turned on" (for example, when charging).
  2. Injecting some of the CAN messages that the IGPM forwards between the different buses.

Switching power turned out to be pretty straightforward. Bench Kona has kept the original engine bay relay box for now. It still provides the main relays, large fuses, and the heavy-duty wiring for the DC/DC Converter and the 12V battery:

Close up on Kona engine bay fuse box

A lot of power supply wiring comes out of this box, goes into the IGPM where it's split up into different power domains and individually fused. Then some of these individual power wires come back through the engine bay fuse box. To replace individual IGPM circuits and fuses, Bench Kona has a simple automotive fuse box:

Close up on automotive fuse box on bench

The "IG3" power supply that's normally switched inside the IGPM by firmware has been replaced by... a switch!

IG3 relay switch on bench

Brakes

Integrated Electronic Brake module, as installed in Kona

I also wanted to leave out the "Integrated Electronic Brake" (IEB) module, if possible. This electric brake booster module incorporates ABS and traction control. This means it relies on input from wheel sensors, among other things.

From CAN log analysis it seemed likely that we could spoof the messages from this module, instead.

The Kona also has a redundant hard-wired brake signal, which connects the brake pedal to both the Vehicle Control Unit (VCU, part of the EPCU) and the Smart Key Module (SKM, for "press brake before starting"). The VCU also independently reads the inverse of this signal on a second wire.

Initially a simple switch was used for this, but it turned out to be easier to mount the brake pedal itself, at least for the first version:

Brake pedal mounted upside down to side of bench

Removing the return spring and mounting it like this means it can be pushed back and forward like a lever. Odd, but functional!

The laptop would run a bench_kona.py program that injected the spoofed IEB CAN messages to the bus, with payloads corresponding to the vehicle sitting still with someone's foot on the brake. This seemed safe enough to me at the time.

Narrator: As we shall see, this was not quite safe enough.

Smart Key Module

My Kona's Smart Key Module

The Smart Key Module was shaping up to be the trickiest module. It contains a lot of logic around the various keyless entry features and door locks, and switches on the main ignition "IG1" and "IG2" power relays. The Bench Kona only needs a few of these functions, so maybe the SKM could be replaced with some switches for now?

Unfortunately, the SKM also has three hard-wired connections to the VCU:

  • "P_STS PWM", not sure what this is.
  • "EV Ready Backup" signal.
  • "IMMO Signal", assumed to be the vehicle immobiliser signal.

Until/unless these can be spoofed, the Smart Key Module needs to behave as if it is operating normally in a real Kona. This means wiring in all of its various power connections, relay outputs, the car's "push to start" power button, and even some of the antennas:

Smart Key Module wiring

Plus the bench_kona.py program had to be augmented to send some spoofed BCAN (Body CAN bus) messages to the Smart Key Module's BCAN transceiver, so it thinks that the doors are closed, etc.

And... nothing happens!

After triple checking all my custom wiring, it was time to attach the 12V Battery and manully switch on "IG3" to start powering up. Various CAN messages appeared on the bus, a few relays clicked in, and... nothing else happend.

The power button, attached directly to the Smart Key module, mostly sat silent but occasionally flashed through five mysterious amber blinks:

GIF of the power button blinking

Attempting to pull diagnostic codes from any of the vehicle components failed, presumably because the "car" was powered off. This left me back at the same awkward spot as last year with the BMW gear selector - a complex electronic system sitting there silent and inscrutable.

RTFM

After trying a lot of things that didn't work, I was reading Hyundai forums online discussing various "won't power on" issues and someone mentioned there was a failsafe "limp home" start method where you press the vehicle key into the power on button. Sure enough, it's right there in the Kona user manual:

Page from Kona manual showing how to emergency start with the vehicle key

Pressing the key against the button, it would now replicate the "five amber blinks" sequence every time. Still, nothing else came to life...

Steering Wheel Lock

Going back to first principles, I started probing all of the inputs and outputs of the Smart Key Module to see if it did anything in particular when the button was pressed. It looks as if it very briefly tried to power up the Steering Wheel Lock module.

This module hadn't been wired in, on the assumption that the Smart Key Module would not consider it a fatal error if it was totally missing.

Turns out the steering wheel (complete with blown airbag) barely fits inside the bench:

Steering wheel jammed inside bench

After wiring the steering wheel lock's data and power lines3, the car finally powered on:

Kona power button illuminated in blue

Such a glorious blue light! 🥳

I heard the tell-tale clunks of the main contactors closing in the traction battery pack, and the Bench Kona even went into Drive. However, the wheels wouldn't turn even with the brake pedal "released".

Kona Gear selector with D illuminated

The bench_kona.py program was spoofing CAN messages saying that someone was standing on the brake. Guessing that's why the motor doesn't turn...

Motion

Next step, update the bench_kona software and add an input to turn the brake on and off. A very sophisticated user interface:

Bench Kona UI screenshot, just a checkbox for Braking

This is a bit clunky as there's a separate hard-wired brake pedal signal as well, but by this point the excitement of a possible breakthrough was making me impatient:

Success? This is the motor in Drive steadily trying to "creep" forward,2 and also revving up once or twice due to a gentle accelerator press.

Too much motion

So far the Bench Kona has been put into Drive three times. I only filmed one of the tests, but the other two ended with uncontrolled motor acceleration! 😱😱😱

Seemingly nothing would stop the motor - even switching to Neutral, putting the brake on (via both switch and CAN), or totally stopping all spoofed CAN messages. After twenty or seconds of the motor spinning flat out, the motor controller flagged a "Motor Excess Current" fault code and it came to a stop.

This was both unexpected and terrifying, and I realised how unprepared I'd been for this eventuality.

I think what was happening is that the Vehicle Control Unit is running a control loop that outputs a motor torque request and reads wheel speed data as feedback. Because the bench_kona.py program was reporting fake 0 wheel speeds all round, the VCU's control loop assumed the torque it was requesting from the motor was either too low (when accelerating) or just fine (when not accelerating). So the controller only ever increased the torque request, or kept it at the same level. Even when I simulated pressing the brake it was like "Nothing needs to change, we're not even moving!"

Meanwhile, the electric motor controller (MCU) is receiving the torque requests and frantically trying to achieve the requested motor torque by revving the unloaded motor faster and faster. This is an impossible task as the motor is spinning unloaded, so torque is minimal.

This theory is a bit surprising, because you'd think the VCU would have some failsafe where it also reads RPM from the motor controller (after all, what happens if a driveshaft breaks and the wheels aren't turning on the real car?) It's pure guesswork at this stage, maybe the real logic is very different.

That said, the internet does contain some supporting material. For example, there is a Hyundai patent about motor control that includes this signal diagram:

Fig 1 from the linked patent

(APS = Accelerator Position Sensor, BPS = Brake Position Sensor.)

If zero wheel speed is the culprit, then all that's needed for appropriate motor control is to send spoofed wheel speed data that matches the current motor rpm. I think we know where the motor rpm signal is found out in the CAN messages, but I want to do more logging on a real Kona to be 100% sure. I don't ever want to trigger that uncontrolled acceleration state again!

Not to mention that the Bench Kona now needs a few more features added, such as a rudimentary cooling system. It's also past time to write some microcontroller firmware, rather than little desktop Python programs.

After all this, it's also possible that the VCU's black box control logic turns out to be too complicated to adapt into a reliable EV conversion. In that case, adapting something like the openinverter motor control board to the Kona's existing IGBT drivers may be the best way to give these parts a second life. We'll see...

Stay tuned for the next update, hopefully soon!


  1. Noting again, for anyone who currently has steam blowing out of their ears, that this wiring technique is for the bench, only

  2. This is a weird feature of Hyundai EVs, they emulate an automatic transmission ICE vehicle by creeping forward in Drive. Hyundai even hold some patents for doing this. Online, most discussion I found about this feature was about how annoying it is, especially as you can't permanently disable it... 

  3. Living in the future means that you say odd things sometimes. 

Thoughts on “The motor turns (too much)