Tesla Model 3 Rear Drive Unit Hacking

Topics concerning the Tesla front and rear drive unit drop-in board
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 »

That's very odd. I can't see why execTicks would need to be volatile. It's only manipulated in interrupt context and read from the main loop. The C2000 has 32-bit atomic reads/writes so this shouldn't pose any problems.

There is some glitching of the PWM when running with printf() calls. I presume this is because I've not bothered (yet) to set up proper emulation support for running the interrupts when the debug interface is active. Removing printf calls on the main loop stops this. Still not able to trigger any DT errors either way.

You are seeing quite different performance numbers for some reason. I get 1424155 ticks per 0.5 second iteration of the main loop. Removing the calls to set the phase counter compare registers does reduce this by ~108k ticks. This is a whopping 266 CPU cycles per main control loop iteration which on an unoptimised debug build seems fine given all the additional asserts, etc involved.

Don't follow your ADC comment. My plan is to sample the 2 phase currents and sine/cosine resolver values at the exact center of the PWM waveform (when the counter = 0). The main control loop will then run on the ADC EOC interrupt. I'm currently rejigging the PWM synchronisation hierarchy to get the resolver exciter output going and so I can add a phase shift to align the peak of the resolver exciter with the center of the phase PWM. This is basically the same approach as stm32_sine but with a little more hardware assist due to the cleverer PWM units on the C2000.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

It could well be the printf(). In fact I caught another DT error later - with volatile. It happened when CCS ran printf-ing in a background window.

Omitting volatile could lead to wrong results being read but I also do not see how it can cause PWM glitches. You tell me :) You have way more experience in MCUs - I engineer databases for living. MCUs/STM32 have always just been intensive hobby.

I see also similar 1.4M ticks/0.5 seconds when running the full code. I had just removed PI control during debugging.

Not sure if I can't be of much help atm, you are way ahead of me on how the C2000, the inverter and libopeninv work and you seem to exactly know where your heading and what you are doing. Happy to assist where you see need.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Btw, IIUC then atomic and volatile are different concepts, volatile will prevent the compiler to optimize the variable. It prevents it from being written to a register thus potentially "hiding" changes to it during parallel access. It also prevents out-of-order execution.

Atomic "just" ensures a variable is written "in one piece" with well defined values for parallel reading.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

I just connected the rotor to the power out. Pretty much

Code: Select all

// 2pi = 0xffff, about 0.5 rot per sec at 12kHz
BaseT::angle += 2; 
FOC::SetAngle(BaseT::angle);
FOC::InvParkClarke(0.1 * 0xffff, 0.25 * 0xffff);
PwmDriverT::SetPhasePwm(...)
12V 1A are sufficient to move it. At the moment it just rocks forth and back in a small angle. But it moves and it looks strong enough to even fully turn it with the right ramp-up and parameters.

There is no oil in the gearbox as I moved the engine to the office, too cold in the garage.

Connecting a simple cable to a single power output kills (again) my debug connection. Not even connected to the rotor.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Engine is turning. Even quite smoothly. It requires still a bit of a manual ramp-up playing with the phases. I replaced the inverse park clark with my own floating point version as I didn't get the int based to turn (probably out of ignorance about it).

This is with 12V and a small angle change of 2.0*PI/12000.0f per interrupt call. Every irq is handled. No position encoder yet or current measurement. But that should be easier now.

It doesn't like my .mp4 files as attachment - otherwise I'd post.
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 »

Wow! That's fantastic progress. Here's a quick look at fbo's video:

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 »

I also made good progress today though a lot more theoretical. Got the resolver exciter code finished and synchronised with the PWM generation. Gave me a trace like this:
SDS00012.png
This shows the 3 main phases (with static 25%, 50% and 75% duty cycle PWM - high-side drive for reasons) and the exciter output on the wiring harness all perfectly aligned. The exciter output is reduced a bit by running at 12.2kHz (2.24V) rather than 10kHz (3.17V) but I'm hoping this should still be enough signal to provide an accurate position. Next stop for me is getting the analog capture of sine/cosine and phase currents going.

The bit of the process I've not really got a handle on or spent any time thinking about yet is the CAN side of things. The stm32_sine code has a whole serial terminal to send commands to the inverter that we need to replicate to control this beast. It also gets used for outputting the entire parameter set as the inverter is running. I don't understand the existing stm32_can.h/.cpp capabilities. Is this enough to monitor a running inverter or is it only a subset of the params?
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 »

