openinverter forum

Edit May23 - Have changed the thread title to better reflect the later contents.

Just looking at the DESAT/MGx_FAULT handling specifically for Toyota inverters running OpenInverter logic boards.

From what I've read the Toyota IGBT drive board actually handles the desat side by turning off the IGBT itself and the fault line is more to flag that it is happening. In this case there seems to be no real need for the inverter to fully trip.

I'm wondering whether, just on the Toyota inverter, it would be better to treat the fault output in much the same way as an over temp and derate instead of tripping. Specifically I was wondering whether to back off the throttle by 0.1% for each pass of the control loop in which the FAULT line was active (and light the MIL light so the driver is aware of the issue). This would give full throttle backoff in around 125ms, should still protect the inverter while also avoiding any an unpleasant side effects associated with shutting down the inverter above base freq. The reverse would happen in the FAULT flag was clear to restore full throttle availability.

Has this been tried before, if so did it work. Can anyone see any reasons not to try it or know of any other alternatives that might be better?

Interesting thought. Remains to find out how to reset the error, i.e. do you need to keep PWM silent for a given period. Or is it ok just to keep going.

My guess is that the IGBT driver just blanks the output for a single PWM pulse and also flags the occurence to the logic board. Anything else could have quite nasty consequences if the motor is operating past base frequency when a desat occurs. Flagging it allows the micro to decide the best course of action while blanking the pulse protects the IGBT.

Could really do with looking over the Toyota driver board to confirm but it's out in the workshop and I'm full of cold/flu today so that's unlikely to happen in the near future. Does anyone happen to know that part number of the IGBT driver IC that Toyota use on the Gen3 inverter? (it's the QFP next to the IGBT connector on the driver board).

I have taken the top board out to expose the driver board. Each IGBT has the following pins going to the IGBT on the pcb: E S G A K *.
Took the inverter outside into the sun to try and see through the yucky crazed varnish stuff hiding the numbers.

Got:
TM-001
DE066
148
C
with some sort of QR code next to 148 and C.

If you know of a solvent to carefully remove this varnish stuff I could get it then try again.

Kind regards Pete9008.

Johnspark

Will send photo shortly.

Thanks Johnspark, that's perfect!

I'm guessing the E S G A K must be Emitter, Substrate (collector), Gate, Anode and Cathode which indicates that there is a temperature sensing diode on each IGBT

The DE066 looks like a Denso part, unfortunately I can't find any data for it so guessing it it Toyota specific

Your last picture has given me an idea though. D1306 looks like it might be part of the standard desat detection circuit. If it is then it should be possible to inject a signal after it from a sig gen to simulate a desat event on the bench and then see what the driver board does. I'll give it a try.

Probably be next week though as my wife has just tested positive for Covid I'm still negative but feeling pretty rough so think it's just a matter of time before I test positive too - so my normal,fairly slow, rate of progress on the car conversion is likely to drop to zero for a while!

Ages ago Pete9008, I downloaded a pdf of an IC, and had another one printed off of an IGBT which I have turned into 2 jpg pages (sorry missing pg 48). Here it is for you. It uses the ESGAK. AK terminals are for a diode on the substrate isolated from any other connections, used for measuring substrate temperature. E is Emitter of IGBT, G is gate of IGBT, S is current sensing.

Hopefully this stuff will be of help,

Kind regards, and all the best with family health.

Johnspark

Thanks Johnspark. I think you are probably right on the current sensing. Looking again at you pictures there is a trace coming off the S pin and it was bothering me that it didn't seem to have the clearances needed for a connection to the collector, it would make sense for a current sense pin though.

That puts a whole new spin on protection on the Prius inverters, they don't do desat, instead they keep the IGBT in the safe operating area so preventing desat from occurring at all!

Once I get it on the bench it should be fairly easy to verify the above as the waveforms on the S pin will be distinctly different in each case.

Thanks for that

