Tesla Model 3 Rear Drive Unit Hacking

[davefiddes]

I don't think I'd seen anyone say that the front drive unit used IGBTs before. If anyone harbours a desire to run this with Damien's board it would be useful to get an SPI capture of the gate driver initialisation sequence before removing the Tesla PCB from the rest of the inverter. It doesn't need any more equipment than a cheap ebay USB logic analyser and a handful of hook up wires. I'm assuming that driving IGBTs and driving SiC FETs will require different gate driver behaviour even if the circuitry is otherwise the same?

[Jack Bauer]

I'll see if I can get my hands on a front inverter. I did attempt to contact the German guy. So far no reply.

[uhi22]

Just saw: Beatbuzzer already started a thread: viewtopic.php?p=81871#p81871

[Jack Bauer]

[Beatbuzzer]

Good evening together!

I'm the "german guy" But you guys can call me Ingo as well.

First I wanna say, I'm not a professional. I'm just a hobbyist probing (and sometimes sawing) around and sometimes get to something. Content about that I'm only creating in german language, because there are so many english channels out there and I would like to make content for that part of german community, who isn't well in english.

While messing around with my flooded front drive unit I of course found Damiens videos about the rear inverter and was confirmend in some things, but also learned some more things.
And Damien, thanks for listening to crazy AI voiceover But no worries, your videos have to be listened to in original english. Otherwise that legendary ironic humor could get affected.
Where did you try to contact me? Sorry for probably missing your message.

So, to come to an end in this offtopic post: I have a front and a rear drive inverter over here. The rear drive inverter is still not disassembled, but will be. Actually I have some other projects on the table, because I want my youtube content to be varied. But if somebody has questions about my work, feel free to ask.

Greetings.

[Jack Bauer]

Welcome to the forum.

[Jack Bauer]

All gate drivers powered up, reset and waiting for spi configuration to be loaded.

[davefiddes]

All gate drivers powered up, reset and waiting for spi configuration to be loaded.

Um. I dont think you need to be worrying about the spi configuration. That's looks to be all in place and working. Those chips are generally very unhappy until properly initialised with a working isolated gate supply. In my experience if the fault light is out the gate driver chips are happy or the power is off.

If you're running the MG_DU branch code there's no reason it couldn't have just started working... I didn't check your schematic for any differences compared to the MG board. You might have just got lucky.

Can you check your error log for any GATEDRIVEFAULT or GATEDRIVEINITFAIL messages. Is it reporting 11 for the "hwrev" param? If so it's correctly identifying the TeslaM3 variant (HWREVS in param_prj.h needs updating to have the correct strings for the MG and TeslaM3).

[Jack Bauer]

Sorry Dave I should have said the gate psu is on and I just strobbed SD.

[davefiddes]

Every day is a school day it seems. Didn't know you could run the gate drivers without any config but the DS confirms this.

I've checked against your latest schematics and the code in the MG_DU branch stands, nothing has changed with the SPI and SD control that would break it that I can see. I don't see a ready signal on your gate PSU like the Tesla board has so you'll need to put in a delay before starting the gate driver. The current code tries to initialise everything immediately which won't work.

The TeslaModel3 class in teslamodel3.cpp is where you want to go putting your changes.

The board variant detection would benefit from this small tweak to show up correctly in the web interface:

Code: Select all

diff --git a/include/param_prj.h b/include/param_prj.h
index a82276c..4aef5ca 100644
--- a/include/param_prj.h
+++ b/include/param_prj.h
@@ -277,7 +277,7 @@
 #define CANSPEEDS    "0=125k, 1=250k, 2=500k, 3=800k, 4=1M"
 #define CANIOS       "1=Cruise, 2=Start, 4=Brake, 8=Fwd, 16=Rev, 32=Bms"
 #define CANPERIODS   "0=100ms, 1=10ms"
-#define HWREVS       "0=Rev1, 1=Rev2, 2=Rev3, 3=Tesla, 4=BluePill, 5=Prius, 6=MiniMainboard, 7=Leaf2, 8=Leaf3, 9=BMWi3"
+#define HWREVS       "0=Rev1, 1=Rev2, 2=Rev3, 3=Tesla, 4=BluePill, 5=Prius, 6=MiniMainboard, 7=Leaf2, 8=Leaf3, 9=BMWi3, 10=MG, 11=TeslaM3"
 #define SWAPS        "0=None, 1=Currents12, 2=SinCos, 4=PWMOutput13, 8=PWMOutput23"
 #define OUTMODES     "0=DcSw, 1=TmpmThresh, 2=TmphsThresh"
 #define STATUS       "0=None, 1=UdcLow, 2=UdcHigh, 4=UdcBelowUdcSw, 8=UdcLim, 16=EmcyStop, 32=MProt, 64=PotPressed, 128=TmpHs, 256=WaitStart, 512=BrakeCheck"