That is crazy cool:) Well done indeed. CAN can be used to stream data from the inverter, receive commands and basically do most things that can be done on the web interface. For example it should be possible to use the Zombieverter VCU to provide an interface to the M3 drive unit via can or indeed any other board or vcu.
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 »

davefiddes wrote: Tue Feb 22, 2022 10:34 pm I also made good progress today though a lot more theoretical. Got the resolver exciter code finished and synchronised with the PWM generation. Gave me a trace like this:
Looks really good. I finally ordered a second probe to my oscilloscope, maybe I can see a bit more then as well.

I have two of questions about offsets:

1. The Tesla resolver is not a rotating exciter but a fixed one. There are 10 equally spaced coils in a ring. I can't tell which are exciters and which are the resolver and how they are connected.
sincos-rotor.jpg
sin-cos-exciter-resolver.jpg
- 10 gives only odd combinations of e.g. 2 exciters and 2x2 resolver?
- This combination should do something with the offset?
- Also a bit uncertain when the exciter sinus current peaks should cause max resolver current.

2. What sampling window wrt the exciter sin wave? I guess symmetrically around it's max?
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 »

Jack Bauer wrote: Wed Feb 23, 2022 6:43 am CAN can be used to stream data from the inverter, receive commands and basically do most things that can be done on the web interface. For example it should be possible to use the Zombieverter VCU to provide an interface to the M3 drive unit via can or indeed any other board or vcu.
That's what I was hoping to hear. I've not explored that part of Johannes' code or the web interface. It sounds like porting the stm32_can module will do much of what we need.
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 »

fbo wrote: Wed Feb 23, 2022 10:50 am
1. The Tesla resolver is not a rotating exciter but a fixed one. There are 10 equally spaced coils in a ring. I can't tell which are exciters and which are the resolver and how they are connected.
- 10 gives only odd combinations of e.g. 2 exciters and 2x2 resolver?
That's the key bit of information. The odd (sinusoidal) shaped rotor acts as a variable transformer and couples the excitation to the sine/cosine coils depending on the position.

Johannes has a great introduction to how this works. It's only 20min long and well worth a watch.


fbo wrote: Wed Feb 23, 2022 10:50 am - This combination should do something with the offset?
- Also a bit uncertain when the exciter sinus current peaks should cause max resolver current.
2. What sampling window wrt the exciter sin wave? I guess symmetrically around it's max?
The offset I was adding yesterday was to do with the phase lag caused by the conversion of the analog filter that converts the square wave coming out of the MCU to a sine wave. The reason for aligning this with the PWM is so that we get the results of the resolver position that corresponds to the current readings at the same moment in time.

The coupling between exciter and sine/cosine should by at its max at the peak of the sine wave. The sampling window should be tiny in comparison to the freq of the signal. What we are interested in is the instantaneous magnitude of the sine and cosine signals. Aiming for the peak of the sine wave just gives us the best chance of getting the largest (and thus lowest noise) signal.

TI have clever examples in their motor control code that samples all over the exciter wave form and applies digital filters. I'm sure this is wonderful but it's a lot more complex and the existing stm32_sine approach works in a lot of motors...
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 »

The pinout on my github has the resolver pin details.
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 »

resolver.png
Resolver triggered at 12.2kHz responding to turning engine. Rotor move is by enforced theta (angel input to inverse park clark) stepping at 2*pi/sec, i.e. 2*pi/12.2k every irq - rotor moves much slower like at 2*pi in 16-ish seconds.

Seeing approx 80us sinus wave and the expected "hull" - at about 500ms.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Forgot the gear ratio, so actual rotor is moving about 10x faster. And it is obviously 1sec over entire 2*pi of the hull.
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 »

Sounds like the ratio of poles on the motor and poles on the resolver. This information is on the thread somewhere but hasn't made it to the wiki. We'll need that soon hopefully to configure the inverter. Any chance you could dig it out?

Just pushed a useful but small change. I've set things up so that EPWM units now continue operating in debug mode. Of note this means that printf() no longer causes weird periodic glitches in the PWM output and resolver exciter.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Jack Bauer wrote: Thu May 28, 2020 8:23 am Some info on the motor from a youtube comment (obviously elon under a pseudonym) :

