Tesla Model 3 Rear Drive Unit Hacking

Topics concerning the Tesla front and rear drive unit drop-in board
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Maybe I still got the wrong pins. But quite sure I hit pin 1 and 2 for example.

I added two commits to the PR just in case you are curious. Not the final cleanup yet.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by Jack Bauer »

Amazing work guys:) You'll have it spinning soon. There are indeed a lot of gates between the mcu pins and the gate driver. I documented this in a few videos.I also ran the motor in foc mode using a prius inverter.
I'm going to need a hacksaw
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Yes, at least one more gate. Got the pwm on the mcu side now, SS1/2 high but still not measuring pwm on the gate driver IN+ and -.

Guess I'll either watch through the videos (again) or just unscrew the board. Latter probably faster ;-) Hope it's max 4 layers with all signal traces on the outside for tracking them.
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by davefiddes »

Sincerely hope you are joking.

The summary can be found in https://github.com/damienmaguire/Tesla- ... PinMap.ods

You need to drive GPIO78 low.

For a detailed explanation watch from 47:00 on:
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by davefiddes »

And be running the current HEAD where I have integrated a basic use of the gate driver config and PSU enable into inverter_main.cpp
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Yes, I was joking (obviously). So, it is 3 things that need to be controlled: PSU Enable Pin, SS2 and GPIO78
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Posting to wider audience. Maybe there are ideas. I am not able to see any meaningful output of the Gate Drivers.

I have PWM on the input of the gate drivers. SS2 high, PSU enabled, Gate enabled, OE enabled. 5V on the isolated side everywhere, even on the HV 3-phase output.

I have 66.7 V on the HV input. Hope I didn't already kill the power stage by unplugging it.

Testing e.g. TP1443 at the isolated B Low side of the gate driver. These are gate driver source/sink current. Like all 6 gate drivers their GON/GOFF (source/sink) seem to be connecting directly and without resistors to the test point and the power stage.

However, no square wave at the Test Point. All conditions for at least creating output there should be fulfilled? And I think there should be output at GON/GOFF even without a HV connection?

NO error detected on the gate drivers. Maybe I need to find a better GND for it to be measurable? Do I need to fool HVIL first? But this 4k Ohm array should only draw 20mA.

Any idea what these 6 x 2 guys between high and low side are and do? Used as diodes? Maybe I missed that part in Damien’s video. I can’t read or match their device parts. One is something like GBC942 with only two pins and GND(?) connected. They seem to work with low voltage, 5V.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by Jack Bauer »

Here is my entire collection of pictures of the rear of the RDU inverter pcb.
Attachments
IMG_20201116_131214.jpg
IMG_20201116_131210.jpg
IMG_20201116_131203.jpg
IMG_20201116_131154.jpg
IMG_20201116_131148.jpg
IMG_20201116_131134.jpg
IMG_20201116_131128.jpg
IMG_20201116_131038.jpg
IMG_20201116_131033.jpg
IMG_20201116_131028.jpg
IMG_20201116_131022.jpg
IMG_20201116_131014.jpg
IMG_20201116_130944.jpg
IMG_20201116_130937.jpg
IMG_20201116_130932.jpg
IMG_20201116_130338.jpg
IMG_20201116_130335.jpg
IMG_20201116_130325.jpg
IMG_20201116_130303.jpg
IMG_20201116_130252.jpg
I'm going to need a hacksaw
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by davefiddes »

Thanks Damien!
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Very good to have those pics.

In the meantime I identified the transistor pairs - 6 N/P channel MOSFET pairs of

- a ST STD46P4LLF6 40V P-channel and
- a Infineon 3N0408 N-channel.

Also found better isognd and measure now stable -5V permanent voltage at the source/sink gate output of the gate driver.
20V on the MOSFET pair when having roughly 70V on the HV connector.

Not sure if any of this helps. Analog power electronics is clearly not my area.
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by davefiddes »

The supply rails are as I would expect with the main Gate PSU turned on (and no HV DC). I can't see what would stop the PWM appearing on the isolated output pins of the STGAP1AS gate drivers. No idea what goes on downstream of those chips. It might be a fun side-task to reverse engineer based on the info you now have.