Edit - slight correction - it's possible that the drivers do desat protection as well (although so far I have been unable to see where the required connection to the collector is made). However, I'm pretty convinced, from looking at the pcb pictures, that they are primarily relying on limiting current by monitoring a split emitter connection on the IGBT (possibly with an adjustable limit which depends on die temp as described in Johnspark's datasheet).

Finally got back to this!

The connection between the control board and the IGBT has five pins per IGBT - E, S, G, A and K. A and K seem to be a temperature sensing diode. G is the IGBT gate and E is the emitter. The question was whether S was for desat monitoring via a collector connection or for IGBT current monitoring via a split emitter connection.

First indicator is the S pin measures ~10R to the E connection (irrespective of polarity), this is consistent woth a split emitter sense connection. Second is when measuring the voltage across S to E while the motor is spinning you see a low voltage signal which is proportional to motor current. With motor current set to 20A then 20mV is seen across each IGBTs resistor meaning each IGBT sense is scaled at 2mV/A. There is no sign of any of the higher voltage waveforms associated with desat detection.

Based on the above it looks fairly clear that the Prius Gen3 protection is based on IGBT current and temperature monitoring, it measures the individual IGBT current and temperature and keeps the device within its safe operating area (description in the data sheet posted by @johnspark above). It's possible it also does desat detection but if so I don't know how as I haven't been able to find the required connections to the IGBTs.

Based on this I'm going to change my code so that the inverter derates on a MG1 or MG2 fault rather than tripping and see how I get on!

Little more information, I've simulated both over temperature and over current trips on a Prius Gen3 inverter by using a sig gen to feed the appropriate signals onto the sense pins to see what happens.

Both the over temp and over current cause the MG fault output to go active for a minimum of 130ms (even if the input pulse is much shorter, tested with 100us pulse) and disables IGBT switching on ALL phases/IGBTs so it looks like the idea of trying to derate rather than trip isn't going to work. Slightly surprised by this as if the motor is operating in the field weakening region shutting down the inverter completely is not ideal! Assume it's down to the controller to monitor the die temperature and current make sure it never gets too close to the limit.

(Edit - Could be talking rubbish above. Not convinced that I disabled the timer break function in the firmware. It might still be the firmware shutting down the PWM until the fault flag lifts. Need to check and redo the tests )

Also worth mentioning that the over current trip for each IGBT seemed to occur with around 550mV on the shunt resistor. At 2mV/A that would be 275A per IGBT or around 550A for the pair. If the IGBTs don't share perfectly then this total would drop a bit so this matches well with the 500A trip threshold measured before.

Not too sure about the temperature trip, it appears to be a pair of series sense diodes measuring around 1.6V at room temp. Pulling it down to 500mV definitely triggered a trip but not too sure where the exact threshold voltage is or what this corresponds to in degrees C. Will have to come back to this once I've characterised the sensor properly.

Had another look at this and the IGBT control board does disable all PWM for the duration of the MG fault. It does this by disabling the supply to the logic board PWM pull ups which was what was confusing me (when scoping the connector pins it looked like the logic board PWM has stopped when it actually hadn't). So this confirms the above, derating isn't going to work, it's either trip or try to ride though the 130ms shutdown (probably the former!).

While doing this I also had another look at the temperatures:

The temperature currently reported as the heatsink temperature is actually the die temperature of the centre phase low side IGBT (the one referred to on the PCB as device 1). I've proved this by adding a resistor across the A and K connections for the IGBT temperature sensing diode and monitoring the web interface while forcing the diode voltage. This has also allowed me to better characterise the sensor and I think we may be reading it wrongly (assuming that I've got my board set up right - I'm using the Semikron setting for snshs??).

The voltage measured at room temperature is 1.5V. This is about right for a pair of temperature sensing diode in series. Based on a measurement of the voltage at room temperature and an assumed characteristic of 2.1mV (or 4.2 for the diode pair) per degree C (assuming it's actually a diode connected transistor which gives better stability) gives a diode pair voltage to temperature characteristic of: Worth noting is that the Prius built in over temperature trip occurs at a diode pair voltage of 0.83V (and resets at 0.87V). This corresponds to a trip when the die temperature hits about 175C. This is a little high but does match the higher end specified for IGBT modules so I'm inclined to believe it.

Next I measured how the diode voltage relates to the voltage on the STM pin giving this:
Which is nice and linear which is good. Also of interest is that the voltage to the STM bottoms out at 0.334V on the pin or 1.077V on the diode (you can just see the plot starting to straighten out in the graph - I didn't include the extra points so as not to mess up the trend line). This equates to about 120C and would suggest that the inverter designers intended the IGBTs to normally be kept below 120C even though the safety trip is 175C - so a pretty big safety margin.

Finally I compared how the temperature calculated from the diode voltage compared to the temperature reported by the web interface for tmphs and got this: Now that is quite a significant error and may explain why some people have commented that it was difficult to use the heatsink temp as it moved around so much! Alternatively I've got something wrong somewhere - let me know if you can see any flaws in the reasoning!

Going to have a look at the alternative sensor characteristics built into OI to see if there is one that matches better, if not I'll create one.

Edit - just realised that there is one more test I should do - bias the temperature sensing diode so that it looks like its at 120C and then see whether the current trip threshold point has changed. Guessing that the current threshold may drop as the temperature goes up?

Final test - biased the temperature sensing diode to simulate 120C and then drove the current sense to simulate high current to see whether the trip threshold changed - answer no difference

On this phase (middle) the trip level is slightly lower at 510A regardless of whether the IGBT temp is 25C for 120C so no temperature derating.

Also created a new sensor lookup to suit the above data (tweaked slightly as I think the inverter had warmed up by a few degrees yesterday which I hadn't accounted for). The changes are:

Class definition enum change and new lookup definition in the temp_meas.h file: Change to sensors[] array and new lookup array definition in temp_meas.cpp: And changes to param_prj.h: I'll update the auto_setup branch on my github to include this too. This should make a big difference to the temperatures reported!

Edit - Have also change the thread title to better reflect the contents.

Are you planning to pull request auto_setup to master?

Was going to wait and see if the F103 auto-setup stuff works first

And even then only if someone explains how to do it!