Hope this help: The rear model 3 motor is a 6 pole permanent magnet motor. The rotor has 4 sub stacks, Each end sub stack is skewed by 3.33 degrees in relation to the middle 2 stacks which are matched to each other. The resolver is a 3 pole resolver.
I was also suspecting pole ratio.

Gear ratio is 9:1 on the model 3 RDU. I'll measure RPM more precisely but I guess then that it was closer to 18 seconds per turn.

What about the 10 coils though? With the resolver unmounted and sending PWM to the exciter I got a small nail to stick and "sing" on each single coil.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

It was even 26secs per turn, 2.89 secs per rotor turn.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

davefiddes wrote: Wed Feb 23, 2022 6:27 pm Just pushed a useful but small change. I've set things up so that EPWM units now continue operating in debug mode. Of note this means that printf() no longer causes weird periodic glitches in the PWM output and resolver exciter.
Great, even reading the comments in the PWM header file about free mode didn’t make it obvious to me what it was supposed to do.

Noticed that you also pushed your new PWM and exciter code. Above scope pic was still done with my own. Guess I can switch to your’s then.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Just sharing this picture.
7-Figure13-1.png
https://ieeexplore.ieee.org/document/6953227

Exciter and resolver coils are placed in the same tooth! Exciter are in every tooth. Just unclear if the Tesla resolver has alternating sin and cos coils or all 3 coils integrated into each tooth.

1 pic explained everything and more than 1000 youtube videos glossing over actual key info. This one pic contains all the missing information I was lacking for the past 2 weeks to understand how the resolver works. I thought it had to be like that but no evidence found until I saw that pic.
fbo
Posts: 36
Joined: Sun Dec 26, 2021 4:58 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by fbo »

Finally I can reliably start the motor just via software and keep it running.

I measure the angel via resolver, add a hardcoded delta to it, then run inverse park clark to calc the new space vectors for phase voltage.

However, somewhere on the way I messed up and need to switch phases.

Next steps would be to figure out phases and also get to current measurement and then clean out a lot of messy code.

Again, 12V sufficient to drive it for testing.

I noticed that there is no phase shift needed between exciter PWM and phase voltage PWM. The total delay from exciter PWM back to ADC "exactly" (exactly enough) matches 40,96uSec - half of our 12.2kHz. I.e. the peaks of the resolver end up in the middle of our phase voltage PWM if the exciter PWM is turned right. I.e. exciter PWM high at phase voltage PWM zero. This way I can also keep interrupt handling tied to phase voltage PWM.
Doig5710
Posts: 44
Joined: Wed Apr 22, 2020 6:41 am
Location: Rangiora, New Zealand
Has thanked: 44 times
Been thanked: 1 time

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by Doig5710 »

Not sure if it's helpful or needed but I have a M3 drive unit, damiens usb adaptor and a 4 channel picoscope 4425a if it would help for any waveforms of things, not any good at the coding stuff but could get clear images of what's going on if it would help things out at all.
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by EV_Builder »

Hey guys how are we doing here...silence before the storm?
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
Denxf
Posts: 1
Joined: Mon May 02, 2022 1:45 pm

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by Denxf »

Hello. I really like what you are doing. I see you have made great progress with the Tesla Inverter. I am not very versed in the software part of the Tesla inverter control, but I have the original Tesla program for flashing the bootloader and the firmware of the tms320 chip. write me in private messages.
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 »

Just to give an update here as I'm getting a lot of contacts as usual on the subject. davefiddes is engaged in the non trivial task of porting the openinverter firmware to the TI MCU on the drive unit. This is not an overnight task and we are beyond lucky as a community to have him involved at this level. When he is ready I'm sure he will post and update and I have two driveunits for testing as its about the only thing I can do to help as the software development skills required are WAAAYYYY beyond me. Whether it takes another week, month or year is immaterial as when it IS released ... well you guess:)
I'm going to need a hacksaw
User avatar
vwbrady
Posts: 246
Joined: Mon Dec 16, 2019 1:18 am
Location: Seattle, WA
Has thanked: 5 times
Been thanked: 11 times

Re: Tesla Model 3 Rear Drive Unit Hacking

Post by vwbrady »

Very good to hear. Yes, I can only imagine what kind of port job that must be. Thank you Dave!

I have a M3 DU in wait for a "some day" project. Been thinking about selling it and doing more Leaf stuff. Just so much cheaper!
Post Reply