[Jack Bauer]

Yeah my initial modboard just ran them in default config as didnt have the spi worked out at that point. Sadly the good luck streak has finally ended. All the drivers fault as soon as pwm is applied. No doubt some error in the HW reverse engineering. I'll get spi coms running to try and narrow it down.

[davefiddes]

Hmm. That's unfortunate. Maybe it'll be fine with the correct config loaded. My driver code will need a bit of work to get useful debug info out of it beyond "There is a fault". Hopefully that won't be required.

[Jack Bauer]

Well, good news is red light stays out and pwm reaches the drivers but they are not happy. Guess I'll have to go in and see whats annoying them. In related news the variant detection is really messed up and needs to be forced to M3 but thats a small matter.

[davefiddes]

Bother. That's quite a complete failure. You'll need to trace through the initialisation code to figure out which bit it is getting upset by. An SPI capture might be necessary to verify that data is going into and then out of the SPI chain. It should look like the captures you took way back on the Tesla board.

I've got a shed that needs it's roof replaced while the weather holds. If I get some time later I'll add some better status debugging but that'll only help once the initialisation succeeds.

[Jack Bauer]

Capture attached. Funny. Am going roofing myself:) Thanks Dave.

[davefiddes]

I think I've figured out what's going on. The SPI bus is running a bit too quickly. It has to be under 5MHz.

If you modify spi_setup_teslam3() and swap the parameter passed to spi_init_master() from SPI_CR1_BAUDRATE_FPCLK_DIV_8 to SPI_CR1_BAUDRATE_FPCLK_DIV_32. I think this will make it run at 3MHz like the MG (spi_setup()) and hopefully work reliably. I don't think that anything bad will come of running the bus at a slightly slower speed.

I think it was like that because an earlier version of the SPI init was set up to work with the other SPI peripheral which is on a different clock and I forgot to change it back for v3(!) of the code.

[Jack Bauer]

Thanks Dave. Will try tomorrow.

[crasbe]

Also notable that reading out the registers after writing results in 0xAA for all of them. Perhaps it is indeed a timing thing.

One other thing that Damien wants to look into tomorrow is that the "STATUS1" is set to "UVLOH = VH undervoltage flag. It is forced high when VH is below VHoff threshold." and STATUS2 is set to "REGERRR", which can also be triggered by "– Isolated interface communication fails".

One hypothesis is that the VH is not at full level yet when /SD goes low and therefore UVLOH is latched.

[Jack Bauer]

SPI clock at divide by 32. Roughly 2MHz now. Same behaviour.

[davefiddes]

Clock looks sensible now. I'm still seeing odd values in the SPI decode. For example at 1s 854ms the driver is trying to send 0x9DD6 six times to write CFG2 register but this is decoding as 0x0DD6 and 0x1DD6 sometimes. From the behaviour this looks to be a capture artifact.

From what I can gather the initialisation is completing successfully and is reading OK status values from each of the STATUS1,2 and 3 registers (it returns 0x000C in all cases). I'm surprised it is posting GATEDRIVEFAULT or GATEDRIVEINITFAIL errors.

I have a gate driver test program for the tesla board that successfully initialises the gate drivers and runs for a few seconds before turning off the gate drive PSU and logging the power good pin and gate driver fault status. This shows the PSU fail and then a gate driver fault be reported shortly after. Perhaps doing something like this would be useful.

[uhi22]

Just to be sure: sampling clock frequency of the saleae is high enough? And SPI mode is the same for controller, gate driver and Saleae?

[crasbe]

Clock looks sensible now. I'm still seeing odd values in the SPI decode. For example at 1s 854ms the driver is trying to send 0x9DD6 six times to write CFG2 register but this is decoding as 0x0DD6 and 0x1DD6 sometimes. From the behaviour this looks to be a capture artifact.

The analyzer settings in the decoder are set to CPHA=0 whereas the bus communication is CPHA=1. Therefore the data is sometimes misinterpreted, even though it is valid.

[crasbe]

From what I can gather the initialisation is completing successfully and is reading OK status values from each of the STATUS1,2 and 3 registers (it returns 0x000C in all cases). I'm surprised it is posting GATEDRIVEFAULT or GATEDRIVEINITFAIL errors.

No, it is returning 0x08 on STATUS1, 0x04 on STATUS2 and 0xE4 on STATUS3 (but the higher bits are unspecified).
0x000C is the CRC of the NOP command that is sent on readout from the STM32.

[davefiddes]

That's correct. I have not had much sleep. I think I need a break.

Edit: One thing I remember from my earlier works with these chips is that the Don't Care bits in the status often assume random values and have to be masked off. The code deals with this but any manual analysis has to also take this into account.

[Jack Bauer]

Okay. 5 sec delay between power on and starting spi coms. No errors.
PWM reaches the drivers but is not passed through.
also set the analyser to CPHA=1.