Tesla Model 3 Rear Drive Unit Hacking

[Jack Bauer]

Capture with pwm on.

[davefiddes]

All looks happy (really this time) assuming no fault errors being logged.

Amusingly you can see in the trace just how hard the STM32F1 has to work when generating PWM as there are some odd looking gaps between writes to the chips. This is fine by the protocol as I understand it, it's just the minimum that matters and keeping the CS asserted until everything has been clocked through all the chips.

I think the reason you are not seeing PWM on the output is because the ~SD~ pin is still de-asserted. Stick a call to TeslaM3GateDriver::Enable() in an if at the end of TeslaModel3::Initialize():

Code: Select all

void TeslaModel3::Initialize()
{
    if (!TeslaM3GateDriver::Init())
    {
        ErrorMessage::Post(ERR_GATEDRIVEINITFAIL);
    }
    else
    {
        TeslaM3GateDriver::Enable();
    }
}

It would be an idea to remove any stray calls to DigIo::gate_sd_hi.Set() or Clear(). I think it's clearer if you leave it to the gate driver code to control that.

It may start tripping faults again but you should hopefully see something on the gate driver outputs.

[Jack Bauer]

Thanks Dave will give a shot tomorrow. Yeah I recall the gaps in the spi when under pwm from when I ran the modboard. Didnt seem to cause any problems.

[crasbe]

Also the configuration is read back correctly, I just went through the logs and checked.

Does that mean we get to see some motor spinach tomorrow?

[Jack Bauer]

Sadly not. Now with SD set properly as soon as pwm hits they drivers they go into fault.

[davefiddes]

Progress.

At 3.507s in the trace it looks like the DESAT flag is triggered on the even gate drive chips which should be all the high-side drivers (U293, U292 and U291 on the Tesla board). Everything else looks OK.

You should see PWM coming out of the low-side.

I'll try and find some time to write code to get this status information out of the chips and into some spot values.

[crasbe]

Copy&Paste from Discord:

I think I might have an idea. So the DESAT circuit of the high side makes sense:
- GNDISO is at the source potential of the IGBTs through the 56R resistors,
- the drain of the IGBTs is connected to HV+,
- the DESAT circuit is now approximately as in the datasheet, with the addition of the 1k resistor, because the DESAT pin is connected to HV+ via the
VN17 diode (aka. to the drain of the IGBT),
- the JV diode is probably just protection,

The low side of the DESAT circuit is a bit odd, but we follow the same scheme:
- GNDISO is at the source potential of the IGBTs through the 56R resistors,
- GNDISO is also at HV-
- this is probably a bit redundant, because the low side IGBT source should be hard at HV- anyway,
- we don't have direct access to the Drain of the IGBTs,
- however: DESAT is determined by measuring the current, therefore it would be fine to go to the Source of the high side and run the test current through the motor windings as well
- Source of the high side = GNDISO of the high side

My hypothesis is that there is a dot missing connecting the DESAT circuitry of the low side driver to the GNDISO of the high side:

For my assumption to be valid, the low side drivers would have to have faulted out and the high side drivers should've been fine.

I found some documentation suggesting that they actually work as shift registers, BUT they are fed "backwards". The first device in the chain is the low side driver of Phase B. That means the last in the chain (and the first that is read out) is the high side driver of Phase A.
Therefore the second device that's read out is the low side driver of Phase A, which fauled out.

[crasbe]

The documentation: https://kth.diva-portal.org/smash/get/d ... TEXT01.pdf page 50

CK and CS lines are still common for all node, but now, if the master
initiates a message transfer, its data will be shifted to the first device, data of the first to the second and
so on until the circle closes and the master receives the data of the last device in the chain. Repeating
this process the number of times devices there are, the master ends up receiving the content of each slave
device’s register, meanwhile it sent one meaningful message to each one of them.

[davefiddes]

That wasn't my understanding. The way they seem to work is that the commands are processed by the first chip in the chain. If the command is valid (using the CRC I think) the first chip then passes through subsequent bits to the next chip in the chain. The process resets when the ~CS~ pin is deasserted. The result is that the MISO receives the data in the order in which it was sent to the chips (i.e. first to last).

This was verified back in the early days of the reverse engineering with SPI captures. If there is any doubt put a tap on the SDO of the first chip and add that in to the capture.

Unfortunately I don't have a working debug adapter (and other stuff to do) so can't fire up my inverter board to verify. Sounds like you and Damien have things in hand.

[crasbe]

That wasn't my understanding. The way they seem to work is that the commands are processed by the first chip in the chain. If the command is valid (using the CRC I think) the first chip then passes through subsequent bits to the next chip in the chain. The process resets when the ~CS~ pin is deasserted. The result is that the MISO receives the data in the order in which it was sent to the chips (i.e. first to last).

That is for shifting the data into the the gate drivers though. For shifting the data out of the chips, the last chip has to shift out it's own buffer first, because it couldn't have received the data from the previous chip(s) yet.

Therefore the first two bytes shifted out of the chain have to be from the last chip, which is a high side driver, which has no fault. The following two bytes are from the low side driver.

[crasbe]

Damien confirmed that Pin 16 (SENSE) and Pin 13 (GNDISO) of the High Side Drivers are connected on the original Tesla M3DU boards.
That would be supporting my hypothesis.

[Jack Bauer]

[johu]

The day of working inverters viewtopic.php?p=82795#p82795

Persistence paying off, great job!

[Jack Bauer]

Sorry for the late update folks. Been down with a stomach bug. But hey , its been 5 years so whats another week. Anyway, before running any real power through the inverter I decided to scope the gate-source waveforms just in case. High sides looked fie but all THREE lowsides showed this sort of a weird ground bounce effect of the other 2 low sides switching. Did dome probing around and narrowed into the "56Ohm" source resistors. Hmmm. Guess what? They are not 56 Ohms on the OEM board.... rather 0.56Ohms!!!

Got the right ones ordered but still feeling very happy about progress on this 1st prototype.

[johu]

Nicely caught in time!

[Jack Bauer]

Just a model 3 inverter with an OI board running a model 3 motor.... nothing interesting:)

[Jack Bauer]

For those interested current V2 board schematic. Not finalised yet but has corrections from V1 and now all component values and types populated. Basically the current board minus the bodges:)

[Jack Bauer]