Tesla Model 3 Rear Drive Unit Hacking

[Bratitude]

my board finally arrive safe and sound

i have now the following: 1x 3D5 rear drive unit and 2 front drive units, one of which is 3D1.

wiki page started here: https://openinverter.org/wiki/Tesla_Mod ... e_Unit_PCB

the rear inverter has pyro fused "crow bar" phase terminals, where as the front inverter dose not (rear being permeant magnet motor, front being induction motor)

[outlandnish]

Did you check the board was working before soldering it to the inverter chassis & mosfets? I would recommend bench testing with just 12V and CAN. The inverter should come up and report that the gate drivers are all OK. It doesn't need the big mosfets to function. You shouldn't need to dismount to debug though.

The REGERRR and REGERRL errors are the sort of thing I have seen when the gate drive PSU is turned off. It would be worth double checking the gate drive PSU for each phase in turn. You do this with TP6/TP7/TP8 for phase A, TP9/TP10/TP11 for phase C and TP12/TP13/TP14 for phase B. I measured 12.7V for the positive supply and -5.1V for the negative supply for each phase. This matches Damien's video I think.

If the phase C PSU is not working it may have current limited as Damien explained. You might have to desolder the relevant STGAP1AS to see if it is a PSU problem or a gate driver chip problem. I found access around the "hot" side of the gate drivers to be quite fiddly. I can imagine it being really easy to end up with a short or nudging one of the many passives.

Running the latest build in the V50 now from Dave's github. All temps reporting correctly.

In general, do please follow the procedure in the video. I know it's tempting to skip parts when you want to see a result , I know that all too well but it almost never works out to be quicker.

I did check these voltages as per the video when I did it initially - the video only covers TP6/TP7/TP8. I didn't know to check the other ones. The other mistake I did make was that I didn't check with WiFi after this step to see that they were all ok.

That said, these are my voltages. Interestingly, I only see a discrepancy on Phase B (which seems inverted compared to the silkscreen labels and with drastically different voltages)

Phase A TP7: TP6 / TP8: 12.74V / -5.16V
Phase B TP13: TP12 / TP14: 3.544V / -14.02V
Phase C TP10: TP9 / TP11: 12.83V / -5.12V

I can understand Phase B giving me problems given it was the first set of gate drivers I soldered on. Is there a chance the errors on the interface are attributed to the wrong gate driver? In the mean time, I'll check the Phase B gate drivers and see what's going on

[davefiddes]

It's entirely possible the gate driver status is wrong. :-/ I'll investigate but it'll be tomorrow before I get to that.

Voltages for Phase B look wild. The zener in the PSU should stop the negative rail getting below -5.1V.

[Jack Bauer]

Yeah the zener "lifts" the iso ground to 5.1v thus creating the neg and pos supplies from a single output of the transformer. Its not a very strong ground so any short or damage will cause it to read weird.

[outlandnish]

That was it! It looks like at some point during installation the D8 diode lifted off of the board. Fixed that and no more gate driver issues.

It looks like the error messages for Phase C Hi and Phase B Hi are flipped

[Jack Bauer]

Not much to report today as not much traction during monsoon season. That said I have now desatted this inverter at least 50 times and it just starts back up. I might try and make diy mud tyres by driving a box of tek screws into them...

[outlandnish]

@Dave, here's a PR that addresses the error ordering. I don't have the board in front of me to test unfortunately, but let me know how it gels with your understanding of the hardware: https://github.com/davefiddes/stm32-sine/pull/1

[davefiddes]

Thanks for finding the problem there outlandnish. It's a pretty facepalmingly stupid bug on my part. No idea how I managed to get that in there. Your fix is on the right track but is actually the reverse of what's required. The way the gate drivers work is that the first data to be clocked out when reading the status comes from the last chip in the chain ( i.e. phase A high-side) and ends with phase B low-side.

Armed with the results of Damien's testing and the knowledge that I can fix anything if I let the magic smoke out I found a way of triggering faults on the high-side. I found that if I short the Source and Gate pins of the high-side drivers I can trigger a UVLOL error. With my most recent commit in place I can now force an error in each high-side and the correct error is reported over CAN. No magic smoke so far.

I've not found a way of getting the low-side gate drivers to fault individually. It doesn't matter as the ordering of data is obvious (when I pay attention ).

As part of my work on the gate driver I've built a Saleae Logic analyzer plugin. This is quite useful for verifying the hardware is behaving the way it should and saves a lot of tedious and error prone parsing of serial data streams. Not necessary to find the bug but a reassuring cross-check. I plan on publishing this in the Saleae Logic 2 Extension "store" as it seems useful beyond our project here.

[Gr8adventures]

I received my beta board this week and got started on soldering the transistors, gate transformer then the gate drivers . Got to the first 12v power up test but got the gate fault l.e.d. lighting up tried resoldering a few of these drivers assuming they may be the culprit but still have the same three leds lighting up with the activity light blinking. I noticed in damiens video that he hooked up the wifi board. My question is if there was a way to isolate the problem driver or other component with the WiFi web interface or some other troubleshooting method. Thanks in advance for any ideas or support!

