Tesla Model 3 Rear Drive Unit Hacking

[Jack Bauer]

Yeah 100% I don't know what I don't know and this could well be the time we see the limits of the f103. Only one way to know. Thanks to "someone" working out the gate driver and psu spi we do have a better than average chance of not blowing the inverter:) worst case the front motor is plain jane induction so it will 100% work in that application. I guess we all play to our skills and software is certainly not mine. I'm constantly impressed by the folks getting oem parts and Tesla in particular running via can.

I've no doubt the oem's keep an eye on us. Case in point I have half the jaguar land rover powertrain team following me on twitter who are also not too keen on me replacing an infinion tricore mcu and a cyclone 4 fpga with a f103 and some random logic:)

[mdrobnak]

I've no doubt the oem's keep an eye on us. Case in point I have half the jaguar land rover powertrain team following me on twitter who are also not too keen on me replacing an infinion tricore mcu and a cyclone 4 fpga with a f103 and some random logic:)

They're more likely jealous - how did we overpay for this?!

And yes, front motor should be just induction.

-Matt

[johu]

Exactly

Until proven otherwise I will not believe that creating a rotating magnetic field that is in someway synchronized to a rotating rotor is a heavy number crunching operation. And no, more horse power does not add more CPU load

And all that stuff going on in the millisecond loops - forget it, can hardly even measure the CPU usage of it. 72 MHz isn't much but then the CPU is in no way disturbed by silly IO operations because that is done via DMA. In "professional" products I have actually seen the IO take up 30% CPU time alone - despite the MCU being able to offload.

Used to work on solar inverters (the large MW ones), the control loop guys actually loaded down some older TI DSP to 97% So in the next product cycle the hardware guys decided to whack in a zillion of FPGAs and two multicore processors Just to be safe I guess. Never found out how much duty these actually did. Assuming the TriCore's of this world probably spend most time idling.

[collin80]

Yeah, I think mostly they over engineer stuff so that they don't get sued. This is especially true for anything sold in the US. We sue each other if the wind blows the wrong direction or someone gives us a sour look. So, redundant processor cores that can be cross checked isn't such a bad idea.

But, I do think that 72MHz should be enough to run a single motor loop. The funky motor they used in the rear might be weird but I can't see how it couldn't be controlled by a single core - maybe using some look up tables to produce a smoothing effect to keep torque ripple under control. It's hard to say. I wonder, has anyone been daring enough to try to take a scope capture of the PWM to the motor while the system is running and driving? That would be very instructive.

[EV_Builder]

I think they create a architecture which is capable of everything you can think of. You don't want tobe left behind because you didn't add those cores and another brand did. The turn-around times around redesigns and validation etc. are big. You better over engineer. The price the big boys pay for PCB's sillicion etc. is nothing compared to us. The risk of being left behind is way bigger. That said they cant afford to use a nuke to kill a mouse.

Also the tasks given to the motorcontroller in the Tesla are way more then "only" making a magnetic field.


Now another question. Can i contribute? And in which way?
I would like to use the M3 motor in my build (on the front axle)..
Should i buy one yet or is it too soon?

[mdrobnak]

That all said, I just had my rear motor replaced. For a fault being caused by the inverter apparently. Doesn't seem too prevalent, but it is happening. Zero cost to me thankfully, and I saw how much nicer the Model 3 is over the 2015 Model S in one weekend.

-Matt

[Jack Bauer]

An inverter fault! but....but ....thats not possible with dual 200mhz processors:)

Regards helping out : viewtopic.php?f=10&t=575&start=200#p21574
I'm not going to advise on buying a drive unit or not as yet but we have overcame a major obstacle regards the hardware for replacing the mcu.

[mdrobnak]

A little birdie told me it was an "isolation fault" so I'm not sure what was going on, but I sure didn't like it! It happened once in Nov, then in January...then a week before my appointment, and on the way to the shop! So happy that's dealt with, and they didn't ask any questions about charge port errors.

-Matt

[davefiddes]

To provide a distraction from trying to understand the F28377D ePWM module architecture I spent this afternoon putting together a header file with command and register definitions for the STGAP1AS isolated gate driver. You can find it here.

During testing I spotted a couple of minor nits in collin80's analysis. It seems that CFG3 register uses 10V threshold on the 2LTO rather than the 13V they indicated. Also I don't think the ~DIAG1~ output will be asserted for SPI comms errors. I would image that we'll need to check the stm32-sine driver output very carefully against the captures. I still don't understand these chips but the possibility for big bangs if programmed incorrectly seems quite high!

I'm going to do the same for the TLF35584 PSU chip now.

[Jack Bauer]

Thats amazing! Thank you so much:)

[davefiddes]

Put together a header file for the TL35584 PMIC which you can find here. I'm just parking it on a branch while I work on this stuff. It's a complex chip, seems to be watchdogs all the way down!

From what I understand of Collin's analysis and the datasheet it seems that we need to talk to it to get the various supplies powered up as a minimum. The watchdog stuff whilst important long term seems unimportant for board bring up. Ditto the fault monitoring capability.

Currently hacking up a set of decoder utilities to automatically parse the SPI captures against my header definitions to make sure that I understand the protocol correctly, get the right CRC, etc. Should be useful to make sure we understand what the Tesla SW is doing.

[Jack Bauer]

I can confirm with no spi to the psu chip it does bring up the various supply rails.

[davefiddes]

