Tesla Model 3 Rear Drive Unit Hacking

[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]

[Beatbuzzer]

Do you have any thoughts about the sort of pyrofuse, placed in the newer rear inverters? Would you transfer it to your design or remove it? I mean, it simply goes away by removing the pcb Only attached with two screws in the frame of the hall sensor.

Seems its not only placed in plaid, but also in Model 3 long range and standard range from 2022. My rear inverter is a 3D5 from 2022 and has it.

I'm in a little research at the moment. There is an additional circuit on the right side of the pcb. Connection of the squib is wired in parallel to the two bigger 499R resistors.

[davefiddes]

Managed to get my JTAG connection working again so I can make some improvements to the Tesla M3 gate driver support:

https://github.com/davefiddes/stm32-sin ... provements

So far I've included the various fixes from above and a new version of the gate driver class. This has a correctness fix in the initialisation verification process. It also pipelines SPI requests when polling the status which makes it substantially more efficient. Both changes more accurately reflect the behaviour of the original Tesla firmware.

I'm planning on parsing out the gate driver failures and reporting them as spot values shortly.

[Jack Bauer]

Thats excellent Dave. Thanks. I've been cleaning up the board and getting ready to order V2. By the time it arrives I'll have the Volvo V50 test mule in the barn and ready for full up tests.

[davefiddes]

Meanwhile in Open Source development... I have finished making the updates to the Tesla M3 gate driver support code to pull out the detailed fault information:

https://github.com/jsphuebner/stm32-sine/pull/51

@crasbe was absolutely correct in their analysis as to the order in which replies are received from the gate driver SPI chain. My new code now pulls out the details of any fault on a chip by chip basis. If you are having a good day it looks like this:

Code: Select all

...
uptime              : 22820 [10ms]
cpuload             : 2 [%]
m3_phaseA_hi        : OK
m3_phaseA_lo        : OK
m3_phaseB_hi        : OK
m3_phaseB_lo        : OK
m3_phaseC_hi        : OK
m3_phaseC_lo        : OK

Given the sorts of issues with the high-side SENSE pins being not connected properly to ISOGND we saw the other week it would look like:

Code: Select all

...
uptime              : 22820 [10ms]
cpuload             : 2 [%]
m3_phaseA_hi        : OK
m3_phaseA_lo        : DESAT
m3_phaseB_hi        : OK
m3_phaseB_lo        : DESAT
m3_phaseC_hi        : OK
m3_phaseC_lo        : DESAT

If the gate drive PSU turns off unexpectedly:

Code: Select all

...
uptime              : 22820 [10ms]
cpuload             : 2 [%]
m3_phaseA_hi        : REGERRR, REGERRL
m3_phaseA_lo        : REGERRR, REGERRL
m3_phaseB_hi        : REGERRR, REGERRL
m3_phaseB_lo        : REGERRR, REGERRL
m3_phaseC_hi        : REGERRR, REGERRL
m3_phaseC_lo        : REGERRR, REGERRL

It's probably bolting the door after the horse has departed but hopefully it'll be helpful should anything go wrong. Some of the errors it can report I don't think will ever be reported (ASC and SENSE) but better to have the decoding in there than be left in the dark if something weird happens.