[outlandnish]

Thanks for finding the problem there outlandnish. It's a pretty facepalmingly stupid bug on my part. No idea how I managed to get that in there. Your fix is on the right track but is actually the reverse of what's required. The way the gate drivers work is that the first data to be clocked out when reading the status comes from the last chip in the chain ( i.e. phase A high-side) and ends with phase B low-side.

Armed with the results of Damien's testing and the knowledge that I can fix anything if I let the magic smoke out I found a way of triggering faults on the high-side. I found that if I short the Source and Gate pins of the high-side drivers I can trigger a UVLOL error. With my most recent commit in place I can now force an error in each high-side and the correct error is reported over CAN. No magic smoke so far.

I've not found a way of getting the low-side gate drivers to fault individually. It doesn't matter as the ordering of data is obvious (when I pay attention ).

As part of my work on the gate driver I've built a Saleae Logic analyzer plugin. This is quite useful for verifying the hardware is behaving the way it should and saves a lot of tedious and error prone parsing of serial data streams. Not necessary to find the bug but a reassuring cross-check. I plan on publishing this in the Saleae Logic 2 Extension "store" as it seems useful beyond our project here.

All good, I had similar types of weirdness with an ST daisy chained driver for low / high side drivers in my VCU. What ended up helping there was grabbing a couple of reference boards to do tests like that without wrecking a full board. That's cool you built an extension for that. I'd love to learn more!

[davefiddes]

I've published my Saleae Logic 2 extension for the gate drivers here: https://github.com/davefiddes/STGAP1BS-SPI-Analyzer Hopefully it'll appear on their "store" shortly. You can install it manually by downloading it and loading it in Logic 2. Instructions for how to do this are in the repo README.

I wished I had started with the Logic 2 analyzer. It would have saved a lot of time and bugs. Definitely a skill that's worth learning if you are dealing with complicated serial protocols. Debugging analyzers can be a bit painful so I'd recommend starting small and building up incrementally.

There's another analyzer I created for the oil pump LIN protocol. I'm planning on sending it to Damien shortly but can be found here: https://github.com/davefiddes/Tesla-Mod ... Pump%20LIN

[davefiddes]

My question is if there was a way to isolate the problem driver or other component with the WiFi web interface or some other troubleshooting method. Thanks in advance for any ideas or support!

I'd definitely recommend getting set up with a CAN configuration tool, either esp32-web-interface or OpenInverter CAN Tool. You'll need this once the inverter is bolted into the motor.

The WiFi interface works just fine on the bench and will get you up an going if that is all you have to hand.

To debug your problem with the gate drivers you should look in the Spot Values for the "m3_phaseX_XX". When operating correctly these should be "Ok" but as your fault LED is lit (the one near the US/IE flag) it'll be an error. Some possible errors:

• RxCRC indicates that data is not making it back from the gate driver chain. Check the soldering on the upper side of the chips.
• REGERRR and/or REGERRL indicates a gate driver PSU failure of some nature. Check the voltages are as per https://openinverter.org/forum/viewtopi ... 779#p87779

If you see different errors on different chips it would be advisable to upgrade the firmware to the latest build from https://github.com/davefiddes/stm32-sine/actions. As above I fixed a problem where the gate driver error wasn't being reported to the correct phase.

[Jack Bauer]

Latest firmware, cranked field weakening to 150Amps, tied the T3RD to the back of the JCB and opened up the taps. Sadly the 9kwh bmw hybrid pack aka "ScamBatt 9000" is sagging and limiting power but not much left of the tyres.

[Jack Bauer]

Here is a log driving around the yard along with the current parameter set from today's testing. Dave, is it possible to alter the logging time interval?

[davefiddes]

Yes but only in 1 second steps. If you add "-s 5" or "--step 5" it'll go in 5 second steps. I'm guessing you're looking for less than 1 second though?

Edit: If you are after smaller time steps than 1 second you're better setting up a CAN map for the params you are interested in. You can use "oic can export --format dbc my-datalog-map.dbc" to create a DBC that is acceptable to SavvyCAN. Then just use SavvyCAN for logging. The CAN SDO protocol used by OpenInverter CAN Tool et al is quite verbose and will clog up the CAN bus when polling for lots of variables at high frequencies.

[Jack Bauer]

Thats grand thanks Dave.

[davefiddes]

You never know until you try stuff. I've updated OpenInverter CAN Tool to allow fractional second steps between log entries. With a step of 0.1 and you log ALL parameters you only get about 3 a second, VALUES does better at about 6 entries. Nothing melts down and the inverter runs fine.

For proper real-time performance a CAN map is best but this probably easier.

[Jack Bauer]

Works a treat Dave This log is from my wife doing a burnout and then a trip when she gets a bit too carried away...