Ah. Didn't read the DS correctly. It seems that the chip starts in the INIT state once the power rails are good and this enables all of the LDOs. Looks like we don't need to program it to get things going. Obviously needed for watchdogs, fault monitoring and sleep power management at some point. Will concentrate on the gate driver for now.

[EV_Builder]

I was wondering if i would contribute what could i do? Which info is needed? Who and where do we coordinate that?
About the SPI can we isolate such a chip and test the settings / configuration?
Do we already know the type nrs?
Or do we want to know the Tesla configuration?

[davefiddes]

I'm still bashing away on a driver for the STGAP1AS gate driver chips. We know how Tesla set this up thanks to Damien's SPI capture and Collin's and my analysis (details above and in a PDF). I've been sidetracked with crc8 spec issues and stm32_sine debugging problems but making better progress today. Hopefully I'll have something to share in the next week. I'm planning on replicating the Tesla config which is mostly sane. It seems that just logging an error and stopping the inverter on a fault condition is the only sane thing to do.

Stuff that would be useful to know is how Damien has wired up the gate driver SPI and interrupt lines. Wasn't going to bother him until I had everything else working as he's the only one that can use it.

The fancy TLF35584 PSU/PMIC remains untouched on my side so far. It seems pretty straight forward to configure it as it's just a fancy watchdog with the ability to raise faults if there's a power problem. If you're happy with libopencm3 and stm32 development then feel free to have a go!

[davefiddes]

I'm struggling with a detail on the STGAP1AS SPI capture. Where was the MISO data tapped into?

The reason I ask is that it seems that the gate driver chips are only returning a single value when queried for a register value despite being queried 6 times. I think this could have happened if the MISO came from the first gate driver chip. Can you help Damien?

The fancy TLF35584 PSU/PMIC remains untouched on my side so far. It seems pretty straight forward to configure it as it's just a fancy watchdog with the ability to raise faults if there's a power problem.

I rewatched your Nov 2020 reverse engineering video and my statement was a load of rubbish. The SS2 line from the TLF35584 needs to be asserted which requires the chip to be programmed and transitioned to the NORMAL state. Which is sort of the point of the chip...apologies for the misunderstanding.

[Jack Bauer]

Will check my notes on this.

[station240]

I'm back to being able to do *some* work on this, had to buy an entirely new PC as the video card and motherboard have been acting flakey.
Still re-installing software.

Just finished making the TMS320F28377/28379 part in design spark, as I didn't entirely trust a chinese project's PCB/schematic layout.
As I don't have any Tesla hardware lying around, I'll be making a PCB to break out all the pins needed for this, and my other project.

As for the overkill OEM CPU/FPGA cores, it didn't seem justified to me either when I first heard about it.
Twin CPU core MIcrocontrollers I get, one for all the comms/user/slow device stuff, the other for the motor/safety related stuff.
Triple CPUs and extra FPGA power... for a fancy motor drive... it really doesn't make sense.
I have to wonder if the extra core is because they couldn't get their software/programmers to play together nicely.

[JaniK]

What if;
One is all communications outside unit.
One is just a humble motor controller.
One acts as the trusty Messenger...

I no rich, here 2cnt. Much wow

[davefiddes]

station240: I'm not sure of the scope of your project but if you just want a TMS320F28379 to use for SW development and integration work then TI make the LAUNCHXL-F28379D dev board. It breaks out all of the pins we could possibly need. Looks like TI subsidise the boards and they are readily available from Farnell/Element14, Digikey, etc for $30 or so.

My hacky build of openinverter can be found here: https://github.com/davefiddes/c2000-sine
There is no HW integration to speak of but it runs and the serial console more or less behaves. I've suspended work on it for now until I can get the various SPI peripherals on the M3 inverter integrated into stm32-sine.

[station240]

station240: I'm not sure of the scope of your project but if you just want a TMS320F28379 to use for SW development and integration work then TI make the LAUNCHXL-F28379D dev board. It breaks out all of the pins we could possibly need.

It's a 377 BGA chip on that board, I already own one, trust me they did NOT break out all the pins we need.
Yes Tesla use the 176 pin LQFP, but there are still multiple pins that are either hard to get to, or not connected.
Plus they only have one onboard CAN transceiver, no LIN Transceiver, and none of the other analogue stuff on the M3 controller board.
Idea is to have a board to test the software w/out the umteen kilos of Motor attached.

My hacky build of openinverter can be found here: https://github.com/davefiddes/c2000-sine
There is no HW integration to speak of but it runs and the serial console more or less behaves. I've suspended work on it for now until I can get the various SPI peripherals on the M3 inverter integrated into stm32-sine.

I'll have to take a look at that, see what else it needs added.

[Jack Bauer]

Excellent work guys. Need to circle back around to this soon. PCBway are hounding me again:)

[davefiddes]

No worries. Thought you were quite busy with other projects... I've just made a start on a driver for the TLF35584 PMIC which seems a bit more straight forward than the gate driver. No rush though.

[station240]

Couple of small points that needed their own short post.

The LV8907 is connected directly to the Micro, right ?
Where does pin 2 (sleep), and the RX/TX on the TJA1021 (LIN Transceiver) go to ?

Couldn't we use the MiniWare MHP30 to locally reheat the TI micro off the board ?
Review here https://www.youtube.com/watch?v=JKlTd1B6Au8

[Jack Bauer]

What I have worked out so far is here :
https://github.com/damienmaguire/Tesla- ... TDIAG1.pdf

I can trace out any others if required as the chip is now off the board. I'm certain there are MUCH better ways of removing the TI micro than what I showed but its what I had to work with