Dumb question but is the gate driver still happy? If ~DIAG asserts the LED comes on so I doubt that's a problem. What about the ~SD line (TP58 near Phase C U292) is it high? Is the gate driver still reporting no faults on the console in the main loop?
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

All MCU side conditions for operation are met. After reading the data sheet again I can only guess that the driver is in safe state.

This is due to DESAT protection which - IIUC - is controlled by HVIL. The DESAT flag should be set in STATUS1 but that is something I don't see due to CIO letting me down. Another possibility for safe state is too low VH but I doubt that as we are talking a P/N pair operating at approx 20V which is available. So, need some more debugging.

Not sure if it is CCS on Mac or flaky JTAG wiring but debugging is painful. Can't restart the code without re-loading it, CIO won't properly print. Inclined to add CAN for diagnostics, shorten my JTAG wires, play with .cio memory and dust off my Linux machine.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by Jack Bauer »

Hmmm...Keep in mind with just the mcu held in reset I was able to drive the gate drivers directly with a modboard during initial testing. Might be worth trying that?
I'm going to need a hacksaw
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by davefiddes »

Getting the status values out of the gate drivers is pretty straight forward. If you add a hardware (not software) breakpoint in CCStudio on the GateDriver::VerifyRegister() just after it reads a register. This will give you a dump of the register contents for all 6 gate drivers.

The reason it worked with the MCU in reset but doesn't now is likely because the Tesla config I've loaded into the gate drivers is stricter than the bare post-reset config.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by Jack Bauer »

Ah ok got it.
I'm going to need a hacksaw
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

The error we ran into was REGERRRR in STATUS2. Disabling DESAT in the gate driver fixes it. I guess using HVIL also would fix it.

I run into DT_ERR now - something I was almost suspecting may happen. Unlike REGERRRR it at least doesn't put the driver into sleep. Datasheet:
When the deadtime function is enabled, the STGAP1BS returns a “deadtime violation” fault when the control unit
tries to turn on any of the drivers in one leg during the counting of the programmed DT time. If such event occurs
the DT_ERR flag is set high and latched.
While supported by the STGAP1 we may try to only use the STGAP1's DT feature - instead of mixing it with the MCU's. Also need to verify if we actually have the PWM phases and dead times configured correctly.

I think the red error gate driver LED is only flagging for low voltage side problems.

Other issues:

- loosing debug probe as soon as HV is enabled with OE switch
- loosing SS2 pin when debugging - likely due to slow strobe or an error condition on INT not reacted to
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

red is IN- (up), orange is IN+ (underneath). Duty cycle 25%.
Screenshot 2022-02-13 at 20.19.18.png
I think (can you check?) IN+ and IN- are inverse and deadtimes are measured at 855ns (shall be 875ns from MCU) and longer than the gate driver's 800ns.

1. MCU's deadtimes need to be shorter than the gate driver's to not trigger DT_ERR.
2. IN+ and IN- need to be inverted to get GON at 25% in line with the MCU's PWM duty cycle. Now GON is 75% on.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

I got a nice square wave on oscilloscope on the high voltage motor connectors.
Also gate drivers seem to finally behave with a -25/+25V signal on it's GON/GOFF output matching the input PWM's 25% duty cycle.

For that to happen I had to do a couple of things:

1. replace 12V power supply to something with more amps, this was key to running the board stable
2. swap PWM output A <> B
3. disable DESAT checking in the gate driver
4. turn HV on only well after system got into a stable state, otherwise PMIC will trigger SSx low, needs to be further investigated

I also replaced printf with basic CAN output, which allows diagnostics in free running mode. CAN is 3V and thus at a level for saleae, so no CAN receiver needed.

Couple observations:

- unlike what I first understood the MCU's DeadTime has to be > gate driver's; IN+ raising edge must simply not fall into the gatedriver's DT counting of 800ns started at IN- falling edge on the odd, and vice versa on the even drivers (see 7.2 in datasheet, direct control), so MCU DT of 875ns was okay
- MCU deadtimes are skewed now as I just swapped A/B but didn't adopt other parameters, but it doesn't seem to matter for the gate drivers
- unless there is a trick or I just made a mistake point 4.) above means that an external control unit is needed to control the contactors
- only way to reset STATUSx from STGAP is to set SD low and thus disable the driver, can't even reset individual flags without causing SPI error flag to be set
- CAN lines are immediately polluted with noise when HV is on. I have not terminated them.
- measured against isognd output voltage is more than my scope can show, like > 80V with a 70V supply
- 10kHz is a very annoying frequency to your ears
- pins with a plastic head from a sewing kid are perfect probes through Musk goo

Not sure if this is enough to drive the rotor yet. Also, I need to revert the code that currently runs at fixed 25% duty cycle for testing. Code needs a lot of cleanup before I can raise a PR.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Btw, maybe most important for simplicity of testing: no need for any high voltages.

I can drive the output with 12V on the HV input. In 12V, out 12V PWM. Increasing input to 20V the output is following along nicely 1:1. If it would turn a rotor is a different question. Wondering if we can test current sensors with simple resistors and lower currents, assuming we don't need the inductance component of the motor windings for that.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by Jack Bauer »

I already work out the current sensor ratios.
I'm going to need a hacksaw
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by davefiddes »

Spent most of yesterday testing @fbo's changes. I think I've found an explanation for why there was an audible whistle from the inverter...unfortunately it's not good. I took this trace of the PWM going into the gate drivers (yellow is low-side, blue is high-side).
SDS00005.png
SDS00006.png
As you can see the dead-band appears to be incorrectly configured. Both high-side and low-side drivers are turned on at the same time. :o This is also likely what was causing the DESAT fault to trip on the gate drivers. Because the edges were outside of the configured dead-band it is acceptable to the STGAP1AS (see Figure 8 on page 28 of the datasheet) which doesn't attempt to fully understand the gate topology.

I backed out all of the changes to PWM and gate driver config. This generated a reasonable looking PWM that the gate drivers were happy with. Turning on an HV(!) supply of 20V caused no audible 12.2kHz whistle. Hooked up my HV differential probe and with a 50% duty cycle I was getting a clean 20Vp-p / 10Vrms PWM waveform on each of the unloaded phases. My JTAG connection took to crashing after a minute or two with a comms error. I suspect that my long unshielded makeshift cable was likely picking up a lot of noise.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Again, thank you for the analysis and time spent on this. Your latest version indeed works flawlessly on my board as well.

The version you tested above seems to miss the latest patch though. Anyways, let’s forget about it.

What is weird though that DESAT error appeared even before I started to look at PWM settings, iirc. After disabling DESAT the DT error happened making me first start to look at PWM changes. Who knows after days of testing and debugging, I simply violated my own rule to always step back and take the 10k feet position on the problem when stuck.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

I see DT errors again on some of the gate drivers (one or two of them only, not all the high or all the low sides) on the current base line code. This happens only when adding additional steps like reading currents from ADC. Not sure yet if it is additional CPU cycles in irq handling or using e.g. PWM4 as a trigger source to read ADC. The first could explain why I saw DT errors in the first place earlier on as well.

If I understand shadowing and loading new duty cycle at zero counter correctly then it should protect us from situations where DT errors could occur even if the irq handling takes longer than one period.

Started on implementing position encoder and current readings implementation. Baseline implementation works just well producing PWM and gate driver output over hrs without issues.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by Jack Bauer »

Thanks for the hard work folks. Need to give this a try myself as would love to see some pwm on those outputs. Plus of course make some video so it looks like I have done all the work myself as I conveniently airbrush everyone else out of history. Muhahahaha:)
I'm going to need a hacksaw
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Adding volatile to the execTicks of the performance counter seems to have solved the problem.

volatile should be avoided by all means. But I guess there is no better option for variables shared between irq handlers and main loop on the C2000.

As DT errors never happened in free running mode I was assuming a connection to printf, CIO or general interaction between interrupt handlers and main loop.

Other random observations:

- EPWM_setCounterCompareValue adds 130k CPU ticks to the printed PWM cycle of my current otherwise 750k CPU ticks loop
- never need to wait a single cycle for End Of Conversion of the ADC
Post Reply